From nobody Fri Sep 1 10:24:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDFA13440B for ; Fri, 1 Sep 2017 10:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Sx5hzujY3qYx for ; Fri, 1 Sep 2017 10:24:10 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAAE81341B0 for ; Fri, 1 Sep 2017 10:24:09 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id g13so2308040pfm.2 for ; Fri, 01 Sep 2017 10:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mHGQi45fdl2fgr8rVlX+bZWXujD+V6eFo++XhIO5vEo=; b=tjQr9rVkJ+ZzOIe4fxuDPkTI+/7WfZ0V+B12dlb7MIReOOfc5/VxlqgtgJQdIbGX6d 3ltVLyDGAHgBu27pwiyVTvPCVHFrCSdIirZ5nEcK9X7+l0jWBP1u4rIMXYc9VvdEoAe3 mydktCXkeE5VrrvIWRCb+T1INVlYZfA1P8SVVqD53buWghsDlten/o3sBapbVZaQ94Oz sfa58BmxoH6DanKx0y+8KR8A2cA8bIsyTSUUPWDZmriftxBZjtCqUImfgliXRpE4fdy3 nBw6bhAcDpLovYCPc+xux5E9zpgo6F9mHK9dS1mNJJKP0+p3/EJda1RLnNbzNmWFFbgo HYZw== 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=mHGQi45fdl2fgr8rVlX+bZWXujD+V6eFo++XhIO5vEo=; b=VRuaol3BVs36qdSCAuMQMCLmMFcaqujpmez3x6igxWBfH5T7qt0bHXJmfUXnA0QH5S SVx/DzYQKuF80wIJDX/OdV+vrbc5typIjXScd6WCyjyiyKPXGetiag5vzBu93lZEl8Se 77t/SxS+I9kc03Iv7kvq3XkaQV3plyBjpzAbiHDbauVtYQE3jJ8B3PQLm5qvlcGM90tQ aIwq78rO4hlgV0r9v0+EN5+wXC+v5PpmhTh5MMK+cOmhDO6PiXWT22tdy4x6vfxBlb80 XnGFzP5XtXo9S/rAI//sS7f89n1wmSj/5yR+DiU8+XLVAFdrZyXY5Re4QpDLeJ1n/CQO BqGA== X-Gm-Message-State: AHPjjUhJ3pxit3iqU8za/5jZDGvR9ovo2DHnSqjYiDyEHEGOSt4OZhAn tqSsSBAZKUfo/6iR82IbuQ== X-Google-Smtp-Source: ADKCNb5I9p/Bvjb1eL1dYBf/8ke+xKPgauGynIgQ/Ncz+386TbI0QDU6PscfzMSFOjDuUPETF1gAuw== X-Received: by 10.84.229.1 with SMTP id b1mr3281594plk.207.1504286649389; Fri, 01 Sep 2017 10:24:09 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:447c:38ff:1448:a94e? ([2620:0:10e7:10:447c:38ff:1448:a94e]) by smtp.gmail.com with ESMTPSA id u67sm1001745pfb.73.2017.09.01.10.24.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Sep 2017 10:24:08 -0700 (PDT) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6FE952C9-77A3-4171-AAF8-EB1958D812E6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 1 Sep 2017 10:24:07 -0700 In-Reply-To: Cc: "v6ops@ietf.org" To: Brian E Carpenter References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 17:24:11 -0000 --Apple-Mail=_6FE952C9-77A3-4171-AAF8-EB1958D812E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 31, 2017, at 16:23, Brian E Carpenter = wrote: > On 31/08/2017 20:13, David Farmer wrote: >> On Aug 30, 2017, at 19:11, Lorenzo Colitti = wrote: >>>=20 >>> If there are any multicast RA/PIOs for these prefixes, they should = have >>> A=3D0; L=3D0 (cf RFC8028). >>>=20 >>> But I'm not sure why there would be any multicast RAs. They don't >>> seem to be needed. The draft talks about unicast RAs. >>=20 >> Unicast RAs would require the router to keep state on all its clients >> regardless of its IP addresses and across IP address changes. That = doesn't >> scale. It's much better for the router to send a multicast RA on each >> separate L2 link, knowing that it will go only to the host on that = link >> that has that prefix. >=20 > Nevertheless, > (a) the draft says unicast. > (b) hypothetically there *is* no separate L2 link for multicast; there = is just a > logical separation for unicast purposes. That seems to be what Ole = described. I think this is the basic reason I misunderstood the draft not to = require L2 isolation. It seems to me like the current draft still admits = the potential utility of using this scheme without L2 isolation, and I = think it leaves way too many open questions about how that would work, = including the question of how redirects should work. Cannot support until this issue is resolved. --james woodyatt > --Apple-Mail=_6FE952C9-77A3-4171-AAF8-EB1958D812E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 31, 2017, at 16:23, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 31/08/2017 20:13, David Farmer = wrote:
On Aug 30, 2017, at 19:11, Lorenzo Colitti <lorenzo@google.com> = wrote:

If there = are any multicast RA/PIOs for these prefixes, they should have
A=3D0; L=3D0 (cf RFC8028).

But = I'm not sure why there would be any multicast RAs. They don't
seem to be needed. The draft talks about unicast RAs.

Unicast RAs would require the = router to keep state on all its clients
regardless of its = IP addresses and across IP address changes. That doesn't
scale. It's much better for the router to send a multicast RA = on each
separate L2 link, knowing that it will go only to = the host on that link
that has that prefix.

Nevertheless,
(a) the draft says = unicast.
(b) hypothetically there *is* no separate = L2 link for multicast; there is just a
logical separation = for unicast purposes. That seems to be what Ole described.

I think this is the basic reason I = misunderstood the draft not to require L2 isolation. It seems to me like = the current draft still admits the potential utility of using this = scheme without L2 isolation, and I think it leaves way too many open = questions about how that would work, including the question of how = redirects should work.

Cannot support until this issue is resolved.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_6FE952C9-77A3-4171-AAF8-EB1958D812E6-- From nobody Sat Sep 2 00:14:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9B5134974 for ; Sat, 2 Sep 2017 00:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfDOMCVCakCW for ; Sat, 2 Sep 2017 00:14:03 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDEE113433A for ; Sat, 2 Sep 2017 00:14:02 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id f199so2041345ita.1 for ; Sat, 02 Sep 2017 00:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xx+ZeO9E9/yoLd+u48aOKWFSLWgz0fqIc18IFv0DZG8=; b=G4wsSKqOd0RysfqfIQCbOqcqWgVVJ2dCM4P/ca4Y9tdcmSg28/NfLLSwe0lPijXy0g EV8qEZIS4MvTmcXoJv92fboOd3EXAxtxaudNWmrpn2szn8qvcIV/eW6mM1eRl+DwF+gm NlEgDV+/oRubQnKnrS37mZRyLdDzovNT6XVI84AbL3xUuxuXn+tlO0rkCnkonWapADH5 IJ1fwN/1RPSEEH8/t7Osy+pY55gAKSO5CsuKSQyUq+NafKHoTAcJYjtrpy5BFnmlk5Sz 7Fhr9EuPTyI3HW+vrzyZg3lexVRYlPj0nHREz/QJ094k5zgpiUeOkt1/0cLoEVWw2AHX ozEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xx+ZeO9E9/yoLd+u48aOKWFSLWgz0fqIc18IFv0DZG8=; b=noXZPBUo1pPdbpUBZFiyD3uIAKIqCeiDKJZQW9sjuZZHTQxKyNDC80XMf/w39Qsv+C n/25/orst4yF4bJiWzZ4V7QZWFcjYm44hPYh/rEHBMubEpTYNV9v0QZsE+dGTUq/JK0e gMrHJ+U/rMoGfh2fgrclOiD96sYIB3oI+rOV14+jM8kChekI34naW6D9nIsj24l0hiG7 g7zyo0dcSLdRUKVcKgSihf2BXTx6CgYPFbvaUutQa+1/DGKoOTsnESHUhQHymC7vjJ/O N2cOiyXI4lJPKpc+UL+3LXzXGsocrbYOjZIz5Lage1e8b/Vc6Hqzt45RYvTVtlmj9JC0 tYJw== X-Gm-Message-State: AHPjjUgiNkxQwa9rN7yZoC6vAYvAXVr71cdaykgAxTFUJuWdMLctBRfE K8pCJ9FUpgRNvOQiL0HJMKlFRpqanBR7 X-Google-Smtp-Source: ADKCNb56BqKVZKZKPQrw+Kg5QyH4+dEHXigf1bgPh7RSAicmO/hgpwb+yNt9KfibBMssYCLtALZgH7PJz0mjITfwIQ0= X-Received: by 10.36.5.206 with SMTP id 197mr542140itl.79.1504336441947; Sat, 02 Sep 2017 00:14:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Sat, 2 Sep 2017 00:13:41 -0700 (PDT) In-Reply-To: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Sat, 2 Sep 2017 16:13:41 +0900 Message-ID: To: Brian E Carpenter Cc: David Farmer , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a113532623f527905582f9fd4" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Sep 2017 07:14:05 -0000 --001a113532623f527905582f9fd4 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 1, 2017 at 8:23 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > Unicast RAs would require the router to keep state on all its clients > > regardless of its IP addresses and across IP address changes. That > doesn't > > scale. It's much better for the router to send a multicast RA on each > > separate L2 link, knowing that it will go only to the host on that link > > that has that prefix. > > Nevertheless, > (a) the draft says unicast. > (b) hypothetically there *is* no separate L2 link for multicast; there is > just a > logical separation for unicast purposes. That seems to be what Ole > described. Layer-2 unicast, yes. They are unicast to the host and have an IPv6 destination address of ff02::1. --001a113532623f527905582f9fd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 1, 2017 at 8:23 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
> Unicast RAs would require the router to keep state on all its= clients
> regardless of its IP addresses and across IP address changes. That doe= sn't
> scale. It's much better for the router to send a multicast RA on e= ach
> separate L2 link, knowing that it will go only to the host on that lin= k
> that has that prefix.

Nevertheless,
(a) the draft says unicast.
(b) hypothetically there *is* no separate L2 link for multicast; there is j= ust a
logical separation for unicast purposes. That seems to be what Ole describe= d.

Layer-2 unicast, yes. They are unicast t= o the host and have an IPv6 destination address of ff02::1.
--001a113532623f527905582f9fd4-- From nobody Mon Sep 4 11:23:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E60124239 for ; Mon, 4 Sep 2017 11:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 T7Y0gu31r1Cq for ; Mon, 4 Sep 2017 11:23:21 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236CB124207 for ; Mon, 4 Sep 2017 11:23:20 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 5F82A746 for ; Mon, 4 Sep 2017 18:23:20 +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 f-vGNuF_BCrS for ; Mon, 4 Sep 2017 13:23:20 -0500 (CDT) Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 292B0719 for ; Mon, 4 Sep 2017 13:23:20 -0500 (CDT) Received: by mail-vk0-f71.google.com with SMTP id m142so554046vkf.5 for ; Mon, 04 Sep 2017 11:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vi2C7X5yUBYkQVHr0UK3aF1HrtKLeoVrqwl096IFIWE=; b=BSuklbfnp5haRLak/oq4ehPzfAosrn3Zw5uByAu3kNaRVqU/TYeA2cbEuSRds38Uwz 99Nu4y5RXzBOUq3EVmyJpsImS7ry/3ehJ4Xkl3xqXSCGcPghC/X9e8xtVM4RZfe3hHvY 8aEI4SFe3J1oBryZHY06ERNxmbvRgLreEBUIAFk808bwDwtOe8Z8tkZAhZA9lrdCyiPJ jvSzK4ISIqNgd8qxM6Q/nthnndBx8TlL6G0AF3usHoNOdA+UUGD0glr6K10AfY/Nnjhi rCjteBhUavhs5dAAMffkiTiUa+yJpROXQdQePtKp5dIyQgZoZm+v20P925W8zegU63xS vtyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vi2C7X5yUBYkQVHr0UK3aF1HrtKLeoVrqwl096IFIWE=; b=ULmcm3k42UDLpvEAUuI+dvHkHZoEUGixqdCMFXIIZB5VtmIJCMH6Irmo4KI4U5d9Kw t/O9k4Anqf/w0pUJNv6AFoVZWNwtatKorO6WtQe0J1KJDH1KS6alFxtJ+xv7FtjqCMUv t+zOhbyF4KZtmWnzP4Hc94i9Xc/JtvZzNBaOljxz2bbZCcpaRLzUCzXO1YUQl2WowjzZ rSwdLoF3xqi4kc3/8rU7UT6K2GUj5ZvQiPYkLlaeHvrhpuz7wtBF5uFFgWyqO0DUu1Tr hjr5ndIPlKN06Q5pC+CFOsd4S147Em0NSr0+eTFOxLgTP7CaI8NjnUbZNNO+LQR/mbR/ ogAA== X-Gm-Message-State: AHPjjUh5EP3vvDW0R+HGLBbC/UhLuV2MenkGjG/9FujfsFXOmeCx7a6a rzIOimkLV7y3AW+qjeOnAazqd2NB4POVuwMGFSao6WvA20EV3orMinF6q852PepqO3mVAGa5mx4 3EeCKJfTOV74xGmeh X-Received: by 10.31.142.72 with SMTP id q69mr739956vkd.81.1504549398752; Mon, 04 Sep 2017 11:23:18 -0700 (PDT) X-Google-Smtp-Source: ADKCNb4h4/X++DVyiaa5iQvRXOhjXg7i6QP+CSWSkXz+8geVRHjVj7i2DUBag1PniV3TziWDtG3JopMPtpMmIpUUHvU= X-Received: by 10.31.142.72 with SMTP id q69mr739951vkd.81.1504549398540; Mon, 04 Sep 2017 11:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.89.81 with HTTP; Mon, 4 Sep 2017 11:23:17 -0700 (PDT) In-Reply-To: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Mon, 4 Sep 2017 13:23:17 -0500 Message-ID: To: Lorenzo Colitti Cc: Brian E Carpenter , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a11436dac72b10205586134f9" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 18:23:24 -0000 --001a11436dac72b10205586134f9 Content-Type: text/plain; charset="UTF-8" On Sat, Sep 2, 2017 at 2:13 AM, Lorenzo Colitti wrote: > On Fri, Sep 1, 2017 at 8:23 AM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> > Unicast RAs would require the router to keep state on all its clients >> > regardless of its IP addresses and across IP address changes. That >> doesn't >> > scale. It's much better for the router to send a multicast RA on each >> > separate L2 link, knowing that it will go only to the host on that link >> > that has that prefix. >> >> Nevertheless, >> (a) the draft says unicast. >> (b) hypothetically there *is* no separate L2 link for multicast; there is >> just a >> logical separation for unicast purposes. That seems to be what Ole >> described. > > > Layer-2 unicast, yes. They are unicast to the host and have an IPv6 > destination address of ff02::1. > I to believe that is the intent, but that needs to be explicitly said in the draft. Further, the draft seems to only discuss the formation of RAs that are sent in response to an RS, the draft should also explicitly discuss the periodic RAs sent by the router. Even if that is as simple as saying they should be formed the same, and using same unicast L2, multicast L3 addressing, as the RAs sent in response to an RS. 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 =============================================== --001a11436dac72b10205586134f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Sep 2, 2017 at 2:13 AM, Lorenzo Colitti <<= a href=3D"mailto:lorenzo@google.com" target=3D"_blank">lorenzo@google.com> wrote:
<= div dir=3D"ltr">
On Fr= i, Sep 1, 2017 at 8:23 AM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
> Unicast RAs would require the router to keep state on= all its clients
> regardless of its IP addresses and across IP address changes. That doe= sn't
> scale. It's much better for the router to send a multicast RA on e= ach
> separate L2 link, knowing that it will go only to the host on that lin= k
> that has that prefix.

Nevertheless,
(a) the draft says unicast.
(b) hypothetically there *is* no separate L2 link for multicast; there is j= ust a
logical separation for unicast purposes. That seems to be what Ole describe= d.

Layer-2 unicast, yes. They are unicast t= o the host and have an IPv6 destination address of ff02::1.

I to believe that is the intent, but that needs to b= e explicitly said in the draft.=C2=A0 Further, the draft seems to only disc= uss the formation of RAs that are sent in response to an RS, the draft shou= ld also explicitly=C2=A0discuss the periodic RAs sent by the router.=C2=A0 = Even if that is as simple as saying they should be formed the same, and usi= ng same unicast L2, multicast L3 addressing, as the RAs sent in response to= an RS.

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunicat= ion Services
Office of Information Technology
University of Minnesota= =C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 6= 12-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a11436dac72b10205586134f9-- From nobody Mon Sep 4 11:38:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A56E126BF0 for ; Mon, 4 Sep 2017 11:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhZd86e469Qw for ; Mon, 4 Sep 2017 11:38:51 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89075126B6E for ; Mon, 4 Sep 2017 11:38:51 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id t75so9375314oie.3 for ; Mon, 04 Sep 2017 11:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=XSY1KE1ASPcHQOKJ45TbebgTHkaVvd5ukTSwYo7sEB0=; b=BhdU7CYeZrxQSzYmIHk1uaRM382hwg23CfrtS/dTboWSSrHIbQlKoLtwZo8nyiPdAi Y2FGjQPMRfeB6lfwjhD3RJC6Bkm0uzowdeiXUFhBu0ikWfj1PJ/iVFgpcAiP8pErj/fM 55/9bI6GmFuyX7SSG7ULHowpq3hmse1Vl05poXRwBWyVNSMdauJ9P5/CgiwUxSHK3R+V 0rm8DvsYW3PlQZ7I5qUF8a1DJzm0b/If/Lo6odKTf0PfaqcuaaRxR6yfCjjJ4Z7y9bQd j/Mol/LMKyFo/aCCvL5OQwUoBvDUNSupJ2zW70N8TjAdBXc7pz1b1SxEjeZRAzJj/yGl i7VQ== 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 :content-transfer-encoding:message-id:references:to; bh=XSY1KE1ASPcHQOKJ45TbebgTHkaVvd5ukTSwYo7sEB0=; b=aN7nqxC/apjV+KcXmT+rXq6/Ls96KwVWkFvbppb4j5fKMagVDQaFDmjGsWSsBmF1aJ lEBSFFBogtiXscXFuuqz2LCJ/jf4tQDvkMCJHWUoqXwWSOirp8zkp3JbyWahKMZaKbov nJQMWP6Qliid6cQD02C2u6S2+rvPv5s2csg6zdrr3Y3QPMwJzbmOzOh4awmWkBb4J+6u GOdVGO/Ybid/+XG7psk7bTvIozWcLe2adssKqV6fCJ3k4ayhyOuDeo2KzMBj/z9bRHUs 6VRjjn02Zf+BEdzeR1uXIfV+SB/OcPrI9g65bklQDKG3xtn4KbvppyvhWl03tEqZwP42 envw== X-Gm-Message-State: AHPjjUilkHaMF0hxWMYHXBLOZIPJIQsOtIBgFazbGXqwxi7c0IHGjuby hG30FqVNpKpAhTRuNsc= X-Google-Smtp-Source: ADKCNb7iybjzLQ0SjgOvGjWQQNTI2ESenCiQIvicnzOWutc1iYVz46QeBVHiVD36rn5lXD5+FwG6Tg== X-Received: by 10.202.56.194 with SMTP id f185mr1168855oia.249.1504550330630; Mon, 04 Sep 2017 11:38:50 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::11d1? ([2600:8802:5600:e::11d1]) by smtp.gmail.com with ESMTPSA id d26sm17643687oic.42.2017.09.04.11.38.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 11:38:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Mon, 4 Sep 2017 11:38:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> To: v6ops@ietf.org Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 18:38:54 -0000 Thought for today... Warren, Ron, Lee, and I are wondering how much of all this relates to the dr= aft mentioned in the subject line. I saw a note from, I think, Lorenzo the o= ther day asking that the applicability comment that communication between su= ch nodes on a LAN should go through a connecting router (which seems to me a= given due to the relationship with routing) should be documented.=20 Is there anything else here that comments specifically on this draft and sho= uld be considered in IESG review? If so, please respond and highlight it. On other matters, by all means please discuss. You might consider changing t= he thread, though. Sent using a machine that autocorrects in interesting ways... > On Aug 31, 2017, at 9:49 AM, David Farmer wrote: >=20 > You are talking about redirects as if they are a universal good, and yes > they are necessary in some situations, but they also have security > considerations. You claim the draft is ignoring the potential usefulness o= f > redirects in some environments and yes it is. However, you are ignoring > the potential additional security that not having redirects has in other > environments. >=20 > Further, you have not discussed any advantages that the use of prefix per > host subnets model has over the classic multiple hosts per subnet model in= > an insecure environment to justify the increased use of number resources b= y > prefix per host subnets model. Please explain some of the use cases you > think their are and why the prefix per host subnets model with redirects > has any kind of advantage over the classic multiple hosts per subnet model= . >=20 > Thanks. >=20 > On Thu, Aug 31, 2017 at 10:18 AM, Templin, Fred L > wrote: >=20 >> Hi, >>=20 >>=20 >>=20 >> The simple point in all of this is that Redirects are (and will remain) a= >>=20 >> useful component of IPv6 ND, yet this document seems to deprecate >>=20 >> their use in all cases even for links where use of Redirects is essential= From nobody Mon Sep 4 13:18:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04520128D0F for ; Mon, 4 Sep 2017 13:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJxFgstcZAl2 for ; Mon, 4 Sep 2017 13:18:01 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC93D12422F for ; Mon, 4 Sep 2017 13:18:01 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id t3so3727660pgt.0 for ; Mon, 04 Sep 2017 13:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/1sj9XZhBAWCZ6fOYYRRrsWNP2HDtzLLcaXa1ANYpWI=; b=Iilm3h2VJnc5kcnhfJ0mmQO1Rv7me4kRXzCfnAsmWCGv9tA+YzBJRRUxlReo7yus/h Npvw75hpLtJU7gp8EZjcQ02D/3l0Vcy1scY0D1lBabpfdG/Jo5O3SMuziTe6OwjcY9Bh A3Mm+hZPHUB1KymumpUNmgztU56hn88ksx/irsp9LUyfZq7iFoLoldsHfdCwnCOm5yyJ yZLJ9ZL0mUoK20UHt2FQGm+n+dJ3j9+FPiFhTvQWcLqOM9int/C1hFr5xAd6Z+GZzrD3 kgdDrI3tNRsdvM7/SK95Om60zaCzV5Q7y6KOFo+dvNazzPjMz1VwGtvt6pEZoYPWzeCn 43Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/1sj9XZhBAWCZ6fOYYRRrsWNP2HDtzLLcaXa1ANYpWI=; b=O21X/t3a8pWmvYzApXkHSTvYoUxFrPKCNadCSE8XkoEFxhCsZX/FBSEQRhasy38Emd QC8DOQbguiqpGCCVD5j/k0CV0vOOtfZcZXoJQVjMCInbOUbyNDZgwaBBhbEuvNSiIGt0 la61dfgiSIOcqTf/CxnSJNkAu13aMKWCYAAG8SyOyxL0l1TTtYc3J+EZz2WIrRT71P9g IJrGR2zVaQmU6W4tqOqvfv7/gzSWu2kEmOSVDacii3AnWI7rwNo8oL9do7in1BubQPZC sALaBbehLdMp1+kDIlHnWy/xyDk/rUbReWPbj2NPUWONwriJ7qw4Lr594U6vLrSteouE 8aPw== X-Gm-Message-State: AHPjjUhCx9h+3QSaggB18xdNCRfj/EpGA8mOw74SGz+K+NErK4H9zKli SHPO+qeaA0KD/UKE X-Google-Smtp-Source: ADKCNb4jmHiTBaYymW8jOXkB9rWR55D6j5jvb6XRX7BpVSeNyz9cjngp9gEqiSkaeMGL+wOaiTbd3g== X-Received: by 10.98.27.73 with SMTP id b70mr1481841pfb.240.1504556280881; Mon, 04 Sep 2017 13:18:00 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i187sm13037700pfe.67.2017.09.04.13.17.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 13:17:59 -0700 (PDT) To: David Farmer , Lorenzo Colitti Cc: "v6ops@ietf.org" References: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 5 Sep 2017 08:17:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 20:18:03 -0000 On 05/09/2017 06:23, David Farmer wrote: > On Sat, Sep 2, 2017 at 2:13 AM, Lorenzo Colitti wrote: > >> On Fri, Sep 1, 2017 at 8:23 AM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>>> Unicast RAs would require the router to keep state on all its clients >>>> regardless of its IP addresses and across IP address changes. That >>> doesn't >>>> scale. It's much better for the router to send a multicast RA on each >>>> separate L2 link, knowing that it will go only to the host on that link >>>> that has that prefix. >>> >>> Nevertheless, >>> (a) the draft says unicast. >>> (b) hypothetically there *is* no separate L2 link for multicast; there is >>> just a >>> logical separation for unicast purposes. That seems to be what Ole >>> described. >> >> >> Layer-2 unicast, yes. They are unicast to the host and have an IPv6 >> destination address of ff02::1. >> > > I to believe that is the intent, but that needs to be explicitly said in > the draft. I can't see into the authors' minds, so I don't know the intent. When I see the word 'unicast in the description of an IPv6 packet, I assume that its destination IPv6 address is a unicast addresses. If that isn't what they mean, it certainly needs to be stated in full detail. Sending a message with a multicast layer 3 destination to a unicast layer 2 destination on a multicast-capable link is unusual. > Further, the draft seems to only discuss the formation of RAs > that are sent in response to an RS, the draft should also > explicitly discuss the periodic RAs sent by the router. Even if that is as > simple as saying they should be formed the same, and using same unicast L2, > multicast L3 addressing, as the RAs sent in response to an RS. Indeed. Brian From nobody Mon Sep 4 13:22:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1652C13208E for ; Mon, 4 Sep 2017 13:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 COKmm81pAgJv for ; Mon, 4 Sep 2017 13:22:38 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD9E132076 for ; Mon, 4 Sep 2017 13:22:38 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id CAE3D2D5073; Mon, 4 Sep 2017 20:22:36 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D3E2610140236; Mon, 4 Sep 2017 22:22:36 +0200 (CEST) From: Ole Troan Message-Id: <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_4F423546-ED9E-4DCE-A218-E1884F13DD47"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 4 Sep 2017 22:22:35 +0200 In-Reply-To: Cc: David Farmer , Lorenzo Colitti , "v6ops@ietf.org" To: Brian E Carpenter References: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 20:22:40 -0000 --Apple-Mail=_4F423546-ED9E-4DCE-A218-E1884F13DD47 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > > Sending a > message with a multicast layer 3 destination to a unicast layer 2 > destination on a multicast-capable link is unusual. RFC6085. Ole --Apple-Mail=_4F423546-ED9E-4DCE-A218-E1884F13DD47 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZrbYMAAoJEL7aWKiYQt92hXwQAJM6QkL3AgDDlrEKDXDyr4kv AXXyZRluICIWyBLWbDBnfvwlaBx5qurMkiaDk5AV40bVlyHVfq8avQnBg7HXi4PM UcHCkaeVXyMCenmC6mkg3u1XWkPnMLnep4sE7xXaHLlKEC7OPubehAOciAPTq37p D9PPY5kNkQEsP6mG8/0jEQ/xTWIfOnJHy44WtjGbXTdkaZIaz0gbRnmw3eVWSIRY fOEA7fs57GpKhDCs3iI23YiR9bxL9wHOxSjGLIbmX6sF6JPRg4qqTUrIOuiEdWOz U8DAVj0epGK+wfuPL4gl5G3LahUrBG/DoaM3ISO6T9ol24YI1qL3D0WN7N1ufLr8 Fbx+p4o7vaCOXCXd5mI27vSdRDqmvAMAOK5QqDnrWUhy7IG60AcwCvjhMrWF77qx BGtAvKoBozyIFuMcnbhLt1MvnDPwASj2w1kPok4rl0WkGuGnloPZ8FUb6YAYxjbN sIbB+TtIyeM9F8k6an5JIhK4BJJXUgLv+6bEHmfkRxVZiP5NxSBm1rRIFwwGS9vE CC723QEXYvTXk2q/vChTqe3/TGmmkGASVzFJshR2gZSGwbjmbDdGyzJzQPnYBkg5 LOYuoHPV2zsaGsEuv7s5MMXRfJVJoVfO3uaQs3lpFdhPmZ3Rh3CSwsX33Pc0uTLw Bmb5cUfgHFIevWiQoRSs =j/Il -----END PGP SIGNATURE----- --Apple-Mail=_4F423546-ED9E-4DCE-A218-E1884F13DD47-- From nobody Mon Sep 4 13:28:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DEF128D0F for ; Mon, 4 Sep 2017 13:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.8 X-Spam-Level: X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 7OtzgAt1olhB for ; Mon, 4 Sep 2017 13:28:19 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5E5132076 for ; Mon, 4 Sep 2017 13:28:18 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 167C773A for ; Mon, 4 Sep 2017 20:28:18 +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 2aIhdK7s60yh for ; Mon, 4 Sep 2017 15:28:17 -0500 (CDT) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id B964A706 for ; Mon, 4 Sep 2017 15:28:17 -0500 (CDT) Received: by mail-ua0-f199.google.com with SMTP id i33so951499uae.4 for ; Mon, 04 Sep 2017 13:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vhFRnDWH4QxZGN/N/LVoG4sU65to8x/vqatZrRqUmbA=; b=Ao5dFYSbbvQRVOGWB9/deIOaj4XWvpkMsacmuKfVwol4Y78bAC5POEugQqUnBR05cg 0j9bulVXhTwjAeWnlQUCUDKG2gIzqlPobvBjvfYyFr4e4XuNg7Jg8XYU+1sLBiTwWJs7 lGH8qpBXoH5V1QMlP7bBiP5VN4ENTG6lHkbcUAOp0i45PVjQGFtG/iSGBUc6hYH1no0p R8RRrlPj4iHacM0V+9P/PymBvdcFWM/ZIV/3NhybTs4qf0AURospQKet34LDboLFu32g Uw9M0kBwVyFIIghqd7U4v79+tSHAZcG4v7VdQk0Yk9PBm1Z6mPs+PQzjMi4h/pskIjAR L1Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vhFRnDWH4QxZGN/N/LVoG4sU65to8x/vqatZrRqUmbA=; b=IhkWenHIe4DI70aVf/6p8jfapm/F72qyT50C+xvjLqQ65k1IelMo3gDVwB1iV3dct5 1qFybePzXyFj4ZfRuF/C/Y8skLvUWXx+WWUxlSK97RmrJ7gmZwpYzrlrdvOi/2GRmQdk GWpPCtO/Or2up3+W+MY4WvW+P1YNJNP0vuxY2x1B+jMQZECp+I2ezY/yw69oi3y5pPuA R0JkAjS07v2EDi+aEcg1vCC5SBVBDgys/cEnzBcTCVaJ5k8Y1u7wqkQcWmOVtd/eCEtd j9wP6TCZ8xEkucWE/khAgswgJf5+DUwfFxe2bNFT8r5zYQ3bLNVQfCiL8Hcf34n7Nxna NvEw== X-Gm-Message-State: AHPjjUirZs9sCorQFPKkIrtqfSMz2/wp3bU73AwdLthUF+ev5FKah1tr wVTjYcElwt3OjkekXfFKXfoVynwRX4XP9dPrPOsbtD+Z1SVSz9jTFBFFlMDzUAI/6uitWP9PHs1 V6hR3uMKMt8MhFeMC X-Received: by 10.176.86.18 with SMTP id y18mr1153733uaa.1.1504556896438; Mon, 04 Sep 2017 13:28:16 -0700 (PDT) X-Google-Smtp-Source: ADKCNb5Bt6RMRLmX4zSH3YEmMP343bSmKFlYqndM8rbM0/qXdYZsIyE1i6++lrQeGK5aqTpG2K+PrQWGb6Q9nRLWnlw= X-Received: by 10.176.86.18 with SMTP id y18mr1153720uaa.1.1504556896158; Mon, 04 Sep 2017 13:28:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.89.81 with HTTP; Mon, 4 Sep 2017 13:28:14 -0700 (PDT) In-Reply-To: References: <36cf4673289247bba28bbd921cf9ebf8@XCH15-06-08.nw.nos.boeing.com> <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Mon, 4 Sep 2017 15:28:14 -0500 Message-ID: To: Fred Baker Cc: V6 Ops List Content-Type: multipart/alternative; boundary="f403045df12a572057055862f323" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 20:28:21 -0000 --f403045df12a572057055862f323 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 4, 2017 at 1:38 PM, Fred Baker wrote: > Thought for today... > > Warren, Ron, Lee, and I are wondering how much of all this relates to the > draft mentioned in the subject line. I saw a note from, I think, Lorenzo > the other day asking that the applicability comment that communication > between such nodes on a LAN should go through a connecting router (which > seems to me a given due to the relationship with routing) should be > documented. > > Is there anything else here that comments specifically on this draft and > should be considered in IESG review? If so, please respond and highlight it. > > On other matters, by all means please discuss. You might consider changing > the thread, though. > > Sent using a machine that autocorrects in interesting ways... > > > On Aug 31, 2017, at 9:49 AM, David Farmer wrote: > > > > You are talking about redirects as if they are a universal good, and yes > > they are necessary in some situations, but they also have security > > considerations. You claim the draft is ignoring the potential usefulness > of > > redirects in some environments and yes it is. However, you are ignoring > > the potential additional security that not having redirects has in other > > environments. > > > > Further, you have not discussed any advantages that the use of prefix per > > host subnets model has over the classic multiple hosts per subnet model > in > > an insecure environment to justify the increased use of number resources > by > > prefix per host subnets model. Please explain some of the use cases you > > think their are and why the prefix per host subnets model with redirects > > has any kind of advantage over the classic multiple hosts per subnet > model. > > > > Thanks. > > > > On Thu, Aug 31, 2017 at 10:18 AM, Templin, Fred L < > Fred.L.Templin@boeing.com > >> wrote: > > > >> Hi, > >> > >> > >> > >> The simple point in all of this is that Redirects are (and will remain) > a > >> > >> useful component of IPv6 ND, yet this document seems to deprecate > >> > >> their use in all cases even for links where use of Redirects is > essential > Adding to Lorenzo's request; Security, in the form of UE/subscriber isolation, is not mentioned in the abstract or introduction of draft-ietf-v6ops-unique-ipv6-prefix-per-host-07. If UE/subscriber isolation is truly a fundamental aspect of this solution, which I and I think several others in the WG think it is, then it should probably be at least mentioned in the abstract or the introduction. I think it should also be noted, maybe in a paragraph at the end of section 2. If it were practical, for security reasons it would be justified, to deploy individual physical or logical links on a per UE/subscriber basis (such as completely separate VLANs per UE/subscriber). Further, the proposed deployment model will not use more IPv6 subnet prefixes than if for security reasons each UE/subscriber were deployed on it's own individual physical or logical link. However, in most cases this deployment model, using L2 isolation between UE/subscribers on a shared network, will be more practical to deploy than separate individual physical or logical links on a per UE/subscriber basis. Further, the security considerations section should discuss the consequences of not providing L2 isolation between UE/subscribers on the shared network. That is primarily, that a malicious UE/subscriber could impersonate the provider first hop router, or otherwise communicate directly with UE/subscribers without first having traffic go through the provider first hop router, therefore bypassing any inter-UE/subscriber security policies that might have been applied by the provider. Finally, it might be worth nothing some place in the draft that redirects SHOULD be disabled on the provider first hop router facing the share network, as direct inter-UE/subscriber communications is not intended to be possible across the shared network. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f403045df12a572057055862f323 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 4, 2017 at 1:38 PM, Fred Baker <fredbaker.ietf@gmai= l.com> wrote:
Thought for today...

Warren, Ron, Lee, and I are wondering how much of all this relates to the d= raft mentioned in the subject line. I saw a note from, I think, Lorenzo the= other day asking that the applicability comment that communication between= such nodes on a LAN should go through a connecting router (which seems to = me a given due to the relationship with routing) should be documented.

Is there anything else here that comments specifically on this draft and sh= ould be considered in IESG review? If so, please respond and highlight it.<= br>
On other matters, by all means please discuss. You might consider changing = the thread, though.

Sent using a machine that autocorrects in interesting ways...

> On Aug 31, 2017, at 9:49 AM, David Farmer <farmer@umn.edu> wrote:
>
> You are talking about redirects as if they are a universal good, and y= es
> they are necessary in some situations, but they also have security
> considerations. You claim the draft is ignoring the potential usefulne= ss of
> redirects in some environments and yes it is.=C2=A0 However, you are i= gnoring
> the potential additional security that not having redirects has in oth= er
> environments.
>
> Further, you have not discussed any advantages that the use of prefix = per
> host subnets model has over the classic multiple hosts per subnet mode= l in
> an insecure environment to justify the increased use of number resourc= es by
> prefix per host subnets model. Please explain some of the use cases yo= u
> think their are and why the prefix per host subnets model with redirec= ts
> has any kind of advantage over the classic multiple hosts per subnet m= odel.
>
> Thanks.
>
> On Thu, Aug 31, 2017 at 10:18 AM, Templin, Fred L <Fred.L.Templin@boeing.com
>> wrote:
>
>> Hi,
>>
>>
>>
>> The simple point in all of this is that Redirects are (and will re= main) a
>>
>> useful component of IPv6 ND, yet this document seems to deprecate<= br> >>
>> their use in all cases even for links where use of Redirects is es= sential



I think it should also be noted, maybe in a paragraph at the end of= section 2. If it were practical, for security reasons it would be justifie= d, to deploy individual physical or logical links on a per UE/subscriber ba= sis (such as completely separate VLANs per UE/subscriber). Further, the pro= posed deployment model will not use more IPv6 subnet prefixes than if for s= ecurity reasons each UE/subscriber were deployed on it's own individual= physical or logical link. However, in most cases this deployment model, us= ing L2 isolation between UE/subscribers on a shared network, will be more p= ractical to deploy than separate individual physical or logical links on a = per UE/subscriber basis.

Further, the security con= siderations section should discuss the consequences of not providing L2 iso= lation between UE/subscribers on the shared network. That is primarily, tha= t a malicious UE/subscriber could impersonate the provider first hop router= , or otherwise communicate directly with UE/subscribers without first havin= g traffic go through the provider first hop router, therefore bypassing any= inter-UE/subscriber security policies that might have been applied by the = provider.=C2=A0

Finally, it might be worth nothing= some place in the draft that redirects SHOULD be disabled on the provider = first hop router facing the share network, as direct inter-UE/subscriber co= mmunications is not intended to be possible across the shared network.

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & = Telecommunication Services
Office of Information Technology
Universit= y of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cel= l: 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
--f403045df12a572057055862f323-- From nobody Mon Sep 4 13:33:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D99128D0F for ; Mon, 4 Sep 2017 13:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Voc1Q4soOJo6 for ; Mon, 4 Sep 2017 13:33:43 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B41512422F for ; Mon, 4 Sep 2017 13:33:43 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id m1so2986851pfk.1 for ; Mon, 04 Sep 2017 13:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uCxSQj1DekvuXZmI+iZpunkzLZ4toqvWmG2IzzGd+7M=; b=Eoeb5bxkce4TRfI0Fho9e8nUgdE/AmhlD4CeuGMIebH8WeFOV1M+an6+woe5i13TWn rHRfZfBA1bGkVM+xxWYgQcMVOj3MIMzyOTTeSzuVEJDD7GS+osHpW9IP7kEYXhYsikCM mjViP7IAj5Nn/Uaf1vaM7wZILmtoEZNhx+hYkVOqbeFR02g2XunefkTmUb9YNCa9D9Fp FZ1z4murfwFQdKZ6TYXIFPD1XEBvvxfkJ5ZnHZUfIgMDQJjR/16q8iboUVpuTDCcficU /uCC+dpsCI1vrzLYOfQ7vr8brdsRBobRrrnxuTCDRBrVA8HJ5rYnLbS/qd2+vjPSnq0m LT8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=uCxSQj1DekvuXZmI+iZpunkzLZ4toqvWmG2IzzGd+7M=; b=cKDrS88XSxzHAYqhmHXwYgRA1kdEWuaoRq2yUY93czDsnBrORa3N42MZxKJkMTTHq0 Vd/wMue2GIOl+E7BUomSuMv1ZgCkhogXMXG0rKPQ2j+YbpQHsftRJWlXgq21M3LbPuCD 1qtWTVTJTaAdYc/ymmbi00lrkAExW4jVcyFgSB82srrTJj+d0JyQQJlVObV5+7xlfL+s d8UfgX17u/L3qFmuKxqT1PxJBv+AmKPinelWxCDBOqbsztUzasRxVzlgF7BI1/LXeY5E Bw9z3JnGqgIQt+HKTPw4dyGlRVpYqHNCFS1ErbXoDGvEmMgvXKnA0GJbYNR1zdYhzhUi BJ8A== X-Gm-Message-State: AHPjjUh2env4hdNEaMBKkiaj5/mT/xzRneoe2cPDROv9gmG5otd/ntNy sxbZ8evn07honPlg X-Google-Smtp-Source: ADKCNb6wBs2VTpo+rkfxLo90d+zTWH8sRMKz1m29rYnAWUbooO0VHpw/su9M/EFrJNRPzy3hRbL0wQ== X-Received: by 10.99.119.5 with SMTP id s5mr1716310pgc.344.1504557222372; Mon, 04 Sep 2017 13:33:42 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u29sm11784467pfa.72.2017.09.04.13.33.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 13:33:41 -0700 (PDT) To: Ole Troan Cc: David Farmer , Lorenzo Colitti , "v6ops@ietf.org" References: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> Date: Tue, 5 Sep 2017 08:33:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 20:33:45 -0000 On 05/09/2017 08:22, Ole Troan wrote: >> >> Sending a >> message with a multicast layer 3 destination to a unicast layer 2 >> destination on a multicast-capable link is unusual. > > RFC6085. Which sort of confirms that it's unusual ;-). This would be a good reference for the draft, if that is indeed what is intended. BTW, RFC6085 is explicitly about Ethernet. Is there any reason that it doesn't apply to any broadcast link-layer? Thanks Brian From nobody Mon Sep 4 13:56:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF8B120721 for ; Mon, 4 Sep 2017 13:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NtBvftKL9dep for ; Mon, 4 Sep 2017 13:56:15 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE2A12426E for ; Mon, 4 Sep 2017 13:56:14 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 342ED2D4FEA; Mon, 4 Sep 2017 20:56:14 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 566EE10148A57; Mon, 4 Sep 2017 22:56:14 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7090C576-2DDA-472C-90E8-03E826A6D813"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 4 Sep 2017 22:56:13 +0200 In-Reply-To: <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> Cc: David Farmer , Lorenzo Colitti , "v6ops@ietf.org" To: Brian E Carpenter References: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 20:56:17 -0000 --Apple-Mail=_7090C576-2DDA-472C-90E8-03E826A6D813 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii >>> >>> Sending a >>> message with a multicast layer 3 destination to a unicast layer 2 >>> destination on a multicast-capable link is unusual. >> >> RFC6085. > > Which sort of confirms that it's unusual ;-). This would be a good > reference for the draft, if that is indeed what is intended. > > BTW, RFC6085 is explicitly about Ethernet. Is there any reason that > it doesn't apply to any broadcast link-layer? Which link-layer are you thinking of? Ole --Apple-Mail=_7090C576-2DDA-472C-90E8-03E826A6D813 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZrb3uAAoJEL7aWKiYQt92gR4P/RNvmaDFBkLGc4/yZg+Yrewe TBBwjHDRTpdlInXVngtyGz3xj5VLCXPxERbKhxeCIKVuesACTPCdXRxlXJAZ/7Ij 9/8QiJNsFtE5zYOufksRb8Oyfc9ppQyLRmEoZ1Gd080IkA5UY4dXakYWEvwwY79j o2d59bsQ6VEyBw6mkXzpelJKQwT/z3q1U8UcsqvF11AiJFINmefTMvhj/8U9aGXV y8+YvZwOfcn+wuW+YLst5bvW/MFeh+tCCWoBbUTKvUgnGi70ijWi3CJgi3Myr14L F0ZQoMqHQYsxdXk3r8kzGYUzttqfIOy6KGdmkoU0XkWEQ10azgkX/K+uYiLHk5Gj xMEMR/meQe3ZQPeh6TM49KolysixOv3j3g2GX9H7p8Wt0d05EQ+9YRV6OAN0baqc zCritSPkO3FgdH6ePnsoIZ7GZbg4FlhZzfyMy/1Lin/ti4fJ0oh53GYgmW0atToM h6ngzui6GGLF6wO9qoj2qpZIkvE78URTV/+V3qjKnI0CfPwEKQknkE9f3cjNJLvN 1UkVTDfVvy6WnmRQYjwL2o81MGIeRfIzN4ssl1PFGbboVSDv9m/c+EkpPv9JOZM9 gCsl9jzEPq0UJLMsPIsh2fTjtSiLkR88LN/cyivU6HQgD+WyQEPn/lneRMXdBdLL CQpgoQyhKlYR3uDerqz5 =tTke -----END PGP SIGNATURE----- --Apple-Mail=_7090C576-2DDA-472C-90E8-03E826A6D813-- From nobody Mon Sep 4 14:44:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEE9132193 for ; Mon, 4 Sep 2017 14:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW6j87Zr3oNZ for ; Mon, 4 Sep 2017 14:43:58 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F58A132192 for ; Mon, 4 Sep 2017 14:43:55 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id y15so4482615wrc.2 for ; Mon, 04 Sep 2017 14:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LvbSG0d0FffHhtWU/sch5VZZMqRKeHb48d2L276S/ds=; b=pgm8AsNcqZY6DT3eB8xzq2XYhg2yqoja7I+a1JhV+rjf8JOf0vSTwsD3H+oaMSID5K /ONGLuwyurHoeW1xoSnzi2soMog/Q/UGGHBiEwkHJYgaeFQf2Ypzi/I/sLaj3hyLR9xZ q+4UWn1vGWIjcyPqWQ9G0EX4XJ3cZ8JXFXCddF+7dfZOT67RwyCSaCOXEeGXgZ8y173n yQQhR5YFTBocVw3KK/1QO/N0KkNMlCkhCPMzL7vOHFyqcgeKgY8mymlqFWuoumEOS4+P yB3Dcy2PIkb7+zsLnRnWAbojbRI59mDvwRBEYoej/r3gnvRS980+dSlikl3Ls4q7f7V7 43aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LvbSG0d0FffHhtWU/sch5VZZMqRKeHb48d2L276S/ds=; b=qcIF+4c854CIK1UttUObR/Hoizcy8d1uw0XSWZIinYSWBcqHE8QGtIGBIqkeEN6tUh zhVd8q1RA344lb0b8293tv1wd9FsKB3VfY3CaQB7SXPdEtQOZnuepp1BSRqtAR1fYaLW 5pu95BMo3ymkNyMdJcSCo2OoWsJPbZmYMJU0+SfCEQrE7zQO0AzpWKdNzTJddgdTAlk6 q3d2XWTzqY89CmG0U5tLW47CnHGM3fJLNLMxLscbHsQYRE/apMIIAG24+VEkm2A49zX5 9h0n5DPBMFzZ80832grBcQCxz0gBQgkd3zwXg2AElv6sMfNM8Jkc7HyPZliAp1aIYmp4 0DiA== X-Gm-Message-State: AHPjjUhDAdlDFUYUeAtBOXRTi57S/ei4wau6tvne3Tod5GmhoH9IQCUE 1JI37+JbFOj7+x6lEr0XKnJD/4uK9NPy X-Google-Smtp-Source: ADKCNb5i9f7/i4R7jLyUIWdvGCkmaeeQq35ScyvXwpHVH7JnlbzPXEoQmjqUmCQvNOcOdlp0CIAbm/ESTg6WSYEjDJ8= X-Received: by 10.223.133.99 with SMTP id 90mr967106wrh.63.1504561433502; Mon, 04 Sep 2017 14:43:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Mon, 4 Sep 2017 14:43:12 -0700 (PDT) In-Reply-To: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Mon, 4 Sep 2017 17:43:12 -0400 Message-ID: To: Suresh Krishnan Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , The IESG , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , Ron Bonica , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 21:44:00 -0000 I'd like to note that that there is continuing discussion on this draft on the v6 ops list (yup, after WGLC and IETF LC :-)). I've only been able to somewhat monitor it, but have asked the v6ops chairs for input. Much of the discussion has been interesting, but not necessarily pertaining exactly to this document. Fred kindly asked the list: https://mailarchive.ietf.org/arch/msg/v6ops/bpEDtnYkbvJQZAx_r6mtEhdNxrw for anything substantive for the document (keeping in mind that it has already gone through WGLC and IETF LC). So far it doesn't seem like there are any other major changes needed, other than "asking that the applicability comment that communication between such nodes on a LAN should go through a connecting router (which seems to me a given due to the relationship with routing) should be documented." and David Farmer's followup -- https://mailarchive.ietf.org/arch/msg/v6ops/_-QlBqGk9dChoFOhxigf5WlxYDY Does anyone have anything else *substantive*? If so, I may have to kick this back to the WG for another round. W On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan wrote: > Hi Gunter, > Thanks for the proposed text changes. They adequately address my DISCUSS > points. I am hoping you will also converge in the discussion with Lorenzo on > the actual value for the timer and/or specify an applicability statement. I > will clear once the new revision posts. > > Regards > Suresh > > On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) > wrote: > > Hi Suresh, > > Many thanks for the review and finding these issues. What do you think of > the proposals below to fix those points of attention? > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > * Section 4 > > It is not clear what you intend here > > "IPv6 Router Advertisement Interval = 300s" > > The router advertisement interval is not configured as an absolute value > but as > minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval) > which are > used to calculate the actual advertisement interval. When the RA is sent > from > an interface, the actual interval is an uniformly distributed random > value > between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum > you > need to clarify if you would like to have this as a lower bound or as an > upper > bound. > > GV> I changed the line to make it more clear that the timer indicates the > maximum Advertisement Interval > GV> Maximum IPv6 Router Advertisement Interval = 300s > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > * Section 4 > > -> I think text is needed here to handle the case where the DNS server is > provided in the RA itself (RFC8106) > > "In addition it will use stateless DHCPv6 to get the IPv6 address of the > DNS > server" > > -> I am not sure what is the motivation for this text. > > "however it SHOULD NOT use stateful DHCPv6 to receive a service provider > managed IPv6 address" > > -> This text seems incorrect > > "due to the L-bit set, it SHOULD send this traffic to the First Hop > Provider > Router" > > I think it should be the exact opposite. i.e. say *unset* instead of set > > "due to the L-bit being unset, it SHOULD send this traffic to the First > Hop > Provider Router" > > GV> What about the following modification in the text: > > OLD: > The architected result of designing the RA as documented above is > that each UE/subscriber gets its own unique IPv6 prefix for which it > can use SLAAC or any other method to select its /128 unique address. > In addition it will use stateless DHCPv6 to get the IPv6 address of > the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive > a service provider managed IPv6 address. If the UE/subscriber > desires to send anything external including other UE/subscriber > devices (assuming device to device communications is enabled and > supported), then, due to the L-bit set, it SHOULD send this traffic > to the First Hop Provider Router. > > New: > The architected result of designing the RA as documented above is > that each UE/subscriber gets its own unique IPv6 prefix for which it > can use SLAAC or any other method to select its /128 unique address. > Either stateless DHCPv6 RFC3736 or IPv6 > Router Advertisement Options for DNS Configuration > RFC8106 can be used to get the > IPv6 address of the DNS server. If the UE/subscriber desires to send > anything external including other UE/subscriber devices (assuming device > to device communications is enabled and supported), then, due to the > L-bit being unset, it SHOULD send this traffic to the First Hop Provider > Router. > > > > Kind Regards, > G/ > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Sep 4 15:21:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F9213219A for ; Mon, 4 Sep 2017 15:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwXevjFSHm0Q for ; Mon, 4 Sep 2017 15:21:42 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6488132193 for ; Mon, 4 Sep 2017 15:21:41 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id c27so4299398uah.2 for ; Mon, 04 Sep 2017 15:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z7I4y4Ik96DrNSyJGG5inmvSJydcQIozf1KNK0CDrJI=; b=FS5RB2tYyGp0qHDBGwDt74ZHondIxcYLnvv2e1Xuh3cyWM1Xc/DuBjWwUMHnShlE2s 4mouiJROww/PdKwxfi3nVGfOmFZcGGCk/FPJ1dAkdAv4jKCLiwNcp+iFSC8Gifvv7MXW J4kumXIkdMMcsdXFN72Cgxd5+4FkIkKW8yJ+syvXnV5b6wELC7684sqLf+DnLFuJLzAv CvXEF6kavUprzq6qqr8XRpmFIO6+FBL1npg0TtK1RG0sTrpccmIrrT7rIq2QfjyS4RKQ S8mF+w2FwsCC2HSkAmAv6PM32zMnJ0ss/BQSN7PIjjv2wQxLJd6ocV20Eyez8i9LKeVG 5zWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z7I4y4Ik96DrNSyJGG5inmvSJydcQIozf1KNK0CDrJI=; b=gBuaFe/cOqpzrjFBmDDb2GkKZzwUy0JAKQMTFFP649JuntZ/NPdJE0X4J+su6isudU DdEChafK4kGi6hWjhI2vypRPYBJ5hWqoi10pIXfdOB4b7KCn/R2FrUdYe2b8vgwLfomm /QkUzw5dMXC5jiT4Lvhpnk9p7WSMnjyw6AeMUF8pmdaWr8xUoBrVVed7us00rSlpTcXA 5Q6M7nsDCnZ0Dp8/dYNwbv2RrPWllfMDyt0J05/hTbVghhrm1rPgzRpihTSKuhczZJAd ldvw/0/dkJL1iqShPCpuU9N5IJWUKPwFdW8CsTcnHf4dt8dD38Me4+NHKub21Q56ho+J xD5w== X-Gm-Message-State: AHPjjUiaOgAfzYIPbJuzjZTtHobYgdAgqIf92ApajAolSPrBcOkaZN5d iZ9RbSyP84FcB4d5qM71RVphqwVXuw== X-Google-Smtp-Source: ADKCNb5Wl8Fpm8mOSQVwKA0dlphpMa1T5uzmCWt32xEVK2i2nGWcmZBaU1/4FAc+n6HP+VYzcQcfUWOHAkHyLv3VF5Y= X-Received: by 10.176.91.87 with SMTP id v23mr1199475uae.13.1504563700845; Mon, 04 Sep 2017 15:21:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Mon, 4 Sep 2017 15:21:39 -0700 (PDT) Received: by 10.176.27.19 with HTTP; Mon, 4 Sep 2017 15:21:39 -0700 (PDT) In-Reply-To: <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> References: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> From: Mark Smith Date: Tue, 5 Sep 2017 08:21:39 +1000 Message-ID: To: Brian E Carpenter Cc: v6ops list , Ole Troan Content-Type: multipart/alternative; boundary="f403045f9008ee510b0558648869" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 22:21:43 -0000 --f403045f9008ee510b0558648869 Content-Type: text/plain; charset="UTF-8" On 5 Sep. 2017 06:33, "Brian E Carpenter" wrote: On 05/09/2017 08:22, Ole Troan wrote: >> >> Sending a >> message with a multicast layer 3 destination to a unicast layer 2 >> destination on a multicast-capable link is unusual. > > RFC6085. Which sort of confirms that it's unusual ;-). This would be a good reference for the draft, if that is indeed what is intended. BTW, RFC6085 is explicitly about Ethernet. Is there any reason that it doesn't apply to any broadcast link-layer? While RFC6085 is useful to have in our toolbox,I think it would be better to IPv6 layer unicast RAs. That encodes the intent of which set of devices are intended to receive the RA in the DA in this scenario (i.e. a set of one). If the draft is discussing a Wifi service provider scenario, which I think is likely, then RAs should probably also be unicast to save batter power of client devices per BCP202. Regards, Mark. Thanks Brian _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --f403045f9008ee510b0558648869 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 5 Sep. 2017 06:33, "Brian E Carpenter" <<= a href=3D"mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com> wrote:
On 05/09/2017 08:22, Ole Troan wrote:
>>
>> Sending a
>> message with a multicast layer 3 destination to a unicast layer 2<= br> >> destination on a multicast-capable link is unusual.
>
> RFC6085.

Which sort of confirms that it's unusual ;-). This would be a goo= d
reference for the draft, if that is indeed what is intended.

BTW, RFC6085 is explicitly about Ethernet. Is there any reason that
it doesn't apply to any broadcast link-layer?


While RFC6085 is useful to have in our toolbox,I think it would be better= to IPv6 layer unicast RAs. That encodes the intent of which set of devices= are intended to receive the RA in the DA in this scenario (i.e. a set of o= ne).

If the draft is dis= cussing a Wifi service provider scenario, which I think is likely, then RAs= should probably also be unicast to save batter power of client devices per= BCP202.

Regards,
<= div dir=3D"auto">Mark.

<= br>

Thanks
=C2=A0 =C2=A0Brian


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

--f403045f9008ee510b0558648869-- From nobody Mon Sep 4 15:33:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF2813219A; Mon, 4 Sep 2017 15:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEDlTH4SHj-D; Mon, 4 Sep 2017 15:33:04 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD88132192; Mon, 4 Sep 2017 15:33:04 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id 188so1056859pgb.2; Mon, 04 Sep 2017 15:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=14pG0V7YSNBPdbBh62qv1reeaB7LIip8RhpBDaE1KPQ=; b=KpYJRL2un+Hz3iX/JA0U1j44/M5ClPINFkFwV6EJJIhKxKeCxrOwET/wyNY739eQFy zee+s3TbtPf0YgwgcSzkLS4z8COz+MPrS995Sl5FUpFLvetZXSimLJNTvLisDkytSPJ6 QL91Ked0XYs+UHR4Ry7b9gImyJVT1OoLiVmXTIEp0rJwelyLCYeobyGIj20Pv/Q/DSWe U517FwQZbtGH0MHesPsF6Oj3GoiVk4JwmDs++67BKc2vGAxnaMcAX3i/G+KiK8uSoofe rwxSpdfx5nMe+k7jmdmdkzKEJpX0Z7Gy3rVt3DkXiE2F4W3FX3CmxrsefJ+n7iTbCE8X puhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=14pG0V7YSNBPdbBh62qv1reeaB7LIip8RhpBDaE1KPQ=; b=a4M+QvI1mINXQhXj92+uN7gRoUppwMAXWvTNocaDFQHG4jZR0owyd3BPaLgbM6JKRH IBytQEhjDhGYBPYhwEL9xVE5/XA4mRZSyauB5txHdn/NrixOKuMuDP3SjTupiXENNlEw 0bh1AOR4P5V0gN7DIArpRosvWk6zFOub3RjW1dieSoPOtiL1FePEyh0YEkHTXLbzcoNT ZgwiauZ9Du3hJVpjWviZOTWKk3TBW+gT5cVjS0d8mJNKWiZL6PbweielUAqJ2JWGoZFk w7Mul0uSA4KCIBStOUQxhGNhyLx1P/sI72mPdf6UbgdoJl1/6qKLK9u1RscbaBg+5LiO li4g== X-Gm-Message-State: AHPjjUhs0Nx9hVdBOoaKxegzZ/yOLqhgY+k8P72RJVKyrwKvoi0Xo+d9 Z+bU2ijGlnOkxqkl X-Google-Smtp-Source: ADKCNb5HvC3wINcPczvW5ixnIjP4Ts4EA+XDIVDea6xAK18rI+NkPs6BXqIOKPP9tLQ9iDtfo9TG3g== X-Received: by 10.99.120.3 with SMTP id t3mr1899486pgc.388.1504564383300; Mon, 04 Sep 2017 15:33:03 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id e4sm12451389pfc.38.2017.09.04.15.32.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 15:33:02 -0700 (PDT) To: Warren Kumari , Suresh Krishnan Cc: "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , The IESG References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 5 Sep 2017 10:32:59 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 22:33:06 -0000 Warren, I believe it's substantive that the text refers to sending unicast RAs without clarifying whether this means that they are sent with a unicast layer 2 address and a multicast layer 3 address (as per RFC6085) or that they are sent with both layer 2 and layer 3 addresses being unicast. At the moment, an implementer has to decide which of these is intended. If either is OK, that could be stated too. Specifically this clarification seems to be needed right after: > 4. IPv6 Unique Prefix Assignment > > When a UE connects to the shared provider managed network and is > attached, it will initiate IP configuration phase. During this phase > the UE will, from an IPv6 perspective, attempt to learn the default > IPv6 gateway, the IPv6 prefix information, the DNS information > RFC8106 [RFC8106], and the remaining information required to > establish globally routable IPv6 connectivity. For that purpose, the > the UE/subscriber sends a RS (Router Solicitation) message. > > The First Hop Router receives this UE/subscriber RS message and > starts the process to compose the response to the UE/subscriber > originated RS message. The First Hop Provider Router will answer > using a unicast RA (Router Advertisement) to the UE/subscriber. Regards Brian Carpenter On 05/09/2017 09:43, Warren Kumari wrote: > I'd like to note that that there is continuing discussion on this > draft on the v6 ops list (yup, after WGLC and IETF LC :-)). I've only > been able to somewhat monitor it, but have asked the v6ops chairs for > input. Much of the discussion has been interesting, but not > necessarily pertaining exactly to this document. > Fred kindly asked the list: > https://mailarchive.ietf.org/arch/msg/v6ops/bpEDtnYkbvJQZAx_r6mtEhdNxrw > for anything substantive for the document (keeping in mind that it has > already gone through WGLC and IETF LC). > > So far it doesn't seem like there are any other major changes needed, > other than "asking that the applicability comment that communication > between such nodes on a LAN should go through a connecting router > (which seems to me a given due to the relationship with routing) > should be documented." and David Farmer's followup -- > https://mailarchive.ietf.org/arch/msg/v6ops/_-QlBqGk9dChoFOhxigf5WlxYDY > > Does anyone have anything else *substantive*? If so, I may have to > kick this back to the WG for another round. > > W > > > > > On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan > wrote: >> Hi Gunter, >> Thanks for the proposed text changes. They adequately address my DISCUSS >> points. I am hoping you will also converge in the discussion with Lorenzo on >> the actual value for the timer and/or specify an applicability statement. I >> will clear once the new revision posts. >> >> Regards >> Suresh >> >> On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) >> wrote: >> >> Hi Suresh, >> >> Many thanks for the review and finding these issues. What do you think of >> the proposals below to fix those points of attention? >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> * Section 4 >> >> It is not clear what you intend here >> >> "IPv6 Router Advertisement Interval = 300s" >> >> The router advertisement interval is not configured as an absolute value >> but as >> minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval) >> which are >> used to calculate the actual advertisement interval. When the RA is sent >> from >> an interface, the actual interval is an uniformly distributed random >> value >> between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum >> you >> need to clarify if you would like to have this as a lower bound or as an >> upper >> bound. >> >> GV> I changed the line to make it more clear that the timer indicates the >> maximum Advertisement Interval >> GV> Maximum IPv6 Router Advertisement Interval = 300s >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> * Section 4 >> >> -> I think text is needed here to handle the case where the DNS server is >> provided in the RA itself (RFC8106) >> >> "In addition it will use stateless DHCPv6 to get the IPv6 address of the >> DNS >> server" >> >> -> I am not sure what is the motivation for this text. >> >> "however it SHOULD NOT use stateful DHCPv6 to receive a service provider >> managed IPv6 address" >> >> -> This text seems incorrect >> >> "due to the L-bit set, it SHOULD send this traffic to the First Hop >> Provider >> Router" >> >> I think it should be the exact opposite. i.e. say *unset* instead of set >> >> "due to the L-bit being unset, it SHOULD send this traffic to the First >> Hop >> Provider Router" >> >> GV> What about the following modification in the text: >> >> OLD: >> The architected result of designing the RA as documented above is >> that each UE/subscriber gets its own unique IPv6 prefix for which it >> can use SLAAC or any other method to select its /128 unique address. >> In addition it will use stateless DHCPv6 to get the IPv6 address of >> the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive >> a service provider managed IPv6 address. If the UE/subscriber >> desires to send anything external including other UE/subscriber >> devices (assuming device to device communications is enabled and >> supported), then, due to the L-bit set, it SHOULD send this traffic >> to the First Hop Provider Router. >> >> New: >> The architected result of designing the RA as documented above is >> that each UE/subscriber gets its own unique IPv6 prefix for which it >> can use SLAAC or any other method to select its /128 unique address. >> Either stateless DHCPv6 RFC3736 or IPv6 >> Router Advertisement Options for DNS Configuration >> RFC8106 can be used to get the >> IPv6 address of the DNS server. If the UE/subscriber desires to send >> anything external including other UE/subscriber devices (assuming device >> to device communications is enabled and supported), then, due to the >> L-bit being unset, it SHOULD send this traffic to the First Hop Provider >> Router. >> >> >> >> Kind Regards, >> G/ >> >> > > > From nobody Mon Sep 4 15:37:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA00132193 for ; Mon, 4 Sep 2017 15:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro0kNl6xcNsY for ; Mon, 4 Sep 2017 15:37:31 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D33132192 for ; Mon, 4 Sep 2017 15:37:31 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id m1so3430671pfk.1 for ; Mon, 04 Sep 2017 15:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sHjlWxxiX1HX+moGx/4ZoxXgnB0U4taO8C5g6BsC4s0=; b=j4xt3yqrMtv2gXVsyxl7k2veYiX+uItybBZSj2MrVf8S55+mD9n7902KBfeujne8Mg F5NpVOLDApodZkqCZTSDB6QGYpbVn3/gP4FGCJS8Wnhu9ajwsi57XSpay0WlQmZBNemT gCDa+AvJN7A/6yjXG6r5PrLCaUzTn+bGUAebN2KfOZx2i/nzv319s7Yqap7qvsYYL8f4 X/ykIodFAWg3a6dOn4j8K/jF3N2H+AHmues45qMR6Li5p+tjeVRrR32ADlTXso5xtnOX ba7kspu111lu3gM3U0vJAPqhESygzXXYnQNeHoQa3v8q6QahWt2RjKOYhRzvyAHIRUSe y1AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=sHjlWxxiX1HX+moGx/4ZoxXgnB0U4taO8C5g6BsC4s0=; b=cqDL66jAuaHrq0ZT4v10pl0Xm5Fqt/cQx4GZrQ3NCKXeIcGiQVodv9eUH9R7CSvJjc zMb2FS8MKTaBvBkF/hFj3Wr9TTi8uDyx9DYDStBxAC61UijIrF5I2tK7Dieb8XYFa8bb n0SR/ho6gjArwr6wZq/74O7ihliT0P+oKrV7hi11+HNzGmGfvK/vxsufaw9FrWg/erWY kv9/BaO5z5DkJkN9/hJd8y2fTeawqpFt/EjiAU/8D29dvf0l5qGp2el39+wbVciCfwn5 yrmp5dW+kGFImxmE8AafcASoJkd/FjLdKahwpkphSMo/VIUtyP93nCZ0+bI5t02p6gRU HUIA== X-Gm-Message-State: AHPjjUhb6AG5WxzUUqwvXXCo+1a9/IPkUXjFq0PuzMiWhsM9xigVTCXw c7HmL8DszIi0yGEl X-Google-Smtp-Source: ADKCNb7L6Bn/q+O3ISkGeZEu++E0gG/CpNlgBchiMNCrX2aj/rGCLflKQQqywnbKw0tXEWxpaMCIgg== X-Received: by 10.99.121.66 with SMTP id u63mr1933344pgc.166.1504564650551; Mon, 04 Sep 2017 15:37:30 -0700 (PDT) Received: from [130.216.38.129] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.129]) by smtp.gmail.com with ESMTPSA id f78sm58247pfk.139.2017.09.04.15.37.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Sep 2017 15:37:29 -0700 (PDT) To: Ole Troan Cc: David Farmer , Lorenzo Colitti , "v6ops@ietf.org" References: <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0f18ee6d-81a3-ff68-1d0e-bc41cc409db5@gmail.com> Date: Tue, 5 Sep 2017 10:37:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] RFC6085 scope [was Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 22:37:32 -0000 On 05/09/2017 08:56, Ole Troan wrote: >>>> >>>> Sending a >>>> message with a multicast layer 3 destination to a unicast layer 2 >>>> destination on a multicast-capable link is unusual. >>> >>> RFC6085. >> >> Which sort of confirms that it's unusual ;-). This would be a good >> reference for the draft, if that is indeed what is intended. >> >> BTW, RFC6085 is explicitly about Ethernet. Is there any reason that >> it doesn't apply to any broadcast link-layer? > > Which link-layer are you thinking of? Well, OK, I'm a standards freak, but Token Ring and FDDI both support layer 2 multicast. And as has been pointed out, 802.11 may look like Ethernet, but it isn't Ethernet. So my question is not about the prevalence of 802.1 in the real world, but about the generality of the rule. I assume it would apply in all cases. Brian From nobody Mon Sep 4 23:38:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE54132392 for ; Mon, 4 Sep 2017 23:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ng74tDHz3KoJ for ; Mon, 4 Sep 2017 23:38:48 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A38F51323A3 for ; Mon, 4 Sep 2017 23:38:48 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id C3AD72D5056; Tue, 5 Sep 2017 06:38:45 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id AF25310159D22; Tue, 5 Sep 2017 08:38:43 +0200 (CEST) From: Ole Troan Message-Id: <22761148-DB11-4792-9C64-B441FA50F5EE@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_9F8DFE8D-473B-43B2-8561-A9B75D20385B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 5 Sep 2017 08:38:42 +0200 In-Reply-To: <0f18ee6d-81a3-ff68-1d0e-bc41cc409db5@gmail.com> Cc: David Farmer , Lorenzo Colitti , "v6ops@ietf.org" To: Brian E Carpenter References: <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> <0f18ee6d-81a3-ff68-1d0e-bc41cc409db5@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] RFC6085 scope [was Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 06:38:54 -0000 --Apple-Mail=_9F8DFE8D-473B-43B2-8561-A9B75D20385B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Brian, >>>>> Sending a >>>>> message with a multicast layer 3 destination to a unicast layer 2 >>>>> destination on a multicast-capable link is unusual. >>>>=20 >>>> RFC6085. >>>=20 >>> Which sort of confirms that it's unusual ;-). This would be a good >>> reference for the draft, if that is indeed what is intended. >>>=20 >>> BTW, RFC6085 is explicitly about Ethernet. Is there any reason that >>> it doesn't apply to any broadcast link-layer? >>=20 >> Which link-layer are you thinking of? >=20 > Well, OK, I'm a standards freak, but Token Ring and FDDI both support > layer 2 multicast. And as has been pointed out, 802.11 may look like > Ethernet, but it isn't Ethernet. So my question is not about the > prevalence of 802.1 in the real world, but about the generality > of the rule. I assume it would apply in all cases. RFC6085 applies to any link-layer which uses RFC2464 mapping. Including = WIFI. I agree with you that the document should have been more general. I = don't see any reason why this rule couldn't be general. It of course = makes some assumptions about keeping the state about the mapping that = isn't required in general if the multicast mapping is used. That said, = 6085 specifically restricts itself to Ethernet. I guess if we need this = clarification on Token Ring we'll cross that barrier when we get to it. = ;-) Best regards, Ole --Apple-Mail=_9F8DFE8D-473B-43B2-8561-A9B75D20385B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZrkZzAAoJEL7aWKiYQt92scQP/3GfQmOLQvlqJ6YxHH0F5dmL 8v6p36nJ70lBBLlb5KN95MtAt42wCASnpNtcALCqELvAOIIhi0/VRjIqEflwqCdo CBEjnylp4H0sCBz8PZyOD/w9YXizK29xu6lzYJSuwirpgCQmV1C+5mHn9FiLYI10 +sItyDjSC/8HZ7zeJz07M9lr06Zk+ZoRsCt/B+lo4p1rmf3pG/ygr7XyUBNbWux8 ijovVVx7BeoSOGWmOMITLua6U+raBkIswsXYbUR3Km9BEfw1mJg4Mmfagl4yhKkM dpN7ogLiJDRIu4Jz4R3axh4GvxQ4cLeaFNdk0e8Mn/7V5vkLwvZC8oQv+Qf9zyKI h8allb4JAYrYjzS81EEgP1cqSmEsI6b3j70I3hRlS0g5bQCZ2jckNd/Ord39MbT3 H37TcysCdAeZOOnepbUjlGYY2hO4Nzu6v0bwag/GLCeD5wcY9eBz8OaoKb1gsIRA rtlVO5y50JfQo9ccy8hxdizcO2w5hUwFZhVpXe4WwsQo1eeghg8CZiGwimDkx8ZV nVI8JVLOLFHZz5hAOPKUUz93lEhDsr85ay5sIg4+8sMDEWUn6CAigqx6N/4d0cvj /X+H99pSgRAbCyz39+8TfbQsBxff5VYVv1zk25nsdknm9EBz+x0mNDp9LOFo5pBg HSfjUzKtw91cbUTT2icF =Awz8 -----END PGP SIGNATURE----- --Apple-Mail=_9F8DFE8D-473B-43B2-8561-A9B75D20385B-- From nobody Mon Sep 4 23:51:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A66132392 for ; Mon, 4 Sep 2017 23:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 163SPV0Ze1QH for ; Mon, 4 Sep 2017 23:51:43 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB2B120727 for ; Mon, 4 Sep 2017 23:51:43 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 283E52D5046; Tue, 5 Sep 2017 06:51:43 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 81F3C10159F4C; Tue, 5 Sep 2017 08:51:42 +0200 (CEST) From: Ole Troan Message-Id: <8C9800CD-91F9-47D4-A7DB-5C7D99371B0B@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_84316DF5-ADC9-4A33-95C8-993A411DC2A1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 5 Sep 2017 08:51:41 +0200 In-Reply-To: Cc: Brian E Carpenter , v6ops list To: Mark Smith References: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 06:51:45 -0000 --Apple-Mail=_84316DF5-ADC9-4A33-95C8-993A411DC2A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, > >> Sending a > >> message with a multicast layer 3 destination to a unicast layer 2 > >> destination on a multicast-capable link is unusual. > > > > RFC6085. >=20 > Which sort of confirms that it's unusual ;-). This would be a good > reference for the draft, if that is indeed what is intended. >=20 > BTW, RFC6085 is explicitly about Ethernet. Is there any reason that > it doesn't apply to any broadcast link-layer? >=20 >=20 > While RFC6085 is useful to have in our toolbox,I think it would be = better to IPv6 layer unicast RAs. That encodes the intent of which set = of devices are intended to receive the RA in the DA in this scenario = (i.e. a set of one). I would strongly object to this draft mandating one mapping over the = other. My implementation uses L3 multicast -> L2 unicast. And it would be a = significant change to send L3 unicast. > If the draft is discussing a Wifi service provider scenario, which I = think is likely, then RAs should probably also be unicast to save batter = power of client devices per BCP202. L2 multicast is what's expensive, so regardless of mapping this results = in battery saving. Ole --Apple-Mail=_84316DF5-ADC9-4A33-95C8-993A411DC2A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZrkl+AAoJEL7aWKiYQt92QCEP+wTO4Vl3Ge6jpUfN2Z0KhjAm zErIdRCRAvgA+u/kruj3Iv0kIWkN/kqwvt583XEjT1f8vElpWNYoKiJQjeLnpZb4 Vb8/JohP/y+cOpIj2dhQtgzF3vLh/Zb6iA4oUdMD4A17vlZZYU8QhVBRRgqtkAcA zPoMzttVX+g9+n3RLQ4zZRQft975icJ4Qk88Mn9/SD27zle45bUnKmWnTNr6usSe ckBEm1VrzvaFQOgACGoj/g8thBZZBToeXVPBtdPyDjeJrBsZB9sWHgzFU8Lyyyu1 MRzoXKE7teWAam54bvnl7HsEUkppRYtzaTqhnTRCPIuxRtEU0ciVeNBbJy9W6aRI LN/p74bX1s+HPxFZHGIdUc5dpWj6uqnlKa2IAve/z5+Bu8DCwOGsvJhRl7NYnd22 +/EbF+LOzOzZ9IoJEd5hybAiRNugMTj5f42zuVWzcySJxghfHmc9B6rpsuU4FT7N HlwEXt67nzuawC7PyEd0V8nWUQU7NpahafrzLv32vrhnMjlHEKTnLfkh1NMJaDIq 8WKFcUGByIlMROv5yqnfC9lCQA74thvZjbGbkam229gOvkIYwtLQ8hNVktQa/iV7 yyZYewlJ1ilJNQhqEVnh2Un+6EbCFKSJommLAsV/X3ECrPlUd4tMtkraLGjpEhop bSWK+W+2gvpKxqtdV/Vf =cLuQ -----END PGP SIGNATURE----- --Apple-Mail=_84316DF5-ADC9-4A33-95C8-993A411DC2A1-- From nobody Mon Sep 4 23:53:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3C91323B8 for ; Mon, 4 Sep 2017 23:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qir1Nkh0k6p7 for ; Mon, 4 Sep 2017 23:53:23 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205C11323B5 for ; Mon, 4 Sep 2017 23:53:23 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8CADEB1; Tue, 5 Sep 2017 08:53:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504594400; bh=WOZpUPFC/0kpywIK+VM3wI1AVn9O+yIKs2JiDVxWbaE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=YKIaMjpxefxKyaNUax1cow/udO+wgbKqZaWrRj+h0Y0XBtlVbVK0cKiV8e6fFSCPv VopmO2ppMQwSfnNO8rUrrXxk3+zfdpw0Y/+P7tMb9WY34iDiI3XZR/4pyZE2t7HTaR F1DPKIXWsy28BbiC2h0POqDQNyAA5x8N7qs0q6Eo= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 753F3B0; Tue, 5 Sep 2017 08:53:20 +0200 (CEST) Date: Tue, 5 Sep 2017 08:53:20 +0200 (CEST) From: Mikael Abrahamsson To: Brian E Carpenter cc: Ole Troan , "v6ops@ietf.org" In-Reply-To: <0f18ee6d-81a3-ff68-1d0e-bc41cc409db5@gmail.com> Message-ID: References: <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> <0f18ee6d-81a3-ff68-1d0e-bc41cc409db5@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] RFC6085 scope [was Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 06:53:25 -0000 On Tue, 5 Sep 2017, Brian E Carpenter wrote: > Well, OK, I'm a standards freak, but Token Ring and FDDI both support > layer 2 multicast. And as has been pointed out, 802.11 may look like > Ethernet, but it isn't Ethernet. So my question is not about the > prevalence of 802.1 in the real world, but about the generality of the > rule. I assume it would apply in all cases. It's an interesting case. To the IP stack in most OSes, doesn't wifi packets received look like they're ethernet framed? So wifi kind of pretends to look Ethernet as much as it can, and these kinds of rules should be applied to all media types that have L2 multicast/broadcast/unicast concepts, right? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 5 00:07:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEEC13243E for ; Tue, 5 Sep 2017 00:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsT3Qs-TzB5b for ; Tue, 5 Sep 2017 00:07:18 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE34F120727 for ; Tue, 5 Sep 2017 00:07:18 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 975C3B1; Tue, 5 Sep 2017 09:07:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504595236; bh=lng9itSThytjN8yUKwx0JY4KzN34ttszU0bNiw9UGBM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=09zACpgO0M2sCbnzVsfgLGK60P9rDycjZZIQdn6IbNmHskvFEJqZsAthhTtC7djFQ FjgdoZT5PtM9hKuobDCkPys1Z786e1RPSyJjTUVrZVaEmc0YOIiwGvU61lGvdQ80Ih GO4Qx0j7GphAMeEyG4VkWBJVbqf5WOLCiwm+24lI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7E7C0B0; Tue, 5 Sep 2017 09:07:16 +0200 (CEST) Date: Tue, 5 Sep 2017 09:07:16 +0200 (CEST) From: Mikael Abrahamsson To: Mark Smith cc: Brian E Carpenter , james woodyatt , v6ops list In-Reply-To: Message-ID: References: <9FB70EAC-1D18-4540-BB2B-85F9B894E843@gmail.com> <42d53255-5ba0-9490-88c9-1210b61af542@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Inconsistent host on-link/off-link assumptions on a multi-access link (Re: Peer discovery for unique IPv6 prefixes per host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 07:07:20 -0000 On Mon, 28 Aug 2017, Mark Smith wrote: > BBF didn't invent this. Private VLANs have been around for about 15 > years or more. From memory, they were created to save IPv4 address > space, avoiding losing .0 and subnet broadcast addresses for each > subnet/VLAN. That requirement doesn't apply to IPv6, however people They were also invented for security reasons, for instance in enterprise and ETTH scenarios. https://datatracker.ietf.org/doc/rfc3069/?include_text=1 from 2001. This includes the concept of sharing an IPv4 subnet across many broadcast domains. This is one way of doing "private vlan", others are different. In this deployment scenario however, I would definitely have separate IPv6 prefixes per vlan (/64) and not share an IPv6 prefix in the same manner. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 5 00:36:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D528B13239C for ; Tue, 5 Sep 2017 00:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBS8yBCRUTxV for ; Tue, 5 Sep 2017 00:36:32 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242CB132397 for ; Tue, 5 Sep 2017 00:36:32 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id g47so6534646uad.0 for ; Tue, 05 Sep 2017 00:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z9KqiE0rg3NCR5VtH+9wMVK/vB3TrCLBqGwt9X0fXIY=; b=TFhu0wnUi/R+eYj6jaw+eK+ZPAG4GZ2cR2+A2USZWtEail8EEiSbybLIjzv2rbZ/Pl JEa7923FK769k4rLhsxps+sdqF6vsg5sDKjdETgh16KN+Hi6iBdjqTxd7oSHa9HVj8wc 8Ss4v346uIdTZjgZ2r7CkW+3T8NtGGPk+qiyWxbX02yib6u5svbKGWs7+o60YCIkuYNa mjqSaWapl1dHPxlQjSngRA7LO6oRhyLm5cW8zx0NXuK5LYiI1wHyOXUMf9NW2MVxed55 HRZXHU4iu1nx8UxMwfU6tTQcGFa2ELEWg5vfP9RLlpWEwdDZ5gwpQO01DdtFaaE49r+I 8pmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z9KqiE0rg3NCR5VtH+9wMVK/vB3TrCLBqGwt9X0fXIY=; b=JVo8Ajj4KNgAuk6JGpd78Ds7omT6jliuF03AZdkSuexsHtwPtIeaTsOExk7yFWxmMy KEfTqvZnud29xGkczvGg9GAsCugLG3E5z/7zF0g59hh/LKdv+WMttTgPUSt54xaerBHQ RdMYTzE1rpIxKpzhyPgLF3nU1Z00xYFlKylTRtiNsSOh5igg/yrg/qZXcdU8cKrLgZem vRjEZwJ9c7CmJiECcZTKbZWfwV4FrvQmbiHFkjTsZM07YceXc7oT+W0U04PA5NhUz70s sRSXowX/6h58A/c34Di5DRFVmBPA8MYVw776/gUEMAlbKDwF8yL7pvORJ7X1rDht/joM 0R8Q== X-Gm-Message-State: AHPjjUiSTe+GtvPAZoz50nQWM4qJohs2pXLSlDZ1L+PCFQg1GqZ4fYNA sgjMPbRVedZdXZ/sY1t6eTfaIxOh4Q== X-Google-Smtp-Source: ADKCNb6f/fj/CagLWOoWaPbrf5JopXFLo9aGyVzA38350MUTReA28n0tehMBFjQJmIDEXQYkyNnIuz5+jQYgStndpok= X-Received: by 10.176.89.131 with SMTP id g3mr1989408uad.53.1504596991069; Tue, 05 Sep 2017 00:36:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Tue, 5 Sep 2017 00:36:30 -0700 (PDT) Received: by 10.176.27.19 with HTTP; Tue, 5 Sep 2017 00:36:30 -0700 (PDT) In-Reply-To: <8C9800CD-91F9-47D4-A7DB-5C7D99371B0B@employees.org> References: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> <8C9800CD-91F9-47D4-A7DB-5C7D99371B0B@employees.org> From: Mark Smith Date: Tue, 5 Sep 2017 17:36:30 +1000 Message-ID: To: Ole Troan Cc: Brian E Carpenter , v6ops list Content-Type: multipart/alternative; boundary="001a114973fc2ed4e405586c491c" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 07:36:34 -0000 --001a114973fc2ed4e405586c491c Content-Type: text/plain; charset="UTF-8" On 5 Sep. 2017 16:51, "Ole Troan" wrote: Mark, > >> Sending a > >> message with a multicast layer 3 destination to a unicast layer 2 > >> destination on a multicast-capable link is unusual. > > > > RFC6085. > > Which sort of confirms that it's unusual ;-). This would be a good > reference for the draft, if that is indeed what is intended. > > BTW, RFC6085 is explicitly about Ethernet. Is there any reason that > it doesn't apply to any broadcast link-layer? > > > While RFC6085 is useful to have in our toolbox,I think it would be better to IPv6 layer unicast RAs. That encodes the intent of which set of devices are intended to receive the RA in the DA in this scenario (i.e. a set of one). I would strongly object to this draft mandating one mapping over the other. My implementation uses L3 multicast -> L2 unicast. And it would be a significant change to send L3 unicast. I'm looking at it from the principle of least surprise. A packet with an L3 mcast DA in a frame with an L2 unicast DA would be surprising unless you're expecting it and know it is intentional. Is the significant change in the area of building up the table of unicast IPv6 addresses (LLs probably) to unicast to? I haven't been entirely sure if routers do this or are required to do this, however I've thought routers could proactively store RS and MLD message source addresses in their ND cache, with NUD then being the method that keeps those entries current. Per when I did investigations while writing this draft, it seems that if a router is processing MLDv2 messages, it needs to have or trigger an NS for the MLDv2 source address. MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6https://tools.ietf.org/id/draft-smith-mldv2-link-unicast-00.txt > If the draft is discussing a Wifi service provider scenario, which I think is likely, then RAs should probably also be unicast to save batter power of client devices per BCP202. L2 multicast is what's expensive, so regardless of mapping this results in battery saving. If RFC6085 was used for more than just RAs, ideally every L3 mcast where possible i.e. draft above, that makes them less surprising. Regards, Mark. Ole --001a114973fc2ed4e405586c491c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 5 Sep. 2017 16:51, "Ole Troan" <otroan@employees.org> wrote= :
Mar= k,

> >> Sending a
> >> message with a multicast layer 3 destination to a unicast lay= er 2
> >> destination on a multicast-capable link is unusual.
> >
> > RFC6085.
>
> Which sort of confirms that it's unusual ;-). This would be a good=
> reference for the draft, if that is indeed what is intended.
>
> BTW, RFC6085 is explicitly about Ethernet. Is there any reason that > it doesn't apply to any broadcast link-layer?
>
>
> While RFC6085 is useful to have in our toolbox,I think it would be bet= ter to IPv6 layer unicast RAs. That encodes the intent of which set of devi= ces are intended to receive the RA in the DA in this scenario (i.e. a set o= f one).

I would strongly object to this draft mandating one mapping over the = other.
My implementation uses L3 multicast -> L2 unicast. And it would be a sig= nificant change to send L3 unicast.

I'm looking at it from the pri= nciple of least surprise. A =C2=A0packet with an L3 mcast DA in a frame wit= h an L2 unicast DA would be surprising unless you're expecting it and k= now it is intentional.

I= s the significant change in the area of building up the table of unicast IP= v6 addresses (LLs probably) to unicast to? I haven't been entirely sure= if routers do this or are required to do this, =C2=A0however I've thou= ght routers could proactively store RS and MLD message source addresses in = their ND cache, with NUD then being the method that keeps those entries cur= rent.

Per when I did inv= estigations while writing this draft, it seems that if a router is processi= ng MLDv2 messages, it needs to have or trigger an NS for the MLDv2 source a= ddress.

MLDv2 Procedures for Link-Layer Un=
icast Delivery of Multicast IPv6https://tools.ietf.org/id/draft-smith-mldv=
2-link-unicast-00.txt


> If the draft is discussing a Wifi service provider scenario, which I t= hink is likely, then RAs should probably also be unicast to save batter pow= er of client devices per BCP202.

L2 multicast is what's expensive, so regardless of mapping this r= esults in battery saving.

If RFC6085 was used for more than just RAs, = ideally every L3 mcast where possible i.e. draft above, that makes them les= s surprising.

Regards,
Mark.


Ole

--001a114973fc2ed4e405586c491c-- From nobody Tue Sep 5 00:55:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF0C132644 for ; Tue, 5 Sep 2017 00:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C_3OWIMvMIh0 for ; Tue, 5 Sep 2017 00:55:32 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1436D132494 for ; Tue, 5 Sep 2017 00:55:31 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 4DEC42D4FEA; Tue, 5 Sep 2017 07:55:28 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7CADF1015ABE4; Tue, 5 Sep 2017 09:55:24 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6BF88C9D-D044-45BF-8286-72290ED7FA51"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 5 Sep 2017 09:55:23 +0200 In-Reply-To: Cc: Brian E Carpenter , v6ops list To: Mark Smith References: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> <8C9800CD-91F9-47D4-A7DB-5C7D99371B0B@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 07:55:35 -0000 --Apple-Mail=_6BF88C9D-D044-45BF-8286-72290ED7FA51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, > > >> Sending a > > >> message with a multicast layer 3 destination to a unicast layer 2 > > >> destination on a multicast-capable link is unusual. > > > > > > RFC6085. > > > > Which sort of confirms that it's unusual ;-). This would be a good > > reference for the draft, if that is indeed what is intended. > > > > BTW, RFC6085 is explicitly about Ethernet. Is there any reason that > > it doesn't apply to any broadcast link-layer? > > > > > > While RFC6085 is useful to have in our toolbox,I think it would be = better to IPv6 layer unicast RAs. That encodes the intent of which set = of devices are intended to receive the RA in the DA in this scenario = (i.e. a set of one). >=20 > I would strongly object to this draft mandating one mapping over the = other. > My implementation uses L3 multicast -> L2 unicast. And it would be a = significant change to send L3 unicast. >=20 > I'm looking at it from the principle of least surprise. A packet with = an L3 mcast DA in a frame with an L2 unicast DA would be surprising = unless you're expecting it and know it is intentional. Not it my implementation. Each router - host connection is represented = as an interface. > Is the significant change in the area of building up the table of = unicast IPv6 addresses (LLs probably) to unicast to? I haven't been = entirely sure if routers do this or are required to do this, however = I've thought routers could proactively store RS and MLD message source = addresses in their ND cache, with NUD then being the method that keeps = those entries current. Again talking about my implementation, but I believe this applies = generally to unique-ipv6-prefix-per-host, - there is no ND cache. = That's kind of the whole point. >=20 > Per when I did investigations while writing this draft, it seems that = if a router is processing MLDv2 messages, it needs to have or trigger an = NS for the MLDv2 source address. >=20 > MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast = IPv6https://tools.ietf.org/id/draft-smith-mldv2-link-unicast-00.txt MLD for link-local multicast has no utility in general. > > If the draft is discussing a Wifi service provider scenario, which I = think is likely, then RAs should probably also be unicast to save batter = power of client devices per BCP202. >=20 > L2 multicast is what's expensive, so regardless of mapping this = results in battery saving. >=20 > If RFC6085 was used for more than just RAs, ideally every L3 mcast = where possible i.e. draft above, that makes them less surprising. This draft essentially creates a /64 -> MAC address binding. It doesn't = specify what to do with multicast in general. My implementation does a P2P interface -> MAC address binding. Which of = course then takes care of multicast. In RFC6085 fashion. Cheers, Ole --Apple-Mail=_6BF88C9D-D044-45BF-8286-72290ED7FA51 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZrlhsAAoJEL7aWKiYQt92XEYP/irJR3FHM0trWyEWew02K/ZH gErobzFpGF1q7YLK0RoWp4T6Ql1MLoDZzJhXX97yYTYbCxP89MsuXqNXyJNjC7HU fyePIDEoXmww7pyl4RY0Z7A6ynkpoDXAM6TbTZhF+dBa8OX3xtv0C9kxM74qXzMZ DW3ExzX1NsC5cS11L0f8Rd5uT5RIOW17ujPZivF8dlvwIpcC3TLSom2pUrtXN/vf J0UU3tbLykDw3MW1zCdcMpTr6ItePikoRzx2mj4kYEUpsGfJXIJwuz7A1i4ZxcLC IlVAAk5dGOblIWtpomu49WA8MuwF8SnhWc7/qHdgcI9ediXJyGHN9kt4+spwQzWu bFbm74Kx2dXJM1sBzINJoaOCVUk9aZ5bw8FBZ1apd8JPapndNS0ffIWbO2WfzTZp SgU3dPBvYLyAqEH42w1adfR7t2u8D0KhD8crTw2Lzr5t8oKW3UluMzdK3tkO+i/F /jbtWwZ1imV/szvQ8rJpubP7rpsX0i8azHBuu7vFXe+l7Gfrems1pkpQ5yUCU/cy 0FyYFtbHcf2RpXLzWPBaNIv96NCu7nCIC3lYiTj0CeVONKQH0ZEq4M/AYzBQ7e0K NnUyI3ajRThwOy6aAtxLChsu2Sk+0Sq3XNMgxe96+o8lJw+YTD9WeNplr01yKOl2 vrEhWrEWKBLRZvd6j6sk =cztR -----END PGP SIGNATURE----- --Apple-Mail=_6BF88C9D-D044-45BF-8286-72290ED7FA51-- From nobody Tue Sep 5 01:30:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D55132715 for ; Tue, 5 Sep 2017 01:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, 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 GX5mwaef-1fj for ; Tue, 5 Sep 2017 01:30:12 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7201513263F for ; Tue, 5 Sep 2017 01:30:12 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id 19so5756570vkf.2 for ; Tue, 05 Sep 2017 01:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EgHhilTYgD29N5nuJRc/jwG05lXiqX70Y+6HjSeEzrg=; b=adeN0EjpDT53A53bJFjq3Xp8ryJExs+VEKlsuHpWGvzo7mPAP1ZtobB0tkA1Nqdl6z fhr48XwivT/OgsqiSBpN4BiD3cAsLN8mqJV9S+gcjHVxld7J5OiS5+jC22xQ2jIRtd+0 WbxchQH1IrzZvQ/1Kcou5hrO40p2GNX9lyOF79G9TvHWCi7KAXWSFK6wK5YiEodixFA9 ad7VryRsYMcuEn8AeJXWc4RTHtLRU/ssUIU3gY8GR2ngMb1tuLRmbjZXqzSFlJgvQNlt RkpFsOY7HrSY9DVR3x67EXGp4XiJCspkZ0A+Agg9O7HZIbQhLCn7KftlYOUFmLv9PxvM //uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EgHhilTYgD29N5nuJRc/jwG05lXiqX70Y+6HjSeEzrg=; b=FD9MqPgRJyNfXq6WyRd019T9JGu/T2CMn0K6SHLNhkn/ScBQmtDv5ur01YQof4j3nZ e9pGIMDUkjXKboA6krdzmVp39h2D0lTd3+c5IBqCtcDQ2n1fHWUzsUjt8yF5W4Ymfzpc esmlO7XIC2L8TVSA7rdSpX8Chdym1jJd+NRJKpfvKYViqF+EO31Oe4L5j/bzNFK8To7q c7OkLCrx70Q+R2GjJKZfUfi2tBKkak8jXuRzbL87ihDvk9Zcw0TBLY0vlmQXSbSAdRMR 3hDFDN1ohXk3b8OvWVlWA+VLCC1W+tkQyb6FExSDzSOCqWzGt8p3ovIx2/ULVYXUCkVi LQuw== X-Gm-Message-State: AHPjjUh+lIE5VUAPGiGseChqrMqPxSk3gw/dSALhxQpI3/zbuAIxKG3I wK/jV0aD8ioe8OaeEq0aUw1izqLuhQ== X-Google-Smtp-Source: ADKCNb6h1RtBVuXZ/hrtwCbMsihzcPRtuYPtqJY2S/bzD840UV4YCcGmR+uqw4CxwMpSA6Kem6weI9D11MT0I7MXoMg= X-Received: by 10.31.189.134 with SMTP id n128mr1554827vkf.11.1504600211443; Tue, 05 Sep 2017 01:30:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.19 with HTTP; Tue, 5 Sep 2017 01:30:10 -0700 (PDT) Received: by 10.176.27.19 with HTTP; Tue, 5 Sep 2017 01:30:10 -0700 (PDT) In-Reply-To: References: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> <8C9800CD-91F9-47D4-A7DB-5C7D99371B0B@employees.org> From: Mark Smith Date: Tue, 5 Sep 2017 18:30:10 +1000 Message-ID: To: Ole Troan Cc: Brian E Carpenter , v6ops list Content-Type: multipart/alternative; boundary="001a114db88c21d4a505586d093c" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 08:30:14 -0000 --001a114db88c21d4a505586d093c Content-Type: text/plain; charset="UTF-8" On 5 Sep. 2017 17:55, "Ole Troan" wrote: Mark, > > >> Sending a > > >> message with a multicast layer 3 destination to a unicast layer 2 > > >> destination on a multicast-capable link is unusual. > > > > > > RFC6085. > > > > Which sort of confirms that it's unusual ;-). This would be a good > > reference for the draft, if that is indeed what is intended. > > > > BTW, RFC6085 is explicitly about Ethernet. Is there any reason that > > it doesn't apply to any broadcast link-layer? > > > > > > While RFC6085 is useful to have in our toolbox,I think it would be better to IPv6 layer unicast RAs. That encodes the intent of which set of devices are intended to receive the RA in the DA in this scenario (i.e. a set of one). > > I would strongly object to this draft mandating one mapping over the other. > My implementation uses L3 multicast -> L2 unicast. And it would be a significant change to send L3 unicast. > > I'm looking at it from the principle of least surprise. A packet with an L3 mcast DA in a frame with an L2 unicast DA would be surprising unless you're expecting it and know it is intentional. Not it my implementation. Each router - host connection is represented as an interface. > Is the significant change in the area of building up the table of unicast IPv6 addresses (LLs probably) to unicast to? I haven't been entirely sure if routers do this or are required to do this, however I've thought routers could proactively store RS and MLD message source addresses in their ND cache, with NUD then being the method that keeps those entries current. Again talking about my implementation, but I believe this applies generally to unique-ipv6-prefix-per-host, - there is no ND cache. That's kind of the whole point. > > Per when I did investigations while writing this draft, it seems that if a router is processing MLDv2 messages, it needs to have or trigger an NS for the MLDv2 source address. > > MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6 https://tools.ietf.org/id/draft-smith-mldv2-link-unicast-00.txt MLD for link-local multicast has no utility in general. Sort of off topic for this thread, however that draft is about any groups for which MLDv2 is used to join. It is a method to L2 unicast over the last hop, but not limited to single hop groups. > > If the draft is discussing a Wifi service provider scenario, which I think is likely, then RAs should probably also be unicast to save batter power of client devices per BCP202. > > L2 multicast is what's expensive, so regardless of mapping this results in battery saving. > > If RFC6085 was used for more than just RAs, ideally every L3 mcast where possible i.e. draft above, that makes them less surprising. This draft essentially creates a /64 -> MAC address binding. It doesn't specify what to do with multicast in general. My implementation does a P2P interface -> MAC address binding. Which of course then takes care of multicast. In RFC6085 fashion. Cheers, Ole --001a114db88c21d4a505586d093c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 5 Sep. 2017 17:55, "Ole Troan" <otroan@employees.org> wrote:
Mark,

> > >> Sending a
> > >> message with a multicast layer 3 destination to a unicas= t layer 2
> > >> destination on a multicast-capable link is unusual.
> > >
> > > RFC6085.
> >
> > Which sort of confirms that it's unusual ;-). This would be a= good
> > reference for the draft, if that is indeed what is intended.
> >
> > BTW, RFC6085 is explicitly about Ethernet. Is there any reason th= at
> > it doesn't apply to any broadcast link-layer?
> >
> >
> > While RFC6085 is useful to have in our toolbox,I think it would b= e better to IPv6 layer unicast RAs. That encodes the intent of which set of= devices are intended to receive the RA in the DA in this scenario (i.e. a = set of one).
>
> I would strongly object to this draft mandating one mapping over the o= ther.
> My implementation uses L3 multicast -> L2 unicast. And it would be = a significant change to send L3 unicast.
>
> I'm looking at it from the principle of least surprise. A=C2=A0 pa= cket with an L3 mcast DA in a frame with an L2 unicast DA would be surprisi= ng unless you're expecting it and know it is intentional.

Not it my implementation. Each router - host connection is represente= d as an interface.

> Is the significant change in the area of building up the table of unic= ast IPv6 addresses (LLs probably) to unicast to? I haven't been entirel= y sure if routers do this or are required to do this,=C2=A0 however I'v= e thought routers could proactively store RS and MLD message source address= es in their ND cache, with NUD then being the method that keeps those entri= es current.

Again talking about my implementation, but I believe this applies gen= erally to unique-ipv6-prefix-per-host,=C2=A0 - there is no ND cache. That&#= 39;s kind of the whole point.

>
> Per when I did investigations while writing this draft, it seems that = if a router is processing MLDv2 messages, it needs to have or trigger an NS= for the MLDv2 source address.
>
> MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6https://tools.ietf.org/id/draft-smit= h-mldv2-link-unicast-00.txt

MLD for link-local multicast has no utility in general.


Sort of off topic for this thread, however that draft i= s about any groups for which MLDv2 is used to join. It is a method to L2 un= icast over the last hop, but not limited to single hop groups.


> > If the draft is discussing a Wifi service provider scenario, whic= h I think is likely, then RAs should probably also be unicast to save batte= r power of client devices per BCP202.
>
> L2 multicast is what's expensive, so regardless of mapping this re= sults in battery saving.
>
> If RFC6085 was used for more than just RAs, ideally every L3 mcast whe= re possible i.e. draft above, that makes them less surprising.

This draft essentially creates a /64 -> MAC address binding. It do= esn't specify what to do with multicast in general.

My implementation does a P2P interface -> MAC address binding. Which of = course then takes care of multicast. In RFC6085 fashion.

Cheers,
Ole


--001a114db88c21d4a505586d093c-- From nobody Tue Sep 5 01:43:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D21132715 for ; Tue, 5 Sep 2017 01:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keN7CoYPlYlw for ; Tue, 5 Sep 2017 01:43:35 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1AB1326F3 for ; Tue, 5 Sep 2017 01:43:35 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 653812D5046; Tue, 5 Sep 2017 08:43:34 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 48F1D1015B217; Tue, 5 Sep 2017 10:43:31 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A7593F7B-E540-432A-B592-7E5934E585FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 5 Sep 2017 10:43:30 +0200 In-Reply-To: Cc: Brian E Carpenter , v6ops list To: Mark Smith References: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> <8C9800CD-91F9-47D4-A7DB-5C7D99371B0B@employees.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 08:43:37 -0000 --Apple-Mail=_A7593F7B-E540-432A-B592-7E5934E585FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Sort of off topic for this thread, however that draft is about any = groups for which MLDv2 is used to join. It is a method to L2 unicast = over the last hop, but not limited to single hop groups. Good point. That's an alternative to what this draft does (essentially = limiting the broadcast domain to one host). Cheers, Ole --Apple-Mail=_A7593F7B-E540-432A-B592-7E5934E585FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZrmOzAAoJEL7aWKiYQt92U3IP/1NIBElrkxNgsT0UJEgqjty4 SVb/uzrOBiLij3uzfTThgq9j2r9R9y9hwUSuutvD8BbSEgc2LfzF03qG+/g9RHp9 H4GsXhWQAKN6Kquuyp/la7vVm6/6pirQH4zUwXvagjTVo7KI3VM0b6JyGvcv5WkR 1AP2uTtw6D7P28jJ+KQS2czb8vKlkJV4yOaHu8Escbh2ootG2OaIjnmADkpoOasV h10FpxkqjVRx/BbOoBtm3fQQio1O+/ZI4TL+Jz2WrllKvt4WnuMfAbc+zfkFn9i6 lSFX1GdLEZv/zzb9A4KLFGyaN+RFDWRjorbd2MdeEFQQZNq2pIQr6buZYPIuh7pz OwbYm41UrsGooN9lzV6gi9IE5nI7EetjSaqaOp9mQF2SZ+FoNxRPSJTON0vK9oUs KosnmEbax1rDTPhYMjlDeDKOO5mroyCYw2z0I+O3zcJh0gSMUFzfjOlzF8YVJTus wkMQWm9RE+LhCivg+RofJb6ZogfTMT1y2w0H7raVRDf9Vh9h0eTmUbfAXJULEy0u VH1Fe6KhukBX9Fxt1QN7mh10B+yNeYVKn0RLIaGCVAKbmnmTL59tXySj6g86klaD C/ombl1OXnVCC+AeHtd01Ewivp/7m762WqcPYDJTlG8pUjpM+TBpvjKjyv+miPDG Ns0igUXm4R/Cs9TJJqnl =881a -----END PGP SIGNATURE----- --Apple-Mail=_A7593F7B-E540-432A-B592-7E5934E585FE-- From nobody Tue Sep 5 06:38:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0751D132C45 for ; Tue, 5 Sep 2017 06:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 1QBw2vVDCN75 for ; Tue, 5 Sep 2017 06:38:31 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D325D132C2A for ; Tue, 5 Sep 2017 06:38:29 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 57CA6666 for ; Tue, 5 Sep 2017 13:38:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZqhMc4FAWYj for ; Tue, 5 Sep 2017 08:38:29 -0500 (CDT) Received: from mail-ua0-f199.google.com (mail-ua0-f199.google.com [209.85.217.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 1B43D6A0 for ; Tue, 5 Sep 2017 08:38:29 -0500 (CDT) Received: by mail-ua0-f199.google.com with SMTP id q29so2730186uaf.5 for ; Tue, 05 Sep 2017 06:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BgFNdtLE9hDZN+wmKxxkPx4ML9ennhDqEpNP0WSJI1I=; b=SnVJ7fW5WOEdoSdyq7YErVS7QlzB6WGQE9B44uX2zR3Cl+XZ8Olgap2vsgZVftiptD ZO2TCEqfjfEptlEVaSOhQzMW4k/So0bon5dlAmTq5oHRAcEbRhzKO5oyKA4rxKLlIL1d AGF3xLBQ0XqB8ery18c4OhjCzNKRRXY94Z+7wEUyDfPBywqBDo8ZMikU1UInV3GQYROY XfyJUZaB+o21hOvQDPDWmzPBGOkbM4ajh6Yx9mthEZe7lxF1rmb5F9IqkQoF76hiUKsi 1UdZ/ux4t5Vq2Mjz8JqItGamwmwVlk9izf1Qge/ELLoupepGjKqyrO06hzaSmsL1FqpO JFMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BgFNdtLE9hDZN+wmKxxkPx4ML9ennhDqEpNP0WSJI1I=; b=S1AhxUVp/XkcBpyctIhc7KilSbsrKXOf+VAJR5cTm/ZQzk+Kpfmw5YcdMJV67iHbtr toVIEle9qhwnxQO1e3qz5ddXaslQrKV6h644dB1VjJDQFT0HlKpnSoy3eWrr6nDvxw3Y XO/RL+rUNM69aoJIj9X7X3XiBmRiSoPU+/wpFM4vphC4AYUu7Trn0EQrMQ9ql/gSvwpQ Pg3rPtxxf6oswHdW/TYXgU3BloUsoJ1f3Jz3/yUaNwtOdybP+VDHof82JT9RdrUsj71Y Vx5/78duYLqhcKq68YZ3OPg2gi7vJN/O7eQdokkHjIU5tpfEzlEmdzdmZisaEJchzBKl VfVg== X-Gm-Message-State: AHPjjUjX2I6JLBsDKiy3YnB/SWs/qquNuDtbR1mPXeGoKQ/Wigdpbk5j ah8Haoxb8h24Hogu7IQESZ08nT1etsETljkBev+vlIShRB9k/NQps2psHPnoZXSBHESbwZ2ynH1 wMTInvUOZD08WrnCm X-Received: by 10.176.2.5 with SMTP id 5mr2782454uas.160.1504618707352; Tue, 05 Sep 2017 06:38:27 -0700 (PDT) X-Google-Smtp-Source: ADKCNb6yWmOqeQRz4Ih0Yq2M1kH2A48tbK2z2PSJPKxGx/8UQGnHtYHMXxzjrGx5TZnyTwy2FR6Pjh7Xk0R+lNA/mvI= X-Received: by 10.176.2.5 with SMTP id 5mr2782442uas.160.1504618707071; Tue, 05 Sep 2017 06:38:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.89.81 with HTTP; Tue, 5 Sep 2017 06:38:25 -0700 (PDT) In-Reply-To: References: <4aeb64fd8f6945868ca2a42312b7e15a@XCH15-06-08.nw.nos.boeing.com> <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> From: David Farmer Date: Tue, 5 Sep 2017 08:38:25 -0500 Message-ID: To: Mark Smith Cc: Brian E Carpenter , v6ops list , draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, v6ops-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a113cfa6a8f3af70558715754" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 13:38:34 -0000 --001a113cfa6a8f3af70558715754 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 4, 2017 at 5:21 PM, Mark Smith wrote: > > > On 5 Sep. 2017 06:33, "Brian E Carpenter" > wrote: > > On 05/09/2017 08:22, Ole Troan wrote: > >> > >> Sending a > >> message with a multicast layer 3 destination to a unicast layer 2 > >> destination on a multicast-capable link is unusual. > > > > RFC6085. > > Which sort of confirms that it's unusual ;-). This would be a good > reference for the draft, if that is indeed what is intended. > > BTW, RFC6085 is explicitly about Ethernet. Is there any reason that > it doesn't apply to any broadcast link-layer? > > > > While RFC6085 is useful to have in our toolbox,I think it would be better > to IPv6 layer unicast RAs. That encodes the intent of which set of devices > are intended to receive the RA in the DA in this scenario (i.e. a set of > one). > > If the draft is discussing a Wifi service provider scenario, which I think > is likely, then RAs should probably also be unicast to save batter power of > client devices per BCP202. > I think the draft should be agnostic about whether solicited RAs are sent unicast or multicast., but unsolicited RA have to be sent multicast. So, I propose the following; In the second paragraph of section 4, s/unicast/solicited/ Then add the following text as the third paragraph of section 4; In general, a solicited RA response, may be sent either unicast or multicast. However, an unsolicited RA, which is sent periodically, is always sent multicast. This is described in [RFC4861], sections 6.2.6 and 6.2.4 respectively. When the First Hop Router sends a multicast RA, either solicited or unsolicited, it SHOULD only be received by the UE/subscriber that has been assigned the Unique IPv6 prefix it contains. This is achieved by sending the packet to the unicast link-layer address of the UE/subscriber instead of the associated link-layer multicast address [RFC6085]. Thanks -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --001a113cfa6a8f3af70558715754 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Sep 4, 2017 at 5:21 PM, Mark Smith <markzzzsmith@gmail.co= m> wrote:


On 5 Sep. 2017 06:33, "Brian E Carpenter" <= ;brian.e.c= arpenter@gmail.com> wrote:
On 05/09/2017 08:22, Ole Troan wrote:<= br> >>
>> Sending a
>> message with a multicast layer 3 destination to a unicast layer 2<= br> >> destination on a multicast-capable link is unusual.
>
> RFC6085.

Which sort of confirms that it's unusual ;-). This would be a goo= d
reference for the draft, if that is indeed what is intended.

BTW, RFC6085 is explicitly about Ethernet. Is there any reason that
it doesn't apply to any broadcast link-layer?


While RFC6085 is useful to have in our toolbox,I think it would be better= to IPv6 layer unicast RAs. That encodes the intent of which set of devices= are intended to receive the RA in the DA in this scenario (i.e. a set of o= ne).

If the draft is dis= cussing a Wifi service provider scenario, which I think is likely, then RAs= should probably also be unicast to save batter power of client devices per= BCP202.

I think the draft shou= ld be agnostic about whether solicited RAs are sent unicast or multicast., = but unsolicited RA have to be sent multicast.=C2=A0=C2=A0So, I propose the = following;

In the second paragraph of section 4, s= /unicast/solicited/=C2=A0

Then add the following t= ext as the third paragraph of section 4;

In genera= l, a solicited RA response, may be sent either unicast or multicast. Howeve= r, an unsolicited RA, which is sent periodically, is always sent multicast.= This is described in [RFC4861], sections 6.2.6 and 6.2.4 respectively. Whe= n the First Hop Router=C2=A0sends a multicast RA, either solicited or unsol= icited, it SHOULD only be received by the=C2=A0UE/subscriber that has been assigned the=C2=A0Unique IPv6 = prefix it contains. This is achieved by sending the packet to the unicast=C2=A0link-= layer address o= f the=C2=A0UE/s= ubscriber instead of=C2=A0the associated=C2=A0link-layer multicast address=C2=A0[RFC6085].

Thanks
=C2=A0=C2=A0 =C2=A0 =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 & Telecommun= ication Services
Office of Information Technology
University of Minne= sota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phon= e: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-= 9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
--001a113cfa6a8f3af70558715754-- From nobody Tue Sep 5 07:52:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23FC132D4C; Tue, 5 Sep 2017 07:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBSQ201NRT2t; Tue, 5 Sep 2017 07:52:49 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670CF132D14; Tue, 5 Sep 2017 07:52:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v85Eqm2B016681; Tue, 5 Sep 2017 07:52:48 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v85Eqjhn016667 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 5 Sep 2017 07:52:46 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Sep 2017 07:52:45 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 5 Sep 2017 07:52:45 -0700 From: "Templin, Fred L" To: Warren Kumari , Suresh Krishnan CC: "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , The IESG Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTJcbyZ/JGPtSOiEKRi/iUYLBZ76KmYOMA Date: Tue, 5 Sep 2017 14:52:45 +0000 Message-ID: <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 14:52:52 -0000 Hi Warren, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Warren Kumari > Sent: Monday, September 04, 2017 2:43 PM > To: Suresh Krishnan > Cc: v6ops@ietf.org; draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org= ; draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org; > v6ops-chairs@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) ; The IESG > Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique= -ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) >=20 > I'd like to note that that there is continuing discussion on this > draft on the v6 ops list (yup, after WGLC and IETF LC :-)). I've only > been able to somewhat monitor it, but have asked the v6ops chairs for > input. Much of the discussion has been interesting, but not > necessarily pertaining exactly to this document. > Fred kindly asked the list: > https://mailarchive.ietf.org/arch/msg/v6ops/bpEDtnYkbvJQZAx_r6mtEhdNxrw > for anything substantive for the document (keeping in mind that it has > already gone through WGLC and IETF LC). >=20 > So far it doesn't seem like there are any other major changes needed, > other than "asking that the applicability comment that communication > between such nodes on a LAN should go through a connecting router > (which seems to me a given due to the relationship with routing) > should be documented." and David Farmer's followup -- > https://mailarchive.ietf.org/arch/msg/v6ops/_-QlBqGk9dChoFOhxigf5WlxYDY >=20 > Does anyone have anything else *substantive*? If so, I may have to > kick this back to the WG for another round. Yes, my substantive comments are found here and as given below: https://www.ietf.org/mail-archive/web/v6ops/current/msg27499.html Thanks - Fred fred.l.templin@boeing.com --- 1) In section 2: " o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router" =20 Please change to say: =20 "o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router unless the shared network explicitly permits peer-to-peer operations" 2) In Section 4: " If the UE/subscriber desires to send anything external including other UE/subscriber devices (assuming device to device communications is enabled and supported), then, due to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router." Please change to: "If the UE/subscriber desires to send anything external including other UE/subscriber devices (assuming device to device communications is enabled and supported), then, due to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router unless the shared network explicitly permits peer-to-peer operations." --- > W >=20 >=20 >=20 >=20 > On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan > wrote: > > Hi Gunter, > > Thanks for the proposed text changes. They adequately address my DISC= USS > > points. I am hoping you will also converge in the discussion with Loren= zo on > > the actual value for the timer and/or specify an applicability statemen= t. I > > will clear once the new revision posts. > > > > Regards > > Suresh > > > > On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) > > wrote: > > > > Hi Suresh, > > > > Many thanks for the review and finding these issues. What do you think = of > > the proposals below to fix those points of attention? > > > > --------------------------------------------------------------------= -- > > DISCUSS: > > --------------------------------------------------------------------= -- > > > > * Section 4 > > > > It is not clear what you intend here > > > > "IPv6 Router Advertisement Interval =3D 300s" > > > > The router advertisement interval is not configured as an absolute v= alue > > but as > > minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval) > > which are > > used to calculate the actual advertisement interval. When the RA is = sent > > from > > an interface, the actual interval is an uniformly distributed random > > value > > between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very min= imum > > you > > need to clarify if you would like to have this as a lower bound or a= s an > > upper > > bound. > > > > GV> I changed the line to make it more clear that the timer indicates t= he > > maximum Advertisement Interval > > GV> Maximum IPv6 Router Advertisement Interval =3D 300s > > > > --------------------------------------------------------------------= -- > > COMMENT: > > --------------------------------------------------------------------= -- > > > > * Section 4 > > > > -> I think text is needed here to handle the case where the DNS serv= er is > > provided in the RA itself (RFC8106) > > > > "In addition it will use stateless DHCPv6 to get the IPv6 address of= the > > DNS > > server" > > > > -> I am not sure what is the motivation for this text. > > > > "however it SHOULD NOT use stateful DHCPv6 to receive a service prov= ider > > managed IPv6 address" > > > > -> This text seems incorrect > > > > "due to the L-bit set, it SHOULD send this traffic to the First Hop > > Provider > > Router" > > > > I think it should be the exact opposite. i.e. say *unset* instead of= set > > > > "due to the L-bit being unset, it SHOULD send this traffic to the Fi= rst > > Hop > > Provider Router" > > > > GV> What about the following modification in the text: > > > > OLD: > > The architected result of designing the RA as documented above is > > that each UE/subscriber gets its own unique IPv6 prefix for which it > > can use SLAAC or any other method to select its /128 unique address. > > In addition it will use stateless DHCPv6 to get the IPv6 address of > > the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive > > a service provider managed IPv6 address. If the UE/subscriber > > desires to send anything external including other UE/subscriber > > devices (assuming device to device communications is enabled and > > supported), then, due to the L-bit set, it SHOULD send this traffic > > to the First Hop Provider Router. > > > > New: > > The architected result of designing the RA as documented above is > > that each UE/subscriber gets its own unique IPv6 prefix for which it > > can use SLAAC or any other method to select its /128 unique address. > > Either stateless DHCPv6 RFC3736 or IPv6 > > Router Advertisement Options for DNS Configuration > > RFC8106 can be used to get the > > IPv6 address of the DNS server. If the UE/subscriber desires to send > > anything external including other UE/subscriber devices (assuming devic= e > > to device communications is enabled and supported), then, due to the > > L-bit being unset, it SHOULD send this traffic to the First Hop Provide= r > > Router. > > > > > > > > Kind Regards, > > G/ > > > > >=20 >=20 >=20 > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 5 08:19:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829A6132D5F for ; Tue, 5 Sep 2017 08:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 7WXeWqhLwcFp for ; Tue, 5 Sep 2017 08:19:08 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B464132D5B for ; Tue, 5 Sep 2017 08:19:07 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id i200so17629267ioa.2 for ; Tue, 05 Sep 2017 08:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vLlHz1gCZXXdSklfYqYOMh/wmF+k7JD9rhrUwinYPCw=; b=ooKQhBdMbnFQknBm85zA2Xm7ypOBhfYZCG8s8r518p3gEq2eXkLrq8iBVwJfyiNMVX XBbAHxRPTNru0OePLibnvAjK/Z7LGB6NnB22f2ToE/XeyaI8VLgxtsZ/Kil5t5lxBOmQ YsuLGElYROuIgFbS/RdLqkV3QU+ytMoJI22ESqwzprPhwWj8rtTbz35C1RrmZqXfbE04 AtJLyDZsizAcnYQt3UXYIkthoBYfhe+92NsgRE+FB88B5Lzx/M4szdhfwaIFKiI/kF72 9Hwyjw7+Gl8BgE/wYH7BK4q8B4BIB2wh+6VGVSXijhrp3FUpYLqBjX8fXS3jCL7wxHq0 fEdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vLlHz1gCZXXdSklfYqYOMh/wmF+k7JD9rhrUwinYPCw=; b=l5oxXvtyn9j3qe63E5w33hhwohTpAvdluoA2cAIQPiAsGX6BfroI+GUvnV+92ldEVc SRu1Ny0rC2sMdrkS56D8o3XUDxYxv2fSbmTvNleUuxUSJka0WmWpASQuz7tVoQMzBbxm 1YPWv2Zg5OSy1jECqwVC8q3eqKLDjM32w7CFgObDLv7SB9UGrxPP2WeA4In67lmzdTES 4qYSX7DBpE6QLbJZhRvjtOuIzUhA1E4k72lY3LdB0BPBh6gK0+4RGMNZwYLcamMMG1W9 Dd0zk428kc/ZC45kZLYfWFHa/i2WSXynd1M1rAeMt7p+26d/Dt4sS1fyE3ZAneBH+RJm qNWA== X-Gm-Message-State: AHPjjUixhDpXBCSN3XyP/PPybrg4bzxc6cqqQHrf3LG8u28aLnQiPtTU 5qqQwcMiLnEPuvNvO7L5vns/ce8kh6AL X-Google-Smtp-Source: ADKCNb56cv6wFt2NJtVLozMTgO8ybiDa1pjrrbkVTH5v8kZulago5HF9MeXb+GDrQ7W+bFyh7NZVE7mfQoODO0s2NwY= X-Received: by 10.36.5.206 with SMTP id 197mr5224049itl.79.1504624746016; Tue, 05 Sep 2017 08:19:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.11 with HTTP; Tue, 5 Sep 2017 08:18:45 -0700 (PDT) In-Reply-To: <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Wed, 6 Sep 2017 00:18:45 +0900 Message-ID: To: "Templin, Fred L" Cc: Warren Kumari , Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , The IESG Content-Type: multipart/alternative; boundary="001a11353262826507055872bf6d" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:19:09 -0000 --001a11353262826507055872bf6d Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 11:52 PM, Templin, Fred L wrote: > Please change to say: > > "o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router unless the shared network > explicitly permits peer-to-peer operations" > AIUI this opinion is in the rough. --001a11353262826507055872bf6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Sep 5, 2017 at 11:52 PM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:
Please chang= e to say:

=C2=A0 =C2=A0 "o=C2=A0 Two devices (subscriber/hosts), both attached t= o the same provider
=C2=A0 =C2=A0 =C2=A0 =C2=A0managed shared network should only be able to co= mmunicate through
=C2=A0 =C2=A0 =C2=A0 =C2=A0the provider managed First Hop Router unless the= shared network
=C2=A0 =C2=A0 =C2=A0 =C2=A0explicitly permits peer-to-peer operations"=

AIUI this opinion is in the rough.
--001a11353262826507055872bf6d-- From nobody Tue Sep 5 08:23:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613FE132D5B for ; Tue, 5 Sep 2017 08:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PY_NgWNLNzk for ; Tue, 5 Sep 2017 08:23:28 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814AB132D52 for ; Tue, 5 Sep 2017 08:23:28 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id x190so10974692oix.3 for ; Tue, 05 Sep 2017 08:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b8kD8yjmn8UpfncEDDEWizhm01roc+7qvWjwlvQsIjE=; b=K6N7Kmp7G6C/TZ2OIdg39+IZP84qQpDKDYe1BDr0VNa02H1EebPPXWQWCKd2s+XgaG SCUkqlxqNWKi8y2IMWXso7wvi8CfY927t72UQ+yT7D5ekJvQ8qa6jixh8wW1yoUKqvfK jFOmw1rYIIQ41mYA7WqZqm9sBZkcN17l0rBSeltoPQICnGZfg7EXulYPUiTmauPtSpjx yDAoAR1oNv5s+HWpaJzhj/Gsn9lf41Fxg+EX4vKDV7zVEdI7mMS7U8Z2uZe1LrmiMjEF QNEJUeON4DavyIhvX1ICTLboAYTu3c9R7g+ieFEMjsEmPn7Bq6rSwR+qWOjE/4OmnR7y U87A== 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=b8kD8yjmn8UpfncEDDEWizhm01roc+7qvWjwlvQsIjE=; b=Dm+PW+XqcBmdgdTLCFFYk8kP+cWKxx4LaEBdx0/QXzs0VE8gmADEIib/xLkwXSgCX5 I2WNtvoS7wUFiuiJp4k9/QLShnJtW4L+pnomKPLSDEIF+vz0EdlsME6hGZiD4f8LOX6s RPjVCnDhglHslRsPDUxedV+8RIKomTrUwotX+xTxgm0sFS3Q+bafAyxmP3o6Budd3fpp oUKT3ZhiohVnHvpXSgK6ejWO/aLrqwNc+VEbMLprc9oF3PMJFq1FRjS9Kp3TG1W6fhHd OQ6zZ3sqpApfpykt1dyxNH5NgCLbZyX25PCajXt6jaT6eyAfD8pCtCxjFznE8UzFbL0v MZig== X-Gm-Message-State: AHPjjUighlKf40otwt6puMgd5bJOJY6iKnPGrfHFuVFXcdOAWcgSLEGO 5Sn8CLAhPUOraQ== X-Google-Smtp-Source: ADKCNb7m4Vi3oIaZH7b90YHRSOZEWe7c760CnVOE9Wl9ILAXxQAq/sSauBbLdAjBl0qc5pofRLwz6A== X-Received: by 10.202.10.150 with SMTP id k22mr3537019oiy.84.1504625007832; Tue, 05 Sep 2017 08:23:27 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1f43? ([2600:8802:5600:e::1f43]) by smtp.gmail.com with ESMTPSA id b130sm832634oih.43.2017.09.05.08.23.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 08:23:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: Date: Tue, 5 Sep 2017 08:23:25 -0700 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3EFFE83B-2BD0-4D67-A397-D7C39F55D554@gmail.com> References: <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> <0f18ee6d-81a3-ff68-1d0e-bc41cc409db5@gmail.com> To: Mikael Abrahamsson , Brian E Carpenter X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] RFC6085 scope [was Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:23:30 -0000 Sounds like an erratum on RFC 6085. > On Sep 4, 2017, at 11:53 PM, Mikael Abrahamsson = wrote: >=20 > On Tue, 5 Sep 2017, Brian E Carpenter wrote: >=20 >> Well, OK, I'm a standards freak, but Token Ring and FDDI both support = layer 2 multicast. And as has been pointed out, 802.11 may look like = Ethernet, but it isn't Ethernet. So my question is not about the = prevalence of 802.1 in the real world, but about the generality of the = rule. I assume it would apply in all cases. >=20 > It's an interesting case. To the IP stack in most OSes, doesn't wifi = packets received look like they're ethernet framed? So wifi kind of = pretends to look Ethernet as much as it can, and these kinds of rules = should be applied to all media types that have L2 = multicast/broadcast/unicast concepts, right? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 5 08:39:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D391132D5E; Tue, 5 Sep 2017 08:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwwIo4TKGeuk; Tue, 5 Sep 2017 08:39:01 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0098.outbound.protection.outlook.com [104.47.36.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59003132D67; Tue, 5 Sep 2017 08:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Me6JgLKcOoZ0+O0F90s9Esad1jbFNtQ0A1BRjRG1xig=; b=btO/G6N7qqAP2NFaJtuGQ9+FrRtu3xgqQv1614ZXrMS9jgq9yIn4mXUHORBR+oJUv0eOVfVaOVBJ/1vuiqWkQ/isSduWyBqxMro7dwbLYT81Kg2qoioIh2/8fXih/g2/yvuF3UKmtnzytQL+AtCQb9PthFHpzAe38ZutDSioqpY= Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB881.namprd05.prod.outlook.com (10.141.254.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Tue, 5 Sep 2017 15:38:56 +0000 Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.20.0035.010; Tue, 5 Sep 2017 15:38:56 +0000 From: Ron Bonica To: "draft-ietf-v6ops-rfc6555bis.all@ietf.org" , IPv6 Ops WG Thread-Topic: IPR confirmation Thread-Index: AdMmXM2cCSyFvzEJTNiVyJEpM7uPSg== Date: Tue, 5 Sep 2017 15:38:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net; x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR0501MB881; 6:9tv4H6dywmZL+Cejm59Ekm7byXf7dT5lqlymN8Qw3SKUZWaiLWy5FvlnsWpZX+P5EWUUKthLoYpRKKPcglJPxvEuN3vdueM8+EZAX438wjB7NyEMqrX8hEtBDQecTY2xWVgEyc5rluJqePatTKHCJ2LeKbBhT33NU8BBGWSr6ZmUv6knRo6nx2DLrKio2Te3bwPBGYwVt+96+dI43yXxpxeH6Byu01oKiUrIUTvr25vY51kG841h2fjozTgdhAAbDUfg+AIjWoKHD13icHxlumsdJzsvn3yShSSxY/qzXDsCWmviwa8urlCsKTuDGOK9jGOf6PNpGTdHuUJgxVu3PA==; 5:YrvdivgDcJaWKfwqm8rlHd2NTNohmo8LuQtxtDuWKotU7GNEnCCnPjS3Kg6pizTA1u7ReavW7cppEC83IyAq06DX7MXxfyY27Ml/YdKicOnLDZHHL8tNxqYypj3UVkiIfrle4sR4XLwi/XQL/rrX7A==; 24:Ho7DxfupYm0Xjuh3b4C533fJB5lHLMPTmpjKM3sSPoNIQzW2afDoby8SP7NtNDmGCnySK/jMD2n6jnOhjT4O+rNh/M7kwLQgQkY1sxJIdr4=; 7:zLl9MQDIYzKqvrw8COCj3ISbucwkMhqgOHEb7JEXBvtBFNs4wB/xi9588DCcr7inTQ/x0yGMlP3MzHvSdRYBkfxWyTuGNAR32TFSWOqlGAV1bUiBTnmfoumWqVZfIuQV0VN5zS7lkw3HO3az9PKX25gwd9O0FHpOXj+eQAqEkVTT0cxmQJsXUte4jYcN4E1MYEBqJ9b/s6LOv27W0m3o4VcLb+FLMiSJkMCNiHbg6sU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7ffc56b0-e39e-47ea-cc7a-08d4f4743821 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR0501MB881; x-ms-traffictypediagnostic: BLUPR0501MB881: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB881; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB881; x-forefront-prvs: 0421BF7135 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(2900100001)(55016002)(54356999)(6506006)(101416001)(50986999)(5660300001)(74316002)(558084003)(7116003)(3280700002)(7696004)(2906002)(3660700001)(99286003)(77096006)(7736002)(9686003)(2501003)(14454004)(305945005)(97736004)(6436002)(53936002)(86362001)(478600001)(81166006)(81156014)(25786009)(450100002)(8936002)(6116002)(102836003)(3846002)(8676002)(3480700004)(105586002)(221733001)(33656002)(106356001)(68736007)(189998001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB881; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2017 15:38:56.0580 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB881 Archived-At: Subject: [v6ops] IPR confirmation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:39:02 -0000 Folks, Could each of the authors of draft-ietf-v6ops-rfc6555bis please respond to = this message stating whether they know of any IPR associated with this draf= t? Ron From nobody Tue Sep 5 08:39:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9247C132D5E for ; Tue, 5 Sep 2017 08:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWChUg5TweL9 for ; Tue, 5 Sep 2017 08:39:11 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDB7132D54 for ; Tue, 5 Sep 2017 08:39:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v85Fd78P039316 for ; Tue, 5 Sep 2017 17:39:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2CFF4207928 for ; Tue, 5 Sep 2017 17:39:07 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 22AD0200F89 for ; Tue, 5 Sep 2017 17:39:07 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v85Fd6ZM017154 for ; Tue, 5 Sep 2017 17:39:07 +0200 To: v6ops@ietf.org References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 5 Sep 2017 17:39:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:39:16 -0000 Hi, I want to update the list about our advancements. We are exploring the question of why DHCPv6 Prefix Delegation is not used on cellular links. This lack of PD support has bad side effects: an INFORMATIONAL RFC 64share becomes more and more used, Mobile Routers are impossible. Here are the unique reasons - if solely these are solved then we get PD on cellular: - some modems in the UE (e.g. QDSP6 and others) block standard DHCPv6 UDP port numbers 546 and 547 and (and sometimes or) standard IP multicast addressing in both directions; this blocking was identified by comparing packet dumps on the ARM part of UE, vs on PGW; this blocking was further confirmed by successful Sol/Adv on unicast and non-std UDP ports. This blocking happens even though the application processor (e.g. ARM) does not block them. These ports and multicast are absolutely needed for Prefix Delegation, because Prefix Delegation runs as an integral part of DHCPv6. - much less likely, it may be that some infrastructure entities like Base Station or SGW - again, very little probable - blocks same DHCP ports and multicast. - DHCPv6 software is little parametrable or portable, even though much source is available openly. Some details: - the DHCPv6 software on Android is hampered by the need of root access. Android blocks that. One needs to ask the platform manufacturer running that Android to "root" the platform such as to be able to run some of the DHCP client software (e.g. ask Huawei for a key to root the smartphone). That's a real pain. There is a risk of "bricking" your platform, i.e. through it out a window. - to make an app available to everyone on Android one must pay some money to become a member of a store. DHCP should not be part of that, as SLAAC isnt; just like SLAAC, DHCP should be builtin for free. - the DHCPv6 server software "ISC" breaks if the port numbers are non-standard (not 546 nor 547) or unicast instead of multicast. (e.g. "Discarding Solicit from [snip]; packet sent unicast") This was a real pain, because we had to modify the source code to allow it; other software like VoIP has SIP ports this configurable easily with a GUI. - Cisco parametering CLI of DHCPv6 service may have some problems in transforming a non-standard UDP port 546 of Solicit to a strange 26483. That was a real pain to one. - various DHCPv6 client software break, or do not even start, with any other src and dst UDP ports than the standard (546, 547) and/or non-standard unicast instead of standard multicast. Other reasons proved not to be causes of absence of DHCPv6 PD on cellular links; they were just speculations: - cellular operators dont provide DHCPv6 PD service (there are some who do under some operational conditions) - cellular operators have a hard time making an IPv6 addressing architecture that delegate prefixes instead of addresses (there are some who do make such architecture) - cellular operators only do '64' (it's false, some could do less, like 56 or even 48) - DHCPv6 software is not available on the client (there are some, like on Android, and more, see quoted mails below) - the computer that runs the DHCPv6 client is the same as the one that puts the Solicit on the wire: this is not true, because even in the smallest UE in the market there is still distinction app-vs-modem processors. Often the modem part is confidential, only the binary is available to the public, and there are two IPs on it: Internet Protocol _and_ Intellectual Property. Alex, with thanks to [Hachata], admin(s), managers, and technicals at offices and organisations. Le 18/08/2017 à 18:07, Alexandre Petrescu a écrit : > I have been pointed by a helpful person that an Android app for > DHCPv6 exists there: > > https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client&hl=fr > > > > > > It is based on the WIDE DHCPv6 client. > > Further browsing leads to a discussion of DHCPv6 on Android topic: > https://issuetracker.google.com/issues/36949085 > > Alex > > Le 17/07/2017 à 18:26, Alexandre Petrescu a écrit : >> Well, this is to note that we too (Fred mentioned it too earlier) >> made the ISC DHCPv6 dhclient work on Android, including DHCPv6 >> Solicit that requests Prefix Delegation. >> >> (but we still dont have a response to DHCP Solicit on cellular >> link). >> >> Alex >> >> Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit : >>> Mark, noted, will try. >>> >>> Just a note... >>> >>> Le 06/07/2017 à 03:16, Mark Andrews a écrit : >>>> >>>> In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, >>>> Alexandre Petrescu writes: >>>>> Hello, >>>>> >>>>> We discussed extensively about the potential use of DHCPv6 >>>>> Prefix Delegation on cellular links. >>>>> >>>>> The chicken issue is the lack of DHCPv6 PD software on >>>>> typical User Equipment. For example, there is no DHCPv6-PD >>>>> app on Android. The egg issue is the lack of operator >>>>> support of DHCPv6-PD towards the User Terminal. For example, >>>>> there is no cellular operator answering to DHCPv6-PD requests >>>>> issued by the User Terminal. >>>>> >>>>> To address the chicken issue, we started with an ISC DHCP >>>>> open software client, which does implement Prefix Delegation. >>>>> It can be (cross)compiled on various platforms; then type >>>>> "./dhclient -6 -P"; this sends an DHCPv6 Solicit Identity >>>>> Associtaion for Prefix Delegation message on the interface. >>>>> >>>>> However, whereas this software runs ok on interfaces such as >>>>> Ethernet, USBnet and WiFi interfaces, it breaks if run on the >>>>> cellular interface of some IoT cellular platform. The error >>>>> can be corrected by the quick-and-dirty solution below. >>>> >>>> The hack would be better as >>>> >>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; hw->hbuf[0] >>>> = HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>> #endif default: log_fatal("Unsupported device type %ld for >>>> \"%s\"", (long int)sa->sa_family, name); break; >>>> >>>> with ARPHRD_XXXX being replaced by the correct macro for 503 >>>> from . Something like that is at least >>>> portable. >>> >>> But it means when I go to other platform will have to modify >>> again the ISC client source code? >>> >>> In cellular terminals there are so many non-IEEE different kinds >>> of links. >>> >>> Other clients work out of the box on this - I agree with you, >>> strange - "rmnet0" interface. >>> >>> Alex >>> >>>> >>>> As for the rest of it I have no idea about the presented >>>> hardware address of this type so I don't know it the rest of it >>>> make sense. >>>> >>>>> Alex >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0." >>>>> dhcp-4.3.5 ./common/lpf.c line number: 551 >>>>> >>>>> //default: // log_fatal("Unsupported device type %ld >>>>> for \"%s\"", // (long int)sa->sa_family, >>>>> name); default: hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; >>>>> memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>>> >>>>> (two programmers worked this out). >>>>> >>>>> Alex >>>>> >>>>> _______________________________________________ v6ops >>>>> mailing list v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 5 08:40:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC7D132D54 for ; Tue, 5 Sep 2017 08:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 meJF9FaRBze1 for ; Tue, 5 Sep 2017 08:40:37 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CCF6132D69 for ; Tue, 5 Sep 2017 08:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1504626036; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gbbLOUUIznjXEqT9crSqisGHBOGLQBwahJizRGSj0IU=; b=XBLLVQrkadqO6QJ5A8CfY56OkeyVSvVKQ1IjgD02kfQGlqAcbiu+b6VDn0gMJJgq KPHlEixJHpaTNlKnaBaVATRe/BCnSos6/ADkV+LG/U6f7Gyn4kV3Qtv1coi/JIQk zPDa5qtRPPAb7D8GoMo2uzyiwR9IU49p9dUXMklYydlKEM8G12jSMGZwELN3V1Oc 2f7a68JvunyXOY5Cu8vausuowKuERwlT+sTx6ReZ3oWKFr4IWRacqREE134RnzWf ZPc4qa09oEx5cMkgb/7tOu6uE0RjWItgWcpr25YGw3AI23G2ZtTNYKvaVSAMlIMd aQncwrkXTTUP9uNiBh14dg==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 47.A8.28433.475CEA95; Tue, 5 Sep 2017 08:40:36 -0700 (PDT) X-AuditID: 11973e11-781ff70000006f11-e4-59aec574b08e Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay4.apple.com (Apple SCV relay) with SMTP id F3.0D.06992.475CEA95; Tue, 5 Sep 2017 08:40:36 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.100.237] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OVT00IS1CVNBW30@nwk-mmpp-sz11.apple.com>; Tue, 05 Sep 2017 08:40:36 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Tue, 05 Sep 2017 08:40:35 -0700 Cc: "draft-ietf-v6ops-rfc6555bis.all@ietf.org" , IPv6 Ops WG Message-id: References: To: Ron Bonica X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUi2FAYrltydF2kwa9nahY7Ftxltjjw3cHi 9LG9zA7MHkuW/GTyuN50lT2AKYrLJiU1J7MstUjfLoEr48CXR6wF05grDl/rZ2lg/MfYxcjJ ISFgIjG/9TVLFyMXh5DAaiaJsz9mM8MkJkx8BJU4xChx8+kusASvgKDEj8n3gBIcHMwC8hIH z8uChJkFtCS+P2qFqv/GKLF16TsmkBphAQmJzXsSQWqEBWQlrmx+C7aYTUBF4vi3DWAjOQWS JebeusQEYrMIqErMn3+fBWJmpcS/nZ1sEGttJGZ8mMAKMlJIIEni5rkokLAI0Ji1fyaBXSMB NH7pnxCQCyQEOtgkjiz6xjiBUXgWkqNnIRw9C8nRCxiZVzEK5SZm5uhm5hnpJRYU5KTqJefn bmIEBfd0O8EdjMdXWR1iFOBgVOLhnbBpXaQQa2JZcWXuIUZpDhYlcd4Vr9dGCgmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamCc8jdebM8iX/8d11vyYplsaoyWa6wzjbT1Xp7D2clUWHt+0Zon Cm3v21v7009Xru37mvPaRkD846a3vFfXlAWHTFvKpuVp0r7i0bQa3p8pDz84RDXnRs+a43f5 h2pac8HG/+v8F9y3WXx7V3L1Q4GEjdclrKxDPLM/TEt8tHeNpUqg4IPpB48osRRnJBpqMRcV JwIAbedXQU8CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FA8W7fk6LpIg70dShY7Ftxltjjw3cHi 9LG9zA7MHkuW/GTyuN50lT2AKYrLJiU1J7MstUjfLoEr48CXR6wF05grDl/rZ2lg/MfYxcjJ ISFgIjFh4iOWLkYuDiGBQ4wSN5/uYgZJ8AoISvyYfA8owcHBLCAvcfC8LEiYWUBL4vujVqj6 b4wSW5e+YwKpERaQkNi8JxGkRlhAVuLK5rdg89kEVCSOf9sANpJTIFli7q1LTCA2i4CqxPz5 91kgZlZK/NvZyQax1kZixocJrCAjhQSSJG6eiwIJiwCNWftnEtg1EkDjl/4JmcAoMAvJnbMQ 7pyF5M4FjMyrGAWKUnMSK030EgsKclL1kvNzNzGCg7EwfAfjv2VWhxgFOBiVeHgtNqyLFGJN LCuuzAUGBAezkgiv8j6gEG9KYmVValF+fFFpTmrxIUZpDhYlcV6xlCWRQgLpiSWp2ampBalF MFkmDk6pBsa1O/YqToty1/datTe2pfeyytqJ7bHnlFZ++peYI9uwd7buWes/HlUX6vvyLJ9t W1046/AxgctqlxxdAo6v3XW3Kqzt6q1F30Pcbzyr0D/VO+NB+Frhj8rbj4t9m2a+5u20za3J EW1ZCyeb/vh67faOu6dmpXzbIHV25ryaol8Gxy8obtiYe3jicyWW4oxEQy3mouJEAOI8B69C AgAA Archived-At: Subject: Re: [v6ops] IPR confirmation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 15:40:38 -0000 Hi Ron, I am not aware of any IPR for this draft. Thanks, Tommy > On Sep 5, 2017, at 8:38 AM, Ron Bonica wrote: > > Folks, > > Could each of the authors of draft-ietf-v6ops-rfc6555bis please respond to this message stating whether they know of any IPR associated with this draft? > > Ron > From nobody Tue Sep 5 09:02:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A43132D63; Tue, 5 Sep 2017 09:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 tWsQIFDb_xO5; Tue, 5 Sep 2017 09:02:20 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50100132D85; Tue, 5 Sep 2017 09:02:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v85G2HN6061308; Tue, 5 Sep 2017 09:02:17 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v85G282C061159 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 5 Sep 2017 09:02:08 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Sep 2017 09:02:07 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 5 Sep 2017 09:02:07 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: Warren Kumari , Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , The IESG Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTJcbyZ/JGPtSOiEKRi/iUYLBZ76KmYOMAgAB9b4D//49D8A== Date: Tue, 5 Sep 2017 16:02:07 +0000 Message-ID: <9bc87af662c845af8aae0e0b0317b452@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_9bc87af662c845af8aae0e0b0317b452XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 16:02:22 -0000 --_000_9bc87af662c845af8aae0e0b0317b452XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9yZW56bywNCg0KT24gc2hhcmVkIG1lZGlhLCB1bmxlc3MgdGhlcmUgaXMgc29tZSBmb3JtIG9m IEwyIHBhcnRpdGlvbmluZyBwZWVyLXRvLXBlZXIgaXMNCnBvc3NpYmxlIGV2ZW4gaWYgdGhlcmUg YXJlIG5vIFJlZGlyZWN0cy4gSSBjYW4gc2ltcGx5IGNhbGwgdXAgbXkgbmVpZ2hib3Igb24gdGhl DQpwaG9uZSBhbmQgYXNrIGZvciB0aGVpciBNQUMgYWRkcmVzcywgdGhlbiB3ZSBjYW4gZG8gcGVl ci10by1wZWVyIHdpdGhvdXQNCmV2ZW4gbmVlZGluZyBhbnkgY29vcmRpbmF0aW9uIHdpdGggdGhl IHJvdXRlci4NCg0KU28sIHRoZSBkb2N1bWVudCBlaXRoZXIgbmVlZHMgdG8gdGFsayBhYm91dCBM MiBwYXJ0aXRpb25pbmcgb3IgYWNrbm93bGVkZ2UNCnRoYXQgKG9uIHNvbWUgbGluayB0eXBlcykg cGVlci10by1wZWVyIGlzIGluZXZpdGFibGUuIEkgcHJlZmVyIHRoZSBsYXR0ZXIgYmVjYXVzZQ0K cGVlci10by1wZWVyIHByb3ZpZGVzIGEgbmVjZXNzYXJ5IG9wdGltaXphdGlvbiBvbiBzb21lIGxp bmsgdHlwZXMuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWls dG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDA1LCAyMDE3 IDg6MTkgQU0NClRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+ DQpDYzogV2FycmVuIEt1bWFyaSA8d2FycmVuQGt1bWFyaS5uZXQ+OyBTdXJlc2ggS3Jpc2huYW4g PHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+OyB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi12 Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdjZv cHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LmFsbEBpZXRmLm9yZzsgdjZvcHMtY2hhaXJz QGlldGYub3JnOyBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8Z3Vu dGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbdjZvcHNdIFN1cmVzaCBLcmlzaG5hbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0 Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDc6ICh3aXRoIERJU0NVU1MgYW5k IENPTU1FTlQpDQoNCk9uIFR1ZSwgU2VwIDUsIDIwMTcgYXQgMTE6NTIgUE0sIFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4+IHdyb3RlOg0KUGxlYXNlIGNoYW5nZSB0byBzYXk6DQoNCiAgICAibyAgVHdvIGRl dmljZXMgKHN1YnNjcmliZXIvaG9zdHMpLCBib3RoIGF0dGFjaGVkIHRvIHRoZSBzYW1lIHByb3Zp ZGVyDQogICAgICAgbWFuYWdlZCBzaGFyZWQgbmV0d29yayBzaG91bGQgb25seSBiZSBhYmxlIHRv IGNvbW11bmljYXRlIHRocm91Z2gNCiAgICAgICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBI b3AgUm91dGVyIHVubGVzcyB0aGUgc2hhcmVkIG5ldHdvcmsNCiAgICAgICBleHBsaWNpdGx5IHBl cm1pdHMgcGVlci10by1wZWVyIG9wZXJhdGlvbnMiDQoNCkFJVUkgdGhpcyBvcGluaW9uIGlzIGlu IHRoZSByb3VnaC4NCg== --_000_9bc87af662c845af8aae0e0b0317b452XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkxvcmVuem8sPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbiBzaGFyZWQgbWVkaWEsIHVubGVzcyB0aGVyZSBp cyBzb21lIGZvcm0gb2YgTDIgcGFydGl0aW9uaW5nIHBlZXItdG8tcGVlciBpczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5wb3NzaWJsZSBldmVuIGlmIHRoZXJlIGFyZSBubyBSZWRpcmVjdHMuIEkgY2FuIHNp bXBseSBjYWxsIHVwIG15IG5laWdoYm9yIG9uIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5waG9uZSBh bmQgYXNrIGZvciB0aGVpciBNQUMgYWRkcmVzcywgdGhlbiB3ZSBjYW4gZG8gcGVlci10by1wZWVy IHdpdGhvdXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZXZlbiBuZWVkaW5nIGFueSBjb29yZGluYXRpb24g d2l0aCB0aGUgcm91dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+U28sIHRoZSBkb2N1bWVudCBlaXRoZXIgbmVlZHMgdG8gdGFsayBhYm91dCBMMiBwYXJ0aXRp b25pbmcgb3IgYWNrbm93bGVkZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhhdCAob24gc29tZSBsaW5r IHR5cGVzKSBwZWVyLXRvLXBlZXIgaXMgaW5ldml0YWJsZS4gSSBwcmVmZXIgdGhlIGxhdHRlciBi ZWNhdXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnBlZXItdG8tcGVlciBwcm92aWRlcyBhIG5lY2Vzc2Fy eSBvcHRpbWl6YXRpb24gb24gc29tZSBsaW5rIHR5cGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZA0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTG9yZW56byBD b2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIFNlcHRlbWJlciAwNSwgMjAxNyA4OjE5IEFNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGlu LCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBXYXJyZW4gS3VtYXJpICZsdDt3YXJyZW5Aa3VtYXJpLm5ldCZndDs7IFN1cmVzaCBLcmlzaG5h biAmbHQ7c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNvbSZndDs7IHY2b3BzQGlldGYub3JnOyBkcmFm dC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdEBpZXRmLm9yZzsgZHJhZnQt aWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QuYWxsQGlldGYub3JnOyB2Nm9w cy1jaGFpcnNAaWV0Zi5vcmc7IFZhbiBEZSBWZWxkZSwNCiBHdW50ZXIgKE5va2lhIC0gQkUvQW50 d2VycCkgJmx0O2d1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tJmd0OzsgVGhlIElFU0cgJmx0 O2llc2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIFN1cmVz aCBLcmlzaG5hbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVm aXgtcGVyLWhvc3QtMDc6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VHVlLCBTZXAgNSwgMjAxNyBhdCAxMTo1MiBQTSwgVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVm PSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQu TC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgY2hhbmdlIHRvIHNheTo8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7ICZxdW90O28mbmJzcDsgVHdvIGRldmljZXMgKHN1YnNjcmliZXIv aG9zdHMpLCBib3RoIGF0dGFjaGVkIHRvIHRoZSBzYW1lIHByb3ZpZGVyPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7bWFuYWdlZCBzaGFyZWQgbmV0d29yayBzaG91bGQgb25seSBiZSBh YmxlIHRvIGNvbW11bmljYXRlIHRocm91Z2g8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVyIHVubGVzcyB0aGUgc2hhcmVk IG5ldHdvcms8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtleHBsaWNpdGx5IHBlcm1p dHMgcGVlci10by1wZWVyIG9wZXJhdGlvbnMmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFJVUkgdGhpcyBvcGluaW9uIGlz IGluIHRoZSByb3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9bc87af662c845af8aae0e0b0317b452XCH150608nwnosboeingcom_-- From nobody Tue Sep 5 09:06:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88611132D77 for ; Tue, 5 Sep 2017 09:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73FUEoQ704hr for ; Tue, 5 Sep 2017 09:06:48 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45DF6132D76 for ; Tue, 5 Sep 2017 09:06:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v85G6ldA023811; Tue, 5 Sep 2017 09:06:47 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v85G6gaK023774 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 5 Sep 2017 09:06:42 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (137.136.238.222) by XCH15-06-09.nw.nos.boeing.com (137.136.239.172) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Sep 2017 09:06:41 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 5 Sep 2017 09:06:41 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] DHCPv6 PD client on cellular on Android Thread-Index: AQHTJl1GQaHk8JRqwk2mcUUbqG/ToKKmdHgQ Date: Tue, 5 Sep 2017 16:06:41 +0000 Message-ID: <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 16:06:50 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyBb bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUgUGV0 cmVzY3UNCj4gU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDA1LCAyMDE3IDg6MzkgQU0NCj4gVG86 IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIERIQ1B2NiBQRCBjbGllbnQg b24gY2VsbHVsYXIgb24gQW5kcm9pZA0KPiANCj4gSGksDQo+IA0KPiBJIHdhbnQgdG8gdXBkYXRl IHRoZSBsaXN0IGFib3V0IG91ciBhZHZhbmNlbWVudHMuDQo+IA0KPiBXZSBhcmUgZXhwbG9yaW5n IHRoZSBxdWVzdGlvbiBvZiB3aHkgREhDUHY2IFByZWZpeCBEZWxlZ2F0aW9uIGlzIG5vdA0KPiB1 c2VkIG9uIGNlbGx1bGFyIGxpbmtzLiAgVGhpcyBsYWNrIG9mIFBEIHN1cHBvcnQgaGFzIGJhZCBz aWRlIGVmZmVjdHM6DQo+IGFuIElORk9STUFUSU9OQUwgUkZDIDY0c2hhcmUgYmVjb21lcyBtb3Jl IGFuZCBtb3JlIHVzZWQsIE1vYmlsZSBSb3V0ZXJzDQo+IGFyZSBpbXBvc3NpYmxlLg0KPiANCj4g SGVyZSBhcmUgdGhlIHVuaXF1ZSByZWFzb25zIC0gaWYgc29sZWx5IHRoZXNlIGFyZSBzb2x2ZWQg dGhlbiB3ZSBnZXQgUEQNCj4gb24gY2VsbHVsYXI6DQo+IC0gc29tZSBtb2RlbXMgaW4gdGhlIFVF IChlLmcuIFFEU1A2IGFuZCBvdGhlcnMpIGJsb2NrIHN0YW5kYXJkIERIQ1B2Ng0KPiAgICBVRFAg cG9ydCBudW1iZXJzIDU0NiBhbmQgNTQ3IGFuZCAoYW5kIHNvbWV0aW1lcyBvcikgc3RhbmRhcmQg SVANCj4gICAgbXVsdGljYXN0IGFkZHJlc3NpbmcgaW4gYm90aCBkaXJlY3Rpb25zOyB0aGlzIGJs b2NraW5nIHdhcyBpZGVudGlmaWVkDQo+ICAgIGJ5IGNvbXBhcmluZyBwYWNrZXQgZHVtcHMgb24g dGhlIEFSTSBwYXJ0IG9mIFVFLCB2cyBvbiBQR1c7DQo+ICAgIHRoaXMgYmxvY2tpbmcgd2FzIGZ1 cnRoZXIgY29uZmlybWVkIGJ5IHN1Y2Nlc3NmdWwgU29sL0FkdiBvbiB1bmljYXN0DQo+ICAgIGFu ZCBub24tc3RkIFVEUCBwb3J0cy4NCj4gICAgVGhpcyBibG9ja2luZyBoYXBwZW5zIGV2ZW4gdGhv dWdoIHRoZSBhcHBsaWNhdGlvbiBwcm9jZXNzb3IgKGUuZy4gQVJNKQ0KPiAgICBkb2VzIG5vdCBi bG9jayB0aGVtLg0KPiAgICBUaGVzZSBwb3J0cyBhbmQgbXVsdGljYXN0IGFyZSBhYnNvbHV0ZWx5 IG5lZWRlZCBmb3IgUHJlZml4IERlbGVnYXRpb24sDQo+ICAgIGJlY2F1c2UgUHJlZml4IERlbGVn YXRpb24gcnVucyBhcyBhbiBpbnRlZ3JhbCBwYXJ0IG9mIERIQ1B2Ni4NCj4gLSBtdWNoIGxlc3Mg bGlrZWx5LCBpdCBtYXkgYmUgdGhhdCBzb21lIGluZnJhc3RydWN0dXJlIGVudGl0aWVzIGxpa2UN Cj4gICAgQmFzZSBTdGF0aW9uIG9yIFNHVyAtIGFnYWluLCB2ZXJ5IGxpdHRsZSBwcm9iYWJsZSAt IGJsb2NrcyBzYW1lIERIQ1ANCj4gICAgcG9ydHMgYW5kIG11bHRpY2FzdC4NCj4gLSBESENQdjYg c29mdHdhcmUgaXMgbGl0dGxlIHBhcmFtZXRyYWJsZSBvciBwb3J0YWJsZSwgZXZlbiB0aG91Z2gg bXVjaA0KPiAgICBzb3VyY2UgaXMgYXZhaWxhYmxlIG9wZW5seS4NCj4gDQo+IFNvbWUgZGV0YWls czoNCj4gLSB0aGUgREhDUHY2IHNvZnR3YXJlIG9uIEFuZHJvaWQgaXMgaGFtcGVyZWQgYnkgdGhl IG5lZWQgb2Ygcm9vdCBhY2Nlc3MuDQo+ICAgIEFuZHJvaWQgYmxvY2tzIHRoYXQuICBPbmUgbmVl ZHMgdG8gYXNrIHRoZSBwbGF0Zm9ybSBtYW51ZmFjdHVyZXINCj4gICAgcnVubmluZyB0aGF0IEFu ZHJvaWQgdG8gInJvb3QiIHRoZSBwbGF0Zm9ybSBzdWNoIGFzIHRvIGJlIGFibGUgdG8gcnVuDQo+ ICAgIHNvbWUgb2YgdGhlIERIQ1AgY2xpZW50IHNvZnR3YXJlIChlLmcuIGFzayBIdWF3ZWkgZm9y IGEga2V5IHRvIHJvb3QNCj4gICAgdGhlIHNtYXJ0cGhvbmUpLiAgVGhhdCdzIGEgcmVhbCBwYWlu LiAgVGhlcmUgaXMgYSByaXNrIG9mICJicmlja2luZyINCj4gICAgeW91ciBwbGF0Zm9ybSwgaS5l LiB0aHJvdWdoIGl0IG91dCBhIHdpbmRvdy4NCg0KWW91IGRvbid0IG5lZWQgdG8gcm9vdCB0aGUg ZGV2aWNlIHRvIHJ1biBESENQdjYgUEQgb3ZlciBhIFZQTjogDQoNCmh0dHBzOi8vZGV2ZWxvcGVy LmFuZHJvaWQuY29tL3JlZmVyZW5jZS9hbmRyb2lkL25ldC9WcG5TZXJ2aWNlLmh0bWwNCg0KQWdh aW4sIHdlIGhhdmUgREhDUHY2IFBEIHdvcmtpbmcgZmluZSBvdmVyIGEgVlBOLg0KDQpUaGFua3Mg LSBGcmVkDQoNCj4gLSB0byBtYWtlIGFuIGFwcCBhdmFpbGFibGUgdG8gZXZlcnlvbmUgb24gQW5k cm9pZCBvbmUgbXVzdCBwYXkgc29tZQ0KPiAgICBtb25leSB0byBiZWNvbWUgYSBtZW1iZXIgb2Yg YSBzdG9yZS4gIERIQ1Agc2hvdWxkIG5vdCBiZSBwYXJ0IG9mIHRoYXQsDQo+ICAgIGFzIFNMQUFD IGlzbnQ7IGp1c3QgbGlrZSBTTEFBQywgREhDUCBzaG91bGQgYmUgYnVpbHRpbiBmb3IgZnJlZS4N Cj4gLSB0aGUgREhDUHY2IHNlcnZlciBzb2Z0d2FyZSAiSVNDIiBicmVha3MgaWYgdGhlIHBvcnQg bnVtYmVycyBhcmUNCj4gICAgbm9uLXN0YW5kYXJkIChub3QgNTQ2IG5vciA1NDcpIG9yIHVuaWNh c3QgaW5zdGVhZCBvZiBtdWx0aWNhc3QuDQo+ICAgIChlLmcuICJEaXNjYXJkaW5nIFNvbGljaXQg ZnJvbSBbc25pcF07IHBhY2tldCBzZW50IHVuaWNhc3QiKQ0KPiAgICBUaGlzIHdhcyBhIHJlYWwg cGFpbiwgYmVjYXVzZSB3ZSBoYWQgdG8gbW9kaWZ5IHRoZSBzb3VyY2UgY29kZQ0KPiAgICB0byBh bGxvdyBpdDsgb3RoZXIgc29mdHdhcmUgbGlrZSBWb0lQIGhhcyBTSVAgcG9ydHMgdGhpcyBjb25m aWd1cmFibGUNCj4gICAgZWFzaWx5IHdpdGggYSBHVUkuDQo+IC0gQ2lzY28gcGFyYW1ldGVyaW5n IENMSSBvZiBESENQdjYgc2VydmljZSBtYXkgaGF2ZSBzb21lIHByb2JsZW1zIGluDQo+ICAgIHRy YW5zZm9ybWluZyBhIG5vbi1zdGFuZGFyZCBVRFAgcG9ydCA1NDYgb2YgU29saWNpdCB0byBhIHN0 cmFuZ2UNCj4gICAgMjY0ODMuICBUaGF0IHdhcyBhIHJlYWwgcGFpbiB0byBvbmUuDQo+IC0gdmFy aW91cyBESENQdjYgY2xpZW50IHNvZnR3YXJlIGJyZWFrLCBvciBkbyBub3QgZXZlbiBzdGFydCwg d2l0aA0KPiAgICBhbnkgb3RoZXIgc3JjIGFuZCBkc3QgVURQIHBvcnRzIHRoYW4gdGhlIHN0YW5k YXJkICg1NDYsIDU0NykNCj4gICAgYW5kL29yIG5vbi1zdGFuZGFyZCB1bmljYXN0IGluc3RlYWQg b2Ygc3RhbmRhcmQgbXVsdGljYXN0Lg0KPiANCj4gT3RoZXIgcmVhc29ucyBwcm92ZWQgbm90IHRv IGJlIGNhdXNlcyBvZiBhYnNlbmNlIG9mIERIQ1B2NiBQRCBvbg0KPiBjZWxsdWxhciBsaW5rczsg dGhleSB3ZXJlIGp1c3Qgc3BlY3VsYXRpb25zOg0KPiAtIGNlbGx1bGFyIG9wZXJhdG9ycyBkb250 IHByb3ZpZGUgREhDUHY2IFBEIHNlcnZpY2UgKHRoZXJlIGFyZSBzb21lIHdobw0KPiAgICBkbyB1 bmRlciBzb21lIG9wZXJhdGlvbmFsIGNvbmRpdGlvbnMpDQo+IC0gY2VsbHVsYXIgb3BlcmF0b3Jz IGhhdmUgYSBoYXJkIHRpbWUgbWFraW5nIGFuIElQdjYgYWRkcmVzc2luZw0KPiAgICBhcmNoaXRl Y3R1cmUgdGhhdCBkZWxlZ2F0ZSBwcmVmaXhlcyBpbnN0ZWFkIG9mIGFkZHJlc3NlcyAodGhlcmUg YXJlDQo+ICAgIHNvbWUgd2hvIGRvIG1ha2Ugc3VjaCBhcmNoaXRlY3R1cmUpDQo+IC0gY2VsbHVs YXIgb3BlcmF0b3JzIG9ubHkgZG8gJzY0JyAoaXQncyBmYWxzZSwgc29tZSBjb3VsZCBkbyBsZXNz LA0KPiAgICBsaWtlIDU2IG9yIGV2ZW4gNDgpDQo+IC0gREhDUHY2IHNvZnR3YXJlIGlzIG5vdCBh dmFpbGFibGUgb24gdGhlIGNsaWVudCAodGhlcmUgYXJlIHNvbWUsIGxpa2UNCj4gICAgb24gQW5k cm9pZCwgYW5kIG1vcmUsIHNlZSBxdW90ZWQgbWFpbHMgYmVsb3cpDQo+IC0gdGhlIGNvbXB1dGVy IHRoYXQgcnVucyB0aGUgREhDUHY2IGNsaWVudCBpcyB0aGUgc2FtZSBhcyB0aGUgb25lIHRoYXQN Cj4gICAgcHV0cyB0aGUgU29saWNpdCBvbiB0aGUgd2lyZTogdGhpcyBpcyBub3QgdHJ1ZSwgYmVj YXVzZSBldmVuIGluIHRoZQ0KPiAgICBzbWFsbGVzdCBVRSBpbiB0aGUgbWFya2V0IHRoZXJlIGlz IHN0aWxsIGRpc3RpbmN0aW9uIGFwcC12cy1tb2RlbQ0KPiAgICBwcm9jZXNzb3JzLiAgT2Z0ZW4g dGhlIG1vZGVtIHBhcnQgaXMgY29uZmlkZW50aWFsLCBvbmx5IHRoZSBiaW5hcnkNCj4gICAgaXMg YXZhaWxhYmxlIHRvIHRoZSBwdWJsaWMsIGFuZCB0aGVyZSBhcmUgdHdvIElQcyBvbiBpdDogSW50 ZXJuZXQNCj4gICAgUHJvdG9jb2wgX2FuZF8gSW50ZWxsZWN0dWFsIFByb3BlcnR5Lg0KPiANCj4g QWxleCwgd2l0aCB0aGFua3MgdG8gW0hhY2hhdGFdLCBhZG1pbihzKSwgbWFuYWdlcnMsIGFuZCB0 ZWNobmljYWxzIGF0DQo+IG9mZmljZXMgYW5kIG9yZ2FuaXNhdGlvbnMuDQo+IA0KPiANCj4gTGUg MTgvMDgvMjAxNyDDoCAxODowNywgQWxleGFuZHJlIFBldHJlc2N1IGEgw6ljcml0IDoNCj4gPiBJ IGhhdmUgYmVlbiBwb2ludGVkIGJ5IGEgaGVscGZ1bCBwZXJzb24gdGhhdCBhbiBBbmRyb2lkIGFw cCBmb3INCj4gPiBESENQdjYgZXhpc3RzIHRoZXJlOg0KPiA+DQo+ID4gaHR0cHM6Ly9wbGF5Lmdv b2dsZS5jb20vc3RvcmUvYXBwcy9kZXRhaWxzP2lkPW9yZy5kYWR1a2UucmVhbG1hci5kaGNwdjZj bGllbnQmaGw9ZnINCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gSXQgaXMgYmFzZWQgb24g dGhlIFdJREUgREhDUHY2IGNsaWVudC4NCj4gPg0KPiA+IEZ1cnRoZXIgYnJvd3NpbmcgbGVhZHMg dG8gYSBkaXNjdXNzaW9uIG9mIERIQ1B2NiBvbiBBbmRyb2lkIHRvcGljOg0KPiA+IGh0dHBzOi8v aXNzdWV0cmFja2VyLmdvb2dsZS5jb20vaXNzdWVzLzM2OTQ5MDg1DQo+ID4NCj4gPiBBbGV4DQo+ ID4NCj4gPiBMZSAxNy8wNy8yMDE3IMOgIDE4OjI2LCBBbGV4YW5kcmUgUGV0cmVzY3UgYSDDqWNy aXQgOg0KPiA+PiBXZWxsLCB0aGlzIGlzIHRvIG5vdGUgdGhhdCB3ZSB0b28gKEZyZWQgbWVudGlv bmVkIGl0IHRvbyBlYXJsaWVyKQ0KPiA+PiBtYWRlIHRoZSBJU0MgREhDUHY2IGRoY2xpZW50IHdv cmsgb24gQW5kcm9pZCwgaW5jbHVkaW5nIERIQ1B2Ng0KPiA+PiBTb2xpY2l0IHRoYXQgcmVxdWVz dHMgUHJlZml4IERlbGVnYXRpb24uDQo+ID4+DQo+ID4+IChidXQgd2Ugc3RpbGwgZG9udCBoYXZl IGEgcmVzcG9uc2UgdG8gREhDUCBTb2xpY2l0IG9uIGNlbGx1bGFyDQo+ID4+IGxpbmspLg0KPiA+ Pg0KPiA+PiBBbGV4DQo+ID4+DQo+ID4+IExlIDA2LzA3LzIwMTcgw6AgMTg6MzIsIEFsZXhhbmRy ZSBQZXRyZXNjdSBhIMOpY3JpdCA6DQo+ID4+PiBNYXJrLCBub3RlZCwgd2lsbCB0cnkuDQo+ID4+ Pg0KPiA+Pj4gSnVzdCBhIG5vdGUuLi4NCj4gPj4+DQo+ID4+PiBMZSAwNi8wNy8yMDE3IMOgIDAz OjE2LCBNYXJrIEFuZHJld3MgYSDDqWNyaXQgOg0KPiA+Pj4+DQo+ID4+Pj4gSW4gbWVzc2FnZSA8 NzUzN2RlZWYtOGY4Ny01MTg3LTFlNDQtNTk1YWM2M2ExNmNhQGdtYWlsLmNvbT4sDQo+ID4+Pj4g QWxleGFuZHJlIFBldHJlc2N1IHdyaXRlczoNCj4gPj4+Pj4gSGVsbG8sDQo+ID4+Pj4+DQo+ID4+ Pj4+IFdlIGRpc2N1c3NlZCBleHRlbnNpdmVseSBhYm91dCB0aGUgcG90ZW50aWFsIHVzZSBvZiBE SENQdjYNCj4gPj4+Pj4gUHJlZml4IERlbGVnYXRpb24gb24gY2VsbHVsYXIgbGlua3MuDQo+ID4+ Pj4+DQo+ID4+Pj4+IFRoZSBjaGlja2VuIGlzc3VlIGlzIHRoZSBsYWNrIG9mIERIQ1B2NiBQRCBz b2Z0d2FyZSBvbg0KPiA+Pj4+PiB0eXBpY2FsIFVzZXIgRXF1aXBtZW50LiAgRm9yIGV4YW1wbGUs IHRoZXJlIGlzIG5vIERIQ1B2Ni1QRA0KPiA+Pj4+PiBhcHAgb24gQW5kcm9pZC4gIFRoZSBlZ2cg aXNzdWUgaXMgdGhlIGxhY2sgb2Ygb3BlcmF0b3INCj4gPj4+Pj4gc3VwcG9ydCBvZiBESENQdjYt UEQgdG93YXJkcyB0aGUgVXNlciBUZXJtaW5hbC4gIEZvciBleGFtcGxlLA0KPiA+Pj4+PiB0aGVy ZSBpcyBubyBjZWxsdWxhciBvcGVyYXRvciBhbnN3ZXJpbmcgdG8gREhDUHY2LVBEIHJlcXVlc3Rz DQo+ID4+Pj4+IGlzc3VlZCBieSB0aGUgVXNlciBUZXJtaW5hbC4NCj4gPj4+Pj4NCj4gPj4+Pj4g VG8gYWRkcmVzcyB0aGUgY2hpY2tlbiBpc3N1ZSwgd2Ugc3RhcnRlZCB3aXRoIGFuIElTQyBESENQ DQo+ID4+Pj4+IG9wZW4gc29mdHdhcmUgY2xpZW50LCB3aGljaCBkb2VzIGltcGxlbWVudCBQcmVm aXggRGVsZWdhdGlvbi4NCj4gPj4+Pj4gSXQgY2FuIGJlIChjcm9zcyljb21waWxlZCBvbiB2YXJp b3VzIHBsYXRmb3JtczsgdGhlbiB0eXBlDQo+ID4+Pj4+ICIuL2RoY2xpZW50IC02IC1QIjsgdGhp cyBzZW5kcyBhbiBESENQdjYgU29saWNpdCBJZGVudGl0eQ0KPiA+Pj4+PiBBc3NvY2l0YWlvbiBm b3IgUHJlZml4IERlbGVnYXRpb24gbWVzc2FnZSBvbiB0aGUgaW50ZXJmYWNlLg0KPiA+Pj4+Pg0K PiA+Pj4+PiBIb3dldmVyLCB3aGVyZWFzIHRoaXMgc29mdHdhcmUgcnVucyBvayBvbiBpbnRlcmZh Y2VzIHN1Y2ggYXMNCj4gPj4+Pj4gRXRoZXJuZXQsIFVTQm5ldCBhbmQgV2lGaSBpbnRlcmZhY2Vz LCBpdCBicmVha3MgaWYgcnVuIG9uIHRoZQ0KPiA+Pj4+PiBjZWxsdWxhciBpbnRlcmZhY2Ugb2Yg c29tZSBJb1QgY2VsbHVsYXIgcGxhdGZvcm0uICBUaGUgZXJyb3INCj4gPj4+Pj4gY2FuIGJlIGNv cnJlY3RlZCBieSB0aGUgcXVpY2stYW5kLWRpcnR5IHNvbHV0aW9uIGJlbG93Lg0KPiA+Pj4+DQo+ ID4+Pj4gVGhlIGhhY2sgd291bGQgYmUgYmV0dGVyIGFzDQo+ID4+Pj4NCj4gPj4+PiAjaWZkZWYg QVJQSFJEX1hYWFggY2FzZSBBUlBIUkRfWFhYWDogaHctPmhsZW4gPSA3OyBody0+aGJ1ZlswXQ0K PiA+Pj4+ICA9IEhUWVBFX0VUSEVSOyBtZW1jcHkoJmh3LT5oYnVmWzFdLCBzYS0+c2FfZGF0YSwg Nik7IGJyZWFrOw0KPiA+Pj4+ICNlbmRpZiBkZWZhdWx0OiBsb2dfZmF0YWwoIlVuc3VwcG9ydGVk IGRldmljZSB0eXBlICVsZCBmb3INCj4gPj4+PiBcIiVzXCIiLCAobG9uZyBpbnQpc2EtPnNhX2Zh bWlseSwgbmFtZSk7IGJyZWFrOw0KPiA+Pj4+DQo+ID4+Pj4gd2l0aCBBUlBIUkRfWFhYWCBiZWlu ZyByZXBsYWNlZCBieSB0aGUgY29ycmVjdCBtYWNybyBmb3IgNTAzDQo+ID4+Pj4gZnJvbSA8bmV0 L2lmX2FycC5oPi4gIFNvbWV0aGluZyBsaWtlIHRoYXQgaXMgYXQgbGVhc3QNCj4gPj4+PiBwb3J0 YWJsZS4NCj4gPj4+DQo+ID4+PiBCdXQgaXQgbWVhbnMgd2hlbiBJIGdvIHRvIG90aGVyIHBsYXRm b3JtIHdpbGwgaGF2ZSB0byBtb2RpZnkNCj4gPj4+IGFnYWluIHRoZSBJU0MgY2xpZW50IHNvdXJj ZSBjb2RlPw0KPiA+Pj4NCj4gPj4+IEluIGNlbGx1bGFyIHRlcm1pbmFscyB0aGVyZSBhcmUgc28g bWFueSBub24tSUVFRSBkaWZmZXJlbnQga2luZHMNCj4gPj4+ICBvZiBsaW5rcy4NCj4gPj4+DQo+ ID4+PiBPdGhlciBjbGllbnRzIHdvcmsgb3V0IG9mIHRoZSBib3ggb24gdGhpcyAtIEkgYWdyZWUg d2l0aCB5b3UsDQo+ID4+PiBzdHJhbmdlIC0gInJtbmV0MCIgaW50ZXJmYWNlLg0KPiA+Pj4NCj4g Pj4+IEFsZXgNCj4gPj4+DQo+ID4+Pj4NCj4gPj4+PiBBcyBmb3IgdGhlIHJlc3Qgb2YgaXQgSSBo YXZlIG5vIGlkZWEgYWJvdXQgdGhlIHByZXNlbnRlZA0KPiA+Pj4+IGhhcmR3YXJlIGFkZHJlc3Mg b2YgdGhpcyB0eXBlIHNvIEkgZG9uJ3Qga25vdyBpdCB0aGUgcmVzdCBvZiBpdA0KPiA+Pj4+IG1h a2Ugc2Vuc2UuDQo+ID4+Pj4NCj4gPj4+Pj4gQWxleA0KPiA+Pj4+Pg0KPiA+Pj4+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4g Pj4+Pj4NCj4gPj4gVGhlIGVycm9yIHNheXMgIi8vVU5TVVBQT1JURUQgREVWSUNFIFRZUEUgNTAz IEZPUiBSTU5FVDAuIg0KPiA+Pj4+PiBkaGNwLTQuMy41IC4vY29tbW9uL2xwZi5jIGxpbmUgbnVt YmVyOiA1NTENCj4gPj4+Pj4NCj4gPj4+Pj4gLy9kZWZhdWx0OiAvLyAgICAgIGxvZ19mYXRhbCgi VW5zdXBwb3J0ZWQgZGV2aWNlIHR5cGUgJWxkDQo+ID4+Pj4+IGZvciBcIiVzXCIiLCAvLyAgICAg ICAgICAgICAgICAobG9uZyBpbnQpc2EtPnNhX2ZhbWlseSwNCj4gPj4+Pj4gbmFtZSk7IGRlZmF1 bHQ6IGh3LT5obGVuID0gNzsgaHctPmhidWZbMF0gPSBIVFlQRV9FVEhFUjsNCj4gPj4+Pj4gbWVt Y3B5KCZody0+aGJ1ZlsxXSwgc2EtPnNhX2RhdGEsIDYpOyBicmVhazsNCj4gPj4+Pj4NCj4gPj4+ Pj4gKHR3byBwcm9ncmFtbWVycyB3b3JrZWQgdGhpcyBvdXQpLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBB bGV4DQo+ID4+Pj4+DQo+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fIHY2b3BzDQo+ID4+Pj4+IG1haWxpbmcgbGlzdCB2Nm9wc0BpZXRmLm9yZw0K PiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4+ Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g djZvcHMgbWFpbGluZw0KPiA+Pj4gbGlzdCB2Nm9wc0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+PiB2 Nm9wc0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPiB2Nm9wc0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Tue Sep 5 09:30:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FB4132D6F for ; Tue, 5 Sep 2017 09:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 MMkRyofLkU9o for ; Tue, 5 Sep 2017 09:30:05 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23FF9132D86 for ; Tue, 5 Sep 2017 09:30:03 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id j141so14413831ioj.4 for ; Tue, 05 Sep 2017 09:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YNDHl67/VzebNGPuIovvZcwMRIlJml+qluoh60WF5Jo=; b=FHOg2clfpeO6I3YdixN2juAiE8JzY5xiIMoq1nZ+h7Wg3IzsQQRrUXlZj7hm4SkvBB zdLAUAEhjyr9oYl9qfnDj5G9tbioyng8HxKRIMjpvvQJQzmmItLywvCAbCUlVZWXMaZR H8S4djRFmvjEUR1H7qUTKiLjQHr1MFvw16U0jsKWZFdzd+ybQZkm35Dqsn+4JF9y842x gxPUAEn4mdx9HD92FUYscxCf2j7pTxEYvsTFp0fhW7HVDFAWnYYjaDp5KQRHENIeyE+i ZTj+fN3f4sBaORaELtEWB1WwA0gr8mW2WAUiA73IiRTzzQz6IHwtwTXGh05TkORUS7I5 teLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YNDHl67/VzebNGPuIovvZcwMRIlJml+qluoh60WF5Jo=; b=mC9jXOfznZop1PKJBE0yz/HDqm9HClnR8rbu6/hoa1QY6N4KTB+5EchtURcnF5zR9c dLTHShVbwfvYfulmePq9ksOVPIVa4zowtbt1hQFgQEMihaQjjiUuK0EaQkLBuZFs8xhY CW4/16NRzCj9umfEFmckr063JbCyBZclmetRTLUE/WOqlk+uNWVpZlFw5W1wp4UzliAP uqMy1SNEVpYP0KCgcj78OCvvL8HFmkRmbkgteQk/e8O2/rjgh7djtlwPwTXVQdeohnf9 4cD8Umwlu17Ui+91z+MREsY5wwI3nZy6AlYSw0S8xFOhXO04UA8uV42sZZfaF+h4ZuGi A9dg== X-Gm-Message-State: AHPjjUilOPPPmtFy20zcS8tIEevOsUSCW0rPk5fG1jUC/OcYzqmOwVWT GsYDVmHXeI1yexnZK7/ou97GcreIUFVh X-Google-Smtp-Source: ADKCNb5D1aPyO32AjA7Ut0OgaJ9szWLJ4voNzLsmhLzkAgDyNOsYq1skRwBEMoje+jCrWCuaSxEF31whTs9G8bD7wDM= X-Received: by 10.36.26.129 with SMTP id 123mr2040345iti.38.1504629002040; Tue, 05 Sep 2017 09:30:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.11 with HTTP; Tue, 5 Sep 2017 09:29:41 -0700 (PDT) In-Reply-To: <9bc87af662c845af8aae0e0b0317b452@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <9bc87af662c845af8aae0e0b0317b452@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Wed, 6 Sep 2017 01:29:41 +0900 Message-ID: To: "Templin, Fred L" Cc: Warren Kumari , Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , The IESG Content-Type: multipart/alternative; boundary="001a114463ec2fe3c3055873bd84" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 16:30:06 -0000 --001a114463ec2fe3c3055873bd84 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 6, 2017 at 1:02 AM, Templin, Fred L wrote: > So, the document either needs to talk about L2 partitioning or acknowledge > > that (on some link types) peer-to-peer is inevitable. I prefer the latter > because > > peer-to-peer provides a necessary optimization on some link types. > Partitioning is in the applicability statement. --001a114463ec2fe3c3055873bd84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 6, 2017 at 1:02 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:

So, the document either needs to talk about = L2 partitioning or acknowledge

that (on some link types) peer-to-pee= r is inevitable. I prefer the latter because

peer-to-peer provides a necessary opt= imization on some link types.


<= /div>
Partitioning is in the applicability statement.=C2=A0
=
--001a114463ec2fe3c3055873bd84-- From nobody Tue Sep 5 09:37:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151C7132D8D; Tue, 5 Sep 2017 09:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 cM-fglhommVs; Tue, 5 Sep 2017 09:37:22 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E659132D86; Tue, 5 Sep 2017 09:37:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v85GbL9l057340; Tue, 5 Sep 2017 09:37:22 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v85GbD4p057144 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 5 Sep 2017 09:37:13 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Sep 2017 09:37:12 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 5 Sep 2017 09:37:12 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: Warren Kumari , Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , The IESG Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTJcbyZ/JGPtSOiEKRi/iUYLBZ76KmYOMAgAB9b4D//49D8IAAhI6A//+LrSA= Date: Tue, 5 Sep 2017 16:37:12 +0000 Message-ID: <704cc3cfaff14f54aea91cb2f51d6b6f@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <9bc87af662c845af8aae0e0b0317b452@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_704cc3cfaff14f54aea91cb2f51d6b6fXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 16:37:24 -0000 --_000_704cc3cfaff14f54aea91cb2f51d6b6fXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KSSBkb27igJl0IHNlZSBhbnl0aGluZyBhYm91dCBMMiBwYXJ0aXRpb25p bmcgYW55d2hlcmUgaW4gdGhlIGRvY3VtZW50LiBBbmQsIGlmIHRoZXJlDQppcyBubyBMMiBwYXJ0 aXRpb25pbmcgdGhlbiBwZWVyLXRvLXBlZXIgaXMgcG9zc2libGUgZXZlbiBpZiB0aGUgZG9jdW1l bnQgc2F5cyBob3N0cw0K4oCcc2hvdWxk4oCdIGdvIHRocm91Z2ggYSBkZWZhdWx0IHJvdXRlci4N Cg0KVGhpcyBpcyBhIGZhY3QgKG5vdCBhbiBvcGluaW9uKSB0aGF0IHRoZSBkb2N1bWVudCBuZWVk cyB0byBhZGRyZXNzLg0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IExvcmVuem8gQ29saXR0aSBb bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwNSwg MjAxNyA5OjMwIEFNDQpUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPg0KQ2M6IFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0PjsgU3VyZXNoIEtyaXNo bmFuIDxzdXJlc2gua3Jpc2huYW5AZ21haWwuY29tPjsgdjZvcHNAaWV0Zi5vcmc7IGRyYWZ0LWll dGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QGlldGYub3JnOyBkcmFmdC1pZXRm LXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC5hbGxAaWV0Zi5vcmc7IHY2b3BzLWNo YWlyc0BpZXRmLm9yZzsgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkg PGd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBTdXJlc2ggS3Jpc2huYW4ncyBEaXNjdXNzIG9uIGRyYWZ0 LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3OiAod2l0aCBESVNDVVNT IGFuZCBDT01NRU5UKQ0KDQpPbiBXZWQsIFNlcCA2LCAyMDE3IGF0IDE6MDIgQU0sIFRlbXBsaW4s IEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbT4+IHdyb3RlOg0KU28sIHRoZSBkb2N1bWVudCBlaXRoZXIgbmVlZHMgdG8gdGFs ayBhYm91dCBMMiBwYXJ0aXRpb25pbmcgb3IgYWNrbm93bGVkZ2UNCnRoYXQgKG9uIHNvbWUgbGlu ayB0eXBlcykgcGVlci10by1wZWVyIGlzIGluZXZpdGFibGUuIEkgcHJlZmVyIHRoZSBsYXR0ZXIg YmVjYXVzZQ0KcGVlci10by1wZWVyIHByb3ZpZGVzIGEgbmVjZXNzYXJ5IG9wdGltaXphdGlvbiBv biBzb21lIGxpbmsgdHlwZXMuDQoNClBhcnRpdGlvbmluZyBpcyBpbiB0aGUgYXBwbGljYWJpbGl0 eSBzdGF0ZW1lbnQuDQo= --_000_704cc3cfaff14f54aea91cb2f51d6b6fXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIExv cmVuem8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGRvbuKA mXQgc2VlIGFueXRoaW5nIGFib3V0IEwyIHBhcnRpdGlvbmluZyBhbnl3aGVyZSBpbiB0aGUgZG9j dW1lbnQuIEFuZCwgaWYgdGhlcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aXMgbm8gTDIgcGFydGl0aW9u aW5nIHRoZW4gcGVlci10by1wZWVyIGlzIHBvc3NpYmxlIGV2ZW4gaWYgdGhlIGRvY3VtZW50IHNh eXMgaG9zdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCcc2hvdWxk4oCdIGdvIHRocm91Z2ggYSBkZWZh dWx0IHJvdXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo aXMgaXMgYSBmYWN0IChub3QgYW4gb3BpbmlvbikgdGhhdCB0aGUgZG9jdW1lbnQgbmVlZHMgdG8g YWRkcmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5r cyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBMb3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3JlbnpvQGdvb2ds ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgU2VwdGVtYmVyIDA1LCAyMDE3IDk6 MzAgQU08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4sIEZyZWQgTCAmbHQ7RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFdhcnJlbiBLdW1hcmkgJmx0O3dhcnJlbkBr dW1hcmkubmV0Jmd0OzsgU3VyZXNoIEtyaXNobmFuICZsdDtzdXJlc2gua3Jpc2huYW5AZ21haWwu Y29tJmd0OzsgdjZvcHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJl Zml4LXBlci1ob3N0QGlldGYub3JnOyBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZp eC1wZXItaG9zdC5hbGxAaWV0Zi5vcmc7IHY2b3BzLWNoYWlyc0BpZXRmLm9yZzsgVmFuIERlIFZl bGRlLA0KIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKSAmbHQ7Z3VudGVyLnZhbl9kZV92ZWxk ZUBub2tpYS5jb20mZ3Q7OyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gU3VyZXNoIEtyaXNobmFuJ3MgRGlzY3VzcyBvbiBkcmFm dC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNzogKHdpdGggRElTQ1VT UyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIFNlcCA2LCAyMDE3IGF0IDE6MDIgQU0s IFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb20iIHRhcmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbywgdGhlIGRv Y3VtZW50IGVpdGhlciBuZWVkcyB0byB0YWxrIGFib3V0IEwyIHBhcnRpdGlvbmluZyBvciBhY2tu b3dsZWRnZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoYXQgKG9uIHNvbWUgbGluayB0eXBlcykgcGVl ci10by1wZWVyIGlzIGluZXZpdGFibGUuIEkgcHJlZmVyIHRoZSBsYXR0ZXIgYmVjYXVzZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPnBlZXItdG8tcGVlciBwcm92aWRlcyBhIG5lY2Vzc2FyeSBvcHRpbWl6 YXRpb24gb24gc29tZSBsaW5rIHR5cGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXJ0 aXRpb25pbmcgaXMgaW4gdGhlIGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50LiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_704cc3cfaff14f54aea91cb2f51d6b6fXCH150608nwnosboeingcom_-- From nobody Tue Sep 5 09:59:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661D3132D79; Tue, 5 Sep 2017 09:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6yUlfqhj4-y; Tue, 5 Sep 2017 09:59:28 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D591E132D86; Tue, 5 Sep 2017 09:59:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7B78BB3; Tue, 5 Sep 2017 18:59:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504630765; bh=FFwIRPeAKexDi8++SnjHZK1w4pRPjZbTv70s/eKw7og=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=U9S5RgfJcDowDR45VdMmyHU31esjafYMi2ZIYDdvo34TrLenbVDVdTECMIKUqmJC0 Yy0MfbQvBGvFYzRFmB2hoNlN6Ua3nWD/z2au5dKlBdPUII/zt7VlIZ9KBnbIjJ+/dQ sEznIM0RCsqXVKqpTTfKdLDxqsSjok07awC/VIKk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 77661B2; Tue, 5 Sep 2017 18:59:25 +0200 (CEST) Date: Tue, 5 Sep 2017 18:59:25 +0200 (CEST) From: Mikael Abrahamsson To: "Templin, Fred L" cc: Lorenzo Colitti , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Suresh Krishnan , The IESG In-Reply-To: <704cc3cfaff14f54aea91cb2f51d6b6f@XCH15-06-08.nw.nos.boeing.com> Message-ID: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <9bc87af662c845af8aae0e0b0317b452@XCH15-06-08.nw.nos.boeing.com> <704cc3cfaff14f54aea91cb2f51d6b6f@XCH15-06-08.nw.nos.boeing.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-998884196-1504630765=:29378" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 16:59:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-998884196-1504630765=:29378 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 5 Sep 2017, Templin, Fred L wrote: > Hi Lorenzo, > > I don’t see anything about L2 partitioning anywhere in the document. And, if there > is no L2 partitioning then peer-to-peer is possible even if the document says hosts > “should” go through a default router. > > This is a fact (not an opinion) that the document needs to address. " o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router" So while this says they should be isolated, I think this text could be made clearer. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-998884196-1504630765=:29378-- From nobody Tue Sep 5 10:40:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C0C132D62; Tue, 5 Sep 2017 10:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AS0A-iR6v06g; Tue, 5 Sep 2017 10:40:26 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B12132D86; Tue, 5 Sep 2017 10:40:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v85HePvp060350; Tue, 5 Sep 2017 10:40:25 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v85HeMIk060312 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 5 Sep 2017 10:40:22 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Sep 2017 10:40:21 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 5 Sep 2017 10:40:21 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson CC: Lorenzo Colitti , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Suresh Krishnan , The IESG Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTJcbyZ/JGPtSOiEKRi/iUYLBZ76KmYOMAgAB9b4D//49D8IAAhI6A//+LrSCAAHyigP//kapA Date: Tue, 5 Sep 2017 17:40:21 +0000 Message-ID: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <9bc87af662c845af8aae0e0b0317b452@XCH15-06-08.nw.nos.boeing.com> <704cc3cfaff14f54aea91cb2f51d6b6f@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 17:40:28 -0000 SGkgTWlrYWVsLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1pa2Fl bCBBYnJhaGFtc3NvbiBbbWFpbHRvOnN3bWlrZUBzd20ucHAuc2VdDQo+IFNlbnQ6IFR1ZXNkYXks IFNlcHRlbWJlciAwNSwgMjAxNyA5OjU5IEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQu TC5UZW1wbGluQGJvZWluZy5jb20+DQo+IENjOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29v Z2xlLmNvbT47IHY2b3BzQGlldGYub3JnOyBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXBy ZWZpeC1wZXItaG9zdEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi12Nm9wcy0NCj4gdW5pcXVlLWlwdjYt cHJlZml4LXBlci1ob3N0LmFsbEBpZXRmLm9yZzsgdjZvcHMtY2hhaXJzQGlldGYub3JnOyBWYW4g RGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKQ0KPiA8Z3VudGVyLnZhbl9kZV92 ZWxkZUBub2tpYS5jb20+OyBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5j b20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gU3Vy ZXNoIEtyaXNobmFuJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXBy ZWZpeC1wZXItaG9zdC0wNzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IE9uIFR1 ZSwgNSBTZXAgMjAxNywgVGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiANCj4gPiBIaSBMb3Jlbnpv LA0KPiA+DQo+ID4gSSBkb27igJl0IHNlZSBhbnl0aGluZyBhYm91dCBMMiBwYXJ0aXRpb25pbmcg YW55d2hlcmUgaW4gdGhlIGRvY3VtZW50LiBBbmQsIGlmIHRoZXJlDQo+ID4gaXMgbm8gTDIgcGFy dGl0aW9uaW5nIHRoZW4gcGVlci10by1wZWVyIGlzIHBvc3NpYmxlIGV2ZW4gaWYgdGhlIGRvY3Vt ZW50IHNheXMgaG9zdHMNCj4gPiDigJxzaG91bGTigJ0gZ28gdGhyb3VnaCBhIGRlZmF1bHQgcm91 dGVyLg0KPiA+DQo+ID4gVGhpcyBpcyBhIGZhY3QgKG5vdCBhbiBvcGluaW9uKSB0aGF0IHRoZSBk b2N1bWVudCBuZWVkcyB0byBhZGRyZXNzLg0KPiANCj4gIiAgIG8gIFR3byBkZXZpY2VzIChzdWJz Y3JpYmVyL2hvc3RzKSwgYm90aCBhdHRhY2hlZCB0byB0aGUgc2FtZSBwcm92aWRlcg0KPiAgICAg ICAgbWFuYWdlZCBzaGFyZWQgbmV0d29yayBzaG91bGQgb25seSBiZSBhYmxlIHRvIGNvbW11bmlj YXRlIHRocm91Z2gNCj4gICAgICAgIHRoZSBwcm92aWRlciBtYW5hZ2VkIEZpcnN0IEhvcCBSb3V0 ZXIiDQo+DQo+IFNvIHdoaWxlIHRoaXMgc2F5cyB0aGV5IHNob3VsZCBiZSBpc29sYXRlZCwgSSB0 aGluayB0aGlzIHRleHQgY291bGQgYmUNCj4gbWFkZSBjbGVhcmVyLg0KDQpSaWdodCwgYW5kIEkg c2FpZDoNCg0KKysrDQogSW4gc2VjdGlvbiAyOg0KDQogICAgIiBvICBUd28gZGV2aWNlcyAoc3Vi c2NyaWJlci9ob3N0cyksIGJvdGggYXR0YWNoZWQgdG8gdGhlIHNhbWUgcHJvdmlkZXINCiAgICAg ICBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gY29tbXVuaWNh dGUgdGhyb3VnaA0KICAgICAgIHRoZSBwcm92aWRlciBtYW5hZ2VkIEZpcnN0IEhvcCBSb3V0ZXIi DQogDQpQbGVhc2UgY2hhbmdlIHRvIHNheToNCiANCiAgICAibyAgVHdvIGRldmljZXMgKHN1YnNj cmliZXIvaG9zdHMpLCBib3RoIGF0dGFjaGVkIHRvIHRoZSBzYW1lIHByb3ZpZGVyDQogICAgICAg bWFuYWdlZCBzaGFyZWQgbmV0d29yayBzaG91bGQgb25seSBiZSBhYmxlIHRvIGNvbW11bmljYXRl IHRocm91Z2gNCiAgICAgICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVyIHVu bGVzcyB0aGUgc2hhcmVkIG5ldHdvcmsNCiAgICAgICBleHBsaWNpdGx5IHBlcm1pdHMgcGVlci10 by1wZWVyIG9wZXJhdGlvbnMiDQorKysNCg0KVGhhbmtzIC0gRnJlZA0K From nobody Tue Sep 5 11:24:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD3A132E07; Tue, 5 Sep 2017 11:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqqKzEwixh5Y; Tue, 5 Sep 2017 11:24:48 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30538120720; Tue, 5 Sep 2017 11:24:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v85IOkvK051016; Tue, 5 Sep 2017 11:24:47 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v85IOceB050877 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 5 Sep 2017 11:24:39 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Sep 2017 11:24:37 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 5 Sep 2017 11:24:37 -0700 From: "Templin, Fred L" To: Mikael Abrahamsson CC: "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org" , "v6ops-chairs@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Suresh Krishnan , The IESG Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTJcbyZ/JGPtSOiEKRi/iUYLBZ76KmYOMAgAB9b4D//49D8IAAhI6A//+LrSCAAHyigP//kapAAAHJUPA= Date: Tue, 5 Sep 2017 18:24:37 +0000 Message-ID: <488e24ec45d24b68b2f2a25653a4a749@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <9bc87af662c845af8aae0e0b0317b452@XCH15-06-08.nw.nos.boeing.com> <704cc3cfaff14f54aea91cb2f51d6b6f@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 18:24:49 -0000 QW5vdGhlciBpc3N1ZSB3aXRoIHRoZSBkb2N1bWVudCBpcyB0aGF0ICJzaGFyZWQgbmV0d29yayIg aXMgbm90IGFuIFJGQzQ4NjEgbGluaw0KdHlwZS4gUkZDNDg2MSBsaW5rIHR5cGVzIHRoYXQgY291 bGQgZmFsbCB1bmRlciB0aGUgY2F0ZWdvcnkgb2YgInNoYXJlZCBuZXR3b3JrIg0KaW5jbHVkZTog Im11bHRpY2FzdCBjYXBhYmxlIiwgIm5vbi1icm9hZGNhc3QgbXVsdGlwbGUgYWNjZXNzIiBhbmQg InNoYXJlZCBtZWRpYSIuDQpJbiBhbGwgb2YgdGhlc2UgY2FzZXMsIGl0IG11c3QgYmUgYXNzdW1l ZCB0aGF0IGFueSBwYWlyIG9mIG5vZGVzIGNhbiBjb21tdW5pY2F0ZQ0KcGVlci10by1wZWVyIHVu bGVzcyBwcmV2ZW50ZWQgZnJvbSBkb2luZyBzbyBieSBzb21lIGZvcm0gb2YgTDIgcGFydGl0aW9u aW5nLg0KDQpUaGUgZG9jdW1lbnQgYWxzbyBzYXlzOg0KDQogICJvICBBbGxvdyBmb3IgdGhlIGdy ZWF0ZXN0IGZsZXhpYmlsaXR5IGFjcm9zcyBob3N0IGltcGxlbWVudGF0aW9uIHRvDQogICAgICBh bGxvdyBmb3IgdGhlIHdpZGVzdCByYW5nZSBvZiBhZGRyZXNzaW5nIGFuZCBjb25maWd1cmF0aW9u DQogICAgICBtZWNoYW5pc21zIHRvIGJlIGVtcGxveWVkLiAgVGhlIGdvYWwgaGVyZSBpcyB0byBl bnN1cmUgdGhhdCB0aGUNCiAgICAgIHdpZGVzdCBwb3B1bGF0aW9uIG9mIFVFIGltcGxlbWVudGF0 aW9ucyBjYW4gbGV2ZXJhZ2UgdGhlDQogICAgICBhdmFpbGFiaWxpdHkgb2YgSVB2NiINCg0KU28s IHJlc3RyaWN0aW5nIHRoZSBsaW5rIHR5cGVzIG9uIHdoaWNoIHRoZXNlIG1lY2hhbmlzbXMgY291 bGQgYmUgYXBwbGllZCB3b3VsZA0Kc2VlbSB0byBiZSBpbiBjb250cmFzdCB3aXRoIHRoaXMgZ29h bC4NCg0KSW4gYW55IGV2ZW50LCB0aGUgZG9jdW1lbnQgbmVlZHMgdG8gY2xhcmlmeSB3aGF0IGl0 IG1lYW5zIGJ5ICJzaGFyZWQgbmV0d29yayINCmJ5IGNpdGluZyB0aGUgYXBwbGljYWJsZSBSRkM0 ODYxIGxpbmsgdHlwZXMuDQoNClRoYW5rcyAtIEZyZWQNCg0KDQo= From nobody Tue Sep 5 11:31:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C37124B18 for ; Tue, 5 Sep 2017 11:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqjeJXSvMa_h for ; Tue, 5 Sep 2017 11:31:56 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C7C120720 for ; Tue, 5 Sep 2017 11:31:56 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id z143so14004560qkb.3 for ; Tue, 05 Sep 2017 11:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=fcN3Vzv4G0vjmjiIvQt/t10PBJ/BMgoo4EcASAePOG8=; b=dlFamEJyhCP3PDZUcJ2eYLzsYry6QQPMkWlJG0rjp0d16OcLUGZcsdQtAd5LNTqkdx zo8GqtiM4+NVte9cgFTwYi1NY7zt/EsdHrmIldt9+zMNzo9VJgS2cBnzQF0mreCPo5CA GiOU9DchHt5L6jxIU2pGVq1AVFLAj4CuenZe07uMe7+5E+8bfNPVhmXL3Now/YJw/Fdx HFSIAfiTDwKh30gcs4hDEO6Vhgii4Yz406GkjQeLHb0ABvOcSB5+mjkPajUlQlzSnt3x ivnHeDDoZCJztplHJGyBGXzwmvP+Gp4AYb0W/LpzUe6eMMuV1z5vgk1UAgDxOGVvoONw A/+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:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=fcN3Vzv4G0vjmjiIvQt/t10PBJ/BMgoo4EcASAePOG8=; b=KQteaR44JQUrGIk43c9Ft072Bqgp8Zh5qJuzo5K6ja0oC2OM5cpqZmSGxyUu96Ez+W ldcYMAy+8/Asl02Vb/sCNY3HKvFyHSeI7VxMamxVJP8geAMJqS5dF/1Wq6EPy9EOCo0S 2SVSGSzU0lETbpiamTxp+rOqzEjCxx9UNwCjCHvEdOiC8SWd8inX+2EUY4WTBglzVMm8 K4jujVm4Bm0f6HLim4RiJf61Sqgs6c98s0rvx150bqcG/kLdtisviEXzzKXD5xmMvO4I EJ16nHjC4EXF5kU9Gl5qbYRxR5wVTaaovp67nDgHDuvkDJpLtTHD83W8gHkuKdc0MVW5 WkJw== X-Gm-Message-State: AHPjjUjtQjNy897N50M6CCCxHBhVXURo3KcIyvIUeSVQ+2HttkAHGYGz OP0kMTqqam768LKnq6EDQ5D6p2SSyslecDQ= X-Google-Smtp-Source: ADKCNb4MuJEPxpy0r13OghdsYM2bwC/26xdZ/Hn8BFKHzYvPhstFAlB5px52BgizPrLXYpdiBhTZCzHNom/k5yhSQ7Y= X-Received: by 10.55.177.195 with SMTP id a186mr21073qkf.78.1504636315399; Tue, 05 Sep 2017 11:31:55 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.54.104 with HTTP; Tue, 5 Sep 2017 11:31:49 -0700 (PDT) In-Reply-To: <982E6DB0-2E8F-484A-934A-8C71F539B36A@employees.org> References: <1655d9119edc47d091c23220023a007d@XCH15-06-08.nw.nos.boeing.com> <982E6DB0-2E8F-484A-934A-8C71F539B36A@employees.org> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 5 Sep 2017 11:31:49 -0700 X-Google-Sender-Auth: s-mmXbXGd4Wf17cMpBra7aAc38o Message-ID: To: Ole Troan Cc: Mikael Abrahamsson , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Prefix Delegation RS/RA vs DHCPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 18:31:58 -0000 At Thu, 31 Aug 2017 15:09:20 +0200, Ole Troan wrote: > >> If I were to recommend something, I would require the requesting route= r (HGW in your parlance) to be responsible for maintaining the state in int= ermediate devices. The mechanism I'd like to use for that is something akin= to BFD echo mode. The RR sends a packet (e.g. ICMP echo) destined to _itse= lf_ using a destination address from the delegated prefix via its first-hop= router. If packet is received the RR is guaranteed that the fist hop route= r has forwarding state. If packet is not received, that should trigger the = RR to revalidate the prefix with a DHCP VERIFY or RENEW message. > > > > Makes sense. Not that I am a network application programmer, but it loo= ks like this will require raw sockets to accomplish. I'll look into it. I guess the IPV6_NEXTHOP ancillary data or socket option as defined in RFC3542 can be used for this purpose. If I remember correctly the BSD implementation of this option works that way (not checked myself recently). But this option/ancillary data may not be very widely available - Linux probably doesn't support it as it's known not to support even much simpler advanced options like IPV6_USE_MIN_MTU. -- JINMEI, Tatuya From nobody Tue Sep 5 12:35:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F55E126D0C for ; Tue, 5 Sep 2017 12:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeyG2tmWGgJp for ; Tue, 5 Sep 2017 12:35:17 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B424F124E15 for ; Tue, 5 Sep 2017 12:35:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v85JZBRl184719; Tue, 5 Sep 2017 21:35:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D31FE20797B; Tue, 5 Sep 2017 21:35:11 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C582F207891; Tue, 5 Sep 2017 21:35:11 +0200 (CEST) Received: from [132.166.84.111] ([132.166.84.111]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v85JZASv020744; Tue, 5 Sep 2017 21:35:11 +0200 To: "Templin, Fred L" , "v6ops@ietf.org" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: Date: Tue, 5 Sep 2017 21:35:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 19:35:19 -0000 Le 05/09/2017 à 18:06, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Tuesday, September 05, 2017 8:39 AM >> To: v6ops@ietf.org >> Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android >> >> Hi, >> >> I want to update the list about our advancements. >> >> We are exploring the question of why DHCPv6 Prefix Delegation is not >> used on cellular links. This lack of PD support has bad side effects: >> an INFORMATIONAL RFC 64share becomes more and more used, Mobile Routers >> are impossible. >> >> Here are the unique reasons - if solely these are solved then we get PD >> on cellular: >> - some modems in the UE (e.g. QDSP6 and others) block standard DHCPv6 >> UDP port numbers 546 and 547 and (and sometimes or) standard IP >> multicast addressing in both directions; this blocking was identified >> by comparing packet dumps on the ARM part of UE, vs on PGW; >> this blocking was further confirmed by successful Sol/Adv on unicast >> and non-std UDP ports. >> This blocking happens even though the application processor (e.g. ARM) >> does not block them. >> These ports and multicast are absolutely needed for Prefix Delegation, >> because Prefix Delegation runs as an integral part of DHCPv6. >> - much less likely, it may be that some infrastructure entities like >> Base Station or SGW - again, very little probable - blocks same DHCP >> ports and multicast. >> - DHCPv6 software is little parametrable or portable, even though much >> source is available openly. >> >> Some details: >> - the DHCPv6 software on Android is hampered by the need of root access. >> Android blocks that. One needs to ask the platform manufacturer >> running that Android to "root" the platform such as to be able to run >> some of the DHCP client software (e.g. ask Huawei for a key to root >> the smartphone). That's a real pain. There is a risk of "bricking" >> your platform, i.e. through it out a window. > > You don't need to root the device to run DHCPv6 PD over a VPN: > > https://developer.android.com/reference/android/net/VpnService.html > > Again, we have DHCPv6 PD working fine over a VPN. That is good to know. In my setting I need DHCPv6-PD as unencapsulated as possible - just straight. (on IPv6 cellular links there is already IPv6-in-GTPU encapsulation, which is an IPv4 protocol, that is hard to get rid of; a 2nd encapsulation for VPN, or a 3rd encapsulation for Mobile IP means additional overhead in terms of packet headers, intelligence to maintain tunnels up, etc) Alex > > Thanks - Fred > >> - to make an app available to everyone on Android one must pay some >> money to become a member of a store. DHCP should not be part of that, >> as SLAAC isnt; just like SLAAC, DHCP should be builtin for free. >> - the DHCPv6 server software "ISC" breaks if the port numbers are >> non-standard (not 546 nor 547) or unicast instead of multicast. >> (e.g. "Discarding Solicit from [snip]; packet sent unicast") >> This was a real pain, because we had to modify the source code >> to allow it; other software like VoIP has SIP ports this configurable >> easily with a GUI. >> - Cisco parametering CLI of DHCPv6 service may have some problems in >> transforming a non-standard UDP port 546 of Solicit to a strange >> 26483. That was a real pain to one. >> - various DHCPv6 client software break, or do not even start, with >> any other src and dst UDP ports than the standard (546, 547) >> and/or non-standard unicast instead of standard multicast. >> >> Other reasons proved not to be causes of absence of DHCPv6 PD on >> cellular links; they were just speculations: >> - cellular operators dont provide DHCPv6 PD service (there are some who >> do under some operational conditions) >> - cellular operators have a hard time making an IPv6 addressing >> architecture that delegate prefixes instead of addresses (there are >> some who do make such architecture) >> - cellular operators only do '64' (it's false, some could do less, >> like 56 or even 48) >> - DHCPv6 software is not available on the client (there are some, like >> on Android, and more, see quoted mails below) >> - the computer that runs the DHCPv6 client is the same as the one that >> puts the Solicit on the wire: this is not true, because even in the >> smallest UE in the market there is still distinction app-vs-modem >> processors. Often the modem part is confidential, only the binary >> is available to the public, and there are two IPs on it: Internet >> Protocol _and_ Intellectual Property. >> >> Alex, with thanks to [Hachata], admin(s), managers, and technicals at >> offices and organisations. >> >> >> Le 18/08/2017 à 18:07, Alexandre Petrescu a écrit : >>> I have been pointed by a helpful person that an Android app for >>> DHCPv6 exists there: >>> >>> https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client&hl=fr >>> >>> >>> >>> >>> >>> It is based on the WIDE DHCPv6 client. >>> >>> Further browsing leads to a discussion of DHCPv6 on Android topic: >>> https://issuetracker.google.com/issues/36949085 >>> >>> Alex >>> >>> Le 17/07/2017 à 18:26, Alexandre Petrescu a écrit : >>>> Well, this is to note that we too (Fred mentioned it too earlier) >>>> made the ISC DHCPv6 dhclient work on Android, including DHCPv6 >>>> Solicit that requests Prefix Delegation. >>>> >>>> (but we still dont have a response to DHCP Solicit on cellular >>>> link). >>>> >>>> Alex >>>> >>>> Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit : >>>>> Mark, noted, will try. >>>>> >>>>> Just a note... >>>>> >>>>> Le 06/07/2017 à 03:16, Mark Andrews a écrit : >>>>>> >>>>>> In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, >>>>>> Alexandre Petrescu writes: >>>>>>> Hello, >>>>>>> >>>>>>> We discussed extensively about the potential use of DHCPv6 >>>>>>> Prefix Delegation on cellular links. >>>>>>> >>>>>>> The chicken issue is the lack of DHCPv6 PD software on >>>>>>> typical User Equipment. For example, there is no DHCPv6-PD >>>>>>> app on Android. The egg issue is the lack of operator >>>>>>> support of DHCPv6-PD towards the User Terminal. For example, >>>>>>> there is no cellular operator answering to DHCPv6-PD requests >>>>>>> issued by the User Terminal. >>>>>>> >>>>>>> To address the chicken issue, we started with an ISC DHCP >>>>>>> open software client, which does implement Prefix Delegation. >>>>>>> It can be (cross)compiled on various platforms; then type >>>>>>> "./dhclient -6 -P"; this sends an DHCPv6 Solicit Identity >>>>>>> Associtaion for Prefix Delegation message on the interface. >>>>>>> >>>>>>> However, whereas this software runs ok on interfaces such as >>>>>>> Ethernet, USBnet and WiFi interfaces, it breaks if run on the >>>>>>> cellular interface of some IoT cellular platform. The error >>>>>>> can be corrected by the quick-and-dirty solution below. >>>>>> >>>>>> The hack would be better as >>>>>> >>>>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; hw->hbuf[0] >>>>>> = HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>>>> #endif default: log_fatal("Unsupported device type %ld for >>>>>> \"%s\"", (long int)sa->sa_family, name); break; >>>>>> >>>>>> with ARPHRD_XXXX being replaced by the correct macro for 503 >>>>>> from . Something like that is at least >>>>>> portable. >>>>> >>>>> But it means when I go to other platform will have to modify >>>>> again the ISC client source code? >>>>> >>>>> In cellular terminals there are so many non-IEEE different kinds >>>>> of links. >>>>> >>>>> Other clients work out of the box on this - I agree with you, >>>>> strange - "rmnet0" interface. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> As for the rest of it I have no idea about the presented >>>>>> hardware address of this type so I don't know it the rest of it >>>>>> make sense. >>>>>> >>>>>>> Alex >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0." >>>>>>> dhcp-4.3.5 ./common/lpf.c line number: 551 >>>>>>> >>>>>>> //default: // log_fatal("Unsupported device type %ld >>>>>>> for \"%s\"", // (long int)sa->sa_family, >>>>>>> name); default: hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; >>>>>>> memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>>>>> >>>>>>> (two programmers worked this out). >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> _______________________________________________ v6ops >>>>>>> mailing list v6ops@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> _______________________________________________ v6ops mailing >>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> _______________________________________________ v6ops mailing list >>>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 5 12:39:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE44132E21 for ; Tue, 5 Sep 2017 12:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYAUjMD9_jfs for ; Tue, 5 Sep 2017 12:39:47 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECADF132E19 for ; Tue, 5 Sep 2017 12:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1504640385; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BagXb23wPMx3twmEj2DztF0bwtxnMvYMgDyiVOXrVaI=; b=wsODXOvpbbvV/cReInK7bkOr6UZ+A+4aU6WIvmQiKfPmX30hbR98y2S1lxUzjGKe kZuRtdaCbkO4fwuwezSgtlPI9xEuoYVuEYjAuv04vjEL3Ba+vR+zM0BoTGomsIMh 8yyx2FHN4t6h0qWJsdZm1d020zEBuZ4jaXIyYep73yMNkpK8l2UQP9lwg7GMApSW pb7EsjUSLenPCUCo3r+3qbraQAeN0rptdBm2eekaPoGCkNgXfy3UZ8zafx6Dp5vx 636VMoFTlADdnMyvDr5Q+nMjpcNZhWjH/OPp/t9z25Kf6CtcVdXOY8VZaUk4GfCi hJLGxhyM3u88jKhALZHAdg==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id C2.76.14095.18DFEA95; Tue, 5 Sep 2017 12:39:45 -0700 (PDT) X-AuditID: 11ab0216-7144d9c00000370f-f7-59aefd815987 Received: from kencur.apple.com (kencur.apple.com [17.151.62.38]) by relay8.apple.com (Apple SCV relay) with SMTP id A1.61.06978.08DFEA95; Tue, 5 Sep 2017 12:39:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from da0602a-dhcp140.apple.com (da0602a-dhcp140.apple.com [17.226.23.140]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OVT00L7NNY8KJA0@kencur.apple.com>; Tue, 05 Sep 2017 12:39:44 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: Date: Tue, 05 Sep 2017 12:39:44 -0700 Cc: IPv6 Ops WG , "draft-ietf-v6ops-rfc6555bis.all@ietf.org" Message-id: <25080CBF-42E2-4664-9627-CFF4D7588444@apple.com> References: To: Ron Bonica X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUi2FCYptv4d12kwYUr2hY7Ftxltjjw3cHi 9LG9zA7MHkuW/GTyuN50lT2AKYrLJiU1J7MstUjfLoEr48366+wFD1krZlw8wNLA2M7SxcjJ ISFgInHw/zu2LkYuDiGBtUwSN1Z0M8EktrZ/h0psYpS4vG09K0iCV0BQ4sfke0DdHBzMAvIS B8/LgoSZBbQkvj9qZYGoX8gksWH3S7B6YQFpia4Ld6FsVYm3R4+wgvSyATUcWGMEEuYUsJU4 fP8xWAkLUMn9Ka1MEOMrJY4+j4bYaiMx4cNXRhBbSGAqo8S7ycEgtoiAisTaP5OgfpGVuDX7 EjPICRICK9gkVuzfzDaBUXgWkqtnIVw9C8nVCxiZVzEK5yZm5uhm5hkZ6SUWFOSk6iXn525i BAX4aiaxHYz3XhseYhTgYFTi4Z2waV2kEGtiWXFl7iFGaQ4WJXHep6/XRgoJpCeWpGanphak FsUXleakFh9iZOLglGpgDE1lZ7WULmf5duFT5Mbvy9qyLJbfV7Ja4LhxRpRad2HZodM7q08t iorWXPmodk1iwSrlBS1H/+5x3VYx5XfEeaNTcsULqt6qt8t+OrMvoOc8Q/ye0kVhYtWqEnbi f5Q+MGp8VVn6Xeb1sVcXbGPk5z55fuAFa64Z38G9dyXOXrZNeqB1IEbrshJLcUaioRZzUXEi AItESeJRAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42IRnG6nptvwd12kwfQFRhY7Ftxltjjw3cHi 9LG9zA7MHkuW/GTyuN50lT2AKYrLJiU1J7MstUjfLoEr48366+wFD1krZlw8wNLA2M7SxcjJ ISFgIrG1/TtbFyMXh5DAJkaJy9vWs4IkeAUEJX5MvgdUxMHBLCAvcfC8LEiYWUBL4vujVhaI +oVMEht2vwSrFxaQlui6cBfKVpV4e/QIK0gvG1DDgTVGIGFOAVuJw/cfg5WwAJXcn9LKBDG+ UuLo82iIrTYSEz58ZQSxhQSmMkq8mxwMYosIqEis/TMJ6mRZiVuzLzFPYBSYheTQWQiHzkJy 6AJG5lWMAkWpOYmVFnqJBQU5qXrJ+bmbGEHh2FCYtoOxabnVIUYBDkYlHt4Jm9ZFCrEmlhVX 5h5ilOBgVhLhffkRKMSbklhZlVqUH19UmpNafIixCuj8icxSosn5wFjJK4k3NDExMDE2NjM2 Njcxp4qwkjiveMqSSCGB9MSS1OzU1ILUIpjlTBycUg2MrGVNzEtLd9ZujaqpUW/5tS6usqZu DmPOQYHznCv+Pz+sekEjv+9AyaX6m/fedrjemd4Rd+/dR5Fm2QlSSZn1N38eLGmW46+oYH60 1uui3XbrNNaFu+QuscQIObHUOU1hVnBW3D575ZdDgUtluOW3L92xjOX1ysnLxARlXkV9zjl7 mm3JtIBJSizFGYmGWsxFxYkAcwaXe6ICAAA= Archived-At: Subject: Re: [v6ops] IPR confirmation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 19:39:50 -0000 Hi Ron, I am not aware of any IPR associated with this draft. Thanks, David Schinazi > On Sep 5, 2017, at 08:40, Tommy Pauly wrote: > > Hi Ron, > > I am not aware of any IPR for this draft. > > Thanks, > Tommy > >> On Sep 5, 2017, at 8:38 AM, Ron Bonica wrote: >> >> Folks, >> >> Could each of the authors of draft-ietf-v6ops-rfc6555bis please respond to this message stating whether they know of any IPR associated with this draft? >> >> Ron >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 5 12:47:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADE0128D0D for ; Tue, 5 Sep 2017 12:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcDJcbYJyg70 for ; Tue, 5 Sep 2017 12:47:22 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B801243F6 for ; Tue, 5 Sep 2017 12:47:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v85JlJZO008667 for ; Tue, 5 Sep 2017 21:47:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A6D79204AC2 for ; Tue, 5 Sep 2017 21:47:19 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9D0F52014DB for ; Tue, 5 Sep 2017 21:47:19 +0200 (CEST) Received: from [132.166.84.111] ([132.166.84.111]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v85JlIgB026486 for ; Tue, 5 Sep 2017 21:47:19 +0200 To: v6ops@ietf.org References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 5 Sep 2017 21:47:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 19:47:24 -0000 For the record, we tried several other things to make PD work ("speculations"), but none was as successful as using unicast and fake port numbers for DHCP Solicit/Advertise. - Hop Limit variations in Solicit, instead of 1: this has some effect in keeping the packet alive on longer IP paths. - use DHCP "Prefix Exclude" option: whether we include it or not, results are same. - request plens same or longer than plen configured at server: no effect. - IP dst address of Solicit: variations between ff02::1 (all-routers) and ff02::2:1 (all DHCP servers) has no effect; if multicast is blocked no form of multicast gets through. - mapping to MAC dst multicast address: be it 33:33 formats or ff:ff formats, the result is the same: when multicast is blocked no form of mapping on MAC multicast gets through. - some other variations. Alex Le 05/09/2017 à 17:39, Alexandre Petrescu a écrit : > Hi, > > I want to update the list about our advancements. > > We are exploring the question of why DHCPv6 Prefix Delegation is not > used on cellular links.  This lack of PD support has bad side effects: > an INFORMATIONAL RFC 64share becomes more and more used, Mobile Routers > are impossible. > > Here are the unique reasons - if solely these are solved then we get PD > on cellular: > - some modems in the UE (e.g. QDSP6 and others) block standard DHCPv6 >   UDP port numbers 546 and 547 and (and sometimes or) standard IP >   multicast addressing in both directions; this blocking was identified >   by comparing packet dumps on the ARM part of UE, vs on PGW; >   this blocking was further confirmed by successful Sol/Adv on unicast >   and non-std UDP ports. >   This blocking happens even though the application processor (e.g. ARM) >   does not block them. >   These ports and multicast are absolutely needed for Prefix Delegation, >   because Prefix Delegation runs as an integral part of DHCPv6. > - much less likely, it may be that some infrastructure entities like >   Base Station or SGW - again, very little probable - blocks same DHCP >   ports and multicast. > - DHCPv6 software is little parametrable or portable, even though much >   source is available openly. > > Some details: > - the DHCPv6 software on Android is hampered by the need of root access. >   Android blocks that.  One needs to ask the platform manufacturer >   running that Android to "root" the platform such as to be able to run >   some of the DHCP client software (e.g. ask Huawei for a key to root >   the smartphone).  That's a real pain.  There is a risk of "bricking" >   your platform, i.e. through it out a window. > - to make an app available to everyone on Android one must pay some >   money to become a member of a store.  DHCP should not be part of that, >   as SLAAC isnt; just like SLAAC, DHCP should be builtin for free. > - the DHCPv6 server software "ISC" breaks if the port numbers are >   non-standard (not 546 nor 547) or unicast instead of multicast. >   (e.g. "Discarding Solicit from [snip]; packet sent unicast") >   This was a real pain, because we had to modify the source code >   to allow it; other software like VoIP has SIP ports this configurable >   easily with a GUI. > - Cisco parametering CLI of DHCPv6 service may have some problems in >   transforming a non-standard UDP port 546 of Solicit to a strange >   26483.  That was a real pain to one. > - various DHCPv6 client software break, or do not even start, with >   any other src and dst UDP ports than the standard (546, 547) >   and/or non-standard unicast instead of standard multicast. > > Other reasons proved not to be causes of absence of DHCPv6 PD on > cellular links; they were just speculations: > - cellular operators dont provide DHCPv6 PD service (there are some who >   do under some operational conditions) > - cellular operators have a hard time making an IPv6 addressing >   architecture that delegate prefixes instead of addresses (there are >   some who do make such architecture) > - cellular operators only do '64' (it's false, some could do less, >   like 56 or even 48) > - DHCPv6 software is not available on the client (there are some, like >   on Android, and more, see quoted mails below) > - the computer that runs the DHCPv6 client is the same as the one that >   puts the Solicit on the wire: this is not true, because even in the >   smallest UE in the market there is still distinction app-vs-modem >   processors.  Often the modem part is confidential, only the binary >   is available to the public, and there are two IPs on it: Internet >   Protocol _and_ Intellectual Property. > > Alex, with thanks to [Hachata], admin(s), managers, and technicals at > offices and organisations. > > > Le 18/08/2017 à 18:07, Alexandre Petrescu a écrit : >> I have been pointed by a helpful person that an Android app for DHCPv6 >> exists there: >> >> https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client&hl=fr >> >> >> >> >> >> >> It is based on the WIDE DHCPv6 client. >> >> Further browsing leads to a discussion of DHCPv6 on Android topic: >> https://issuetracker.google.com/issues/36949085 >> >> Alex >> >> Le 17/07/2017 à 18:26, Alexandre Petrescu a écrit : >>> Well, this is to note that we too (Fred mentioned it too earlier) >>> made the ISC DHCPv6 dhclient work on Android, including DHCPv6 >>> Solicit that requests Prefix Delegation. >>> >>> (but we still dont have a response to DHCP Solicit on cellular link). >>> >>> Alex >>> >>> Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit : >>>> Mark, noted, will try. >>>> >>>> Just a note... >>>> >>>> Le 06/07/2017 à 03:16, Mark Andrews a écrit : >>>>> >>>>> In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, >>>>> Alexandre Petrescu writes: >>>>>> Hello, >>>>>> >>>>>> We discussed extensively about the potential use of DHCPv6 Prefix >>>>>> Delegation on cellular links. >>>>>> >>>>>> The chicken issue is the lack of DHCPv6 PD software on typical >>>>>> User Equipment.  For example, there is no DHCPv6-PD app on >>>>>> Android.  The egg issue is the lack of operator support of >>>>>> DHCPv6-PD towards the User Terminal.  For example, >>>>>> there is no cellular operator answering to DHCPv6-PD requests >>>>>> issued by the User Terminal. >>>>>> >>>>>> To address the chicken issue, we started with an ISC DHCP open >>>>>> software client, which does implement Prefix Delegation. >>>>>> It can be (cross)compiled on various platforms; then type >>>>>> "./dhclient -6 -P"; this sends an DHCPv6 Solicit Identity >>>>>> Associtaion for Prefix Delegation message on the interface. >>>>>> >>>>>> However, whereas this software runs ok on interfaces such as >>>>>> Ethernet, USBnet and WiFi interfaces, it breaks if run on the >>>>>> cellular interface of some IoT cellular platform.  The error >>>>>> can be corrected by the quick-and-dirty solution below. >>>>> >>>>> The hack would be better as >>>>> >>>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; hw->hbuf[0] >>>>>  = HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; #endif >>>>> default: log_fatal("Unsupported device type %ld for \"%s\"", (long >>>>> int)sa->sa_family, name); break; >>>>> >>>>> with ARPHRD_XXXX being replaced by the correct macro for 503 from >>>>> .  Something like that is at least portable. >>>> >>>> But it means when I go to other platform will have to modify again >>>> the ISC client source code? >>>> >>>> In cellular terminals there are so many non-IEEE different kinds >>>>  of links. >>>> >>>> Other clients work out of the box on this - I agree with you, >>>> strange - "rmnet0" interface. >>>> >>>> Alex >>>> >>>>> >>>>> As for the rest of it I have no idea about the presented hardware >>>>> address of this type so I don't know it the rest of it >>>>> make sense. >>>>> >>>>>> Alex >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0." >>>>>> dhcp-4.3.5 ./common/lpf.c line number: 551 >>>>>> >>>>>> //default: //      log_fatal("Unsupported device type %ld >>>>>> for \"%s\"", //                (long int)sa->sa_family, >>>>>> name); default: hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; >>>>>> memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>>>> >>>>>> (two programmers worked this out). >>>>>> >>>>>> Alex >>>>>> >>>>>> _______________________________________________ v6ops >>>>>> mailing list v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> _______________________________________________ v6ops mailing list >>>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 5 12:54:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED31126B6D for ; Tue, 5 Sep 2017 12:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HN3uipYjZiVp for ; Tue, 5 Sep 2017 12:54:29 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611641243F6 for ; Tue, 5 Sep 2017 12:54:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v85JsREr010976; Tue, 5 Sep 2017 12:54:28 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v85JsIXm010464 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 5 Sep 2017 12:54:18 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Sep 2017 12:54:17 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 5 Sep 2017 12:54:17 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] DHCPv6 PD client on cellular on Android Thread-Index: AQHTJl1GQaHk8JRqwk2mcUUbqG/ToKKmdHgQgACwUgD//46dcA== Date: Tue, 5 Sep 2017 19:54:17 +0000 Message-ID: References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 19:54:32 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cmUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTcgMTI6MzUgUE0NCj4gVG86IFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IHY2b3BzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbdjZvcHNdIERIQ1B2NiBQRCBjbGllbnQgb24gY2VsbHVsYXIgb24gQW5kcm9pZA0K PiANCj4gDQo+IA0KPiBMZSAwNS8wOS8yMDE3IMOgIDE4OjA2LCBUZW1wbGluLCBGcmVkIEwgYSDD qWNyaXTCoDoNCj4gPiBIaSBBbGV4LA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+IEZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFsZXhhbmRyZSBQZXRyZXNjdQ0KPiA+PiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1i ZXIgMDUsIDIwMTcgODozOSBBTQ0KPiA+PiBUbzogdjZvcHNAaWV0Zi5vcmcNCj4gPj4gU3ViamVj dDogUmU6IFt2Nm9wc10gREhDUHY2IFBEIGNsaWVudCBvbiBjZWxsdWxhciBvbiBBbmRyb2lkDQo+ ID4+DQo+ID4+IEhpLA0KPiA+Pg0KPiA+PiBJIHdhbnQgdG8gdXBkYXRlIHRoZSBsaXN0IGFib3V0 IG91ciBhZHZhbmNlbWVudHMuDQo+ID4+DQo+ID4+IFdlIGFyZSBleHBsb3JpbmcgdGhlIHF1ZXN0 aW9uIG9mIHdoeSBESENQdjYgUHJlZml4IERlbGVnYXRpb24gaXMgbm90DQo+ID4+IHVzZWQgb24g Y2VsbHVsYXIgbGlua3MuICBUaGlzIGxhY2sgb2YgUEQgc3VwcG9ydCBoYXMgYmFkIHNpZGUgZWZm ZWN0czoNCj4gPj4gYW4gSU5GT1JNQVRJT05BTCBSRkMgNjRzaGFyZSBiZWNvbWVzIG1vcmUgYW5k IG1vcmUgdXNlZCwgTW9iaWxlIFJvdXRlcnMNCj4gPj4gYXJlIGltcG9zc2libGUuDQo+ID4+DQo+ ID4+IEhlcmUgYXJlIHRoZSB1bmlxdWUgcmVhc29ucyAtIGlmIHNvbGVseSB0aGVzZSBhcmUgc29s dmVkIHRoZW4gd2UgZ2V0IFBEDQo+ID4+IG9uIGNlbGx1bGFyOg0KPiA+PiAtIHNvbWUgbW9kZW1z IGluIHRoZSBVRSAoZS5nLiBRRFNQNiBhbmQgb3RoZXJzKSBibG9jayBzdGFuZGFyZCBESENQdjYN Cj4gPj4gICAgIFVEUCBwb3J0IG51bWJlcnMgNTQ2IGFuZCA1NDcgYW5kIChhbmQgc29tZXRpbWVz IG9yKSBzdGFuZGFyZCBJUA0KPiA+PiAgICAgbXVsdGljYXN0IGFkZHJlc3NpbmcgaW4gYm90aCBk aXJlY3Rpb25zOyB0aGlzIGJsb2NraW5nIHdhcyBpZGVudGlmaWVkDQo+ID4+ICAgICBieSBjb21w YXJpbmcgcGFja2V0IGR1bXBzIG9uIHRoZSBBUk0gcGFydCBvZiBVRSwgdnMgb24gUEdXOw0KPiA+ PiAgICAgdGhpcyBibG9ja2luZyB3YXMgZnVydGhlciBjb25maXJtZWQgYnkgc3VjY2Vzc2Z1bCBT b2wvQWR2IG9uIHVuaWNhc3QNCj4gPj4gICAgIGFuZCBub24tc3RkIFVEUCBwb3J0cy4NCj4gPj4g ICAgIFRoaXMgYmxvY2tpbmcgaGFwcGVucyBldmVuIHRob3VnaCB0aGUgYXBwbGljYXRpb24gcHJv Y2Vzc29yIChlLmcuIEFSTSkNCj4gPj4gICAgIGRvZXMgbm90IGJsb2NrIHRoZW0uDQo+ID4+ICAg ICBUaGVzZSBwb3J0cyBhbmQgbXVsdGljYXN0IGFyZSBhYnNvbHV0ZWx5IG5lZWRlZCBmb3IgUHJl Zml4IERlbGVnYXRpb24sDQo+ID4+ICAgICBiZWNhdXNlIFByZWZpeCBEZWxlZ2F0aW9uIHJ1bnMg YXMgYW4gaW50ZWdyYWwgcGFydCBvZiBESENQdjYuDQo+ID4+IC0gbXVjaCBsZXNzIGxpa2VseSwg aXQgbWF5IGJlIHRoYXQgc29tZSBpbmZyYXN0cnVjdHVyZSBlbnRpdGllcyBsaWtlDQo+ID4+ICAg ICBCYXNlIFN0YXRpb24gb3IgU0dXIC0gYWdhaW4sIHZlcnkgbGl0dGxlIHByb2JhYmxlIC0gYmxv Y2tzIHNhbWUgREhDUA0KPiA+PiAgICAgcG9ydHMgYW5kIG11bHRpY2FzdC4NCj4gPj4gLSBESENQ djYgc29mdHdhcmUgaXMgbGl0dGxlIHBhcmFtZXRyYWJsZSBvciBwb3J0YWJsZSwgZXZlbiB0aG91 Z2ggbXVjaA0KPiA+PiAgICAgc291cmNlIGlzIGF2YWlsYWJsZSBvcGVubHkuDQo+ID4+DQo+ID4+ IFNvbWUgZGV0YWlsczoNCj4gPj4gLSB0aGUgREhDUHY2IHNvZnR3YXJlIG9uIEFuZHJvaWQgaXMg aGFtcGVyZWQgYnkgdGhlIG5lZWQgb2Ygcm9vdCBhY2Nlc3MuDQo+ID4+ICAgICBBbmRyb2lkIGJs b2NrcyB0aGF0LiAgT25lIG5lZWRzIHRvIGFzayB0aGUgcGxhdGZvcm0gbWFudWZhY3R1cmVyDQo+ ID4+ICAgICBydW5uaW5nIHRoYXQgQW5kcm9pZCB0byAicm9vdCIgdGhlIHBsYXRmb3JtIHN1Y2gg YXMgdG8gYmUgYWJsZSB0byBydW4NCj4gPj4gICAgIHNvbWUgb2YgdGhlIERIQ1AgY2xpZW50IHNv ZnR3YXJlIChlLmcuIGFzayBIdWF3ZWkgZm9yIGEga2V5IHRvIHJvb3QNCj4gPj4gICAgIHRoZSBz bWFydHBob25lKS4gIFRoYXQncyBhIHJlYWwgcGFpbi4gIFRoZXJlIGlzIGEgcmlzayBvZiAiYnJp Y2tpbmciDQo+ID4+ICAgICB5b3VyIHBsYXRmb3JtLCBpLmUuIHRocm91Z2ggaXQgb3V0IGEgd2lu ZG93Lg0KPiA+DQo+ID4gWW91IGRvbid0IG5lZWQgdG8gcm9vdCB0aGUgZGV2aWNlIHRvIHJ1biBE SENQdjYgUEQgb3ZlciBhIFZQTjoNCj4gPg0KPiA+IGh0dHBzOi8vZGV2ZWxvcGVyLmFuZHJvaWQu Y29tL3JlZmVyZW5jZS9hbmRyb2lkL25ldC9WcG5TZXJ2aWNlLmh0bWwNCj4gPg0KPiA+IEFnYWlu LCB3ZSBoYXZlIERIQ1B2NiBQRCB3b3JraW5nIGZpbmUgb3ZlciBhIFZQTi4NCj4gDQo+IFRoYXQg aXMgZ29vZCB0byBrbm93Lg0KPiANCj4gSW4gbXkgc2V0dGluZyBJIG5lZWQgREhDUHY2LVBEIGFz IHVuZW5jYXBzdWxhdGVkIGFzIHBvc3NpYmxlIC0ganVzdA0KPiBzdHJhaWdodC4NCj4gDQo+IChv biBJUHY2IGNlbGx1bGFyIGxpbmtzIHRoZXJlIGlzIGFscmVhZHkgSVB2Ni1pbi1HVFBVIGVuY2Fw c3VsYXRpb24sDQo+IHdoaWNoIGlzIGFuIElQdjQgcHJvdG9jb2wsIHRoYXQgaXMgaGFyZCB0byBn ZXQgcmlkIG9mOyAgYSAybmQNCj4gZW5jYXBzdWxhdGlvbiBmb3IgVlBOLCBvciBhIDNyZCBlbmNh cHN1bGF0aW9uIGZvciBNb2JpbGUgSVAgbWVhbnMNCj4gYWRkaXRpb25hbCBvdmVyaGVhZCBpbiB0 ZXJtcyBvZiBwYWNrZXQgaGVhZGVycywgaW50ZWxsaWdlbmNlIHRvIG1haW50YWluDQo+IHR1bm5l bHMgdXAsIGV0YykNCg0KQXQgbGVhc3Qgb25lIGZyZWVseS1hdmFpbGFibGUgVlBOIGFwcCBJIGFt IGF3YXJlIG9mIHVzZXMgTFpPIHdob2xlDQptZXNzYWdlIGNvbXByZXNzaW9uLCB3aGljaCBjYW4g YXR0ZW51YXRlIHRoZSBleHRyYSBvdmVyaGVhZCB0bw0KYSBjb25zaWRlcmFibGUgZXh0ZW50Lg0K DQpQbHVzLCB1c2luZyB0aGUgVlBOIG1heSBiZSBjb21wYXRpYmxlIHdpdGggdGhlIHNlY3VyaXR5 IHBvbGljeS4gRm9yDQpleGFtcGxlLCBmb3IgYSBjZWxscGhvbmUgaW4gdGhlIEludGVybmV0IGNv bm5lY3RpbmcgaW50byBhIGhvbWUNCmVudGVycHJpc2UgbmV0d29yayB0aGUgdXNlIG9mIFZQTnMg d291bGQgYmUgY29uc2lzdGVudCB3aXRoIHRoZQ0Kc2VjdXJpdHkgbW9kZWwuDQoNClRoYW5rcyAt IEZyZWQNCg0KPiBBbGV4DQo+IA0KPiA+DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+DQo+ID4+IC0g dG8gbWFrZSBhbiBhcHAgYXZhaWxhYmxlIHRvIGV2ZXJ5b25lIG9uIEFuZHJvaWQgb25lIG11c3Qg cGF5IHNvbWUNCj4gPj4gICAgIG1vbmV5IHRvIGJlY29tZSBhIG1lbWJlciBvZiBhIHN0b3JlLiAg REhDUCBzaG91bGQgbm90IGJlIHBhcnQgb2YgdGhhdCwNCj4gPj4gICAgIGFzIFNMQUFDIGlzbnQ7 IGp1c3QgbGlrZSBTTEFBQywgREhDUCBzaG91bGQgYmUgYnVpbHRpbiBmb3IgZnJlZS4NCj4gPj4g LSB0aGUgREhDUHY2IHNlcnZlciBzb2Z0d2FyZSAiSVNDIiBicmVha3MgaWYgdGhlIHBvcnQgbnVt YmVycyBhcmUNCj4gPj4gICAgIG5vbi1zdGFuZGFyZCAobm90IDU0NiBub3IgNTQ3KSBvciB1bmlj YXN0IGluc3RlYWQgb2YgbXVsdGljYXN0Lg0KPiA+PiAgICAgKGUuZy4gIkRpc2NhcmRpbmcgU29s aWNpdCBmcm9tIFtzbmlwXTsgcGFja2V0IHNlbnQgdW5pY2FzdCIpDQo+ID4+ICAgICBUaGlzIHdh cyBhIHJlYWwgcGFpbiwgYmVjYXVzZSB3ZSBoYWQgdG8gbW9kaWZ5IHRoZSBzb3VyY2UgY29kZQ0K PiA+PiAgICAgdG8gYWxsb3cgaXQ7IG90aGVyIHNvZnR3YXJlIGxpa2UgVm9JUCBoYXMgU0lQIHBv cnRzIHRoaXMgY29uZmlndXJhYmxlDQo+ID4+ICAgICBlYXNpbHkgd2l0aCBhIEdVSS4NCj4gPj4g LSBDaXNjbyBwYXJhbWV0ZXJpbmcgQ0xJIG9mIERIQ1B2NiBzZXJ2aWNlIG1heSBoYXZlIHNvbWUg cHJvYmxlbXMgaW4NCj4gPj4gICAgIHRyYW5zZm9ybWluZyBhIG5vbi1zdGFuZGFyZCBVRFAgcG9y dCA1NDYgb2YgU29saWNpdCB0byBhIHN0cmFuZ2UNCj4gPj4gICAgIDI2NDgzLiAgVGhhdCB3YXMg YSByZWFsIHBhaW4gdG8gb25lLg0KPiA+PiAtIHZhcmlvdXMgREhDUHY2IGNsaWVudCBzb2Z0d2Fy ZSBicmVhaywgb3IgZG8gbm90IGV2ZW4gc3RhcnQsIHdpdGgNCj4gPj4gICAgIGFueSBvdGhlciBz cmMgYW5kIGRzdCBVRFAgcG9ydHMgdGhhbiB0aGUgc3RhbmRhcmQgKDU0NiwgNTQ3KQ0KPiA+PiAg ICAgYW5kL29yIG5vbi1zdGFuZGFyZCB1bmljYXN0IGluc3RlYWQgb2Ygc3RhbmRhcmQgbXVsdGlj YXN0Lg0KPiA+Pg0KPiA+PiBPdGhlciByZWFzb25zIHByb3ZlZCBub3QgdG8gYmUgY2F1c2VzIG9m IGFic2VuY2Ugb2YgREhDUHY2IFBEIG9uDQo+ID4+IGNlbGx1bGFyIGxpbmtzOyB0aGV5IHdlcmUg anVzdCBzcGVjdWxhdGlvbnM6DQo+ID4+IC0gY2VsbHVsYXIgb3BlcmF0b3JzIGRvbnQgcHJvdmlk ZSBESENQdjYgUEQgc2VydmljZSAodGhlcmUgYXJlIHNvbWUgd2hvDQo+ID4+ICAgICBkbyB1bmRl ciBzb21lIG9wZXJhdGlvbmFsIGNvbmRpdGlvbnMpDQo+ID4+IC0gY2VsbHVsYXIgb3BlcmF0b3Jz IGhhdmUgYSBoYXJkIHRpbWUgbWFraW5nIGFuIElQdjYgYWRkcmVzc2luZw0KPiA+PiAgICAgYXJj aGl0ZWN0dXJlIHRoYXQgZGVsZWdhdGUgcHJlZml4ZXMgaW5zdGVhZCBvZiBhZGRyZXNzZXMgKHRo ZXJlIGFyZQ0KPiA+PiAgICAgc29tZSB3aG8gZG8gbWFrZSBzdWNoIGFyY2hpdGVjdHVyZSkNCj4g Pj4gLSBjZWxsdWxhciBvcGVyYXRvcnMgb25seSBkbyAnNjQnIChpdCdzIGZhbHNlLCBzb21lIGNv dWxkIGRvIGxlc3MsDQo+ID4+ICAgICBsaWtlIDU2IG9yIGV2ZW4gNDgpDQo+ID4+IC0gREhDUHY2 IHNvZnR3YXJlIGlzIG5vdCBhdmFpbGFibGUgb24gdGhlIGNsaWVudCAodGhlcmUgYXJlIHNvbWUs IGxpa2UNCj4gPj4gICAgIG9uIEFuZHJvaWQsIGFuZCBtb3JlLCBzZWUgcXVvdGVkIG1haWxzIGJl bG93KQ0KPiA+PiAtIHRoZSBjb21wdXRlciB0aGF0IHJ1bnMgdGhlIERIQ1B2NiBjbGllbnQgaXMg dGhlIHNhbWUgYXMgdGhlIG9uZSB0aGF0DQo+ID4+ICAgICBwdXRzIHRoZSBTb2xpY2l0IG9uIHRo ZSB3aXJlOiB0aGlzIGlzIG5vdCB0cnVlLCBiZWNhdXNlIGV2ZW4gaW4gdGhlDQo+ID4+ICAgICBz bWFsbGVzdCBVRSBpbiB0aGUgbWFya2V0IHRoZXJlIGlzIHN0aWxsIGRpc3RpbmN0aW9uIGFwcC12 cy1tb2RlbQ0KPiA+PiAgICAgcHJvY2Vzc29ycy4gIE9mdGVuIHRoZSBtb2RlbSBwYXJ0IGlzIGNv bmZpZGVudGlhbCwgb25seSB0aGUgYmluYXJ5DQo+ID4+ICAgICBpcyBhdmFpbGFibGUgdG8gdGhl IHB1YmxpYywgYW5kIHRoZXJlIGFyZSB0d28gSVBzIG9uIGl0OiBJbnRlcm5ldA0KPiA+PiAgICAg UHJvdG9jb2wgX2FuZF8gSW50ZWxsZWN0dWFsIFByb3BlcnR5Lg0KPiA+Pg0KPiA+PiBBbGV4LCB3 aXRoIHRoYW5rcyB0byBbSGFjaGF0YV0sIGFkbWluKHMpLCBtYW5hZ2VycywgYW5kIHRlY2huaWNh bHMgYXQNCj4gPj4gb2ZmaWNlcyBhbmQgb3JnYW5pc2F0aW9ucy4NCj4gPj4NCj4gPj4NCj4gPj4g TGUgMTgvMDgvMjAxNyDDoCAxODowNywgQWxleGFuZHJlIFBldHJlc2N1IGEgw6ljcml0IDoNCj4g Pj4+IEkgaGF2ZSBiZWVuIHBvaW50ZWQgYnkgYSBoZWxwZnVsIHBlcnNvbiB0aGF0IGFuIEFuZHJv aWQgYXBwIGZvcg0KPiA+Pj4gREhDUHY2IGV4aXN0cyB0aGVyZToNCj4gPj4+DQo+ID4+PiBodHRw czovL3BsYXkuZ29vZ2xlLmNvbS9zdG9yZS9hcHBzL2RldGFpbHM/aWQ9b3JnLmRhZHVrZS5yZWFs bWFyLmRoY3B2NmNsaWVudCZobD1mcg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ DQo+ID4+PiBJdCBpcyBiYXNlZCBvbiB0aGUgV0lERSBESENQdjYgY2xpZW50Lg0KPiA+Pj4NCj4g Pj4+IEZ1cnRoZXIgYnJvd3NpbmcgbGVhZHMgdG8gYSBkaXNjdXNzaW9uIG9mIERIQ1B2NiBvbiBB bmRyb2lkIHRvcGljOg0KPiA+Pj4gaHR0cHM6Ly9pc3N1ZXRyYWNrZXIuZ29vZ2xlLmNvbS9pc3N1 ZXMvMzY5NDkwODUNCj4gPj4+DQo+ID4+PiBBbGV4DQo+ID4+Pg0KPiA+Pj4gTGUgMTcvMDcvMjAx NyDDoCAxODoyNiwgQWxleGFuZHJlIFBldHJlc2N1IGEgw6ljcml0IDoNCj4gPj4+PiBXZWxsLCB0 aGlzIGlzIHRvIG5vdGUgdGhhdCB3ZSB0b28gKEZyZWQgbWVudGlvbmVkIGl0IHRvbyBlYXJsaWVy KQ0KPiA+Pj4+IG1hZGUgdGhlIElTQyBESENQdjYgZGhjbGllbnQgd29yayBvbiBBbmRyb2lkLCBp bmNsdWRpbmcgREhDUHY2DQo+ID4+Pj4gU29saWNpdCB0aGF0IHJlcXVlc3RzIFByZWZpeCBEZWxl Z2F0aW9uLg0KPiA+Pj4+DQo+ID4+Pj4gKGJ1dCB3ZSBzdGlsbCBkb250IGhhdmUgYSByZXNwb25z ZSB0byBESENQIFNvbGljaXQgb24gY2VsbHVsYXINCj4gPj4+PiBsaW5rKS4NCj4gPj4+Pg0KPiA+ Pj4+IEFsZXgNCj4gPj4+Pg0KPiA+Pj4+IExlIDA2LzA3LzIwMTcgw6AgMTg6MzIsIEFsZXhhbmRy ZSBQZXRyZXNjdSBhIMOpY3JpdCA6DQo+ID4+Pj4+IE1hcmssIG5vdGVkLCB3aWxsIHRyeS4NCj4g Pj4+Pj4NCj4gPj4+Pj4gSnVzdCBhIG5vdGUuLi4NCj4gPj4+Pj4NCj4gPj4+Pj4gTGUgMDYvMDcv MjAxNyDDoCAwMzoxNiwgTWFyayBBbmRyZXdzIGEgw6ljcml0IDoNCj4gPj4+Pj4+DQo+ID4+Pj4+ PiBJbiBtZXNzYWdlIDw3NTM3ZGVlZi04Zjg3LTUxODctMWU0NC01OTVhYzYzYTE2Y2FAZ21haWwu Y29tPiwNCj4gPj4+Pj4+IEFsZXhhbmRyZSBQZXRyZXNjdSB3cml0ZXM6DQo+ID4+Pj4+Pj4gSGVs bG8sDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBXZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgYWJvdXQg dGhlIHBvdGVudGlhbCB1c2Ugb2YgREhDUHY2DQo+ID4+Pj4+Pj4gUHJlZml4IERlbGVnYXRpb24g b24gY2VsbHVsYXIgbGlua3MuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBUaGUgY2hpY2tlbiBpc3N1 ZSBpcyB0aGUgbGFjayBvZiBESENQdjYgUEQgc29mdHdhcmUgb24NCj4gPj4+Pj4+PiB0eXBpY2Fs IFVzZXIgRXF1aXBtZW50LiAgRm9yIGV4YW1wbGUsIHRoZXJlIGlzIG5vIERIQ1B2Ni1QRA0KPiA+ Pj4+Pj4+IGFwcCBvbiBBbmRyb2lkLiAgVGhlIGVnZyBpc3N1ZSBpcyB0aGUgbGFjayBvZiBvcGVy YXRvcg0KPiA+Pj4+Pj4+IHN1cHBvcnQgb2YgREhDUHY2LVBEIHRvd2FyZHMgdGhlIFVzZXIgVGVy bWluYWwuICBGb3IgZXhhbXBsZSwNCj4gPj4+Pj4+PiB0aGVyZSBpcyBubyBjZWxsdWxhciBvcGVy YXRvciBhbnN3ZXJpbmcgdG8gREhDUHY2LVBEIHJlcXVlc3RzDQo+ID4+Pj4+Pj4gaXNzdWVkIGJ5 IHRoZSBVc2VyIFRlcm1pbmFsLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gVG8gYWRkcmVzcyB0aGUg Y2hpY2tlbiBpc3N1ZSwgd2Ugc3RhcnRlZCB3aXRoIGFuIElTQyBESENQDQo+ID4+Pj4+Pj4gb3Bl biBzb2Z0d2FyZSBjbGllbnQsIHdoaWNoIGRvZXMgaW1wbGVtZW50IFByZWZpeCBEZWxlZ2F0aW9u Lg0KPiA+Pj4+Pj4+IEl0IGNhbiBiZSAoY3Jvc3MpY29tcGlsZWQgb24gdmFyaW91cyBwbGF0Zm9y bXM7IHRoZW4gdHlwZQ0KPiA+Pj4+Pj4+ICIuL2RoY2xpZW50IC02IC1QIjsgdGhpcyBzZW5kcyBh biBESENQdjYgU29saWNpdCBJZGVudGl0eQ0KPiA+Pj4+Pj4+IEFzc29jaXRhaW9uIGZvciBQcmVm aXggRGVsZWdhdGlvbiBtZXNzYWdlIG9uIHRoZSBpbnRlcmZhY2UuDQo+ID4+Pj4+Pj4NCj4gPj4+ Pj4+PiBIb3dldmVyLCB3aGVyZWFzIHRoaXMgc29mdHdhcmUgcnVucyBvayBvbiBpbnRlcmZhY2Vz IHN1Y2ggYXMNCj4gPj4+Pj4+PiBFdGhlcm5ldCwgVVNCbmV0IGFuZCBXaUZpIGludGVyZmFjZXMs IGl0IGJyZWFrcyBpZiBydW4gb24gdGhlDQo+ID4+Pj4+Pj4gY2VsbHVsYXIgaW50ZXJmYWNlIG9m IHNvbWUgSW9UIGNlbGx1bGFyIHBsYXRmb3JtLiAgVGhlIGVycm9yDQo+ID4+Pj4+Pj4gY2FuIGJl IGNvcnJlY3RlZCBieSB0aGUgcXVpY2stYW5kLWRpcnR5IHNvbHV0aW9uIGJlbG93Lg0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+IFRoZSBoYWNrIHdvdWxkIGJlIGJldHRlciBhcw0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+ICNpZmRlZiBBUlBIUkRfWFhYWCBjYXNlIEFSUEhSRF9YWFhYOiBody0+aGxlbiA9IDc7IGh3 LT5oYnVmWzBdDQo+ID4+Pj4+PiAgID0gSFRZUEVfRVRIRVI7IG1lbWNweSgmaHctPmhidWZbMV0s IHNhLT5zYV9kYXRhLCA2KTsgYnJlYWs7DQo+ID4+Pj4+PiAjZW5kaWYgZGVmYXVsdDogbG9nX2Zh dGFsKCJVbnN1cHBvcnRlZCBkZXZpY2UgdHlwZSAlbGQgZm9yDQo+ID4+Pj4+PiBcIiVzXCIiLCAo bG9uZyBpbnQpc2EtPnNhX2ZhbWlseSwgbmFtZSk7IGJyZWFrOw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ IHdpdGggQVJQSFJEX1hYWFggYmVpbmcgcmVwbGFjZWQgYnkgdGhlIGNvcnJlY3QgbWFjcm8gZm9y IDUwMw0KPiA+Pj4+Pj4gZnJvbSA8bmV0L2lmX2FycC5oPi4gIFNvbWV0aGluZyBsaWtlIHRoYXQg aXMgYXQgbGVhc3QNCj4gPj4+Pj4+IHBvcnRhYmxlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBCdXQgaXQg bWVhbnMgd2hlbiBJIGdvIHRvIG90aGVyIHBsYXRmb3JtIHdpbGwgaGF2ZSB0byBtb2RpZnkNCj4g Pj4+Pj4gYWdhaW4gdGhlIElTQyBjbGllbnQgc291cmNlIGNvZGU/DQo+ID4+Pj4+DQo+ID4+Pj4+ IEluIGNlbGx1bGFyIHRlcm1pbmFscyB0aGVyZSBhcmUgc28gbWFueSBub24tSUVFRSBkaWZmZXJl bnQga2luZHMNCj4gPj4+Pj4gICBvZiBsaW5rcy4NCj4gPj4+Pj4NCj4gPj4+Pj4gT3RoZXIgY2xp ZW50cyB3b3JrIG91dCBvZiB0aGUgYm94IG9uIHRoaXMgLSBJIGFncmVlIHdpdGggeW91LA0KPiA+ Pj4+PiBzdHJhbmdlIC0gInJtbmV0MCIgaW50ZXJmYWNlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBBbGV4 DQo+ID4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQXMgZm9yIHRoZSByZXN0IG9mIGl0IEkgaGF2 ZSBubyBpZGVhIGFib3V0IHRoZSBwcmVzZW50ZWQNCj4gPj4+Pj4+IGhhcmR3YXJlIGFkZHJlc3Mg b2YgdGhpcyB0eXBlIHNvIEkgZG9uJ3Qga25vdyBpdCB0aGUgcmVzdCBvZiBpdA0KPiA+Pj4+Pj4g bWFrZSBzZW5zZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gQWxleA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+ Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4gVGhlIGVycm9yIHNheXMgIi8vVU5T VVBQT1JURUQgREVWSUNFIFRZUEUgNTAzIEZPUiBSTU5FVDAuIg0KPiA+Pj4+Pj4+IGRoY3AtNC4z LjUgLi9jb21tb24vbHBmLmMgbGluZSBudW1iZXI6IDU1MQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4g Ly9kZWZhdWx0OiAvLyAgICAgIGxvZ19mYXRhbCgiVW5zdXBwb3J0ZWQgZGV2aWNlIHR5cGUgJWxk DQo+ID4+Pj4+Pj4gZm9yIFwiJXNcIiIsIC8vICAgICAgICAgICAgICAgIChsb25nIGludClzYS0+ c2FfZmFtaWx5LA0KPiA+Pj4+Pj4+IG5hbWUpOyBkZWZhdWx0OiBody0+aGxlbiA9IDc7IGh3LT5o YnVmWzBdID0gSFRZUEVfRVRIRVI7DQo+ID4+Pj4+Pj4gbWVtY3B5KCZody0+aGJ1ZlsxXSwgc2Et PnNhX2RhdGEsIDYpOyBicmVhazsNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICh0d28gcHJvZ3JhbW1l cnMgd29ya2VkIHRoaXMgb3V0KS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEFsZXgNCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fIHY2b3BzDQo+ID4+Pj4+Pj4gbWFpbGluZyBsaXN0IHY2b3BzQGlldGYub3JnDQo+ID4+Pj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pj4+Pg0K PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2 Nm9wcyBtYWlsaW5nDQo+ID4+Pj4+IGxpc3QgdjZvcHNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gdjZvcHMgbWFpbGluZyBsaXN0DQo+ ID4+Pj4gdjZvcHNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fIHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+Pj4gdjZvcHNAaWV0Zi5vcmcgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pg0KPiA+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiB2Nm9wcyBt YWlsaW5nIGxpc3QNCj4gPj4gdjZvcHNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Tue Sep 5 12:59:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AB8129C41 for ; Tue, 5 Sep 2017 12:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgMnBf4kt0XB for ; Tue, 5 Sep 2017 12:59:18 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5521243F6 for ; Tue, 5 Sep 2017 12:59:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v85JxCiE010616; Tue, 5 Sep 2017 21:59:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8F817204C82; Tue, 5 Sep 2017 21:59:12 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 82393200FEC; Tue, 5 Sep 2017 21:59:12 +0200 (CEST) Received: from [132.166.84.111] ([132.166.84.111]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v85JxBpM032225; Tue, 5 Sep 2017 21:59:12 +0200 To: "Templin, Fred L" , "v6ops@ietf.org" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: Date: Tue, 5 Sep 2017 21:59:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 19:59:21 -0000 Hi Fred, Le 05/09/2017 à 21:54, Templin, Fred L a écrit : > Hi Alex, > >> -----Original Message----- >> From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] >> Sent: Tuesday, September 05, 2017 12:35 PM >> To: Templin, Fred L ; v6ops@ietf.org >> Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android >> >> >> >> Le 05/09/2017 à 18:06, Templin, Fred L a écrit : >>> Hi Alex, >>> >>>> -----Original Message----- >>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu >>>> Sent: Tuesday, September 05, 2017 8:39 AM >>>> To: v6ops@ietf.org >>>> Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android >>>> >>>> Hi, >>>> >>>> I want to update the list about our advancements. >>>> >>>> We are exploring the question of why DHCPv6 Prefix Delegation is not >>>> used on cellular links. This lack of PD support has bad side effects: >>>> an INFORMATIONAL RFC 64share becomes more and more used, Mobile Routers >>>> are impossible. >>>> >>>> Here are the unique reasons - if solely these are solved then we get PD >>>> on cellular: >>>> - some modems in the UE (e.g. QDSP6 and others) block standard DHCPv6 >>>> UDP port numbers 546 and 547 and (and sometimes or) standard IP >>>> multicast addressing in both directions; this blocking was identified >>>> by comparing packet dumps on the ARM part of UE, vs on PGW; >>>> this blocking was further confirmed by successful Sol/Adv on unicast >>>> and non-std UDP ports. >>>> This blocking happens even though the application processor (e.g. ARM) >>>> does not block them. >>>> These ports and multicast are absolutely needed for Prefix Delegation, >>>> because Prefix Delegation runs as an integral part of DHCPv6. >>>> - much less likely, it may be that some infrastructure entities like >>>> Base Station or SGW - again, very little probable - blocks same DHCP >>>> ports and multicast. >>>> - DHCPv6 software is little parametrable or portable, even though much >>>> source is available openly. >>>> >>>> Some details: >>>> - the DHCPv6 software on Android is hampered by the need of root access. >>>> Android blocks that. One needs to ask the platform manufacturer >>>> running that Android to "root" the platform such as to be able to run >>>> some of the DHCP client software (e.g. ask Huawei for a key to root >>>> the smartphone). That's a real pain. There is a risk of "bricking" >>>> your platform, i.e. through it out a window. >>> >>> You don't need to root the device to run DHCPv6 PD over a VPN: >>> >>> https://developer.android.com/reference/android/net/VpnService.html >>> >>> Again, we have DHCPv6 PD working fine over a VPN. >> >> That is good to know. >> >> In my setting I need DHCPv6-PD as unencapsulated as possible - just >> straight. >> >> (on IPv6 cellular links there is already IPv6-in-GTPU encapsulation, >> which is an IPv4 protocol, that is hard to get rid of; a 2nd >> encapsulation for VPN, or a 3rd encapsulation for Mobile IP means >> additional overhead in terms of packet headers, intelligence to maintain >> tunnels up, etc) > > At least one freely-available VPN app I am aware of uses LZO whole > message compression, which can attenuate the extra overhead to > a considerable extent. That is the overhead of packets that could be reduced. I agree. But the software of maintaining that VPN tunnel up upon handover is also considerable, and no compression mechanism could reduce it. > Plus, using the VPN may be compatible with the security policy. For > example, for a cellphone in the Internet connecting into a home > enterprise network the use of VPNs would be consistent with the > security model. Yes, I agree with this point. I have not given much consideration to security. I wonder whether it can be possible to set the VPN up after the DHCPv6-PD exchange happened between the operator and the smartphone. Alex > > Thanks - Fred > >> Alex >> >>> >>> Thanks - Fred >>> >>>> - to make an app available to everyone on Android one must pay some >>>> money to become a member of a store. DHCP should not be part of that, >>>> as SLAAC isnt; just like SLAAC, DHCP should be builtin for free. >>>> - the DHCPv6 server software "ISC" breaks if the port numbers are >>>> non-standard (not 546 nor 547) or unicast instead of multicast. >>>> (e.g. "Discarding Solicit from [snip]; packet sent unicast") >>>> This was a real pain, because we had to modify the source code >>>> to allow it; other software like VoIP has SIP ports this configurable >>>> easily with a GUI. >>>> - Cisco parametering CLI of DHCPv6 service may have some problems in >>>> transforming a non-standard UDP port 546 of Solicit to a strange >>>> 26483. That was a real pain to one. >>>> - various DHCPv6 client software break, or do not even start, with >>>> any other src and dst UDP ports than the standard (546, 547) >>>> and/or non-standard unicast instead of standard multicast. >>>> >>>> Other reasons proved not to be causes of absence of DHCPv6 PD on >>>> cellular links; they were just speculations: >>>> - cellular operators dont provide DHCPv6 PD service (there are some who >>>> do under some operational conditions) >>>> - cellular operators have a hard time making an IPv6 addressing >>>> architecture that delegate prefixes instead of addresses (there are >>>> some who do make such architecture) >>>> - cellular operators only do '64' (it's false, some could do less, >>>> like 56 or even 48) >>>> - DHCPv6 software is not available on the client (there are some, like >>>> on Android, and more, see quoted mails below) >>>> - the computer that runs the DHCPv6 client is the same as the one that >>>> puts the Solicit on the wire: this is not true, because even in the >>>> smallest UE in the market there is still distinction app-vs-modem >>>> processors. Often the modem part is confidential, only the binary >>>> is available to the public, and there are two IPs on it: Internet >>>> Protocol _and_ Intellectual Property. >>>> >>>> Alex, with thanks to [Hachata], admin(s), managers, and technicals at >>>> offices and organisations. >>>> >>>> >>>> Le 18/08/2017 à 18:07, Alexandre Petrescu a écrit : >>>>> I have been pointed by a helpful person that an Android app for >>>>> DHCPv6 exists there: >>>>> >>>>> https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client&hl=fr >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> It is based on the WIDE DHCPv6 client. >>>>> >>>>> Further browsing leads to a discussion of DHCPv6 on Android topic: >>>>> https://issuetracker.google.com/issues/36949085 >>>>> >>>>> Alex >>>>> >>>>> Le 17/07/2017 à 18:26, Alexandre Petrescu a écrit : >>>>>> Well, this is to note that we too (Fred mentioned it too earlier) >>>>>> made the ISC DHCPv6 dhclient work on Android, including DHCPv6 >>>>>> Solicit that requests Prefix Delegation. >>>>>> >>>>>> (but we still dont have a response to DHCP Solicit on cellular >>>>>> link). >>>>>> >>>>>> Alex >>>>>> >>>>>> Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit : >>>>>>> Mark, noted, will try. >>>>>>> >>>>>>> Just a note... >>>>>>> >>>>>>> Le 06/07/2017 à 03:16, Mark Andrews a écrit : >>>>>>>> >>>>>>>> In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, >>>>>>>> Alexandre Petrescu writes: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> We discussed extensively about the potential use of DHCPv6 >>>>>>>>> Prefix Delegation on cellular links. >>>>>>>>> >>>>>>>>> The chicken issue is the lack of DHCPv6 PD software on >>>>>>>>> typical User Equipment. For example, there is no DHCPv6-PD >>>>>>>>> app on Android. The egg issue is the lack of operator >>>>>>>>> support of DHCPv6-PD towards the User Terminal. For example, >>>>>>>>> there is no cellular operator answering to DHCPv6-PD requests >>>>>>>>> issued by the User Terminal. >>>>>>>>> >>>>>>>>> To address the chicken issue, we started with an ISC DHCP >>>>>>>>> open software client, which does implement Prefix Delegation. >>>>>>>>> It can be (cross)compiled on various platforms; then type >>>>>>>>> "./dhclient -6 -P"; this sends an DHCPv6 Solicit Identity >>>>>>>>> Associtaion for Prefix Delegation message on the interface. >>>>>>>>> >>>>>>>>> However, whereas this software runs ok on interfaces such as >>>>>>>>> Ethernet, USBnet and WiFi interfaces, it breaks if run on the >>>>>>>>> cellular interface of some IoT cellular platform. The error >>>>>>>>> can be corrected by the quick-and-dirty solution below. >>>>>>>> >>>>>>>> The hack would be better as >>>>>>>> >>>>>>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; hw->hbuf[0] >>>>>>>> = HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>>>>>> #endif default: log_fatal("Unsupported device type %ld for >>>>>>>> \"%s\"", (long int)sa->sa_family, name); break; >>>>>>>> >>>>>>>> with ARPHRD_XXXX being replaced by the correct macro for 503 >>>>>>>> from . Something like that is at least >>>>>>>> portable. >>>>>>> >>>>>>> But it means when I go to other platform will have to modify >>>>>>> again the ISC client source code? >>>>>>> >>>>>>> In cellular terminals there are so many non-IEEE different kinds >>>>>>> of links. >>>>>>> >>>>>>> Other clients work out of the box on this - I agree with you, >>>>>>> strange - "rmnet0" interface. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> >>>>>>>> As for the rest of it I have no idea about the presented >>>>>>>> hardware address of this type so I don't know it the rest of it >>>>>>>> make sense. >>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0." >>>>>>>>> dhcp-4.3.5 ./common/lpf.c line number: 551 >>>>>>>>> >>>>>>>>> //default: // log_fatal("Unsupported device type %ld >>>>>>>>> for \"%s\"", // (long int)sa->sa_family, >>>>>>>>> name); default: hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; >>>>>>>>> memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>>>>>>> >>>>>>>>> (two programmers worked this out). >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> _______________________________________________ v6ops >>>>>>>>> mailing list v6ops@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>> >>>>>>> _______________________________________________ v6ops mailing >>>>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>>>> >>>>>> _______________________________________________ v6ops mailing list >>>>>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> _______________________________________________ v6ops mailing list >>>>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Sep 5 13:07:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24092128D0D for ; Tue, 5 Sep 2017 13:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTanx7CbtofN for ; Tue, 5 Sep 2017 13:07:21 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C955126DD9 for ; Tue, 5 Sep 2017 13:07:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v85K7JLB032049; Tue, 5 Sep 2017 13:07:20 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v85K7JGV032045 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 5 Sep 2017 13:07:19 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Sep 2017 13:07:18 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 5 Sep 2017 13:07:18 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] DHCPv6 PD client on cellular on Android Thread-Index: AQHTJl1GQaHk8JRqwk2mcUUbqG/ToKKmdHgQgACwUgD//46dcIAAeBiA//+LG4A= Date: Tue, 5 Sep 2017 20:07:18 +0000 Message-ID: <152f893f24224371aa94ce1bbd54935b@XCH15-06-08.nw.nos.boeing.com> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:07:23 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cmUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTcgMTI6NTkgUE0NCj4gVG86IFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IHY2b3BzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbdjZvcHNdIERIQ1B2NiBQRCBjbGllbnQgb24gY2VsbHVsYXIgb24gQW5kcm9pZA0K PiANCj4gSGkgRnJlZCwNCj4gDQo+IExlIDA1LzA5LzIwMTcgw6AgMjE6NTQsIFRlbXBsaW4sIEZy ZWQgTCBhIMOpY3JpdMKgOg0KPiA+IEhpIEFsZXgsDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogQWxleGFuZHJlIFBldHJlc2N1IFttYWlsdG86YWxleGFu ZHJlLnBldHJlc2N1QGdtYWlsLmNvbV0NCj4gPj4gU2VudDogVHVlc2RheSwgU2VwdGVtYmVyIDA1 LCAyMDE3IDEyOjM1IFBNDQo+ID4+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20+OyB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBE SENQdjYgUEQgY2xpZW50IG9uIGNlbGx1bGFyIG9uIEFuZHJvaWQNCj4gPj4NCj4gPj4NCj4gPj4N Cj4gPj4gTGUgMDUvMDkvMjAxNyDDoCAxODowNiwgVGVtcGxpbiwgRnJlZCBMIGEgw6ljcml0wqA6 DQo+ID4+PiBIaSBBbGV4LA0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+Pj4+IEZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFsZXhhbmRyZSBQZXRyZXNjdQ0KPiA+Pj4+IFNlbnQ6IFR1ZXNkYXksIFNlcHRl bWJlciAwNSwgMjAxNyA4OjM5IEFNDQo+ID4+Pj4gVG86IHY2b3BzQGlldGYub3JnDQo+ID4+Pj4g U3ViamVjdDogUmU6IFt2Nm9wc10gREhDUHY2IFBEIGNsaWVudCBvbiBjZWxsdWxhciBvbiBBbmRy b2lkDQo+ID4+Pj4NCj4gPj4+PiBIaSwNCj4gPj4+Pg0KPiA+Pj4+IEkgd2FudCB0byB1cGRhdGUg dGhlIGxpc3QgYWJvdXQgb3VyIGFkdmFuY2VtZW50cy4NCj4gPj4+Pg0KPiA+Pj4+IFdlIGFyZSBl eHBsb3JpbmcgdGhlIHF1ZXN0aW9uIG9mIHdoeSBESENQdjYgUHJlZml4IERlbGVnYXRpb24gaXMg bm90DQo+ID4+Pj4gdXNlZCBvbiBjZWxsdWxhciBsaW5rcy4gIFRoaXMgbGFjayBvZiBQRCBzdXBw b3J0IGhhcyBiYWQgc2lkZSBlZmZlY3RzOg0KPiA+Pj4+IGFuIElORk9STUFUSU9OQUwgUkZDIDY0 c2hhcmUgYmVjb21lcyBtb3JlIGFuZCBtb3JlIHVzZWQsIE1vYmlsZSBSb3V0ZXJzDQo+ID4+Pj4g YXJlIGltcG9zc2libGUuDQo+ID4+Pj4NCj4gPj4+PiBIZXJlIGFyZSB0aGUgdW5pcXVlIHJlYXNv bnMgLSBpZiBzb2xlbHkgdGhlc2UgYXJlIHNvbHZlZCB0aGVuIHdlIGdldCBQRA0KPiA+Pj4+IG9u IGNlbGx1bGFyOg0KPiA+Pj4+IC0gc29tZSBtb2RlbXMgaW4gdGhlIFVFIChlLmcuIFFEU1A2IGFu ZCBvdGhlcnMpIGJsb2NrIHN0YW5kYXJkIERIQ1B2Ng0KPiA+Pj4+ICAgICAgVURQIHBvcnQgbnVt YmVycyA1NDYgYW5kIDU0NyBhbmQgKGFuZCBzb21ldGltZXMgb3IpIHN0YW5kYXJkIElQDQo+ID4+ Pj4gICAgICBtdWx0aWNhc3QgYWRkcmVzc2luZyBpbiBib3RoIGRpcmVjdGlvbnM7IHRoaXMgYmxv Y2tpbmcgd2FzIGlkZW50aWZpZWQNCj4gPj4+PiAgICAgIGJ5IGNvbXBhcmluZyBwYWNrZXQgZHVt cHMgb24gdGhlIEFSTSBwYXJ0IG9mIFVFLCB2cyBvbiBQR1c7DQo+ID4+Pj4gICAgICB0aGlzIGJs b2NraW5nIHdhcyBmdXJ0aGVyIGNvbmZpcm1lZCBieSBzdWNjZXNzZnVsIFNvbC9BZHYgb24gdW5p Y2FzdA0KPiA+Pj4+ICAgICAgYW5kIG5vbi1zdGQgVURQIHBvcnRzLg0KPiA+Pj4+ICAgICAgVGhp cyBibG9ja2luZyBoYXBwZW5zIGV2ZW4gdGhvdWdoIHRoZSBhcHBsaWNhdGlvbiBwcm9jZXNzb3Ig KGUuZy4gQVJNKQ0KPiA+Pj4+ICAgICAgZG9lcyBub3QgYmxvY2sgdGhlbS4NCj4gPj4+PiAgICAg IFRoZXNlIHBvcnRzIGFuZCBtdWx0aWNhc3QgYXJlIGFic29sdXRlbHkgbmVlZGVkIGZvciBQcmVm aXggRGVsZWdhdGlvbiwNCj4gPj4+PiAgICAgIGJlY2F1c2UgUHJlZml4IERlbGVnYXRpb24gcnVu cyBhcyBhbiBpbnRlZ3JhbCBwYXJ0IG9mIERIQ1B2Ni4NCj4gPj4+PiAtIG11Y2ggbGVzcyBsaWtl bHksIGl0IG1heSBiZSB0aGF0IHNvbWUgaW5mcmFzdHJ1Y3R1cmUgZW50aXRpZXMgbGlrZQ0KPiA+ Pj4+ICAgICAgQmFzZSBTdGF0aW9uIG9yIFNHVyAtIGFnYWluLCB2ZXJ5IGxpdHRsZSBwcm9iYWJs ZSAtIGJsb2NrcyBzYW1lIERIQ1ANCj4gPj4+PiAgICAgIHBvcnRzIGFuZCBtdWx0aWNhc3QuDQo+ ID4+Pj4gLSBESENQdjYgc29mdHdhcmUgaXMgbGl0dGxlIHBhcmFtZXRyYWJsZSBvciBwb3J0YWJs ZSwgZXZlbiB0aG91Z2ggbXVjaA0KPiA+Pj4+ICAgICAgc291cmNlIGlzIGF2YWlsYWJsZSBvcGVu bHkuDQo+ID4+Pj4NCj4gPj4+PiBTb21lIGRldGFpbHM6DQo+ID4+Pj4gLSB0aGUgREhDUHY2IHNv ZnR3YXJlIG9uIEFuZHJvaWQgaXMgaGFtcGVyZWQgYnkgdGhlIG5lZWQgb2Ygcm9vdCBhY2Nlc3Mu DQo+ID4+Pj4gICAgICBBbmRyb2lkIGJsb2NrcyB0aGF0LiAgT25lIG5lZWRzIHRvIGFzayB0aGUg cGxhdGZvcm0gbWFudWZhY3R1cmVyDQo+ID4+Pj4gICAgICBydW5uaW5nIHRoYXQgQW5kcm9pZCB0 byAicm9vdCIgdGhlIHBsYXRmb3JtIHN1Y2ggYXMgdG8gYmUgYWJsZSB0byBydW4NCj4gPj4+PiAg ICAgIHNvbWUgb2YgdGhlIERIQ1AgY2xpZW50IHNvZnR3YXJlIChlLmcuIGFzayBIdWF3ZWkgZm9y IGEga2V5IHRvIHJvb3QNCj4gPj4+PiAgICAgIHRoZSBzbWFydHBob25lKS4gIFRoYXQncyBhIHJl YWwgcGFpbi4gIFRoZXJlIGlzIGEgcmlzayBvZiAiYnJpY2tpbmciDQo+ID4+Pj4gICAgICB5b3Vy IHBsYXRmb3JtLCBpLmUuIHRocm91Z2ggaXQgb3V0IGEgd2luZG93Lg0KPiA+Pj4NCj4gPj4+IFlv dSBkb24ndCBuZWVkIHRvIHJvb3QgdGhlIGRldmljZSB0byBydW4gREhDUHY2IFBEIG92ZXIgYSBW UE46DQo+ID4+Pg0KPiA+Pj4gaHR0cHM6Ly9kZXZlbG9wZXIuYW5kcm9pZC5jb20vcmVmZXJlbmNl L2FuZHJvaWQvbmV0L1ZwblNlcnZpY2UuaHRtbA0KPiA+Pj4NCj4gPj4+IEFnYWluLCB3ZSBoYXZl IERIQ1B2NiBQRCB3b3JraW5nIGZpbmUgb3ZlciBhIFZQTi4NCj4gPj4NCj4gPj4gVGhhdCBpcyBn b29kIHRvIGtub3cuDQo+ID4+DQo+ID4+IEluIG15IHNldHRpbmcgSSBuZWVkIERIQ1B2Ni1QRCBh cyB1bmVuY2Fwc3VsYXRlZCBhcyBwb3NzaWJsZSAtIGp1c3QNCj4gPj4gc3RyYWlnaHQuDQo+ID4+ DQo+ID4+IChvbiBJUHY2IGNlbGx1bGFyIGxpbmtzIHRoZXJlIGlzIGFscmVhZHkgSVB2Ni1pbi1H VFBVIGVuY2Fwc3VsYXRpb24sDQo+ID4+IHdoaWNoIGlzIGFuIElQdjQgcHJvdG9jb2wsIHRoYXQg aXMgaGFyZCB0byBnZXQgcmlkIG9mOyAgYSAybmQNCj4gPj4gZW5jYXBzdWxhdGlvbiBmb3IgVlBO LCBvciBhIDNyZCBlbmNhcHN1bGF0aW9uIGZvciBNb2JpbGUgSVAgbWVhbnMNCj4gPj4gYWRkaXRp b25hbCBvdmVyaGVhZCBpbiB0ZXJtcyBvZiBwYWNrZXQgaGVhZGVycywgaW50ZWxsaWdlbmNlIHRv IG1haW50YWluDQo+ID4+IHR1bm5lbHMgdXAsIGV0YykNCj4gPg0KPiA+IEF0IGxlYXN0IG9uZSBm cmVlbHktYXZhaWxhYmxlIFZQTiBhcHAgSSBhbSBhd2FyZSBvZiB1c2VzIExaTyB3aG9sZQ0KPiA+ IG1lc3NhZ2UgY29tcHJlc3Npb24sIHdoaWNoIGNhbiBhdHRlbnVhdGUgdGhlIGV4dHJhIG92ZXJo ZWFkIHRvDQo+ID4gYSBjb25zaWRlcmFibGUgZXh0ZW50Lg0KPiANCj4gVGhhdCBpcyB0aGUgb3Zl cmhlYWQgb2YgcGFja2V0cyB0aGF0IGNvdWxkIGJlIHJlZHVjZWQuICBJIGFncmVlLg0KPiANCj4g QnV0IHRoZSBzb2Z0d2FyZSBvZiBtYWludGFpbmluZyB0aGF0IFZQTiB0dW5uZWwgdXAgdXBvbiBo YW5kb3ZlciBpcyBhbHNvDQo+IGNvbnNpZGVyYWJsZSwgYW5kIG5vIGNvbXByZXNzaW9uIG1lY2hh bmlzbSBjb3VsZCByZWR1Y2UgaXQuDQoNCkRvIHlvdSBtZWFuIGhhbmRvdmVyIGZyb20gb25lIGNl bGx1bGFyIGJhc2Ugc3RhdGlvbiB0byBhIHNlY29uZCBjZWxsdWxhcg0KYmFzZSBzdGF0aW9uPyBG cm9tIGNlbGx1bGFyIHRvIHdpcmVsZXNzPyBTb21ldGhpbmcgZWxzZT8gSW4gYW55IGV2ZW50IHRo ZQ0KaGFuZG92ZXIgaXMgYWNjb21tb2RhdGVkIGJ5IGEgc21hbGwgZXhjaGFuZ2Ugb2YgY29udHJv bCBtZXNzYWdlcywgYnV0DQp0aGUgVlBOIHNlcnZpY2UgaXRzZWxmIGNvbnRpbnVlcyB1bmludGVy cnVwdGVkLiBIZW5jZSwgaXQgaXMgYSBNb2JpbGUgVlBOLg0KDQo+ID4gUGx1cywgdXNpbmcgdGhl IFZQTiBtYXkgYmUgY29tcGF0aWJsZSB3aXRoIHRoZSBzZWN1cml0eSBwb2xpY3kuIEZvcg0KPiA+ IGV4YW1wbGUsIGZvciBhIGNlbGxwaG9uZSBpbiB0aGUgSW50ZXJuZXQgY29ubmVjdGluZyBpbnRv IGEgaG9tZQ0KPiA+IGVudGVycHJpc2UgbmV0d29yayB0aGUgdXNlIG9mIFZQTnMgd291bGQgYmUg Y29uc2lzdGVudCB3aXRoIHRoZQ0KPiA+IHNlY3VyaXR5IG1vZGVsLg0KPiANCj4gWWVzLCBJIGFn cmVlIHdpdGggdGhpcyBwb2ludC4NCj4gSSBoYXZlIG5vdCBnaXZlbiBtdWNoIGNvbnNpZGVyYXRp b24gdG8gc2VjdXJpdHkuDQoNCk9LLg0KDQo+IEkgd29uZGVyIHdoZXRoZXIgaXQgY2FuIGJlIHBv c3NpYmxlIHRvIHNldCB0aGUgVlBOIHVwIGFmdGVyIHRoZQ0KPiBESENQdjYtUEQgZXhjaGFuZ2Ug aGFwcGVuZWQgYmV0d2VlbiB0aGUgb3BlcmF0b3IgYW5kIHRoZSBzbWFydHBob25lLg0KDQpUaGUg c3lzdGVtIEkgYW0gZGVzY3JpYmluZyBmaXJzdCBvYnRhaW5zIGFuIGFkZHJlc3MgZnJvbSB0aGUg b3BlcmF0b3INCmFuZCBuZXh0IHNldHMgdXAgdGhlIFZQTiB1c2luZyB0aGUgb3BlcmF0b3IncyBz ZXJ2aWNlIGFzIGEgbGluayBsYXllci4NCg0KVGhhbmtzIC0gRnJlZA0KDQo+IEFsZXgNCj4gDQo+ ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4NCj4gPj4gQWxleA0KPiA+Pg0KPiA+Pj4NCj4gPj4+ IFRoYW5rcyAtIEZyZWQNCj4gPj4+DQo+ID4+Pj4gLSB0byBtYWtlIGFuIGFwcCBhdmFpbGFibGUg dG8gZXZlcnlvbmUgb24gQW5kcm9pZCBvbmUgbXVzdCBwYXkgc29tZQ0KPiA+Pj4+ICAgICAgbW9u ZXkgdG8gYmVjb21lIGEgbWVtYmVyIG9mIGEgc3RvcmUuICBESENQIHNob3VsZCBub3QgYmUgcGFy dCBvZiB0aGF0LA0KPiA+Pj4+ICAgICAgYXMgU0xBQUMgaXNudDsganVzdCBsaWtlIFNMQUFDLCBE SENQIHNob3VsZCBiZSBidWlsdGluIGZvciBmcmVlLg0KPiA+Pj4+IC0gdGhlIERIQ1B2NiBzZXJ2 ZXIgc29mdHdhcmUgIklTQyIgYnJlYWtzIGlmIHRoZSBwb3J0IG51bWJlcnMgYXJlDQo+ID4+Pj4g ICAgICBub24tc3RhbmRhcmQgKG5vdCA1NDYgbm9yIDU0Nykgb3IgdW5pY2FzdCBpbnN0ZWFkIG9m IG11bHRpY2FzdC4NCj4gPj4+PiAgICAgIChlLmcuICJEaXNjYXJkaW5nIFNvbGljaXQgZnJvbSBb c25pcF07IHBhY2tldCBzZW50IHVuaWNhc3QiKQ0KPiA+Pj4+ICAgICAgVGhpcyB3YXMgYSByZWFs IHBhaW4sIGJlY2F1c2Ugd2UgaGFkIHRvIG1vZGlmeSB0aGUgc291cmNlIGNvZGUNCj4gPj4+PiAg ICAgIHRvIGFsbG93IGl0OyBvdGhlciBzb2Z0d2FyZSBsaWtlIFZvSVAgaGFzIFNJUCBwb3J0cyB0 aGlzIGNvbmZpZ3VyYWJsZQ0KPiA+Pj4+ICAgICAgZWFzaWx5IHdpdGggYSBHVUkuDQo+ID4+Pj4g LSBDaXNjbyBwYXJhbWV0ZXJpbmcgQ0xJIG9mIERIQ1B2NiBzZXJ2aWNlIG1heSBoYXZlIHNvbWUg cHJvYmxlbXMgaW4NCj4gPj4+PiAgICAgIHRyYW5zZm9ybWluZyBhIG5vbi1zdGFuZGFyZCBVRFAg cG9ydCA1NDYgb2YgU29saWNpdCB0byBhIHN0cmFuZ2UNCj4gPj4+PiAgICAgIDI2NDgzLiAgVGhh dCB3YXMgYSByZWFsIHBhaW4gdG8gb25lLg0KPiA+Pj4+IC0gdmFyaW91cyBESENQdjYgY2xpZW50 IHNvZnR3YXJlIGJyZWFrLCBvciBkbyBub3QgZXZlbiBzdGFydCwgd2l0aA0KPiA+Pj4+ICAgICAg YW55IG90aGVyIHNyYyBhbmQgZHN0IFVEUCBwb3J0cyB0aGFuIHRoZSBzdGFuZGFyZCAoNTQ2LCA1 NDcpDQo+ID4+Pj4gICAgICBhbmQvb3Igbm9uLXN0YW5kYXJkIHVuaWNhc3QgaW5zdGVhZCBvZiBz dGFuZGFyZCBtdWx0aWNhc3QuDQo+ID4+Pj4NCj4gPj4+PiBPdGhlciByZWFzb25zIHByb3ZlZCBu b3QgdG8gYmUgY2F1c2VzIG9mIGFic2VuY2Ugb2YgREhDUHY2IFBEIG9uDQo+ID4+Pj4gY2VsbHVs YXIgbGlua3M7IHRoZXkgd2VyZSBqdXN0IHNwZWN1bGF0aW9uczoNCj4gPj4+PiAtIGNlbGx1bGFy IG9wZXJhdG9ycyBkb250IHByb3ZpZGUgREhDUHY2IFBEIHNlcnZpY2UgKHRoZXJlIGFyZSBzb21l IHdobw0KPiA+Pj4+ICAgICAgZG8gdW5kZXIgc29tZSBvcGVyYXRpb25hbCBjb25kaXRpb25zKQ0K PiA+Pj4+IC0gY2VsbHVsYXIgb3BlcmF0b3JzIGhhdmUgYSBoYXJkIHRpbWUgbWFraW5nIGFuIElQ djYgYWRkcmVzc2luZw0KPiA+Pj4+ICAgICAgYXJjaGl0ZWN0dXJlIHRoYXQgZGVsZWdhdGUgcHJl Zml4ZXMgaW5zdGVhZCBvZiBhZGRyZXNzZXMgKHRoZXJlIGFyZQ0KPiA+Pj4+ICAgICAgc29tZSB3 aG8gZG8gbWFrZSBzdWNoIGFyY2hpdGVjdHVyZSkNCj4gPj4+PiAtIGNlbGx1bGFyIG9wZXJhdG9y cyBvbmx5IGRvICc2NCcgKGl0J3MgZmFsc2UsIHNvbWUgY291bGQgZG8gbGVzcywNCj4gPj4+PiAg ICAgIGxpa2UgNTYgb3IgZXZlbiA0OCkNCj4gPj4+PiAtIERIQ1B2NiBzb2Z0d2FyZSBpcyBub3Qg YXZhaWxhYmxlIG9uIHRoZSBjbGllbnQgKHRoZXJlIGFyZSBzb21lLCBsaWtlDQo+ID4+Pj4gICAg ICBvbiBBbmRyb2lkLCBhbmQgbW9yZSwgc2VlIHF1b3RlZCBtYWlscyBiZWxvdykNCj4gPj4+PiAt IHRoZSBjb21wdXRlciB0aGF0IHJ1bnMgdGhlIERIQ1B2NiBjbGllbnQgaXMgdGhlIHNhbWUgYXMg dGhlIG9uZSB0aGF0DQo+ID4+Pj4gICAgICBwdXRzIHRoZSBTb2xpY2l0IG9uIHRoZSB3aXJlOiB0 aGlzIGlzIG5vdCB0cnVlLCBiZWNhdXNlIGV2ZW4gaW4gdGhlDQo+ID4+Pj4gICAgICBzbWFsbGVz dCBVRSBpbiB0aGUgbWFya2V0IHRoZXJlIGlzIHN0aWxsIGRpc3RpbmN0aW9uIGFwcC12cy1tb2Rl bQ0KPiA+Pj4+ICAgICAgcHJvY2Vzc29ycy4gIE9mdGVuIHRoZSBtb2RlbSBwYXJ0IGlzIGNvbmZp ZGVudGlhbCwgb25seSB0aGUgYmluYXJ5DQo+ID4+Pj4gICAgICBpcyBhdmFpbGFibGUgdG8gdGhl IHB1YmxpYywgYW5kIHRoZXJlIGFyZSB0d28gSVBzIG9uIGl0OiBJbnRlcm5ldA0KPiA+Pj4+ICAg ICAgUHJvdG9jb2wgX2FuZF8gSW50ZWxsZWN0dWFsIFByb3BlcnR5Lg0KPiA+Pj4+DQo+ID4+Pj4g QWxleCwgd2l0aCB0aGFua3MgdG8gW0hhY2hhdGFdLCBhZG1pbihzKSwgbWFuYWdlcnMsIGFuZCB0 ZWNobmljYWxzIGF0DQo+ID4+Pj4gb2ZmaWNlcyBhbmQgb3JnYW5pc2F0aW9ucy4NCj4gPj4+Pg0K PiA+Pj4+DQo+ID4+Pj4gTGUgMTgvMDgvMjAxNyDDoCAxODowNywgQWxleGFuZHJlIFBldHJlc2N1 IGEgw6ljcml0IDoNCj4gPj4+Pj4gSSBoYXZlIGJlZW4gcG9pbnRlZCBieSBhIGhlbHBmdWwgcGVy c29uIHRoYXQgYW4gQW5kcm9pZCBhcHAgZm9yDQo+ID4+Pj4+IERIQ1B2NiBleGlzdHMgdGhlcmU6 DQo+ID4+Pj4+DQo+ID4+Pj4+IGh0dHBzOi8vcGxheS5nb29nbGUuY29tL3N0b3JlL2FwcHMvZGV0 YWlscz9pZD1vcmcuZGFkdWtlLnJlYWxtYXIuZGhjcHY2Y2xpZW50JmhsPWZyDQo+ID4+Pj4+DQo+ ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IEl0IGlzIGJhc2VkIG9u IHRoZSBXSURFIERIQ1B2NiBjbGllbnQuDQo+ID4+Pj4+DQo+ID4+Pj4+IEZ1cnRoZXIgYnJvd3Np bmcgbGVhZHMgdG8gYSBkaXNjdXNzaW9uIG9mIERIQ1B2NiBvbiBBbmRyb2lkIHRvcGljOg0KPiA+ Pj4+PiBodHRwczovL2lzc3VldHJhY2tlci5nb29nbGUuY29tL2lzc3Vlcy8zNjk0OTA4NQ0KPiA+ Pj4+Pg0KPiA+Pj4+PiBBbGV4DQo+ID4+Pj4+DQo+ID4+Pj4+IExlIDE3LzA3LzIwMTcgw6AgMTg6 MjYsIEFsZXhhbmRyZSBQZXRyZXNjdSBhIMOpY3JpdCA6DQo+ID4+Pj4+PiBXZWxsLCB0aGlzIGlz IHRvIG5vdGUgdGhhdCB3ZSB0b28gKEZyZWQgbWVudGlvbmVkIGl0IHRvbyBlYXJsaWVyKQ0KPiA+ Pj4+Pj4gbWFkZSB0aGUgSVNDIERIQ1B2NiBkaGNsaWVudCB3b3JrIG9uIEFuZHJvaWQsIGluY2x1 ZGluZyBESENQdjYNCj4gPj4+Pj4+IFNvbGljaXQgdGhhdCByZXF1ZXN0cyBQcmVmaXggRGVsZWdh dGlvbi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAoYnV0IHdlIHN0aWxsIGRvbnQgaGF2ZSBhIHJlc3Bv bnNlIHRvIERIQ1AgU29saWNpdCBvbiBjZWxsdWxhcg0KPiA+Pj4+Pj4gbGluaykuDQo+ID4+Pj4+ Pg0KPiA+Pj4+Pj4gQWxleA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IExlIDA2LzA3LzIwMTcgw6AgMTg6 MzIsIEFsZXhhbmRyZSBQZXRyZXNjdSBhIMOpY3JpdCA6DQo+ID4+Pj4+Pj4gTWFyaywgbm90ZWQs IHdpbGwgdHJ5Lg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSnVzdCBhIG5vdGUuLi4NCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IExlIDA2LzA3LzIwMTcgw6AgMDM6MTYsIE1hcmsgQW5kcmV3cyBhIMOpY3Jp dCA6DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEluIG1lc3NhZ2UgPDc1MzdkZWVmLThmODctNTE4 Ny0xZTQ0LTU5NWFjNjNhMTZjYUBnbWFpbC5jb20+LA0KPiA+Pj4+Pj4+PiBBbGV4YW5kcmUgUGV0 cmVzY3Ugd3JpdGVzOg0KPiA+Pj4+Pj4+Pj4gSGVsbG8sDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pj4gV2UgZGlzY3Vzc2VkIGV4dGVuc2l2ZWx5IGFib3V0IHRoZSBwb3RlbnRpYWwgdXNlIG9mIERI Q1B2Ng0KPiA+Pj4+Pj4+Pj4gUHJlZml4IERlbGVnYXRpb24gb24gY2VsbHVsYXIgbGlua3MuDQo+ ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gVGhlIGNoaWNrZW4gaXNzdWUgaXMgdGhlIGxhY2sgb2Yg REhDUHY2IFBEIHNvZnR3YXJlIG9uDQo+ID4+Pj4+Pj4+PiB0eXBpY2FsIFVzZXIgRXF1aXBtZW50 LiAgRm9yIGV4YW1wbGUsIHRoZXJlIGlzIG5vIERIQ1B2Ni1QRA0KPiA+Pj4+Pj4+Pj4gYXBwIG9u IEFuZHJvaWQuICBUaGUgZWdnIGlzc3VlIGlzIHRoZSBsYWNrIG9mIG9wZXJhdG9yDQo+ID4+Pj4+ Pj4+PiBzdXBwb3J0IG9mIERIQ1B2Ni1QRCB0b3dhcmRzIHRoZSBVc2VyIFRlcm1pbmFsLiAgRm9y IGV4YW1wbGUsDQo+ID4+Pj4+Pj4+PiB0aGVyZSBpcyBubyBjZWxsdWxhciBvcGVyYXRvciBhbnN3 ZXJpbmcgdG8gREhDUHY2LVBEIHJlcXVlc3RzDQo+ID4+Pj4+Pj4+PiBpc3N1ZWQgYnkgdGhlIFVz ZXIgVGVybWluYWwuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gVG8gYWRkcmVzcyB0aGUgY2hp Y2tlbiBpc3N1ZSwgd2Ugc3RhcnRlZCB3aXRoIGFuIElTQyBESENQDQo+ID4+Pj4+Pj4+PiBvcGVu IHNvZnR3YXJlIGNsaWVudCwgd2hpY2ggZG9lcyBpbXBsZW1lbnQgUHJlZml4IERlbGVnYXRpb24u DQo+ID4+Pj4+Pj4+PiBJdCBjYW4gYmUgKGNyb3NzKWNvbXBpbGVkIG9uIHZhcmlvdXMgcGxhdGZv cm1zOyB0aGVuIHR5cGUNCj4gPj4+Pj4+Pj4+ICIuL2RoY2xpZW50IC02IC1QIjsgdGhpcyBzZW5k cyBhbiBESENQdjYgU29saWNpdCBJZGVudGl0eQ0KPiA+Pj4+Pj4+Pj4gQXNzb2NpdGFpb24gZm9y IFByZWZpeCBEZWxlZ2F0aW9uIG1lc3NhZ2Ugb24gdGhlIGludGVyZmFjZS4NCj4gPj4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+PiBIb3dldmVyLCB3aGVyZWFzIHRoaXMgc29mdHdhcmUgcnVucyBvayBvbiBp bnRlcmZhY2VzIHN1Y2ggYXMNCj4gPj4+Pj4+Pj4+IEV0aGVybmV0LCBVU0JuZXQgYW5kIFdpRmkg aW50ZXJmYWNlcywgaXQgYnJlYWtzIGlmIHJ1biBvbiB0aGUNCj4gPj4+Pj4+Pj4+IGNlbGx1bGFy IGludGVyZmFjZSBvZiBzb21lIElvVCBjZWxsdWxhciBwbGF0Zm9ybS4gIFRoZSBlcnJvcg0KPiA+ Pj4+Pj4+Pj4gY2FuIGJlIGNvcnJlY3RlZCBieSB0aGUgcXVpY2stYW5kLWRpcnR5IHNvbHV0aW9u IGJlbG93Lg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBUaGUgaGFjayB3b3VsZCBiZSBiZXR0ZXIg YXMNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gI2lmZGVmIEFSUEhSRF9YWFhYIGNhc2UgQVJQSFJE X1hYWFg6IGh3LT5obGVuID0gNzsgaHctPmhidWZbMF0NCj4gPj4+Pj4+Pj4gICAgPSBIVFlQRV9F VEhFUjsgbWVtY3B5KCZody0+aGJ1ZlsxXSwgc2EtPnNhX2RhdGEsIDYpOyBicmVhazsNCj4gPj4+ Pj4+Pj4gI2VuZGlmIGRlZmF1bHQ6IGxvZ19mYXRhbCgiVW5zdXBwb3J0ZWQgZGV2aWNlIHR5cGUg JWxkIGZvcg0KPiA+Pj4+Pj4+PiBcIiVzXCIiLCAobG9uZyBpbnQpc2EtPnNhX2ZhbWlseSwgbmFt ZSk7IGJyZWFrOw0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiB3aXRoIEFSUEhSRF9YWFhYIGJlaW5n IHJlcGxhY2VkIGJ5IHRoZSBjb3JyZWN0IG1hY3JvIGZvciA1MDMNCj4gPj4+Pj4+Pj4gZnJvbSA8 bmV0L2lmX2FycC5oPi4gIFNvbWV0aGluZyBsaWtlIHRoYXQgaXMgYXQgbGVhc3QNCj4gPj4+Pj4+ Pj4gcG9ydGFibGUuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBCdXQgaXQgbWVhbnMgd2hlbiBJIGdv IHRvIG90aGVyIHBsYXRmb3JtIHdpbGwgaGF2ZSB0byBtb2RpZnkNCj4gPj4+Pj4+PiBhZ2FpbiB0 aGUgSVNDIGNsaWVudCBzb3VyY2UgY29kZT8NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEluIGNlbGx1 bGFyIHRlcm1pbmFscyB0aGVyZSBhcmUgc28gbWFueSBub24tSUVFRSBkaWZmZXJlbnQga2luZHMN Cj4gPj4+Pj4+PiAgICBvZiBsaW5rcy4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IE90aGVyIGNsaWVu dHMgd29yayBvdXQgb2YgdGhlIGJveCBvbiB0aGlzIC0gSSBhZ3JlZSB3aXRoIHlvdSwNCj4gPj4+ Pj4+PiBzdHJhbmdlIC0gInJtbmV0MCIgaW50ZXJmYWNlLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4g QWxleA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEFzIGZvciB0aGUgcmVzdCBv ZiBpdCBJIGhhdmUgbm8gaWRlYSBhYm91dCB0aGUgcHJlc2VudGVkDQo+ID4+Pj4+Pj4+IGhhcmR3 YXJlIGFkZHJlc3Mgb2YgdGhpcyB0eXBlIHNvIEkgZG9uJ3Qga25vdyBpdCB0aGUgcmVzdCBvZiBp dA0KPiA+Pj4+Pj4+PiBtYWtlIHNlbnNlLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gQWxleA0K PiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4gVGhlIGVycm9yIHNheXMgIi8vVU5TVVBQT1JURUQgREVWSUNFIFRZUEUg NTAzIEZPUiBSTU5FVDAuIg0KPiA+Pj4+Pj4+Pj4gZGhjcC00LjMuNSAuL2NvbW1vbi9scGYuYyBs aW5lIG51bWJlcjogNTUxDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gLy9kZWZhdWx0OiAvLyAg ICAgIGxvZ19mYXRhbCgiVW5zdXBwb3J0ZWQgZGV2aWNlIHR5cGUgJWxkDQo+ID4+Pj4+Pj4+PiBm b3IgXCIlc1wiIiwgLy8gICAgICAgICAgICAgICAgKGxvbmcgaW50KXNhLT5zYV9mYW1pbHksDQo+ ID4+Pj4+Pj4+PiBuYW1lKTsgZGVmYXVsdDogaHctPmhsZW4gPSA3OyBody0+aGJ1ZlswXSA9IEhU WVBFX0VUSEVSOw0KPiA+Pj4+Pj4+Pj4gbWVtY3B5KCZody0+aGJ1ZlsxXSwgc2EtPnNhX2RhdGEs IDYpOyBicmVhazsNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiAodHdvIHByb2dyYW1tZXJzIHdv cmtlZCB0aGlzIG91dCkuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gQWxleA0KPiA+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fIHY2b3BzDQo+ID4+Pj4+Pj4+PiBtYWlsaW5nIGxpc3QgdjZvcHNAaWV0Zi5vcmcNCj4g Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4g Pj4+Pj4+Pg0KPiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fIHY2b3BzIG1haWxpbmcNCj4gPj4+Pj4+PiBsaXN0IHY2b3BzQGlldGYub3JnIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPj4+Pj4+DQo+ID4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2Nm9w cyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+IHY2b3BzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gPj4+Pj4NCj4gPj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gdjZvcHMgbWFpbGluZyBsaXN0DQo+ ID4+Pj4+IHY2b3BzQGlldGYub3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdjZvcHMNCj4gPj4+Pg0KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+Pj4gdjZvcHNA aWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQo+ID4NCg0K From nobody Tue Sep 5 13:15:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D213313202D for ; Tue, 5 Sep 2017 13:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4HkzFG_8VGb for ; Tue, 5 Sep 2017 13:15:11 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFF21329C5 for ; Tue, 5 Sep 2017 13:15:11 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id 188so8098734pgb.2 for ; Tue, 05 Sep 2017 13:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AmFnCImbdu1CjjVVhQuEOFO2RhXXf+Ja3s64A5SxEz8=; b=ovCLeeKJtiDCI/0e7/soNrsz3XNcrdOoMf7IUYqCe9d+nWVgCJ1afCcOK15OfC6LzN O8+vbTdIoAYarmACv5YyULOpwSmp+OBnVtJ5rDVtJp3oMKp9phoW9TR29rCVd4hFzYch qn1KuOVWO8izgL19wJ5cvEw+wbuCa59rw1JCr9ExVbFhv7PjWKKDuc4GNch/Z0irIJ7u 6h8okQ4THTlYkkCqJzlF8MFkLqGjxJH2ocDepMdXEWUo3zgQVWdeaZoqUo+uJ7rUf+cT 7VAIXAbmxSFKlw3190K+FKdN0GntBowepgNfJWi6nQxOwroYOioxYs8W5aGjI7eHVEID j9dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=AmFnCImbdu1CjjVVhQuEOFO2RhXXf+Ja3s64A5SxEz8=; b=W6sQaw9/YvojQ8s8sbQw33Dnn3mYIHG/mkJCUXsUwKf5sSrDWJ7A8kcv5euw87fSmN gILsnav+i1NwvQ3Vg2uS5SKragwH7h6oj6gt71T1FyOvvMNdON0OFDR1ZsW3XvjayfbU rf6Dd6C5EKX+pfsZ3EmtyCX1fS9CmJYJaQFvOSlF4FwFCrV6CJpFwLlMUdPIgMr2ijkS eulnwvVcMwOISRF8+iCyizLu/QQNQYyCAjm89fUux0AWIxfuOlmD+0rwUIDaOVHIjzTd YKxeLCJeH1budwY2mGqCEIAsW26YsR1sVBsEEP5u/D1FQ57nYwMLWOUsVba78hz1vBXc on5w== X-Gm-Message-State: AHPjjUgLsMzGLpQtKTWImP4fxF6YB48nqamkZACyCdR2Z/FeVlfCD7Yz rBbjCnaKQrkSJYVA X-Google-Smtp-Source: ADKCNb4NYXNZpWzK6olYajyzUuhFpzDz8h0K3fYXy91EJkHMaucYeeI3bctJTrs7dW4l7wHsc/yitg== X-Received: by 10.98.18.73 with SMTP id a70mr5012395pfj.245.1504642510349; Tue, 05 Sep 2017 13:15:10 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a6sm1791811pgq.17.2017.09.05.13.15.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 13:15:09 -0700 (PDT) To: Fred Baker , Mikael Abrahamsson Cc: "v6ops@ietf.org" References: <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> <0f18ee6d-81a3-ff68-1d0e-bc41cc409db5@gmail.com> <3EFFE83B-2BD0-4D67-A397-D7C39F55D554@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <934f3251-9318-537c-9ad6-bb1bca2a0591@gmail.com> Date: Wed, 6 Sep 2017 08:15:10 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3EFFE83B-2BD0-4D67-A397-D7C39F55D554@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] RFC6085 scope [was Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:15:13 -0000 On 06/09/2017 03:23, Fred Baker wrote: > Sounds like an erratum on RFC 6085. I think that might be wise, but I'm happy to leave that to Ole if he thinks it's useful. Brian > >> On Sep 4, 2017, at 11:53 PM, Mikael Abrahamsson wrote: >> >> On Tue, 5 Sep 2017, Brian E Carpenter wrote: >> >>> Well, OK, I'm a standards freak, but Token Ring and FDDI both support layer 2 multicast. And as has been pointed out, 802.11 may look like Ethernet, but it isn't Ethernet. So my question is not about the prevalence of 802.1 in the real world, but about the generality of the rule. I assume it would apply in all cases. >> >> It's an interesting case. To the IP stack in most OSes, doesn't wifi packets received look like they're ethernet framed? So wifi kind of pretends to look Ethernet as much as it can, and these kinds of rules should be applied to all media types that have L2 multicast/broadcast/unicast concepts, right? >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Tue Sep 5 13:27:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CE1128D0D; Tue, 5 Sep 2017 13:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieT2WbJqG671; Tue, 5 Sep 2017 13:27:11 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EAE2132E23; Tue, 5 Sep 2017 13:27:09 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id t3so11468979pgt.0; Tue, 05 Sep 2017 13:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=M48v4f/TA0lobHD8aNCX5m5+e10DaeLmrWpbm8DA2QI=; b=GITfU8AfY3YE4jtBp4y5rk1yYoUL95KtpzCSE2S5xpog2ujSrAUhV9LTORGOP/i6pC mCTY7Tz+MGxZP76i0Y93xg234lkP2iSJYgavar7yRgnNZdn/MZvudm2EqzRKoP90P3bL u4aQId3baYinV5wGHuuq1eewQnR8RQvCgoYYQBfLKDTLr7Iz2ZBSUeZ5mAWlAdITHa94 RMGKzb3i6FDou6QHPC9Ex4PsxhiUsKoKpzQm8QuNOOT/kVuvz2YJ/10LoHcjyIQ9UQRQ CTqglXF3kdXBuuUnqVPpSyyyZM1TjNTfvgBPEt3S8QUTz8lVaGdAh0T6LcALq4HHsDU+ /GGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=M48v4f/TA0lobHD8aNCX5m5+e10DaeLmrWpbm8DA2QI=; b=NjNSEnMeG51rCNZHjUA1Mt6v80DVfW1CBEl5Rrhu8Bp8YXfkPQyVgmNG/YoJMZV87O elxx4G1wAcjjJLvYKqdYRKHPC3P9+cy2a4Ztqq+m2jISIad+wDS/s5yG9YdvS9Wl0VA7 8XiGgk461tbV0gc1+quJSEMsKF1SUNlwZKcLwPu4ZldboZJqrufaRupWPbiEw16dCli4 DMF8+wwKrZkrXaNIBWys9fCDk7TAKXeVaXPhCirxeA0DZT7FSBf7ZePURqRJZRcnrhkH jNqWckJZxOaUr2ds/97joWS0vd3tbYGIdDZmqesp4TAKOxbDxDTkwd6zcadT4RFcjR24 4bqA== X-Gm-Message-State: AHPjjUhqMPQNHfS9ylisTOU+qC5RxyRfaNolaL34DUMlcOYSLcZEkoYt 399m7HohMMqVCXcq X-Google-Smtp-Source: ADKCNb5vEhI83CRl8Ro5g7hdZznK5Od63/GpCNQecT2AnhcwpNxdcKBcxv3u4qU5zglQK/4jKOMHzQ== X-Received: by 10.84.246.200 with SMTP id j8mr5632845plt.89.1504643228798; Tue, 05 Sep 2017 13:27:08 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z1sm2166437pge.45.2017.09.05.13.27.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 13:27:07 -0700 (PDT) To: David Farmer , Mark Smith Cc: v6ops list , draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, v6ops-chairs@ietf.org References: <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 6 Sep 2017 08:27:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:27:15 -0000 On 06/09/2017 01:38, David Farmer wrote: ... > I think the draft should be agnostic about whether solicited RAs are sent > unicast or multicast., but unsolicited RA have to be sent multicast. So, I > propose the following; > > In the second paragraph of section 4, s/unicast/solicited/ > > Then add the following text as the third paragraph of section 4; > > In general, a solicited RA response, may be sent either unicast or > multicast. That still doesn't explain whether it means L2 or L3 unicast. Even if we agree with Ole's point that either interpretation is OK, it needs to be said explicitly. Brian > However, an unsolicited RA, which is sent periodically, is > always sent multicast. This is described in [RFC4861], sections 6.2.6 and > 6.2.4 respectively. When the First Hop Router sends a multicast RA, either > solicited or unsolicited, it SHOULD only be received by the UE/subscriber > that has been assigned the Unique IPv6 prefix it contains. This is achieved > by sending the packet to the unicast link-layer address of the UE/subscriber > instead of the associated link-layer multicast address [RFC6085]. > > Thanks > From nobody Tue Sep 5 13:44:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1163124239; Tue, 5 Sep 2017 13:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8n6Wp66eT2T; Tue, 5 Sep 2017 13:44:35 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E1C126BF0; Tue, 5 Sep 2017 13:44:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v85KiYWs001698; Tue, 5 Sep 2017 13:44:34 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v85KiN9x001491 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 5 Sep 2017 13:44:23 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Sep 2017 13:44:22 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 5 Sep 2017 13:44:22 -0700 From: "Templin, Fred L" To: Brian E Carpenter , David Farmer , Mark Smith CC: v6ops list , "v6ops-chairs@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Thread-Topic: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' Thread-Index: AdMc/6CUzPiNhsaqSHeBevoZRQIEcwAsjuMAABm3lAAADkV24AABC3uAAG54hrAAEcLjAAAOmvKAABmowzAAMCdaBQAHEcpAASwgz5cAAHhxgA== Date: Tue, 5 Sep 2017 20:44:22 +0000 Message-ID: <491890c944a64aca940acfda8ab3d367@XCH15-06-08.nw.nos.boeing.com> References: <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:44:38 -0000 Hi, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpente= r > Sent: Tuesday, September 05, 2017 1:27 PM > To: David Farmer ; Mark Smith > Cc: v6ops list ; v6ops-chairs@ietf.org; draft-ietf-v6ops-= unique-ipv6-prefix-per-host@ietf.org > Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-= host-07' >=20 > On 06/09/2017 01:38, David Farmer wrote: > ... > > I think the draft should be agnostic about whether solicited RAs are se= nt > > unicast or multicast., but unsolicited RA have to be sent multicast. S= o, I > > propose the following; > > > > In the second paragraph of section 4, s/unicast/solicited/ > > > > Then add the following text as the third paragraph of section 4; > > > > In general, a solicited RA response, may be sent either unicast or > > multicast. >=20 > That still doesn't explain whether it means L2 or L3 unicast. Even if > we agree with Ole's point that either interpretation is OK, it needs > to be said explicitly. In RFC5214, the RAs use unicast for both L2 and L3. (Also, there are no per= iodic RAs - only solicited ones.) And, RFC5214 defines the behavior explicitly. So, I agree with Brian that the interpretation in this document needs to be made explicit. Thanks - Fred > Brian >=20 > > However, an unsolicited RA, which is sent periodically, is > > always sent multicast. This is described in [RFC4861], sections 6.2.6 a= nd > > 6.2.4 respectively. When the First Hop Router sends a multicast RA, eit= her > > solicited or unsolicited, it SHOULD only be received by the UE/subscrib= er > > that has been assigned the Unique IPv6 prefix it contains. This is achi= eved > > by sending the packet to the unicast link-layer address of the UE/subsc= riber > > instead of the associated link-layer multicast address [RFC6085]. > > > > Thanks > > >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 5 14:27:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E373312895E for ; Tue, 5 Sep 2017 14:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USUcoF25wuey for ; Tue, 5 Sep 2017 14:27:11 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B6C1243F6 for ; Tue, 5 Sep 2017 14:27:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v85LR9oh006786; Tue, 5 Sep 2017 14:27:10 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v85LR9sE006626 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Tue, 5 Sep 2017 14:27:09 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Sep 2017 14:27:08 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 5 Sep 2017 14:27:08 -0700 From: "Templin, Fred L" To: v6ops list Thread-Topic: I-D Action: draft-templin-v6ops-pdhost-06.txt Thread-Index: AQHTJoxCYBlQLPEYAUGtsG36832ak6KmzGnw Date: Tue, 5 Sep 2017 21:27:08 +0000 Message-ID: References: <150464618134.29784.3337785472849329615@ietfa.amsl.com> In-Reply-To: <150464618134.29784.3337785472849329615@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [v6ops] FW: I-D Action: draft-templin-v6ops-pdhost-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 21:27:13 -0000 Hi, here is a draft that is very closely related to RFC7934 and 'unique-ipv= 6-prefix-per-host'. It described the options available for a node that receives a unique prefix= delegation from the network in terms of routing and multi-addressing considerations. It is = of direct interest to this community. I have given my time and energies to contribute to the aforementioned v6ops= docs and would appreciate input from the working group on my document. Please see be= low for abstract and URLs. Thanks - Fred -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Tuesday, September 05, 2017 2:16 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-pdhost-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 Prefix Delegation for Hosts Author : Fred L. Templin Filename : draft-templin-v6ops-pdhost-06.txt Pages : 10 Date : 2017-09-05 Abstract: IPv6 prefixes are typically delegated to requesting routers which then use them to number their downstream-attached links and networks. This document considers both this traditional case, and the case when the "requesting router" is actually a simple host which receives a delegated prefix that it can use for its own internal multi- addressing purposes. This latter method can be employed in a wide variety of use cases to allow ample address availability without impacting link performance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-v6ops-pdhost-06 https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-06 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 Sep 5 15:15:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAA4132191 for ; Tue, 5 Sep 2017 15:15:52 -0700 (PDT) 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_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=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 PN7oIWsvxEpo for ; Tue, 5 Sep 2017 15:15:49 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2DD41320CF for ; Tue, 5 Sep 2017 15:15:49 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 7AAE2C75 for ; Tue, 5 Sep 2017 22:15:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBE1WusikNSO for ; Tue, 5 Sep 2017 17:15:48 -0500 (CDT) Received: from mail-ua0-f197.google.com (mail-ua0-f197.google.com [209.85.217.197]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id E0012C92 for ; Tue, 5 Sep 2017 17:15:45 -0500 (CDT) Received: by mail-ua0-f197.google.com with SMTP id k23so3449164uaf.0 for ; Tue, 05 Sep 2017 15:15:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hD1icuATT0Z/vjuaFDRg5BxBCcjq46OGB7EJBrrM6JE=; b=h+71kH5RiiNxHEOuuyakuurrjiwWIs2Uxi04sjILvJ6fYsWQruFc8RArv5vzW178Ff ueQKjYXLusc38N6cgdAeORTyRoRiVrraG4tuKShMIXY2q+pD0W2f9dtrMHUZHVK8KUT5 qNIHT4empKrzZGuPIHe+bQQbaVQsKa1HaIgWxIpTZpOgvFDQTSVhy81K1vTOJar5176R WdliRR+0CrduBrultr0MZjcRhK0dUOUZ2DmsQcGQHOwxZGnZtgHkKNMBy30GTlIFIEvs ND0ykS4UcsakMgKGEFdza7FedSz+P+RDJs681VDtTAw7eNX+Tw+bTtxs4F1l5gMmHlV4 XfBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hD1icuATT0Z/vjuaFDRg5BxBCcjq46OGB7EJBrrM6JE=; b=r79mcKZRmnsbuRL1Gl7I42pEX7+BdxDq0EDBi3PCFg2UaSYa6kPMJhiEYbVHr0HbBo SSE4dSwKxhl3ZxKn6No4dvHllVoE6jpEAodH2N1sqT9ITVmLb4AruCzUd1PMrXFFRcnS +BtfD99nRqlVXkNykalVlXI6Ct4lzTpREtYXmWvulHijIxkza5w6Gc95HoCpil/mUfvN +9HR3+EZX3oFgIE2JGDpCQr0y3jz0jFo1ggWCp+AsvF5PX1mhOOkXykDeOSKjlkxHRx9 9pz9l7bIKTwP7Q9Kyn1IspVuubgEBEzlYCFwSIyR7AcTnjXpyoCtNG0Sp7REOX8cqXsI fQSA== X-Gm-Message-State: AHPjjUhRaM3s53E1f9s4KfD1kR15ZiLFB28SA3qGYGWLlQBdZOGbLkUJ xpm2xRwJ/ETndC+n/ALrXn9Cyt6sNMuO+mzqg1Cn7tj/NqGEoHfvn43Hlx/9UvVqWvv9lTwyFWz Z7opyueRNIPXhgeQu X-Received: by 10.31.142.72 with SMTP id q69mr331253vkd.81.1504649744591; Tue, 05 Sep 2017 15:15:44 -0700 (PDT) X-Google-Smtp-Source: ADKCNb7Wzw7wT9vrxevj3suITmxk/lg0ha3+5194CXcadblH4rXGVueBoj/BaLTOWqJk1JWjIgC3qogp7+3WVliqeQw= X-Received: by 10.31.142.72 with SMTP id q69mr331244vkd.81.1504649744392; Tue, 05 Sep 2017 15:15:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.89.81 with HTTP; Tue, 5 Sep 2017 15:15:42 -0700 (PDT) In-Reply-To: <491890c944a64aca940acfda8ab3d367@XCH15-06-08.nw.nos.boeing.com> References: <62F47F12-EF74-4D48-8C25-75F478D100C7@employees.org> <64479d17-ae77-3e46-d167-6e7a8ffca1bf@gmail.com> <491890c944a64aca940acfda8ab3d367@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Tue, 5 Sep 2017 17:15:42 -0500 Message-ID: To: "Templin, Fred L" Cc: Brian E Carpenter , Mark Smith , v6ops list , "v6ops-chairs@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Content-Type: multipart/alternative; boundary="001a11436dac86b8c3055878914e" Archived-At: Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07' X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 22:15:52 -0000 --001a11436dac86b8c3055878914e Content-Type: text/plain; charset="UTF-8" On Tue, Sep 5, 2017 at 3:44 PM, Templin, Fred L wrote: > Hi, > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E > Carpenter > > Sent: Tuesday, September 05, 2017 1:27 PM > > To: David Farmer ; Mark Smith > > Cc: v6ops list ; v6ops-chairs@ietf.org; > draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org > > Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6- > prefix-per-host-07' > > > > On 06/09/2017 01:38, David Farmer wrote: > > ... > > > I think the draft should be agnostic about whether solicited RAs are > sent > > > unicast or multicast., but unsolicited RA have to be sent multicast. > So, I > > > propose the following; > > > > > > In the second paragraph of section 4, s/unicast/solicited/ > > > > > > Then add the following text as the third paragraph of section 4; > > > > > > In general, a solicited RA response, may be sent either unicast or > > > multicast. > > > > That still doesn't explain whether it means L2 or L3 unicast. Even if > > we agree with Ole's point that either interpretation is OK, it needs > > to be said explicitly. > Ok is this explicit enough? Again, in the second paragraph of section 4, s/unicast/solicited/ Then add the following text as the third paragraph of section 4; When the First Hop Provider Router sends a solicited RA response, or a periodic unsolicited RA, the RA MUST be sent only to the UE/subscriber that has been assigned the Unique IPv6 prefix contained in the RA. This is achieved by sending a unicast RA response, as detailed in [RFC4861] section 6.2.6, or by sending a multicast RA response or unsolicited RA to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6, but instead of using the link-layer multicast address associated with the all-nodes group, the link-layer unicast address of the UE/subscriber that has been assigned the Unique IPv6 prefix contained in the RA MUST be used as the link-layer destination [RFC6085]. In RFC5214, the RAs use unicast for both L2 and L3. (Also, there are no > periodic > RAs - only solicited ones.) And, RFC5214 defines the behavior explicitly. > But ISATAP clients know they not doing plain vanilla RFC4861, these clients don't, so they are expecting periodic unsolicited RAs sent by the router. > So, I agree with Brian that the interpretation in this document needs to be > made explicit. > > Thanks - Fred > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --001a11436dac86b8c3055878914e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Sep 5, 2017 at 3:44 PM, Templin, Fred L <<= a href=3D"mailto:Fred.L.Templin@boeing.com" target=3D"_blank">Fred.L.Templi= n@boeing.com> wrote:
Hi,

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter=
> Sent: Tuesday, September 05, 2017 1:27 PM
> To: David Farmer <farmer@umn.edu>; Mark Smith <markzzzsmith@gmail.com>
> Cc: v6ops list <v6ops@ietf.org>; v6ops-chairs@ietf.org; draft-ietf-v6ops-unique= -ipv6-prefix-per-host@ietf.org
> Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'
>
> On 06/09/2017 01:38, David Farmer wrote:
> ...
> > I think the draft should be agnostic about whether solicited RAs = are sent
> > unicast or multicast., but unsolicited RA have to be sent multica= st.=C2=A0 So, I
> > propose the following;
> >
> > In the second paragraph of section 4, s/unicast/solicited/
> >
> > Then add the following text as the third paragraph of section 4;<= br> > >
> > In general, a solicited RA response, may be sent either unicast o= r
> > multicast.
>
> That still doesn't explain whether it means L2 or L3 unicast. Even= if
> we agree with Ole's point that either interpretation is OK, it nee= ds
> to be said explicitly.

Ok is this = explicit enough? =C2=A0

Again, in the second = paragraph of section 4, s/unicast/solicited/

Then = add the following text as the third paragraph of section 4;

When the First Hop Provider Router sends a solicited R= A response, or a periodic unsolicited RA, the RA MUST be sent only to the U= E/subscriber that has been assigned the Unique IPv6 prefix contained in the= RA.=C2=A0 This is achieved by sending a unicast RA response, as detailed i= n [RFC4861] section 6.2.6, or by sending a multicast RA response=C2=A0or un= solicited RA to the all-nodes group, as detailed in [RFC4861] section 6.2.4= and 6.2.6, but instead of using the link-layer multicast address associate= d with the all-nodes group, the link-layer unicast address of the UE/subscr= iber that has been assigned=C2=A0the Unique IPv6 prefix contained in the RA= MUST be used as the link-layer destination [RFC6085].

=
In RFC5214, the RAs use unicast for both L2 and L3. (Also, there are no per= iodic
RAs - only solicited ones.) And, RFC5214 defines the behavior explicitly.

But ISATAP clients know they not doing p= lain vanilla RFC4861, these clients don't, so they are expecting period= ic unsolicited RAs sent by the router.
=C2=A0
So, I agree with Brian that the interpretation in this document needs to be=
made explicit.

Thanks - Fred




--
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & = Telecommunication Services
Office of Information Technology
Universit= y of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cel= l: 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
--001a11436dac86b8c3055878914e-- From nobody Tue Sep 5 16:03:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B371321CB for ; Tue, 5 Sep 2017 16:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGBMx0AqfflX for ; Tue, 5 Sep 2017 16:03:24 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E284F132199 for ; Tue, 5 Sep 2017 16:03:23 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id o42so647724wrb.3 for ; Tue, 05 Sep 2017 16:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yuq9RZ/YfOE95zM2PBbViRvJ+bzpYVgx101t+1UTf/c=; b=XjQGThFas2ylhI+WfxHfKR2BZqR3Zjaq0cEpmZ3NaHq7pqdREdkyFWhV7almLQsykr ez3bd+SBhmz7KPykaoADbb7+Oy629Ya3a94eXxBniNoKUtrHiAenRouNHfPQxv+4Uizs hMyEKQD2OH508e8xPUzOl6PEzdGim0NEHpOskY/S+Bo/Za6j0ph38CAqz9Fdf0DMuC9y 5No54nH5Kvs2HcUIq0ySe2VZAsMWLkzh/KQfAMeE3IBnwlkrQKnZWq/lrgxJFxSDTHYE p3MUQG3jAfZuw47iBRz6EKpFT9Uhnbc7uGwwJQilmm1oW+6K7aQu8KYySpZan0u6dlgA RJGg== 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=yuq9RZ/YfOE95zM2PBbViRvJ+bzpYVgx101t+1UTf/c=; b=O6ypYNOPZr0tIFaarEbU3UO+dhw3m4aLnxudPR5TCE8luv7mh2cFUby+nvZo2vkK7a 5w1/MTk/yvHvfEgY4BXZhaS61+YjTbpMF8Eu5v4WBB/UPv2LNdI2OxiQ33yObtAV3dEP J20nU5OsqPUmPTTHYDZRiK7DoBuo3O7jHl3SaYABKVeYPdU3vniKCM73kvJCjZe1r72W YvkShmufQLDIlpXvDv6YJhSMI7Ha+AuTs3w26laiQv/Wj0/AmecLunr4pckEQ0tiHIRx FI36DF0S/JqeskXNVVLq4p5szhXgKPNavAxRdf+zNsjHFU7dyQTUIP8lU+fbIIQ13uqs 0l8g== X-Gm-Message-State: AHPjjUgupjutBbwDAx7wLrQ9L2hHZHiV7dvUD0ynMXNoaNupcg6wfviD HSbgTk8uMjRKow== X-Google-Smtp-Source: ADKCNb4LRG1Hqnp0YsHRaMDDH1O2vfPtwq7WP2LuYb56y7xe5XULURfFUDnPAWoiQnSi/YQ479YR9A== X-Received: by 10.223.164.13 with SMTP id d13mr335207wra.48.1504652602423; Tue, 05 Sep 2017 16:03:22 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1146? ([2600:8802:5600:e::1146]) by smtp.gmail.com with ESMTPSA id r188sm2211568wmb.41.2017.09.05.16.03.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 16:03:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: Date: Tue, 5 Sep 2017 16:03:18 -0700 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <150464618134.29784.3337785472849329615@ietfa.amsl.com> To: Fred Templin X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] I-D Action: draft-templin-v6ops-pdhost-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 23:03:26 -0000 As requested, I'll give you my thoughts. Hats off. Your comments seem to be focused on draft-aerolink, and specifically the = model that a host uses on its WAN interface an address derived from its = LAN interface (obtained via IA_PD) in a specific environment. You appear = to very much want that to be part of the standard model. The standard model of a LAN (L2) is that it has an associated subnet = (L3), so that a system's address on the LAN is an address in the = indicated subnet. As much as anything, this is so that IP can find a = next-hop, do something similar to ARP/ND, and find the L2 encoding that = will get it to that device. You're not happy, apparently, with the use = of a link-local address on the LAN to replace that subnet, and I gather = want the router to maintain not only the IP(v4/v6) address of the = neighboring device, but its L2 parameters, wherever the Next Hop = information is maintained. I won't tell you you're wrong, but I'll tell you that it's an unusual = design that requires a lot more discussion before we can reasonably = expect vendors and network administrators to use it. If one wants to = find it in Ethernet/Wifi/Cable Modem/DSL/FTTH/etc environments, it's not = a universally-accepted viewpoint and calls for explicit discussion. > On Sep 5, 2017, at 2:27 PM, Templin, Fred L = wrote: >=20 > I have given my time and energies to contribute to the aforementioned = v6ops docs and > would appreciate input from the working group on my document. From nobody Tue Sep 5 16:10:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AAE132199 for ; Tue, 5 Sep 2017 16:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKDOGX0IIgNV for ; Tue, 5 Sep 2017 16:10:32 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307A1132198 for ; Tue, 5 Sep 2017 16:10:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v85NAVso023603; Tue, 5 Sep 2017 16:10:31 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v85NAQ8N023591 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 5 Sep 2017 16:10:26 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Sep 2017 16:10:25 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 5 Sep 2017 16:10:25 -0700 From: "Templin, Fred L" To: Fred Baker CC: v6ops list Thread-Topic: [v6ops] I-D Action: draft-templin-v6ops-pdhost-06.txt Thread-Index: AQHTJoxCYBlQLPEYAUGtsG36832ak6KmzGnwgACSKQD//4t3MA== Date: Tue, 5 Sep 2017 23:10:25 +0000 Message-ID: References: <150464618134.29784.3337785472849329615@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-templin-v6ops-pdhost-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 23:10:34 -0000 Hi Fred, No, this is not specifically about aerolink anymore. This is about any end = system that requests and gets an IPv6 prefix delegation in the spirit of RFC7934. = It would be worth a reread if you have not already done so - it is only 10 pages (le= ss if you ignore the boilerplate). Thanks - Fred > -----Original Message----- > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > Sent: Tuesday, September 05, 2017 4:03 PM > To: Templin, Fred L > Cc: v6ops list > Subject: Re: [v6ops] I-D Action: draft-templin-v6ops-pdhost-06.txt >=20 > As requested, I'll give you my thoughts. Hats off. >=20 > Your comments seem to be focused on draft-aerolink, and specifically the = model that a host uses on its WAN interface an address > derived from its LAN interface (obtained via IA_PD) in a specific environ= ment. You appear to very much want that to be part of the > standard model. >=20 > The standard model of a LAN (L2) is that it has an associated subnet (L3)= , so that a system's address on the LAN is an address in the > indicated subnet. As much as anything, this is so that IP can find a next= -hop, do something similar to ARP/ND, and find the L2 encoding > that will get it to that device. You're not happy, apparently, with the u= se of a link-local address on the LAN to replace that subnet, and I > gather want the router to maintain not only the IP(v4/v6) address of the = neighboring device, but its L2 parameters, wherever the > Next Hop information is maintained. >=20 > I won't tell you you're wrong, but I'll tell you that it's an unusual des= ign that requires a lot more discussion before we can reasonably > expect vendors and network administrators to use it. If one wants to find= it in Ethernet/Wifi/Cable Modem/DSL/FTTH/etc > environments, it's not a universally-accepted viewpoint and calls for exp= licit discussion. >=20 > > On Sep 5, 2017, at 2:27 PM, Templin, Fred L = wrote: > > > > I have given my time and energies to contribute to the aforementioned v= 6ops docs and > > would appreciate input from the working group on my document. >=20 From nobody Tue Sep 5 23:03:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277BD132358 for ; Tue, 5 Sep 2017 23:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcv6hHs2NLue for ; Tue, 5 Sep 2017 23:03:26 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D1913234E for ; Tue, 5 Sep 2017 23:03:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8663L6N045051; Wed, 6 Sep 2017 08:03:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CCCCE201C77; Wed, 6 Sep 2017 08:03:21 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BFB33201A03; Wed, 6 Sep 2017 08:03:21 +0200 (CEST) Received: from [132.166.84.7] ([132.166.84.7]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8663KpE006803; Wed, 6 Sep 2017 08:03:21 +0200 To: "Templin, Fred L" , "v6ops@ietf.org" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> Date: Wed, 6 Sep 2017 08:03:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 06:03:29 -0000 Fred,, Le 05/09/2017 à 18:06, Templin, Fred L a écrit : [...] >> Some details: >> - the DHCPv6 software on Android is hampered by the need of root access. >> Android blocks that. One needs to ask the platform manufacturer >> running that Android to "root" the platform such as to be able to run >> some of the DHCP client software (e.g. ask Huawei for a key to root >> the smartphone). That's a real pain. There is a risk of "bricking" >> your platform, i.e. through it out a window. > > You don't need to root the device to run DHCPv6 PD over a VPN: > > https://developer.android.com/reference/android/net/VpnService.html Fred, I can understand VPN set up runs ok without need to root the device running Android OS. But, is DHCP client over that VPN needing to "root" the device? Is that DHCP client in-house software, odhcpcd, WIDE, ISC, scapy? If it is in-house software, I can understand you may not need to root it. But then I would like to know whether that in-house software is parametrable so it can unicast and non-std UDP, such that it runs over straight interfaces too, not only VPN. Alex > > Again, we have DHCPv6 PD working fine over a VPN. > > Thanks - Fred > >> - to make an app available to everyone on Android one must pay some >> money to become a member of a store. DHCP should not be part of that, >> as SLAAC isnt; just like SLAAC, DHCP should be builtin for free. >> - the DHCPv6 server software "ISC" breaks if the port numbers are >> non-standard (not 546 nor 547) or unicast instead of multicast. >> (e.g. "Discarding Solicit from [snip]; packet sent unicast") >> This was a real pain, because we had to modify the source code >> to allow it; other software like VoIP has SIP ports this configurable >> easily with a GUI. >> - Cisco parametering CLI of DHCPv6 service may have some problems in >> transforming a non-standard UDP port 546 of Solicit to a strange >> 26483. That was a real pain to one. >> - various DHCPv6 client software break, or do not even start, with >> any other src and dst UDP ports than the standard (546, 547) >> and/or non-standard unicast instead of standard multicast. >> >> Other reasons proved not to be causes of absence of DHCPv6 PD on >> cellular links; they were just speculations: >> - cellular operators dont provide DHCPv6 PD service (there are some who >> do under some operational conditions) >> - cellular operators have a hard time making an IPv6 addressing >> architecture that delegate prefixes instead of addresses (there are >> some who do make such architecture) >> - cellular operators only do '64' (it's false, some could do less, >> like 56 or even 48) >> - DHCPv6 software is not available on the client (there are some, like >> on Android, and more, see quoted mails below) >> - the computer that runs the DHCPv6 client is the same as the one that >> puts the Solicit on the wire: this is not true, because even in the >> smallest UE in the market there is still distinction app-vs-modem >> processors. Often the modem part is confidential, only the binary >> is available to the public, and there are two IPs on it: Internet >> Protocol _and_ Intellectual Property. >> >> Alex, with thanks to [Hachata], admin(s), managers, and technicals at >> offices and organisations. >> >> >> Le 18/08/2017 à 18:07, Alexandre Petrescu a écrit : >>> I have been pointed by a helpful person that an Android app for >>> DHCPv6 exists there: >>> >>> https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client&hl=fr >>> >>> >>> >>> >>> >>> It is based on the WIDE DHCPv6 client. >>> >>> Further browsing leads to a discussion of DHCPv6 on Android topic: >>> https://issuetracker.google.com/issues/36949085 >>> >>> Alex >>> >>> Le 17/07/2017 à 18:26, Alexandre Petrescu a écrit : >>>> Well, this is to note that we too (Fred mentioned it too earlier) >>>> made the ISC DHCPv6 dhclient work on Android, including DHCPv6 >>>> Solicit that requests Prefix Delegation. >>>> >>>> (but we still dont have a response to DHCP Solicit on cellular >>>> link). >>>> >>>> Alex >>>> >>>> Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit : >>>>> Mark, noted, will try. >>>>> >>>>> Just a note... >>>>> >>>>> Le 06/07/2017 à 03:16, Mark Andrews a écrit : >>>>>> >>>>>> In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, >>>>>> Alexandre Petrescu writes: >>>>>>> Hello, >>>>>>> >>>>>>> We discussed extensively about the potential use of DHCPv6 >>>>>>> Prefix Delegation on cellular links. >>>>>>> >>>>>>> The chicken issue is the lack of DHCPv6 PD software on >>>>>>> typical User Equipment. For example, there is no DHCPv6-PD >>>>>>> app on Android. The egg issue is the lack of operator >>>>>>> support of DHCPv6-PD towards the User Terminal. For example, >>>>>>> there is no cellular operator answering to DHCPv6-PD requests >>>>>>> issued by the User Terminal. >>>>>>> >>>>>>> To address the chicken issue, we started with an ISC DHCP >>>>>>> open software client, which does implement Prefix Delegation. >>>>>>> It can be (cross)compiled on various platforms; then type >>>>>>> "./dhclient -6 -P"; this sends an DHCPv6 Solicit Identity >>>>>>> Associtaion for Prefix Delegation message on the interface. >>>>>>> >>>>>>> However, whereas this software runs ok on interfaces such as >>>>>>> Ethernet, USBnet and WiFi interfaces, it breaks if run on the >>>>>>> cellular interface of some IoT cellular platform. The error >>>>>>> can be corrected by the quick-and-dirty solution below. >>>>>> >>>>>> The hack would be better as >>>>>> >>>>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; hw->hbuf[0] >>>>>> = HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>>>> #endif default: log_fatal("Unsupported device type %ld for >>>>>> \"%s\"", (long int)sa->sa_family, name); break; >>>>>> >>>>>> with ARPHRD_XXXX being replaced by the correct macro for 503 >>>>>> from . Something like that is at least >>>>>> portable. >>>>> >>>>> But it means when I go to other platform will have to modify >>>>> again the ISC client source code? >>>>> >>>>> In cellular terminals there are so many non-IEEE different kinds >>>>> of links. >>>>> >>>>> Other clients work out of the box on this - I agree with you, >>>>> strange - "rmnet0" interface. >>>>> >>>>> Alex >>>>> >>>>>> >>>>>> As for the rest of it I have no idea about the presented >>>>>> hardware address of this type so I don't know it the rest of it >>>>>> make sense. >>>>>> >>>>>>> Alex >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0." >>>>>>> dhcp-4.3.5 ./common/lpf.c line number: 551 >>>>>>> >>>>>>> //default: // log_fatal("Unsupported device type %ld >>>>>>> for \"%s\"", // (long int)sa->sa_family, >>>>>>> name); default: hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; >>>>>>> memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>>>>> >>>>>>> (two programmers worked this out). >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> _______________________________________________ v6ops >>>>>>> mailing list v6ops@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>>>> _______________________________________________ v6ops mailing >>>>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> _______________________________________________ v6ops mailing list >>>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 5 23:08:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17F71241F3 for ; Tue, 5 Sep 2017 23:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOmq0qY3Iont for ; Tue, 5 Sep 2017 23:08:20 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81D71321A5 for ; Tue, 5 Sep 2017 23:08:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8668E2m127770; Wed, 6 Sep 2017 08:08:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B5885201F26; Wed, 6 Sep 2017 08:08:14 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A6C95201660; Wed, 6 Sep 2017 08:08:14 +0200 (CEST) Received: from [132.166.84.7] ([132.166.84.7]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8668DSo009644; Wed, 6 Sep 2017 08:08:14 +0200 To: "Templin, Fred L" , "v6ops@ietf.org" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <152f893f24224371aa94ce1bbd54935b@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: Date: Wed, 6 Sep 2017 08:08:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <152f893f24224371aa94ce1bbd54935b@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 06:08:23 -0000 Le 05/09/2017 à 22:07, Templin, Fred L a écrit : [...] >> But the software of maintaining that VPN tunnel up upon handover >> is also considerable, and no compression mechanism could reduce >> it. > > Do you mean handover from one cellular base station to a second > cellular base station? Yes. > From cellular to wireless? No. Only Mobile IP can achieve it. To run that, again, we need to root the device. > Something else? Yes, something else too: handover from getting underground parking to daylight where coverage is present. That means losing connection and obtaining a new prefix. The software to achieve that is difficult to write and typically long. Some part of it should be distributed. > In any event the handover is accommodated by a small exchange of > control messages, but the VPN service itself continues uninterrupted. > Hence, it is a Mobile VPN. Well it is an interesting VPN software. It seems it is a VPN software that resists when the IP address changes on the mobile. [...] >> I wonder whether it can be possible to set the VPN up after the >> DHCPv6-PD exchange happened between the operator and the >> smartphone. > > The system I am describing first obtains an address from the operator > and next sets up the VPN using the operator's service as a link > layer. I see. It is like an overlay network, and it is good many times. Alex > > Thanks - Fred > >> Alex >> >>> >>> Thanks - Fred >>> >>>> Alex >>>> >>>>> >>>>> Thanks - Fred >>>>> >>>>>> - to make an app available to everyone on Android one must >>>>>> pay some money to become a member of a store. DHCP should >>>>>> not be part of that, as SLAAC isnt; just like SLAAC, DHCP >>>>>> should be builtin for free. - the DHCPv6 server software >>>>>> "ISC" breaks if the port numbers are non-standard (not 546 >>>>>> nor 547) or unicast instead of multicast. (e.g. >>>>>> "Discarding Solicit from [snip]; packet sent unicast") This >>>>>> was a real pain, because we had to modify the source code >>>>>> to allow it; other software like VoIP has SIP ports this >>>>>> configurable easily with a GUI. - Cisco parametering CLI of >>>>>> DHCPv6 service may have some problems in transforming a >>>>>> non-standard UDP port 546 of Solicit to a strange 26483. >>>>>> That was a real pain to one. - various DHCPv6 client >>>>>> software break, or do not even start, with any other src >>>>>> and dst UDP ports than the standard (546, 547) and/or >>>>>> non-standard unicast instead of standard multicast. >>>>>> >>>>>> Other reasons proved not to be causes of absence of DHCPv6 >>>>>> PD on cellular links; they were just speculations: - >>>>>> cellular operators dont provide DHCPv6 PD service (there >>>>>> are some who do under some operational conditions) - >>>>>> cellular operators have a hard time making an IPv6 >>>>>> addressing architecture that delegate prefixes instead of >>>>>> addresses (there are some who do make such architecture) - >>>>>> cellular operators only do '64' (it's false, some could do >>>>>> less, like 56 or even 48) - DHCPv6 software is not >>>>>> available on the client (there are some, like on Android, >>>>>> and more, see quoted mails below) - the computer that runs >>>>>> the DHCPv6 client is the same as the one that puts the >>>>>> Solicit on the wire: this is not true, because even in the >>>>>> smallest UE in the market there is still distinction >>>>>> app-vs-modem processors. Often the modem part is >>>>>> confidential, only the binary is available to the public, >>>>>> and there are two IPs on it: Internet Protocol _and_ >>>>>> Intellectual Property. >>>>>> >>>>>> Alex, with thanks to [Hachata], admin(s), managers, and >>>>>> technicals at offices and organisations. >>>>>> >>>>>> >>>>>> Le 18/08/2017 à 18:07, Alexandre Petrescu a écrit : >>>>>>> I have been pointed by a helpful person that an Android >>>>>>> app for DHCPv6 exists there: >>>>>>> >>>>>>> https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client&hl=fr >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It is based on the WIDE DHCPv6 client. >>>>>>> >>>>>>> Further browsing leads to a discussion of DHCPv6 on >>>>>>> Android topic: >>>>>>> https://issuetracker.google.com/issues/36949085 >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> Le 17/07/2017 à 18:26, Alexandre Petrescu a écrit : >>>>>>>> Well, this is to note that we too (Fred mentioned it >>>>>>>> too earlier) made the ISC DHCPv6 dhclient work on >>>>>>>> Android, including DHCPv6 Solicit that requests Prefix >>>>>>>> Delegation. >>>>>>>> >>>>>>>> (but we still dont have a response to DHCP Solicit on >>>>>>>> cellular link). >>>>>>>> >>>>>>>> Alex >>>>>>>> >>>>>>>> Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit : >>>>>>>>> Mark, noted, will try. >>>>>>>>> >>>>>>>>> Just a note... >>>>>>>>> >>>>>>>>> Le 06/07/2017 à 03:16, Mark Andrews a écrit : >>>>>>>>>> >>>>>>>>>> In message >>>>>>>>>> <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, >>>>>>>>>> Alexandre Petrescu writes: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> We discussed extensively about the potential use >>>>>>>>>>> of DHCPv6 Prefix Delegation on cellular links. >>>>>>>>>>> >>>>>>>>>>> The chicken issue is the lack of DHCPv6 PD >>>>>>>>>>> software on typical User Equipment. For >>>>>>>>>>> example, there is no DHCPv6-PD app on Android. >>>>>>>>>>> The egg issue is the lack of operator support of >>>>>>>>>>> DHCPv6-PD towards the User Terminal. For >>>>>>>>>>> example, there is no cellular operator answering >>>>>>>>>>> to DHCPv6-PD requests issued by the User >>>>>>>>>>> Terminal. >>>>>>>>>>> >>>>>>>>>>> To address the chicken issue, we started with an >>>>>>>>>>> ISC DHCP open software client, which does >>>>>>>>>>> implement Prefix Delegation. It can be >>>>>>>>>>> (cross)compiled on various platforms; then type >>>>>>>>>>> "./dhclient -6 -P"; this sends an DHCPv6 Solicit >>>>>>>>>>> Identity Associtaion for Prefix Delegation >>>>>>>>>>> message on the interface. >>>>>>>>>>> >>>>>>>>>>> However, whereas this software runs ok on >>>>>>>>>>> interfaces such as Ethernet, USBnet and WiFi >>>>>>>>>>> interfaces, it breaks if run on the cellular >>>>>>>>>>> interface of some IoT cellular platform. The >>>>>>>>>>> error can be corrected by the quick-and-dirty >>>>>>>>>>> solution below. >>>>>>>>>> >>>>>>>>>> The hack would be better as >>>>>>>>>> >>>>>>>>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; >>>>>>>>>> hw->hbuf[0] = HTYPE_ETHER; memcpy(&hw->hbuf[1], >>>>>>>>>> sa->sa_data, 6); break; #endif default: >>>>>>>>>> log_fatal("Unsupported device type %ld for >>>>>>>>>> \"%s\"", (long int)sa->sa_family, name); break; >>>>>>>>>> >>>>>>>>>> with ARPHRD_XXXX being replaced by the correct >>>>>>>>>> macro for 503 from . Something like >>>>>>>>>> that is at least portable. >>>>>>>>> >>>>>>>>> But it means when I go to other platform will have >>>>>>>>> to modify again the ISC client source code? >>>>>>>>> >>>>>>>>> In cellular terminals there are so many non-IEEE >>>>>>>>> different kinds of links. >>>>>>>>> >>>>>>>>> Other clients work out of the box on this - I agree >>>>>>>>> with you, strange - "rmnet0" interface. >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>>> >>>>>>>>>> As for the rest of it I have no idea about the >>>>>>>>>> presented hardware address of this type so I don't >>>>>>>>>> know it the rest of it make sense. >>>>>>>>>> >>>>>>>>>>> Alex >>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0." >>>>>>>>>>> dhcp-4.3.5 ./common/lpf.c line number: 551 >>>>>>>>>>> >>>>>>>>>>> //default: // log_fatal("Unsupported device >>>>>>>>>>> type %ld for \"%s\"", // (long >>>>>>>>>>> int)sa->sa_family, name); default: hw->hlen = 7; >>>>>>>>>>> hw->hbuf[0] = HTYPE_ETHER; memcpy(&hw->hbuf[1], >>>>>>>>>>> sa->sa_data, 6); break; >>>>>>>>>>> >>>>>>>>>>> (two programmers worked this out). >>>>>>>>>>> >>>>>>>>>>> Alex >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> v6ops mailing list v6ops@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> v6ops mailing list v6ops@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>>> >>>>>>>> _______________________________________________ v6ops >>>>>>>> mailing list v6ops@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>> >>>>>>> _______________________________________________ v6ops >>>>>>> mailing list v6ops@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>> >>>>>> _______________________________________________ v6ops >>>>>> mailing list v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>> > From nobody Wed Sep 6 00:21:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B9132351 for ; Wed, 6 Sep 2017 00:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpXk6RnrGjEq for ; Wed, 6 Sep 2017 00:21:20 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35581321D5 for ; Wed, 6 Sep 2017 00:21:20 -0700 (PDT) Received: from h.hanazo.no (77.16.43.143.tmi.telenormobil.no [77.16.43.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 4A45C2D507A; Wed, 6 Sep 2017 07:21:16 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 27116101E4858; Wed, 6 Sep 2017 09:21:13 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D2F4DA9C-BEF4-4772-BC1B-83D3B4A4C0EC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 6 Sep 2017 09:21:11 +0200 In-Reply-To: Cc: v6ops list To: "Templin, Fred L" References: <150464618134.29784.3337785472849329615@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-templin-v6ops-pdhost-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 07:21:23 -0000 --Apple-Mail=_D2F4DA9C-BEF4-4772-BC1B-83D3B4A4C0EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Fred, Thank for writing this up. Is the only difference from doing 3633 directly, that you allow = addresses from P on the interface connecting R and D? Then the rest of the text is there to deal with that special case. A simpler solution both to specify and to implement would just be to go = with 3633 and state that addresses from P must be on a separate = interface. For the special case, you don't say anything about address resolution. I don't see the value in supporting redirects. You already have to = inject this prefix into the routing system. (setting isRouter to True). Replace talk of WAN link / LAN link. This usage of PD differs from 3633, = in that it would typically be done within a single AS right? Cheers, Ole > On 5 Sep 2017, at 23:27, Templin, Fred L = wrote: >=20 > Hi, here is a draft that is very closely related to RFC7934 and = 'unique-ipv6-prefix-per-host'. > It described the options available for a node that receives a unique = prefix delegation from > the network in terms of routing and multi-addressing considerations. = It is of direct interest > to this community. >=20 > I have given my time and energies to contribute to the aforementioned = v6ops docs and > would appreciate input from the working group on my document. Please = see below for > abstract and URLs. >=20 > Thanks - Fred >=20 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Tuesday, September 05, 2017 2:16 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-templin-v6ops-pdhost-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : IPv6 Prefix Delegation for Hosts > Author : Fred L. Templin > Filename : draft-templin-v6ops-pdhost-06.txt > Pages : 10 > Date : 2017-09-05 >=20 > Abstract: > IPv6 prefixes are typically delegated to requesting routers which > then use them to number their downstream-attached links and = networks. > This document considers both this traditional case, and the case = when > the "requesting router" is actually a simple host which receives a > delegated prefix that it can use for its own internal multi- > addressing purposes. This latter method can be employed in a wide > variety of use cases to allow ample address availability without > impacting link performance. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-templin-v6ops-pdhost-06 > https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_D2F4DA9C-BEF4-4772-BC1B-83D3B4A4C0EC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZr6HoAAoJEL7aWKiYQt92b58P/27KSjCxnNKU3k4F0/cwG9og tFz/6cv5aVSpz0qxGGjSFuA/cUyGf6rIMznbcDSNHdFBW3zaN7pwWxxV4ISve1Y8 F+oopcSAsSI+7Jcey46dKCK2bzsuEo7bY5aikNsBBuHm+L+/iO1cFwnX4fly6JrS BPPVoeWR5uQ3TZad0rr2F+mTQO788k27bt3+Ox4RoQpcwQkD3SGPTFP5u6m4JAu3 yWrHd4wnt/KcYWkrNLZl7E4sLLiRn+1KN+SaN7qYpUKb7SOmIlV3YmCll08gs+Zz yb6hPFd0XXROIcJViANCd1dfr66OzuG5NwCY2MIbC3am+Tu3ATJJ1n7exiyU5BI3 BE18w43cb01bx9U96YXjg67I8gry+eMNBJw6+thoWQdwfbNfU007w2Hr2CecrsKx 0Oqoni0SYnaTzv5ENlfjvXPgu9sGDurkluFFVd2WVCM4Qu7uHEqnrEzzDImUDM3T 74e6d1C2PSidtt5uqB27m1G8KeB+2zAOR785n+ZIWk1k3LbqtuhMYmdfruDznY/8 UTVRqe22a08rPW+tHAy75x4+AWwZ8e4SnglcmJXiJ9P+M+9RCJ9YjMe0Ul83bTP4 NmezhQbqvfScsFxMUTlSggMgTo9vMz/56DowHvWHB7D9tNfv7O0YE1OTEww0Hv0l 9Tnfthi5uqCV3Qu9x+Nq =eq9Z -----END PGP SIGNATURE----- --Apple-Mail=_D2F4DA9C-BEF4-4772-BC1B-83D3B4A4C0EC-- From nobody Wed Sep 6 05:11:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D81132C23 for ; Wed, 6 Sep 2017 05:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 UENx3HCK5CRS for ; Wed, 6 Sep 2017 05:10:59 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCDB13291C for ; Wed, 6 Sep 2017 05:10:59 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id p6so9595313itb.1 for ; Wed, 06 Sep 2017 05:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c9AqMXi4bvJksSrK1cHT14Y982plcjou+np211Xfhzk=; b=I5+49MDtZEP29f+XYaUXCVvKQoylkSmCa+mXWAcjPuDfdSDy7o9DYHnZE07ItP+Syk YteGLHkRM2YLZB9wHKmu6NW2eDyeX1t4LCdO2PeQvKf+lxG3ft+EXce/h3z3er7QWZu6 im/Z4vq1RMuh9L671WIsizrhrmUt0jj7xNEKW++nJK1dqxXNAs46Tw8coFJg9VVhO4pH km2tAbql5W174Oy//NB4FKlUKuayieWdBH+vdP6hERErxtelC88dLrxc72OZCILlz60v 6DQjztaopAdKXowUXAovwcBRcqK+KwVjf21vKNQo/RbXtir55PHGsdY5F7Anr6/0RNXQ jI9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c9AqMXi4bvJksSrK1cHT14Y982plcjou+np211Xfhzk=; b=ijJay30Ck5R+FkdnDnnLb69H4rZ9TV0E4mpPpTfadBKpuOcV5/i4ix7BsO7X5gciSW HESpTWjbZiWtzAcnAlbObMAunL2v/2ptzt8FQuQSaelKlsQ6p06Kv+Xy44LNpnmfWTng 91vWi3MC3S/Lhjjm4hYnAyMM+R3alc4f9bvNxQilLP1gSYrjTROZt75J7XVnoir9I8fV n8h+0FAZBKiocF7qpeVun3xi9D2Tb/QvwkxMqgbzfl3Dn4rlC5Ie09k7BMTYeOr5XtRB fWvHATHR/ig0XdHuLGU/2INY7t8BlVe6/GZTSrE3sVS2ObcMe2uyfdTmg5EZPTsa4rfm AZbQ== X-Gm-Message-State: AHPjjUiagCsnZEqJGpeIgap/Vs7JkV6Sme0OeqWrJjN4/k5+nqPZBdlo +WcisDcU4J+PIV5n1kQKvv+M+Du4SoJd X-Google-Smtp-Source: ADKCNb6NFgNdIcROBMd7msLouUfrWoBbBauGBAQ0dZbjeyf5yNcLnbHuWxjD6pXdwQNSFR39ItErzVm43dqlOvDifBg= X-Received: by 10.36.176.75 with SMTP id b11mr3206280itj.101.1504699857942; Wed, 06 Sep 2017 05:10:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.11 with HTTP; Wed, 6 Sep 2017 05:10:36 -0700 (PDT) In-Reply-To: <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Wed, 6 Sep 2017 21:10:36 +0900 Message-ID: To: "Templin, Fred L" Cc: Alexandre Petrescu , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="089e082318848787330558843cba" Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 12:11:01 -0000 --089e082318848787330558843cba Content-Type: text/plain; charset="UTF-8" On Wed, Sep 6, 2017 at 1:06 AM, Templin, Fred L wrote: > You don't need to root the device to run DHCPv6 PD over a VPN: > > https://developer.android.com/reference/android/net/VpnService.html > > Again, we have DHCPv6 PD working fine over a VPN. > You can't bind to port 546 without rooting the device. You can certainly encapsulate DHCPv6 packets within another protocol that you do have permission to use (e.g., UDP or TCP on a high port), but you don't need VpnService to do that. --089e082318848787330558843cba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 6, 2017 at 1:06 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:
You don'= t need to root the device to run DHCPv6 PD over a VPN:

https://developer.android.com/reference/android/net/VpnService.html

Again, we have DHCPv6 PD working fine over a VPN.

=
You can't bind to port 546 without rooting the device. You c= an certainly encapsulate DHCPv6 packets within another protocol that you do= have permission to use (e.g., UDP or TCP on a high port), but you don'= t need VpnService to do that.
--089e082318848787330558843cba-- From nobody Wed Sep 6 07:35:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECD5132FC1 for ; Wed, 6 Sep 2017 07:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQmjQ7CYRYyE for ; Wed, 6 Sep 2017 07:35:18 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1CDC13243E for ; Wed, 6 Sep 2017 07:35:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v86EZGO7043396; Wed, 6 Sep 2017 07:35:17 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v86EZ6ZB042823 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 6 Sep 2017 07:35:06 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Sep 2017 07:35:05 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 6 Sep 2017 07:35:05 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] DHCPv6 PD client on cellular on Android Thread-Index: AQHTJl1GQaHk8JRqwk2mcUUbqG/ToKKmdHgQgAFf1ACAABZHAA== Date: Wed, 6 Sep 2017 14:35:05 +0000 Message-ID: <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> In-Reply-To: <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 14:35:21 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cmUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTcgMTE6MDMgUE0NCj4gVG86IFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IHY2b3BzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbdjZvcHNdIERIQ1B2NiBQRCBjbGllbnQgb24gY2VsbHVsYXIgb24gQW5kcm9pZA0K PiANCj4gRnJlZCwsDQo+IA0KPiBMZSAwNS8wOS8yMDE3IMOgIDE4OjA2LCBUZW1wbGluLCBGcmVk IEwgYSDDqWNyaXTCoDoNCj4gWy4uLl0NCj4gDQo+ID4+IFNvbWUgZGV0YWlsczoNCj4gPj4gLSB0 aGUgREhDUHY2IHNvZnR3YXJlIG9uIEFuZHJvaWQgaXMgaGFtcGVyZWQgYnkgdGhlIG5lZWQgb2Yg cm9vdCBhY2Nlc3MuDQo+ID4+ICAgICBBbmRyb2lkIGJsb2NrcyB0aGF0LiAgT25lIG5lZWRzIHRv IGFzayB0aGUgcGxhdGZvcm0gbWFudWZhY3R1cmVyDQo+ID4+ICAgICBydW5uaW5nIHRoYXQgQW5k cm9pZCB0byAicm9vdCIgdGhlIHBsYXRmb3JtIHN1Y2ggYXMgdG8gYmUgYWJsZSB0byBydW4NCj4g Pj4gICAgIHNvbWUgb2YgdGhlIERIQ1AgY2xpZW50IHNvZnR3YXJlIChlLmcuIGFzayBIdWF3ZWkg Zm9yIGEga2V5IHRvIHJvb3QNCj4gPj4gICAgIHRoZSBzbWFydHBob25lKS4gIFRoYXQncyBhIHJl YWwgcGFpbi4gIFRoZXJlIGlzIGEgcmlzayBvZiAiYnJpY2tpbmciDQo+ID4+ICAgICB5b3VyIHBs YXRmb3JtLCBpLmUuIHRocm91Z2ggaXQgb3V0IGEgd2luZG93Lg0KPiA+DQo+ID4gWW91IGRvbid0 IG5lZWQgdG8gcm9vdCB0aGUgZGV2aWNlIHRvIHJ1biBESENQdjYgUEQgb3ZlciBhIFZQTjoNCj4g Pg0KPiA+IGh0dHBzOi8vZGV2ZWxvcGVyLmFuZHJvaWQuY29tL3JlZmVyZW5jZS9hbmRyb2lkL25l dC9WcG5TZXJ2aWNlLmh0bWwNCj4gDQo+IEZyZWQsDQo+IA0KPiBJIGNhbiB1bmRlcnN0YW5kIFZQ TiBzZXQgdXAgcnVucyBvayB3aXRob3V0IG5lZWQgdG8gcm9vdCB0aGUgZGV2aWNlDQo+IHJ1bm5p bmcgQW5kcm9pZCBPUy4NCg0KT0sgLSBBbmRyb2lkIHByb3ZpZGVzIFZwblNlcnZpY2UgYnVpbGRl ciBmb3IgdGhpcywgd2hpY2ggaXMgd2hhdCB3ZSBhcmUgdXNpbmcuDQoNCj4gQnV0LCBpcyBESENQ IGNsaWVudCBvdmVyIHRoYXQgVlBOIG5lZWRpbmcgdG8gInJvb3QiIHRoZSBkZXZpY2U/DQoNCk5v Lg0KDQo+IElzIHRoYXQgREhDUCBjbGllbnQgaW4taG91c2Ugc29mdHdhcmUsIG9kaGNwY2QsIFdJ REUsIElTQywgc2NhcHk/DQoNCkluLWhvdXNlIHNvZnR3YXJlLCBidXQgb25seSBhIGZldyBodW5k cmVkIGxpbmVzIG9mIGNvZGUgdGhhdCB3ZXJlDQplYXN5IHRvIHdyaXRlLg0KIA0KPiBJZiBpdCBp cyBpbi1ob3VzZSBzb2Z0d2FyZSwgSSBjYW4gdW5kZXJzdGFuZCB5b3UgbWF5IG5vdCBuZWVkIHRv IHJvb3QNCj4gaXQuICBCdXQgdGhlbiBJIHdvdWxkIGxpa2UgdG8ga25vdyB3aGV0aGVyIHRoYXQg aW4taG91c2Ugc29mdHdhcmUgaXMNCj4gcGFyYW1ldHJhYmxlIHNvIGl0IGNhbiB1bmljYXN0IGFu ZCBub24tc3RkIFVEUCwgc3VjaCB0aGF0IGl0IHJ1bnMgb3Zlcg0KPiBzdHJhaWdodCBpbnRlcmZh Y2VzIHRvbywgbm90IG9ubHkgVlBOLg0KDQpJdCB3b3VsZCBiZSBmaW5lIHRvIHJ1biBpdCBvdmVy IGEgcmVndWxhciBpbnRlcmZhY2UgYW5kIGdldCBiYWNrIERIQ1B2Ng0KaW5mb3JtYXRpb24uIFRo ZSBwcm9ibGVtIGlzIHRoYXQgdGhlIGdvYWwgb2YgREhDUHY2IGlzIHRvIGZpcnN0IG9idGFpbg0K YWRkcmVzc2luZyBpbmZvcm1hdGlvbiBhbmQgc2Vjb25kIHRvIGFzc2lnbiBhZGRyZXNzZXMgdG8g aW50ZXJmYWNlcy4NCkJ1dCwgQW5kcm9pZCBkb2VzIG5vdCBhbGxvdyBhcHBzIHRvIGFzc2lnbiBh ZGRyZXNzZXMgdG8gcmVndWxhcg0KaW50ZXJmYWNlcy4gVGhlIG9ubHkgaW50ZXJmYWNlcyBhbiBh cHAgY2FuIGFzc2lnbiBhZGRyZXNzZXMgdG8gYXJlDQp0aG9zZSBjcmVhdGVkIGJ5IGEgc2Vydmlj ZSB0aGF0IGdpdmVzIGVsZXZhdGVkIHByaXZpbGVnZXMgbGlrZSBWUE4uDQoNClRoYW5rcyAtIEZy ZWQNCg0KPiBBbGV4DQo+IA0KPiA+DQo+ID4gQWdhaW4sIHdlIGhhdmUgREhDUHY2IFBEIHdvcmtp bmcgZmluZSBvdmVyIGEgVlBOLg0KPiA+DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+DQo+ID4+IC0g dG8gbWFrZSBhbiBhcHAgYXZhaWxhYmxlIHRvIGV2ZXJ5b25lIG9uIEFuZHJvaWQgb25lIG11c3Qg cGF5IHNvbWUNCj4gPj4gICAgIG1vbmV5IHRvIGJlY29tZSBhIG1lbWJlciBvZiBhIHN0b3JlLiAg REhDUCBzaG91bGQgbm90IGJlIHBhcnQgb2YgdGhhdCwNCj4gPj4gICAgIGFzIFNMQUFDIGlzbnQ7 IGp1c3QgbGlrZSBTTEFBQywgREhDUCBzaG91bGQgYmUgYnVpbHRpbiBmb3IgZnJlZS4NCj4gPj4g LSB0aGUgREhDUHY2IHNlcnZlciBzb2Z0d2FyZSAiSVNDIiBicmVha3MgaWYgdGhlIHBvcnQgbnVt YmVycyBhcmUNCj4gPj4gICAgIG5vbi1zdGFuZGFyZCAobm90IDU0NiBub3IgNTQ3KSBvciB1bmlj YXN0IGluc3RlYWQgb2YgbXVsdGljYXN0Lg0KPiA+PiAgICAgKGUuZy4gIkRpc2NhcmRpbmcgU29s aWNpdCBmcm9tIFtzbmlwXTsgcGFja2V0IHNlbnQgdW5pY2FzdCIpDQo+ID4+ICAgICBUaGlzIHdh cyBhIHJlYWwgcGFpbiwgYmVjYXVzZSB3ZSBoYWQgdG8gbW9kaWZ5IHRoZSBzb3VyY2UgY29kZQ0K PiA+PiAgICAgdG8gYWxsb3cgaXQ7IG90aGVyIHNvZnR3YXJlIGxpa2UgVm9JUCBoYXMgU0lQIHBv cnRzIHRoaXMgY29uZmlndXJhYmxlDQo+ID4+ICAgICBlYXNpbHkgd2l0aCBhIEdVSS4NCj4gPj4g LSBDaXNjbyBwYXJhbWV0ZXJpbmcgQ0xJIG9mIERIQ1B2NiBzZXJ2aWNlIG1heSBoYXZlIHNvbWUg cHJvYmxlbXMgaW4NCj4gPj4gICAgIHRyYW5zZm9ybWluZyBhIG5vbi1zdGFuZGFyZCBVRFAgcG9y dCA1NDYgb2YgU29saWNpdCB0byBhIHN0cmFuZ2UNCj4gPj4gICAgIDI2NDgzLiAgVGhhdCB3YXMg YSByZWFsIHBhaW4gdG8gb25lLg0KPiA+PiAtIHZhcmlvdXMgREhDUHY2IGNsaWVudCBzb2Z0d2Fy ZSBicmVhaywgb3IgZG8gbm90IGV2ZW4gc3RhcnQsIHdpdGgNCj4gPj4gICAgIGFueSBvdGhlciBz cmMgYW5kIGRzdCBVRFAgcG9ydHMgdGhhbiB0aGUgc3RhbmRhcmQgKDU0NiwgNTQ3KQ0KPiA+PiAg ICAgYW5kL29yIG5vbi1zdGFuZGFyZCB1bmljYXN0IGluc3RlYWQgb2Ygc3RhbmRhcmQgbXVsdGlj YXN0Lg0KPiA+Pg0KPiA+PiBPdGhlciByZWFzb25zIHByb3ZlZCBub3QgdG8gYmUgY2F1c2VzIG9m IGFic2VuY2Ugb2YgREhDUHY2IFBEIG9uDQo+ID4+IGNlbGx1bGFyIGxpbmtzOyB0aGV5IHdlcmUg anVzdCBzcGVjdWxhdGlvbnM6DQo+ID4+IC0gY2VsbHVsYXIgb3BlcmF0b3JzIGRvbnQgcHJvdmlk ZSBESENQdjYgUEQgc2VydmljZSAodGhlcmUgYXJlIHNvbWUgd2hvDQo+ID4+ICAgICBkbyB1bmRl ciBzb21lIG9wZXJhdGlvbmFsIGNvbmRpdGlvbnMpDQo+ID4+IC0gY2VsbHVsYXIgb3BlcmF0b3Jz IGhhdmUgYSBoYXJkIHRpbWUgbWFraW5nIGFuIElQdjYgYWRkcmVzc2luZw0KPiA+PiAgICAgYXJj aGl0ZWN0dXJlIHRoYXQgZGVsZWdhdGUgcHJlZml4ZXMgaW5zdGVhZCBvZiBhZGRyZXNzZXMgKHRo ZXJlIGFyZQ0KPiA+PiAgICAgc29tZSB3aG8gZG8gbWFrZSBzdWNoIGFyY2hpdGVjdHVyZSkNCj4g Pj4gLSBjZWxsdWxhciBvcGVyYXRvcnMgb25seSBkbyAnNjQnIChpdCdzIGZhbHNlLCBzb21lIGNv dWxkIGRvIGxlc3MsDQo+ID4+ICAgICBsaWtlIDU2IG9yIGV2ZW4gNDgpDQo+ID4+IC0gREhDUHY2 IHNvZnR3YXJlIGlzIG5vdCBhdmFpbGFibGUgb24gdGhlIGNsaWVudCAodGhlcmUgYXJlIHNvbWUs IGxpa2UNCj4gPj4gICAgIG9uIEFuZHJvaWQsIGFuZCBtb3JlLCBzZWUgcXVvdGVkIG1haWxzIGJl bG93KQ0KPiA+PiAtIHRoZSBjb21wdXRlciB0aGF0IHJ1bnMgdGhlIERIQ1B2NiBjbGllbnQgaXMg dGhlIHNhbWUgYXMgdGhlIG9uZSB0aGF0DQo+ID4+ICAgICBwdXRzIHRoZSBTb2xpY2l0IG9uIHRo ZSB3aXJlOiB0aGlzIGlzIG5vdCB0cnVlLCBiZWNhdXNlIGV2ZW4gaW4gdGhlDQo+ID4+ICAgICBz bWFsbGVzdCBVRSBpbiB0aGUgbWFya2V0IHRoZXJlIGlzIHN0aWxsIGRpc3RpbmN0aW9uIGFwcC12 cy1tb2RlbQ0KPiA+PiAgICAgcHJvY2Vzc29ycy4gIE9mdGVuIHRoZSBtb2RlbSBwYXJ0IGlzIGNv bmZpZGVudGlhbCwgb25seSB0aGUgYmluYXJ5DQo+ID4+ICAgICBpcyBhdmFpbGFibGUgdG8gdGhl IHB1YmxpYywgYW5kIHRoZXJlIGFyZSB0d28gSVBzIG9uIGl0OiBJbnRlcm5ldA0KPiA+PiAgICAg UHJvdG9jb2wgX2FuZF8gSW50ZWxsZWN0dWFsIFByb3BlcnR5Lg0KPiA+Pg0KPiA+PiBBbGV4LCB3 aXRoIHRoYW5rcyB0byBbSGFjaGF0YV0sIGFkbWluKHMpLCBtYW5hZ2VycywgYW5kIHRlY2huaWNh bHMgYXQNCj4gPj4gb2ZmaWNlcyBhbmQgb3JnYW5pc2F0aW9ucy4NCj4gPj4NCj4gPj4NCj4gPj4g TGUgMTgvMDgvMjAxNyDDoCAxODowNywgQWxleGFuZHJlIFBldHJlc2N1IGEgw6ljcml0IDoNCj4g Pj4+IEkgaGF2ZSBiZWVuIHBvaW50ZWQgYnkgYSBoZWxwZnVsIHBlcnNvbiB0aGF0IGFuIEFuZHJv aWQgYXBwIGZvcg0KPiA+Pj4gREhDUHY2IGV4aXN0cyB0aGVyZToNCj4gPj4+DQo+ID4+PiBodHRw czovL3BsYXkuZ29vZ2xlLmNvbS9zdG9yZS9hcHBzL2RldGFpbHM/aWQ9b3JnLmRhZHVrZS5yZWFs bWFyLmRoY3B2NmNsaWVudCZobD1mcg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ DQo+ID4+PiBJdCBpcyBiYXNlZCBvbiB0aGUgV0lERSBESENQdjYgY2xpZW50Lg0KPiA+Pj4NCj4g Pj4+IEZ1cnRoZXIgYnJvd3NpbmcgbGVhZHMgdG8gYSBkaXNjdXNzaW9uIG9mIERIQ1B2NiBvbiBB bmRyb2lkIHRvcGljOg0KPiA+Pj4gaHR0cHM6Ly9pc3N1ZXRyYWNrZXIuZ29vZ2xlLmNvbS9pc3N1 ZXMvMzY5NDkwODUNCj4gPj4+DQo+ID4+PiBBbGV4DQo+ID4+Pg0KPiA+Pj4gTGUgMTcvMDcvMjAx NyDDoCAxODoyNiwgQWxleGFuZHJlIFBldHJlc2N1IGEgw6ljcml0IDoNCj4gPj4+PiBXZWxsLCB0 aGlzIGlzIHRvIG5vdGUgdGhhdCB3ZSB0b28gKEZyZWQgbWVudGlvbmVkIGl0IHRvbyBlYXJsaWVy KQ0KPiA+Pj4+IG1hZGUgdGhlIElTQyBESENQdjYgZGhjbGllbnQgd29yayBvbiBBbmRyb2lkLCBp bmNsdWRpbmcgREhDUHY2DQo+ID4+Pj4gU29saWNpdCB0aGF0IHJlcXVlc3RzIFByZWZpeCBEZWxl Z2F0aW9uLg0KPiA+Pj4+DQo+ID4+Pj4gKGJ1dCB3ZSBzdGlsbCBkb250IGhhdmUgYSByZXNwb25z ZSB0byBESENQIFNvbGljaXQgb24gY2VsbHVsYXINCj4gPj4+PiBsaW5rKS4NCj4gPj4+Pg0KPiA+ Pj4+IEFsZXgNCj4gPj4+Pg0KPiA+Pj4+IExlIDA2LzA3LzIwMTcgw6AgMTg6MzIsIEFsZXhhbmRy ZSBQZXRyZXNjdSBhIMOpY3JpdCA6DQo+ID4+Pj4+IE1hcmssIG5vdGVkLCB3aWxsIHRyeS4NCj4g Pj4+Pj4NCj4gPj4+Pj4gSnVzdCBhIG5vdGUuLi4NCj4gPj4+Pj4NCj4gPj4+Pj4gTGUgMDYvMDcv MjAxNyDDoCAwMzoxNiwgTWFyayBBbmRyZXdzIGEgw6ljcml0IDoNCj4gPj4+Pj4+DQo+ID4+Pj4+ PiBJbiBtZXNzYWdlIDw3NTM3ZGVlZi04Zjg3LTUxODctMWU0NC01OTVhYzYzYTE2Y2FAZ21haWwu Y29tPiwNCj4gPj4+Pj4+IEFsZXhhbmRyZSBQZXRyZXNjdSB3cml0ZXM6DQo+ID4+Pj4+Pj4gSGVs bG8sDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBXZSBkaXNjdXNzZWQgZXh0ZW5zaXZlbHkgYWJvdXQg dGhlIHBvdGVudGlhbCB1c2Ugb2YgREhDUHY2DQo+ID4+Pj4+Pj4gUHJlZml4IERlbGVnYXRpb24g b24gY2VsbHVsYXIgbGlua3MuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBUaGUgY2hpY2tlbiBpc3N1 ZSBpcyB0aGUgbGFjayBvZiBESENQdjYgUEQgc29mdHdhcmUgb24NCj4gPj4+Pj4+PiB0eXBpY2Fs IFVzZXIgRXF1aXBtZW50LiAgRm9yIGV4YW1wbGUsIHRoZXJlIGlzIG5vIERIQ1B2Ni1QRA0KPiA+ Pj4+Pj4+IGFwcCBvbiBBbmRyb2lkLiAgVGhlIGVnZyBpc3N1ZSBpcyB0aGUgbGFjayBvZiBvcGVy YXRvcg0KPiA+Pj4+Pj4+IHN1cHBvcnQgb2YgREhDUHY2LVBEIHRvd2FyZHMgdGhlIFVzZXIgVGVy bWluYWwuICBGb3IgZXhhbXBsZSwNCj4gPj4+Pj4+PiB0aGVyZSBpcyBubyBjZWxsdWxhciBvcGVy YXRvciBhbnN3ZXJpbmcgdG8gREhDUHY2LVBEIHJlcXVlc3RzDQo+ID4+Pj4+Pj4gaXNzdWVkIGJ5 IHRoZSBVc2VyIFRlcm1pbmFsLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gVG8gYWRkcmVzcyB0aGUg Y2hpY2tlbiBpc3N1ZSwgd2Ugc3RhcnRlZCB3aXRoIGFuIElTQyBESENQDQo+ID4+Pj4+Pj4gb3Bl biBzb2Z0d2FyZSBjbGllbnQsIHdoaWNoIGRvZXMgaW1wbGVtZW50IFByZWZpeCBEZWxlZ2F0aW9u Lg0KPiA+Pj4+Pj4+IEl0IGNhbiBiZSAoY3Jvc3MpY29tcGlsZWQgb24gdmFyaW91cyBwbGF0Zm9y bXM7IHRoZW4gdHlwZQ0KPiA+Pj4+Pj4+ICIuL2RoY2xpZW50IC02IC1QIjsgdGhpcyBzZW5kcyBh biBESENQdjYgU29saWNpdCBJZGVudGl0eQ0KPiA+Pj4+Pj4+IEFzc29jaXRhaW9uIGZvciBQcmVm aXggRGVsZWdhdGlvbiBtZXNzYWdlIG9uIHRoZSBpbnRlcmZhY2UuDQo+ID4+Pj4+Pj4NCj4gPj4+ Pj4+PiBIb3dldmVyLCB3aGVyZWFzIHRoaXMgc29mdHdhcmUgcnVucyBvayBvbiBpbnRlcmZhY2Vz IHN1Y2ggYXMNCj4gPj4+Pj4+PiBFdGhlcm5ldCwgVVNCbmV0IGFuZCBXaUZpIGludGVyZmFjZXMs IGl0IGJyZWFrcyBpZiBydW4gb24gdGhlDQo+ID4+Pj4+Pj4gY2VsbHVsYXIgaW50ZXJmYWNlIG9m IHNvbWUgSW9UIGNlbGx1bGFyIHBsYXRmb3JtLiAgVGhlIGVycm9yDQo+ID4+Pj4+Pj4gY2FuIGJl IGNvcnJlY3RlZCBieSB0aGUgcXVpY2stYW5kLWRpcnR5IHNvbHV0aW9uIGJlbG93Lg0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+IFRoZSBoYWNrIHdvdWxkIGJlIGJldHRlciBhcw0KPiA+Pj4+Pj4NCj4gPj4+ Pj4+ICNpZmRlZiBBUlBIUkRfWFhYWCBjYXNlIEFSUEhSRF9YWFhYOiBody0+aGxlbiA9IDc7IGh3 LT5oYnVmWzBdDQo+ID4+Pj4+PiAgID0gSFRZUEVfRVRIRVI7IG1lbWNweSgmaHctPmhidWZbMV0s IHNhLT5zYV9kYXRhLCA2KTsgYnJlYWs7DQo+ID4+Pj4+PiAjZW5kaWYgZGVmYXVsdDogbG9nX2Zh dGFsKCJVbnN1cHBvcnRlZCBkZXZpY2UgdHlwZSAlbGQgZm9yDQo+ID4+Pj4+PiBcIiVzXCIiLCAo bG9uZyBpbnQpc2EtPnNhX2ZhbWlseSwgbmFtZSk7IGJyZWFrOw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ IHdpdGggQVJQSFJEX1hYWFggYmVpbmcgcmVwbGFjZWQgYnkgdGhlIGNvcnJlY3QgbWFjcm8gZm9y IDUwMw0KPiA+Pj4+Pj4gZnJvbSA8bmV0L2lmX2FycC5oPi4gIFNvbWV0aGluZyBsaWtlIHRoYXQg aXMgYXQgbGVhc3QNCj4gPj4+Pj4+IHBvcnRhYmxlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBCdXQgaXQg bWVhbnMgd2hlbiBJIGdvIHRvIG90aGVyIHBsYXRmb3JtIHdpbGwgaGF2ZSB0byBtb2RpZnkNCj4g Pj4+Pj4gYWdhaW4gdGhlIElTQyBjbGllbnQgc291cmNlIGNvZGU/DQo+ID4+Pj4+DQo+ID4+Pj4+ IEluIGNlbGx1bGFyIHRlcm1pbmFscyB0aGVyZSBhcmUgc28gbWFueSBub24tSUVFRSBkaWZmZXJl bnQga2luZHMNCj4gPj4+Pj4gICBvZiBsaW5rcy4NCj4gPj4+Pj4NCj4gPj4+Pj4gT3RoZXIgY2xp ZW50cyB3b3JrIG91dCBvZiB0aGUgYm94IG9uIHRoaXMgLSBJIGFncmVlIHdpdGggeW91LA0KPiA+ Pj4+PiBzdHJhbmdlIC0gInJtbmV0MCIgaW50ZXJmYWNlLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBBbGV4 DQo+ID4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQXMgZm9yIHRoZSByZXN0IG9mIGl0IEkgaGF2 ZSBubyBpZGVhIGFib3V0IHRoZSBwcmVzZW50ZWQNCj4gPj4+Pj4+IGhhcmR3YXJlIGFkZHJlc3Mg b2YgdGhpcyB0eXBlIHNvIEkgZG9uJ3Qga25vdyBpdCB0aGUgcmVzdCBvZiBpdA0KPiA+Pj4+Pj4g bWFrZSBzZW5zZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gQWxleA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+ Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+ Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4gVGhlIGVycm9yIHNheXMgIi8vVU5T VVBQT1JURUQgREVWSUNFIFRZUEUgNTAzIEZPUiBSTU5FVDAuIg0KPiA+Pj4+Pj4+IGRoY3AtNC4z LjUgLi9jb21tb24vbHBmLmMgbGluZSBudW1iZXI6IDU1MQ0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4g Ly9kZWZhdWx0OiAvLyAgICAgIGxvZ19mYXRhbCgiVW5zdXBwb3J0ZWQgZGV2aWNlIHR5cGUgJWxk DQo+ID4+Pj4+Pj4gZm9yIFwiJXNcIiIsIC8vICAgICAgICAgICAgICAgIChsb25nIGludClzYS0+ c2FfZmFtaWx5LA0KPiA+Pj4+Pj4+IG5hbWUpOyBkZWZhdWx0OiBody0+aGxlbiA9IDc7IGh3LT5o YnVmWzBdID0gSFRZUEVfRVRIRVI7DQo+ID4+Pj4+Pj4gbWVtY3B5KCZody0+aGJ1ZlsxXSwgc2Et PnNhX2RhdGEsIDYpOyBicmVhazsNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICh0d28gcHJvZ3JhbW1l cnMgd29ya2VkIHRoaXMgb3V0KS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEFsZXgNCj4gPj4+Pj4+ Pg0KPiA+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fIHY2b3BzDQo+ID4+Pj4+Pj4gbWFpbGluZyBsaXN0IHY2b3BzQGlldGYub3JnDQo+ID4+Pj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pj4+Pg0K PiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyB2 Nm9wcyBtYWlsaW5nDQo+ID4+Pj4+IGxpc3QgdjZvcHNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gdjZvcHMgbWFpbGluZyBsaXN0DQo+ ID4+Pj4gdjZvcHNAaWV0Zi5vcmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fIHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+Pj4gdjZvcHNAaWV0Zi5vcmcgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pg0KPiA+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiB2Nm9wcyBt YWlsaW5nIGxpc3QNCj4gPj4gdjZvcHNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Wed Sep 6 07:40:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58310132D77 for ; Wed, 6 Sep 2017 07:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3S0fEbGA4KA for ; Wed, 6 Sep 2017 07:40:44 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0304113243E for ; Wed, 6 Sep 2017 07:40:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v86EehSa016961; Wed, 6 Sep 2017 07:40:43 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v86EedVv016923 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 6 Sep 2017 07:40:39 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Sep 2017 07:40:38 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 6 Sep 2017 07:40:38 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] DHCPv6 PD client on cellular on Android Thread-Index: AQHTJl1GQaHk8JRqwk2mcUUbqG/ToKKmdHgQgACwUgD//46dcIAAeBiA//+LG4CAAR8PgIAAGE5Q Date: Wed, 6 Sep 2017 14:40:38 +0000 Message-ID: <2df79e19030f4b30a1b97e7d9d7fcba1@XCH15-06-08.nw.nos.boeing.com> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <152f893f24224371aa94ce1bbd54935b@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 14:40:46 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cmUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDUsIDIwMTcgMTE6MDggUE0NCj4gVG86IFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IHY2b3BzQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbdjZvcHNdIERIQ1B2NiBQRCBjbGllbnQgb24gY2VsbHVsYXIgb24gQW5kcm9pZA0K PiANCj4gDQo+IA0KPiBMZSAwNS8wOS8yMDE3IMOgIDIyOjA3LCBUZW1wbGluLCBGcmVkIEwgYSDD qWNyaXQgOg0KPiBbLi4uXQ0KPiANCj4gPj4gQnV0IHRoZSBzb2Z0d2FyZSBvZiBtYWludGFpbmlu ZyB0aGF0IFZQTiB0dW5uZWwgdXAgdXBvbiBoYW5kb3Zlcg0KPiA+PiBpcyBhbHNvIGNvbnNpZGVy YWJsZSwgYW5kIG5vIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBjb3VsZCByZWR1Y2UNCj4gPj4gaXQu DQo+ID4NCj4gPiBEbyB5b3UgbWVhbiBoYW5kb3ZlciBmcm9tIG9uZSBjZWxsdWxhciBiYXNlIHN0 YXRpb24gdG8gYSBzZWNvbmQNCj4gPiBjZWxsdWxhciBiYXNlIHN0YXRpb24/DQo+IA0KPiBZZXMu DQoNCk9LLg0KDQo+ID4gRnJvbSBjZWxsdWxhciB0byB3aXJlbGVzcz8NCj4gDQo+IE5vLiAgT25s eSBNb2JpbGUgSVAgY2FuIGFjaGlldmUgaXQuICBUbyBydW4gdGhhdCwgYWdhaW4sIHdlIG5lZWQg dG8gcm9vdA0KPiB0aGUgZGV2aWNlLg0KDQpObywgbm8gTUlQdjYuIEkgdXNlIElQdjYgTkQgaW5z dGVhZCB0byBhY2NvbW1vZGF0ZSBhZGRyZXNzIGNoYW5nZXMsDQptdWx0aXBsZSBpbnRlcmZhY2Vz LCBldGMuIElQdjYgTkQgcHJvdmlkZXMgYSBncmVhdCBtb2JpbGl0eSBzZXJ2aWNlIG92ZXINCnR1 bm5lbCB2aXJ0dWFsIGludGVyZmFjZXMuDQoNCj4gPiBTb21ldGhpbmcgZWxzZT8NCj4gDQo+IFll cywgc29tZXRoaW5nIGVsc2UgdG9vOiBoYW5kb3ZlciBmcm9tIGdldHRpbmcgdW5kZXJncm91bmQg cGFya2luZyB0bw0KPiBkYXlsaWdodCB3aGVyZSBjb3ZlcmFnZSBpcyBwcmVzZW50LiAgVGhhdCBt ZWFucyBsb3NpbmcgY29ubmVjdGlvbiBhbmQNCj4gb2J0YWluaW5nIGEgbmV3IHByZWZpeC4NCg0K V2l0aCBWUE4sIHlvdSBnZXQgdG8ga2VlcCB0aGUgc2FtZSBwcmVmaXggZXZlbiB0aG91Z2ggdGhl IHVuZGVybHlpbmcNCmludGVyZmFjZSBhZGRyZXNzIGNoYW5nZXMuDQoNCj4gVGhlIHNvZnR3YXJl IHRvIGFjaGlldmUgdGhhdCBpcyBkaWZmaWN1bHQgdG8gd3JpdGUgYW5kIHR5cGljYWxseSBsb25n Lg0KPiBTb21lIHBhcnQgb2YgaXQgc2hvdWxkIGJlIGRpc3RyaWJ1dGVkLg0KPiANCj4gPiBJbiBh bnkgZXZlbnQgdGhlIGhhbmRvdmVyIGlzIGFjY29tbW9kYXRlZCBieSBhIHNtYWxsIGV4Y2hhbmdl IG9mDQo+ID4gY29udHJvbCBtZXNzYWdlcywgYnV0IHRoZSBWUE4gc2VydmljZSBpdHNlbGYgY29u dGludWVzIHVuaW50ZXJydXB0ZWQuDQo+ID4gSGVuY2UsIGl0IGlzIGEgTW9iaWxlIFZQTi4NCj4g DQo+IFdlbGwgaXQgaXMgYW4gaW50ZXJlc3RpbmcgVlBOIHNvZnR3YXJlLiAgSXQgc2VlbXMgaXQg aXMgYSBWUE4gc29mdHdhcmUNCj4gdGhhdCByZXNpc3RzIHdoZW4gdGhlIElQIGFkZHJlc3MgY2hh bmdlcyBvbiB0aGUgbW9iaWxlLg0KDQpJdCBpcyBhIFZQTiBzb2Z0d2FyZSB3aXRoIGFuIElQdjYg cHJlZml4IHRoYXQgcGVyc2lzdHMgKG5vdCAicmVzaXN0aXMiIDpefSApDQp3aGVuIHRoZSBJUCBh ZGRyZXNzIG9mIHRoZSBtb2JpbGUgY2hhbmdlcy4NCg0KPiBbLi4uXQ0KPiANCj4gPj4gSSB3b25k ZXIgd2hldGhlciBpdCBjYW4gYmUgcG9zc2libGUgdG8gc2V0IHRoZSBWUE4gdXAgYWZ0ZXIgdGhl DQo+ID4+IERIQ1B2Ni1QRCBleGNoYW5nZSBoYXBwZW5lZCBiZXR3ZWVuIHRoZSBvcGVyYXRvciBh bmQgdGhlDQo+ID4+IHNtYXJ0cGhvbmUuDQo+ID4NCj4gPiBUaGUgc3lzdGVtIEkgYW0gZGVzY3Jp YmluZyBmaXJzdCBvYnRhaW5zIGFuIGFkZHJlc3MgZnJvbSB0aGUgb3BlcmF0b3INCj4gPiBhbmQg bmV4dCBzZXRzIHVwIHRoZSBWUE4gdXNpbmcgdGhlIG9wZXJhdG9yJ3Mgc2VydmljZSBhcyBhIGxp bmsNCj4gPiBsYXllci4NCj4gDQo+IEkgc2VlLiAgSXQgaXMgbGlrZSBhbiBvdmVybGF5IG5ldHdv cmssIGFuZCBpdCBpcyBnb29kIG1hbnkgdGltZXMuDQoNCk92ZXJsYXkgbmV0d29yayB5ZXMuIEdv b2QgbWFueSB0aW1lcywgYWxzbyB5ZXMuDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGlu QGJvZWluZy5jb20NCg0KPiBBbGV4DQo+IA0KPiA+DQo+ID4gVGhhbmtzIC0gRnJlZA0KPiA+DQo+ ID4+IEFsZXgNCj4gPj4NCj4gPj4+DQo+ID4+PiBUaGFua3MgLSBGcmVkDQo+ID4+Pg0KPiA+Pj4+ IEFsZXgNCj4gPj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUaGFua3MgLSBGcmVkDQo+ID4+Pj4+DQo+ ID4+Pj4+PiAtIHRvIG1ha2UgYW4gYXBwIGF2YWlsYWJsZSB0byBldmVyeW9uZSBvbiBBbmRyb2lk IG9uZSBtdXN0DQo+ID4+Pj4+PiBwYXkgc29tZSBtb25leSB0byBiZWNvbWUgYSBtZW1iZXIgb2Yg YSBzdG9yZS4gIERIQ1Agc2hvdWxkDQo+ID4+Pj4+PiBub3QgYmUgcGFydCBvZiB0aGF0LCBhcyBT TEFBQyBpc250OyBqdXN0IGxpa2UgU0xBQUMsIERIQ1ANCj4gPj4+Pj4+IHNob3VsZCBiZSBidWls dGluIGZvciBmcmVlLiAtIHRoZSBESENQdjYgc2VydmVyIHNvZnR3YXJlDQo+ID4+Pj4+PiAiSVND IiBicmVha3MgaWYgdGhlIHBvcnQgbnVtYmVycyBhcmUgbm9uLXN0YW5kYXJkIChub3QgNTQ2DQo+ ID4+Pj4+PiBub3IgNTQ3KSBvciB1bmljYXN0IGluc3RlYWQgb2YgbXVsdGljYXN0LiAoZS5nLg0K PiA+Pj4+Pj4gIkRpc2NhcmRpbmcgU29saWNpdCBmcm9tIFtzbmlwXTsgcGFja2V0IHNlbnQgdW5p Y2FzdCIpIFRoaXMNCj4gPj4+Pj4+IHdhcyBhIHJlYWwgcGFpbiwgYmVjYXVzZSB3ZSBoYWQgdG8g bW9kaWZ5IHRoZSBzb3VyY2UgY29kZQ0KPiA+Pj4+Pj4gdG8gYWxsb3cgaXQ7IG90aGVyIHNvZnR3 YXJlIGxpa2UgVm9JUCBoYXMgU0lQIHBvcnRzIHRoaXMNCj4gPj4+Pj4+IGNvbmZpZ3VyYWJsZSBl YXNpbHkgd2l0aCBhIEdVSS4gLSBDaXNjbyBwYXJhbWV0ZXJpbmcgQ0xJIG9mDQo+ID4+Pj4+PiBE SENQdjYgc2VydmljZSBtYXkgaGF2ZSBzb21lIHByb2JsZW1zIGluIHRyYW5zZm9ybWluZyBhDQo+ ID4+Pj4+PiBub24tc3RhbmRhcmQgVURQIHBvcnQgNTQ2IG9mIFNvbGljaXQgdG8gYSBzdHJhbmdl IDI2NDgzLg0KPiA+Pj4+Pj4gVGhhdCB3YXMgYSByZWFsIHBhaW4gdG8gb25lLiAtIHZhcmlvdXMg REhDUHY2IGNsaWVudA0KPiA+Pj4+Pj4gc29mdHdhcmUgYnJlYWssIG9yIGRvIG5vdCBldmVuIHN0 YXJ0LCB3aXRoIGFueSBvdGhlciBzcmMNCj4gPj4+Pj4+IGFuZCBkc3QgVURQIHBvcnRzIHRoYW4g dGhlIHN0YW5kYXJkICg1NDYsIDU0NykgYW5kL29yDQo+ID4+Pj4+PiBub24tc3RhbmRhcmQgdW5p Y2FzdCBpbnN0ZWFkIG9mIHN0YW5kYXJkIG11bHRpY2FzdC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBP dGhlciByZWFzb25zIHByb3ZlZCBub3QgdG8gYmUgY2F1c2VzIG9mIGFic2VuY2Ugb2YgREhDUHY2 DQo+ID4+Pj4+PiBQRCBvbiBjZWxsdWxhciBsaW5rczsgdGhleSB3ZXJlIGp1c3Qgc3BlY3VsYXRp b25zOiAtDQo+ID4+Pj4+PiBjZWxsdWxhciBvcGVyYXRvcnMgZG9udCBwcm92aWRlIERIQ1B2NiBQ RCBzZXJ2aWNlICh0aGVyZQ0KPiA+Pj4+Pj4gYXJlIHNvbWUgd2hvIGRvIHVuZGVyIHNvbWUgb3Bl cmF0aW9uYWwgY29uZGl0aW9ucykgLQ0KPiA+Pj4+Pj4gY2VsbHVsYXIgb3BlcmF0b3JzIGhhdmUg YSBoYXJkIHRpbWUgbWFraW5nIGFuIElQdjYNCj4gPj4+Pj4+IGFkZHJlc3NpbmcgYXJjaGl0ZWN0 dXJlIHRoYXQgZGVsZWdhdGUgcHJlZml4ZXMgaW5zdGVhZCBvZg0KPiA+Pj4+Pj4gYWRkcmVzc2Vz ICh0aGVyZSBhcmUgc29tZSB3aG8gZG8gbWFrZSBzdWNoIGFyY2hpdGVjdHVyZSkgLQ0KPiA+Pj4+ Pj4gY2VsbHVsYXIgb3BlcmF0b3JzIG9ubHkgZG8gJzY0JyAoaXQncyBmYWxzZSwgc29tZSBjb3Vs ZCBkbw0KPiA+Pj4+Pj4gbGVzcywgbGlrZSA1NiBvciBldmVuIDQ4KSAtIERIQ1B2NiBzb2Z0d2Fy ZSBpcyBub3QNCj4gPj4+Pj4+IGF2YWlsYWJsZSBvbiB0aGUgY2xpZW50ICh0aGVyZSBhcmUgc29t ZSwgbGlrZSBvbiBBbmRyb2lkLA0KPiA+Pj4+Pj4gYW5kIG1vcmUsIHNlZSBxdW90ZWQgbWFpbHMg YmVsb3cpIC0gdGhlIGNvbXB1dGVyIHRoYXQgcnVucw0KPiA+Pj4+Pj4gdGhlIERIQ1B2NiBjbGll bnQgaXMgdGhlIHNhbWUgYXMgdGhlIG9uZSB0aGF0IHB1dHMgdGhlDQo+ID4+Pj4+PiBTb2xpY2l0 IG9uIHRoZSB3aXJlOiB0aGlzIGlzIG5vdCB0cnVlLCBiZWNhdXNlIGV2ZW4gaW4gdGhlDQo+ID4+ Pj4+PiAgc21hbGxlc3QgVUUgaW4gdGhlIG1hcmtldCB0aGVyZSBpcyBzdGlsbCBkaXN0aW5jdGlv bg0KPiA+Pj4+Pj4gYXBwLXZzLW1vZGVtIHByb2Nlc3NvcnMuICBPZnRlbiB0aGUgbW9kZW0gcGFy dCBpcw0KPiA+Pj4+Pj4gY29uZmlkZW50aWFsLCBvbmx5IHRoZSBiaW5hcnkgaXMgYXZhaWxhYmxl IHRvIHRoZSBwdWJsaWMsDQo+ID4+Pj4+PiBhbmQgdGhlcmUgYXJlIHR3byBJUHMgb24gaXQ6IElu dGVybmV0IFByb3RvY29sIF9hbmRfDQo+ID4+Pj4+PiBJbnRlbGxlY3R1YWwgUHJvcGVydHkuDQo+ ID4+Pj4+Pg0KPiA+Pj4+Pj4gQWxleCwgd2l0aCB0aGFua3MgdG8gW0hhY2hhdGFdLCBhZG1pbihz KSwgbWFuYWdlcnMsIGFuZA0KPiA+Pj4+Pj4gdGVjaG5pY2FscyBhdCBvZmZpY2VzIGFuZCBvcmdh bmlzYXRpb25zLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBMZSAxOC8wOC8yMDE3IMOg IDE4OjA3LCBBbGV4YW5kcmUgUGV0cmVzY3UgYSDDqWNyaXQgOg0KPiA+Pj4+Pj4+IEkgaGF2ZSBi ZWVuIHBvaW50ZWQgYnkgYSBoZWxwZnVsIHBlcnNvbiB0aGF0IGFuIEFuZHJvaWQNCj4gPj4+Pj4+ PiBhcHAgZm9yIERIQ1B2NiBleGlzdHMgdGhlcmU6DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBodHRw czovL3BsYXkuZ29vZ2xlLmNvbS9zdG9yZS9hcHBzL2RldGFpbHM/aWQ9b3JnLmRhZHVrZS5yZWFs bWFyLmRoY3B2NmNsaWVudCZobD1mcg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0K PiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4g SXQgaXMgYmFzZWQgb24gdGhlIFdJREUgREhDUHY2IGNsaWVudC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+ Pj4+IEZ1cnRoZXIgYnJvd3NpbmcgbGVhZHMgdG8gYSBkaXNjdXNzaW9uIG9mIERIQ1B2NiBvbg0K PiA+Pj4+Pj4+IEFuZHJvaWQgdG9waWM6DQo+ID4+Pj4+Pj4gaHR0cHM6Ly9pc3N1ZXRyYWNrZXIu Z29vZ2xlLmNvbS9pc3N1ZXMvMzY5NDkwODUNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEFsZXgNCj4g Pj4+Pj4+Pg0KPiA+Pj4+Pj4+IExlIDE3LzA3LzIwMTcgw6AgMTg6MjYsIEFsZXhhbmRyZSBQZXRy ZXNjdSBhIMOpY3JpdCA6DQo+ID4+Pj4+Pj4+IFdlbGwsIHRoaXMgaXMgdG8gbm90ZSB0aGF0IHdl IHRvbyAoRnJlZCBtZW50aW9uZWQgaXQNCj4gPj4+Pj4+Pj4gdG9vIGVhcmxpZXIpIG1hZGUgdGhl IElTQyBESENQdjYgZGhjbGllbnQgd29yayBvbg0KPiA+Pj4+Pj4+PiBBbmRyb2lkLCBpbmNsdWRp bmcgREhDUHY2IFNvbGljaXQgdGhhdCByZXF1ZXN0cyBQcmVmaXgNCj4gPj4+Pj4+Pj4gRGVsZWdh dGlvbi4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gKGJ1dCB3ZSBzdGlsbCBkb250IGhhdmUgYSBy ZXNwb25zZSB0byBESENQIFNvbGljaXQgb24NCj4gPj4+Pj4+Pj4gY2VsbHVsYXIgbGluaykuDQo+ ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEFsZXgNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gTGUgMDYv MDcvMjAxNyDDoCAxODozMiwgQWxleGFuZHJlIFBldHJlc2N1IGEgw6ljcml0IDoNCj4gPj4+Pj4+ Pj4+IE1hcmssIG5vdGVkLCB3aWxsIHRyeS4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBKdXN0 IGEgbm90ZS4uLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IExlIDA2LzA3LzIwMTcgw6AgMDM6 MTYsIE1hcmsgQW5kcmV3cyBhIMOpY3JpdCA6DQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBJ biBtZXNzYWdlDQo+ID4+Pj4+Pj4+Pj4gPDc1MzdkZWVmLThmODctNTE4Ny0xZTQ0LTU5NWFjNjNh MTZjYUBnbWFpbC5jb20+LA0KPiA+Pj4+Pj4+Pj4+IEFsZXhhbmRyZSBQZXRyZXNjdSB3cml0ZXM6 DQo+ID4+Pj4+Pj4+Pj4+IEhlbGxvLA0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBXZSBk aXNjdXNzZWQgZXh0ZW5zaXZlbHkgYWJvdXQgdGhlIHBvdGVudGlhbCB1c2UNCj4gPj4+Pj4+Pj4+ Pj4gb2YgREhDUHY2IFByZWZpeCBEZWxlZ2F0aW9uIG9uIGNlbGx1bGFyIGxpbmtzLg0KPiA+Pj4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBUaGUgY2hpY2tlbiBpc3N1ZSBpcyB0aGUgbGFjayBvZiBE SENQdjYgUEQNCj4gPj4+Pj4+Pj4+Pj4gc29mdHdhcmUgb24gdHlwaWNhbCBVc2VyIEVxdWlwbWVu dC4gIEZvcg0KPiA+Pj4+Pj4+Pj4+PiBleGFtcGxlLCB0aGVyZSBpcyBubyBESENQdjYtUEQgYXBw IG9uIEFuZHJvaWQuDQo+ID4+Pj4+Pj4+Pj4+IFRoZSBlZ2cgaXNzdWUgaXMgdGhlIGxhY2sgb2Yg b3BlcmF0b3Igc3VwcG9ydCBvZg0KPiA+Pj4+Pj4+Pj4+PiBESENQdjYtUEQgdG93YXJkcyB0aGUg VXNlciBUZXJtaW5hbC4gIEZvcg0KPiA+Pj4+Pj4+Pj4+PiBleGFtcGxlLCB0aGVyZSBpcyBubyBj ZWxsdWxhciBvcGVyYXRvciBhbnN3ZXJpbmcNCj4gPj4+Pj4+Pj4+Pj4gdG8gREhDUHY2LVBEIHJl cXVlc3RzIGlzc3VlZCBieSB0aGUgVXNlcg0KPiA+Pj4+Pj4+Pj4+PiBUZXJtaW5hbC4NCj4gPj4+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gVG8gYWRkcmVzcyB0aGUgY2hpY2tlbiBpc3N1ZSwgd2Ug c3RhcnRlZCB3aXRoIGFuDQo+ID4+Pj4+Pj4+Pj4+IElTQyBESENQIG9wZW4gc29mdHdhcmUgY2xp ZW50LCB3aGljaCBkb2VzDQo+ID4+Pj4+Pj4+Pj4+IGltcGxlbWVudCBQcmVmaXggRGVsZWdhdGlv bi4gSXQgY2FuIGJlDQo+ID4+Pj4+Pj4+Pj4+IChjcm9zcyljb21waWxlZCBvbiB2YXJpb3VzIHBs YXRmb3JtczsgdGhlbiB0eXBlDQo+ID4+Pj4+Pj4+Pj4+ICIuL2RoY2xpZW50IC02IC1QIjsgdGhp cyBzZW5kcyBhbiBESENQdjYgU29saWNpdA0KPiA+Pj4+Pj4+Pj4+PiBJZGVudGl0eSBBc3NvY2l0 YWlvbiBmb3IgUHJlZml4IERlbGVnYXRpb24NCj4gPj4+Pj4+Pj4+Pj4gbWVzc2FnZSBvbiB0aGUg aW50ZXJmYWNlLg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBIb3dldmVyLCB3aGVyZWFz IHRoaXMgc29mdHdhcmUgcnVucyBvayBvbg0KPiA+Pj4+Pj4+Pj4+PiBpbnRlcmZhY2VzIHN1Y2gg YXMgRXRoZXJuZXQsIFVTQm5ldCBhbmQgV2lGaQ0KPiA+Pj4+Pj4+Pj4+PiBpbnRlcmZhY2VzLCBp dCBicmVha3MgaWYgcnVuIG9uIHRoZSBjZWxsdWxhcg0KPiA+Pj4+Pj4+Pj4+PiBpbnRlcmZhY2Ug b2Ygc29tZSBJb1QgY2VsbHVsYXIgcGxhdGZvcm0uICBUaGUNCj4gPj4+Pj4+Pj4+Pj4gZXJyb3Ig Y2FuIGJlIGNvcnJlY3RlZCBieSB0aGUgcXVpY2stYW5kLWRpcnR5DQo+ID4+Pj4+Pj4+Pj4+IHNv bHV0aW9uIGJlbG93Lg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gVGhlIGhhY2sgd291bGQg YmUgYmV0dGVyIGFzDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiAjaWZkZWYgQVJQSFJEX1hY WFggY2FzZSBBUlBIUkRfWFhYWDogaHctPmhsZW4gPSA3Ow0KPiA+Pj4+Pj4+Pj4+IGh3LT5oYnVm WzBdID0gSFRZUEVfRVRIRVI7IG1lbWNweSgmaHctPmhidWZbMV0sDQo+ID4+Pj4+Pj4+Pj4gc2Et PnNhX2RhdGEsIDYpOyBicmVhazsgI2VuZGlmIGRlZmF1bHQ6DQo+ID4+Pj4+Pj4+Pj4gbG9nX2Zh dGFsKCJVbnN1cHBvcnRlZCBkZXZpY2UgdHlwZSAlbGQgZm9yDQo+ID4+Pj4+Pj4+Pj4gXCIlc1wi IiwgKGxvbmcgaW50KXNhLT5zYV9mYW1pbHksIG5hbWUpOyBicmVhazsNCj4gPj4+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj4+IHdpdGggQVJQSFJEX1hYWFggYmVpbmcgcmVwbGFjZWQgYnkgdGhlIGNvcnJl Y3QNCj4gPj4+Pj4+Pj4+PiBtYWNybyBmb3IgNTAzIGZyb20gPG5ldC9pZl9hcnAuaD4uICBTb21l dGhpbmcgbGlrZQ0KPiA+Pj4+Pj4+Pj4+IHRoYXQgaXMgYXQgbGVhc3QgcG9ydGFibGUuDQo+ID4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gQnV0IGl0IG1lYW5zIHdoZW4gSSBnbyB0byBvdGhlciBwbGF0 Zm9ybSB3aWxsIGhhdmUNCj4gPj4+Pj4+Pj4+IHRvIG1vZGlmeSBhZ2FpbiB0aGUgSVNDIGNsaWVu dCBzb3VyY2UgY29kZT8NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBJbiBjZWxsdWxhciB0ZXJt aW5hbHMgdGhlcmUgYXJlIHNvIG1hbnkgbm9uLUlFRUUNCj4gPj4+Pj4+Pj4+IGRpZmZlcmVudCBr aW5kcyBvZiBsaW5rcy4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBPdGhlciBjbGllbnRzIHdv cmsgb3V0IG9mIHRoZSBib3ggb24gdGhpcyAtIEkgYWdyZWUNCj4gPj4+Pj4+Pj4+IHdpdGggeW91 LCBzdHJhbmdlIC0gInJtbmV0MCIgaW50ZXJmYWNlLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ IEFsZXgNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiBBcyBmb3IgdGhl IHJlc3Qgb2YgaXQgSSBoYXZlIG5vIGlkZWEgYWJvdXQgdGhlDQo+ID4+Pj4+Pj4+Pj4gcHJlc2Vu dGVkIGhhcmR3YXJlIGFkZHJlc3Mgb2YgdGhpcyB0eXBlIHNvIEkgZG9uJ3QNCj4gPj4+Pj4+Pj4+ PiBrbm93IGl0IHRoZSByZXN0IG9mIGl0IG1ha2Ugc2Vuc2UuDQo+ID4+Pj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4+Pj4gQWxleA0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4NCj4gVGhlIGVycm9yIHNheXMgIi8vVU5TVVBQT1JURUQgREVW SUNFIFRZUEUgNTAzIEZPUiBSTU5FVDAuIg0KPiA+Pj4+Pj4+Pj4+PiBkaGNwLTQuMy41IC4vY29t bW9uL2xwZi5jIGxpbmUgbnVtYmVyOiA1NTENCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4g Ly9kZWZhdWx0OiAvLyAgICAgIGxvZ19mYXRhbCgiVW5zdXBwb3J0ZWQgZGV2aWNlDQo+ID4+Pj4+ Pj4+Pj4+IHR5cGUgJWxkIGZvciBcIiVzXCIiLCAvLyAgICAgICAgICAgICAgICAobG9uZw0KPiA+ Pj4+Pj4+Pj4+PiBpbnQpc2EtPnNhX2ZhbWlseSwgbmFtZSk7IGRlZmF1bHQ6IGh3LT5obGVuID0g NzsNCj4gPj4+Pj4+Pj4+Pj4gaHctPmhidWZbMF0gPSBIVFlQRV9FVEhFUjsgbWVtY3B5KCZody0+ aGJ1ZlsxXSwNCj4gPj4+Pj4+Pj4+Pj4gc2EtPnNhX2RhdGEsIDYpOyBicmVhazsNCj4gPj4+Pj4+ Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gKHR3byBwcm9ncmFtbWVycyB3b3JrZWQgdGhpcyBvdXQpLg0K PiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBBbGV4DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+Pj4+Pj4+Pj4+IHY2b3BzIG1haWxpbmcgbGlzdCB2Nm9wc0BpZXRmLm9yZw0KPiA+Pj4+Pj4+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPj4+Pj4+Pj4+IHY2b3BzIG1haWxpbmcgbGlzdCB2Nm9wc0BpZXRmLm9yZw0K PiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K PiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXyB2Nm9wcw0KPiA+Pj4+Pj4+PiBtYWlsaW5nIGxpc3QgdjZvcHNAaWV0Zi5v cmcNCj4gPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gdjZvcHMNCj4gPj4+Pj4+PiBtYWlsaW5nIGxpc3QgdjZvcHNAaWV0Zi5v cmcNCj4gPj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gdjZvcHMNCj4gPj4+Pj4+IG1haWxpbmcgbGlzdCB2Nm9wc0BpZXRmLm9yZw0K PiA+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+ Pj4NCj4gPg0KDQo= From nobody Wed Sep 6 07:53:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C705C132494 for ; Wed, 6 Sep 2017 07:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkLa5wWvesqK for ; Wed, 6 Sep 2017 07:53:52 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2AC132A89 for ; Wed, 6 Sep 2017 07:53:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v86ErpSE013481; Wed, 6 Sep 2017 07:53:52 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v86ErmeB013446 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 6 Sep 2017 07:53:48 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Sep 2017 07:53:47 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 6 Sep 2017 07:53:47 -0700 From: "Templin, Fred L" To: Ole Troan CC: v6ops list Thread-Topic: [v6ops] I-D Action: draft-templin-v6ops-pdhost-06.txt Thread-Index: AQHTJoxCYBlQLPEYAUGtsG36832ak6KmzGnwgAEdRYCAAAaMYA== Date: Wed, 6 Sep 2017 14:53:47 +0000 Message-ID: <4da4597820ab4495b1b370406f38e8b9@XCH15-06-08.nw.nos.boeing.com> References: <150464618134.29784.3337785472849329615@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-templin-v6ops-pdhost-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 14:53:56 -0000 Hi Ole, > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: Wednesday, September 06, 2017 12:21 AM > To: Templin, Fred L > Cc: v6ops list > Subject: Re: [v6ops] I-D Action: draft-templin-v6ops-pdhost-06.txt >=20 > Hi Fred, >=20 > Thank for writing this up. Thanks for your consideration. > Is the only difference from doing 3633 directly, that you allow addresses= from P on the interface connecting R and D? > Then the rest of the text is there to deal with that special case. This is doing RFC3633 directly, but enumerates the possibilities of what a = requesting node can do with the delegated prefix it receives. And, it is about end sy= stems and not "traditional" routers as the requesting node. > A simpler solution both to specify and to implement would just be to go w= ith 3633 and state that addresses from P must be on a > separate interface. This document is intended to be an informational/BCP and not a specificatio= n. RFC3633 is the specification for the primary example prefix delegation serv= ice, and the purpose of this document is only to enumerate the possibilities.=20 > For the special case, you don't say anything about address resolution. > I don't see the value in supporting redirects. You already have to inject= this prefix into the routing system. > (setting isRouter to True). I am considering the case where there may be large links with many thousand= s or more of these kinds of end systems where it would be impractical to run = a routing protocol between all of them. So, only a few nodes on the link have full topology information and these end systems need to discover routes via a service like Redirect. > Replace talk of WAN link / LAN link. This usage of PD differs from 3633, = in that it would typically be done within a single AS right? Yes, good point. I have not been in love with the WAN/LAN terminology, and I see that RFC3633 calls these upstream/downstream interfaces. I will go wi= th that terminology in the next version. Thanks - Fred > Cheers, > Ole >=20 > > On 5 Sep 2017, at 23:27, Templin, Fred L wr= ote: > > > > Hi, here is a draft that is very closely related to RFC7934 and 'unique= -ipv6-prefix-per-host'. > > It described the options available for a node that receives a unique pr= efix delegation from > > the network in terms of routing and multi-addressing considerations. It= is of direct interest > > to this community. > > > > I have given my time and energies to contribute to the aforementioned v= 6ops docs and > > would appreciate input from the working group on my document. Please se= e below for > > abstract and URLs. > > > > Thanks - Fred > > > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > > Sent: Tuesday, September 05, 2017 2:16 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-templin-v6ops-pdhost-06.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > > > > > Title : IPv6 Prefix Delegation for Hosts > > Author : Fred L. Templin > > Filename : draft-templin-v6ops-pdhost-06.txt > > Pages : 10 > > Date : 2017-09-05 > > > > Abstract: > > IPv6 prefixes are typically delegated to requesting routers which > > then use them to number their downstream-attached links and networks. > > This document considers both this traditional case, and the case when > > the "requesting router" is actually a simple host which receives a > > delegated prefix that it can use for its own internal multi- > > addressing purposes. This latter method can be employed in a wide > > variety of use cases to allow ample address availability without > > impacting link performance. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-templin-v6ops-pdhost-06 > > https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-06 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-06 > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Sep 6 07:57:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E71D132A65 for ; Wed, 6 Sep 2017 07:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGa7koIRzk0m for ; Wed, 6 Sep 2017 07:57:17 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99FF0132494 for ; Wed, 6 Sep 2017 07:57:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v86EvGYY019783; Wed, 6 Sep 2017 07:57:17 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v86EvFvU019675 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 6 Sep 2017 07:57:15 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Sep 2017 07:57:14 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 6 Sep 2017 07:57:14 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] DHCPv6 PD client on cellular on Android Thread-Index: AQHTJl1GQaHk8JRqwk2mcUUbqG/ToKKmdHgQgAHGcQD//7hLkA== Date: Wed, 6 Sep 2017 14:57:14 +0000 Message-ID: References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_ef41378969c5403385f9af231c6596c5XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 14:57:19 -0000 --_000_ef41378969c5403385f9af231c6596c5XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29n bGUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDYsIDIwMTcgNToxMSBBTQ0KVG86 IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCkNjOiBBbGV4YW5k cmUgUGV0cmVzY3UgPGFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+OyB2Nm9wc0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFt2Nm9wc10gREhDUHY2IFBEIGNsaWVudCBvbiBjZWxsdWxhciBvbiBB bmRyb2lkDQoNCk9uIFdlZCwgU2VwIDYsIDIwMTcgYXQgMTowNiBBTSwgVGVtcGxpbiwgRnJlZCBM IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPj4gd3JvdGU6DQpZb3UgZG9uJ3QgbmVlZCB0byByb290IHRoZSBkZXZpY2UgdG8gcnVuIERI Q1B2NiBQRCBvdmVyIGEgVlBOOg0KDQpodHRwczovL2RldmVsb3Blci5hbmRyb2lkLmNvbS9yZWZl cmVuY2UvYW5kcm9pZC9uZXQvVnBuU2VydmljZS5odG1sDQoNCkFnYWluLCB3ZSBoYXZlIERIQ1B2 NiBQRCB3b3JraW5nIGZpbmUgb3ZlciBhIFZQTi4NCg0KWW91IGNhbid0IGJpbmQgdG8gcG9ydCA1 NDYgd2l0aG91dCByb290aW5nIHRoZSBkZXZpY2UuIFlvdSBjYW4gY2VydGFpbmx5IGVuY2Fwc3Vs YXRlIERIQ1B2NiBwYWNrZXRzIHdpdGhpbiBhbm90aGVyIHByb3RvY29sIHRoYXQgeW91IGRvIGhh dmUgcGVybWlzc2lvbiB0byB1c2UgKGUuZy4sIFVEUCBvciBUQ1Agb24gYSBoaWdoIHBvcnQpLCBi dXQgeW91IGRvbid0IG5lZWQgVnBuU2VydmljZSB0byBkbyB0aGF0Lg0KDQoNCsOYICAgIFllcywg SSB1bmRlcnN0YW5kIHRoZSBwb2ludCBhYm91dCBiZWluZyBhYmxlIHRvIHJ1biBESENQdjYgb3Zl ciBhIGRpZmZlcmVudCBwb3J0IG51bWJlcg0KDQrDmCAgICBUaGUgcHJvYmxlbSBpcyB0aGF0IG9u Y2UgdGhlIERIQ1B2NiBjbGllbnQgZ2V0cyBiYWNrIGFkZHJlc3NpbmcgaW5mb3JtYXRpb24sIGl0 IGNhbm5vdA0KDQrDmCAgICBhc3NpZ24gYWRkcmVzc2VzIHRvIGludGVyZmFjZXMgb24gdGhlIEFu ZHJvaWQgcGxhdGZvcm0gd2l0aG91dCBoYXZpbmcgdGhlIGRldmljZQ0KDQrDmCAgICByb290ZWQu IFZwblNlcnZpY2Ugc2tpcnRzIGFyb3VuZCB0aGlzIGlzc3VlIGJ5IGFza2luZyB0aGUgdXNlciDi gJxpcyBpdCBPSyBpZiB0aGlzIGFwcA0KDQrDmCAgICBtb2RpZmllcyB0aGUgbmV0d29yayBzZXR0 aW5ncz/igJ0gYW5kIGlmIHRoZSB1c2VyIGFuc3dlcnMgeWVzIHRoZW4gdGhlIHNlcnZpY2UgYWxs b3dzDQoNCsOYICAgIHRoZSBhcHAgdG8gYXNzaWduIGFkZHJlc3NlcyBvbiB0aGUgVlBOIGludGVy ZmFjZSB3aXRob3V0IGhhdmluZyB0byByb290IHRoZSBkZXZpY2UuDQoNCsOYDQpUaGFua3MgLSBG cmVkDQo= --_000_ef41378969c5403385f9af231c6596c5XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0MTAyNzQ3MTM7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTMyMzM5MDYyIC00NjQ3MjM2 MTggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1h dDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv g5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIExvcmVuem8sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTG9yZW56byBD b2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgU2VwdGVtYmVyIDA2LCAyMDE3IDU6MTEgQU08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBs aW4sIEZyZWQgTCAmbHQ7RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IEFsZXhhbmRyZSBQZXRyZXNjdSAmbHQ7YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbSZn dDs7IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIERIQ1B2 NiBQRCBjbGllbnQgb24gY2VsbHVsYXIgb24gQW5kcm9pZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgU2Vw IDYsIDIwMTcgYXQgMTowNiBBTSwgVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86 RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgZG9uJ3QgbmVlZCB0byByb290IHRoZSBkZXZpY2UgdG8g cnVuIERIQ1B2NiBQRCBvdmVyIGEgVlBOOjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGV2 ZWxvcGVyLmFuZHJvaWQuY29tL3JlZmVyZW5jZS9hbmRyb2lkL25ldC9WcG5TZXJ2aWNlLmh0bWwi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RldmVsb3Blci5hbmRyb2lkLmNvbS9yZWZlcmVuY2Uv YW5kcm9pZC9uZXQvVnBuU2VydmljZS5odG1sPC9hPjxicj4NCjxicj4NCkFnYWluLCB3ZSBoYXZl IERIQ1B2NiBQRCB3b3JraW5nIGZpbmUgb3ZlciBhIFZQTi48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBjYW4ndCBiaW5kIHRv IHBvcnQgNTQ2IHdpdGhvdXQgcm9vdGluZyB0aGUgZGV2aWNlLiBZb3UgY2FuIGNlcnRhaW5seSBl bmNhcHN1bGF0ZSBESENQdjYgcGFja2V0cyB3aXRoaW4gYW5vdGhlciBwcm90b2NvbCB0aGF0IHlv dSBkbyBoYXZlIHBlcm1pc3Npb24gdG8gdXNlIChlLmcuLCBVRFAgb3IgVENQIG9uIGEgaGlnaCBw b3J0KSwgYnV0IHlvdSBkb24ndCBuZWVkIFZwblNlcnZpY2UgdG8gZG8gdGhhdC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WWVzLCBJIHVuZGVyc3RhbmQg dGhlIHBvaW50IGFib3V0IGJlaW5nIGFibGUgdG8gcnVuIERIQ1B2NiBvdmVyIGEgZGlmZmVyZW50 IHBvcnQgbnVtYmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBwcm9ibGVtIGlz IHRoYXQgb25jZSB0aGUgREhDUHY2IGNsaWVudCBnZXRzIGJhY2sgYWRkcmVzc2luZyBpbmZvcm1h dGlvbiwgaXQgY2Fubm90PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFzc2lnbiBhZGRy ZXNzZXMgdG8gaW50ZXJmYWNlcyBvbiB0aGUgQW5kcm9pZCBwbGF0Zm9ybSB3aXRob3V0IGhhdmlu ZyB0aGUgZGV2aWNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnJvb3RlZC4gVnBuU2Vy dmljZSBza2lydHMgYXJvdW5kIHRoaXMgaXNzdWUgYnkgYXNraW5nIHRoZSB1c2VyIOKAnGlzIGl0 IE9LIGlmIHRoaXMgYXBwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm1vZGlmaWVzIHRo ZSBuZXR3b3JrIHNldHRpbmdzP+KAnSBhbmQgaWYgdGhlIHVzZXIgYW5zd2VycyB5ZXMgdGhlbiB0 aGUgc2VydmljZSBhbGxvd3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhlIGFwcCB0 byBhc3NpZ24gYWRkcmVzc2VzIG9uIHRoZSBWUE4gaW50ZXJmYWNlIHdpdGhvdXQgaGF2aW5nIHRv IHJvb3QgdGhlIGRldmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_ef41378969c5403385f9af231c6596c5XCH150608nwnosboeingcom_-- From nobody Wed Sep 6 09:11:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1E3132992 for ; Wed, 6 Sep 2017 09:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzu5Wx3jyMKz for ; Wed, 6 Sep 2017 09:11:18 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E9C132031 for ; Wed, 6 Sep 2017 09:11:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v86GBCEU172155; Wed, 6 Sep 2017 18:11:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 33ED7207D51; Wed, 6 Sep 2017 18:11:12 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1D303204E1F; Wed, 6 Sep 2017 18:11:12 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v86GBBqA032059; Wed, 6 Sep 2017 18:11:12 +0200 To: "Templin, Fred L" , "v6ops@ietf.org" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: Date: Wed, 6 Sep 2017 18:11:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 16:11:20 -0000 Fred, Le 06/09/2017 à 16:35, Templin, Fred L a écrit : [...] > The problem is that the goal of DHCPv6 is to first obtain > addressing information and second to assign addresses to interfaces. Let's clarify this. We dont want DHCP to assign addresses on interfaces. We want it to obtain a prefix from the network (DHCPv6 Prefix Delegation). Right? > But, Android does not allow apps to assign addresses to regular > interfaces. If so, it seems like a problem of Android. It's hard to accept buying an expensive smartphone with its data plan yet be forbidden to set an address on it on the command line. I should be allowed to freely set not one, but as many addresses that I want. Alex From nobody Wed Sep 6 09:21:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F1213294B for ; Wed, 6 Sep 2017 09:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lS_rX2OZjXNW for ; Wed, 6 Sep 2017 09:21:23 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8A7132992 for ; Wed, 6 Sep 2017 09:21:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v86GLJ47009027; Wed, 6 Sep 2017 18:21:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 20D64207E4E; Wed, 6 Sep 2017 18:21:19 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 12E27207E46; Wed, 6 Sep 2017 18:21:19 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v86GLIPu004709; Wed, 6 Sep 2017 18:21:18 +0200 To: "Templin, Fred L" , "v6ops@ietf.org" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <152f893f24224371aa94ce1bbd54935b@XCH15-06-08.nw.nos.boeing.com> <2df79e19030f4b30a1b97e7d9d7fcba1@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: Date: Wed, 6 Sep 2017 18:21:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2df79e19030f4b30a1b97e7d9d7fcba1@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 16:21:31 -0000 Fred, Le 06/09/2017 à 16:40, Templin, Fred L a écrit : [...] >> Yes, something else too: handover from getting underground parking >> to daylight where coverage is present. That means losing >> connection and obtaining a new prefix. > > With VPN, you get to keep the same prefix even though the underlying > interface address changes. Yes, you keep the same prefix despite changes in IP address of underlying interface; for that to work, among other things, one needs a VPN server in the infrastructure to maintain that prefix. A VPN server may be costly to maintain, in some cases. It would be advantageous, in some cases, to not need a VPN server. In these cases we want the DHCPv6 Prefix Delegation to work straight on a cellular interface. In these cases, instead of relying on a VPN server to maintain that prefix, we rely on the cellular network operator to maintain it. The prefix may change upon handover - yes, but for many applications that's not ultra-important (they dont break). We think that the ability to rely most of the time on connectivity for cellular network (instead of additional VPN server) is worth sacrificing the few times when the apps care about session continuity. It's on this direction that we propose the use of DHCPv6 Prefix Delegation on cellular links. We propose that as Prefix Delegation (not IA_NA address). Alex >>> In any event the handover is accommodated by a small exchange of >>> control messages, but the VPN service itself continues >>> uninterrupted. Hence, it is a Mobile VPN. >> >> Well it is an interesting VPN software. It seems it is a VPN >> software that resists when the IP address changes on the mobile. > > It is a VPN software with an IPv6 prefix that persists (not > "resistis" :^} ) when the IP address of the mobile changes. > >> [...] >> >>>> I wonder whether it can be possible to set the VPN up after >>>> the DHCPv6-PD exchange happened between the operator and the >>>> smartphone. >>> >>> The system I am describing first obtains an address from the >>> operator and next sets up the VPN using the operator's service as >>> a link layer. >> >> I see. It is like an overlay network, and it is good many times. > > Overlay network yes. Good many times, also yes. > > Thanks - Fred fred.l.templin@boeing.com > >> Alex >> >>> >>> Thanks - Fred >>> >>>> Alex >>>> >>>>> >>>>> Thanks - Fred >>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> Thanks - Fred >>>>>>> >>>>>>>> - to make an app available to everyone on Android one >>>>>>>> must pay some money to become a member of a store. >>>>>>>> DHCP should not be part of that, as SLAAC isnt; just >>>>>>>> like SLAAC, DHCP should be builtin for free. - the >>>>>>>> DHCPv6 server software "ISC" breaks if the port numbers >>>>>>>> are non-standard (not 546 nor 547) or unicast instead >>>>>>>> of multicast. (e.g. "Discarding Solicit from [snip]; >>>>>>>> packet sent unicast") This was a real pain, because we >>>>>>>> had to modify the source code to allow it; other >>>>>>>> software like VoIP has SIP ports this configurable >>>>>>>> easily with a GUI. - Cisco parametering CLI of DHCPv6 >>>>>>>> service may have some problems in transforming a >>>>>>>> non-standard UDP port 546 of Solicit to a strange >>>>>>>> 26483. That was a real pain to one. - various DHCPv6 >>>>>>>> client software break, or do not even start, with any >>>>>>>> other src and dst UDP ports than the standard (546, >>>>>>>> 547) and/or non-standard unicast instead of standard >>>>>>>> multicast. >>>>>>>> >>>>>>>> Other reasons proved not to be causes of absence of >>>>>>>> DHCPv6 PD on cellular links; they were just >>>>>>>> speculations: - cellular operators dont provide DHCPv6 >>>>>>>> PD service (there are some who do under some >>>>>>>> operational conditions) - cellular operators have a >>>>>>>> hard time making an IPv6 addressing architecture that >>>>>>>> delegate prefixes instead of addresses (there are some >>>>>>>> who do make such architecture) - cellular operators >>>>>>>> only do '64' (it's false, some could do less, like 56 >>>>>>>> or even 48) - DHCPv6 software is not available on the >>>>>>>> client (there are some, like on Android, and more, see >>>>>>>> quoted mails below) - the computer that runs the DHCPv6 >>>>>>>> client is the same as the one that puts the Solicit on >>>>>>>> the wire: this is not true, because even in the >>>>>>>> smallest UE in the market there is still distinction >>>>>>>> app-vs-modem processors. Often the modem part is >>>>>>>> confidential, only the binary is available to the >>>>>>>> public, and there are two IPs on it: Internet Protocol >>>>>>>> _and_ Intellectual Property. >>>>>>>> >>>>>>>> Alex, with thanks to [Hachata], admin(s), managers, >>>>>>>> and technicals at offices and organisations. >>>>>>>> >>>>>>>> >>>>>>>> Le 18/08/2017 à 18:07, Alexandre Petrescu a écrit : >>>>>>>>> I have been pointed by a helpful person that an >>>>>>>>> Android app for DHCPv6 exists there: >>>>>>>>> >>>>>>>>> https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client&hl=fr >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >> >>>>>>>>> It is based on the WIDE DHCPv6 client. >>>>>>>>> >>>>>>>>> Further browsing leads to a discussion of DHCPv6 on >>>>>>>>> Android topic: >>>>>>>>> https://issuetracker.google.com/issues/36949085 >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> Le 17/07/2017 à 18:26, Alexandre Petrescu a écrit : >>>>>>>>>> Well, this is to note that we too (Fred mentioned >>>>>>>>>> it too earlier) made the ISC DHCPv6 dhclient work >>>>>>>>>> on Android, including DHCPv6 Solicit that requests >>>>>>>>>> Prefix Delegation. >>>>>>>>>> >>>>>>>>>> (but we still dont have a response to DHCP Solicit >>>>>>>>>> on cellular link). >>>>>>>>>> >>>>>>>>>> Alex >>>>>>>>>> >>>>>>>>>> Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit >>>>>>>>>> : >>>>>>>>>>> Mark, noted, will try. >>>>>>>>>>> >>>>>>>>>>> Just a note... >>>>>>>>>>> >>>>>>>>>>> Le 06/07/2017 à 03:16, Mark Andrews a écrit : >>>>>>>>>>>> >>>>>>>>>>>> In message >>>>>>>>>>>> <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, >>>>>>>>>>>> >>>>>>>>>>>> Alexandre Petrescu writes: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> We discussed extensively about the potential >>>>>>>>>>>>> use of DHCPv6 Prefix Delegation on cellular >>>>>>>>>>>>> links. >>>>>>>>>>>>> >>>>>>>>>>>>> The chicken issue is the lack of DHCPv6 PD >>>>>>>>>>>>> software on typical User Equipment. For >>>>>>>>>>>>> example, there is no DHCPv6-PD app on >>>>>>>>>>>>> Android. The egg issue is the lack of >>>>>>>>>>>>> operator support of DHCPv6-PD towards the >>>>>>>>>>>>> User Terminal. For example, there is no >>>>>>>>>>>>> cellular operator answering to DHCPv6-PD >>>>>>>>>>>>> requests issued by the User Terminal. >>>>>>>>>>>>> >>>>>>>>>>>>> To address the chicken issue, we started with >>>>>>>>>>>>> an ISC DHCP open software client, which does >>>>>>>>>>>>> implement Prefix Delegation. It can be >>>>>>>>>>>>> (cross)compiled on various platforms; then >>>>>>>>>>>>> type "./dhclient -6 -P"; this sends an DHCPv6 >>>>>>>>>>>>> Solicit Identity Associtaion for Prefix >>>>>>>>>>>>> Delegation message on the interface. >>>>>>>>>>>>> >>>>>>>>>>>>> However, whereas this software runs ok on >>>>>>>>>>>>> interfaces such as Ethernet, USBnet and WiFi >>>>>>>>>>>>> interfaces, it breaks if run on the cellular >>>>>>>>>>>>> interface of some IoT cellular platform. >>>>>>>>>>>>> The error can be corrected by the >>>>>>>>>>>>> quick-and-dirty solution below. >>>>>>>>>>>> >>>>>>>>>>>> The hack would be better as >>>>>>>>>>>> >>>>>>>>>>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = >>>>>>>>>>>> 7; hw->hbuf[0] = HTYPE_ETHER; >>>>>>>>>>>> memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>>>>>>>>>> #endif default: log_fatal("Unsupported device >>>>>>>>>>>> type %ld for \"%s\"", (long int)sa->sa_family, >>>>>>>>>>>> name); break; >>>>>>>>>>>> >>>>>>>>>>>> with ARPHRD_XXXX being replaced by the correct >>>>>>>>>>>> macro for 503 from . Something >>>>>>>>>>>> like that is at least portable. >>>>>>>>>>> >>>>>>>>>>> But it means when I go to other platform will >>>>>>>>>>> have to modify again the ISC client source code? >>>>>>>>>>> >>>>>>>>>>> In cellular terminals there are so many non-IEEE >>>>>>>>>>> different kinds of links. >>>>>>>>>>> >>>>>>>>>>> Other clients work out of the box on this - I >>>>>>>>>>> agree with you, strange - "rmnet0" interface. >>>>>>>>>>> >>>>>>>>>>> Alex >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> As for the rest of it I have no idea about the >>>>>>>>>>>> presented hardware address of this type so I >>>>>>>>>>>> don't know it the rest of it make sense. >>>>>>>>>>>> >>>>>>>>>>>>> Alex >>>>>>>>>>>>> >>>>>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >> >>>>>>>>>>>>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0." >>>>>>>>>>>>> dhcp-4.3.5 ./common/lpf.c line number: 551 >>>>>>>>>>>>> >>>>>>>>>>>>> //default: // log_fatal("Unsupported >>>>>>>>>>>>> device type %ld for \"%s\"", // >>>>>>>>>>>>> (long int)sa->sa_family, name); default: >>>>>>>>>>>>> hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; >>>>>>>>>>>>> memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>>>>>>>>>>> >>>>>>>>>>>>> (two programmers worked this out). >>>>>>>>>>>>> >>>>>>>>>>>>> Alex >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> v6ops mailing list v6ops@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> v6ops mailing list v6ops@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> v6ops mailing list v6ops@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> v6ops mailing list v6ops@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>>>>> >>>>>>>> _______________________________________________ v6ops >>>>>>>> mailing list v6ops@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>> >>> > From nobody Wed Sep 6 09:40:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5BE1329AB for ; Wed, 6 Sep 2017 09:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHKXdMPSlzXV for ; Wed, 6 Sep 2017 09:40:21 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DA2132351 for ; Wed, 6 Sep 2017 09:40:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v86GeG4a012760; Wed, 6 Sep 2017 09:40:16 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v86GeAYH012702 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 6 Sep 2017 09:40:10 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Sep 2017 09:40:09 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 6 Sep 2017 09:40:09 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] DHCPv6 PD client on cellular on Android Thread-Index: AQHTJl1GQaHk8JRqwk2mcUUbqG/ToKKmdHgQgAFf1ACAABZHAIAAk42A//+Q6tA= Date: Wed, 6 Sep 2017 16:40:08 +0000 Message-ID: References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 16:40:28 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cmUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwNiwgMjAxNyA5OjExIEFNDQo+IFRvOiBUZW1wbGluLCBG cmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+OyB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW3Y2b3BzXSBESENQdjYgUEQgY2xpZW50IG9uIGNlbGx1bGFyIG9uIEFuZHJvaWQN Cj4gDQo+IEZyZWQsDQo+IA0KPiBMZSAwNi8wOS8yMDE3IMOgIDE2OjM1LCBUZW1wbGluLCBGcmVk IEwgYSDDqWNyaXTCoDoNCj4gWy4uLl0NCj4gPiBUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBnb2Fs IG9mIERIQ1B2NiBpcyB0byBmaXJzdCBvYnRhaW4NCj4gPiBhZGRyZXNzaW5nIGluZm9ybWF0aW9u IGFuZCBzZWNvbmQgdG8gYXNzaWduIGFkZHJlc3NlcyB0byBpbnRlcmZhY2VzLg0KPiANCj4gTGV0 J3MgY2xhcmlmeSB0aGlzLg0KPiANCj4gV2UgZG9udCB3YW50IERIQ1AgdG8gYXNzaWduIGFkZHJl c3NlcyBvbiBpbnRlcmZhY2VzLiAgV2Ugd2FudCBpdCB0bw0KPiBvYnRhaW4gYSBwcmVmaXggZnJv bSB0aGUgbmV0d29yayAoREhDUHY2IFByZWZpeCBEZWxlZ2F0aW9uKS4gIFJpZ2h0Pw0KDQpPYnRh aW4gYSBwcmVmaXgsIHllcy4gQnV0LCBwcmVzdW1hYmx5LCB0aGUgQW5kcm9pZCBub2RlIHdpbGwg d2FudCB0byB1c2UNCnRoZSBwcmVmaXggaW4gc29tZSBmYXNoaW9uLiBJdCBjYW4gZWl0aGVyIGFj dCBhcyBhIHJvdXRlciAod2hpY2ggaXMgcHJvaGliaXRlZA0KYnkgQW5kcm9pZCB3aXRob3V0IHJv b3RpbmcgdGhlIGRldmljZSkgb3IgaXQgY2FuIGFjdCBhcyBhIGhvc3QgYW5kIHRyeSB0bw0KYXNz aWduIGFkZHJlc3NlcyBmcm9tIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IHRvIGFuIGludGVyZmFjZSAo d2hpY2ggaXMgYWxzbw0KcHJvaGliaXRlZCBieSBBbmRyb2lkIHcvbyByb290aW5nIHRoZSBkZXZp Y2UpLiANCg0KPiA+IEJ1dCwgQW5kcm9pZCBkb2VzIG5vdCBhbGxvdyBhcHBzIHRvIGFzc2lnbiBh ZGRyZXNzZXMgdG8gcmVndWxhcg0KPiA+IGludGVyZmFjZXMuDQo+IA0KPiBJZiBzbywgaXQgc2Vl bXMgbGlrZSBhIHByb2JsZW0gb2YgQW5kcm9pZC4NCg0KQUZBSUNULCBBbmRyb2lkIHRyaWVzIHRv IHByb3RlY3QgdXNlcnMgZnJvbSBzaG9vdGluZyB0aGVtc2VsdmVzIGluDQp0aGUgZm9vdC4gUm9v dGluZyB0aGUgZGV2aWNlIGlzIHRoZSB1c2VyJ3Mgd2F5IG9mIHNheWluZzogIkkga25vdyB3aGF0 DQpJIGFtIGRvaW5nIGFuZCBhY2NlcHQgdGhlIGNvbnNlcXVlbmNlcyBvZiBteSBhY3Rpb25zIiBi dXQgaXQgdm9pZHMNCmFueSB3YXJyYW50aWVzLg0KDQo+IEl0J3MgaGFyZCB0byBhY2NlcHQgYnV5 aW5nIGFuIGV4cGVuc2l2ZSBzbWFydHBob25lIHdpdGggaXRzIGRhdGEgcGxhbg0KPiB5ZXQgYmUg Zm9yYmlkZGVuIHRvIHNldCBhbiBhZGRyZXNzIG9uIGl0IG9uIHRoZSBjb21tYW5kIGxpbmUuICBJ IHNob3VsZA0KPiBiZSBhbGxvd2VkIHRvIGZyZWVseSBzZXQgbm90IG9uZSwgYnV0IGFzIG1hbnkg YWRkcmVzc2VzIHRoYXQgSSB3YW50Lg0KDQpZb3UgY2FuIHRyeSBicmluZ2luZyB1cCBhIHRlcm1p bmFsIHdpbmRvdyBhcHAgb24gdGhlIEFuZHJvaWQgYW5kDQp0eXBlOiAiaXAgLTYgYWRkciBhZGQg MjAwMTpkYjg6OjEgZGV2IFgiIGJ1dCBpdCB3aWxsIG5vdCBsZXQgeW91IGRvIGl0Lg0KDQpUaGFu a3MgLSBGcmVkDQoNCj4gQWxleA0KDQo= From nobody Wed Sep 6 09:50:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2063A132199 for ; Wed, 6 Sep 2017 09:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33sUtRMB3kqD for ; Wed, 6 Sep 2017 09:50:20 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8879613219C for ; Wed, 6 Sep 2017 09:50:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v86GoJAZ052999; Wed, 6 Sep 2017 09:50:19 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v86GoG8R052955 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 6 Sep 2017 09:50:16 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Sep 2017 09:50:15 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 6 Sep 2017 09:50:15 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] DHCPv6 PD client on cellular on Android Thread-Index: AQHTJl1GQaHk8JRqwk2mcUUbqG/ToKKmdHgQgACwUgD//46dcIAAeBiA//+LG4CAAR8PgIAAGE5QgACS/QD//4/2AA== Date: Wed, 6 Sep 2017 16:50:14 +0000 Message-ID: References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <152f893f24224371aa94ce1bbd54935b@XCH15-06-08.nw.nos.boeing.com> <2df79e19030f4b30a1b97e7d9d7fcba1@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 16:50:22 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cmUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwNiwgMjAxNyA5OjIxIEFNDQo+IFRvOiBUZW1wbGluLCBG cmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+OyB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW3Y2b3BzXSBESENQdjYgUEQgY2xpZW50IG9uIGNlbGx1bGFyIG9uIEFuZHJvaWQN Cj4gDQo+IEZyZWQsDQo+IA0KPiBMZSAwNi8wOS8yMDE3IMOgIDE2OjQwLCBUZW1wbGluLCBGcmVk IEwgYSDDqWNyaXQgOg0KPiBbLi4uXQ0KPiANCj4gPj4gWWVzLCBzb21ldGhpbmcgZWxzZSB0b286 IGhhbmRvdmVyIGZyb20gZ2V0dGluZyB1bmRlcmdyb3VuZCBwYXJraW5nDQo+ID4+IHRvIGRheWxp Z2h0IHdoZXJlIGNvdmVyYWdlIGlzIHByZXNlbnQuICBUaGF0IG1lYW5zIGxvc2luZw0KPiA+PiBj b25uZWN0aW9uIGFuZCBvYnRhaW5pbmcgYSBuZXcgcHJlZml4Lg0KPiA+DQo+ID4gV2l0aCBWUE4s IHlvdSBnZXQgdG8ga2VlcCB0aGUgc2FtZSBwcmVmaXggZXZlbiB0aG91Z2ggdGhlIHVuZGVybHlp bmcNCj4gPiBpbnRlcmZhY2UgYWRkcmVzcyBjaGFuZ2VzLg0KPiANCj4gWWVzLCB5b3Uga2VlcCB0 aGUgc2FtZSBwcmVmaXggZGVzcGl0ZSBjaGFuZ2VzIGluIElQIGFkZHJlc3Mgb2YNCj4gdW5kZXJs eWluZyBpbnRlcmZhY2U7IGZvciB0aGF0IHRvIHdvcmssIGFtb25nIG90aGVyIHRoaW5ncywgb25l IG5lZWRzIGENCj4gVlBOIHNlcnZlciBpbiB0aGUgaW5mcmFzdHJ1Y3R1cmUgdG8gbWFpbnRhaW4g dGhhdCBwcmVmaXguDQo+DQo+IEEgVlBOIHNlcnZlciBtYXkgYmUgY29zdGx5IHRvIG1haW50YWlu LCBpbiBzb21lIGNhc2VzLg0KDQpZZXMsIGEgVlBOIHNlcnZlciBpcyBuZWNlc3NhcnkgYnV0IG5v dCBuZWNlc3NhcmlseSBjb3N0bHkgdG8gbWFpbnRhaW4uIEZvcg0KZXhhbXBsZSwgT3BlblZQTiBz ZXJ2ZXIgcnVucyB3ZWxsIGV2ZW4gb24gbGlnaHR3ZWlnaHQgdmlydHVhbCBtYWNoaW5lcy4NCg0K PiBJdCB3b3VsZCBiZSBhZHZhbnRhZ2VvdXMsIGluIHNvbWUgY2FzZXMsIHRvIG5vdCBuZWVkIGEg VlBOIHNlcnZlci4gSW4NCj4gdGhlc2UgY2FzZXMgd2Ugd2FudCB0aGUgREhDUHY2IFByZWZpeCBE ZWxlZ2F0aW9uIHRvIHdvcmsgc3RyYWlnaHQgb24gYQ0KPiBjZWxsdWxhciBpbnRlcmZhY2UuDQoN CkJ1dCwgaWYgdGhlIG5vZGUgZ2V0cyBhIFBEIGZyb20gYSBmaXJzdCBuZXR3b3JrIGF0dGFjaG1l bnQgcG9pbnQgYW5kIHRoZW4NCm1vdmVzIHRvIGEgc2Vjb25kIG5ldHdvcmsgYXR0YWNobWVudCBw b2ludCwgaXQgd2lsbCBuZWVkIHRvIHNjcmFwIHRoZSBmaXJzdA0KUEQgYW5kIGdldCBhIG5ldyBv bmUuIFRoZSByZXN1bHQgaXMgYSBtZXNzeSByZW51bWJlcmluZyBldmVudCBhbmQgbG9zcw0Kb2Yg Y29udGludWl0eSBmb3IgYW55IHNlc3Npb25zIGluIHByb2dyZXNzLg0KDQo+IEluIHRoZXNlIGNh c2VzLCBpbnN0ZWFkIG9mIHJlbHlpbmcgb24gYSBWUE4gc2VydmVyIHRvIG1haW50YWluIHRoYXQN Cj4gcHJlZml4LCB3ZSByZWx5IG9uIHRoZSBjZWxsdWxhciBuZXR3b3JrIG9wZXJhdG9yIHRvIG1h aW50YWluIGl0LiAgVGhlDQo+IHByZWZpeCBtYXkgY2hhbmdlIHVwb24gaGFuZG92ZXIgLSB5ZXMs IGJ1dCBmb3IgbWFueQ0KPiBhcHBsaWNhdGlvbnMgdGhhdCdzIG5vdCB1bHRyYS1pbXBvcnRhbnQg KHRoZXkgZG9udCBicmVhaykuDQoNClJlbnVtYmVyaW5nIG9uLXRoZS1mbHkgaXMgaGFyZCwgYW5k IGFwcGxpY2F0aW9ucyB0aGF0IHJlbHkgb24gYSBjb25zdGFudA0KSVAgYWRkcmVzcyB3aWxsIGJy ZWFrLg0KIA0KPiBXZSB0aGluayB0aGF0IHRoZSBhYmlsaXR5IHRvIHJlbHkgbW9zdCBvZiB0aGUg dGltZSBvbiBjb25uZWN0aXZpdHkgZm9yDQo+IGNlbGx1bGFyIG5ldHdvcmsgIChpbnN0ZWFkIG9m IGFkZGl0aW9uYWwgVlBOIHNlcnZlcikgaXMgd29ydGgNCj4gc2FjcmlmaWNpbmcgdGhlIGZldyB0 aW1lcyB3aGVuIHRoZSBhcHBzIGNhcmUgYWJvdXQgc2Vzc2lvbiBjb250aW51aXR5Lg0KPiANCj4g SXQncyBvbiB0aGlzIGRpcmVjdGlvbiB0aGF0IHdlIHByb3Bvc2UgdGhlIHVzZSBvZiBESENQdjYg UHJlZml4DQo+IERlbGVnYXRpb24gb24gY2VsbHVsYXIgbGlua3MuDQo+IA0KPiBXZSBwcm9wb3Nl IHRoYXQgYXMgUHJlZml4IERlbGVnYXRpb24gKG5vdCBJQV9OQSBhZGRyZXNzKS4NCg0KTWFpbnRh aW5pbmcgYSBjb25zdGFudCBhbmQgdW5jaGFuZ2luZyBhZGRyZXNzIGlzIGJlbmVmaWNpYWwgZm9y IG1haW50YWluaW5nDQphcHBsaWNhdGlvbiBzZXNzaW9ucywgZm9yIGF2b2lkaW5nIHJlbnVtYmVy aW5nIGV2ZW50cyBhbmQgKGZvciBtb2JpbGUNCmVudGVycHJpc2UgZGV2aWNlIHVzZXJzKSBmb3Ig bWFpbnRhaW5pbmcgYSByZWFjaGFibGUgc2V0IG9mIGFkZHJlc3NlcyB0aGF0DQpjYW4gYWx3YXlz IGJlIHVzZWQgdG8gbG9jYXRlIHRoZSBkZXZpY2UuDQoNClRoYW5rcyAtIEZyZWQNCg0KPiBBbGV4 DQo+IA0KPiA+Pj4gSW4gYW55IGV2ZW50IHRoZSBoYW5kb3ZlciBpcyBhY2NvbW1vZGF0ZWQgYnkg YSBzbWFsbCBleGNoYW5nZSBvZg0KPiA+Pj4gY29udHJvbCBtZXNzYWdlcywgYnV0IHRoZSBWUE4g c2VydmljZSBpdHNlbGYgY29udGludWVzDQo+ID4+PiB1bmludGVycnVwdGVkLiBIZW5jZSwgaXQg aXMgYSBNb2JpbGUgVlBOLg0KPiA+Pg0KPiA+PiBXZWxsIGl0IGlzIGFuIGludGVyZXN0aW5nIFZQ TiBzb2Z0d2FyZS4gIEl0IHNlZW1zIGl0IGlzIGEgVlBODQo+ID4+IHNvZnR3YXJlIHRoYXQgcmVz aXN0cyB3aGVuIHRoZSBJUCBhZGRyZXNzIGNoYW5nZXMgb24gdGhlIG1vYmlsZS4NCj4gPg0KPiA+ IEl0IGlzIGEgVlBOIHNvZnR3YXJlIHdpdGggYW4gSVB2NiBwcmVmaXggdGhhdCBwZXJzaXN0cyAo bm90DQo+ID4gInJlc2lzdGlzIiA6Xn0gKSB3aGVuIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBtb2Jp bGUgY2hhbmdlcy4NCj4gPg0KPiA+PiBbLi4uXQ0KPiA+Pg0KPiA+Pj4+IEkgd29uZGVyIHdoZXRo ZXIgaXQgY2FuIGJlIHBvc3NpYmxlIHRvIHNldCB0aGUgVlBOIHVwIGFmdGVyDQo+ID4+Pj4gdGhl IERIQ1B2Ni1QRCBleGNoYW5nZSBoYXBwZW5lZCBiZXR3ZWVuIHRoZSBvcGVyYXRvciBhbmQgdGhl DQo+ID4+Pj4gc21hcnRwaG9uZS4NCj4gPj4+DQo+ID4+PiBUaGUgc3lzdGVtIEkgYW0gZGVzY3Jp YmluZyBmaXJzdCBvYnRhaW5zIGFuIGFkZHJlc3MgZnJvbSB0aGUNCj4gPj4+IG9wZXJhdG9yIGFu ZCBuZXh0IHNldHMgdXAgdGhlIFZQTiB1c2luZyB0aGUgb3BlcmF0b3IncyBzZXJ2aWNlIGFzDQo+ ID4+PiBhIGxpbmsgbGF5ZXIuDQo+ID4+DQo+ID4+IEkgc2VlLiAgSXQgaXMgbGlrZSBhbiBvdmVy bGF5IG5ldHdvcmssIGFuZCBpdCBpcyBnb29kIG1hbnkgdGltZXMuDQo+ID4NCj4gPiBPdmVybGF5 IG5ldHdvcmsgeWVzLiBHb29kIG1hbnkgdGltZXMsIGFsc28geWVzLg0KPiA+DQo+ID4gVGhhbmtz IC0gRnJlZCBmcmVkLmwudGVtcGxpbkBib2VpbmcuY29tDQo+ID4NCj4gPj4gQWxleA0KPiA+Pg0K PiA+Pj4NCj4gPj4+IFRoYW5rcyAtIEZyZWQNCj4gPj4+DQo+ID4+Pj4gQWxleA0KPiA+Pj4+DQo+ ID4+Pj4+DQo+ID4+Pj4+IFRoYW5rcyAtIEZyZWQNCj4gPj4+Pj4NCj4gPj4+Pj4+IEFsZXgNCj4g Pj4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBUaGFua3MgLSBGcmVkDQo+ID4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4gLSB0byBtYWtlIGFuIGFwcCBhdmFpbGFibGUgdG8gZXZlcnlvbmUgb24gQW5kcm9p ZCBvbmUNCj4gPj4+Pj4+Pj4gbXVzdCBwYXkgc29tZSBtb25leSB0byBiZWNvbWUgYSBtZW1iZXIg b2YgYSBzdG9yZS4NCj4gPj4+Pj4+Pj4gREhDUCBzaG91bGQgbm90IGJlIHBhcnQgb2YgdGhhdCwg YXMgU0xBQUMgaXNudDsganVzdA0KPiA+Pj4+Pj4+PiBsaWtlIFNMQUFDLCBESENQIHNob3VsZCBi ZSBidWlsdGluIGZvciBmcmVlLiAtIHRoZQ0KPiA+Pj4+Pj4+PiBESENQdjYgc2VydmVyIHNvZnR3 YXJlICJJU0MiIGJyZWFrcyBpZiB0aGUgcG9ydCBudW1iZXJzDQo+ID4+Pj4+Pj4+IGFyZSBub24t c3RhbmRhcmQgKG5vdCA1NDYgbm9yIDU0Nykgb3IgdW5pY2FzdCBpbnN0ZWFkDQo+ID4+Pj4+Pj4+ IG9mIG11bHRpY2FzdC4gKGUuZy4gIkRpc2NhcmRpbmcgU29saWNpdCBmcm9tIFtzbmlwXTsNCj4g Pj4+Pj4+Pj4gcGFja2V0IHNlbnQgdW5pY2FzdCIpIFRoaXMgd2FzIGEgcmVhbCBwYWluLCBiZWNh dXNlIHdlDQo+ID4+Pj4+Pj4+IGhhZCB0byBtb2RpZnkgdGhlIHNvdXJjZSBjb2RlIHRvIGFsbG93 IGl0OyBvdGhlcg0KPiA+Pj4+Pj4+PiBzb2Z0d2FyZSBsaWtlIFZvSVAgaGFzIFNJUCBwb3J0cyB0 aGlzIGNvbmZpZ3VyYWJsZQ0KPiA+Pj4+Pj4+PiBlYXNpbHkgd2l0aCBhIEdVSS4gLSBDaXNjbyBw YXJhbWV0ZXJpbmcgQ0xJIG9mIERIQ1B2Ng0KPiA+Pj4+Pj4+PiBzZXJ2aWNlIG1heSBoYXZlIHNv bWUgcHJvYmxlbXMgaW4gdHJhbnNmb3JtaW5nIGENCj4gPj4+Pj4+Pj4gbm9uLXN0YW5kYXJkIFVE UCBwb3J0IDU0NiBvZiBTb2xpY2l0IHRvIGEgc3RyYW5nZQ0KPiA+Pj4+Pj4+PiAyNjQ4My4gVGhh dCB3YXMgYSByZWFsIHBhaW4gdG8gb25lLiAtIHZhcmlvdXMgREhDUHY2DQo+ID4+Pj4+Pj4+IGNs aWVudCBzb2Z0d2FyZSBicmVhaywgb3IgZG8gbm90IGV2ZW4gc3RhcnQsIHdpdGggYW55DQo+ID4+ Pj4+Pj4+IG90aGVyIHNyYyBhbmQgZHN0IFVEUCBwb3J0cyB0aGFuIHRoZSBzdGFuZGFyZCAoNTQ2 LA0KPiA+Pj4+Pj4+PiA1NDcpIGFuZC9vciBub24tc3RhbmRhcmQgdW5pY2FzdCBpbnN0ZWFkIG9m IHN0YW5kYXJkDQo+ID4+Pj4+Pj4+IG11bHRpY2FzdC4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4g T3RoZXIgcmVhc29ucyBwcm92ZWQgbm90IHRvIGJlIGNhdXNlcyBvZiBhYnNlbmNlIG9mDQo+ID4+ Pj4+Pj4+IERIQ1B2NiBQRCBvbiBjZWxsdWxhciBsaW5rczsgdGhleSB3ZXJlIGp1c3QNCj4gPj4+ Pj4+Pj4gc3BlY3VsYXRpb25zOiAtIGNlbGx1bGFyIG9wZXJhdG9ycyBkb250IHByb3ZpZGUgREhD UHY2DQo+ID4+Pj4+Pj4+IFBEIHNlcnZpY2UgKHRoZXJlIGFyZSBzb21lIHdobyBkbyB1bmRlciBz b21lDQo+ID4+Pj4+Pj4+IG9wZXJhdGlvbmFsIGNvbmRpdGlvbnMpIC0gY2VsbHVsYXIgb3BlcmF0 b3JzIGhhdmUgYQ0KPiA+Pj4+Pj4+PiBoYXJkIHRpbWUgbWFraW5nIGFuIElQdjYgYWRkcmVzc2lu ZyBhcmNoaXRlY3R1cmUgdGhhdA0KPiA+Pj4+Pj4+PiBkZWxlZ2F0ZSBwcmVmaXhlcyBpbnN0ZWFk IG9mIGFkZHJlc3NlcyAodGhlcmUgYXJlIHNvbWUNCj4gPj4+Pj4+Pj4gd2hvIGRvIG1ha2Ugc3Vj aCBhcmNoaXRlY3R1cmUpIC0gY2VsbHVsYXIgb3BlcmF0b3JzDQo+ID4+Pj4+Pj4+IG9ubHkgZG8g JzY0JyAoaXQncyBmYWxzZSwgc29tZSBjb3VsZCBkbyBsZXNzLCBsaWtlIDU2DQo+ID4+Pj4+Pj4+ IG9yIGV2ZW4gNDgpIC0gREhDUHY2IHNvZnR3YXJlIGlzIG5vdCBhdmFpbGFibGUgb24gdGhlDQo+ ID4+Pj4+Pj4+IGNsaWVudCAodGhlcmUgYXJlIHNvbWUsIGxpa2Ugb24gQW5kcm9pZCwgYW5kIG1v cmUsIHNlZQ0KPiA+Pj4+Pj4+PiBxdW90ZWQgbWFpbHMgYmVsb3cpIC0gdGhlIGNvbXB1dGVyIHRo YXQgcnVucyB0aGUgREhDUHY2DQo+ID4+Pj4+Pj4+IGNsaWVudCBpcyB0aGUgc2FtZSBhcyB0aGUg b25lIHRoYXQgcHV0cyB0aGUgU29saWNpdCBvbg0KPiA+Pj4+Pj4+PiB0aGUgd2lyZTogdGhpcyBp cyBub3QgdHJ1ZSwgYmVjYXVzZSBldmVuIGluIHRoZQ0KPiA+Pj4+Pj4+PiBzbWFsbGVzdCBVRSBp biB0aGUgbWFya2V0IHRoZXJlIGlzIHN0aWxsIGRpc3RpbmN0aW9uDQo+ID4+Pj4+Pj4+IGFwcC12 cy1tb2RlbSBwcm9jZXNzb3JzLiAgT2Z0ZW4gdGhlIG1vZGVtIHBhcnQgaXMNCj4gPj4+Pj4+Pj4g Y29uZmlkZW50aWFsLCBvbmx5IHRoZSBiaW5hcnkgaXMgYXZhaWxhYmxlIHRvIHRoZQ0KPiA+Pj4+ Pj4+PiBwdWJsaWMsIGFuZCB0aGVyZSBhcmUgdHdvIElQcyBvbiBpdDogSW50ZXJuZXQgUHJvdG9j b2wNCj4gPj4+Pj4+Pj4gX2FuZF8gSW50ZWxsZWN0dWFsIFByb3BlcnR5Lg0KPiA+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+PiBBbGV4LCB3aXRoIHRoYW5rcyB0byBbSGFjaGF0YV0sIGFkbWluKHMpLCBtYW5h Z2VycywNCj4gPj4+Pj4+Pj4gYW5kIHRlY2huaWNhbHMgYXQgb2ZmaWNlcyBhbmQgb3JnYW5pc2F0 aW9ucy4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gTGUgMTgvMDgvMjAxNyDD oCAxODowNywgQWxleGFuZHJlIFBldHJlc2N1IGEgw6ljcml0IDoNCj4gPj4+Pj4+Pj4+IEkgaGF2 ZSBiZWVuIHBvaW50ZWQgYnkgYSBoZWxwZnVsIHBlcnNvbiB0aGF0IGFuDQo+ID4+Pj4+Pj4+PiBB bmRyb2lkIGFwcCBmb3IgREhDUHY2IGV4aXN0cyB0aGVyZToNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+PiBodHRwczovL3BsYXkuZ29vZ2xlLmNvbS9zdG9yZS9hcHBzL2RldGFpbHM/aWQ9b3JnLmRh ZHVrZS5yZWFsbWFyLmRoY3B2NmNsaWVudCZobD1mcg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+DQo+ID4+Pj4+Pj4+Pg0KPiBJdCBpcyBiYXNlZCBv biB0aGUgV0lERSBESENQdjYgY2xpZW50Lg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEZ1cnRo ZXIgYnJvd3NpbmcgbGVhZHMgdG8gYSBkaXNjdXNzaW9uIG9mIERIQ1B2NiBvbg0KPiA+Pj4+Pj4+ Pj4gQW5kcm9pZCB0b3BpYzoNCj4gPj4+Pj4+Pj4+IGh0dHBzOi8vaXNzdWV0cmFja2VyLmdvb2ds ZS5jb20vaXNzdWVzLzM2OTQ5MDg1DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gQWxleA0KPiA+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IExlIDE3LzA3LzIwMTcgw6AgMTg6MjYsIEFsZXhhbmRyZSBQ ZXRyZXNjdSBhIMOpY3JpdCA6DQo+ID4+Pj4+Pj4+Pj4gV2VsbCwgdGhpcyBpcyB0byBub3RlIHRo YXQgd2UgdG9vIChGcmVkIG1lbnRpb25lZA0KPiA+Pj4+Pj4+Pj4+IGl0IHRvbyBlYXJsaWVyKSBt YWRlIHRoZSBJU0MgREhDUHY2IGRoY2xpZW50IHdvcmsNCj4gPj4+Pj4+Pj4+PiBvbiBBbmRyb2lk LCBpbmNsdWRpbmcgREhDUHY2IFNvbGljaXQgdGhhdCByZXF1ZXN0cw0KPiA+Pj4+Pj4+Pj4+IFBy ZWZpeCBEZWxlZ2F0aW9uLg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gKGJ1dCB3ZSBzdGls bCBkb250IGhhdmUgYSByZXNwb25zZSB0byBESENQIFNvbGljaXQNCj4gPj4+Pj4+Pj4+PiBvbiBj ZWxsdWxhciBsaW5rKS4NCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IEFsZXgNCj4gPj4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IExlIDA2LzA3LzIwMTcgw6AgMTg6MzIsIEFsZXhhbmRyZSBQZXRy ZXNjdSBhIMOpY3JpdA0KPiA+Pj4+Pj4+Pj4+IDoNCj4gPj4+Pj4+Pj4+Pj4gTWFyaywgbm90ZWQs IHdpbGwgdHJ5Lg0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBKdXN0IGEgbm90ZS4uLg0K PiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBMZSAwNi8wNy8yMDE3IMOgIDAzOjE2LCBNYXJr IEFuZHJld3MgYSDDqWNyaXQgOg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+IEluIG1l c3NhZ2UNCj4gPj4+Pj4+Pj4+Pj4+IDw3NTM3ZGVlZi04Zjg3LTUxODctMWU0NC01OTVhYzYzYTE2 Y2FAZ21haWwuY29tPiwNCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pg0KPiBBbGV4YW5k cmUgUGV0cmVzY3Ugd3JpdGVzOg0KPiA+Pj4+Pj4+Pj4+Pj4+IEhlbGxvLA0KPiA+Pj4+Pj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4gV2UgZGlzY3Vzc2VkIGV4dGVuc2l2ZWx5IGFib3V0IHRoZSBw b3RlbnRpYWwNCj4gPj4+Pj4+Pj4+Pj4+PiB1c2Ugb2YgREhDUHY2IFByZWZpeCBEZWxlZ2F0aW9u IG9uIGNlbGx1bGFyDQo+ID4+Pj4+Pj4+Pj4+Pj4gbGlua3MuDQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4+Pj4+PiBUaGUgY2hpY2tlbiBpc3N1ZSBpcyB0aGUgbGFjayBvZiBESENQdjYgUEQN Cj4gPj4+Pj4+Pj4+Pj4+PiBzb2Z0d2FyZSBvbiB0eXBpY2FsIFVzZXIgRXF1aXBtZW50LiAgRm9y DQo+ID4+Pj4+Pj4+Pj4+Pj4gZXhhbXBsZSwgdGhlcmUgaXMgbm8gREhDUHY2LVBEIGFwcCBvbg0K PiA+Pj4+Pj4+Pj4+Pj4+IEFuZHJvaWQuIFRoZSBlZ2cgaXNzdWUgaXMgdGhlIGxhY2sgb2YNCj4g Pj4+Pj4+Pj4+Pj4+PiBvcGVyYXRvciBzdXBwb3J0IG9mIERIQ1B2Ni1QRCB0b3dhcmRzIHRoZQ0K PiA+Pj4+Pj4+Pj4+Pj4+IFVzZXIgVGVybWluYWwuICBGb3IgZXhhbXBsZSwgdGhlcmUgaXMgbm8N Cj4gPj4+Pj4+Pj4+Pj4+PiBjZWxsdWxhciBvcGVyYXRvciBhbnN3ZXJpbmcgdG8gREhDUHY2LVBE DQo+ID4+Pj4+Pj4+Pj4+Pj4gcmVxdWVzdHMgaXNzdWVkIGJ5IHRoZSBVc2VyIFRlcm1pbmFsLg0K PiA+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4gVG8gYWRkcmVzcyB0aGUgY2hpY2tlbiBp c3N1ZSwgd2Ugc3RhcnRlZCB3aXRoDQo+ID4+Pj4+Pj4+Pj4+Pj4gYW4gSVNDIERIQ1Agb3BlbiBz b2Z0d2FyZSBjbGllbnQsIHdoaWNoIGRvZXMNCj4gPj4+Pj4+Pj4+Pj4+PiBpbXBsZW1lbnQgUHJl Zml4IERlbGVnYXRpb24uIEl0IGNhbiBiZQ0KPiA+Pj4+Pj4+Pj4+Pj4+IChjcm9zcyljb21waWxl ZCBvbiB2YXJpb3VzIHBsYXRmb3JtczsgdGhlbg0KPiA+Pj4+Pj4+Pj4+Pj4+IHR5cGUgIi4vZGhj bGllbnQgLTYgLVAiOyB0aGlzIHNlbmRzIGFuIERIQ1B2Ng0KPiA+Pj4+Pj4+Pj4+Pj4+IFNvbGlj aXQgSWRlbnRpdHkgQXNzb2NpdGFpb24gZm9yIFByZWZpeA0KPiA+Pj4+Pj4+Pj4+Pj4+IERlbGVn YXRpb24gbWVzc2FnZSBvbiB0aGUgaW50ZXJmYWNlLg0KPiA+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+Pj4+Pj4gSG93ZXZlciwgd2hlcmVhcyB0aGlzIHNvZnR3YXJlIHJ1bnMgb2sgb24NCj4gPj4+ Pj4+Pj4+Pj4+PiBpbnRlcmZhY2VzIHN1Y2ggYXMgRXRoZXJuZXQsIFVTQm5ldCBhbmQgV2lGaQ0K PiA+Pj4+Pj4+Pj4+Pj4+IGludGVyZmFjZXMsIGl0IGJyZWFrcyBpZiBydW4gb24gdGhlIGNlbGx1 bGFyDQo+ID4+Pj4+Pj4+Pj4+Pj4gaW50ZXJmYWNlIG9mIHNvbWUgSW9UIGNlbGx1bGFyIHBsYXRm b3JtLg0KPiA+Pj4+Pj4+Pj4+Pj4+IFRoZSBlcnJvciBjYW4gYmUgY29ycmVjdGVkIGJ5IHRoZQ0K PiA+Pj4+Pj4+Pj4+Pj4+IHF1aWNrLWFuZC1kaXJ0eSBzb2x1dGlvbiBiZWxvdy4NCj4gPj4+Pj4+ Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBUaGUgaGFjayB3b3VsZCBiZSBiZXR0ZXIgYXMNCj4gPj4+ Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiAjaWZkZWYgQVJQSFJEX1hYWFggY2FzZSBBUlBIUkRf WFhYWDogaHctPmhsZW4gPQ0KPiA+Pj4+Pj4+Pj4+Pj4gNzsgaHctPmhidWZbMF0gPSBIVFlQRV9F VEhFUjsNCj4gPj4+Pj4+Pj4+Pj4+IG1lbWNweSgmaHctPmhidWZbMV0sIHNhLT5zYV9kYXRhLCA2 KTsgYnJlYWs7DQo+ID4+Pj4+Pj4+Pj4+PiAjZW5kaWYgZGVmYXVsdDogbG9nX2ZhdGFsKCJVbnN1 cHBvcnRlZCBkZXZpY2UNCj4gPj4+Pj4+Pj4+Pj4+IHR5cGUgJWxkIGZvciBcIiVzXCIiLCAobG9u ZyBpbnQpc2EtPnNhX2ZhbWlseSwNCj4gPj4+Pj4+Pj4+Pj4+IG5hbWUpOyBicmVhazsNCj4gPj4+ Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiB3aXRoIEFSUEhSRF9YWFhYIGJlaW5nIHJlcGxhY2Vk IGJ5IHRoZSBjb3JyZWN0DQo+ID4+Pj4+Pj4+Pj4+PiBtYWNybyBmb3IgNTAzIGZyb20gPG5ldC9p Zl9hcnAuaD4uICBTb21ldGhpbmcNCj4gPj4+Pj4+Pj4+Pj4+IGxpa2UgdGhhdCBpcyBhdCBsZWFz dCBwb3J0YWJsZS4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gQnV0IGl0IG1lYW5zIHdo ZW4gSSBnbyB0byBvdGhlciBwbGF0Zm9ybSB3aWxsDQo+ID4+Pj4+Pj4+Pj4+IGhhdmUgdG8gbW9k aWZ5IGFnYWluIHRoZSBJU0MgY2xpZW50IHNvdXJjZSBjb2RlPw0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+ Pj4+Pj4+Pj4+PiBJbiBjZWxsdWxhciB0ZXJtaW5hbHMgdGhlcmUgYXJlIHNvIG1hbnkgbm9uLUlF RUUNCj4gPj4+Pj4+Pj4+Pj4gZGlmZmVyZW50IGtpbmRzIG9mIGxpbmtzLg0KPiA+Pj4+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+Pj4+PiBPdGhlciBjbGllbnRzIHdvcmsgb3V0IG9mIHRoZSBib3ggb24gdGhp cyAtIEkNCj4gPj4+Pj4+Pj4+Pj4gYWdyZWUgd2l0aCB5b3UsIHN0cmFuZ2UgLSAicm1uZXQwIiBp bnRlcmZhY2UuDQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+IEFsZXgNCj4gPj4+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+PiBBcyBmb3IgdGhlIHJlc3Qgb2YgaXQg SSBoYXZlIG5vIGlkZWEgYWJvdXQgdGhlDQo+ID4+Pj4+Pj4+Pj4+PiBwcmVzZW50ZWQgaGFyZHdh cmUgYWRkcmVzcyBvZiB0aGlzIHR5cGUgc28gSQ0KPiA+Pj4+Pj4+Pj4+Pj4gZG9uJ3Qga25vdyBp dCB0aGUgcmVzdCBvZiBpdCBtYWtlIHNlbnNlLg0KPiA+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ Pj4+PiBBbGV4DQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gPj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+Pg0KPiA+Pj4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4gPj4NCj4gPj4+Pj4+Pj4+ Pj4+Pg0KPiBUaGUgZXJyb3Igc2F5cyAiLy9VTlNVUFBPUlRFRCBERVZJQ0UgVFlQRSA1MDMgRk9S IFJNTkVUMC4iDQo+ID4+Pj4+Pj4+Pj4+Pj4gZGhjcC00LjMuNSAuL2NvbW1vbi9scGYuYyBsaW5l IG51bWJlcjogNTUxDQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+PiAvL2RlZmF1bHQ6 IC8vICAgICAgbG9nX2ZhdGFsKCJVbnN1cHBvcnRlZA0KPiA+Pj4+Pj4+Pj4+Pj4+IGRldmljZSB0 eXBlICVsZCBmb3IgXCIlc1wiIiwgLy8NCj4gPj4+Pj4+Pj4+Pj4+PiAobG9uZyBpbnQpc2EtPnNh X2ZhbWlseSwgbmFtZSk7IGRlZmF1bHQ6DQo+ID4+Pj4+Pj4+Pj4+Pj4gaHctPmhsZW4gPSA3OyBo dy0+aGJ1ZlswXSA9IEhUWVBFX0VUSEVSOw0KPiA+Pj4+Pj4+Pj4+Pj4+IG1lbWNweSgmaHctPmhi dWZbMV0sIHNhLT5zYV9kYXRhLCA2KTsgYnJlYWs7DQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+Pj4+PiAodHdvIHByb2dyYW1tZXJzIHdvcmtlZCB0aGlzIG91dCkuDQo+ID4+Pj4+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+Pj4+PiBBbGV4DQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+ Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+Pj4NCj4gdjZvcHMgbWFpbGluZyBsaXN0IHY2b3BzQGll dGYub3JnDQo+ID4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcw0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4+PiB2Nm9wcyBtYWls aW5nIGxpc3QgdjZvcHNAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4+ PiB2Nm9wcyBtYWlsaW5nIGxpc3QgdjZvcHNAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pj4+Pj4+Pj4+IHY2b3BzIG1haWxpbmcgbGlzdCB2Nm9wc0BpZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyB2Nm9wcw0KPiA+Pj4+Pj4+PiBtYWlsaW5nIGxpc3QgdjZvcHNAaWV0Zi5vcmcNCj4gPj4+Pj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiA+Pj4+Pg0K PiA+Pj4NCj4gPg0KDQo= From nobody Wed Sep 6 10:10:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561A51320C9 for ; Wed, 6 Sep 2017 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zD3_y4T6P7Yy for ; Wed, 6 Sep 2017 10:10:38 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610BE126DD9 for ; Wed, 6 Sep 2017 10:10:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v86HAXR8007094; Wed, 6 Sep 2017 19:10:33 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 40858207E91; Wed, 6 Sep 2017 19:10:33 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 32680207E59; Wed, 6 Sep 2017 19:10:33 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v86HAWTv025784; Wed, 6 Sep 2017 19:10:33 +0200 To: "Templin, Fred L" , "v6ops@ietf.org" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> Date: Wed, 6 Sep 2017 19:10:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:10:40 -0000 Fred, Le 06/09/2017 à 18:40, Templin, Fred L a écrit : [...] >> We dont want DHCP to assign addresses on interfaces. We want it >> to obtain a prefix from the network (DHCPv6 Prefix Delegation). >> Right? > > Obtain a prefix, yes. But, presumably, the Android node will want to > use the prefix in some fashion. Yes, first, we want our in-house software to form an address out of the delegated prefix and assign it on the WiFi interface. We want to do that without having to root the smartphone. 64share already does that in some sort. I dont understand why the 64share INFORMATIONAL RFC does address assignment by default, yet if I want to do it with the Prefix Delegation Stds Track RFC I have to risk the platform by trying to root it. > It can either act as a router (which is prohibited by Android without > rooting the device) Transforming a Host into a Router by toggling ipv6_forwarding should not need to root the device either. > or it can act as a host and try to assign addresses from the > delegated prefix to an interface (which is also prohibited by Android > w/o rooting the device). Prohibition wrong, must open. >>> But, Android does not allow apps to assign addresses to regular >>> interfaces. >> >> If so, it seems like a problem of Android. > > AFAICT, Android tries to protect users from shooting themselves in > the foot. Good initiative, but wrong results. Even if Android has not offered the means, others have offered more or less official means to root, like Huawei. At the end of the day one is still capable to shoot in the foot. Imagine that I had to root a smartphone in order to run IPv6 on it - is that acceptable? Is a user irresponsible if s/he wants to use IPv6? > Rooting the device is the user's way of saying: "I know what I am > doing and accept the consequences of my actions" but it voids any > warranties. I agree. Many people know what they are doing, but its inacceptable for someone to claim knowing better without proof. >> It's hard to accept buying an expensive smartphone with its data >> plan yet be forbidden to set an address on it on the command line. >> I should be allowed to freely set not one, but as many addresses >> that I want. > > You can try bringing up a terminal window app on the Android and > type: "ip -6 addr add 2001:db8::1 dev X" but it will not let you do > it. That should change. Alex From nobody Wed Sep 6 10:19:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493DB132A8F for ; Wed, 6 Sep 2017 10:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPPqF7asPdaT for ; Wed, 6 Sep 2017 10:19:14 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4E4D132946 for ; Wed, 6 Sep 2017 10:19:06 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 91B56B1; Wed, 6 Sep 2017 19:19:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504718344; bh=olBJ5jCSR4eZcejQ1I0LYA5BdC0t9UJmvUMOxFQcc9s=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=rSe6vDHgcF6Wt7XwHiW3d1nzp0mLIsRWONCHdYplF5yFNG4C/cEoZXd0mUzbEggLF 7aY8IE9SU6wcQAOR//Ghaieyy9ue/n9iCAHPw/xpCgd+GfSLa8CFv77fBGXewxbgjz Fkh860Xd5H00r3N+kXkkC1BKvFcfgf47GNaEIYb0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 78C9FAF; Wed, 6 Sep 2017 19:19:04 +0200 (CEST) Date: Wed, 6 Sep 2017 19:19:04 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: "Templin, Fred L" , "v6ops@ietf.org" In-Reply-To: <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> Message-ID: References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:19:21 -0000 On Wed, 6 Sep 2017, Alexandre Petrescu wrote: > I dont understand why the 64share INFORMATIONAL RFC does address > assignment by default, yet if I want to do it with the Prefix Delegation > Stds Track RFC I have to risk the platform by trying to root it. That's because you're trying to install something on it by yourself, when the vendor has decided this is not something they want their users to do. So proper procedure is to go to vendor and ask for feature. I've been out of the loop for a long time now, but I still haven't heard of any mobile core vendor who implemented DHCPv6-PD. That's the right thing to get done (and for instance on some WWAN router to have DHCPv6-PD client), then after that you can grow the rest of the ecosystem by doing feature requests. There is no standards action to be had here, the problem isn't with standards. It's with getting running code into all components needed to make this happen. There is nothing fundamental in 3GPP architecture that makes DHCPv6-PD hard to do, it's just that... nobody does it, so nobody tests against it. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Sep 6 10:21:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F8C132980 for ; Wed, 6 Sep 2017 10:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW9INVFI4PGI for ; Wed, 6 Sep 2017 10:21:39 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB49C1329B5 for ; Wed, 6 Sep 2017 10:21:19 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v86HLHgr003427 for ; Wed, 6 Sep 2017 19:21:17 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BF3D4207EBE for ; Wed, 6 Sep 2017 19:21:17 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B551C207C4D for ; Wed, 6 Sep 2017 19:21:17 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v86HLH8T029771 for ; Wed, 6 Sep 2017 19:21:17 +0200 To: v6ops@ietf.org References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> From: Alexandre Petrescu Message-ID: <475edc27-0c8c-fd90-e25e-d4cabe80787b@gmail.com> Date: Wed, 6 Sep 2017 19:21:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6 PD client on cellular on Android and modems X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:21:42 -0000 I wanted to clarify one thing. Le 05/09/2017 à 17:39, Alexandre Petrescu a écrit : [...] > Here are the unique reasons - if solely these are solved then we get > PD on cellular: - some modems in the UE (e.g. QDSP6 and others) block > standard DHCPv6 UDP port numbers 546 and 547 and (and sometimes or) > standard IP multicast addressing in both directions; I mentioned above modem "QDSP6" which is a Qalcomm product in Sierra module; but there are other modems in other platforms. In our Android smartphone the brand is Huawei Mate 8, the processor is produced by HiSilicon, the model is HiSilicom Kirin 950 and the modem integrated in the processor is Balong Integrated UE [User Equipment] Cat. 6E. It is highly likely that the Balong Integrated UE blocks IPv6 multicast packets; these packets are of utmost importance to the execution of DHCPv6 Prefix Delegation. (it is very little probable that the Base Station, nor SGW, nor PGW block this multicast addressing). I have been asked whether the Android linux (instead of the Balong modem software) blocks these multicast packets necessary to DHCPv6 Prefix Delegation. I think no, but I am not a specialist of Android. Anybody knows? Is Android on Huawei smartphone blocking the multicast addressed packets of DHCPv6 Prefix Delegation? Alex this blocking was identified > by comparing packet dumps on the ARM part of UE, vs on PGW; this > blocking was further confirmed by successful Sol/Adv on unicast and > non-std UDP ports. This blocking happens even though the application > processor (e.g. ARM) does not block them. These ports and multicast > are absolutely needed for Prefix Delegation, because Prefix > Delegation runs as an integral part of DHCPv6. - much less likely, it > may be that some infrastructure entities like Base Station or SGW - > again, very little probable - blocks same DHCP ports and multicast. - > DHCPv6 software is little parametrable or portable, even though much > source is available openly. > > Some details: - the DHCPv6 software on Android is hampered by the > need of root access. Android blocks that. One needs to ask the > platform manufacturer running that Android to "root" the platform > such as to be able to run some of the DHCP client software (e.g. ask > Huawei for a key to root the smartphone). That's a real pain. There > is a risk of "bricking" your platform, i.e. through it out a window. > - to make an app available to everyone on Android one must pay some > money to become a member of a store. DHCP should not be part of > that, as SLAAC isnt; just like SLAAC, DHCP should be builtin for > free. - the DHCPv6 server software "ISC" breaks if the port numbers > are non-standard (not 546 nor 547) or unicast instead of multicast. > (e.g. "Discarding Solicit from [snip]; packet sent unicast") This was > a real pain, because we had to modify the source code to allow it; > other software like VoIP has SIP ports this configurable easily with > a GUI. - Cisco parametering CLI of DHCPv6 service may have some > problems in transforming a non-standard UDP port 546 of Solicit to a > strange 26483. That was a real pain to one. - various DHCPv6 client > software break, or do not even start, with any other src and dst UDP > ports than the standard (546, 547) and/or non-standard unicast > instead of standard multicast. > > Other reasons proved not to be causes of absence of DHCPv6 PD on > cellular links; they were just speculations: - cellular operators > dont provide DHCPv6 PD service (there are some who do under some > operational conditions) - cellular operators have a hard time making > an IPv6 addressing architecture that delegate prefixes instead of > addresses (there are some who do make such architecture) - cellular > operators only do '64' (it's false, some could do less, like 56 or > even 48) - DHCPv6 software is not available on the client (there are > some, like on Android, and more, see quoted mails below) - the > computer that runs the DHCPv6 client is the same as the one that puts > the Solicit on the wire: this is not true, because even in the > smallest UE in the market there is still distinction app-vs-modem > processors. Often the modem part is confidential, only the binary is > available to the public, and there are two IPs on it: Internet > Protocol _and_ Intellectual Property. > > Alex, with thanks to [Hachata], admin(s), managers, and technicals > at offices and organisations. > > > Le 18/08/2017 à 18:07, Alexandre Petrescu a écrit : >> I have been pointed by a helpful person that an Android app for >> DHCPv6 exists there: >> >> https://play.google.com/store/apps/details?id=org.daduke.realmar.dhcpv6client&hl=fr >> >> >> >> >> >> >> >> It is based on the WIDE DHCPv6 client. >> >> Further browsing leads to a discussion of DHCPv6 on Android topic: >> https://issuetracker.google.com/issues/36949085 >> >> Alex >> >> Le 17/07/2017 à 18:26, Alexandre Petrescu a écrit : >>> Well, this is to note that we too (Fred mentioned it too earlier) >>> made the ISC DHCPv6 dhclient work on Android, including DHCPv6 >>> Solicit that requests Prefix Delegation. >>> >>> (but we still dont have a response to DHCP Solicit on cellular >>> link). >>> >>> Alex >>> >>> Le 06/07/2017 à 18:32, Alexandre Petrescu a écrit : >>>> Mark, noted, will try. >>>> >>>> Just a note... >>>> >>>> Le 06/07/2017 à 03:16, Mark Andrews a écrit : >>>>> >>>>> In message <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, >>>>> Alexandre Petrescu writes: >>>>>> Hello, >>>>>> >>>>>> We discussed extensively about the potential use of DHCPv6 >>>>>> Prefix Delegation on cellular links. >>>>>> >>>>>> The chicken issue is the lack of DHCPv6 PD software on >>>>>> typical User Equipment. For example, there is no DHCPv6-PD >>>>>> app on Android. The egg issue is the lack of operator >>>>>> support of DHCPv6-PD towards the User Terminal. For >>>>>> example, there is no cellular operator answering to >>>>>> DHCPv6-PD requests issued by the User Terminal. >>>>>> >>>>>> To address the chicken issue, we started with an ISC DHCP >>>>>> open software client, which does implement Prefix >>>>>> Delegation. It can be (cross)compiled on various platforms; >>>>>> then type "./dhclient -6 -P"; this sends an DHCPv6 Solicit >>>>>> Identity Associtaion for Prefix Delegation message on the >>>>>> interface. >>>>>> >>>>>> However, whereas this software runs ok on interfaces such >>>>>> as Ethernet, USBnet and WiFi interfaces, it breaks if run >>>>>> on the cellular interface of some IoT cellular platform. >>>>>> The error can be corrected by the quick-and-dirty solution >>>>>> below. >>>>> >>>>> The hack would be better as >>>>> >>>>> #ifdef ARPHRD_XXXX case ARPHRD_XXXX: hw->hlen = 7; >>>>> hw->hbuf[0] = HTYPE_ETHER; memcpy(&hw->hbuf[1], sa->sa_data, >>>>> 6); break; #endif default: log_fatal("Unsupported device type >>>>> %ld for \"%s\"", (long int)sa->sa_family, name); break; >>>>> >>>>> with ARPHRD_XXXX being replaced by the correct macro for 503 >>>>> from . Something like that is at least >>>>> portable. >>>> >>>> But it means when I go to other platform will have to modify >>>> again the ISC client source code? >>>> >>>> In cellular terminals there are so many non-IEEE different >>>> kinds of links. >>>> >>>> Other clients work out of the box on this - I agree with you, >>>> strange - "rmnet0" interface. >>>> >>>> Alex >>>> >>>>> >>>>> As for the rest of it I have no idea about the presented >>>>> hardware address of this type so I don't know it the rest of >>>>> it make sense. >>>>> >>>>>> Alex >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> The error says "//UNSUPPORTED DEVICE TYPE 503 FOR RMNET0." >>>>>> dhcp-4.3.5 ./common/lpf.c line number: 551 >>>>>> >>>>>> //default: // log_fatal("Unsupported device type %ld >>>>>> for \"%s\"", // (long int)sa->sa_family, >>>>>> name); default: hw->hlen = 7; hw->hbuf[0] = HTYPE_ETHER; >>>>>> memcpy(&hw->hbuf[1], sa->sa_data, 6); break; >>>>>> >>>>>> (two programmers worked this out). >>>>>> >>>>>> Alex >>>>>> >>>>>> _______________________________________________ v6ops >>>>>> mailing list v6ops@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> _______________________________________________ v6ops mailing >>>> list v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Sep 6 10:53:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9881321A2 for ; Wed, 6 Sep 2017 10:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI1SF_vQ8dSC for ; Wed, 6 Sep 2017 10:53:47 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9A22132055 for ; Wed, 6 Sep 2017 10:53:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v86Hrg37021906; Wed, 6 Sep 2017 19:53:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A9081207EEE; Wed, 6 Sep 2017 19:53:42 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 99B5B207EA4; Wed, 6 Sep 2017 19:53:42 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v86HrgWn007747; Wed, 6 Sep 2017 19:53:42 +0200 To: Mikael Abrahamsson Cc: "Templin, Fred L" , "v6ops@ietf.org" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> From: Alexandre Petrescu Message-ID: <92c1bb9c-0d23-6037-e124-dfe74df530f7@gmail.com> Date: Wed, 6 Sep 2017 19:53:42 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 17:53:49 -0000 Le 06/09/2017 à 19:19, Mikael Abrahamsson a écrit : > On Wed, 6 Sep 2017, Alexandre Petrescu wrote: > >> I dont understand why the 64share INFORMATIONAL RFC does address >> assignment by default, yet if I want to do it with the Prefix >> Delegation Stds Track RFC I have to risk the platform by trying to >> root it. > > That's because you're trying to install something on it by yourself, > when the vendor has decided this is not something they want their > users to do. What users want must be standard, and vice-versa. We have a problem in that the standard is not what the users want. Or maybe the problem lies in the vendor interpretation of what users want. > So proper procedure is to go to vendor and ask for feature. For Android there is a feature request to get DHCPv6 working on Android https://issuetracker.google.com/issues/36949085 The discussion runs since 2012 until now. Maybe with a specialised DHCPv6 Prefix Delegation request (rather than just DHCPv6) it could go further? > I've been out of the loop for a long time now, but I still haven't > heard of any mobile core vendor who implemented DHCPv6-PD. Cisco does that. On AS5500 they have DHCPv6 Prefix Delegation service. Some cellular operators have AS5500 on PGW. Or I dont understand what do you mean by 'mobile core vendor'? > That's the right thing to get done Some feature requests are ongoing at hardware manufacturers, operators, vendors; but do you have one particular feature request in mind that I could file? > (and for instance on some WWAN router to have DHCPv6-PD client), I dont understand this. Among many dimensions, there is one in which two distinct models propose DHCPv6 Prefix Delegation in a cellular network. A good sketch of it (it misses many details like Host-IMP interfaces in the UE) is in Figures 2 and 3 of RFC6653 "Prefix Delegation on LTE". Is it model of Figure 2 you talk about? Or Figure 3? > then after that you can grow the rest of the ecosystem by doing > feature requests. Which feature request would one think of? > There is no standards action to be had here, the problem isn't with > standards. It's with getting running code into all components needed > to make this happen. There is nothing fundamental in 3GPP > architecture that makes DHCPv6-PD hard to do, it's just that... > nobody does it, so nobody tests against it. Others and us by rooting the device were able to successfully test it. There is no more question of whether it works or not - it works, provided some conditions are satisfied. To make it work some put it on a VPN, others use non-standard unicast or non-standard UDP port numbers. We dont want to go that way, we want to use standards. The 3GPP specs must says this: the UE (e.g. QDSP6, Balong) MUST NOT run DHCPv6 software, proxies, clients or relays; it MUST NOT filter IPv6 packets port 546 and 547, nor IPv6 multicast address ff02::2:1 (all-DHCP-servers). It is the application processor (e.g. ARM) that MUST run DHCPv6 software. 3GPP should also understand the fine distinction between DHCPv6-for-addresses (IA_NA, we dont want on smartphone) and DHCPv6 Prefix Delegation (IA_PD, we want on smartphone). Alex From nobody Wed Sep 6 11:03:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77932132055 for ; Wed, 6 Sep 2017 11:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfsWm9NNigtR for ; Wed, 6 Sep 2017 11:03:27 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303E41321E6 for ; Wed, 6 Sep 2017 11:03:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1D9C5B1; Wed, 6 Sep 2017 20:03:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504721005; bh=LRE18T/ZBHIZuoM6mVEbXkeE+VfXsgliQO5K32RDzu8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ht7lfrC6CToe7CsJEP2h6MtRiWrrye5FOS8FCC0aRj+C1C9tbpgGef6+/sOH2IHuV gfHas4QOamUGVbsQ9Vo79eEW+JulDrWaOLad/mxuH6od034A3RGG6d7Cs/Jn36jhHt XS6RrFh/OJK7bN6GbdoYXjOqirULT9/LK0/4hYKA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0610AAF; Wed, 6 Sep 2017 20:03:25 +0200 (CEST) Date: Wed, 6 Sep 2017 20:03:25 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: "Templin, Fred L" , "v6ops@ietf.org" In-Reply-To: <92c1bb9c-0d23-6037-e124-dfe74df530f7@gmail.com> Message-ID: References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <92c1bb9c-0d23-6037-e124-dfe74df530f7@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 18:03:28 -0000 On Wed, 6 Sep 2017, Alexandre Petrescu wrote: >> I've been out of the loop for a long time now, but I still haven't heard of >> any mobile core vendor who implemented DHCPv6-PD. > > Cisco does that. On AS5500 they have DHCPv6 Prefix Delegation service. > Some cellular operators have AS5500 on PGW. > > Or I dont understand what do you mean by 'mobile core vendor'? Yes, I mean PGW and the rest of the 3GPP core nodes. > Some feature requests are ongoing at hardware manufacturers, operators, > vendors; but do you have one particular feature request in mind that I > could file? No, "create everything needed for DHCPv6-PD server in PGW". >> (and for instance on some WWAN router to have DHCPv6-PD client), > > I dont understand this. The natural case for DHCPv6-PD is a router with 4G uplink and multiple LAN interfaces. > 3GPP should also understand the fine distinction between > DHCPv6-for-addresses (IA_NA, we dont want on smartphone) and DHCPv6 > Prefix Delegation (IA_PD, we want on smartphone). When we discussed this a few years back and i looked at the 2012 specs, this was already that way. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Sep 6 11:14:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA88C132705 for ; Wed, 6 Sep 2017 11:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaGtotQUZq02 for ; Wed, 6 Sep 2017 11:14:34 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48BBF13292C for ; Wed, 6 Sep 2017 11:14:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v86IEX9k004604; Wed, 6 Sep 2017 11:14:33 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v86IERpE004517 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 6 Sep 2017 11:14:27 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Sep 2017 11:14:27 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 6 Sep 2017 11:14:27 -0700 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] Android must allow root access Thread-Index: AQHTJzv50V/YyosaiU2YXiTgPr6MRQ== Date: Wed, 6 Sep 2017 18:14:27 +0000 Message-ID: <5fe9eea416834b199da609065a4ad510@XCH15-06-08.nw.nos.boeing.com> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> In-Reply-To: <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 18:14:36 -0000 SGkgQWxleCwNCg0KSW4gZ2VuZXJhbCwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IEFuZHJvaWQg aXMgbGlrZSBhIG1pbmkgbGludXggc3lzdGVtIGluDQp5b3VyIHBvY2tldC4gQXMgeW91IGtub3cs IGxpbnV4IHByb2hpYml0cyBnZW5lcmFsIHVzZXJzIGZyb20gc2V0dGluZw0KbmV0d29yayBjb25m aWd1cmF0aW9ucyAoZS5nLiwgYWRkaW5nIGFuIGFkZHJlc3MgdG8gYW4gaW50ZXJmYWNlKSB3aXRo b3V0DQpmaXJzdCBlbGV2YXRpbmcgdGhlaXIgcHJpdmlsZWdlcy4gQW5kLCBpbiBhbmRyb2lkLCB0 aGUgb25seSB3YXkgZm9yIGEgZ2VuZXJhbA0KdXNlciB0byBnYWluIGVsZXZhdGVkIHByaXZpbGVn ZXMgaXMgdG8gcm9vdCB0aGUgZGV2aWNlLg0KDQpUbyBNaWthZWwncyBwb2ludCwgc3lzdGVtIHBy b2Nlc3NlcyB0aGF0IGFyZSBjYXBhYmxlIG9mIG1hbmFnaW5nDQpuZXR3b3JrIGNvbmZpZ3VyYXRp b24gc2V0dGluZ3MgYXJlIHBsYWNlZCB0aGVyZSBieSB0aGUgbWFudWZhY3R1cmVyDQphbmQgaGF2 ZSBlbGV2YXRlZCBwcml2aWxlZ2VzIGZvciB0aGUgc3BlY2lmaWMgdGFzayB0aGV5IHdlcmUgZGVz aWduZWQNCnRvIHBlcmZvcm0uIEJ1dCwgYSBnZW5lcmFsIHVzZXIgY2Fubm90IGNyZWF0ZSBhbiBh cHAgd2l0aCBlbGV2YXRlZA0KcHJpdmlsZWdlcywgc28gdW5sZXNzIHRoZSBtYW51ZmFjdHVyZXIg c3VwcG9ydHMgaXQgdGhlIGFwcCBjYW5ub3QNCm1lc3MgYXJvdW5kIHdpdGggbmV0d29yayBjb25m aWd1cmF0aW9uIHNldHRpbmdzLg0KDQpBcHBzIHRoYXQgdXNlIFZwblNlcnZpY2UgYXJlIGFuIGV4 YW1wbGUgb2YgYW4gYXBwIHRoYXQgY2FuIHdvcmsNCmFyb3VuZCB0aGlzIGxpbWl0YXRpb24uIERv IHlvdSBrbm93IG9mIG90aGVycz8NCg0KVGhhbmtzIC0gRnJlZA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEFsZXhhbmRyZSBQZXRyZXNjdSBbbWFpbHRvOmFsZXhhbmRy ZS5wZXRyZXNjdUBnbWFpbC5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDA2LCAy MDE3IDEwOjExIEFNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb20+OyB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBBbmRyb2lkIG11 c3QgYWxsb3cgcm9vdCBhY2Nlc3MNCj4gDQo+IEZyZWQsDQo+IA0KPiBMZSAwNi8wOS8yMDE3IMOg IDE4OjQwLCBUZW1wbGluLCBGcmVkIEwgYSDDqWNyaXQgOg0KPiBbLi4uXQ0KPiA+PiBXZSBkb250 IHdhbnQgREhDUCB0byBhc3NpZ24gYWRkcmVzc2VzIG9uIGludGVyZmFjZXMuICBXZSB3YW50IGl0 DQo+ID4+IHRvIG9idGFpbiBhIHByZWZpeCBmcm9tIHRoZSBuZXR3b3JrIChESENQdjYgUHJlZml4 IERlbGVnYXRpb24pLg0KPiA+PiBSaWdodD8NCj4gPg0KPiA+IE9idGFpbiBhIHByZWZpeCwgeWVz LiBCdXQsIHByZXN1bWFibHksIHRoZSBBbmRyb2lkIG5vZGUgd2lsbCB3YW50IHRvDQo+ID4gIHVz ZSB0aGUgcHJlZml4IGluIHNvbWUgZmFzaGlvbi4NCj4gDQo+IFllcywgZmlyc3QsIHdlIHdhbnQg b3VyIGluLWhvdXNlIHNvZnR3YXJlIHRvIGZvcm0gYW4gYWRkcmVzcyBvdXQgb2YgdGhlDQo+IGRl bGVnYXRlZCBwcmVmaXggYW5kIGFzc2lnbiBpdCBvbiB0aGUgV2lGaSBpbnRlcmZhY2UuDQo+IA0K PiBXZSB3YW50IHRvIGRvIHRoYXQgd2l0aG91dCBoYXZpbmcgdG8gcm9vdCB0aGUgc21hcnRwaG9u ZS4NCj4gDQo+IDY0c2hhcmUgYWxyZWFkeSBkb2VzIHRoYXQgaW4gc29tZSBzb3J0Lg0KPiANCj4g SSBkb250IHVuZGVyc3RhbmQgd2h5IHRoZSA2NHNoYXJlIElORk9STUFUSU9OQUwgUkZDIGRvZXMg YWRkcmVzcw0KPiBhc3NpZ25tZW50IGJ5IGRlZmF1bHQsIHlldCBpZiBJIHdhbnQgdG8gZG8gaXQg d2l0aCB0aGUgUHJlZml4IERlbGVnYXRpb24NCj4gU3RkcyBUcmFjayBSRkMgSSBoYXZlIHRvIHJp c2sgdGhlIHBsYXRmb3JtIGJ5IHRyeWluZyB0byByb290IGl0Lg0KPiANCj4gPiBJdCBjYW4gZWl0 aGVyIGFjdCBhcyBhIHJvdXRlciAod2hpY2ggaXMgcHJvaGliaXRlZCBieSBBbmRyb2lkIHdpdGhv dXQNCj4gPiByb290aW5nIHRoZSBkZXZpY2UpDQo+IA0KPiBUcmFuc2Zvcm1pbmcgYSBIb3N0IGlu dG8gYSBSb3V0ZXIgYnkgdG9nZ2xpbmcgaXB2Nl9mb3J3YXJkaW5nIHNob3VsZCBub3QNCj4gbmVl ZCB0byByb290IHRoZSBkZXZpY2UgZWl0aGVyLg0KPiANCj4gPiBvciBpdCBjYW4gYWN0IGFzIGEg aG9zdCBhbmQgdHJ5IHRvIGFzc2lnbiBhZGRyZXNzZXMgZnJvbSB0aGUNCj4gPiBkZWxlZ2F0ZWQg cHJlZml4IHRvIGFuIGludGVyZmFjZSAod2hpY2ggaXMgYWxzbyBwcm9oaWJpdGVkIGJ5IEFuZHJv aWQNCj4gPiB3L28gcm9vdGluZyB0aGUgZGV2aWNlKS4NCj4gDQo+IFByb2hpYml0aW9uIHdyb25n LCBtdXN0IG9wZW4uDQo+IA0KPiA+Pj4gQnV0LCBBbmRyb2lkIGRvZXMgbm90IGFsbG93IGFwcHMg dG8gYXNzaWduIGFkZHJlc3NlcyB0byByZWd1bGFyDQo+ID4+PiBpbnRlcmZhY2VzLg0KPiA+Pg0K PiA+PiBJZiBzbywgaXQgc2VlbXMgbGlrZSBhIHByb2JsZW0gb2YgQW5kcm9pZC4NCj4gPg0KPiA+ IEFGQUlDVCwgQW5kcm9pZCB0cmllcyB0byBwcm90ZWN0IHVzZXJzIGZyb20gc2hvb3RpbmcgdGhl bXNlbHZlcyBpbg0KPiA+IHRoZSBmb290Lg0KPiANCj4gR29vZCBpbml0aWF0aXZlLCBidXQgd3Jv bmcgcmVzdWx0cy4NCj4gDQo+IEV2ZW4gaWYgQW5kcm9pZCBoYXMgbm90IG9mZmVyZWQgdGhlIG1l YW5zLCBvdGhlcnMgaGF2ZSBvZmZlcmVkIG1vcmUgb3INCj4gbGVzcyBvZmZpY2lhbCBtZWFucyB0 byByb290LCBsaWtlIEh1YXdlaS4gIEF0IHRoZSBlbmQgb2YgdGhlIGRheSBvbmUgaXMNCj4gc3Rp bGwgY2FwYWJsZSB0byBzaG9vdCBpbiB0aGUgZm9vdC4NCj4gDQo+IEltYWdpbmUgdGhhdCBJIGhh ZCB0byByb290IGEgc21hcnRwaG9uZSBpbiBvcmRlciB0byBydW4gSVB2NiBvbiBpdCAtIGlzDQo+ IHRoYXQgYWNjZXB0YWJsZT8NCj4gDQo+IElzIGEgdXNlciBpcnJlc3BvbnNpYmxlIGlmIHMvaGUg IHdhbnRzIHRvIHVzZSBJUHY2Pw0KPiANCj4gPiBSb290aW5nIHRoZSBkZXZpY2UgaXMgdGhlIHVz ZXIncyB3YXkgb2Ygc2F5aW5nOiAiSSBrbm93IHdoYXQgSSBhbQ0KPiA+IGRvaW5nIGFuZCBhY2Nl cHQgdGhlIGNvbnNlcXVlbmNlcyBvZiBteSBhY3Rpb25zIiBidXQgaXQgdm9pZHMgYW55DQo+ID4g d2FycmFudGllcy4NCj4gDQo+IEkgYWdyZWUuICBNYW55IHBlb3BsZSBrbm93IHdoYXQgdGhleSBh cmUgZG9pbmcsIGJ1dCBpdHMgaW5hY2NlcHRhYmxlIGZvcg0KPiBzb21lb25lIHRvIGNsYWltIGtu b3dpbmcgYmV0dGVyIHdpdGhvdXQgcHJvb2YuDQo+IA0KPiA+PiBJdCdzIGhhcmQgdG8gYWNjZXB0 IGJ1eWluZyBhbiBleHBlbnNpdmUgc21hcnRwaG9uZSB3aXRoIGl0cyBkYXRhDQo+ID4+IHBsYW4g eWV0IGJlIGZvcmJpZGRlbiB0byBzZXQgYW4gYWRkcmVzcyBvbiBpdCBvbiB0aGUgY29tbWFuZCBs aW5lLg0KPiA+PiAgSSBzaG91bGQgYmUgYWxsb3dlZCB0byBmcmVlbHkgc2V0IG5vdCBvbmUsIGJ1 dCBhcyBtYW55IGFkZHJlc3Nlcw0KPiA+PiB0aGF0IEkgd2FudC4NCj4gPg0KPiA+IFlvdSBjYW4g dHJ5IGJyaW5naW5nIHVwIGEgdGVybWluYWwgd2luZG93IGFwcCBvbiB0aGUgQW5kcm9pZCBhbmQN Cj4gPiB0eXBlOiAiaXAgLTYgYWRkciBhZGQgMjAwMTpkYjg6OjEgZGV2IFgiIGJ1dCBpdCB3aWxs IG5vdCBsZXQgeW91IGRvDQo+ID4gaXQuDQo+IA0KPiBUaGF0IHNob3VsZCBjaGFuZ2UuDQo+IA0K PiBBbGV4DQoNCg== From nobody Wed Sep 6 12:15:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E5D132980 for ; Wed, 6 Sep 2017 12:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSb2oB4agDTW for ; Wed, 6 Sep 2017 12:15:31 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299AA120720 for ; Wed, 6 Sep 2017 12:15:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v86JFQWS045070; Wed, 6 Sep 2017 21:15:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 43F0C207F3A; Wed, 6 Sep 2017 21:15:26 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 347DF200CF9; Wed, 6 Sep 2017 21:15:26 +0200 (CEST) Received: from [132.166.84.49] ([132.166.84.49]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v86JFP94014021; Wed, 6 Sep 2017 21:15:25 +0200 To: Mikael Abrahamsson Cc: "Templin, Fred L" , "v6ops@ietf.org" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <92c1bb9c-0d23-6037-e124-dfe74df530f7@gmail.com> From: Alexandre Petrescu Message-ID: <77f8d0a6-a717-7411-61d5-130c1246477d@gmail.com> Date: Wed, 6 Sep 2017 21:15:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 19:15:33 -0000 Mikael, Le 06/09/2017 à 20:03, Mikael Abrahamsson a écrit : >> Some feature requests are ongoing at hardware manufacturers, >> operators, vendors; but do you have one particular feature request >> in mind that I could file? > > No, "create everything needed for DHCPv6-PD server in PGW". I see, I agree. It sounds like an excellent feature request. We did something along these lines that and we got answers: (1) the Cisco CLI has a problem in setting other UDP listening port number than the standard 547. When they set it to 546 the GUI shows 26483 and (2) they dont want to listen to any unicast address because the DHCPv6 _multicast_ address is the standard. It's also little appreciated to ask Cisco for a feature request that is a Balong problem (multicast is standard and Balong does unicast). I wonder whether Balong has a webpage to receive feature requests? I could ask them to allow IPv6 multicast through, because DHCPv6 PD needs it. Or should one rather ask the DHC WG to for a DHCPv6 server to listen to unicast to become a standard too? And maybe listen to a dynamically-defined UDP port number, rather than the fixed 547? Which way? One should consider that an update to Balong may be a hardware upgrade, which may be rolled in into future smartphones, but old smartphones would still not work. I would like a solution for both present and future smartphones to run DHCPv6 Prefix Delegation, because some of the users I am concerned with will carry their old smartphones and some cars will carry new 4G modems. >>> (and for instance on some WWAN router to have DHCPv6-PD client), >> >> I dont understand this. > > The natural case for DHCPv6-PD is a router with 4G uplink and > multiple LAN interfaces. I agree, and Sierra built what may be the smallest such natural router on the market (4g uplink, Ethernet downlink1, WiFi downlink2 on 7cmx7cm). Yet it can't be called "smallest IPv6 WWAN router" because of this lack of PD. >> 3GPP should also understand the fine distinction between >> DHCPv6-for-addresses (IA_NA, we dont want on smartphone) and >> DHCPv6 Prefix Delegation (IA_PD, we want on smartphone). > > When we discussed this a few years back and i looked at the 2012 > specs, this was already that way. In this case, I believe there may be misunderstanding. Either spec writers dont understand the implementers, or vice-versa. Alex > From nobody Wed Sep 6 12:37:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC411326BB for ; Wed, 6 Sep 2017 12:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHjjzp8giyuk for ; Wed, 6 Sep 2017 12:37:12 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18AD81201F8 for ; Wed, 6 Sep 2017 12:37:12 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 87BEDB1; Wed, 6 Sep 2017 21:37:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504726629; bh=WKpnLgNUjH30G8S0t8MLJdt0Ey/xC5PkBgorFKyklSc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=K4gxXOy/rE9fpCgIUv49ak2rGXe3Nl9g2TU3iuDzM5hxNrm58rjz503KDdeDksKtr 1v0K84D4sGFNk2rGg6n9yvBeqhMAGxGdVLpMIcJ8zL2l4+s7uMst1U96cn81/R+xQC rnnMe/aewkljvc53bZMijgPxpwzuyj5qh/yHc2ns= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6E67CAF; Wed, 6 Sep 2017 21:37:09 +0200 (CEST) Date: Wed, 6 Sep 2017 21:37:09 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: "Templin, Fred L" , "v6ops@ietf.org" In-Reply-To: <77f8d0a6-a717-7411-61d5-130c1246477d@gmail.com> Message-ID: References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <92c1bb9c-0d23-6037-e124-dfe74df530f7@gmail.com> <77f8d0a6-a717-7411-61d5-130c1246477d@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 19:37:14 -0000 On Wed, 6 Sep 2017, Alexandre Petrescu wrote: > Or should one rather ask the DHC WG to for a DHCPv6 server to listen > to unicast to become a standard too? And maybe listen to a > dynamically-defined UDP port number, rather than the fixed 547? What unicast address would you send this packet to? > Which way? Fix the defective 3GPP baseband thingie that drops multicast is the proper solution. > In this case, I believe there may be misunderstanding. Either spec > writers dont understand the implementers, or vice-versa. ... or the implementers do the wrong thing because they don't know better. Perhaps they tried to save energy so they decided to put in filters for multicast traffic. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Sep 6 13:12:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C25B1321AF for ; Wed, 6 Sep 2017 13:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCMHvxxd8_b2 for ; Wed, 6 Sep 2017 13:12:01 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A36126B7E for ; Wed, 6 Sep 2017 13:12:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v86KBuYk045231; Wed, 6 Sep 2017 22:11:56 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 752A0207F92; Wed, 6 Sep 2017 22:11:56 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 65174207F87; Wed, 6 Sep 2017 22:11:56 +0200 (CEST) Received: from [132.166.84.49] ([132.166.84.49]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v86KBthw009187; Wed, 6 Sep 2017 22:11:56 +0200 To: Mikael Abrahamsson Cc: "Templin, Fred L" , "v6ops@ietf.org" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <92c1bb9c-0d23-6037-e124-dfe74df530f7@gmail.com> <77f8d0a6-a717-7411-61d5-130c1246477d@gmail.com> From: Alexandre Petrescu Message-ID: <145ed661-5aa2-9ea6-593e-83ab6763871d@gmail.com> Date: Wed, 6 Sep 2017 22:11:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 20:12:02 -0000 Le 06/09/2017 à 21:37, Mikael Abrahamsson a écrit : > On Wed, 6 Sep 2017, Alexandre Petrescu wrote: > >> Or should one rather ask the DHC WG to for a DHCPv6 server to listen >> to unicast to become a standard too?  And maybe listen to a >> dynamically-defined UDP port number, rather than the fixed 547? > > What unicast address would you send this packet to? An unicast address communicated out-of-band. >> Which way? > > Fix the defective 3GPP baseband thingie that drops multicast is the > proper solution. That may mean new hardware. But old hardware would continue to block DHCPv6-PD. >> In this case, I believe there may be misunderstanding.  Either spec >> writers dont understand the implementers, or vice-versa. > > ... or the implementers do the wrong thing because they don't know > better. Perhaps they tried to save energy so they decided to put in > filters for multicast traffic. Could be. Alex From nobody Wed Sep 6 19:02:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BF6132D67 for ; Wed, 6 Sep 2017 19:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIevsM18t00e for ; Wed, 6 Sep 2017 19:02:35 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DF3132D62 for ; Wed, 6 Sep 2017 19:02:35 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id AE42434B9BA; Thu, 7 Sep 2017 02:02:03 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 99F41160043; Thu, 7 Sep 2017 02:02:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 75C21160071; Thu, 7 Sep 2017 02:02:03 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0W1b8C-u0Vqw; Thu, 7 Sep 2017 02:02:03 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id ED6BB160043; Thu, 7 Sep 2017 02:02:02 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9D9D88476F3E; Thu, 7 Sep 2017 12:02:00 +1000 (AEST) To: "Templin, Fred L" Cc: Alexandre Petrescu , "v6ops@ietf.org" From: Mark Andrews References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <5fe9eea416834b199da609065a4ad510@XCH15-06-08.nw.nos.boeing.com> In-reply-to: Your message of "Wed, 06 Sep 2017 18:14:27 +0000." <5fe9eea416834b199da609065a4ad510@XCH15-06-08.nw.nos.boeing.com> Date: Thu, 07 Sep 2017 12:02:00 +1000 Message-Id: <20170907020200.9D9D88476F3E@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 02:02:37 -0000 In message <5fe9eea416834b199da609065a4ad510@XCH15-06-08.nw.nos.boeing.com>, "T emplin, Fred L" writes: > Hi Alex, > > In general, my understanding is that Android is like a mini linux system > in your pocket. As you know, linux prohibits general users from setting > network configurations (e.g., adding an address to an interface) without > first elevating their privileges. And, in android, the only way for a > general user to gain elevated privileges is to root the device. Can anyone tell me why we bother with reserved ports anymore on single user machines? No one uses r* commands anymore and they are the only thing that really depended on ports being restricted. The only thing else they do is allow the operator to bring up a service after startup without having to worry has some "user" grabbed the port. > To Mikael's point, system processes that are capable of managing > network configuration settings are placed there by the manufacturer > and have elevated privileges for the specific task they were designed > to perform. But, a general user cannot create an app with elevated > privileges, so unless the manufacturer supports it the app cannot > mess around with network configuration settings. Reserved ports are orthogonal to changing network settings. I can configure FreeBSD so all ports are available to all users but only root can change the systems IP addresses. > Apps that use VpnService are an example of an app that can work > around this limitation. Do you know of others? > > Thanks - Fred > > > -----Original Message----- > > From: Alexandre Petrescu mailto:alexandre.petrescu@gmail.com > > Sent: Wednesday, September 06, 2017 10:11 AM > > To: Templin, Fred L ; v6ops@ietf.org > > Subject: Re: v6ops Android must allow root access > > > > Fred, > > > > Le 06/09/2017 18:40, Templin, Fred L a crit : > > ... > > >> We dont want DHCP to assign addresses on interfaces. We want it > > >> to obtain a prefix from the network (DHCPv6 Prefix Delegation). > > >> Right? > > > > > > Obtain a prefix, yes. But, presumably, the Android node will want to > > > use the prefix in some fashion. > > > > Yes, first, we want our in-house software to form an address out of the > > delegated prefix and assign it on the WiFi interface. > > > > We want to do that without having to root the smartphone. > > > > 64share already does that in some sort. > > > > I dont understand why the 64share INFORMATIONAL RFC does address > > assignment by default, yet if I want to do it with the Prefix Delegation > > Stds Track RFC I have to risk the platform by trying to root it. > > > > > It can either act as a router (which is prohibited by Android without > > > rooting the device) > > > > Transforming a Host into a Router by toggling ipv6_forwarding should not > > need to root the device either. > > > > > or it can act as a host and try to assign addresses from the > > > delegated prefix to an interface (which is also prohibited by Android > > > w/o rooting the device). > > > > Prohibition wrong, must open. > > > > >>> But, Android does not allow apps to assign addresses to regular > > >>> interfaces. > > >> > > >> If so, it seems like a problem of Android. > > > > > > AFAICT, Android tries to protect users from shooting themselves in > > > the foot. > > > > Good initiative, but wrong results. > > > > Even if Android has not offered the means, others have offered more or > > less official means to root, like Huawei. At the end of the day one is > > still capable to shoot in the foot. > > > > Imagine that I had to root a smartphone in order to run IPv6 on it - is > > that acceptable? > > > > Is a user irresponsible if s/he wants to use IPv6? > > > > > Rooting the device is the user's way of saying: "I know what I am > > > doing and accept the consequences of my actions" but it voids any > > > warranties. > > > > I agree. Many people know what they are doing, but its inacceptable for > > someone to claim knowing better without proof. > > > > >> It's hard to accept buying an expensive smartphone with its data > > >> plan yet be forbidden to set an address on it on the command line. > > >> I should be allowed to freely set not one, but as many addresses > > >> that I want. > > > > > > You can try bringing up a terminal window app on the Android and > > > type: "ip -6 addr add 2001:db8::1 dev X" but it will not let you do > > > it. > > > > That should change. > > > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Sep 6 19:22:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F32132D69 for ; Wed, 6 Sep 2017 19:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 9WOxDjK0wxt2 for ; Wed, 6 Sep 2017 19:22:08 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60AAC1252BA for ; Wed, 6 Sep 2017 19:22:08 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id k186so1442139ith.0 for ; Wed, 06 Sep 2017 19:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xBWrRC2VhYkIgkc3ClRpztR5PlHRfngVoXOGbdvO+v0=; b=Fi45nI9pe2xko6E+oqXUCt6fZzbNSjGyfNuqiaS2B+NwYs+Zf6vLYpLgcIWgpiC8qI wPhLjJa9Bc90+qmxdBQTgoH86FczkfXyy7eXuwqJSqX33LHeZA8CO0yR/w4P5gl3ir7p zKfVnoaJju3RlZ38lXjbpqDkyJALO/UMqHGKBPvtYF2u9UrXs4LxuKQXb129DxdXwBKs 5m9u4zB6ejSZ929qSmUEpyde+ARJR0wQijcYwDLPO7evhAhMI8aRa2T52qH05skG4aTn pSBThZXoULeyKvrAGaQdVDPN6QH74lBycR2RJHAn61lpB5qZZQ9S1AsMJc3IJvJ13MLl VsJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xBWrRC2VhYkIgkc3ClRpztR5PlHRfngVoXOGbdvO+v0=; b=iaGFz9w3rXv4eKDNmMLkX0fV2LWxdAhaBP4qQJvKgT/5qnplxSCUXjn1q++RPhcKMO e1rmNzkE0eNd+vKLbhB7KFvTuBwWcxUw0gBNIH308zm72N3hzNaX5fhNl4Mba95yM8pD 8nuckKMdr5InXTlJWIr5Uc2FYCM/YEea5BA+RIBAhzp+FNTnY0xKbkzQgz7BLPhBMbsg qsuHbA3eYsdON1QjvcyhANKEEc9CLR4i74d5qVS6F5KYu9XbE7nI6NcW8fws64QDGQ38 1NTbvJmI3y5caqsfBxpsPf6t7fX+e7xZZwYnvKmq0yC7gRgYJ/iuJJf6ywsWgyYufS1F iUaQ== X-Gm-Message-State: AHPjjUhoZ8IY8xw3r/qclLd9FWOfw0D61quWp4giWIhqNh4bTkF7FSu9 CtE+w70DulbaHoPVcjg9ZQ+z9YEU+pXs X-Google-Smtp-Source: ADKCNb7DRcj9Y8YzYlp+GTq1cTinlRlpSEIfWM/UT3+7mpMdN7NWcvWOp4Rc8h0WJX8/mSSp7a/LCcn/Y4z4t/87YTU= X-Received: by 10.36.74.66 with SMTP id k63mr2213013itb.133.1504750927369; Wed, 06 Sep 2017 19:22:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.11 with HTTP; Wed, 6 Sep 2017 19:22:06 -0700 (PDT) Received: by 10.107.20.11 with HTTP; Wed, 6 Sep 2017 19:22:06 -0700 (PDT) In-Reply-To: <20170907020200.9D9D88476F3E@rock.dv.isc.org> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <5fe9eea416834b199da609065a4ad510@XCH15-06-08.nw.nos.boeing.com> <20170907020200.9D9D88476F3E@rock.dv.isc.org> From: Lorenzo Colitti Date: Thu, 7 Sep 2017 11:22:06 +0900 Message-ID: To: Mark Andrews Cc: "Templin, Fred L" , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a11459bea80f0120558902085" Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 02:22:10 -0000 --001a11459bea80f0120558902085 Content-Type: text/plain; charset="UTF-8" On 7 Sep 2017 11:02, "Mark Andrews" wrote: Can anyone tell me why we bother with reserved ports anymore on single user machines? No one uses r* commands anymore and they are the only thing that really depended on ports being restricted. The only thing else they do is allow the operator to bring up a service after startup without having to worry has some "user" grabbed the port. That seems like a good enough reason to me, particularly if you think of a non-network-savvy user that could potentially be running an app that's misbehaving or even malicious. --001a11459bea80f0120558902085 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 7 Sep 2017 11:02, "Mark Andrews" <marka@isc.org> wrote:
Can anyone t= ell me why we bother with reserved ports anymore on
single user machines?=C2=A0 No one uses r* commands anymore and they are the only thing that really depended on ports being restricted.

The only thing else they do is allow the operator to bring up a
service after startup without having to worry has some "user" gra= bbed
the port.

That seems like a good enough reason to me, particularly if = you think of a non-network-savvy user that could potentially be running an = app that's misbehaving or even malicious.
--001a11459bea80f0120558902085-- From nobody Wed Sep 6 19:40:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B48132D69 for ; Wed, 6 Sep 2017 19:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYomW8L2LaRi for ; Wed, 6 Sep 2017 19:40:26 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573441252BA for ; Wed, 6 Sep 2017 19:40:26 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id ABAB824AE21; Thu, 7 Sep 2017 02:40:14 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 66392160043; Thu, 7 Sep 2017 02:40:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 4EBD5160071; Thu, 7 Sep 2017 02:40:21 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jydXum1VIZqO; Thu, 7 Sep 2017 02:40:21 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 02236160043; Thu, 7 Sep 2017 02:40:21 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id AC15A847791E; Thu, 7 Sep 2017 12:40:18 +1000 (AEST) To: Lorenzo Colitti Cc: "Templin, Fred L" , "v6ops@ietf.org WG" From: Mark Andrews References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <5fe9eea416834b199da609065a4ad510@XCH15-06-08.nw.nos.boeing.com> <20170907020200.9D9D88476F3E@rock.dv.isc.org> In-reply-to: Your message of "Thu, 07 Sep 2017 11:22:06 +0900." Date: Thu, 07 Sep 2017 12:40:18 +1000 Message-Id: <20170907024018.AC15A847791E@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 02:40:28 -0000 In message , Lorenzo Colitti writes: > On 7 Sep 2017 11:02, "Mark Andrews" wrote: > > Can anyone tell me why we bother with reserved ports anymore on > single user machines? No one uses r* commands anymore and they are > the only thing that really depended on ports being restricted. > > The only thing else they do is allow the operator to bring up a > service after startup without having to worry has some "user" grabbed > the port. > > > That seems like a good enough reason to me, particularly if you think of a > non-network-savvy user that could potentially be running an app that's > misbehaving or even malicious. And what servers are there on a phone for them to bring up? DHCP servers when tethered. Anything else? Sshd - No. Telnetd - No. Httpd - No. Httpds - No. A much saner approach would be to have a reserved list for the ACTUAL ports the phone may use not the complete range. That allows apps to provide services that phone doesn't provide itself. You could even disable a port if you want a app to replace the system one and restart the phone. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Sep 6 19:47:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4544F132192 for ; Wed, 6 Sep 2017 19:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 K7BlWuMlUdo3 for ; Wed, 6 Sep 2017 19:47:38 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B27C124319 for ; Wed, 6 Sep 2017 19:47:38 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id p6so1813567itb.1 for ; Wed, 06 Sep 2017 19:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KMi8s7QsbsVhJR09kWH6P35PEgso9sifGPkJHWj74Yw=; b=fb6wi4NLCvrKa/wAAaoQ9+ZIRkAk0UfJsZ+Kvs3BzaWDxJQ2iYbTkyDyskhM0YAowG yFp5h2HjGjvPfq8xyjZgdQimg8WzSt/5KnAAP322ZRjZFFfIUtYWcci5aA9Y1012NKdu wi025Rcmz0vqlh2wj6p52HD0pQMcix4RDXZ6DS5yE9g25gt0EepUnSvwweQo/JU0kZIz b65l2Vz0HtgAIaW/YQFYi9XUmMpGKNkb6uWVjDxDhXaoNQjb+EZCYWQjK1rTR7lY/h0c npM1XO48Q7XfmV+0CLAU0sYV2jeybffcCZW/EMxMr9xndNj3E1RairwzorKnpqafcLnI bqJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KMi8s7QsbsVhJR09kWH6P35PEgso9sifGPkJHWj74Yw=; b=NxMx8Z1h4NLrSNLbn2zoGJU8eG6pUf4P0KhGeDIQdx9b3Il5hnr9sqznKUmJx2zGSs rbEgTnBKiGP1ETLiXaIyjeZOARTGTs/lBSY0nU4ZgS6lOxptIFwf59rr5cKKstDMqJ26 vCdB2pPNaSaNOO8amrM4zb15f43HEi2sy/hb4vdV6QMLaRhnu6bKgQCchVwkGhhqZyWJ 03+COsrMlzBAtHolCJgncwOC/hSj2ed01D5XwOi/de9Q15stqSWz1/Hc5QW+hyN2r2HS DSZYvrc/BWXKMF1fWwt+MUdeQhnNCs+4+qpDAYmgyMdFKM+9gF8RLA4vvB0sg+xRlLEf Eh/A== X-Gm-Message-State: AHPjjUisy1zAAniVbeIs9s+Yqv4QrRDtDC9vRuLkwpas/1iTbHrdapQO +VanaMZ1rfHMUjah51LI7OwW+TvEN6On X-Google-Smtp-Source: ADKCNb4hupPieuwFDiTJY4DeiKNgZ/2U1NwGGoxaQc+PUkUsMCh7wx6B7zWYA2TY7BN2NP6EStPjJddjuH4k1hd+178= X-Received: by 10.36.176.75 with SMTP id b11mr2339508itj.101.1504752457038; Wed, 06 Sep 2017 19:47:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.11 with HTTP; Wed, 6 Sep 2017 19:47:16 -0700 (PDT) In-Reply-To: <20170907024018.AC15A847791E@rock.dv.isc.org> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <5fe9eea416834b199da609065a4ad510@XCH15-06-08.nw.nos.boeing.com> <20170907020200.9D9D88476F3E@rock.dv.isc.org> <20170907024018.AC15A847791E@rock.dv.isc.org> From: Lorenzo Colitti Date: Thu, 7 Sep 2017 11:47:16 +0900 Message-ID: To: Mark Andrews Cc: "Templin, Fred L" , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="089e08231884aded1b0558907b3c" Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 02:47:39 -0000 --089e08231884aded1b0558907b3c Content-Type: text/plain; charset="UTF-8" On Thu, Sep 7, 2017 at 11:40 AM, Mark Andrews wrote: > That allows apps to provide services that phone doesn't provide > itself. You could even disable a port if you want a app to replace > the system one and restart the phone. > I think a better way to do that is to have the app request a port from a privileged process that can do arbitration. --089e08231884aded1b0558907b3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 7, 2017 at 11:40 AM, Mark Andrews <marka@isc.org> wrote:=
That allows apps to provide services tha= t phone doesn't provide
itself.=C2=A0 You could even disable a port if you want a app to replace the system one and restart the phone.

I= think a better way to do that is to have the app request a port from a pri= vileged process that can do arbitration.=C2=A0
--089e08231884aded1b0558907b3c-- From nobody Wed Sep 6 19:55:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F8B132D6D for ; Wed, 6 Sep 2017 19:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OuiZ4XjHcEEu for ; Wed, 6 Sep 2017 19:55:00 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [IPv6:2607:f2f8:abf8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057BC124319 for ; Wed, 6 Sep 2017 19:55:00 -0700 (PDT) Received: from minnie.hitronhub.home (S0106a84e3f81a003.vc.shawcable.net [24.80.126.119]) (authenticated bits=0) by orthanc.ca (8.15.2/8.15.2) with ESMTPSA id v872swOg046449 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Sep 2017 19:54:59 -0700 (PDT) (envelope-from lyndon@orthanc.ca) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Lyndon Nerenberg In-Reply-To: <20170907020200.9D9D88476F3E@rock.dv.isc.org> Date: Wed, 6 Sep 2017 19:54:52 -0700 Cc: "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9ABF4A43-92C7-4FD0-B8CC-0659233F0FB5@orthanc.ca> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <5fe9eea416834b199da609065a4ad510@XCH15-06-08.nw.nos.boeing.com> <20170907020200.9D9D88476F3E@rock.dv.isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 02:55:01 -0000 > On Sep 6, 2017, at 7:02 PM, Mark Andrews wrote: >=20 > Can anyone tell me why we bother with reserved ports anymore on > single user machines? No one uses r* commands anymore and they are > the only thing that really depended on ports being restricted. FTP proxies, maybe? > The only thing else they do is allow the operator to bring up a > service after startup without having to worry has some "user" grabbed > the port. That seems unlikely, these days. Any "system" services will (or at = least should) get launched before any general user access is allowed, so = the system bits will have glommed on to the respective network ports by = then. But the idea that ports <=3D 1024 are "magic" died the day that BSD/OS = was released to the wild blue Internet. --lyndon= From nobody Wed Sep 6 20:43:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2433132D79 for ; Wed, 6 Sep 2017 20:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXKvAq1b8C5v for ; Wed, 6 Sep 2017 20:43:50 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD13127517 for ; Wed, 6 Sep 2017 20:43:49 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1A09FB1; Thu, 7 Sep 2017 05:43:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504755826; bh=Secfan4XAzM4xmfDh0IEIH5/51LkopYIs0tm3FRdBK8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=UihsURyD/qBwoTbKzCawHyY/0Lc6YoAVjHR4QAANGPHnfcUxVf35P0ZXXZxXaqv77 rRQyK00UEvmajGlysH3M7cTdOUfXVcqpJA70oO2GbdrlYRS7g0dQRhcBZz59mBLb3h WLIn9dda2cfl9bb0LTKd5iA+zsoOzCVKUlPBPwuA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 15CEAAF; Thu, 7 Sep 2017 05:43:46 +0200 (CEST) Date: Thu, 7 Sep 2017 05:43:46 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: "v6ops@ietf.org" In-Reply-To: <145ed661-5aa2-9ea6-593e-83ab6763871d@gmail.com> Message-ID: References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <20170706011605.1BEDB7D9F1D6@rock.dv.isc.org> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <92c1bb9c-0d23-6037-e124-dfe74df530f7@gmail.com> <77f8d0a6-a717-7411-61d5-130c1246477d@gmail.com> <145ed661-5aa2-9ea6-593e-83ab6763871d@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 03:43:57 -0000 On Wed, 6 Sep 2017, Alexandre Petrescu wrote: > That may mean new hardware. No, it most likely means updated software in the baseband module. This however is also not something YOU can fix, it has to be fixed by whoever bought it and incorporated it into its device (which you then bought). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Sep 6 23:45:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E341321F5 for ; Wed, 6 Sep 2017 23:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDnGNPxfgoG2 for ; Wed, 6 Sep 2017 23:45:23 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47B7C1321BB for ; Wed, 6 Sep 2017 23:45:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v876jKKd026860; Thu, 7 Sep 2017 08:45:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E49772026C3; Thu, 7 Sep 2017 08:45:20 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DBEE9202108; Thu, 7 Sep 2017 08:45:20 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v876jK5J026842; Thu, 7 Sep 2017 08:45:20 +0200 To: Mikael Abrahamsson Cc: "v6ops@ietf.org" References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <2c145a79-ad0a-59fd-0300-f427d2fbd6f6@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <92c1bb9c-0d23-6037-e124-dfe74df530f7@gmail.com> <77f8d0a6-a717-7411-61d5-130c1246477d@gmail.com> <145ed661-5aa2-9ea6-593e-83ab6763871d@gmail.com> From: Alexandre Petrescu Message-ID: <2f27efa3-dd4a-535d-dc2e-34f42d63d519@gmail.com> Date: Thu, 7 Sep 2017 08:45:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 06:45:25 -0000 Le 07/09/2017 à 05:43, Mikael Abrahamsson a écrit : > On Wed, 6 Sep 2017, Alexandre Petrescu wrote: > >> That may mean new hardware. > > No, it most likely means updated software in the baseband module. YEs in principle, but no in some case. Some modem manufacturer does not want to update software on baseband module that manufacturer considers to be too old. That modem manufacturer recommends to the bigger system integrator to move first to the new 'baseband' module before updating the software to support DHCPv6. (it is the case with some support at Qualcomm considering MDM8215 'baseband' being too old - they dont support it anymore despite being present in some devices; they recommend replacing old with a new 'baseband' MDM9207 including a new version of QDSP6 modem; without that some Qualcomm support will not allow some Sierra engineer to update the software of the old modem QDSP6 - simply put they dont provide the source code of the old modem to some customer). (maybe I dont understand the term 'baseband' term very well, but it is sometimes used to designate just the "modem" running miniVM, other times to designate the processor that runs the tcpdump; in this second interpretation it includes both an ARM Cortex and the 'modem'; it's the 'modem' part of the 'baseband' that poses problems, not the ARM part of the 'baseband' processor.) > This however is also not something YOU can fix, it has to be fixed by > whoever bought it and incorporated it into its device (which you then > bought). I really would like to, but the end result of a case described above is that I am forced into getting new hardware if I want that 546-port-blocked problem fixed in the modem thingie, and thus DHCPv6 Prefix Delegation to run. Users of old devices wont be able to use DHCPv6 PD. When one thinks about 'old' modems one has to have in mind smartphones but also cars. There are still many cars in the market that have 2011-year Sierra modules and these wont ever be able to connect to IPv6 Internet. This is not a happy situation to be in. Alex > From nobody Thu Sep 7 00:53:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D67132EC4 for ; Thu, 7 Sep 2017 00:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmqmOlrTY69Y for ; Thu, 7 Sep 2017 00:53:39 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0AC0132EBC for ; Thu, 7 Sep 2017 00:53:38 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 14E5CB1; Thu, 7 Sep 2017 09:53:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504770816; bh=KIr+5yVmCNbRSh1U5P4ZpY0MnaeZF7W1zbw9cSFmD5E=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=XEtbfgsfz7TucThWb2ZmZDxZOHWnFTcS9y/HOfaiuIHOnx6GgEv8eyktTlxR3e9Pd FRJVB17xSSdqTX4qgBR0tp30EwgnBz9G7BYH3jDv5xJhQy7XYUtK1xBNy2v2eE83hj ba/HjvP9oHDF9Q/WSxWTu106EGDZgvE1gDxRm4EY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 12011AF; Thu, 7 Sep 2017 09:53:36 +0200 (CEST) Date: Thu, 7 Sep 2017 09:53:36 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: "v6ops@ietf.org" In-Reply-To: <2f27efa3-dd4a-535d-dc2e-34f42d63d519@gmail.com> Message-ID: References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <9948cb75-6c11-9071-697f-a79702472132@gmail.com> <5c78ea63-6764-13a2-ddd4-ba7956694f4d@gmail.com> <9ea82cc815424d038978f46f94fbf5b3@XCH15-06-08.nw.nos.boeing.com> <0b5919f6-a146-2086-055b-7ac16787556a@gmail.com> <7367f3ec99ae42c2b425b38d80ca2abd@XCH15-06-08.nw.nos.boeing.com> <7bd0ceb3-b17e-3448-d5ac-bf98dc1e6db4@gmail.com> <92c1bb9c-0d23-6037-e124-dfe74df530f7@gmail.com> <77f8d0a6-a717-7411-61d5-130c1246477d@gmail.com> <145ed661-5aa2-9ea6-593e-83ab6763871d@gmail.com> <2f27efa3-dd4a-535d-dc2e-34f42d63d519@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Android must allow root access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 07:53:42 -0000 On Thu, 7 Sep 2017, Alexandre Petrescu wrote: > This is not a happy situation to be in. Sure. But I don't see any standards-action here. You can write operational document how to get around the problem of hardware/software not implementing support for existing standards (which typically means tunneling). But I doubt you're going to see anyone interested in standardizing unicast DHCPv6-in-3GPP with out-of-band address for DHCP communication. That seems more like a 3GPP profile than anything else. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 7 03:53:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A9A132EE4 for ; Thu, 7 Sep 2017 03:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ujAIbDQTkaB for ; Thu, 7 Sep 2017 03:53:43 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C275126D0C for ; Thu, 7 Sep 2017 03:53:43 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id F203FB1; Thu, 7 Sep 2017 12:53:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504781620; bh=EpVjrpaobY/XcPEwd0T+5OCK4cO1eWcAefmPHGtFNTQ=; h=Date:From:To:Subject:From; b=bE8vjtE3MGucLhxJk7gF9ft8g9FcUGSaSDYRp0xcLl6it/1O97uJEIjtDtGjsSSeY TVE6LiqMLEE6Q9CqtwDYsy+Z3Vd7fnTV/CNzIatrWojj3oFAowD3Ih9iZa24V2IrUT d6dKvUVJAitqEV2Ie6cKDT2CHMI/oAki3AL3J0/c= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DAE22AF for ; Thu, 7 Sep 2017 12:53:40 +0200 (CEST) Date: Thu, 7 Sep 2017 12:53:40 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [v6ops] Microsoft Win10 source address selection woes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 10:53:45 -0000 I am finding interesting behavior with my fully updated Win10. It seems to prefer "public" address over temporary, which doesn't seem to follow RFC6724. These addresses are all in the same /64, I am running with A=1. (obfuscated some fields) >netsh int ipv6 sho addr Interface 6: Ethernet Addr Type DAD State Valid Life Pref. Life Address --------- ----------- ---------- ---------- ------------------------ Temporary Deprecated 5d2h5m1s 0s PREFIX:8403:XYZ:f15e:d720 Temporary Preferred 6d2h3m27s 2h1m57s PREFIX:a910:XYZ:ef8e:3484 Public Preferred 29d23h57m11s 6d23h57m11s PREFIX:c16d:XYZ:XYZ:a45c Other Preferred infinite infinite fe80::c16d:fb79:XYZ:XYZ%6 Now, when I use web browsers (firefox/chrome/edge) they all use the public address for outgoing connections. This is not what I expected (and not what I see on my MacOS machine). RFC6724 rule 7 seems it should indicate that temporary address should be chosen. However, RFC3484 says public addresses should be chosen over temporary ones, unless specific API calls are made. Does this mean Windows 10 doesn't implement RFC6724 but instead implements 3484? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 7 04:09:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6154A1329AD for ; Thu, 7 Sep 2017 04:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 mbK34feHXzRz for ; Thu, 7 Sep 2017 04:09:07 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F311132D67 for ; Thu, 7 Sep 2017 04:09:07 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id r85so14228025ywg.1 for ; Thu, 07 Sep 2017 04:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DedM/ezweawDT0ZHIHvGw5sqtb+DsqSTnY+pif+8fJ0=; b=NgpOonvAOBGbfKuNPjHGbuJBPLMiSVggw5bFrJ+b55eJ1AeKffMERBpFqOFQEejuhS ATvUUO4AWa0keiT/xgIRmD+S/czQovR8EDAowiTFMpEh5Y6L4eDZNDlZEVa4nfan/Zti EAr2eOsQjExKmoaA+dD4dNmo5G2kVTTshaKU+IYcNvosHPcPlNkSGr26P60k6VyX6CNa JLaj88NLw4cXdvb0ynDNjo+QILN06RzPKbp2XLtyYrfIP9Yz0vSMBFYBh5dL7RbubPIH +QWbRh95FVUq4TAnSRLJRBChAwmB+BpLxg36L9DR4OtOqS4bLRvdE0NtABt+YpIzNJww OK9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DedM/ezweawDT0ZHIHvGw5sqtb+DsqSTnY+pif+8fJ0=; b=e7BPa9CbevwEVnc2SBSdOkA9SAy6d7ae/fWmcKqpxf6RE+tJUSjxMCPm/y03Iz5N6j bfjkZvKyf6z2CajwRrvvp2bJmSenRj7Vjj8rA+Zg4uC1mJH3YGhJL/eGHFJYuSOSZQxy EaoJni1/UPctFuskRxmnoIU8KrI9RFDsHzeejDLJswT9zosIoUjM9NOYbMxzTd7nyjqu wG5oV/qQhqU+skA1c+JHhaerDiAfOvGLacl3Z3tNSq290AeJiHsg6zO2pv2uD54zqSoz xITn8o+iAoj+NQ6Bq7wQL6KomvdOhP6FCuXkJl0onkLhzM0326OqEdYOYqbNLn0vsKk8 B3rA== X-Gm-Message-State: AHPjjUhAog20SUxuKIt/aW2VJfAitPKc2ek3hFnbK53WIRTcrSpHSD8P juJon6flxruFl4tsD6WiHZjm7GG8wkDkt6pP4Q== X-Google-Smtp-Source: ADKCNb7AM/dnwfZRxo+Y433CKdy8rrTQJ91rISl2Kejo4DgcWx+iIUHupacMeD7D55fJkPjQ7a8yeWDP994HzrK0SEo= X-Received: by 10.37.126.4 with SMTP id z4mr1772945ybc.136.1504782546437; Thu, 07 Sep 2017 04:09:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.52.78 with HTTP; Thu, 7 Sep 2017 04:08:45 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Thu, 7 Sep 2017 20:08:45 +0900 Message-ID: To: Mikael Abrahamsson Cc: "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114e2f862f01300558977d44" Archived-At: Subject: Re: [v6ops] Microsoft Win10 source address selection woes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 11:09:09 -0000 --001a114e2f862f01300558977d44 Content-Type: text/plain; charset="UTF-8" Is it expected that apps should make use of some https://tools.ietf.org/html/rfc5014 API? On 7 September 2017 at 19:53, Mikael Abrahamsson wrote: > > I am finding interesting behavior with my fully updated Win10. It seems to > prefer "public" address over temporary, which doesn't seem to follow > RFC6724. These addresses are all in the same /64, I am running with A=1. > > (obfuscated some fields) > >> netsh int ipv6 sho addr > > > Interface 6: Ethernet > > Addr Type DAD State Valid Life Pref. Life Address > --------- ----------- ---------- ---------- ------------------------ > Temporary Deprecated 5d2h5m1s 0s PREFIX:8403:XYZ:f15e:d720 > Temporary Preferred 6d2h3m27s 2h1m57s PREFIX:a910:XYZ:ef8e:3484 > Public Preferred 29d23h57m11s 6d23h57m11s PREFIX:c16d:XYZ:XYZ:a45c > Other Preferred infinite infinite fe80::c16d:fb79:XYZ:XYZ%6 > > Now, when I use web browsers (firefox/chrome/edge) they all use the public > address for outgoing connections. This is not what I expected (and not what > I see on my MacOS machine). > > RFC6724 rule 7 seems it should indicate that temporary address should be > chosen. However, RFC3484 says public addresses should be chosen over > temporary ones, unless specific API calls are made. > > Does this mean Windows 10 doesn't implement RFC6724 but instead implements > 3484? > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --001a114e2f862f01300558977d44 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgpBlRIJH1sSkMUu8zAqwx+AUuy1pakxhC 5mji89cP4ZwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTA3 MTEwOTA3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAKCbw6IWL80H4pQoqXOxpyMkqolfxq6dO91apLaWtNwFKjWmRXcY NdCzyVrq/TYOM31WTCPfOgDdsH/xFfUViisb+Rlwcgp4kyHqFyn8j9i1Oz0sMrd8OOIU/3DgwJ+G sWmoPv9r0NUBvokUZXleMYgn7MREu6uyWub+yYzGwo3fOzl4xxABD/HqnkLu1qt/JP1fmLEKw13+ 4md2Pr7mqkV/t2I9/tgIASwOym59z0ZlJ7yESU79SOougzB55zOKDs3vJKkZVYHq30eKHfptvn3G AY/lqptAcX2HS1NB3S7uYPqPeZDAhJ9JUVStbh4NyK3zx9zIoIHgQwViSPtTIos= --001a114e2f862f01300558977d44-- From nobody Thu Sep 7 04:10:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D7A132EE7 for ; Thu, 7 Sep 2017 04:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGn8bd-Q2aeJ for ; Thu, 7 Sep 2017 04:10:51 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8439C1329AD for ; Thu, 7 Sep 2017 04:10:51 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2291AB1; Thu, 7 Sep 2017 13:10:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504782650; bh=2BqhNM3F89g+IpuTWaNQCYVWnrK/2tCEochUOSp8Pdo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=AmDVC8pfXDSdmmsSswXOPSJBUHAuekYTAx4mOuYD8H2W+ZdyF6yRTPDST2PHjStg4 RsPHUv/s9VsctKEku61xSwa5fUn/tGsiQJIDERekbLDpzrD5lMwEZqINPA3vSUEY9R cIqeRbatSU6TmiqSDxNEBi0lPARDVjr7aMS3kHQ4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1F361AF; Thu, 7 Sep 2017 13:10:50 +0200 (CEST) Date: Thu, 7 Sep 2017 13:10:50 +0200 (CEST) From: Mikael Abrahamsson To: Erik Kline cc: "v6ops@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Microsoft Win10 source address selection woes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 11:10:53 -0000 On Thu, 7 Sep 2017, Erik Kline wrote: > Is it expected that apps should make use of some > https://tools.ietf.org/html/rfc5014 API? Another twist is that the person who initially brought this to my attention now said that if his application sends UDP packets, it will by default use the temp address. Very confusing. Different APIs, different defaults? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 7 10:35:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6A713219C for ; Thu, 7 Sep 2017 10:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3m0E8ciMgBn for ; Thu, 7 Sep 2017 10:35:09 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E801D1204DA for ; Thu, 7 Sep 2017 10:35:08 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2F081B1; Thu, 7 Sep 2017 19:35:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1504805706; bh=2M0hG3g3dJ9+qOcK6vpHY0AVZmur/xH75MvSUHZou0I=; h=Date:From:To:Subject:In-Reply-To:References:From; b=pOPWnae8WdhIe7yGvwi219NffVFCDkejmf/MS09urikriSOjYKIN4NXmDJOIEUb9Y 9T11l2dR1AweZIys3cs0sxF41AWKRxn23gCFdhcWiUS+tS/sHx5n4pYV0rzuldArqW 7AMXydfQRFW4p5aqPI4hMixAZCSEUmc5g9vvCZlU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2B5E1AF for ; Thu, 7 Sep 2017 19:35:06 +0200 (CEST) Date: Thu, 7 Sep 2017 19:35:06 +0200 (CEST) From: Mikael Abrahamsson To: v6ops@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] Microsoft Win10 source address selection woes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 17:35:11 -0000 On Thu, 7 Sep 2017, Mikael Abrahamsson wrote: > Does this mean Windows 10 doesn't implement RFC6724 but instead > implements 3484? I have now done more tests. It seems this problem only occurs when windows has two temporary addresses, one of which is deprecated and has 0 preferred time. So as long as it has single temp address, the temp address is used for outgoing browser connections. When it has two temp addresses, it starts using the public address. People at Microsoft has been notified about my findings. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Sep 8 03:57:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256081326F3 for ; Fri, 8 Sep 2017 03:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 lgMi1qK1GxhF for ; Fri, 8 Sep 2017 03:57:20 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA1D13236D for ; Fri, 8 Sep 2017 03:57:20 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id c195so1127660itb.1 for ; Fri, 08 Sep 2017 03:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K645Cz10O81Kin5iSza7cBeZKkvAVyXn0DnhQQHRxOU=; b=CQRgihi2/PmbP+ZEGYv4DxzcnJ0JxQKkC61/XrY+sBzcaq5omW5gBmPMkLgnPQ8JS4 LQNRE6QTEsnEOhYrYUtf64LSD6Sd24WIwsev2gHRGh/APGZfRS8sCjDE9EFuxjuLf2iM +Xufi27cAeoVngHapcC8EOriK9BKPQbPLMC48cVz5SZAX8+rd1ZO2eGka//p/LX3x+ue 7jJ15dck16AWn2OGxLSEhhVIu/nUxQbX9fSejc3+QJ8fPY/FvaMASjPPx3MbE7GpzpUZ fC0rYK1HWvlZvCe4lAcJcsXyHvKVtp6IvQd4VapYn6BnEblPt+59qSeTUqQnjTERWpxb QKsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K645Cz10O81Kin5iSza7cBeZKkvAVyXn0DnhQQHRxOU=; b=cgrwX10pFr4d5BWHdEZpCncxn/sqIbYumB1gmhPikdkvTBioUgGpgULXcRfpGHs9my NIXwXwn3FfaO/LMxxHWuNOab54oa6aXPNkIfdw5k7ByEaUzarNyDaGrzNcFDw/WYs5GL sQAZ/qy95sWwORSlny3T2H6U9aDvIjNMPP78Y84+4eJNnp951/iocKJ9YBRMB2dwebT8 f9KwWH+v+fRBvRfHER5wXXRF294hf+MCLhrR/izDp149GSOCZhMjGjRP7JufeQ+DuccC 12UFaTpoaTRHkF4uSd0vie5aFRytB10Tyxb1NWlQDFHhXmdc64k/KQMw2zWG2jlc32G0 YpfA== X-Gm-Message-State: AHPjjUg7Q0Rm5sIKOzkuLy1bNUBv3UU9UVZ0Xe0R3UcKy9r08Vr7B0UC A7d/uiWqXBGXswW9RmfyH11oiXjXbU+oeEs= X-Google-Smtp-Source: AOwi7QAdfH6gR47j4SQEqqr95Bc4uduu2wblumcB1dvslP1OIP8cDozPh13dOBSICE6DL/eK1BFRXevVPnlA3F6eMKs= X-Received: by 10.36.200.132 with SMTP id w126mr357644itf.101.1504868239359; Fri, 08 Sep 2017 03:57:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.11 with HTTP; Fri, 8 Sep 2017 03:57:18 -0700 (PDT) Received: by 10.107.20.11 with HTTP; Fri, 8 Sep 2017 03:57:18 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Fri, 8 Sep 2017 19:57:18 +0900 Message-ID: To: Mikael Abrahamsson Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c060256d7dc870558ab70d3" Archived-At: Subject: Re: [v6ops] Microsoft Win10 source address selection woes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 10:57:22 -0000 --94eb2c060256d7dc870558ab70d3 Content-Type: text/plain; charset="UTF-8" On Sep 8, 2017 02:35, "Mikael Abrahamsson" wrote: When it has two temp addresses, it starts using the public address. That's amusing. Perhaps the OS thinks privacy is good, but only if you don't have too much of it ;-) --94eb2c060256d7dc870558ab70d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sep 8, 2017 02:35, "Mikael Abrahamsson" <swmike@swm.pp.se> wrote:
When it has two temp addresses, it starts using the public address.

Th= at's amusing. Perhaps the OS thinks privacy is good, but only if you do= n't have too much of it ;-)
--94eb2c060256d7dc870558ab70d3-- From nobody Fri Sep 8 07:53:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EC5132EE2 for ; Fri, 8 Sep 2017 07:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LQ_FB3puP5m for ; Fri, 8 Sep 2017 07:53:03 -0700 (PDT) Received: from atl4mhob20.registeredsite.com (atl4mhob20.registeredsite.com [209.17.115.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EFF132D79 for ; Fri, 8 Sep 2017 07:53:03 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob20.registeredsite.com (8.14.4/8.14.4) with ESMTP id v88Er01i034484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Sep 2017 10:53:00 -0400 Received: (qmail 19330 invoked by uid 0); 8 Sep 2017 14:53:00 -0000 X-TCPREMOTEIP: 72.221.14.181 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.181) by 0 with ESMTPA; 8 Sep 2017 14:52:58 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 08 Sep 2017 10:52:54 -0400 From: Lee Howard To: Message-ID: Thread-Topic: LAN behavior when there's no IPv4 Internet access Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3587712778_8248487" Archived-At: Subject: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 14:53:05 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3587712778_8248487 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Thank you all for the discussion of covering the gaps identified in draft-ietf-sunset4-gapanalysis. In particular, I think many of the gaps are resolved with the revision of rfc6555 Happy Eyeballs. I wonder, though, what should be the expected behavior of a stub network when there is no IPv4 Internet access? My current thinking is that the Internet gateway (IGD, Customer Premise Router CPR, home gateway, etc.): * May still route between multiple segments of the site network, and therefore should be the IPv4 default gateway for those segments. * Only knows whether native IPv4 is available. It may not be aware of NAT64 or other transition mechanisms where it=E2=80=99s not involved. So, islands of IPv4 are probable, and that=E2=80=99s okay. Do we need a document responding to gapanalysis that says so? Do we need to work out how to know when it=E2=80=99s possible to disable IPv4 completely in a heterogenous unmanaged site network? Or do we need to sit on these problems for several more years and wait for IPv4 to become unused in many networks before we can deal with the gaps? For reference, here=E2=80=99s the relevant section of sunset4-gapanalysis: 3.1. Indicating that IPv4 connectivity is unavailable PROBLEM 1: When an IPv4 node boots and requests an IPv4 address (e.g., using DHCP), it typically interprets the absence of a response as a failure condition even when it is not. PROBLEM 2: Home router devices often identify themselves as default routers in DHCP responses that they send to requests coming from the LAN, even in the absence of IPv4 connectivity on the WAN. 3.2. Disabling IPv4 in the LAN PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- configure IPv4 addresses [RFC3927] and enable various protocols over IPv4 such as mDNS [RFC6762] and LLMNR [RFC4795]. This can be undesirable for operational or security reasons, since in the absence of IPv4, no monitoring or logging of IPv4 will be in place. PROBLEM 4: IPv4 can be completely disabled on a link by filtering it on the L2 switching device. However, this may not be possible in all cases or may be too complex to deploy. For example, an ISP is often not able to control the L2 switching device in the subscriber home network. PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP for everything", as described in Section 2.6.2 of [RFC3927]. Applications running on such a host connected to an IPv6-only network will believe that IPv4 connectivity is available, resulting in various bad or sub-optimal behavior patterns. See [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for further analysis. Some of these problems were described in [RFC2563], which standardized a DHCP option to disable IPv4 address auto- configuration. However, using this option requires running an IPv4 DHCP server, which is contrary to the goal of IPv4 sunsetting. Thanks for discussion, Lee --B_3587712778_8248487 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Thank you all for the di= scussion of covering the gaps identified in draft-ietf-sunset4-gapanalysis. = In particular, I think many of the gaps are resolved with the revision of rf= c6555 Happy Eyeballs.

I wonder, though, what should= be the expected behavior of a stub network when there is no IPv4 Internet a= ccess?

My current thinking is that the Internet gat= eway (IGD, Customer Premise Router CPR, home gateway, etc.):
  • Ma= y still route between multiple segments of the site network, and therefore s= hould be the IPv4 default gateway for those segments. 
  • Only kno= ws whether native IPv4 is available. It may not be aware of NAT64 or other t= ransition mechanisms where it’s not involved.
So, island= s of IPv4 are probable, and that’s okay. Do we need a document respond= ing to gapanalysis that says so? Do we need to work out how to know when it&= #8217;s possible to disable IPv4 completely in a heterogenous unmanaged site= network? Or do we need to sit on these problems for several more years and = wait for IPv4 to become unused in many networks before we can deal with the = gaps?

For reference, here’s the relevant sect= ion of sunset4-gapanalysis:
3.1.  Indic=
ating that IPv4 connectivity is unavailable

   PROBLEM 1:  When an IPv4 node boots and requests an IPv4 address
               (e.g., using DHCP), it typically interprets the absence
               of a response as a failure condition even when it is not.

   PROBLEM 2:  Home router devices often identify themselves as default
               routers in DHCP responses that they send to requests
               coming from the LAN, even in the absence of IPv4
               connectivity on the WAN.

3.2.  Disabling IPv4 in the LAN

   PROBLEM 3:  IPv4-enabled hosts inside an IPv6-only LAN can auto-
               configure IPv4 addresses [RFC3927] and enable various
               protocols over IPv4 such as mDNS [RFC6762] and LLMNR
               [RFC4795].  This can be undesirable for operational or
               security reasons, since in the absence of IPv4, no
               monitoring or logging of IPv4 will be in place.

   PROBLEM 4:  IPv4 can be completely disabled on a link by filtering it
               on the L2 switching device.  However, this may not be
               possible in all cases or may be too complex to deploy.
               For example, an ISP is often not able to control the L2
               switching device in the subscriber home network.

   PROBLEM 5:  A host with only Link-Local IPv4 addresses will "ARP for
               everything", as described in Section 2.6.2 of [RFC3927].
               Applications running on such a host connected to an
               IPv6-only network will believe that IPv4 connectivity is
               available, resulting in various bad or sub-optimal
               behavior patterns.  See
               [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for further
               analysis.

   Some of these problems were described in [RFC2563], which
   standardized a DHCP option to disable IPv4 address auto-
   configuration.  However, using this option requires running an IPv4
   DHCP server, which is contrary to the goal of IPv4 sunsetting.

Thanks for discussion,
Lee

--B_3587712778_8248487-- From nobody Fri Sep 8 09:56:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF9E132710 for ; Fri, 8 Sep 2017 09:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMN6Vta5d54B for ; Fri, 8 Sep 2017 09:56:23 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB29132705 for ; Fri, 8 Sep 2017 09:56:22 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id i189so8317097wmf.1 for ; Fri, 08 Sep 2017 09:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UoOaqBFexMQ1iwrgq/MnERszuaRoaHR6SQea8Zbmua0=; b=hyvscKi5TukjJsIUNOyMJNiwh11yNq2Dtbu3EZNoeL73obKVr8h57ffpkLok7P8fmR tvVHS7XRMNRWEmxH/EB3CCI/EYB9JxElh3pF5mM9IofVoho65m99Ka/0tx6LIA3zOOE3 UjWT5uYUSm6phNYrWkfOznQWXZKXZFpyd2oJF+TdDycSR4/QMq+57y/7Lq9AY56MMTXk H7dEYde77PKHwDfn6sHNrqsDcpcfnA6mPBU0ZUSm7opmSF3gQyRt7zl/cWfOWDW1N4Sj kRenSlibq1zXifdU0Dr9cdGlUz7hu9+E49nwaD9RAOKRTJJzsi7kXh6+ruWgzhjDMYPm Zwhw== 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=UoOaqBFexMQ1iwrgq/MnERszuaRoaHR6SQea8Zbmua0=; b=qCZnkzkdWJ2J9Ohb9fAkJL1lefd4q1ymLnGRNASdH7klwtaLCQDxndy3d5zX9wh6tH jCJhXiCQyAgtqjQW95voWre1gfjlzIGwzXretb45qmrZ2rQfRbWqYkz/AJXoLFEtzhFV MUwet6TPp+YhUGg0WiPhfYo1QBQNTJmDQ8f8mvQkohXijAolHY1MGEeKEXzkoksjf8iO uFcCUM9vV+FcYzCxdnTyYSFmf6hD5s1JZUr9vH/bnB/YSmbY4xLJc65h6hrqb36sRRJA 3KHU8bb74q9SOhMHPi8dgH1lf0XB4YX6tqsARR2OP9PzB/ltYZ99rEmiBwL/1z3PfjaM uXsA== X-Gm-Message-State: AHPjjUisHxZc55er7pt3r7KDNY3gwRG6k3sIUVlZ4FUSKQqkQKUji58B 4VUJgy0XQcDosxv/yld+/woihFkG X-Google-Smtp-Source: ADKCNb4pULK9Rk5KGcmJS3nOwpuqN36uPru8RRD7+/baeW6otbFQH/g3OPP495o9ZfloZDVWNi/mgA== X-Received: by 10.28.23.5 with SMTP id 5mr2127227wmx.62.1504889781229; Fri, 08 Sep 2017 09:56:21 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:7064:f9a7:6905:c94f? ([2601:646:c005:a10:7064:f9a7:6905:c94f]) by smtp.gmail.com with ESMTPSA id z51sm3026933wrb.22.2017.09.08.09.56.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Sep 2017 09:56:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: Date: Fri, 8 Sep 2017 09:56:17 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Lee Howard X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 16:56:25 -0000 Dumb question: is it necessary, when there is a network in which IPv4 is = disabled, to say that it is disabled? What does that accomplish? =46rom my perspective, if the DHCP server is disabled from an IPv4 = perspective, it will stop responding to requests for an IPv4 address. = Hosts can then build IPv4 link-local addresses if they choose, and = communicate using them, but IPv4 will have no network services. Either = IPv6 works or the network doesn't work for IPv4 traffic. My thought is that we don't have a way to say "IPv6 is disabled here"; = either IPv6 works or it doesn't. I don't quite see what is really = different when the shoe is on the other foot. > On Sep 8, 2017, at 7:52 AM, Lee Howard wrote: >=20 > Thank you all for the discussion of covering the gaps identified in = draft-ietf-sunset4-gapanalysis. In particular, I think many of the gaps = are resolved with the revision of rfc6555 Happy Eyeballs. >=20 > I wonder, though, what should be the expected behavior of a stub = network when there is no IPv4 Internet access? >=20 > My current thinking is that the Internet gateway (IGD, Customer = Premise Router CPR, home gateway, etc.): > =E2=80=A2 May still route between multiple segments of the site = network, and therefore should be the IPv4 default gateway for those = segments.=20 > =E2=80=A2 Only knows whether native IPv4 is available. It may = not be aware of NAT64 or other transition mechanisms where it=E2=80=99s = not involved. > So, islands of IPv4 are probable, and that=E2=80=99s okay. Do we need = a document responding to gapanalysis that says so? Do we need to work = out how to know when it=E2=80=99s possible to disable IPv4 completely in = a heterogenous unmanaged site network? Or do we need to sit on these = problems for several more years and wait for IPv4 to become unused in = many networks before we can deal with the gaps? >=20 > For reference, here=E2=80=99s the relevant section of = sunset4-gapanalysis: > 3.1. Indicating that IPv4 connectivity is unavailable >=20 > PROBLEM 1: When an IPv4 node boots and requests an IPv4 address > (e.g., using DHCP), it typically interprets the absence > of a response as a failure condition even when it is = not. >=20 > PROBLEM 2: Home router devices often identify themselves as = default > routers in DHCP responses that they send to requests > coming from the LAN, even in the absence of IPv4 > connectivity on the WAN. >=20 > 3.2. Disabling IPv4 in the LAN >=20 > PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- > configure IPv4 addresses [RFC3927] and enable various > protocols over IPv4 such as mDNS [RFC6762] and LLMNR > [RFC4795]. This can be undesirable for operational or > security reasons, since in the absence of IPv4, no > monitoring or logging of IPv4 will be in place. >=20 > PROBLEM 4: IPv4 can be completely disabled on a link by filtering = it > on the L2 switching device. However, this may not be > possible in all cases or may be too complex to deploy. > For example, an ISP is often not able to control the L2 > switching device in the subscriber home network. >=20 > PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP = for > everything", as described in Section 2.6.2 of = [RFC3927]. > Applications running on such a host connected to an > IPv6-only network will believe that IPv4 connectivity = is > available, resulting in various bad or sub-optimal > behavior patterns. See > [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for = further > analysis. >=20 > Some of these problems were described in [RFC2563], which > standardized a DHCP option to disable IPv4 address auto- > configuration. However, using this option requires running an IPv4 > DHCP server, which is contrary to the goal of IPv4 sunsetting. >=20 >=20 > Thanks for discussion, > Lee >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Sep 8 11:03:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F4199132962 for ; Fri, 8 Sep 2017 11:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFhlECoA_ov1 for ; Fri, 8 Sep 2017 11:03:15 -0700 (PDT) Received: from atl4mhob17.registeredsite.com (atl4mhob17.registeredsite.com [209.17.115.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA9713292B for ; Fri, 8 Sep 2017 11:03:14 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob17.registeredsite.com (8.14.4/8.14.4) with ESMTP id v88I3Bj8035886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 8 Sep 2017 14:03:11 -0400 Received: (qmail 21990 invoked by uid 0); 8 Sep 2017 18:03:11 -0000 X-TCPREMOTEIP: 72.221.14.181 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.181) by 0 with ESMTPA; 8 Sep 2017 18:03:08 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 08 Sep 2017 14:03:02 -0400 From: Lee Howard To: Fred Baker CC: Message-ID: Thread-Topic: [v6ops] LAN behavior when there's no IPv4 Internet access References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 18:03:17 -0000 On 9/8/17, 12:56 PM, "Fred Baker" wrote: >Dumb question: is it necessary, when there is a network in which IPv4 is >disabled, to say that it is disabled? What does that accomplish? Debatable, but some use cases are implied by the problems documented in the draft. > >From my perspective, if the DHCP server is disabled from an IPv4 >perspective, it will stop responding to requests for an IPv4 address. >Hosts can then build IPv4 link-local addresses if they choose, and >communicate using them, but IPv4 will have no network services. Either >IPv6 works or the network doesn't work for IPv4 traffic. Should a home gateway that doesn=E2=80=99t have an IPv4 WAN address still act as = a DHCP server? Some clients interpret a lack of DHCP response as an indication that the network is down, even if they have IPv6. Or so it is alleged; I have not tested it myself. How often does a DHCP client send Discover messages? How much ARP traffic is on a network? Do we need a way to mute this traffic, or do we just have to wait until device manufacturers decide to stop including IPv4 in their devices? > >My thought is that we don't have a way to say "IPv6 is disabled here"; >either IPv6 works or it doesn't. I don't quite see what is really >different when the shoe is on the other foot. Assumptions (and therefore defaults) change depending on where you start. Most people still assume IPv4, even if they also assume IPv6. Lee > >> On Sep 8, 2017, at 7:52 AM, Lee Howard wrote: >>=20 >> Thank you all for the discussion of covering the gaps identified in >>draft-ietf-sunset4-gapanalysis. In particular, I think many of the gaps >>are resolved with the revision of rfc6555 Happy Eyeballs. >>=20 >> I wonder, though, what should be the expected behavior of a stub >>network when there is no IPv4 Internet access? >>=20 >> My current thinking is that the Internet gateway (IGD, Customer Premise >>Router CPR, home gateway, etc.): >> =E2=80=A2 May still route between multiple segments of the site network, and >>therefore should be the IPv4 default gateway for those segments. >> =E2=80=A2 Only knows whether native IPv4 is available. It may not be aware of >>NAT64 or other transition mechanisms where it=E2=80=99s not involved. >> So, islands of IPv4 are probable, and that=E2=80=99s okay. Do we need a >>document responding to gapanalysis that says so? Do we need to work out >>how to know when it=E2=80=99s possible to disable IPv4 completely in a >>heterogenous unmanaged site network? Or do we need to sit on these >>problems for several more years and wait for IPv4 to become unused in >>many networks before we can deal with the gaps? >>=20 >> For reference, here=E2=80=99s the relevant section of sunset4-gapanalysis: >> 3.1. Indicating that IPv4 connectivity is unavailable >>=20 >> PROBLEM 1: When an IPv4 node boots and requests an IPv4 address >> (e.g., using DHCP), it typically interprets the absence >> of a response as a failure condition even when it is not. >>=20 >> PROBLEM 2: Home router devices often identify themselves as default >> routers in DHCP responses that they send to requests >> coming from the LAN, even in the absence of IPv4 >> connectivity on the WAN. >>=20 >> 3.2. Disabling IPv4 in the LAN >>=20 >> PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- >> configure IPv4 addresses [RFC3927] and enable various >> protocols over IPv4 such as mDNS [RFC6762] and LLMNR >> [RFC4795]. This can be undesirable for operational or >> security reasons, since in the absence of IPv4, no >> monitoring or logging of IPv4 will be in place. >>=20 >> PROBLEM 4: IPv4 can be completely disabled on a link by filtering it >> on the L2 switching device. However, this may not be >> possible in all cases or may be too complex to deploy. >> For example, an ISP is often not able to control the L2 >> switching device in the subscriber home network. >>=20 >> PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP for >> everything", as described in Section 2.6.2 of [RFC3927]. >> Applications running on such a host connected to an >> IPv6-only network will believe that IPv4 connectivity is >> available, resulting in various bad or sub-optimal >> behavior patterns. See >> [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for further >> analysis. >>=20 >> Some of these problems were described in [RFC2563], which >> standardized a DHCP option to disable IPv4 address auto- >> configuration. However, using this option requires running an IPv4 >> DHCP server, which is contrary to the goal of IPv4 sunsetting. >>=20 >>=20 >> Thanks for discussion, >> Lee >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Fri Sep 8 12:23:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6168E1320C9 for ; Fri, 8 Sep 2017 12:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79WndsCPr5qA for ; Fri, 8 Sep 2017 12:23:20 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049E1126DD9 for ; Fri, 8 Sep 2017 12:23:16 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id o42so6200856wrb.3 for ; Fri, 08 Sep 2017 12:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DEAx7YUPN9/REPcBwWyAkPMgc35z7aNIR7esFwenry0=; b=RjYTs6WkyGYE9tMRsjZoyjWHBKEnI9A9mutGz4EaISiS3WUq/WhQUPrRIk6kM29Kpk dBTCpEpQCRkwnwbLNRQhpFZ4febERTRBhojx+2l0+SfPjrYkXG/BI/4gcqCIpHwQR1wX hPzwR52qC2zlUwlvReNr2chu30mgTNWae7tEJztMcMspqdgyTB5wIKnp0WhgB1U4Agvd ZEHgXg3JyQCgGO2s1DMBIftC/ajxEW6SYWZM5Iuvc4+ShoxuGsEiVuYVIyleqAs6eExn 5KBhGMD/yJgdjohiFdqrXawGNef4ZZwI05qtrgLESkUmFUKtoJHYyqDTg22Zoy9OuYLD abPw== 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=DEAx7YUPN9/REPcBwWyAkPMgc35z7aNIR7esFwenry0=; b=Apc7CW1I3WZdd7XezfFYmU7bJaMGlRe3RlckQPbfOkIU9CbRRP8gCXQkyQ357hBWk2 qBUHFPX6i2hMXLTuDD/sbS7rSdzLg8E3AHMl8qPPsLy/yTawVSz6f2u1cbiuDjIUe32C 0CCVem/SrlaZRiZTci/QMTlogKU8yYHtoAJLcWteNPv/WP1NzUQ2KJ6vsfV5nch+coJu e45S2T3U1JD2lX1P5eKqzxQfxcT/qHEDjhL80Fm6K42pHI4ONq6XMyhbzwY6/IKq5f1D Gk0qM4ij2L2J9vmc3ohDrKCcqoO5SI8N1TVhwXJMDRHsJCdzglk5/Dcwb+PvAI77voAm zCVg== X-Gm-Message-State: AHPjjUhJS9XWMnW0Z2j5juOakSK7r+HqVV+AggBbW+J/EDJyMUVmsmKP wjRpurCzXiApww== X-Google-Smtp-Source: ADKCNb61/FrUC8lDg2k/pKgWROUXNoOwRhb08NVpb08CXegovzsziQWU0t25tNkF9RbXbNYKoyWikw== X-Received: by 10.223.163.154 with SMTP id l26mr2950177wrb.42.1504898594296; Fri, 08 Sep 2017 12:23:14 -0700 (PDT) Received: from ?IPv6:2601:646:c005:a10:7064:f9a7:6905:c94f? ([2601:646:c005:a10:7064:f9a7:6905:c94f]) by smtp.gmail.com with ESMTPSA id s196sm3441417wmb.6.2017.09.08.12.23.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Sep 2017 12:23:13 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: Date: Fri, 8 Sep 2017 12:23:10 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> References: To: Lee Howard X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 19:23:22 -0000 > On Sep 8, 2017, at 11:03 AM, Lee Howard wrote: >=20 >=20 >=20 > On 9/8/17, 12:56 PM, "Fred Baker" wrote: >=20 >> Dumb question: is it necessary, when there is a network in which IPv4 = is >> disabled, to say that it is disabled? What does that accomplish? >=20 > Debatable, but some use cases are implied by the problems documented = in > the draft. >=20 >>=20 >> =46rom my perspective, if the DHCP server is disabled from an IPv4 >> perspective, it will stop responding to requests for an IPv4 address. >> Hosts can then build IPv4 link-local addresses if they choose, and >> communicate using them, but IPv4 will have no network services. = Either >> IPv6 works or the network doesn't work for IPv4 traffic. >=20 > Should a home gateway that doesn=E2=80=99t have an IPv4 WAN address = still act as a > DHCP server? The question isn't whether some other world uses IPv4, it's whether = there is a need for an IPv4 DHCP server inside the home. I don't know = that having or not having an address on the WAN interface tells me that. = I might have an IPv4 address on the WAN interface and not want to use it = from inside the home, and I might not have such an address but need to = use IPv4 on the LAN interface. I don't see any reason to presume that = the WAN interface tells me anything about the LAN interface. I would say "yes". The reason is that within the home, IPv4 may still be = in use, and 169.254.x.x addresses may not serve it's purposes. The = obvious examples of reasons are legacy devices that haven't been = replaced/upgraded yet.=20 > Some clients interpret a lack of DHCP response as an indication that = the > network is down, even if they have IPv6. Or so it is alleged; I have = not > tested it myself. > How often does a DHCP client send Discover messages? > How much ARP traffic is on a network? > Do we need a way to mute this traffic, or do we just have to wait = until > device manufacturers decide to stop including IPv4 in their devices? I don't know that *WE* need to think about this. Ripping functionality = out of software is often difficult and error-prone. A vendor is unlikely = to literally remove IPv4 capabilities; he's far more likely to rewrite = the technology and not include it, or provide a way to turn it off (such = as never sending a DHCP request because IPv4 is "manually configured"). = What if they *NEVER* actually remove it, but everybody stops using it? >> My thought is that we don't have a way to say "IPv6 is disabled = here"; >> either IPv6 works or it doesn't. I don't quite see what is really >> different when the shoe is on the other foot. >=20 > Assumptions (and therefore defaults) change depending on where you = start. > Most people still assume IPv4, even if they also assume IPv6. > Lee >=20 >=20 >>=20 >>> On Sep 8, 2017, at 7:52 AM, Lee Howard wrote: >>>=20 >>> Thank you all for the discussion of covering the gaps identified in >>> draft-ietf-sunset4-gapanalysis. In particular, I think many of the = gaps >>> are resolved with the revision of rfc6555 Happy Eyeballs. >>>=20 >>> I wonder, though, what should be the expected behavior of a stub >>> network when there is no IPv4 Internet access? >>>=20 >>> My current thinking is that the Internet gateway (IGD, Customer = Premise >>> Router CPR, home gateway, etc.): >>> =E2=80=A2 May still route between multiple segments of the site = network, and >>> therefore should be the IPv4 default gateway for those segments. >>> =E2=80=A2 Only knows whether native IPv4 is available. It may = not be aware of >>> NAT64 or other transition mechanisms where it=E2=80=99s not = involved. >>> So, islands of IPv4 are probable, and that=E2=80=99s okay. Do we = need a >>> document responding to gapanalysis that says so? Do we need to work = out >>> how to know when it=E2=80=99s possible to disable IPv4 completely in = a >>> heterogenous unmanaged site network? Or do we need to sit on these >>> problems for several more years and wait for IPv4 to become unused = in >>> many networks before we can deal with the gaps? >>>=20 >>> For reference, here=E2=80=99s the relevant section of = sunset4-gapanalysis: >>> 3.1. Indicating that IPv4 connectivity is unavailable >>>=20 >>> PROBLEM 1: When an IPv4 node boots and requests an IPv4 address >>> (e.g., using DHCP), it typically interprets the = absence >>> of a response as a failure condition even when it is = not. >>>=20 >>> PROBLEM 2: Home router devices often identify themselves as = default >>> routers in DHCP responses that they send to requests >>> coming from the LAN, even in the absence of IPv4 >>> connectivity on the WAN. >>>=20 >>> 3.2. Disabling IPv4 in the LAN >>>=20 >>> PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- >>> configure IPv4 addresses [RFC3927] and enable various >>> protocols over IPv4 such as mDNS [RFC6762] and LLMNR >>> [RFC4795]. This can be undesirable for operational or >>> security reasons, since in the absence of IPv4, no >>> monitoring or logging of IPv4 will be in place. >>>=20 >>> PROBLEM 4: IPv4 can be completely disabled on a link by filtering = it >>> on the L2 switching device. However, this may not be >>> possible in all cases or may be too complex to deploy. >>> For example, an ISP is often not able to control the = L2 >>> switching device in the subscriber home network. >>>=20 >>> PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP = for >>> everything", as described in Section 2.6.2 of = [RFC3927]. >>> Applications running on such a host connected to an >>> IPv6-only network will believe that IPv4 connectivity = is >>> available, resulting in various bad or sub-optimal >>> behavior patterns. See >>> [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for = further >>> analysis. >>>=20 >>> Some of these problems were described in [RFC2563], which >>> standardized a DHCP option to disable IPv4 address auto- >>> configuration. However, using this option requires running an = IPv4 >>> DHCP server, which is contrary to the goal of IPv4 sunsetting. >>>=20 >>>=20 >>> Thanks for discussion, >>> Lee >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 From nobody Fri Sep 8 13:08:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F1A13293A for ; Fri, 8 Sep 2017 13:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKQycrPghDs6 for ; Fri, 8 Sep 2017 13:08:50 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00F61321E6 for ; Fri, 8 Sep 2017 13:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1504901329; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=v0tIthK3oZm09S/UhgxgxJwJj0iqG0q9JDfJpm/sqm0=; b=aM9heeBU+YwQWZfxVTUMvSQqbor621gEXIdx2Rut388oW1jxGqhEZ7Qr5Y+1AysE 3t7BEZs817Q6sd6USrt+bV7An8emOABzb3gR1oG0HqNe0ALaSdWvt8y5Vj+YFIQe nVvzoJTnatioaRzC5emeImCkw2ikw4hnccwj1Vo2Sz8f83g7aArZqLeDyldwS9O7 j+2AIr2FnpeH4VS5PqbwKpkeD5HldZ4XhbO8vpGuDPX3rzTAqkt2gRL0imHEkZ+q CmwUv0QlO/N43PKwOLKugWj+QlBwwtJM0DRcZnX++mc0YRLJ444sDPhbki/yz0gA 4eZZ4M+smfQwvC2An+AiUg==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id D4.5F.25405.0D8F2B95; Fri, 8 Sep 2017 13:08:48 -0700 (PDT) X-AuditID: 11ab0218-751d39c00000633d-75-59b2f8d0ba52 Received: from jimbu.apple.com (jimbu.apple.com [17.151.62.37]) by relay7.apple.com (Apple SCV relay) with SMTP id 85.8F.07283.0D8F2B95; Fri, 8 Sep 2017 13:08:48 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_xmTOJXXiBc48dqIv3r45nw)" Received: from da0602a-dhcp231.apple.com (da0602a-dhcp231.apple.com [17.226.23.231]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OVZ00GH99AOOW10@jimbu.apple.com>; Fri, 08 Sep 2017 13:08:48 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <11075405-E37C-443D-9F76-474F115A1ABD@apple.com> Date: Fri, 08 Sep 2017 13:08:47 -0700 In-reply-to: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> Cc: Lee Howard , v6ops@ietf.org To: Fred Baker References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUi2FCYqnvxx6ZIg7XcFre/NrBa/Nz3h9Hi 9LG9zA7MHr965jN57Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZ729PZCzY9oax4uPVJUwN jOdPMnYxcnJICJhIPP8xg62LkYtDSGAtk8SK1a/YYRInJ09hhkhsYJQ427qfFSTBKyAo8WPy PRYQm1kgTGLCwiYWiKK5TBJ7P08ASwgLSEt0XbgL1MDBwSagJXFgjRFEr43EzcfdUCVuEm8O rGcGsVkEVCVWPTsItphTwFbi0rQ2Noj5+hKXHqwAs0UENCVur5vGBLFrM6PEzAPXWCEulZW4 NfsS2KUSAmvYJBb9OcE4gVFoFpJjZyE5dhbQTcwC6hJTpuRChLUlnry7wAphq0ks/L2ICVl8 ASPbKkbh3MTMHN3MPCMTvcSCgpxUveT83E2MoChZzSSxg/HLa8NDjAIcjEo8vBd2booUYk0s K67MPcQozcGiJM5b93BjpJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGV73Hby166u9/4L07 y6jga+2fzPP79k7bzhnwTcRzy7o991/kZL+4eo99bv/Z5lUuX4x7giQO581NK39QpmgqWfPv /9pK50lCQhz3TmXXXleOSjp58tEHWSlpcUn2Xa/iVWQDyi4+8Vts8GLqGtH/RhKqjDeWh/5w uGSn8uxlQGKZv0L+6RfNSizFGYmGWsxFxYkAGLipfXMCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUiON1OVffCj02RBq/a5Cxuf21gtfi57w+j xelje5kdmD1+9cxn8tg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mt7fnshYsO0NY8XHq0uY GhjPn2TsYuTkkBAwkTg5eQpzFyMXh5DABkaJs637WUESvAKCEj8m32MBsZkFwiQmLGxigSia yySx9/MEsISwgLRE14W7QA0cHGwCWhIH1hhB9NpI3HzcDVXiJvHmwHpmEJtFQFVi1bOD7CA2 p4CtxKVpbWwQ8/UlLj1YAWaLCGhK3F43jQli12ZGiZkHrrFCXCorcWv2JeYJjPyzkNw3C8l9 s4DOYBZQl5gyJRcirC3x5N0FVghbTWLh70VMyOILGNlWMQoUpeYkVprrJRYU5KTqJefnbmIE BXVDYeoOxsblVocYBTgYlXh4K7ZvihRiTSwrrsw9xCjBwawkwsv+HijEm5JYWZValB9fVJqT WnyIUZqDRUmcd/b09ZFCAumJJanZqakFqUUwWSYOTqkGxrInLyp5qr5fW3aSb+rHrbw8cS7v Sma7GbVKTnnjYBPbd+7zT13vdZvcGSKZGd6vP7Jd2+p8k+BxmznHfZhNxF4dY7Pe+P7vz7kT H6iaFlb0npHcKH20cfacd2wZJx/aFk9wvWJ2OEw/Ym+H/as5Ok+TG0W5JU9v2uN8SXCDzqmb Gp++Klk5L1RiKc5INNRiLipOBAAlZXEGZgIAAA== Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 20:08:52 -0000 --Boundary_(ID_xmTOJXXiBc48dqIv3r45nw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable While most Modern Operating Systems=E2=84=A2 have good IPv6 support now, = there will always be that one device in your home that supports neither = IPv6 nor IPv4 link-local. Because of those, I don't think removing = DHCPv4 from the home is worth doing in the next decades. I also don't = think this should be handled by the IETF - as far as I know there was no = RFC saying "stop using AppleTalk", it just went away when vendors felt = that supporting it cost more than it was benefiting. The same will be = true of IPv4, eventually. If the IETF wants to spend energy on = sunsetting IPv4, I think it should be used on improving and documenting = transition mechanisms like NAT64. David Schinazi > On Sep 8, 2017, at 12:23, Fred Baker wrote: >=20 >=20 >=20 >> On Sep 8, 2017, at 11:03 AM, Lee Howard wrote: >>=20 >>=20 >>=20 >> On 9/8/17, 12:56 PM, "Fred Baker" wrote: >>=20 >>> Dumb question: is it necessary, when there is a network in which = IPv4 is >>> disabled, to say that it is disabled? What does that accomplish? >>=20 >> Debatable, but some use cases are implied by the problems documented = in >> the draft. >>=20 >>>=20 >>> =46rom my perspective, if the DHCP server is disabled from an IPv4 >>> perspective, it will stop responding to requests for an IPv4 = address. >>> Hosts can then build IPv4 link-local addresses if they choose, and >>> communicate using them, but IPv4 will have no network services. = Either >>> IPv6 works or the network doesn't work for IPv4 traffic. >>=20 >> Should a home gateway that doesn=E2=80=99t have an IPv4 WAN address = still act as a >> DHCP server? >=20 > The question isn't whether some other world uses IPv4, it's whether = there is a need for an IPv4 DHCP server inside the home. I don't know = that having or not having an address on the WAN interface tells me that. = I might have an IPv4 address on the WAN interface and not want to use it = from inside the home, and I might not have such an address but need to = use IPv4 on the LAN interface. I don't see any reason to presume that = the WAN interface tells me anything about the LAN interface. >=20 > I would say "yes". The reason is that within the home, IPv4 may still = be in use, and 169.254.x.x addresses may not serve it's purposes. The = obvious examples of reasons are legacy devices that haven't been = replaced/upgraded yet.=20 >=20 >> Some clients interpret a lack of DHCP response as an indication that = the >> network is down, even if they have IPv6. Or so it is alleged; I have = not >> tested it myself. >=20 >=20 >> How often does a DHCP client send Discover messages? >> How much ARP traffic is on a network? >> Do we need a way to mute this traffic, or do we just have to wait = until >> device manufacturers decide to stop including IPv4 in their devices? >=20 > I don't know that *WE* need to think about this. Ripping functionality = out of software is often difficult and error-prone. A vendor is unlikely = to literally remove IPv4 capabilities; he's far more likely to rewrite = the technology and not include it, or provide a way to turn it off (such = as never sending a DHCP request because IPv4 is "manually configured"). = What if they *NEVER* actually remove it, but everybody stops using it? >=20 >>> My thought is that we don't have a way to say "IPv6 is disabled = here"; >>> either IPv6 works or it doesn't. I don't quite see what is really >>> different when the shoe is on the other foot. >>=20 >> Assumptions (and therefore defaults) change depending on where you = start. >> Most people still assume IPv4, even if they also assume IPv6. >=20 >=20 >=20 >> Lee >>=20 >>=20 >>>=20 >>>> On Sep 8, 2017, at 7:52 AM, Lee Howard wrote: >>>>=20 >>>> Thank you all for the discussion of covering the gaps identified in >>>> draft-ietf-sunset4-gapanalysis. In particular, I think many of the = gaps >>>> are resolved with the revision of rfc6555 Happy Eyeballs. >>>>=20 >>>> I wonder, though, what should be the expected behavior of a stub >>>> network when there is no IPv4 Internet access? >>>>=20 >>>> My current thinking is that the Internet gateway (IGD, Customer = Premise >>>> Router CPR, home gateway, etc.): >>>> =E2=80=A2 May still route between multiple segments of the site = network, and >>>> therefore should be the IPv4 default gateway for those segments. >>>> =E2=80=A2 Only knows whether native IPv4 is available. It may = not be aware of >>>> NAT64 or other transition mechanisms where it=E2=80=99s not = involved. >>>> So, islands of IPv4 are probable, and that=E2=80=99s okay. Do we = need a >>>> document responding to gapanalysis that says so? Do we need to work = out >>>> how to know when it=E2=80=99s possible to disable IPv4 completely = in a >>>> heterogenous unmanaged site network? Or do we need to sit on these >>>> problems for several more years and wait for IPv4 to become unused = in >>>> many networks before we can deal with the gaps? >>>>=20 >>>> For reference, here=E2=80=99s the relevant section of = sunset4-gapanalysis: >>>> 3.1. Indicating that IPv4 connectivity is unavailable >>>>=20 >>>> PROBLEM 1: When an IPv4 node boots and requests an IPv4 address >>>> (e.g., using DHCP), it typically interprets the = absence >>>> of a response as a failure condition even when it is = not. >>>>=20 >>>> PROBLEM 2: Home router devices often identify themselves as = default >>>> routers in DHCP responses that they send to requests >>>> coming from the LAN, even in the absence of IPv4 >>>> connectivity on the WAN. >>>>=20 >>>> 3.2. Disabling IPv4 in the LAN >>>>=20 >>>> PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- >>>> configure IPv4 addresses [RFC3927] and enable various >>>> protocols over IPv4 such as mDNS [RFC6762] and LLMNR >>>> [RFC4795]. This can be undesirable for operational or >>>> security reasons, since in the absence of IPv4, no >>>> monitoring or logging of IPv4 will be in place. >>>>=20 >>>> PROBLEM 4: IPv4 can be completely disabled on a link by filtering = it >>>> on the L2 switching device. However, this may not be >>>> possible in all cases or may be too complex to deploy. >>>> For example, an ISP is often not able to control the = L2 >>>> switching device in the subscriber home network. >>>>=20 >>>> PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP = for >>>> everything", as described in Section 2.6.2 of = [RFC3927]. >>>> Applications running on such a host connected to an >>>> IPv6-only network will believe that IPv4 connectivity = is >>>> available, resulting in various bad or sub-optimal >>>> behavior patterns. See >>>> [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for = further >>>> analysis. >>>>=20 >>>> Some of these problems were described in [RFC2563], which >>>> standardized a DHCP option to disable IPv4 address auto- >>>> configuration. However, using this option requires running an = IPv4 >>>> DHCP server, which is contrary to the goal of IPv4 sunsetting. >>>>=20 >>>>=20 >>>> Thanks for discussion, >>>> Lee >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Boundary_(ID_xmTOJXXiBc48dqIv3r45nw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable While most Modern Operating Systems=E2=84=A2 have good IPv6 = support now, there will always be that one device in your home that = supports neither IPv6 nor IPv4 link-local. Because of those, I don't = think removing DHCPv4 from the home is worth doing in the next decades. = I also don't think this should be handled by the IETF - as far as I know = there was no RFC saying "stop using AppleTalk", it just went away when = vendors felt that supporting it cost more than it was benefiting. The = same will be true of IPv4, eventually. If the IETF wants to spend energy = on sunsetting IPv4, I think it should be used on improving and = documenting transition mechanisms like NAT64.

David Schinazi


On = Sep 8, 2017, at 12:23, Fred Baker <fredbaker.ietf@gmail.com> wrote:


On Sep 8, 2017, at 11:03 AM, = Lee Howard <Lee@asgard.org> wrote:



On 9/8/17, 12:56 PM, "Fred Baker" <fredbaker.ietf@gmail.com> wrote:

Dumb question: is it = necessary, when there is a network in which IPv4 is
disabled, to say that it is disabled? What does that = accomplish?

Debatable, but = some use cases are implied by the problems documented in
the= draft.


=46rom my perspective, if the DHCP server is = disabled from an IPv4
perspective, it will stop responding = to requests for an IPv4 address.
Hosts can then build IPv4 = link-local addresses if they choose, and
communicate using = them, but IPv4 will have no network services. Either
IPv6 = works or the network doesn't work for IPv4 traffic.

Should a home gateway that = doesn=E2=80=99t have an IPv4 WAN address still act as a
DHCP= server?

The question isn't whether some = other world uses IPv4, it's whether there is a need for an IPv4 DHCP = server inside the home. I don't know that having or not having an = address on the WAN interface tells me that. I might have an IPv4 address = on the WAN interface and not want to use it from inside the home, and I = might not have such an address but need to use IPv4 on the LAN = interface. I don't see any reason to presume that the WAN interface = tells me anything about the LAN interface.

I would say "yes". The reason is that within the = home, IPv4 may still be in use, and 169.254.x.x addresses may not serve = it's purposes. The obvious examples of reasons are legacy devices that = haven't been replaced/upgraded yet. 
Some clients interpret a = lack of DHCP response as an indication that the
network is = down, even if they have IPv6. Or so it is alleged; I have not
tested it myself.

How often does a DHCP client = send Discover messages?
How much ARP traffic is on a = network?
Do we need a way to mute this traffic, or do we = just have to wait until
device manufacturers decide to = stop including IPv4 in their devices?

I don't know that *WE* need to think about this. = Ripping functionality out of software is often difficult and = error-prone. A vendor is unlikely to literally remove IPv4 capabilities; = he's far more likely to rewrite the technology and not include it, or = provide a way to turn it off (such as never sending a DHCP request = because IPv4 is "manually configured"). What if they *NEVER* actually = remove it, but everybody stops using it?

My thought is that we don't have a way to say "IPv6 is = disabled here";
either IPv6 works or it doesn't. I don't = quite see what is really
different when the shoe is on the = other foot.

Assumptions (and = therefore defaults) change depending on where you start.
Most people still assume IPv4, even if they also assume = IPv6.


Lee



On Sep 8, 2017, at 7:52 = AM, Lee Howard <Lee@asgard.org> wrote:

Thank you all for the discussion of covering the gaps = identified in
draft-ietf-sunset4-gapanalysis. In = particular, I think many of the gaps
are resolved with the = revision of rfc6555 Happy Eyeballs.

I = wonder, though, what should be the expected behavior of a stub
network when there is no IPv4 Internet access?

My current thinking is that the Internet = gateway (IGD, Customer Premise
Router CPR, home gateway, = etc.):
=E2=80=A2 May still route between multiple segments of = the site network, and
therefore should be the IPv4 default = gateway for those segments.
=E2=80=A2 Only knows whether = native IPv4 is available. It may not be aware of
NAT64 or = other transition mechanisms where it=E2=80=99s not involved.
So, islands of IPv4 are probable, and that=E2=80=99s okay. Do = we need a
document responding to gapanalysis that says so? = Do we need to work out
how to know when it=E2=80=99s = possible to disable IPv4 completely in a
heterogenous = unmanaged site network? Or do we need to sit on these
problems for several more years and wait for IPv4 to become = unused in
many networks before we can deal with the = gaps?

For reference, here=E2=80=99s the = relevant section of sunset4-gapanalysis:
3.1. =  Indicating that IPv4 connectivity is unavailable

 PROBLEM 1:  When an IPv4 node boots and requests = an IPv4 address
          &nb= sp;  (e.g., using DHCP), it typically interprets the = absence
          &nb= sp;  of a response as a failure condition even when it is = not.

 PROBLEM 2:  Home router = devices often identify themselves as default
          &nb= sp;  routers in DHCP responses that they send to requests
          &nb= sp;  coming from the LAN, even in the absence of IPv4
          &nb= sp;  connectivity on the WAN.

3.2. =  Disabling IPv4 in the LAN

 PROBLEM= 3:  IPv4-enabled hosts inside an IPv6-only LAN can auto-
          &nb= sp;  configure IPv4 addresses [RFC3927] and enable various
          &nb= sp;  protocols over IPv4 such as mDNS [RFC6762] and LLMNR
          &nb= sp;  [RFC4795].  This can be undesirable for operational = or
          &nb= sp;  security reasons, since in the absence of IPv4, no
          &nb= sp;  monitoring or logging of IPv4 will be in place.

 PROBLEM 4:  IPv4 can be completely = disabled on a link by filtering it
          &nb= sp;  on the L2 switching device.  However, this may not = be
          &nb= sp;  possible in all cases or may be too complex to deploy.
          &nb= sp;  For example, an ISP is often not able to control the = L2
          &nb= sp;  switching device in the subscriber home network.

 PROBLEM 5:  A host with only = Link-Local IPv4 addresses will "ARP for
          &nb= sp;  everything", as described in Section 2.6.2 of = [RFC3927].
          &nb= sp;  Applications running on such a host connected to an
          &nb= sp;  IPv6-only network will believe that IPv4 connectivity = is
          &nb= sp;  available, resulting in various bad or sub-optimal
          &nb= sp;  behavior patterns.  See
          &nb= sp;  [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for = further
          &nb= sp;  analysis.

 Some of = these problems were described in [RFC2563], which
 standardized a DHCP option to disable IPv4 address = auto-
 configuration.  However, using this = option requires running an IPv4
 DHCP server, which = is contrary to the goal of IPv4 sunsetting.


Thanks for discussion,
Lee

_______________________________________________
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

= --Boundary_(ID_xmTOJXXiBc48dqIv3r45nw)-- From nobody Fri Sep 8 16:36:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737E5126BF0 for ; Fri, 8 Sep 2017 16:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-_CT8-mzWRh for ; Fri, 8 Sep 2017 16:36:27 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437E2127005 for ; Fri, 8 Sep 2017 16:36:27 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id m9so7115082pgd.3 for ; Fri, 08 Sep 2017 16:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=c7WOp2fTIDQnAtdfp7lIgSh1z5m9v65GOeM6//60eRQ=; b=TwrtsE9xxQM8wI1uPHh7ts4XHUvfCHgnTIjDfNkebEwhYrLdfpZXGEr1oC2vqABM6Z Gebr2htIYcZuw1MWAkvDsbaUKYKQBjeouoEWMnR8fD7qlAg/E8JOIF/RunNUA28H+w3n uByzPZRdCctJLVnT6UUSMKRjW0X6NW9FyxIGdqjLSlH6qDUg44U4dPelyRxj7tlfnoKZ l9Yn2IpMmS0nF1JAsu/BXZhpvL2OH0vrOUcfON36F7MlJahrSDo5jgD7mWWzRhsDIdsS v3u9Ftcp3hD4UDhT3jEZ2JH1sNZmstGUU67j9yOFBi4bm+GQxFik00ahRfGVqiY6oV3K WeUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=c7WOp2fTIDQnAtdfp7lIgSh1z5m9v65GOeM6//60eRQ=; b=XG6V7PtArbsxdNlubAjuiJ2CcnyXf4vjhNCW+j9arIRjPnwQH/uN/se2AoWYH10hou EzNVWWTkxa5EST2pSFQEG2gst6iQ2OHJSMEN9radvuguK0FK2mLvhQaf5E+doF5jh/TY NAvXIqPqHG9zOexP0EJrh3ufpNdd50OdUZFjCHKvFuKMHaSD1s0qmGYt6qhD7qjS5C4j yhiQBabIOFxSTTeRNz2LxC//8peknBLYmRJl6ArVPAoz7WbTz4LmxBj1jk7N+r0Bgdm7 RRZmp3qz6DbVwFTXiBQs6uLuGfPEMeq8QnDendDltKMUcvVb7kHlQJ0iXvxmTQa1XqF6 prQA== X-Gm-Message-State: AHPjjUhEm06NEJ758Fz7277sEEIZsvjZujmR0ukt7nFIFpCU8BD+Lj9B DJGPZ1kwjRZRF9r+ X-Google-Smtp-Source: ADKCNb7C0HzqCNP+vPL/Bk3dVpn3IJ0eGVOzzR3smNPSS3KYly07kgrT54jWZSe1HAej7/2DzzJ0EQ== X-Received: by 10.98.157.73 with SMTP id i70mr4662990pfd.268.1504913786445; Fri, 08 Sep 2017 16:36:26 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r16sm5644898pfk.178.2017.09.08.16.36.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Sep 2017 16:36:25 -0700 (PDT) To: Fred Baker , Lee Howard Cc: v6ops@ietf.org References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> Date: Sat, 9 Sep 2017 11:36:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 23:36:29 -0000 On 09/09/2017 07:23, Fred Baker wrote: >=20 >=20 >> On Sep 8, 2017, at 11:03 AM, Lee Howard wrote: >> >> >> >> On 9/8/17, 12:56 PM, "Fred Baker" wrote: >> >>> Dumb question: is it necessary, when there is a network in which IPv4= is >>> disabled, to say that it is disabled? What does that accomplish? >> >> Debatable, but some use cases are implied by the problems documented i= n >> the draft. >> >>> >>> From my perspective, if the DHCP server is disabled from an IPv4 >>> perspective, it will stop responding to requests for an IPv4 address.= >>> Hosts can then build IPv4 link-local addresses if they choose, and >>> communicate using them, but IPv4 will have no network services. Eithe= r >>> IPv6 works or the network doesn't work for IPv4 traffic. >> >> Should a home gateway that doesn=E2=80=99t have an IPv4 WAN address st= ill act as a >> DHCP server? >=20 > The question isn't whether some other world uses IPv4, it's whether the= re is a need for an IPv4 DHCP server inside the home. I don't know that h= aving or not having an address on the WAN interface tells me that. I migh= t have an IPv4 address on the WAN interface and not want to use it from i= nside the home, and I might not have such an address but need to use IPv4= on the LAN interface. I don't see any reason to presume that the WAN int= erface tells me anything about the LAN interface. >=20 > I would say "yes". The reason is that within the home, IPv4 may still b= e in use, and 169.254.x.x addresses may not serve it's purposes. The obvi= ous examples of reasons are legacy devices that haven't been replaced/upg= raded yet.=20 I agree. Apart from religious reasons, who cares if IPv4 is providing use= ful legacy services in the home for the next seventy years? For example, ther= e are innumerable IPv4-only DHCP-using printers around, which are accessed = in ways that don't seem to involve DNS. Where's the harm? It is presumably written somwhere that a DNS resolver in a CE that has no= Internet IPv4 connectivity MUST NOT return off-site A records; if not, it should be. Does anything need to be said about mDNS? Again, where's the harm in using mDNS when there is no WAN IPv4? Incdidentally: >> 3.2. Disabling IPv4 in the LAN >>=20 >> PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- >> configure IPv4 addresses [RFC3927] and enable various >> protocols over IPv4 such as mDNS [RFC6762] and LLMNR >> [RFC4795]. This can be undesirable for operational or >> security reasons, since in the absence of IPv4, no >> monitoring or logging of IPv4 will be in place. Who says there will be no IPv4 monitoring or logging when there is no IPv4 WAN connectivity? Brian From nobody Sat Sep 9 12:49:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CF2132925 for ; Sat, 9 Sep 2017 12:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEepArVQK-Rx for ; Sat, 9 Sep 2017 12:49:49 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E81D1243F6 for ; Sat, 9 Sep 2017 12:49:49 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id m18so8840909wrm.2 for ; Sat, 09 Sep 2017 12:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Oxemkr2QGK3SUS8lI/9gy+oETxacoHQC0XLim+E8so0=; b=AQEafsKeuSIE2qdfK4uEeLc98m4o85y2+kK8Ueo4pNsDT4tWu2aPzT8dr36gIAfar4 /I0h9ZMM5jZRUZB3+ryEU232s1Hp0W2VwIZZd+J6OPr60WAbEzEbENWQ5n8bivEvSLio cxCIYM95C0Q871kVY6IU1YzHtCWUjqPKlxNzZ0PdRZyg22YdE/CykpK7sdilBJSwY0Yg dIZZToIl16DE+5qid91n8FP13T/4lpQEBZC3ESLz/Qv17pb9KPmXe8NmIRm/PEc7H1CB rpHJY+59qhugVxw5IptaqqAMP1psea9ZGOejLapDNCbehAx/BI8zHOIGqbuAXZ0AqIJA mFSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Oxemkr2QGK3SUS8lI/9gy+oETxacoHQC0XLim+E8so0=; b=TbRhponBgHmI3VTDxzZeaYnmqxxrAVRmsBddmUfej+1HuxKjy5qyd34X+9KUMdn5nb JThlyGqjFWObTWVf2DuCX5TPAR5nuQW6sfWacPPxNq7lCJpXmHksokAoCB5BbiHDLJeL LQcOlRvQGeH9a/B9fyX3qHhA1//kBKLcayPYRQE7Kvqze1QJGGhKb8S2+5c78ItKBm7q FCNNJPHg28ObcqY3O91+XjHRt1NZ6oqCdwEMYvTmjSc09av4/pnmDAcm3j0T5XUQigPA dmrsLFkiMz5IYJSoXGI7Qddntk22JFWe+y3gJMRlfcLHFhQvKskZ8UkKpkYvjTGIdhA+ jpLg== X-Gm-Message-State: AHPjjUg8aAfHP+TKraQlJVKNrGyYfkR63o2az8qyr//IswCxfxNtOKuc 1oUj3RvMHTKKXZw30Y5C+hGJnKl6ymU1 X-Google-Smtp-Source: ADKCNb74i6/hJugTsgtfRM/GTatXjGGoJzD3SqtUFCsrX9rthV2gXdDR9WvIwLm1f02wnSi7KkNT46GPq4WQZF27Ki4= X-Received: by 10.223.177.211 with SMTP id r19mr5201925wra.2.1504986587675; Sat, 09 Sep 2017 12:49:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.141 with HTTP; Sat, 9 Sep 2017 12:49:06 -0700 (PDT) In-Reply-To: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Sat, 9 Sep 2017 15:49:06 -0400 Message-ID: To: Brian E Carpenter Cc: Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "v6ops-chairs@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , The IESG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 19:49:52 -0000 [ Top-post ] Yup, I was thinking that, while substantive, that would be handled while still keeping it in IESG eval -- but, I've just gone back and re-read the threads, especially all of the mail (~102) after the IESG / telechat, and I've decided that I will have to return it to the WG. Seeing as it has already had a WGLC, I expect that the next one can be compressed. The good news is that a: there have been a number of suggestions / provided text to improve the document, and b: I'd expect the next IESG eval to go easily. Sorry all, W On Mon, Sep 4, 2017 at 6:32 PM, Brian E Carpenter wrote: > Warren, > > I believe it's substantive that the text refers to sending unicast > RAs without clarifying whether this means that they are sent > with a unicast layer 2 address and a multicast layer 3 address > (as per RFC6085) or that they are sent with both layer 2 and > layer 3 addresses being unicast. At the moment, an implementer > has to decide which of these is intended. If either is OK, > that could be stated too. > > Specifically this clarification seems to be needed right after: > >> 4. IPv6 Unique Prefix Assignment >> >> When a UE connects to the shared provider managed network and is >> attached, it will initiate IP configuration phase. During this phase >> the UE will, from an IPv6 perspective, attempt to learn the default >> IPv6 gateway, the IPv6 prefix information, the DNS information >> RFC8106 [RFC8106], and the remaining information required to >> establish globally routable IPv6 connectivity. For that purpose, the >> the UE/subscriber sends a RS (Router Solicitation) message. >> >> The First Hop Router receives this UE/subscriber RS message and >> starts the process to compose the response to the UE/subscriber >> originated RS message. The First Hop Provider Router will answer >> using a unicast RA (Router Advertisement) to the UE/subscriber. > > Regards > Brian Carpenter > > On 05/09/2017 09:43, Warren Kumari wrote: >> I'd like to note that that there is continuing discussion on this >> draft on the v6 ops list (yup, after WGLC and IETF LC :-)). I've only >> been able to somewhat monitor it, but have asked the v6ops chairs for >> input. Much of the discussion has been interesting, but not >> necessarily pertaining exactly to this document. >> Fred kindly asked the list: >> https://mailarchive.ietf.org/arch/msg/v6ops/bpEDtnYkbvJQZAx_r6mtEhdNxrw >> for anything substantive for the document (keeping in mind that it has >> already gone through WGLC and IETF LC). >> >> So far it doesn't seem like there are any other major changes needed, >> other than "asking that the applicability comment that communication >> between such nodes on a LAN should go through a connecting router >> (which seems to me a given due to the relationship with routing) >> should be documented." and David Farmer's followup -- >> https://mailarchive.ietf.org/arch/msg/v6ops/_-QlBqGk9dChoFOhxigf5WlxYDY >> >> Does anyone have anything else *substantive*? If so, I may have to >> kick this back to the WG for another round. >> >> W >> >> >> >> >> On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan >> wrote: >>> Hi Gunter, >>> Thanks for the proposed text changes. They adequately address my DISCUSS >>> points. I am hoping you will also converge in the discussion with Lorenzo on >>> the actual value for the timer and/or specify an applicability statement. I >>> will clear once the new revision posts. >>> >>> Regards >>> Suresh >>> >>> On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) >>> wrote: >>> >>> Hi Suresh, >>> >>> Many thanks for the review and finding these issues. What do you think of >>> the proposals below to fix those points of attention? >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> * Section 4 >>> >>> It is not clear what you intend here >>> >>> "IPv6 Router Advertisement Interval = 300s" >>> >>> The router advertisement interval is not configured as an absolute value >>> but as >>> minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval) >>> which are >>> used to calculate the actual advertisement interval. When the RA is sent >>> from >>> an interface, the actual interval is an uniformly distributed random >>> value >>> between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum >>> you >>> need to clarify if you would like to have this as a lower bound or as an >>> upper >>> bound. >>> >>> GV> I changed the line to make it more clear that the timer indicates the >>> maximum Advertisement Interval >>> GV> Maximum IPv6 Router Advertisement Interval = 300s >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> * Section 4 >>> >>> -> I think text is needed here to handle the case where the DNS server is >>> provided in the RA itself (RFC8106) >>> >>> "In addition it will use stateless DHCPv6 to get the IPv6 address of the >>> DNS >>> server" >>> >>> -> I am not sure what is the motivation for this text. >>> >>> "however it SHOULD NOT use stateful DHCPv6 to receive a service provider >>> managed IPv6 address" >>> >>> -> This text seems incorrect >>> >>> "due to the L-bit set, it SHOULD send this traffic to the First Hop >>> Provider >>> Router" >>> >>> I think it should be the exact opposite. i.e. say *unset* instead of set >>> >>> "due to the L-bit being unset, it SHOULD send this traffic to the First >>> Hop >>> Provider Router" >>> >>> GV> What about the following modification in the text: >>> >>> OLD: >>> The architected result of designing the RA as documented above is >>> that each UE/subscriber gets its own unique IPv6 prefix for which it >>> can use SLAAC or any other method to select its /128 unique address. >>> In addition it will use stateless DHCPv6 to get the IPv6 address of >>> the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive >>> a service provider managed IPv6 address. If the UE/subscriber >>> desires to send anything external including other UE/subscriber >>> devices (assuming device to device communications is enabled and >>> supported), then, due to the L-bit set, it SHOULD send this traffic >>> to the First Hop Provider Router. >>> >>> New: >>> The architected result of designing the RA as documented above is >>> that each UE/subscriber gets its own unique IPv6 prefix for which it >>> can use SLAAC or any other method to select its /128 unique address. >>> Either stateless DHCPv6 RFC3736 or IPv6 >>> Router Advertisement Options for DNS Configuration >>> RFC8106 can be used to get the >>> IPv6 address of the DNS server. If the UE/subscriber desires to send >>> anything external including other UE/subscriber devices (assuming device >>> to device communications is enabled and supported), then, due to the >>> L-bit being unset, it SHOULD send this traffic to the First Hop Provider >>> Router. >>> >>> >>> >>> Kind Regards, >>> G/ >>> >>> >> >> >> -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sat Sep 9 17:58:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8E6132D18 for ; Sat, 9 Sep 2017 17:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 GpOmMLL4IZ7n for ; Sat, 9 Sep 2017 17:58:45 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E747132CE7 for ; Sat, 9 Sep 2017 17:58:41 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id i14so11913710ioe.2 for ; Sat, 09 Sep 2017 17:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RlcK8r2nKoT36LeANHi+wgp857etR3v59FY4Vk84or0=; b=dApOC0TIYTSlPPai90yEa3h4kjhHaipbg9v1G8r+lnYgsDevM/qJf5YUt7yYvzTXu8 axYZqqP2fepGlqiGzxo9KTgVemrQi9LzKhj+04AACHH995XrW4xq8bTtRcTRGSwLQJ9+ beqEddXaNn/MIci+H55VMQovlojQCJhJcMMQ2iiXZih4x2LXzlWzZa2K8br4791Q917n esLguToTe5cIwARQPfBUV3/WIYuTCFf+zQ3sRI19NdLLXS1fscpndcY07RvFOnrCFRd5 iE5/KGW1aBbRo9pGTLKuZGBykktTAsfUJL9PtHiWLWHd6a0j0aaCQv+hvQPKdS6Ez7Cd SZ6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RlcK8r2nKoT36LeANHi+wgp857etR3v59FY4Vk84or0=; b=I+balGVMGH7G4MX3Hw74P08NOiVg7dTPRI0F/Xve/Dzq9hoIdIfcRltpZiJ4jKS6ok CYse07K+0AvlM4iCcw+GldUU0eQqRixVwJcUlsdfoioEAqJJbSCB4NwDn5HZrfHGKSvT PiQvlNtcP+AwoZkNW8wJtQsae8WeD2MvOZisVEXVe2TKblt91pU9kjibEYSMj7JhnYpc mTIWXZF8JATc0VizWEzR5+khQQ3TdUw4mA/x8cG4l6aHfC3rOXiwHvzXdrRYW/nWZ4G6 seniiaIB161ly6ZQDGEpzytkYRKFWEdFvrwt6rol6vmXo3HL0AbpgA9s03alZByt4XDO Tajg== X-Gm-Message-State: AHPjjUg/9iUnYnqcyH1Pl63IzzicPBGBNPEBz7KOr9zsNsyb4DEFGTEv 6/zMSc0u/cFLe6ngpIjLX5wOs+R63Bes X-Google-Smtp-Source: AOwi7QDqaUe/j5jHqZQr1zFF+WjzbKO99Oc7nLR1cqG06kWhuJ2rjsnJJdwJmKNSA4nzDDcxhvqA1I2QO64LVxR2G48= X-Received: by 10.107.143.14 with SMTP id r14mr9138288iod.172.1505005120077; Sat, 09 Sep 2017 17:58:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.11 with HTTP; Sat, 9 Sep 2017 17:58:19 -0700 (PDT) In-Reply-To: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> From: Lorenzo Colitti Date: Sun, 10 Sep 2017 09:58:19 +0900 Message-ID: To: Warren Kumari Cc: Brian E Carpenter , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , "v6ops-chairs@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Suresh Krishnan , The IESG Content-Type: multipart/alternative; boundary="94eb2c061b4c91ece70558cb4fe0" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 00:58:48 -0000 --94eb2c061b4c91ece70558cb4fe0 Content-Type: text/plain; charset="UTF-8" Warren, care to summarize the main issues that caused you to do this? We'll want to make sure we don't spend too much time discussing issues that did not materially impact this decision. Cheers, Lorenzo On Sun, Sep 10, 2017 at 4:49 AM, Warren Kumari wrote: > [ Top-post ] > > Yup, I was thinking that, while substantive, that would be handled > while still keeping it in IESG eval -- but, I've just gone back and > re-read the threads, especially all of the mail (~102) after the IESG > / telechat, and I've decided that I will have to return it to the WG. > Seeing as it has already had a WGLC, I expect that the next one can be > compressed. > > The good news is that a: there have been a number of suggestions / > provided text to improve the document, and b: I'd expect the next IESG > eval to go easily. > > Sorry all, > W > > > On Mon, Sep 4, 2017 at 6:32 PM, Brian E Carpenter > wrote: > > Warren, > > > > I believe it's substantive that the text refers to sending unicast > > RAs without clarifying whether this means that they are sent > > with a unicast layer 2 address and a multicast layer 3 address > > (as per RFC6085) or that they are sent with both layer 2 and > > layer 3 addresses being unicast. At the moment, an implementer > > has to decide which of these is intended. If either is OK, > > that could be stated too. > > > > Specifically this clarification seems to be needed right after: > > > >> 4. IPv6 Unique Prefix Assignment > >> > >> When a UE connects to the shared provider managed network and is > >> attached, it will initiate IP configuration phase. During this phase > >> the UE will, from an IPv6 perspective, attempt to learn the default > >> IPv6 gateway, the IPv6 prefix information, the DNS information > >> RFC8106 [RFC8106], and the remaining information required to > >> establish globally routable IPv6 connectivity. For that purpose, the > >> the UE/subscriber sends a RS (Router Solicitation) message. > >> > >> The First Hop Router receives this UE/subscriber RS message and > >> starts the process to compose the response to the UE/subscriber > >> originated RS message. The First Hop Provider Router will answer > >> using a unicast RA (Router Advertisement) to the UE/subscriber. > > > > Regards > > Brian Carpenter > > > > On 05/09/2017 09:43, Warren Kumari wrote: > >> I'd like to note that that there is continuing discussion on this > >> draft on the v6 ops list (yup, after WGLC and IETF LC :-)). I've only > >> been able to somewhat monitor it, but have asked the v6ops chairs for > >> input. Much of the discussion has been interesting, but not > >> necessarily pertaining exactly to this document. > >> Fred kindly asked the list: > >> https://mailarchive.ietf.org/arch/msg/v6ops/bpEDtnYkbvJQZAx_r6mtEhdNxrw > >> for anything substantive for the document (keeping in mind that it has > >> already gone through WGLC and IETF LC). > >> > >> So far it doesn't seem like there are any other major changes needed, > >> other than "asking that the applicability comment that communication > >> between such nodes on a LAN should go through a connecting router > >> (which seems to me a given due to the relationship with routing) > >> should be documented." and David Farmer's followup -- > >> https://mailarchive.ietf.org/arch/msg/v6ops/_-QlBqGk9dChoFOhxigf5WlxYDY > >> > >> Does anyone have anything else *substantive*? If so, I may have to > >> kick this back to the WG for another round. > >> > >> W > >> > >> > >> > >> > >> On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan > >> wrote: > >>> Hi Gunter, > >>> Thanks for the proposed text changes. They adequately address my > DISCUSS > >>> points. I am hoping you will also converge in the discussion with > Lorenzo on > >>> the actual value for the timer and/or specify an applicability > statement. I > >>> will clear once the new revision posts. > >>> > >>> Regards > >>> Suresh > >>> > >>> On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) > >>> wrote: > >>> > >>> Hi Suresh, > >>> > >>> Many thanks for the review and finding these issues. What do you think > of > >>> the proposals below to fix those points of attention? > >>> > >>> ------------------------------------------------------------ > ---------- > >>> DISCUSS: > >>> ------------------------------------------------------------ > ---------- > >>> > >>> * Section 4 > >>> > >>> It is not clear what you intend here > >>> > >>> "IPv6 Router Advertisement Interval = 300s" > >>> > >>> The router advertisement interval is not configured as an absolute > value > >>> but as > >>> minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval) > >>> which are > >>> used to calculate the actual advertisement interval. When the RA is > sent > >>> from > >>> an interface, the actual interval is an uniformly distributed random > >>> value > >>> between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very > minimum > >>> you > >>> need to clarify if you would like to have this as a lower bound or > as an > >>> upper > >>> bound. > >>> > >>> GV> I changed the line to make it more clear that the timer indicates > the > >>> maximum Advertisement Interval > >>> GV> Maximum IPv6 Router Advertisement Interval = 300s > >>> > >>> ------------------------------------------------------------ > ---------- > >>> COMMENT: > >>> ------------------------------------------------------------ > ---------- > >>> > >>> * Section 4 > >>> > >>> -> I think text is needed here to handle the case where the DNS > server is > >>> provided in the RA itself (RFC8106) > >>> > >>> "In addition it will use stateless DHCPv6 to get the IPv6 address > of the > >>> DNS > >>> server" > >>> > >>> -> I am not sure what is the motivation for this text. > >>> > >>> "however it SHOULD NOT use stateful DHCPv6 to receive a service > provider > >>> managed IPv6 address" > >>> > >>> -> This text seems incorrect > >>> > >>> "due to the L-bit set, it SHOULD send this traffic to the First Hop > >>> Provider > >>> Router" > >>> > >>> I think it should be the exact opposite. i.e. say *unset* instead > of set > >>> > >>> "due to the L-bit being unset, it SHOULD send this traffic to the > First > >>> Hop > >>> Provider Router" > >>> > >>> GV> What about the following modification in the text: > >>> > >>> OLD: > >>> The architected result of designing the RA as documented above is > >>> that each UE/subscriber gets its own unique IPv6 prefix for which it > >>> can use SLAAC or any other method to select its /128 unique address. > >>> In addition it will use stateless DHCPv6 to get the IPv6 address of > >>> the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive > >>> a service provider managed IPv6 address. If the UE/subscriber > >>> desires to send anything external including other UE/subscriber > >>> devices (assuming device to device communications is enabled and > >>> supported), then, due to the L-bit set, it SHOULD send this traffic > >>> to the First Hop Provider Router. > >>> > >>> New: > >>> The architected result of designing the RA as documented above is > >>> that each UE/subscriber gets its own unique IPv6 prefix for which it > >>> can use SLAAC or any other method to select its /128 unique address. > >>> Either stateless DHCPv6 RFC3736 or IPv6 > >>> Router Advertisement Options for DNS Configuration > >>> RFC8106 can be used to get the > >>> IPv6 address of the DNS server. If the UE/subscriber desires to send > >>> anything external including other UE/subscriber devices (assuming > device > >>> to device communications is enabled and supported), then, due to the > >>> L-bit being unset, it SHOULD send this traffic to the First Hop > Provider > >>> Router. > >>> > >>> > >>> > >>> Kind Regards, > >>> G/ > >>> > >>> > >> > >> > >> > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c061b4c91ece70558cb4fe0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Warren,

care to summarize the main issu= es that caused you to do this? We'll want to make sure we don't spe= nd too much time discussing issues that did not materially impact this deci= sion.

Cheers,
Lorenzo

On Sun, Sep 10, 2017 at = 4:49 AM, Warren Kumari <warren@kumari.net> wrote:
[ Top-post ]

Yup, I was thinking that, while substantive, that would be handled
while still keeping it in IESG eval -- but, I've just gone back and
re-read the threads, especially all of the mail (~102) after the IESG
/ telechat, and I've decided that I will have to return it to the WG. Seeing as it has already had a WGLC, I expect that the next one can be
compressed.

The good news is that a: there have been a number of suggestions /
provided text to improve the document, and b: I'd expect the next IESG<= br> eval to go easily.

Sorry all,
W


On Mon, Sep 4, 2017 at 6:32 PM, Brian E Carpenter
<brian.e.carpenter@gmail.= com> wrote:
> Warren,
>
> I believe it's substantive that the text refers to sending unicast=
> RAs without clarifying whether this means that they are sent
> with a unicast layer 2 address and a multicast layer 3 address
> (as per RFC6085) or that they are sent with both layer 2 and
> layer 3 addresses being unicast. At the moment, an implementer
> has to decide which of these is intended. If either is OK,
> that could be stated too.
>
> Specifically this clarification seems to be needed right after:
>
>> 4.=C2=A0 IPv6 Unique Prefix Assignment
>>
>>=C2=A0 =C2=A0 When a UE connects to the shared provider managed net= work and is
>>=C2=A0 =C2=A0 attached, it will initiate IP configuration phase.=C2= =A0 During this phase
>>=C2=A0 =C2=A0 the UE will, from an IPv6 perspective, attempt to lea= rn the default
>>=C2=A0 =C2=A0 IPv6 gateway, the IPv6 prefix information, the DNS in= formation
>>=C2=A0 =C2=A0 RFC8106 [RFC8106], and the remaining information requ= ired to
>>=C2=A0 =C2=A0 establish globally routable IPv6 connectivity.=C2=A0 = For that purpose, the
>>=C2=A0 =C2=A0 the UE/subscriber sends a RS (Router Solicitation) me= ssage.
>>
>>=C2=A0 =C2=A0 The First Hop Router receives this UE/subscriber RS m= essage and
>>=C2=A0 =C2=A0 starts the process to compose the response to the UE/= subscriber
>>=C2=A0 =C2=A0 originated RS message.=C2=A0 The First Hop Provider R= outer will answer
>>=C2=A0 =C2=A0 using a unicast RA (Router Advertisement) to the UE/s= ubscriber.
>
> Regards
>=C2=A0 =C2=A0 Brian Carpenter
>
> On 05/09/2017 09:43, Warren Kumari wrote:
>> I'd like to note that that there is continuing discussion on t= his
>> draft on the v6 ops list (yup, after WGLC and IETF LC :-)). I'= ve only
>> been able to somewhat monitor it, but have asked the v6ops chairs = for
>> input. Much of the discussion has been interesting, but not
>> necessarily pertaining exactly to this document.
>> Fred kindly asked the list:
>> https://mailarchive.= ietf.org/arch/msg/v6ops/bpEDtnYkbvJQZAx_r6mtEhdNxrw
>> for anything substantive for the document (keeping in mind that it= has
>> already gone through WGLC and IETF LC).
>>
>> So far it doesn't seem like there are any other major changes = needed,
>> other than "asking that the applicability comment that commun= ication
>> between such nodes on a LAN should go through a connecting router<= br> >> (which seems to me a given due to the relationship with routing) >> should be documented." and David Farmer's followup --
>> https://mailarchive.= ietf.org/arch/msg/v6ops/_-QlBqGk9dChoFOhxigf5WlxYDY
>>
>> Does anyone have anything else *substantive*? If so, I may have to=
>> kick this back to the WG for another round.
>>
>> W
>>
>>
>>
>>
>> On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan
>> <suresh.krishnan@g= mail.com> wrote:
>>> Hi Gunter,
>>>=C2=A0 =C2=A0Thanks for the proposed text changes. They adequat= ely address my DISCUSS
>>> points. I am hoping you will also converge in the discussion w= ith Lorenzo on
>>> the actual value for the timer and/or specify an applicability= statement. I
>>> will clear once the new revision posts.
>>>
>>> Regards
>>> Suresh
>>>
>>> On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/= Antwerp)
>>> <gunter.va= n_de_velde@nokia.com> wrote:
>>>
>>> Hi Suresh,
>>>
>>> Many thanks for the review and finding these issues. What do y= ou think of
>>> the proposals below to fix those points of attention?
>>>
>>>=C2=A0 =C2=A0 --------------------------------------------= --------------------------
>>>=C2=A0 =C2=A0 DISCUSS:
>>>=C2=A0 =C2=A0 --------------------------------------------= --------------------------
>>>
>>>=C2=A0 =C2=A0 * Section 4
>>>
>>>=C2=A0 =C2=A0 It is not clear what you intend here
>>>
>>>=C2=A0 =C2=A0 "IPv6 Router Advertisement Interval =3D 300s= "
>>>
>>>=C2=A0 =C2=A0 The router advertisement interval is not configur= ed as an absolute value
>>> but as
>>>=C2=A0 =C2=A0 minimum and maximum bounds (MinRtrAdvInterval and= MaxRtrAdvInterval)
>>> which are
>>>=C2=A0 =C2=A0 used to calculate the actual advertisement interv= al. When the RA is sent
>>> from
>>>=C2=A0 =C2=A0 an interface, the actual interval is an uniformly= distributed random
>>> value
>>>=C2=A0 =C2=A0 between the MinRtrAdvInterval and MaxRtrAdvInterv= al. At the very minimum
>>> you
>>>=C2=A0 =C2=A0 need to clarify if you would like to have this as= a lower bound or as an
>>> upper
>>>=C2=A0 =C2=A0 bound.
>>>
>>> GV> I changed the line to make it more clear that the timer= indicates the
>>> maximum Advertisement Interval
>>> GV>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <t>Maximum IPv6= Router Advertisement Interval =3D 300s</t>
>>>
>>>=C2=A0 =C2=A0 --------------------------------------------= --------------------------
>>>=C2=A0 =C2=A0 COMMENT:
>>>=C2=A0 =C2=A0 --------------------------------------------= --------------------------
>>>
>>>=C2=A0 =C2=A0 * Section 4
>>>
>>>=C2=A0 =C2=A0 -> I think text is needed here to handle the c= ase where the DNS server is
>>>=C2=A0 =C2=A0 provided in the RA itself=C2=A0 (RFC8106)
>>>
>>>=C2=A0 =C2=A0 "In addition it will use stateless DHCPv6 to= get the IPv6 address of the
>>> DNS
>>>=C2=A0 =C2=A0 server"
>>>
>>>=C2=A0 =C2=A0 -> I am not sure what is the motivation for th= is text.
>>>
>>>=C2=A0 =C2=A0 "however it SHOULD NOT use stateful DHCPv6 t= o receive a service provider
>>>=C2=A0 =C2=A0 managed IPv6 address"
>>>
>>>=C2=A0 =C2=A0 -> This text seems incorrect
>>>
>>>=C2=A0 =C2=A0 "due to the L-bit set, it SHOULD send this t= raffic to the First Hop
>>> Provider
>>>=C2=A0 =C2=A0 Router"
>>>
>>>=C2=A0 =C2=A0 I think it should be the exact opposite. i.e. say= *unset* instead of set
>>>
>>>=C2=A0 =C2=A0 "due to the L-bit being unset, it SHOULD sen= d this traffic to the First
>>> Hop
>>>=C2=A0 =C2=A0 Provider Router"
>>>
>>> GV> What about the following modification in the text:
>>>
>>> OLD:
>>> The architected result of designing the RA as documented above= is
>>>=C2=A0 =C2=A0that each UE/subscriber gets its own unique IPv6 p= refix for which it
>>>=C2=A0 =C2=A0can use SLAAC or any other method to select its /1= 28 unique address.
>>>=C2=A0 =C2=A0In addition it will use stateless DHCPv6 to get th= e IPv6 address of
>>>=C2=A0 =C2=A0the DNS server, however it SHOULD NOT use stateful= DHCPv6 to receive
>>>=C2=A0 =C2=A0a service provider managed IPv6 address.=C2=A0 If = the UE/subscriber
>>>=C2=A0 =C2=A0desires to send anything external including other = UE/subscriber
>>>=C2=A0 =C2=A0devices (assuming device to device communications = is enabled and
>>>=C2=A0 =C2=A0supported), then, due to the L-bit set, it SHOULD = send this traffic
>>>=C2=A0 =C2=A0to the First Hop Provider Router.
>>>
>>> New:
>>> The architected result of designing the RA as documented above= is
>>> that each UE/subscriber gets its own unique IPv6 prefix for wh= ich it
>>> can use SLAAC or any other method to select its /128 unique ad= dress.
>>> Either stateless DHCPv6 <xref target=3D"RFC3736"&= gt;RFC3736</xref> or IPv6
>>> Router Advertisement Options for DNS Configuration
>>> <xref target=3D"RFC8106">RFC8106</xref= > can be used to get the
>>> IPv6 address of the DNS server. If the UE/subscriber desires t= o send
>>> anything external including other UE/subscriber devices (assum= ing device
>>> to device communications is enabled and supported), then, due = to the
>>> L-bit being unset, it SHOULD send this traffic to the First Ho= p Provider
>>> Router.</t>
>>>
>>>
>>>
>>> Kind Regards,
>>> G/
>>>
>>>
>>
>>
>>



--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
=C2=A0 =C2=A0---maf

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

--94eb2c061b4c91ece70558cb4fe0-- From nobody Sun Sep 10 14:05:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B33E13291C for ; Sun, 10 Sep 2017 14:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOOU8gj18xpG for ; Sun, 10 Sep 2017 14:05:23 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31D301243F6 for ; Sun, 10 Sep 2017 14:05:23 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id a43so11261250wrc.0 for ; Sun, 10 Sep 2017 14:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=17gkIvD90RJae9BcZC0NDqCqAB33eLiGBPT9t+JRdX4=; b=KJ/INY6zonMn7xpi+F2F+6xjFZvhrlDBw2mjyFymukQid4d+ddYUjxUj9syHWbtECU RcKVWZGnbCdvlUd0ScHAnmrgUxSwixi7ut7bLV1QjKG5cgCNYRQ/DMVOr+3gQZKwJJmD AZgkAnJuXLxThViNJ3MwapgWAhwoTKSz4+wsqDZRWlqsNFVrh7ytd3B8l0si7880O2Eb jMFxAfDxMTSWVmk27XwBVjkoZzLFbjFK5IWvA8xBJ1c4zZLeTTY06zn01U/d7bZznXOu ChPAjQSMAieZFKHOME9PXszuGv7TCDrSslHXG5aEs07C0aFMcIJoxTRu+D5Eo4mh9XKm ucCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=17gkIvD90RJae9BcZC0NDqCqAB33eLiGBPT9t+JRdX4=; b=o9+gkMWAB2PMt5RvGUbmjGr9Yi6DBjslqGw1YIs0VEY7JYxixeZrcsFsL95OGgASb8 5EpIGTgZPzVWR/AVGC+X+ic31ukexgP8fA9IVK0/k5upN2nLEi9rwfgEH9b0fDehxr2z oQGxPekL82y3qtas5HUs7tbYCEaTR7LOwUQHBew1XcD039Ji5arGbs6SeIRduru5DpHS EcXkP5SxkUiXgjUGxJFgFqhBecPw/X1HQKhwFTiVm1ROmjum0MlMJv5oDpYZmgIvoR4c pIv0WHYZWT9MxSVxH8F7I1fvj8X0WtOGbZ5DGIHqCcskF+Rcl2lss+pAefey8uyAePuB C9jQ== X-Gm-Message-State: AHPjjUh8ESCzjdBsmXglpW/Q6gFgdMiyyQam/hAVsflJA/N9nB+S88cD miYnNjDxAhJ3YEeWT1WRGmR8C/Rgjjr6 X-Google-Smtp-Source: ADKCNb6FU09E18sbBwwNOTm6ZFeKS/dJbv6bfqYZxbR6l2zx5jOwCbzmXETd3xxBCZUfxQ6HD0CfoVDODOBRebP+bmU= X-Received: by 10.223.133.147 with SMTP id 19mr6907467wrt.184.1505077521073; Sun, 10 Sep 2017 14:05:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.141 with HTTP; Sun, 10 Sep 2017 14:04:40 -0700 (PDT) In-Reply-To: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Sun, 10 Sep 2017 17:04:40 -0400 Message-ID: To: Lorenzo Colitti Cc: Brian E Carpenter , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , Suresh Krishnan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Sep 2017 21:05:26 -0000 [ - IESG, -Gunter (he gets a copy as part of draft-ietf-v6ops-unique-ipv6-prefix-per-host@), -v6chairs@ ] On Sat, Sep 9, 2017 at 8:58 PM, Lorenzo Colitti wrote: > Warren, > > care to summarize the main issues that caused you to do this? We'll want = to > make sure we don't spend too much time discussing issues that did not > materially impact this decision. > Sure. During IESG review, some of the IESG raised questions and suggested text to improve the document. We received responses from the authors saying that the questions, along with Suresh's DISCUSS, would be addressed. We did not see an updated draft, and it's difficult to keep the patched version in one's head. So, I don't know exactly what it looks like now, but here are some of the considerations that influenced my decision: 1: Brian Carpenter's: "I believe it's substantive that the text refers to sending unicast RAs without clarifying whether this means that they are sent with a unicast layer 2 address and a multicast layer 3 address (as per RFC6085) or that they are sent with both layer 2 and layer 3 addresses being unicast. At the moment, an implementer has to decide which of these is intended. If either is OK, that could be stated too.". 2: Fred Templin's "unless the shared network explicitly permits peer-to-peer operations" -- in my view adding this exact text didn't seem to have support, but clarifying what is meant by a "shared network" would be useful. This was also mentioned in EKR's ballot -- ballot text is all below (I don't want it to get lost when being LCed). 3: I do not believe that I ever saw a resolution to Lorenzo's "I'll also point out yet again that this value is in conflict with RFC 7772 in the case of networks that are provide service for battery-powered devices. The text should either be changed to follow that RFC or to explain the reason for the conflict." -- I personally don't care what the value is (I wasn't really thinking that this would occur much on battery-powered devices, but I may be completely wrong), but I *do* think that if it conflicts with RFC 7772 it needs to note this. 4: Much of the thread above David Farmer's https://mailarchive.ietf.org/arch/msg/v6ops/i72cb0r6fVbxhZLhr4qybppwP6Q 5: Simply the amount of discussion after IESG eval, and IETF LC (I think that the number is something like 100 and >350 respectively) -- while many of them wandered afar from the actual draft (and, often, topic :-)) it is hard to make the claim that the document is really clear and has strong consensus from this. I'd note that #1, 2, and 4 are very closely related, and I think should be fairly easily addressed. I'm also happy for the chairs to have a compressed 2 WGLC (if they think appropriate). Incidentally (but in no way relevant), I happen to really like the idea / document, and would like to see it published (soon!). w -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Copy-n-paste of b= allot =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Suresh KrishnanDiscuss Discuss (2017-08-16) * Section 4 It is not clear what you intend here "IPv6 Router Advertisement Interval =3D 300s" The router advertisement interval is not configured as an absolute value but as minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval) which are used to calculate the actual advertisement interval. When the RA is sent from an interface, the actual interval is an uniformly distributed random value between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum you need to clarify if you would like to have this as a lower bound or as an upper bound. Comment (2017-08-16) * Section 4 -> I think text is needed here to handle the case where the DNS server is provided in the RA itself (RFC8106) "In addition it will use stateless DHCPv6 to get the IPv6 address of the DNS server" -> I am not sure what is the motivation for this text. "however it SHOULD NOT use stateful DHCPv6 to receive a service provider managed IPv6 address" -> This text seems incorrect "due to the L-bit set, it SHOULD send this traffic to the First Hop Provider Router" I think it should be the exact opposite. i.e. say *unset* instead of set "due to the L-bit being unset, it SHOULD send this traffic to the First Hop Provider Router" Warren KumariYes Deborah BrungardNo Objection Ben CampbellNo Objection Comment (2017-08-16) I have no technical comments, but a number of editorial comments: - General: I think this could use another proofreading and/or editing pass for the following issues: -- Inconsistent tense--especially use of future or present continuous. -- Wordy and convoluted sentences -- Use of "/" as a conjunction. - Abstract: The abstract is longer and more detailed than is useful. The last paragraph could have stood alone as the abstract. It's not clear to me if "hosts (subscribers)" means something different than "hosts" in context. -1: Please expand "IA_NA" on first use. s/"This document will focus..."/"This document focuses..." "As such the use of IPv6 SLAAC based subscriber and address management for provider managed shared network services is the recommended technology of choice, as it does not exclude any known IPv6 implementation." Does this document make that recommendation, or is that some pre-existing recommendation? -3: "The Best Current Practice documented in this note is to provide a unique IPv6 prefix to hosts/subscribers devices connected to the provider managed shared network." The sentence hard to follow. Consider "This document recommends...". I'm not sure how to interpret "hosts/subscribers devices" "Each unique IPv6 prefix can function as control-plane anchor point to make sure that each subscriber is receiving" s/"... subscriber is receiving ..."/"... subscriber receives..." -4: Is "First Hop Provider Router" different than "First Hop Router"? In the last bullet (L-flag=3D0), are NEVER and ALWAYS in all-caps expected to have different meaning than if they had normal capitalization? The sentence starting with "The architected result of designing the RA as documented above..." is convoluted and hard to follow. "... however it SHOULD NOT use stateful DHCPv6 to receive a service provider managed IPv6 address": Is that really a normative requirement, or is it a statement of fact about existing requirements? "it SHOULD send this traffic to the First Hop Provider Router." : statement of fact? - 5: "To reduce undesired resource consumption on the First Hop Router the desire is to remove UE/subscriber context in the case of non-permanent UE, such as in the case of WiFi hotspots as quickly as possible. " Convoluted sentence. "A possible solution is to use a subscriber inactivity timer which, after tracking a pre-defined (currently unspecified) number of minutes, deletes the subscriber context on the First Hop Router." s/which/that (Consider " ... timer that deletes...after a predetermined number of minutes" -7: "The combination of both IPv6 privacy extensions and operator based assignment of a Unique IPv6 Prefix per Host provides each implementing operator a tool to manage and provide subscriber services and hence reduces the experienced privacy within each operator controlled domain." I have trouble following that sentence. Is the point to say that providing tools to manage and provide services reduces privacy in general? As worded, it almost sounds like this is meant as a feature, which I assume is not the case. Spencer DawkinsNo Objection Comment (2017-08-15) One nit: Please consider moving Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. to the first paragraph of the Abstract. I=E2=80=99m assuming that this explains the =E2=80=9Cneeds that have arisen=E2=80=9D in the first sentence= of the Abstract, of course. Mirja K=C3=BChlewindNo Objection Comment (2017-08-14) To me this seems approriate for BCP; I'm saying this because this was mentioned in the shepherd-write-up as it was brought up by the gen-art review. Please also consider the following comment from the gen-art review (Thanks Joel!): "The issue of status for the document (BCP vs Informational) is for the IES= G to conclude. However, even if it is a BCP, as I understand the purpose, this document is intended to describe the practices to be used when a provider has decided to deploy a /64 per host. The wording that is chos= en throughout the document makes it appear that the underlying decision abo= ut such a deployment is also a recommended practice." I agree that wording could be made clearer here! Alexey MelnikovNo Objection Comment (2017-08-12) Radius should have an informative reference on first use. Kathleen MoriartyNo Objection Comment (2017-08-15) Thank you for addressing the SecDir review: https://mailarchive.ietf.org/arch/msg/secdir/wWp_0vlmsz7Ss-nowjhehYImOeg Eric RescorlaNo Objection Comment (2017-08-15) Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt I found the discussion of the shared network medium a bit confusing. As I understand it, the idea is that if we are on a shared network and we have the same prefix, I might try to send to you directly. What you want to do is make that not happen by having each node have a separate prefix. Correct? If so, perhaps promote this bullet, and also have it describe the problem and why this provides a solution: o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router It's a bit unclear to me how much you are saying that something is current practice versus how much you are recommending it. For instance, the abstract reads more like what you would expect for PS. This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management. But then S 4 seems to be documenting: The IPv6 RA flags used for best common practice in IPv6 SLAAC based Provider managed shared networks are: The use of a unique IPv6 prefix per UE adds an additional level of protection and efficiency as it relates to how IPv6 Neighbor Discovery and Router Discovery processing. Since the UE has a unique IPv6 prefix all traffic by default will be directed to the First Hop provider router. Further, the flag combinations documented above maximise the IPv6 configurations that are available by hosts including the use of privacy IPv6 addressing. It's not quite clear to me why unique prefixs are needed here if people set L=3D0. Is it that people ignore L=3D0? Finally, I'm a bit confused about how to read this text about the L=3D0 bit in cases where I have multiple devices rather than just one at the customer prem. Say I have a topology with a home router and devices behind it. I.e., Service Provider | | Customer Router | +-----------+-----------+ | | | Host 1 Host 2 Host 3 I assume what happens here is that the router gets prefix X, assigns itself XY, and then the Hosts get XA, XB, XC, etc, a la 7278. Is that right? If so, my question is about packets coming into the Router from the SP, which have (say) XA. The text about the L-flag suggests that the router should send them back to the gateway, but that's clearly not right. What am I missing? > Cheers, > Lorenzo > > On Sun, Sep 10, 2017 at 4:49 AM, Warren Kumari wrote: >> >> [ Top-post ] >> >> Yup, I was thinking that, while substantive, that would be handled >> while still keeping it in IESG eval -- but, I've just gone back and >> re-read the threads, especially all of the mail (~102) after the IESG >> / telechat, and I've decided that I will have to return it to the WG. >> Seeing as it has already had a WGLC, I expect that the next one can be >> compressed. >> >> The good news is that a: there have been a number of suggestions / >> provided text to improve the document, and b: I'd expect the next IESG >> eval to go easily. >> >> Sorry all, >> W >> >> >> On Mon, Sep 4, 2017 at 6:32 PM, Brian E Carpenter >> wrote: >> > Warren, >> > >> > I believe it's substantive that the text refers to sending unicast >> > RAs without clarifying whether this means that they are sent >> > with a unicast layer 2 address and a multicast layer 3 address >> > (as per RFC6085) or that they are sent with both layer 2 and >> > layer 3 addresses being unicast. At the moment, an implementer >> > has to decide which of these is intended. If either is OK, >> > that could be stated too. >> > >> > Specifically this clarification seems to be needed right after: >> > >> >> 4. IPv6 Unique Prefix Assignment >> >> >> >> When a UE connects to the shared provider managed network and is >> >> attached, it will initiate IP configuration phase. During this >> >> phase >> >> the UE will, from an IPv6 perspective, attempt to learn the defaul= t >> >> IPv6 gateway, the IPv6 prefix information, the DNS information >> >> RFC8106 [RFC8106], and the remaining information required to >> >> establish globally routable IPv6 connectivity. For that purpose, >> >> the >> >> the UE/subscriber sends a RS (Router Solicitation) message. >> >> >> >> The First Hop Router receives this UE/subscriber RS message and >> >> starts the process to compose the response to the UE/subscriber >> >> originated RS message. The First Hop Provider Router will answer >> >> using a unicast RA (Router Advertisement) to the UE/subscriber. >> > >> > Regards >> > Brian Carpenter >> > >> > On 05/09/2017 09:43, Warren Kumari wrote: >> >> I'd like to note that that there is continuing discussion on this >> >> draft on the v6 ops list (yup, after WGLC and IETF LC :-)). I've only >> >> been able to somewhat monitor it, but have asked the v6ops chairs for >> >> input. Much of the discussion has been interesting, but not >> >> necessarily pertaining exactly to this document. >> >> Fred kindly asked the list: >> >> https://mailarchive.ietf.org/arch/msg/v6ops/bpEDtnYkbvJQZAx_r6mtEhdNx= rw >> >> for anything substantive for the document (keeping in mind that it ha= s >> >> already gone through WGLC and IETF LC). >> >> >> >> So far it doesn't seem like there are any other major changes needed, >> >> other than "asking that the applicability comment that communication >> >> between such nodes on a LAN should go through a connecting router >> >> (which seems to me a given due to the relationship with routing) >> >> should be documented." and David Farmer's followup -- >> >> https://mailarchive.ietf.org/arch/msg/v6ops/_-QlBqGk9dChoFOhxigf5WlxY= DY >> >> >> >> Does anyone have anything else *substantive*? If so, I may have to >> >> kick this back to the WG for another round. >> >> >> >> W >> >> >> >> >> >> >> >> >> >> On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan >> >> wrote: >> >>> Hi Gunter, >> >>> Thanks for the proposed text changes. They adequately address my >> >>> DISCUSS >> >>> points. I am hoping you will also converge in the discussion with >> >>> Lorenzo on >> >>> the actual value for the timer and/or specify an applicability >> >>> statement. I >> >>> will clear once the new revision posts. >> >>> >> >>> Regards >> >>> Suresh >> >>> >> >>> On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwer= p) >> >>> wrote: >> >>> >> >>> Hi Suresh, >> >>> >> >>> Many thanks for the review and finding these issues. What do you thi= nk >> >>> of >> >>> the proposals below to fix those points of attention? >> >>> >> >>> >> >>> --------------------------------------------------------------------= -- >> >>> DISCUSS: >> >>> >> >>> --------------------------------------------------------------------= -- >> >>> >> >>> * Section 4 >> >>> >> >>> It is not clear what you intend here >> >>> >> >>> "IPv6 Router Advertisement Interval =3D 300s" >> >>> >> >>> The router advertisement interval is not configured as an absolut= e >> >>> value >> >>> but as >> >>> minimum and maximum bounds (MinRtrAdvInterval and >> >>> MaxRtrAdvInterval) >> >>> which are >> >>> used to calculate the actual advertisement interval. When the RA = is >> >>> sent >> >>> from >> >>> an interface, the actual interval is an uniformly distributed >> >>> random >> >>> value >> >>> between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very >> >>> minimum >> >>> you >> >>> need to clarify if you would like to have this as a lower bound o= r >> >>> as an >> >>> upper >> >>> bound. >> >>> >> >>> GV> I changed the line to make it more clear that the timer indicate= s >> >>> the >> >>> maximum Advertisement Interval >> >>> GV> Maximum IPv6 Router Advertisement Interval =3D 300s<= /t> >> >>> >> >>> >> >>> --------------------------------------------------------------------= -- >> >>> COMMENT: >> >>> >> >>> --------------------------------------------------------------------= -- >> >>> >> >>> * Section 4 >> >>> >> >>> -> I think text is needed here to handle the case where the DNS >> >>> server is >> >>> provided in the RA itself (RFC8106) >> >>> >> >>> "In addition it will use stateless DHCPv6 to get the IPv6 address >> >>> of the >> >>> DNS >> >>> server" >> >>> >> >>> -> I am not sure what is the motivation for this text. >> >>> >> >>> "however it SHOULD NOT use stateful DHCPv6 to receive a service >> >>> provider >> >>> managed IPv6 address" >> >>> >> >>> -> This text seems incorrect >> >>> >> >>> "due to the L-bit set, it SHOULD send this traffic to the First H= op >> >>> Provider >> >>> Router" >> >>> >> >>> I think it should be the exact opposite. i.e. say *unset* instead >> >>> of set >> >>> >> >>> "due to the L-bit being unset, it SHOULD send this traffic to the >> >>> First >> >>> Hop >> >>> Provider Router" >> >>> >> >>> GV> What about the following modification in the text: >> >>> >> >>> OLD: >> >>> The architected result of designing the RA as documented above is >> >>> that each UE/subscriber gets its own unique IPv6 prefix for which = it >> >>> can use SLAAC or any other method to select its /128 unique addres= s. >> >>> In addition it will use stateless DHCPv6 to get the IPv6 address o= f >> >>> the DNS server, however it SHOULD NOT use stateful DHCPv6 to recei= ve >> >>> a service provider managed IPv6 address. If the UE/subscriber >> >>> desires to send anything external including other UE/subscriber >> >>> devices (assuming device to device communications is enabled and >> >>> supported), then, due to the L-bit set, it SHOULD send this traffi= c >> >>> to the First Hop Provider Router. >> >>> >> >>> New: >> >>> The architected result of designing the RA as documented above is >> >>> that each UE/subscriber gets its own unique IPv6 prefix for which it >> >>> can use SLAAC or any other method to select its /128 unique address. >> >>> Either stateless DHCPv6 RFC3736 or I= Pv6 >> >>> Router Advertisement Options for DNS Configuration >> >>> RFC8106 can be used to get the >> >>> IPv6 address of the DNS server. If the UE/subscriber desires to send >> >>> anything external including other UE/subscriber devices (assuming >> >>> device >> >>> to device communications is enabled and supported), then, due to the >> >>> L-bit being unset, it SHOULD send this traffic to the First Hop >> >>> Provider >> >>> Router. >> >>> >> >>> >> >>> >> >>> Kind Regards, >> >>> G/ >> >>> >> >>> >> >> >> >> >> >> >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Sep 11 00:01:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714561323B0 for ; Mon, 11 Sep 2017 00:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6xRPFhJtfzM for ; Mon, 11 Sep 2017 00:01:50 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033CD132113 for ; Mon, 11 Sep 2017 00:01:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8B71mcw010924 for ; Mon, 11 Sep 2017 09:01:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 096C5209F99 for ; Mon, 11 Sep 2017 09:01:48 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F3A68209EAE for ; Mon, 11 Sep 2017 09:01:47 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8B71lex017308 for ; Mon, 11 Sep 2017 09:01:47 +0200 To: v6ops@ietf.org References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <85f3ebd4-0493-221c-ae05-826ca02f5d2a@gmail.com> Date: Mon, 11 Sep 2017 09:01:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 07:01:52 -0000 To this Fred's point, It seemed to me obvious and did not care to reply until now. Le 05/09/2017 à 16:52, Templin, Fred L a écrit : [...] > 1) In section 2: > > " o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router" > > Please change to say: > > "o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router unless the shared network > explicitly permits peer-to-peer operations" I fully agree. And I think this is what happens in practice: on WiFi, ND multicast messages are exchanged without going to Access Router (first-hop IP router), even if the RA is unicast from the AR to individual nodes, and even if each node has a distinct /64 on same shared media. Do you think otherwise? > > 2) In Section 4: > > " If the UE/subscriber > desires to send anything external including other UE/subscriber > devices (assuming device to device communications is enabled and > supported), then, due to the L-bit set, it SHOULD send this traffic > to the First Hop Provider Router." > > Please change to: > > "If the UE/subscriber > desires to send anything external including other UE/subscriber > devices (assuming device to device communications is enabled and > supported), then, due to the L-bit set, it SHOULD send this traffic > to the First Hop Provider Router unless the shared network > explicitly permits peer-to-peer operations." Agreed, same reason as above. Alex > > --- > >> W >> >> >> >> >> On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan >> wrote: >>> Hi Gunter, >>> Thanks for the proposed text changes. They adequately address my DISCUSS >>> points. I am hoping you will also converge in the discussion with Lorenzo on >>> the actual value for the timer and/or specify an applicability statement. I >>> will clear once the new revision posts. >>> >>> Regards >>> Suresh >>> >>> On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) >>> wrote: >>> >>> Hi Suresh, >>> >>> Many thanks for the review and finding these issues. What do you think of >>> the proposals below to fix those points of attention? >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> * Section 4 >>> >>> It is not clear what you intend here >>> >>> "IPv6 Router Advertisement Interval = 300s" >>> >>> The router advertisement interval is not configured as an absolute value >>> but as >>> minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval) >>> which are >>> used to calculate the actual advertisement interval. When the RA is sent >>> from >>> an interface, the actual interval is an uniformly distributed random >>> value >>> between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum >>> you >>> need to clarify if you would like to have this as a lower bound or as an >>> upper >>> bound. >>> >>> GV> I changed the line to make it more clear that the timer indicates the >>> maximum Advertisement Interval >>> GV> Maximum IPv6 Router Advertisement Interval = 300s >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> * Section 4 >>> >>> -> I think text is needed here to handle the case where the DNS server is >>> provided in the RA itself (RFC8106) >>> >>> "In addition it will use stateless DHCPv6 to get the IPv6 address of the >>> DNS >>> server" >>> >>> -> I am not sure what is the motivation for this text. >>> >>> "however it SHOULD NOT use stateful DHCPv6 to receive a service provider >>> managed IPv6 address" >>> >>> -> This text seems incorrect >>> >>> "due to the L-bit set, it SHOULD send this traffic to the First Hop >>> Provider >>> Router" >>> >>> I think it should be the exact opposite. i.e. say *unset* instead of set >>> >>> "due to the L-bit being unset, it SHOULD send this traffic to the First >>> Hop >>> Provider Router" >>> >>> GV> What about the following modification in the text: >>> >>> OLD: >>> The architected result of designing the RA as documented above is >>> that each UE/subscriber gets its own unique IPv6 prefix for which it >>> can use SLAAC or any other method to select its /128 unique address. >>> In addition it will use stateless DHCPv6 to get the IPv6 address of >>> the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive >>> a service provider managed IPv6 address. If the UE/subscriber >>> desires to send anything external including other UE/subscriber >>> devices (assuming device to device communications is enabled and >>> supported), then, due to the L-bit set, it SHOULD send this traffic >>> to the First Hop Provider Router. >>> >>> New: >>> The architected result of designing the RA as documented above is >>> that each UE/subscriber gets its own unique IPv6 prefix for which it >>> can use SLAAC or any other method to select its /128 unique address. >>> Either stateless DHCPv6 RFC3736 or IPv6 >>> Router Advertisement Options for DNS Configuration >>> RFC8106 can be used to get the >>> IPv6 address of the DNS server. If the UE/subscriber desires to send >>> anything external including other UE/subscriber devices (assuming device >>> to device communications is enabled and supported), then, due to the >>> L-bit being unset, it SHOULD send this traffic to the First Hop Provider >>> Router. >>> >>> >>> >>> Kind Regards, >>> G/ >>> >>> >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> 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 Sep 11 00:17:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A467133010 for ; Mon, 11 Sep 2017 00:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvAQeKS0r8Rm for ; Mon, 11 Sep 2017 00:17:32 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864A313300C for ; Mon, 11 Sep 2017 00:17:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4BA58AF; Mon, 11 Sep 2017 09:17:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1505114250; bh=oFGUoboz9gLRbS4uEPtJDd8fo2kqhvG335ed/QB4RNI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=dDk7QwTrb8e7yA/krXTr51514mAFyrJrKUgBvnQXfyY1px47OGuKIsTcjgHCnzvFj jOApe/Y0QneWb+AL8jAzxoUZ6QjINTDaEZtPelLP9C5Xho6GbbFzKT+SEHX7MgFhJg Hdap2UtmmU/q+ahfKqPHdaJz8noWDAgQqT9BrZDY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 32A3984; Mon, 11 Sep 2017 09:17:30 +0200 (CEST) Date: Mon, 11 Sep 2017 09:17:30 +0200 (CEST) From: Mikael Abrahamsson To: Lee Howard cc: v6ops@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 07:17:34 -0000 On Fri, 8 Sep 2017, Lee Howard wrote: > Some clients interpret a lack of DHCP response as an indication that the > network is down, even if they have IPv6. Or so it is alleged; I have not > tested it myself. With modern software, this seems to work better. It was not working properly a few years back, then it was several OSes that decided that lack of IPv4 was "no network". Win10, OSX and recent Ubuntu for instance, all this this is fine. It might take a bit longer to decide this, but it still works. > How often does a DHCP client send Discover messages? > How much ARP traffic is on a network? > Do we need a way to mute this traffic, or do we just have to wait until > device manufacturers decide to stop including IPv4 in their devices? I would prefer if there was a signal to indicate "there is no IPv4 here". I'm fine if this is treated similarily to the M/O flags in IPv6 RAs, in that they're a signal and the client can choose to ignore them if it wants to. An IPv6 flag meaning something like "as far as I know, there is no IPv4 on this LAN, do what you want with this information". -- Mikael Abrahamsson email: swmike@swm.pp.se From pch-bCE2691D2@u-1.phicoh.com Mon Sep 11 05:26:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004F2133061 for ; Mon, 11 Sep 2017 05:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfjnFHWQxtTc for ; Mon, 11 Sep 2017 05:26:50 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id CC1C1133060 for ; Mon, 11 Sep 2017 05:26:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1drNnb-0000FNC; Mon, 11 Sep 2017 14:26:47 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> In-reply-to: Your message of "Sat, 9 Sep 2017 11:36:32 +1200 ." <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> Date: Mon, 11 Sep 2017 14:26:47 +0200 Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 12:28:19 -0000 > It is presumably written somwhere that a DNS resolver in a CE that > has no Internet IPv4 connectivity MUST NOT return off-site A records; > if not, it should be. That would break local validating resolvers. Personally I dislike DNS resolvers that lie, how well intentioned it may be. I guess the proper way to solve the issue of only local IPv4 connectivity is to have a DHCP option that lists which IPv4 prefixes are reachable. Then a host can avoid installing a default route but install only routes for the listed prefixes. From nobody Mon Sep 11 07:24:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F4C1326ED for ; Mon, 11 Sep 2017 07:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtaHJ0O0tD94 for ; Mon, 11 Sep 2017 07:24:53 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A08D13309E for ; Mon, 11 Sep 2017 07:24:53 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id f199so41140472wme.0 for ; Mon, 11 Sep 2017 07:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=mH2Ewba3CdSFptyKAWSJdkKXN+s8OvltxW6QAKn3fyE=; b=f8Ff1k/7CfxjWwDMmD+r4c/H+yGolSm9Svz8nLhuEM4S9J3QmPuap8N/QsF74nz6jy 5riOqetDUFVTZ4d+MVGpJAHE90NTBCA8hyHPWlMzD5xWPQKAUozdvGDzLIiY9Rrra1Ja fcFZmta9w1N2BCTm205vwrrnTHVz1c+oPhzgtoHr0P3eoaes249vk40pzU3ewm3oiqCg lOUOOSSsx88QYlHt9PbUY31mlRgjLChTHgpGScym9Pf5mH9TYxJlhsTax91wD8fk8Gjd eq8Vwn2yTZzGn6LTYmRvOSgs7439hpqJqO2CJ8oR5Xo0wzcmuDYEQaObQaGd/Y32DoYp 8sTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mH2Ewba3CdSFptyKAWSJdkKXN+s8OvltxW6QAKn3fyE=; b=A+QBDWAMKR38rwnpfLUp6TVpNZ3SGbEbm4EKQorJR28TWLhAkgFNHUpqiAPav35ST6 Y0+e9z5t/Y9h9+JoJvNuZREBgGeAFUcxE7WKJFMgwbw3DUw+8HlHEWrd2FB+zadM7+rs ig8Mh4AuFAx6sGbHxUILFADtXANB1hNOgXVx+U2PIZG5DhKuw3v2SBz/D2FRLVBIGXZW d57JW0h/h5ta6zDfCP03Xj9TCcGZM7fiCUmS+/gUGBbJ+AtYDMKjWSQcxSAq9ExKyXuB P+5oWG01O0vKrBO4KsKXu+y/N4io1/RBZCCCKeP8W3+frzPyGs9jqchww+iLXgKoL3Zn hM5A== X-Gm-Message-State: AHPjjUjRCYtNWi/WJn9P+iKAt/GMHeqelOdYGi4DfMcX4q1mpgjmaSoZ i19icEXx/PPeNXaSKGjOBVkDM8nBu8lIpu62jQ== X-Google-Smtp-Source: AOwi7QBhDueQqMB4xWckBI0axgJYQ+qvwCIcmoE1JoLo14r+qjIxLBWq4ZwJmg/EcGiPNa5zmTcnxDuo2VZ1Rw/OzGw= X-Received: by 10.28.210.204 with SMTP id j195mr7825743wmg.124.1505139891213; Mon, 11 Sep 2017 07:24:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.141 with HTTP; Mon, 11 Sep 2017 07:24:10 -0700 (PDT) From: Warren Kumari Date: Mon, 11 Sep 2017 10:24:10 -0400 Message-ID: To: draft-ietf-v6ops-rfc6555bis@ietf.org, IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] AD review of draft-ietf-v6ops-rfc6555bis. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 14:24:54 -0000 Hi, I've finished my AD review of draft-ietf-v6ops-rfc6555bis. I have only one comment / question: Section 3. Hostname Resolution Query Handling " If the AAAA response is received within the Resolution Delay period, the client immediately starts the IPv6 connection attempt. If, at the end of the Resolution Delay period, the AAAA response has not been received but the A response has been received, ..." So, let's say that at time T I fire off my queries, and 5ms later I get back a valid A record, and a NOERROR/NODATA response to the AAAA query (saying that there is no AAAA record) -- what do I do? I'm assuming that I just connect with the A record immediately, but this isn't actually stated anywhere (or, if it is, I missed it) - this seems like a common case, and should at least be mentioned. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Sep 11 10:15:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDA7133186 for ; Mon, 11 Sep 2017 10:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RmPUz_MEFYa0 for ; Mon, 11 Sep 2017 10:15:10 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DE7132EBB for ; Mon, 11 Sep 2017 10:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1505150110; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=z6AF9MX9hAZSZbS/yHCreNOmRpUymBjlcwtLbFZLJkM=; b=0pHKpPrATFlc3VtkiM+j+tHbPaXFHFljfhSmXDbA3HjVWvrK6mo7MZPbIgPXA0xB l6Kj8yC2i3e2j/4vRPjFD+NRMouDdWZw8Xm6JFGFpvNc4XSRMF74c6a/4qzQ2Z0r XAQv++MI0iR9969OGAzo9sXWnL2TQBAqVnT3n4xKZdrqJaY25jRsqsyJB7NVT443 /ASaIR2IcEahqoL5PWZ0J/26qg6N4hFmKXryeR1W3tzEMaTcBklguK56GwPxdfgD N2GZnPx8oPrGz+h+U7pKb9vmjTNlscgLEXGwq68ewNO/CUVhGpcspcCUFwMO78pf +ci1LU0bkUrAFuL5rJrjUw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 66.9D.28433.E94C6B95; Mon, 11 Sep 2017 10:15:10 -0700 (PDT) X-AuditID: 11973e11-c4e0f9c000006f11-2b-59b6c49e54c3 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay2.apple.com (Apple SCV relay) with SMTP id D7.7C.09069.E94C6B95; Mon, 11 Sep 2017 10:15:10 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.20.217] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OW4009W2L99XF80@nwk-mmpp-sz12.apple.com>; Mon, 11 Sep 2017 10:15:10 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Mon, 11 Sep 2017 10:15:08 -0700 Cc: draft-ietf-v6ops-rfc6555bis@ietf.org, IPv6 Operations Message-id: References: To: Warren Kumari X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUi2FDorDvvyLZIg3mbJC0O/5rJYnH62F5m i8PHLjM5MHssWfKTyeP2jT/sAUxRXDYpqTmZZalF+nYJXBnfeu4yFRzhrTjf+Ja9gfEcVxcj J4eEgInE/4sn2boYuTiEBFYzSWzftJ8NJtF16CsrROIQo8Sk7YfZQRK8AoISPybfY+li5OBg FpCXOHheFiTMLKAl8f1RKwtE/VdGiZcPzrCB1AgLSEhs3pMIUiMsYCbR1LgEbAybgIrE8W8b mEFsToFgia5Nd5hAbBYBVYm/O5cxQsz0kti/cjEjxFobiZfPfoHZQgIBEmsenQCbIwJU37hg PzvIKgkBWYmlf0JATpAQmMAmcb7rC+sERuFZSK6ehXD1LCRXL2BkXsUolJuYmaObmWekl1hQ kJOql5yfu4kRFODT7QR3MB5fZXWIUYCDUYmHV6N7W6QQa2JZcWXuIUZpDhYlcV5Vnc2RQgLp iSWp2ampBalF8UWlOanFhxiZODilGhjn/Xfn8uo4zSl2wFsjnP+4Us/ewHuOp5ecFypn7OFS uF23/UDjbJ6rdw6Gxy2d/Cve9P7/qQs1vu3f/2Rh8E12YTMulYvSmSvu3j8wM+rsr1lPpf8V LVQw4+J2OKM8N+Tf8Q+7lIITM4X+GSSqusxSybq/5Wzwvb7a+7zn1zZI8euy1IjZ+DIqsRRn JBpqMRcVJwIAI7T8a1ECAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FB8RnfekW2RBsd/iVkc/jWTxeL0sb3M FoePXWZyYPZYsuQnk8ftG3/YA5iiuGxSUnMyy1KL9O0SuDK+9dxlKjjCW3G+8S17A+M5ri5G Tg4JAROJrkNfWbsYuTiEBA4xSkzafpgdJMErICjxY/I9li5GDg5mAXmJg+dlQcLMAloS3x+1 skDUf2WUePngDBtIjbCAhMTmPYkgNcICZhJNjUvAxrAJqEgc/7aBGcTmFAiW6Np0hwnEZhFQ lfi7cxkjxEwvif0rFzNCrLWRePnsF5gtJBAgsebRCbA5IkD1jQv2s4OskhCQlVj6J2QCo8As JIfOQjh0FpJDFzAyr2IUKErNSaw00kssKMhJ1UvOz93ECA7IQucdjMeWWR1iFOBgVOLhbejd FinEmlhWXJkLDAkOZiUR3u97gUK8KYmVValF+fFFpTmpxYcYpTlYlMR5505fHykkkJ5Ykpqd mlqQWgSTZeLglGpglLn45vQt4SnPuHfUOPHYmGoL/zORjn9z6snXt+FKv/NbpQ6JyH7Srflk eeTZMZvYdz+m98aV6YTvlLrR1Zl9ZzO3slFN/ql9C+4WXXbLKXk0+Y/aJv59Uz+qKM1pXat0 f9+xqb0PFyetntZwsm1B/3d2J0XWrROq3/xbXqv5serP5F3+sx/NkVBiKc5INNRiLipOBACg fNFQRAIAAA== Archived-At: Subject: Re: [v6ops] AD review of draft-ietf-v6ops-rfc6555bis. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 17:15:12 -0000 Hi Warren, Thanks for the review! You're absolutely correct that a negative query response counts to stop any delays, etc. I don't think this is pointed out explicitly. The way I would propose solving this would be to clarify in Section 3 around the parts that read "if the AAAA query returns first" and "If the A query returns first", that any the responses we are referring to include positive answers as well as negative answers like NODATA. Does that sound good to you? Thanks, Tommy > On Sep 11, 2017, at 7:24 AM, Warren Kumari wrote: > > Hi, > > I've finished my AD review of draft-ietf-v6ops-rfc6555bis. > > I have only one comment / question: > Section 3. Hostname Resolution Query Handling > " If the AAAA response is received within the Resolution Delay period, > the client immediately starts the IPv6 connection attempt. If, at the > end of the Resolution Delay period, the AAAA response has not been > received but the A response has been received, ..." > > So, let's say that at time T I fire off my queries, and 5ms later I > get back a valid A record, and a NOERROR/NODATA response to the AAAA > query (saying that there is no AAAA record) -- what do I do? > I'm assuming that I just connect with the A record immediately, but > this isn't actually stated anywhere (or, if it is, I missed it) - this > seems like a common case, and should at least be mentioned. > > W > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf From nobody Mon Sep 11 11:06:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0486B132EC2 for ; Mon, 11 Sep 2017 11:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HSKhD8QGscr for ; Mon, 11 Sep 2017 11:05:56 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAB01331A3 for ; Mon, 11 Sep 2017 11:05:56 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id 189so10572808wmh.1 for ; Mon, 11 Sep 2017 11:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UlLEP2OVYEx45msQMXV8Tl6Y4yzfZaP2z0aPIPbEfmo=; b=U1ae95TL+LIGnJfF8YQsJ5/p0CTGcJi5tKDTWsrGVs7Py+EJeHoCWyvF3Nej/kVWOp R4X3T5Jbq0400QN1vhdQtN26NmSFewoKM7K+9+BdyhOwkSH5FrLj6B0PVscyrVhEETOs czfxfQoadFLsLTr7pmFpwnxq2Nc6+Jes19IKJzA2D0h40JDQW/o77YiEiOSRvsA8+Pux eLYVYWU2Pq7Gx5hRdVRkzAhvGIcAbD+32aM3MVMIzOpDVlvxX6mLXrdrwr/Vui6o0JnU meUE7cLGA1f4EY+Du+Q8B+3Y+N3rcDZP4If/KRVwAyDqy22D+2XSfglBc4XWCtyKT/Mx 7CiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UlLEP2OVYEx45msQMXV8Tl6Y4yzfZaP2z0aPIPbEfmo=; b=WQxb7WDGdzeuw67aIiWn+ursxsDWEQkcZacV+sdnFmZO5uvJA8r0oIHzArdyVE71nx JFnf6MD9xNrk+bNrORhzlm4grA+R9SKcw6+HDEzp9zAr/iCYa0xcn5f4nBo8QqxCNLP7 GnT6Afbp7GnYQX4Aps3LAnji747X7Tx6OXVsP8oKOpTDrnBzzfTBYg9jI3DXMPTreRHx +hyyeyJ+hIdMF55GseeZbEL9gqjAOFEymJaWDFJVbXfr3OKJCMhUArRmh40phPoEITur +nx401CLFqYlz+bFZJIuTeUDg1QCym2KF2Cutl764B74NCQ33IBRcFbToCrQFyeHp6hL oBNA== X-Gm-Message-State: AHPjjUgHDfxzIiC37guZrtXWOchX5pPMpe2hfnv9eq4+LkQ2KHVI3DQa LF16dURBS7M6ds8PLk6W6xoqZCieTOvo X-Google-Smtp-Source: AOwi7QDcGBEllUv2NYdN7uU/iptTrN16JeQrdLJ3z1cx+ejrj7PhmoDIhPwamq4TGeqajwLJbb57tvSdKskBj8sHYDE= X-Received: by 10.28.157.1 with SMTP id g1mr5526909wme.140.1505153154958; Mon, 11 Sep 2017 11:05:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.141 with HTTP; Mon, 11 Sep 2017 11:05:14 -0700 (PDT) In-Reply-To: References: From: Warren Kumari Date: Mon, 11 Sep 2017 14:05:14 -0400 Message-ID: To: Tommy Pauly Cc: draft-ietf-v6ops-rfc6555bis@ietf.org, IPv6 Operations Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] AD review of draft-ietf-v6ops-rfc6555bis. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 18:05:59 -0000 On Mon, Sep 11, 2017 at 1:15 PM, Tommy Pauly wrote: > Hi Warren, > > Thanks for the review! > > You're absolutely correct that a negative query response counts to stop a= ny delays, etc. I don't think this is pointed out explicitly. The way I wou= ld propose solving this would be to clarify in Section 3 around the parts t= hat read "if the AAAA query returns first" and "If the A query returns firs= t", that any the responses we are referring to include positive answers as = well as negative answers like NODATA. Does that sound good to you? WFM. Please let me know once you've submitted a new version and I'll start IETF = LC. W > > Thanks, > Tommy > >> On Sep 11, 2017, at 7:24 AM, Warren Kumari wrote: >> >> Hi, >> >> I've finished my AD review of draft-ietf-v6ops-rfc6555bis. >> >> I have only one comment / question: >> Section 3. Hostname Resolution Query Handling >> " If the AAAA response is received within the Resolution Delay period, >> the client immediately starts the IPv6 connection attempt. If, at the >> end of the Resolution Delay period, the AAAA response has not been >> received but the A response has been received, ..." >> >> So, let's say that at time T I fire off my queries, and 5ms later I >> get back a valid A record, and a NOERROR/NODATA response to the AAAA >> query (saying that there is no AAAA record) -- what do I do? >> I'm assuming that I just connect with the A record immediately, but >> this isn't actually stated anywhere (or, if it is, I missed it) - this >> seems like a common case, and should at least be mentioned. >> >> W >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Sep 11 12:39:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88F5132F34; Mon, 11 Sep 2017 12:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbSPFGG-Ulx6; Mon, 11 Sep 2017 12:39:30 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C0F132F32; Mon, 11 Sep 2017 12:39:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8BJdTfn043815; Mon, 11 Sep 2017 12:39:29 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8BJdLDj043735 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 11 Sep 2017 12:39:21 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 11 Sep 2017 12:39:20 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 11 Sep 2017 12:39:20 -0700 From: "Templin, Fred L" To: Warren Kumari , Lorenzo Colitti CC: Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTKaTY2SQFbjmM502TqtM/gaCiM6KtwdeAgAFRDQCAAPq0kA== Date: Mon, 11 Sep 2017 19:39:20 +0000 Message-ID: <5ec52c86f18e453b8191679afb7ec1b4@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 19:39:34 -0000 SGkgV2FycmVuLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3Bz IFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdhcnJlbiBLdW1h cmkNCj4gU2VudDogU3VuZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTcgMjowNSBQTQ0KPiBUbzogTG9y ZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20+DQo+IENjOiBTdXJlc2ggS3Jpc2huYW4g PHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+OyB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi12 Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFt2Nm9wc10gU3VyZXNoIEtyaXNobmFuJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXY2b3BzLXVu aXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkN Cj4gDQo+IFsgLSBJRVNHLCAtR3VudGVyIChoZSBnZXRzIGEgY29weSBhcyBwYXJ0IG9mDQo+IGRy YWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QCksIC12NmNoYWlyc0Ag XQ0KPiANCj4gDQo+IA0KPiBPbiBTYXQsIFNlcCA5LCAyMDE3IGF0IDg6NTggUE0sIExvcmVuem8g Q29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPiB3cm90ZToNCj4gPiBXYXJyZW4sDQo+ID4NCj4g PiBjYXJlIHRvIHN1bW1hcml6ZSB0aGUgbWFpbiBpc3N1ZXMgdGhhdCBjYXVzZWQgeW91IHRvIGRv IHRoaXM/IFdlJ2xsIHdhbnQgdG8NCj4gPiBtYWtlIHN1cmUgd2UgZG9uJ3Qgc3BlbmQgdG9vIG11 Y2ggdGltZSBkaXNjdXNzaW5nIGlzc3VlcyB0aGF0IGRpZCBub3QNCj4gPiBtYXRlcmlhbGx5IGlt cGFjdCB0aGlzIGRlY2lzaW9uLg0KPiA+DQo+IA0KPiBTdXJlLg0KPiANCj4gRHVyaW5nIElFU0cg cmV2aWV3LCBzb21lIG9mIHRoZSBJRVNHIHJhaXNlZCBxdWVzdGlvbnMgYW5kIHN1Z2dlc3RlZA0K PiB0ZXh0IHRvIGltcHJvdmUgdGhlIGRvY3VtZW50LiBXZSByZWNlaXZlZCByZXNwb25zZXMgZnJv bSB0aGUgYXV0aG9ycw0KPiBzYXlpbmcgdGhhdCB0aGUgcXVlc3Rpb25zLCBhbG9uZyB3aXRoIFN1 cmVzaCdzIERJU0NVU1MsIHdvdWxkIGJlDQo+IGFkZHJlc3NlZC4gV2UgZGlkIG5vdCBzZWUgYW4g dXBkYXRlZCBkcmFmdCwgYW5kIGl0J3MgZGlmZmljdWx0IHRvIGtlZXANCj4gdGhlIHBhdGNoZWQg dmVyc2lvbiBpbiBvbmUncyBoZWFkLiBTbywgSSBkb24ndCBrbm93IGV4YWN0bHkgd2hhdCBpdA0K PiBsb29rcyBsaWtlIG5vdywgYnV0IGhlcmUgYXJlIHNvbWUgb2YgdGhlIGNvbnNpZGVyYXRpb25z IHRoYXQNCj4gaW5mbHVlbmNlZCBteSBkZWNpc2lvbjoNCj4gDQo+IDE6IEJyaWFuIENhcnBlbnRl cidzOg0KPiAiSSBiZWxpZXZlIGl0J3Mgc3Vic3RhbnRpdmUgdGhhdCB0aGUgdGV4dCByZWZlcnMg dG8gc2VuZGluZyB1bmljYXN0DQo+IFJBcyB3aXRob3V0IGNsYXJpZnlpbmcgd2hldGhlciB0aGlz IG1lYW5zIHRoYXQgdGhleSBhcmUgc2VudA0KPiB3aXRoIGEgdW5pY2FzdCBsYXllciAyIGFkZHJl c3MgYW5kIGEgbXVsdGljYXN0IGxheWVyIDMgYWRkcmVzcw0KPiAoYXMgcGVyIFJGQzYwODUpIG9y IHRoYXQgdGhleSBhcmUgc2VudCB3aXRoIGJvdGggbGF5ZXIgMiBhbmQNCj4gbGF5ZXIgMyBhZGRy ZXNzZXMgYmVpbmcgdW5pY2FzdC4gQXQgdGhlIG1vbWVudCwgYW4gaW1wbGVtZW50ZXINCj4gaGFz IHRvIGRlY2lkZSB3aGljaCBvZiB0aGVzZSBpcyBpbnRlbmRlZC4gSWYgZWl0aGVyIGlzIE9LLA0K PiB0aGF0IGNvdWxkIGJlIHN0YXRlZCB0b28uIi4NCj4gDQo+IDI6IEZyZWQgVGVtcGxpbidzICJ1 bmxlc3MgdGhlIHNoYXJlZCBuZXR3b3JrIGV4cGxpY2l0bHkgcGVybWl0cw0KPiBwZWVyLXRvLXBl ZXIgb3BlcmF0aW9ucyIgLS0gaW4gbXkgdmlldyBhZGRpbmcgdGhpcyBleGFjdCB0ZXh0IGRpZG4n dA0KPiBzZWVtIHRvIGhhdmUgc3VwcG9ydCwgYnV0IGNsYXJpZnlpbmcgd2hhdCBpcyBtZWFudCBi eSBhICJzaGFyZWQNCj4gbmV0d29yayIgd291bGQgYmUgdXNlZnVsLg0KDQpJIGFncmVlLiAiU2hh cmVkIG5ldHdvcmsiIGlzIG5vdCAgYW4gUkZDNDg2MSBzdXBwb3J0ZWQgbGluayB0eXBlLiBUaGUN CnN1cHBvcnRlZCBsaW5rIHR5cGVzIGFyZSBnaXZlbiBpbiBSRkM0ODYxIFNlY3Rpb25zIDIuMiBh bmQgMy4yLCBhbmQgdGhpcw0KZG9jdW1lbnQgbmVlZHMgdG8gb2JzZXJ2ZSB0aGUgUkZDNDg2MSB0 ZXJtaW5vbG9neS4gRm9yIGV4YW1wbGUsIGluDQp0aGUgYWJzdHJhY3QgYW5kL29yIGludHJvZHVj dGlvbiBpdCBjb3VsZCBzYXkgc29tZXRoaW5nIGxpa2UgInNoYXJlZA0KbmV0d29yayB0eXBlcyBz dWNoIGFzIG11bHRpY2FzdC1jYXBhYmxlLCBub24tYnJvYWRjYXN0IG11bHRpLWFjY2Vzcw0KKE5C TUEpLCBzaGFyZWQgbWVkaWEsIGV0Yy4gW1JGQzQ4NjFdIiBhbmQgdGhlbiB0aGUgdGVybSAic2hh cmVkDQpuZXR3b3JrIiAgY291bGQgYmUgdXNlZCB0aHJvdWdob3V0IHRoZSBkb2N1bWVudC4NCg0K SGF2aW5nIHNhaWQgdGhhdCwgaG93ZXZlciwgYWxsIG9mIHRob3NlIFJGQzQ4NjEgc3VwcG9ydGVk IGxpbmsgdHlwZXMNCnN1cHBvcnQgcGVlci10by1wZWVyIGNvbW11bmljYXRpb25zIHdpdGhvdXQg aGF2aW5nIHRvIHNlbmQgYWxsIHRyYWZmaWMNCnRocm91Z2ggYSByb3V0ZXIuIEluIG9yZGVyIHRv IHByZXZlbnQgdGhhdCwgdGhpcyBkb2N1bWVudCB3b3VsZCBoYXZlIHRvDQpyZXF1aXJlIHRoYXQg TDIgcGFydGl0aW9uaW5nIG11c3QgYmUgdXNlZC4gT3RoZXJ3aXNlLCB0aGlzIGRvY3VtZW50IGlz DQplc3NlbnRpYWxseSBkZXByZWNhdGluZyBwZWVyLXRvLXBlZXIgKGluY2x1ZGluZyB0aGUgUmVk aXJlY3QgZnVuY3Rpb24pDQpldmVuIGZvciBsaW5rIHR5cGVzIHdoZXJlIGl0IG1heSBwcm92aWRl IHVzZWZ1bCBiZW5lZml0cy4NCg0KVGhhbmtzIC0gRnJlZA0KZnJlZC5sLnRlbXBsaW5AYm9laW5n LmNvbQ0KDQo+IFRoaXMgd2FzIGFsc28gbWVudGlvbmVkIGluIEVLUidzIGJhbGxvdCAtLSBiYWxs b3QgdGV4dCBpcyBhbGwgYmVsb3cgKEkNCj4gZG9uJ3Qgd2FudCBpdCB0byBnZXQgbG9zdCB3aGVu IGJlaW5nIExDZWQpLg0KPiANCj4gMzogSSBkbyBub3QgYmVsaWV2ZSB0aGF0IEkgZXZlciBzYXcg YSByZXNvbHV0aW9uIHRvIExvcmVuem8ncyAiSSdsbA0KPiBhbHNvIHBvaW50IG91dCB5ZXQgYWdh aW4gdGhhdCB0aGlzIHZhbHVlIGlzIGluIGNvbmZsaWN0IHdpdGggUkZDIDc3NzINCj4gaW4gdGhl IGNhc2Ugb2YgbmV0d29ya3MgdGhhdCBhcmUgcHJvdmlkZSBzZXJ2aWNlIGZvciBiYXR0ZXJ5LXBv d2VyZWQNCj4gZGV2aWNlcy4gVGhlIHRleHQgc2hvdWxkIGVpdGhlciBiZSBjaGFuZ2VkIHRvIGZv bGxvdyB0aGF0IFJGQyBvciB0bw0KPiBleHBsYWluIHRoZSByZWFzb24gZm9yIHRoZSBjb25mbGlj dC4iIC0tIEkgcGVyc29uYWxseSBkb24ndCBjYXJlIHdoYXQNCj4gdGhlIHZhbHVlIGlzIChJIHdh c24ndCByZWFsbHkgdGhpbmtpbmcgdGhhdCB0aGlzIHdvdWxkIG9jY3VyIG11Y2ggb24NCj4gYmF0 dGVyeS1wb3dlcmVkIGRldmljZXMsIGJ1dCBJIG1heSBiZSBjb21wbGV0ZWx5IHdyb25nKSwgYnV0 IEkgKmRvKg0KPiB0aGluayB0aGF0IGlmIGl0IGNvbmZsaWN0cyB3aXRoIFJGQyA3NzcyIGl0IG5l ZWRzIHRvIG5vdGUgdGhpcy4NCj4gDQo+IDQ6IE11Y2ggb2YgdGhlIHRocmVhZCBhYm92ZSBEYXZp ZCBGYXJtZXIncw0KPiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Y2b3Bz L2k3MmNiMHI2ZlZieGhaTGhyNHF5YnBwd1A2UQ0KPiANCj4gNTogU2ltcGx5IHRoZSBhbW91bnQg b2YgZGlzY3Vzc2lvbiBhZnRlciBJRVNHIGV2YWwsIGFuZCBJRVRGIExDIChJDQo+IHRoaW5rIHRo YXQgdGhlIG51bWJlciBpcyBzb21ldGhpbmcgbGlrZSAxMDAgYW5kID4zNTAgcmVzcGVjdGl2ZWx5 KSAtLQ0KPiB3aGlsZSBtYW55IG9mIHRoZW0gd2FuZGVyZWQgYWZhciBmcm9tIHRoZSBhY3R1YWwg ZHJhZnQgKGFuZCwgb2Z0ZW4sDQo+IHRvcGljIDotKSkgaXQgaXMgaGFyZCB0byBtYWtlIHRoZSBj bGFpbSB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFsbHkNCj4gY2xlYXIgYW5kIGhhcyBzdHJvbmcg Y29uc2Vuc3VzIGZyb20gdGhpcy4NCj4gDQo+IA0KPiBJJ2Qgbm90ZSB0aGF0ICMxLCAyLCBhbmQg NCBhcmUgdmVyeSBjbG9zZWx5IHJlbGF0ZWQsIGFuZCBJIHRoaW5rDQo+IHNob3VsZCBiZSBmYWly bHkgZWFzaWx5IGFkZHJlc3NlZC4gSSdtIGFsc28gaGFwcHkgZm9yIHRoZSBjaGFpcnMgdG8NCj4g aGF2ZSBhIGNvbXByZXNzZWQgMiBXR0xDIChpZiB0aGV5IHRoaW5rIGFwcHJvcHJpYXRlKS4NCj4g DQo+IEluY2lkZW50YWxseSAoYnV0IGluIG5vIHdheSByZWxldmFudCksIEkgaGFwcGVuIHRvIHJl YWxseSBsaWtlIHRoZQ0KPiBpZGVhIC8gZG9jdW1lbnQsIGFuZCB3b3VsZCBsaWtlIHRvIHNlZSBp dCBwdWJsaXNoZWQgKHNvb24hKS4NCj4gdw0KPiANCj4gDQo+IA0KPiAtPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS09LSBDb3B5LW4tcGFzdGUgb2YgYmFsbG90DQo+ID0tPS09LT0tPS09LT0tPS09 LT0tPS09LT0tPS0NCj4gDQo+IFN1cmVzaCBLcmlzaG5hbkRpc2N1c3MNCj4gDQo+IERpc2N1c3Mg KDIwMTctMDgtMTYpDQo+IA0KPiAqIFNlY3Rpb24gNA0KPiANCj4gSXQgaXMgbm90IGNsZWFyIHdo YXQgeW91IGludGVuZCBoZXJlDQo+IA0KPiAiSVB2NiBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBJbnRl cnZhbCA9IDMwMHMiDQo+IA0KPiBUaGUgcm91dGVyIGFkdmVydGlzZW1lbnQgaW50ZXJ2YWwgaXMg bm90IGNvbmZpZ3VyZWQgYXMgYW4gYWJzb2x1dGUNCj4gdmFsdWUgYnV0IGFzIG1pbmltdW0gYW5k IG1heGltdW0gYm91bmRzIChNaW5SdHJBZHZJbnRlcnZhbCBhbmQNCj4gTWF4UnRyQWR2SW50ZXJ2 YWwpIHdoaWNoIGFyZSB1c2VkIHRvIGNhbGN1bGF0ZSB0aGUgYWN0dWFsDQo+IGFkdmVydGlzZW1l bnQgaW50ZXJ2YWwuIFdoZW4gdGhlIFJBIGlzIHNlbnQgZnJvbSBhbiBpbnRlcmZhY2UsIHRoZQ0K PiBhY3R1YWwgaW50ZXJ2YWwgaXMgYW4gdW5pZm9ybWx5IGRpc3RyaWJ1dGVkIHJhbmRvbSB2YWx1 ZSBiZXR3ZWVuIHRoZQ0KPiBNaW5SdHJBZHZJbnRlcnZhbCBhbmQgTWF4UnRyQWR2SW50ZXJ2YWwu IEF0IHRoZSB2ZXJ5IG1pbmltdW0geW91IG5lZWQNCj4gdG8gY2xhcmlmeSBpZiB5b3Ugd291bGQg bGlrZSB0byBoYXZlIHRoaXMgYXMgYSBsb3dlciBib3VuZCBvciBhcyBhbg0KPiB1cHBlciBib3Vu ZC4NCj4gDQo+IENvbW1lbnQgKDIwMTctMDgtMTYpDQo+IA0KPiAqIFNlY3Rpb24gNA0KPiANCj4g LT4gSSB0aGluayB0ZXh0IGlzIG5lZWRlZCBoZXJlIHRvIGhhbmRsZSB0aGUgY2FzZSB3aGVyZSB0 aGUgRE5TIHNlcnZlcg0KPiBpcyBwcm92aWRlZCBpbiB0aGUgUkEgaXRzZWxmICAoUkZDODEwNikN Cj4gDQo+ICJJbiBhZGRpdGlvbiBpdCB3aWxsIHVzZSBzdGF0ZWxlc3MgREhDUHY2IHRvIGdldCB0 aGUgSVB2NiBhZGRyZXNzIG9mDQo+IHRoZSBETlMgc2VydmVyIg0KPiANCj4gLT4gSSBhbSBub3Qg c3VyZSB3aGF0IGlzIHRoZSBtb3RpdmF0aW9uIGZvciB0aGlzIHRleHQuDQo+IA0KPiAiaG93ZXZl ciBpdCBTSE9VTEQgTk9UIHVzZSBzdGF0ZWZ1bCBESENQdjYgdG8gcmVjZWl2ZSBhIHNlcnZpY2UN Cj4gcHJvdmlkZXIgbWFuYWdlZCBJUHY2IGFkZHJlc3MiDQo+IA0KPiAtPiBUaGlzIHRleHQgc2Vl bXMgaW5jb3JyZWN0DQo+IA0KPiAiZHVlIHRvIHRoZSBMLWJpdCBzZXQsIGl0IFNIT1VMRCBzZW5k IHRoaXMgdHJhZmZpYyB0byB0aGUgRmlyc3QgSG9wDQo+IFByb3ZpZGVyIFJvdXRlciINCj4gDQo+ IEkgdGhpbmsgaXQgc2hvdWxkIGJlIHRoZSBleGFjdCBvcHBvc2l0ZS4gaS5lLiBzYXkgKnVuc2V0 KiBpbnN0ZWFkIG9mIHNldA0KPiANCj4gImR1ZSB0byB0aGUgTC1iaXQgYmVpbmcgdW5zZXQsIGl0 IFNIT1VMRCBzZW5kIHRoaXMgdHJhZmZpYyB0byB0aGUNCj4gRmlyc3QgSG9wIFByb3ZpZGVyIFJv dXRlciINCj4gDQo+IFdhcnJlbiBLdW1hcmlZZXMNCj4gDQo+IERlYm9yYWggQnJ1bmdhcmRObyBP YmplY3Rpb24NCj4gDQo+IEJlbiBDYW1wYmVsbE5vIE9iamVjdGlvbg0KPiANCj4gQ29tbWVudCAo MjAxNy0wOC0xNikNCj4gDQo+IEkgaGF2ZSBubyB0ZWNobmljYWwgY29tbWVudHMsIGJ1dCBhIG51 bWJlciBvZiBlZGl0b3JpYWwgY29tbWVudHM6DQo+IA0KPiAtIEdlbmVyYWw6IEkgdGhpbmsgdGhp cyBjb3VsZCB1c2UgYW5vdGhlciBwcm9vZnJlYWRpbmcgYW5kL29yIGVkaXRpbmcNCj4gcGFzcyBm b3IgdGhlIGZvbGxvd2luZyBpc3N1ZXM6DQo+IC0tIEluY29uc2lzdGVudCB0ZW5zZS0tZXNwZWNp YWxseSB1c2Ugb2YgZnV0dXJlIG9yIHByZXNlbnQgY29udGludW91cy4NCj4gLS0gV29yZHkgYW5k IGNvbnZvbHV0ZWQgc2VudGVuY2VzDQo+IC0tIFVzZSBvZiAiLyIgYXMgYSBjb25qdW5jdGlvbi4N Cj4gDQo+IC0gQWJzdHJhY3Q6DQo+IFRoZSBhYnN0cmFjdCBpcyBsb25nZXIgYW5kIG1vcmUgZGV0 YWlsZWQgdGhhbiBpcyB1c2VmdWwuIFRoZSBsYXN0DQo+IHBhcmFncmFwaCBjb3VsZCBoYXZlIHN0 b29kIGFsb25lIGFzIHRoZSBhYnN0cmFjdC4NCj4gSXQncyBub3QgY2xlYXIgdG8gbWUgaWYgImhv c3RzIChzdWJzY3JpYmVycykiIG1lYW5zIHNvbWV0aGluZw0KPiBkaWZmZXJlbnQgdGhhbiAiaG9z dHMiIGluIGNvbnRleHQuDQo+IA0KPiAtMToNCj4gUGxlYXNlIGV4cGFuZCAiSUFfTkEiIG9uIGZp cnN0IHVzZS4NCj4gcy8iVGhpcyBkb2N1bWVudCB3aWxsIGZvY3VzLi4uIi8iVGhpcyBkb2N1bWVu dCBmb2N1c2VzLi4uIg0KPiANCj4gIkFzIHN1Y2ggdGhlIHVzZQ0KPiAgICBvZiBJUHY2IFNMQUFD IGJhc2VkIHN1YnNjcmliZXIgYW5kIGFkZHJlc3MgbWFuYWdlbWVudCBmb3IgcHJvdmlkZXINCj4g ICAgbWFuYWdlZCBzaGFyZWQgbmV0d29yayBzZXJ2aWNlcyBpcyB0aGUgcmVjb21tZW5kZWQgdGVj aG5vbG9neSBvZg0KPiAgICBjaG9pY2UsIGFzIGl0IGRvZXMgbm90IGV4Y2x1ZGUgYW55IGtub3du IElQdjYgaW1wbGVtZW50YXRpb24uIg0KPiBEb2VzIHRoaXMgZG9jdW1lbnQgbWFrZSB0aGF0IHJl Y29tbWVuZGF0aW9uLCBvciBpcyB0aGF0IHNvbWUNCj4gcHJlLWV4aXN0aW5nIHJlY29tbWVuZGF0 aW9uPw0KPiANCj4gDQo+IC0zOiAiVGhlIEJlc3QgQ3VycmVudCBQcmFjdGljZSBkb2N1bWVudGVk IGluIHRoaXMgbm90ZSBpcyB0byBwcm92aWRlIGENCj4gICAgdW5pcXVlIElQdjYgcHJlZml4IHRv IGhvc3RzL3N1YnNjcmliZXJzIGRldmljZXMgY29ubmVjdGVkIHRvIHRoZQ0KPiAgICBwcm92aWRl ciBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrLiINCj4gDQo+IFRoZSBzZW50ZW5jZSBoYXJkIHRvIGZv bGxvdy4gQ29uc2lkZXIgIlRoaXMgZG9jdW1lbnQgcmVjb21tZW5kcy4uLiIuDQo+IEknbSBub3Qg c3VyZSBob3cgdG8gaW50ZXJwcmV0ICJob3N0cy9zdWJzY3JpYmVycyBkZXZpY2VzIg0KPiANCj4g IkVhY2ggdW5pcXVlIElQdjYgcHJlZml4IGNhbg0KPiAgICBmdW5jdGlvbiBhcyBjb250cm9sLXBs YW5lIGFuY2hvciBwb2ludCB0byBtYWtlIHN1cmUgdGhhdCBlYWNoDQo+ICAgIHN1YnNjcmliZXIg aXMgcmVjZWl2aW5nIg0KPiBzLyIuLi4gc3Vic2NyaWJlciBpcyByZWNlaXZpbmcgLi4uIi8iLi4u IHN1YnNjcmliZXIgcmVjZWl2ZXMuLi4iDQo+IA0KPiANCj4gDQo+IC00OiBJcyAiRmlyc3QgSG9w IFByb3ZpZGVyIFJvdXRlciIgZGlmZmVyZW50IHRoYW4gIkZpcnN0IEhvcCBSb3V0ZXIiPw0KPiAN Cj4gSW4gdGhlIGxhc3QgYnVsbGV0IChMLWZsYWc9MCksIGFyZSBORVZFUiBhbmQgQUxXQVlTIGlu IGFsbC1jYXBzDQo+IGV4cGVjdGVkIHRvIGhhdmUgZGlmZmVyZW50IG1lYW5pbmcgdGhhbiBpZiB0 aGV5IGhhZCBub3JtYWwNCj4gY2FwaXRhbGl6YXRpb24/DQo+IA0KPiBUaGUgc2VudGVuY2Ugc3Rh cnRpbmcgd2l0aCAiVGhlIGFyY2hpdGVjdGVkIHJlc3VsdCBvZiBkZXNpZ25pbmcgdGhlIFJBDQo+ IGFzIGRvY3VtZW50ZWQgYWJvdmUuLi4iIGlzIGNvbnZvbHV0ZWQgYW5kIGhhcmQgdG8gZm9sbG93 Lg0KPiANCj4gIi4uLiBob3dldmVyIGl0IFNIT1VMRCBOT1QgdXNlIHN0YXRlZnVsIERIQ1B2NiB0 byByZWNlaXZlDQo+ICAgIGEgc2VydmljZSBwcm92aWRlciBtYW5hZ2VkIElQdjYgYWRkcmVzcyI6 IElzIHRoYXQgcmVhbGx5IGENCj4gbm9ybWF0aXZlIHJlcXVpcmVtZW50LCBvciBpcyBpdCBhIHN0 YXRlbWVudCBvZiBmYWN0IGFib3V0IGV4aXN0aW5nDQo+IHJlcXVpcmVtZW50cz8NCj4gDQo+ICJp dCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMNCj4gICAgdG8gdGhlIEZpcnN0IEhvcCBQcm92aWRl ciBSb3V0ZXIuIiA6IHN0YXRlbWVudCBvZiBmYWN0Pw0KPiANCj4gLSA1OiAiVG8gcmVkdWNlDQo+ ICAgIHVuZGVzaXJlZCByZXNvdXJjZSBjb25zdW1wdGlvbiBvbiB0aGUgRmlyc3QgSG9wIFJvdXRl ciB0aGUgZGVzaXJlIGlzDQo+ICAgIHRvIHJlbW92ZSBVRS9zdWJzY3JpYmVyIGNvbnRleHQgaW4g dGhlIGNhc2Ugb2Ygbm9uLXBlcm1hbmVudCBVRSwgc3VjaA0KPiAgICBhcyBpbiB0aGUgY2FzZSBv ZiBXaUZpIGhvdHNwb3RzIGFzIHF1aWNrbHkgYXMgcG9zc2libGUuICINCj4gQ29udm9sdXRlZCBz ZW50ZW5jZS4NCj4gDQo+ICJBIHBvc3NpYmxlIHNvbHV0aW9uIGlzIHRvIHVzZSBhIHN1YnNjcmli ZXIgaW5hY3Rpdml0eSB0aW1lciB3aGljaCwgYWZ0ZXINCj4gICAgdHJhY2tpbmcgYSBwcmUtZGVm aW5lZCAoY3VycmVudGx5IHVuc3BlY2lmaWVkKSBudW1iZXIgb2YgbWludXRlcywNCj4gICAgZGVs ZXRlcyB0aGUgc3Vic2NyaWJlciBjb250ZXh0IG9uIHRoZSBGaXJzdCBIb3AgUm91dGVyLiINCj4g DQo+IHMvd2hpY2gvdGhhdCAgIChDb25zaWRlciAiIC4uLiB0aW1lciB0aGF0IGRlbGV0ZXMuLi5h ZnRlciBhDQo+IHByZWRldGVybWluZWQgbnVtYmVyIG9mIG1pbnV0ZXMiDQo+IA0KPiAtNzogIlRo ZQ0KPiAgICBjb21iaW5hdGlvbiBvZiBib3RoIElQdjYgcHJpdmFjeSBleHRlbnNpb25zIGFuZCBv cGVyYXRvciBiYXNlZA0KPiAgICBhc3NpZ25tZW50IG9mIGEgVW5pcXVlIElQdjYgUHJlZml4IHBl ciBIb3N0IHByb3ZpZGVzIGVhY2gNCj4gICAgaW1wbGVtZW50aW5nIG9wZXJhdG9yIGEgdG9vbCB0 byBtYW5hZ2UgYW5kIHByb3ZpZGUgc3Vic2NyaWJlcg0KPiAgICBzZXJ2aWNlcyBhbmQgaGVuY2Ug cmVkdWNlcyB0aGUgZXhwZXJpZW5jZWQgcHJpdmFjeSB3aXRoaW4gZWFjaA0KPiAgICBvcGVyYXRv ciBjb250cm9sbGVkIGRvbWFpbi4iDQo+IA0KPiBJIGhhdmUgdHJvdWJsZSBmb2xsb3dpbmcgdGhh dCBzZW50ZW5jZS4gSXMgdGhlIHBvaW50IHRvIHNheSB0aGF0DQo+IHByb3ZpZGluZyB0b29scyB0 byBtYW5hZ2UgYW5kIHByb3ZpZGUgc2VydmljZXMgcmVkdWNlcyBwcml2YWN5IGluDQo+IGdlbmVy YWw/IEFzIHdvcmRlZCwgaXQgYWxtb3N0IHNvdW5kcyBsaWtlIHRoaXMgaXMgbWVhbnQgYXMgYSBm ZWF0dXJlLA0KPiB3aGljaCBJIGFzc3VtZSBpcyBub3QgdGhlIGNhc2UuDQo+IA0KPiBTcGVuY2Vy IERhd2tpbnNObyBPYmplY3Rpb24NCj4gDQo+IENvbW1lbnQgKDIwMTctMDgtMTUpDQo+IA0KPiBP bmUgbml0Og0KPiANCj4gUGxlYXNlIGNvbnNpZGVyIG1vdmluZw0KPiANCj4gICAgQmVuZWZpdHMg b2YgdW5pcXVlDQo+ICAgIElQdjYgcHJlZml4IG92ZXIgYSB1bmlxdWUgSVB2NiBhZGRyZXNzIGZy b20gdGhlIHNlcnZpY2UgcHJvdmlkZXINCj4gICAgaW5jbHVkZSBpbXByb3ZlZCBzdWJzY3JpYmVy IGlzb2xhdGlvbiBhbmQgZW5oYW5jZWQgc3Vic2NyaWJlcg0KPiAgICBtYW5hZ2VtZW50Lg0KPiAN Cj4gdG8gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUgQWJzdHJhY3QuIEnigJltIGFzc3VtaW5n IHRoYXQgdGhpcw0KPiBleHBsYWlucyB0aGUg4oCcbmVlZHMgdGhhdCBoYXZlIGFyaXNlbuKAnSBp biB0aGUgZmlyc3Qgc2VudGVuY2Ugb2YgdGhlDQo+IEFic3RyYWN0LCBvZiBjb3Vyc2UuDQo+IA0K PiBNaXJqYSBLw7xobGV3aW5kTm8gT2JqZWN0aW9uDQo+IA0KPiBDb21tZW50ICgyMDE3LTA4LTE0 KQ0KPiANCj4gVG8gbWUgdGhpcyBzZWVtcyBhcHByb3JpYXRlIGZvciBCQ1A7IEknbSBzYXlpbmcg dGhpcyBiZWNhdXNlIHRoaXMgd2FzDQo+IG1lbnRpb25lZCBpbiB0aGUgc2hlcGhlcmQtd3JpdGUt dXAgYXMgaXQgd2FzIGJyb3VnaHQgdXAgYnkgdGhlIGdlbi1hcnQNCj4gcmV2aWV3Lg0KPiANCj4g UGxlYXNlIGFsc28gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBjb21tZW50IGZyb20gdGhlIGdlbi1h cnQgcmV2aWV3DQo+IChUaGFua3MgSm9lbCEpOg0KPiAiVGhlIGlzc3VlIG9mIHN0YXR1cyBmb3Ig dGhlIGRvY3VtZW50IChCQ1AgdnMgSW5mb3JtYXRpb25hbCkgaXMgZm9yIHRoZSBJRVNHDQo+ICAg IHRvIGNvbmNsdWRlLiAgSG93ZXZlciwgZXZlbiBpZiBpdCBpcyBhIEJDUCwgYXMgSSB1bmRlcnN0 YW5kIHRoZSBwdXJwb3NlLA0KPiAgICB0aGlzIGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGRlc2Ny aWJlIHRoZSBwcmFjdGljZXMgdG8gYmUgdXNlZCB3aGVuIGENCj4gICAgcHJvdmlkZXIgaGFzIGRl Y2lkZWQgdG8gZGVwbG95IGEgLzY0IHBlciBob3N0LiAgVGhlIHdvcmRpbmcgdGhhdCBpcyBjaG9z ZW4NCj4gICAgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgbWFrZXMgaXQgYXBwZWFyIHRoYXQgdGhl IHVuZGVybHlpbmcgZGVjaXNpb24gYWJvdXQNCj4gICAgc3VjaCBhIGRlcGxveW1lbnQgaXMgYWxz byBhIHJlY29tbWVuZGVkIHByYWN0aWNlLiINCj4gSSBhZ3JlZSB0aGF0IHdvcmRpbmcgY291bGQg YmUgbWFkZSBjbGVhcmVyIGhlcmUhDQo+IA0KPiBBbGV4ZXkgTWVsbmlrb3ZObyBPYmplY3Rpb24N Cj4gDQo+IENvbW1lbnQgKDIwMTctMDgtMTIpDQo+IA0KPiBSYWRpdXMgc2hvdWxkIGhhdmUgYW4g aW5mb3JtYXRpdmUgcmVmZXJlbmNlIG9uIGZpcnN0IHVzZS4NCj4gDQo+IEthdGhsZWVuIE1vcmlh cnR5Tm8gT2JqZWN0aW9uDQo+IA0KPiBDb21tZW50ICgyMDE3LTA4LTE1KQ0KPiANCj4gVGhhbmsg eW91IGZvciBhZGRyZXNzaW5nIHRoZSBTZWNEaXIgcmV2aWV3Og0KPiBodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3NlY2Rpci93V3BfMHZsbXN6N1NzLW5vd2poZWhZSW1PZWcN Cj4gDQo+IEVyaWMgUmVzY29ybGFObyBPYmplY3Rpb24NCj4gDQo+IENvbW1lbnQgKDIwMTctMDgt MTUpDQo+IA0KPiBEb2N1bWVudDogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgt cGVyLWhvc3QtMDcudHh0DQo+IA0KPiANCj4gSSBmb3VuZCB0aGUgZGlzY3Vzc2lvbiBvZiB0aGUg c2hhcmVkIG5ldHdvcmsgbWVkaXVtIGEgYml0DQo+IGNvbmZ1c2luZy4gQXMgSSB1bmRlcnN0YW5k IGl0LCB0aGUgaWRlYSBpcyB0aGF0IGlmIHdlIGFyZQ0KPiBvbiBhIHNoYXJlZCBuZXR3b3JrIGFu ZCB3ZSBoYXZlIHRoZSBzYW1lIHByZWZpeCwgSSBtaWdodA0KPiB0cnkgdG8gc2VuZCB0byB5b3Ug ZGlyZWN0bHkuIFdoYXQgeW91IHdhbnQgdG8gZG8gaXMgbWFrZQ0KPiB0aGF0IG5vdCBoYXBwZW4g YnkgaGF2aW5nIGVhY2ggbm9kZSBoYXZlIGEgc2VwYXJhdGUgcHJlZml4Lg0KPiBDb3JyZWN0PyBJ ZiBzbywgcGVyaGFwcyBwcm9tb3RlIHRoaXMgYnVsbGV0LCBhbmQgYWxzbyBoYXZlDQo+IGl0IGRl c2NyaWJlIHRoZSBwcm9ibGVtIGFuZCB3aHkgdGhpcyBwcm92aWRlcyBhIHNvbHV0aW9uOg0KPiAN Cj4gICAgbyAgVHdvIGRldmljZXMgKHN1YnNjcmliZXIvaG9zdHMpLCBib3RoIGF0dGFjaGVkIHRv IHRoZSBzYW1lIHByb3ZpZGVyDQo+ICAgICAgIG1hbmFnZWQgc2hhcmVkIG5ldHdvcmsgc2hvdWxk IG9ubHkgYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB0aHJvdWdoDQo+ICAgICAgIHRoZSBwcm92aWRl ciBtYW5hZ2VkIEZpcnN0IEhvcCBSb3V0ZXINCj4gDQo+IA0KPiBJdCdzIGEgYml0IHVuY2xlYXIg dG8gbWUgaG93IG11Y2ggeW91IGFyZSBzYXlpbmcgdGhhdA0KPiBzb21ldGhpbmcgaXMgY3VycmVu dCBwcmFjdGljZSB2ZXJzdXMgaG93IG11Y2ggeW91IGFyZQ0KPiByZWNvbW1lbmRpbmcgaXQuIEZv ciBpbnN0YW5jZSwgdGhlIGFic3RyYWN0IHJlYWRzIG1vcmUNCj4gbGlrZSB3aGF0IHlvdSB3b3Vs ZCBleHBlY3QgZm9yIFBTLg0KPiANCj4gICAgVGhpcyBkb2N1bWVudCBvdXRsaW5lcyBhbiBhcHBy b2FjaCB1dGlsaXNpbmcgZXhpc3RpbmcgSVB2NiBwcm90b2NvbHMNCj4gICAgdG8gYWxsb3cgaG9z dHMgdG8gYmUgYXNzaWduZWQgYSB1bmlxdWUgSVB2NiBwcmVmaXggKGluc3RlYWQgb2YgYQ0KPiAg ICB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLiAgQmVuZWZp dHMgb2YgdW5pcXVlDQo+ICAgIElQdjYgcHJlZml4IG92ZXIgYSB1bmlxdWUgSVB2NiBhZGRyZXNz IGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXINCj4gICAgaW5jbHVkZSBpbXByb3ZlZCBzdWJzY3Jp YmVyIGlzb2xhdGlvbiBhbmQgZW5oYW5jZWQgc3Vic2NyaWJlcg0KPiAgICBtYW5hZ2VtZW50Lg0K PiANCj4gQnV0IHRoZW4gUyA0IHNlZW1zIHRvIGJlIGRvY3VtZW50aW5nOg0KPiANCj4gICAgVGhl IElQdjYgUkEgZmxhZ3MgdXNlZCBmb3IgYmVzdCBjb21tb24gcHJhY3RpY2UgaW4gSVB2NiBTTEFB QyBiYXNlZA0KPiAgICBQcm92aWRlciBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrcyBhcmU6DQo+IA0K PiANCj4gICAgVGhlIHVzZSBvZiBhIHVuaXF1ZSBJUHY2IHByZWZpeCBwZXIgVUUgYWRkcyBhbiBh ZGRpdGlvbmFsIGxldmVsIG9mDQo+ICAgIHByb3RlY3Rpb24gYW5kIGVmZmljaWVuY3kgYXMgaXQg cmVsYXRlcyB0byBob3cgSVB2NiBOZWlnaGJvcg0KPiAgICBEaXNjb3ZlcnkgYW5kIFJvdXRlciBE aXNjb3ZlcnkgcHJvY2Vzc2luZy4gIFNpbmNlIHRoZSBVRSBoYXMgYSB1bmlxdWUNCj4gICAgSVB2 NiBwcmVmaXggYWxsIHRyYWZmaWMgYnkgZGVmYXVsdCB3aWxsIGJlIGRpcmVjdGVkIHRvIHRoZSBG aXJzdCBIb3ANCj4gICAgcHJvdmlkZXIgcm91dGVyLiAgRnVydGhlciwgdGhlIGZsYWcgY29tYmlu YXRpb25zIGRvY3VtZW50ZWQgYWJvdmUNCj4gICAgbWF4aW1pc2UgdGhlIElQdjYgY29uZmlndXJh dGlvbnMgdGhhdCBhcmUgYXZhaWxhYmxlIGJ5IGhvc3RzDQo+ICAgIGluY2x1ZGluZyB0aGUgdXNl IG9mIHByaXZhY3kgSVB2NiBhZGRyZXNzaW5nLg0KPiANCj4gSXQncyBub3QgcXVpdGUgY2xlYXIg dG8gbWUgd2h5IHVuaXF1ZSBwcmVmaXhzIGFyZSBuZWVkZWQgaGVyZSBpZg0KPiBwZW9wbGUgc2V0 IEw9MC4gSXMgaXQgdGhhdCBwZW9wbGUgaWdub3JlIEw9MD8NCj4gDQo+IEZpbmFsbHksIEknbSBh IGJpdCBjb25mdXNlZCBhYm91dCBob3cgdG8gcmVhZCB0aGlzIHRleHQgYWJvdXQgdGhlDQo+IEw9 MCBiaXQgaW4gY2FzZXMgd2hlcmUgSSBoYXZlIG11bHRpcGxlIGRldmljZXMgcmF0aGVyIHRoYW4g anVzdCBvbmUNCj4gYXQgdGhlIGN1c3RvbWVyIHByZW0uIFNheSBJIGhhdmUgYSB0b3BvbG9neSB3 aXRoIGEgaG9tZSByb3V0ZXINCj4gYW5kIGRldmljZXMgYmVoaW5kIGl0LiBJLmUuLA0KPiANCj4g ICAgICAgICAgICAgICAgICAgICBTZXJ2aWNlIFByb3ZpZGVyDQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAg ICAgICAgICAgICAgICBDdXN0b21lcg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgUm91dGVy DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tKw0KPiAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAg ICAgICB8DQo+ICAgICAgICAgICAgICBIb3N0IDEgICAgICBIb3N0IDIgICAgICBIb3N0IDMNCj4g DQo+IEkgYXNzdW1lIHdoYXQgaGFwcGVucyBoZXJlIGlzIHRoYXQgdGhlIHJvdXRlciBnZXRzIHBy ZWZpeCBYLCBhc3NpZ25zDQo+IGl0c2VsZiBYWSwgYW5kIHRoZW4gdGhlIEhvc3RzIGdldCBYQSwg WEIsIFhDLCBldGMsIGEgbGEgNzI3OC4gSXMgdGhhdA0KPiByaWdodD8gSWYgc28sIG15IHF1ZXN0 aW9uIGlzIGFib3V0IHBhY2tldHMgY29taW5nIGludG8gdGhlIFJvdXRlciBmcm9tDQo+IHRoZSBT UCwgd2hpY2ggaGF2ZSAoc2F5KSBYQS4gIFRoZSB0ZXh0IGFib3V0IHRoZSBMLWZsYWcgc3VnZ2Vz dHMgdGhhdA0KPiB0aGUgcm91dGVyIHNob3VsZCBzZW5kIHRoZW0gYmFjayB0byB0aGUgZ2F0ZXdh eSwgYnV0IHRoYXQncyBjbGVhcmx5DQo+IG5vdCByaWdodC4gV2hhdCBhbSBJIG1pc3Npbmc/DQo+ IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ID4gQ2hlZXJzLA0KPiA+IExvcmVuem8NCj4gPg0KPiA+ IE9uIFN1biwgU2VwIDEwLCAyMDE3IGF0IDQ6NDkgQU0sIFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBr dW1hcmkubmV0PiB3cm90ZToNCj4gPj4NCj4gPj4gWyBUb3AtcG9zdCBdDQo+ID4+DQo+ID4+IFl1 cCwgSSB3YXMgdGhpbmtpbmcgdGhhdCwgd2hpbGUgc3Vic3RhbnRpdmUsIHRoYXQgd291bGQgYmUg aGFuZGxlZA0KPiA+PiB3aGlsZSBzdGlsbCBrZWVwaW5nIGl0IGluIElFU0cgZXZhbCAtLSBidXQs IEkndmUganVzdCBnb25lIGJhY2sgYW5kDQo+ID4+IHJlLXJlYWQgdGhlIHRocmVhZHMsIGVzcGVj aWFsbHkgYWxsIG9mIHRoZSBtYWlsICh+MTAyKSBhZnRlciB0aGUgSUVTRw0KPiA+PiAvIHRlbGVj aGF0LCBhbmQgSSd2ZSBkZWNpZGVkIHRoYXQgSSB3aWxsIGhhdmUgdG8gcmV0dXJuIGl0IHRvIHRo ZSBXRy4NCj4gPj4gU2VlaW5nIGFzIGl0IGhhcyBhbHJlYWR5IGhhZCBhIFdHTEMsIEkgZXhwZWN0 IHRoYXQgdGhlIG5leHQgb25lIGNhbiBiZQ0KPiA+PiBjb21wcmVzc2VkLg0KPiA+Pg0KPiA+PiBU aGUgZ29vZCBuZXdzIGlzIHRoYXQgYTogdGhlcmUgaGF2ZSBiZWVuIGEgbnVtYmVyIG9mIHN1Z2dl c3Rpb25zIC8NCj4gPj4gcHJvdmlkZWQgdGV4dCB0byBpbXByb3ZlIHRoZSBkb2N1bWVudCwgYW5k IGI6IEknZCBleHBlY3QgdGhlIG5leHQgSUVTRw0KPiA+PiBldmFsIHRvIGdvIGVhc2lseS4NCj4g Pj4NCj4gPj4gU29ycnkgYWxsLA0KPiA+PiBXDQo+ID4+DQo+ID4+DQo+ID4+IE9uIE1vbiwgU2Vw IDQsIDIwMTcgYXQgNjozMiBQTSwgQnJpYW4gRSBDYXJwZW50ZXINCj4gPj4gPGJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+ID4gV2FycmVuLA0KPiA+PiA+DQo+ID4+ID4g SSBiZWxpZXZlIGl0J3Mgc3Vic3RhbnRpdmUgdGhhdCB0aGUgdGV4dCByZWZlcnMgdG8gc2VuZGlu ZyB1bmljYXN0DQo+ID4+ID4gUkFzIHdpdGhvdXQgY2xhcmlmeWluZyB3aGV0aGVyIHRoaXMgbWVh bnMgdGhhdCB0aGV5IGFyZSBzZW50DQo+ID4+ID4gd2l0aCBhIHVuaWNhc3QgbGF5ZXIgMiBhZGRy ZXNzIGFuZCBhIG11bHRpY2FzdCBsYXllciAzIGFkZHJlc3MNCj4gPj4gPiAoYXMgcGVyIFJGQzYw ODUpIG9yIHRoYXQgdGhleSBhcmUgc2VudCB3aXRoIGJvdGggbGF5ZXIgMiBhbmQNCj4gPj4gPiBs YXllciAzIGFkZHJlc3NlcyBiZWluZyB1bmljYXN0LiBBdCB0aGUgbW9tZW50LCBhbiBpbXBsZW1l bnRlcg0KPiA+PiA+IGhhcyB0byBkZWNpZGUgd2hpY2ggb2YgdGhlc2UgaXMgaW50ZW5kZWQuIElm IGVpdGhlciBpcyBPSywNCj4gPj4gPiB0aGF0IGNvdWxkIGJlIHN0YXRlZCB0b28uDQo+ID4+ID4N Cj4gPj4gPiBTcGVjaWZpY2FsbHkgdGhpcyBjbGFyaWZpY2F0aW9uIHNlZW1zIHRvIGJlIG5lZWRl ZCByaWdodCBhZnRlcjoNCj4gPj4gPg0KPiA+PiA+PiA0LiAgSVB2NiBVbmlxdWUgUHJlZml4IEFz c2lnbm1lbnQNCj4gPj4gPj4NCj4gPj4gPj4gICAgV2hlbiBhIFVFIGNvbm5lY3RzIHRvIHRoZSBz aGFyZWQgcHJvdmlkZXIgbWFuYWdlZCBuZXR3b3JrIGFuZCBpcw0KPiA+PiA+PiAgICBhdHRhY2hl ZCwgaXQgd2lsbCBpbml0aWF0ZSBJUCBjb25maWd1cmF0aW9uIHBoYXNlLiAgRHVyaW5nIHRoaXMN Cj4gPj4gPj4gcGhhc2UNCj4gPj4gPj4gICAgdGhlIFVFIHdpbGwsIGZyb20gYW4gSVB2NiBwZXJz cGVjdGl2ZSwgYXR0ZW1wdCB0byBsZWFybiB0aGUgZGVmYXVsdA0KPiA+PiA+PiAgICBJUHY2IGdh dGV3YXksIHRoZSBJUHY2IHByZWZpeCBpbmZvcm1hdGlvbiwgdGhlIEROUyBpbmZvcm1hdGlvbg0K PiA+PiA+PiAgICBSRkM4MTA2IFtSRkM4MTA2XSwgYW5kIHRoZSByZW1haW5pbmcgaW5mb3JtYXRp b24gcmVxdWlyZWQgdG8NCj4gPj4gPj4gICAgZXN0YWJsaXNoIGdsb2JhbGx5IHJvdXRhYmxlIElQ djYgY29ubmVjdGl2aXR5LiAgRm9yIHRoYXQgcHVycG9zZSwNCj4gPj4gPj4gdGhlDQo+ID4+ID4+ ICAgIHRoZSBVRS9zdWJzY3JpYmVyIHNlbmRzIGEgUlMgKFJvdXRlciBTb2xpY2l0YXRpb24pIG1l c3NhZ2UuDQo+ID4+ID4+DQo+ID4+ID4+ICAgIFRoZSBGaXJzdCBIb3AgUm91dGVyIHJlY2VpdmVz IHRoaXMgVUUvc3Vic2NyaWJlciBSUyBtZXNzYWdlIGFuZA0KPiA+PiA+PiAgICBzdGFydHMgdGhl IHByb2Nlc3MgdG8gY29tcG9zZSB0aGUgcmVzcG9uc2UgdG8gdGhlIFVFL3N1YnNjcmliZXINCj4g Pj4gPj4gICAgb3JpZ2luYXRlZCBSUyBtZXNzYWdlLiAgVGhlIEZpcnN0IEhvcCBQcm92aWRlciBS b3V0ZXIgd2lsbCBhbnN3ZXINCj4gPj4gPj4gICAgdXNpbmcgYSB1bmljYXN0IFJBIChSb3V0ZXIg QWR2ZXJ0aXNlbWVudCkgdG8gdGhlIFVFL3N1YnNjcmliZXIuDQo+ID4+ID4NCj4gPj4gPiBSZWdh cmRzDQo+ID4+ID4gICAgQnJpYW4gQ2FycGVudGVyDQo+ID4+ID4NCj4gPj4gPiBPbiAwNS8wOS8y MDE3IDA5OjQzLCBXYXJyZW4gS3VtYXJpIHdyb3RlOg0KPiA+PiA+PiBJJ2QgbGlrZSB0byBub3Rl IHRoYXQgdGhhdCB0aGVyZSBpcyBjb250aW51aW5nIGRpc2N1c3Npb24gb24gdGhpcw0KPiA+PiA+ PiBkcmFmdCBvbiB0aGUgdjYgb3BzIGxpc3QgKHl1cCwgYWZ0ZXIgV0dMQyBhbmQgSUVURiBMQyA6 LSkpLiBJJ3ZlIG9ubHkNCj4gPj4gPj4gYmVlbiBhYmxlIHRvIHNvbWV3aGF0IG1vbml0b3IgaXQs IGJ1dCBoYXZlIGFza2VkIHRoZSB2Nm9wcyBjaGFpcnMgZm9yDQo+ID4+ID4+IGlucHV0LiBNdWNo IG9mIHRoZSBkaXNjdXNzaW9uIGhhcyBiZWVuIGludGVyZXN0aW5nLCBidXQgbm90DQo+ID4+ID4+ IG5lY2Vzc2FyaWx5IHBlcnRhaW5pbmcgZXhhY3RseSB0byB0aGlzIGRvY3VtZW50Lg0KPiA+PiA+ PiBGcmVkIGtpbmRseSBhc2tlZCB0aGUgbGlzdDoNCj4gPj4gPj4gaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy92Nm9wcy9icEVEdG5Za2J2SlFaQXhfcjZtdEVoZE54cncNCj4g Pj4gPj4gZm9yIGFueXRoaW5nIHN1YnN0YW50aXZlIGZvciB0aGUgZG9jdW1lbnQgKGtlZXBpbmcg aW4gbWluZCB0aGF0IGl0IGhhcw0KPiA+PiA+PiBhbHJlYWR5IGdvbmUgdGhyb3VnaCBXR0xDIGFu ZCBJRVRGIExDKS4NCj4gPj4gPj4NCj4gPj4gPj4gU28gZmFyIGl0IGRvZXNuJ3Qgc2VlbSBsaWtl IHRoZXJlIGFyZSBhbnkgb3RoZXIgbWFqb3IgY2hhbmdlcyBuZWVkZWQsDQo+ID4+ID4+IG90aGVy IHRoYW4gImFza2luZyB0aGF0IHRoZSBhcHBsaWNhYmlsaXR5IGNvbW1lbnQgdGhhdCBjb21tdW5p Y2F0aW9uDQo+ID4+ID4+IGJldHdlZW4gc3VjaCBub2RlcyBvbiBhIExBTiBzaG91bGQgZ28gdGhy b3VnaCBhIGNvbm5lY3Rpbmcgcm91dGVyDQo+ID4+ID4+ICh3aGljaCBzZWVtcyB0byBtZSBhIGdp dmVuIGR1ZSB0byB0aGUgcmVsYXRpb25zaGlwIHdpdGggcm91dGluZykNCj4gPj4gPj4gc2hvdWxk IGJlIGRvY3VtZW50ZWQuIiBhbmQgRGF2aWQgRmFybWVyJ3MgZm9sbG93dXAgLS0NCj4gPj4gPj4g aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy92Nm9wcy9fLVFsQnFHazlkQ2hv Rk9oeGlnZjVXbHhZRFkNCj4gPj4gPj4NCj4gPj4gPj4gRG9lcyBhbnlvbmUgaGF2ZSBhbnl0aGlu ZyBlbHNlICpzdWJzdGFudGl2ZSo/IElmIHNvLCBJIG1heSBoYXZlIHRvDQo+ID4+ID4+IGtpY2sg dGhpcyBiYWNrIHRvIHRoZSBXRyBmb3IgYW5vdGhlciByb3VuZC4NCj4gPj4gPj4NCj4gPj4gPj4g Vw0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiBPbiBUdWUsIEF1 ZyAyMiwgMjAxNyBhdCA3OjMxIFBNLCBTdXJlc2ggS3Jpc2huYW4NCj4gPj4gPj4gPHN1cmVzaC5r cmlzaG5hbkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+PiA+Pj4gSGkgR3VudGVyLA0KPiA+PiA+Pj4g ICBUaGFua3MgZm9yIHRoZSBwcm9wb3NlZCB0ZXh0IGNoYW5nZXMuIFRoZXkgYWRlcXVhdGVseSBh ZGRyZXNzIG15DQo+ID4+ID4+PiBESVNDVVNTDQo+ID4+ID4+PiBwb2ludHMuIEkgYW0gaG9waW5n IHlvdSB3aWxsIGFsc28gY29udmVyZ2UgaW4gdGhlIGRpc2N1c3Npb24gd2l0aA0KPiA+PiA+Pj4g TG9yZW56byBvbg0KPiA+PiA+Pj4gdGhlIGFjdHVhbCB2YWx1ZSBmb3IgdGhlIHRpbWVyIGFuZC9v ciBzcGVjaWZ5IGFuIGFwcGxpY2FiaWxpdHkNCj4gPj4gPj4+IHN0YXRlbWVudC4gSQ0KPiA+PiA+ Pj4gd2lsbCBjbGVhciBvbmNlIHRoZSBuZXcgcmV2aXNpb24gcG9zdHMuDQo+ID4+ID4+Pg0KPiA+ PiA+Pj4gUmVnYXJkcw0KPiA+PiA+Pj4gU3VyZXNoDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gT24gQXVn IDIxLCAyMDE3LCBhdCA4OjU3IEFNLCBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9B bnR3ZXJwKQ0KPiA+PiA+Pj4gPGd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tPiB3cm90ZToN Cj4gPj4gPj4+DQo+ID4+ID4+PiBIaSBTdXJlc2gsDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gTWFueSB0 aGFua3MgZm9yIHRoZSByZXZpZXcgYW5kIGZpbmRpbmcgdGhlc2UgaXNzdWVzLiBXaGF0IGRvIHlv dSB0aGluaw0KPiA+PiA+Pj4gb2YNCj4gPj4gPj4+IHRoZSBwcm9wb3NhbHMgYmVsb3cgdG8gZml4 IHRob3NlIHBvaW50cyBvZiBhdHRlbnRpb24/DQo+ID4+ID4+Pg0KPiA+PiA+Pj4NCj4gPj4gPj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPj4gPj4+ICAgIERJU0NVU1M6DQo+ID4+ID4+Pg0KPiA+PiA+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiA+PiA+Pj4NCj4gPj4gPj4+ICAgICogU2VjdGlvbiA0DQo+ID4+ID4+ Pg0KPiA+PiA+Pj4gICAgSXQgaXMgbm90IGNsZWFyIHdoYXQgeW91IGludGVuZCBoZXJlDQo+ID4+ ID4+Pg0KPiA+PiA+Pj4gICAgIklQdjYgUm91dGVyIEFkdmVydGlzZW1lbnQgSW50ZXJ2YWwgPSAz MDBzIg0KPiA+PiA+Pj4NCj4gPj4gPj4+ICAgIFRoZSByb3V0ZXIgYWR2ZXJ0aXNlbWVudCBpbnRl cnZhbCBpcyBub3QgY29uZmlndXJlZCBhcyBhbiBhYnNvbHV0ZQ0KPiA+PiA+Pj4gdmFsdWUNCj4g Pj4gPj4+IGJ1dCBhcw0KPiA+PiA+Pj4gICAgbWluaW11bSBhbmQgbWF4aW11bSBib3VuZHMgKE1p blJ0ckFkdkludGVydmFsIGFuZA0KPiA+PiA+Pj4gTWF4UnRyQWR2SW50ZXJ2YWwpDQo+ID4+ID4+ PiB3aGljaCBhcmUNCj4gPj4gPj4+ICAgIHVzZWQgdG8gY2FsY3VsYXRlIHRoZSBhY3R1YWwgYWR2 ZXJ0aXNlbWVudCBpbnRlcnZhbC4gV2hlbiB0aGUgUkEgaXMNCj4gPj4gPj4+IHNlbnQNCj4gPj4g Pj4+IGZyb20NCj4gPj4gPj4+ICAgIGFuIGludGVyZmFjZSwgdGhlIGFjdHVhbCBpbnRlcnZhbCBp cyBhbiB1bmlmb3JtbHkgZGlzdHJpYnV0ZWQNCj4gPj4gPj4+IHJhbmRvbQ0KPiA+PiA+Pj4gdmFs dWUNCj4gPj4gPj4+ICAgIGJldHdlZW4gdGhlIE1pblJ0ckFkdkludGVydmFsIGFuZCBNYXhSdHJB ZHZJbnRlcnZhbC4gQXQgdGhlIHZlcnkNCj4gPj4gPj4+IG1pbmltdW0NCj4gPj4gPj4+IHlvdQ0K PiA+PiA+Pj4gICAgbmVlZCB0byBjbGFyaWZ5IGlmIHlvdSB3b3VsZCBsaWtlIHRvIGhhdmUgdGhp cyBhcyBhIGxvd2VyIGJvdW5kIG9yDQo+ID4+ID4+PiBhcyBhbg0KPiA+PiA+Pj4gdXBwZXINCj4g Pj4gPj4+ICAgIGJvdW5kLg0KPiA+PiA+Pj4NCj4gPj4gPj4+IEdWPiBJIGNoYW5nZWQgdGhlIGxp bmUgdG8gbWFrZSBpdCBtb3JlIGNsZWFyIHRoYXQgdGhlIHRpbWVyIGluZGljYXRlcw0KPiA+PiA+ Pj4gdGhlDQo+ID4+ID4+PiBtYXhpbXVtIEFkdmVydGlzZW1lbnQgSW50ZXJ2YWwNCj4gPj4gPj4+ IEdWPiAgICAgICAgICA8dD5NYXhpbXVtIElQdjYgUm91dGVyIEFkdmVydGlzZW1lbnQgSW50ZXJ2 YWwgPSAzMDBzPC90Pg0KPiA+PiA+Pj4NCj4gPj4gPj4+DQo+ID4+ID4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4+ID4+PiAgICBDT01NRU5UOg0KPiA+PiA+Pj4NCj4gPj4gPj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPj4gPj4+DQo+ID4+ID4+PiAgICAqIFNlY3Rpb24gNA0KPiA+PiA+Pj4NCj4gPj4gPj4+ICAg IC0+IEkgdGhpbmsgdGV4dCBpcyBuZWVkZWQgaGVyZSB0byBoYW5kbGUgdGhlIGNhc2Ugd2hlcmUg dGhlIEROUw0KPiA+PiA+Pj4gc2VydmVyIGlzDQo+ID4+ID4+PiAgICBwcm92aWRlZCBpbiB0aGUg UkEgaXRzZWxmICAoUkZDODEwNikNCj4gPj4gPj4+DQo+ID4+ID4+PiAgICAiSW4gYWRkaXRpb24g aXQgd2lsbCB1c2Ugc3RhdGVsZXNzIERIQ1B2NiB0byBnZXQgdGhlIElQdjYgYWRkcmVzcw0KPiA+ PiA+Pj4gb2YgdGhlDQo+ID4+ID4+PiBETlMNCj4gPj4gPj4+ICAgIHNlcnZlciINCj4gPj4gPj4+ DQo+ID4+ID4+PiAgICAtPiBJIGFtIG5vdCBzdXJlIHdoYXQgaXMgdGhlIG1vdGl2YXRpb24gZm9y IHRoaXMgdGV4dC4NCj4gPj4gPj4+DQo+ID4+ID4+PiAgICAiaG93ZXZlciBpdCBTSE9VTEQgTk9U IHVzZSBzdGF0ZWZ1bCBESENQdjYgdG8gcmVjZWl2ZSBhIHNlcnZpY2UNCj4gPj4gPj4+IHByb3Zp ZGVyDQo+ID4+ID4+PiAgICBtYW5hZ2VkIElQdjYgYWRkcmVzcyINCj4gPj4gPj4+DQo+ID4+ID4+ PiAgICAtPiBUaGlzIHRleHQgc2VlbXMgaW5jb3JyZWN0DQo+ID4+ID4+Pg0KPiA+PiA+Pj4gICAg ImR1ZSB0byB0aGUgTC1iaXQgc2V0LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMgdG8gdGhl IEZpcnN0IEhvcA0KPiA+PiA+Pj4gUHJvdmlkZXINCj4gPj4gPj4+ICAgIFJvdXRlciINCj4gPj4g Pj4+DQo+ID4+ID4+PiAgICBJIHRoaW5rIGl0IHNob3VsZCBiZSB0aGUgZXhhY3Qgb3Bwb3NpdGUu IGkuZS4gc2F5ICp1bnNldCogaW5zdGVhZA0KPiA+PiA+Pj4gb2Ygc2V0DQo+ID4+ID4+Pg0KPiA+ PiA+Pj4gICAgImR1ZSB0byB0aGUgTC1iaXQgYmVpbmcgdW5zZXQsIGl0IFNIT1VMRCBzZW5kIHRo aXMgdHJhZmZpYyB0byB0aGUNCj4gPj4gPj4+IEZpcnN0DQo+ID4+ID4+PiBIb3ANCj4gPj4gPj4+ ICAgIFByb3ZpZGVyIFJvdXRlciINCj4gPj4gPj4+DQo+ID4+ID4+PiBHVj4gV2hhdCBhYm91dCB0 aGUgZm9sbG93aW5nIG1vZGlmaWNhdGlvbiBpbiB0aGUgdGV4dDoNCj4gPj4gPj4+DQo+ID4+ID4+ PiBPTEQ6DQo+ID4+ID4+PiBUaGUgYXJjaGl0ZWN0ZWQgcmVzdWx0IG9mIGRlc2lnbmluZyB0aGUg UkEgYXMgZG9jdW1lbnRlZCBhYm92ZSBpcw0KPiA+PiA+Pj4gICB0aGF0IGVhY2ggVUUvc3Vic2Ny aWJlciBnZXRzIGl0cyBvd24gdW5pcXVlIElQdjYgcHJlZml4IGZvciB3aGljaCBpdA0KPiA+PiA+ Pj4gICBjYW4gdXNlIFNMQUFDIG9yIGFueSBvdGhlciBtZXRob2QgdG8gc2VsZWN0IGl0cyAvMTI4 IHVuaXF1ZSBhZGRyZXNzLg0KPiA+PiA+Pj4gICBJbiBhZGRpdGlvbiBpdCB3aWxsIHVzZSBzdGF0 ZWxlc3MgREhDUHY2IHRvIGdldCB0aGUgSVB2NiBhZGRyZXNzIG9mDQo+ID4+ID4+PiAgIHRoZSBE TlMgc2VydmVyLCBob3dldmVyIGl0IFNIT1VMRCBOT1QgdXNlIHN0YXRlZnVsIERIQ1B2NiB0byBy ZWNlaXZlDQo+ID4+ID4+PiAgIGEgc2VydmljZSBwcm92aWRlciBtYW5hZ2VkIElQdjYgYWRkcmVz cy4gIElmIHRoZSBVRS9zdWJzY3JpYmVyDQo+ID4+ID4+PiAgIGRlc2lyZXMgdG8gc2VuZCBhbnl0 aGluZyBleHRlcm5hbCBpbmNsdWRpbmcgb3RoZXIgVUUvc3Vic2NyaWJlcg0KPiA+PiA+Pj4gICBk ZXZpY2VzIChhc3N1bWluZyBkZXZpY2UgdG8gZGV2aWNlIGNvbW11bmljYXRpb25zIGlzIGVuYWJs ZWQgYW5kDQo+ID4+ID4+PiAgIHN1cHBvcnRlZCksIHRoZW4sIGR1ZSB0byB0aGUgTC1iaXQgc2V0 LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMNCj4gPj4gPj4+ICAgdG8gdGhlIEZpcnN0IEhv cCBQcm92aWRlciBSb3V0ZXIuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gTmV3Og0KPiA+PiA+Pj4gVGhl IGFyY2hpdGVjdGVkIHJlc3VsdCBvZiBkZXNpZ25pbmcgdGhlIFJBIGFzIGRvY3VtZW50ZWQgYWJv dmUgaXMNCj4gPj4gPj4+IHRoYXQgZWFjaCBVRS9zdWJzY3JpYmVyIGdldHMgaXRzIG93biB1bmlx dWUgSVB2NiBwcmVmaXggZm9yIHdoaWNoIGl0DQo+ID4+ID4+PiBjYW4gdXNlIFNMQUFDIG9yIGFu eSBvdGhlciBtZXRob2QgdG8gc2VsZWN0IGl0cyAvMTI4IHVuaXF1ZSBhZGRyZXNzLg0KPiA+PiA+ Pj4gRWl0aGVyIHN0YXRlbGVzcyBESENQdjYgPHhyZWYgdGFyZ2V0PSJSRkMzNzM2Ij5SRkMzNzM2 PC94cmVmPiBvciBJUHY2DQo+ID4+ID4+PiBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBPcHRpb25zIGZv ciBETlMgQ29uZmlndXJhdGlvbg0KPiA+PiA+Pj4gPHhyZWYgdGFyZ2V0PSJSRkM4MTA2Ij5SRkM4 MTA2PC94cmVmPiBjYW4gYmUgdXNlZCB0byBnZXQgdGhlDQo+ID4+ID4+PiBJUHY2IGFkZHJlc3Mg b2YgdGhlIEROUyBzZXJ2ZXIuIElmIHRoZSBVRS9zdWJzY3JpYmVyIGRlc2lyZXMgdG8gc2VuZA0K PiA+PiA+Pj4gYW55dGhpbmcgZXh0ZXJuYWwgaW5jbHVkaW5nIG90aGVyIFVFL3N1YnNjcmliZXIg ZGV2aWNlcyAoYXNzdW1pbmcNCj4gPj4gPj4+IGRldmljZQ0KPiA+PiA+Pj4gdG8gZGV2aWNlIGNv bW11bmljYXRpb25zIGlzIGVuYWJsZWQgYW5kIHN1cHBvcnRlZCksIHRoZW4sIGR1ZSB0byB0aGUN Cj4gPj4gPj4+IEwtYml0IGJlaW5nIHVuc2V0LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMg dG8gdGhlIEZpcnN0IEhvcA0KPiA+PiA+Pj4gUHJvdmlkZXINCj4gPj4gPj4+IFJvdXRlci48L3Q+ DQo+ID4+ID4+Pg0KPiA+PiA+Pj4NCj4gPj4gPj4+DQo+ID4+ID4+PiBLaW5kIFJlZ2FyZHMsDQo+ ID4+ID4+PiBHLw0KPiA+PiA+Pj4NCj4gPj4gPj4+DQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+ DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tDQo+ID4+IEkgZG9uJ3QgdGhpbmsgdGhlIGV4ZWN1 dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkgYSBiYWQNCj4gPj4gaWRlYSBp biB0aGUgZmlyc3QgcGxhY2UuDQo+ID4+IFRoaXMgaXMgbGlrZSBwdXR0aW5nIHJhYmlkIHdlYXNl bHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyIGV4cHJlc3NpbmcNCj4gPj4gcmVncmV0IGF0IGhh dmluZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxzIGFuZCB0aGF0IHBhaXIN Cj4gPj4gb2YgcGFudHMuDQo+ID4+ICAgIC0tLW1hZg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiB2Nm9wcyBtYWlsaW5nIGxp c3QNCj4gPj4gdjZvcHNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wcw0KPiA+DQo+ID4NCj4gDQo+IA0KPiANCj4gLS0NCj4gSSBkb24ndCB0 aGluayB0aGUgZXhlY3V0aW9uIGlzIHJlbGV2YW50IHdoZW4gaXQgd2FzIG9idmlvdXNseSBhIGJh ZA0KPiBpZGVhIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4gVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFi aWQgd2Vhc2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZw0KPiByZWdyZXQg YXQgaGF2aW5nIGNob3NlbiB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQg cGFpcg0KPiBvZiBwYW50cy4NCj4gICAgLS0tbWFmDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZv cHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0K From nobody Mon Sep 11 13:34:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988EC132A65 for ; Mon, 11 Sep 2017 13:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOmRrFSBp1vi for ; Mon, 11 Sep 2017 13:34:22 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AFE132351 for ; Mon, 11 Sep 2017 13:34:21 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id i130so10010091pgc.3 for ; Mon, 11 Sep 2017 13:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FgraZ978JjaFmQWvTqks0p5ssB4rbguZudaP4H59Hx4=; b=BhvPCVISiaGTf1Gpy3nBhfpTs9ah7EO6zQNML5A51eBntWZaYy4djgy6p3NjMl9feE /GHx2NSFEe0rzJhypX6rnWFqaXW5j/HxkSUba+91FCro8kUspwiurV17YV2R55xOUg9Y JviaX634veLLovDUoYtoEW6WkUMry5uWzj1zpwT0hgHoGta3VWk/DYHNxQ0YtB6MLuL+ lUW75DdsTdKxkz+QWht4iPyQ+SRJqVi7+7QelEgDV/R0j27LDEmQenRhHhi5Yp8Ag67h 4lwEIx4KrtYU2MyLlJaynqseSxLPrw2k8ba7zDN//OH4rssd533B9oVm4SZiDIZJjO0H O+3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=FgraZ978JjaFmQWvTqks0p5ssB4rbguZudaP4H59Hx4=; b=YlaItosCzsNwiJW6BTRNnrtIAPdPZScrOdg6AiXZ17FbEvX1ewXjB0ic1JBIed43GD fu+2mZjKNOE31pebZuvgma/Sygf2CT9nUvuIe7/POodVVREaNi63vcNo9rWQQ6Y04D5n +C9uKp2WcIYVKHaG4JjWhJBv0ivgnivlMaOinyLIeJt2xmS5J2BKQJz/LzJl6mPz1Z0h M3Op0oRI02Ly0bSfttItCrh3tuhzlhfopVHpplGLC6KSHaEcTomwuc7JrYxpCgDaMqYB UMlcyjmlJa0vzlMOmXWDki7IiGvCvQvcvLXcTAHgV9Qkdtc/w+N28SJP07QQH/r/NfY7 G7aQ== X-Gm-Message-State: AHPjjUhhoA9LE02xWRX8CKolDAPlmvKBx8bbI8pMJI9npED0adEgnmJy UpPJkHY1PD4B7Co9 X-Google-Smtp-Source: ADKCNb47NAu3DIIBTPSpi2eT65891YhLqFxi3FThJGuT8ZppnrW1sZifKvmo0kBCNQgpOHL/IaEsrw== X-Received: by 10.99.163.67 with SMTP id v3mr12506557pgn.206.1505162060535; Mon, 11 Sep 2017 13:34:20 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e3sm17445082pga.80.2017.09.11.13.34.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 13:34:19 -0700 (PDT) To: Philip Homburg , v6ops@ietf.org References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 12 Sep 2017 08:34:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 20:34:24 -0000 On 12/09/2017 00:26, Philip Homburg wrote: >> It is presumably written somwhere that a DNS resolver in a CE that >> has no Internet IPv4 connectivity MUST NOT return off-site A records; >> if not, it should be. > > That would break local validating resolvers. Can you explain that a bit? Since the record concerned is useless, why do we care whether it validates? Or would this somehow affect the validation of AAAA records for the same domain? In other words, how is this different from a case with IPv4 connectivity when there is in fact no A record? > Personally I dislike DNS > resolvers that lie, how well intentioned it may be. Fair enough, but it's matter of choosing the least bad solution. > I guess the proper way to solve the issue of only local IPv4 connectivity > is to have a DHCP option that lists which IPv4 prefixes are reachable. > > That won't work for legacy hosts that don't know about that option, and > we really need to allow for legacy hosts. That won't work for legacy hosts that don't know about that option, and we really need to allow for legacy hosts. Brian From nobody Mon Sep 11 13:48:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F204132D6A for ; Mon, 11 Sep 2017 13:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyroFCjp1mi1 for ; Mon, 11 Sep 2017 13:48:40 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31F4132351 for ; Mon, 11 Sep 2017 13:48:40 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id v66so17366450pgb.5 for ; Mon, 11 Sep 2017 13:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TNEQ/0V1Zsp80rQ+radm7HP1m1Zio91A7InC5pYjhVI=; b=CcIzH6QJK3HwDAtJWB5VvLc+hXapXeGDChJTUmTowmWyDmeyrGAAHBKOBAOcZZYA7Y OCOeMc6YkYLKjHyNZzshelr0eMl28oUCeKjjWYUOnccGpCM/7Ul+wnNOBQ+g5WPcUJZy PUDxD2tYqsunjsYSFHAETZM47pj1WoEAyuuMhXmlN5TI8cC8yjhvwOL0w19Z9rxLvKzN 0IineMlv0eBhL9Inxh53TRCM2mSmvtsdWbwMqwYLViaGhi+WTkIKUBvrYqFUOGYCb1aV D0WGsuvsbq6zcjNzGqm57Zaq9iKTcujY/skWKsf4big5RG6X9o+sNR65HIH8h0RoQGix ZxPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=TNEQ/0V1Zsp80rQ+radm7HP1m1Zio91A7InC5pYjhVI=; b=oyFOplGu3zk94ol73K1F9YA7zwRmIVie/6OoiRud4za/5uf2Dn1foTuUXG/RbhJLy+ /GwwNtupeK1p7ey/aIRrWoKxod1he2PxKU0BbustWt+A1cOePXSv5OozLlySgdBAUNNc YDyJnsjZSEqeOC6XqTlOtDQ6uw/Rzo5fwDSf+kxv9voP5l33OyNBfVuWIualvKUMeIz5 2rJDuSXS6vuDUM/oRiQQ6Lz1ZpDSxB8xsIoz/8QlnbiyaCgiCniZp59q7Hik9QwYpqWf MjAVBcUt/8CIQGiw8YV+1qg8d48+5xRKdhgMbyYd/jinfD3ENzVbXisGYuo0NHv9jboX Q59A== X-Gm-Message-State: AHPjjUg8Gr0vBWwpY7Si8eqx6q5PvzGlHxhS04Qjyfk1AfvzlES8gE+Z LXDDjd5OcIrMx0hE X-Google-Smtp-Source: ADKCNb4tZKfAxQAQRs4XDN72XeBSdC7nws9Ap/WbaSBkH/+wRx0npJWVF4/APbZMrGBqyiZs/TOg1Q== X-Received: by 10.84.232.133 with SMTP id i5mr14685022plk.396.1505162919898; Mon, 11 Sep 2017 13:48:39 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s17sm14398417pgq.25.2017.09.11.13.48.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 13:48:39 -0700 (PDT) To: v6ops@ietf.org References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <85f3ebd4-0493-221c-ae05-826ca02f5d2a@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <19d26495-b9d9-970f-bdc1-5e35e46a28c6@gmail.com> Date: Tue, 12 Sep 2017 08:48:37 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <85f3ebd4-0493-221c-ae05-826ca02f5d2a@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 20:48:42 -0000 On 11/09/2017 19:01, Alexandre Petrescu wrote: > To this Fred's point, >=20 > It seemed to me obvious and did not care to reply until now. >=20 > Le 05/09/2017 =C3=A0 16:52, Templin, Fred L a =C3=A9crit=C2=A0: > [...] >> 1) In section 2: >> >> " o Two devices (subscriber/hosts), both attached to the same pr= ovider >> managed shared network should only be able to communicate thro= ugh >> the provider managed First Hop Router" That's a lower-case should, not even an RFC2119 SHOULD. So there is no need to add an "unless" clause. It doesn't matter whether the exception is "unless the shared network explicitly permits peer-to-peer operations"= or "unless it's Thursday afternoon". "Should" doesn't mean "must." Fred said: > In order to prevent that, this document would have to > require that L2 partitioning must be used. Otherwise, this document is > essentially deprecating peer-to-peer (including the Redirect function) > even for link types where it may provide useful benefits. Again, it does not require or deprecate, it only recommends. And don't forget that peer-to-peer operation will only happen for link-local addresses or for announced on-link prefixes, neither of which are covered by the concept "unique-ipv6-prefix-per-host". The draft is 100% clear on this: " o L-flag =3D 0 (the prefix is not an on-link prefix, which means tha= t the UE/subscriber will NEVER assume destination addresses that match the prefix are on-link and will ALWAYS send packets to those addresses to the appropriate gateway according to route selection rules.)" So I don't agree that this text needs changing. Brian From nobody Mon Sep 11 13:56:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA63C1330CF for ; Mon, 11 Sep 2017 13:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IFF0fsFSg-8 for ; Mon, 11 Sep 2017 13:56:41 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id CF3D2132F3B for ; Mon, 11 Sep 2017 13:56:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1drVkz-0000FKC; Mon, 11 Sep 2017 22:56:37 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> In-reply-to: Your message of "Tue, 12 Sep 2017 08:34:17 +1200 ." Date: Mon, 11 Sep 2017 22:56:36 +0200 Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 20:56:43 -0000 >> That would break local validating resolvers. > >Can you explain that a bit? Since the record concerned is useless, >why do we care whether it validates? Or would this somehow affect the >validation of AAAA records for the same domain? It is hard to tell what is going to happen when validation fails. That's local policy. One thing that may happen is that the validating resolver will consider the local resolver in the CPE to be broken and sets up a TLS (or similar) connection to a remote resolver, by passing all of this filtering. >In other words, how is this different from a case with IPv4 connectivity >when there is in fact no A record? The DNS record types available for a domain name are listed in the NSEC/NSEC3 record. So if the query for 'A' results in a empty RR then the validating resolver will look for a NSEC/NSEC3 record that confirms that this is indeed the case. >> I guess the proper way to solve the issue of only local IPv4 connectivity >> is to have a DHCP option that lists which IPv4 prefixes are reachable. >> >That won't work for legacy hosts that don't know about that option, and >we really need to allow for legacy hosts. I assume that in the future there will be systems that can talk IPv6 and need to know what IPv4 resources are locally available. Those systems would benefit from a new DHCP option. Legacy systems that only talk IPv4 don't really care. They are limited to whatever is locally available anyhow. From nobody Mon Sep 11 14:40:08 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 225BF1320CF; Mon, 11 Sep 2017 14:39:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150516599909.9617.11381215807918191665@ietfa.amsl.com> Date: Mon, 11 Sep 2017 14:39:59 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-rfc6555bis-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 21:39:59 -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 : Happy Eyeballs Version 2: Better Connectivity Using Concurrency Authors : David Schinazi Tommy Pauly Filename : draft-ietf-v6ops-rfc6555bis-05.txt Pages : 15 Date : 2017-09-11 Abstract: Many communication protocols operated over the modern Internet use host names. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a higher chance of establishing a connection sooner. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-05 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 11 14:43:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7897A133200 for ; Mon, 11 Sep 2017 14:43:57 -0700 (PDT) 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_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 D4PrQhsHQxoZ for ; Mon, 11 Sep 2017 14:43:55 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435AA1320CF for ; Mon, 11 Sep 2017 14:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1505166235; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=F3m/ZWtmNYuXpebBqftqN53lowh3W/ZbiYogDHv/jPM=; b=eu2u703saPFUj85BdZJ3psONdPOqa+N3s4StFVO9yDuochYx6SF2VjnzM/Qrgg/C V25Hcm1z2pkNHw+KG1j8ZGn5pxVu8wl6EZJFUwWAX7NYy0V5qM/BePIxNRvEYhJM vKX84HEG40/k9ecCYohrivGivDQhg6ZV0743yAbphNN+EWfzkbh8+apKAHxAgwXg zLDe3uVU1+0F/Sm7GquaOLZRteErKXBjMGAra1BiTkYNP0/y2KTZbVwq1QxPxsmw DX8oRDXZl1lyxPhf0Fgw4IJeGBWM3j0PMTWN7i13bsoa3Jux/xTXgo1JDaAkX6pv gV8K3eoAIW33IuvsgC4VVQ==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 22.5F.11091.B9307B95; Mon, 11 Sep 2017 14:43:55 -0700 (PDT) X-AuditID: 11973e15-512379c000002b53-c5-59b7039b20c6 Received: from kencur.apple.com (kencur.apple.com [17.151.62.38]) by relay7.apple.com (Apple SCV relay) with SMTP id 4B.58.07283.A9307B95; Mon, 11 Sep 2017 14:43:55 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_4Cg7L3/l+2BwKUkGUR0j2w)" Received: from da0602a-dhcp231.apple.com (da0602a-dhcp231.apple.com [17.226.23.231]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OW40067ZXP6Z840@kencur.apple.com>; Mon, 11 Sep 2017 14:43:54 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <7AF2E7C6-A075-40E9-BF64-585C44CFDDEA@apple.com> Date: Mon, 11 Sep 2017 14:43:54 -0700 In-reply-to: Cc: Tommy Pauly , draft-ietf-v6ops-rfc6555bis@ietf.org, IPv6 Operations To: Warren Kumari References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FCYqjubeXukwbFuDovDv2ayWJw+tpfZ 4vCxy0wOzB5Llvxk8rh94w97AFMUl01Kak5mWWqRvl0CV0b77q1sBRsOM1bs2CjXwDh3JWMX IyeHhICJxNkP28FsIYE1TBI75rHBxFe8vAUU5wCKb2KUuMsLEuYVEJT4MfkeC4jNLBAmsWzT P/YuRi6gkoVMEjNmrWUHSQgLSEt0XbjLCtLLJqAlcWCNEUSvjcTum68ZIUrsJHbdvs8MYrMI qEqse/MVbCanQLBE96keZoj5ORJfX/xhArFFgGoaF+yH2nWGUWLRp5lQ98tK3Jp9iRkkISGw hE1ia8cZ1gmMQrOQHDsLybEQtpbE90etQHEOIFte4uB5WYiwpsSze5+gSrQlnry7wLqAkW0V o1BuYmaObmaemV5iQUFOql5yfu4mRlBMTLcT3cF4ZpXVIUYBDkYlHt6G3m2RQqyJZcWVuYcY pTlYlMR51XQ2RwoJpCeWpGanphakFsUXleakFh9iZOLglGpgPKufwp+7I6A+cP+Jm91cAXYV Kep7ni1paeqb/7bgCNdqwcJnUu7vvl2wYA3K28q2Ozx7Cc9/9oolXXWW4h5hOyY/dehOFn2d ENm9Qcb/RVNd+7xz685/Wpw2PXbBbs8XRpMWmf6YmfypaMPvr0u3sh2cU+zJvT9qiYxxJ/ee HNUqObUdeVWxSizFGYmGWsxFxYkA87NUCGoCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUiON1OTXc28/ZIg0mXmS0O/5rJYnH62F4g 69hlJgdmjyVLfjJ53L7xhz2AKYrLJiU1J7MstUjfLoEro333VraCDYcZK3ZslGtgnLuSsYuR k0NCwERixctbQDYHh5DAJkaJu7wgYV4BQYkfk++xgNjMAmESyzb9Y+9i5AIqWcgkMWPWWnaQ hLCAtETXhbusIL1sAloSB9YYQfTaSOy++ZoRosROYtft+8wgNouAqsS6N1/BZnIKBEt0n+ph hpifI/H1xR8mEFsEqKZxwX6oXWcYJRZ9mgl1p6zErdmXmCcw8s9Cct8sJPdB2FoS3x+1AsU5 gGx5iYPnZSHCmhLP7n2CKtGWePLuAusCRrZVjAJFqTmJleZ6iQUFOal6yfm5mxhBQdxQmLqD sXG51SFGAQ5GJR7eht5tkUKsiWXFlbmHGCU4mJVEeEUeAoV4UxIrq1KL8uOLSnNSiw8xSnOw KInzzp6+PlJIID2xJDU7NbUgtQgmy8TBKdXAaPT3Usdc/WU7pe1Kphp/Xr9J1CN9sqgbRxyL wPXJBu9bl4lUpP96aMR1gDP14iWj2yt3iq+VKHi1aR3fdZ21XN/yV/XfapC+IsNquGrGjDn7 DOq+3T1yLOqbSvD6+z8lHi9P0E0I/fCg54ruhmURu45nxiz6bnWbre+JsOr5OIuFJXdnF2wW KldiKc5INNRiLipOBACyycuAXgIAAA== Archived-At: Subject: Re: [v6ops] AD review of draft-ietf-v6ops-rfc6555bis. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 21:43:57 -0000 --Boundary_(ID_4Cg7L3/l+2BwKUkGUR0j2w) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Warren, and thanks for your review. We've submitted -05 to clarify handling of negative DNS responses: https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-05 The relevant paragraph now reads: << The RECOMMENDED algorithm proceeds as follows: if a positive AAAA response (a response with at least one valid AAAA record) is received first, the first IPv6 connection attempt is immediately started. If a positive A response is received first due to reordering, the client SHOULD wait for a short time for the AAAA response to ensure preference is given to IPv6 (it is common for the AAAA response to follow the A response by a few milliseconds). This delay will be referred to as the "Resolution Delay". The RECOMMENDED value for the Resolution Delay is 50 milliseconds. If a positive AAAA response is received within the Resolution Delay period, the client immediately starts the IPv6 connection attempt. If a negative AAAA response (no error, no data) is received within the Resolution Delay period or the AAAA response has not been received by the end of the Resolution Delay period, the client SHOULD proceed to Sorting Addresses [Section 4] and staggered connection attempts [Section 5] using any IPv4 addresses returned so far. If the AAAA response arrives while these connection attempts are in progress, but before any connection has been established, then the newly received IPv6 addresses are incorporated into the list of available candidate addresses [Section 6] and the process of connection attempts will continue with the IPv6 addresses added, until one connection is established. >> Thanks, David Schinazi > On Sep 11, 2017, at 11:05, Warren Kumari wrote: > > On Mon, Sep 11, 2017 at 1:15 PM, Tommy Pauly > wrote: >> Hi Warren, >> >> Thanks for the review! >> >> You're absolutely correct that a negative query response counts to stop any delays, etc. I don't think this is pointed out explicitly. The way I would propose solving this would be to clarify in Section 3 around the parts that read "if the AAAA query returns first" and "If the A query returns first", that any the responses we are referring to include positive answers as well as negative answers like NODATA. Does that sound good to you? > > WFM. > > Please let me know once you've submitted a new version and I'll start IETF LC. > > W > > >> >> Thanks, >> Tommy >> >>> On Sep 11, 2017, at 7:24 AM, Warren Kumari wrote: >>> >>> Hi, >>> >>> I've finished my AD review of draft-ietf-v6ops-rfc6555bis. >>> >>> I have only one comment / question: >>> Section 3. Hostname Resolution Query Handling >>> " If the AAAA response is received within the Resolution Delay period, >>> the client immediately starts the IPv6 connection attempt. If, at the >>> end of the Resolution Delay period, the AAAA response has not been >>> received but the A response has been received, ..." >>> >>> So, let's say that at time T I fire off my queries, and 5ms later I >>> get back a valid A record, and a NOERROR/NODATA response to the AAAA >>> query (saying that there is no AAAA record) -- what do I do? >>> I'm assuming that I just connect with the A record immediately, but >>> this isn't actually stated anywhere (or, if it is, I missed it) - this >>> seems like a common case, and should at least be mentioned. >>> >>> W >>> >>> >>> -- >>> I don't think the execution is relevant when it was obviously a bad >>> idea in the first place. >>> This is like putting rabid weasels in your pants, and later expressing >>> regret at having chosen those particular rabid weasels and that pair >>> of pants. >>> ---maf >> > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Boundary_(ID_4Cg7L3/l+2BwKUkGUR0j2w) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Hi Warren, and thanks for your = review.

We've = submitted -05 to clarify handling of negative DNS responses:
https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-05<= /div>

The relevant = paragraph now reads:
<<
   The RECOMMENDED algorithm proceeds as follows: = if a positive AAAA
   response (a response with = at least one valid AAAA record) is received
  =  first, the first IPv6 connection attempt is immediately started. =  If
   a positive A response is received = first due to reordering, the client
   SHOULD = wait for a short time for the AAAA response to ensure
 =  preference is given to IPv6 (it is common for the AAAA response = to
   follow the A response by a few = milliseconds).  This delay will be
  =  referred to as the "Resolution Delay".  The RECOMMENDED value = for the
   Resolution Delay is 50 milliseconds. =  If a positive AAAA response is
   received = within the Resolution Delay period, the client immediately
   starts the IPv6 connection attempt.  If a = negative AAAA response (no
   error, no data) is = received within the Resolution Delay period or the
  =  AAAA response has not been received by the end of the = Resolution
   Delay period, the client SHOULD = proceed to Sorting Addresses
   [Section 4] and = staggered connection attempts [Section 5] using any
  =  IPv4 addresses returned so far.  If the AAAA response arrives = while
   these connection attempts are in = progress, but before any connection
   has been = established, then the newly received IPv6 addresses are
   incorporated into the list of available = candidate addresses
   [Section 6] and the = process of connection attempts will continue with
  =  the IPv6 addresses added, until one connection is = established.
>>

Thanks,
David = Schinazi


On = Sep 11, 2017, at 11:05, Warren Kumari <warren@kumari.net> = wrote:

On Mon, Sep 11, 2017 at 1:15 PM, = Tommy Pauly <tpauly@apple.com> wrote:
Hi Warren,

Thanks for the review!

You're = absolutely correct that a negative query response counts to stop any = delays, etc. I don't think this is pointed out explicitly. The way I = would propose solving this would be to clarify in Section 3 around the = parts that read "if the AAAA query returns first" and "If the A query = returns first", that any the responses we are referring to include = positive answers as well as negative answers like NODATA. Does that = sound good to you?

WFM.
Please let me know once you've submitted a new = version and I'll start IETF LC.

W


Thanks,
Tommy

On Sep 11, 2017, at 7:24 AM, Warren Kumari <warren@kumari.net> = wrote:

Hi,

I've = finished my AD review of draft-ietf-v6ops-rfc6555bis.

I have only one comment / question:
Section 3. =  Hostname Resolution Query Handling
" If the AAAA = response is received within the Resolution Delay period,
the= client immediately starts the IPv6 connection attempt.  If, at = the
end of the Resolution Delay period, the AAAA response = has not been
received but the A response has been = received, ..."

So, let's say that at time T = I fire off my queries, and 5ms later I
get back a valid A = record, and a NOERROR/NODATA response to the AAAA
query = (saying that there is no AAAA record) -- what do I do?
I'm = assuming that I just connect with the A record immediately, but
this isn't actually stated anywhere (or, if it is, I missed = it) - this
seems like a common case, and should at least = be mentioned.

W


--
I don't think the execution = is relevant when it was obviously a bad
idea in the first = place.
This is like putting rabid weasels in your pants, = and later expressing
regret at having chosen those = particular rabid weasels and that pair
of pants.
 ---maf




-- 
I don't think the execution is relevant when it = was obviously a bad
idea in the first = place.
This is like putting rabid weasels in = your pants, and later expressing
regret at having chosen those = particular rabid weasels and that pair
of pants.
  ---maf

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

= --Boundary_(ID_4Cg7L3/l+2BwKUkGUR0j2w)-- From nobody Mon Sep 11 15:01:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8007C126B71 for ; Mon, 11 Sep 2017 15:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCsz4mSLIAXq for ; Mon, 11 Sep 2017 15:01:37 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4879F13234B for ; Mon, 11 Sep 2017 15:01:37 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id f199so49527477wme.0 for ; Mon, 11 Sep 2017 15:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gEhHa4Tja1M32ektgKb9kjH9DClx0vV+lsgdgp8cbzI=; b=wVLzAaEG/TCxaNMgH8X2Qv/o9jkwZPnO5Vt6q0Q18Q0A4EBOhr0XM+5hnt1T9MTgRx IQo8PcabfSwsIfLdzVOqadxhwJN2Pf/yvrxo1Qzx9+JeXcmfihl0XZo1pv7l+Gum2cTD DU/njwOPGha/2Ju7zULKF/VVjcjl69zW2aspup8DQnQyFR22PMWGD04ewmOT4aO3IVkq ZHFuj/zVKHtbW0OC9/re/XbUwhvlfv6KA8zRa2HZJfZTIAxBhC4niim6WsrM0SL1eFay EPKGIqM2fKZkFYEAXQh2MmSOBrmrw/QT3bo94CzDx0uT2V2BGXRUbY4W+4aHOqWFzNd5 bSkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gEhHa4Tja1M32ektgKb9kjH9DClx0vV+lsgdgp8cbzI=; b=W0HUFrZguhGjX0WLuLfqweEFRvj5lXATLdfIMUfP3ONfuwAVzip12dqyAZhnFdeHvz JNP2ttIhQUS9GIw4FLfJ/24YOo+8W2q44TjBSqJKf6dImMXpv5aqfFsOtnhCZmw6eZcp 59XmIRorhEMEmUmfqDZOp5GTA4to/LARVTRfvIMQ3w+sLUPnRnsGhQT34zUwdHTBMzxD 3v0Ela22ZMNNSeoosRebdcPxqRBEd/kFroFCKttYDH4iXKYdohzVjolF23RCiRNTOCko Kv6Refd2V7PmS1kS9OJHl5pPs+HFB0Kl5uuzEgEGmJpb4sxFkzwLciKnk7VyIhcp4SNw QIFA== X-Gm-Message-State: AHPjjUgBa6bSEWyvcjyraeZv8/ym9uNuAeKyoNMv648yXXmQvVas6J8s 1MaDIqLj4nkm7MT8thI8JoEqMTsyrysKSVx2oB4r7A== X-Google-Smtp-Source: AOwi7QBXToPOx3KUN7+CjVABqqS+gl4JSsrvm3DKJq/37l4L3nS19p5jzqfI8dBgKqAxS2lsIv3aVnKeWNrDc5p/QS8= X-Received: by 10.28.211.66 with SMTP id k63mr2690235wmg.85.1505167295433; Mon, 11 Sep 2017 15:01:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.141 with HTTP; Mon, 11 Sep 2017 15:00:54 -0700 (PDT) In-Reply-To: <5ec52c86f18e453b8191679afb7ec1b4@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <5ec52c86f18e453b8191679afb7ec1b4@XCH15-06-08.nw.nos.boeing.com> From: Warren Kumari Date: Mon, 11 Sep 2017 18:00:54 -0400 Message-ID: To: "Templin, Fred L" Cc: Lorenzo Colitti , Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 22:01:41 -0000 On Mon, Sep 11, 2017 at 3:39 PM, Templin, Fred L wrote: > Hi Warren, > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Warren Kumari >> Sent: Sunday, September 10, 2017 2:05 PM >> To: Lorenzo Colitti >> Cc: Suresh Krishnan ; v6ops@ietf.org; draft-i= etf-v6ops-unique-ipv6-prefix-per-host@ietf.org >> Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-uniqu= e-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) >> >> [ - IESG, -Gunter (he gets a copy as part of >> draft-ietf-v6ops-unique-ipv6-prefix-per-host@), -v6chairs@ ] >> >> >> >> On Sat, Sep 9, 2017 at 8:58 PM, Lorenzo Colitti wro= te: >> > Warren, >> > >> > care to summarize the main issues that caused you to do this? We'll wa= nt to >> > make sure we don't spend too much time discussing issues that did not >> > materially impact this decision. >> > >> >> Sure. >> >> During IESG review, some of the IESG raised questions and suggested >> text to improve the document. We received responses from the authors >> saying that the questions, along with Suresh's DISCUSS, would be >> addressed. We did not see an updated draft, and it's difficult to keep >> the patched version in one's head. So, I don't know exactly what it >> looks like now, but here are some of the considerations that >> influenced my decision: >> >> 1: Brian Carpenter's: >> "I believe it's substantive that the text refers to sending unicast >> RAs without clarifying whether this means that they are sent >> with a unicast layer 2 address and a multicast layer 3 address >> (as per RFC6085) or that they are sent with both layer 2 and >> layer 3 addresses being unicast. At the moment, an implementer >> has to decide which of these is intended. If either is OK, >> that could be stated too.". >> >> 2: Fred Templin's "unless the shared network explicitly permits >> peer-to-peer operations" -- in my view adding this exact text didn't >> seem to have support, but clarifying what is meant by a "shared >> network" would be useful. > > I agree. "Shared network" is not an RFC4861 supported link type. The > supported link types are given in RFC4861 Sections 2.2 and 3.2, and this > document needs to observe the RFC4861 terminology. I do not agree with you that it needs to use RFC4861 terminology (nor, I think, does the WG) -- I do however think that it would be useful for the document to clarify what it *does* mean when it says "shared network" -- it uses the term 11 times, and some description of what it is meaning would be (IMO) useful. EKR's ballot also expressed confusion on this: -------- Eric Rescorla No Objection Comment (2017-08-15) I found the discussion of the shared network medium a bit confusing. As I understand it, the idea is that if we are on a shared network and we have the same prefix, I might try to send to you directly. What you want to do is make that not happen by having each node have a separate prefix. Correct? If so, perhaps promote this bullet, and also have it describe the problem and why this provides a solution: o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router ----- I'm also fine if the WG disagrees and feels that everyone reading this will understand what a "shared network" is (and where all things like an RA/RS will reach on one). > For example, in > the abstract and/or introduction it could say something like "shared > network types such as multicast-capable, non-broadcast multi-access > (NBMA), shared media, etc. [RFC4861]" and then the term "shared > network" could be used throughout the document. > > Having said that, however, all of those RFC4861 supported link types > support peer-to-peer communications without having to send all traffic > through a router. In order to prevent that, this document would have to > require that L2 partitioning must be used. Depends what you mean by "prevent", and what you think that document is trying to accomplish - the abstract says: "While this is still viable and operates as designed, there are some large scale environments where this concept introduces significant performance challenges and implications, specifically related to IPv6 router and neighbor discovery. This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique IPv6 address from the service provider include improved subscriber isolation and enhanced subscriber management." It doesn't say "make it completely impossible for subscribers to communicate" or "enforce isolation for security", or "prevent peer-to-peer". W > Otherwise, this document is > essentially deprecating peer-to-peer (including the Redirect function) > even for link types where it may provide useful benefits. > > Thanks - Fred > fred.l.templin@boeing.com > >> This was also mentioned in EKR's ballot -- ballot text is all below (I >> don't want it to get lost when being LCed). >> >> 3: I do not believe that I ever saw a resolution to Lorenzo's "I'll >> also point out yet again that this value is in conflict with RFC 7772 >> in the case of networks that are provide service for battery-powered >> devices. The text should either be changed to follow that RFC or to >> explain the reason for the conflict." -- I personally don't care what >> the value is (I wasn't really thinking that this would occur much on >> battery-powered devices, but I may be completely wrong), but I *do* >> think that if it conflicts with RFC 7772 it needs to note this. >> >> 4: Much of the thread above David Farmer's >> https://mailarchive.ietf.org/arch/msg/v6ops/i72cb0r6fVbxhZLhr4qybppwP6Q >> >> 5: Simply the amount of discussion after IESG eval, and IETF LC (I >> think that the number is something like 100 and >350 respectively) -- >> while many of them wandered afar from the actual draft (and, often, >> topic :-)) it is hard to make the claim that the document is really >> clear and has strong consensus from this. >> >> >> I'd note that #1, 2, and 4 are very closely related, and I think >> should be fairly easily addressed. I'm also happy for the chairs to >> have a compressed 2 WGLC (if they think appropriate). >> >> Incidentally (but in no way relevant), I happen to really like the >> idea / document, and would like to see it published (soon!). >> w >> >> >> >> -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Copy-n-paste o= f ballot >> =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >> >> Suresh KrishnanDiscuss >> >> Discuss (2017-08-16) >> >> * Section 4 >> >> It is not clear what you intend here >> >> "IPv6 Router Advertisement Interval =3D 300s" >> >> The router advertisement interval is not configured as an absolute >> value but as minimum and maximum bounds (MinRtrAdvInterval and >> MaxRtrAdvInterval) which are used to calculate the actual >> advertisement interval. When the RA is sent from an interface, the >> actual interval is an uniformly distributed random value between the >> MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum you need >> to clarify if you would like to have this as a lower bound or as an >> upper bound. >> >> Comment (2017-08-16) >> >> * Section 4 >> >> -> I think text is needed here to handle the case where the DNS server >> is provided in the RA itself (RFC8106) >> >> "In addition it will use stateless DHCPv6 to get the IPv6 address of >> the DNS server" >> >> -> I am not sure what is the motivation for this text. >> >> "however it SHOULD NOT use stateful DHCPv6 to receive a service >> provider managed IPv6 address" >> >> -> This text seems incorrect >> >> "due to the L-bit set, it SHOULD send this traffic to the First Hop >> Provider Router" >> >> I think it should be the exact opposite. i.e. say *unset* instead of set >> >> "due to the L-bit being unset, it SHOULD send this traffic to the >> First Hop Provider Router" >> >> Warren KumariYes >> >> Deborah BrungardNo Objection >> >> Ben CampbellNo Objection >> >> Comment (2017-08-16) >> >> I have no technical comments, but a number of editorial comments: >> >> - General: I think this could use another proofreading and/or editing >> pass for the following issues: >> -- Inconsistent tense--especially use of future or present continuous. >> -- Wordy and convoluted sentences >> -- Use of "/" as a conjunction. >> >> - Abstract: >> The abstract is longer and more detailed than is useful. The last >> paragraph could have stood alone as the abstract. >> It's not clear to me if "hosts (subscribers)" means something >> different than "hosts" in context. >> >> -1: >> Please expand "IA_NA" on first use. >> s/"This document will focus..."/"This document focuses..." >> >> "As such the use >> of IPv6 SLAAC based subscriber and address management for provider >> managed shared network services is the recommended technology of >> choice, as it does not exclude any known IPv6 implementation." >> Does this document make that recommendation, or is that some >> pre-existing recommendation? >> >> >> -3: "The Best Current Practice documented in this note is to provide a >> unique IPv6 prefix to hosts/subscribers devices connected to the >> provider managed shared network." >> >> The sentence hard to follow. Consider "This document recommends...". >> I'm not sure how to interpret "hosts/subscribers devices" >> >> "Each unique IPv6 prefix can >> function as control-plane anchor point to make sure that each >> subscriber is receiving" >> s/"... subscriber is receiving ..."/"... subscriber receives..." >> >> >> >> -4: Is "First Hop Provider Router" different than "First Hop Router"? >> >> In the last bullet (L-flag=3D0), are NEVER and ALWAYS in all-caps >> expected to have different meaning than if they had normal >> capitalization? >> >> The sentence starting with "The architected result of designing the RA >> as documented above..." is convoluted and hard to follow. >> >> "... however it SHOULD NOT use stateful DHCPv6 to receive >> a service provider managed IPv6 address": Is that really a >> normative requirement, or is it a statement of fact about existing >> requirements? >> >> "it SHOULD send this traffic >> to the First Hop Provider Router." : statement of fact? >> >> - 5: "To reduce >> undesired resource consumption on the First Hop Router the desire is >> to remove UE/subscriber context in the case of non-permanent UE, such >> as in the case of WiFi hotspots as quickly as possible. " >> Convoluted sentence. >> >> "A possible solution is to use a subscriber inactivity timer which, afte= r >> tracking a pre-defined (currently unspecified) number of minutes, >> deletes the subscriber context on the First Hop Router." >> >> s/which/that (Consider " ... timer that deletes...after a >> predetermined number of minutes" >> >> -7: "The >> combination of both IPv6 privacy extensions and operator based >> assignment of a Unique IPv6 Prefix per Host provides each >> implementing operator a tool to manage and provide subscriber >> services and hence reduces the experienced privacy within each >> operator controlled domain." >> >> I have trouble following that sentence. Is the point to say that >> providing tools to manage and provide services reduces privacy in >> general? As worded, it almost sounds like this is meant as a feature, >> which I assume is not the case. >> >> Spencer DawkinsNo Objection >> >> Comment (2017-08-15) >> >> One nit: >> >> Please consider moving >> >> Benefits of unique >> IPv6 prefix over a unique IPv6 address from the service provider >> include improved subscriber isolation and enhanced subscriber >> management. >> >> to the first paragraph of the Abstract. I=E2=80=99m assuming that this >> explains the =E2=80=9Cneeds that have arisen=E2=80=9D in the first sente= nce of the >> Abstract, of course. >> >> Mirja K=C3=BChlewindNo Objection >> >> Comment (2017-08-14) >> >> To me this seems approriate for BCP; I'm saying this because this was >> mentioned in the shepherd-write-up as it was brought up by the gen-art >> review. >> >> Please also consider the following comment from the gen-art review >> (Thanks Joel!): >> "The issue of status for the document (BCP vs Informational) is for the = IESG >> to conclude. However, even if it is a BCP, as I understand the purpo= se, >> this document is intended to describe the practices to be used when a >> provider has decided to deploy a /64 per host. The wording that is c= hosen >> throughout the document makes it appear that the underlying decision = about >> such a deployment is also a recommended practice." >> I agree that wording could be made clearer here! >> >> Alexey MelnikovNo Objection >> >> Comment (2017-08-12) >> >> Radius should have an informative reference on first use. >> >> Kathleen MoriartyNo Objection >> >> Comment (2017-08-15) >> >> Thank you for addressing the SecDir review: >> https://mailarchive.ietf.org/arch/msg/secdir/wWp_0vlmsz7Ss-nowjhehYImOeg >> >> Eric RescorlaNo Objection >> >> Comment (2017-08-15) >> >> Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt >> >> >> I found the discussion of the shared network medium a bit >> confusing. As I understand it, the idea is that if we are >> on a shared network and we have the same prefix, I might >> try to send to you directly. What you want to do is make >> that not happen by having each node have a separate prefix. >> Correct? If so, perhaps promote this bullet, and also have >> it describe the problem and why this provides a solution: >> >> o Two devices (subscriber/hosts), both attached to the same provider >> managed shared network should only be able to communicate through >> the provider managed First Hop Router >> >> >> It's a bit unclear to me how much you are saying that >> something is current practice versus how much you are >> recommending it. For instance, the abstract reads more >> like what you would expect for PS. >> >> This document outlines an approach utilising existing IPv6 protocols >> to allow hosts to be assigned a unique IPv6 prefix (instead of a >> unique IPv6 address from a shared IPv6 prefix). Benefits of unique >> IPv6 prefix over a unique IPv6 address from the service provider >> include improved subscriber isolation and enhanced subscriber >> management. >> >> But then S 4 seems to be documenting: >> >> The IPv6 RA flags used for best common practice in IPv6 SLAAC based >> Provider managed shared networks are: >> >> >> The use of a unique IPv6 prefix per UE adds an additional level of >> protection and efficiency as it relates to how IPv6 Neighbor >> Discovery and Router Discovery processing. Since the UE has a unique >> IPv6 prefix all traffic by default will be directed to the First Hop >> provider router. Further, the flag combinations documented above >> maximise the IPv6 configurations that are available by hosts >> including the use of privacy IPv6 addressing. >> >> It's not quite clear to me why unique prefixs are needed here if >> people set L=3D0. Is it that people ignore L=3D0? >> >> Finally, I'm a bit confused about how to read this text about the >> L=3D0 bit in cases where I have multiple devices rather than just one >> at the customer prem. Say I have a topology with a home router >> and devices behind it. I.e., >> >> Service Provider >> | >> | >> Customer >> Router >> | >> +-----------+-----------+ >> | | | >> Host 1 Host 2 Host 3 >> >> I assume what happens here is that the router gets prefix X, assigns >> itself XY, and then the Hosts get XA, XB, XC, etc, a la 7278. Is that >> right? If so, my question is about packets coming into the Router from >> the SP, which have (say) XA. The text about the L-flag suggests that >> the router should send them back to the gateway, but that's clearly >> not right. What am I missing? >> >> >> >> >> >> >> > Cheers, >> > Lorenzo >> > >> > On Sun, Sep 10, 2017 at 4:49 AM, Warren Kumari wro= te: >> >> >> >> [ Top-post ] >> >> >> >> Yup, I was thinking that, while substantive, that would be handled >> >> while still keeping it in IESG eval -- but, I've just gone back and >> >> re-read the threads, especially all of the mail (~102) after the IESG >> >> / telechat, and I've decided that I will have to return it to the WG. >> >> Seeing as it has already had a WGLC, I expect that the next one can b= e >> >> compressed. >> >> >> >> The good news is that a: there have been a number of suggestions / >> >> provided text to improve the document, and b: I'd expect the next IES= G >> >> eval to go easily. >> >> >> >> Sorry all, >> >> W >> >> >> >> >> >> On Mon, Sep 4, 2017 at 6:32 PM, Brian E Carpenter >> >> wrote: >> >> > Warren, >> >> > >> >> > I believe it's substantive that the text refers to sending unicast >> >> > RAs without clarifying whether this means that they are sent >> >> > with a unicast layer 2 address and a multicast layer 3 address >> >> > (as per RFC6085) or that they are sent with both layer 2 and >> >> > layer 3 addresses being unicast. At the moment, an implementer >> >> > has to decide which of these is intended. If either is OK, >> >> > that could be stated too. >> >> > >> >> > Specifically this clarification seems to be needed right after: >> >> > >> >> >> 4. IPv6 Unique Prefix Assignment >> >> >> >> >> >> When a UE connects to the shared provider managed network and i= s >> >> >> attached, it will initiate IP configuration phase. During this >> >> >> phase >> >> >> the UE will, from an IPv6 perspective, attempt to learn the def= ault >> >> >> IPv6 gateway, the IPv6 prefix information, the DNS information >> >> >> RFC8106 [RFC8106], and the remaining information required to >> >> >> establish globally routable IPv6 connectivity. For that purpos= e, >> >> >> the >> >> >> the UE/subscriber sends a RS (Router Solicitation) message. >> >> >> >> >> >> The First Hop Router receives this UE/subscriber RS message and >> >> >> starts the process to compose the response to the UE/subscriber >> >> >> originated RS message. The First Hop Provider Router will answ= er >> >> >> using a unicast RA (Router Advertisement) to the UE/subscriber. >> >> > >> >> > Regards >> >> > Brian Carpenter >> >> > >> >> > On 05/09/2017 09:43, Warren Kumari wrote: >> >> >> I'd like to note that that there is continuing discussion on this >> >> >> draft on the v6 ops list (yup, after WGLC and IETF LC :-)). I've o= nly >> >> >> been able to somewhat monitor it, but have asked the v6ops chairs = for >> >> >> input. Much of the discussion has been interesting, but not >> >> >> necessarily pertaining exactly to this document. >> >> >> Fred kindly asked the list: >> >> >> https://mailarchive.ietf.org/arch/msg/v6ops/bpEDtnYkbvJQZAx_r6mtEh= dNxrw >> >> >> for anything substantive for the document (keeping in mind that it= has >> >> >> already gone through WGLC and IETF LC). >> >> >> >> >> >> So far it doesn't seem like there are any other major changes need= ed, >> >> >> other than "asking that the applicability comment that communicati= on >> >> >> between such nodes on a LAN should go through a connecting router >> >> >> (which seems to me a given due to the relationship with routing) >> >> >> should be documented." and David Farmer's followup -- >> >> >> https://mailarchive.ietf.org/arch/msg/v6ops/_-QlBqGk9dChoFOhxigf5W= lxYDY >> >> >> >> >> >> Does anyone have anything else *substantive*? If so, I may have to >> >> >> kick this back to the WG for another round. >> >> >> >> >> >> W >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan >> >> >> wrote: >> >> >>> Hi Gunter, >> >> >>> Thanks for the proposed text changes. They adequately address m= y >> >> >>> DISCUSS >> >> >>> points. I am hoping you will also converge in the discussion with >> >> >>> Lorenzo on >> >> >>> the actual value for the timer and/or specify an applicability >> >> >>> statement. I >> >> >>> will clear once the new revision posts. >> >> >>> >> >> >>> Regards >> >> >>> Suresh >> >> >>> >> >> >>> On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Ant= werp) >> >> >>> wrote: >> >> >>> >> >> >>> Hi Suresh, >> >> >>> >> >> >>> Many thanks for the review and finding these issues. What do you = think >> >> >>> of >> >> >>> the proposals below to fix those points of attention? >> >> >>> >> >> >>> >> >> >>> -----------------------------------------------------------------= ----- >> >> >>> DISCUSS: >> >> >>> >> >> >>> -----------------------------------------------------------------= ----- >> >> >>> >> >> >>> * Section 4 >> >> >>> >> >> >>> It is not clear what you intend here >> >> >>> >> >> >>> "IPv6 Router Advertisement Interval =3D 300s" >> >> >>> >> >> >>> The router advertisement interval is not configured as an abso= lute >> >> >>> value >> >> >>> but as >> >> >>> minimum and maximum bounds (MinRtrAdvInterval and >> >> >>> MaxRtrAdvInterval) >> >> >>> which are >> >> >>> used to calculate the actual advertisement interval. When the = RA is >> >> >>> sent >> >> >>> from >> >> >>> an interface, the actual interval is an uniformly distributed >> >> >>> random >> >> >>> value >> >> >>> between the MinRtrAdvInterval and MaxRtrAdvInterval. At the ve= ry >> >> >>> minimum >> >> >>> you >> >> >>> need to clarify if you would like to have this as a lower boun= d or >> >> >>> as an >> >> >>> upper >> >> >>> bound. >> >> >>> >> >> >>> GV> I changed the line to make it more clear that the timer indic= ates >> >> >>> the >> >> >>> maximum Advertisement Interval >> >> >>> GV> Maximum IPv6 Router Advertisement Interval =3D 30= 0s >> >> >>> >> >> >>> >> >> >>> -----------------------------------------------------------------= ----- >> >> >>> COMMENT: >> >> >>> >> >> >>> -----------------------------------------------------------------= ----- >> >> >>> >> >> >>> * Section 4 >> >> >>> >> >> >>> -> I think text is needed here to handle the case where the DN= S >> >> >>> server is >> >> >>> provided in the RA itself (RFC8106) >> >> >>> >> >> >>> "In addition it will use stateless DHCPv6 to get the IPv6 addr= ess >> >> >>> of the >> >> >>> DNS >> >> >>> server" >> >> >>> >> >> >>> -> I am not sure what is the motivation for this text. >> >> >>> >> >> >>> "however it SHOULD NOT use stateful DHCPv6 to receive a servic= e >> >> >>> provider >> >> >>> managed IPv6 address" >> >> >>> >> >> >>> -> This text seems incorrect >> >> >>> >> >> >>> "due to the L-bit set, it SHOULD send this traffic to the Firs= t Hop >> >> >>> Provider >> >> >>> Router" >> >> >>> >> >> >>> I think it should be the exact opposite. i.e. say *unset* inst= ead >> >> >>> of set >> >> >>> >> >> >>> "due to the L-bit being unset, it SHOULD send this traffic to = the >> >> >>> First >> >> >>> Hop >> >> >>> Provider Router" >> >> >>> >> >> >>> GV> What about the following modification in the text: >> >> >>> >> >> >>> OLD: >> >> >>> The architected result of designing the RA as documented above is >> >> >>> that each UE/subscriber gets its own unique IPv6 prefix for whi= ch it >> >> >>> can use SLAAC or any other method to select its /128 unique add= ress. >> >> >>> In addition it will use stateless DHCPv6 to get the IPv6 addres= s of >> >> >>> the DNS server, however it SHOULD NOT use stateful DHCPv6 to re= ceive >> >> >>> a service provider managed IPv6 address. If the UE/subscriber >> >> >>> desires to send anything external including other UE/subscriber >> >> >>> devices (assuming device to device communications is enabled an= d >> >> >>> supported), then, due to the L-bit set, it SHOULD send this tra= ffic >> >> >>> to the First Hop Provider Router. >> >> >>> >> >> >>> New: >> >> >>> The architected result of designing the RA as documented above is >> >> >>> that each UE/subscriber gets its own unique IPv6 prefix for which= it >> >> >>> can use SLAAC or any other method to select its /128 unique addre= ss. >> >> >>> Either stateless DHCPv6 RFC3736 o= r IPv6 >> >> >>> Router Advertisement Options for DNS Configuration >> >> >>> RFC8106 can be used to get the >> >> >>> IPv6 address of the DNS server. If the UE/subscriber desires to s= end >> >> >>> anything external including other UE/subscriber devices (assuming >> >> >>> device >> >> >>> to device communications is enabled and supported), then, due to = the >> >> >>> L-bit being unset, it SHOULD send this traffic to the First Hop >> >> >>> Provider >> >> >>> Router. >> >> >>> >> >> >>> >> >> >>> >> >> >>> Kind Regards, >> >> >>> G/ >> >> >>> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> I don't think the execution is relevant when it was obviously a bad >> >> idea in the first place. >> >> This is like putting rabid weasels in your pants, and later expressin= g >> >> regret at having chosen those particular rabid weasels and that pair >> >> of pants. >> >> ---maf >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> > >> > >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Sep 11 15:28:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8E313219C for ; Mon, 11 Sep 2017 15:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLD11DWfyW00 for ; Mon, 11 Sep 2017 15:27:59 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825E4126B71 for ; Mon, 11 Sep 2017 15:27:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8BMRxWM015311; Mon, 11 Sep 2017 15:27:59 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8BMRtAu015305 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 11 Sep 2017 15:27:55 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 11 Sep 2017 15:27:54 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 11 Sep 2017 15:27:54 -0700 From: "Templin, Fred L" To: Brian E Carpenter , "v6ops@ietf.org" Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTJcbyZ/JGPtSOiEKRi/iUYLBZ76KmYOMAgAnSVoyAABWYEA== Date: Mon, 11 Sep 2017 22:27:54 +0000 Message-ID: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <85f3ebd4-0493-221c-ae05-826ca02f5d2a@gmail.com> <19d26495-b9d9-970f-bdc1-5e35e46a28c6@gmail.com> In-Reply-To: <19d26495-b9d9-970f-bdc1-5e35e46a28c6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 22:28:01 -0000 SGkgQnJpYW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMg W21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRSBDYXJw ZW50ZXINCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMTEsIDIwMTcgMTo0OSBQTQ0KPiBUbzog djZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gU3VyZXNoIEtyaXNobmFuJ3Mg RGlzY3VzcyBvbiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0w NzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IE9uIDExLzA5LzIwMTcgMTk6MDEs IEFsZXhhbmRyZSBQZXRyZXNjdSB3cm90ZToNCj4gPiBUbyB0aGlzIEZyZWQncyBwb2ludCwNCj4g Pg0KPiA+IEl0IHNlZW1lZCB0byBtZSBvYnZpb3VzIGFuZCBkaWQgbm90IGNhcmUgdG8gcmVwbHkg dW50aWwgbm93Lg0KPiA+DQo+ID4gTGUgMDUvMDkvMjAxNyDDoCAxNjo1MiwgVGVtcGxpbiwgRnJl ZCBMIGEgw6ljcml0wqA6DQo+ID4gWy4uLl0NCj4gPj4gMSkgSW4gc2VjdGlvbiAyOg0KPiA+Pg0K PiA+PiAgICAgICIgbyAgVHdvIGRldmljZXMgKHN1YnNjcmliZXIvaG9zdHMpLCBib3RoIGF0dGFj aGVkIHRvIHRoZSBzYW1lIHByb3ZpZGVyDQo+ID4+ICAgICAgICAgbWFuYWdlZCBzaGFyZWQgbmV0 d29yayBzaG91bGQgb25seSBiZSBhYmxlIHRvIGNvbW11bmljYXRlIHRocm91Z2gNCj4gPj4gICAg ICAgICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVyIg0KPiANCj4gVGhhdCdz IGEgbG93ZXItY2FzZSBzaG91bGQsIG5vdCBldmVuIGFuIFJGQzIxMTkgU0hPVUxELiBTbyB0aGVy ZSBpcyBubw0KPiBuZWVkIHRvIGFkZCBhbiAidW5sZXNzIiBjbGF1c2UuIEl0IGRvZXNuJ3QgbWF0 dGVyIHdoZXRoZXIgdGhlIGV4Y2VwdGlvbg0KPiBpcyAidW5sZXNzIHRoZSBzaGFyZWQgbmV0d29y ayBleHBsaWNpdGx5IHBlcm1pdHMgcGVlci10by1wZWVyIG9wZXJhdGlvbnMiDQo+IG9yICJ1bmxl c3MgaXQncyBUaHVyc2RheSBhZnRlcm5vb24iLiAiU2hvdWxkIiBkb2Vzbid0IG1lYW4gIm11c3Qu Ig0KPiANCj4gRnJlZCBzYWlkOg0KPiANCj4gPiBJbiBvcmRlciB0byBwcmV2ZW50IHRoYXQsIHRo aXMgZG9jdW1lbnQgd291bGQgaGF2ZSB0bw0KPiA+IHJlcXVpcmUgdGhhdCBMMiBwYXJ0aXRpb25p bmcgbXVzdCBiZSB1c2VkLiBPdGhlcndpc2UsIHRoaXMgZG9jdW1lbnQgaXMNCj4gPiBlc3NlbnRp YWxseSBkZXByZWNhdGluZyBwZWVyLXRvLXBlZXIgKGluY2x1ZGluZyB0aGUgUmVkaXJlY3QgZnVu Y3Rpb24pDQo+ID4gZXZlbiBmb3IgbGluayB0eXBlcyB3aGVyZSBpdCBtYXkgcHJvdmlkZSB1c2Vm dWwgYmVuZWZpdHMuDQo+IA0KPiBBZ2FpbiwgaXQgZG9lcyBub3QgcmVxdWlyZSBvciBkZXByZWNh dGUsIGl0IG9ubHkgcmVjb21tZW5kcy4gQW5kIGRvbid0DQo+IGZvcmdldCB0aGF0IHBlZXItdG8t cGVlciBvcGVyYXRpb24gd2lsbCBvbmx5IGhhcHBlbiBmb3IgbGluay1sb2NhbA0KPiBhZGRyZXNz ZXMgb3IgZm9yIGFubm91bmNlZCBvbi1saW5rIHByZWZpeGVzLCBuZWl0aGVyIG9mIHdoaWNoIGFy ZQ0KPiBjb3ZlcmVkIGJ5IHRoZSBjb25jZXB0ICJ1bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3Qi LiBUaGUgZHJhZnQgaXMNCj4gMTAwJSBjbGVhciBvbiB0aGlzOg0KDQpQZWVyIHRvIHBlZXIgY2Fu IGhhcHBlbiBmb3Igbm9uLWxpbmstbG9jYWwgYWRkcmVzc2VzIGlmIHRoZXJlIGlzIGEgUmVkaXJl Y3QsDQpvciBpZiBJIGNhbGwgbXkgbmVpZ2hib3IgdXAgb24gdGhlIHBob25lIGFuZCBhc2sgaGlt IGZvciBoaXMgTUFDIGFkZHJlc3MNCmFuZCB0aGVuIHNldCB1cCBhIHN0YXRpYyBuZWlnaGJvciBj YWNoZSBlbnRyeS4NCg0KPiAiICAgbyAgTC1mbGFnID0gMCAodGhlIHByZWZpeCBpcyBub3QgYW4g b24tbGluayBwcmVmaXgsIHdoaWNoIG1lYW5zIHRoYXQNCj4gICAgICAgdGhlIFVFL3N1YnNjcmli ZXIgd2lsbCBORVZFUiBhc3N1bWUgZGVzdGluYXRpb24gYWRkcmVzc2VzIHRoYXQNCj4gICAgICAg bWF0Y2ggdGhlIHByZWZpeCBhcmUgb24tbGluayBhbmQgd2lsbCBBTFdBWVMgc2VuZCBwYWNrZXRz IHRvIHRob3NlDQo+ICAgICAgIGFkZHJlc3NlcyB0byB0aGUgYXBwcm9wcmlhdGUgZ2F0ZXdheSBh Y2NvcmRpbmcgdG8gcm91dGUgc2VsZWN0aW9uDQo+ICAgICAgIHJ1bGVzLikiDQoNClVubGVzcyB0 aGVyZSBpcyBhIFJlZGlyZWN0IChvciBhIHN0YXRpYyBuZWlnaGJvciBjYWNoZSBlbnRyeSBnZXRz IGFkZGVkKS4NCg0KPiBTbyBJIGRvbid0IGFncmVlIHRoYXQgdGhpcyB0ZXh0IG5lZWRzIGNoYW5n aW5nLg0KDQpZb3Ugc2hvdWxkIGFncmVlIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBub3QgaW50ZW5k aW5nIHRvIGRlcHJlY2F0ZQ0KcGVlci10by1wZWVyPyBJZiB5ZXMsIHRoZW4gdGhlIGRvY3VtZW50 IHNob3VsZCBtYWtlIHRoYXQgY2xlYXIuDQoNClRoYW5rcyAtIEZyZWQNCg0KPiAgICAgQnJpYW4N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Mon Sep 11 15:38:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12B31330C2; Mon, 11 Sep 2017 15:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sD_5pIOEZJq1; Mon, 11 Sep 2017 15:38:02 -0700 (PDT) Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D467713213D; Mon, 11 Sep 2017 15:38:01 -0700 (PDT) X-AuditID: 60721c4b-a3fff70000007844-1d-59b7104593cc Received: from VAADCEX13.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 99.2F.30788.54017B95; Mon, 11 Sep 2017 18:37:57 -0400 (EDT) Received: from VAADCEX09.cable.comcast.com (147.191.102.76) by VAADCEX13.cable.comcast.com (147.191.102.80) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 11 Sep 2017 18:37:56 -0400 Received: from VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0]) by VAADCEX09.cable.comcast.com ([fe80::3aea:a7ff:fe12:e2a0%19]) with mapi id 15.00.1293.005; Mon, 11 Sep 2017 18:37:56 -0400 From: "Brzozowski, John" To: Warren Kumari , Lorenzo Colitti CC: Brian E Carpenter , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , Suresh Krishnan Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTFuKYkPyp/oueP0qWqLt0C3+aF6KPD4OAgAJDVgCAFFAMAIAADemAgAet3gCAAFZlgIABUQ0AgAFpVIA= Date: Mon, 11 Sep 2017 22:37:56 +0000 Message-ID: <2C7D1552-D046-4A78-B36D-837F6B9BBF2A@cable.comcast.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.21.0.170409 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [96.114.156.9] Content-Type: text/plain; charset="utf-8" Content-ID: <25F906AC0206874F82526D328CBDDC6A@comcast.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA11Ub0wbZRzOe3elR+3LXg5K33XMbMfmnDoGZH/qMtEYzVj2YUy/rPvgOODW NnQt3rVj9YNjuhgLIbrMf6sGZsRsbAslOGAYwK404584J9PpCHOGagTNFExG0Eq8f4WrXy6/ e5739zzP73eXlyaZZpONdnv9vODlPGyGiaoQ99q3PI96HEVjM9vtb9wcIOx3z2+2R8buA3u8 Y9xgH7veT9oHr08Qz2SU9YanjGXnOgNlra2LRNnk90ljOXXItLua97iP8cLW0gqTKxYKEbWt bxLHF/t/N9aD6EmiAWTSGG3D16amDQ3ARDOoh8DN994zqi9RgBsHY0B9GQH4wc8Jo9ySgXbg K9cmlToX7cM3ZuaVdhL9DXBTKKQQOegEbuwYVqRyUT3Ak+0RUu2oxEunblJyTaGNONHUIlnQ NETP4aH6Parb6xQOLUwoZzLRAfzL+ZMGuQYoDy+MXlaCk8iK7yRatCEQbu27Qaq1Bc9MLynn LagQf/dnG6XiT+Dx2wmg1kW469MBDV+H/1gazZAzkGgzjny+VZXfhT8+PW5U6/X4ncaflBqi bDxyNqG1WvFg/KrhbbAmrEsUXlEK65TCOqWwTukcMFwE5id3FBYXbysssRfu3N4J5M8v5O+7 CtoX98QAogFrhizocTAG7pgYPBoDNTTBWuD9oSsOJqvSVx10caLrsBDw8CKbCwt+7HYwcBmu DHhqWBu0rpL6c5ZRL18neni/9L+xD8OCbyQh6zInBsRad5XbFxAPBwRPDGCalGSDlCQAq7ng K7zgU81iYA1NsVbYdktyRE7Oz9fwfC0vpNg6mmYxnM+SGrMF3skfP+L2+FO01LdbzoT0jBJ2 Ldxf/5mDydMTurzr4csybdPT/49M0Jkx4KTNUu52KOcWa7mjotupWefAl+RQ5hSq2K6GB2SQ SYE6y7XwhLyivBSVbjcKTgP6gx+mkgTdqTw7Fu4lCYby+ry8zQpNypRyqyvgXR7flgdDue0O ZpWOkGPY8uG7f3U5GIsOX0liWwfnaiIOZrWOTQ+TujtmQZX03+TANmVQ6WZZmZ6BLhl8SAOV 4TE8pHwmDdPNng9fk2e3aEy626y0ZEJaslk+AkU/59cv+XEZNadQbckbZJBJgWlLflRdskal O9mkS6T0QfkWeuLbEvNvZz4xBJlLT/3THa+4tQtO9g3vrCh6ZKigrrzqgqXpi/CmZ2e/bny1 e9PegdvOsbeGBnpL/j0l+hLZl4aBsNE55z0YOXM3+f4d15H+5ugcavmypyO+OP/h2dnmrwLJ eMPBxNNdWX35lb+OREs3RC9P9L740UXTC75plhJdXPFjpCBy/wFmOHz8sQUAAA== Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 22:38:06 -0000 SnVtcGluZyBpbiBhIGxpdHRsZSBsYXRlIGhlcmUsIEZXSVcgdGhlIG9ubHkgaXRlbSB3ZSAoR3Vu dGVyIGFuZCBJKSByZWFsbHkgaW50ZW5kIG9uIGFkZHJlc3NpbmcgaXMgTG9yZW56b+KAmXMgY29t bWVudC4gIEl0IGlzIHBlcmZlY3RseSB2YWxpZC4gIEd1bnRlciBhbmQgSSBtZWFudCB0byBhZGRy ZXNzIHRoZSBzYW1lIGFuZCBoYXZlIGJlZW4gZW1haWxpbmcgdG8gcmVzb2x2ZSB0aGUgcmVxdWVz dC4NCg0KQWxsIG90aGVyIGNvbW1lbnRzIGFyZSBsYXJnZWx5IHVucmVsYXRlZC4gIFZvbHVtZSBk b2VzIG5vdCBpbXBseSByZWxldmFuY2UuDQoNCkpvaG4NCisxLTQ4NC05NjItMDA2MA0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV2FycmVuIEt1bWFyaSA8d2FycmVuQGt1bWFy aS5uZXQ+DQpEYXRlOiBTdW5kYXksIFNlcHRlbWJlciAxMCwgMjAxNyBhdCAxNzowNA0KVG86IExv cmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPg0KQ2M6IEJyaWFuIENhcnBlbnRlciA8 YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiwgdjZvcHMgPHY2b3BzQGlldGYub3JnPiwgImRy YWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QGlldGYub3JnIiA8ZHJh ZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAaWV0Zi5vcmc+LCBTdXJl c2ggS3Jpc2huYW4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW3Y2 b3BzXSBTdXJlc2ggS3Jpc2huYW4ncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVl LWlwdjYtcHJlZml4LXBlci1ob3N0LTA3OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KUmVz ZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPg0KUmVzZW50LVRvOiA8am9obl9icnpv em93c2tpQGNvbWNhc3QuY29tPiwgR3VudGVyIFZhbiBkZSBWZWxkZSA8Z3VudGVyLnZhbl9kZV92 ZWxkZUBub2tpYS5jb20+DQpSZXNlbnQtRGF0ZTogU3VuZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTcg YXQgMTc6MDUNCg0KICAgIFsgLSBJRVNHLCAtR3VudGVyIChoZSBnZXRzIGEgY29weSBhcyBwYXJ0 IG9mDQogICAgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAKSwg LXY2Y2hhaXJzQCBdDQogICAgDQogICAgDQogICAgDQogICAgT24gU2F0LCBTZXAgOSwgMjAxNyBh dCA4OjU4IFBNLCBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4gd3JvdGU6DQog ICAgPiBXYXJyZW4sDQogICAgPg0KICAgID4gY2FyZSB0byBzdW1tYXJpemUgdGhlIG1haW4gaXNz dWVzIHRoYXQgY2F1c2VkIHlvdSB0byBkbyB0aGlzPyBXZSdsbCB3YW50IHRvDQogICAgPiBtYWtl IHN1cmUgd2UgZG9uJ3Qgc3BlbmQgdG9vIG11Y2ggdGltZSBkaXNjdXNzaW5nIGlzc3VlcyB0aGF0 IGRpZCBub3QNCiAgICA+IG1hdGVyaWFsbHkgaW1wYWN0IHRoaXMgZGVjaXNpb24uDQogICAgPg0K ICAgIA0KICAgIFN1cmUuDQogICAgDQogICAgRHVyaW5nIElFU0cgcmV2aWV3LCBzb21lIG9mIHRo ZSBJRVNHIHJhaXNlZCBxdWVzdGlvbnMgYW5kIHN1Z2dlc3RlZA0KICAgIHRleHQgdG8gaW1wcm92 ZSB0aGUgZG9jdW1lbnQuIFdlIHJlY2VpdmVkIHJlc3BvbnNlcyBmcm9tIHRoZSBhdXRob3JzDQog ICAgc2F5aW5nIHRoYXQgdGhlIHF1ZXN0aW9ucywgYWxvbmcgd2l0aCBTdXJlc2gncyBESVNDVVNT LCB3b3VsZCBiZQ0KICAgIGFkZHJlc3NlZC4gV2UgZGlkIG5vdCBzZWUgYW4gdXBkYXRlZCBkcmFm dCwgYW5kIGl0J3MgZGlmZmljdWx0IHRvIGtlZXANCiAgICB0aGUgcGF0Y2hlZCB2ZXJzaW9uIGlu IG9uZSdzIGhlYWQuIFNvLCBJIGRvbid0IGtub3cgZXhhY3RseSB3aGF0IGl0DQogICAgbG9va3Mg bGlrZSBub3csIGJ1dCBoZXJlIGFyZSBzb21lIG9mIHRoZSBjb25zaWRlcmF0aW9ucyB0aGF0DQog ICAgaW5mbHVlbmNlZCBteSBkZWNpc2lvbjoNCiAgICANCiAgICAxOiBCcmlhbiBDYXJwZW50ZXIn czoNCiAgICAiSSBiZWxpZXZlIGl0J3Mgc3Vic3RhbnRpdmUgdGhhdCB0aGUgdGV4dCByZWZlcnMg dG8gc2VuZGluZyB1bmljYXN0DQogICAgUkFzIHdpdGhvdXQgY2xhcmlmeWluZyB3aGV0aGVyIHRo aXMgbWVhbnMgdGhhdCB0aGV5IGFyZSBzZW50DQogICAgd2l0aCBhIHVuaWNhc3QgbGF5ZXIgMiBh ZGRyZXNzIGFuZCBhIG11bHRpY2FzdCBsYXllciAzIGFkZHJlc3MNCiAgICAoYXMgcGVyIFJGQzYw ODUpIG9yIHRoYXQgdGhleSBhcmUgc2VudCB3aXRoIGJvdGggbGF5ZXIgMiBhbmQNCiAgICBsYXll ciAzIGFkZHJlc3NlcyBiZWluZyB1bmljYXN0LiBBdCB0aGUgbW9tZW50LCBhbiBpbXBsZW1lbnRl cg0KICAgIGhhcyB0byBkZWNpZGUgd2hpY2ggb2YgdGhlc2UgaXMgaW50ZW5kZWQuIElmIGVpdGhl ciBpcyBPSywNCiAgICB0aGF0IGNvdWxkIGJlIHN0YXRlZCB0b28uIi4NCiAgICANCiAgICAyOiBG cmVkIFRlbXBsaW4ncyAidW5sZXNzIHRoZSBzaGFyZWQgbmV0d29yayBleHBsaWNpdGx5IHBlcm1p dHMNCiAgICBwZWVyLXRvLXBlZXIgb3BlcmF0aW9ucyIgLS0gaW4gbXkgdmlldyBhZGRpbmcgdGhp cyBleGFjdCB0ZXh0IGRpZG4ndA0KICAgIHNlZW0gdG8gaGF2ZSBzdXBwb3J0LCBidXQgY2xhcmlm eWluZyB3aGF0IGlzIG1lYW50IGJ5IGEgInNoYXJlZA0KICAgIG5ldHdvcmsiIHdvdWxkIGJlIHVz ZWZ1bC4NCiAgICBUaGlzIHdhcyBhbHNvIG1lbnRpb25lZCBpbiBFS1IncyBiYWxsb3QgLS0gYmFs bG90IHRleHQgaXMgYWxsIGJlbG93IChJDQogICAgZG9uJ3Qgd2FudCBpdCB0byBnZXQgbG9zdCB3 aGVuIGJlaW5nIExDZWQpLg0KICAgIA0KICAgIDM6IEkgZG8gbm90IGJlbGlldmUgdGhhdCBJIGV2 ZXIgc2F3IGEgcmVzb2x1dGlvbiB0byBMb3JlbnpvJ3MgIkknbGwNCiAgICBhbHNvIHBvaW50IG91 dCB5ZXQgYWdhaW4gdGhhdCB0aGlzIHZhbHVlIGlzIGluIGNvbmZsaWN0IHdpdGggUkZDIDc3NzIN CiAgICBpbiB0aGUgY2FzZSBvZiBuZXR3b3JrcyB0aGF0IGFyZSBwcm92aWRlIHNlcnZpY2UgZm9y IGJhdHRlcnktcG93ZXJlZA0KICAgIGRldmljZXMuIFRoZSB0ZXh0IHNob3VsZCBlaXRoZXIgYmUg Y2hhbmdlZCB0byBmb2xsb3cgdGhhdCBSRkMgb3IgdG8NCiAgICBleHBsYWluIHRoZSByZWFzb24g Zm9yIHRoZSBjb25mbGljdC4iIC0tIEkgcGVyc29uYWxseSBkb24ndCBjYXJlIHdoYXQNCiAgICB0 aGUgdmFsdWUgaXMgKEkgd2Fzbid0IHJlYWxseSB0aGlua2luZyB0aGF0IHRoaXMgd291bGQgb2Nj dXIgbXVjaCBvbg0KICAgIGJhdHRlcnktcG93ZXJlZCBkZXZpY2VzLCBidXQgSSBtYXkgYmUgY29t cGxldGVseSB3cm9uZyksIGJ1dCBJICpkbyoNCiAgICB0aGluayB0aGF0IGlmIGl0IGNvbmZsaWN0 cyB3aXRoIFJGQyA3NzcyIGl0IG5lZWRzIHRvIG5vdGUgdGhpcy4NCiAgICANCiAgICA0OiBNdWNo IG9mIHRoZSB0aHJlYWQgYWJvdmUgRGF2aWQgRmFybWVyJ3MNCiAgICBodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3Y2b3BzL2k3MmNiMHI2ZlZieGhaTGhyNHF5YnBwd1A2UQ0K ICAgIA0KICAgIDU6IFNpbXBseSB0aGUgYW1vdW50IG9mIGRpc2N1c3Npb24gYWZ0ZXIgSUVTRyBl dmFsLCBhbmQgSUVURiBMQyAoSQ0KICAgIHRoaW5rIHRoYXQgdGhlIG51bWJlciBpcyBzb21ldGhp bmcgbGlrZSAxMDAgYW5kID4zNTAgcmVzcGVjdGl2ZWx5KSAtLQ0KICAgIHdoaWxlIG1hbnkgb2Yg dGhlbSB3YW5kZXJlZCBhZmFyIGZyb20gdGhlIGFjdHVhbCBkcmFmdCAoYW5kLCBvZnRlbiwNCiAg ICB0b3BpYyA6LSkpIGl0IGlzIGhhcmQgdG8gbWFrZSB0aGUgY2xhaW0gdGhhdCB0aGUgZG9jdW1l bnQgaXMgcmVhbGx5DQogICAgY2xlYXIgYW5kIGhhcyBzdHJvbmcgY29uc2Vuc3VzIGZyb20gdGhp cy4NCiAgICANCiAgICANCiAgICBJJ2Qgbm90ZSB0aGF0ICMxLCAyLCBhbmQgNCBhcmUgdmVyeSBj bG9zZWx5IHJlbGF0ZWQsIGFuZCBJIHRoaW5rDQogICAgc2hvdWxkIGJlIGZhaXJseSBlYXNpbHkg YWRkcmVzc2VkLiBJJ20gYWxzbyBoYXBweSBmb3IgdGhlIGNoYWlycyB0bw0KICAgIGhhdmUgYSBj b21wcmVzc2VkIDIgV0dMQyAoaWYgdGhleSB0aGluayBhcHByb3ByaWF0ZSkuDQogICAgDQogICAg SW5jaWRlbnRhbGx5IChidXQgaW4gbm8gd2F5IHJlbGV2YW50KSwgSSBoYXBwZW4gdG8gcmVhbGx5 IGxpa2UgdGhlDQogICAgaWRlYSAvIGRvY3VtZW50LCBhbmQgd291bGQgbGlrZSB0byBzZWUgaXQg cHVibGlzaGVkIChzb29uISkuDQogICAgdw0KICAgIA0KICAgIA0KICAgIA0KICAgIC09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LT0tIENvcHktbi1wYXN0ZSBvZiBiYWxsb3QNCiAgICA9LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LT0tDQogICAgDQogICAgU3VyZXNoIEtyaXNobmFuRGlzY3Vzcw0K ICAgIA0KICAgIERpc2N1c3MgKDIwMTctMDgtMTYpDQogICAgDQogICAgKiBTZWN0aW9uIDQNCiAg ICANCiAgICBJdCBpcyBub3QgY2xlYXIgd2hhdCB5b3UgaW50ZW5kIGhlcmUNCiAgICANCiAgICAi SVB2NiBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBJbnRlcnZhbCA9IDMwMHMiDQogICAgDQogICAgVGhl IHJvdXRlciBhZHZlcnRpc2VtZW50IGludGVydmFsIGlzIG5vdCBjb25maWd1cmVkIGFzIGFuIGFi c29sdXRlDQogICAgdmFsdWUgYnV0IGFzIG1pbmltdW0gYW5kIG1heGltdW0gYm91bmRzIChNaW5S dHJBZHZJbnRlcnZhbCBhbmQNCiAgICBNYXhSdHJBZHZJbnRlcnZhbCkgd2hpY2ggYXJlIHVzZWQg dG8gY2FsY3VsYXRlIHRoZSBhY3R1YWwNCiAgICBhZHZlcnRpc2VtZW50IGludGVydmFsLiBXaGVu IHRoZSBSQSBpcyBzZW50IGZyb20gYW4gaW50ZXJmYWNlLCB0aGUNCiAgICBhY3R1YWwgaW50ZXJ2 YWwgaXMgYW4gdW5pZm9ybWx5IGRpc3RyaWJ1dGVkIHJhbmRvbSB2YWx1ZSBiZXR3ZWVuIHRoZQ0K ICAgIE1pblJ0ckFkdkludGVydmFsIGFuZCBNYXhSdHJBZHZJbnRlcnZhbC4gQXQgdGhlIHZlcnkg bWluaW11bSB5b3UgbmVlZA0KICAgIHRvIGNsYXJpZnkgaWYgeW91IHdvdWxkIGxpa2UgdG8gaGF2 ZSB0aGlzIGFzIGEgbG93ZXIgYm91bmQgb3IgYXMgYW4NCiAgICB1cHBlciBib3VuZC4NCiAgICAN CiAgICBDb21tZW50ICgyMDE3LTA4LTE2KQ0KICAgIA0KICAgICogU2VjdGlvbiA0DQogICAgDQog ICAgLT4gSSB0aGluayB0ZXh0IGlzIG5lZWRlZCBoZXJlIHRvIGhhbmRsZSB0aGUgY2FzZSB3aGVy ZSB0aGUgRE5TIHNlcnZlcg0KICAgIGlzIHByb3ZpZGVkIGluIHRoZSBSQSBpdHNlbGYgIChSRkM4 MTA2KQ0KICAgIA0KICAgICJJbiBhZGRpdGlvbiBpdCB3aWxsIHVzZSBzdGF0ZWxlc3MgREhDUHY2 IHRvIGdldCB0aGUgSVB2NiBhZGRyZXNzIG9mDQogICAgdGhlIEROUyBzZXJ2ZXIiDQogICAgDQog ICAgLT4gSSBhbSBub3Qgc3VyZSB3aGF0IGlzIHRoZSBtb3RpdmF0aW9uIGZvciB0aGlzIHRleHQu DQogICAgDQogICAgImhvd2V2ZXIgaXQgU0hPVUxEIE5PVCB1c2Ugc3RhdGVmdWwgREhDUHY2IHRv IHJlY2VpdmUgYSBzZXJ2aWNlDQogICAgcHJvdmlkZXIgbWFuYWdlZCBJUHY2IGFkZHJlc3MiDQog ICAgDQogICAgLT4gVGhpcyB0ZXh0IHNlZW1zIGluY29ycmVjdA0KICAgIA0KICAgICJkdWUgdG8g dGhlIEwtYml0IHNldCwgaXQgU0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljIHRvIHRoZSBGaXJzdCBI b3ANCiAgICBQcm92aWRlciBSb3V0ZXIiDQogICAgDQogICAgSSB0aGluayBpdCBzaG91bGQgYmUg dGhlIGV4YWN0IG9wcG9zaXRlLiBpLmUuIHNheSAqdW5zZXQqIGluc3RlYWQgb2Ygc2V0DQogICAg DQogICAgImR1ZSB0byB0aGUgTC1iaXQgYmVpbmcgdW5zZXQsIGl0IFNIT1VMRCBzZW5kIHRoaXMg dHJhZmZpYyB0byB0aGUNCiAgICBGaXJzdCBIb3AgUHJvdmlkZXIgUm91dGVyIg0KICAgIA0KICAg IFdhcnJlbiBLdW1hcmlZZXMNCiAgICANCiAgICBEZWJvcmFoIEJydW5nYXJkTm8gT2JqZWN0aW9u DQogICAgDQogICAgQmVuIENhbXBiZWxsTm8gT2JqZWN0aW9uDQogICAgDQogICAgQ29tbWVudCAo MjAxNy0wOC0xNikNCiAgICANCiAgICBJIGhhdmUgbm8gdGVjaG5pY2FsIGNvbW1lbnRzLCBidXQg YSBudW1iZXIgb2YgZWRpdG9yaWFsIGNvbW1lbnRzOg0KICAgIA0KICAgIC0gR2VuZXJhbDogSSB0 aGluayB0aGlzIGNvdWxkIHVzZSBhbm90aGVyIHByb29mcmVhZGluZyBhbmQvb3IgZWRpdGluZw0K ICAgIHBhc3MgZm9yIHRoZSBmb2xsb3dpbmcgaXNzdWVzOg0KICAgIC0tIEluY29uc2lzdGVudCB0 ZW5zZS0tZXNwZWNpYWxseSB1c2Ugb2YgZnV0dXJlIG9yIHByZXNlbnQgY29udGludW91cy4NCiAg ICAtLSBXb3JkeSBhbmQgY29udm9sdXRlZCBzZW50ZW5jZXMNCiAgICAtLSBVc2Ugb2YgIi8iIGFz IGEgY29uanVuY3Rpb24uDQogICAgDQogICAgLSBBYnN0cmFjdDoNCiAgICBUaGUgYWJzdHJhY3Qg aXMgbG9uZ2VyIGFuZCBtb3JlIGRldGFpbGVkIHRoYW4gaXMgdXNlZnVsLiBUaGUgbGFzdA0KICAg IHBhcmFncmFwaCBjb3VsZCBoYXZlIHN0b29kIGFsb25lIGFzIHRoZSBhYnN0cmFjdC4NCiAgICBJ dCdzIG5vdCBjbGVhciB0byBtZSBpZiAiaG9zdHMgKHN1YnNjcmliZXJzKSIgbWVhbnMgc29tZXRo aW5nDQogICAgZGlmZmVyZW50IHRoYW4gImhvc3RzIiBpbiBjb250ZXh0Lg0KICAgIA0KICAgIC0x Og0KICAgIFBsZWFzZSBleHBhbmQgIklBX05BIiBvbiBmaXJzdCB1c2UuDQogICAgcy8iVGhpcyBk b2N1bWVudCB3aWxsIGZvY3VzLi4uIi8iVGhpcyBkb2N1bWVudCBmb2N1c2VzLi4uIg0KICAgIA0K ICAgICJBcyBzdWNoIHRoZSB1c2UNCiAgICAgICBvZiBJUHY2IFNMQUFDIGJhc2VkIHN1YnNjcmli ZXIgYW5kIGFkZHJlc3MgbWFuYWdlbWVudCBmb3IgcHJvdmlkZXINCiAgICAgICBtYW5hZ2VkIHNo YXJlZCBuZXR3b3JrIHNlcnZpY2VzIGlzIHRoZSByZWNvbW1lbmRlZCB0ZWNobm9sb2d5IG9mDQog ICAgICAgY2hvaWNlLCBhcyBpdCBkb2VzIG5vdCBleGNsdWRlIGFueSBrbm93biBJUHY2IGltcGxl bWVudGF0aW9uLiINCiAgICBEb2VzIHRoaXMgZG9jdW1lbnQgbWFrZSB0aGF0IHJlY29tbWVuZGF0 aW9uLCBvciBpcyB0aGF0IHNvbWUNCiAgICBwcmUtZXhpc3RpbmcgcmVjb21tZW5kYXRpb24/DQog ICAgDQogICAgDQogICAgLTM6ICJUaGUgQmVzdCBDdXJyZW50IFByYWN0aWNlIGRvY3VtZW50ZWQg aW4gdGhpcyBub3RlIGlzIHRvIHByb3ZpZGUgYQ0KICAgICAgIHVuaXF1ZSBJUHY2IHByZWZpeCB0 byBob3N0cy9zdWJzY3JpYmVycyBkZXZpY2VzIGNvbm5lY3RlZCB0byB0aGUNCiAgICAgICBwcm92 aWRlciBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrLiINCiAgICANCiAgICBUaGUgc2VudGVuY2UgaGFy ZCB0byBmb2xsb3cuIENvbnNpZGVyICJUaGlzIGRvY3VtZW50IHJlY29tbWVuZHMuLi4iLg0KICAg IEknbSBub3Qgc3VyZSBob3cgdG8gaW50ZXJwcmV0ICJob3N0cy9zdWJzY3JpYmVycyBkZXZpY2Vz Ig0KICAgIA0KICAgICJFYWNoIHVuaXF1ZSBJUHY2IHByZWZpeCBjYW4NCiAgICAgICBmdW5jdGlv biBhcyBjb250cm9sLXBsYW5lIGFuY2hvciBwb2ludCB0byBtYWtlIHN1cmUgdGhhdCBlYWNoDQog ICAgICAgc3Vic2NyaWJlciBpcyByZWNlaXZpbmciDQogICAgcy8iLi4uIHN1YnNjcmliZXIgaXMg cmVjZWl2aW5nIC4uLiIvIi4uLiBzdWJzY3JpYmVyIHJlY2VpdmVzLi4uIg0KICAgIA0KICAgIA0K ICAgIA0KICAgIC00OiBJcyAiRmlyc3QgSG9wIFByb3ZpZGVyIFJvdXRlciIgZGlmZmVyZW50IHRo YW4gIkZpcnN0IEhvcCBSb3V0ZXIiPw0KICAgIA0KICAgIEluIHRoZSBsYXN0IGJ1bGxldCAoTC1m bGFnPTApLCBhcmUgTkVWRVIgYW5kIEFMV0FZUyBpbiBhbGwtY2Fwcw0KICAgIGV4cGVjdGVkIHRv IGhhdmUgZGlmZmVyZW50IG1lYW5pbmcgdGhhbiBpZiB0aGV5IGhhZCBub3JtYWwNCiAgICBjYXBp dGFsaXphdGlvbj8NCiAgICANCiAgICBUaGUgc2VudGVuY2Ugc3RhcnRpbmcgd2l0aCAiVGhlIGFy Y2hpdGVjdGVkIHJlc3VsdCBvZiBkZXNpZ25pbmcgdGhlIFJBDQogICAgYXMgZG9jdW1lbnRlZCBh Ym92ZS4uLiIgaXMgY29udm9sdXRlZCBhbmQgaGFyZCB0byBmb2xsb3cuDQogICAgDQogICAgIi4u LiBob3dldmVyIGl0IFNIT1VMRCBOT1QgdXNlIHN0YXRlZnVsIERIQ1B2NiB0byByZWNlaXZlDQog ICAgICAgYSBzZXJ2aWNlIHByb3ZpZGVyIG1hbmFnZWQgSVB2NiBhZGRyZXNzIjogSXMgdGhhdCBy ZWFsbHkgYQ0KICAgIG5vcm1hdGl2ZSByZXF1aXJlbWVudCwgb3IgaXMgaXQgYSBzdGF0ZW1lbnQg b2YgZmFjdCBhYm91dCBleGlzdGluZw0KICAgIHJlcXVpcmVtZW50cz8NCiAgICANCiAgICAiaXQg U0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljDQogICAgICAgdG8gdGhlIEZpcnN0IEhvcCBQcm92aWRl ciBSb3V0ZXIuIiA6IHN0YXRlbWVudCBvZiBmYWN0Pw0KICAgIA0KICAgIC0gNTogIlRvIHJlZHVj ZQ0KICAgICAgIHVuZGVzaXJlZCByZXNvdXJjZSBjb25zdW1wdGlvbiBvbiB0aGUgRmlyc3QgSG9w IFJvdXRlciB0aGUgZGVzaXJlIGlzDQogICAgICAgdG8gcmVtb3ZlIFVFL3N1YnNjcmliZXIgY29u dGV4dCBpbiB0aGUgY2FzZSBvZiBub24tcGVybWFuZW50IFVFLCBzdWNoDQogICAgICAgYXMgaW4g dGhlIGNhc2Ugb2YgV2lGaSBob3RzcG90cyBhcyBxdWlja2x5IGFzIHBvc3NpYmxlLiAiDQogICAg Q29udm9sdXRlZCBzZW50ZW5jZS4NCiAgICANCiAgICAiQSBwb3NzaWJsZSBzb2x1dGlvbiBpcyB0 byB1c2UgYSBzdWJzY3JpYmVyIGluYWN0aXZpdHkgdGltZXIgd2hpY2gsIGFmdGVyDQogICAgICAg dHJhY2tpbmcgYSBwcmUtZGVmaW5lZCAoY3VycmVudGx5IHVuc3BlY2lmaWVkKSBudW1iZXIgb2Yg bWludXRlcywNCiAgICAgICBkZWxldGVzIHRoZSBzdWJzY3JpYmVyIGNvbnRleHQgb24gdGhlIEZp cnN0IEhvcCBSb3V0ZXIuIg0KICAgIA0KICAgIHMvd2hpY2gvdGhhdCAgIChDb25zaWRlciAiIC4u LiB0aW1lciB0aGF0IGRlbGV0ZXMuLi5hZnRlciBhDQogICAgcHJlZGV0ZXJtaW5lZCBudW1iZXIg b2YgbWludXRlcyINCiAgICANCiAgICAtNzogIlRoZQ0KICAgICAgIGNvbWJpbmF0aW9uIG9mIGJv dGggSVB2NiBwcml2YWN5IGV4dGVuc2lvbnMgYW5kIG9wZXJhdG9yIGJhc2VkDQogICAgICAgYXNz aWdubWVudCBvZiBhIFVuaXF1ZSBJUHY2IFByZWZpeCBwZXIgSG9zdCBwcm92aWRlcyBlYWNoDQog ICAgICAgaW1wbGVtZW50aW5nIG9wZXJhdG9yIGEgdG9vbCB0byBtYW5hZ2UgYW5kIHByb3ZpZGUg c3Vic2NyaWJlcg0KICAgICAgIHNlcnZpY2VzIGFuZCBoZW5jZSByZWR1Y2VzIHRoZSBleHBlcmll bmNlZCBwcml2YWN5IHdpdGhpbiBlYWNoDQogICAgICAgb3BlcmF0b3IgY29udHJvbGxlZCBkb21h aW4uIg0KICAgIA0KICAgIEkgaGF2ZSB0cm91YmxlIGZvbGxvd2luZyB0aGF0IHNlbnRlbmNlLiBJ cyB0aGUgcG9pbnQgdG8gc2F5IHRoYXQNCiAgICBwcm92aWRpbmcgdG9vbHMgdG8gbWFuYWdlIGFu ZCBwcm92aWRlIHNlcnZpY2VzIHJlZHVjZXMgcHJpdmFjeSBpbg0KICAgIGdlbmVyYWw/IEFzIHdv cmRlZCwgaXQgYWxtb3N0IHNvdW5kcyBsaWtlIHRoaXMgaXMgbWVhbnQgYXMgYSBmZWF0dXJlLA0K ICAgIHdoaWNoIEkgYXNzdW1lIGlzIG5vdCB0aGUgY2FzZS4NCiAgICANCiAgICBTcGVuY2VyIERh d2tpbnNObyBPYmplY3Rpb24NCiAgICANCiAgICBDb21tZW50ICgyMDE3LTA4LTE1KQ0KICAgIA0K ICAgIE9uZSBuaXQ6DQogICAgDQogICAgUGxlYXNlIGNvbnNpZGVyIG1vdmluZw0KICAgIA0KICAg ICAgIEJlbmVmaXRzIG9mIHVuaXF1ZQ0KICAgICAgIElQdjYgcHJlZml4IG92ZXIgYSB1bmlxdWUg SVB2NiBhZGRyZXNzIGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXINCiAgICAgICBpbmNsdWRlIGlt cHJvdmVkIHN1YnNjcmliZXIgaXNvbGF0aW9uIGFuZCBlbmhhbmNlZCBzdWJzY3JpYmVyDQogICAg ICAgbWFuYWdlbWVudC4NCiAgICANCiAgICB0byB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHRoZSBB YnN0cmFjdC4gSeKAmW0gYXNzdW1pbmcgdGhhdCB0aGlzDQogICAgZXhwbGFpbnMgdGhlIOKAnG5l ZWRzIHRoYXQgaGF2ZSBhcmlzZW7igJ0gaW4gdGhlIGZpcnN0IHNlbnRlbmNlIG9mIHRoZQ0KICAg IEFic3RyYWN0LCBvZiBjb3Vyc2UuDQogICAgDQogICAgTWlyamEgS8O8aGxld2luZE5vIE9iamVj dGlvbg0KICAgIA0KICAgIENvbW1lbnQgKDIwMTctMDgtMTQpDQogICAgDQogICAgVG8gbWUgdGhp cyBzZWVtcyBhcHByb3JpYXRlIGZvciBCQ1A7IEknbSBzYXlpbmcgdGhpcyBiZWNhdXNlIHRoaXMg d2FzDQogICAgbWVudGlvbmVkIGluIHRoZSBzaGVwaGVyZC13cml0ZS11cCBhcyBpdCB3YXMgYnJv dWdodCB1cCBieSB0aGUgZ2VuLWFydA0KICAgIHJldmlldy4NCiAgICANCiAgICBQbGVhc2UgYWxz byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGNvbW1lbnQgZnJvbSB0aGUgZ2VuLWFydCByZXZpZXcN CiAgICAoVGhhbmtzIEpvZWwhKToNCiAgICAiVGhlIGlzc3VlIG9mIHN0YXR1cyBmb3IgdGhlIGRv Y3VtZW50IChCQ1AgdnMgSW5mb3JtYXRpb25hbCkgaXMgZm9yIHRoZSBJRVNHDQogICAgICAgdG8g Y29uY2x1ZGUuICBIb3dldmVyLCBldmVuIGlmIGl0IGlzIGEgQkNQLCBhcyBJIHVuZGVyc3RhbmQg dGhlIHB1cnBvc2UsDQogICAgICAgdGhpcyBkb2N1bWVudCBpcyBpbnRlbmRlZCB0byBkZXNjcmli ZSB0aGUgcHJhY3RpY2VzIHRvIGJlIHVzZWQgd2hlbiBhDQogICAgICAgcHJvdmlkZXIgaGFzIGRl Y2lkZWQgdG8gZGVwbG95IGEgLzY0IHBlciBob3N0LiAgVGhlIHdvcmRpbmcgdGhhdCBpcyBjaG9z ZW4NCiAgICAgICB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCBtYWtlcyBpdCBhcHBlYXIgdGhhdCB0 aGUgdW5kZXJseWluZyBkZWNpc2lvbiBhYm91dA0KICAgICAgIHN1Y2ggYSBkZXBsb3ltZW50IGlz IGFsc28gYSByZWNvbW1lbmRlZCBwcmFjdGljZS4iDQogICAgSSBhZ3JlZSB0aGF0IHdvcmRpbmcg Y291bGQgYmUgbWFkZSBjbGVhcmVyIGhlcmUhDQogICAgDQogICAgQWxleGV5IE1lbG5pa292Tm8g T2JqZWN0aW9uDQogICAgDQogICAgQ29tbWVudCAoMjAxNy0wOC0xMikNCiAgICANCiAgICBSYWRp dXMgc2hvdWxkIGhhdmUgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIG9uIGZpcnN0IHVzZS4NCiAg ICANCiAgICBLYXRobGVlbiBNb3JpYXJ0eU5vIE9iamVjdGlvbg0KICAgIA0KICAgIENvbW1lbnQg KDIwMTctMDgtMTUpDQogICAgDQogICAgVGhhbmsgeW91IGZvciBhZGRyZXNzaW5nIHRoZSBTZWNE aXIgcmV2aWV3Og0KICAgIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc2Vj ZGlyL3dXcF8wdmxtc3o3U3Mtbm93amhlaFlJbU9lZw0KICAgIA0KICAgIEVyaWMgUmVzY29ybGFO byBPYmplY3Rpb24NCiAgICANCiAgICBDb21tZW50ICgyMDE3LTA4LTE1KQ0KICAgIA0KICAgIERv Y3VtZW50OiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNy50 eHQNCiAgICANCiAgICANCiAgICBJIGZvdW5kIHRoZSBkaXNjdXNzaW9uIG9mIHRoZSBzaGFyZWQg bmV0d29yayBtZWRpdW0gYSBiaXQNCiAgICBjb25mdXNpbmcuIEFzIEkgdW5kZXJzdGFuZCBpdCwg dGhlIGlkZWEgaXMgdGhhdCBpZiB3ZSBhcmUNCiAgICBvbiBhIHNoYXJlZCBuZXR3b3JrIGFuZCB3 ZSBoYXZlIHRoZSBzYW1lIHByZWZpeCwgSSBtaWdodA0KICAgIHRyeSB0byBzZW5kIHRvIHlvdSBk aXJlY3RseS4gV2hhdCB5b3Ugd2FudCB0byBkbyBpcyBtYWtlDQogICAgdGhhdCBub3QgaGFwcGVu IGJ5IGhhdmluZyBlYWNoIG5vZGUgaGF2ZSBhIHNlcGFyYXRlIHByZWZpeC4NCiAgICBDb3JyZWN0 PyBJZiBzbywgcGVyaGFwcyBwcm9tb3RlIHRoaXMgYnVsbGV0LCBhbmQgYWxzbyBoYXZlDQogICAg aXQgZGVzY3JpYmUgdGhlIHByb2JsZW0gYW5kIHdoeSB0aGlzIHByb3ZpZGVzIGEgc29sdXRpb246 DQogICAgDQogICAgICAgbyAgVHdvIGRldmljZXMgKHN1YnNjcmliZXIvaG9zdHMpLCBib3RoIGF0 dGFjaGVkIHRvIHRoZSBzYW1lIHByb3ZpZGVyDQogICAgICAgICAgbWFuYWdlZCBzaGFyZWQgbmV0 d29yayBzaG91bGQgb25seSBiZSBhYmxlIHRvIGNvbW11bmljYXRlIHRocm91Z2gNCiAgICAgICAg ICB0aGUgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3AgUm91dGVyDQogICAgDQogICAgDQogICAg SXQncyBhIGJpdCB1bmNsZWFyIHRvIG1lIGhvdyBtdWNoIHlvdSBhcmUgc2F5aW5nIHRoYXQNCiAg ICBzb21ldGhpbmcgaXMgY3VycmVudCBwcmFjdGljZSB2ZXJzdXMgaG93IG11Y2ggeW91IGFyZQ0K ICAgIHJlY29tbWVuZGluZyBpdC4gRm9yIGluc3RhbmNlLCB0aGUgYWJzdHJhY3QgcmVhZHMgbW9y ZQ0KICAgIGxpa2Ugd2hhdCB5b3Ugd291bGQgZXhwZWN0IGZvciBQUy4NCiAgICANCiAgICAgICBU aGlzIGRvY3VtZW50IG91dGxpbmVzIGFuIGFwcHJvYWNoIHV0aWxpc2luZyBleGlzdGluZyBJUHY2 IHByb3RvY29scw0KICAgICAgIHRvIGFsbG93IGhvc3RzIHRvIGJlIGFzc2lnbmVkIGEgdW5pcXVl IElQdjYgcHJlZml4IChpbnN0ZWFkIG9mIGENCiAgICAgICB1bmlxdWUgSVB2NiBhZGRyZXNzIGZy b20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLiAgQmVuZWZpdHMgb2YgdW5pcXVlDQogICAgICAgSVB2 NiBwcmVmaXggb3ZlciBhIHVuaXF1ZSBJUHY2IGFkZHJlc3MgZnJvbSB0aGUgc2VydmljZSBwcm92 aWRlcg0KICAgICAgIGluY2x1ZGUgaW1wcm92ZWQgc3Vic2NyaWJlciBpc29sYXRpb24gYW5kIGVu aGFuY2VkIHN1YnNjcmliZXINCiAgICAgICBtYW5hZ2VtZW50Lg0KICAgIA0KICAgIEJ1dCB0aGVu IFMgNCBzZWVtcyB0byBiZSBkb2N1bWVudGluZzoNCiAgICANCiAgICAgICBUaGUgSVB2NiBSQSBm bGFncyB1c2VkIGZvciBiZXN0IGNvbW1vbiBwcmFjdGljZSBpbiBJUHY2IFNMQUFDIGJhc2VkDQog ICAgICAgUHJvdmlkZXIgbWFuYWdlZCBzaGFyZWQgbmV0d29ya3MgYXJlOg0KICAgIA0KICAgIA0K ICAgICAgIFRoZSB1c2Ugb2YgYSB1bmlxdWUgSVB2NiBwcmVmaXggcGVyIFVFIGFkZHMgYW4gYWRk aXRpb25hbCBsZXZlbCBvZg0KICAgICAgIHByb3RlY3Rpb24gYW5kIGVmZmljaWVuY3kgYXMgaXQg cmVsYXRlcyB0byBob3cgSVB2NiBOZWlnaGJvcg0KICAgICAgIERpc2NvdmVyeSBhbmQgUm91dGVy IERpc2NvdmVyeSBwcm9jZXNzaW5nLiAgU2luY2UgdGhlIFVFIGhhcyBhIHVuaXF1ZQ0KICAgICAg IElQdjYgcHJlZml4IGFsbCB0cmFmZmljIGJ5IGRlZmF1bHQgd2lsbCBiZSBkaXJlY3RlZCB0byB0 aGUgRmlyc3QgSG9wDQogICAgICAgcHJvdmlkZXIgcm91dGVyLiAgRnVydGhlciwgdGhlIGZsYWcg Y29tYmluYXRpb25zIGRvY3VtZW50ZWQgYWJvdmUNCiAgICAgICBtYXhpbWlzZSB0aGUgSVB2NiBj b25maWd1cmF0aW9ucyB0aGF0IGFyZSBhdmFpbGFibGUgYnkgaG9zdHMNCiAgICAgICBpbmNsdWRp bmcgdGhlIHVzZSBvZiBwcml2YWN5IElQdjYgYWRkcmVzc2luZy4NCiAgICANCiAgICBJdCdzIG5v dCBxdWl0ZSBjbGVhciB0byBtZSB3aHkgdW5pcXVlIHByZWZpeHMgYXJlIG5lZWRlZCBoZXJlIGlm DQogICAgcGVvcGxlIHNldCBMPTAuIElzIGl0IHRoYXQgcGVvcGxlIGlnbm9yZSBMPTA/DQogICAg DQogICAgRmluYWxseSwgSSdtIGEgYml0IGNvbmZ1c2VkIGFib3V0IGhvdyB0byByZWFkIHRoaXMg dGV4dCBhYm91dCB0aGUNCiAgICBMPTAgYml0IGluIGNhc2VzIHdoZXJlIEkgaGF2ZSBtdWx0aXBs ZSBkZXZpY2VzIHJhdGhlciB0aGFuIGp1c3Qgb25lDQogICAgYXQgdGhlIGN1c3RvbWVyIHByZW0u IFNheSBJIGhhdmUgYSB0b3BvbG9neSB3aXRoIGEgaG9tZSByb3V0ZXINCiAgICBhbmQgZGV2aWNl cyBiZWhpbmQgaXQuIEkuZS4sDQogICAgDQogICAgICAgICAgICAgICAgICAgICAgICBTZXJ2aWNl IFByb3ZpZGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDdXN0b21l cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb3V0ZXINCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tKw0KICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgICAg ICAgICAgICAgICAgSG9zdCAxICAgICAgSG9zdCAyICAgICAgSG9zdCAzDQogICAgDQogICAgSSBh c3N1bWUgd2hhdCBoYXBwZW5zIGhlcmUgaXMgdGhhdCB0aGUgcm91dGVyIGdldHMgcHJlZml4IFgs IGFzc2lnbnMNCiAgICBpdHNlbGYgWFksIGFuZCB0aGVuIHRoZSBIb3N0cyBnZXQgWEEsIFhCLCBY QywgZXRjLCBhIGxhIDcyNzguIElzIHRoYXQNCiAgICByaWdodD8gSWYgc28sIG15IHF1ZXN0aW9u IGlzIGFib3V0IHBhY2tldHMgY29taW5nIGludG8gdGhlIFJvdXRlciBmcm9tDQogICAgdGhlIFNQ LCB3aGljaCBoYXZlIChzYXkpIFhBLiAgVGhlIHRleHQgYWJvdXQgdGhlIEwtZmxhZyBzdWdnZXN0 cyB0aGF0DQogICAgdGhlIHJvdXRlciBzaG91bGQgc2VuZCB0aGVtIGJhY2sgdG8gdGhlIGdhdGV3 YXksIGJ1dCB0aGF0J3MgY2xlYXJseQ0KICAgIG5vdCByaWdodC4gV2hhdCBhbSBJIG1pc3Npbmc/ DQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgPiBDaGVlcnMsDQogICAg PiBMb3JlbnpvDQogICAgPg0KICAgID4gT24gU3VuLCBTZXAgMTAsIDIwMTcgYXQgNDo0OSBBTSwg V2FycmVuIEt1bWFyaSA8d2FycmVuQGt1bWFyaS5uZXQ+IHdyb3RlOg0KICAgID4+DQogICAgPj4g WyBUb3AtcG9zdCBdDQogICAgPj4NCiAgICA+PiBZdXAsIEkgd2FzIHRoaW5raW5nIHRoYXQsIHdo aWxlIHN1YnN0YW50aXZlLCB0aGF0IHdvdWxkIGJlIGhhbmRsZWQNCiAgICA+PiB3aGlsZSBzdGls bCBrZWVwaW5nIGl0IGluIElFU0cgZXZhbCAtLSBidXQsIEkndmUganVzdCBnb25lIGJhY2sgYW5k DQogICAgPj4gcmUtcmVhZCB0aGUgdGhyZWFkcywgZXNwZWNpYWxseSBhbGwgb2YgdGhlIG1haWwg KH4xMDIpIGFmdGVyIHRoZSBJRVNHDQogICAgPj4gLyB0ZWxlY2hhdCwgYW5kIEkndmUgZGVjaWRl ZCB0aGF0IEkgd2lsbCBoYXZlIHRvIHJldHVybiBpdCB0byB0aGUgV0cuDQogICAgPj4gU2VlaW5n IGFzIGl0IGhhcyBhbHJlYWR5IGhhZCBhIFdHTEMsIEkgZXhwZWN0IHRoYXQgdGhlIG5leHQgb25l IGNhbiBiZQ0KICAgID4+IGNvbXByZXNzZWQuDQogICAgPj4NCiAgICA+PiBUaGUgZ29vZCBuZXdz IGlzIHRoYXQgYTogdGhlcmUgaGF2ZSBiZWVuIGEgbnVtYmVyIG9mIHN1Z2dlc3Rpb25zIC8NCiAg ICA+PiBwcm92aWRlZCB0ZXh0IHRvIGltcHJvdmUgdGhlIGRvY3VtZW50LCBhbmQgYjogSSdkIGV4 cGVjdCB0aGUgbmV4dCBJRVNHDQogICAgPj4gZXZhbCB0byBnbyBlYXNpbHkuDQogICAgPj4NCiAg ICA+PiBTb3JyeSBhbGwsDQogICAgPj4gVw0KICAgID4+DQogICAgPj4NCiAgICA+PiBPbiBNb24s IFNlcCA0LCAyMDE3IGF0IDY6MzIgUE0sIEJyaWFuIEUgQ2FycGVudGVyDQogICAgPj4gPGJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPj4gPiBXYXJyZW4sDQogICAgPj4g Pg0KICAgID4+ID4gSSBiZWxpZXZlIGl0J3Mgc3Vic3RhbnRpdmUgdGhhdCB0aGUgdGV4dCByZWZl cnMgdG8gc2VuZGluZyB1bmljYXN0DQogICAgPj4gPiBSQXMgd2l0aG91dCBjbGFyaWZ5aW5nIHdo ZXRoZXIgdGhpcyBtZWFucyB0aGF0IHRoZXkgYXJlIHNlbnQNCiAgICA+PiA+IHdpdGggYSB1bmlj YXN0IGxheWVyIDIgYWRkcmVzcyBhbmQgYSBtdWx0aWNhc3QgbGF5ZXIgMyBhZGRyZXNzDQogICAg Pj4gPiAoYXMgcGVyIFJGQzYwODUpIG9yIHRoYXQgdGhleSBhcmUgc2VudCB3aXRoIGJvdGggbGF5 ZXIgMiBhbmQNCiAgICA+PiA+IGxheWVyIDMgYWRkcmVzc2VzIGJlaW5nIHVuaWNhc3QuIEF0IHRo ZSBtb21lbnQsIGFuIGltcGxlbWVudGVyDQogICAgPj4gPiBoYXMgdG8gZGVjaWRlIHdoaWNoIG9m IHRoZXNlIGlzIGludGVuZGVkLiBJZiBlaXRoZXIgaXMgT0ssDQogICAgPj4gPiB0aGF0IGNvdWxk IGJlIHN0YXRlZCB0b28uDQogICAgPj4gPg0KICAgID4+ID4gU3BlY2lmaWNhbGx5IHRoaXMgY2xh cmlmaWNhdGlvbiBzZWVtcyB0byBiZSBuZWVkZWQgcmlnaHQgYWZ0ZXI6DQogICAgPj4gPg0KICAg ID4+ID4+IDQuICBJUHY2IFVuaXF1ZSBQcmVmaXggQXNzaWdubWVudA0KICAgID4+ID4+DQogICAg Pj4gPj4gICAgV2hlbiBhIFVFIGNvbm5lY3RzIHRvIHRoZSBzaGFyZWQgcHJvdmlkZXIgbWFuYWdl ZCBuZXR3b3JrIGFuZCBpcw0KICAgID4+ID4+ICAgIGF0dGFjaGVkLCBpdCB3aWxsIGluaXRpYXRl IElQIGNvbmZpZ3VyYXRpb24gcGhhc2UuICBEdXJpbmcgdGhpcw0KICAgID4+ID4+IHBoYXNlDQog ICAgPj4gPj4gICAgdGhlIFVFIHdpbGwsIGZyb20gYW4gSVB2NiBwZXJzcGVjdGl2ZSwgYXR0ZW1w dCB0byBsZWFybiB0aGUgZGVmYXVsdA0KICAgID4+ID4+ICAgIElQdjYgZ2F0ZXdheSwgdGhlIElQ djYgcHJlZml4IGluZm9ybWF0aW9uLCB0aGUgRE5TIGluZm9ybWF0aW9uDQogICAgPj4gPj4gICAg UkZDODEwNiBbUkZDODEwNl0sIGFuZCB0aGUgcmVtYWluaW5nIGluZm9ybWF0aW9uIHJlcXVpcmVk IHRvDQogICAgPj4gPj4gICAgZXN0YWJsaXNoIGdsb2JhbGx5IHJvdXRhYmxlIElQdjYgY29ubmVj dGl2aXR5LiAgRm9yIHRoYXQgcHVycG9zZSwNCiAgICA+PiA+PiB0aGUNCiAgICA+PiA+PiAgICB0 aGUgVUUvc3Vic2NyaWJlciBzZW5kcyBhIFJTIChSb3V0ZXIgU29saWNpdGF0aW9uKSBtZXNzYWdl Lg0KICAgID4+ID4+DQogICAgPj4gPj4gICAgVGhlIEZpcnN0IEhvcCBSb3V0ZXIgcmVjZWl2ZXMg dGhpcyBVRS9zdWJzY3JpYmVyIFJTIG1lc3NhZ2UgYW5kDQogICAgPj4gPj4gICAgc3RhcnRzIHRo ZSBwcm9jZXNzIHRvIGNvbXBvc2UgdGhlIHJlc3BvbnNlIHRvIHRoZSBVRS9zdWJzY3JpYmVyDQog ICAgPj4gPj4gICAgb3JpZ2luYXRlZCBSUyBtZXNzYWdlLiAgVGhlIEZpcnN0IEhvcCBQcm92aWRl ciBSb3V0ZXIgd2lsbCBhbnN3ZXINCiAgICA+PiA+PiAgICB1c2luZyBhIHVuaWNhc3QgUkEgKFJv dXRlciBBZHZlcnRpc2VtZW50KSB0byB0aGUgVUUvc3Vic2NyaWJlci4NCiAgICA+PiA+DQogICAg Pj4gPiBSZWdhcmRzDQogICAgPj4gPiAgICBCcmlhbiBDYXJwZW50ZXINCiAgICA+PiA+DQogICAg Pj4gPiBPbiAwNS8wOS8yMDE3IDA5OjQzLCBXYXJyZW4gS3VtYXJpIHdyb3RlOg0KICAgID4+ID4+ IEknZCBsaWtlIHRvIG5vdGUgdGhhdCB0aGF0IHRoZXJlIGlzIGNvbnRpbnVpbmcgZGlzY3Vzc2lv biBvbiB0aGlzDQogICAgPj4gPj4gZHJhZnQgb24gdGhlIHY2IG9wcyBsaXN0ICh5dXAsIGFmdGVy IFdHTEMgYW5kIElFVEYgTEMgOi0pKS4gSSd2ZSBvbmx5DQogICAgPj4gPj4gYmVlbiBhYmxlIHRv IHNvbWV3aGF0IG1vbml0b3IgaXQsIGJ1dCBoYXZlIGFza2VkIHRoZSB2Nm9wcyBjaGFpcnMgZm9y DQogICAgPj4gPj4gaW5wdXQuIE11Y2ggb2YgdGhlIGRpc2N1c3Npb24gaGFzIGJlZW4gaW50ZXJl c3RpbmcsIGJ1dCBub3QNCiAgICA+PiA+PiBuZWNlc3NhcmlseSBwZXJ0YWluaW5nIGV4YWN0bHkg dG8gdGhpcyBkb2N1bWVudC4NCiAgICA+PiA+PiBGcmVkIGtpbmRseSBhc2tlZCB0aGUgbGlzdDoN CiAgICA+PiA+PiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Y2b3BzL2Jw RUR0bllrYnZKUVpBeF9yNm10RWhkTnhydw0KICAgID4+ID4+IGZvciBhbnl0aGluZyBzdWJzdGFu dGl2ZSBmb3IgdGhlIGRvY3VtZW50IChrZWVwaW5nIGluIG1pbmQgdGhhdCBpdCBoYXMNCiAgICA+ PiA+PiBhbHJlYWR5IGdvbmUgdGhyb3VnaCBXR0xDIGFuZCBJRVRGIExDKS4NCiAgICA+PiA+Pg0K ICAgID4+ID4+IFNvIGZhciBpdCBkb2Vzbid0IHNlZW0gbGlrZSB0aGVyZSBhcmUgYW55IG90aGVy IG1ham9yIGNoYW5nZXMgbmVlZGVkLA0KICAgID4+ID4+IG90aGVyIHRoYW4gImFza2luZyB0aGF0 IHRoZSBhcHBsaWNhYmlsaXR5IGNvbW1lbnQgdGhhdCBjb21tdW5pY2F0aW9uDQogICAgPj4gPj4g YmV0d2VlbiBzdWNoIG5vZGVzIG9uIGEgTEFOIHNob3VsZCBnbyB0aHJvdWdoIGEgY29ubmVjdGlu ZyByb3V0ZXINCiAgICA+PiA+PiAod2hpY2ggc2VlbXMgdG8gbWUgYSBnaXZlbiBkdWUgdG8gdGhl IHJlbGF0aW9uc2hpcCB3aXRoIHJvdXRpbmcpDQogICAgPj4gPj4gc2hvdWxkIGJlIGRvY3VtZW50 ZWQuIiBhbmQgRGF2aWQgRmFybWVyJ3MgZm9sbG93dXAgLS0NCiAgICA+PiA+PiBodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Y2b3BzL18tUWxCcUdrOWRDaG9GT2h4aWdmNVds eFlEWQ0KICAgID4+ID4+DQogICAgPj4gPj4gRG9lcyBhbnlvbmUgaGF2ZSBhbnl0aGluZyBlbHNl ICpzdWJzdGFudGl2ZSo/IElmIHNvLCBJIG1heSBoYXZlIHRvDQogICAgPj4gPj4ga2ljayB0aGlz IGJhY2sgdG8gdGhlIFdHIGZvciBhbm90aGVyIHJvdW5kLg0KICAgID4+ID4+DQogICAgPj4gPj4g Vw0KICAgID4+ID4+DQogICAgPj4gPj4NCiAgICA+PiA+Pg0KICAgID4+ID4+DQogICAgPj4gPj4g T24gVHVlLCBBdWcgMjIsIDIwMTcgYXQgNzozMSBQTSwgU3VyZXNoIEtyaXNobmFuDQogICAgPj4g Pj4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+IHdyb3RlOg0KICAgID4+ID4+PiBIaSBHdW50 ZXIsDQogICAgPj4gPj4+ICAgVGhhbmtzIGZvciB0aGUgcHJvcG9zZWQgdGV4dCBjaGFuZ2VzLiBU aGV5IGFkZXF1YXRlbHkgYWRkcmVzcyBteQ0KICAgID4+ID4+PiBESVNDVVNTDQogICAgPj4gPj4+ IHBvaW50cy4gSSBhbSBob3BpbmcgeW91IHdpbGwgYWxzbyBjb252ZXJnZSBpbiB0aGUgZGlzY3Vz c2lvbiB3aXRoDQogICAgPj4gPj4+IExvcmVuem8gb24NCiAgICA+PiA+Pj4gdGhlIGFjdHVhbCB2 YWx1ZSBmb3IgdGhlIHRpbWVyIGFuZC9vciBzcGVjaWZ5IGFuIGFwcGxpY2FiaWxpdHkNCiAgICA+ PiA+Pj4gc3RhdGVtZW50LiBJDQogICAgPj4gPj4+IHdpbGwgY2xlYXIgb25jZSB0aGUgbmV3IHJl dmlzaW9uIHBvc3RzLg0KICAgID4+ID4+Pg0KICAgID4+ID4+PiBSZWdhcmRzDQogICAgPj4gPj4+ IFN1cmVzaA0KICAgID4+ID4+Pg0KICAgID4+ID4+PiBPbiBBdWcgMjEsIDIwMTcsIGF0IDg6NTcg QU0sIFZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtIEJFL0FudHdlcnApDQogICAgPj4gPj4+ IDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4gd3JvdGU6DQogICAgPj4gPj4+DQogICAg Pj4gPj4+IEhpIFN1cmVzaCwNCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gTWFueSB0aGFua3MgZm9y IHRoZSByZXZpZXcgYW5kIGZpbmRpbmcgdGhlc2UgaXNzdWVzLiBXaGF0IGRvIHlvdSB0aGluaw0K ICAgID4+ID4+PiBvZg0KICAgID4+ID4+PiB0aGUgcHJvcG9zYWxzIGJlbG93IHRvIGZpeCB0aG9z ZSBwb2ludHMgb2YgYXR0ZW50aW9uPw0KICAgID4+ID4+Pg0KICAgID4+ID4+Pg0KICAgID4+ID4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogICAgPj4gPj4+ICAgIERJU0NVU1M6DQogICAgPj4gPj4+DQogICAg Pj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gICAgKiBTZWN0aW9u IDQNCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gICAgSXQgaXMgbm90IGNsZWFyIHdoYXQgeW91IGlu dGVuZCBoZXJlDQogICAgPj4gPj4+DQogICAgPj4gPj4+ICAgICJJUHY2IFJvdXRlciBBZHZlcnRp c2VtZW50IEludGVydmFsID0gMzAwcyINCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gICAgVGhlIHJv dXRlciBhZHZlcnRpc2VtZW50IGludGVydmFsIGlzIG5vdCBjb25maWd1cmVkIGFzIGFuIGFic29s dXRlDQogICAgPj4gPj4+IHZhbHVlDQogICAgPj4gPj4+IGJ1dCBhcw0KICAgID4+ID4+PiAgICBt aW5pbXVtIGFuZCBtYXhpbXVtIGJvdW5kcyAoTWluUnRyQWR2SW50ZXJ2YWwgYW5kDQogICAgPj4g Pj4+IE1heFJ0ckFkdkludGVydmFsKQ0KICAgID4+ID4+PiB3aGljaCBhcmUNCiAgICA+PiA+Pj4g ICAgdXNlZCB0byBjYWxjdWxhdGUgdGhlIGFjdHVhbCBhZHZlcnRpc2VtZW50IGludGVydmFsLiBX aGVuIHRoZSBSQSBpcw0KICAgID4+ID4+PiBzZW50DQogICAgPj4gPj4+IGZyb20NCiAgICA+PiA+ Pj4gICAgYW4gaW50ZXJmYWNlLCB0aGUgYWN0dWFsIGludGVydmFsIGlzIGFuIHVuaWZvcm1seSBk aXN0cmlidXRlZA0KICAgID4+ID4+PiByYW5kb20NCiAgICA+PiA+Pj4gdmFsdWUNCiAgICA+PiA+ Pj4gICAgYmV0d2VlbiB0aGUgTWluUnRyQWR2SW50ZXJ2YWwgYW5kIE1heFJ0ckFkdkludGVydmFs LiBBdCB0aGUgdmVyeQ0KICAgID4+ID4+PiBtaW5pbXVtDQogICAgPj4gPj4+IHlvdQ0KICAgID4+ ID4+PiAgICBuZWVkIHRvIGNsYXJpZnkgaWYgeW91IHdvdWxkIGxpa2UgdG8gaGF2ZSB0aGlzIGFz IGEgbG93ZXIgYm91bmQgb3INCiAgICA+PiA+Pj4gYXMgYW4NCiAgICA+PiA+Pj4gdXBwZXINCiAg ICA+PiA+Pj4gICAgYm91bmQuDQogICAgPj4gPj4+DQogICAgPj4gPj4+IEdWPiBJIGNoYW5nZWQg dGhlIGxpbmUgdG8gbWFrZSBpdCBtb3JlIGNsZWFyIHRoYXQgdGhlIHRpbWVyIGluZGljYXRlcw0K ICAgID4+ID4+PiB0aGUNCiAgICA+PiA+Pj4gbWF4aW11bSBBZHZlcnRpc2VtZW50IEludGVydmFs DQogICAgPj4gPj4+IEdWPiAgICAgICAgICA8dD5NYXhpbXVtIElQdjYgUm91dGVyIEFkdmVydGlz ZW1lbnQgSW50ZXJ2YWwgPSAzMDBzPC90Pg0KICAgID4+ID4+Pg0KICAgID4+ID4+Pg0KICAgID4+ ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPj4gPj4+ICAgIENPTU1FTlQ6DQogICAgPj4gPj4+DQog ICAgPj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gICAgKiBTZWN0 aW9uIDQNCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gICAgLT4gSSB0aGluayB0ZXh0IGlzIG5lZWRl ZCBoZXJlIHRvIGhhbmRsZSB0aGUgY2FzZSB3aGVyZSB0aGUgRE5TDQogICAgPj4gPj4+IHNlcnZl ciBpcw0KICAgID4+ID4+PiAgICBwcm92aWRlZCBpbiB0aGUgUkEgaXRzZWxmICAoUkZDODEwNikN CiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gICAgIkluIGFkZGl0aW9uIGl0IHdpbGwgdXNlIHN0YXRl bGVzcyBESENQdjYgdG8gZ2V0IHRoZSBJUHY2IGFkZHJlc3MNCiAgICA+PiA+Pj4gb2YgdGhlDQog ICAgPj4gPj4+IEROUw0KICAgID4+ID4+PiAgICBzZXJ2ZXIiDQogICAgPj4gPj4+DQogICAgPj4g Pj4+ICAgIC0+IEkgYW0gbm90IHN1cmUgd2hhdCBpcyB0aGUgbW90aXZhdGlvbiBmb3IgdGhpcyB0 ZXh0Lg0KICAgID4+ID4+Pg0KICAgID4+ID4+PiAgICAiaG93ZXZlciBpdCBTSE9VTEQgTk9UIHVz ZSBzdGF0ZWZ1bCBESENQdjYgdG8gcmVjZWl2ZSBhIHNlcnZpY2UNCiAgICA+PiA+Pj4gcHJvdmlk ZXINCiAgICA+PiA+Pj4gICAgbWFuYWdlZCBJUHY2IGFkZHJlc3MiDQogICAgPj4gPj4+DQogICAg Pj4gPj4+ICAgIC0+IFRoaXMgdGV4dCBzZWVtcyBpbmNvcnJlY3QNCiAgICA+PiA+Pj4NCiAgICA+ PiA+Pj4gICAgImR1ZSB0byB0aGUgTC1iaXQgc2V0LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZm aWMgdG8gdGhlIEZpcnN0IEhvcA0KICAgID4+ID4+PiBQcm92aWRlcg0KICAgID4+ID4+PiAgICBS b3V0ZXIiDQogICAgPj4gPj4+DQogICAgPj4gPj4+ICAgIEkgdGhpbmsgaXQgc2hvdWxkIGJlIHRo ZSBleGFjdCBvcHBvc2l0ZS4gaS5lLiBzYXkgKnVuc2V0KiBpbnN0ZWFkDQogICAgPj4gPj4+IG9m IHNldA0KICAgID4+ID4+Pg0KICAgID4+ID4+PiAgICAiZHVlIHRvIHRoZSBMLWJpdCBiZWluZyB1 bnNldCwgaXQgU0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljIHRvIHRoZQ0KICAgID4+ID4+PiBGaXJz dA0KICAgID4+ID4+PiBIb3ANCiAgICA+PiA+Pj4gICAgUHJvdmlkZXIgUm91dGVyIg0KICAgID4+ ID4+Pg0KICAgID4+ID4+PiBHVj4gV2hhdCBhYm91dCB0aGUgZm9sbG93aW5nIG1vZGlmaWNhdGlv biBpbiB0aGUgdGV4dDoNCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gT0xEOg0KICAgID4+ID4+PiBU aGUgYXJjaGl0ZWN0ZWQgcmVzdWx0IG9mIGRlc2lnbmluZyB0aGUgUkEgYXMgZG9jdW1lbnRlZCBh Ym92ZSBpcw0KICAgID4+ID4+PiAgIHRoYXQgZWFjaCBVRS9zdWJzY3JpYmVyIGdldHMgaXRzIG93 biB1bmlxdWUgSVB2NiBwcmVmaXggZm9yIHdoaWNoIGl0DQogICAgPj4gPj4+ICAgY2FuIHVzZSBT TEFBQyBvciBhbnkgb3RoZXIgbWV0aG9kIHRvIHNlbGVjdCBpdHMgLzEyOCB1bmlxdWUgYWRkcmVz cy4NCiAgICA+PiA+Pj4gICBJbiBhZGRpdGlvbiBpdCB3aWxsIHVzZSBzdGF0ZWxlc3MgREhDUHY2 IHRvIGdldCB0aGUgSVB2NiBhZGRyZXNzIG9mDQogICAgPj4gPj4+ICAgdGhlIEROUyBzZXJ2ZXIs IGhvd2V2ZXIgaXQgU0hPVUxEIE5PVCB1c2Ugc3RhdGVmdWwgREhDUHY2IHRvIHJlY2VpdmUNCiAg ICA+PiA+Pj4gICBhIHNlcnZpY2UgcHJvdmlkZXIgbWFuYWdlZCBJUHY2IGFkZHJlc3MuICBJZiB0 aGUgVUUvc3Vic2NyaWJlcg0KICAgID4+ID4+PiAgIGRlc2lyZXMgdG8gc2VuZCBhbnl0aGluZyBl eHRlcm5hbCBpbmNsdWRpbmcgb3RoZXIgVUUvc3Vic2NyaWJlcg0KICAgID4+ID4+PiAgIGRldmlj ZXMgKGFzc3VtaW5nIGRldmljZSB0byBkZXZpY2UgY29tbXVuaWNhdGlvbnMgaXMgZW5hYmxlZCBh bmQNCiAgICA+PiA+Pj4gICBzdXBwb3J0ZWQpLCB0aGVuLCBkdWUgdG8gdGhlIEwtYml0IHNldCwg aXQgU0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljDQogICAgPj4gPj4+ICAgdG8gdGhlIEZpcnN0IEhv cCBQcm92aWRlciBSb3V0ZXIuDQogICAgPj4gPj4+DQogICAgPj4gPj4+IE5ldzoNCiAgICA+PiA+ Pj4gVGhlIGFyY2hpdGVjdGVkIHJlc3VsdCBvZiBkZXNpZ25pbmcgdGhlIFJBIGFzIGRvY3VtZW50 ZWQgYWJvdmUgaXMNCiAgICA+PiA+Pj4gdGhhdCBlYWNoIFVFL3N1YnNjcmliZXIgZ2V0cyBpdHMg b3duIHVuaXF1ZSBJUHY2IHByZWZpeCBmb3Igd2hpY2ggaXQNCiAgICA+PiA+Pj4gY2FuIHVzZSBT TEFBQyBvciBhbnkgb3RoZXIgbWV0aG9kIHRvIHNlbGVjdCBpdHMgLzEyOCB1bmlxdWUgYWRkcmVz cy4NCiAgICA+PiA+Pj4gRWl0aGVyIHN0YXRlbGVzcyBESENQdjYgPHhyZWYgdGFyZ2V0PSJSRkMz NzM2Ij5SRkMzNzM2PC94cmVmPiBvciBJUHY2DQogICAgPj4gPj4+IFJvdXRlciBBZHZlcnRpc2Vt ZW50IE9wdGlvbnMgZm9yIEROUyBDb25maWd1cmF0aW9uDQogICAgPj4gPj4+IDx4cmVmIHRhcmdl dD0iUkZDODEwNiI+UkZDODEwNjwveHJlZj4gY2FuIGJlIHVzZWQgdG8gZ2V0IHRoZQ0KICAgID4+ ID4+PiBJUHY2IGFkZHJlc3Mgb2YgdGhlIEROUyBzZXJ2ZXIuIElmIHRoZSBVRS9zdWJzY3JpYmVy IGRlc2lyZXMgdG8gc2VuZA0KICAgID4+ID4+PiBhbnl0aGluZyBleHRlcm5hbCBpbmNsdWRpbmcg b3RoZXIgVUUvc3Vic2NyaWJlciBkZXZpY2VzIChhc3N1bWluZw0KICAgID4+ID4+PiBkZXZpY2UN CiAgICA+PiA+Pj4gdG8gZGV2aWNlIGNvbW11bmljYXRpb25zIGlzIGVuYWJsZWQgYW5kIHN1cHBv cnRlZCksIHRoZW4sIGR1ZSB0byB0aGUNCiAgICA+PiA+Pj4gTC1iaXQgYmVpbmcgdW5zZXQsIGl0 IFNIT1VMRCBzZW5kIHRoaXMgdHJhZmZpYyB0byB0aGUgRmlyc3QgSG9wDQogICAgPj4gPj4+IFBy b3ZpZGVyDQogICAgPj4gPj4+IFJvdXRlci48L3Q+DQogICAgPj4gPj4+DQogICAgPj4gPj4+DQog ICAgPj4gPj4+DQogICAgPj4gPj4+IEtpbmQgUmVnYXJkcywNCiAgICA+PiA+Pj4gRy8NCiAgICA+ PiA+Pj4NCiAgICA+PiA+Pj4NCiAgICA+PiA+Pg0KICAgID4+ID4+DQogICAgPj4gPj4NCiAgICA+ Pg0KICAgID4+DQogICAgPj4NCiAgICA+PiAtLQ0KICAgID4+IEkgZG9uJ3QgdGhpbmsgdGhlIGV4 ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkgYSBiYWQNCiAgICA+PiBp ZGVhIGluIHRoZSBmaXJzdCBwbGFjZS4NCiAgICA+PiBUaGlzIGlzIGxpa2UgcHV0dGluZyByYWJp ZCB3ZWFzZWxzIGluIHlvdXIgcGFudHMsIGFuZCBsYXRlciBleHByZXNzaW5nDQogICAgPj4gcmVn cmV0IGF0IGhhdmluZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxzIGFuZCB0 aGF0IHBhaXINCiAgICA+PiBvZiBwYW50cy4NCiAgICA+PiAgICAtLS1tYWYNCiAgICA+Pg0KICAg ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQogICAgPj4gdjZvcHNAaWV0Zi5vcmcNCiAgICA+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQogICAgPg0KICAgID4NCiAg ICANCiAgICANCiAgICANCiAgICAtLSANCiAgICBJIGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24g aXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91c2x5IGEgYmFkDQogICAgaWRlYSBpbiB0aGUg Zmlyc3QgcGxhY2UuDQogICAgVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vhc2VscyBpbiB5 b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZw0KICAgIHJlZ3JldCBhdCBoYXZpbmcgY2hv c2VuIHRob3NlIHBhcnRpY3VsYXIgcmFiaWQgd2Vhc2VscyBhbmQgdGhhdCBwYWlyDQogICAgb2Yg cGFudHMuDQogICAgICAgLS0tbWFmDQogICAgDQogICAgDQoNCg== From nobody Mon Sep 11 15:43:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68402132F76; Mon, 11 Sep 2017 15:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JceFgUM1hVp4; Mon, 11 Sep 2017 15:43:35 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BA313213D; Mon, 11 Sep 2017 15:43:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8BMhXqO065354; Mon, 11 Sep 2017 15:43:33 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8BMhOx4064928 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 11 Sep 2017 15:43:24 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 11 Sep 2017 15:43:23 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 11 Sep 2017 15:43:23 -0700 From: "Templin, Fred L" To: Warren Kumari CC: Lorenzo Colitti , Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTKaTY2SQFbjmM502TqtM/gaCiM6KtwdeAgAFRDQCAAPq0kIAAp1cA//+S9hA= Date: Mon, 11 Sep 2017 22:43:23 +0000 Message-ID: <31e926886e01457fb84efd165dd000c5@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <5ec52c86f18e453b8191679afb7ec1b4@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 22:43:38 -0000 SGkgV2FycmVuLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdhcnJl biBLdW1hcmkgW21haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldF0NCj4gU2VudDogTW9uZGF5LCBTZXB0 ZW1iZXIgMTEsIDIwMTcgMzowMSBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPg0KPiBDYzogTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5j b20+OyBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaC5rcmlzaG5hbkBnbWFpbC5jb20+OyB2Nm9wc0Bp ZXRmLm9yZzsgZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtDQo+IGlwdjYtcHJlZml4LXBlci1ob3N0 QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFN1cmVzaCBLcmlzaG5hbidzIERpc2N1 c3Mgb24gZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDc6ICh3 aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBPbiBNb24sIFNlcCAxMSwgMjAxNyBhdCAz OjM5IFBNLCBUZW1wbGluLCBGcmVkIEwNCj4gPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdy b3RlOg0KPiA+IEhpIFdhcnJlbiwNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+PiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBXYXJyZW4gS3VtYXJpDQo+ID4+IFNlbnQ6IFN1bmRheSwgU2VwdGVtYmVyIDEwLCAy MDE3IDI6MDUgUE0NCj4gPj4gVG86IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29t Pg0KPiA+PiBDYzogU3VyZXNoIEtyaXNobmFuIDxzdXJlc2gua3Jpc2huYW5AZ21haWwuY29tPjsg djZvcHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1o b3N0QGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFN1cmVzaCBLcmlzaG5hbidz IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3Qt MDc6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+ID4+DQo+ID4+IFsgLSBJRVNHLCAtR3Vu dGVyIChoZSBnZXRzIGEgY29weSBhcyBwYXJ0IG9mDQo+ID4+IGRyYWZ0LWlldGYtdjZvcHMtdW5p cXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QCksIC12NmNoYWlyc0AgXQ0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiA+PiBPbiBTYXQsIFNlcCA5LCAyMDE3IGF0IDg6NTggUE0sIExvcmVuem8gQ29saXR0aSA8 bG9yZW56b0Bnb29nbGUuY29tPiB3cm90ZToNCj4gPj4gPiBXYXJyZW4sDQo+ID4+ID4NCj4gPj4g PiBjYXJlIHRvIHN1bW1hcml6ZSB0aGUgbWFpbiBpc3N1ZXMgdGhhdCBjYXVzZWQgeW91IHRvIGRv IHRoaXM/IFdlJ2xsIHdhbnQgdG8NCj4gPj4gPiBtYWtlIHN1cmUgd2UgZG9uJ3Qgc3BlbmQgdG9v IG11Y2ggdGltZSBkaXNjdXNzaW5nIGlzc3VlcyB0aGF0IGRpZCBub3QNCj4gPj4gPiBtYXRlcmlh bGx5IGltcGFjdCB0aGlzIGRlY2lzaW9uLg0KPiA+PiA+DQo+ID4+DQo+ID4+IFN1cmUuDQo+ID4+ DQo+ID4+IER1cmluZyBJRVNHIHJldmlldywgc29tZSBvZiB0aGUgSUVTRyByYWlzZWQgcXVlc3Rp b25zIGFuZCBzdWdnZXN0ZWQNCj4gPj4gdGV4dCB0byBpbXByb3ZlIHRoZSBkb2N1bWVudC4gV2Ug cmVjZWl2ZWQgcmVzcG9uc2VzIGZyb20gdGhlIGF1dGhvcnMNCj4gPj4gc2F5aW5nIHRoYXQgdGhl IHF1ZXN0aW9ucywgYWxvbmcgd2l0aCBTdXJlc2gncyBESVNDVVNTLCB3b3VsZCBiZQ0KPiA+PiBh ZGRyZXNzZWQuIFdlIGRpZCBub3Qgc2VlIGFuIHVwZGF0ZWQgZHJhZnQsIGFuZCBpdCdzIGRpZmZp Y3VsdCB0byBrZWVwDQo+ID4+IHRoZSBwYXRjaGVkIHZlcnNpb24gaW4gb25lJ3MgaGVhZC4gU28s IEkgZG9uJ3Qga25vdyBleGFjdGx5IHdoYXQgaXQNCj4gPj4gbG9va3MgbGlrZSBub3csIGJ1dCBo ZXJlIGFyZSBzb21lIG9mIHRoZSBjb25zaWRlcmF0aW9ucyB0aGF0DQo+ID4+IGluZmx1ZW5jZWQg bXkgZGVjaXNpb246DQo+ID4+DQo+ID4+IDE6IEJyaWFuIENhcnBlbnRlcidzOg0KPiA+PiAiSSBi ZWxpZXZlIGl0J3Mgc3Vic3RhbnRpdmUgdGhhdCB0aGUgdGV4dCByZWZlcnMgdG8gc2VuZGluZyB1 bmljYXN0DQo+ID4+IFJBcyB3aXRob3V0IGNsYXJpZnlpbmcgd2hldGhlciB0aGlzIG1lYW5zIHRo YXQgdGhleSBhcmUgc2VudA0KPiA+PiB3aXRoIGEgdW5pY2FzdCBsYXllciAyIGFkZHJlc3MgYW5k IGEgbXVsdGljYXN0IGxheWVyIDMgYWRkcmVzcw0KPiA+PiAoYXMgcGVyIFJGQzYwODUpIG9yIHRo YXQgdGhleSBhcmUgc2VudCB3aXRoIGJvdGggbGF5ZXIgMiBhbmQNCj4gPj4gbGF5ZXIgMyBhZGRy ZXNzZXMgYmVpbmcgdW5pY2FzdC4gQXQgdGhlIG1vbWVudCwgYW4gaW1wbGVtZW50ZXINCj4gPj4g aGFzIHRvIGRlY2lkZSB3aGljaCBvZiB0aGVzZSBpcyBpbnRlbmRlZC4gSWYgZWl0aGVyIGlzIE9L LA0KPiA+PiB0aGF0IGNvdWxkIGJlIHN0YXRlZCB0b28uIi4NCj4gPj4NCj4gPj4gMjogRnJlZCBU ZW1wbGluJ3MgInVubGVzcyB0aGUgc2hhcmVkIG5ldHdvcmsgZXhwbGljaXRseSBwZXJtaXRzDQo+ ID4+IHBlZXItdG8tcGVlciBvcGVyYXRpb25zIiAtLSBpbiBteSB2aWV3IGFkZGluZyB0aGlzIGV4 YWN0IHRleHQgZGlkbid0DQo+ID4+IHNlZW0gdG8gaGF2ZSBzdXBwb3J0LCBidXQgY2xhcmlmeWlu ZyB3aGF0IGlzIG1lYW50IGJ5IGEgInNoYXJlZA0KPiA+PiBuZXR3b3JrIiB3b3VsZCBiZSB1c2Vm dWwuDQo+ID4NCj4gPiBJIGFncmVlLiAiU2hhcmVkIG5ldHdvcmsiIGlzIG5vdCAgYW4gUkZDNDg2 MSBzdXBwb3J0ZWQgbGluayB0eXBlLiBUaGUNCj4gPiBzdXBwb3J0ZWQgbGluayB0eXBlcyBhcmUg Z2l2ZW4gaW4gUkZDNDg2MSBTZWN0aW9ucyAyLjIgYW5kIDMuMiwgYW5kIHRoaXMNCj4gPiBkb2N1 bWVudCBuZWVkcyB0byBvYnNlcnZlIHRoZSBSRkM0ODYxIHRlcm1pbm9sb2d5Lg0KPiANCj4gSSBk byBub3QgYWdyZWUgd2l0aCB5b3UgdGhhdCBpdCBuZWVkcyB0byB1c2UgUkZDNDg2MSB0ZXJtaW5v bG9neQ0KDQpUaGF0IHN1cnByaXNlcyBtZS4gVGhpcyBkb2N1bWVudCBpcyBhYm91dCBhbiBpbnRl cnByZXRhdGlvbiBvZiBSRkM0ODYxLA0KYW5kIHRoZSBSRkM0ODYxIHRlcm1pbm9sb2d5IHNob3Vs ZCBhcHBseS4NCg0KPiAobm9yLA0KPiBJIHRoaW5rLCBkb2VzIHRoZSBXRykgLS0gSSBkbyBob3dl dmVyIHRoaW5rIHRoYXQgaXQgd291bGQgYmUgdXNlZnVsDQo+IGZvciB0aGUgZG9jdW1lbnQgdG8g Y2xhcmlmeSB3aGF0IGl0ICpkb2VzKiBtZWFuIHdoZW4gaXQgc2F5cyAic2hhcmVkDQo+IG5ldHdv cmsiIC0tIGl0IHVzZXMgdGhlIHRlcm0gMTEgdGltZXMsIGFuZCBzb21lIGRlc2NyaXB0aW9uIG9m IHdoYXQgaXQNCj4gaXMgbWVhbmluZyB3b3VsZCBiZSAoSU1PKSB1c2VmdWwuIEVLUidzIGJhbGxv dCBhbHNvIGV4cHJlc3NlZA0KPiBjb25mdXNpb24gb24gdGhpczoNCj4gDQo+IC0tLS0tLS0tDQo+ IEVyaWMgUmVzY29ybGEgTm8gT2JqZWN0aW9uIENvbW1lbnQgKDIwMTctMDgtMTUpDQo+IA0KPiAg SSBmb3VuZCB0aGUgZGlzY3Vzc2lvbiBvZiB0aGUgc2hhcmVkIG5ldHdvcmsgbWVkaXVtIGEgYml0 DQo+ICBjb25mdXNpbmcuIEFzIEkgdW5kZXJzdGFuZCBpdCwgdGhlIGlkZWEgaXMgdGhhdCBpZiB3 ZSBhcmUNCj4gIG9uIGEgc2hhcmVkIG5ldHdvcmsgYW5kIHdlIGhhdmUgdGhlIHNhbWUgcHJlZml4 LCBJIG1pZ2h0DQo+ICB0cnkgdG8gc2VuZCB0byB5b3UgZGlyZWN0bHkuIFdoYXQgeW91IHdhbnQg dG8gZG8gaXMgbWFrZQ0KPiAgdGhhdCBub3QgaGFwcGVuIGJ5IGhhdmluZyBlYWNoIG5vZGUgaGF2 ZSBhIHNlcGFyYXRlIHByZWZpeC4NCj4gIENvcnJlY3Q/IElmIHNvLCBwZXJoYXBzIHByb21vdGUg dGhpcyBidWxsZXQsIGFuZCBhbHNvIGhhdmUNCj4gIGl0IGRlc2NyaWJlIHRoZSBwcm9ibGVtIGFu ZCB3aHkgdGhpcyBwcm92aWRlcyBhIHNvbHV0aW9uOg0KPiANCj4gICAgIG8gIFR3byBkZXZpY2Vz IChzdWJzY3JpYmVyL2hvc3RzKSwgYm90aCBhdHRhY2hlZCB0byB0aGUgc2FtZSBwcm92aWRlcg0K PiAgICAgICBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrIHNob3VsZCBvbmx5IGJlIGFibGUgdG8gY29t bXVuaWNhdGUgdGhyb3VnaA0KPiAgICAgICAgdGhlIHByb3ZpZGVyIG1hbmFnZWQgRmlyc3QgSG9w IFJvdXRlcg0KPiAtLS0tLQ0KPiANCj4gSSdtIGFsc28gZmluZSBpZiB0aGUgV0cgZGlzYWdyZWVz IGFuZCBmZWVscyB0aGF0IGV2ZXJ5b25lIHJlYWRpbmcgdGhpcw0KPiB3aWxsIHVuZGVyc3RhbmQg d2hhdCBhICJzaGFyZWQgbmV0d29yayIgaXMgKGFuZCB3aGVyZSBhbGwgdGhpbmdzIGxpa2UNCj4g YW4gUkEvUlMgd2lsbCByZWFjaCBvbiBvbmUpLg0KPiANCj4gDQo+ID4gRm9yIGV4YW1wbGUsIGlu DQo+ID4gdGhlIGFic3RyYWN0IGFuZC9vciBpbnRyb2R1Y3Rpb24gaXQgY291bGQgc2F5IHNvbWV0 aGluZyBsaWtlICJzaGFyZWQNCj4gPiBuZXR3b3JrIHR5cGVzIHN1Y2ggYXMgbXVsdGljYXN0LWNh cGFibGUsIG5vbi1icm9hZGNhc3QgbXVsdGktYWNjZXNzDQo+ID4gKE5CTUEpLCBzaGFyZWQgbWVk aWEsIGV0Yy4gW1JGQzQ4NjFdIiBhbmQgdGhlbiB0aGUgdGVybSAic2hhcmVkDQo+ID4gbmV0d29y ayIgIGNvdWxkIGJlIHVzZWQgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQuDQo+ID4NCj4gPiBIYXZp bmcgc2FpZCB0aGF0LCBob3dldmVyLCBhbGwgb2YgdGhvc2UgUkZDNDg2MSBzdXBwb3J0ZWQgbGlu ayB0eXBlcw0KPiA+IHN1cHBvcnQgcGVlci10by1wZWVyIGNvbW11bmljYXRpb25zIHdpdGhvdXQg aGF2aW5nIHRvIHNlbmQgYWxsIHRyYWZmaWMNCj4gPiB0aHJvdWdoIGEgcm91dGVyLiBJbiBvcmRl ciB0byBwcmV2ZW50IHRoYXQsIHRoaXMgZG9jdW1lbnQgd291bGQgaGF2ZSB0bw0KPiA+IHJlcXVp cmUgdGhhdCBMMiBwYXJ0aXRpb25pbmcgbXVzdCBiZSB1c2VkLg0KPiANCj4gRGVwZW5kcyB3aGF0 IHlvdSBtZWFuIGJ5ICJwcmV2ZW50IiwgYW5kIHdoYXQgeW91IHRoaW5rIHRoYXQgZG9jdW1lbnQN Cj4gaXMgdHJ5aW5nIHRvIGFjY29tcGxpc2ggLSB0aGUgYWJzdHJhY3Qgc2F5czoNCj4gIldoaWxl DQo+ICAgIHRoaXMgaXMgc3RpbGwgdmlhYmxlIGFuZCBvcGVyYXRlcyBhcyBkZXNpZ25lZCwgdGhl cmUgYXJlIHNvbWUgbGFyZ2UNCj4gICAgc2NhbGUgZW52aXJvbm1lbnRzIHdoZXJlIHRoaXMgY29u Y2VwdCBpbnRyb2R1Y2VzIHNpZ25pZmljYW50DQo+ICAgIHBlcmZvcm1hbmNlIGNoYWxsZW5nZXMg YW5kIGltcGxpY2F0aW9ucywgc3BlY2lmaWNhbGx5IHJlbGF0ZWQgdG8gSVB2Ng0KPiAgICByb3V0 ZXIgYW5kIG5laWdoYm9yIGRpc2NvdmVyeS4NCj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgb3V0bGlu ZXMgYW4gYXBwcm9hY2ggdXRpbGlzaW5nIGV4aXN0aW5nIElQdjYgcHJvdG9jb2xzDQo+ICAgIHRv IGFsbG93IGhvc3RzIHRvIGJlIGFzc2lnbmVkIGEgdW5pcXVlIElQdjYgcHJlZml4IChpbnN0ZWFk IG9mIGENCj4gICAgdW5pcXVlIElQdjYgYWRkcmVzcyBmcm9tIGEgc2hhcmVkIElQdjYgcHJlZml4 KS4gIEJlbmVmaXRzIG9mIHVuaXF1ZQ0KPiAgICBJUHY2IHByZWZpeCBvdmVyIGEgdW5pcXVlIElQ djYgYWRkcmVzcyBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyDQo+ICAgIGluY2x1ZGUgaW1wcm92 ZWQgc3Vic2NyaWJlciBpc29sYXRpb24gYW5kIGVuaGFuY2VkIHN1YnNjcmliZXINCj4gICAgbWFu YWdlbWVudC4iDQo+IA0KPiANCj4gSXQgZG9lc24ndCBzYXkgIm1ha2UgaXQgY29tcGxldGVseSBp bXBvc3NpYmxlIGZvciBzdWJzY3JpYmVycyB0bw0KPiBjb21tdW5pY2F0ZSIgb3IgImVuZm9yY2Ug aXNvbGF0aW9uIGZvciBzZWN1cml0eSIsIG9yICJwcmV2ZW50DQo+IHBlZXItdG8tcGVlciIuDQoN CkFyZSB5b3UgcHJlcGFyZWQgdG8gc2F5IHRoYXQsIGlmIHR3byBzdWJzY3JpYmVycyBmaW5kIG91 dCB0aHJvdWdoIHNvbWUNCm1lYW5zIHRoYXQgdGhleSBjb3VsZCBjb21tdW5pY2F0ZSBkaXJlY3Rs eSB3aXRob3V0IGdvaW5nIHRocm91Z2ggdGhlDQpyb3V0ZXIsIHRoYXQgdGhpcyBkb2N1bWVudCBk b2VzIG5vdCBwcmV2ZW50IHRoZW0gZnJvbSBkb2luZyBzbz8gSWYNCnllcywgdGhlbiBsZXQncyBo YXZlIHRoYXQgb24gdGhlIGxpc3QuDQoNClRoYW5rcyAtIEZyZWQNCiANCj4gVw0KPiANCj4gPiBP dGhlcndpc2UsIHRoaXMgZG9jdW1lbnQgaXMNCj4gPiBlc3NlbnRpYWxseSBkZXByZWNhdGluZyBw ZWVyLXRvLXBlZXIgKGluY2x1ZGluZyB0aGUgUmVkaXJlY3QgZnVuY3Rpb24pDQo+ID4gZXZlbiBm b3IgbGluayB0eXBlcyB3aGVyZSBpdCBtYXkgcHJvdmlkZSB1c2VmdWwgYmVuZWZpdHMuDQo+ID4N Cj4gPiBUaGFua3MgLSBGcmVkDQo+ID4gZnJlZC5sLnRlbXBsaW5AYm9laW5nLmNvbQ0KPiA+DQo+ ID4+IFRoaXMgd2FzIGFsc28gbWVudGlvbmVkIGluIEVLUidzIGJhbGxvdCAtLSBiYWxsb3QgdGV4 dCBpcyBhbGwgYmVsb3cgKEkNCj4gPj4gZG9uJ3Qgd2FudCBpdCB0byBnZXQgbG9zdCB3aGVuIGJl aW5nIExDZWQpLg0KPiA+Pg0KPiA+PiAzOiBJIGRvIG5vdCBiZWxpZXZlIHRoYXQgSSBldmVyIHNh dyBhIHJlc29sdXRpb24gdG8gTG9yZW56bydzICJJJ2xsDQo+ID4+IGFsc28gcG9pbnQgb3V0IHll dCBhZ2FpbiB0aGF0IHRoaXMgdmFsdWUgaXMgaW4gY29uZmxpY3Qgd2l0aCBSRkMgNzc3Mg0KPiA+ PiBpbiB0aGUgY2FzZSBvZiBuZXR3b3JrcyB0aGF0IGFyZSBwcm92aWRlIHNlcnZpY2UgZm9yIGJh dHRlcnktcG93ZXJlZA0KPiA+PiBkZXZpY2VzLiBUaGUgdGV4dCBzaG91bGQgZWl0aGVyIGJlIGNo YW5nZWQgdG8gZm9sbG93IHRoYXQgUkZDIG9yIHRvDQo+ID4+IGV4cGxhaW4gdGhlIHJlYXNvbiBm b3IgdGhlIGNvbmZsaWN0LiIgLS0gSSBwZXJzb25hbGx5IGRvbid0IGNhcmUgd2hhdA0KPiA+PiB0 aGUgdmFsdWUgaXMgKEkgd2Fzbid0IHJlYWxseSB0aGlua2luZyB0aGF0IHRoaXMgd291bGQgb2Nj dXIgbXVjaCBvbg0KPiA+PiBiYXR0ZXJ5LXBvd2VyZWQgZGV2aWNlcywgYnV0IEkgbWF5IGJlIGNv bXBsZXRlbHkgd3JvbmcpLCBidXQgSSAqZG8qDQo+ID4+IHRoaW5rIHRoYXQgaWYgaXQgY29uZmxp Y3RzIHdpdGggUkZDIDc3NzIgaXQgbmVlZHMgdG8gbm90ZSB0aGlzLg0KPiA+Pg0KPiA+PiA0OiBN dWNoIG9mIHRoZSB0aHJlYWQgYWJvdmUgRGF2aWQgRmFybWVyJ3MNCj4gPj4gaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy92Nm9wcy9pNzJjYjByNmZWYnhoWkxocjRxeWJwcHdQ NlENCj4gPj4NCj4gPj4gNTogU2ltcGx5IHRoZSBhbW91bnQgb2YgZGlzY3Vzc2lvbiBhZnRlciBJ RVNHIGV2YWwsIGFuZCBJRVRGIExDIChJDQo+ID4+IHRoaW5rIHRoYXQgdGhlIG51bWJlciBpcyBz b21ldGhpbmcgbGlrZSAxMDAgYW5kID4zNTAgcmVzcGVjdGl2ZWx5KSAtLQ0KPiA+PiB3aGlsZSBt YW55IG9mIHRoZW0gd2FuZGVyZWQgYWZhciBmcm9tIHRoZSBhY3R1YWwgZHJhZnQgKGFuZCwgb2Z0 ZW4sDQo+ID4+IHRvcGljIDotKSkgaXQgaXMgaGFyZCB0byBtYWtlIHRoZSBjbGFpbSB0aGF0IHRo ZSBkb2N1bWVudCBpcyByZWFsbHkNCj4gPj4gY2xlYXIgYW5kIGhhcyBzdHJvbmcgY29uc2Vuc3Vz IGZyb20gdGhpcy4NCj4gPj4NCj4gPj4NCj4gPj4gSSdkIG5vdGUgdGhhdCAjMSwgMiwgYW5kIDQg YXJlIHZlcnkgY2xvc2VseSByZWxhdGVkLCBhbmQgSSB0aGluaw0KPiA+PiBzaG91bGQgYmUgZmFp cmx5IGVhc2lseSBhZGRyZXNzZWQuIEknbSBhbHNvIGhhcHB5IGZvciB0aGUgY2hhaXJzIHRvDQo+ ID4+IGhhdmUgYSBjb21wcmVzc2VkIDIgV0dMQyAoaWYgdGhleSB0aGluayBhcHByb3ByaWF0ZSku DQo+ID4+DQo+ID4+IEluY2lkZW50YWxseSAoYnV0IGluIG5vIHdheSByZWxldmFudCksIEkgaGFw cGVuIHRvIHJlYWxseSBsaWtlIHRoZQ0KPiA+PiBpZGVhIC8gZG9jdW1lbnQsIGFuZCB3b3VsZCBs aWtlIHRvIHNlZSBpdCBwdWJsaXNoZWQgKHNvb24hKS4NCj4gPj4gdw0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiA+PiAtPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS09LSBDb3B5LW4tcGFzdGUgb2YgYmFs bG90DQo+ID4+ID0tPS09LT0tPS09LT0tPS09LT0tPS09LT0tPS0NCj4gPj4NCj4gPj4gU3VyZXNo IEtyaXNobmFuRGlzY3Vzcw0KPiA+Pg0KPiA+PiBEaXNjdXNzICgyMDE3LTA4LTE2KQ0KPiA+Pg0K PiA+PiAqIFNlY3Rpb24gNA0KPiA+Pg0KPiA+PiBJdCBpcyBub3QgY2xlYXIgd2hhdCB5b3UgaW50 ZW5kIGhlcmUNCj4gPj4NCj4gPj4gIklQdjYgUm91dGVyIEFkdmVydGlzZW1lbnQgSW50ZXJ2YWwg PSAzMDBzIg0KPiA+Pg0KPiA+PiBUaGUgcm91dGVyIGFkdmVydGlzZW1lbnQgaW50ZXJ2YWwgaXMg bm90IGNvbmZpZ3VyZWQgYXMgYW4gYWJzb2x1dGUNCj4gPj4gdmFsdWUgYnV0IGFzIG1pbmltdW0g YW5kIG1heGltdW0gYm91bmRzIChNaW5SdHJBZHZJbnRlcnZhbCBhbmQNCj4gPj4gTWF4UnRyQWR2 SW50ZXJ2YWwpIHdoaWNoIGFyZSB1c2VkIHRvIGNhbGN1bGF0ZSB0aGUgYWN0dWFsDQo+ID4+IGFk dmVydGlzZW1lbnQgaW50ZXJ2YWwuIFdoZW4gdGhlIFJBIGlzIHNlbnQgZnJvbSBhbiBpbnRlcmZh Y2UsIHRoZQ0KPiA+PiBhY3R1YWwgaW50ZXJ2YWwgaXMgYW4gdW5pZm9ybWx5IGRpc3RyaWJ1dGVk IHJhbmRvbSB2YWx1ZSBiZXR3ZWVuIHRoZQ0KPiA+PiBNaW5SdHJBZHZJbnRlcnZhbCBhbmQgTWF4 UnRyQWR2SW50ZXJ2YWwuIEF0IHRoZSB2ZXJ5IG1pbmltdW0geW91IG5lZWQNCj4gPj4gdG8gY2xh cmlmeSBpZiB5b3Ugd291bGQgbGlrZSB0byBoYXZlIHRoaXMgYXMgYSBsb3dlciBib3VuZCBvciBh cyBhbg0KPiA+PiB1cHBlciBib3VuZC4NCj4gPj4NCj4gPj4gQ29tbWVudCAoMjAxNy0wOC0xNikN Cj4gPj4NCj4gPj4gKiBTZWN0aW9uIDQNCj4gPj4NCj4gPj4gLT4gSSB0aGluayB0ZXh0IGlzIG5l ZWRlZCBoZXJlIHRvIGhhbmRsZSB0aGUgY2FzZSB3aGVyZSB0aGUgRE5TIHNlcnZlcg0KPiA+PiBp cyBwcm92aWRlZCBpbiB0aGUgUkEgaXRzZWxmICAoUkZDODEwNikNCj4gPj4NCj4gPj4gIkluIGFk ZGl0aW9uIGl0IHdpbGwgdXNlIHN0YXRlbGVzcyBESENQdjYgdG8gZ2V0IHRoZSBJUHY2IGFkZHJl c3Mgb2YNCj4gPj4gdGhlIEROUyBzZXJ2ZXIiDQo+ID4+DQo+ID4+IC0+IEkgYW0gbm90IHN1cmUg d2hhdCBpcyB0aGUgbW90aXZhdGlvbiBmb3IgdGhpcyB0ZXh0Lg0KPiA+Pg0KPiA+PiAiaG93ZXZl ciBpdCBTSE9VTEQgTk9UIHVzZSBzdGF0ZWZ1bCBESENQdjYgdG8gcmVjZWl2ZSBhIHNlcnZpY2UN Cj4gPj4gcHJvdmlkZXIgbWFuYWdlZCBJUHY2IGFkZHJlc3MiDQo+ID4+DQo+ID4+IC0+IFRoaXMg dGV4dCBzZWVtcyBpbmNvcnJlY3QNCj4gPj4NCj4gPj4gImR1ZSB0byB0aGUgTC1iaXQgc2V0LCBp dCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMgdG8gdGhlIEZpcnN0IEhvcA0KPiA+PiBQcm92aWRl ciBSb3V0ZXIiDQo+ID4+DQo+ID4+IEkgdGhpbmsgaXQgc2hvdWxkIGJlIHRoZSBleGFjdCBvcHBv c2l0ZS4gaS5lLiBzYXkgKnVuc2V0KiBpbnN0ZWFkIG9mIHNldA0KPiA+Pg0KPiA+PiAiZHVlIHRv IHRoZSBMLWJpdCBiZWluZyB1bnNldCwgaXQgU0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljIHRvIHRo ZQ0KPiA+PiBGaXJzdCBIb3AgUHJvdmlkZXIgUm91dGVyIg0KPiA+Pg0KPiA+PiBXYXJyZW4gS3Vt YXJpWWVzDQo+ID4+DQo+ID4+IERlYm9yYWggQnJ1bmdhcmRObyBPYmplY3Rpb24NCj4gPj4NCj4g Pj4gQmVuIENhbXBiZWxsTm8gT2JqZWN0aW9uDQo+ID4+DQo+ID4+IENvbW1lbnQgKDIwMTctMDgt MTYpDQo+ID4+DQo+ID4+IEkgaGF2ZSBubyB0ZWNobmljYWwgY29tbWVudHMsIGJ1dCBhIG51bWJl ciBvZiBlZGl0b3JpYWwgY29tbWVudHM6DQo+ID4+DQo+ID4+IC0gR2VuZXJhbDogSSB0aGluayB0 aGlzIGNvdWxkIHVzZSBhbm90aGVyIHByb29mcmVhZGluZyBhbmQvb3IgZWRpdGluZw0KPiA+PiBw YXNzIGZvciB0aGUgZm9sbG93aW5nIGlzc3VlczoNCj4gPj4gLS0gSW5jb25zaXN0ZW50IHRlbnNl LS1lc3BlY2lhbGx5IHVzZSBvZiBmdXR1cmUgb3IgcHJlc2VudCBjb250aW51b3VzLg0KPiA+PiAt LSBXb3JkeSBhbmQgY29udm9sdXRlZCBzZW50ZW5jZXMNCj4gPj4gLS0gVXNlIG9mICIvIiBhcyBh IGNvbmp1bmN0aW9uLg0KPiA+Pg0KPiA+PiAtIEFic3RyYWN0Og0KPiA+PiBUaGUgYWJzdHJhY3Qg aXMgbG9uZ2VyIGFuZCBtb3JlIGRldGFpbGVkIHRoYW4gaXMgdXNlZnVsLiBUaGUgbGFzdA0KPiA+ PiBwYXJhZ3JhcGggY291bGQgaGF2ZSBzdG9vZCBhbG9uZSBhcyB0aGUgYWJzdHJhY3QuDQo+ID4+ IEl0J3Mgbm90IGNsZWFyIHRvIG1lIGlmICJob3N0cyAoc3Vic2NyaWJlcnMpIiBtZWFucyBzb21l dGhpbmcNCj4gPj4gZGlmZmVyZW50IHRoYW4gImhvc3RzIiBpbiBjb250ZXh0Lg0KPiA+Pg0KPiA+ PiAtMToNCj4gPj4gUGxlYXNlIGV4cGFuZCAiSUFfTkEiIG9uIGZpcnN0IHVzZS4NCj4gPj4gcy8i VGhpcyBkb2N1bWVudCB3aWxsIGZvY3VzLi4uIi8iVGhpcyBkb2N1bWVudCBmb2N1c2VzLi4uIg0K PiA+Pg0KPiA+PiAiQXMgc3VjaCB0aGUgdXNlDQo+ID4+ICAgIG9mIElQdjYgU0xBQUMgYmFzZWQg c3Vic2NyaWJlciBhbmQgYWRkcmVzcyBtYW5hZ2VtZW50IGZvciBwcm92aWRlcg0KPiA+PiAgICBt YW5hZ2VkIHNoYXJlZCBuZXR3b3JrIHNlcnZpY2VzIGlzIHRoZSByZWNvbW1lbmRlZCB0ZWNobm9s b2d5IG9mDQo+ID4+ICAgIGNob2ljZSwgYXMgaXQgZG9lcyBub3QgZXhjbHVkZSBhbnkga25vd24g SVB2NiBpbXBsZW1lbnRhdGlvbi4iDQo+ID4+IERvZXMgdGhpcyBkb2N1bWVudCBtYWtlIHRoYXQg cmVjb21tZW5kYXRpb24sIG9yIGlzIHRoYXQgc29tZQ0KPiA+PiBwcmUtZXhpc3RpbmcgcmVjb21t ZW5kYXRpb24/DQo+ID4+DQo+ID4+DQo+ID4+IC0zOiAiVGhlIEJlc3QgQ3VycmVudCBQcmFjdGlj ZSBkb2N1bWVudGVkIGluIHRoaXMgbm90ZSBpcyB0byBwcm92aWRlIGENCj4gPj4gICAgdW5pcXVl IElQdjYgcHJlZml4IHRvIGhvc3RzL3N1YnNjcmliZXJzIGRldmljZXMgY29ubmVjdGVkIHRvIHRo ZQ0KPiA+PiAgICBwcm92aWRlciBtYW5hZ2VkIHNoYXJlZCBuZXR3b3JrLiINCj4gPj4NCj4gPj4g VGhlIHNlbnRlbmNlIGhhcmQgdG8gZm9sbG93LiBDb25zaWRlciAiVGhpcyBkb2N1bWVudCByZWNv bW1lbmRzLi4uIi4NCj4gPj4gSSdtIG5vdCBzdXJlIGhvdyB0byBpbnRlcnByZXQgImhvc3RzL3N1 YnNjcmliZXJzIGRldmljZXMiDQo+ID4+DQo+ID4+ICJFYWNoIHVuaXF1ZSBJUHY2IHByZWZpeCBj YW4NCj4gPj4gICAgZnVuY3Rpb24gYXMgY29udHJvbC1wbGFuZSBhbmNob3IgcG9pbnQgdG8gbWFr ZSBzdXJlIHRoYXQgZWFjaA0KPiA+PiAgICBzdWJzY3JpYmVyIGlzIHJlY2VpdmluZyINCj4gPj4g cy8iLi4uIHN1YnNjcmliZXIgaXMgcmVjZWl2aW5nIC4uLiIvIi4uLiBzdWJzY3JpYmVyIHJlY2Vp dmVzLi4uIg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiAtNDogSXMgIkZpcnN0IEhvcCBQcm92aWRl ciBSb3V0ZXIiIGRpZmZlcmVudCB0aGFuICJGaXJzdCBIb3AgUm91dGVyIj8NCj4gPj4NCj4gPj4g SW4gdGhlIGxhc3QgYnVsbGV0IChMLWZsYWc9MCksIGFyZSBORVZFUiBhbmQgQUxXQVlTIGluIGFs bC1jYXBzDQo+ID4+IGV4cGVjdGVkIHRvIGhhdmUgZGlmZmVyZW50IG1lYW5pbmcgdGhhbiBpZiB0 aGV5IGhhZCBub3JtYWwNCj4gPj4gY2FwaXRhbGl6YXRpb24/DQo+ID4+DQo+ID4+IFRoZSBzZW50 ZW5jZSBzdGFydGluZyB3aXRoICJUaGUgYXJjaGl0ZWN0ZWQgcmVzdWx0IG9mIGRlc2lnbmluZyB0 aGUgUkENCj4gPj4gYXMgZG9jdW1lbnRlZCBhYm92ZS4uLiIgaXMgY29udm9sdXRlZCBhbmQgaGFy ZCB0byBmb2xsb3cuDQo+ID4+DQo+ID4+ICIuLi4gaG93ZXZlciBpdCBTSE9VTEQgTk9UIHVzZSBz dGF0ZWZ1bCBESENQdjYgdG8gcmVjZWl2ZQ0KPiA+PiAgICBhIHNlcnZpY2UgcHJvdmlkZXIgbWFu YWdlZCBJUHY2IGFkZHJlc3MiOiBJcyB0aGF0IHJlYWxseSBhDQo+ID4+IG5vcm1hdGl2ZSByZXF1 aXJlbWVudCwgb3IgaXMgaXQgYSBzdGF0ZW1lbnQgb2YgZmFjdCBhYm91dCBleGlzdGluZw0KPiA+ PiByZXF1aXJlbWVudHM/DQo+ID4+DQo+ID4+ICJpdCBTSE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMN Cj4gPj4gICAgdG8gdGhlIEZpcnN0IEhvcCBQcm92aWRlciBSb3V0ZXIuIiA6IHN0YXRlbWVudCBv ZiBmYWN0Pw0KPiA+Pg0KPiA+PiAtIDU6ICJUbyByZWR1Y2UNCj4gPj4gICAgdW5kZXNpcmVkIHJl c291cmNlIGNvbnN1bXB0aW9uIG9uIHRoZSBGaXJzdCBIb3AgUm91dGVyIHRoZSBkZXNpcmUgaXMN Cj4gPj4gICAgdG8gcmVtb3ZlIFVFL3N1YnNjcmliZXIgY29udGV4dCBpbiB0aGUgY2FzZSBvZiBu b24tcGVybWFuZW50IFVFLCBzdWNoDQo+ID4+ICAgIGFzIGluIHRoZSBjYXNlIG9mIFdpRmkgaG90 c3BvdHMgYXMgcXVpY2tseSBhcyBwb3NzaWJsZS4gIg0KPiA+PiBDb252b2x1dGVkIHNlbnRlbmNl Lg0KPiA+Pg0KPiA+PiAiQSBwb3NzaWJsZSBzb2x1dGlvbiBpcyB0byB1c2UgYSBzdWJzY3JpYmVy IGluYWN0aXZpdHkgdGltZXIgd2hpY2gsIGFmdGVyDQo+ID4+ICAgIHRyYWNraW5nIGEgcHJlLWRl ZmluZWQgKGN1cnJlbnRseSB1bnNwZWNpZmllZCkgbnVtYmVyIG9mIG1pbnV0ZXMsDQo+ID4+ICAg IGRlbGV0ZXMgdGhlIHN1YnNjcmliZXIgY29udGV4dCBvbiB0aGUgRmlyc3QgSG9wIFJvdXRlci4i DQo+ID4+DQo+ID4+IHMvd2hpY2gvdGhhdCAgIChDb25zaWRlciAiIC4uLiB0aW1lciB0aGF0IGRl bGV0ZXMuLi5hZnRlciBhDQo+ID4+IHByZWRldGVybWluZWQgbnVtYmVyIG9mIG1pbnV0ZXMiDQo+ ID4+DQo+ID4+IC03OiAiVGhlDQo+ID4+ICAgIGNvbWJpbmF0aW9uIG9mIGJvdGggSVB2NiBwcml2 YWN5IGV4dGVuc2lvbnMgYW5kIG9wZXJhdG9yIGJhc2VkDQo+ID4+ICAgIGFzc2lnbm1lbnQgb2Yg YSBVbmlxdWUgSVB2NiBQcmVmaXggcGVyIEhvc3QgcHJvdmlkZXMgZWFjaA0KPiA+PiAgICBpbXBs ZW1lbnRpbmcgb3BlcmF0b3IgYSB0b29sIHRvIG1hbmFnZSBhbmQgcHJvdmlkZSBzdWJzY3JpYmVy DQo+ID4+ICAgIHNlcnZpY2VzIGFuZCBoZW5jZSByZWR1Y2VzIHRoZSBleHBlcmllbmNlZCBwcml2 YWN5IHdpdGhpbiBlYWNoDQo+ID4+ICAgIG9wZXJhdG9yIGNvbnRyb2xsZWQgZG9tYWluLiINCj4g Pj4NCj4gPj4gSSBoYXZlIHRyb3VibGUgZm9sbG93aW5nIHRoYXQgc2VudGVuY2UuIElzIHRoZSBw b2ludCB0byBzYXkgdGhhdA0KPiA+PiBwcm92aWRpbmcgdG9vbHMgdG8gbWFuYWdlIGFuZCBwcm92 aWRlIHNlcnZpY2VzIHJlZHVjZXMgcHJpdmFjeSBpbg0KPiA+PiBnZW5lcmFsPyBBcyB3b3JkZWQs IGl0IGFsbW9zdCBzb3VuZHMgbGlrZSB0aGlzIGlzIG1lYW50IGFzIGEgZmVhdHVyZSwNCj4gPj4g d2hpY2ggSSBhc3N1bWUgaXMgbm90IHRoZSBjYXNlLg0KPiA+Pg0KPiA+PiBTcGVuY2VyIERhd2tp bnNObyBPYmplY3Rpb24NCj4gPj4NCj4gPj4gQ29tbWVudCAoMjAxNy0wOC0xNSkNCj4gPj4NCj4g Pj4gT25lIG5pdDoNCj4gPj4NCj4gPj4gUGxlYXNlIGNvbnNpZGVyIG1vdmluZw0KPiA+Pg0KPiA+ PiAgICBCZW5lZml0cyBvZiB1bmlxdWUNCj4gPj4gICAgSVB2NiBwcmVmaXggb3ZlciBhIHVuaXF1 ZSBJUHY2IGFkZHJlc3MgZnJvbSB0aGUgc2VydmljZSBwcm92aWRlcg0KPiA+PiAgICBpbmNsdWRl IGltcHJvdmVkIHN1YnNjcmliZXIgaXNvbGF0aW9uIGFuZCBlbmhhbmNlZCBzdWJzY3JpYmVyDQo+ ID4+ICAgIG1hbmFnZW1lbnQuDQo+ID4+DQo+ID4+IHRvIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2Yg dGhlIEFic3RyYWN0LiBJ4oCZbSBhc3N1bWluZyB0aGF0IHRoaXMNCj4gPj4gZXhwbGFpbnMgdGhl IOKAnG5lZWRzIHRoYXQgaGF2ZSBhcmlzZW7igJ0gaW4gdGhlIGZpcnN0IHNlbnRlbmNlIG9mIHRo ZQ0KPiA+PiBBYnN0cmFjdCwgb2YgY291cnNlLg0KPiA+Pg0KPiA+PiBNaXJqYSBLw7xobGV3aW5k Tm8gT2JqZWN0aW9uDQo+ID4+DQo+ID4+IENvbW1lbnQgKDIwMTctMDgtMTQpDQo+ID4+DQo+ID4+ IFRvIG1lIHRoaXMgc2VlbXMgYXBwcm9yaWF0ZSBmb3IgQkNQOyBJJ20gc2F5aW5nIHRoaXMgYmVj YXVzZSB0aGlzIHdhcw0KPiA+PiBtZW50aW9uZWQgaW4gdGhlIHNoZXBoZXJkLXdyaXRlLXVwIGFz IGl0IHdhcyBicm91Z2h0IHVwIGJ5IHRoZSBnZW4tYXJ0DQo+ID4+IHJldmlldy4NCj4gPj4NCj4g Pj4gUGxlYXNlIGFsc28gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBjb21tZW50IGZyb20gdGhlIGdl bi1hcnQgcmV2aWV3DQo+ID4+IChUaGFua3MgSm9lbCEpOg0KPiA+PiAiVGhlIGlzc3VlIG9mIHN0 YXR1cyBmb3IgdGhlIGRvY3VtZW50IChCQ1AgdnMgSW5mb3JtYXRpb25hbCkgaXMgZm9yIHRoZSBJ RVNHDQo+ID4+ICAgIHRvIGNvbmNsdWRlLiAgSG93ZXZlciwgZXZlbiBpZiBpdCBpcyBhIEJDUCwg YXMgSSB1bmRlcnN0YW5kIHRoZSBwdXJwb3NlLA0KPiA+PiAgICB0aGlzIGRvY3VtZW50IGlzIGlu dGVuZGVkIHRvIGRlc2NyaWJlIHRoZSBwcmFjdGljZXMgdG8gYmUgdXNlZCB3aGVuIGENCj4gPj4g ICAgcHJvdmlkZXIgaGFzIGRlY2lkZWQgdG8gZGVwbG95IGEgLzY0IHBlciBob3N0LiAgVGhlIHdv cmRpbmcgdGhhdCBpcyBjaG9zZW4NCj4gPj4gICAgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgbWFr ZXMgaXQgYXBwZWFyIHRoYXQgdGhlIHVuZGVybHlpbmcgZGVjaXNpb24gYWJvdXQNCj4gPj4gICAg c3VjaCBhIGRlcGxveW1lbnQgaXMgYWxzbyBhIHJlY29tbWVuZGVkIHByYWN0aWNlLiINCj4gPj4g SSBhZ3JlZSB0aGF0IHdvcmRpbmcgY291bGQgYmUgbWFkZSBjbGVhcmVyIGhlcmUhDQo+ID4+DQo+ ID4+IEFsZXhleSBNZWxuaWtvdk5vIE9iamVjdGlvbg0KPiA+Pg0KPiA+PiBDb21tZW50ICgyMDE3 LTA4LTEyKQ0KPiA+Pg0KPiA+PiBSYWRpdXMgc2hvdWxkIGhhdmUgYW4gaW5mb3JtYXRpdmUgcmVm ZXJlbmNlIG9uIGZpcnN0IHVzZS4NCj4gPj4NCj4gPj4gS2F0aGxlZW4gTW9yaWFydHlObyBPYmpl Y3Rpb24NCj4gPj4NCj4gPj4gQ29tbWVudCAoMjAxNy0wOC0xNSkNCj4gPj4NCj4gPj4gVGhhbmsg eW91IGZvciBhZGRyZXNzaW5nIHRoZSBTZWNEaXIgcmV2aWV3Og0KPiA+PiBodHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NlY2Rpci93V3BfMHZsbXN6N1NzLW5vd2poZWhZSW1P ZWcNCj4gPj4NCj4gPj4gRXJpYyBSZXNjb3JsYU5vIE9iamVjdGlvbg0KPiA+Pg0KPiA+PiBDb21t ZW50ICgyMDE3LTA4LTE1KQ0KPiA+Pg0KPiA+PiBEb2N1bWVudDogZHJhZnQtaWV0Zi12Nm9wcy11 bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDcudHh0DQo+ID4+DQo+ID4+DQo+ID4+IEkgZm91 bmQgdGhlIGRpc2N1c3Npb24gb2YgdGhlIHNoYXJlZCBuZXR3b3JrIG1lZGl1bSBhIGJpdA0KPiA+ PiBjb25mdXNpbmcuIEFzIEkgdW5kZXJzdGFuZCBpdCwgdGhlIGlkZWEgaXMgdGhhdCBpZiB3ZSBh cmUNCj4gPj4gb24gYSBzaGFyZWQgbmV0d29yayBhbmQgd2UgaGF2ZSB0aGUgc2FtZSBwcmVmaXgs IEkgbWlnaHQNCj4gPj4gdHJ5IHRvIHNlbmQgdG8geW91IGRpcmVjdGx5LiBXaGF0IHlvdSB3YW50 IHRvIGRvIGlzIG1ha2UNCj4gPj4gdGhhdCBub3QgaGFwcGVuIGJ5IGhhdmluZyBlYWNoIG5vZGUg aGF2ZSBhIHNlcGFyYXRlIHByZWZpeC4NCj4gPj4gQ29ycmVjdD8gSWYgc28sIHBlcmhhcHMgcHJv bW90ZSB0aGlzIGJ1bGxldCwgYW5kIGFsc28gaGF2ZQ0KPiA+PiBpdCBkZXNjcmliZSB0aGUgcHJv YmxlbSBhbmQgd2h5IHRoaXMgcHJvdmlkZXMgYSBzb2x1dGlvbjoNCj4gPj4NCj4gPj4gICAgbyAg VHdvIGRldmljZXMgKHN1YnNjcmliZXIvaG9zdHMpLCBib3RoIGF0dGFjaGVkIHRvIHRoZSBzYW1l IHByb3ZpZGVyDQo+ID4+ICAgICAgIG1hbmFnZWQgc2hhcmVkIG5ldHdvcmsgc2hvdWxkIG9ubHkg YmUgYWJsZSB0byBjb21tdW5pY2F0ZSB0aHJvdWdoDQo+ID4+ICAgICAgIHRoZSBwcm92aWRlciBt YW5hZ2VkIEZpcnN0IEhvcCBSb3V0ZXINCj4gPj4NCj4gPj4NCj4gPj4gSXQncyBhIGJpdCB1bmNs ZWFyIHRvIG1lIGhvdyBtdWNoIHlvdSBhcmUgc2F5aW5nIHRoYXQNCj4gPj4gc29tZXRoaW5nIGlz IGN1cnJlbnQgcHJhY3RpY2UgdmVyc3VzIGhvdyBtdWNoIHlvdSBhcmUNCj4gPj4gcmVjb21tZW5k aW5nIGl0LiBGb3IgaW5zdGFuY2UsIHRoZSBhYnN0cmFjdCByZWFkcyBtb3JlDQo+ID4+IGxpa2Ug d2hhdCB5b3Ugd291bGQgZXhwZWN0IGZvciBQUy4NCj4gPj4NCj4gPj4gICAgVGhpcyBkb2N1bWVu dCBvdXRsaW5lcyBhbiBhcHByb2FjaCB1dGlsaXNpbmcgZXhpc3RpbmcgSVB2NiBwcm90b2NvbHMN Cj4gPj4gICAgdG8gYWxsb3cgaG9zdHMgdG8gYmUgYXNzaWduZWQgYSB1bmlxdWUgSVB2NiBwcmVm aXggKGluc3RlYWQgb2YgYQ0KPiA+PiAgICB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gYSBzaGFy ZWQgSVB2NiBwcmVmaXgpLiAgQmVuZWZpdHMgb2YgdW5pcXVlDQo+ID4+ICAgIElQdjYgcHJlZml4 IG92ZXIgYSB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gdGhlIHNlcnZpY2UgcHJvdmlkZXINCj4g Pj4gICAgaW5jbHVkZSBpbXByb3ZlZCBzdWJzY3JpYmVyIGlzb2xhdGlvbiBhbmQgZW5oYW5jZWQg c3Vic2NyaWJlcg0KPiA+PiAgICBtYW5hZ2VtZW50Lg0KPiA+Pg0KPiA+PiBCdXQgdGhlbiBTIDQg c2VlbXMgdG8gYmUgZG9jdW1lbnRpbmc6DQo+ID4+DQo+ID4+ICAgIFRoZSBJUHY2IFJBIGZsYWdz IHVzZWQgZm9yIGJlc3QgY29tbW9uIHByYWN0aWNlIGluIElQdjYgU0xBQUMgYmFzZWQNCj4gPj4g ICAgUHJvdmlkZXIgbWFuYWdlZCBzaGFyZWQgbmV0d29ya3MgYXJlOg0KPiA+Pg0KPiA+Pg0KPiA+ PiAgICBUaGUgdXNlIG9mIGEgdW5pcXVlIElQdjYgcHJlZml4IHBlciBVRSBhZGRzIGFuIGFkZGl0 aW9uYWwgbGV2ZWwgb2YNCj4gPj4gICAgcHJvdGVjdGlvbiBhbmQgZWZmaWNpZW5jeSBhcyBpdCBy ZWxhdGVzIHRvIGhvdyBJUHY2IE5laWdoYm9yDQo+ID4+ICAgIERpc2NvdmVyeSBhbmQgUm91dGVy IERpc2NvdmVyeSBwcm9jZXNzaW5nLiAgU2luY2UgdGhlIFVFIGhhcyBhIHVuaXF1ZQ0KPiA+PiAg ICBJUHY2IHByZWZpeCBhbGwgdHJhZmZpYyBieSBkZWZhdWx0IHdpbGwgYmUgZGlyZWN0ZWQgdG8g dGhlIEZpcnN0IEhvcA0KPiA+PiAgICBwcm92aWRlciByb3V0ZXIuICBGdXJ0aGVyLCB0aGUgZmxh ZyBjb21iaW5hdGlvbnMgZG9jdW1lbnRlZCBhYm92ZQ0KPiA+PiAgICBtYXhpbWlzZSB0aGUgSVB2 NiBjb25maWd1cmF0aW9ucyB0aGF0IGFyZSBhdmFpbGFibGUgYnkgaG9zdHMNCj4gPj4gICAgaW5j bHVkaW5nIHRoZSB1c2Ugb2YgcHJpdmFjeSBJUHY2IGFkZHJlc3NpbmcuDQo+ID4+DQo+ID4+IEl0 J3Mgbm90IHF1aXRlIGNsZWFyIHRvIG1lIHdoeSB1bmlxdWUgcHJlZml4cyBhcmUgbmVlZGVkIGhl cmUgaWYNCj4gPj4gcGVvcGxlIHNldCBMPTAuIElzIGl0IHRoYXQgcGVvcGxlIGlnbm9yZSBMPTA/ DQo+ID4+DQo+ID4+IEZpbmFsbHksIEknbSBhIGJpdCBjb25mdXNlZCBhYm91dCBob3cgdG8gcmVh ZCB0aGlzIHRleHQgYWJvdXQgdGhlDQo+ID4+IEw9MCBiaXQgaW4gY2FzZXMgd2hlcmUgSSBoYXZl IG11bHRpcGxlIGRldmljZXMgcmF0aGVyIHRoYW4ganVzdCBvbmUNCj4gPj4gYXQgdGhlIGN1c3Rv bWVyIHByZW0uIFNheSBJIGhhdmUgYSB0b3BvbG9neSB3aXRoIGEgaG9tZSByb3V0ZXINCj4gPj4g YW5kIGRldmljZXMgYmVoaW5kIGl0LiBJLmUuLA0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAg ICAgIFNlcnZpY2UgUHJvdmlkZXINCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K PiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ID4+ICAgICAgICAgICAgICAgICAg ICAgICAgIEN1c3RvbWVyDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICBSb3V0ZXINCj4g Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+PiAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0rDQo+ID4+ICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwg ICAgICAgICAgIHwNCj4gPj4gICAgICAgICAgICAgIEhvc3QgMSAgICAgIEhvc3QgMiAgICAgIEhv c3QgMw0KPiA+Pg0KPiA+PiBJIGFzc3VtZSB3aGF0IGhhcHBlbnMgaGVyZSBpcyB0aGF0IHRoZSBy b3V0ZXIgZ2V0cyBwcmVmaXggWCwgYXNzaWducw0KPiA+PiBpdHNlbGYgWFksIGFuZCB0aGVuIHRo ZSBIb3N0cyBnZXQgWEEsIFhCLCBYQywgZXRjLCBhIGxhIDcyNzguIElzIHRoYXQNCj4gPj4gcmln aHQ/IElmIHNvLCBteSBxdWVzdGlvbiBpcyBhYm91dCBwYWNrZXRzIGNvbWluZyBpbnRvIHRoZSBS b3V0ZXIgZnJvbQ0KPiA+PiB0aGUgU1AsIHdoaWNoIGhhdmUgKHNheSkgWEEuICBUaGUgdGV4dCBh Ym91dCB0aGUgTC1mbGFnIHN1Z2dlc3RzIHRoYXQNCj4gPj4gdGhlIHJvdXRlciBzaG91bGQgc2Vu ZCB0aGVtIGJhY2sgdG8gdGhlIGdhdGV3YXksIGJ1dCB0aGF0J3MgY2xlYXJseQ0KPiA+PiBub3Qg cmlnaHQuIFdoYXQgYW0gSSBtaXNzaW5nPw0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0K PiA+Pg0KPiA+PiA+IENoZWVycywNCj4gPj4gPiBMb3JlbnpvDQo+ID4+ID4NCj4gPj4gPiBPbiBT dW4sIFNlcCAxMCwgMjAxNyBhdCA0OjQ5IEFNLCBXYXJyZW4gS3VtYXJpIDx3YXJyZW5Aa3VtYXJp Lm5ldD4gd3JvdGU6DQo+ID4+ID4+DQo+ID4+ID4+IFsgVG9wLXBvc3QgXQ0KPiA+PiA+Pg0KPiA+ PiA+PiBZdXAsIEkgd2FzIHRoaW5raW5nIHRoYXQsIHdoaWxlIHN1YnN0YW50aXZlLCB0aGF0IHdv dWxkIGJlIGhhbmRsZWQNCj4gPj4gPj4gd2hpbGUgc3RpbGwga2VlcGluZyBpdCBpbiBJRVNHIGV2 YWwgLS0gYnV0LCBJJ3ZlIGp1c3QgZ29uZSBiYWNrIGFuZA0KPiA+PiA+PiByZS1yZWFkIHRoZSB0 aHJlYWRzLCBlc3BlY2lhbGx5IGFsbCBvZiB0aGUgbWFpbCAofjEwMikgYWZ0ZXIgdGhlIElFU0cN Cj4gPj4gPj4gLyB0ZWxlY2hhdCwgYW5kIEkndmUgZGVjaWRlZCB0aGF0IEkgd2lsbCBoYXZlIHRv IHJldHVybiBpdCB0byB0aGUgV0cuDQo+ID4+ID4+IFNlZWluZyBhcyBpdCBoYXMgYWxyZWFkeSBo YWQgYSBXR0xDLCBJIGV4cGVjdCB0aGF0IHRoZSBuZXh0IG9uZSBjYW4gYmUNCj4gPj4gPj4gY29t cHJlc3NlZC4NCj4gPj4gPj4NCj4gPj4gPj4gVGhlIGdvb2QgbmV3cyBpcyB0aGF0IGE6IHRoZXJl IGhhdmUgYmVlbiBhIG51bWJlciBvZiBzdWdnZXN0aW9ucyAvDQo+ID4+ID4+IHByb3ZpZGVkIHRl eHQgdG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQsIGFuZCBiOiBJJ2QgZXhwZWN0IHRoZSBuZXh0IElF U0cNCj4gPj4gPj4gZXZhbCB0byBnbyBlYXNpbHkuDQo+ID4+ID4+DQo+ID4+ID4+IFNvcnJ5IGFs bCwNCj4gPj4gPj4gVw0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiBPbiBNb24sIFNlcCA0LCAy MDE3IGF0IDY6MzIgUE0sIEJyaWFuIEUgQ2FycGVudGVyDQo+ID4+ID4+IDxicmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiA+PiA+PiA+IFdhcnJlbiwNCj4gPj4gPj4gPg0KPiA+ PiA+PiA+IEkgYmVsaWV2ZSBpdCdzIHN1YnN0YW50aXZlIHRoYXQgdGhlIHRleHQgcmVmZXJzIHRv IHNlbmRpbmcgdW5pY2FzdA0KPiA+PiA+PiA+IFJBcyB3aXRob3V0IGNsYXJpZnlpbmcgd2hldGhl ciB0aGlzIG1lYW5zIHRoYXQgdGhleSBhcmUgc2VudA0KPiA+PiA+PiA+IHdpdGggYSB1bmljYXN0 IGxheWVyIDIgYWRkcmVzcyBhbmQgYSBtdWx0aWNhc3QgbGF5ZXIgMyBhZGRyZXNzDQo+ID4+ID4+ ID4gKGFzIHBlciBSRkM2MDg1KSBvciB0aGF0IHRoZXkgYXJlIHNlbnQgd2l0aCBib3RoIGxheWVy IDIgYW5kDQo+ID4+ID4+ID4gbGF5ZXIgMyBhZGRyZXNzZXMgYmVpbmcgdW5pY2FzdC4gQXQgdGhl IG1vbWVudCwgYW4gaW1wbGVtZW50ZXINCj4gPj4gPj4gPiBoYXMgdG8gZGVjaWRlIHdoaWNoIG9m IHRoZXNlIGlzIGludGVuZGVkLiBJZiBlaXRoZXIgaXMgT0ssDQo+ID4+ID4+ID4gdGhhdCBjb3Vs ZCBiZSBzdGF0ZWQgdG9vLg0KPiA+PiA+PiA+DQo+ID4+ID4+ID4gU3BlY2lmaWNhbGx5IHRoaXMg Y2xhcmlmaWNhdGlvbiBzZWVtcyB0byBiZSBuZWVkZWQgcmlnaHQgYWZ0ZXI6DQo+ID4+ID4+ID4N Cj4gPj4gPj4gPj4gNC4gIElQdjYgVW5pcXVlIFByZWZpeCBBc3NpZ25tZW50DQo+ID4+ID4+ID4+ DQo+ID4+ID4+ID4+ICAgIFdoZW4gYSBVRSBjb25uZWN0cyB0byB0aGUgc2hhcmVkIHByb3ZpZGVy IG1hbmFnZWQgbmV0d29yayBhbmQgaXMNCj4gPj4gPj4gPj4gICAgYXR0YWNoZWQsIGl0IHdpbGwg aW5pdGlhdGUgSVAgY29uZmlndXJhdGlvbiBwaGFzZS4gIER1cmluZyB0aGlzDQo+ID4+ID4+ID4+ IHBoYXNlDQo+ID4+ID4+ID4+ICAgIHRoZSBVRSB3aWxsLCBmcm9tIGFuIElQdjYgcGVyc3BlY3Rp dmUsIGF0dGVtcHQgdG8gbGVhcm4gdGhlIGRlZmF1bHQNCj4gPj4gPj4gPj4gICAgSVB2NiBnYXRl d2F5LCB0aGUgSVB2NiBwcmVmaXggaW5mb3JtYXRpb24sIHRoZSBETlMgaW5mb3JtYXRpb24NCj4g Pj4gPj4gPj4gICAgUkZDODEwNiBbUkZDODEwNl0sIGFuZCB0aGUgcmVtYWluaW5nIGluZm9ybWF0 aW9uIHJlcXVpcmVkIHRvDQo+ID4+ID4+ID4+ICAgIGVzdGFibGlzaCBnbG9iYWxseSByb3V0YWJs ZSBJUHY2IGNvbm5lY3Rpdml0eS4gIEZvciB0aGF0IHB1cnBvc2UsDQo+ID4+ID4+ID4+IHRoZQ0K PiA+PiA+PiA+PiAgICB0aGUgVUUvc3Vic2NyaWJlciBzZW5kcyBhIFJTIChSb3V0ZXIgU29saWNp dGF0aW9uKSBtZXNzYWdlLg0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+PiAgICBUaGUgRmlyc3QgSG9w IFJvdXRlciByZWNlaXZlcyB0aGlzIFVFL3N1YnNjcmliZXIgUlMgbWVzc2FnZSBhbmQNCj4gPj4g Pj4gPj4gICAgc3RhcnRzIHRoZSBwcm9jZXNzIHRvIGNvbXBvc2UgdGhlIHJlc3BvbnNlIHRvIHRo ZSBVRS9zdWJzY3JpYmVyDQo+ID4+ID4+ID4+ICAgIG9yaWdpbmF0ZWQgUlMgbWVzc2FnZS4gIFRo ZSBGaXJzdCBIb3AgUHJvdmlkZXIgUm91dGVyIHdpbGwgYW5zd2VyDQo+ID4+ID4+ID4+ICAgIHVz aW5nIGEgdW5pY2FzdCBSQSAoUm91dGVyIEFkdmVydGlzZW1lbnQpIHRvIHRoZSBVRS9zdWJzY3Jp YmVyLg0KPiA+PiA+PiA+DQo+ID4+ID4+ID4gUmVnYXJkcw0KPiA+PiA+PiA+ICAgIEJyaWFuIENh cnBlbnRlcg0KPiA+PiA+PiA+DQo+ID4+ID4+ID4gT24gMDUvMDkvMjAxNyAwOTo0MywgV2FycmVu IEt1bWFyaSB3cm90ZToNCj4gPj4gPj4gPj4gSSdkIGxpa2UgdG8gbm90ZSB0aGF0IHRoYXQgdGhl cmUgaXMgY29udGludWluZyBkaXNjdXNzaW9uIG9uIHRoaXMNCj4gPj4gPj4gPj4gZHJhZnQgb24g dGhlIHY2IG9wcyBsaXN0ICh5dXAsIGFmdGVyIFdHTEMgYW5kIElFVEYgTEMgOi0pKS4gSSd2ZSBv bmx5DQo+ID4+ID4+ID4+IGJlZW4gYWJsZSB0byBzb21ld2hhdCBtb25pdG9yIGl0LCBidXQgaGF2 ZSBhc2tlZCB0aGUgdjZvcHMgY2hhaXJzIGZvcg0KPiA+PiA+PiA+PiBpbnB1dC4gTXVjaCBvZiB0 aGUgZGlzY3Vzc2lvbiBoYXMgYmVlbiBpbnRlcmVzdGluZywgYnV0IG5vdA0KPiA+PiA+PiA+PiBu ZWNlc3NhcmlseSBwZXJ0YWluaW5nIGV4YWN0bHkgdG8gdGhpcyBkb2N1bWVudC4NCj4gPj4gPj4g Pj4gRnJlZCBraW5kbHkgYXNrZWQgdGhlIGxpc3Q6DQo+ID4+ID4+ID4+IGh0dHBzOi8vbWFpbGFy Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdjZvcHMvYnBFRHRuWWtidkpRWkF4X3I2bXRFaGROeHJ3 DQo+ID4+ID4+ID4+IGZvciBhbnl0aGluZyBzdWJzdGFudGl2ZSBmb3IgdGhlIGRvY3VtZW50IChr ZWVwaW5nIGluIG1pbmQgdGhhdCBpdCBoYXMNCj4gPj4gPj4gPj4gYWxyZWFkeSBnb25lIHRocm91 Z2ggV0dMQyBhbmQgSUVURiBMQykuDQo+ID4+ID4+ID4+DQo+ID4+ID4+ID4+IFNvIGZhciBpdCBk b2Vzbid0IHNlZW0gbGlrZSB0aGVyZSBhcmUgYW55IG90aGVyIG1ham9yIGNoYW5nZXMgbmVlZGVk LA0KPiA+PiA+PiA+PiBvdGhlciB0aGFuICJhc2tpbmcgdGhhdCB0aGUgYXBwbGljYWJpbGl0eSBj b21tZW50IHRoYXQgY29tbXVuaWNhdGlvbg0KPiA+PiA+PiA+PiBiZXR3ZWVuIHN1Y2ggbm9kZXMg b24gYSBMQU4gc2hvdWxkIGdvIHRocm91Z2ggYSBjb25uZWN0aW5nIHJvdXRlcg0KPiA+PiA+PiA+ PiAod2hpY2ggc2VlbXMgdG8gbWUgYSBnaXZlbiBkdWUgdG8gdGhlIHJlbGF0aW9uc2hpcCB3aXRo IHJvdXRpbmcpDQo+ID4+ID4+ID4+IHNob3VsZCBiZSBkb2N1bWVudGVkLiIgYW5kIERhdmlkIEZh cm1lcidzIGZvbGxvd3VwIC0tDQo+ID4+ID4+ID4+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvdjZvcHMvXy1RbEJxR2s5ZENob0ZPaHhpZ2Y1V2x4WURZDQo+ID4+ID4+ID4+ DQo+ID4+ID4+ID4+IERvZXMgYW55b25lIGhhdmUgYW55dGhpbmcgZWxzZSAqc3Vic3RhbnRpdmUq PyBJZiBzbywgSSBtYXkgaGF2ZSB0bw0KPiA+PiA+PiA+PiBraWNrIHRoaXMgYmFjayB0byB0aGUg V0cgZm9yIGFub3RoZXIgcm91bmQuDQo+ID4+ID4+ID4+DQo+ID4+ID4+ID4+IFcNCj4gPj4gPj4g Pj4NCj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4NCj4gPj4gPj4gPj4gT24gVHVl LCBBdWcgMjIsIDIwMTcgYXQgNzozMSBQTSwgU3VyZXNoIEtyaXNobmFuDQo+ID4+ID4+ID4+IDxz dXJlc2gua3Jpc2huYW5AZ21haWwuY29tPiB3cm90ZToNCj4gPj4gPj4gPj4+IEhpIEd1bnRlciwN Cj4gPj4gPj4gPj4+ICAgVGhhbmtzIGZvciB0aGUgcHJvcG9zZWQgdGV4dCBjaGFuZ2VzLiBUaGV5 IGFkZXF1YXRlbHkgYWRkcmVzcyBteQ0KPiA+PiA+PiA+Pj4gRElTQ1VTUw0KPiA+PiA+PiA+Pj4g cG9pbnRzLiBJIGFtIGhvcGluZyB5b3Ugd2lsbCBhbHNvIGNvbnZlcmdlIGluIHRoZSBkaXNjdXNz aW9uIHdpdGgNCj4gPj4gPj4gPj4+IExvcmVuem8gb24NCj4gPj4gPj4gPj4+IHRoZSBhY3R1YWwg dmFsdWUgZm9yIHRoZSB0aW1lciBhbmQvb3Igc3BlY2lmeSBhbiBhcHBsaWNhYmlsaXR5DQo+ID4+ ID4+ID4+PiBzdGF0ZW1lbnQuIEkNCj4gPj4gPj4gPj4+IHdpbGwgY2xlYXIgb25jZSB0aGUgbmV3 IHJldmlzaW9uIHBvc3RzLg0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+IFJlZ2FyZHMNCj4gPj4g Pj4gPj4+IFN1cmVzaA0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+IE9uIEF1ZyAyMSwgMjAxNywg YXQgODo1NyBBTSwgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkNCj4g Pj4gPj4gPj4+IDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4gd3JvdGU6DQo+ID4+ID4+ ID4+Pg0KPiA+PiA+PiA+Pj4gSGkgU3VyZXNoLA0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+IE1h bnkgdGhhbmtzIGZvciB0aGUgcmV2aWV3IGFuZCBmaW5kaW5nIHRoZXNlIGlzc3Vlcy4gV2hhdCBk byB5b3UgdGhpbmsNCj4gPj4gPj4gPj4+IG9mDQo+ID4+ID4+ID4+PiB0aGUgcHJvcG9zYWxzIGJl bG93IHRvIGZpeCB0aG9zZSBwb2ludHMgb2YgYXR0ZW50aW9uPw0KPiA+PiA+PiA+Pj4NCj4gPj4g Pj4gPj4+DQo+ID4+ID4+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ID4+ID4+PiAgICBESVNDVVNT Og0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gPj4gPj4+DQo+ ID4+ID4+ID4+PiAgICAqIFNlY3Rpb24gNA0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+ICAgIEl0 IGlzIG5vdCBjbGVhciB3aGF0IHlvdSBpbnRlbmQgaGVyZQ0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4g Pj4+ICAgICJJUHY2IFJvdXRlciBBZHZlcnRpc2VtZW50IEludGVydmFsID0gMzAwcyINCj4gPj4g Pj4gPj4+DQo+ID4+ID4+ID4+PiAgICBUaGUgcm91dGVyIGFkdmVydGlzZW1lbnQgaW50ZXJ2YWwg aXMgbm90IGNvbmZpZ3VyZWQgYXMgYW4gYWJzb2x1dGUNCj4gPj4gPj4gPj4+IHZhbHVlDQo+ID4+ ID4+ID4+PiBidXQgYXMNCj4gPj4gPj4gPj4+ICAgIG1pbmltdW0gYW5kIG1heGltdW0gYm91bmRz IChNaW5SdHJBZHZJbnRlcnZhbCBhbmQNCj4gPj4gPj4gPj4+IE1heFJ0ckFkdkludGVydmFsKQ0K PiA+PiA+PiA+Pj4gd2hpY2ggYXJlDQo+ID4+ID4+ID4+PiAgICB1c2VkIHRvIGNhbGN1bGF0ZSB0 aGUgYWN0dWFsIGFkdmVydGlzZW1lbnQgaW50ZXJ2YWwuIFdoZW4gdGhlIFJBIGlzDQo+ID4+ID4+ ID4+PiBzZW50DQo+ID4+ID4+ID4+PiBmcm9tDQo+ID4+ID4+ID4+PiAgICBhbiBpbnRlcmZhY2Us IHRoZSBhY3R1YWwgaW50ZXJ2YWwgaXMgYW4gdW5pZm9ybWx5IGRpc3RyaWJ1dGVkDQo+ID4+ID4+ ID4+PiByYW5kb20NCj4gPj4gPj4gPj4+IHZhbHVlDQo+ID4+ID4+ID4+PiAgICBiZXR3ZWVuIHRo ZSBNaW5SdHJBZHZJbnRlcnZhbCBhbmQgTWF4UnRyQWR2SW50ZXJ2YWwuIEF0IHRoZSB2ZXJ5DQo+ ID4+ID4+ID4+PiBtaW5pbXVtDQo+ID4+ID4+ID4+PiB5b3UNCj4gPj4gPj4gPj4+ICAgIG5lZWQg dG8gY2xhcmlmeSBpZiB5b3Ugd291bGQgbGlrZSB0byBoYXZlIHRoaXMgYXMgYSBsb3dlciBib3Vu ZCBvcg0KPiA+PiA+PiA+Pj4gYXMgYW4NCj4gPj4gPj4gPj4+IHVwcGVyDQo+ID4+ID4+ID4+PiAg ICBib3VuZC4NCj4gPj4gPj4gPj4+DQo+ID4+ID4+ID4+PiBHVj4gSSBjaGFuZ2VkIHRoZSBsaW5l IHRvIG1ha2UgaXQgbW9yZSBjbGVhciB0aGF0IHRoZSB0aW1lciBpbmRpY2F0ZXMNCj4gPj4gPj4g Pj4+IHRoZQ0KPiA+PiA+PiA+Pj4gbWF4aW11bSBBZHZlcnRpc2VtZW50IEludGVydmFsDQo+ID4+ ID4+ID4+PiBHVj4gICAgICAgICAgPHQ+TWF4aW11bSBJUHY2IFJvdXRlciBBZHZlcnRpc2VtZW50 IEludGVydmFsID0gMzAwczwvdD4NCj4gPj4gPj4gPj4+DQo+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+ Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiA+PiA+Pj4gICAgQ09NTUVOVDoNCj4gPj4gPj4gPj4+DQo+ ID4+ID4+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+Pj4gICAgKiBT ZWN0aW9uIDQNCj4gPj4gPj4gPj4+DQo+ID4+ID4+ID4+PiAgICAtPiBJIHRoaW5rIHRleHQgaXMg bmVlZGVkIGhlcmUgdG8gaGFuZGxlIHRoZSBjYXNlIHdoZXJlIHRoZSBETlMNCj4gPj4gPj4gPj4+ IHNlcnZlciBpcw0KPiA+PiA+PiA+Pj4gICAgcHJvdmlkZWQgaW4gdGhlIFJBIGl0c2VsZiAgKFJG QzgxMDYpDQo+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+Pj4gICAgIkluIGFkZGl0aW9uIGl0IHdpbGwg dXNlIHN0YXRlbGVzcyBESENQdjYgdG8gZ2V0IHRoZSBJUHY2IGFkZHJlc3MNCj4gPj4gPj4gPj4+ IG9mIHRoZQ0KPiA+PiA+PiA+Pj4gRE5TDQo+ID4+ID4+ID4+PiAgICBzZXJ2ZXIiDQo+ID4+ID4+ ID4+Pg0KPiA+PiA+PiA+Pj4gICAgLT4gSSBhbSBub3Qgc3VyZSB3aGF0IGlzIHRoZSBtb3RpdmF0 aW9uIGZvciB0aGlzIHRleHQuDQo+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+Pj4gICAgImhvd2V2ZXIg aXQgU0hPVUxEIE5PVCB1c2Ugc3RhdGVmdWwgREhDUHY2IHRvIHJlY2VpdmUgYSBzZXJ2aWNlDQo+ ID4+ID4+ID4+PiBwcm92aWRlcg0KPiA+PiA+PiA+Pj4gICAgbWFuYWdlZCBJUHY2IGFkZHJlc3Mi DQo+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+Pj4gICAgLT4gVGhpcyB0ZXh0IHNlZW1zIGluY29ycmVj dA0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+ICAgICJkdWUgdG8gdGhlIEwtYml0IHNldCwgaXQg U0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljIHRvIHRoZSBGaXJzdCBIb3ANCj4gPj4gPj4gPj4+IFBy b3ZpZGVyDQo+ID4+ID4+ID4+PiAgICBSb3V0ZXIiDQo+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+Pj4g ICAgSSB0aGluayBpdCBzaG91bGQgYmUgdGhlIGV4YWN0IG9wcG9zaXRlLiBpLmUuIHNheSAqdW5z ZXQqIGluc3RlYWQNCj4gPj4gPj4gPj4+IG9mIHNldA0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+ ICAgICJkdWUgdG8gdGhlIEwtYml0IGJlaW5nIHVuc2V0LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRy YWZmaWMgdG8gdGhlDQo+ID4+ID4+ID4+PiBGaXJzdA0KPiA+PiA+PiA+Pj4gSG9wDQo+ID4+ID4+ ID4+PiAgICBQcm92aWRlciBSb3V0ZXIiDQo+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+Pj4gR1Y+IFdo YXQgYWJvdXQgdGhlIGZvbGxvd2luZyBtb2RpZmljYXRpb24gaW4gdGhlIHRleHQ6DQo+ID4+ID4+ ID4+Pg0KPiA+PiA+PiA+Pj4gT0xEOg0KPiA+PiA+PiA+Pj4gVGhlIGFyY2hpdGVjdGVkIHJlc3Vs dCBvZiBkZXNpZ25pbmcgdGhlIFJBIGFzIGRvY3VtZW50ZWQgYWJvdmUgaXMNCj4gPj4gPj4gPj4+ ICAgdGhhdCBlYWNoIFVFL3N1YnNjcmliZXIgZ2V0cyBpdHMgb3duIHVuaXF1ZSBJUHY2IHByZWZp eCBmb3Igd2hpY2ggaXQNCj4gPj4gPj4gPj4+ICAgY2FuIHVzZSBTTEFBQyBvciBhbnkgb3RoZXIg bWV0aG9kIHRvIHNlbGVjdCBpdHMgLzEyOCB1bmlxdWUgYWRkcmVzcy4NCj4gPj4gPj4gPj4+ICAg SW4gYWRkaXRpb24gaXQgd2lsbCB1c2Ugc3RhdGVsZXNzIERIQ1B2NiB0byBnZXQgdGhlIElQdjYg YWRkcmVzcyBvZg0KPiA+PiA+PiA+Pj4gICB0aGUgRE5TIHNlcnZlciwgaG93ZXZlciBpdCBTSE9V TEQgTk9UIHVzZSBzdGF0ZWZ1bCBESENQdjYgdG8gcmVjZWl2ZQ0KPiA+PiA+PiA+Pj4gICBhIHNl cnZpY2UgcHJvdmlkZXIgbWFuYWdlZCBJUHY2IGFkZHJlc3MuICBJZiB0aGUgVUUvc3Vic2NyaWJl cg0KPiA+PiA+PiA+Pj4gICBkZXNpcmVzIHRvIHNlbmQgYW55dGhpbmcgZXh0ZXJuYWwgaW5jbHVk aW5nIG90aGVyIFVFL3N1YnNjcmliZXINCj4gPj4gPj4gPj4+ICAgZGV2aWNlcyAoYXNzdW1pbmcg ZGV2aWNlIHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBlbmFibGVkIGFuZA0KPiA+PiA+PiA+ Pj4gICBzdXBwb3J0ZWQpLCB0aGVuLCBkdWUgdG8gdGhlIEwtYml0IHNldCwgaXQgU0hPVUxEIHNl bmQgdGhpcyB0cmFmZmljDQo+ID4+ID4+ID4+PiAgIHRvIHRoZSBGaXJzdCBIb3AgUHJvdmlkZXIg Um91dGVyLg0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4gPj4+IE5ldzoNCj4gPj4gPj4gPj4+IFRoZSBh cmNoaXRlY3RlZCByZXN1bHQgb2YgZGVzaWduaW5nIHRoZSBSQSBhcyBkb2N1bWVudGVkIGFib3Zl IGlzDQo+ID4+ID4+ID4+PiB0aGF0IGVhY2ggVUUvc3Vic2NyaWJlciBnZXRzIGl0cyBvd24gdW5p cXVlIElQdjYgcHJlZml4IGZvciB3aGljaCBpdA0KPiA+PiA+PiA+Pj4gY2FuIHVzZSBTTEFBQyBv ciBhbnkgb3RoZXIgbWV0aG9kIHRvIHNlbGVjdCBpdHMgLzEyOCB1bmlxdWUgYWRkcmVzcy4NCj4g Pj4gPj4gPj4+IEVpdGhlciBzdGF0ZWxlc3MgREhDUHY2IDx4cmVmIHRhcmdldD0iUkZDMzczNiI+ UkZDMzczNjwveHJlZj4gb3IgSVB2Ng0KPiA+PiA+PiA+Pj4gUm91dGVyIEFkdmVydGlzZW1lbnQg T3B0aW9ucyBmb3IgRE5TIENvbmZpZ3VyYXRpb24NCj4gPj4gPj4gPj4+IDx4cmVmIHRhcmdldD0i UkZDODEwNiI+UkZDODEwNjwveHJlZj4gY2FuIGJlIHVzZWQgdG8gZ2V0IHRoZQ0KPiA+PiA+PiA+ Pj4gSVB2NiBhZGRyZXNzIG9mIHRoZSBETlMgc2VydmVyLiBJZiB0aGUgVUUvc3Vic2NyaWJlciBk ZXNpcmVzIHRvIHNlbmQNCj4gPj4gPj4gPj4+IGFueXRoaW5nIGV4dGVybmFsIGluY2x1ZGluZyBv dGhlciBVRS9zdWJzY3JpYmVyIGRldmljZXMgKGFzc3VtaW5nDQo+ID4+ID4+ID4+PiBkZXZpY2UN Cj4gPj4gPj4gPj4+IHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBlbmFibGVkIGFuZCBzdXBw b3J0ZWQpLCB0aGVuLCBkdWUgdG8gdGhlDQo+ID4+ID4+ID4+PiBMLWJpdCBiZWluZyB1bnNldCwg aXQgU0hPVUxEIHNlbmQgdGhpcyB0cmFmZmljIHRvIHRoZSBGaXJzdCBIb3ANCj4gPj4gPj4gPj4+ IFByb3ZpZGVyDQo+ID4+ID4+ID4+PiBSb3V0ZXIuPC90Pg0KPiA+PiA+PiA+Pj4NCj4gPj4gPj4g Pj4+DQo+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+Pj4gS2luZCBSZWdhcmRzLA0KPiA+PiA+PiA+Pj4g Ry8NCj4gPj4gPj4gPj4+DQo+ID4+ID4+ID4+Pg0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+Pg0KPiA+ PiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+PiAtLQ0KPiA+PiA+PiBJ IGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91 c2x5IGEgYmFkDQo+ID4+ID4+IGlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLg0KPiA+PiA+PiBUaGlz IGlzIGxpa2UgcHV0dGluZyByYWJpZCB3ZWFzZWxzIGluIHlvdXIgcGFudHMsIGFuZCBsYXRlciBl eHByZXNzaW5nDQo+ID4+ID4+IHJlZ3JldCBhdCBoYXZpbmcgY2hvc2VuIHRob3NlIHBhcnRpY3Vs YXIgcmFiaWQgd2Vhc2VscyBhbmQgdGhhdCBwYWlyDQo+ID4+ID4+IG9mIHBhbnRzLg0KPiA+PiA+ PiAgICAtLS1tYWYNCj4gPj4gPj4NCj4gPj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4gPj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+ID4+ IHY2b3BzQGlldGYub3JnDQo+ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCj4gPj4gPg0KPiA+PiA+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IC0tDQo+ ID4+IEkgZG9uJ3QgdGhpbmsgdGhlIGV4ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBv YnZpb3VzbHkgYSBiYWQNCj4gPj4gaWRlYSBpbiB0aGUgZmlyc3QgcGxhY2UuDQo+ID4+IFRoaXMg aXMgbGlrZSBwdXR0aW5nIHJhYmlkIHdlYXNlbHMgaW4geW91ciBwYW50cywgYW5kIGxhdGVyIGV4 cHJlc3NpbmcNCj4gPj4gcmVncmV0IGF0IGhhdmluZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciBy YWJpZCB3ZWFzZWxzIGFuZCB0aGF0IHBhaXINCj4gPj4gb2YgcGFudHMuDQo+ID4+ICAgIC0tLW1h Zg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPj4gdjZvcHNAaWV0Zi5vcmcNCj4gPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiANCj4gDQo+IA0K PiAtLQ0KPiBJIGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3 YXMgb2J2aW91c2x5IGEgYmFkDQo+IGlkZWEgaW4gdGhlIGZpcnN0IHBsYWNlLg0KPiBUaGlzIGlz IGxpa2UgcHV0dGluZyByYWJpZCB3ZWFzZWxzIGluIHlvdXIgcGFudHMsIGFuZCBsYXRlciBleHBy ZXNzaW5nDQo+IHJlZ3JldCBhdCBoYXZpbmcgY2hvc2VuIHRob3NlIHBhcnRpY3VsYXIgcmFiaWQg d2Vhc2VscyBhbmQgdGhhdCBwYWlyDQo+IG9mIHBhbnRzLg0KPiAgICAtLS1tYWYNCg0K From nobody Mon Sep 11 17:59:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429E0124F57 for ; Mon, 11 Sep 2017 17:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrsFGqwx6pQW for ; Mon, 11 Sep 2017 17:59:06 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A240A124B18 for ; Mon, 11 Sep 2017 17:59:06 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id y29so15631943pff.0 for ; Mon, 11 Sep 2017 17:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=3uLsfFhSgx6kWPfm3aRRQRMIv4WFDCPbSKiNOAprIQo=; b=DYgJUjw6zNSFyYVJs9xNVMRRhLSxHz1SOSj9Yja0ZzGwaDSSjBaqjTKwTz2PItLW6c umcmdAO8uZhyZngGUPvlfzUQgC/sNerZxILbWGPy3IMOmKgUZpOXwvO2dRUVVFcPA8oi nfdF5A2M9Ir8unbYv/+NJVDOs1HRY3rjzLQzgmQSr3AaE5t+rtp+jxXw9fDW9BI31J3S Vu5ueSjvqaYuHBPRYd0NzcBZgJEJIInppNUL4CKyh746VxhI4bzDAHxdOmOdBh8T1Mcu 7HTKUTb78nZ5zKHIhRescU1cx+Kqtv+EHs4h//01SJH0RZdIVW9GEU65fgLPVN1e0qrS 82GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=3uLsfFhSgx6kWPfm3aRRQRMIv4WFDCPbSKiNOAprIQo=; b=rlzTuMkCy7rpkQNewxNNG7L6nkb2SUfvOWFblDRKdcFi4FiJy36V7BwLFa+rLzSLoj vLbYhE5Pl5QqFOUuxQO9SAq4JbQP3WgHZGRapK2X2+cwXm+M5bJPe7bipE7+SZlPYUBk J1rBgFc5j37A4kIYmZOM3LBS+dws+Txrd0XC6oS+uvUQDz99CiU/MeXunRcN9142fG7d kdC6+fFPMHRUaKiHfmAuaXBbQfKaL6XMZkMv7dlwRQyq7enobOmybIe9hC1x/c8vRcWl slKswkcQiWJP9/W7qPS1Oi/dw740ijq8F86B90ngt4FDIpPN6uUJEKF5dmnYcBV2nyhP 71Lg== X-Gm-Message-State: AHPjjUhhvhjdagutEauPSE6OwIQGjs1x8I5qTg5R2xBrlL8H1dYKfhH7 E9h+kjQzvuhZhvaD X-Google-Smtp-Source: ADKCNb6leGKvlRp0RZ52PtJXdBbe1SERCvy5JFnCTVEkCWR9x54Hj1vVfot0ygVmOHYrcSPJ6bhXeg== X-Received: by 10.98.224.136 with SMTP id d8mr13087326pfm.97.1505177945679; Mon, 11 Sep 2017 17:59:05 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 76sm19126479pfp.158.2017.09.11.17.59.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Sep 2017 17:59:04 -0700 (PDT) To: Philip Homburg , v6ops@ietf.org References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Tue, 12 Sep 2017 12:59:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 00:59:08 -0000 On 12/09/2017 08:56, Philip Homburg wrote: >>> That would break local validating resolvers. >> >> Can you explain that a bit? Since the record concerned is useless, >> why do we care whether it validates? Or would this somehow affect the >> validation of AAAA records for the same domain? > > It is hard to tell what is going to happen when validation fails. That's > local policy. > > One thing that may happen is that the validating resolver will consider the > local resolver in the CPE to be broken and sets up a TLS (or similar) > connection to a remote resolver, by passing all of this filtering. > >> In other words, how is this different from a case with IPv4 connectivity >> when there is in fact no A record? > > The DNS record types available for a domain name are listed in the NSEC/NSEC3 > record. > > So if the query for 'A' results in a empty RR then the validating resolver > will look for a NSEC/NSEC3 record that confirms that this is indeed the case. Ah, I see. That is a problem. >>> I guess the proper way to solve the issue of only local IPv4 connectivity >>> is to have a DHCP option that lists which IPv4 prefixes are reachable. >>> >> That won't work for legacy hosts that don't know about that option, and >> we really need to allow for legacy hosts. > > I assume that in the future there will be systems that can talk IPv6 and need > to know what IPv4 resources are locally available. Those systems would > benefit from a new DHCP option. > > Legacy systems that only talk IPv4 don't really care. They are limited to > whatever is locally available anyhow. The thing is that if a home network includes a Windows 98 client and a Windows 10 client, and has no WAN IPv4 service, there will be dual stack sites that are accessible from Windows 10 and unreachable from Windows 98. That translates into help desk calls. I see a bright future for 464XLAT. Brian From nobody Tue Sep 12 00:14:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F011332CD for ; Tue, 12 Sep 2017 00:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 9fWsuozcnUZM for ; Tue, 12 Sep 2017 00:14:14 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2EF1332CA for ; Tue, 12 Sep 2017 00:14:14 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id j141so41082130ioj.4 for ; Tue, 12 Sep 2017 00:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KzSjsBJRHa+d/ATW40SrWg1pTiWRTAsO3/Ypw78dZKU=; b=v4RaMk6rwMHrENC6OPiXEbDOo/jfpr7N+yKDHLRf53d6tm/iH/+onBxzZ2jhO3PqR0 ViA4HiUZrkyvM86NyRdaLByWAtJgGhd8CXq53bNVAU+780/amLEe9PiyT0RjEWa3RjSb 34JgI57bRm6daf8HtdjT6TiKOi9mrhMcb+7tqwHp9KW4Mqw87Uk7/i5bSecb4QwaN9un kV9QeKflD566FnQZ98YrD07uELQDDCCHNpKbZaqw1quE5Dt0DAZ+mvWxhn8/77t2Y7uw fwCOnF8Syho+YNDp8yoowoECduhb8lcaMJrXrqIHVbqDQMyaxwHF8C5KDr6fZgMYjeeZ UWFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KzSjsBJRHa+d/ATW40SrWg1pTiWRTAsO3/Ypw78dZKU=; b=lkbV9gv04NBbBKJznP0Oy7UOYhQbLpxCpbLVTDds14s/zyVYWg1xPqlavkZY+J5Dh/ V87QpInhAhhAzKrgLEluup9fbn99IrMZ3sXHi8/Jrc9mPDLQ8jYAAi/fEc9wRMu7WOKc MpRZc9l3941xHIO5L88qdPrYBa29tr3Y6/IPQc0br9zAU65pPu3hsseHpvNeIocrQ1eZ l/kVTlQmaDgwP6TDAOC6vydjy3CL7XQhgxgd9ougQwK4BNwntLzpcbVbjyDzZXnI3eZE TE8Oio0VLAXNul5pwpI/3haC8QbKklNl8GR8tIk6kKjoM0TcTKBSC9IzTf45/aTTuBzF XTpg== X-Gm-Message-State: AHPjjUgeXoJCasfEwNfW9Q9EJJer2Qon01uJ0RTMvYk63ygJ1YkPVnhM kdTb/0G4pUvaQ9d4ayPKD10f0wfdID9q X-Google-Smtp-Source: AOwi7QDVipSAWZTD75aA9KsNtMOslS7lzhPRq8d+DTD4ZMPuZ9ONvyErwSMz6NwO/WeS1MkIVvYqfFc5pQ5HY77lKUU= X-Received: by 10.107.175.10 with SMTP id y10mr13589441ioe.222.1505200453621; Tue, 12 Sep 2017 00:14:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.20.11 with HTTP; Tue, 12 Sep 2017 00:13:52 -0700 (PDT) In-Reply-To: <31e926886e01457fb84efd165dd000c5@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <5ec52c86f18e453b8191679afb7ec1b4@XCH15-06-08.nw.nos.boeing.com> <31e926886e01457fb84efd165dd000c5@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Tue, 12 Sep 2017 16:13:52 +0900 Message-ID: To: "Templin, Fred L" Cc: Warren Kumari , Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Content-Type: multipart/alternative; boundary="001a11449b2c5afcaa0558f8ca33" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 07:14:16 -0000 --001a11449b2c5afcaa0558f8ca33 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 12, 2017 at 7:43 AM, Templin, Fred L wrote: > > > I agree. "Shared network" is not an RFC4861 supported link type. The > > > supported link types are given in RFC4861 Sections 2.2 and 3.2, and > this > > > document needs to observe the RFC4861 terminology. > > > > I do not agree with you that it needs to use RFC4861 terminology > > That surprises me. This document is about an interpretation of RFC4861, > and the RFC4861 terminology should apply. This document is not an interpretation of 4861 and is under no such obligations. In any case - RFC 4861 section 2.2 is clearly not a taxonomy of link types, it's a list of link *properties*. Example: "variable MTU" (which is one of the bullets of that section) is not a link type. --001a11449b2c5afcaa0558f8ca33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Sep 12, 2017 at 7:43 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:
> > I agree. "Shared network= " is not=C2=A0 an RFC4861 supported link type. The
> > supported link types are given in RFC4861 Sections 2.2 and 3.2, a= nd this
> > document needs to observe the RFC4861 terminology.
>
> I do not agree with you that it needs to use RFC4861 terminology

That surprises me. This document is about an interpretation of = RFC4861,
and the RFC4861 terminology should apply.

T= his document is not an interpretation of 4861 and is under no such obligati= ons. In any case - RFC 4861 section 2.2 is clearly not a taxonomy of link t= ypes, it's a list of link *properties*. Example: "variable MTU&quo= t; (which is one of the bullets of that section) is not a link type.
<= /div>
--001a11449b2c5afcaa0558f8ca33-- From nobody Tue Sep 12 02:14:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5551331B0 for ; Tue, 12 Sep 2017 02:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SYSADMIN=1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doC5RjEOMef4 for ; Tue, 12 Sep 2017 02:14:39 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC1E133011 for ; Tue, 12 Sep 2017 02:14:38 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1drhHB-0000FfC; Tue, 12 Sep 2017 11:14:37 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> In-reply-to: Your message of "Tue, 12 Sep 2017 12:59:02 +1200 ." Date: Tue, 12 Sep 2017 11:14:36 +0200 Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 09:14:41 -0000 >The thing is that if a home network includes a Windows 98 client and a >Windows 10 client, and has no WAN IPv4 service, there will be dual stack >sites that are accessible from Windows 10 and unreachable from Windows 98. >That translates into help desk calls. > >I see a bright future for 464XLAT. 464xlat or one of the many other ways of tunneling IPv4 over IPv6. But I assumed that sunset is when there no (global) IPv4 access at all. What I am now wondering about is a form of NAT46/DNS46. I.e. host sends an 'A' query to a DNS resolver, DNS resolver does a 'AAAA' look up and maps the resulting IPv6 address to an address in 10.0.0.0/8. And then the NAT46 module would translate traffic. This would allow legacy hosts to connect to the IPv6 internet. From nobody Tue Sep 12 02:47:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79D413334E for ; Tue, 12 Sep 2017 02:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POkwIjzxdrbO for ; Tue, 12 Sep 2017 02:47:38 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E2A13217D for ; Tue, 12 Sep 2017 02:47:38 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 97489B0; Tue, 12 Sep 2017 11:47:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1505209655; bh=0mpldzLYPEP+8Wt6TBWSKil6I1noCAYHOmc1yzgFFC4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=hQtawujzQ8Z/jlrI2nA0K1cCH7PItrdgD1PIjbTwahP7LC+l/qftobbjCk2t6wKO8 3SyJZ4aUyw161qx5bVQOg9QotIPgcv1rhxYshaIA4MfcCGxvz94+YVuKp0Mf1XJG+T Th6lNftRoN7sq3T3uteKqBYIRQApeYDBXeOrA1rk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9556CAF; Tue, 12 Sep 2017 11:47:35 +0200 (CEST) Date: Tue, 12 Sep 2017 11:47:35 +0200 (CEST) From: Mikael Abrahamsson To: Philip Homburg cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 09:47:41 -0000 On Tue, 12 Sep 2017, Philip Homburg wrote: > 464xlat or one of the many other ways of tunneling IPv4 over IPv6. But I > assumed that sunset is when there no (global) IPv4 access at all. Sure, but I also think that it's a viable thing to contemplate what host support there should be to access legacy IPv4 resources over an IPv6 only access. In 10 years or something I can see IPv6 only access being a lot more common compared to today, but that long tail is ... long. So having hosts being able to access IPv4 resources using for instance NAT64+DNS64 for older applications will be one component here that will make that transistion easier. > What I am now wondering about is a form of NAT46/DNS46. I.e. host sends > an 'A' query to a DNS resolver, DNS resolver does a 'AAAA' look up and > maps the resulting IPv6 address to an address in 10.0.0.0/8. And then > the NAT46 module would translate traffic. > > This would allow legacy hosts to connect to the IPv6 internet. There has been work done in this space. I think this function would have to be done very close to the user, perhaps even in the HGW, or perhaps even in the device itself (if it has legacy applications that use the old IPv4 only socket API). On for instance iOS I see it as very viable with the approach Apple has chosen by just mandating IPv6 to work. This can be done in a few years, applications are revved quite often or they're abandoned (just see now with 32bit applications being abandoned on iOS, it's A LOT of applications that will not work anymore). People seem to be fine with this. On PCs, there is an expectation to be able to install older applications, and applications that are 10-15 years old sometimes. So I see the need to support these older applications, and I guess the only way to do that is either do NAT46 in the host or if available in the network, NAT64+464XLAT in the host. The NAT46 approach would work even when not speaking to a DNS64 resolver, because this would be internal to the host itself. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Sep 12 07:39:57 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9C6127517; Tue, 12 Sep 2017 07:39:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk CC: Ron Bonica , v6ops@ietf.org, rbonica@juniper.net, v6ops-chairs@ietf.org, draft-ietf-v6ops-rfc6555bis@ietf.org, warren@kumari.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150522719582.4692.5662383794098533190.idtracker@ietfa.amsl.com> Date: Tue, 12 Sep 2017 07:39:55 -0700 Archived-At: Subject: [v6ops] Last Call: (Happy Eyeballs Version 2: Better Connectivity Using Concurrency) to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:39:56 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Happy Eyeballs Version 2: Better Connectivity Using Concurrency' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-09-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Many communication protocols operated over the modern Internet use host names. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a higher chance of establishing a connection sooner. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Sep 12 07:43:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407A4127517; Tue, 12 Sep 2017 07:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UtkJUAv47DM; Tue, 12 Sep 2017 07:43:26 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DAE132332; Tue, 12 Sep 2017 07:43:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8CEhO8Z049471; Tue, 12 Sep 2017 07:43:25 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8CEhJ93049370 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 12 Sep 2017 07:43:19 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 12 Sep 2017 07:43:18 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 12 Sep 2017 07:43:18 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: Warren Kumari , Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTKaTY2SQFbjmM502TqtM/gaCiM6KtwdeAgAFRDQCAAPq0kIAAp1cA//+S9hCAAQeJAIAABEWQ Date: Tue, 12 Sep 2017 14:43:18 +0000 Message-ID: <80ba83ecbb364ae4858679851f51f720@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <5ec52c86f18e453b8191679afb7ec1b4@XCH15-06-08.nw.nos.boeing.com> <31e926886e01457fb84efd165dd000c5@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_80ba83ecbb364ae4858679851f51f720XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 14:43:28 -0000 --_000_80ba83ecbb364ae4858679851f51f720XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KQ29tbWVudHMgYmVsb3c6DQoNCkZyZWQNCg0KRnJvbTogTG9yZW56byBD b2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDogVHVlc2RheSwgU2VwdGVt YmVyIDEyLCAyMDE3IDEyOjE0IEFNDQpUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tPg0KQ2M6IFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0PjsgU3Vy ZXNoIEtyaXNobmFuIDxzdXJlc2gua3Jpc2huYW5AZ21haWwuY29tPjsgdjZvcHNAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3Y2b3BzXSBTdXJlc2ggS3Jpc2huYW4ncyBEaXNjdXNzIG9uIGRyYWZ0LWll dGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA3OiAod2l0aCBESVNDVVNTIGFu ZCBDT01NRU5UKQ0KDQpPbiBUdWUsIFNlcCAxMiwgMjAxNyBhdCA3OjQzIEFNLCBUZW1wbGluLCBG cmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb20+PiB3cm90ZToNCj4gPiBJIGFncmVlLiAiU2hhcmVkIG5ldHdvcmsiIGlzIG5vdCAg YW4gUkZDNDg2MSBzdXBwb3J0ZWQgbGluayB0eXBlLiBUaGUNCj4gPiBzdXBwb3J0ZWQgbGluayB0 eXBlcyBhcmUgZ2l2ZW4gaW4gUkZDNDg2MSBTZWN0aW9ucyAyLjIgYW5kIDMuMiwgYW5kIHRoaXMN Cj4gPiBkb2N1bWVudCBuZWVkcyB0byBvYnNlcnZlIHRoZSBSRkM0ODYxIHRlcm1pbm9sb2d5Lg0K Pg0KPiBJIGRvIG5vdCBhZ3JlZSB3aXRoIHlvdSB0aGF0IGl0IG5lZWRzIHRvIHVzZSBSRkM0ODYx IHRlcm1pbm9sb2d5DQpUaGF0IHN1cnByaXNlcyBtZS4gVGhpcyBkb2N1bWVudCBpcyBhYm91dCBh biBpbnRlcnByZXRhdGlvbiBvZiBSRkM0ODYxLA0KYW5kIHRoZSBSRkM0ODYxIHRlcm1pbm9sb2d5 IHNob3VsZCBhcHBseS4NCg0KVGhpcyBkb2N1bWVudCBpcyBub3QgYW4gaW50ZXJwcmV0YXRpb24g b2YgNDg2MSBhbmQgaXMgdW5kZXIgbm8gc3VjaCBvYmxpZ2F0aW9ucy4NCg0KDQrDmCAgVGhlIGRv Y3VtZW50IG1ha2VzIGFuIGludGVycHJldGF0aW9uIG9mIHdoYXQgdGhlIEE9MTsgTD0wIGJpdCBh c3NpZ25tZW50cw0KDQrDmCAgZm9yIFBJT3MgbWVhbnMgd2l0aGluIHRoaXMgY29udGV4dC4gVGhh dCBtYWtlcyBpdCBhbiBpbnRlcnByZXRhdGlvbiBvZiBSRkM0ODYxLg0KDQoNCkluIGFueSBjYXNl IC0gUkZDIDQ4NjEgc2VjdGlvbiAyLjIgaXMgY2xlYXJseSBub3QgYSB0YXhvbm9teSBvZiBsaW5r IHR5cGVzLCBpdCdzIGEgbGlzdCBvZiBsaW5rICpwcm9wZXJ0aWVzKi4gRXhhbXBsZTogInZhcmlh YmxlIE1UVSIgKHdoaWNoIGlzIG9uZSBvZiB0aGUgYnVsbGV0cyBvZiB0aGF0IHNlY3Rpb24pIGlz IG5vdCBhIGxpbmsgdHlwZS4NCg0KDQrDmCAgICBTZWN0aW9uIDIuMiBpcyB0aXRsZWQ6IOKAnExp bmsgVHlwZXPigJ0gYW5kIFNlY3Rpb24gMy4yIGlzIHRpdGxlZDog4oCcU3VwcG9ydGVkIExpbmsg VHlwZXPigJ0NCg0Kw5ggICAgVGhlIHR5cGUgZGVzY3JpcHRpb25zIGFyZSB1bmRlcnN0b29kIHRv IGxpbmUgdXAgd2l0aCBhY3R1YWwgSVAgZGF0YSBsaW5rcy4gRm9yDQoNCsOYICAgIGV4YW1wbGUs IEV0aGVybmV0IGFuZCBXaUZpIGFyZSBleGFtcGxlcyBvZiBtdWx0aWNhc3QtY2FwYWJsZSBsaW5r cywgdHVubmVsDQoNCsOYICAgIHZpcnR1YWwgbGlua3MgYXJlIGFuIGV4YW1wbGUgb2YgTkJNQSBs aW5rcywgZXRjLiBUaGVzZSBhcmUgdGhlIGxpbmsgdHlwZXMgdGhhdA0KDQrDmCAgICBJUHY2IE5E IG9wZXJhdGVzIG92ZXIsIGFuZCBoYXZlIGJlZW4gc3BlY2lmaWVkIHRoYXQgd2F5IHNpbmNlIFJG QzE5NzAuDQo= --_000_80ba83ecbb364ae4858679851f51f720XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDI4ODg2NTA7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4OTE3Nzk5NzYgLTc1NDE3NDcy MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+D mDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgTG9yZW56byw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNvbW1lbnRzIGJlbG93OjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExvcmVuem8gQ29saXR0aSBb bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBT ZXB0ZW1iZXIgMTIsIDIwMTcgMTI6MTQgQU08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4sIEZyZWQg TCAmbHQ7RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFdhcnJl biBLdW1hcmkgJmx0O3dhcnJlbkBrdW1hcmkubmV0Jmd0OzsgU3VyZXNoIEtyaXNobmFuICZsdDtz dXJlc2gua3Jpc2huYW5AZ21haWwuY29tJmd0OzsgdjZvcHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYt djZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdjZvcHNdIFN1cmVzaCBLcmlzaG5hbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0 Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDc6ICh3aXRoIERJU0NVU1MgYW5k IENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBTZXAgMTIsIDIwMTcgYXQgNzo0MyBBTSwgVGVt cGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0OyAmZ3Q7IEkgYWdyZWUu ICZxdW90O1NoYXJlZCBuZXR3b3JrJnF1b3Q7IGlzIG5vdCZuYnNwOyBhbiBSRkM0ODYxIHN1cHBv cnRlZCBsaW5rIHR5cGUuIFRoZTxicj4NCiZndDsgJmd0OyBzdXBwb3J0ZWQgbGluayB0eXBlcyBh cmUgZ2l2ZW4gaW4gUkZDNDg2MSBTZWN0aW9ucyAyLjIgYW5kIDMuMiwgYW5kIHRoaXM8YnI+DQom Z3Q7ICZndDsgZG9jdW1lbnQgbmVlZHMgdG8gb2JzZXJ2ZSB0aGUgUkZDNDg2MSB0ZXJtaW5vbG9n eS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGRvIG5vdCBhZ3JlZSB3aXRoIHlvdSB0aGF0IGl0IG5l ZWRzIHRvIHVzZSBSRkM0ODYxIHRlcm1pbm9sb2d5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBzdXJwcmlzZXMgbWUuIFRoaXMgZG9jdW1l bnQgaXMgYWJvdXQgYW4gaW50ZXJwcmV0YXRpb24gb2YgUkZDNDg2MSw8YnI+DQphbmQgdGhlIFJG QzQ4NjEgdGVybWlub2xvZ3kgc2hvdWxkIGFwcGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2N1bWVudCBpcyBub3Qg YW4gaW50ZXJwcmV0YXRpb24gb2YgNDg2MSBhbmQgaXMgdW5kZXIgbm8gc3VjaCBvYmxpZ2F0aW9u cy48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGlu Z3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5UaGUgZG9jdW1lbnQgbWFrZXMgYW4gaW50ZXJwcmV0YXRpb24gb2Ygd2hhdCB0aGUgQT0xOyBM PTAgYml0IGFzc2lnbm1lbnRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmZvciBQSU9zIG1lYW5zIHdpdGhpbiB0aGlzIGNvbnRleHQu IFRoYXQgbWFrZXMgaXQgYW4gaW50ZXJwcmV0YXRpb24gb2YgUkZDNDg2MS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkluIGFueSBjYXNlIC0gUkZDIDQ4NjEgc2VjdGlvbiAyLjIgaXMgY2xlYXJseSBub3Qg YSB0YXhvbm9teSBvZiBsaW5rIHR5cGVzLCBpdCdzIGEgbGlzdCBvZiBsaW5rICpwcm9wZXJ0aWVz Ki4gRXhhbXBsZTogJnF1b3Q7dmFyaWFibGUgTVRVJnF1b3Q7ICh3aGljaCBpcyBvbmUgb2YgdGhl IGJ1bGxldHMgb2YgdGhhdCBzZWN0aW9uKSBpcyBub3QgYSBsaW5rIHR5cGUuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gMi4yIGlzIHRpdGxl ZDog4oCcTGluayBUeXBlc+KAnSBhbmQgU2VjdGlvbiAzLjIgaXMgdGl0bGVkOiDigJxTdXBwb3J0 ZWQgTGluayBUeXBlc+KAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50OjBpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgdHlwZSBk ZXNjcmlwdGlvbnMgYXJlIHVuZGVyc3Rvb2QgdG8gbGluZSB1cCB3aXRoIGFjdHVhbCBJUCBkYXRh IGxpbmtzLiBGb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZXhhbXBsZSwgRXRoZXJu ZXQgYW5kIFdpRmkgYXJlIGV4YW1wbGVzIG9mIG11bHRpY2FzdC1jYXBhYmxlIGxpbmtzLCB0dW5u ZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dmlydHVhbCBsaW5rcyBhcmUgYW4gZXhh bXBsZSBvZiBOQk1BIGxpbmtzLCBldGMuIFRoZXNlIGFyZSB0aGUgbGluayB0eXBlcyB0aGF0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklQdjYgTkQgb3BlcmF0ZXMgb3ZlciwgYW5kIGhh dmUgYmVlbiBzcGVjaWZpZWQgdGhhdCB3YXkgc2luY2UgUkZDMTk3MC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_80ba83ecbb364ae4858679851f51f720XCH150608nwnosboeingcom_-- From nobody Tue Sep 12 11:22:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A251132ED3 for ; Tue, 12 Sep 2017 11:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhq-hMTqOpAW for ; Tue, 12 Sep 2017 11:21:52 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F519132EC0 for ; Tue, 12 Sep 2017 11:21:52 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 6so511641itl.1 for ; Tue, 12 Sep 2017 11:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rt8UAoPj9GL/WPhgBlkNRGQoxWbH1PIdZC9iyPnv1ts=; b=BBvucKudbrynz2WZDjipCEZheBIfAD5cth2WB2iZCMkWI9MRyOnxWV5h2iu9jxnE/N y5boWM6D9UrGKAVawjlEYfTmbmE5M4fyC8+A8CsrsQSapAvTe1kYtJr2dE7UD7jAbJXO DPX4JJaa9qH7ErbCPz851QicWl8mw6iHKRGLcYtQtjDQApD8s//MqX84bBjm3CIo6oD3 7y6qCA+z+ac5wIb+OrZuIzYbb8Xe3SBHHsZU8b6Kmb9UFZ6npNCYB78pgtJSmljsOzOX /MpQbMWGCUc5ptxM/QVy9j5XAgb85OA4GPnFd2W9VjOMMwoyxDROp+GU2M383cTtdqxV VpDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Rt8UAoPj9GL/WPhgBlkNRGQoxWbH1PIdZC9iyPnv1ts=; b=LF/jl9DYG+U7YGpAvW7/+Vg6NKBl0YRkqxeoocEtRFoGg9hjeYO9XDmcT/prjfORtm XVMEvQQywEZa6S+c20m1a+NcvC8W5cDxBcDwHPLL8Qgc3RIhqP2Nw0UFgw+FM7KGdnYl yDxM+B57MVXF45gtZlbplQ/zum/6dC/7rvQlcsdnJWQUD29YIHj1bstVKP2Zk82LXTuS 6ctNuCe9DXPxb5NkrtYEitVu5o+fZJu4RXHdZrKEPLX3nn6asx5for3R+/A5jMfX5CtI 1OmxKNYrNa54STfMjnfIbLQCpPjiJHhuIZsN6/Md6DvSE1OekJxpjxSGTMQTKnDnA0GJ A5UA== X-Gm-Message-State: AHPjjUhb4Je7SK5nQT1uCc7Hnp21guRgIOcZGc1iTGLEX2OtMcyglv1a 33ry8jO/X7TLfsXNQLF2vgqBeLi86rMeYG7l6SaCMQ== X-Google-Smtp-Source: AOwi7QDBHZagYx5Zw0qalinh/Ff4KyWbvJYjYRw6ew7Q4bL09u6OD66Su6UPd5vozJT1mSrr1eanFLomn8lmpubpKf0= X-Received: by 10.36.121.85 with SMTP id z82mr641581itc.87.1505240511480; Tue, 12 Sep 2017 11:21:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.185.9 with HTTP; Tue, 12 Sep 2017 11:21:30 -0700 (PDT) In-Reply-To: <80ba83ecbb364ae4858679851f51f720@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <5ec52c86f18e453b8191679afb7ec1b4@XCH15-06-08.nw.nos.boeing.com> <31e926886e01457fb84efd165dd000c5@XCH15-06-08.nw.nos.boeing.com> <80ba83ecbb364ae4858679851f51f720@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Wed, 13 Sep 2017 03:21:30 +0900 Message-ID: To: "Templin, Fred L" Cc: Warren Kumari , Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Content-Type: multipart/alternative; boundary="001a114ab790fdb9f40559021db3" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 18:21:54 -0000 --001a114ab790fdb9f40559021db3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 12, 2017 at 11:43 PM, Templin, Fred L wrote: > > In any case - RFC 4861 section 2.2 is clearly not a taxonomy of link > types, it's a list of link *properties*. Example: "variable MTU" (which i= s > one of the bullets of that section) is not a link type. > > > > =C3=98 Section 2.2 is titled: =E2=80=9CLink Types=E2=80=9D and Section= 3.2 is titled: > =E2=80=9CSupported Link Types=E2=80=9D > > =C3=98 The type descriptions are understood to line up with actual IP = data > links. For > > =C3=98 example, Ethernet and WiFi are examples of multicast-capable li= nks, > tunnel > > =C3=98 virtual links are an example of NBMA links, etc. These are the = link > types that > > =C3=98 IPv6 ND operates over, and have been specified that way since > RFC1970. > You're not actually suggesting that "variable MTU" is a link type, are you? --001a114ab790fdb9f40559021db3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Sep 12, 2017 at 11:43 PM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:

In any case - RFC 4861 section 2.2 is clearly not a = taxonomy of link types, it's a list of link *properties*. Example: &quo= t;variable MTU" (which is one of the bullets of that section) is not a= link type.

=C2=A0

=C3=98=C2=A0= =C2=A0=C2=A0 Section 2.2 is titled: =E2=80=9C= Link Types=E2=80=9D and Section 3.2 is titled: =E2=80=9CSupported Link Type= s=E2=80=9D

=C3=98=C2=A0= =C2=A0=C2=A0 The type descriptions are unders= tood to line up with actual IP data links. For

=C3=98=C2=A0= =C2=A0=C2=A0 example, Ethernet and WiFi are e= xamples of multicast-capable links, tunnel

=C3=98=C2=A0= =C2=A0=C2=A0 virtual links are an example of = NBMA links, etc. These are the link types that

=C3=98=C2=A0= =C2=A0=C2=A0 IPv6 ND operates over, and have = been specified that way since RFC1970.

You'= ;re not actually suggesting that "variable MTU" is a link type, a= re you?
--001a114ab790fdb9f40559021db3-- From nobody Tue Sep 12 11:56:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22353132ECE for ; Tue, 12 Sep 2017 11:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87An_cKkkdKp for ; Tue, 12 Sep 2017 11:56:10 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1AA113293A for ; Tue, 12 Sep 2017 11:56:10 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id i50so27749331qtf.0 for ; Tue, 12 Sep 2017 11:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Dn4VH8+1xCyCMIEEhso2ALdUMyCTORXgc6kWUsWC48k=; b=hAjThPNnDJBhTf74DW6zNkRAtEacdTtYLHNtAAhQ31i/amn6mCwlCyQMcJS9Fn8e7U bKkOqdjR+RmrCISxVRJp0trchIKlxQaYV9G7X82Qz5FCz5dY107OcA8YXcDZpBwm6UB/ WSRBhaXeaC1v6Px/JV0Um2J6UmnA1JRub9ta7d/V6zPAOrpl0PcIwz0KMcagRLQoYW5x or8MZmpKBkftcO9bLEBNdQVXakML9PK+vn5XBJ5yUCFmG846xr5FJg+XBFiXLU4O1aND ojyOp5v8OJsBc5llrBwnfcAPGP+qExd7zWMZ605Can3F48CecXfBz5C688Nwv4npZePB 2u6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Dn4VH8+1xCyCMIEEhso2ALdUMyCTORXgc6kWUsWC48k=; b=oFt/Ib5P+hRGDE49eROIaA83AywH/DwIS98XZ47kXKtzo5T0bjzPuZ5IIZKDnLjauz s1xt9Ce3QQ/9cPNGSu8m4ktkmzMrr/yOm8L3ph57gCwj62N/qzyzzj9emCbGCKZZDelH 6E+32wZr/Oi9Qx8D9T1eNBonfEp0zEYZwZ3nmsJH+OS0DO1j8xSQbj0ySxzpwHsPkzyh TMUiWF39Mj/sa0GrhfC/+fY8La3zQfCAqLvNJLlDHahfm9yg9SNS9HKb8ywouOtLuzBv SAA2S07IuKYyX3pRKtko7rEtqMDu8I3DRi0w8MviAG8fdn/aoUJfr0Swur3xdLEotjSi QTBA== X-Gm-Message-State: AHPjjUjplWXzl9HZFAQWQCD+j0NUa53HS4dcYZoPViHBKxqxscZmNsKT C3lAPS6buF/kKwIsuY1fAXsMvL+uiQ== X-Google-Smtp-Source: AOwi7QCOzMY8D7L8ajvZCTy8es7v/VnPW/Gf+54MHxgiTmtJ41WmMTZVQ7T+02d0hA7c425Tz3IMpYy3+DRdtGStObs= X-Received: by 10.237.56.67 with SMTP id j61mr7124875qte.192.1505242569591; Tue, 12 Sep 2017 11:56:09 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.54.104 with HTTP; Tue, 12 Sep 2017 11:56:08 -0700 (PDT) In-Reply-To: <19d26495-b9d9-970f-bdc1-5e35e46a28c6@gmail.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <85f3ebd4-0493-221c-ae05-826ca02f5d2a@gmail.com> <19d26495-b9d9-970f-bdc1-5e35e46a28c6@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 12 Sep 2017 11:56:08 -0700 X-Google-Sender-Auth: nHLrMzsM9kpgQ0KzMcIq7fm2ZYs Message-ID: To: Brian E Carpenter Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 18:56:12 -0000 On Mon, Sep 11, 2017 at 1:48 PM, Brian E Carpenter wrote: >>> " o Two devices (subscriber/hosts), both attached to the same provider >>> managed shared network should only be able to communicate through >>> the provider managed First Hop Router" > > That's a lower-case should, not even an RFC2119 SHOULD. So there is no > need to add an "unless" clause. It doesn't matter whether the exception > is "unless the shared network explicitly permits peer-to-peer operations" > or "unless it's Thursday afternoon". "Should" doesn't mean "must." > > Fred said: > >> In order to prevent that, this document would have to >> require that L2 partitioning must be used. Otherwise, this document is >> essentially deprecating peer-to-peer (including the Redirect function) >> even for link types where it may provide useful benefits. > > Again, it does not require or deprecate, it only recommends. And don't > forget that peer-to-peer operation will only happen for link-local > addresses or for announced on-link prefixes, neither of which are > covered by the concept "unique-ipv6-prefix-per-host". The draft is > 100% clear on this: > > " o L-flag = 0 (the prefix is not an on-link prefix, which means that > the UE/subscriber will NEVER assume destination addresses that > match the prefix are on-link and will ALWAYS send packets to those > addresses to the appropriate gateway according to route selection > rules.)" > > So I don't agree that this text needs changing. +1. I don't even understand why we are discussing this level of things in the context of draft-ietf-v6ops-unique-ipv6-prefix-per-host. My interpretation of the draft has always been that it explains *one* way to provide each individual host with a unique IPv6 prefix for *some* environments. While it mildly recommends their way for others who share the same motivation, it doesn't insist that's *the* only way to operate an IPv6 network or it doesn't change any protocol specifications. I've just re-read the entire 07 version of the draft and still have the same impression. Although some more editorial clarifications might make the point even super crystal clearer, I don't see the need for the level of wordsmith nitpicking discussed in this lengthy thread. For example, it's true that adding "unless redirect is sent" to the above cited bullet would make the idea of this draft even clearer than 100%, the current text is already clear enough to me if you read it with the entire context. Same for the definition of "shared network". Assuming the main source of the objections is based on the interpretation that this draft prohibits other ways of operation, (although the draft doesn't read that way to me) a couple of higher level clarifications might help us move forward: - note in the introduction that this draft doesn't intend to prevent other way of network operation such as allowing direct p2p communication between hosts in the shared link. it totally depends on operational requirements and assumptions of each environment. - rephrase the seemingly controversial bullet in Section 2 so it's more obvious it's just a part of motivation, not a requirement (let alone some kind of standard). e.g. From: o Two devices (subscriber/hosts), both attached to the same provider managed shared network should only be able to communicate through the provider managed First Hop Router To: o Make sure two devices (subscriber/hosts), both attached to the same provider managed shared network, will only be able to communicate through the provider managed First Hop Router -- JINMEI, Tatuya From nobody Tue Sep 12 12:41:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DA6132F2D for ; Tue, 12 Sep 2017 12:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYwejgqYym_G for ; Tue, 12 Sep 2017 12:41:22 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224E21330BC for ; Tue, 12 Sep 2017 12:41:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8CJfJev023713 for ; Tue, 12 Sep 2017 21:41:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E4DFD20B5FA for ; Tue, 12 Sep 2017 21:41:19 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DB0C620B5CE for ; Tue, 12 Sep 2017 21:41:19 +0200 (CEST) Received: from [132.166.84.227] ([132.166.84.227]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8CJfInk015699 for ; Tue, 12 Sep 2017 21:41:19 +0200 To: v6ops@ietf.org References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <85f3ebd4-0493-221c-ae05-826ca02f5d2a@gmail.com> <19d26495-b9d9-970f-bdc1-5e35e46a28c6@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 12 Sep 2017 21:41:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 19:41:23 -0000 Le 12/09/2017 à 20:56, 神明達哉 a écrit : [...] > - rephrase the seemingly controversial bullet in Section 2 so it's > more obvious it's just a part of motivation, not a requirement (let > alone some kind of standard). e.g. > From: > o Two devices (subscriber/hosts), both attached to the same provider > managed shared network should only be able to communicate through > the provider managed First Hop Router > To: > o Make sure two devices (subscriber/hosts), both attached to the > same provider managed shared network, will only be able to > communicate through the provider managed First Hop Router This IP Host-to-Host communication does happen on shared media, unless someone forbids it somehow with some iptables filtering. Or maybe we want to clarify at which level of the ISO OSI stack is this "communicate through". For example: at APP layer, make sure two subscribers both attached to same provider managed shared network, will only be able to communicate through the provider's managed App Server; at network layer, allow for direct communications. Alex From nobody Tue Sep 12 13:17:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1951330C5; Tue, 12 Sep 2017 13:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAOMbpn5-e5w; Tue, 12 Sep 2017 13:17:53 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66AB113293A; Tue, 12 Sep 2017 13:17:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8CKHpoh045774; Tue, 12 Sep 2017 13:17:52 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8CKHmW8045727 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 12 Sep 2017 13:17:49 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 12 Sep 2017 13:17:48 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 12 Sep 2017 13:17:48 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: Warren Kumari , Suresh Krishnan , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTKaTY2SQFbjmM502TqtM/gaCiM6KtwdeAgAFRDQCAAPq0kIAAp1cA//+S9hCAAQeJAIAABEWQgAC2RAD//6rssA== Date: Tue, 12 Sep 2017 20:17:48 +0000 Message-ID: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <5ec52c86f18e453b8191679afb7ec1b4@XCH15-06-08.nw.nos.boeing.com> <31e926886e01457fb84efd165dd000c5@XCH15-06-08.nw.nos.boeing.com> <80ba83ecbb364ae4858679851f51f720@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_e69e456cbde048a499a5fcacadcb55e3XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2017 20:17:55 -0000 --_000_e69e456cbde048a499a5fcacadcb55e3XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNl bnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAxMiwgMjAxNyAxMToyMiBBTQ0KVG86IFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCkNjOiBXYXJyZW4gS3VtYXJpIDx3YXJy ZW5Aa3VtYXJpLm5ldD47IFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoLmtyaXNobmFuQGdtYWlsLmNv bT47IHY2b3BzQGlldGYub3JnOyBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1w ZXItaG9zdEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gU3VyZXNoIEtyaXNobmFuJ3Mg RGlzY3VzcyBvbiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0w NzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KT24gVHVlLCBTZXAgMTIsIDIwMTcgYXQg MTE6NDMgUE0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWls dG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KSW4gYW55IGNhc2UgLSBSRkMg NDg2MSBzZWN0aW9uIDIuMiBpcyBjbGVhcmx5IG5vdCBhIHRheG9ub215IG9mIGxpbmsgdHlwZXMs IGl0J3MgYSBsaXN0IG9mIGxpbmsgKnByb3BlcnRpZXMqLiBFeGFtcGxlOiAidmFyaWFibGUgTVRV IiAod2hpY2ggaXMgb25lIG9mIHRoZSBidWxsZXRzIG9mIHRoYXQgc2VjdGlvbikgaXMgbm90IGEg bGluayB0eXBlLg0KDQoNCj4gICAgU2VjdGlvbiAyLjIgaXMgdGl0bGVkOiDigJxMaW5rIFR5cGVz 4oCdIGFuZCBTZWN0aW9uIDMuMiBpcyB0aXRsZWQ6IOKAnFN1cHBvcnRlZCBMaW5rIFR5cGVz4oCd DQoNCj4gICAgVGhlIHR5cGUgZGVzY3JpcHRpb25zIGFyZSB1bmRlcnN0b29kIHRvIGxpbmUgdXAg d2l0aCBhY3R1YWwgSVAgZGF0YSBsaW5rcy4gRm9yDQoNCj4gICAgZXhhbXBsZSwgRXRoZXJuZXQg YW5kIFdpRmkgYXJlIGV4YW1wbGVzIG9mIG11bHRpY2FzdC1jYXBhYmxlIGxpbmtzLCB0dW5uZWwN Cg0KPiAgICB2aXJ0dWFsIGxpbmtzIGFyZSBhbiBleGFtcGxlIG9mIE5CTUEgbGlua3MsIGV0Yy4g VGhlc2UgYXJlIHRoZSBsaW5rIHR5cGVzIHRoYXQNCg0KPiAgICBJUHY2IE5EIG9wZXJhdGVzIG92 ZXIsIGFuZCBoYXZlIGJlZW4gc3BlY2lmaWVkIHRoYXQgd2F5IHNpbmNlIFJGQzE5NzAuDQpZb3Un cmUgbm90IGFjdHVhbGx5IHN1Z2dlc3RpbmcgdGhhdCAidmFyaWFibGUgTVRVIiBpcyBhIGxpbmsg dHlwZSwgYXJlIHlvdT8NCg0KDQrDmCAgICBSRkM0ODYxIGdpdmVzIGFuIGV4YW1wbGUuDQo= --_000_e69e456cbde048a499a5fcacadcb55e3XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm04NDU2MDIzOTgxMzI3NzQ0MDE3bXNvbGlzdHBhcmFncmFw aCwgbGkubTg0NTYwMjM5ODEzMjc3NDQwMTdtc29saXN0cGFyYWdyYXBoLCBkaXYubTg0NTYwMjM5 ODEzMjc3NDQwMTdtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fODQ1NjAyMzk4 MTMyNzc0NDAxN21zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTIyMDg2NTgxOw0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzI2NzkxODc0IDQ3MjQyMDU5NiA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJ bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTG9yZW56byBDb2xpdHRpIFttYWls dG86bG9yZW56b0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIFNlcHRl bWJlciAxMiwgMjAxNyAxMToyMiBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBMICZs dDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gV2FycmVuIEt1 bWFyaSAmbHQ7d2FycmVuQGt1bWFyaS5uZXQmZ3Q7OyBTdXJlc2ggS3Jpc2huYW4gJmx0O3N1cmVz aC5rcmlzaG5hbkBnbWFpbC5jb20mZ3Q7OyB2Nm9wc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi12Nm9w cy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFt2Nm9wc10gU3VyZXNoIEtyaXNobmFuJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXY2 b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wNzogKHdpdGggRElTQ1VTUyBhbmQgQ09N TUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIFNlcCAxMiwgMjAxNyBhdCAxMTo0MyBQTSwgVGVtcGxp biwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JbiBhbnkgY2FzZSAtIFJGQyA0ODYxIHNlY3Rpb24gMi4yIGlzIGNsZWFybHkgbm90IGEg dGF4b25vbXkgb2YgbGluayB0eXBlcywgaXQncyBhIGxpc3Qgb2YgbGluayAqcHJvcGVydGllcyou IEV4YW1wbGU6ICZxdW90O3ZhcmlhYmxlIE1UVSZxdW90OyAod2hpY2ggaXMgb25lIG9mIHRoZSBi dWxsZXRzIG9mIHRoYXQgc2VjdGlvbikNCiBpcyBub3QgYSBsaW5rIHR5cGUuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTg0NTYwMjM5ODEzMjc3 NDQwMTdtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbiAyLjIgaXMgdGl0bGVkOiDigJxM aW5rIFR5cGVz4oCdIGFuZCBTZWN0aW9uIDMuMiBpcyB0aXRsZWQ6IOKAnFN1cHBvcnRlZCBMaW5r IFR5cGVz4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04NDU2MDIzOTgxMzI3 NzQ0MDE3bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSB0eXBlIGRlc2NyaXB0aW9ucyBhcmUg dW5kZXJzdG9vZCB0byBsaW5lIHVwIHdpdGggYWN0dWFsIElQIGRhdGEgbGlua3MuIEZvcjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtODQ1NjAyMzk4MTMyNzc0NDAxN21zb2xpc3Rw YXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldpbmdk aW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5leGFtcGxlLCBFdGhlcm5ldCBhbmQgV2lGaSBhcmUgZXhhbXBsZXMg b2YgbXVsdGljYXN0LWNhcGFibGUgbGlua3MsIHR1bm5lbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJtODQ1NjAyMzk4MTMyNzc0NDAxN21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdE Ij7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj52 aXJ0dWFsIGxpbmtzIGFyZSBhbiBleGFtcGxlIG9mIE5CTUEgbGlua3MsIGV0Yy4gVGhlc2UgYXJl IHRoZSBsaW5rIHR5cGVzIHRoYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTg0 NTYwMjM5ODEzMjc3NDQwMTdtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SVB2NiBORCBvcGVyYXRl cyBvdmVyLCBhbmQgaGF2ZSBiZWVuIHNwZWNpZmllZCB0aGF0IHdheSBzaW5jZSBSRkMxOTcwLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UncmUgbm90IGFjdHVhbGx5IHN1Z2dlc3RpbmcgdGhh dCAmcXVvdDt2YXJpYWJsZSBNVFUmcXVvdDsgaXMgYSBsaW5rIHR5cGUsIGFyZSB5b3U/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJGQzQ4NjEgZ2l2ZXMg YW4gZXhhbXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e69e456cbde048a499a5fcacadcb55e3XCH150608nwnosboeingcom_-- From nobody Tue Sep 12 22:51:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1C91321D8 for ; Tue, 12 Sep 2017 22:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fijiG8tRQnlY for ; Tue, 12 Sep 2017 22:51:21 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386FF13307F for ; Tue, 12 Sep 2017 22:51:21 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8D5pJB3153763 for ; Wed, 13 Sep 2017 07:51:19 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1F0DF20312F for ; Wed, 13 Sep 2017 07:51:19 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 15D7B202DA1 for ; Wed, 13 Sep 2017 07:51:19 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8D5pI39025472 for ; Wed, 13 Sep 2017 07:51:18 +0200 To: v6ops@ietf.org References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <5ec52c86f18e453b8191679afb7ec1b4@XCH15-06-08.nw.nos.boeing.com> <31e926886e01457fb84efd165dd000c5@XCH15-06-08.nw.nos.boeing.com> <80ba83ecbb364ae4858679851f51f720@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <4a97907b-7f6d-ee43-11a8-0d370f96e625@gmail.com> Date: Wed, 13 Sep 2017 07:51:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 05:51:23 -0000 Le 12/09/2017 à 22:17, Templin, Fred L a écrit : > *From:*Lorenzo Colitti [mailto:lorenzo@google.com] > *Sent:* Tuesday, September 12, 2017 11:22 AM > *To:* Templin, Fred L > *Cc:* Warren Kumari ; Suresh Krishnan > ; v6ops@ietf.org; > draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org > *Subject:* Re: [v6ops] Suresh Krishnan's Discuss on > draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) > > On Tue, Sep 12, 2017 at 11:43 PM, Templin, Fred L > > wrote: > > In any case - RFC 4861 section 2.2 is clearly not a taxonomy of link > types, it's a list of link *properties*. Example: "variable MTU" > (which is one of the bullets of that section) is not a link type. > > ØSection 2.2 is titled: “Link Types” and Section 3.2 is titled: > “Supported Link Types” > > ØThe type descriptions are understood to line up with actual IP data > links. For > > Øexample, Ethernet and WiFi are examples of multicast-capable links, > tunnel > > Øvirtual links are an example of NBMA links, etc. These are the link > types that > > ØIPv6 ND operates over, and have been specified that way since RFC1970. > > You're not actually suggesting that "variable MTU" is a link type, are you? > > ØRFC4861 gives an example. I think it is possible to decide that a particular link is of a particular 'link type' too by looking at the MTU value that is advertised on the link in the RA. If there is no MTU value in RA - it's likely to be an Ethernet and family. If there is smaller than 1280 value - it's likely to be either Ethernet, or some other IoT kind constrained of link. If there is a larger than 1280 value - it's likely to be one of those core network links like ATM and FDDI which support MTU of up to 65k. One could test a Host on that link see at which point it fragments by varying the MTU value in RA and then ping -s 'size': one will notice IPv6 Fragments popping up. The threshold 'size' is the MTU of that link. Whether or not dedicated-/64-per-Host applies on these links types - only this draft could tell, or no. Alex From nobody Wed Sep 13 00:14:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7837F1341CF for ; Wed, 13 Sep 2017 00:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NGRrm9FIY12e for ; Wed, 13 Sep 2017 00:14:26 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421EF133DFE for ; Wed, 13 Sep 2017 00:14:26 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 364622D4FD0; Wed, 13 Sep 2017 07:14:24 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E512110677986; Wed, 13 Sep 2017 09:14:25 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_98768F80-E70D-458D-BBD1-34A9C9EFA0D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Sep 2017 09:14:25 +0200 In-Reply-To: Cc: Brian E Carpenter , "v6ops@ietf.org" To: =?utf-8?B?56We5piO6YGU5ZOJ?= References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <85f3ebd4-0493-221c-ae05-826ca02f5d2a@gmail.com> <19d26495-b9d9-970f-bdc1-5e35e46a28c6@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 07:14:27 -0000 --Apple-Mail=_98768F80-E70D-458D-BBD1-34A9C9EFA0D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > +1. I don't even understand why we are discussing this level of > things in the context of draft-ietf-v6ops-unique-ipv6-prefix-per-host. >=20 > My interpretation of the draft has always been that it explains *one* > way to provide each individual host with a unique IPv6 prefix for > *some* environments. While it mildly recommends their way for others > who share the same motivation, it doesn't insist that's *the* only way > to operate an IPv6 network or it doesn't change any protocol > specifications. I've just re-read the entire 07 version of the draft > and still have the same impression. The document has: Intended status: Best Current Practice I think when something has that label, people unsurprisingly reads it as = _the_ recommended way of doing things. It also labels doing it any other way as not best current practice. A simple fix to those concerns are: s/Best Current Practice/Informational Ole --Apple-Mail=_98768F80-E70D-458D-BBD1-34A9C9EFA0D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZuNrRAAoJEL7aWKiYQt92/ngP/18nGenHGAXcfGYtf95sUcL/ c58aCEqkO/2f3pA/Qtny0yVXlGMsZzCYTuJks732PV0+XbFcTGEIj3hnOZz01lqg uGUhpIIMrmsnIE+WiZUMUrF0rqj5rRDi74CZ9bcdFgKVsKC7vc5m/NTkWPRoBXtD KCiFJhx1Oj2sYqmw4owZ6vSQzCJTxRMp25Koz4tf8cHclJeNfyQrgpqldypDMtUp Nfqa9TewtbLIAL49LnyUmFNMmtnqC02v14Jyq/BdCQq2oSE0Z9Jh2uJwxAPRdHl3 NR/NYYpWDmjunbSkV+daeVYr5futf7HuUivC1aM1eFThliqKlVgHdCj85iNNvsbC T0w7MNKfHzVcUIdf7Z9k4F+lCCF8qF55obQ7g/JoAOTfL1+65eO09YzzfvLxc+rR 9ujlmU1j88NTTvzUEuf6WrKkT2FbcbgSQb5o+JWDuAPyruFwg/8M4viFtAXCDLzI iDIANbUzIAyjpUwM8NT0+pUyheJCBsbDhI35QA3FaVeRcA5jjVvWG2x8JCg55kjz GIKtSTLWp6rUaD21cVTQN/24YZY1S2tXmdf44/1k8J9PjYI185SyYr/EWTqnr9wZ S9hQ6vfFNZJkH120kbgk8srCjlRPQnhU/hvy7Qv+UtrxIRvt9KNl67P0BK8hqu12 HbuyAmbr1aH0LAoRM+f2 =1jdH -----END PGP SIGNATURE----- --Apple-Mail=_98768F80-E70D-458D-BBD1-34A9C9EFA0D0-- From nobody Wed Sep 13 00:56:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4EE13295C for ; Wed, 13 Sep 2017 00:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HluZF0D4BsuN for ; Wed, 13 Sep 2017 00:56:19 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0D913219C for ; Wed, 13 Sep 2017 00:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1308; q=dns/txt; s=iport; t=1505289379; x=1506498979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=J2r0fF9rEox70IhV29we5fM7f3ojTj4/puYoXv727Kk=; b=Vv2m5lUPrU3Vq2da3jA6QN2Meizt0XUiQALlbSGPjIH64pNCgbYPbg2X rG+OCooNGjZGofVh/iSS9Sh8Gm93snMezEpx3j0hWs2e88Uumhir7g03C 4pGHXYaPbYQIuwjknLQLzJE9sPffM/fYBU6Kxlh4x/G9UPgxN60PWRJvH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAgAF5LhZ/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBUicHg3GaRoF0mDoKhT4ChEZXAQIBAQEBAQJrKIUYAQEBBCE?= =?us-ascii?q?BVwwEAgEIDgMEAQECAwsUBAIDAjIUCQgCBAENBQiKKY5pnWEBgiuLOAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2BC4IgggKBUIULiAeCZAWgdAKUR4IciWaGeZUCAhE?= =?us-ascii?q?ZAYE4AVeBDXcVhheBTnaId4EPAQEB?= X-IronPort-AV: E=Sophos;i="5.42,386,1500940800"; d="scan'208";a="2237661" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Sep 2017 07:56:18 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v8D7uI6G017059 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Sep 2017 07:56:18 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 13 Sep 2017 02:56:17 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1263.000; Wed, 13 Sep 2017 02:56:17 -0500 From: "Pascal Thubert (pthubert)" To: Ole Troan , =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTGn0tqyIh4RxUZU6YAbONu9yaiaKRXGcAgBRQDQCAAR+ngIAI6meAgADnA4CAAXLoAIAAzkaA//+3VGA= Date: Wed, 13 Sep 2017 07:55:50 +0000 Deferred-Delivery: Wed, 13 Sep 2017 07:55:30 +0000 Message-ID: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <85f3ebd4-0493-221c-ae05-826ca02f5d2a@gmail.com> <19d26495-b9d9-970f-bdc1-5e35e46a28c6@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.10] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 07:56:21 -0000 +1 -----Original Message----- From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ole Troan Sent: mercredi 13 septembre 2017 09:14 To: =1B$B?@L@C#:H=1B(B Cc: v6ops@ietf.org Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-i= pv6-prefix-per-host-07: (with DISCUSS and COMMENT) >=20 > +1. I don't even understand why we are discussing this level of > things in the context of draft-ietf-v6ops-unique-ipv6-prefix-per-host. >=20 > My interpretation of the draft has always been that it explains *one*=20 > way to provide each individual host with a unique IPv6 prefix for > *some* environments. While it mildly recommends their way for others=20 > who share the same motivation, it doesn't insist that's *the* only way=20 > to operate an IPv6 network or it doesn't change any protocol=20 > specifications. I've just re-read the entire 07 version of the draft=20 > and still have the same impression. The document has: Intended status: Best Current Practice I think when something has that label, people unsurprisingly reads it as _t= he_ recommended way of doing things. It also labels doing it any other way as not best current practice. A simple fix to those concerns are: s/Best Current Practice/Informational Ole From nobody Wed Sep 13 07:04:01 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B99133065; Wed, 13 Sep 2017 07:04:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150531144008.30405.8720524557391780522@ietfa.amsl.com> Date: Wed, 13 Sep 2017 07:04:00 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:04:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt Pages : 9 Date : 2017-09-13 Abstract: This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique service provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 13 07:11:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7F6132F7A; Wed, 13 Sep 2017 07:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh91LAj7_tnu; Wed, 13 Sep 2017 07:11:33 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50112.outbound.protection.outlook.com [40.107.5.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD7513291C; Wed, 13 Sep 2017 07:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ipISGeXGtqlXJY9cJ1sdUdYDCVEfrWBsuKkh8KxfYeE=; b=NsWAWUdrJTcJvYpaT846ucNSraxhCYZMtw/mzwOGkPvbwGEwwW0s8uG0LRfdi+of88AhH27ci436z2AU/b3DTRHHV9x4/clQRXopA875DYMFmF1InsIB66XfxwZ5/y9hbOMJD+uQMDAzkn4Icu1+x2QYM7tzOVrkjtTjWwsxnz8= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1491.eurprd07.prod.outlook.com (10.165.248.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Wed, 13 Sep 2017 14:11:29 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be%13]) with mapi id 15.20.0056.010; Wed, 13 Sep 2017 14:11:29 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Warren Kumari , Lorenzo Colitti CC: Brian E Carpenter , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" , Suresh Krishnan Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTFuKYQ+gKTl12Z0GuSR6OAMdtbqKO7fkAgB4t23qAAFYvgIABUQ0AgARlEwA= Date: Wed, 13 Sep 2017 14:11:29 +0000 Message-ID: <961C9C36-C4DA-4D84-8A0C-97EB15BD9A36@nokia.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.135.12.190] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1491; 6:wy1EMMyMplkQhw3Tt8YOWCWfi8FlWaFoUxlMbBSDhVE6Xv92yK+kx8PY1z7oUiuqOPHUDeuHf9Ndtrw33TEiKuJB2lsZRhrR0dYRxn6B1A7D6HMejzGx7JXw/AWwwGgGd3W/lvFUT3SYzHQ1XnQUx6hNwT/2doytsLfYrLbBGxCLP106oT+PtrzAENR6d06STjw3iRa7TGZDhG3J7sETenwrbHZ00k8QhxErnHeL+Cnu9ZuoJktYCVAwaHpqg2kwe07+HYqvzk7r7hxRoyfnEKwMkXMdGY2R9mYOsFSfDMafgiD27LhWs1XXMSzBp9nvuy4klC9bELK54DNNVR5orw==; 5:+meaM+rp6gyhoDz3hOwLaxGhNubmR3TwAFLZIxP+p9PYjcG4gw7xMmruggGX2i6a4cd7HvIzFxfT0JlKSosqAoJhx7LHNg1L2tP02stHO5wiEoXiL+2gksNi2MV5drITlI62ZzgEK+l0Hj7KC/Mvpg==; 24:z/R48szUQudYECcW3TGAzzNneaZ1ECwjYSldDJTJJzhaepN2E+LXPewHS3o9vGf0Vgg4ArGNBbLS4xqtD7CpAryNriqg5dz4IFqLG6L4ptQ=; 7:TcEFkIvlodrqJydbCgLsGqtdBOu5fPwEyQl4Y3+wS+CwzlwoIlTSAlqpXv72PkFMJNeN5W3frIkDFdqDNf58KX6NybcLwKV8aNYbWC8fmbuvdqDALK6itfjR2POaU8KmzaCK4tiRWCYPbAMQ1uWokdYNbEpj1Ca+oxHgZqvIZ6vjj5x+OtxxFiLOfIwi9ES1rV745R340J4rh2w7fNWri4rGzcQVodJNXWTFiNP3TO4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7a509706-fb3c-4c48-dd47-08d4fab1542f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR07MB1491; x-ms-traffictypediagnostic: AM4PR07MB1491: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(82608151540597)(211936372134217)(100405760836317)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(920507026)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB1491; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB1491; x-forefront-prvs: 042957ACD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(366002)(39860400002)(189002)(199003)(51914003)(51444003)(24454002)(16064003)(76104003)(377454003)(377424004)(66654002)(8936002)(3660700001)(6306002)(5890100001)(86362001)(81156014)(53936002)(6512007)(53946003)(99286003)(575784001)(81166006)(25786009)(8676002)(6246003)(66066001)(106356001)(5250100002)(6506006)(68736007)(2900100001)(54906002)(6486002)(3280700002)(53546010)(3846002)(6436002)(102836003)(105586002)(229853002)(6116002)(230783001)(33656002)(2950100002)(316002)(5660300001)(93886005)(4326008)(2906002)(189998001)(82746002)(54356999)(76176999)(50986999)(345774005)(478600001)(97736004)(101416001)(83716003)(36756003)(966005)(34040400001)(14454004)(39060400002)(305945005)(7736002)(372894003)(341764005)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1491; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2017 14:11:29.3567 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1491 Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:11:37 -0000 TmV3IHZlcnNpb24gaXMgc3VibWl0dGVkLCB0YWtpbmcgdGhlIElFVEYgTEMgY29tbWVudHMgaW50 byBhY2NvdW50LCBpbmNsdWRpbmcgU3VyZXNoIGNvbW1lbnQgYWJvdXQgbWF4aW11bSBSQSBpbnRl cnZhbCBhbmQgTG9yZW56b+KAmXMgc3Vic3RhbnRpYWwgbm90ZSBhYm91dCAzMDBzIHZzIDYwMHMg UkEgaW50ZXJ2YWwgZm9yIGJhdHRlcnkgY29uc3RyYWludCBkZXZpY2VzLiANCg0KRy8NCg0KDQpP biAxMC8wOS8yMDE3LCAyMzowNCwgIldhcnJlbiBLdW1hcmkiIDx3YXJyZW5Aa3VtYXJpLm5ldD4g d3JvdGU6DQoNCiAgICBbIC0gSUVTRywgLUd1bnRlciAoaGUgZ2V0cyBhIGNvcHkgYXMgcGFydCBv Zg0KICAgIGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0QCksIC12 NmNoYWlyc0AgXQ0KICAgIA0KICAgIA0KICAgIA0KICAgIE9uIFNhdCwgU2VwIDksIDIwMTcgYXQg ODo1OCBQTSwgTG9yZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20+IHdyb3RlOg0KICAg ID4gV2FycmVuLA0KICAgID4NCiAgICA+IGNhcmUgdG8gc3VtbWFyaXplIHRoZSBtYWluIGlzc3Vl cyB0aGF0IGNhdXNlZCB5b3UgdG8gZG8gdGhpcz8gV2UnbGwgd2FudCB0bw0KICAgID4gbWFrZSBz dXJlIHdlIGRvbid0IHNwZW5kIHRvbyBtdWNoIHRpbWUgZGlzY3Vzc2luZyBpc3N1ZXMgdGhhdCBk aWQgbm90DQogICAgPiBtYXRlcmlhbGx5IGltcGFjdCB0aGlzIGRlY2lzaW9uLg0KICAgID4NCiAg ICANCiAgICBTdXJlLg0KICAgIA0KICAgIER1cmluZyBJRVNHIHJldmlldywgc29tZSBvZiB0aGUg SUVTRyByYWlzZWQgcXVlc3Rpb25zIGFuZCBzdWdnZXN0ZWQNCiAgICB0ZXh0IHRvIGltcHJvdmUg dGhlIGRvY3VtZW50LiBXZSByZWNlaXZlZCByZXNwb25zZXMgZnJvbSB0aGUgYXV0aG9ycw0KICAg IHNheWluZyB0aGF0IHRoZSBxdWVzdGlvbnMsIGFsb25nIHdpdGggU3VyZXNoJ3MgRElTQ1VTUywg d291bGQgYmUNCiAgICBhZGRyZXNzZWQuIFdlIGRpZCBub3Qgc2VlIGFuIHVwZGF0ZWQgZHJhZnQs IGFuZCBpdCdzIGRpZmZpY3VsdCB0byBrZWVwDQogICAgdGhlIHBhdGNoZWQgdmVyc2lvbiBpbiBv bmUncyBoZWFkLiBTbywgSSBkb24ndCBrbm93IGV4YWN0bHkgd2hhdCBpdA0KICAgIGxvb2tzIGxp a2Ugbm93LCBidXQgaGVyZSBhcmUgc29tZSBvZiB0aGUgY29uc2lkZXJhdGlvbnMgdGhhdA0KICAg IGluZmx1ZW5jZWQgbXkgZGVjaXNpb246DQogICAgDQogICAgMTogQnJpYW4gQ2FycGVudGVyJ3M6 DQogICAgIkkgYmVsaWV2ZSBpdCdzIHN1YnN0YW50aXZlIHRoYXQgdGhlIHRleHQgcmVmZXJzIHRv IHNlbmRpbmcgdW5pY2FzdA0KICAgIFJBcyB3aXRob3V0IGNsYXJpZnlpbmcgd2hldGhlciB0aGlz IG1lYW5zIHRoYXQgdGhleSBhcmUgc2VudA0KICAgIHdpdGggYSB1bmljYXN0IGxheWVyIDIgYWRk cmVzcyBhbmQgYSBtdWx0aWNhc3QgbGF5ZXIgMyBhZGRyZXNzDQogICAgKGFzIHBlciBSRkM2MDg1 KSBvciB0aGF0IHRoZXkgYXJlIHNlbnQgd2l0aCBib3RoIGxheWVyIDIgYW5kDQogICAgbGF5ZXIg MyBhZGRyZXNzZXMgYmVpbmcgdW5pY2FzdC4gQXQgdGhlIG1vbWVudCwgYW4gaW1wbGVtZW50ZXIN CiAgICBoYXMgdG8gZGVjaWRlIHdoaWNoIG9mIHRoZXNlIGlzIGludGVuZGVkLiBJZiBlaXRoZXIg aXMgT0ssDQogICAgdGhhdCBjb3VsZCBiZSBzdGF0ZWQgdG9vLiIuDQogICAgDQogICAgMjogRnJl ZCBUZW1wbGluJ3MgInVubGVzcyB0aGUgc2hhcmVkIG5ldHdvcmsgZXhwbGljaXRseSBwZXJtaXRz DQogICAgcGVlci10by1wZWVyIG9wZXJhdGlvbnMiIC0tIGluIG15IHZpZXcgYWRkaW5nIHRoaXMg ZXhhY3QgdGV4dCBkaWRuJ3QNCiAgICBzZWVtIHRvIGhhdmUgc3VwcG9ydCwgYnV0IGNsYXJpZnlp bmcgd2hhdCBpcyBtZWFudCBieSBhICJzaGFyZWQNCiAgICBuZXR3b3JrIiB3b3VsZCBiZSB1c2Vm dWwuDQogICAgVGhpcyB3YXMgYWxzbyBtZW50aW9uZWQgaW4gRUtSJ3MgYmFsbG90IC0tIGJhbGxv dCB0ZXh0IGlzIGFsbCBiZWxvdyAoSQ0KICAgIGRvbid0IHdhbnQgaXQgdG8gZ2V0IGxvc3Qgd2hl biBiZWluZyBMQ2VkKS4NCiAgICANCiAgICAzOiBJIGRvIG5vdCBiZWxpZXZlIHRoYXQgSSBldmVy IHNhdyBhIHJlc29sdXRpb24gdG8gTG9yZW56bydzICJJJ2xsDQogICAgYWxzbyBwb2ludCBvdXQg eWV0IGFnYWluIHRoYXQgdGhpcyB2YWx1ZSBpcyBpbiBjb25mbGljdCB3aXRoIFJGQyA3NzcyDQog ICAgaW4gdGhlIGNhc2Ugb2YgbmV0d29ya3MgdGhhdCBhcmUgcHJvdmlkZSBzZXJ2aWNlIGZvciBi YXR0ZXJ5LXBvd2VyZWQNCiAgICBkZXZpY2VzLiBUaGUgdGV4dCBzaG91bGQgZWl0aGVyIGJlIGNo YW5nZWQgdG8gZm9sbG93IHRoYXQgUkZDIG9yIHRvDQogICAgZXhwbGFpbiB0aGUgcmVhc29uIGZv ciB0aGUgY29uZmxpY3QuIiAtLSBJIHBlcnNvbmFsbHkgZG9uJ3QgY2FyZSB3aGF0DQogICAgdGhl IHZhbHVlIGlzIChJIHdhc24ndCByZWFsbHkgdGhpbmtpbmcgdGhhdCB0aGlzIHdvdWxkIG9jY3Vy IG11Y2ggb24NCiAgICBiYXR0ZXJ5LXBvd2VyZWQgZGV2aWNlcywgYnV0IEkgbWF5IGJlIGNvbXBs ZXRlbHkgd3JvbmcpLCBidXQgSSAqZG8qDQogICAgdGhpbmsgdGhhdCBpZiBpdCBjb25mbGljdHMg d2l0aCBSRkMgNzc3MiBpdCBuZWVkcyB0byBub3RlIHRoaXMuDQogICAgDQogICAgNDogTXVjaCBv ZiB0aGUgdGhyZWFkIGFib3ZlIERhdmlkIEZhcm1lcidzDQogICAgaHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL21zZy92Nm9wcy9pNzJjYjByNmZWYnhoWkxocjRxeWJwcHdQNlENCiAg ICANCiAgICA1OiBTaW1wbHkgdGhlIGFtb3VudCBvZiBkaXNjdXNzaW9uIGFmdGVyIElFU0cgZXZh bCwgYW5kIElFVEYgTEMgKEkNCiAgICB0aGluayB0aGF0IHRoZSBudW1iZXIgaXMgc29tZXRoaW5n IGxpa2UgMTAwIGFuZCA+MzUwIHJlc3BlY3RpdmVseSkgLS0NCiAgICB3aGlsZSBtYW55IG9mIHRo ZW0gd2FuZGVyZWQgYWZhciBmcm9tIHRoZSBhY3R1YWwgZHJhZnQgKGFuZCwgb2Z0ZW4sDQogICAg dG9waWMgOi0pKSBpdCBpcyBoYXJkIHRvIG1ha2UgdGhlIGNsYWltIHRoYXQgdGhlIGRvY3VtZW50 IGlzIHJlYWxseQ0KICAgIGNsZWFyIGFuZCBoYXMgc3Ryb25nIGNvbnNlbnN1cyBmcm9tIHRoaXMu DQogICAgDQogICAgDQogICAgSSdkIG5vdGUgdGhhdCAjMSwgMiwgYW5kIDQgYXJlIHZlcnkgY2xv c2VseSByZWxhdGVkLCBhbmQgSSB0aGluaw0KICAgIHNob3VsZCBiZSBmYWlybHkgZWFzaWx5IGFk ZHJlc3NlZC4gSSdtIGFsc28gaGFwcHkgZm9yIHRoZSBjaGFpcnMgdG8NCiAgICBoYXZlIGEgY29t cHJlc3NlZCAyIFdHTEMgKGlmIHRoZXkgdGhpbmsgYXBwcm9wcmlhdGUpLg0KICAgIA0KICAgIElu Y2lkZW50YWxseSAoYnV0IGluIG5vIHdheSByZWxldmFudCksIEkgaGFwcGVuIHRvIHJlYWxseSBs aWtlIHRoZQ0KICAgIGlkZWEgLyBkb2N1bWVudCwgYW5kIHdvdWxkIGxpa2UgdG8gc2VlIGl0IHB1 Ymxpc2hlZCAoc29vbiEpLg0KICAgIHcNCiAgICANCiAgICANCiAgICANCiAgICAtPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LSBDb3B5LW4tcGFzdGUgb2YgYmFsbG90DQogICAgPS09LT0tPS09 LT0tPS09LT0tPS09LT0tPS09LQ0KICAgIA0KICAgIFN1cmVzaCBLcmlzaG5hbkRpc2N1c3MNCiAg ICANCiAgICBEaXNjdXNzICgyMDE3LTA4LTE2KQ0KICAgIA0KICAgICogU2VjdGlvbiA0DQogICAg DQogICAgSXQgaXMgbm90IGNsZWFyIHdoYXQgeW91IGludGVuZCBoZXJlDQogICAgDQogICAgIklQ djYgUm91dGVyIEFkdmVydGlzZW1lbnQgSW50ZXJ2YWwgPSAzMDBzIg0KICAgIA0KICAgIFRoZSBy b3V0ZXIgYWR2ZXJ0aXNlbWVudCBpbnRlcnZhbCBpcyBub3QgY29uZmlndXJlZCBhcyBhbiBhYnNv bHV0ZQ0KICAgIHZhbHVlIGJ1dCBhcyBtaW5pbXVtIGFuZCBtYXhpbXVtIGJvdW5kcyAoTWluUnRy QWR2SW50ZXJ2YWwgYW5kDQogICAgTWF4UnRyQWR2SW50ZXJ2YWwpIHdoaWNoIGFyZSB1c2VkIHRv IGNhbGN1bGF0ZSB0aGUgYWN0dWFsDQogICAgYWR2ZXJ0aXNlbWVudCBpbnRlcnZhbC4gV2hlbiB0 aGUgUkEgaXMgc2VudCBmcm9tIGFuIGludGVyZmFjZSwgdGhlDQogICAgYWN0dWFsIGludGVydmFs IGlzIGFuIHVuaWZvcm1seSBkaXN0cmlidXRlZCByYW5kb20gdmFsdWUgYmV0d2VlbiB0aGUNCiAg ICBNaW5SdHJBZHZJbnRlcnZhbCBhbmQgTWF4UnRyQWR2SW50ZXJ2YWwuIEF0IHRoZSB2ZXJ5IG1p bmltdW0geW91IG5lZWQNCiAgICB0byBjbGFyaWZ5IGlmIHlvdSB3b3VsZCBsaWtlIHRvIGhhdmUg dGhpcyBhcyBhIGxvd2VyIGJvdW5kIG9yIGFzIGFuDQogICAgdXBwZXIgYm91bmQuDQogICAgDQog ICAgQ29tbWVudCAoMjAxNy0wOC0xNikNCiAgICANCiAgICAqIFNlY3Rpb24gNA0KICAgIA0KICAg IC0+IEkgdGhpbmsgdGV4dCBpcyBuZWVkZWQgaGVyZSB0byBoYW5kbGUgdGhlIGNhc2Ugd2hlcmUg dGhlIEROUyBzZXJ2ZXINCiAgICBpcyBwcm92aWRlZCBpbiB0aGUgUkEgaXRzZWxmICAoUkZDODEw NikNCiAgICANCiAgICAiSW4gYWRkaXRpb24gaXQgd2lsbCB1c2Ugc3RhdGVsZXNzIERIQ1B2NiB0 byBnZXQgdGhlIElQdjYgYWRkcmVzcyBvZg0KICAgIHRoZSBETlMgc2VydmVyIg0KICAgIA0KICAg IC0+IEkgYW0gbm90IHN1cmUgd2hhdCBpcyB0aGUgbW90aXZhdGlvbiBmb3IgdGhpcyB0ZXh0Lg0K ICAgIA0KICAgICJob3dldmVyIGl0IFNIT1VMRCBOT1QgdXNlIHN0YXRlZnVsIERIQ1B2NiB0byBy ZWNlaXZlIGEgc2VydmljZQ0KICAgIHByb3ZpZGVyIG1hbmFnZWQgSVB2NiBhZGRyZXNzIg0KICAg IA0KICAgIC0+IFRoaXMgdGV4dCBzZWVtcyBpbmNvcnJlY3QNCiAgICANCiAgICAiZHVlIHRvIHRo ZSBMLWJpdCBzZXQsIGl0IFNIT1VMRCBzZW5kIHRoaXMgdHJhZmZpYyB0byB0aGUgRmlyc3QgSG9w DQogICAgUHJvdmlkZXIgUm91dGVyIg0KICAgIA0KICAgIEkgdGhpbmsgaXQgc2hvdWxkIGJlIHRo ZSBleGFjdCBvcHBvc2l0ZS4gaS5lLiBzYXkgKnVuc2V0KiBpbnN0ZWFkIG9mIHNldA0KICAgIA0K ICAgICJkdWUgdG8gdGhlIEwtYml0IGJlaW5nIHVuc2V0LCBpdCBTSE9VTEQgc2VuZCB0aGlzIHRy YWZmaWMgdG8gdGhlDQogICAgRmlyc3QgSG9wIFByb3ZpZGVyIFJvdXRlciINCiAgICANCiAgICBX YXJyZW4gS3VtYXJpWWVzDQogICAgDQogICAgRGVib3JhaCBCcnVuZ2FyZE5vIE9iamVjdGlvbg0K ICAgIA0KICAgIEJlbiBDYW1wYmVsbE5vIE9iamVjdGlvbg0KICAgIA0KICAgIENvbW1lbnQgKDIw MTctMDgtMTYpDQogICAgDQogICAgSSBoYXZlIG5vIHRlY2huaWNhbCBjb21tZW50cywgYnV0IGEg bnVtYmVyIG9mIGVkaXRvcmlhbCBjb21tZW50czoNCiAgICANCiAgICAtIEdlbmVyYWw6IEkgdGhp bmsgdGhpcyBjb3VsZCB1c2UgYW5vdGhlciBwcm9vZnJlYWRpbmcgYW5kL29yIGVkaXRpbmcNCiAg ICBwYXNzIGZvciB0aGUgZm9sbG93aW5nIGlzc3VlczoNCiAgICAtLSBJbmNvbnNpc3RlbnQgdGVu c2UtLWVzcGVjaWFsbHkgdXNlIG9mIGZ1dHVyZSBvciBwcmVzZW50IGNvbnRpbnVvdXMuDQogICAg LS0gV29yZHkgYW5kIGNvbnZvbHV0ZWQgc2VudGVuY2VzDQogICAgLS0gVXNlIG9mICIvIiBhcyBh IGNvbmp1bmN0aW9uLg0KICAgIA0KICAgIC0gQWJzdHJhY3Q6DQogICAgVGhlIGFic3RyYWN0IGlz IGxvbmdlciBhbmQgbW9yZSBkZXRhaWxlZCB0aGFuIGlzIHVzZWZ1bC4gVGhlIGxhc3QNCiAgICBw YXJhZ3JhcGggY291bGQgaGF2ZSBzdG9vZCBhbG9uZSBhcyB0aGUgYWJzdHJhY3QuDQogICAgSXQn cyBub3QgY2xlYXIgdG8gbWUgaWYgImhvc3RzIChzdWJzY3JpYmVycykiIG1lYW5zIHNvbWV0aGlu Zw0KICAgIGRpZmZlcmVudCB0aGFuICJob3N0cyIgaW4gY29udGV4dC4NCiAgICANCiAgICAtMToN CiAgICBQbGVhc2UgZXhwYW5kICJJQV9OQSIgb24gZmlyc3QgdXNlLg0KICAgIHMvIlRoaXMgZG9j dW1lbnQgd2lsbCBmb2N1cy4uLiIvIlRoaXMgZG9jdW1lbnQgZm9jdXNlcy4uLiINCiAgICANCiAg ICAiQXMgc3VjaCB0aGUgdXNlDQogICAgICAgb2YgSVB2NiBTTEFBQyBiYXNlZCBzdWJzY3JpYmVy IGFuZCBhZGRyZXNzIG1hbmFnZW1lbnQgZm9yIHByb3ZpZGVyDQogICAgICAgbWFuYWdlZCBzaGFy ZWQgbmV0d29yayBzZXJ2aWNlcyBpcyB0aGUgcmVjb21tZW5kZWQgdGVjaG5vbG9neSBvZg0KICAg ICAgIGNob2ljZSwgYXMgaXQgZG9lcyBub3QgZXhjbHVkZSBhbnkga25vd24gSVB2NiBpbXBsZW1l bnRhdGlvbi4iDQogICAgRG9lcyB0aGlzIGRvY3VtZW50IG1ha2UgdGhhdCByZWNvbW1lbmRhdGlv biwgb3IgaXMgdGhhdCBzb21lDQogICAgcHJlLWV4aXN0aW5nIHJlY29tbWVuZGF0aW9uPw0KICAg IA0KICAgIA0KICAgIC0zOiAiVGhlIEJlc3QgQ3VycmVudCBQcmFjdGljZSBkb2N1bWVudGVkIGlu IHRoaXMgbm90ZSBpcyB0byBwcm92aWRlIGENCiAgICAgICB1bmlxdWUgSVB2NiBwcmVmaXggdG8g aG9zdHMvc3Vic2NyaWJlcnMgZGV2aWNlcyBjb25uZWN0ZWQgdG8gdGhlDQogICAgICAgcHJvdmlk ZXIgbWFuYWdlZCBzaGFyZWQgbmV0d29yay4iDQogICAgDQogICAgVGhlIHNlbnRlbmNlIGhhcmQg dG8gZm9sbG93LiBDb25zaWRlciAiVGhpcyBkb2N1bWVudCByZWNvbW1lbmRzLi4uIi4NCiAgICBJ J20gbm90IHN1cmUgaG93IHRvIGludGVycHJldCAiaG9zdHMvc3Vic2NyaWJlcnMgZGV2aWNlcyIN CiAgICANCiAgICAiRWFjaCB1bmlxdWUgSVB2NiBwcmVmaXggY2FuDQogICAgICAgZnVuY3Rpb24g YXMgY29udHJvbC1wbGFuZSBhbmNob3IgcG9pbnQgdG8gbWFrZSBzdXJlIHRoYXQgZWFjaA0KICAg ICAgIHN1YnNjcmliZXIgaXMgcmVjZWl2aW5nIg0KICAgIHMvIi4uLiBzdWJzY3JpYmVyIGlzIHJl Y2VpdmluZyAuLi4iLyIuLi4gc3Vic2NyaWJlciByZWNlaXZlcy4uLiINCiAgICANCiAgICANCiAg ICANCiAgICAtNDogSXMgIkZpcnN0IEhvcCBQcm92aWRlciBSb3V0ZXIiIGRpZmZlcmVudCB0aGFu ICJGaXJzdCBIb3AgUm91dGVyIj8NCiAgICANCiAgICBJbiB0aGUgbGFzdCBidWxsZXQgKEwtZmxh Zz0wKSwgYXJlIE5FVkVSIGFuZCBBTFdBWVMgaW4gYWxsLWNhcHMNCiAgICBleHBlY3RlZCB0byBo YXZlIGRpZmZlcmVudCBtZWFuaW5nIHRoYW4gaWYgdGhleSBoYWQgbm9ybWFsDQogICAgY2FwaXRh bGl6YXRpb24/DQogICAgDQogICAgVGhlIHNlbnRlbmNlIHN0YXJ0aW5nIHdpdGggIlRoZSBhcmNo aXRlY3RlZCByZXN1bHQgb2YgZGVzaWduaW5nIHRoZSBSQQ0KICAgIGFzIGRvY3VtZW50ZWQgYWJv dmUuLi4iIGlzIGNvbnZvbHV0ZWQgYW5kIGhhcmQgdG8gZm9sbG93Lg0KICAgIA0KICAgICIuLi4g aG93ZXZlciBpdCBTSE9VTEQgTk9UIHVzZSBzdGF0ZWZ1bCBESENQdjYgdG8gcmVjZWl2ZQ0KICAg ICAgIGEgc2VydmljZSBwcm92aWRlciBtYW5hZ2VkIElQdjYgYWRkcmVzcyI6IElzIHRoYXQgcmVh bGx5IGENCiAgICBub3JtYXRpdmUgcmVxdWlyZW1lbnQsIG9yIGlzIGl0IGEgc3RhdGVtZW50IG9m IGZhY3QgYWJvdXQgZXhpc3RpbmcNCiAgICByZXF1aXJlbWVudHM/DQogICAgDQogICAgIml0IFNI T1VMRCBzZW5kIHRoaXMgdHJhZmZpYw0KICAgICAgIHRvIHRoZSBGaXJzdCBIb3AgUHJvdmlkZXIg Um91dGVyLiIgOiBzdGF0ZW1lbnQgb2YgZmFjdD8NCiAgICANCiAgICAtIDU6ICJUbyByZWR1Y2UN CiAgICAgICB1bmRlc2lyZWQgcmVzb3VyY2UgY29uc3VtcHRpb24gb24gdGhlIEZpcnN0IEhvcCBS b3V0ZXIgdGhlIGRlc2lyZSBpcw0KICAgICAgIHRvIHJlbW92ZSBVRS9zdWJzY3JpYmVyIGNvbnRl eHQgaW4gdGhlIGNhc2Ugb2Ygbm9uLXBlcm1hbmVudCBVRSwgc3VjaA0KICAgICAgIGFzIGluIHRo ZSBjYXNlIG9mIFdpRmkgaG90c3BvdHMgYXMgcXVpY2tseSBhcyBwb3NzaWJsZS4gIg0KICAgIENv bnZvbHV0ZWQgc2VudGVuY2UuDQogICAgDQogICAgIkEgcG9zc2libGUgc29sdXRpb24gaXMgdG8g dXNlIGEgc3Vic2NyaWJlciBpbmFjdGl2aXR5IHRpbWVyIHdoaWNoLCBhZnRlcg0KICAgICAgIHRy YWNraW5nIGEgcHJlLWRlZmluZWQgKGN1cnJlbnRseSB1bnNwZWNpZmllZCkgbnVtYmVyIG9mIG1p bnV0ZXMsDQogICAgICAgZGVsZXRlcyB0aGUgc3Vic2NyaWJlciBjb250ZXh0IG9uIHRoZSBGaXJz dCBIb3AgUm91dGVyLiINCiAgICANCiAgICBzL3doaWNoL3RoYXQgICAoQ29uc2lkZXIgIiAuLi4g dGltZXIgdGhhdCBkZWxldGVzLi4uYWZ0ZXIgYQ0KICAgIHByZWRldGVybWluZWQgbnVtYmVyIG9m IG1pbnV0ZXMiDQogICAgDQogICAgLTc6ICJUaGUNCiAgICAgICBjb21iaW5hdGlvbiBvZiBib3Ro IElQdjYgcHJpdmFjeSBleHRlbnNpb25zIGFuZCBvcGVyYXRvciBiYXNlZA0KICAgICAgIGFzc2ln bm1lbnQgb2YgYSBVbmlxdWUgSVB2NiBQcmVmaXggcGVyIEhvc3QgcHJvdmlkZXMgZWFjaA0KICAg ICAgIGltcGxlbWVudGluZyBvcGVyYXRvciBhIHRvb2wgdG8gbWFuYWdlIGFuZCBwcm92aWRlIHN1 YnNjcmliZXINCiAgICAgICBzZXJ2aWNlcyBhbmQgaGVuY2UgcmVkdWNlcyB0aGUgZXhwZXJpZW5j ZWQgcHJpdmFjeSB3aXRoaW4gZWFjaA0KICAgICAgIG9wZXJhdG9yIGNvbnRyb2xsZWQgZG9tYWlu LiINCiAgICANCiAgICBJIGhhdmUgdHJvdWJsZSBmb2xsb3dpbmcgdGhhdCBzZW50ZW5jZS4gSXMg dGhlIHBvaW50IHRvIHNheSB0aGF0DQogICAgcHJvdmlkaW5nIHRvb2xzIHRvIG1hbmFnZSBhbmQg cHJvdmlkZSBzZXJ2aWNlcyByZWR1Y2VzIHByaXZhY3kgaW4NCiAgICBnZW5lcmFsPyBBcyB3b3Jk ZWQsIGl0IGFsbW9zdCBzb3VuZHMgbGlrZSB0aGlzIGlzIG1lYW50IGFzIGEgZmVhdHVyZSwNCiAg ICB3aGljaCBJIGFzc3VtZSBpcyBub3QgdGhlIGNhc2UuDQogICAgDQogICAgU3BlbmNlciBEYXdr aW5zTm8gT2JqZWN0aW9uDQogICAgDQogICAgQ29tbWVudCAoMjAxNy0wOC0xNSkNCiAgICANCiAg ICBPbmUgbml0Og0KICAgIA0KICAgIFBsZWFzZSBjb25zaWRlciBtb3ZpbmcNCiAgICANCiAgICAg ICBCZW5lZml0cyBvZiB1bmlxdWUNCiAgICAgICBJUHY2IHByZWZpeCBvdmVyIGEgdW5pcXVlIElQ djYgYWRkcmVzcyBmcm9tIHRoZSBzZXJ2aWNlIHByb3ZpZGVyDQogICAgICAgaW5jbHVkZSBpbXBy b3ZlZCBzdWJzY3JpYmVyIGlzb2xhdGlvbiBhbmQgZW5oYW5jZWQgc3Vic2NyaWJlcg0KICAgICAg IG1hbmFnZW1lbnQuDQogICAgDQogICAgdG8gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUgQWJz dHJhY3QuIEnigJltIGFzc3VtaW5nIHRoYXQgdGhpcw0KICAgIGV4cGxhaW5zIHRoZSDigJxuZWVk cyB0aGF0IGhhdmUgYXJpc2Vu4oCdIGluIHRoZSBmaXJzdCBzZW50ZW5jZSBvZiB0aGUNCiAgICBB YnN0cmFjdCwgb2YgY291cnNlLg0KICAgIA0KICAgIE1pcmphIEvDvGhsZXdpbmRObyBPYmplY3Rp b24NCiAgICANCiAgICBDb21tZW50ICgyMDE3LTA4LTE0KQ0KICAgIA0KICAgIFRvIG1lIHRoaXMg c2VlbXMgYXBwcm9yaWF0ZSBmb3IgQkNQOyBJJ20gc2F5aW5nIHRoaXMgYmVjYXVzZSB0aGlzIHdh cw0KICAgIG1lbnRpb25lZCBpbiB0aGUgc2hlcGhlcmQtd3JpdGUtdXAgYXMgaXQgd2FzIGJyb3Vn aHQgdXAgYnkgdGhlIGdlbi1hcnQNCiAgICByZXZpZXcuDQogICAgDQogICAgUGxlYXNlIGFsc28g Y29uc2lkZXIgdGhlIGZvbGxvd2luZyBjb21tZW50IGZyb20gdGhlIGdlbi1hcnQgcmV2aWV3DQog ICAgKFRoYW5rcyBKb2VsISk6DQogICAgIlRoZSBpc3N1ZSBvZiBzdGF0dXMgZm9yIHRoZSBkb2N1 bWVudCAoQkNQIHZzIEluZm9ybWF0aW9uYWwpIGlzIGZvciB0aGUgSUVTRw0KICAgICAgIHRvIGNv bmNsdWRlLiAgSG93ZXZlciwgZXZlbiBpZiBpdCBpcyBhIEJDUCwgYXMgSSB1bmRlcnN0YW5kIHRo ZSBwdXJwb3NlLA0KICAgICAgIHRoaXMgZG9jdW1lbnQgaXMgaW50ZW5kZWQgdG8gZGVzY3JpYmUg dGhlIHByYWN0aWNlcyB0byBiZSB1c2VkIHdoZW4gYQ0KICAgICAgIHByb3ZpZGVyIGhhcyBkZWNp ZGVkIHRvIGRlcGxveSBhIC82NCBwZXIgaG9zdC4gIFRoZSB3b3JkaW5nIHRoYXQgaXMgY2hvc2Vu DQogICAgICAgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgbWFrZXMgaXQgYXBwZWFyIHRoYXQgdGhl IHVuZGVybHlpbmcgZGVjaXNpb24gYWJvdXQNCiAgICAgICBzdWNoIGEgZGVwbG95bWVudCBpcyBh bHNvIGEgcmVjb21tZW5kZWQgcHJhY3RpY2UuIg0KICAgIEkgYWdyZWUgdGhhdCB3b3JkaW5nIGNv dWxkIGJlIG1hZGUgY2xlYXJlciBoZXJlIQ0KICAgIA0KICAgIEFsZXhleSBNZWxuaWtvdk5vIE9i amVjdGlvbg0KICAgIA0KICAgIENvbW1lbnQgKDIwMTctMDgtMTIpDQogICAgDQogICAgUmFkaXVz IHNob3VsZCBoYXZlIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSBvbiBmaXJzdCB1c2UuDQogICAg DQogICAgS2F0aGxlZW4gTW9yaWFydHlObyBPYmplY3Rpb24NCiAgICANCiAgICBDb21tZW50ICgy MDE3LTA4LTE1KQ0KICAgIA0KICAgIFRoYW5rIHlvdSBmb3IgYWRkcmVzc2luZyB0aGUgU2VjRGly IHJldmlldzoNCiAgICBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NlY2Rp ci93V3BfMHZsbXN6N1NzLW5vd2poZWhZSW1PZWcNCiAgICANCiAgICBFcmljIFJlc2NvcmxhTm8g T2JqZWN0aW9uDQogICAgDQogICAgQ29tbWVudCAoMjAxNy0wOC0xNSkNCiAgICANCiAgICBEb2N1 bWVudDogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDcudHh0 DQogICAgDQogICAgDQogICAgSSBmb3VuZCB0aGUgZGlzY3Vzc2lvbiBvZiB0aGUgc2hhcmVkIG5l dHdvcmsgbWVkaXVtIGEgYml0DQogICAgY29uZnVzaW5nLiBBcyBJIHVuZGVyc3RhbmQgaXQsIHRo ZSBpZGVhIGlzIHRoYXQgaWYgd2UgYXJlDQogICAgb24gYSBzaGFyZWQgbmV0d29yayBhbmQgd2Ug aGF2ZSB0aGUgc2FtZSBwcmVmaXgsIEkgbWlnaHQNCiAgICB0cnkgdG8gc2VuZCB0byB5b3UgZGly ZWN0bHkuIFdoYXQgeW91IHdhbnQgdG8gZG8gaXMgbWFrZQ0KICAgIHRoYXQgbm90IGhhcHBlbiBi eSBoYXZpbmcgZWFjaCBub2RlIGhhdmUgYSBzZXBhcmF0ZSBwcmVmaXguDQogICAgQ29ycmVjdD8g SWYgc28sIHBlcmhhcHMgcHJvbW90ZSB0aGlzIGJ1bGxldCwgYW5kIGFsc28gaGF2ZQ0KICAgIGl0 IGRlc2NyaWJlIHRoZSBwcm9ibGVtIGFuZCB3aHkgdGhpcyBwcm92aWRlcyBhIHNvbHV0aW9uOg0K ICAgIA0KICAgICAgIG8gIFR3byBkZXZpY2VzIChzdWJzY3JpYmVyL2hvc3RzKSwgYm90aCBhdHRh Y2hlZCB0byB0aGUgc2FtZSBwcm92aWRlcg0KICAgICAgICAgIG1hbmFnZWQgc2hhcmVkIG5ldHdv cmsgc2hvdWxkIG9ubHkgYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB0aHJvdWdoDQogICAgICAgICAg dGhlIHByb3ZpZGVyIG1hbmFnZWQgRmlyc3QgSG9wIFJvdXRlcg0KICAgIA0KICAgIA0KICAgIEl0 J3MgYSBiaXQgdW5jbGVhciB0byBtZSBob3cgbXVjaCB5b3UgYXJlIHNheWluZyB0aGF0DQogICAg c29tZXRoaW5nIGlzIGN1cnJlbnQgcHJhY3RpY2UgdmVyc3VzIGhvdyBtdWNoIHlvdSBhcmUNCiAg ICByZWNvbW1lbmRpbmcgaXQuIEZvciBpbnN0YW5jZSwgdGhlIGFic3RyYWN0IHJlYWRzIG1vcmUN CiAgICBsaWtlIHdoYXQgeW91IHdvdWxkIGV4cGVjdCBmb3IgUFMuDQogICAgDQogICAgICAgVGhp cyBkb2N1bWVudCBvdXRsaW5lcyBhbiBhcHByb2FjaCB1dGlsaXNpbmcgZXhpc3RpbmcgSVB2NiBw cm90b2NvbHMNCiAgICAgICB0byBhbGxvdyBob3N0cyB0byBiZSBhc3NpZ25lZCBhIHVuaXF1ZSBJ UHY2IHByZWZpeCAoaW5zdGVhZCBvZiBhDQogICAgICAgdW5pcXVlIElQdjYgYWRkcmVzcyBmcm9t IGEgc2hhcmVkIElQdjYgcHJlZml4KS4gIEJlbmVmaXRzIG9mIHVuaXF1ZQ0KICAgICAgIElQdjYg cHJlZml4IG92ZXIgYSB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gdGhlIHNlcnZpY2UgcHJvdmlk ZXINCiAgICAgICBpbmNsdWRlIGltcHJvdmVkIHN1YnNjcmliZXIgaXNvbGF0aW9uIGFuZCBlbmhh bmNlZCBzdWJzY3JpYmVyDQogICAgICAgbWFuYWdlbWVudC4NCiAgICANCiAgICBCdXQgdGhlbiBT IDQgc2VlbXMgdG8gYmUgZG9jdW1lbnRpbmc6DQogICAgDQogICAgICAgVGhlIElQdjYgUkEgZmxh Z3MgdXNlZCBmb3IgYmVzdCBjb21tb24gcHJhY3RpY2UgaW4gSVB2NiBTTEFBQyBiYXNlZA0KICAg ICAgIFByb3ZpZGVyIG1hbmFnZWQgc2hhcmVkIG5ldHdvcmtzIGFyZToNCiAgICANCiAgICANCiAg ICAgICBUaGUgdXNlIG9mIGEgdW5pcXVlIElQdjYgcHJlZml4IHBlciBVRSBhZGRzIGFuIGFkZGl0 aW9uYWwgbGV2ZWwgb2YNCiAgICAgICBwcm90ZWN0aW9uIGFuZCBlZmZpY2llbmN5IGFzIGl0IHJl bGF0ZXMgdG8gaG93IElQdjYgTmVpZ2hib3INCiAgICAgICBEaXNjb3ZlcnkgYW5kIFJvdXRlciBE aXNjb3ZlcnkgcHJvY2Vzc2luZy4gIFNpbmNlIHRoZSBVRSBoYXMgYSB1bmlxdWUNCiAgICAgICBJ UHY2IHByZWZpeCBhbGwgdHJhZmZpYyBieSBkZWZhdWx0IHdpbGwgYmUgZGlyZWN0ZWQgdG8gdGhl IEZpcnN0IEhvcA0KICAgICAgIHByb3ZpZGVyIHJvdXRlci4gIEZ1cnRoZXIsIHRoZSBmbGFnIGNv bWJpbmF0aW9ucyBkb2N1bWVudGVkIGFib3ZlDQogICAgICAgbWF4aW1pc2UgdGhlIElQdjYgY29u ZmlndXJhdGlvbnMgdGhhdCBhcmUgYXZhaWxhYmxlIGJ5IGhvc3RzDQogICAgICAgaW5jbHVkaW5n IHRoZSB1c2Ugb2YgcHJpdmFjeSBJUHY2IGFkZHJlc3NpbmcuDQogICAgDQogICAgSXQncyBub3Qg cXVpdGUgY2xlYXIgdG8gbWUgd2h5IHVuaXF1ZSBwcmVmaXhzIGFyZSBuZWVkZWQgaGVyZSBpZg0K ICAgIHBlb3BsZSBzZXQgTD0wLiBJcyBpdCB0aGF0IHBlb3BsZSBpZ25vcmUgTD0wPw0KICAgIA0K ICAgIEZpbmFsbHksIEknbSBhIGJpdCBjb25mdXNlZCBhYm91dCBob3cgdG8gcmVhZCB0aGlzIHRl eHQgYWJvdXQgdGhlDQogICAgTD0wIGJpdCBpbiBjYXNlcyB3aGVyZSBJIGhhdmUgbXVsdGlwbGUg ZGV2aWNlcyByYXRoZXIgdGhhbiBqdXN0IG9uZQ0KICAgIGF0IHRoZSBjdXN0b21lciBwcmVtLiBT YXkgSSBoYXZlIGEgdG9wb2xvZ3kgd2l0aCBhIGhvbWUgcm91dGVyDQogICAgYW5kIGRldmljZXMg YmVoaW5kIGl0LiBJLmUuLA0KICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgU2VydmljZSBQ cm92aWRlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQ3VzdG9tZXIN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm91dGVyDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSstLS0tLS0tLS0t LSsNCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICB8DQogICAgICAg ICAgICAgICAgIEhvc3QgMSAgICAgIEhvc3QgMiAgICAgIEhvc3QgMw0KICAgIA0KICAgIEkgYXNz dW1lIHdoYXQgaGFwcGVucyBoZXJlIGlzIHRoYXQgdGhlIHJvdXRlciBnZXRzIHByZWZpeCBYLCBh c3NpZ25zDQogICAgaXRzZWxmIFhZLCBhbmQgdGhlbiB0aGUgSG9zdHMgZ2V0IFhBLCBYQiwgWEMs IGV0YywgYSBsYSA3Mjc4LiBJcyB0aGF0DQogICAgcmlnaHQ/IElmIHNvLCBteSBxdWVzdGlvbiBp cyBhYm91dCBwYWNrZXRzIGNvbWluZyBpbnRvIHRoZSBSb3V0ZXIgZnJvbQ0KICAgIHRoZSBTUCwg d2hpY2ggaGF2ZSAoc2F5KSBYQS4gIFRoZSB0ZXh0IGFib3V0IHRoZSBMLWZsYWcgc3VnZ2VzdHMg dGhhdA0KICAgIHRoZSByb3V0ZXIgc2hvdWxkIHNlbmQgdGhlbSBiYWNrIHRvIHRoZSBnYXRld2F5 LCBidXQgdGhhdCdzIGNsZWFybHkNCiAgICBub3QgcmlnaHQuIFdoYXQgYW0gSSBtaXNzaW5nPw0K ICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgIA0KICAgID4gQ2hlZXJzLA0KICAgID4g TG9yZW56bw0KICAgID4NCiAgICA+IE9uIFN1biwgU2VwIDEwLCAyMDE3IGF0IDQ6NDkgQU0sIFdh cnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0PiB3cm90ZToNCiAgICA+Pg0KICAgID4+IFsg VG9wLXBvc3QgXQ0KICAgID4+DQogICAgPj4gWXVwLCBJIHdhcyB0aGlua2luZyB0aGF0LCB3aGls ZSBzdWJzdGFudGl2ZSwgdGhhdCB3b3VsZCBiZSBoYW5kbGVkDQogICAgPj4gd2hpbGUgc3RpbGwg a2VlcGluZyBpdCBpbiBJRVNHIGV2YWwgLS0gYnV0LCBJJ3ZlIGp1c3QgZ29uZSBiYWNrIGFuZA0K ICAgID4+IHJlLXJlYWQgdGhlIHRocmVhZHMsIGVzcGVjaWFsbHkgYWxsIG9mIHRoZSBtYWlsICh+ MTAyKSBhZnRlciB0aGUgSUVTRw0KICAgID4+IC8gdGVsZWNoYXQsIGFuZCBJJ3ZlIGRlY2lkZWQg dGhhdCBJIHdpbGwgaGF2ZSB0byByZXR1cm4gaXQgdG8gdGhlIFdHLg0KICAgID4+IFNlZWluZyBh cyBpdCBoYXMgYWxyZWFkeSBoYWQgYSBXR0xDLCBJIGV4cGVjdCB0aGF0IHRoZSBuZXh0IG9uZSBj YW4gYmUNCiAgICA+PiBjb21wcmVzc2VkLg0KICAgID4+DQogICAgPj4gVGhlIGdvb2QgbmV3cyBp cyB0aGF0IGE6IHRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBzdWdnZXN0aW9ucyAvDQogICAg Pj4gcHJvdmlkZWQgdGV4dCB0byBpbXByb3ZlIHRoZSBkb2N1bWVudCwgYW5kIGI6IEknZCBleHBl Y3QgdGhlIG5leHQgSUVTRw0KICAgID4+IGV2YWwgdG8gZ28gZWFzaWx5Lg0KICAgID4+DQogICAg Pj4gU29ycnkgYWxsLA0KICAgID4+IFcNCiAgICA+Pg0KICAgID4+DQogICAgPj4gT24gTW9uLCBT ZXAgNCwgMjAxNyBhdCA2OjMyIFBNLCBCcmlhbiBFIENhcnBlbnRlcg0KICAgID4+IDxicmlhbi5l LmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KICAgID4+ID4gV2FycmVuLA0KICAgID4+ID4N CiAgICA+PiA+IEkgYmVsaWV2ZSBpdCdzIHN1YnN0YW50aXZlIHRoYXQgdGhlIHRleHQgcmVmZXJz IHRvIHNlbmRpbmcgdW5pY2FzdA0KICAgID4+ID4gUkFzIHdpdGhvdXQgY2xhcmlmeWluZyB3aGV0 aGVyIHRoaXMgbWVhbnMgdGhhdCB0aGV5IGFyZSBzZW50DQogICAgPj4gPiB3aXRoIGEgdW5pY2Fz dCBsYXllciAyIGFkZHJlc3MgYW5kIGEgbXVsdGljYXN0IGxheWVyIDMgYWRkcmVzcw0KICAgID4+ ID4gKGFzIHBlciBSRkM2MDg1KSBvciB0aGF0IHRoZXkgYXJlIHNlbnQgd2l0aCBib3RoIGxheWVy IDIgYW5kDQogICAgPj4gPiBsYXllciAzIGFkZHJlc3NlcyBiZWluZyB1bmljYXN0LiBBdCB0aGUg bW9tZW50LCBhbiBpbXBsZW1lbnRlcg0KICAgID4+ID4gaGFzIHRvIGRlY2lkZSB3aGljaCBvZiB0 aGVzZSBpcyBpbnRlbmRlZC4gSWYgZWl0aGVyIGlzIE9LLA0KICAgID4+ID4gdGhhdCBjb3VsZCBi ZSBzdGF0ZWQgdG9vLg0KICAgID4+ID4NCiAgICA+PiA+IFNwZWNpZmljYWxseSB0aGlzIGNsYXJp ZmljYXRpb24gc2VlbXMgdG8gYmUgbmVlZGVkIHJpZ2h0IGFmdGVyOg0KICAgID4+ID4NCiAgICA+ PiA+PiA0LiAgSVB2NiBVbmlxdWUgUHJlZml4IEFzc2lnbm1lbnQNCiAgICA+PiA+Pg0KICAgID4+ ID4+ICAgIFdoZW4gYSBVRSBjb25uZWN0cyB0byB0aGUgc2hhcmVkIHByb3ZpZGVyIG1hbmFnZWQg bmV0d29yayBhbmQgaXMNCiAgICA+PiA+PiAgICBhdHRhY2hlZCwgaXQgd2lsbCBpbml0aWF0ZSBJ UCBjb25maWd1cmF0aW9uIHBoYXNlLiAgRHVyaW5nIHRoaXMNCiAgICA+PiA+PiBwaGFzZQ0KICAg ID4+ID4+ICAgIHRoZSBVRSB3aWxsLCBmcm9tIGFuIElQdjYgcGVyc3BlY3RpdmUsIGF0dGVtcHQg dG8gbGVhcm4gdGhlIGRlZmF1bHQNCiAgICA+PiA+PiAgICBJUHY2IGdhdGV3YXksIHRoZSBJUHY2 IHByZWZpeCBpbmZvcm1hdGlvbiwgdGhlIEROUyBpbmZvcm1hdGlvbg0KICAgID4+ID4+ICAgIFJG QzgxMDYgW1JGQzgxMDZdLCBhbmQgdGhlIHJlbWFpbmluZyBpbmZvcm1hdGlvbiByZXF1aXJlZCB0 bw0KICAgID4+ID4+ICAgIGVzdGFibGlzaCBnbG9iYWxseSByb3V0YWJsZSBJUHY2IGNvbm5lY3Rp dml0eS4gIEZvciB0aGF0IHB1cnBvc2UsDQogICAgPj4gPj4gdGhlDQogICAgPj4gPj4gICAgdGhl IFVFL3N1YnNjcmliZXIgc2VuZHMgYSBSUyAoUm91dGVyIFNvbGljaXRhdGlvbikgbWVzc2FnZS4N CiAgICA+PiA+Pg0KICAgID4+ID4+ICAgIFRoZSBGaXJzdCBIb3AgUm91dGVyIHJlY2VpdmVzIHRo aXMgVUUvc3Vic2NyaWJlciBSUyBtZXNzYWdlIGFuZA0KICAgID4+ID4+ICAgIHN0YXJ0cyB0aGUg cHJvY2VzcyB0byBjb21wb3NlIHRoZSByZXNwb25zZSB0byB0aGUgVUUvc3Vic2NyaWJlcg0KICAg ID4+ID4+ICAgIG9yaWdpbmF0ZWQgUlMgbWVzc2FnZS4gIFRoZSBGaXJzdCBIb3AgUHJvdmlkZXIg Um91dGVyIHdpbGwgYW5zd2VyDQogICAgPj4gPj4gICAgdXNpbmcgYSB1bmljYXN0IFJBIChSb3V0 ZXIgQWR2ZXJ0aXNlbWVudCkgdG8gdGhlIFVFL3N1YnNjcmliZXIuDQogICAgPj4gPg0KICAgID4+ ID4gUmVnYXJkcw0KICAgID4+ID4gICAgQnJpYW4gQ2FycGVudGVyDQogICAgPj4gPg0KICAgID4+ ID4gT24gMDUvMDkvMjAxNyAwOTo0MywgV2FycmVuIEt1bWFyaSB3cm90ZToNCiAgICA+PiA+PiBJ J2QgbGlrZSB0byBub3RlIHRoYXQgdGhhdCB0aGVyZSBpcyBjb250aW51aW5nIGRpc2N1c3Npb24g b24gdGhpcw0KICAgID4+ID4+IGRyYWZ0IG9uIHRoZSB2NiBvcHMgbGlzdCAoeXVwLCBhZnRlciBX R0xDIGFuZCBJRVRGIExDIDotKSkuIEkndmUgb25seQ0KICAgID4+ID4+IGJlZW4gYWJsZSB0byBz b21ld2hhdCBtb25pdG9yIGl0LCBidXQgaGF2ZSBhc2tlZCB0aGUgdjZvcHMgY2hhaXJzIGZvcg0K ICAgID4+ID4+IGlucHV0LiBNdWNoIG9mIHRoZSBkaXNjdXNzaW9uIGhhcyBiZWVuIGludGVyZXN0 aW5nLCBidXQgbm90DQogICAgPj4gPj4gbmVjZXNzYXJpbHkgcGVydGFpbmluZyBleGFjdGx5IHRv IHRoaXMgZG9jdW1lbnQuDQogICAgPj4gPj4gRnJlZCBraW5kbHkgYXNrZWQgdGhlIGxpc3Q6DQog ICAgPj4gPj4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy92Nm9wcy9icEVE dG5Za2J2SlFaQXhfcjZtdEVoZE54cncNCiAgICA+PiA+PiBmb3IgYW55dGhpbmcgc3Vic3RhbnRp dmUgZm9yIHRoZSBkb2N1bWVudCAoa2VlcGluZyBpbiBtaW5kIHRoYXQgaXQgaGFzDQogICAgPj4g Pj4gYWxyZWFkeSBnb25lIHRocm91Z2ggV0dMQyBhbmQgSUVURiBMQykuDQogICAgPj4gPj4NCiAg ICA+PiA+PiBTbyBmYXIgaXQgZG9lc24ndCBzZWVtIGxpa2UgdGhlcmUgYXJlIGFueSBvdGhlciBt YWpvciBjaGFuZ2VzIG5lZWRlZCwNCiAgICA+PiA+PiBvdGhlciB0aGFuICJhc2tpbmcgdGhhdCB0 aGUgYXBwbGljYWJpbGl0eSBjb21tZW50IHRoYXQgY29tbXVuaWNhdGlvbg0KICAgID4+ID4+IGJl dHdlZW4gc3VjaCBub2RlcyBvbiBhIExBTiBzaG91bGQgZ28gdGhyb3VnaCBhIGNvbm5lY3Rpbmcg cm91dGVyDQogICAgPj4gPj4gKHdoaWNoIHNlZW1zIHRvIG1lIGEgZ2l2ZW4gZHVlIHRvIHRoZSBy ZWxhdGlvbnNoaXAgd2l0aCByb3V0aW5nKQ0KICAgID4+ID4+IHNob3VsZCBiZSBkb2N1bWVudGVk LiIgYW5kIERhdmlkIEZhcm1lcidzIGZvbGxvd3VwIC0tDQogICAgPj4gPj4gaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy92Nm9wcy9fLVFsQnFHazlkQ2hvRk9oeGlnZjVXbHhZ RFkNCiAgICA+PiA+Pg0KICAgID4+ID4+IERvZXMgYW55b25lIGhhdmUgYW55dGhpbmcgZWxzZSAq c3Vic3RhbnRpdmUqPyBJZiBzbywgSSBtYXkgaGF2ZSB0bw0KICAgID4+ID4+IGtpY2sgdGhpcyBi YWNrIHRvIHRoZSBXRyBmb3IgYW5vdGhlciByb3VuZC4NCiAgICA+PiA+Pg0KICAgID4+ID4+IFcN CiAgICA+PiA+Pg0KICAgID4+ID4+DQogICAgPj4gPj4NCiAgICA+PiA+Pg0KICAgID4+ID4+IE9u IFR1ZSwgQXVnIDIyLCAyMDE3IGF0IDc6MzEgUE0sIFN1cmVzaCBLcmlzaG5hbg0KICAgID4+ID4+ IDxzdXJlc2gua3Jpc2huYW5AZ21haWwuY29tPiB3cm90ZToNCiAgICA+PiA+Pj4gSGkgR3VudGVy LA0KICAgID4+ID4+PiAgIFRoYW5rcyBmb3IgdGhlIHByb3Bvc2VkIHRleHQgY2hhbmdlcy4gVGhl eSBhZGVxdWF0ZWx5IGFkZHJlc3MgbXkNCiAgICA+PiA+Pj4gRElTQ1VTUw0KICAgID4+ID4+PiBw b2ludHMuIEkgYW0gaG9waW5nIHlvdSB3aWxsIGFsc28gY29udmVyZ2UgaW4gdGhlIGRpc2N1c3Np b24gd2l0aA0KICAgID4+ID4+PiBMb3JlbnpvIG9uDQogICAgPj4gPj4+IHRoZSBhY3R1YWwgdmFs dWUgZm9yIHRoZSB0aW1lciBhbmQvb3Igc3BlY2lmeSBhbiBhcHBsaWNhYmlsaXR5DQogICAgPj4g Pj4+IHN0YXRlbWVudC4gSQ0KICAgID4+ID4+PiB3aWxsIGNsZWFyIG9uY2UgdGhlIG5ldyByZXZp c2lvbiBwb3N0cy4NCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gUmVnYXJkcw0KICAgID4+ID4+PiBT dXJlc2gNCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gT24gQXVnIDIxLCAyMDE3LCBhdCA4OjU3IEFN LCBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKQ0KICAgID4+ID4+PiA8 Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+IHdyb3RlOg0KICAgID4+ID4+Pg0KICAgID4+ ID4+PiBIaSBTdXJlc2gsDQogICAgPj4gPj4+DQogICAgPj4gPj4+IE1hbnkgdGhhbmtzIGZvciB0 aGUgcmV2aWV3IGFuZCBmaW5kaW5nIHRoZXNlIGlzc3Vlcy4gV2hhdCBkbyB5b3UgdGhpbmsNCiAg ICA+PiA+Pj4gb2YNCiAgICA+PiA+Pj4gdGhlIHByb3Bvc2FscyBiZWxvdyB0byBmaXggdGhvc2Ug cG9pbnRzIG9mIGF0dGVudGlvbj8NCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KICAgID4+ID4+PiAgICBESVNDVVNTOg0KICAgID4+ID4+Pg0KICAgID4+ ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPj4gPj4+DQogICAgPj4gPj4+ICAgICogU2VjdGlvbiA0 DQogICAgPj4gPj4+DQogICAgPj4gPj4+ICAgIEl0IGlzIG5vdCBjbGVhciB3aGF0IHlvdSBpbnRl bmQgaGVyZQ0KICAgID4+ID4+Pg0KICAgID4+ID4+PiAgICAiSVB2NiBSb3V0ZXIgQWR2ZXJ0aXNl bWVudCBJbnRlcnZhbCA9IDMwMHMiDQogICAgPj4gPj4+DQogICAgPj4gPj4+ICAgIFRoZSByb3V0 ZXIgYWR2ZXJ0aXNlbWVudCBpbnRlcnZhbCBpcyBub3QgY29uZmlndXJlZCBhcyBhbiBhYnNvbHV0 ZQ0KICAgID4+ID4+PiB2YWx1ZQ0KICAgID4+ID4+PiBidXQgYXMNCiAgICA+PiA+Pj4gICAgbWlu aW11bSBhbmQgbWF4aW11bSBib3VuZHMgKE1pblJ0ckFkdkludGVydmFsIGFuZA0KICAgID4+ID4+ PiBNYXhSdHJBZHZJbnRlcnZhbCkNCiAgICA+PiA+Pj4gd2hpY2ggYXJlDQogICAgPj4gPj4+ICAg IHVzZWQgdG8gY2FsY3VsYXRlIHRoZSBhY3R1YWwgYWR2ZXJ0aXNlbWVudCBpbnRlcnZhbC4gV2hl biB0aGUgUkEgaXMNCiAgICA+PiA+Pj4gc2VudA0KICAgID4+ID4+PiBmcm9tDQogICAgPj4gPj4+ ICAgIGFuIGludGVyZmFjZSwgdGhlIGFjdHVhbCBpbnRlcnZhbCBpcyBhbiB1bmlmb3JtbHkgZGlz dHJpYnV0ZWQNCiAgICA+PiA+Pj4gcmFuZG9tDQogICAgPj4gPj4+IHZhbHVlDQogICAgPj4gPj4+ ICAgIGJldHdlZW4gdGhlIE1pblJ0ckFkdkludGVydmFsIGFuZCBNYXhSdHJBZHZJbnRlcnZhbC4g QXQgdGhlIHZlcnkNCiAgICA+PiA+Pj4gbWluaW11bQ0KICAgID4+ID4+PiB5b3UNCiAgICA+PiA+ Pj4gICAgbmVlZCB0byBjbGFyaWZ5IGlmIHlvdSB3b3VsZCBsaWtlIHRvIGhhdmUgdGhpcyBhcyBh IGxvd2VyIGJvdW5kIG9yDQogICAgPj4gPj4+IGFzIGFuDQogICAgPj4gPj4+IHVwcGVyDQogICAg Pj4gPj4+ICAgIGJvdW5kLg0KICAgID4+ID4+Pg0KICAgID4+ID4+PiBHVj4gSSBjaGFuZ2VkIHRo ZSBsaW5lIHRvIG1ha2UgaXQgbW9yZSBjbGVhciB0aGF0IHRoZSB0aW1lciBpbmRpY2F0ZXMNCiAg ICA+PiA+Pj4gdGhlDQogICAgPj4gPj4+IG1heGltdW0gQWR2ZXJ0aXNlbWVudCBJbnRlcnZhbA0K ICAgID4+ID4+PiBHVj4gICAgICAgICAgPHQ+TWF4aW11bSBJUHY2IFJvdXRlciBBZHZlcnRpc2Vt ZW50IEludGVydmFsID0gMzAwczwvdD4NCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4NCiAgICA+PiA+ Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KICAgID4+ID4+PiAgICBDT01NRU5UOg0KICAgID4+ID4+Pg0KICAg ID4+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPj4gPj4+DQogICAgPj4gPj4+ICAgICogU2VjdGlv biA0DQogICAgPj4gPj4+DQogICAgPj4gPj4+ICAgIC0+IEkgdGhpbmsgdGV4dCBpcyBuZWVkZWQg aGVyZSB0byBoYW5kbGUgdGhlIGNhc2Ugd2hlcmUgdGhlIEROUw0KICAgID4+ID4+PiBzZXJ2ZXIg aXMNCiAgICA+PiA+Pj4gICAgcHJvdmlkZWQgaW4gdGhlIFJBIGl0c2VsZiAgKFJGQzgxMDYpDQog ICAgPj4gPj4+DQogICAgPj4gPj4+ICAgICJJbiBhZGRpdGlvbiBpdCB3aWxsIHVzZSBzdGF0ZWxl c3MgREhDUHY2IHRvIGdldCB0aGUgSVB2NiBhZGRyZXNzDQogICAgPj4gPj4+IG9mIHRoZQ0KICAg ID4+ID4+PiBETlMNCiAgICA+PiA+Pj4gICAgc2VydmVyIg0KICAgID4+ID4+Pg0KICAgID4+ID4+ PiAgICAtPiBJIGFtIG5vdCBzdXJlIHdoYXQgaXMgdGhlIG1vdGl2YXRpb24gZm9yIHRoaXMgdGV4 dC4NCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gICAgImhvd2V2ZXIgaXQgU0hPVUxEIE5PVCB1c2Ug c3RhdGVmdWwgREhDUHY2IHRvIHJlY2VpdmUgYSBzZXJ2aWNlDQogICAgPj4gPj4+IHByb3ZpZGVy DQogICAgPj4gPj4+ICAgIG1hbmFnZWQgSVB2NiBhZGRyZXNzIg0KICAgID4+ID4+Pg0KICAgID4+ ID4+PiAgICAtPiBUaGlzIHRleHQgc2VlbXMgaW5jb3JyZWN0DQogICAgPj4gPj4+DQogICAgPj4g Pj4+ICAgICJkdWUgdG8gdGhlIEwtYml0IHNldCwgaXQgU0hPVUxEIHNlbmQgdGhpcyB0cmFmZmlj IHRvIHRoZSBGaXJzdCBIb3ANCiAgICA+PiA+Pj4gUHJvdmlkZXINCiAgICA+PiA+Pj4gICAgUm91 dGVyIg0KICAgID4+ID4+Pg0KICAgID4+ID4+PiAgICBJIHRoaW5rIGl0IHNob3VsZCBiZSB0aGUg ZXhhY3Qgb3Bwb3NpdGUuIGkuZS4gc2F5ICp1bnNldCogaW5zdGVhZA0KICAgID4+ID4+PiBvZiBz ZXQNCiAgICA+PiA+Pj4NCiAgICA+PiA+Pj4gICAgImR1ZSB0byB0aGUgTC1iaXQgYmVpbmcgdW5z ZXQsIGl0IFNIT1VMRCBzZW5kIHRoaXMgdHJhZmZpYyB0byB0aGUNCiAgICA+PiA+Pj4gRmlyc3QN CiAgICA+PiA+Pj4gSG9wDQogICAgPj4gPj4+ICAgIFByb3ZpZGVyIFJvdXRlciINCiAgICA+PiA+ Pj4NCiAgICA+PiA+Pj4gR1Y+IFdoYXQgYWJvdXQgdGhlIGZvbGxvd2luZyBtb2RpZmljYXRpb24g aW4gdGhlIHRleHQ6DQogICAgPj4gPj4+DQogICAgPj4gPj4+IE9MRDoNCiAgICA+PiA+Pj4gVGhl IGFyY2hpdGVjdGVkIHJlc3VsdCBvZiBkZXNpZ25pbmcgdGhlIFJBIGFzIGRvY3VtZW50ZWQgYWJv dmUgaXMNCiAgICA+PiA+Pj4gICB0aGF0IGVhY2ggVUUvc3Vic2NyaWJlciBnZXRzIGl0cyBvd24g dW5pcXVlIElQdjYgcHJlZml4IGZvciB3aGljaCBpdA0KICAgID4+ID4+PiAgIGNhbiB1c2UgU0xB QUMgb3IgYW55IG90aGVyIG1ldGhvZCB0byBzZWxlY3QgaXRzIC8xMjggdW5pcXVlIGFkZHJlc3Mu DQogICAgPj4gPj4+ICAgSW4gYWRkaXRpb24gaXQgd2lsbCB1c2Ugc3RhdGVsZXNzIERIQ1B2NiB0 byBnZXQgdGhlIElQdjYgYWRkcmVzcyBvZg0KICAgID4+ID4+PiAgIHRoZSBETlMgc2VydmVyLCBo b3dldmVyIGl0IFNIT1VMRCBOT1QgdXNlIHN0YXRlZnVsIERIQ1B2NiB0byByZWNlaXZlDQogICAg Pj4gPj4+ICAgYSBzZXJ2aWNlIHByb3ZpZGVyIG1hbmFnZWQgSVB2NiBhZGRyZXNzLiAgSWYgdGhl IFVFL3N1YnNjcmliZXINCiAgICA+PiA+Pj4gICBkZXNpcmVzIHRvIHNlbmQgYW55dGhpbmcgZXh0 ZXJuYWwgaW5jbHVkaW5nIG90aGVyIFVFL3N1YnNjcmliZXINCiAgICA+PiA+Pj4gICBkZXZpY2Vz IChhc3N1bWluZyBkZXZpY2UgdG8gZGV2aWNlIGNvbW11bmljYXRpb25zIGlzIGVuYWJsZWQgYW5k DQogICAgPj4gPj4+ICAgc3VwcG9ydGVkKSwgdGhlbiwgZHVlIHRvIHRoZSBMLWJpdCBzZXQsIGl0 IFNIT1VMRCBzZW5kIHRoaXMgdHJhZmZpYw0KICAgID4+ID4+PiAgIHRvIHRoZSBGaXJzdCBIb3Ag UHJvdmlkZXIgUm91dGVyLg0KICAgID4+ID4+Pg0KICAgID4+ID4+PiBOZXc6DQogICAgPj4gPj4+ IFRoZSBhcmNoaXRlY3RlZCByZXN1bHQgb2YgZGVzaWduaW5nIHRoZSBSQSBhcyBkb2N1bWVudGVk IGFib3ZlIGlzDQogICAgPj4gPj4+IHRoYXQgZWFjaCBVRS9zdWJzY3JpYmVyIGdldHMgaXRzIG93 biB1bmlxdWUgSVB2NiBwcmVmaXggZm9yIHdoaWNoIGl0DQogICAgPj4gPj4+IGNhbiB1c2UgU0xB QUMgb3IgYW55IG90aGVyIG1ldGhvZCB0byBzZWxlY3QgaXRzIC8xMjggdW5pcXVlIGFkZHJlc3Mu DQogICAgPj4gPj4+IEVpdGhlciBzdGF0ZWxlc3MgREhDUHY2IDx4cmVmIHRhcmdldD0iUkZDMzcz NiI+UkZDMzczNjwveHJlZj4gb3IgSVB2Ng0KICAgID4+ID4+PiBSb3V0ZXIgQWR2ZXJ0aXNlbWVu dCBPcHRpb25zIGZvciBETlMgQ29uZmlndXJhdGlvbg0KICAgID4+ID4+PiA8eHJlZiB0YXJnZXQ9 IlJGQzgxMDYiPlJGQzgxMDY8L3hyZWY+IGNhbiBiZSB1c2VkIHRvIGdldCB0aGUNCiAgICA+PiA+ Pj4gSVB2NiBhZGRyZXNzIG9mIHRoZSBETlMgc2VydmVyLiBJZiB0aGUgVUUvc3Vic2NyaWJlciBk ZXNpcmVzIHRvIHNlbmQNCiAgICA+PiA+Pj4gYW55dGhpbmcgZXh0ZXJuYWwgaW5jbHVkaW5nIG90 aGVyIFVFL3N1YnNjcmliZXIgZGV2aWNlcyAoYXNzdW1pbmcNCiAgICA+PiA+Pj4gZGV2aWNlDQog ICAgPj4gPj4+IHRvIGRldmljZSBjb21tdW5pY2F0aW9ucyBpcyBlbmFibGVkIGFuZCBzdXBwb3J0 ZWQpLCB0aGVuLCBkdWUgdG8gdGhlDQogICAgPj4gPj4+IEwtYml0IGJlaW5nIHVuc2V0LCBpdCBT SE9VTEQgc2VuZCB0aGlzIHRyYWZmaWMgdG8gdGhlIEZpcnN0IEhvcA0KICAgID4+ID4+PiBQcm92 aWRlcg0KICAgID4+ID4+PiBSb3V0ZXIuPC90Pg0KICAgID4+ID4+Pg0KICAgID4+ID4+Pg0KICAg ID4+ID4+Pg0KICAgID4+ID4+PiBLaW5kIFJlZ2FyZHMsDQogICAgPj4gPj4+IEcvDQogICAgPj4g Pj4+DQogICAgPj4gPj4+DQogICAgPj4gPj4NCiAgICA+PiA+Pg0KICAgID4+ID4+DQogICAgPj4N CiAgICA+Pg0KICAgID4+DQogICAgPj4gLS0NCiAgICA+PiBJIGRvbid0IHRoaW5rIHRoZSBleGVj dXRpb24gaXMgcmVsZXZhbnQgd2hlbiBpdCB3YXMgb2J2aW91c2x5IGEgYmFkDQogICAgPj4gaWRl YSBpbiB0aGUgZmlyc3QgcGxhY2UuDQogICAgPj4gVGhpcyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQg d2Vhc2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIgZXhwcmVzc2luZw0KICAgID4+IHJlZ3Jl dCBhdCBoYXZpbmcgY2hvc2VuIHRob3NlIHBhcnRpY3VsYXIgcmFiaWQgd2Vhc2VscyBhbmQgdGhh dCBwYWlyDQogICAgPj4gb2YgcGFudHMuDQogICAgPj4gICAgLS0tbWFmDQogICAgPj4NCiAgICA+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4+ IHY2b3BzIG1haWxpbmcgbGlzdA0KICAgID4+IHY2b3BzQGlldGYub3JnDQogICAgPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KICAgID4NCiAgICA+DQogICAg DQogICAgDQogICAgDQogICAgLS0gDQogICAgSSBkb24ndCB0aGluayB0aGUgZXhlY3V0aW9uIGlz IHJlbGV2YW50IHdoZW4gaXQgd2FzIG9idmlvdXNseSBhIGJhZA0KICAgIGlkZWEgaW4gdGhlIGZp cnN0IHBsYWNlLg0KICAgIFRoaXMgaXMgbGlrZSBwdXR0aW5nIHJhYmlkIHdlYXNlbHMgaW4geW91 ciBwYW50cywgYW5kIGxhdGVyIGV4cHJlc3NpbmcNCiAgICByZWdyZXQgYXQgaGF2aW5nIGNob3Nl biB0aG9zZSBwYXJ0aWN1bGFyIHJhYmlkIHdlYXNlbHMgYW5kIHRoYXQgcGFpcg0KICAgIG9mIHBh bnRzLg0KICAgICAgIC0tLW1hZg0KICAgIA0KDQo= From nobody Wed Sep 13 07:47:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D9B133047 for ; Wed, 13 Sep 2017 07:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xzvTB43NxTR for ; Wed, 13 Sep 2017 07:47:14 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA23013305C for ; Wed, 13 Sep 2017 07:47:11 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id i50so1164084qtf.0 for ; Wed, 13 Sep 2017 07:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=E2beGj56BhcjaXzAnEBGpBpTDMCF5zv43uedjrHhcKk=; b=l0t0mI03XYxmQYlD1HQX8W9jISwn9vgjyU0yna8bhSmKnykeTzC3uE+s3ea1r1cFqu c4ODrFU1kxace55DdzA6Jtr1ZBoVmbSVnLX4AK619qoPfYmU6Qa3m6i3UmJBY7iX9PgB 9OkzjhjBKbyflXa1tbSnjW0SYO1NukrZ9c9ypAYhDOZQzSijAY6q4FLwFHqgOZg4Ar6W YhpDmWBZOV5qszOolmBxlkFYXYP3g2UCurbXRqKgA5KYdCcINSSrBFEhHeBjuG+BwUDS CiJ6yUo1yJ1lf8Pla8uEdwO5RrdrPCZJUM/OeneraESEGKfU5LnJLFsI3LHhFptcySWt DajQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=E2beGj56BhcjaXzAnEBGpBpTDMCF5zv43uedjrHhcKk=; b=XZOfuxoULctNu1Fy/BYAAcTrW6FfHtr41sUTaNSKPPW1fxH5Q77GTw3JNXk2z4U97U ++rO0UD/DRNHgSKylO2Difcn3ginP8FFA27IaJVyWltf3paJRIl8FxE1iW7WLgR6A31N JXVkUCuKUIq+feEiQk+nQb3vWW9da8fE5goyww7xzCRmLApWX+5pvLOB4ZKkFAuanYT1 PfzNvebDN6FJRjv4CT/+Jww9H4cHB8xHS2lVJ9iAyr75VN3vZEgkAiQ7eBS+uGTAhmLl fuzHrqDdmZc0z/e3tdKXvfUjvdInClmMwmtNW9i5C+SDM/pIu2E5fiOI4gF4ZCB6rOSV 1fzg== X-Gm-Message-State: AHPjjUhFphqOku8cwk08htNi2bCU8kA3YV+Xv7P+iPKM6p9wXLkZCp6y LsdG3/jO9gQBAW+3y4trIdUazwV8YXEkeoIERGc= X-Google-Smtp-Source: AOwi7QAlIHgo+JO4EoWNFydNE3MC83wSsxAMLUJA3LkeMOIyoMhcXKEPZtfz0470FeF4fTAKiYQTuWhg09Drn6TDAJI= X-Received: by 10.200.39.189 with SMTP id w58mr13624061qtw.246.1505314030674; Wed, 13 Sep 2017 07:47:10 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.200.54.104 with HTTP; Wed, 13 Sep 2017 07:47:10 -0700 (PDT) In-Reply-To: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <85f3ebd4-0493-221c-ae05-826ca02f5d2a@gmail.com> <19d26495-b9d9-970f-bdc1-5e35e46a28c6@gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Wed, 13 Sep 2017 07:47:10 -0700 X-Google-Sender-Auth: JNxHaKmeosIDLxWMZ9byIQpndvo Message-ID: To: Ole Troan Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 14:47:16 -0000 At Wed, 13 Sep 2017 09:14:25 +0200, Ole Troan wrote: > > My interpretation of the draft has always been that it explains *one* > > way to provide each individual host with a unique IPv6 prefix for > > *some* environments. While it mildly recommends their way for others > > who share the same motivation, it doesn't insist that's *the* only way > > to operate an IPv6 network or it doesn't change any protocol > > specifications. I've just re-read the entire 07 version of the draft > > and still have the same impression. > > The document has: > Intended status: Best Current Practice > > I think when something has that label, people unsurprisingly reads it as _the_ recommended way of doing things. > It also labels doing it any other way as not best current practice. I see it, but even so, and even if I were a kind of operator who wants to allow p2p host communication in the link, I'd have no problem with the proposal of this draft. It's pretty clear to me that not allowing it is part of its motivation and it's 'the best current practice' when you have that motivation. If I don't share that motivation I would just consider it not applicable to my use case. That said... > A simple fix to those concerns are: > s/Best Current Practice/Informational ...I have no problem with this resolution. After all, I have no stake in the proposal of this draft, and I don't care about its document category. I just think the current discussion is unproductive. I'd welcome any easy way out from it. -- jinmei From nobody Wed Sep 13 09:06:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F377A1323B4 for ; Wed, 13 Sep 2017 09:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzSU6D4d4akS for ; Wed, 13 Sep 2017 09:06:30 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6087E1321AC for ; Wed, 13 Sep 2017 09:06:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8DG6S8k022924; Wed, 13 Sep 2017 09:06:29 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8DG6LNA022832 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 09:06:22 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Sep 2017 09:06:20 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 13 Sep 2017 09:06:20 -0700 From: "Templin, Fred L" To: Ole Troan , =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= CC: "v6ops@ietf.org" Thread-Topic: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) Thread-Index: AQHTJcbyZ/JGPtSOiEKRi/iUYLBZ76KmYOMAgAwTgfiAAJR1kA== Date: Wed, 13 Sep 2017 16:06:20 +0000 Message-ID: <22fa9d1a40554642977bb5626f3200d5@XCH15-06-08.nw.nos.boeing.com> References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <0ca0ceb8edb34125bd680667b1d77dfe@XCH15-06-08.nw.nos.boeing.com> <85f3ebd4-0493-221c-ae05-826ca02f5d2a@gmail.com> <19d26495-b9d9-970f-bdc1-5e35e46a28c6@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 16:06:32 -0000 +1 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ole Troan > Sent: Wednesday, September 13, 2017 12:14 AM > To: =1B$B?@L@C#:H=1B(B > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique= -ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) >=20 > > > > +1. I don't even understand why we are discussing this level of > > things in the context of draft-ietf-v6ops-unique-ipv6-prefix-per-host. > > > > My interpretation of the draft has always been that it explains *one* > > way to provide each individual host with a unique IPv6 prefix for > > *some* environments. While it mildly recommends their way for others > > who share the same motivation, it doesn't insist that's *the* only way > > to operate an IPv6 network or it doesn't change any protocol > > specifications. I've just re-read the entire 07 version of the draft > > and still have the same impression. >=20 > The document has: > Intended status: Best Current Practice >=20 > I think when something has that label, people unsurprisingly reads it as = _the_ recommended way of doing things. > It also labels doing it any other way as not best current practice. >=20 > A simple fix to those concerns are: > s/Best Current Practice/Informational >=20 > Ole From nobody Wed Sep 13 10:40:07 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8D9133083; Wed, 13 Sep 2017 10:39:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org, Ron Bonica , draft-ietf-v6ops-unique-ipv6-prefix-per-host.all@ietf.org, v6ops-chairs@ietf.org, rbonica@juniper.net, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150532438516.30425.4032435990856813297.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 10:39:45 -0700 Archived-At: Subject: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-unique-ipv6-prefix-per-host-08: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 17:39:45 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-v6ops-unique-ipv6-prefix-per-host-08: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS and COMMENTs. From nobody Wed Sep 13 10:40:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB8A132403; Wed, 13 Sep 2017 10:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtWCDIboTpJc; Wed, 13 Sep 2017 10:40:52 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6F81320D9; Wed, 13 Sep 2017 10:40:52 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id k101so5245835iod.0; Wed, 13 Sep 2017 10:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wMOzfRReq9/H0VYnlVqFtv+GoWSrppqjdUlxRBXZbLY=; b=Y0YwIU6MhByjzm1gkjcxjAlQ8e3Ko21Qs1xnokNqufGRL2Us2ItAYqbkSxfdOCV9nu rYKFQqDD74l5xlyUCIr0zzslPEfzNp1TYMgt1czldLGaepNiOVWLGl3u+4s7GjL552Ry EZZ7u4+SADhv/0u0Nx9fjjZZ/moYZU8TIQU9+myzNckyb+gF3LhSc9mgoHUN/nLMonJ8 OdN5o8s3B4tAdZUeZRs0WDOBbKQQDTk7HcRROM2ERu75I1M/L85Ac1Mxyssk2CdCkwOX RCAmrucHv6eMnuKhdyjDj+aKNiq6d7lDQFHVuZNIOS2zYs6+qF3kQ0VPbL/2nf63rJTz JQjg== 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=wMOzfRReq9/H0VYnlVqFtv+GoWSrppqjdUlxRBXZbLY=; b=MtKuHP3VugplH3vS3to2ipBp1WGUNDdU6N4jWH6U9BSDo9Elgz7XXIab+nsYzLBGvi b02GyYydRnuHD8T03Cv1SmIPadwnaTGlTKdysGx3lTKxh4B9R0haD2NZNQ/ct0NhXk7M WWGl2iXNKnDfgioN7fuGn9/DIcEJV/v4xhnojWaJpDSch4xpnPe5NKHH4Ch9uasbsN36 OhK3c9jvnsoB0oQmbd0M4uClfiEiSmbH7DbieGelzMGxqLrh+rIkdP/GqpWx4exSfaev Dr5B3VNNgKQhDkwVyKIvcvTUEsGSuhKXx+5kUcJ9xwsKsX9ypFlomjfN5cdNLDIvqF/C p6iw== X-Gm-Message-State: AHPjjUj9+prQ5TtTZD8Vq2a/hyRvEIvl1lcF8c3YsTfbVrvjgueOBIpf 034mxWXiOlvC/A== X-Google-Smtp-Source: AOwi7QD9q2TqqAkm1RRnFBR2AQdfR1DABsohd4l5Tv8JHUMeg+jm8vGcfqLrRFfk7uO2GQKN6HEgDw== X-Received: by 10.107.11.13 with SMTP id v13mr28240149ioi.225.1505324450767; Wed, 13 Sep 2017 10:40:50 -0700 (PDT) Received: from [192.168.36.124] ([67.22.228.35]) by smtp.gmail.com with ESMTPSA id p124sm1323203ite.3.2017.09.13.10.40.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 10:40:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Suresh Krishnan In-Reply-To: <961C9C36-C4DA-4D84-8A0C-97EB15BD9A36@nokia.com> Date: Wed, 13 Sep 2017 13:40:48 -0400 Cc: Warren Kumari , Lorenzo Colitti , Brian E Carpenter , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <961C9C36-C4DA-4D84-8A0C-97EB15BD9A36@nokia.com> To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 17:40:56 -0000 Thanks Gunter and John. The new version addresses my DISCUSS and = COMMENTs. I have cleared. Regards Suresh > On Sep 13, 2017, at 10:11 AM, Van De Velde, Gunter (Nokia - = BE/Antwerp) wrote: >=20 > New version is submitted, taking the IETF LC comments into account, = including Suresh comment about maximum RA interval and Lorenzo=E2=80=99s = substantial note about 300s vs 600s RA interval for battery constraint = devices.=20 >=20 > G/ >=20 >=20 > On 10/09/2017, 23:04, "Warren Kumari" wrote: >=20 > [ - IESG, -Gunter (he gets a copy as part of > draft-ietf-v6ops-unique-ipv6-prefix-per-host@), -v6chairs@ ] >=20 >=20 >=20 > On Sat, Sep 9, 2017 at 8:58 PM, Lorenzo Colitti = wrote: >> Warren, >>=20 >> care to summarize the main issues that caused you to do this? We'll = want to >> make sure we don't spend too much time discussing issues that did not >> materially impact this decision. >>=20 >=20 > Sure. >=20 > During IESG review, some of the IESG raised questions and suggested > text to improve the document. We received responses from the = authors > saying that the questions, along with Suresh's DISCUSS, would be > addressed. We did not see an updated draft, and it's difficult to = keep > the patched version in one's head. So, I don't know exactly what it > looks like now, but here are some of the considerations that > influenced my decision: >=20 > 1: Brian Carpenter's: > "I believe it's substantive that the text refers to sending unicast > RAs without clarifying whether this means that they are sent > with a unicast layer 2 address and a multicast layer 3 address > (as per RFC6085) or that they are sent with both layer 2 and > layer 3 addresses being unicast. At the moment, an implementer > has to decide which of these is intended. If either is OK, > that could be stated too.". >=20 > 2: Fred Templin's "unless the shared network explicitly permits > peer-to-peer operations" -- in my view adding this exact text = didn't > seem to have support, but clarifying what is meant by a "shared > network" would be useful. > This was also mentioned in EKR's ballot -- ballot text is all below = (I > don't want it to get lost when being LCed). >=20 > 3: I do not believe that I ever saw a resolution to Lorenzo's "I'll > also point out yet again that this value is in conflict with RFC = 7772 > in the case of networks that are provide service for = battery-powered > devices. The text should either be changed to follow that RFC or to > explain the reason for the conflict." -- I personally don't care = what > the value is (I wasn't really thinking that this would occur much = on > battery-powered devices, but I may be completely wrong), but I *do* > think that if it conflicts with RFC 7772 it needs to note this. >=20 > 4: Much of the thread above David Farmer's > = https://mailarchive.ietf.org/arch/msg/v6ops/i72cb0r6fVbxhZLhr4qybppwP6Q >=20 > 5: Simply the amount of discussion after IESG eval, and IETF LC (I > think that the number is something like 100 and >350 respectively) = -- > while many of them wandered afar from the actual draft (and, often, > topic :-)) it is hard to make the claim that the document is really > clear and has strong consensus from this. >=20 >=20 > I'd note that #1, 2, and 4 are very closely related, and I think > should be fairly easily addressed. I'm also happy for the chairs to > have a compressed 2 WGLC (if they think appropriate). >=20 > Incidentally (but in no way relevant), I happen to really like the > idea / document, and would like to see it published (soon!). > w >=20 >=20 >=20 > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- = Copy-n-paste of ballot > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=20 > Suresh KrishnanDiscuss >=20 > Discuss (2017-08-16) >=20 > * Section 4 >=20 > It is not clear what you intend here >=20 > "IPv6 Router Advertisement Interval =3D 300s" >=20 > The router advertisement interval is not configured as an absolute > value but as minimum and maximum bounds (MinRtrAdvInterval and > MaxRtrAdvInterval) which are used to calculate the actual > advertisement interval. When the RA is sent from an interface, the > actual interval is an uniformly distributed random value between = the > MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum you = need > to clarify if you would like to have this as a lower bound or as an > upper bound. >=20 > Comment (2017-08-16) >=20 > * Section 4 >=20 > -> I think text is needed here to handle the case where the DNS = server > is provided in the RA itself (RFC8106) >=20 > "In addition it will use stateless DHCPv6 to get the IPv6 address = of > the DNS server" >=20 > -> I am not sure what is the motivation for this text. >=20 > "however it SHOULD NOT use stateful DHCPv6 to receive a service > provider managed IPv6 address" >=20 > -> This text seems incorrect >=20 > "due to the L-bit set, it SHOULD send this traffic to the First Hop > Provider Router" >=20 > I think it should be the exact opposite. i.e. say *unset* instead = of set >=20 > "due to the L-bit being unset, it SHOULD send this traffic to the > First Hop Provider Router" >=20 > Warren KumariYes >=20 > Deborah BrungardNo Objection >=20 > Ben CampbellNo Objection >=20 > Comment (2017-08-16) >=20 > I have no technical comments, but a number of editorial comments: >=20 > - General: I think this could use another proofreading and/or = editing > pass for the following issues: > -- Inconsistent tense--especially use of future or present = continuous. > -- Wordy and convoluted sentences > -- Use of "/" as a conjunction. >=20 > - Abstract: > The abstract is longer and more detailed than is useful. The last > paragraph could have stood alone as the abstract. > It's not clear to me if "hosts (subscribers)" means something > different than "hosts" in context. >=20 > -1: > Please expand "IA_NA" on first use. > s/"This document will focus..."/"This document focuses..." >=20 > "As such the use > of IPv6 SLAAC based subscriber and address management for = provider > managed shared network services is the recommended technology of > choice, as it does not exclude any known IPv6 implementation." > Does this document make that recommendation, or is that some > pre-existing recommendation? >=20 >=20 > -3: "The Best Current Practice documented in this note is to = provide a > unique IPv6 prefix to hosts/subscribers devices connected to the > provider managed shared network." >=20 > The sentence hard to follow. Consider "This document = recommends...". > I'm not sure how to interpret "hosts/subscribers devices" >=20 > "Each unique IPv6 prefix can > function as control-plane anchor point to make sure that each > subscriber is receiving" > s/"... subscriber is receiving ..."/"... subscriber receives..." >=20 >=20 >=20 > -4: Is "First Hop Provider Router" different than "First Hop = Router"? >=20 > In the last bullet (L-flag=3D0), are NEVER and ALWAYS in all-caps > expected to have different meaning than if they had normal > capitalization? >=20 > The sentence starting with "The architected result of designing the = RA > as documented above..." is convoluted and hard to follow. >=20 > "... however it SHOULD NOT use stateful DHCPv6 to receive > a service provider managed IPv6 address": Is that really a > normative requirement, or is it a statement of fact about existing > requirements? >=20 > "it SHOULD send this traffic > to the First Hop Provider Router." : statement of fact? >=20 > - 5: "To reduce > undesired resource consumption on the First Hop Router the = desire is > to remove UE/subscriber context in the case of non-permanent UE, = such > as in the case of WiFi hotspots as quickly as possible. " > Convoluted sentence. >=20 > "A possible solution is to use a subscriber inactivity timer which, = after > tracking a pre-defined (currently unspecified) number of = minutes, > deletes the subscriber context on the First Hop Router." >=20 > s/which/that (Consider " ... timer that deletes...after a > predetermined number of minutes" >=20 > -7: "The > combination of both IPv6 privacy extensions and operator based > assignment of a Unique IPv6 Prefix per Host provides each > implementing operator a tool to manage and provide subscriber > services and hence reduces the experienced privacy within each > operator controlled domain." >=20 > I have trouble following that sentence. Is the point to say that > providing tools to manage and provide services reduces privacy in > general? As worded, it almost sounds like this is meant as a = feature, > which I assume is not the case. >=20 > Spencer DawkinsNo Objection >=20 > Comment (2017-08-15) >=20 > One nit: >=20 > Please consider moving >=20 > Benefits of unique > IPv6 prefix over a unique IPv6 address from the service provider > include improved subscriber isolation and enhanced subscriber > management. >=20 > to the first paragraph of the Abstract. I=E2=80=99m assuming that = this > explains the =E2=80=9Cneeds that have arisen=E2=80=9D in the first = sentence of the > Abstract, of course. >=20 > Mirja K=C3=BChlewindNo Objection >=20 > Comment (2017-08-14) >=20 > To me this seems approriate for BCP; I'm saying this because this = was > mentioned in the shepherd-write-up as it was brought up by the = gen-art > review. >=20 > Please also consider the following comment from the gen-art review > (Thanks Joel!): > "The issue of status for the document (BCP vs Informational) is for = the IESG > to conclude. However, even if it is a BCP, as I understand the = purpose, > this document is intended to describe the practices to be used = when a > provider has decided to deploy a /64 per host. The wording that = is chosen > throughout the document makes it appear that the underlying = decision about > such a deployment is also a recommended practice." > I agree that wording could be made clearer here! >=20 > Alexey MelnikovNo Objection >=20 > Comment (2017-08-12) >=20 > Radius should have an informative reference on first use. >=20 > Kathleen MoriartyNo Objection >=20 > Comment (2017-08-15) >=20 > Thank you for addressing the SecDir review: > = https://mailarchive.ietf.org/arch/msg/secdir/wWp_0vlmsz7Ss-nowjhehYImOeg >=20 > Eric RescorlaNo Objection >=20 > Comment (2017-08-15) >=20 > Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt >=20 >=20 > I found the discussion of the shared network medium a bit > confusing. As I understand it, the idea is that if we are > on a shared network and we have the same prefix, I might > try to send to you directly. What you want to do is make > that not happen by having each node have a separate prefix. > Correct? If so, perhaps promote this bullet, and also have > it describe the problem and why this provides a solution: >=20 > o Two devices (subscriber/hosts), both attached to the same = provider > managed shared network should only be able to communicate = through > the provider managed First Hop Router >=20 >=20 > It's a bit unclear to me how much you are saying that > something is current practice versus how much you are > recommending it. For instance, the abstract reads more > like what you would expect for PS. >=20 > This document outlines an approach utilising existing IPv6 = protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of = unique > IPv6 prefix over a unique IPv6 address from the service provider > include improved subscriber isolation and enhanced subscriber > management. >=20 > But then S 4 seems to be documenting: >=20 > The IPv6 RA flags used for best common practice in IPv6 SLAAC = based > Provider managed shared networks are: >=20 >=20 > The use of a unique IPv6 prefix per UE adds an additional level = of > protection and efficiency as it relates to how IPv6 Neighbor > Discovery and Router Discovery processing. Since the UE has a = unique > IPv6 prefix all traffic by default will be directed to the First = Hop > provider router. Further, the flag combinations documented = above > maximise the IPv6 configurations that are available by hosts > including the use of privacy IPv6 addressing. >=20 > It's not quite clear to me why unique prefixs are needed here if > people set L=3D0. Is it that people ignore L=3D0? >=20 > Finally, I'm a bit confused about how to read this text about the > L=3D0 bit in cases where I have multiple devices rather than just = one > at the customer prem. Say I have a topology with a home router > and devices behind it. I.e., >=20 > Service Provider > | > | > Customer > Router > | > +-----------+-----------+ > | | | > Host 1 Host 2 Host 3 >=20 > I assume what happens here is that the router gets prefix X, = assigns > itself XY, and then the Hosts get XA, XB, XC, etc, a la 7278. Is = that > right? If so, my question is about packets coming into the Router = from > the SP, which have (say) XA. The text about the L-flag suggests = that > the router should send them back to the gateway, but that's clearly > not right. What am I missing? >=20 >=20 >=20 >=20 >=20 >=20 >> Cheers, >> Lorenzo >>=20 >> On Sun, Sep 10, 2017 at 4:49 AM, Warren Kumari = wrote: >>>=20 >>> [ Top-post ] >>>=20 >>> Yup, I was thinking that, while substantive, that would be handled >>> while still keeping it in IESG eval -- but, I've just gone back and >>> re-read the threads, especially all of the mail (~102) after the = IESG >>> / telechat, and I've decided that I will have to return it to the = WG. >>> Seeing as it has already had a WGLC, I expect that the next one can = be >>> compressed. >>>=20 >>> The good news is that a: there have been a number of suggestions / >>> provided text to improve the document, and b: I'd expect the next = IESG >>> eval to go easily. >>>=20 >>> Sorry all, >>> W >>>=20 >>>=20 >>> On Mon, Sep 4, 2017 at 6:32 PM, Brian E Carpenter >>> wrote: >>>> Warren, >>>>=20 >>>> I believe it's substantive that the text refers to sending unicast >>>> RAs without clarifying whether this means that they are sent >>>> with a unicast layer 2 address and a multicast layer 3 address >>>> (as per RFC6085) or that they are sent with both layer 2 and >>>> layer 3 addresses being unicast. At the moment, an implementer >>>> has to decide which of these is intended. If either is OK, >>>> that could be stated too. >>>>=20 >>>> Specifically this clarification seems to be needed right after: >>>>=20 >>>>> 4. IPv6 Unique Prefix Assignment >>>>>=20 >>>>> When a UE connects to the shared provider managed network and is >>>>> attached, it will initiate IP configuration phase. During this >>>>> phase >>>>> the UE will, from an IPv6 perspective, attempt to learn the = default >>>>> IPv6 gateway, the IPv6 prefix information, the DNS information >>>>> RFC8106 [RFC8106], and the remaining information required to >>>>> establish globally routable IPv6 connectivity. For that = purpose, >>>>> the >>>>> the UE/subscriber sends a RS (Router Solicitation) message. >>>>>=20 >>>>> The First Hop Router receives this UE/subscriber RS message and >>>>> starts the process to compose the response to the UE/subscriber >>>>> originated RS message. The First Hop Provider Router will = answer >>>>> using a unicast RA (Router Advertisement) to the UE/subscriber. >>>>=20 >>>> Regards >>>> Brian Carpenter >>>>=20 >>>> On 05/09/2017 09:43, Warren Kumari wrote: >>>>> I'd like to note that that there is continuing discussion on this >>>>> draft on the v6 ops list (yup, after WGLC and IETF LC :-)). I've = only >>>>> been able to somewhat monitor it, but have asked the v6ops chairs = for >>>>> input. Much of the discussion has been interesting, but not >>>>> necessarily pertaining exactly to this document. >>>>> Fred kindly asked the list: >>>>> = https://mailarchive.ietf.org/arch/msg/v6ops/bpEDtnYkbvJQZAx_r6mtEhdNxrw >>>>> for anything substantive for the document (keeping in mind that it = has >>>>> already gone through WGLC and IETF LC). >>>>>=20 >>>>> So far it doesn't seem like there are any other major changes = needed, >>>>> other than "asking that the applicability comment that = communication >>>>> between such nodes on a LAN should go through a connecting router >>>>> (which seems to me a given due to the relationship with routing) >>>>> should be documented." and David Farmer's followup -- >>>>> = https://mailarchive.ietf.org/arch/msg/v6ops/_-QlBqGk9dChoFOhxigf5WlxYDY >>>>>=20 >>>>> Does anyone have anything else *substantive*? If so, I may have to >>>>> kick this back to the WG for another round. >>>>>=20 >>>>> W >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan >>>>> wrote: >>>>>> Hi Gunter, >>>>>> Thanks for the proposed text changes. They adequately address my >>>>>> DISCUSS >>>>>> points. I am hoping you will also converge in the discussion with >>>>>> Lorenzo on >>>>>> the actual value for the timer and/or specify an applicability >>>>>> statement. I >>>>>> will clear once the new revision posts. >>>>>>=20 >>>>>> Regards >>>>>> Suresh >>>>>>=20 >>>>>> On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - = BE/Antwerp) >>>>>> wrote: >>>>>>=20 >>>>>> Hi Suresh, >>>>>>=20 >>>>>> Many thanks for the review and finding these issues. What do you = think >>>>>> of >>>>>> the proposals below to fix those points of attention? >>>>>>=20 >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>> DISCUSS: >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> * Section 4 >>>>>>=20 >>>>>> It is not clear what you intend here >>>>>>=20 >>>>>> "IPv6 Router Advertisement Interval =3D 300s" >>>>>>=20 >>>>>> The router advertisement interval is not configured as an = absolute >>>>>> value >>>>>> but as >>>>>> minimum and maximum bounds (MinRtrAdvInterval and >>>>>> MaxRtrAdvInterval) >>>>>> which are >>>>>> used to calculate the actual advertisement interval. When the = RA is >>>>>> sent >>>>>> from >>>>>> an interface, the actual interval is an uniformly distributed >>>>>> random >>>>>> value >>>>>> between the MinRtrAdvInterval and MaxRtrAdvInterval. At the = very >>>>>> minimum >>>>>> you >>>>>> need to clarify if you would like to have this as a lower bound = or >>>>>> as an >>>>>> upper >>>>>> bound. >>>>>>=20 >>>>>> GV> I changed the line to make it more clear that the timer = indicates >>>>>> the >>>>>> maximum Advertisement Interval >>>>>> GV> Maximum IPv6 Router Advertisement Interval =3D = 300s >>>>>>=20 >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> * Section 4 >>>>>>=20 >>>>>> -> I think text is needed here to handle the case where the DNS >>>>>> server is >>>>>> provided in the RA itself (RFC8106) >>>>>>=20 >>>>>> "In addition it will use stateless DHCPv6 to get the IPv6 = address >>>>>> of the >>>>>> DNS >>>>>> server" >>>>>>=20 >>>>>> -> I am not sure what is the motivation for this text. >>>>>>=20 >>>>>> "however it SHOULD NOT use stateful DHCPv6 to receive a service >>>>>> provider >>>>>> managed IPv6 address" >>>>>>=20 >>>>>> -> This text seems incorrect >>>>>>=20 >>>>>> "due to the L-bit set, it SHOULD send this traffic to the First = Hop >>>>>> Provider >>>>>> Router" >>>>>>=20 >>>>>> I think it should be the exact opposite. i.e. say *unset* = instead >>>>>> of set >>>>>>=20 >>>>>> "due to the L-bit being unset, it SHOULD send this traffic to = the >>>>>> First >>>>>> Hop >>>>>> Provider Router" >>>>>>=20 >>>>>> GV> What about the following modification in the text: >>>>>>=20 >>>>>> OLD: >>>>>> The architected result of designing the RA as documented above is >>>>>> that each UE/subscriber gets its own unique IPv6 prefix for = which it >>>>>> can use SLAAC or any other method to select its /128 unique = address. >>>>>> In addition it will use stateless DHCPv6 to get the IPv6 address = of >>>>>> the DNS server, however it SHOULD NOT use stateful DHCPv6 to = receive >>>>>> a service provider managed IPv6 address. If the UE/subscriber >>>>>> desires to send anything external including other UE/subscriber >>>>>> devices (assuming device to device communications is enabled and >>>>>> supported), then, due to the L-bit set, it SHOULD send this = traffic >>>>>> to the First Hop Provider Router. >>>>>>=20 >>>>>> New: >>>>>> The architected result of designing the RA as documented above is >>>>>> that each UE/subscriber gets its own unique IPv6 prefix for which = it >>>>>> can use SLAAC or any other method to select its /128 unique = address. >>>>>> Either stateless DHCPv6 RFC3736 = or IPv6 >>>>>> Router Advertisement Options for DNS Configuration >>>>>> RFC8106 can be used to get the >>>>>> IPv6 address of the DNS server. If the UE/subscriber desires to = send >>>>>> anything external including other UE/subscriber devices (assuming >>>>>> device >>>>>> to device communications is enabled and supported), then, due to = the >>>>>> L-bit being unset, it SHOULD send this traffic to the First Hop >>>>>> Provider >>>>>> Router. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Kind Regards, >>>>>> G/ >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> I don't think the execution is relevant when it was obviously a bad >>> idea in the first place. >>> This is like putting rabid weasels in your pants, and later = expressing >>> regret at having chosen those particular rabid weasels and that pair >>> of pants. >>> ---maf >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >=20 >=20 >=20 > --=20 > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later = expressing > regret at having chosen those particular rabid weasels and that = pair > of pants. > ---maf >=20 >=20 From nobody Wed Sep 13 12:09:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61532132EDC for ; Wed, 13 Sep 2017 12:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4CcVbmoCiKWw for ; Wed, 13 Sep 2017 12:09:22 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9113132EBB for ; Wed, 13 Sep 2017 12:09:21 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id e1so1637245pfk.1 for ; Wed, 13 Sep 2017 12:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=ftbpJguQ/kzIrDmERqyTTdULqU+l3qcF8vgATOwC0FQ=; b=m+zNRDYFHQrn7pC0ZzznPECnDzTuzSaQp9RHfvIzgAwFLUm5yXXd83iaQ2RuUlFei8 vx8kOZnmM9P1ggBAlc/L8VQYwnaaIY7oLzySVk++AYP0siMwyHS8Uu6uivTIvCMIRQIl 2d85In0Ov8BOyrQ7JjIYtWoO0uhp9cABaGxAHTFQWC2GP5WFOki3AMUTHCCQG6JEuIbz cN/E+sD2ZBtynx2NA0zeXasLIPZFbdcolon7hhxfTXcB04XBWB6R6piWeOOiF9L2vpnI ZjbXWu9zYQU3OSC1iLtC7PJ+qFQb7KQO6UTo/M/PuVxr1RERmq7Tck3/DIzhCi6tTP2W aGaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=ftbpJguQ/kzIrDmERqyTTdULqU+l3qcF8vgATOwC0FQ=; b=J3HVwG2vY9+SIc+txeDX2JYuopBv8RF3keCtn56mb+mFTqLX6pPrTSLr8KXpE2zLS1 jGDyCyUcRUJczbE2pd6hvFhgZTTQHyX/J1JtsrHKBD1TdUaV80aJ4aaADMzYSUONVWyr i5GmfPMmJPE5dh0GcqqfmtQeSSrPuta6E6VyDj/QVJVsBGkV9zRlh2q/tHbBpNjl6UEk VdbC5dAUaOAGHLuR1LujWX7jNwpn+Kxh0ZaSlMS69fCyRTBbapzofy3FP510JVTStQZK u6ZvWm1sWG3Mot3YR3jTXkr8Q83ZXpJS2tZ/vprTAb4p4adgrhft7ZElyRL9t5yG8b8I pHZg== X-Gm-Message-State: AHPjjUh+hL3htC4RPD9TQqUNcWqO2HCnH8grbcSNE5MbWPsoowHDvtTB 783BeCD46w8qyIpFsTWRoA== X-Google-Smtp-Source: ADKCNb6k97MoRJxgZf3KTDaZcyepvbDQE992a9vBPOhfdmh8NfbqlSo6Oa2RRSIkCCFXAu/0EPI1DA== X-Received: by 10.84.233.10 with SMTP id j10mr21659720plk.134.1505329760978; Wed, 13 Sep 2017 12:09:20 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:c17f:5e9e:80b0:3b44? ([2620:0:10e7:10:c17f:5e9e:80b0:3b44]) by smtp.gmail.com with ESMTPSA id r22sm27545588pfe.78.2017.09.13.12.09.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 12:09:20 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_A9A83BDA-1DC6-4C9E-897A-5D27D36964C6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 13 Sep 2017 12:09:19 -0700 References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> To: v6ops list In-Reply-To: <150531144008.30405.8720524557391780522@ietfa.amsl.com> Message-Id: <162CC84F-4970-460F-AE5A-DE7A73879B2F@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 19:09:23 -0000 --Apple-Mail=_A9A83BDA-1DC6-4C9E-897A-5D27D36964C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 13, 2017, at 07:04, internet-drafts@ietf.org wrote: >=20 >=20 > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt > Pages : 9 > Date : 2017-09-13 >=20 > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. This revision greatly improves on its predecessor, but I=E2=80=99m still = left wondering why the word =E2=80=9Credirect=E2=80=9D doesn=E2=80=99t = appear anywhere in the text. Shouldn=E2=80=99t it make an explicit = recommendation that routers never send them? And if that=E2=80=99s not = the recommendation, then shouldn=E2=80=99t it say something about how to = provide improved isolation between connected visitor devices while still = admitting the use of redirects? --james woodyatt > --Apple-Mail=_A9A83BDA-1DC6-4C9E-897A-5D27D36964C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Sep 13, 2017, at 07:04, internet-drafts@ietf.org wrote:


       Title =           : Unique = IPv6 Prefix Per Host
=        Authors =         : John Jason = Brzozowski
=             &n= bsp;           &nbs= p;Gunter Van De Velde
Filename =        : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
Pages =           : 9
= Date =            : = 2017-09-13

Abstract:
=   This document outlines an approach utilising existing IPv6 = protocols
  to allow hosts to be assigned a = unique IPv6 prefix (instead of a
  unique IPv6 = address from a shared IPv6 prefix).  Benefits of unique
  IPv6 prefix over a unique service provider IPv6 = address include
  improved host isolation and = enhanced subscriber management on shared
=   network segments.

This revision greatly improves on its = predecessor, but I=E2=80=99m still left wondering why the word = =E2=80=9Credirect=E2=80=9D doesn=E2=80=99t appear anywhere in the text. = Shouldn=E2=80=99t it make an explicit recommendation that routers never = send them? And if that=E2=80=99s not the recommendation, then = shouldn=E2=80=99t it say something about how to provide improved = isolation between connected visitor devices while still admitting the = use of redirects?


--james woodyatt <jhw@google.com>



= --Apple-Mail=_A9A83BDA-1DC6-4C9E-897A-5D27D36964C6-- From nobody Wed Sep 13 13:29:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E03132F2D for ; Wed, 13 Sep 2017 13:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOvVrpM-Q3b2 for ; Wed, 13 Sep 2017 13:29:13 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58487132ECE for ; Wed, 13 Sep 2017 13:29:13 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id v66so2421671pgb.5 for ; Wed, 13 Sep 2017 13:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2luox3WuqB3R9mePaEVkVC+2n5f5OZEkCfD2pd8IaVQ=; b=I73oSSb/OWpJ8KyzfgPgBdyGYYLo2RQLKN/U+oR3/iQpvOD0KKo4HOsA5lVp65vnpS EuJL+Y9WB7hk5Q9LNlRaz0+moeFa/cqlrIB2EVE2UDnGwPgBWsZceUx5EBcqTRvBna5L Ti0sw50qMVxMx3hQjA8CoIAGpYL/5Nrt8j3wibSrz7nI/Yb1BpdYJSuomhJ0TlKYy0Rw 2o3VwyzbsVl9dHDu/G90Yca/LNSvYDHH05YPmmr4UnBXQrnKs++O47HBXPVj1VRFqoY6 wvLJYmV+k7Nq/xyjVK7PgprvNij0PURD0TyBsgYrwiNIisAxACCRyStKm5XzQh1AInQG dkiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=2luox3WuqB3R9mePaEVkVC+2n5f5OZEkCfD2pd8IaVQ=; b=VV2GlMU1P6dmlzz5MqG7TXRp/M85+T2xXZMHlYXGrd4kd5+7X7fZkt8aJnOTyZG+im AwD+P3kyYaFM06665fdsz2sSY53SMJ5juU2AQRyNasLj4Km3hHUY5hioZ+0nJzHCr6QJ BWc5Ru7by0TecGrigNLbOmBVQ1nHHiStY8HnAiCCCjCFkEHxj6Zw10+45GiKT0pzg0tg TrWfL9PTe132/stanbu/W6h9dI1eE+uaFT4CL6BQkEkGoKyAsaRhTp7VGvYzhBVWniz2 EtFouQYHY54r1gJUQBBEqI9lo9Y+MJQKQPaOO6lDQCXzonB+O+EirU7cLdYbDiDW6C+5 RU5A== X-Gm-Message-State: AHPjjUilBW4nzs7Ak7+1P4o1w/nln+DqFIefNgrrUIzuA+raBtJ+06o+ r6wJS/nT+Yv/9Sgs X-Google-Smtp-Source: ADKCNb49yrNQahlD7qUiBdwxAkpKZELomUrOZd6ApRSxMpkXNRpA2LG31j3HmujH2xVIYPVmRWwqLw== X-Received: by 10.98.217.75 with SMTP id s72mr18901077pfg.158.1505334552701; Wed, 13 Sep 2017 13:29:12 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id d186sm12910086pfd.117.2017.09.13.13.29.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 13:29:11 -0700 (PDT) To: v6ops@ietf.org References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <11835e89-4aff-9ebe-01f0-155498586913@gmail.com> Date: Thu, 14 Sep 2017 08:29:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150531144008.30405.8720524557391780522@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 20:29:14 -0000 > A shared network service, is a service offering where a particular L2 > access network (i.e. wifi) is shared and used by multiple visiting > devices (i.e. subscribers). I'm pretty sure that you mean "e.g.", not "i.e.", in both of those parentheses. This version still does not clarify whether a "unicast" RA means one sent to a unicast Layer 3 address at a unicast Layer 2 address, or to ff02::1 at a unicast Layer 2 address, or either. An implementer has to guess. Regards Brian From nobody Wed Sep 13 13:37:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29FB132F2A; Wed, 13 Sep 2017 13:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 SdtMZsgjmHNv; Wed, 13 Sep 2017 13:37:27 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F228C132697; Wed, 13 Sep 2017 13:37:26 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id 188so2482670pgb.2; Wed, 13 Sep 2017 13:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pE/EBa3cbMkfOWa2s8/0VF0mTu6itoxkDBgCXUW1shE=; b=oEjVP+fdSxR9L3Wo2F/svcL7heRM+6qrx0y5/d7+/FtNawJUTcYkaYN+T+seLP1462 oVPkG7jumLGrkp0yUpJ4CWSost5rPV/wTJY2lU0wjO1FXhTCndKdJmvqSbVGBL/597vg r9WvNvCCts8KkmWzsHy1U/G8mXSAgs4YGhb8Hth5mRjduvAcG2Ady/CTx90TQZPrnw56 L6zBRrQJ1/3Y/VLKkKJSNvrk8/KFfpIpkx+neOXxK8b720o3Z89gVEN+lokf3F1ZOLfG gAZo8QOv2k+Lf/tKS7+fHey0UiL8JyZCmXPTr9kDFqMI81gHGQKy879MMnBUIoNsbhHT L7rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=pE/EBa3cbMkfOWa2s8/0VF0mTu6itoxkDBgCXUW1shE=; b=TmGfpyMdv6JAhZvynm6x+ACjaT+wBQHIPrGXX4rhzqLwVkQK/cx2e4hpDCbzkg9DNz WzJzsTJkARzBaP8DwIKYH31DJMJx5/1nbmbkaPi1RUgljghzlNzilALgXJrrtPZ4/3fz cwTiD/a7ZfE8Ye+Ek8rLMZK63Xk8op2U7h/SWMhbaqAtgx9WqFErV/F+JRyviUXRIX5a 1u0aTS3dgUNpQhXqRvuVhe0ClRxgSlW6elnOPdBNk1bmhpTAm+V+j6dL0FGgH4Cdf/I4 TmdFF1e2Dga6v/4xexo6Br5Gtz1XK+q0NCM8vsdvqncimHoQwVVnfbDFOILVINa+292a 36Aw== X-Gm-Message-State: AHPjjUjC3NxXMqLVwuplUdg106+SwzoaXXbYG/dxJbOE1xDSSH+t8kiZ aurkimdse3TKnTo5 X-Google-Smtp-Source: ADKCNb51CSb5IYDDUxXT+w3D9FOJAfYidyNudAhKunWLeoSo4SqeOH3BOB3hOoTH8nX7mrQ4rDkGxg== X-Received: by 10.98.76.134 with SMTP id e6mr19276978pfj.180.1505335046238; Wed, 13 Sep 2017 13:37:26 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s17sm22473379pgq.25.2017.09.13.13.37.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 13:37:25 -0700 (PDT) To: Suresh Krishnan , "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: Warren Kumari , Lorenzo Colitti , "v6ops@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@ietf.org" References: <150292405512.12308.10034157849517158179.idtracker@ietfa.amsl.com> <961C9C36-C4DA-4D84-8A0C-97EB15BD9A36@nokia.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 14 Sep 2017 08:37:26 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 20:37:28 -0000 On 14/09/2017 05:40, Suresh Krishnan wrote: > Thanks Gunter and John. The new version addresses my DISCUSS and COMMENTs. I have cleared. Sadly though it has at least one significant nit and one remaining ambiguity, as I just reported. I hope they can be fixed before we see an approval notice. Brian From nobody Wed Sep 13 14:12:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814AB132ECF; Wed, 13 Sep 2017 14:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRaJAcv8-otC; Wed, 13 Sep 2017 14:12:24 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DD613293A; Wed, 13 Sep 2017 14:12:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8DLCNCY026712; Wed, 13 Sep 2017 14:12:23 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8DLCIWw026669 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 14:12:18 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Sep 2017 14:12:18 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 13 Sep 2017 14:12:18 -0700 From: "Templin, Fred L" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt Thread-Index: AQHTLJkv/GFPUda+3EaDW5zERE6omaKzTQFQ Date: Wed, 13 Sep 2017 21:12:18 +0000 Message-ID: <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> In-Reply-To: <150531144008.30405.8720524557391780522@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 21:12:26 -0000 Please add the following to Security Considerations: "While the practices described herein encourage L3 operations that would forward all traffic through a provider managed First Hop Router, peer t= o peer communications are still possible unless L2 mechanisms are also employe= d in some fashion outside the scope of this document." Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org > Sent: Wednesday, September 13, 2017 7:04 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host= -08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt > Pages : 9 > Date : 2017-09-13 >=20 > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-= 08 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix= -per-host-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-p= er-host-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Sep 13 15:00:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33646132339; Wed, 13 Sep 2017 15:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYcEJJoS2qq5; Wed, 13 Sep 2017 15:00:40 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3328132192; Wed, 13 Sep 2017 15:00:39 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id l24so2003938uaa.5; Wed, 13 Sep 2017 15:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S2rp549RjRqZ3J4n+pOp/wpgKa1HQQcNccpPE8VR8Vs=; b=M+x/W0s7qLWf62LpuLhLrkwGG789qlCOfFCgSGdm1WuAEbmuD4jZjGgw2aCnEVdxSN XPOtZqoxA2CIZRGyMx3WSjdt2H+lG4fpvuLnHtWdykBAPWCNneYMHsZZASzu1G6p2PyL 4OkqIhg0nS1r8E+SpapISDZw9F58SvC9CnVKf/LYE/0jQz3uzFqp04yX332IKiauiYfA CXFu8E+yv3toHjPBNn5ZL+i4rK/c0ppMiBam90PQKNeqohq6qsoxnsHupi9yu9gnY1iC 4Jkgj8pH52xgDavwJg09R0Y4Ht867wKMEhJJJhmxjrQTbZcvBe6K8kOm57GT8fYeHd5x C0Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S2rp549RjRqZ3J4n+pOp/wpgKa1HQQcNccpPE8VR8Vs=; b=N+eSGG5CRi8Y+9DW+sh0lUZtxy8O5RGJRmRGBvgZ3t5yNZg4gYrGnMHJzUtANqk3FJ HgzbIZcQE5Udh15XxOeiGemkk38MpwhodQaDZaYgz257B8ChABImysf2tSi2+v6Ih3HS 1Al1gkiKVLLX/LBLOv4SnE00EdNUJn0JBzkA2jXOrVV4JM1Ez0GjzoT7VeHnEVioaLso D42A2GTh3ccNuZ4ziPekOVloKyGcVYpKFm+h+Z1ncwS8klKbLxNz/I32/Cmhph8/gzK9 s23KwNFB1he2OyzQdr4fHg9cjaprsnyPHnzOu8nh13ETavimAQAaTArGVJMU5aulmOVf s+LQ== X-Gm-Message-State: AHPjjUiA/g507RezLFsYu8C/YdLTFK9trQw650+EFYf5oYkkdHy1Z6St rEZiCPk1Ys09Jq86M27zp/wfdTmxQQp95y1kDe8= X-Google-Smtp-Source: ADKCNb6g/58fPahHPmpTcLIjQhf41YM721wAUgBzf0VKHyvflmNQXhRWmc67auI0FBoYtIbQG5nYrPboXE/X8T3dFOE= X-Received: by 10.159.36.168 with SMTP id 37mr16605631uar.116.1505340038843; Wed, 13 Sep 2017 15:00:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.27.17 with HTTP; Wed, 13 Sep 2017 15:00:38 -0700 (PDT) Received: by 10.176.27.17 with HTTP; Wed, 13 Sep 2017 15:00:38 -0700 (PDT) In-Reply-To: <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> From: Mark Smith Date: Thu, 14 Sep 2017 08:00:38 +1000 Message-ID: To: "Templin, Fred L" Cc: v6ops list , internet-drafts@ietf.org, "i-d-announce@ietf.org" Content-Type: multipart/alternative; boundary="001a113cf8b84812210559194ab3" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 22:00:42 -0000 --001a113cf8b84812210559194ab3 Content-Type: text/plain; charset="UTF-8" On 14 Sep. 2017 07:12, "Templin, Fred L" wrote: Please add the following to Security Considerations: "While the practices described herein encourage L3 operations that would forward all traffic through a provider managed First Hop Router, That needs to be adjusted slightly to be accurate. Unless an ND proxy is used, LL traffic cannot be made to go though the first hop router. It'd be worth everybody interested in this draft having a read of IP over Intentionally Partially Partitioned Links https://tools.ietf.org/html/draft-intf-intarea-ippl-00 It recommends against using an ND proxy. It should also probably be referenced by this draft. Regards, Mark. peer to peer communications are still possible unless L2 mechanisms are also employed in some fashion outside the scope of this document." Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, September 13, 2017 7:04 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6- prefix-per-host-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6- prefix-per-host-08.txt > Pages : 9 > Date : 2017-09-13 > > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique- ipv6-prefix-per-host/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6- prefix-per-host-08 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops- unique-ipv6-prefix-per-host-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique- ipv6-prefix-per-host-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 --001a113cf8b84812210559194ab3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 14 Sep. 2017 07:12, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:=
Please add the following = to Security Considerations:

=C2=A0 "While the practices described herein encourage L3 operations t= hat would
=C2=A0 =C2=A0 forward all traffic through a provider managed First Hop Rout= er,

That needs to be adjusted slightly to be accurate. Unless an ND proxy = is used, LL traffic cannot be made to go though the first hop router.
=

It'd be worth everybody i= nterested in this draft having a read of

<= div dir=3D"auto">
IP over Intentiona=
lly Partially Partitioned Links
https://tools.ietf.org/=
html/draft-intf-intarea-ippl-00

It recommends against using an ND proxy.

It should also probably be referenced by this draft.

Regards,
Mark.

peer = to peer
=C2=A0 =C2=A0 communications are still possible unless L2 mechanisms are al= so employed
=C2=A0 =C2=A0 in some fashion outside the scope of this document."

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:v6ops-bo= unces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: Wednesday, September 13, 2017 7:04 AM
> To: i-d-announce@ietf.org=
> Cc: v6ops@ietf.org
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-= per-host-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the IPv6 Operations WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Unique IPv6 Prefix Per Host
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: John Jason Brzozowski
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Gunter Van De Velde
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 9
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-09-13
>
> Abstract:
>=C2=A0 =C2=A0 This document outlines an approach utilising existing IPv= 6 protocols
>=C2=A0 =C2=A0 to allow hosts to be assigned a unique IPv6 prefix (inste= ad of a
>=C2=A0 =C2=A0 unique IPv6 address from a shared IPv6 prefix).=C2=A0 Ben= efits of unique
>=C2=A0 =C2=A0 IPv6 prefix over a unique service provider IPv6 address i= nclude
>=C2=A0 =C2=A0 improved host isolation and enhanced subscriber managemen= t on shared
>=C2=A0 =C2=A0 network segments.
>
>
> The IETF datatracker status page for this draft is:
> https://datatrack= er.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/=
>
> There are also htmlized versions available at:
> https://tools.ietf.o= rg/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08
> https://da= tatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-p= er-host-08
>
> A diff from the previous version is available at:
> https://www.= ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-per-h= ost-08
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> 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=


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

--001a113cf8b84812210559194ab3-- From nobody Wed Sep 13 15:04:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D7E13304E for ; Wed, 13 Sep 2017 15:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DHouqueFmQIc for ; Wed, 13 Sep 2017 15:03:56 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C5E132F63 for ; Wed, 13 Sep 2017 15:03:56 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id v72so3544953ywa.3 for ; Wed, 13 Sep 2017 15:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=URsVyAp0XbjqEGSgFNobJ1s3WNSfG/VR9XanJ1/DpbM=; b=bIDH2xSAjfzICmecNR6kyqQqB6RVNGfMPkNr05qROIMYlY+gKcwRTW37y45DcG6+eU QTnOoCZ4v3SImsKddNG+EpqyvH7TB83ThOq47paQi7hBxTlmBxA7u8WFVwtPCU1Wazh0 j5imrYH27wUQFJqon0jxRc3jKSZzKZOy6JdZkmCJXhOy2S5x0OXa5CvV+FLxPEJSFTyZ RzkhXyTQg5cThozd9+U+4JssPeWr0xAuriimuxE8JxrAluv71NuJpdhrok0Wb8+3BFpS kETehM7hBdAiUOR1TP/2q+LmDyqjf0qNwti92ZEpYy4/re4hPOjIx+XdLDPNIKDaOPgX /qFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=URsVyAp0XbjqEGSgFNobJ1s3WNSfG/VR9XanJ1/DpbM=; b=Dr7IQl31sVy5S/1TXlmIHv6ZuHRBrywMJsW2GPxI/7/nBJfqBuE56gNexkUJBMPFao bbcmt8ajCf47HjTTwozd9tp0t7tYlQ5gP1LNgCyuwhS90soZbLwZkS/y/uraXc5qj1Qq lGf/8UMi2U6Co2+vqSV7zioPUjbngzo83USTnT2HwCbxsl38Ehs2vLbhVusoKmxXecJ4 AAGQNvzLHXit0KR6EqPQT6DXndJMiMF6xBzOyawe5az0fclhLjxjONdXRSfHUlzb6k8T ak4hprynWA+rKQHDQTU3re8ADP8t8aPoyvqNpAR1ALAC6NoMQHHbMKti0ky4wLRSwmY0 3e+g== X-Gm-Message-State: AHPjjUh9+8bKyG4sjgjnzCK5Dfo8hBLBF3d+D9faLOtPg/H5yjtkbR3/ Ti7yHQlyX9V7FCS9ukeFq02dG+YpGQkx1KQr77XTiw== X-Google-Smtp-Source: ADKCNb5NBp0RV6mzCfIcQAt6QV2JEss58oivbsXbhfU/LceiwKSb0VWjsVfE/zI3LiNzBOOqVgO0vnihEK4sU4j+nZA= X-Received: by 10.129.78.207 with SMTP id c198mr17974217ywb.121.1505340235045; Wed, 13 Sep 2017 15:03:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Wed, 13 Sep 2017 15:03:34 -0700 (PDT) In-Reply-To: <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Wed, 13 Sep 2017 15:03:34 -0700 Message-ID: To: "Templin, Fred L" Cc: "internet-drafts@ietf.org" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a114dcd70fa6b6005591955fc" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 22:03:59 -0000 --001a114dcd70fa6b6005591955fc Content-Type: text/plain; charset="UTF-8" I would instead say the opposite, i.e., call attention to what is in fact one of the the main benefits of this document. Suggested text: The practices described in this document make it very simple for networks to implement robust isolation between clients at layer 2. The network can simply ensure that devices cannot send packets to each other except through the first-hop router. This will automatically provide robust protection against attacks between devices that rely on link-local ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, malicious redirects, and rogue RAs. This form of protection is much more scalable and robust than alternative mechanisms such as DAD proxying, forced forwarding, or ND snooping. On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L wrote: > Please add the following to Security Considerations: > > "While the practices described herein encourage L3 operations that would > forward all traffic through a provider managed First Hop Router, peer > to peer > communications are still possible unless L2 mechanisms are also > employed > in some fashion outside the scope of this document." > > Thanks - Fred > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > > Sent: Wednesday, September 13, 2017 7:04 AM > > To: i-d-announce@ietf.org > > Cc: v6ops@ietf.org > > Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6- > prefix-per-host-08.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IPv6 Operations WG of the IETF. > > > > Title : Unique IPv6 Prefix Per Host > > Authors : John Jason Brzozowski > > Gunter Van De Velde > > Filename : draft-ietf-v6ops-unique-ipv6- > prefix-per-host-08.txt > > Pages : 9 > > Date : 2017-09-13 > > > > Abstract: > > This document outlines an approach utilising existing IPv6 protocols > > to allow hosts to be assigned a unique IPv6 prefix (instead of a > > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > > IPv6 prefix over a unique service provider IPv6 address include > > improved host isolation and enhanced subscriber management on shared > > network segments. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique- > ipv6-prefix-per-host/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6- > prefix-per-host-08 > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops- > unique-ipv6-prefix-per-host-08 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique- > ipv6-prefix-per-host-08 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > --001a114dcd70fa6b6005591955fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would instead say the opposite, i.e., call attention to = what is in fact one of the the main benefits of this document. Suggested te= xt:

The practices described in this document make it ver= y simple for networks to implement robust isolation between clients at laye= r 2. The network can simply ensure that devices cannot send packets to each= other except through the first-hop router. This will automatically provide= robust protection against attacks between devices that rely on link-local = ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, malicious = redirects, and rogue RAs. This form of protection is much more scalable and= robust than alternative mechanisms such as DAD proxying, forced forwarding= , or ND snooping.



On Wed, Sep 13, 2017 at 2:12 PM, = Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
Please add the following to Security Consi= derations:

=C2=A0 "While the practices described herein encourage L3 operations t= hat would
=C2=A0 =C2=A0 forward all traffic through a provider managed First Hop Rout= er, peer to peer
=C2=A0 =C2=A0 communications are still possible unless L2 mechanisms are al= so employed
=C2=A0 =C2=A0 in some fashion outside the scope of this document."

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:v6ops-bo= unces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: Wednesday, September 13, 2017 7:04 AM
> To: i-d-announce@ietf.org=
> Cc: v6ops@ietf.org
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-= per-host-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the IPv6 Operations WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Unique IPv6 Prefix Per Host
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: John Jason Brzozowski
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Gunter Van De Velde
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 9
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-09-13
>
> Abstract:
>=C2=A0 =C2=A0 This document outlines an approach utilising existing IPv= 6 protocols
>=C2=A0 =C2=A0 to allow hosts to be assigned a unique IPv6 prefix (inste= ad of a
>=C2=A0 =C2=A0 unique IPv6 address from a shared IPv6 prefix).=C2=A0 Ben= efits of unique
>=C2=A0 =C2=A0 IPv6 prefix over a unique service provider IPv6 address i= nclude
>=C2=A0 =C2=A0 improved host isolation and enhanced subscriber managemen= t on shared
>=C2=A0 =C2=A0 network segments.
>
>
> The IETF datatracker status page for this draft is:
> https://datatrack= er.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/=
>
> There are also htmlized versions available at:
> https://tools.ietf.o= rg/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08
> https://da= tatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-p= er-host-08
>
> A diff from the previous version is available at:
> https://www.= ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-per-h= ost-08
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> 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=


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

--001a114dcd70fa6b6005591955fc-- From nobody Wed Sep 13 15:11:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A755113219F; Wed, 13 Sep 2017 15:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 ntvwG0rl4hrw; Wed, 13 Sep 2017 15:11:06 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B82F126DD9; Wed, 13 Sep 2017 15:11:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8DMB5Dr048861; Wed, 13 Sep 2017 15:11:05 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8DMAtpo048336 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 15:10:55 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Sep 2017 15:10:55 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 13 Sep 2017 15:10:55 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: "internet-drafts@ietf.org" , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt Thread-Index: AQHTLJkv/GFPUda+3EaDW5zERE6omaKzTQFQgACHbgD//4wjsA== Date: Wed, 13 Sep 2017 22:10:55 +0000 Message-ID: References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_b8df290dc5854ee8962f8070dbd09bb1XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 22:11:09 -0000 --_000_b8df290dc5854ee8962f8070dbd09bb1XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBsaWtlIG15IHRleHQgYmV0dGVyOyBpdCBpcyBzaW1wbGVyLCBhbmQgc2F5cyB3aGF0IGlzIG5l Y2Vzc2FyeSBhbmQgc3VmZmljaWVudC4NCkF0IGEgbWluaW11bSwgaXQgaGFzIHRvIGFkbWl0IHRo YXQgcGVlciB0byBwZWVyIGlzIHBvc3NpYmxlIHVubGVzcyBzb21laG93DQpwcmV2ZW50ZWQgYnkg TDIgbWVjaGFuaXNtcy4NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBMb3JlbnpvIENvbGl0dGkg W21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAx MywgMjAxNyAzOjA0IFBNDQpUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tPg0KQ2M6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlw djYtcHJlZml4LXBlci1ob3N0LTA4LnR4dA0KDQpJIHdvdWxkIGluc3RlYWQgc2F5IHRoZSBvcHBv c2l0ZSwgaS5lLiwgY2FsbCBhdHRlbnRpb24gdG8gd2hhdCBpcyBpbiBmYWN0IG9uZSBvZiB0aGUg dGhlIG1haW4gYmVuZWZpdHMgb2YgdGhpcyBkb2N1bWVudC4gU3VnZ2VzdGVkIHRleHQ6DQoNClRo ZSBwcmFjdGljZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgbWFrZSBpdCB2ZXJ5IHNpbXBs ZSBmb3IgbmV0d29ya3MgdG8gaW1wbGVtZW50IHJvYnVzdCBpc29sYXRpb24gYmV0d2VlbiBjbGll bnRzIGF0IGxheWVyIDIuIFRoZSBuZXR3b3JrIGNhbiBzaW1wbHkgZW5zdXJlIHRoYXQgZGV2aWNl cyBjYW5ub3Qgc2VuZCBwYWNrZXRzIHRvIGVhY2ggb3RoZXIgZXhjZXB0IHRocm91Z2ggdGhlIGZp cnN0LWhvcCByb3V0ZXIuIFRoaXMgd2lsbCBhdXRvbWF0aWNhbGx5IHByb3ZpZGUgcm9idXN0IHBy b3RlY3Rpb24gYWdhaW5zdCBhdHRhY2tzIGJldHdlZW4gZGV2aWNlcyB0aGF0IHJlbHkgb24gbGlu ay1sb2NhbCBJQ01QdjYgcGFja2V0cywgc3VjaCBhcyBEQUQgcmVwbHkgc3Bvb2ZpbmcsIE5EIGNh Y2hlIGV4aGF1c3Rpb24sIG1hbGljaW91cyByZWRpcmVjdHMsIGFuZCByb2d1ZSBSQXMuIFRoaXMg Zm9ybSBvZiBwcm90ZWN0aW9uIGlzIG11Y2ggbW9yZSBzY2FsYWJsZSBhbmQgcm9idXN0IHRoYW4g YWx0ZXJuYXRpdmUgbWVjaGFuaXNtcyBzdWNoIGFzIERBRCBwcm94eWluZywgZm9yY2VkIGZvcndh cmRpbmcsIG9yIE5EIHNub29waW5nLg0KDQoNCg0KT24gV2VkLCBTZXAgMTMsIDIwMTcgYXQgMjox MiBQTSwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQpQbGVhc2UgYWRkIHRoZSBmb2xsb3dp bmcgdG8gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM6DQoNCiAgIldoaWxlIHRoZSBwcmFjdGljZXMg ZGVzY3JpYmVkIGhlcmVpbiBlbmNvdXJhZ2UgTDMgb3BlcmF0aW9ucyB0aGF0IHdvdWxkDQogICAg Zm9yd2FyZCBhbGwgdHJhZmZpYyB0aHJvdWdoIGEgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3Ag Um91dGVyLCBwZWVyIHRvIHBlZXINCiAgICBjb21tdW5pY2F0aW9ucyBhcmUgc3RpbGwgcG9zc2li bGUgdW5sZXNzIEwyIG1lY2hhbmlzbXMgYXJlIGFsc28gZW1wbG95ZWQNCiAgICBpbiBzb21lIGZh c2hpb24gb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4iDQoNClRoYW5rcyAtIEZy ZWQNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyBbbWFpbHRv OnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc+DQo+IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEzLCAyMDE3IDc6MDQg QU0NCj4gVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYu b3JnPg0KPiBDYzogdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KPiBTdWJq ZWN0OiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJl Zml4LXBlci1ob3N0LTA4LnR4dA0KPg0KPg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBXRyBvZiB0aGUg SUVURi4NCj4NCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBVbmlxdWUgSVB2NiBQcmVmaXgg UGVyIEhvc3QNCj4gICAgICAgICBBdXRob3JzICAgICAgICAgOiBKb2huIEphc29uIEJyem96b3dz a2kNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBHdW50ZXIgVmFuIERlIFZlbGRlDQo+ICAg ICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4 LXBlci1ob3N0LTA4LnR4dA0KPiAgICAgICBQYWdlcyAgICAgICAgICAgOiA5DQo+ICAgICAgIERh dGUgICAgICAgICAgICA6IDIwMTctMDktMTMNCj4NCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9j dW1lbnQgb3V0bGluZXMgYW4gYXBwcm9hY2ggdXRpbGlzaW5nIGV4aXN0aW5nIElQdjYgcHJvdG9j b2xzDQo+ICAgIHRvIGFsbG93IGhvc3RzIHRvIGJlIGFzc2lnbmVkIGEgdW5pcXVlIElQdjYgcHJl Zml4IChpbnN0ZWFkIG9mIGENCj4gICAgdW5pcXVlIElQdjYgYWRkcmVzcyBmcm9tIGEgc2hhcmVk IElQdjYgcHJlZml4KS4gIEJlbmVmaXRzIG9mIHVuaXF1ZQ0KPiAgICBJUHY2IHByZWZpeCBvdmVy IGEgdW5pcXVlIHNlcnZpY2UgcHJvdmlkZXIgSVB2NiBhZGRyZXNzIGluY2x1ZGUNCj4gICAgaW1w cm92ZWQgaG9zdCBpc29sYXRpb24gYW5kIGVuaGFuY2VkIHN1YnNjcmliZXIgbWFuYWdlbWVudCBv biBzaGFyZWQNCj4gICAgbmV0d29yayBzZWdtZW50cy4NCj4NCj4NCj4gVGhlIElFVEYgZGF0YXRy YWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1o b3N0Lw0KPg0KPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6 DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1p cHY2LXByZWZpeC1wZXItaG9zdC0wOA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA4DQo+ DQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtdW5pcXVl LWlwdjYtcHJlZml4LXBlci1ob3N0LTA4DQo+DQo+DQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KPg0KPiBJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9y ZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZv cHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3Bz DQoNCg== --_000_b8df290dc5854ee8962f8070dbd09bb1XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgbGlrZSBteSB0ZXh0IGJldHRlcjsgaXQg aXMgc2ltcGxlciwgYW5kIHNheXMgd2hhdCBpcyBuZWNlc3NhcnkgYW5kIHN1ZmZpY2llbnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkF0IGEgbWluaW11bSwgaXQgaGFzIHRvIGFkbWl0IHRoYXQgcGVlciB0 byBwZWVyIGlzIHBvc3NpYmxlIHVubGVzcyBzb21laG93PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnByZXZl bnRlZCBieSBMMiBtZWNoYW5pc21zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRv OmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIFNlcHRl bWJlciAxMywgMjAxNyAzOjA0IFBNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGluLCBGcmVkIEwgJmx0 O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb djZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBl ci1ob3N0LTA4LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHdvdWxkIGluc3RlYWQgc2F5IHRoZSBvcHBvc2l0ZSwgaS5lLiwgY2FsbCBh dHRlbnRpb24gdG8gd2hhdCBpcyBpbiBmYWN0IG9uZSBvZiB0aGUgdGhlIG1haW4gYmVuZWZpdHMg b2YgdGhpcyBkb2N1bWVudC4gU3VnZ2VzdGVkIHRleHQ6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJhY3RpY2VzIGRlc2NyaWJlZCBpbiB0aGlzIGRv Y3VtZW50IG1ha2UgaXQgdmVyeSBzaW1wbGUgZm9yIG5ldHdvcmtzIHRvIGltcGxlbWVudCByb2J1 c3QgaXNvbGF0aW9uIGJldHdlZW4gY2xpZW50cyBhdCBsYXllciAyLiBUaGUgbmV0d29yayBjYW4g c2ltcGx5IGVuc3VyZSB0aGF0IGRldmljZXMgY2Fubm90IHNlbmQgcGFja2V0cyB0byBlYWNoIG90 aGVyIGV4Y2VwdCB0aHJvdWdoIHRoZSBmaXJzdC1ob3ANCiByb3V0ZXIuIFRoaXMgd2lsbCBhdXRv bWF0aWNhbGx5IHByb3ZpZGUgcm9idXN0IHByb3RlY3Rpb24gYWdhaW5zdCBhdHRhY2tzIGJldHdl ZW4gZGV2aWNlcyB0aGF0IHJlbHkgb24gbGluay1sb2NhbCBJQ01QdjYgcGFja2V0cywgc3VjaCBh cyBEQUQgcmVwbHkgc3Bvb2ZpbmcsIE5EIGNhY2hlIGV4aGF1c3Rpb24sIG1hbGljaW91cyByZWRp cmVjdHMsIGFuZCByb2d1ZSBSQXMuIFRoaXMgZm9ybSBvZiBwcm90ZWN0aW9uIGlzIG11Y2ggbW9y ZSBzY2FsYWJsZQ0KIGFuZCByb2J1c3QgdGhhbiBhbHRlcm5hdGl2ZSBtZWNoYW5pc21zIHN1Y2gg YXMgREFEIHByb3h5aW5nLCBmb3JjZWQgZm9yd2FyZGluZywgb3IgTkQgc25vb3BpbmcuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBX ZWQsIFNlcCAxMywgMjAxNyBhdCAyOjEyIFBNLCBUZW1wbGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9 Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBhZGQgdGhlIGZvbGxvd2luZyB0byBT ZWN1cml0eSBDb25zaWRlcmF0aW9uczo8YnI+DQo8YnI+DQombmJzcDsgJnF1b3Q7V2hpbGUgdGhl IHByYWN0aWNlcyBkZXNjcmliZWQgaGVyZWluIGVuY291cmFnZSBMMyBvcGVyYXRpb25zIHRoYXQg d291bGQ8YnI+DQombmJzcDsgJm5ic3A7IGZvcndhcmQgYWxsIHRyYWZmaWMgdGhyb3VnaCBhIHBy b3ZpZGVyIG1hbmFnZWQgRmlyc3QgSG9wIFJvdXRlciwgcGVlciB0byBwZWVyPGJyPg0KJm5ic3A7 ICZuYnNwOyBjb21tdW5pY2F0aW9ucyBhcmUgc3RpbGwgcG9zc2libGUgdW5sZXNzIEwyIG1lY2hh bmlzbXMgYXJlIGFsc28gZW1wbG95ZWQ8YnI+DQombmJzcDsgJm5ic3A7IGluIHNvbWUgZmFzaGlv biBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiZxdW90Ozxicj4NCjxicj4NClRo YW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJv bTogdjZvcHMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+ djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZg0KPGEgaHJlZj0ibWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjxi cj4NCiZndDsgU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTcgNzowNCBBTTxicj4N CiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1hbm5v dW5jZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0 Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogW3Y2b3BzXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wOC50 eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxi cj4NCiZndDsgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRpb25z IFdHIG9mIHRoZSBJRVRGLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1RpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs6IFVuaXF1ZSBJUHY2IFByZWZpeCBQZXIgSG9zdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7QXV0aG9ycyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs6IEpvaG4gSmFzb24gQnJ6b3pvd3NraTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7R3VudGVyIFZhbiBEZSBWZWxkZTxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRy YWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA4LnR4dDxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7OiA5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0RhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTctMDkt MTM8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBU aGlzIGRvY3VtZW50IG91dGxpbmVzIGFuIGFwcHJvYWNoIHV0aWxpc2luZyBleGlzdGluZyBJUHY2 IHByb3RvY29sczxicj4NCiZndDsmbmJzcDsgJm5ic3A7IHRvIGFsbG93IGhvc3RzIHRvIGJlIGFz c2lnbmVkIGEgdW5pcXVlIElQdjYgcHJlZml4IChpbnN0ZWFkIG9mIGE8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLiZu YnNwOyBCZW5lZml0cyBvZiB1bmlxdWU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBJUHY2IHByZWZp eCBvdmVyIGEgdW5pcXVlIHNlcnZpY2UgcHJvdmlkZXIgSVB2NiBhZGRyZXNzIGluY2x1ZGU8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyBpbXByb3ZlZCBob3N0IGlzb2xhdGlvbiBhbmQgZW5oYW5jZWQg c3Vic2NyaWJlciBtYW5hZ2VtZW50IG9uIHNoYXJlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG5l dHdvcmsgc2VnbWVudHMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCiZndDsgPGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy11bmlx dWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1w ZXItaG9zdC88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQg dmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0 LTA4IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDg8L2E+PGJyPg0KJmd0OyA8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYt djZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA4IiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5p cXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA4PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IEEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3Bz LXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wOCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYt cHJlZml4LXBlci1ob3N0LTA4PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uPGJyPg0KJmd0OyB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8L2E+Ljxicj4NCiZndDs8YnI+DQomZ3Q7IElu dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+ DQomZ3Q7IDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJn ZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJyPg0K Jmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFp bHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxicj4N Cjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGll dGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_b8df290dc5854ee8962f8070dbd09bb1XCH150608nwnosboeingcom_-- From nobody Wed Sep 13 15:18:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7673613305C; Wed, 13 Sep 2017 15:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 LLGNBikkRDtH; Wed, 13 Sep 2017 15:18:35 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D2C133042; Wed, 13 Sep 2017 15:18:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8DMIXck036537; Wed, 13 Sep 2017 15:18:34 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8DMIR24036496 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 15:18:27 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Sep 2017 15:18:26 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 13 Sep 2017 15:18:26 -0700 From: "Templin, Fred L" To: Mark Smith CC: v6ops list , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt Thread-Index: AQHTLJkv/GFPUda+3EaDW5zERE6omaKzTQFQgACGnAD//44t8A== Date: Wed, 13 Sep 2017 22:18:26 +0000 Message-ID: <1df0139644aa4c8084ca6f4d207836e0@XCH15-06-08.nw.nos.boeing.com> References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_1df0139644aa4c8084ca6f4d207836e0XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 22:18:37 -0000 --_000_1df0139644aa4c8084ca6f4d207836e0XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyaywNCg0KRnJvbTogTWFyayBTbWl0aCBbbWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5j b21dDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMywgMjAxNyAzOjAxIFBNDQpUbzogVGVt cGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KQ2M6IHY2b3BzIGxpc3Qg PHY2b3BzQGlldGYub3JnPjsgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnOyBpLWQtYW5ub3VuY2VA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZv cHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA4LnR4dA0KDQoNCg0KT24gMTQgU2VwLiAy MDE3IDA3OjEyLCAiVGVtcGxpbiwgRnJlZCBMIiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxt YWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KUGxlYXNlIGFkZCB0aGUg Zm9sbG93aW5nIHRvIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zOg0KDQogICJXaGlsZSB0aGUgcHJh Y3RpY2VzIGRlc2NyaWJlZCBoZXJlaW4gZW5jb3VyYWdlIEwzIG9wZXJhdGlvbnMgdGhhdCB3b3Vs ZA0KICAgIGZvcndhcmQgYWxsIHRyYWZmaWMgdGhyb3VnaCBhIHByb3ZpZGVyIG1hbmFnZWQgRmly c3QgSG9wIFJvdXRlciwNCg0KVGhhdCBuZWVkcyB0byBiZSBhZGp1c3RlZCBzbGlnaHRseSB0byBi ZSBhY2N1cmF0ZS4gVW5sZXNzIGFuIE5EIHByb3h5IGlzIHVzZWQsIExMIHRyYWZmaWMgY2Fubm90 IGJlIG1hZGUgdG8gZ28gdGhvdWdoIHRoZSBmaXJzdCBob3Agcm91dGVyLg0KDQoNCsOYICAgIFJp Z2h0LCB0aGUgdGV4dCBkb2VzIG5vdCB0YWtlIExMIHRyYWZmaWMgaW50byBjb25zaWRlcmF0aW9u LiBJIGJvcnJvd2VkDQoNCsOYICAgIHRoZSB0ZXh0IGZyb20gdGhlIG1haW4gcG9ydGlvbiBvZiB0 aGUgZG9jdW1lbnQsIHNvIHlvdXIgY29tbWVudA0KDQrDmCAgICBwcm9iYWJseSBhcHBsaWVzIHRo ZXJlIGFzIHdlbGwuDQoNCkl0J2QgYmUgd29ydGggZXZlcnlib2R5IGludGVyZXN0ZWQgaW4gdGhp cyBkcmFmdCBoYXZpbmcgYSByZWFkIG9mDQoNCklQIG92ZXIgSW50ZW50aW9uYWxseSBQYXJ0aWFs bHkgUGFydGl0aW9uZWQgTGlua3MNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p bnRmLWludGFyZWEtaXBwbC0wMA0KDQpJdCByZWNvbW1lbmRzIGFnYWluc3QgdXNpbmcgYW4gTkQg cHJveHkuDQoNCkl0IHNob3VsZCBhbHNvIHByb2JhYmx5IGJlIHJlZmVyZW5jZWQgYnkgdGhpcyBk cmFmdC4NCg0KUmVnYXJkcywNCk1hcmsuDQoNCnBlZXIgdG8gcGVlcg0KICAgIGNvbW11bmljYXRp b25zIGFyZSBzdGlsbCBwb3NzaWJsZSB1bmxlc3MgTDIgbWVjaGFuaXNtcyBhcmUgYWxzbyBlbXBs b3llZA0KICAgIGluIHNvbWUgZmFzaGlvbiBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50LiINCg0KVGhhbmtzIC0gRnJlZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86djZvcHMt Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8 bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0 ZW1iZXIgMTMsIDIwMTcgNzowNCBBTQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0 bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+IENjOiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZv cHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12 Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDgudHh0DQo+DQo+DQo+IEEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBP cGVyYXRpb25zIFdHIG9mIHRoZSBJRVRGLg0KPg0KPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6 IFVuaXF1ZSBJUHY2IFByZWZpeCBQZXIgSG9zdA0KPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6 IEpvaG4gSmFzb24gQnJ6b3pvd3NraQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEd1bnRl ciBWYW4gRGUgVmVsZGUNCj4gICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi12Nm9w cy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDgudHh0DQo+ICAgICAgIFBhZ2VzICAgICAg ICAgICA6IDkNCj4gICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNy0wOS0xMw0KPg0KPiBBYnN0 cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBvdXRsaW5lcyBhbiBhcHByb2FjaCB1dGlsaXNpbmcg ZXhpc3RpbmcgSVB2NiBwcm90b2NvbHMNCj4gICAgdG8gYWxsb3cgaG9zdHMgdG8gYmUgYXNzaWdu ZWQgYSB1bmlxdWUgSVB2NiBwcmVmaXggKGluc3RlYWQgb2YgYQ0KPiAgICB1bmlxdWUgSVB2NiBh ZGRyZXNzIGZyb20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLiAgQmVuZWZpdHMgb2YgdW5pcXVlDQo+ ICAgIElQdjYgcHJlZml4IG92ZXIgYSB1bmlxdWUgc2VydmljZSBwcm92aWRlciBJUHY2IGFkZHJl c3MgaW5jbHVkZQ0KPiAgICBpbXByb3ZlZCBob3N0IGlzb2xhdGlvbiBhbmQgZW5oYW5jZWQgc3Vi c2NyaWJlciBtYW5hZ2VtZW50IG9uIHNoYXJlZA0KPiAgICBuZXR3b3JrIHNlZ21lbnRzLg0KPg0K Pg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy11bmlx dWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QvDQo+DQo+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZl cnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA4DQo+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1w cmVmaXgtcGVyLWhvc3QtMDgNCj4NCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDgNCj4NCj4NCj4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQo+ DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh dDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBs aXN0DQo+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3Bz QGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K --_000_1df0139644aa4c8084ca6f4d207836e0XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KaDENCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7 DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MjQuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xp c3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJ e21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IZWFkaW5nMUNoYXINCgl7bXNvLXN0eWxlLW5hbWU6Ikhl YWRpbmcgMSBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoi SGVhZGluZyAxIjsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCglj b2xvcjojMkU3NEI1O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTY1ODg3MDAyOw0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTA1MjIxMjUxMCAxMTY1 OTE4NDgwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBNYXJrLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE1hcmsgU21p dGggW21haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgU2VwdGVtYmVyIDEzLCAyMDE3IDM6MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBs aW4sIEZyZWQgTCAmbHQ7RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IHY2b3BzIGxpc3QgJmx0O3Y2b3BzQGlldGYub3JnJmd0OzsgaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnOyBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2 Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy LWhvc3QtMDgudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiAxNCBTZXAuIDIwMTcgMDc6MTIsICZxdW90O1RlbXBsaW4sIEZyZWQgTCZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iPkZyZWQuTC5UZW1w bGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UGxlYXNlIGFkZCB0aGUgZm9sbG93aW5nIHRvIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zOjxi cj4NCjxicj4NCiZuYnNwOyAmcXVvdDtXaGlsZSB0aGUgcHJhY3RpY2VzIGRlc2NyaWJlZCBoZXJl aW4gZW5jb3VyYWdlIEwzIG9wZXJhdGlvbnMgdGhhdCB3b3VsZDxicj4NCiZuYnNwOyAmbmJzcDsg Zm9yd2FyZCBhbGwgdHJhZmZpYyB0aHJvdWdoIGEgcHJvdmlkZXIgbWFuYWdlZCBGaXJzdCBIb3Ag Um91dGVyLDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBuZWVkcyB0byBiZSBhZGp1 c3RlZCBzbGlnaHRseSB0byBiZSBhY2N1cmF0ZS4gVW5sZXNzIGFuIE5EIHByb3h5IGlzIHVzZWQs IExMIHRyYWZmaWMgY2Fubm90IGJlIG1hZGUgdG8gZ28gdGhvdWdoIHRoZSBmaXJzdCBob3Agcm91 dGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50OjBpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SaWdo dCwgdGhlIHRleHQgZG9lcyBub3QgdGFrZSBMTCB0cmFmZmljIGludG8gY29uc2lkZXJhdGlvbi4g SSBib3Jyb3dlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGUgdGV4dCBmcm9tIHRo ZSBtYWluIHBvcnRpb24gb2YgdGhlIGRvY3VtZW50LCBzbyB5b3VyIGNvbW1lbnQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOY PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+cHJvYmFibHkgYXBwbGllcyB0aGVyZSBhcyB3ZWxsLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SXQnZCBiZSB3b3J0aCBldmVyeWJvZHkgaW50ZXJlc3RlZCBpbiB0aGlzIGRyYWZ0IGhhdmluZyBh IHJlYWQgb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGgxIHN0eWxlPSJtc28t bGluZS1oZWlnaHQtYWx0OjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SVAgb3ZlciBJbnRlbnRpb25hbGx5IFBhcnRp YWxseSBQYXJ0aXRpb25lZCBMaW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvaDE+DQo8aDEgc3R5bGU9 Im1zby1saW5lLWhlaWdodC1hbHQ6MHB0Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaW50Zi1pbnRhcmVhLWlwcGwtMDAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pbnRmLWludGFyZWEtaXBwbC0wMDwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L2gxPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCByZWNv bW1lbmRzIGFnYWluc3QgdXNpbmcgYW4gTkQgcHJveHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNob3VsZCBhbHNvIHByb2JhYmx5IGJl IHJlZmVyZW5jZWQgYnkgdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1hcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wZWVyIHRvIHBlZXI8YnI+DQom bmJzcDsgJm5ic3A7IGNvbW11bmljYXRpb25zIGFyZSBzdGlsbCBwb3NzaWJsZSB1bmxlc3MgTDIg bWVjaGFuaXNtcyBhcmUgYWxzbyBlbXBsb3llZDxicj4NCiZuYnNwOyAmbmJzcDsgaW4gc29tZSBm YXNoaW9uIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuJnF1b3Q7PGJyPg0KPGJy Pg0KVGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206 IHY2b3BzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmciPnY2 b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YNCjxhIGhyZWY9Im1haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT48YnI+ DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEzLCAyMDE3IDc6MDQgQU08YnI+DQom Z3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj5pLWQtYW5ub3Vu Y2VAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYu b3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFt2Nm9wc10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDgudHh0 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2 YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+ DQomZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBX RyBvZiB0aGUgSUVURi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtUaXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 OiBVbmlxdWUgSVB2NiBQcmVmaXggUGVyIEhvc3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0F1dGhvcnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 OiBKb2huIEphc29uIEJyem96b3dza2k8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0d1bnRlciBWYW4gRGUgVmVsZGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7RmlsZW5hbWUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBkcmFm dC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wOC50eHQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzogOTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtE YXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE3LTA5LTEz PGJyPg0KJmd0Ozxicj4NCiZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgVGhp cyBkb2N1bWVudCBvdXRsaW5lcyBhbiBhcHByb2FjaCB1dGlsaXNpbmcgZXhpc3RpbmcgSVB2NiBw cm90b2NvbHM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB0byBhbGxvdyBob3N0cyB0byBiZSBhc3Np Z25lZCBhIHVuaXF1ZSBJUHY2IHByZWZpeCAoaW5zdGVhZCBvZiBhPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgdW5pcXVlIElQdjYgYWRkcmVzcyBmcm9tIGEgc2hhcmVkIElQdjYgcHJlZml4KS4mbmJz cDsgQmVuZWZpdHMgb2YgdW5pcXVlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgSVB2NiBwcmVmaXgg b3ZlciBhIHVuaXF1ZSBzZXJ2aWNlIHByb3ZpZGVyIElQdjYgYWRkcmVzcyBpbmNsdWRlPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgaW1wcm92ZWQgaG9zdCBpc29sYXRpb24gYW5kIGVuaGFuY2VkIHN1 YnNjcmliZXIgbWFuYWdlbWVudCBvbiBzaGFyZWQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBuZXR3 b3JrIHNlZ21lbnRzLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgSUVURiBkYXRh dHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVl LWlwdjYtcHJlZml4LXBlci1ob3N0LyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy LWhvc3QvPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZl cnNpb25zIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0w OCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA4PC9hPjxicj4NCiZndDsgPGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2 b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wOCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1 ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wODwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBIGRpZmYg ZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy11 bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDgiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXBy ZWZpeC1wZXItaG9zdC0wODwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2Ygc3VibWlzc2lvbjxicj4NCiZndDsgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbnRl cm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0K Jmd0OyA8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyIgdGFyZ2V0 PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPjxicj4NCiZn dDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0 bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48YnI+DQo8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRm Lm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_1df0139644aa4c8084ca6f4d207836e0XCH150608nwnosboeingcom_-- From nobody Wed Sep 13 15:23:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F5C13304E for ; Wed, 13 Sep 2017 15:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 uw3yDzZozYko for ; Wed, 13 Sep 2017 15:23:45 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3397129A89 for ; Wed, 13 Sep 2017 15:23:44 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id r85so3639410ywg.1 for ; Wed, 13 Sep 2017 15:23:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tf8/QCfx3KPZTtoxcs57LWPdy/1FRSX8NBkh/cjrYkU=; b=JEIwXs+v7TYXPlgL2JvITJslK1+2/DR2zGUfxSYVDgYyQPRz6QCHbNHSsIVfJkvzVh ti96yFUVSzdfQ4N4/fd7xkFauRjPPHsL/45VznB3ofGY3wMa5hstxVIAJHAJoRNDIDYz hu8srbwz3Quhvs6lD2hlcYwI+uRNSq4AJFOGZTKqjA+0Y4d0YN7mb3yaQGBPhifONC/R IyWF6Zu+o9HAfbFsgcZ69aPmqxyIPyIvNl+ZbQ5VYYcYNHeEoChnDyMdvNWnW559dCEZ C0nY7AnFfLtQnfhPI9kim9W061nhiwjycJ6yF5ierLJKT/VlGxNi04tkLP/9H8a8R/lI R1uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Tf8/QCfx3KPZTtoxcs57LWPdy/1FRSX8NBkh/cjrYkU=; b=Vzjwafcs3HGDmN9jGLrXK3ei9e1keWyCYyxrUDNghRXnWthQMhJv3258m+ZzXHu7Zj D447Ta4KxxhqkUwkH+yX5dC13WpGi7gRhXR4biiqs+i252tv1Otx6LGpimOYxQ/OHXEZ DxaVmmjTH6Sn6kI17Ix3laSw8VF8y7BbdrEJQUWVozXV4ebO2MHxY90hqMt3DZc1shW2 Ptl4PBQzw3KtevyYVG/oXMw2DQRfQS1ghcJCQUDrYyi1n8IlQR5Y46xOIyM9TfQOLYua lOV7VCXTm6TsHxNI9K2GulF616xnzMbOlRiEq19lVhs2LiVfgpa6nQiyURnvgMoyxsAY eGOQ== X-Gm-Message-State: AHPjjUjL/eN8EwUVW2+IGug+BhpFka/xUmoFyatWjIqI5St7LzLqEo7q R07MzXfWAG3y+v1/OnFIBjvf/kFQtcal9+EyAfllgQ== X-Google-Smtp-Source: ADKCNb5ebi9yakq4aFCdbE30c0nksqUxsPcbDyzg1YDtVvyD5Le8Zi7GgeQSg9hudVUvgtmt2XLJvEt/rTaKT/wtOCQ= X-Received: by 10.129.233.12 with SMTP id d12mr16602170ywm.213.1505341423575; Wed, 13 Sep 2017 15:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Wed, 13 Sep 2017 15:23:22 -0700 (PDT) In-Reply-To: References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Wed, 13 Sep 2017 15:23:22 -0700 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="089e08221fc8d217a30559199c69" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 22:23:47 -0000 --089e08221fc8d217a30559199c69 Content-Type: text/plain; charset="UTF-8" That you like your text better is not surprising. :-) But the reality is that peer-to-peer communication on a public network enables a whole class of attacks, and the major advantage of the prefix-per-host model is that it makes it possible to defend against those attacks in a scalable way. This model allows implementing security in a scalable way, and this draft should say that. At a minimum, if we want to say that peer-to-peer is possible, we *must* also say that peer-to-peer communication enables a whole class of attacks that can be very simply defended against if it not allowed. On Wed, Sep 13, 2017 at 3:10 PM, Templin, Fred L wrote: > I like my text better; it is simpler, and says what is necessary and > sufficient. > > At a minimum, it has to admit that peer to peer is possible unless somehow > > prevented by L2 mechanisms. > > > > Thanks - Fred > > > > *From:* Lorenzo Colitti [mailto:lorenzo@google.com] > *Sent:* Wednesday, September 13, 2017 3:04 PM > *To:* Templin, Fred L > *Cc:* internet-drafts@ietf.org; v6ops@ietf.org > *Subject:* Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-p > refix-per-host-08.txt > > > > I would instead say the opposite, i.e., call attention to what is in fact > one of the the main benefits of this document. Suggested text: > > > > The practices described in this document make it very simple for networks > to implement robust isolation between clients at layer 2. The network can > simply ensure that devices cannot send packets to each other except through > the first-hop router. This will automatically provide robust protection > against attacks between devices that rely on link-local ICMPv6 packets, > such as DAD reply spoofing, ND cache exhaustion, malicious redirects, and > rogue RAs. This form of protection is much more scalable and robust than > alternative mechanisms such as DAD proxying, forced forwarding, or ND > snooping. > > > > > > > > On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L < > Fred.L.Templin@boeing.com> wrote: > > Please add the following to Security Considerations: > > "While the practices described herein encourage L3 operations that would > forward all traffic through a provider managed First Hop Router, peer > to peer > communications are still possible unless L2 mechanisms are also > employed > in some fashion outside the scope of this document." > > Thanks - Fred > > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > > Sent: Wednesday, September 13, 2017 7:04 AM > > To: i-d-announce@ietf.org > > Cc: v6ops@ietf.org > > Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-p > refix-per-host-08.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the IPv6 Operations WG of the IETF. > > > > Title : Unique IPv6 Prefix Per Host > > Authors : John Jason Brzozowski > > Gunter Van De Velde > > Filename : draft-ietf-v6ops-unique-ipv6-p > refix-per-host-08.txt > > Pages : 9 > > Date : 2017-09-13 > > > > Abstract: > > This document outlines an approach utilising existing IPv6 protocols > > to allow hosts to be assigned a unique IPv6 prefix (instead of a > > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > > IPv6 prefix over a unique service provider IPv6 address include > > improved host isolation and enhanced subscriber management on shared > > network segments. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv > 6-prefix-per-host/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-pre > fix-per-host-08 > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-uniqu > e-ipv6-prefix-per-host-08 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ip > v6-prefix-per-host-08 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > > > --089e08221fc8d217a30559199c69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That you like your text better is not surprising. :-)
=
But the reality is that peer-to-peer communication on a publ= ic network enables a whole class of attacks, and the major advantage of the= prefix-per-host model is that it makes it possible to defend against those= attacks in a scalable way. This model allows implementing security in a sc= alable way, and this draft should say that.

At a m= inimum, if we want to say that peer-to-peer is possible, we *must* also say= that peer-to-peer communication enables a whole class of attacks that can = be very simply defended against if it not allowed.

On Wed, Sep 13, 2017 at 3:10 PM, Tem= plin, Fred L <Fred.L.Templin@boeing.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

I like my text better; it is simpler,= and says what is necessary and sufficient.

At a minimum, it has to admit that pe= er to peer is possible unless somehow

prevented by L2 mechanisms.=

=C2=A0

Thanks - Fred

=C2=A0

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Wednesday, September 13, 2017 3:04 PM
To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: in= ternet-drafts@ietf.org; v6ops@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-p= refix-per-host-08.txt

=C2=A0

I would instead say the opposite, i.e., call attenti= on to what is in fact one of the the main benefits of this document. Sugges= ted text:

=C2=A0

The practices described in this document make it ver= y simple for networks to implement robust isolation between clients at laye= r 2. The network can simply ensure that devices cannot send packets to each= other except through the first-hop router. This will automatically provide robust protection against attacks = between devices that rely on link-local ICMPv6 packets, such as DAD reply s= poofing, ND cache exhaustion, malicious redirects, and rogue RAs. This form= of protection is much more scalable and robust than alternative mechanisms such as DAD proxying, forced forwar= ding, or ND snooping.

=C2=A0

=C2=A0

=C2=A0

On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L <= ;Fred.L.Temp= lin@boeing.com> wrote:

Please add the following to Security Considerations:=

=C2=A0 "While the practices described herein encourage L3 operations t= hat would
=C2=A0 =C2=A0 forward all traffic through a provider managed First Hop Rout= er, peer to peer
=C2=A0 =C2=A0 communications are still possible unless L2 mechanisms are al= so employed
=C2=A0 =C2=A0 in some fashion outside the scope of this document."

Thanks - Fred


> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-draf= ts@ietf.org
> Sent: Wednesday, September 13, 2017 7:04 AM
> To: i-d-ann= ounce@ietf.org
> Cc: v6ops@ietf.org=
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-= per-host-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the IPv6 Operations WG of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Unique IPv6 Prefix Per Host
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: John Jason Brzozowski
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Gunter Van De Velde
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 9
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-09-13
>
> Abstract:
>=C2=A0 =C2=A0 This document outlines an approach utilising existing IPv= 6 protocols
>=C2=A0 =C2=A0 to allow hosts to be assigned a unique IPv6 prefix (inste= ad of a
>=C2=A0 =C2=A0 unique IPv6 address from a shared IPv6 prefix).=C2=A0 Ben= efits of unique
>=C2=A0 =C2=A0 IPv6 prefix over a unique service provider IPv6 address i= nclude
>=C2=A0 =C2=A0 improved host isolation and enhanced subscriber managemen= t on shared
>=C2=A0 =C2=A0 network segments.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-pre= fix-per-host/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-p= er-host-08
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv= 6-prefix-per-host-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-= prefix-per-host-08
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> 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


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

=C2=A0


--089e08221fc8d217a30559199c69-- From nobody Wed Sep 13 15:31:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3382C132F65 for ; Wed, 13 Sep 2017 15:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 h9iORTcbGmYG for ; Wed, 13 Sep 2017 15:31:24 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB28129A89 for ; Wed, 13 Sep 2017 15:31:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8DMVOHW011690; Wed, 13 Sep 2017 15:31:24 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8DMVDFD011591 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 13 Sep 2017 15:31:13 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Sep 2017 15:31:13 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 13 Sep 2017 15:31:13 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt Thread-Index: AQHTLJkv/GFPUda+3EaDW5zERE6omaKzTQFQgACHbgD//4wjsIAAeWUA//+LfhA= Date: Wed, 13 Sep 2017 22:31:12 +0000 Message-ID: References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_c8485a52b0d34567941ec8043e1b9197XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 22:31:27 -0000 --_000_c8485a52b0d34567941ec8043e1b9197XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXNpZGUgZnJvbSBNYXJrIFNtaXRo4oCZcyBjb21tZW50IG9uIExMcywgSSBzdGlsbCBkb27igJl0 IGdldCB3aGF0IHlvdSB0aGluaw0KaXMgaW5zdWZmaWNpZW50IGluIHRoZSB0ZXh0IEkgb2ZmZXJl ZC4gVGhlIHRocmVhdCBtb2RlbCBmb3IgcGVlci10by1wZWVyIGlzDQpjZXJ0YWlubHkgb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCBhbmQgZG9lcyBub3QgYXBwbHkgaW4gY2FzZXMN CndoZXJlIHBlZXItdG8tcGVlciBpcyBkZXNpcmFibGUuDQoNCkZyZWQNCg0KRnJvbTogTG9yZW56 byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBT ZXB0ZW1iZXIgMTMsIDIwMTcgMzoyMyBQTQ0KVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbT4NCkNjOiB2Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9w c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhv c3QtMDgudHh0DQoNClRoYXQgeW91IGxpa2UgeW91ciB0ZXh0IGJldHRlciBpcyBub3Qgc3VycHJp c2luZy4gOi0pDQoNCkJ1dCB0aGUgcmVhbGl0eSBpcyB0aGF0IHBlZXItdG8tcGVlciBjb21tdW5p Y2F0aW9uIG9uIGEgcHVibGljIG5ldHdvcmsgZW5hYmxlcyBhIHdob2xlIGNsYXNzIG9mIGF0dGFj a3MsIGFuZCB0aGUgbWFqb3IgYWR2YW50YWdlIG9mIHRoZSBwcmVmaXgtcGVyLWhvc3QgbW9kZWwg aXMgdGhhdCBpdCBtYWtlcyBpdCBwb3NzaWJsZSB0byBkZWZlbmQgYWdhaW5zdCB0aG9zZSBhdHRh Y2tzIGluIGEgc2NhbGFibGUgd2F5LiBUaGlzIG1vZGVsIGFsbG93cyBpbXBsZW1lbnRpbmcgc2Vj dXJpdHkgaW4gYSBzY2FsYWJsZSB3YXksIGFuZCB0aGlzIGRyYWZ0IHNob3VsZCBzYXkgdGhhdC4N Cg0KQXQgYSBtaW5pbXVtLCBpZiB3ZSB3YW50IHRvIHNheSB0aGF0IHBlZXItdG8tcGVlciBpcyBw b3NzaWJsZSwgd2UgKm11c3QqIGFsc28gc2F5IHRoYXQgcGVlci10by1wZWVyIGNvbW11bmljYXRp b24gZW5hYmxlcyBhIHdob2xlIGNsYXNzIG9mIGF0dGFja3MgdGhhdCBjYW4gYmUgdmVyeSBzaW1w bHkgZGVmZW5kZWQgYWdhaW5zdCBpZiBpdCBub3QgYWxsb3dlZC4NCg0KT24gV2VkLCBTZXAgMTMs IDIwMTcgYXQgMzoxMCBQTSwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQpJIGxpa2UgbXkg dGV4dCBiZXR0ZXI7IGl0IGlzIHNpbXBsZXIsIGFuZCBzYXlzIHdoYXQgaXMgbmVjZXNzYXJ5IGFu ZCBzdWZmaWNpZW50Lg0KQXQgYSBtaW5pbXVtLCBpdCBoYXMgdG8gYWRtaXQgdGhhdCBwZWVyIHRv IHBlZXIgaXMgcG9zc2libGUgdW5sZXNzIHNvbWVob3cNCnByZXZlbnRlZCBieSBMMiBtZWNoYW5p c21zLg0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxv cmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tPl0NClNlbnQ6IFdlZG5l c2RheSwgU2VwdGVtYmVyIDEzLCAyMDE3IDM6MDQgUE0NClRvOiBUZW1wbGluLCBGcmVkIEwgPEZy ZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+ Pg0KQ2M6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPjsgdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVm aXgtcGVyLWhvc3QtMDgudHh0DQoNCkkgd291bGQgaW5zdGVhZCBzYXkgdGhlIG9wcG9zaXRlLCBp LmUuLCBjYWxsIGF0dGVudGlvbiB0byB3aGF0IGlzIGluIGZhY3Qgb25lIG9mIHRoZSB0aGUgbWFp biBiZW5lZml0cyBvZiB0aGlzIGRvY3VtZW50LiBTdWdnZXN0ZWQgdGV4dDoNCg0KVGhlIHByYWN0 aWNlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBtYWtlIGl0IHZlcnkgc2ltcGxlIGZvciBu ZXR3b3JrcyB0byBpbXBsZW1lbnQgcm9idXN0IGlzb2xhdGlvbiBiZXR3ZWVuIGNsaWVudHMgYXQg bGF5ZXIgMi4gVGhlIG5ldHdvcmsgY2FuIHNpbXBseSBlbnN1cmUgdGhhdCBkZXZpY2VzIGNhbm5v dCBzZW5kIHBhY2tldHMgdG8gZWFjaCBvdGhlciBleGNlcHQgdGhyb3VnaCB0aGUgZmlyc3QtaG9w IHJvdXRlci4gVGhpcyB3aWxsIGF1dG9tYXRpY2FsbHkgcHJvdmlkZSByb2J1c3QgcHJvdGVjdGlv biBhZ2FpbnN0IGF0dGFja3MgYmV0d2VlbiBkZXZpY2VzIHRoYXQgcmVseSBvbiBsaW5rLWxvY2Fs IElDTVB2NiBwYWNrZXRzLCBzdWNoIGFzIERBRCByZXBseSBzcG9vZmluZywgTkQgY2FjaGUgZXho YXVzdGlvbiwgbWFsaWNpb3VzIHJlZGlyZWN0cywgYW5kIHJvZ3VlIFJBcy4gVGhpcyBmb3JtIG9m IHByb3RlY3Rpb24gaXMgbXVjaCBtb3JlIHNjYWxhYmxlIGFuZCByb2J1c3QgdGhhbiBhbHRlcm5h dGl2ZSBtZWNoYW5pc21zIHN1Y2ggYXMgREFEIHByb3h5aW5nLCBmb3JjZWQgZm9yd2FyZGluZywg b3IgTkQgc25vb3BpbmcuDQoNCg0KDQpPbiBXZWQsIFNlcCAxMywgMjAxNyBhdCAyOjEyIFBNLCBU ZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNClBsZWFzZSBhZGQgdGhlIGZvbGxvd2luZyB0byBT ZWN1cml0eSBDb25zaWRlcmF0aW9uczoNCg0KICAiV2hpbGUgdGhlIHByYWN0aWNlcyBkZXNjcmli ZWQgaGVyZWluIGVuY291cmFnZSBMMyBvcGVyYXRpb25zIHRoYXQgd291bGQNCiAgICBmb3J3YXJk IGFsbCB0cmFmZmljIHRocm91Z2ggYSBwcm92aWRlciBtYW5hZ2VkIEZpcnN0IEhvcCBSb3V0ZXIs IHBlZXIgdG8gcGVlcg0KICAgIGNvbW11bmljYXRpb25zIGFyZSBzdGlsbCBwb3NzaWJsZSB1bmxl c3MgTDIgbWVjaGFuaXNtcyBhcmUgYWxzbyBlbXBsb3llZA0KICAgIGluIHNvbWUgZmFzaGlvbiBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiINCg0KVGhhbmtzIC0gRnJlZA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3BzIFttYWlsdG86djZvcHMt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZz4NCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTcgNzowNCBBTQ0KPiBU bzogaS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+DQo+ IENjOiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFt2 Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy LWhvc3QtMDgudHh0DQo+DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRpb25zIFdHIG9mIHRoZSBJRVRGLg0K Pg0KPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFVuaXF1ZSBJUHY2IFByZWZpeCBQZXIgSG9z dA0KPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IEpvaG4gSmFzb24gQnJ6b3pvd3NraQ0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgIEd1bnRlciBWYW4gRGUgVmVsZGUNCj4gICAgICAgRmls ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhv c3QtMDgudHh0DQo+ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDkNCj4gICAgICAgRGF0ZSAgICAg ICAgICAgIDogMjAxNy0wOS0xMw0KPg0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBv dXRsaW5lcyBhbiBhcHByb2FjaCB1dGlsaXNpbmcgZXhpc3RpbmcgSVB2NiBwcm90b2NvbHMNCj4g ICAgdG8gYWxsb3cgaG9zdHMgdG8gYmUgYXNzaWduZWQgYSB1bmlxdWUgSVB2NiBwcmVmaXggKGlu c3RlYWQgb2YgYQ0KPiAgICB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gYSBzaGFyZWQgSVB2NiBw cmVmaXgpLiAgQmVuZWZpdHMgb2YgdW5pcXVlDQo+ICAgIElQdjYgcHJlZml4IG92ZXIgYSB1bmlx dWUgc2VydmljZSBwcm92aWRlciBJUHY2IGFkZHJlc3MgaW5jbHVkZQ0KPiAgICBpbXByb3ZlZCBo b3N0IGlzb2xhdGlvbiBhbmQgZW5oYW5jZWQgc3Vic2NyaWJlciBtYW5hZ2VtZW50IG9uIHNoYXJl ZA0KPiAgICBuZXR3b3JrIHNlZ21lbnRzLg0KPg0KPg0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QvDQo+ DQo+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJl Zml4LXBlci1ob3N0LTA4DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv ZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDgNCj4NCj4gQSBk aWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1w cmVmaXgtcGVyLWhvc3QtMDgNCj4NCj4NCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQo+DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnPG1haWx0 bzp2Nm9wc0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KDQo= --_000_c8485a52b0d34567941ec8043e1b9197XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFzaWRlIGZyb20gTWFyayBTbWl0aOKAmXMg Y29tbWVudCBvbiBMTHMsIEkgc3RpbGwgZG9u4oCZdCBnZXQgd2hhdCB5b3UgdGhpbms8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+aXMgaW5zdWZmaWNpZW50IGluIHRoZSB0ZXh0IEkgb2ZmZXJlZC4gVGhlIHRo cmVhdCBtb2RlbCBmb3IgcGVlci10by1wZWVyIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmNlcnRhaW5s eSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50IGFuZCBkb2VzIG5vdCBhcHBseSBp biBjYXNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj53aGVyZSBwZWVyLXRvLXBlZXIgaXMgZGVzaXJhYmxl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJlZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMywgMjAxNyAzOjIzIFBNPGJyPg0KPGI+ VG86PC9iPiBUZW1wbGluLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1w ZXItaG9zdC0wOC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhdCB5b3UgbGlrZSB5b3VyIHRleHQgYmV0dGVyIGlzIG5vdCBzdXJwcmlz aW5nLiA6LSk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1 dCB0aGUgcmVhbGl0eSBpcyB0aGF0IHBlZXItdG8tcGVlciBjb21tdW5pY2F0aW9uIG9uIGEgcHVi bGljIG5ldHdvcmsgZW5hYmxlcyBhIHdob2xlIGNsYXNzIG9mIGF0dGFja3MsIGFuZCB0aGUgbWFq b3IgYWR2YW50YWdlIG9mIHRoZSBwcmVmaXgtcGVyLWhvc3QgbW9kZWwgaXMgdGhhdCBpdCBtYWtl cyBpdCBwb3NzaWJsZSB0byBkZWZlbmQgYWdhaW5zdCB0aG9zZSBhdHRhY2tzIGluIGEgc2NhbGFi bGUgd2F5Lg0KIFRoaXMgbW9kZWwgYWxsb3dzIGltcGxlbWVudGluZyBzZWN1cml0eSBpbiBhIHNj YWxhYmxlIHdheSwgYW5kIHRoaXMgZHJhZnQgc2hvdWxkIHNheSB0aGF0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCBhIG1pbmltdW0sIGlm IHdlIHdhbnQgdG8gc2F5IHRoYXQgcGVlci10by1wZWVyIGlzIHBvc3NpYmxlLCB3ZSAqbXVzdCog YWxzbyBzYXkgdGhhdCBwZWVyLXRvLXBlZXIgY29tbXVuaWNhdGlvbiBlbmFibGVzIGEgd2hvbGUg Y2xhc3Mgb2YgYXR0YWNrcyB0aGF0IGNhbiBiZSB2ZXJ5IHNpbXBseSBkZWZlbmRlZCBhZ2FpbnN0 IGlmIGl0IG5vdCBhbGxvd2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gV2VkLCBTZXAgMTMsIDIwMTcgYXQgMzoxMCBQTSwgVGVtcGxpbiwgRnJlZCBM ICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgbGlrZSBteSB0ZXh0IGJldHRlcjsgaXQg aXMgc2ltcGxlciwgYW5kIHNheXMgd2hhdCBpcyBuZWNlc3NhcnkgYW5kIHN1ZmZpY2llbnQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+QXQgYSBtaW5pbXVtLCBpdCBoYXMgdG8gYWRtaXQgdGhhdCBwZWVy IHRvIHBlZXIgaXMgcG9zc2libGUgdW5sZXNzIHNvbWVob3c8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5w cmV2ZW50ZWQgYnkgTDIgbWVjaGFuaXNtcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExvcmVuem8gQ29s aXR0aSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5sb3JlbnpvQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgU2VwdGVtYmVyIDEzLCAyMDE3IDM6MDQgUE08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4s IEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iIHRh cmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDs8YnI+DQo8Yj5D Yzo8L2I+IDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnY2 b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5p cXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA4LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdvdWxkIGlu c3RlYWQgc2F5IHRoZSBvcHBvc2l0ZSwgaS5lLiwgY2FsbCBhdHRlbnRpb24gdG8gd2hhdCBpcyBp biBmYWN0IG9uZSBvZiB0aGUgdGhlIG1haW4gYmVuZWZpdHMgb2YgdGhpcyBkb2N1bWVudC4gU3Vn Z2VzdGVkIHRleHQ6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhlIHByYWN0aWNlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBtYWtlIGl0IHZl cnkgc2ltcGxlIGZvciBuZXR3b3JrcyB0byBpbXBsZW1lbnQgcm9idXN0IGlzb2xhdGlvbiBiZXR3 ZWVuIGNsaWVudHMgYXQgbGF5ZXIgMi4gVGhlIG5ldHdvcmsgY2FuIHNpbXBseSBlbnN1cmUgdGhh dCBkZXZpY2VzIGNhbm5vdA0KIHNlbmQgcGFja2V0cyB0byBlYWNoIG90aGVyIGV4Y2VwdCB0aHJv dWdoIHRoZSBmaXJzdC1ob3Agcm91dGVyLiBUaGlzIHdpbGwgYXV0b21hdGljYWxseSBwcm92aWRl IHJvYnVzdCBwcm90ZWN0aW9uIGFnYWluc3QgYXR0YWNrcyBiZXR3ZWVuIGRldmljZXMgdGhhdCBy ZWx5IG9uIGxpbmstbG9jYWwgSUNNUHY2IHBhY2tldHMsIHN1Y2ggYXMgREFEIHJlcGx5IHNwb29m aW5nLCBORCBjYWNoZSBleGhhdXN0aW9uLCBtYWxpY2lvdXMgcmVkaXJlY3RzLA0KIGFuZCByb2d1 ZSBSQXMuIFRoaXMgZm9ybSBvZiBwcm90ZWN0aW9uIGlzIG11Y2ggbW9yZSBzY2FsYWJsZSBhbmQg cm9idXN0IHRoYW4gYWx0ZXJuYXRpdmUgbWVjaGFuaXNtcyBzdWNoIGFzIERBRCBwcm94eWluZywg Zm9yY2VkIGZvcndhcmRpbmcsIG9yIE5EIHNub29waW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIFNlcCAx MywgMjAxNyBhdCAyOjEyIFBNLCBUZW1wbGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlBsZWFzZSBhZGQgdGhlIGZvbGxvd2luZyB0byBTZWN1cml0eSBDb25zaWRlcmF0aW9uczo8YnI+ DQo8YnI+DQombmJzcDsgJnF1b3Q7V2hpbGUgdGhlIHByYWN0aWNlcyBkZXNjcmliZWQgaGVyZWlu IGVuY291cmFnZSBMMyBvcGVyYXRpb25zIHRoYXQgd291bGQ8YnI+DQombmJzcDsgJm5ic3A7IGZv cndhcmQgYWxsIHRyYWZmaWMgdGhyb3VnaCBhIHByb3ZpZGVyIG1hbmFnZWQgRmlyc3QgSG9wIFJv dXRlciwgcGVlciB0byBwZWVyPGJyPg0KJm5ic3A7ICZuYnNwOyBjb21tdW5pY2F0aW9ucyBhcmUg c3RpbGwgcG9zc2libGUgdW5sZXNzIEwyIG1lY2hhbmlzbXMgYXJlIGFsc28gZW1wbG95ZWQ8YnI+ DQombmJzcDsgJm5ic3A7IGluIHNvbWUgZmFzaGlvbiBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50LiZxdW90Ozxicj4NCjxicj4NClRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQomZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiB2Nm9wcyBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHMtYm91 bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZg0KPGEgaHJlZj0ibWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDEzLCAyMDE3IDc6MDQg QU08YnI+DQomZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCiZndDsgQ2M6IDxh IGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYu b3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wOC50eHQ8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NCiZndDsgVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRpb25zIFdHIG9mIHRoZSBJRVRGLjxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RpdGxl Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IFVuaXF1ZSBJUHY2IFBy ZWZpeCBQZXIgSG9zdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 QXV0aG9ycyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IEpvaG4gSmFzb24gQnJ6 b3pvd3NraTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 R3VudGVyIFZhbiBEZSBWZWxkZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtG aWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtdjZvcHMtdW5p cXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA4LnR4dDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 OiA5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RhdGUmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTctMDktMTM8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBBYnN0cmFjdDo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUaGlzIGRvY3VtZW50IG91dGxp bmVzIGFuIGFwcHJvYWNoIHV0aWxpc2luZyBleGlzdGluZyBJUHY2IHByb3RvY29sczxicj4NCiZn dDsmbmJzcDsgJm5ic3A7IHRvIGFsbG93IGhvc3RzIHRvIGJlIGFzc2lnbmVkIGEgdW5pcXVlIElQ djYgcHJlZml4IChpbnN0ZWFkIG9mIGE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB1bmlxdWUgSVB2 NiBhZGRyZXNzIGZyb20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLiZuYnNwOyBCZW5lZml0cyBvZiB1 bmlxdWU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBJUHY2IHByZWZpeCBvdmVyIGEgdW5pcXVlIHNl cnZpY2UgcHJvdmlkZXIgSVB2NiBhZGRyZXNzIGluY2x1ZGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyBpbXByb3ZlZCBob3N0IGlzb2xhdGlvbiBhbmQgZW5oYW5jZWQgc3Vic2NyaWJlciBtYW5hZ2Vt ZW50IG9uIHNoYXJlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7IG5ldHdvcmsgc2VnbWVudHMuPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVy LWhvc3QvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC88L2E+PGJyPg0K Jmd0Ozxicj4NCiZndDsgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxl IGF0Ojxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA4IiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUt aXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDg8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYt cHJlZml4LXBlci1ob3N0LTA4IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBl ci1ob3N0LTA4PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91 cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZp eC1wZXItaG9zdC0wOCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA4 PC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJy Pg0KJmd0OyB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9v bHMuaWV0Zi5vcmc8L2E+Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUg YWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQomZ3Q7IDxhIGhyZWY9ImZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHY2 b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48YnI+DQo8 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_c8485a52b0d34567941ec8043e1b9197XCH150608nwnosboeingcom_-- From nobody Wed Sep 13 20:47:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046C1133062 for ; Wed, 13 Sep 2017 20:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59ZRD5ZHWrtC for ; Wed, 13 Sep 2017 20:47:27 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A603132811 for ; Wed, 13 Sep 2017 20:47:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8E3lPWk039797 for ; Thu, 14 Sep 2017 05:47:25 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 569DC202DC6 for ; Thu, 14 Sep 2017 05:47:25 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4CFC9200B40 for ; Thu, 14 Sep 2017 05:47:25 +0200 (CEST) Received: from [132.166.84.22] ([132.166.84.22]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8E3lOfA025015 for ; Thu, 14 Sep 2017 05:47:24 +0200 To: v6ops@ietf.org References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <134994a0-046f-11c9-f9d8-bb27ef27d105@gmail.com> Date: Thu, 14 Sep 2017 05:47:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 03:47:30 -0000 Le 14/09/2017 à 00:23, Lorenzo Colitti a écrit : > That you like your text better is not surprising. :-) > > But the reality is that peer-to-peer communication on a public network > enables a whole class of attacks, and the major advantage of the > prefix-per-host model is that it makes it possible to defend against > those attacks in a scalable way. This model allows implementing security > in a scalable way, and this draft should say that. > > At a minimum, if we want to say that peer-to-peer is possible, we *must* > also say that peer-to-peer communication enables a whole class of > attacks that can be very simply defended against if it not allowed. Well, there is SeND. Alex > > On Wed, Sep 13, 2017 at 3:10 PM, Templin, Fred L > > wrote: > > I like my text better; it is simpler, and says what is necessary and > sufficient.____ > > At a minimum, it has to admit that peer to peer is possible unless > somehow____ > > prevented by L2 mechanisms.____ > > __ __ > > Thanks - Fred____ > > __ __ > > *From:*Lorenzo Colitti [mailto:lorenzo@google.com > ] > *Sent:* Wednesday, September 13, 2017 3:04 PM > *To:* Templin, Fred L > > *Cc:* internet-drafts@ietf.org ; > v6ops@ietf.org > *Subject:* Re: [v6ops] I-D Action: > draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt____ > > __ __ > > I would instead say the opposite, i.e., call attention to what is in > fact one of the the main benefits of this document. Suggested text:____ > > __ __ > > The practices described in this document make it very simple for > networks to implement robust isolation between clients at layer 2. > The network can simply ensure that devices cannot send packets to > each other except through the first-hop router. This will > automatically provide robust protection against attacks between > devices that rely on link-local ICMPv6 packets, such as DAD reply > spoofing, ND cache exhaustion, malicious redirects, and rogue RAs. > This form of protection is much more scalable and robust than > alternative mechanisms such as DAD proxying, forced forwarding, or > ND snooping.____ > > __ __ > > __ __ > > __ __ > > On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L > > > wrote:____ > > Please add the following to Security Considerations: > >   "While the practices described herein encourage L3 operations > that would >     forward all traffic through a provider managed First Hop > Router, peer to peer >     communications are still possible unless L2 mechanisms are > also employed >     in some fashion outside the scope of this document." > > Thanks - Fred____ > > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org > ] On Behalf Of > internet-drafts@ietf.org > > Sent: Wednesday, September 13, 2017 7:04 AM > > To: i-d-announce@ietf.org > > Cc: v6ops@ietf.org > > Subject: [v6ops] I-D Action: > draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt > > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > This draft is a work item of the IPv6 Operations WG of the IETF. > > > >         Title           : Unique IPv6 Prefix Per Host > >         Authors         : John Jason Brzozowski > >                           Gunter Van De Velde > >       Filename        : > draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt > >       Pages           : 9 > >       Date            : 2017-09-13 > > > > Abstract: > >    This document outlines an approach utilising existing IPv6 > protocols > >    to allow hosts to be assigned a unique IPv6 prefix > (instead of a > >    unique IPv6 address from a shared IPv6 prefix).  Benefits > of unique > >    IPv6 prefix over a unique service provider IPv6 address > include > >    improved host isolation and enhanced subscriber management > on shared > >    network segments. > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08 > > > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08 > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-08 > > > > > > > Please note that it may take a couple of minutes from the > time of submission > > until the htmlized version and diff are available at > tools.ietf.org . > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > ____ > > __ __ > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 13 22:57:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004831330B1 for ; Wed, 13 Sep 2017 22:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgWb4bEWl_F4 for ; Wed, 13 Sep 2017 22:57:54 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0092.outbound.protection.outlook.com [104.47.37.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC8C1321DE for ; Wed, 13 Sep 2017 22:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LWHBTVKLfgB68MAAqAHiwuLO0wuLeCwF1LO28kRp32w=; b=fQRI7acQyMxXnbLsBbxG0XFPHSHbvXxnytFF4dVLlQ4OoGsviaRf7FHe03W6LqPWv/1a93fmDRvRhcA1d0mAk2b9/6hoyXORkPwaN7dZ95mPAyRr+UOC8T1txRYgo2i8mMTUbyHsDjF3OR/OBCkLzz6tGMryd4YTotmb3Ina3nw= Received: from MWHPR21MB0703.namprd21.prod.outlook.com (10.175.142.13) by MWHPR21MB0509.namprd21.prod.outlook.com (10.172.95.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 14 Sep 2017 05:57:51 +0000 Received: from MWHPR21MB0703.namprd21.prod.outlook.com ([10.175.142.13]) by MWHPR21MB0703.namprd21.prod.outlook.com ([10.175.142.13]) with mapi id 15.20.0077.005; Thu, 14 Sep 2017 05:57:51 +0000 From: Sourav Das To: Mikael Abrahamsson , "v6ops@ietf.org" CC: Praveen Balasubramanian Thread-Topic: [v6ops] Microsoft Win10 source address selection woes Thread-Index: AQHTKAuJ0enUxVpxVUay0kILU9Bn96Kz6vYA Date: Thu, 14 Sep 2017 05:57:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:9::52d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0509; 6:Z/a8y9QKC3ZVBAGBa/O42+30pZlm5roLoG83tOIa73kitnLJ5cWQI3kTjKwSUhN9JvpJOcj6rexKzrXRTkEf0J38m1ExmLcijZbsaUQJ8hHM8GpeiOzEwcVYGek6fYOoV9nlE/j8dC6ssO/d4ogeZhTU+LZjZ7kVhYHnITZtkjQLOc9XpiEhctN23JaruAEy246VEN7yLPf51ue1mk+nmBhOT2yNe+RUTskEtxa1kF8ieuUeNJVp3Tmw7dwp1GTOsOj9PSqM2WfTth/jX9qmPnCE2kLNf+E3bVdxwrRb7kAt/dDPaDDnk7/YubufyEahi+0nJKeEj+zKAZEhdC4V7w==; 5:srVe6jOLsyI3l4KWGlyT8x9DWq+q2O+CwX0xuTJ1FjsUq6MCemfL9vy1r3uFzZmKKKwl/q2+PQQ1ASaImn7wODdVedDhJZ4bITW6AUX9M3ZYW3ecTtsigdMtazowGn2vfXa08KWITjAgPohv8LrToA==; 24:spGKzXmuoga8DnRAFh/yX7xSOIjM8hSFLBkb87zLEHiul1ZcLp/yYJdHz+oXt62tUI5V0UeCzZ+Adl/b8qgfBlfnlyYxIMXTkf7lysggMok=; 7:NHjVYKDix1PZYk4rtOMO6i7kQeqoxEhDwDpXZ5Tk2PgFKhRGi7HPAjClGAS7LE60V9HoVRaiEfNE0rV0RPcPcEZPkGlF5t1CW3YEwNNn3VjoFQRF08sV3tN0d1Ob/hCe4DGjQgxufXay3j/l79Epiway8XjbKQB3Lpw7nGhVvkml/pp11jYnDS52j/BzQhGf4EZbuEXkyKUstGWtHxGGY1s6z/cNICr/aXeYxROML8U= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 446962b8-3d9f-4452-acb8-08d4fb358906 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0509; x-ms-traffictypediagnostic: MWHPR21MB0509: authentication-results: spf=none (sender IP is ) smtp.mailfrom=sourad@microsoft.com; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0509; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0509; x-forefront-prvs: 0430FA5CB7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(47530400004)(47760400005)(252514010)(377454003)(199003)(13464003)(24454002)(189002)(7736002)(305945005)(8990500004)(9686003)(102836003)(5660300001)(86612001)(7696004)(106356001)(3660700001)(33656002)(478600001)(4326008)(3280700002)(74316002)(10290500003)(6116002)(76176999)(50986999)(54356999)(8936002)(77096006)(105586002)(189998001)(55016002)(99286003)(101416001)(81156014)(229853002)(2501003)(107886003)(8676002)(2950100002)(25786009)(81166006)(53936002)(6246003)(2900100001)(6436002)(53546010)(316002)(10090500001)(6506006)(86362001)(22452003)(97736004)(2906002)(14454004)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0509; H:MWHPR21MB0703.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2017 05:57:51.6212 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0509 Archived-At: Subject: Re: [v6ops] Microsoft Win10 source address selection woes X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 05:57:56 -0000 Windows does implements RFC 6724 and prefers temporary addresses over publi= c address (per rule 7) . This happens for the 1st temporary address generat= ed by the stack when the interface gets enabled (as mentioned below). Howev= er due to a bug in our code for subsequently re-generated temporary address= es (when the 1st gets deprecated), the public address is unintentionally pr= eferred over them. We are working on a fix to address this. Thanks for brin= ging this to our notice. -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Thursday, September 7, 2017 10:35 AM To: v6ops@ietf.org Subject: Re: [v6ops] Microsoft Win10 source address selection woes On Thu, 7 Sep 2017, Mikael Abrahamsson wrote: > Does this mean Windows 10 doesn't implement RFC6724 but instead=20 > implements 3484? I have now done more tests. It seems this problem only occurs when windows = has two temporary addresses, one of which is deprecated and has 0 preferred= time. So as long as it has single temp address, the temp address is used for outg= oing browser connections. When it has two temp addresses, it starts using the public address. People at Microsoft has been notified about my findings. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 14 00:18:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472B4132EDA for ; Thu, 14 Sep 2017 00:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPOrhNS-jIYF for ; Thu, 14 Sep 2017 00:18:25 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F41C1321D8 for ; Thu, 14 Sep 2017 00:18:24 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8E7INYS039047 for ; Thu, 14 Sep 2017 09:18:23 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 41B5B20325D for ; Thu, 14 Sep 2017 09:18:23 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 36EBE200C37 for ; Thu, 14 Sep 2017 09:18:23 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8E7IMkx017958 for ; Thu, 14 Sep 2017 09:18:23 +0200 References: <150537334963.22241.11626392582096925889.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org" From: Alexandre Petrescu X-Forwarded-Message-Id: <150537334963.22241.11626392582096925889.idtracker@ietfa.amsl.com> Message-ID: <1e43337f-783e-3dcc-6b27-be4628414d07@gmail.com> Date: Thu, 14 Sep 2017 09:18:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150537334963.22241.11626392582096925889.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------C3ED1D862DA72B541EF8BA24" Content-Language: fr Archived-At: Subject: [v6ops] Fwd: I-D was expired X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 07:18:27 -0000 This is a multi-part message in MIME format. --------------C3ED1D862DA72B541EF8BA24 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit It's expired, but I work with a partner in finding a solution to reduce consumption of IPv6 vs IPv4 for some particular application on cellular smartphone, and we do have some idea, but would like to advance a bit on implementation. -------- Message transféré -------- Sujet : I-D was expired Date de renvoi : Thu, 14 Sep 2017 00:15:49 -0700 De (renvoi) : alias-bounces@ietf.org Pour (renvoi) : alexandre.petrescu@cea.fr, siwar.benhadjsaid@cea.fr, ophilippot@greenspector.com, tvincent@greenspector.com Date : Thu, 14 Sep 2017 00:15:49 -0700 De : I-D Expiring System Pour : draft-petrescu-v6ops-ipv6-power-ipv4@ietf.org was just expired. This draft is in the state "I-D Exists" in the Datatracker. Thanks, IETF Secretariat. --------------C3ED1D862DA72B541EF8BA24 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

It's expired, but I work with a partner in finding a solution to reduce consumption of IPv6 vs IPv4 for some particular application on cellular smartphone, and we do have some idea, but would like to advance a bit on implementation.



-------- Message transféré --------
Sujet : I-D was expired <draft-petrescu-v6ops-ipv6-power-ipv4-00.txt>
Date de renvoi : Thu, 14 Sep 2017 00:15:49 -0700
De (renvoi) : alias-bounces@ietf.org
Pour (renvoi) : alexandre.petrescu@cea.fr, siwar.benhadjsaid@cea.fr, ophilippot@greenspector.com, tvincent@greenspector.com
Date : Thu, 14 Sep 2017 00:15:49 -0700
De : I-D Expiring System <ietf-secretariat-reply@ietf.org>
Pour : draft-petrescu-v6ops-ipv6-power-ipv4@ietf.org 


<draft-petrescu-v6ops-ipv6-power-ipv4-00.txt> was just expired.
This draft is in the state "I-D Exists" in the Datatracker.


Thanks,
IETF Secretariat.
--------------C3ED1D862DA72B541EF8BA24-- From nobody Thu Sep 14 02:43:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52D21331E4 for ; Thu, 14 Sep 2017 02:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3le60neWLt3 for ; Thu, 14 Sep 2017 02:43:37 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB7F1331D2 for ; Thu, 14 Sep 2017 02:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1505382214; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references; bh=+c7Qw45Ry19mYMQ92/sFHoUNMWe7Byp7MheoEgeBVow=; b=GJTou3VDiBNo6xHuEmeWb6zcxtUnqzC+PF72N8p4Z6hwdvYZljSjFmR6QFbk6MVRS0LsuAK4mbSry8V/yUbkuTchAgLhk0mSCXr1XonX10g/x/fxruTD+3N+JZT34fifUPzH5z1bKfuRzGXA2TM6zCeED7m+9whmSQPcsIOBtCE= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0081.outbound.protection.outlook.com [94.245.120.81]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-17-a7ndhYAIMo6B4mWJy3-BYA-1; Thu, 14 Sep 2017 10:43:31 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0741.eurprd07.prod.outlook.com (10.242.253.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 14 Sep 2017 09:43:29 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590%14]) with mapi id 15.20.0077.005; Thu, 14 Sep 2017 09:43:29 +0000 From: Tim Chown To: Lorenzo Colitti CC: "Templin, Fred L" , "v6ops@ietf.org" , "internet-drafts@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt Thread-Index: AQHTLJk5GrNrckyw8E6Ie5aQVJcS3qKzUMMAgAAOUwCAAMONAA== Date: Thu, 14 Sep 2017 09:43:29 +0000 Message-ID: References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [109.246.123.207] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0741; 20:1w27rFawACqLD5Pw+2nfbVa2GD/Vy9ATXRNV0iEyhHyJZChcpfeT9MrrD/H9WMHZ2nZzY9YXWn62ZLl/YVRazqpSS36dNsjdOjcH+FMORE8pvXz6DzuImmETZfhNLFHBUQ6uH7o7Ym0JVSfxaGsZMfrtDIObY7dUDPjMQSaR8no= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 50ad1a9d-017c-4e7e-8407-08d4fb550e4f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0741; x-ms-traffictypediagnostic: AM3PR07MB0741: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(39337521807258)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(920507026)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0741; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0741; x-forefront-prvs: 0430FA5CB7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(199003)(189002)(377454003)(13464003)(24454002)(377424004)(54896002)(54906002)(6306002)(8676002)(34040400001)(5250100002)(316002)(606006)(230783001)(7736002)(50226002)(66066001)(3280700002)(68736007)(6506006)(478600001)(81156014)(81166006)(8666007)(99286003)(786003)(3846002)(6512007)(83716003)(236005)(36756003)(6116002)(53936002)(8936002)(53546010)(102836003)(82746002)(50986999)(86362001)(6486002)(97736004)(6246003)(106356001)(2900100001)(76176999)(229853002)(110136004)(6436002)(105586002)(2906002)(189998001)(33656002)(101416001)(3660700001)(42882006)(6916009)(2950100002)(4326008)(72206003)(14454004)(57306001)(5660300001)(25786009)(74482002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0741; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2017 09:43:29.6341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0741 X-MC-Unique: a7ndhYAIMo6B4mWJy3-BYA-1 Content-Type: multipart/alternative; boundary="_000_B2A14BB0283A47E8802785F9FAF903E4jiscacuk_" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 09:43:40 -0000 --_000_B2A14BB0283A47E8802785F9FAF903E4jiscacuk_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable On 13 Sep 2017, at 23:03, Lorenzo Colitti > wrote: I would instead say the opposite, i.e., call attention to what is in fact o= ne of the the main benefits of this document. Suggested text: The practices described in this document make it very simple for networks t= o implement robust isolation between clients at layer 2. The network can si= mply ensure that devices cannot send packets to each other except through t= he first-hop router. This will automatically provide robust protection agai= nst attacks between devices that rely on link-local ICMPv6 packets, such as= DAD reply spoofing, ND cache exhaustion, malicious redirects, and rogue RA= s. This form of protection is much more scalable and robust than alternativ= e mechanisms such as DAD proxying, forced forwarding, or ND snooping. +1 to this. It improves the document and further clarifies its applicabilit= y and benefits. Tim On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L > wrote: Please add the following to Security Considerations: "While the practices described herein encourage L3 operations that would forward all traffic through a provider managed First Hop Router, peer t= o peer communications are still possible unless L2 mechanisms are also employe= d in some fashion outside the scope of this document." Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, September 13, 2017 7:04 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host= -08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.t= xt > Pages : 9 > Date : 2017-09-13 > > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-= 08 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix= -per-host-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-p= er-host-08 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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 _______________________________________________ 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 --_000_B2A14BB0283A47E8802785F9FAF903E4jiscacuk_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: <8DD66EAF4D375440A87BEFCFB02B019B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
On 13 Sep 2017, at 23:03, Lorenzo Colitti <lorenzo@google.com> wrote:

I would instead say the opposite, i.e., call at= tention to what is in fact one of the the main benefits of this document. S= uggested text:

The practices described in this document make it very simpl= e for networks to implement robust isolation between clients at layer 2. Th= e network can simply ensure that devices cannot send packets to each other = except through the first-hop router. This will automatically provide robust protection against attacks between = devices that rely on link-local ICMPv6 packets, such as DAD reply spoofing,= ND cache exhaustion, malicious redirects, and rogue RAs. This form of prot= ection is much more scalable and robust than alternative mechanisms such as DAD proxying, forced forwarding= , or ND snooping.

+1 to this. It improves the document and further clarifies its applicab= ility and benefits.

Tim


On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L= <Fred.L.Templin@boeing.com> wrote:
Please add the following to Security Considerations:

  "While the practices described herein encourage L3 operations t= hat would
    forward all traffic through a provider managed First Hop Rout= er, peer to peer
    communications are still possible unless L2 mechanisms are al= so employed
    in some fashion outside the scope of this document."

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org
> Sent: Wednesday, September 13, 2017 7:04 AM
> To: i-d-announce@i= etf.org
> Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the IPv6 Operations WG of the IETF.
>
>         Title        &nbs= p;  : Unique IPv6 Prefix Per Host
>         Authors        &n= bsp;: John Jason Brzozowski
>                    &= nbsp;      Gunter Van De Velde
>       Filename        : draft-= ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>       Pages          &nbs= p;: 9
>       Date           = ; : 2017-09-13
>
> Abstract:
>    This document outlines an approach utilising existing IPv= 6 protocols
>    to allow hosts to be assigned a unique IPv6 prefix (inste= ad of a
>    unique IPv6 address from a shared IPv6 prefix).  Ben= efits of unique
>    IPv6 prefix over a unique service provider IPv6 address i= nclude
>    improved host isolation and enhanced subscriber managemen= t on shared
>    network segments.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique= -ipv6-prefix-per-host-08
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> 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


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

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

--_000_B2A14BB0283A47E8802785F9FAF903E4jiscacuk_-- From nobody Thu Sep 14 10:47:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796AE126BF0; Thu, 14 Sep 2017 10:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX1ki17KYdie; Thu, 14 Sep 2017 10:47:04 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5066913304F; Thu, 14 Sep 2017 10:47:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8EHl2Fv053477; Thu, 14 Sep 2017 10:47:03 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8EHl0sn053310 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 14 Sep 2017 10:47:01 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Sep 2017 10:47:00 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 14 Sep 2017 10:47:00 -0700 From: "Templin, Fred L" To: Tim Chown , Lorenzo Colitti CC: "v6ops@ietf.org" , "internet-drafts@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt Thread-Index: AQHTLJkv/GFPUda+3EaDW5zERE6omaKzUMMAgAAOUwCAAMONAIAAhRYA Date: Thu, 14 Sep 2017 17:47:00 +0000 Message-ID: References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_be57d2fa8b02489b92c23fe75796cb48XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 17:47:06 -0000 --_000_be57d2fa8b02489b92c23fe75796cb48XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below: From: Tim Chown [mailto:Tim.Chown@jisc.ac.uk] Sent: Thursday, September 14, 2017 2:43 AM To: Lorenzo Colitti Cc: Templin, Fred L ; v6ops@ietf.org; internet-d= rafts@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-ho= st-08.txt On 13 Sep 2017, at 23:03, Lorenzo Colitti > wrote: I would instead say the opposite, i.e., call attention to what is in fact o= ne of the the main benefits of this document. Suggested text: The practices described in this document make it very simple for networks t= o implement robust isolation between clients at layer 2. ? The practices described in this document do not make it any simpler for = networks to implement ? robust isolation between clients at layer 2. If networks are going to im= plement layer 2 isolation, ? it does not matter whether /not the practices described in this document= are used. The network can simply ensure that devices cannot send packets to each othe= r except through the first-hop router. This will automatically provide robu= st protection against attacks between devices that rely on link-local ICMPv= 6 packets, such as DAD reply spoofing, ND cache exhaustion, malicious redir= ects, and rogue RAs. This form of protection is much more scalable and robu= st than alternative mechanisms such as DAD proxying, forced forwarding, or = ND snooping. ? These are all artifacts of the layer 2 isolation; not of the L3 practi= ces described in this document. +1 to this. It improves the document and further clarifies its applicabilit= y and benefits. Tim On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L > wrote: Please add the following to Security Considerations: "While the practices described herein encourage L3 operations that would forward all traffic through a provider managed First Hop Router, peer t= o peer communications are still possible unless L2 mechanisms are also employe= d in some fashion outside the scope of this document." Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, September 13, 2017 7:04 AM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host= -08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.t= xt > Pages : 9 > Date : 2017-09-13 > > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-= 08 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix= -per-host-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-p= er-host-08 > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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 _______________________________________________ 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 --_000_be57d2fa8b02489b92c23fe75796cb48XCH150608nwnosboeingcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below:

 

From: Tim Chown [mailto:Tim.Chown@ji= sc.ac.uk]
Sent: Thursday, September 14, 2017 2:43 AM
To: Lorenzo Colitti <lorenzo@google.com>
Cc: Templin, Fred L <Fred.L.Templin@boeing.com>; v6ops@ietf.or= g; internet-drafts@ietf.org
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix= -per-host-08.txt

 

On 13 Sep 2017, at 23:03, Lorenzo Colitti <lorenzo@google.com> wrote:

 

I would instead say the opposite, i.e., call attenti= on to what is in fact one of the the main benefits of this document. Sugges= ted text:

 

The practices described in this document make it ver= y simple for networks to implement robust isolation between clients at laye= r 2.

 

Ø  The practices described in th= is document do not make it any simpler for networks to implement=

Ø  robust isolation between clie= nts at layer 2. If networks are going to implement layer 2 isolation,<= /o:p>

Ø  it does not matter whether /n= ot the practices described in this document are used.

<= o:p> 

The network can simply ensure that devices cannot se= nd packets to each other except through the first-hop router. This will aut= omatically provide robust protection against attacks between devices that r= ely on link-local ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, malicious redirects, and = rogue RAs. This form of protection is much more scalable and robust than al= ternative mechanisms such as DAD proxying, forced forwarding, or ND snoopin= g.

 

Ø    These are all artifacts of th= e layer 2 isolation; not of the L3 practices described in this document.

 

+1 to this. It improves the document and further= clarifies its applicability and benefits.

 

Tim



 

On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L <= ;Fred.L.Temp= lin@boeing.com> wrote:

Please add the following to Security Considerations:=

  "While the practices described herein encourage L3 operations t= hat would
    forward all traffic through a provider managed First Hop Rout= er, peer to peer
    communications are still possible unless L2 mechanisms are al= so employed
    in some fashion outside the scope of this document."

Thanks - Fred


> -----Original Message-----
> From: v6ops [mailto:v6ops-bo= unces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, September 13, 2017 7:04 AM
> To: i-d-announce@ietf.org=
> Cc: v6ops@ietf.org
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-h= ost-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the IPv6 Operations WG of the IETF.
>
>         Title        &nbs= p;  : Unique IPv6 Prefix Per Host
>         Authors        &n= bsp;: John Jason Brzozowski
>                    &= nbsp;      Gunter Van De Velde
>       Filename        : draft-= ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>       Pages          &nbs= p;: 9
>       Date           = ; : 2017-09-13
>
> Abstract:
>    This document outlines an approach utilising existing IPv= 6 protocols
>    to allow hosts to be assigned a unique IPv6 prefix (inste= ad of a
>    unique IPv6 address from a shared IPv6 prefix).  Ben= efits of unique
>    IPv6 prefix over a unique service provider IPv6 address i= nclude
>    improved host isolation and enhanced subscriber managemen= t on shared
>    network segments.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-ho= st/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08=
> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-p= er-host-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-per= -host-08
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> 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


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

 

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

 

--_000_be57d2fa8b02489b92c23fe75796cb48XCH150608nwnosboeingcom_-- From nobody Thu Sep 14 11:16:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CFA13304F for ; Thu, 14 Sep 2017 11:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Jk0XcF5et56x for ; Thu, 14 Sep 2017 11:16:37 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99EC1323F7 for ; Thu, 14 Sep 2017 11:16:36 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 73561A42 for ; Thu, 14 Sep 2017 18:16: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 wfQegIR8NeDO for ; Thu, 14 Sep 2017 13:16:36 -0500 (CDT) Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id DE71DAB4 for ; Thu, 14 Sep 2017 13:16:35 -0500 (CDT) Received: by mail-lf0-f71.google.com with SMTP id 80so92358lfy.5 for ; Thu, 14 Sep 2017 11:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r4od6gh99nLr1RvlhKgJe+n4DoJPwR2TKkCiwtJpR5k=; b=mpD+UqVp+38H8IlDqpJC5kR2p5hr0ZSsJGIW+XFNtCq3DscdKZhQCinMvzgZPfDBnh u018VVaAI/bKvm2INJHRVMveIwBkuYdKfwh2oQvo0WPNnQcJiv+H8e+i/Gn+LL7iShiO LngvI1d7lmC7+Tys7zx4ZkK2K+zqPlSzAni8Nf50w0htmWLaE4Cpavso06KyhXHmEX9E wBWPz9xOOui/aDXd7I4uTk+FWZfH9qHMOoHK90R6lOBJu7v6/NeNpuG8X/Yemln/PYvA S5qP/4uFId9b5o2KXW9Ede4qrM+Co+f/2qhMoPTmV5QHJOXu+A9YXW6CHQQZtr070ePb M9qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r4od6gh99nLr1RvlhKgJe+n4DoJPwR2TKkCiwtJpR5k=; b=IBZBvw6jb8NOknjnsmr+oFcVSrf5Y+YQosOz/8ePPwPmoLP2LHv9GLRS57qOkoUTkR wt5NY7nUhw3FPVEzKVvdDWZ4E14JPPeK2YNPplpIgoYw0ZYJW9DG/RUddWIydhxH809a 6PdhR57B/zu8eUUdcv8LbuMQvMTEGa5FruphBKk/D6Zq5LFN8ktaoLSqIx6awxuzft2C 0oRPP0i5gPhmdJk8+Bi18ok8thxKqMJVgJiUkCv/iNxVt63pVHopTUZ7YTlPkW/m5G1S ML2bHPY7JaaO4WIrxhwp+RBYRrRpb+tAkchgLyyR+agcb1c4SVoW6y3olQAgUctb6hPD QHTA== X-Gm-Message-State: AHPjjUhqz2V0QBj0OC4px3b1B95MBvqXso77nDh86tMYuhVKky4Ac6p1 msqHVXl9b+N9gHRWo3zXgyEWq7weCiEl6U9ph+jKpFxRcMMYxmBwFlqG6N4JnMmAUzJ2BJVHRyR dxDIe2dhg3pim0Q+FFOczfGeAkg== X-Received: by 10.25.23.80 with SMTP id n77mr8325847lfi.121.1505412993996; Thu, 14 Sep 2017 11:16:33 -0700 (PDT) X-Google-Smtp-Source: AOwi7QASfFRGsXAsMeNQ0Chn3kgqZzkAkmvJfsm8/dt+3Y6CXL2kWIUi7BxSQi2D5RJxIXM1ALO58UCB9nlSMwWlIHg= X-Received: by 10.25.23.80 with SMTP id n77mr8325842lfi.121.1505412993643; Thu, 14 Sep 2017 11:16:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Thu, 14 Sep 2017 11:16:33 -0700 (PDT) In-Reply-To: References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <466db83261804d179fc991f43df5dcf9@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Thu, 14 Sep 2017 13:16:33 -0500 Message-ID: To: "Templin, Fred L" Cc: Tim Chown , Lorenzo Colitti , "v6ops@ietf.org" , "internet-drafts@ietf.org" Content-Type: multipart/alternative; boundary="001a1140650aba1bb205592a4646" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 18:16:40 -0000 --001a1140650aba1bb205592a4646 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 14, 2017 at 12:47 PM, Templin, Fred L wrote: > Below: > > > > *From:* Tim Chown [mailto:Tim.Chown@jisc.ac.uk] > > On 13 Sep 2017, at 23:03, Lorenzo Colitti wrote: > > > > I would instead say the opposite, i.e., call attention to what is in fact > one of the the main benefits of this document. Suggested text: > > > > The practices described in this document make it very simple for networks > to implement robust isolation between clients at layer 2. > > > > =C3=98 The practices described in this document do not make it any simpl= er > for networks to implement > > =C3=98 robust isolation between clients at layer 2. If networks are goin= g to > implement layer 2 isolation, > > =C3=98 it does not matter whether /not the practices described in this > document are used. > > I disagree, layer 2 isolation breaks a classic IPv6 subnet, without something like DAD or ND proxy, or ND snooping. This model of doing Layer 3, allows layer 2 isolation without any of that, which is cleaner and more scalable like Lerenzo's text says. The network can simply ensure that devices cannot send packets to each > other except through the first-hop router. This will automatically provid= e > robust protection against attacks between devices that rely on link-local > ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, maliciou= s > redirects, and rogue RAs. This form of protection is much more scalable a= nd > robust than alternative mechanisms such as DAD proxying, forced forwardin= g, > or ND snooping. > > > > =C3=98 These are all artifacts of the layer 2 isolation; not of the L3 > practices described in this document. > > Yes, they are artifacts of the layer2 isolation, which is enable by this model of doing Layer 3, with ND proxy... > +1 to this. It improves the document and further clarifies its > applicability and benefits. > > > > Tim > Yep, +1 to Lerenzo's text Thanks --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a1140650aba1bb205592a4646 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Sep 14, 2017 at 12:47 PM, Templin, Fred L <= ;Fred.L.Temp= lin@boeing.com> wrote:

Below:

=C2=A0

From: Tim Chown [mailto:Tim.Chown@jisc.ac.uk]

On 13 Sep 2017, at 23:03, Lorenzo Colitti <lorenzo@google.com>= ; wrote:

=C2=A0

I would instead say the opposite, i.e., call attenti= on to what is in fact one of the the main benefits of this document. Sugges= ted text:

=C2=A0

The practices described in this document make it ver= y simple for networks to implement robust isolation between clients at laye= r 2.

=C2=A0

=C3=98=C2=A0 The practices described in this documen= t do not make it any simpler for networks to implement=

=C3=98=C2=A0 robust isolation between clients at lay= er 2. If networks are going to implement layer 2 isolation,

=C3=98=C2=A0 it does not matter whether /not the pra= ctices described in this document are used.

I disagree, layer 2 iso= lation breaks a classic IPv6 subnet, without something like DAD or ND proxy= , or ND snooping.=C2=A0 This model of doing Layer 3, allows layer 2 isolati= on without any of that, which is cleaner and more scalable like Lerenzo'= ;s text says.=C2=A0=C2=A0

The network can simply ensure that devices cannot se= nd packets to each other except through the first-hop router. This will aut= omatically provide robust protection against attacks between devices that r= ely on link-local ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, malicious redirects, and = rogue RAs. This form of protection is much more scalable and robust than al= ternative mechanisms such as DAD proxying, forced forwarding, or ND snoopin= g.

=C2=A0

=C3=98=C2=A0= =C2=A0=C2=A0 These are all artifacts of the layer 2 = isolation; not of the L3 practices described in this document.


Yes, they are= artifacts of the layer2 isolation, which is enable by this model of doing = Layer 3, with ND proxy...=C2=A0
=C2=A0
=

+1 to this. It improves the document and further cla= rifies its applicability and benefits.

=C2=A0

Tim

=C2=A0Yep, +1 to Lerenzo's text

Th= anks

--
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farme= r=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networ= king & Telecommunication Services
Office of Information TechnologyUniversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0= =C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
--001a1140650aba1bb205592a4646-- From nobody Thu Sep 14 11:32:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C02B13292D for ; Thu, 14 Sep 2017 11:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 DBPfh9q2M6bF for ; Thu, 14 Sep 2017 11:32:40 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACB41320D9 for ; Thu, 14 Sep 2017 11:32:39 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 3BCD8797 for ; Thu, 14 Sep 2017 18:32:39 +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 4OJNvUab9yNp for ; Thu, 14 Sep 2017 13:32:39 -0500 (CDT) Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id C1B179A0 for ; Thu, 14 Sep 2017 13:32:38 -0500 (CDT) Received: by mail-lf0-f69.google.com with SMTP id h80so111579lfe.7 for ; Thu, 14 Sep 2017 11:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D3PoNY1ikNgeDxxbgo+k9pmIDoKIaKI4fzDzzmLUe8o=; b=nSoeq3XNF6SrQInEJXS10h/K1ruiLxu1DjAPegJaZnyIIqe6R/Fx48di5w6dhonWhx f6vJLeI55dDf6ftPxHxVSx5fYeIGxlxKpG5WNAWfRx0g2erkU9aZ7VoJaQ8uAEIi0USL V/0UPtJM+5CPjhYHID6m5eGx5cDl/Vdb2buPvrW048YG0U1+Cdp0CPcJ1qhUQqY1+2na jexJv5Z4etiUKwHUf33Z1uomxqb5XTdKYWgOZNh3e87khgNyEXuK43jgntdyVkWBDNYz DKwijWFt/iKRPPr9jeBHvYYm1p7kTyuF5Bl60k35oGMo62RaEN/GFnXs7RGNu7IfMpJy pKZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D3PoNY1ikNgeDxxbgo+k9pmIDoKIaKI4fzDzzmLUe8o=; b=cdHRa84dK84FSfqp1YP1S5BVyPtpWywC0d4nLwIS+4QWi3qvXx7S3qT0oBEMXxia/W 0MiAQfgudPHsgdOH658sJyHcAbBp7sNOzLOIpTY5qJpLXJDN4Ob3FRYqWtBgdTGykaYj hFeCIrfxcwdBKR7ArgJmWnFU9hZOWAN8TzuCs2kTFFm++664WYD197HgYsSNLni1Izc3 Iu8fLKlzwPqPU4FrPXFY3S/G21lo2B6n1avr6NU8VJ5g3ndEFTOYOwAYeUVOVuQqJAPJ OYUjUbGG1djYPfHqz00iGIVQsxl24a4IrkG4FpRr0PuS3uli1fexFw0iGm9bcL4Jcwg0 4KxA== X-Gm-Message-State: AHPjjUhiwYWewiZgDPPqoi0tFGPgWsXqs/B28j4WKQSPELRP3YLs/UvC XGt4dLRmdoYxpoSD6Db9Q+aFIIFm8KqmvHPEJPLj3nZKDRde8aDBzAkuLnEhr/gyKYKsf7vLQKI FXzvUxzXacb3zF9W7Z3tkLtNJCA== X-Received: by 10.25.233.8 with SMTP id g8mr9159877lfh.197.1505413957445; Thu, 14 Sep 2017 11:32:37 -0700 (PDT) X-Google-Smtp-Source: AOwi7QCPCnY2ztRaoM1YgGwVC9uSNo6xM4fj8I3yJKnboKT+j8L9Zdmu2jvexL+KWSe9Z6uINSLbQqnkV5+qa+RvQk0= X-Received: by 10.25.233.8 with SMTP id g8mr9159872lfh.197.1505413957287; Thu, 14 Sep 2017 11:32:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Thu, 14 Sep 2017 11:32:36 -0700 (PDT) In-Reply-To: <11835e89-4aff-9ebe-01f0-155498586913@gmail.com> References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <11835e89-4aff-9ebe-01f0-155498586913@gmail.com> From: David Farmer Date: Thu, 14 Sep 2017 13:32:36 -0500 Message-ID: To: Brian E Carpenter Cc: V6 Ops List Content-Type: multipart/alternative; boundary="001a113cba462a164005592a80d0" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 18:32:42 -0000 --001a113cba462a164005592a80d0 Content-Type: text/plain; charset="UTF-8" On Wed, Sep 13, 2017 at 3:29 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > A shared network service, is a service offering where a particular L2 > > access network (i.e. wifi) is shared and used by multiple visiting > > devices (i.e. subscribers). > > I'm pretty sure that you mean "e.g.", not "i.e.", in both of those > parentheses. > Actually I think "i.e." is fine in the second case, "(in other words subscribers)" seems appropriate to the sentence, which is more or less what "i.e." means. But, yes in the first case "e.g." or "(for example wifi)" would seem more appropriate to the sentence. > This version still does not clarify whether a "unicast" RA means one sent > to > a unicast Layer 3 address at a unicast Layer 2 address, or to ff02::1 at > a unicast Layer 2 address, or either. An implementer has to guess. > +1, while adding the reference to RFC6085, helps a little, I think this is worth a few more words to make it explicitly clear. Also, mentioning how periodic RA are intended to be handled in addition to RAs in response to an RS. I provided some text previously, use it if you like. Regards > Brian > 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 =============================================== --001a113cba462a164005592a80d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Sep 13, 2017 at 3:29 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
>=C2=A0 =C2=A0 A shared network service, is a servic= e offering where a particular L2
>=C2=A0 =C2=A0 access network (i.e. wifi) is shared and used by multiple= visiting
>=C2=A0 =C2=A0 devices (i.e. subscribers).

I'm pretty sure that you mean "e.g.", not "i.e.", i= n both of those parentheses.

Actually I= think "i.e." is fine in the second case, "(in other words s= ubscribers)" seems appropriate to the sentence, which is more or less = what =C2=A0"i.e." means.

But, yes in the= first case "e.g." or "(for example wifi)" would seem m= ore appropriate to the sentence.
=C2=A0
This version still does not clarify whether a "unicast" RA means = one sent to
a unicast Layer 3 address at a unicast Layer 2 address, or to ff02::1 at a unicast Layer 2 address, or either. An implementer has to guess.

+1, while adding the reference to RFC6085, help= s a little, I think this is worth a few more words to make it explicitly cl= ear.=C2=A0 Also, mentioning how periodic RA are intended to be handled in a= ddition to RAs in response to an RS.=C2=A0 I provided some text previously,= use it if you like. =C2=A0 =C2=A0

Regards
=C2=A0 =C2=A0Brian

Thanks

--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Tele= communication Services
Office of Information Technology
University of= Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612= -812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
--001a113cba462a164005592a80d0-- From nobody Thu Sep 14 12:09:54 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6356A1320D9; Thu, 14 Sep 2017 12:09:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150541619338.18973.1376799734453993603@ietfa.amsl.com> Date: Thu, 14 Sep 2017 12:09:53 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 19:09:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Pages : 9 Date : 2017-09-14 Abstract: This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique service provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-09 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-09 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 Thu Sep 14 12:16:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8B41320D9 for ; Thu, 14 Sep 2017 12:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43MIjV9mcgTV for ; Thu, 14 Sep 2017 12:16:05 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10127.outbound.protection.outlook.com [40.107.1.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779A01321F5 for ; Thu, 14 Sep 2017 12:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RHAMgnKDh92LaYz2ydoGH48n3zOMiFQ0tWJXQY557SQ=; b=ANHztqcB1r+8IGmHGDIxRs3OomLrYL/+e3217OXcvxp5wpPz+4/Es/0yI94i40EeklCkzHSfRM7zYKPTyMFc8nb/f4ew+KI0lcmN6I3/kuoma86J6oabX7bz4ERwK8cDSLLBes8ZTl4qTzcqtUthqqXb+/2Hl9RvmIHdOf4EYvk= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM5SPR01MB251.eurprd07.prod.outlook.com (10.173.255.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.56.4; Thu, 14 Sep 2017 19:16:01 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be%13]) with mapi id 15.20.0056.010; Thu, 14 Sep 2017 19:16:01 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0StrMTKqyUsUSTtL8Hlw+rn6K04jqA Date: Thu, 14 Sep 2017 19:16:01 +0000 Message-ID: <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> In-Reply-To: <150541619338.18973.1376799734453993603@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.242.26.240] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5SPR01MB251; 6:X6XWiu3XtjfP3gv9/2h+WYKjwO+Ul902oI9pzWGlVWDBLr5Px1cqLX+JcbHiakZ71+YG38ODGaP306dI61nqf8LcsIr3wwONMTbW84NREmyHE3NTc9OUKAhSYLWmQIemoamb0cphLVTglAfyE2pLWiPm7i4IWA8x6VNhWep8rO6kRKp+ncAqnVGHn8ukxxRKfsJgMT+drDF2lxKp55Jh54ENqBvVraZL60AJYEoFuQlMHN4jY/zQseZzhbNcxEnxEKxD9NKhD4cmpzY93OImgJ6nObp27kyM9ars4mKBhikteF38cANnEw+uWB6NBAUjvtKn0Rxu4QYhrbEz4aNPdA==; 5:KBv68972fqfzRRTmIh4CS9y17FEuKbnrmbelKJ614n4daT2c13ZSvLCMgMJTRfbCtIIkl0B0eiMx32mwFsvbaVrWkfQ7BIX6LP0Fv1fM2p8+1zyULbMQkUbquEv4jHPMz9P5kSIcy7XWHvxHnd6ayQ==; 24:UNJpvSulthhXmC3ZI1m9mqotNIJ31VTdGzZ3jkOFNGEQb9w7LoWr39NaAiY2Zk5WhkltPl+KlmpQyP0JrykJ4KEhFkMmszKBmXkgd9XGV6s=; 7:Ot4hfpfI/pObI1zxFLaEjDL2zuQ3t6bcYTAJkAiLQLTfPftkq1vhf3yqefauRNYH7kSOBM/KdHr6Fpdl7Im34902qeJDrnNxmR3B+ZCVX98Ic1n8VzTwCcNS+cQY9b/x566LaeVWnClbAr/Paud0Bq8Wh1eykA3urujGn1MF40ENvL/OlxytiLvxsqVKWFgfgjtF39/KU9YnxMfJOGppIRfwutNKidiNxpiGtRJ3w04= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 95eef775-6a1b-4d66-3756-08d4fba509aa x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5SPR01MB251; x-ms-traffictypediagnostic: AM5SPR01MB251: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5SPR01MB251; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5SPR01MB251; x-forefront-prvs: 0430FA5CB7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39860400002)(346002)(376002)(189002)(377424004)(24454002)(199003)(5250100002)(76176999)(99286003)(33656002)(2351001)(83716003)(2501003)(81166006)(86362001)(81156014)(8936002)(230783001)(8676002)(25786009)(97736004)(305945005)(68736007)(7736002)(54906002)(478600001)(105586002)(966005)(106356001)(101416001)(2900100001)(5660300001)(110136004)(2906002)(36756003)(39060400002)(6486002)(4326008)(66066001)(3660700001)(316002)(6506006)(6436002)(6916009)(54356999)(3280700002)(5640700003)(82746002)(14454004)(189998001)(6512007)(6116002)(2950100002)(229853002)(3846002)(6306002)(53936002)(6246003)(50986999)(53546010)(102836003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5SPR01MB251; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2017 19:16:01.5783 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5SPR01MB251 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 19:16:07 -0000 VGhpcyAtMDkgdmVyc2lvbiBpbmNsdWRlcyBuZXcgdGV4dCB0byBhZGRyZXNzIHRoZSBpZG5pdHMg KGkuZS4gdmVyc3VzIGUuZy4pIG5vdGVkIGJ5IEJyaWFuIGFuZCB0aGUgY2xhcmlmaWNhdGlvbiB0 ZXh0IHBvaW50ZWQgb3V0IG9uIHRoZSBmaXJzdCBob3Agcm91dGVyIHNvbGljaXRlZC9VbmljYXN0 IFJBIHJlc3BvbnNlIHVzaW5nIHRoZSBzdWdnZXN0ZWQgdGV4dCBmcm9tIERhdmlkIEZhcm1lciBp biBzZWN0aW9uIDQgcGFyYSAzLg0KDQpBbHNvIHRoZSB0ZXh0IHN1Z2dlc3RlZCBieSBMb3Jlbnpv IGlzIGluY2x1ZGVkIGluIHRoZSB0ZXh0IHRvIG1ha2UgdGhlIGJlbmVmaXRzIG9mIFVFL3N1YnNj cmliZXIgbW9yZSBjbGVhciBpbiBzZWN0aW9uIDEgcGFyYSAzLg0KDQpHLw0KDQpPbiAxNC8wOS8y MDE3LCAyMTowOSwgInY2b3BzIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci IDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KICAgIFRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYgT3BlcmF0aW9ucyBXRyBvZiB0aGUg SUVURi4NCiAgICANCiAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFVuaXF1ZSBJUHY2IFBy ZWZpeCBQZXIgSG9zdA0KICAgICAgICAgICAgQXV0aG9ycyAgICAgICAgIDogSm9obiBKYXNvbiBC cnpvem93c2tpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHdW50ZXIgVmFuIERlIFZl bGRlDQogICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYt cHJlZml4LXBlci1ob3N0LTA5LnR4dA0KICAgIAlQYWdlcyAgICAgICAgICAgOiA5DQogICAgCURh dGUgICAgICAgICAgICA6IDIwMTctMDktMTQNCiAgICANCiAgICBBYnN0cmFjdDoNCiAgICAgICBU aGlzIGRvY3VtZW50IG91dGxpbmVzIGFuIGFwcHJvYWNoIHV0aWxpc2luZyBleGlzdGluZyBJUHY2 IHByb3RvY29scw0KICAgICAgIHRvIGFsbG93IGhvc3RzIHRvIGJlIGFzc2lnbmVkIGEgdW5pcXVl IElQdjYgcHJlZml4IChpbnN0ZWFkIG9mIGENCiAgICAgICB1bmlxdWUgSVB2NiBhZGRyZXNzIGZy b20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLiAgQmVuZWZpdHMgb2YgdW5pcXVlDQogICAgICAgSVB2 NiBwcmVmaXggb3ZlciBhIHVuaXF1ZSBzZXJ2aWNlIHByb3ZpZGVyIElQdjYgYWRkcmVzcyBpbmNs dWRlDQogICAgICAgaW1wcm92ZWQgaG9zdCBpc29sYXRpb24gYW5kIGVuaGFuY2VkIHN1YnNjcmli ZXIgbWFuYWdlbWVudCBvbiBzaGFyZWQNCiAgICAgICBuZXR3b3JrIHNlZ21lbnRzLg0KICAgIA0K ICAgIA0KICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0 IGlzOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZv cHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0Lw0KICAgIA0KICAgIFRoZXJlIGFyZSBhbHNv IGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDkN CiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZv cHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA5DQogICAgDQogICAgQSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1w ZXItaG9zdC0wOQ0KICAgIA0KICAgIA0KICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KICAgIA0KICAgIEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDoNCiAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQogICAgdjZvcHNAaWV0Zi5vcmcNCiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQogICAgDQoNCg== From nobody Thu Sep 14 13:02:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940D31320D9 for ; Thu, 14 Sep 2017 13:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTYrE31xEASG for ; Thu, 14 Sep 2017 13:02:11 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA6A126E64 for ; Thu, 14 Sep 2017 13:02:11 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id q76so237316pfq.2 for ; Thu, 14 Sep 2017 13:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yco14xVRzbFfJvOYO3xlBsfzJDFewAYLMOgnA5sqKaI=; b=SbRx8+n7t+yHqYiy1wj5MlBwn5NStxRtOvN3DL5A1maoDTD5nFPlSJJqMChdLr2qUv cEmabhlI15hv+RZRc6ceOD2jZhAbtRD4lqQZEVMyOtkTJjArRderxtrWVUbQ48WFQVEu oq07AbGAdfO59b8CHtHQD14q+W+i7l7BFCE/KYxPwfwEDxLeTYXqwm7kuTLuxA6YlL+t MOvjBmolx5fDl+Zi7yDtj5/b0WYzGwdFmw7jL5pif6NRib4Ng6au2vJ5HvjkWqtltdTU 1JeeGZChYvm+CYqNn8ZB3dPtW52pQmLuxCnNakmOODQibVVuv+UDJTIeJREsTaUGXStg lReA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=yco14xVRzbFfJvOYO3xlBsfzJDFewAYLMOgnA5sqKaI=; b=RP6/3rvi4LpkCIyLwPPXV4A7eLFhv412oG+NjXkHk11BuE0LCbHk7VFZN9Ec47uffp yzAV98E+FfxE8VEZaEzYG8Y4719q3EU/+9q3jmocqByLPojnPePXXrK8GKV7jMsrpB/c 8sNC3Ujp+1mNajJOeUF1tfCXf1zH8Na0fSpQSzOBCVMh9Jn7TUuirbWWfYyzm+kVWhb1 2Tm9klbHVk1TxdZdowDxsEmSHBw57UPwN0Ugv17JDrvStWE+uXkCNn0/l/cOnLAFitCj JYHoYbwCm7GkGqEUiYokSluhIkbQRNptWpx71mvwZdWrb4SgyqdFhPrHKLl47/k4ujab y5Ew== X-Gm-Message-State: AHPjjUjVP6srsKALm+NIaLPP9XmWDlTQLK8zbE35jtCzloSL188tYivN 9poSaFr1IC8foA== X-Google-Smtp-Source: ADKCNb77dGPjP55fOgtDFL4Ziu92PYazlopXRKAiqSZ/0WqKCoB1zgM6JxEprlx1iO5M5EngrARuyA== X-Received: by 10.84.229.13 with SMTP id b13mr26010893plk.189.1505419331267; Thu, 14 Sep 2017 13:02:11 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w5sm28443325pfw.99.2017.09.14.13.02.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Sep 2017 13:02:10 -0700 (PDT) To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 15 Sep 2017 08:02:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 20:02:13 -0000 Thanks, I'm happy with the changes now. Regards Brian On 15/09/2017 07:16, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > This -09 version includes new text to address the idnits (i.e. versus e.g.) noted by Brian and the clarification text pointed out on the first hop router solicited/Unicast RA response using the suggested text from David Farmer in section 4 para 3. > > Also the text suggested by Lorenzo is included in the text to make the benefits of UE/subscriber more clear in section 1 para 3. > > G/ > > On 14/09/2017, 21:09, "v6ops on behalf of internet-drafts@ietf.org" wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt > Pages : 9 > Date : 2017-09-14 > > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-09 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-09 > > > 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 > > From nobody Thu Sep 14 13:21:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8F51320DC for ; Thu, 14 Sep 2017 13:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Zhb1lhG3yxLI for ; Thu, 14 Sep 2017 13:21:54 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E96126E64 for ; Thu, 14 Sep 2017 13:21:54 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 99A2968F for ; Thu, 14 Sep 2017 20:21:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCsoI4lks8ex for ; Thu, 14 Sep 2017 15:21:53 -0500 (CDT) Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 14F19AFF for ; Thu, 14 Sep 2017 15:21:53 -0500 (CDT) Received: by mail-lf0-f69.google.com with SMTP id l196so302945lfl.2 for ; Thu, 14 Sep 2017 13:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pKB3t3jvIhnl3uHlmtyXqN4p1+E34dC5VzGKSgLaN+8=; b=abl1IV0irSLdJbhGryG6Hpd4nvKv+1PgwbppF9JB7NX2trE66HFTjZRZj03zP0qoaL IU+Rl+NUd5Knnirzcc38uu4Da0/jtl0gMtp7AZ0M9qXA51YpW/eucD4ioiT6yhDTQSrb frR1BIfqKEehj7p8CgNPaY1b2Twzhrw9JU/XHotU1pixWjMq600XqDde0DYqx3hUaM8l hUL355rv1O09CkWKyYs21Lr60sec9Z1jNPTCLWD8xoSwax8XfzsleQcMiWsrSvnqPnD+ Ix2Nh6aEhUMsBH9lCJgRi2qbgxAO3bnOslc7C1pUNflLk/p0KuFoA3O/D+36BGzeAYUe VNjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pKB3t3jvIhnl3uHlmtyXqN4p1+E34dC5VzGKSgLaN+8=; b=jVqFU5NdmasRMMfyvrL8KGd6s4RotLqieAs6MnIa0PkE2N/MMITk6Ry6uTduPhx/fZ c07Ehj+7eenxGDxdAJHps2LiANDjp67rGGy2/qxT34Ag3yF6f56rK0c/Bcnn5JgAlyLN cUOnF5SwOLXY74iyA9dP2CUdB83urZY89v85OlxWx90LOlr4KBE7ndr2SmdPoI76qRQo f5GhFzalngyPEmB3oAmeQmp4d2GLW4FyFKk27fo8boIq8j7XYqv9LUx4p9pX/pTIEWSz l6MDdnYBbl6CQga6n98H1yT2+SEciDPj76JLyQmkYV6fXzsH8G2EjCLqsPR1SF51wePZ 5Smw== X-Gm-Message-State: AHPjjUinnV++dZCMPbinq8I5YDsJU8VZJL37ke3mfWRqeh/cmtCjuirJ U0SPh1vwGJIMyvcEQxizC2HMira37kPabEswMkKGIoTUHFFENQsRHgNf4+oR2oSU8VDDAOMtt9n hJgjhFFPw6zyMzMcmkxBHHOwcAQ== X-Received: by 10.25.125.197 with SMTP id y188mr8997434lfc.61.1505420511311; Thu, 14 Sep 2017 13:21:51 -0700 (PDT) X-Google-Smtp-Source: AOwi7QC2P9i9LQxIXjJt4Vmmynib0z7BVhdttvzPFnqYsUbTxfZTSQOvNfOgahOsEtm8YOpNpWrZxVOAtI5lRHY4VEo= X-Received: by 10.25.125.197 with SMTP id y188mr8997428lfc.61.1505420511119; Thu, 14 Sep 2017 13:21:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Thu, 14 Sep 2017 13:21:50 -0700 (PDT) In-Reply-To: <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: David Farmer Date: Thu, 14 Sep 2017 15:21:50 -0500 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" , Brian E Carpenter , "Brzozowski, John" Content-Type: multipart/alternative; boundary="001a114b8232cd991f05592c067e" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 20:21:56 -0000 --001a114b8232cd991f05592c067e Content-Type: text/plain; charset="UTF-8" One of the changes made between version 7 and 8 was to remove "UE/" from "UE/subscriber" in several places, so maybe you want to remove them from the text just inserted. Regardless, there is a typo in the following; This solicited RA contains two important parameters for the EU/ subscriber to consume: ... I think you mean This solicited RA contains two important parameters for the UE/ subscriber to consume: ... Further, you could also change "This solicited RA" in the sentence to "The RA", so it will be understood to apply to both solicited or periodic RAs. The RA contains two important parameters for the subscriber to consume: ... Otherwise looks good to me. Thanks On Thu, Sep 14, 2017 at 2:16 PM, Van De Velde, Gunter (Nokia - BE/Antwerp) < gunter.van_de_velde@nokia.com> wrote: > This -09 version includes new text to address the idnits (i.e. versus > e.g.) noted by Brian and the clarification text pointed out on the first > hop router solicited/Unicast RA response using the suggested text from > David Farmer in section 4 para 3. > > Also the text suggested by Lorenzo is included in the text to make the > benefits of UE/subscriber more clear in section 1 para 3. > > G/ > > On 14/09/2017, 21:09, "v6ops on behalf of internet-drafts@ietf.org" < > v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6- > prefix-per-host-09.txt > Pages : 9 > Date : 2017-09-14 > > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique- > ipv6-prefix-per-host/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6- > prefix-per-host-09 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops- > unique-ipv6-prefix-per-host-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique- > ipv6-prefix-per-host-09 > > > 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 > > > -- =============================================== 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 =============================================== --001a114b8232cd991f05592c067e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of the changes made between version 7 and 8 was to rem= ove "UE/" from "UE/subscriber" in several places, so ma= ybe you want to remove them from the text just inserted.=C2=A0 Regardless, = there is a typo in the following;

=C2=A0 =C2=A0This= solicited RA contains two important parameters for the EU/
=C2= =A0 =C2=A0subscriber to consume: ...

I think= you mean=C2=A0

=C2=A0 =C2=A0This solicited R= A contains two important parameters for the UE/
=C2=A0 =C2=A0subs= criber to consume: ...

Further, you could also change "This solicited = RA" in the sentence to "The RA", so it will be understood to= apply to both solicited or periodic RAs.
<= br>
=C2=A0 =C2=A0The RA contains two i= mportant parameters for the subscriber=C2=A0
=C2=A0 =C2=A0to cons= ume: ...

Otherwise looks good to me.
Thanks
<= br>
On Thu, Sep 14, 2017 at 2:16 PM, Van De Velde= , Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:
T= his -09 version includes new text to address the idnits (i.e. versus e.g.) = noted by Brian and the clarification text pointed out on the first hop rout= er solicited/Unicast RA response using the suggested text from David Farmer= in section 4 para 3.

Also the text suggested by Lorenzo is included in the text to make the bene= fits of UE/subscriber more clear in section 1 para 3.

G/

On 14/09/2017, 21:09, "v6ops on behalf of internet-drafts@ietf.org" <v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts directories.
=C2=A0 =C2=A0 This draft is a work item of the IPv6 Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Unique IPv6 Prefix Per Host
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: John Jason Brzozowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gunter Van De Velde
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-unique-ipv6-prefix-per-host-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-14

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document outlines an approach utilising exi= sting IPv6 protocols
=C2=A0 =C2=A0 =C2=A0 =C2=A0to allow hosts to be assigned a unique IPv6 pref= ix (instead of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0unique IPv6 address from a shared IPv6 prefix).= =C2=A0 Benefits of unique
=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 prefix over a unique service provider IPv6 = address include
=C2=A0 =C2=A0 =C2=A0 =C2=A0improved host isolation and enhanced subscriber = management on shared
=C2=A0 =C2=A0 =C2=A0 =C2=A0network segments.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://= datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/

=C2=A0 =C2=A0 There are also htmlized versions available at:
=C2=A0 =C2=A0 https://too= ls.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-09<= /a>
=C2=A0 =C2=A0 h= ttps://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6= -prefix-per-host-09

=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pre= fix-per-host-09


=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.= org.

=C2=A0 =C2=A0 Internet-Drafts are also available by anonymous FTP at:
=C2=A0 =C2=A0 ftp://ftp.ietf.org/internet-drafts/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/v6ops





--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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
--001a114b8232cd991f05592c067e-- From nobody Thu Sep 14 15:21:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5CF13208E for ; Thu, 14 Sep 2017 15:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q23o6H0rX8_5 for ; Thu, 14 Sep 2017 15:21:03 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DD9126DD9 for ; Thu, 14 Sep 2017 15:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1505427661; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=C5j+sIiTzZaYZ/d3JsNH6IDxuWHY1L9+qRYCsv7zb2o=; b=CpAiWCA6kv8RHqudlNFlq+1r1PSDxqKaHxKdRfT2vy+eU+x6xPc3reZ4bMTX8dNeFyrYJk6L3Uil3ULFR6iwz4S9O2oT+h/91ru5EdHkjIS9oajw32l+nNf+eVbijgWAyrl6DJTgVDyp7ZAPa/+ZmvmxLud18uqwxbyVUGDR2W0= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0056.outbound.protection.outlook.com [213.199.154.56]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-131-kV5tNRuuPXuhbnz1BcUMaQ-1; Thu, 14 Sep 2017 23:20:57 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0741.eurprd07.prod.outlook.com (10.242.253.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 14 Sep 2017 22:20:55 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590%14]) with mapi id 15.20.0077.005; Thu, 14 Sep 2017 22:20:55 +0000 From: Tim Chown To: David Farmer CC: Brian E Carpenter , V6 Ops List Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt Thread-Index: AQHTLJk5GrNrckyw8E6Ie5aQVJcS3qKzRLsAgAFxvgCAAD/UgA== Date: Thu, 14 Sep 2017 22:20:55 +0000 Message-ID: References: <150531144008.30405.8720524557391780522@ietfa.amsl.com> <11835e89-4aff-9ebe-01f0-155498586913@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:c49a:48e3:3b8b:4d4f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0741; 20:kE2PpKgIc1orgfjJnHp6gbCMLS6kWjoRYdDPb5dpbjV+/Kw/cUjsL5lTFrcGFF8jUN3wc+hN11AEWhR73EmK2JPrShdtFN7/NKLX4Uz6jluCHtvn3sVGNQ3kA13eSmzw6hW6kmGI+neJL2vyi3/bukzJL/ef+gmYeATg5DFTrLs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 090ae384-c49c-4e17-e7dc-08d4fbbede4a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0741; x-ms-traffictypediagnostic: AM3PR07MB0741: x-exchange-antispam-report-test: UriScan:(8104003914727); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0741; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0741; x-forefront-prvs: 0430FA5CB7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(377454003)(24454002)(6916009)(54906002)(8676002)(36756003)(316002)(5250100002)(230783001)(7736002)(50226002)(6506006)(3280700002)(68736007)(478600001)(99286003)(81166006)(6512007)(83716003)(305945005)(786003)(2171002)(53936002)(6116002)(8936002)(53546010)(102836003)(81156014)(82746002)(39060400002)(6246003)(86362001)(50986999)(97736004)(106356001)(6486002)(2900100001)(76176999)(6436002)(105586002)(2906002)(229853002)(189998001)(33656002)(101416001)(110136004)(3660700001)(2950100002)(42882006)(25786009)(4326008)(72206003)(14454004)(5660300001)(74482002)(57306001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0741; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2017 22:20:55.7422 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0741 X-MC-Unique: kV5tNRuuPXuhbnz1BcUMaQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 22:21:05 -0000 > On 14 Sep 2017, at 19:32, David Farmer wrote: >=20 >=20 >=20 > On Wed, Sep 13, 2017 at 3:29 PM, Brian E Carpenter wrote: > > A shared network service, is a service offering where a particular L= 2 > > access network (i.e. wifi) is shared and used by multiple visiting > > devices (i.e. subscribers). >=20 > I'm pretty sure that you mean "e.g.", not "i.e.", in both of those parent= heses. >=20 > Actually I think "i.e." is fine in the second case, "(in other words subs= cribers)" seems appropriate to the sentence, which is more or less what "i= .e." means. >=20 > But, yes in the first case "e.g." or "(for example wifi)" would seem more= appropriate to the sentence. > =20 > This version still does not clarify whether a "unicast" RA means one sent= to > a unicast Layer 3 address at a unicast Layer 2 address, or to ff02::1 at > a unicast Layer 2 address, or either. An implementer has to guess. >=20 > +1, while adding the reference to RFC6085, helps a little, I think this i= s worth a few more words to make it explicitly clear. Also, mentioning how= periodic RA are intended to be handled in addition to RAs in response to a= n RS. I provided some text previously, use it if you like. =20 Yes, this small change would improve the draft. Tim From nobody Thu Sep 14 18:18:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0CB1286C7 for ; Thu, 14 Sep 2017 18:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ab7pSluUjl6s for ; Thu, 14 Sep 2017 18:18:38 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EE4132331 for ; Thu, 14 Sep 2017 18:18:38 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id z8so1670645itc.2 for ; Thu, 14 Sep 2017 18:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h+uc1CMOUERUndU7HDaDV7seLsuVHHcLtImBEzs15BE=; b=Yyzbaw7bOP6Fc3qiDc+3du3nM/qBenVNC798r2ebuL5TMxkb8VbPrQ+yy8SD5kpMF9 y4K+xBs9YbjSA961ihCwnyqg88DMegiuZy/se6Qwbrea5D+0Lh4JK8zZ80qncOI8LQz2 iCVgzwn9TSOl4abl05NesfDkgJ1bB+wLWnPDAlP8JmaJzB7l0JcUIDlLDMDqxD+U5O2Z R8yZt+BWebxJaghzLuiqoH94uklWW4oya50XovheE9QVtD7eo7xHpkeQAvPz0dxw4kCN wqC1tbIo8VscQ8qHIWns4X//Jdi3a3Wes2WoCOAIGg9WEbtvUJeeQRAw6CnbLhgNzDAt 4s7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h+uc1CMOUERUndU7HDaDV7seLsuVHHcLtImBEzs15BE=; b=Cxiw2n5xmkTzfcYJBGwqibqxbh3DFqDahJfvZxrxZKFoYT6eh9Y5pdX6U4HZ8JnQ2b E181WDfD8wfMetGDHqrcrL3Jv8ZXGd/ZugsHN+3AhO3OF45mQ74S/eDiOiXYU+jsTD+q ooS/MaIXbm1zHZU6bQsZXTqqlPgqJHJmKEqZjNiGzbJ7Pv7bZvIM0e5I3Go3TS2h8XrH VN2joapoQ0tUc/mVDW69qDXktktocdlpkrnz9CLFja/GyWmN9u57wpJ29Lb/LwqT6ecJ JrKCrrxgpRGAlKK0CtRVYgZ4X/xGNUUzu2aq5tVfCXqCN6NkIv1HWsqpWO7lhRxCdI+S Yhhw== X-Gm-Message-State: AHPjjUhN1AFWmPlFbD+FOqKIIg8g8qUiFD1BKE25hcJXXlteeQb405ox 6F8hGkZUflH/s1QuCehGwjT3x3j9wRDgHyHV98Uqqg== X-Google-Smtp-Source: AOwi7QDRlf/0XdIH/nB0wuFqfFHjgb9LxQ3XHW+O4P35masvfgjNVFQKZbVqw+5qQS3u1wZo3lxYOo55n6dQ1JKfDvw= X-Received: by 10.36.77.83 with SMTP id l80mr2887443itb.148.1505438317250; Thu, 14 Sep 2017 18:18:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Thu, 14 Sep 2017 18:18:16 -0700 (PDT) In-Reply-To: <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: Lorenzo Colitti Date: Thu, 14 Sep 2017 18:18:16 -0700 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a11445aee2202770559302ca7" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 01:18:41 -0000 --001a11445aee2202770559302ca7 Content-Type: text/plain; charset="UTF-8" Thanks for fixing these issues. I think there are two issues remaining. First, the document needs to say something about periodic RAs. These are necessary or the device will fall off the network after the initial 1800s RA has expired. For initial RAs, the document covers two cases: 1. RAs are sent to the link-local address that the RS came from. 2. RAs are sent to ff02::1 but unicasted to the link-layer unicast address of the UE/subscriber. Case #2 is easy: just send it to the MAC address of the subcriber. Case #1 is not so easy.Which address should the router send it to? Does it need to cache the link-local address from the first RA it sees? What if the RS comes from the unspecified address (AFAIK that's explicitly allowed by 4861)? What if the host changes its link-local address? This is a problem for the first RS as well, so #2 seems like a better option in general. Second, the RA lifetimes should be longer. Bear in mind that many current mobile devices drop substantial percentage of multicast packets (1/2 or even 2/3). If the battery life recommendations of RFC 7772 are followed, the network will send RAs every 600s with a lifetime of 1800s. That means that if the device drops all three packets, it will fall off the network after 1800s. On a device that drops 2/3 multicast packets, that will happen .66**3 = 28.7% of the time. We should increase the router lifetime accordingly. Even if the lifetimes are increased to 3600s, the probability of connection loss after 1 hour is .66^3 = 8.3% of the time. If reliability is important I would suggest setting the RA lifetime to 5400 or 7200. In any case, the 3600 currently being recommended is too low. On Thu, Sep 14, 2017 at 12:16 PM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > This -09 version includes new text to address the idnits (i.e. versus > e.g.) noted by Brian and the clarification text pointed out on the first > hop router solicited/Unicast RA response using the suggested text from > David Farmer in section 4 para 3. > > Also the text suggested by Lorenzo is included in the text to make the > benefits of UE/subscriber more clear in section 1 para 3. > > G/ > > On 14/09/2017, 21:09, "v6ops on behalf of internet-drafts@ietf.org" < > v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6- > prefix-per-host-09.txt > Pages : 9 > Date : 2017-09-14 > > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique- > ipv6-prefix-per-host/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6- > prefix-per-host-09 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops- > unique-ipv6-prefix-per-host-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique- > ipv6-prefix-per-host-09 > > > 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 > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11445aee2202770559302ca7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for fixing these issues. I think there are two issu= es remaining.

First, the document needs to say something= about periodic RAs. These are necessary or the device will fall off the ne= twork after the initial 1800s RA has expired. For initial RAs, the document= covers two cases:
  1. RAs are sent to the link-local address= that the RS came from.
  2. RAs are sent to ff02::1 but unicasted to th= e link-layer unicast address of the UE/subscriber.
Case= #2 is easy: just send it to the MAC address of the subcriber.
Case #1 is not so easy.Which address should the router send it= to? Does it need to cache the link-local address from the first RA it sees= ?=C2=A0 What if the RS comes from the unspecified address (AFAIK that's= explicitly allowed by 4861)? What if the host changes its link-local addre= ss? This is a problem for the first RS as well, so #2 seems like a better o= ption in general.


Second, the RA lifetimes sho= uld be longer. Bear in mind that many current mobile devices drop substanti= al percentage of multicast packets (1/2 or even 2/3). If the battery life r= ecommendations of RFC 7772 are followed, the network will send RAs every 60= 0s with a lifetime of 1800s. That means that if the device drops all three = packets, it will fall off the network after 1800s. On a device that drops 2= /3 multicast packets, that will happen .66**3 =3D 28.7% of the time. We sho= uld increase the router lifetime accordingly. Even if the lifetimes are inc= reased to 3600s, the probability of connection loss after 1 hour is .66^3 = =3D 8.3% of the time.

If reliability is important = I would suggest setting the RA lifetime to 5400 or 7200. In any case, the 3= 600 currently being recommended is too low.

On Thu, Sep 14, 2017 at 12:16 PM, Van= De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@no= kia.com> wrote:
This -09 ve= rsion includes new text to address the idnits (i.e. versus e.g.) noted by B= rian and the clarification text pointed out on the first hop router solicit= ed/Unicast RA response using the suggested text from David Farmer in sectio= n 4 para 3.

Also the text suggested by Lorenzo is included in the text to make the bene= fits of UE/subscriber more clear in section 1 para 3.

G/

On 14/09/2017, 21:09, "v6ops on behalf of internet-drafts@ietf.org" <v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts directories.
=C2=A0 =C2=A0 This draft is a work item of the IPv6 Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Unique IPv6 Prefix Per Host
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: John Jason Brzozowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gunter Van De Velde
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-unique-ipv6-prefix-per-host-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-14

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document outlines an approach utilising exi= sting IPv6 protocols
=C2=A0 =C2=A0 =C2=A0 =C2=A0to allow hosts to be assigned a unique IPv6 pref= ix (instead of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0unique IPv6 address from a shared IPv6 prefix).= =C2=A0 Benefits of unique
=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 prefix over a unique service provider IPv6 = address include
=C2=A0 =C2=A0 =C2=A0 =C2=A0improved host isolation and enhanced subscriber = management on shared
=C2=A0 =C2=A0 =C2=A0 =C2=A0network segments.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://= datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/

=C2=A0 =C2=A0 There are also htmlized versions available at:
=C2=A0 =C2=A0 https://too= ls.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-09<= /a>
=C2=A0 =C2=A0 h= ttps://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6= -prefix-per-host-09

=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pre= fix-per-host-09


=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.= org.

=C2=A0 =C2=A0 Internet-Drafts are also available by anonymous FTP at:
=C2=A0 =C2=A0 ftp://ftp.ietf.org/internet-drafts/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/v6ops


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

--001a11445aee2202770559302ca7-- From nobody Thu Sep 14 22:54:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8D6132936 for ; Thu, 14 Sep 2017 22:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.039 X-Spam-Level: X-Spam-Status: No, score=-4.039 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 yEusGpySo64o for ; Thu, 14 Sep 2017 22:54:47 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1619126C0F for ; Thu, 14 Sep 2017 22:54:47 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 3125E24F for ; Fri, 15 Sep 2017 05:54:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtd_UFFtwF3s for ; Fri, 15 Sep 2017 00:54:46 -0500 (CDT) Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 908559B1 for ; Fri, 15 Sep 2017 00:54:46 -0500 (CDT) Received: by mail-lf0-f70.google.com with SMTP id 23so1135746lfs.0 for ; Thu, 14 Sep 2017 22:54:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0A5KtatabRGrn03WxjaJePjChny1q1/RfFMlQ6TSMGA=; b=dxkSjdaJWmymQYyKC1svspa9HILCnTJuHSsKdiXP7HVMWrduW3azrrAecjsD/KWHp0 sMQACeG1RK3D21LgMIIMoK6c69MWBNJJPBoQzcRXxC23kkZqo+AbtkCV9mR985mO5tzA 6ouVFpCdVlztNTp7xRCgkiiTQNolwuU9JIAgaVSm/w1hOH9QJHow+U4xGKB/yz79tw0R xfTgh0X89i5MGRzxBorW9WgNEarp5AKDOdJWLA25mBXrPJoxLIfUM8AlMkrKxDz53T6B dEy59XzV/Rinq07YpLodx51pk5fCoPedqRf86UIFwpTBW0yyAWBhBtFs+UmY0f4kILF6 nxWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0A5KtatabRGrn03WxjaJePjChny1q1/RfFMlQ6TSMGA=; b=oCP0vpKn9a6tpTwOMdGg7HP5oKpoUSPV0HgmqNpFZ3UI6FSca+0iTuNbNrPhtl00Vt X3+YY0HtjRbVDChIb3JrdH8UnBpgMj6xYzkmZRqoGvYC41GPvQ2hnksK3LWQIkVhDYwV Eir2+gNcfjFg+VG+wJaIr57gpbNQwEtZlPk/nToqWxmU70jLZyETOB5XVd7bwXaW+aj7 pTje7jBUJyCWDz1ECj6PqgNeH1Um8UXz61dt2Mwrx8ID1v226l/K96fBrXUaQL6UzwH1 iJsyij4UImE3GU0PPmERcF91V4hpboZ6N5nE+tGJpwk5wDnYLYZy5ab14CoXz0MpNqgm CGng== X-Gm-Message-State: AHPjjUiojMyK0DPbAcmjqMzkcYj3VlgeYAvi8rRf1P4lKnImtynqMKFV yJ4YLH80n0gWd94aqO8rm0/x9eKu9T7uMlOdbSutt6qwLO1dQDZiw3jgH0pu3vn6wATrtoKWVc2 78MI3Ulg4yp46g9pLbno8R+GZEg== X-Received: by 10.25.23.80 with SMTP id n77mr195943lfi.121.1505454884979; Thu, 14 Sep 2017 22:54:44 -0700 (PDT) X-Google-Smtp-Source: AOwi7QA1eE/b2AQMwhv1l7HqDugPe7FWzmjW3fkNhzmK3w5L+3LZc5j6Qqhl4AvPHv2atrwPLYzEVAE8nsEonNRxVXQ= X-Received: by 10.25.23.80 with SMTP id n77mr195937lfi.121.1505454884744; Thu, 14 Sep 2017 22:54:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Thu, 14 Sep 2017 22:54:44 -0700 (PDT) In-Reply-To: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: David Farmer Date: Fri, 15 Sep 2017 00:54:44 -0500 Message-ID: To: Lorenzo Colitti Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a1140650aa188a40559340786" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 05:54:50 -0000 --001a1140650aa188a40559340786 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 14, 2017 at 8:18 PM, Lorenzo Colitti wrote: > Thanks for fixing these issues. I think there are two issues remaining. > > First, the document needs to say something about periodic RAs. These are > necessary or the device will fall off the network after the initial 1800s > RA has expired. For initial RAs, the document covers two cases: > The text added does cover unsolicited RAs, A.K.A periodic RAs. > > 1. RAs are sent to the link-local address that the RS came from. > 2. RAs are sent to ff02::1 but unicasted to the link-layer unicast > address of the UE/subscriber. > > Case #2 is easy: just send it to the MAC address of the subcriber. > > Case #1 is not so easy.Which address should the router send it to? Does it > need to cache the link-local address from the first RA it sees? What if > the RS comes from the unspecified address (AFAIK that's explicitly allowed > by 4861)? What if the host changes its link-local address? This is a > problem for the first RS as well, so #2 seems like a better option in > general. > The new text refers you to [RFC4861] section 6.2.6 for details about a Unicast RA response and sections 6.2.4 and 6.2.6 for details about a Multicast RA response or unsolicited RA. Further, section 6.2.6 says "but the usual case is to multicast the response to the all-nodes group." However, I'm not sure case #1, as you put it, is that much harder, everything needed to do a Unicast RA response is knowing the RS packet, and once the Unicast RA is sent that information isn't needed any longer and can be forgotten. So from the perspective of this document I don't think there needs to be a preference that differs for what is stated in [RFC4861] section 6.2.6. As for an RS sourced from the unspecified address, [RFC4861] section 6.2.6, is quit clear you can't use a Unicast RA response in that case, and since that is referenced, I'm not sure it needs to be restated in this document. Maybe it should be noted that RFC7772 prefers the use of a Unicast RA responses to reduce the energy consumption of RAs, however since this document requires that any Multicast RAs are sent as a Link-layer Unicast, the Unicast RA responses is not necessary to reduce the energy consumption of RAs. Second, the RA lifetimes should be longer. Bear in mind that many current > mobile devices drop substantial percentage of multicast packets (1/2 or > even 2/3). If the battery life recommendations of RFC 7772 are followed, > the network will send RAs every 600s with a lifetime of 1800s. That means > that if the device drops all three packets, it will fall off the network > after 1800s. On a device that drops 2/3 multicast packets, that will happen > .66**3 = 28.7% of the time. We should increase the router lifetime > accordingly. Even if the lifetimes are increased to 3600s, the probability > of connection loss after 1 hour is .66^3 = 8.3% of the time. > > If reliability is important I would suggest setting the RA lifetime to > 5400 or 7200. In any case, the 3600 currently being recommended is too low. > Yea, I was thinking about that; maybe there should be a complete set of alternate IPv6 router discovery and neighbor discovery timers, provided for when battery consumption is a concern and referencing RFC7772, instead of just an alternate Maximum IPv6 Router Advertisement Interval. > > On Thu, Sep 14, 2017 at 12:16 PM, Van De Velde, Gunter (Nokia - > BE/Antwerp) wrote: > >> This -09 version includes new text to address the idnits (i.e. versus >> e.g.) noted by Brian and the clarification text pointed out on the first >> hop router solicited/Unicast RA response using the suggested text from >> David Farmer in section 4 para 3. >> >> Also the text suggested by Lorenzo is included in the text to make the >> benefits of UE/subscriber more clear in section 1 para 3. >> >> G/ >> >> On 14/09/2017, 21:09, "v6ops on behalf of internet-drafts@ietf.org" < >> v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Operations WG of the IETF. >> >> Title : Unique IPv6 Prefix Per Host >> Authors : John Jason Brzozowski >> Gunter Van De Velde >> Filename : draft-ietf-v6ops-unique-ipv6-p >> refix-per-host-09.txt >> Pages : 9 >> Date : 2017-09-14 >> >> Abstract: >> This document outlines an approach utilising existing IPv6 >> protocols >> to allow hosts to be assigned a unique IPv6 prefix (instead of a >> unique IPv6 address from a shared IPv6 prefix). Benefits of unique >> IPv6 prefix over a unique service provider IPv6 address include >> improved host isolation and enhanced subscriber management on >> shared >> network segments. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv >> 6-prefix-per-host/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-pre >> fix-per-host-09 >> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-uniqu >> e-ipv6-prefix-per-host-09 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ip >> v6-prefix-per-host-09 >> >> >> 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 >> >> >> _______________________________________________ >> 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 > > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --001a1140650aa188a40559340786 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Sep 14, 2017 at 8:18 PM, Lorenzo Colitti <lorenzo@goog= le.com> wrote:
Thanks for fixing these issues. I think there are t= wo issues remaining.

First, the document needs to say so= mething about periodic RAs. These are necessary or the device will fall off= the network after the initial 1800s RA has expired. For initial RAs, the d= ocument covers two cases:

The t= ext added does cover unsolicited RAs, A.K.A periodic RAs.
  1. RAs are= sent to the link-local address that the RS came from.
  2. RAs are sent= to ff02::1 but unicasted to the link-layer unicast address of the UE/subsc= riber.
Case #2 is easy: just send it to the MAC address= of the subcriber.

Case #1 is not so easy.Which ad= dress should the router send it to? Does it need to cache the link-local ad= dress from the first RA it sees?=C2=A0 What if the RS comes from the unspec= ified address (AFAIK that's explicitly allowed by 4861)? What if the ho= st changes its link-local address? This is a problem for the first RS as we= ll, so #2 seems like a better option in general.

The new text refers you to [RFC4861] section 6.2.6 for de= tails about a Unicast RA response and sections 6.2.4 and 6.2.6 for details = about a Multicast RA response or unsolicited RA. Further, section 6.2.6 say= s "but the usual case is to multicast the response to the all-nodes gr= oup." However, I'm not sure case #1, as you put it, is that much h= arder, everything needed to do a Unicast RA response is knowing the RS pack= et, and once the Unicast RA is sent that information isn't needed any l= onger and can be forgotten. So from the perspective of this document I don&= #39;t think there needs to be a preference that differs for what is stated = in [RFC4861] section 6.2.6. As for an RS sourced from the unspecified addre= ss, [RFC4861] section 6.2.6, is quit clear you can't use a Unicast RA r= esponse in that case, and since that is referenced, I'm not sure it nee= ds to be restated in this document.

Maybe it shoul= d be noted that RFC7772 prefers the use of a Unicast RA responses to reduce= the energy consumption of RAs, however since this document requires that a= ny Multicast RAs are sent as a Link-layer Unicast, the Unicast RA responses= is not necessary to reduce the energy consumption of RAs.

Second, the RA lifetimes should be longer. Bear in mind that many current = mobile devices drop substantial percentage of multicast packets (1/2 or eve= n 2/3). If the battery life recommendations of RFC 7772 are followed, the n= etwork will send RAs every 600s with a lifetime of 1800s. That means that i= f the device drops all three packets, it will fall off the network after 18= 00s. On a device that drops 2/3 multicast packets, that will happen .66**3 = =3D 28.7% of the time. We should increase the router lifetime accordingly. = Even if the lifetimes are increased to 3600s, the probability of connection= loss after 1 hour is .66^3 =3D 8.3% of the time.

= If reliability is important I would suggest setting the RA lifetime to 5400= or 7200. In any case, the 3600 currently being recommended is too low.

Yea, I was thinking about that; maybe t= here should be a complete set of alternate IPv6 router discovery and neighb= or discovery timers, provided for when battery consumption is a concern and= referencing RFC7772, instead of just an alternate Maximum IPv6 Router Adve= rtisement Interval.
=C2=A0
On Thu, Sep 14, 2017 at 12:16 PM, Van De Velde, Gunter (Nokia -= BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:
This -09 vers= ion includes new text to address the idnits (i.e. versus e.g.) noted by Bri= an and the clarification text pointed out on the first hop router solicited= /Unicast RA response using the suggested text from David Farmer in section = 4 para 3.

Also the text suggested by Lorenzo is included in the text to make the bene= fits of UE/subscriber more clear in section 1 para 3.

G/

On 14/09/2017, 21:09, "v6ops on behalf of internet-drafts@ietf.org" <v6ops-bounces@iet= f.org on behalf of internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts directories.
=C2=A0 =C2=A0 This draft is a work item of the IPv6 Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Unique IPv6 Prefix Per Host
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: John Jason Brzozowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gunter Van De Velde
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-unique-ipv6-prefix-per-host-09.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-14

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document outlines an approach utilising exi= sting IPv6 protocols
=C2=A0 =C2=A0 =C2=A0 =C2=A0to allow hosts to be assigned a unique IPv6 pref= ix (instead of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0unique IPv6 address from a shared IPv6 prefix).= =C2=A0 Benefits of unique
=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 prefix over a unique service provider IPv6 = address include
=C2=A0 =C2=A0 =C2=A0 =C2=A0improved host isolation and enhanced subscriber = management on shared
=C2=A0 =C2=A0 =C2=A0 =C2=A0network segments.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://= datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/

=C2=A0 =C2=A0 There are also htmlized versions available at:
=C2=A0 =C2=A0 https://too= ls.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-09<= /a>
=C2=A0 =C2=A0 h= ttps://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6= -prefix-per-host-09

=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pre= fix-per-host-09


=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.= org.

=C2=A0 =C2=A0 Internet-Drafts are also available by anonymous FTP at:
=C2=A0 =C2=A0 ftp://ftp.ietf.org/internet-drafts/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/v6ops


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


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




--
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & = Telecommunication Services
Office of Information Technology
Universit= y of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cel= l: 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
--001a1140650aa188a40559340786-- From nobody Thu Sep 14 23:17:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84A01320D8 for ; Thu, 14 Sep 2017 23:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 cweDqNUbDRhl for ; Thu, 14 Sep 2017 23:17:38 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73031132076 for ; Thu, 14 Sep 2017 23:17:38 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id w9so879142ywi.11 for ; Thu, 14 Sep 2017 23:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zoQMvowxRTQ5a8nZvwHqRE/jHOPvWvWZFqRGEQbMFoQ=; b=HZD9WW/j2sExYDK5fSAcCuRw/Eg8+X4DY1xfOUNzW/NGoEcfaxyxFQ1IxgixflcrTl 0kzZirYPBullV+u8DT+/46WWrDaMpTbcFuqGnxdUaU9HF5Hx4GhzaDM023myoAo1Q93s 74BzusbKxmKlrQ9IE70qizb4E04gOBh8FjbLK/zO8zGWN7Zq2ArIaqyYf8UFS4OOvjmj T/kKRQHY5nKf/2ZWHXUmGssHnjHcsY4+TNe0aBs1/duN6pUzn1CJ2AMyJq8MltzV86Tq e5d/Mjt8yxewWC2/ImLcaThCDaJH/gPy6kKic8GSW4bcHkpHIENAhuKU9+ZKRGZBLIcL WTRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zoQMvowxRTQ5a8nZvwHqRE/jHOPvWvWZFqRGEQbMFoQ=; b=uU6aGMK8nJ9xUqDU9Zf9lMNcLN8diPhXguPrQsGtQ+gesurwnZptSzOyxHYd1k1W7o Za0hbRsYfnLLIrwPV4FD3aQyYDPwsiLS1NHUJuTROp+dNs+ApuTC0Z65fkp3s+2RCJTk 0ZSOb/Kd8FGsZjb2fF8aWtu2I8gZJ2kKNOvKCUluw2Tkj/B8QYBhxDRMEQrCjaUuFZHC YBV21x8UWnoN6air49kkJi5e1N0Yj6Eq8ysSGE49ICNk1ZGqfj7BufLf3YW6+1bn7DMY FLwqU+mJKu5y26IMgMDove+0D7qE6ibLDFk5sdc2DwnkqhErc/TVFzVDHGe1VokcI32a IL9w== X-Gm-Message-State: AHPjjUi1GiOPp0vyXCEHa41si4+iZh5iUgL+KwOiwTG48Bw0UXXKFSlU Zs1EQQ+uvNiHylI07jOvuzcTWLEzfk4cQN2pFo+BAw== X-Google-Smtp-Source: AOwi7QD0he3vi+h3amb+JaszqKtLo2OWEjtKPsShQfnA7OAv03nEL5EdbdQ4Rb1y3v4nm3SQe7jXF+fjJgFj6MtCxd0= X-Received: by 10.37.36.141 with SMTP id k135mr6165553ybk.259.1505456257413; Thu, 14 Sep 2017 23:17:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Thu, 14 Sep 2017 23:17:16 -0700 (PDT) In-Reply-To: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: Lorenzo Colitti Date: Thu, 14 Sep 2017 23:17:16 -0700 Message-ID: To: David Farmer Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a113ce3c873556f055934596e" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 06:17:40 -0000 --001a113ce3c873556f055934596e Content-Type: text/plain; charset="UTF-8" On Thu, Sep 14, 2017 at 10:54 PM, David Farmer wrote: > >> First, the document needs to say something about periodic RAs. These are >> necessary or the device will fall off the network after the initial 1800s >> RA has expired. For initial RAs, the document covers two cases: >> > > The text added does cover unsolicited RAs, A.K.A periodic RAs. > >> >> 1. RAs are sent to the link-local address that the RS came from. >> 2. RAs are sent to ff02::1 but unicasted to the link-layer unicast >> address of the UE/subscriber. >> >> Ah yes, it does say that. So if I understand correctly, solicited RAs can be either #1 (assuming the RS doesn't come from the unspecified address) or #2, but periodic RAs must be #2. Given that periodic RAs must be #2, what's the reason to do #1 at all? --001a113ce3c873556f055934596e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 14, 2017 at 10:54 PM, David Farmer <farmer@umn.edu> wro= te:

First, the document needs to= say something about periodic RAs. These are necessary or the device will f= all off the network after the initial 1800s RA has expired. For initial RAs= , the document covers two cases:

The text added does cover unsolicited RAs, A.K.A periodic RAs.
  1. RAs are sent to the link-local address that the RS came f= rom.
  2. RAs are sent to ff02::1 but unicasted to the link-layer unicas= t address of the UE/subscriber.

Ah yes, it does say that. = So if I understand correctly, solicited RAs can be either #1 (assuming the = RS doesn't come from the unspecified address) or #2, but periodic RAs m= ust be #2.

Given that periodic RAs must be #2, wha= t's the reason to do #1 at all?
--001a113ce3c873556f055934596e-- From nobody Fri Sep 15 00:01:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD3D132936 for ; Fri, 15 Sep 2017 00:01:16 -0700 (PDT) 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_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 md9KifNfRUiE for ; Fri, 15 Sep 2017 00:01:15 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB8C13218F for ; Fri, 15 Sep 2017 00:01:15 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id E55BBA31 for ; Fri, 15 Sep 2017 07:01:14 +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 ubL-TDsOfYfR for ; Fri, 15 Sep 2017 02:01:14 -0500 (CDT) Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 7C4EAA2F for ; Fri, 15 Sep 2017 02:01:14 -0500 (CDT) Received: by mail-lf0-f69.google.com with SMTP id h80so1221398lfe.7 for ; Fri, 15 Sep 2017 00:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D7wEPyUtV051DHtGf/2sOkYfZW+4wFbEdWmvHC+bNfM=; b=KiP1b64bXYhjydeR32CWHu5gncxui1jrxrdACrSgq8G0Eij2XBXM5jImGnxz3tmk3O 58SmXOTLgPBhHo1+M4aSV+E5LvDUZMsCKMqICxv4GwqTbRh0CZN9K6bCEZc6BkwrTUmh 0wb1qSFo+C+hDJsLBzVCATbJHlT/3+HSCgAPB9ruMYZNvBQJ6jMIMqoNTOJ9VjpHhtdr ivjgB0N1YzpzoDwhFjjgxVJUDqIkwt7x1jbv1UvgbBGr8YBbT2PNAv0l9Gs/A2Kly2Ad mEKoT5vL0gCmF/Vl1/94daRglgcf8lFvvYCCpMaybClOKeZNNd3c18UeRgxbpvWkOmk+ EZvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D7wEPyUtV051DHtGf/2sOkYfZW+4wFbEdWmvHC+bNfM=; b=O7DCWYhdJjGlSMJB36k0Pqj/x5y7G0Rht6EiC7GsuKBY5NOLSxXfSeWi5rQX/8cBhb BR+Gc0i+YFePqSTWgKkf2N6Kt46q3o5dQl9I7wuFsv1mVjeSGAg7McghNN69uX1AATPZ UetX+ot+Faogs1LvpHSI57AIEZyo0AIf8p9N5Nc/zxqaLaj1gEKKBk4pFKohOgWYRCn/ +2hAIcs6OVa762/omidEHGaPbw26a/91NZKWKRLwMM97Nws3NRHevf0HhbHHC3Q+uLxM Iz3XT+6Q+9UxfmZE6LZfz7yNNpPjG49VvkGjDLs7G9syrp46AI2oPoGkHARWqxpLq6Dc GPyQ== X-Gm-Message-State: AHPjjUhck6YxGSmHCQoY4tDDK/cFrYBdECYgpNfjVCyBIyDqCaIpQVlJ 94EniicxuBhasnY7ENFOF1B6s2Mj0JFrd9TADDvEjF517flR2KEj5aYZtIrHC2RRfR5hPe6Z81l Sv+cUCWCEjf+6Edod4qRfN1JRqg== X-Received: by 10.25.23.80 with SMTP id n77mr258653lfi.121.1505458872056; Fri, 15 Sep 2017 00:01:12 -0700 (PDT) X-Google-Smtp-Source: AOwi7QC5WYJJfd6R8ed5RDrH5ZO2/PGcYtW6JFRFNBUdlK5Xvbl8lFk+LsNPvW3EW3GysvB5ODusyN/zaLO73pzPCIw= X-Received: by 10.25.23.80 with SMTP id n77mr258640lfi.121.1505458871574; Fri, 15 Sep 2017 00:01:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Fri, 15 Sep 2017 00:01:10 -0700 (PDT) In-Reply-To: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: David Farmer Date: Fri, 15 Sep 2017 02:01:10 -0500 Message-ID: To: Lorenzo Colitti Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a1140650a43bc6a055934f52b" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 07:01:17 -0000 --001a1140650a43bc6a055934f52b Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 1:17 AM, Lorenzo Colitti wrote: > On Thu, Sep 14, 2017 at 10:54 PM, David Farmer wrote: > >> >>> First, the document needs to say something about periodic RAs. These are >>> necessary or the device will fall off the network after the initial 1800s >>> RA has expired. For initial RAs, the document covers two cases: >>> >> >> The text added does cover unsolicited RAs, A.K.A periodic RAs. >> >>> >>> 1. RAs are sent to the link-local address that the RS came from. >>> 2. RAs are sent to ff02::1 but unicasted to the link-layer unicast >>> address of the UE/subscriber. >>> >>> > Ah yes, it does say that. So if I understand correctly, solicited RAs can > be either #1 (assuming the RS doesn't come from the unspecified address) or > #2, but periodic RAs must be #2. > > Given that periodic RAs must be #2, what's the reason to do #1 at all? > While I'm not sure there is a good reason to implement anything more than #2. On the other hand, I see no good reason for this document to disallow #1 since it's allows by RFC4861. There is a lot of basic router code that doesn't implement #1, no one had to say anything more than what is already in RFC4861 for that to be the case, why do you think anything more needs to be said in this case? Like I said; Maybe it should be noted that RFC7772 prefers the use of a Unicast RA responses to reduce the energy consumption of RAs, however since this document requires that any Multicast RAs are sent as a Link-layer Unicast, a Unicast RA responses is not necessary to reduce the energy consumption of RAs. Since RFC4861 allows Unicast RAs and I don't see any reason requiring they MUST NOT be used within this use case, I don't see any reason to discourage their use more than what RFC4861 says already. I don't think the text says anything to encourage there use, if you feel otherwise please point out what you think is encouraging there use. Anyway, who knows, maybe someone will might come up a variant of this use case where they are useful, I doubt it, but I can't rule it out. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --001a1140650a43bc6a055934f52b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 15, 2017 at 1:17 AM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
=
On T= hu, Sep 14, 2017 at 10:54 PM, David Farmer <farmer@umn.edu> wro= te:
<= div class=3D"gmail_extra">

First, the document = needs to say something about periodic RAs. These are necessary or the devic= e will fall off the network after the initial 1800s RA has expired. For ini= tial RAs, the document covers two cases:

<= /span>
The text added does cover unsolicited RAs, A.K.A periodic RAs.
  1. RAs are sent to the link-local address that the RS came from= .
  2. RAs are sent to ff02::1 but unicasted to the link-layer unicast a= ddress of the UE/subscriber.

Ah yes, it does say that. So = if I understand correctly, solicited RAs can be either #1 (assuming the RS = doesn't come from the unspecified address) or #2, but periodic RAs must= be #2.

Given that periodic RAs must be #2, what&#= 39;s the reason to do #1 at all?

While I'm not s= ure there is a good reason to implement anything more than #2. On the other= hand, I see no good reason for this document to disallow #1 since it's= allows by RFC4861.=C2=A0 There is a lot of basic router code that doesn= 9;t implement #1, no one had to say anything more than what is already in R= FC4861 for that to be the case, why do you think anything more needs to be = said in this case?=C2=A0

Like I said;=C2=A0Maybe= it should be noted that RFC7772 prefers the use of a Unicast RA responses = to reduce the energy consumption of RAs, however since this document requir= es that any Multicast RAs are sent as a Link-layer Unicast, a Unicast RA re= sponses is not necessary to reduce the energy consumption of RAs.=C2= =A0

Si= nce RFC4861 allows Unicast RAs and I don't see any reason requiring the= y MUST NOT be used within this use case, I don't see any reason to disc= ourage their use more than what RFC4861 says already. I don't think the= text says anything to encourage there use, if you feel otherwise please po= int out what you think is encouraging there use.=C2=A0 Anyway, who knows, m= aybe someone will might come up a variant of this use case where they are u= seful, I doubt it, but I can't rule it out.

Thanks.
--
=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking &a= mp; Telecommunication Services
Office of Information Technology
Unive= rsity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0= Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
--001a1140650a43bc6a055934f52b-- From nobody Fri Sep 15 00:15:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBEA9133038 for ; Fri, 15 Sep 2017 00:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Q4yEuYAF_I2T for ; Fri, 15 Sep 2017 00:15:27 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527BF132055 for ; Fri, 15 Sep 2017 00:15:27 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id m103so6180441iod.13 for ; Fri, 15 Sep 2017 00:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vbb6UybdarOhTxGE0VZuIwlBLAAP/ThzFKXklnKi/UE=; b=X8yD5D7E2KY0wqxBXM2Qi1Afm+WBc7Luzjb9MpJWxOuiAgpEr7wpTI3QBl/hl865Ix YNKa2p1uiyLI9wy4TWVvuhyKL1vPB+DjkJAbsnXXyKtbai/2/E/us+3HfTPWLwPVyO2b saMB0zcgFp4t+vhfBTLKoBpspna3qtn7S4pQCxNzdDQqX+4MAyGAS/OGEXReeMLa4SNt GjYe8goDtWcENqy/ulA9yzKFBa9J+IAerlmRAirw703H4NCYG3BzPBepXluh733Oyeg9 xi3wl6eoFKfL2iunVNTpDT7VF7gd1vIDsjRbtuDXS8jW4+X3cwKAcFNGYKifths+A0W2 YS7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vbb6UybdarOhTxGE0VZuIwlBLAAP/ThzFKXklnKi/UE=; b=N6zwoMPCvOwb0q0YgEmBYzimwkeFrFWAk8e2JoGQPRx1Qk+0xFTEQHcM/gUBzrJCq8 c/4lF7vTnaUSHujdX3UrK7KgcuHfeNKssytsJ2MdVwyBxb0fyBuXkoTaULoOX24vIQbR RrOJWXGnj856YgSeykq8gTZ8pNO6e93AOmq+qx6pOGU3U+9I8YP3VMXhqNa2mr0vTA0Y GaCmVVyMNxjlnE/+HVJgIti1cx3pnvVMQ8VHhsiGzXtmZ5Z12W4Ok/0WQRTRticLRP3L ce0LWmOHhCXPO/LLNPb7bj58LlM3Sv1+5/cSGb3aU9tPZIurs0h96dqAjFEsiPpOeCAJ aBWQ== X-Gm-Message-State: AHPjjUhtvX8/PL/MrkTKumnMONdBp3l/5wN3jyoRUeRpgOCUpDOGayPU aTJBbCtYQ9/AdBZnFH+fTjzu0dsQlc93odQJj/cl6A== X-Google-Smtp-Source: AOwi7QAb9abSgYJ4p5dtcgof5iYRRYPombPiPAUMqUxGPp5ibPj6Jym9Clu6/70nxZs28epIvWI/j77zy8ck2xwbYd0= X-Received: by 10.107.52.205 with SMTP id b196mr1610787ioa.4.1505459726338; Fri, 15 Sep 2017 00:15:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Fri, 15 Sep 2017 00:15:05 -0700 (PDT) In-Reply-To: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: Lorenzo Colitti Date: Fri, 15 Sep 2017 00:15:05 -0700 Message-ID: To: David Farmer Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a114410cc36c8270559352819" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 07:15:29 -0000 --001a114410cc36c8270559352819 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 12:01 AM, David Farmer wrote: > Ah yes, it does say that. So if I understand correctly, solicited RAs can >> be either #1 (assuming the RS doesn't come from the unspecified address) or >> #2, but periodic RAs must be #2. >> >> Given that periodic RAs must be #2, what's the reason to do #1 at all? >> > > While I'm not sure there is a good reason to implement anything more than > #2. On the other hand, I see no good reason for this document to disallow > #1 since it's allows by RFC4861. There is a lot of basic router code that > doesn't implement #1, no one had to say anything more than what is already > in RFC4861 for that to be the case, why do you think anything more needs to > be said in this case? > > Like I said; Maybe it should be noted that RFC7772 prefers the use of a > Unicast RA responses to reduce the energy consumption of RAs, however since > this document requires that any Multicast RAs are sent as a Link-layer > Unicast, a Unicast RA responses is not necessary to reduce the energy > consumption of RAs. > Agreed on both the interpretation of the RFCs. Also, this is not about energy consumption - in both cases the packets are unicast at layer 2, so there is no difference in power. My comment is regarding simplicity of router implementation. Ideally, anyone implementing this RFC would realize that #2 has to be done regardless (for periodic RAs) and that #1 is optional. If they then decide to implement #1 as well, that's fine. Unfortunately I'm not sure the text is clear enough for that. Specifically I worry that implementers won't realize that #2 is mandatory, implement #1 first, and then implement periodic RAs with something hacky like "cache the last-seen link-local address, and always send unicast RAs to that address". --001a114410cc36c8270559352819 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 15, 2017 at 12:01 AM, David Farmer <farmer@umn.edu> wro= te:
A= h yes, it does say that. So if I understand correctly, solicited RAs can be= either #1 (assuming the RS doesn't come from the unspecified address) = or #2, but periodic RAs must be #2.

Given that per= iodic RAs must be #2, what's the reason to do #1 at all?

While I= 'm not sure there is a good reason to implement anything more than #2. = On the other hand, I see no good reason for this document to disallow #1 si= nce it's allows by RFC4861.=C2=A0 There is a lot of basic router code t= hat doesn't implement #1, no one had to say anything more than what is = already in RFC4861 for that to be the case, why do you think anything more = needs to be said in this case?=C2=A0

Like I said;=C2=A0Maybe it should be noted that RFC7772 prefers the use of a Unicast R= A responses to reduce the energy consumption of RAs, however since this doc= ument requires that any Multicast RAs are sent as a Link-layer Unicast, a U= nicast RA responses is not necessary to reduce the energy consumption of RA= s.=C2=A0

Agreed on both = the interpretation of the RFCs. Also, this is not about energy consumption = - in both cases the packets are unicast at layer 2, so there is no differen= ce in power.

My comment is regarding simplicity of= router implementation. Ideally, anyone implementing this RFC would realize= that #2 has to be done regardless (for periodic RAs) and that #1 is option= al. If they then decide to implement #1 as well, that's fine.

Unfortunately I'm not sure the text is clear enough for= that. Specifically I worry that implementers won't realize that #2 is = mandatory, implement #1 first, and then implement periodic RAs with somethi= ng hacky like "cache the last-seen link-local address, and always send= unicast RAs to that address".
--001a114410cc36c8270559352819-- From nobody Fri Sep 15 07:34:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42439133343; Fri, 15 Sep 2017 07:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpaEL3JO-paG; Fri, 15 Sep 2017 07:34:30 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7345B13337F; Fri, 15 Sep 2017 07:34:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8FEYTiL011575; Fri, 15 Sep 2017 07:34:29 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8FEYKbM011439 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Sep 2017 07:34:20 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Sep 2017 07:34:20 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 15 Sep 2017 07:34:20 -0700 From: "Templin, Fred L" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0R353fXvPDrEeoXyoh+k1EZqK2AYpw Date: Fri, 15 Sep 2017 14:34:19 +0000 Message-ID: <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> In-Reply-To: <150541619338.18973.1376799734453993603@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 14:34:32 -0000 I am OK with the changes, but there is still something missing. The router = needs to be able to send ICMPv6 Destination Unreachables for IPv6 destination addres= ses that do not match one of the host's current addresses. That means that the = router needs to consider the prefix as on-link and perform address resolution for = each destination address covered by the prefix. The document should mention this, because it is currently silent on how rou= ters regard PIOs with A=3D1;L=3D0. This is also an important distinction between what this document recommends and true prefix delegation. Fred=20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-drafts@= ietf.org > Sent: Thursday, September 14, 2017 12:10 PM > To: i-d-announce@ietf.org > Cc: v6ops@ietf.org > Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host= -09.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt > Pages : 9 > Date : 2017-09-14 >=20 > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-= 09 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix= -per-host-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-p= er-host-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Sep 15 07:40:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA2E13337F for ; Fri, 15 Sep 2017 07:40:56 -0700 (PDT) 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_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 iYDm6Gq0BE_3 for ; Fri, 15 Sep 2017 07:40:55 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84D8133343 for ; Fri, 15 Sep 2017 07:40:54 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 5A3E9B8E for ; Fri, 15 Sep 2017 14:40:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge72DB7hM6YV for ; Fri, 15 Sep 2017 09:40:53 -0500 (CDT) Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 3C1B6BA6 for ; Fri, 15 Sep 2017 09:40:53 -0500 (CDT) Received: by mail-lf0-f72.google.com with SMTP id c8so2047415lfe.4 for ; Fri, 15 Sep 2017 07:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NSzuCyFsuiN8g7tcOO55WEV29NZsHC4dZeqtU8GnO7Y=; b=ADZuwQRGL6XZScUz9QiMZLddU5CotV8y41XIJSgibre2l36JYJEzBHS8csqvuu3CXc shF3bHW83ikMz+boPZGuqZ/c/CwosNdYOdCXiJwY5J/ejBf5Uh+EuRGxOIwlXMsK3FWJ tZcWK1SXwB5fn6JN+B4IL9VHF/53BfqNXJSRr9dsySVcoixfyOoVmcmdViNAspHettL+ JYceEVafwogqC3KrZQZ0v/BiJ1O0FgGG6esVRTLccxHgXQW2sMgzJHq3DJ+uP7SC7bmS 3dXE33CdoRirxNOciXnyRnwnBm62Ed84eYz5tBfhJtB3gJprDJWpdWLJSPcUHg+vJFcy CV1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NSzuCyFsuiN8g7tcOO55WEV29NZsHC4dZeqtU8GnO7Y=; b=tPHlkjalOVZT/x48SpbmZHjkRCwzMI4MOjind8lNcWk3N0tNEOgRprh6GIr80SBbWI Iy2fuF0nHFoRC9bGdlUcV4i0gfdWI8ys2LzJRYIiHEbd5O1WJ0EWZTn7pDQt30nPwhin S26tDDFcNZOjwVoAaywoQTPM7XYprKaWAU6HJKjFdDykAVMmHa5YLut/DqQT4OWX0b+P Y562/Sp5Q+kUDFVCYxxlcixQ4lXNOpQYkABSnvG8keouUQittvlnOvGaxnX6eDndtrwl vzaKF0fqneiYhjJqjRyvXfDLJPPz4Z17j58uUawT0fQkjjX/aURH3D+meS7FfvCjwCjf DDMA== X-Gm-Message-State: AHPjjUiUUlyUAY2um9zoRszWiAn+VFCJ9JgEs1aHeUFujFoubdAPpDbd S4avsZemYZqt0pqQwQdAE3XUQ/Awgt7ODR1q+urCxa8bLR3YkfJw/gOPpNlOyzr0B8rboLrrXx9 1SDHNDyWtUkR3LbCV1SIBsIfWvg== X-Received: by 10.46.3.9 with SMTP id 9mr10794387ljd.17.1505486451796; Fri, 15 Sep 2017 07:40:51 -0700 (PDT) X-Google-Smtp-Source: AOwi7QC+xrveLyr9knXEYC3X4zSy7GQJsibUkb3YexUiZTQPIsCipzjj/JdsC7cjihakbhpCvlFBW8vpX3ilRXPYT6I= X-Received: by 10.46.3.9 with SMTP id 9mr10794383ljd.17.1505486451525; Fri, 15 Sep 2017 07:40:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Fri, 15 Sep 2017 07:40:50 -0700 (PDT) In-Reply-To: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: David Farmer Date: Fri, 15 Sep 2017 09:40:50 -0500 Message-ID: To: Lorenzo Colitti Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="089e08274d582855b905593b612d" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 14:40:57 -0000 --089e08274d582855b905593b612d Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 2:15 AM, Lorenzo Colitti wrote: > On Fri, Sep 15, 2017 at 12:01 AM, David Farmer wrote: > >> Ah yes, it does say that. So if I understand correctly, solicited RAs can >>> be either #1 (assuming the RS doesn't come from the unspecified address) or >>> #2, but periodic RAs must be #2. >>> >>> Given that periodic RAs must be #2, what's the reason to do #1 at all? >>> >> >> While I'm not sure there is a good reason to implement anything more than >> #2. On the other hand, I see no good reason for this document to disallow >> #1 since it's allows by RFC4861. There is a lot of basic router code that >> doesn't implement #1, no one had to say anything more than what is already >> in RFC4861 for that to be the case, why do you think anything more needs to >> be said in this case? >> >> Like I said; Maybe it should be noted that RFC7772 prefers the use of a >> Unicast RA responses to reduce the energy consumption of RAs, however since >> this document requires that any Multicast RAs are sent as a Link-layer >> Unicast, a Unicast RA responses is not necessary to reduce the energy >> consumption of RAs. >> > > Agreed on both the interpretation of the RFCs. Also, this is not about > energy consumption - in both cases the packets are unicast at layer 2, so > there is no difference in power. > > My comment is regarding simplicity of router implementation. Ideally, > anyone implementing this RFC would realize that #2 has to be done > regardless (for periodic RAs) and that #1 is optional. If they then decide > to implement #1 as well, that's fine. > > Unfortunately I'm not sure the text is clear enough for that. Specifically > I worry that implementers won't realize that #2 is mandatory, implement #1 > first, and then implement periodic RAs with something hacky like "cache the > last-seen link-local address, and always send unicast RAs to that address". > Ok, maybe by discussing the unicast RA fist, there could be some unintended emphasis put on that option, how about a minor rearrangement of the paragraph, adding that unsolicited RAs are always multicast, and adding the few editorial nits I mentioned earlier for the following paragraph; When the First Hop Provider Router sends a solicited RA response, or periodically sends unsolicited RAs, the RA MUST be sent only to the subscriber that has been assigned the Unique IPv6 prefix contained in the RA. This is achieved by sending a multicast RA response or unsolicited RAs to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6, but instead of using the link-layer multicast address associated with the all-nodes group, the link-layer unicast address of the subscriber that has been assigned the Unique IPv6 prefix contained in the RA MUST be used as the link-layer destination RFC6085 [RFC6085]. Or, optionally in some cases, a unicast RA response could be sent as detailed in [RFC4861] section 6.2.6, nevertheless unsolicited RAs are always sent to the all-nodes group. The RA contains two important parameters for the subscriber to consume: ... I think that removes any unintended emphasis the unicast RA option, while at the same time putting a little more emphasis on the multicast RA option. What do you think? Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --089e08274d582855b905593b612d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 15, 2017 at 2:15 AM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
=
On F= ri, Sep 15, 2017 at 12:01 AM, David Farmer <farmer@umn.edu> wro= te:
<= div class=3D"gmail_extra">
A= h yes, it does say that. So if I understand correctly, solicited RAs can be= either #1 (assuming the RS doesn't come from the unspecified address) = or #2, but periodic RAs must be #2.

Given that per= iodic RAs must be #2, what's the reason to do #1 at all?

While I= 'm not sure there is a good reason to implement anything more than #2. = On the other hand, I see no good reason for this document to disallow #1 si= nce it's allows by RFC4861.=C2=A0 There is a lot of basic router code t= hat doesn't implement #1, no one had to say anything more than what is = already in RFC4861 for that to be the case, why do you think anything more = needs to be said in this case?=C2=A0

Like I said;=C2=A0Maybe it should be noted that RFC7772 prefers the use of a Unicast R= A responses to reduce the energy consumption of RAs, however since this doc= ument requires that any Multicast RAs are sent as a Link-layer Unicast, a U= nicast RA responses is not necessary to reduce the energy consumption of RA= s.=C2=A0

Agreed on both = the interpretation of the RFCs. Also, this is not about energy consumption = - in both cases the packets are unicast at layer 2, so there is no differen= ce in power.

My comment is regarding simplicity of= router implementation. Ideally, anyone implementing this RFC would realize= that #2 has to be done regardless (for periodic RAs) and that #1 is option= al. If they then decide to implement #1 as well, that's fine.

Unfortunately I'm not sure the text is clear enough for= that. Specifically I worry that implementers won't realize that #2 is = mandatory, implement #1 first, and then implement periodic RAs with somethi= ng hacky like "cache the last-seen link-local address, and always send= unicast RAs to that address".

Ok, maybe by discussing the unicast RA fist, there c= ould be some unintended emphasis put on that option, how about a minor rear= rangement of the paragraph, adding that unsolicited RAs are always multicas= t, and adding the few editorial nits I mentioned earlier for the following = paragraph;

When the First Hop Provider Router sends a solicited RA resp= onse, or periodically sends unsolicited RAs, the RA MUST be sent only to th= e subscriber that has been assigned the Unique IPv6 prefix contained in the= RA. This is achieved by sending a multicast RA response or unsolicited RAs= to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6, = but instead of using the link-layer multicast address associated with the a= ll-nodes group, the link-layer unicast address of the subscriber that has b= een assigned the Unique IPv6 prefix contained in the RA MUST be used as the= link-layer destination RFC6085 [RFC6085].=C2=A0 Or, optionally in some cas= es, a unicast RA response could be sent as detailed in [RFC4861] section 6.= 2.6, nevertheless unsolicited RAs are always sent to the all-nodes group.
The RA contains two important parameters for the subscriber to consum= e: ...

I think that removes any uninte= nded emphasis the unicast RA option, while at the same time putting a littl= e more emphasis on the multicast RA option.

What do you think?

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & = Telecommunication Services
Office of Information Technology
Universit= y of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cel= l: 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
--089e08274d582855b905593b612d-- From nobody Fri Sep 15 10:01:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B56133058 for ; Fri, 15 Sep 2017 10:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vmcne_iZxIiK for ; Fri, 15 Sep 2017 10:01:25 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D196133039 for ; Fri, 15 Sep 2017 10:01:25 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id j16so1853770pga.1 for ; Fri, 15 Sep 2017 10:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=E6wBGLhGZfR4wZ1OP+aDsCzzpj4yAmE99Pm2ZYVjEJE=; b=RPKQ0vwN7+X5KjCS0KwSdJC3YSk/Y2nDhvopAqdvOAdQdazcpzZjr8MOa4/Dm8ba54 WVwyBaxbJyboflY/z6q8EdhHoMaOzxWEeDq81DvAqxuhO164no3jOX9D5mAnbw0ROaXw HpJwdZLaJp5w8ZNna8F47hYqbRmE/luxos53Fki9PvLRfyqOVYa7PcIBa04lTpd8zE5M 9C/yds7B7jgxocOSgKLMQjVIU7GhzZF4O0uZW2JZNx8I0OuYqF1SDJKEEhEKZLI8jJJ+ Pc2ZZ8Zsb8nzMvUw4A81ZVi7u/jbNhL+MhIzGZNtgAV9z8wFQCF+C7pLdAWSz7RRWeZn mXvQ== 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=E6wBGLhGZfR4wZ1OP+aDsCzzpj4yAmE99Pm2ZYVjEJE=; b=sdEu1YxDUBNic1QOtsFO9yUrn1piRkbOVur63s4JwF/WJ3yjgLvQWFWF+dO3XYgT/4 qd02ACzKNEJlfVacbpq53qzF+a2YfSLb4sO2hERvadPlK2HpORe5ro6Mo0/pqus8kjl+ BFbhm+1xSGCbFlgIelvFA8YoDgDc70coemuzx51AfpikHyX7/j0cfKlaLuZgzOUESd/M 5yRKIuMSNMsuZkbCRsobwlIbtM8tOxJRG4sCpoTQBuj6oAyvKodll9Je12cmCRCXV9kM GVZyLYI9o73ytIdKuvwjQQ2H//dDMT7XVPm8GlZAR7syCp/Vzl5ZtRLQkUuSq5Q1KI+7 omkw== X-Gm-Message-State: AHPjjUhkdF2y+3Ht+1SWJta/xPu4YgiOBcUF0UStM/U33QHxh53vApsH wsC9v2GblLc4Roer X-Google-Smtp-Source: ADKCNb4+wr393UDMrzDfjTFqgPWPrMUaF5AJvvS9r36YUCz5GwsX9L6udN5pf4MVtm9ns8uQJ5RP0A== X-Received: by 10.98.204.69 with SMTP id a66mr25717723pfg.132.1505494882597; Fri, 15 Sep 2017 10:01:22 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:6819:7ca7:6d94:acd8? ([2620:0:10e7:10:6819:7ca7:6d94:acd8]) by smtp.gmail.com with ESMTPSA id g66sm2884633pgc.36.2017.09.15.10.01.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Sep 2017 10:01:21 -0700 (PDT) From: james woodyatt Message-Id: <726C5F27-DA9E-42B6-9CDB-051A041BE53F@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_08082776-BD25-458A-B8FB-6C84A74156AA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 15 Sep 2017 10:01:20 -0700 In-Reply-To: <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> Cc: "v6ops@ietf.org" To: "Templin, Fred L" References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:01:26 -0000 --Apple-Mail=_08082776-BD25-458A-B8FB-6C84A74156AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 15, 2017, at 07:34, Templin, Fred L = wrote: >=20 > That means that the router needs to consider the prefix as on-link and = perform address resolution for each > destination address covered by the prefix. I think it suffices to say that the router sends ICMP errors destined = for addresses in the Host Unique Prefix to the link-layer address of the = host in the same way that multicast RA messages are sent to the = link-layer unicast address of the host. No address resolution necessary. --james woodyatt > --Apple-Mail=_08082776-BD25-458A-B8FB-6C84A74156AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Sep 15, 2017, at 07:34, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:

That means that the = router needs to consider the prefix as on-link and = perform address resolution for each
destination address = covered by the prefix.

I think it suffices to say that the = router sends ICMP errors destined for addresses in the Host Unique = Prefix to the link-layer address of the host in the same way that = multicast RA messages are sent to the link-layer unicast address of the = host. No address resolution necessary.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_08082776-BD25-458A-B8FB-6C84A74156AA-- From nobody Fri Sep 15 10:04:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EBD13305B for ; Fri, 15 Sep 2017 10:04:36 -0700 (PDT) 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_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 0_o4Jmn1flzT for ; Fri, 15 Sep 2017 10:04:34 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1749133044 for ; Fri, 15 Sep 2017 10:04:34 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 4AA09B72 for ; Fri, 15 Sep 2017 17:04:34 +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 dT5uRCG0dqpB for ; Fri, 15 Sep 2017 12:04:34 -0500 (CDT) Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id CFE20B55 for ; Fri, 15 Sep 2017 12:04:33 -0500 (CDT) Received: by mail-lf0-f70.google.com with SMTP id y15so2290321lfd.6 for ; Fri, 15 Sep 2017 10:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B2GVJcD/b12U4hzRndQx/bNzLG0cf7Mt/7XQsuOJOKs=; b=I1TVrNaeIzki64yJdBeqcEbxNLEVkw1YR69dhFmfy64Vh7r+qhdLV2L7XCGLP2It2T DuGhczKBPPuM5BWNXW5u9ZM6HUOKd09Xk3B3Hix3qOaNwOJn3MDYL6RtiNlUFX3LWqAv NX8pwJaa+4prjQmnfhkaxYXi5SxiJ27qW9B9UjNod+icR+3kEbvmfkD+LCuP7V9XHVon QnlXNKzbUeS3rkvQ9LuGMpNn5q7i2Vxx5/5R+hskQp9VN1Y69dhxbNLsyRfkZ+kn0sv5 DSrQ+nD4E81g1BO1jkhzcgCZ/5acdJsr2TNKYv95i//WRJlY0Cdu6lmtzmWDzcSb/ZaJ QtWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B2GVJcD/b12U4hzRndQx/bNzLG0cf7Mt/7XQsuOJOKs=; b=F3uruE4H2T69XBEhDQ/1t6dV3GzfHj1INrRJICaXWOO3V9sZNn9R4gam1i0sS7VfyP ug/i28MbGd5Ei811SOMdFW9Zmbm3y+1GJVdoan0rgX0/YYBCaa7r6lECpvLs6AVXux/c o2kt8QUILQ6vu6R3ZuPzJxvVLMT16D16aA0/Ur0gbFADbAKH2wamRSFOCwL9Q5d3/J2y NMbndxpx9vo+vKX+Tpfh6kfWxUPW1MFQ7QAo+Z1K7SXcH9F9gHsFtNWCc+ZTBVjH0ui9 yE7Rd+SBA3U9Yne3KeTmcHGddtHYw9QFEK4vUPV+wms71NIUwM3ouSFdNPY2YJpOd35G Zvjg== X-Gm-Message-State: AHPjjUhnjZasP9Rgk6cnMSZGSMEwcwX+rCIUincEUFsIeigd70p4nm+l 1L1iwmsupxAB49t9DW4agee9w7Jvso9GmF+gQsKRb0bZC18cVwWz6zV7jgUhSEY3K1JAorw6VRv sHz9Dd0cAFASC3dCo28VTz6+2Og== X-Received: by 10.25.147.142 with SMTP id w14mr1085594lfk.32.1505495072390; Fri, 15 Sep 2017 10:04:32 -0700 (PDT) X-Google-Smtp-Source: AOwi7QDIxFQaCaQByUXR3gU0NJ1O2GSR6x4jIz/fMN+eoFgFHcOoyesHEHerh9eyiEJZB/zcPfAdki2pCw4R1OHtY2w= X-Received: by 10.25.147.142 with SMTP id w14mr1085586lfk.32.1505495072155; Fri, 15 Sep 2017 10:04:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Fri, 15 Sep 2017 10:04:31 -0700 (PDT) In-Reply-To: <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Fri, 15 Sep 2017 12:04:31 -0500 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="f403045f4cbcfcb78005593d6280" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:04:36 -0000 --f403045f4cbcfcb78005593d6280 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 9:34 AM, Templin, Fred L wrote: > I am OK with the changes, but there is still something missing. The router > needs to > be able to send ICMPv6 Destination Unreachables for IPv6 destination > addresses > that do not match one of the host's current addresses. That means that the > router > needs to consider the prefix as on-link and perform address resolution for > each > destination address covered by the prefix. > > The document should mention this, because it is currently silent on how > routers > regard PIOs with A=1;L=0. > > This is also an important distinction between what this document recommends > and true prefix delegation. > RFC4443 section 3.1 simply says "a Destination Unreachable message SHOULD be generated by a router, or by the IPv6 layer in the originating node, in response to a packet that cannot be delivered to its destination address for reasons other than congestion." Therefore Destination Unreachable messages are not REQUIRED, and the whole motivation of this draft is to not to do neighbor discovery on the unique prefix assigned to each host. I believe per RFC2119, that is sufficient reason to ignore this particular SHOULD. So at most it might be worth noting someplace in the draft, as the actual addresses that are used by each host within it's unique prefix are not intended to be tracked by the first hop router, the first hop router will not be able to generate Destination Unreachable messages, RECOMMENDED in RFC4443 section 3.1, for the unused addresses within each unique prefix. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f403045f4cbcfcb78005593d6280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 15, 2017 at 9:34 AM, Templin, Fred L <= Fred.L.Templ= in@boeing.com> wrote:
I am OK with the changes, but there is still something missin= g. The router needs to
be able to send ICMPv6 Destination Unreachables for IPv6 destination addres= ses
that do not match one of the host's current addresses. That means that = the router
needs to consider the prefix as on-link and perform address resolution for = each
destination address covered by the prefix.

The document should mention this, because it is currently silent on how rou= ters
regard PIOs with A=3D1;L=3D0.

This is also an important distinction between what this document recommends=
and true prefix delegation.

RFC4443 sec= tion 3.1 simply says "a Destination Unreachable message SHOULD be gene= rated by a router, or by the IPv6 layer in the originating node, in respons= e to a packet that cannot be delivered to its destination address for reaso= ns other than congestion."

Therefore Destinat= ion Unreachable messages=C2=A0are not REQUIRED, and the whole motivation of= this draft is to not to do neighbor discovery on the unique prefix assigne= d to each host.=C2=A0 I believe per RFC2119, that is sufficient reason to i= gnore this particular SHOULD.=C2=A0 So at most it might be worth noting som= eplace in the draft, as the actual addresses that are used by each host wit= hin it's unique prefix are not intended to be tracked by the first hop = router, the first hop router will not be able to generate Destination Unrea= chable messages, RECOMMENDED in RFC4443 section 3.1,=C2=A0for the unused ad= dresses within each unique prefix.
=C2=A0=C2=A0
Thanks.=

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0 Em= ail:farmer@umn.edu
Networking & Telecommunication Services
Of= fice of Information Technology
University of Minnesota=C2=A0=C2=A0
2= 218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
= Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403045f4cbcfcb78005593d6280-- From nobody Fri Sep 15 10:15:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD523133391 for ; Fri, 15 Sep 2017 10:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vIghtZP5_XSj for ; Fri, 15 Sep 2017 10:15:43 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA79133050 for ; Fri, 15 Sep 2017 10:15:43 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id g142so1884116ita.0 for ; Fri, 15 Sep 2017 10:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UwgCQxpVuqG9c+lUGxy+oZs7bTsdV/9oZmCdbWhko14=; b=mKCn2NDZiS+w+YrvTxQ6a8cDuPhaK5z1pavhH/DAaZwZY47IEXkiRca55mzCs3xG2/ y2eCtMpg/xeDtWD9cEFk3yyBvVPMoi8kJx5XiUkeSvFqfHmeptt2+EKikBZlpiLt1Iog PsK8M39jRF9CWZvtzCUdh0xH8spFUqmVIZg71SNPqxOO4rqXDJo2n0zArMLB0XwLGvxe pfOtyEVu6q+5ElLUOskzERt9djseTSecCbyl/Rocj6ENM2CtQ2KqwfTTpbeQZcNsZc0+ j11mepeVa3UP/gWK2yY1Vf830zTd1ifK+l8jik9bUhKOt2CPYLoM8s1Qf6rYsyNeeRsX WTsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UwgCQxpVuqG9c+lUGxy+oZs7bTsdV/9oZmCdbWhko14=; b=ltCcBL1Bwfv26XK5MdFie1eXsKGh0V2qWk0uaRIn9nTNKIfnzw4bN1zQ70rXe2tdL2 3Z++s6/RZ29mm+dOqwDBNiBNbeKJlwVZvungaNgBlCfCYTOZzFiVNWqwWRfE8WP+K7O0 WwUwZDlVG1A+Brf3sN6fGmjUvI+GtmEV5jVuZcj9Bit+YFA9EBL63px8wu9HcQ2qfyyD 3fC6bbeKBrxCD/tKK4sFOYx/0ljwb1UM+nRhPLXLnv00V7EsJFsXTjLthSp/xzd0OMqY bC7hb1XXAUYutm0zcHAmKEwRSqG4sBNqdVUDIAabWAkYoOv9ptiRVxOmBY0IZlmFdOvE bWBA== X-Gm-Message-State: AHPjjUgTKWSt7uSHGqZ9NGPBMhcF8XDu4Y+3Zi3WtRr/2JBXpP1GBFF0 Ao2YokLZ0dzBb7r8OLsxV6X1u5mUNxWGGxOZyV25DQ== X-Google-Smtp-Source: AOwi7QB0sIDa6XIBRdDAWt+WBwmwsNU+sEWQr8Nd+QzOetaWhT2Mci7tVW+3CZnDkO/ErIIX626tJG9VlUvUYa5UWxY= X-Received: by 10.36.200.132 with SMTP id w126mr6696306itf.101.1505495742151; Fri, 15 Sep 2017 10:15:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Fri, 15 Sep 2017 10:15:21 -0700 (PDT) In-Reply-To: <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Fri, 15 Sep 2017 10:15:21 -0700 Message-ID: To: "Templin, Fred L" Cc: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c060256ecbfc605593d8a68" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:15:45 -0000 --94eb2c060256ecbfc605593d8a68 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 7:34 AM, Templin, Fred L wrote: > I am OK with the changes, but there is still something missing. The router > needs to > be able to send ICMPv6 Destination Unreachables for IPv6 destination > addresses > that do not match one of the host's current addresses. I disagree. That prefix belongs to the host. If the host wishes to send unreachables, then it can choose to do so. If not, it can choose not to do so. Additionally, one of the desirable properties of this scheme is that the router does not need to store all host addresses in its ND cache. That simplifies implementation and protects from a number of state exhaustion attacks. --94eb2c060256ecbfc605593d8a68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 15, 2017 at 7:34 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:
I am OK with= the changes, but there is still something missing. The router needs to
be able to send ICMPv6 Destination Unreachables for IPv6 destination addres= ses
that do not match one of the host's current addresses.

I disagree. That prefix belongs to the host. If the host wi= shes to send unreachables, then it can choose to do so. If not, it can choo= se not to do so. Additionally, one of the desirable properties of this sche= me is that the router does not need to store all host addresses in its ND c= ache. That simplifies implementation and protects from a number of state ex= haustion attacks.
--94eb2c060256ecbfc605593d8a68-- From nobody Fri Sep 15 10:16:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044CB13305B for ; Fri, 15 Sep 2017 10:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 toVmON9NOO3J for ; Fri, 15 Sep 2017 10:16:26 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA65133039 for ; Fri, 15 Sep 2017 10:16:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8FHGPiZ063133; Fri, 15 Sep 2017 10:16:25 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8FHGFNN063050 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Sep 2017 10:16:15 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Sep 2017 10:16:14 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 15 Sep 2017 10:16:14 -0700 From: "Templin, Fred L" To: David Farmer CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0R353fXvPDrEeoXyoh+k1EZqK2AYpwgACiGYD//4u/sA== Date: Fri, 15 Sep 2017 17:16:14 +0000 Message-ID: <289746642fb745ad819c71a02ef4cb22@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_289746642fb745ad819c71a02ef4cb22XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:16:28 -0000 --_000_289746642fb745ad819c71a02ef4cb22XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNClRoYW5rcyBmb3IgdGhlIGluc2lnaHRzLCBhbmQgc2VlIGJlbG93IGZvciBm b2xsb3ctdXBzOg0KDQpGcmVkDQoNCkZyb206IERhdmlkIEZhcm1lciBbbWFpbHRvOmZhcm1lckB1 bW4uZWR1XQ0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMTcgMTA6MDUgQU0NClRvOiBU ZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogdjZvcHNAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMt dW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA5LnR4dA0KDQoNCg0KT24gRnJpLCBTZXAgMTUs IDIwMTcgYXQgOTozNCBBTSwgVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQpJIGFtIE9LIHdp dGggdGhlIGNoYW5nZXMsIGJ1dCB0aGVyZSBpcyBzdGlsbCBzb21ldGhpbmcgbWlzc2luZy4gVGhl IHJvdXRlciBuZWVkcyB0bw0KYmUgYWJsZSB0byBzZW5kIElDTVB2NiBEZXN0aW5hdGlvbiBVbnJl YWNoYWJsZXMgZm9yIElQdjYgZGVzdGluYXRpb24gYWRkcmVzc2VzDQp0aGF0IGRvIG5vdCBtYXRj aCBvbmUgb2YgdGhlIGhvc3QncyBjdXJyZW50IGFkZHJlc3Nlcy4gVGhhdCBtZWFucyB0aGF0IHRo ZSByb3V0ZXINCm5lZWRzIHRvIGNvbnNpZGVyIHRoZSBwcmVmaXggYXMgb24tbGluayBhbmQgcGVy Zm9ybSBhZGRyZXNzIHJlc29sdXRpb24gZm9yIGVhY2gNCmRlc3RpbmF0aW9uIGFkZHJlc3MgY292 ZXJlZCBieSB0aGUgcHJlZml4Lg0KDQpUaGUgZG9jdW1lbnQgc2hvdWxkIG1lbnRpb24gdGhpcywg YmVjYXVzZSBpdCBpcyBjdXJyZW50bHkgc2lsZW50IG9uIGhvdyByb3V0ZXJzDQpyZWdhcmQgUElP cyB3aXRoIEE9MTtMPTAuDQoNClRoaXMgaXMgYWxzbyBhbiBpbXBvcnRhbnQgZGlzdGluY3Rpb24g YmV0d2VlbiB3aGF0IHRoaXMgZG9jdW1lbnQgcmVjb21tZW5kcw0KYW5kIHRydWUgcHJlZml4IGRl bGVnYXRpb24uDQoNClJGQzQ0NDMgc2VjdGlvbiAzLjEgc2ltcGx5IHNheXMgImEgRGVzdGluYXRp b24gVW5yZWFjaGFibGUgbWVzc2FnZSBTSE9VTEQgYmUgZ2VuZXJhdGVkIGJ5IGEgcm91dGVyLCBv ciBieSB0aGUgSVB2NiBsYXllciBpbiB0aGUgb3JpZ2luYXRpbmcgbm9kZSwgaW4gcmVzcG9uc2Ug dG8gYSBwYWNrZXQgdGhhdCBjYW5ub3QgYmUgZGVsaXZlcmVkIHRvIGl0cyBkZXN0aW5hdGlvbiBh ZGRyZXNzIGZvciByZWFzb25zIG90aGVyIHRoYW4gY29uZ2VzdGlvbi4iDQoNCg0Kw5ggICAgVGhh dCBpcyByaWdodC4gSXQgaXMgYSBTSE9VTEQuIEJ1dCBpbiB0aGlzIGNhc2UsIEkgdGhpbmsgaXQg aXMgYSBzdHJvbmcgU0hPVUxELg0KDQpUaGVyZWZvcmUgRGVzdGluYXRpb24gVW5yZWFjaGFibGUg bWVzc2FnZXMgYXJlIG5vdCBSRVFVSVJFRCwgYW5kIHRoZSB3aG9sZSBtb3RpdmF0aW9uIG9mIHRo aXMgZHJhZnQgaXMgdG8gbm90IHRvIGRvIG5laWdoYm9yIGRpc2NvdmVyeSBvbiB0aGUgdW5pcXVl IHByZWZpeCBhc3NpZ25lZCB0byBlYWNoIGhvc3QuDQoNCg0Kw5ggIExldOKAmXMgYXNzdW1lIHRo ZSBwcmVmaXggaXMgMjAwMTpkYjg6Oi82NC4gV2hhdCBpZiB0aGUgaG9zdCBvbmx5IGNvbmZpZ3Vy ZXMgdGhlDQoNCsOYICBhZGRyZXNzIDIwMDE6ZGI4OjpmMDAsIGFuZCB0aGUgcm91dGVyIHJlY2Vp dmVzIGFuIElQdjYgcGFja2V0IHdpdGggZGVzdGluYXRpb24NCg0Kw5ggIDIwMDE6ZGI4OjpiYWEu IFNob3VsZCB0aGUgcm91dGVyIHNlbmQgdGhlIHBhY2tldCB0byB0aGUgaG9zdCwgd2hpY2ggd2ls bCBkcm9wDQoNCsOYICBpdCBzaWxlbnRseT8gVGhlbiwgd2hhdCBpZiB0aGVyZSBpcyBhIGZsb29k IG9mIHBhY2tldHMgd2l0aCBJUHY2IGRlc3RpbmF0aW9uDQoNCsOYICBhZGRyZXNzIDIwMDE6ZGI4 OjoqPyBTaG91bGQgdGhlIHJvdXRlciBzZW5kIGFsbCBvZiB0aGVtIHRvIHRoZSBob3N0PyBJDQoN CsOYICBkb27igJl0IHRoaW5rIHNvLiBJbnN0ZWFkLCB0aGUgcm91dGVyIFNIT1VMRCBwZXJmb3Jt IGFkZHJlc3MgcmVzb2x1dGlvbg0KDQrDmCAgYW5kIGRyb3AgYW55IHBhY2tldHMgZm9yIHdoaWNo IGFkZHJlc3MgcmVzb2x1dGlvbiBmYWlscyBhbmQgdGhlbiBTSE9VTEQNCg0Kw5ggIHJldHVybiBh IERlc3RpbmF0aW9uIFVucmVhY2hhYmxlLg0KSSBiZWxpZXZlIHBlciBSRkMyMTE5LCB0aGF0IGlz IHN1ZmZpY2llbnQgcmVhc29uIHRvIGlnbm9yZSB0aGlzIHBhcnRpY3VsYXIgU0hPVUxELiAgU28g YXQgbW9zdCBpdCBtaWdodCBiZSB3b3J0aCBub3Rpbmcgc29tZXBsYWNlIGluIHRoZSBkcmFmdCwg YXMgdGhlIGFjdHVhbCBhZGRyZXNzZXMgdGhhdCBhcmUgdXNlZCBieSBlYWNoIGhvc3Qgd2l0aGlu IGl0J3MgdW5pcXVlIHByZWZpeCBhcmUgbm90IGludGVuZGVkIHRvIGJlIHRyYWNrZWQgYnkgdGhl IGZpcnN0IGhvcCByb3V0ZXIsIHRoZSBmaXJzdCBob3Agcm91dGVyIHdpbGwgbm90IGJlIGFibGUg dG8gZ2VuZXJhdGUgRGVzdGluYXRpb24gVW5yZWFjaGFibGUgbWVzc2FnZXMsIFJFQ09NTUVOREVE IGluIFJGQzQ0NDMgc2VjdGlvbiAzLjEsIGZvciB0aGUgdW51c2VkIGFkZHJlc3NlcyB3aXRoaW4g ZWFjaCB1bmlxdWUgcHJlZml4Lg0KDQoNCsOYICAgIFNlZSBhYm92ZS4gSSBkb27igJl0IHRoaW5r IHRoZSBmbG9vZCBvZiBwYWNrZXRzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBob3N0LiBJIHRoaW5r DQoNCsOYICAgIHRoZSByb3V0ZXIgc2hvdWxkIHBlcmZvcm0gYWRkcmVzcyByZXNvbHV0aW9uLCBh bmQgZHJvcCBhbmQgc2VuZCBEVXMgcGVyIHRoZQ0KDQrDmCAgICBSRkM0NDQzIFNIT1VMRC4NCg0K VGhhbmtzLg0KDQotLQ0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCkRhdmlkIEZhcm1lciAgICAgICAgICAgICAgIEVtYWlsOmZhcm1lckB1bW4uZWR1PG1h aWx0bzpFbWFpbCUzQWZhcm1lckB1bW4uZWR1Pg0KTmV0d29ya2luZyAmIFRlbGVjb21tdW5pY2F0 aW9uIFNlcnZpY2VzDQpPZmZpY2Ugb2YgSW5mb3JtYXRpb24gVGVjaG5vbG9neQ0KVW5pdmVyc2l0 eSBvZiBNaW5uZXNvdGENCjIyMTggVW5pdmVyc2l0eSBBdmUgU0UgICAgICAgIFBob25lOiA2MTIt NjI2LTA4MTU8dGVsOig2MTIpJTIwNjI2LTA4MTU+DQpNaW5uZWFwb2xpcywgTU4gNTU0MTQtMzAy OSAgIENlbGw6IDYxMi04MTItOTk1Mjx0ZWw6KDYxMiklMjA4MTItOTk1Mj4NCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo= --_000_289746642fb745ad819c71a02ef4cb22XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1NDAzNjUyMzk7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjMzOTkwMDg4MCAxMjM1MTMyMjMy IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OY Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBEYXZpZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGluc2lnaHRzLCBhbmQgc2VlIGJlbG93 IGZvciBmb2xsb3ctdXBzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+RnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IERhdmlkIEZhcm1lciBbbWFpbHRvOmZhcm1lckB1bW4uZWR1XQ0K PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgU2VwdGVtYmVyIDE1LCAyMDE3IDEwOjA1IEFNPGJy Pg0KPGI+VG86PC9iPiBUZW1wbGluLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXBy ZWZpeC1wZXItaG9zdC0wOS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgOTozNCBBTSwgVGVtcGxpbiwgRnJlZCBMICZs dDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIE9LIHdpdGggdGhlIGNo YW5nZXMsIGJ1dCB0aGVyZSBpcyBzdGlsbCBzb21ldGhpbmcgbWlzc2luZy4gVGhlIHJvdXRlciBu ZWVkcyB0bzxicj4NCmJlIGFibGUgdG8gc2VuZCBJQ01QdjYgRGVzdGluYXRpb24gVW5yZWFjaGFi bGVzIGZvciBJUHY2IGRlc3RpbmF0aW9uIGFkZHJlc3Nlczxicj4NCnRoYXQgZG8gbm90IG1hdGNo IG9uZSBvZiB0aGUgaG9zdCdzIGN1cnJlbnQgYWRkcmVzc2VzLiBUaGF0IG1lYW5zIHRoYXQgdGhl IHJvdXRlcjxicj4NCm5lZWRzIHRvIGNvbnNpZGVyIHRoZSBwcmVmaXggYXMgb24tbGluayBhbmQg cGVyZm9ybSBhZGRyZXNzIHJlc29sdXRpb24gZm9yIGVhY2g8YnI+DQpkZXN0aW5hdGlvbiBhZGRy ZXNzIGNvdmVyZWQgYnkgdGhlIHByZWZpeC48YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnQgc2hvdWxk IG1lbnRpb24gdGhpcywgYmVjYXVzZSBpdCBpcyBjdXJyZW50bHkgc2lsZW50IG9uIGhvdyByb3V0 ZXJzPGJyPg0KcmVnYXJkIFBJT3Mgd2l0aCBBPTE7TD0wLjxicj4NCjxicj4NClRoaXMgaXMgYWxz byBhbiBpbXBvcnRhbnQgZGlzdGluY3Rpb24gYmV0d2VlbiB3aGF0IHRoaXMgZG9jdW1lbnQgcmVj b21tZW5kczxicj4NCmFuZCB0cnVlIHByZWZpeCBkZWxlZ2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UkZDNDQ0MyBzZWN0 aW9uIDMuMSBzaW1wbHkgc2F5cyAmcXVvdDthIERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIG1lc3Nh Z2UgU0hPVUxEIGJlIGdlbmVyYXRlZCBieSBhIHJvdXRlciwgb3IgYnkgdGhlIElQdjYgbGF5ZXIg aW4gdGhlIG9yaWdpbmF0aW5nIG5vZGUsIGluIHJlc3BvbnNlIHRvIGEgcGFja2V0IHRoYXQgY2Fu bm90IGJlIGRlbGl2ZXJlZCB0byBpdHMgZGVzdGluYXRpb24gYWRkcmVzcyBmb3IgcmVhc29ucyBv dGhlcg0KIHRoYW4gY29uZ2VzdGlvbi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOY PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhdCBpcyByaWdodC4gSXQgaXMgYSBTSE9VTEQuIEJ1dCBp biB0aGlzIGNhc2UsIEkgdGhpbmsgaXQgaXMgYSBzdHJvbmcgU0hPVUxELjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmVmb3Jl IERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIG1lc3NhZ2VzJm5ic3A7YXJlIG5vdCBSRVFVSVJFRCwg YW5kIHRoZSB3aG9sZSBtb3RpdmF0aW9uIG9mIHRoaXMgZHJhZnQgaXMgdG8gbm90IHRvIGRvIG5l aWdoYm9yIGRpc2NvdmVyeSBvbiB0aGUgdW5pcXVlIHByZWZpeCBhc3NpZ25lZCB0byBlYWNoIGhv c3QuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rp bmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+TGV04oCZcyBhc3N1bWUgdGhlIHByZWZpeCBpcyAyMDAxOmRiODo6LzY0LiBXaGF0IGlmIHRo ZSBob3N0IG9ubHkgY29uZmlndXJlcyB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQxLjI1cHQ7dGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFkZHJl c3MgMjAwMTpkYjg6OmYwMCwgYW5kIHRoZSByb3V0ZXIgcmVjZWl2ZXMgYW4gSVB2NiBwYWNrZXQg d2l0aCBkZXN0aW5hdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDEuMjVwdDt0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0Qi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MjAwMTpkYjg6OmJhYS4g U2hvdWxkIHRoZSByb3V0ZXIgc2VuZCB0aGUgcGFja2V0IHRvIHRoZSBob3N0LCB3aGljaCB3aWxs IGRyb3A8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjQxLjI1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPml0IHNpbGVudGx5PyBUaGVuLCB3aGF0IGlm IHRoZXJlIGlzIGEgZmxvb2Qgb2YgcGFja2V0cyB3aXRoIElQdjYgZGVzdGluYXRpb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjQxLjI1cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPmFkZHJlc3MgMjAwMTpkYjg6Oio/IFNob3VsZCB0aGUgcm91dGVy IHNlbmQgYWxsIG9mIHRoZW0gdG8gdGhlIGhvc3Q/IEk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQxLjI1cHQ7dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5n cztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PmRvbuKAmXQgdGhpbmsgc28uIEluc3RlYWQsIHRoZSByb3V0ZXIgU0hPVUxEIHBlcmZvcm0gYWRk cmVzcyByZXNvbHV0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo0MS4yNXB0O3RleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hbmQgZHJvcCBhbnkgcGFj a2V0cyBmb3Igd2hpY2ggYWRkcmVzcyByZXNvbHV0aW9uIGZhaWxzIGFuZCB0aGVuIFNIT1VMRDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6NDEuMjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+cmV0dXJuIGEgRGVzdGluYXRpb24gVW5yZWFjaGFibGUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgYmVsaWV2ZSBwZXIgUkZDMjExOSwgdGhhdCBpcyBzdWZmaWNpZW50IHJlYXNvbiB0 byBpZ25vcmUgdGhpcyBwYXJ0aWN1bGFyIFNIT1VMRC4mbmJzcDsgU28gYXQgbW9zdCBpdCBtaWdo dCBiZSB3b3J0aCBub3Rpbmcgc29tZXBsYWNlIGluIHRoZSBkcmFmdCwgYXMgdGhlIGFjdHVhbCBh ZGRyZXNzZXMgdGhhdCBhcmUgdXNlZCBieSBlYWNoIGhvc3Qgd2l0aGluIGl0J3MgdW5pcXVlIHBy ZWZpeCBhcmUgbm90IGludGVuZGVkDQogdG8gYmUgdHJhY2tlZCBieSB0aGUgZmlyc3QgaG9wIHJv dXRlciwgdGhlIGZpcnN0IGhvcCByb3V0ZXIgd2lsbCBub3QgYmUgYWJsZSB0byBnZW5lcmF0ZSBE ZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBtZXNzYWdlcywgUkVDT01NRU5ERUQgaW4gUkZDNDQ0MyBz ZWN0aW9uIDMuMSwmbmJzcDtmb3IgdGhlIHVudXNlZCBhZGRyZXNzZXMgd2l0aGluIGVhY2ggdW5p cXVlIHByZWZpeC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVu dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+U2VlIGFib3ZlLiBJIGRvbuKAmXQgdGhpbmsgdGhlIGZsb29kIG9mIHBhY2tldHMgc2hvdWxk IGJlIHNlbnQgdG8gdGhlIGhvc3QuIEkgdGhpbms8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVu dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+dGhlIHJvdXRlciBzaG91bGQgcGVyZm9ybSBhZGRyZXNzIHJlc29sdXRpb24sIGFuZCBkcm9w IGFuZCBzZW5kIERVcyBwZXIgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJGQzQ0 NDMgU0hPVUxELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08YnI+DQpEYXZpZCBGYXJtZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkVtYWlsJTNBZmFybWVyQHVt bi5lZHUiIHRhcmdldD0iX2JsYW5rIj4NCkVtYWlsOmZhcm1lckB1bW4uZWR1PC9hPjxicj4NCk5l dHdvcmtpbmcgJmFtcDsgVGVsZWNvbW11bmljYXRpb24gU2VydmljZXM8YnI+DQpPZmZpY2Ugb2Yg SW5mb3JtYXRpb24gVGVjaG5vbG9neTxicj4NClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhJm5ic3A7 Jm5ic3A7IDxicj4NCjIyMTggVW5pdmVyc2l0eSBBdmUgU0UmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgUGhvbmU6IDxhIGhyZWY9InRlbDooNjEyKSUyMDYyNi0wODE1IiB0YXJnZXQ9Il9ibGFu ayI+DQo2MTItNjI2LTA4MTU8L2E+PGJyPg0KTWlubmVhcG9saXMsIE1OIDU1NDE0LTMwMjkmbmJz cDsmbmJzcDsgQ2VsbDogPGEgaHJlZj0idGVsOig2MTIpJTIwODEyLTk5NTIiIHRhcmdldD0iX2Js YW5rIj4NCjYxMi04MTItOTk1MjwvYT48YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_289746642fb745ad819c71a02ef4cb22XCH150608nwnosboeingcom_-- From nobody Fri Sep 15 10:18:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A163A13352D for ; Fri, 15 Sep 2017 10:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jlhXco7mRftv for ; Fri, 15 Sep 2017 10:18:56 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE5713344F for ; Fri, 15 Sep 2017 10:18:56 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id i6so1832729ywc.9 for ; Fri, 15 Sep 2017 10:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=06VmdoXThs7YHYtRtcbcpONDt60KDLsHliXgMvPyiKM=; b=DEH5NVF4bKFxqdVwz/jX/S3C1UPNWK6Zwd+PzUPGA0HUzCwnIY23eIfK15lFNCUb+q E8dxhsSjnId13aq6Vvr88GACNCn4CFHORAIUWyaiYdrVtKKiVK7Le1Tq/RQh7IHX6Xff nMA1r5ESFP2ZpFIeUxRaPEs+HW7JiPkj6S8KoX6hgt9ntPNnpCvFYRJsH0wG1vinm9cp m34rKYAoolUrWwamp47a3V652fck1FU9Q2H49qoRnlX0fx93dBEVzvl0rWYVW03yYj05 RmBlGwdwhlzM9pVxfMj5LrZH6J5Lz9rcZuxBMQ+Hvxg1KMfqu3h/FIvbQP1clT8jrozw GzKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=06VmdoXThs7YHYtRtcbcpONDt60KDLsHliXgMvPyiKM=; b=cgniktQo8smk+GQOHYurxMgxps4rOWMVyZRVrOC98RyVMacHlp5zejNBWpnbhm9Q0s WGD81imJ5ZrJOvutO07L4V4HoGuIqQYQShD9zN5vMvbd4gPdo3kWQx+iUI8JTUObYdjD O/fEECT+ZXe2WYyAq5b0Piy4L1EjnMr1t2yfyc/JNyY7SrCiDzhcG55B3Xn+zxPKc4zl +fbNvx83mc3UNYmpb7Tj7uMiG0MIaJwlgbThaJEn6A4b4d4H5KTZLN/OeVx7u+Z6mKHo kA8rB5tlFJbJjvUIWqKxbJYqk2ch9lr9pN+jJ8UTZV0OI2dncbDCed60Tv6GAo6KCVVQ Kt8w== X-Gm-Message-State: AHPjjUi3m9x591gHJvzCWd9+ovgGedHcctwzUei7BSFKI/bhvNivipyF lnKYb21MFaLFY3fBImGudHw+sfLlOH9CKVlQ9LzOtiXg X-Google-Smtp-Source: AOwi7QAUAKFcu23RDHoUFHwkXbfXUM4321D24JpnEKMv23V0xkhNgEEHEk7xknCzBm2ewltOimT//zpcMhKEMHZHEOY= X-Received: by 10.37.36.141 with SMTP id k135mr7615968ybk.259.1505495935211; Fri, 15 Sep 2017 10:18:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Fri, 15 Sep 2017 10:18:34 -0700 (PDT) In-Reply-To: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: Lorenzo Colitti Date: Fri, 15 Sep 2017 10:18:34 -0700 Message-ID: To: David Farmer Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a113ce3c86e7ab205593d965e" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:18:57 -0000 --001a113ce3c86e7ab205593d965e Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 7:40 AM, David Farmer wrote: > > > When the First Hop Provider Router sends a solicited RA response, or > periodically sends unsolicited RAs, the RA MUST be sent only to the > subscriber that has been assigned the Unique IPv6 prefix contained in the > RA. This is achieved by sending a multicast RA response or unsolicited RAs > to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6, > but instead of using the link-layer multicast address associated with the > all-nodes group, the link-layer unicast address of the subscriber that has > been assigned the Unique IPv6 prefix contained in the RA MUST be used as > the link-layer destination RFC6085 [RFC6085]. Or, optionally in some > cases, a unicast RA response could be sent as detailed in [RFC4861] section > 6.2.6, nevertheless unsolicited RAs are always sent to the all-nodes group. > > That would help, yes. I would replace "unicast RA response" with "solicited RAs" but otherwise LGTM. --001a113ce3c86e7ab205593d965e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 15, 2017 at 7:40 AM, David Farmer <farmer@umn.edu> wrot= e:

When the First Hop Provide= r Router sends a solicited RA response, or periodically sends unsolicited R= As, the RA MUST be sent only to the subscriber that has been assigned the U= nique IPv6 prefix contained in the RA. This is achieved by sending a multic= ast RA response or unsolicited RAs to the all-nodes group, as detailed in [= RFC4861] section 6.2.4 and 6.2.6, but instead of using the link-layer multi= cast address associated with the all-nodes group, the link-layer unicast ad= dress of the subscriber that has been assigned the Unique IPv6 prefix conta= ined in the RA MUST be used as the link-layer destination RFC6085 [RFC6085]= .=C2=A0 Or, optionally in some cases, a unicast RA response could be sent a= s detailed in [RFC4861] section 6.2.6, nevertheless unsolicited RAs are alw= ays sent to the all-nodes group.

That would help, yes. I would replace "unicast RA response&qu= ot; with "solicited RAs" but otherwise LGTM.
--001a113ce3c86e7ab205593d965e-- From nobody Fri Sep 15 10:19:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD8E132FA7; Fri, 15 Sep 2017 10:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 E86oZ8JQBlum; Fri, 15 Sep 2017 10:19:46 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F39E132949; Fri, 15 Sep 2017 10:19:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8FHJjXR002618; Fri, 15 Sep 2017 10:19:45 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8FHJYVr002480 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Sep 2017 10:19:34 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Sep 2017 10:19:33 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 15 Sep 2017 10:19:33 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0R353fXvPDrEeoXyoh+k1EZqK2AYpwgAClIID//4rzsA== Date: Fri, 15 Sep 2017 17:19:33 +0000 Message-ID: <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_0e85678e70b243709887ad4a2f21e5fdXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:19:48 -0000 --_000_0e85678e70b243709887ad4a2f21e5fdXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KU2VlIGJlbG93Og0KDQpGcmVkDQoNCkZyb206IExvcmVuem8gQ29saXR0 aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDE1 LCAyMDE3IDEwOjE1IEFNDQpUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tPg0KQ2M6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzsgaS1kLWFubm91bmNlQGlldGYu b3JnOyB2Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDkudHh0DQoNCk9uIEZy aSwgU2VwIDE1LCAyMDE3IGF0IDc6MzQgQU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0K SSBhbSBPSyB3aXRoIHRoZSBjaGFuZ2VzLCBidXQgdGhlcmUgaXMgc3RpbGwgc29tZXRoaW5nIG1p c3NpbmcuIFRoZSByb3V0ZXIgbmVlZHMgdG8NCmJlIGFibGUgdG8gc2VuZCBJQ01QdjYgRGVzdGlu YXRpb24gVW5yZWFjaGFibGVzIGZvciBJUHY2IGRlc3RpbmF0aW9uIGFkZHJlc3Nlcw0KdGhhdCBk byBub3QgbWF0Y2ggb25lIG9mIHRoZSBob3N0J3MgY3VycmVudCBhZGRyZXNzZXMuDQoNCkkgZGlz YWdyZWUuIFRoYXQgcHJlZml4IGJlbG9uZ3MgdG8gdGhlIGhvc3QuDQoNCg0Kw5ggIFRoYXQgd291 bGQgb25seSBiZSB0cnVlIGZvciBwcmVmaXggZGVsZWdhdGlvbi4gVGhpcyBpcyBub3QgcHJlZml4 IGRlbGVnYXRpb24uDQoNCklmIHRoZSBob3N0IHdpc2hlcyB0byBzZW5kIHVucmVhY2hhYmxlcywg dGhlbiBpdCBjYW4gY2hvb3NlIHRvIGRvIHNvLg0KDQoNCsOYICBIb3N0cyBkbyBub3Qgc2VuZCBE ZXN0aW5hdGlvbiBVbnJlYWNoYWJsZXMgd2l0aCBjb2RlIEFkZHJlc3MgVW5yZWFjaGFibGU7DQoN CsOYICBvbmx5IHJvdXRlcnMgY2FuIGRvIHRoYXQuIHRoYXQgaXMgd2h5IHRoZSByb3V0ZXIgbmVl ZHMgdG8gY29uc2lkZXIgdGhlIHByZWZpeA0KDQrDmCAgYXMgb24tbGluayBhbmQgZG8gYWRkcmVz cyByZXNvbHV0aW9uIG9uIGJlaGFsZiBvZiB0aGUgaG9zdC4NCg0KDQpJZiBub3QsIGl0IGNhbiBj aG9vc2Ugbm90IHRvIGRvIHNvLiBBZGRpdGlvbmFsbHksIG9uZSBvZiB0aGUgZGVzaXJhYmxlIHBy b3BlcnRpZXMgb2YgdGhpcyBzY2hlbWUgaXMgdGhhdCB0aGUgcm91dGVyIGRvZXMgbm90IG5lZWQg dG8gc3RvcmUgYWxsIGhvc3QgYWRkcmVzc2VzIGluIGl0cyBORCBjYWNoZS4gVGhhdCBzaW1wbGlm aWVzIGltcGxlbWVudGF0aW9uIGFuZCBwcm90ZWN0cyBmcm9tIGEgbnVtYmVyIG9mIHN0YXRlIGV4 aGF1c3Rpb24gYXR0YWNrcy4NCg0KDQrDmCAgICBTZWUgbXkgcmVwbHkgdG8gRGF2aWQuIEkgdGhp bmsgdGhlIHJvdXRlciBuZWVkcyB0byBwcm90ZWN0IHRoZSBob3N0IGFnYWluc3QNCg0Kw5ggICAg YSBmbG9vZCBvZiBwYWNrZXRzIHdpdGggKHBvdGVudGlhbGx5KSBzcG9vZmVkIGRlc3RpbmF0aW9u IGFkZHJlc3Nlcy4NCg== --_000_0e85678e70b243709887ad4a2f21e5fdXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyNDg2NjI1NDk7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE5NzI2NDIwODIgLTM3NjUzMDE5 OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+D mDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjI2NTQyNTg5NzsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTgwODI5NzE1NCAxMzkwODQ0ODkwIDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5IaSBMb3JlbnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+U2VlIGJlbG93OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+RnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9A Z29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIFNlcHRlbWJlciAxNSwgMjAx NyAxMDoxNSBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBMICZsdDtGcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnOyBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlw djYtcHJlZml4LXBlci1ob3N0LTA5LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgU2VwIDE1LCAyMDE3 IGF0IDc6MzQgQU0sIFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb20iIHRhcmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBhbSBPSyB3aXRoIHRoZSBjaGFuZ2VzLCBidXQgdGhlcmUgaXMgc3RpbGwg c29tZXRoaW5nIG1pc3NpbmcuIFRoZSByb3V0ZXIgbmVlZHMgdG88YnI+DQpiZSBhYmxlIHRvIHNl bmQgSUNNUHY2IERlc3RpbmF0aW9uIFVucmVhY2hhYmxlcyBmb3IgSVB2NiBkZXN0aW5hdGlvbiBh ZGRyZXNzZXM8YnI+DQp0aGF0IGRvIG5vdCBtYXRjaCBvbmUgb2YgdGhlIGhvc3QncyBjdXJyZW50 IGFkZHJlc3Nlcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgZGlzYWdyZWUuIFRoYXQgcHJlZml4IGJlbG9uZ3MgdG8gdGhlIGhv c3QuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rp bmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGhhdCB3b3VsZCBvbmx5IGJlIHRydWUgZm9yIHByZWZpeCBkZWxlZ2F0aW9uLiBUaGlzIGlz IG5vdCBwcmVmaXggZGVsZWdhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIGhvc3Qgd2lzaGVzIHRv IHNlbmQgdW5yZWFjaGFibGVzLCB0aGVuIGl0IGNhbiBjaG9vc2UgdG8gZG8gc28uPHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG9zdHMgZG8g bm90IHNlbmQgRGVzdGluYXRpb24gVW5yZWFjaGFibGVzIHdpdGggY29kZSBBZGRyZXNzIFVucmVh Y2hhYmxlOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5vbmx5IHJvdXRlcnMgY2FuIGRvIHRoYXQuIHRoYXQgaXMgd2h5IHRoZSByb3V0 ZXIgbmVlZHMgdG8gY29uc2lkZXIgdGhlIHByZWZpeDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hcyBvbi1saW5rIGFuZCBkbyBhZGRy ZXNzIHJlc29sdXRpb24gb24gYmVoYWxmIG9mIHRoZSBob3N0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWYgbm90LCBpdCBjYW4gY2hvb3NlIG5vdCB0byBkbyBzby4gQWRkaXRpb25hbGx5LCBvbmUgb2Yg dGhlIGRlc2lyYWJsZSBwcm9wZXJ0aWVzIG9mIHRoaXMgc2NoZW1lIGlzIHRoYXQgdGhlIHJvdXRl ciBkb2VzIG5vdCBuZWVkIHRvIHN0b3JlIGFsbCBob3N0IGFkZHJlc3NlcyBpbiBpdHMgTkQgY2Fj aGUuIFRoYXQgc2ltcGxpZmllcyBpbXBsZW1lbnRhdGlvbiBhbmQgcHJvdGVjdHMgZnJvbSBhIG51 bWJlciBvZg0KIHN0YXRlIGV4aGF1c3Rpb24gYXR0YWNrcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2VlIG15IHJlcGx5IHRvIERhdmlkLiBJIHRoaW5r IHRoZSByb3V0ZXIgbmVlZHMgdG8gcHJvdGVjdCB0aGUgaG9zdCBhZ2FpbnN0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldp bmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPmEgZmxvb2Qgb2YgcGFja2V0cyB3aXRoIChwb3RlbnRpYWxseSkg c3Bvb2ZlZCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_0e85678e70b243709887ad4a2f21e5fdXCH150608nwnosboeingcom_-- From nobody Fri Sep 15 10:21:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA87132FA7 for ; Fri, 15 Sep 2017 10:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 u0AUchAUNVJW for ; Fri, 15 Sep 2017 10:20:59 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B22132949 for ; Fri, 15 Sep 2017 10:20:59 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id v72so1844795ywa.3 for ; Fri, 15 Sep 2017 10:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5kqgvNOtB5fu/vasTHGaUbdvxT/xCyK1SjnnzDQv2IY=; b=hKW1WXGJ8etjoyd7DrCurmwf3F07Uzc+XDES5mgl6N62l4Oi4wBbcXfaBCilREfe3b tt7VIKB0UpPNwyIH8MNkbgv4AJPBRpkCOiDWK7K+0Fnh+vlR/5jnYs27UYqOhlXJZvz2 NWeWPN+x+4isrhxak3hJ6CVqkDW5H0nKYaL4XVgvNSq+qGN0ae+llSczgrc7++1gFjAn fV1YNaj5izULFcimIEgVPvVa6cj5cFPZSrmE1bR56E/joXGJY68hscBbmW9I9barNOZ+ 3F9iMY4pa3Cav/pAa/v1u0A2tiPLPgOMzzEGuPT1ZZqgj0KZwsuTepd6De1+2X6jEpBh KQ6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5kqgvNOtB5fu/vasTHGaUbdvxT/xCyK1SjnnzDQv2IY=; b=MOkDJ2nIhuvaMgCNMYCeUCfGZPzdTdVIpbb0/URb85ULyaRCQ/GYzLQyvjHB6XGZgk qy8eRLQ9KveIZIMpr3iOo26i+vdUTbqdp694dkbTBvWPsIkJ1sbpI0QDY0aoU2M3Aq2d h0nMGG5xgp9fW7ADpkiEyJr8ohYWcfe2ph0crhhnOPjaOCSyD05xcIHGtYek62GYBHS5 VA82HXVM7SOiAbWYSmY3D/a3B/86I49IBvlFumqcGXsQqxB/s0/OwoPjouWeUZZf065P j6tS7kkYXxhqQ8yP0SfGMiP4/UPdltrvYra/hmYLCqe1coQh7EbfY4LMUGtFkqpVUXCz tC2Q== X-Gm-Message-State: AHPjjUhpOqQE3rjdzt2KMKDjRaH5LSwwbVXaLSQF3/OMWpy6YGx2+mbw qJFoMvLyMT570dRLYvj9XbDLVU53DsweRySYxoIsza8J X-Google-Smtp-Source: AOwi7QA3rqhCl+8QpOW7x81qXOjM6B4F7Jqzg51ldxaJZjbg1x8magwh4LuNj45KMjH6rzRqtD8hM3BnfyUnQF+4WJ0= X-Received: by 10.37.116.83 with SMTP id p80mr22766449ybc.34.1505496058404; Fri, 15 Sep 2017 10:20:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Fri, 15 Sep 2017 10:20:37 -0700 (PDT) In-Reply-To: <289746642fb745ad819c71a02ef4cb22@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <289746642fb745ad819c71a02ef4cb22@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Fri, 15 Sep 2017 10:20:37 -0700 Message-ID: To: "Templin, Fred L" Cc: David Farmer , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a114dafeec6080a05593d9d87" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:21:00 -0000 --001a114dafeec6080a05593d9d87 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 15, 2017 at 10:16 AM, Templin, Fred L wrote: > =C3=98 Let=E2=80=99s assume the prefix is 2001:db8::/64. What if the hos= t only > configures the > > =C3=98 address 2001:db8::f00, and the router receives an IPv6 packet wit= h > destination > > =C3=98 2001:db8::baa. Should the router send the packet to the host, whi= ch > will drop > > =C3=98 it silently? Then, what if there is a flood of packets with IPv6 > destination > > =C3=98 address 2001:db8::*? Should the router send all of them to the ho= st? > I think so, yes. --001a114dafeec6080a05593d9d87 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 15, 2017 at 10:16 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:

=C3=98=C2=A0 Let=E2=80=99s assume the prefix is 2001:db8::/= 64. What if the host only configures the

=C3=98=C2=A0 address 2001:db8::f00, and the r= outer receives an IPv6 packet with destination

=C3=98=C2=A0 2001:db8::baa. Should the router= send the packet to the host, which will drop

=C3=98=C2=A0 it silently? Then, what if there= is a flood of packets with IPv6 destination

=C3=98=C2=A0 address 2001:db8::*? Should the = router send all of them to the host?

I think so, yes.
--001a114dafeec6080a05593d9d87-- From nobody Fri Sep 15 10:22:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D8D133453 for ; Fri, 15 Sep 2017 10:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 Ljd2AapS3miN for ; Fri, 15 Sep 2017 10:22:02 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B3C13344F for ; Fri, 15 Sep 2017 10:22:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8FHM1Mi006871; Fri, 15 Sep 2017 10:22:01 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8FHM0pd006853 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Sep 2017 10:22:00 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Sep 2017 10:22:00 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 15 Sep 2017 10:21:59 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: David Farmer , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0R353fXvPDrEeoXyoh+k1EZqK2AYpwgACiGYD//4u/sIAAeMGA//+K5yA= Date: Fri, 15 Sep 2017 17:21:59 +0000 Message-ID: <0afb49c595c04c1b860909eff432b399@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <289746642fb745ad819c71a02ef4cb22@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_0afb49c595c04c1b860909eff432b399XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:22:04 -0000 --_000_0afb49c595c04c1b860909eff432b399XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTG9yZW56bywNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWlsdG86bG9yZW56b0Bnb29n bGUuY29tXQ0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMTcgMTA6MjEgQU0NClRvOiBU ZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogRGF2aWQgRmFy bWVyIDxmYXJtZXJAdW1uLmVkdT47IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3Bz XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9z dC0wOS50eHQNCg0KT24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgMTA6MTYgQU0sIFRlbXBsaW4sIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4+IHdyb3RlOg0KPiAgTGV04oCZcyBhc3N1bWUgdGhlIHByZWZpeCBpcyAyMDAxOmRi ODo6LzY0LiBXaGF0IGlmIHRoZSBob3N0IG9ubHkgY29uZmlndXJlcyB0aGUNCg0KPiAgYWRkcmVz cyAyMDAxOmRiODo6ZjAwLCBhbmQgdGhlIHJvdXRlciByZWNlaXZlcyBhbiBJUHY2IHBhY2tldCB3 aXRoIGRlc3RpbmF0aW9uDQoNCj4gIDIwMDE6ZGI4OjpiYWEuIFNob3VsZCB0aGUgcm91dGVyIHNl bmQgdGhlIHBhY2tldCB0byB0aGUgaG9zdCwgd2hpY2ggd2lsbCBkcm9wDQoNCj4gIGl0IHNpbGVu dGx5PyBUaGVuLCB3aGF0IGlmIHRoZXJlIGlzIGEgZmxvb2Qgb2YgcGFja2V0cyB3aXRoIElQdjYg ZGVzdGluYXRpb24NCg0KPiAgYWRkcmVzcyAyMDAxOmRiODo6Kj8gU2hvdWxkIHRoZSByb3V0ZXIg c2VuZCBhbGwgb2YgdGhlbSB0byB0aGUgaG9zdD8NCkkgdGhpbmsgc28sIHllcy4NCg0KDQoNCsOY ICBPSywgc28gdGhlbiB0aGUgYXR0YWNrZXIgY2FuIERvUyB0aGUgaG9zdC4NCg== --_000_0afb49c595c04c1b860909eff432b399XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm0xNDAxMTE3NTQxMDQ5NTY2NDY3bXNvbGlzdHBhcmFncmFw aCwgbGkubTE0MDExMTc1NDEwNDk1NjY0Njdtc29saXN0cGFyYWdyYXBoLCBkaXYubTE0MDExMTc1 NDEwNDk1NjY0Njdtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fMTQwMTExNzU0 MTA0OTU2NjQ2N21zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTc2NDU5ODM2Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3NzExNDMxNDYgNDE5Njk4NDM0IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCglt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5IaSBMb3JlbnpvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExvcmVuem8gQ29saXR0aSBb bWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIFNl cHRlbWJlciAxNSwgMjAxNyAxMDoyMSBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBM ICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRGF2aWQg RmFybWVyICZsdDtmYXJtZXJAdW1uLmVkdSZndDs7IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVl LWlwdjYtcHJlZml4LXBlci1ob3N0LTA5LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgU2VwIDE1LCAy MDE3IGF0IDEwOjE2IEFNLCBUZW1wbGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5MZXTigJlzIGFzc3VtZSB0aGUgcHJlZml4IGlzIDIwMDE6 ZGI4OjovNjQuIFdoYXQgaWYgdGhlIGhvc3Qgb25seSBjb25maWd1cmVzIHRoZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTQwMTExNzU0MTA0OTU2NjQ2N21zb2xpc3RwYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo0MS4yNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YWRkcmVzcyAyMDAxOmRiODo6ZjAwLCBhbmQgdGhl IHJvdXRlciByZWNlaXZlcyBhbiBJUHY2IHBhY2tldCB3aXRoIGRlc3RpbmF0aW9uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0xNDAxMTE3NTQxMDQ5NTY2NDY3bXNvbGlzdHBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQxLjI1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOw0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4yMDAxOmRiODo6YmFhLiBTaG91bGQgdGhlIHJv dXRlciBzZW5kIHRoZSBwYWNrZXQgdG8gdGhlIGhvc3QsIHdoaWNoIHdpbGwgZHJvcDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTQwMTExNzU0MTA0OTU2NjQ2N21zb2xpc3RwYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo0MS4yNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aXQgc2lsZW50bHk/IFRoZW4sIHdoYXQgaWYg dGhlcmUgaXMgYSBmbG9vZCBvZiBwYWNrZXRzIHdpdGggSVB2NiBkZXN0aW5hdGlvbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMTQwMTExNzU0MTA0OTU2NjQ2N21zb2xpc3RwYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo0MS4yNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YWRkcmVzcyAyMDAxOmRiODo6Kj8gU2hvdWxk IHRoZSByb3V0ZXIgc2VuZCBhbGwgb2YgdGhlbSB0byB0aGUgaG9zdD88L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5r IHNvLCB5ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5n ZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5PSywgc28gdGhlbiB0aGUgYXR0YWNrZXIgY2FuIERvUyB0aGUgaG9zdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0afb49c595c04c1b860909eff432b399XCH150608nwnosboeingcom_-- From nobody Fri Sep 15 10:25:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3012C13305F for ; Fri, 15 Sep 2017 10:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dIEnQCME-tVe for ; Fri, 15 Sep 2017 10:25:35 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6CE4133050 for ; Fri, 15 Sep 2017 10:25:35 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id w22so1831412ywa.13 for ; Fri, 15 Sep 2017 10:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8tGHPrKKYTaco+49JnvF6ja2ekddzxpGv0gxiZHj7Y=; b=QdawbEJI2myfggjxehLTA98+ijR9cXcDDky7+nrdc/adLs8ABNkQuP2hVpYJ7a1RmL LHRrEH/VLsrV61aDx9mvt22WryIKPMjdN+qHL2Ta1NyVqccI3HNNimMW7ufuWpftFjsx Nc/c5uY45JPitmzBLyp05wrqRH/8khq/LRUr9aK2wTQu698UVIeV5sVhtnDXMdNXy4vE 97da5yZIhVP0OFLmMwj0zrGSSSyueC/pBTPM2tr4bcKI/MNrrZFNbiVbnK2hKro6lYdC VMzf/tXOE58ADGvZ5P/tjJn9N73CkTg4yblD//Vv3U56vnFRzIg6xeguIm1yqx9p1XUZ zZYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8tGHPrKKYTaco+49JnvF6ja2ekddzxpGv0gxiZHj7Y=; b=RSxlrkqYQ/r4xIV0C+oMxeL3C5Xa8IYqGWOmvpabUktYzv0ZIp/qSwNTnW/oDiAj0B a9vwVtBpCl32MF0LXVNVzhvs4uvqjj+KKdEkRpNB1D3mChS6SRULPIVEq+V5+/Y9c5B+ 4LY51rh8ixNndTm+syltERRaRR+hFQZUhGCOdH+Gia7JnZFEyyNezL66vltpZoseuhKa QQs/porkpSXcVBgPpwwSgI6raf6wPx/xfsy8aGOKvILjRbikfXt7VxLxcgi7aUxdyGwB hsTYJ0VxgslBXQ7/Y6OGoZqa44Qj+6UZRTz9+oeAQhyNIWJC1vdSCax8pv8vVRKAn6c/ sQ0A== X-Gm-Message-State: AHPjjUhCCwQo+BKGKOSjjO7ggEIhJVCwOgTj1znppxAQnF89tNOb7qV7 XAIYaJazRfJRrKSXE08BQupirbDuxoR6g08seD7Fow== X-Google-Smtp-Source: AOwi7QAMO8U24EhEaw0WPqs7voo9nhQOlai//hMSSIdeWKyU5cGB36at1gHaLSngczdOngqD57ngsJgBPRJBbk0sMdg= X-Received: by 10.37.208.134 with SMTP id h128mr21722867ybg.103.1505496334679; Fri, 15 Sep 2017 10:25:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Fri, 15 Sep 2017 10:25:13 -0700 (PDT) In-Reply-To: <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Fri, 15 Sep 2017 10:25:13 -0700 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c055e7c3de3af05593daedb" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:25:37 -0000 --94eb2c055e7c3de3af05593daedb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 15, 2017 at 10:19 AM, Templin, Fred L wrote: > > =C3=98 Hosts do not send Destination Unreachables with code Address > Unreachable; > > =C3=98 only routers can do that. that is why the router needs to conside= r the > prefix > > =C3=98 as on-link and do address resolution on behalf of the host. > If you want to distinguish "host" vs "router" in this sense, then the host will not send destination unreachables at all, and I think that's fine. > If not, it can choose not to do so. Additionally, one of the desirable > properties of this scheme is that the router does not need to store all > host addresses in its ND cache. That simplifies implementation and protec= ts > from a number of state exhaustion attacks. > > =C3=98 See my reply to David. I think the router needs to protect the = host > against > > =C3=98 a flood of packets with (potentially) spoofed destination addre= sses. > I disagree. If it's a host, it will just silently drop those packets. Such an attack can do no more damage than a flood of packets to the host's own address, and in most cases it will do much less. --94eb2c055e7c3de3af05593daedb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 15, 2017 at 10:19 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:=C2=A0
<= div>

=C3=98=C2= =A0 Hosts do not send Destination Un= reachables with code Address Unreachable;

<= span>=C3=98=C2=A0 only routers can do that. that i= s why the router needs to consider the prefix

<= span>=C3=98=C2=A0 as on-link and do address resolu= tion on behalf of the host.

<= /div>
If you want to distinguish "host" vs "= ;router" in this sense, then the host will not send destination unreac= hables at all, and I think that's fine.
<= div>

=C2=A0If not, it can choose not to do so. Additi= onally, one of the desirable properties of this scheme is that the router d= oes not need to store all host addresses in its ND cache. That simplifies i= mplementation and protects from a number of state exhaustion attacks.

=C3=98=C2=A0= =C2=A0=C2=A0 See my reply to David. I think t= he router needs to protect the host against

=C3=98=C2=A0= =C2=A0=C2=A0 a flood of packets with (potenti= ally) spoofed destination addresses.

I disagree. If it's a host, it will just silently dr= op those packets. Such an attack can do no more damage than a flood of pack= ets to the host's own address, and in most cases it will do much less.<= /div>
--94eb2c055e7c3de3af05593daedb-- From nobody Fri Sep 15 10:30:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F93113305F for ; Fri, 15 Sep 2017 10:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 Nx1VItSsnoIQ for ; Fri, 15 Sep 2017 10:30:20 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29145133016 for ; Fri, 15 Sep 2017 10:30:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8FHUJML020430; Fri, 15 Sep 2017 10:30:19 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8FHU9uG020336 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Sep 2017 10:30:09 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Sep 2017 10:30:08 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 15 Sep 2017 10:30:08 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0R353fXvPDrEeoXyoh+k1EZqK2AYpwgAClIID//4rzsIAAd8+A//+K8tA= Date: Fri, 15 Sep 2017 17:30:08 +0000 Message-ID: <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_38d4a1701dd64a62b93e087f7c42756bXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:30:21 -0000 --_000_38d4a1701dd64a62b93e087f7c42756bXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVsb3c6DQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNv bV0NClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDE1LCAyMDE3IDEwOjI1IEFNDQpUbzogVGVtcGxp biwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KQ2M6IHY2b3BzQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1 ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0wOS50eHQNCg0KT24gRnJpLCBTZXAgMTUsIDIwMTcgYXQg MTA6MTkgQU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWls dG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KDQo+ICBIb3N0cyBkbyBub3Qg c2VuZCBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZXMgd2l0aCBjb2RlIEFkZHJlc3MgVW5yZWFjaGFi bGU7DQoNCj4gIG9ubHkgcm91dGVycyBjYW4gZG8gdGhhdC4gdGhhdCBpcyB3aHkgdGhlIHJvdXRl ciBuZWVkcyB0byBjb25zaWRlciB0aGUgcHJlZml4DQoNCj4gIGFzIG9uLWxpbmsgYW5kIGRvIGFk ZHJlc3MgcmVzb2x1dGlvbiBvbiBiZWhhbGYgb2YgdGhlIGhvc3QuDQpJZiB5b3Ugd2FudCB0byBk aXN0aW5ndWlzaCAiaG9zdCIgdnMgInJvdXRlciIgaW4gdGhpcyBzZW5zZSwgdGhlbiB0aGUgaG9z dCB3aWxsIG5vdCBzZW5kIGRlc3RpbmF0aW9uIHVucmVhY2hhYmxlcyBhdCBhbGwsIGFuZCBJIHRo aW5rIHRoYXQncyBmaW5lLg0KDQoNCsOYICAgIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlz IGlzIGFib3V0IHNpbXBsZSBob3N0cywgYW5kIG5vdCBob3N0cyB0aGF0IGFjdCBhcyByb3V0ZXJz Lg0KDQrDmCAgICBIb3N0cyBjYW4gc2VuZCBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSDigJMgUG9y dCBVbnJlYWNoYWJsZTsgdGhleSBjYW5ub3Qgc2VuZA0KDQrDmCAgICBEZXN0aW5hdGlvbiBVbnJl YWNoYWJsZSDigJMgQWRkcmVzcyBVbnJlYWNoYWJsZSBleGNlcHQgdG8gdGhlaXIgb3duIGxvY2Fs DQoNCsOYICAgIGFwcGxpY2F0aW9ucy4NCg0KIElmIG5vdCwgaXQgY2FuIGNob29zZSBub3QgdG8g ZG8gc28uIEFkZGl0aW9uYWxseSwgb25lIG9mIHRoZSBkZXNpcmFibGUgcHJvcGVydGllcyBvZiB0 aGlzIHNjaGVtZSBpcyB0aGF0IHRoZSByb3V0ZXIgZG9lcyBub3QgbmVlZCB0byBzdG9yZSBhbGwg aG9zdCBhZGRyZXNzZXMgaW4gaXRzIE5EIGNhY2hlLiBUaGF0IHNpbXBsaWZpZXMgaW1wbGVtZW50 YXRpb24gYW5kIHByb3RlY3RzIGZyb20gYSBudW1iZXIgb2Ygc3RhdGUgZXhoYXVzdGlvbiBhdHRh Y2tzLg0KDQo+ICAgIFNlZSBteSByZXBseSB0byBEYXZpZC4gSSB0aGluayB0aGUgcm91dGVyIG5l ZWRzIHRvIHByb3RlY3QgdGhlIGhvc3QgYWdhaW5zdA0KDQo+ICAgIGEgZmxvb2Qgb2YgcGFja2V0 cyB3aXRoIChwb3RlbnRpYWxseSkgc3Bvb2ZlZCBkZXN0aW5hdGlvbiBhZGRyZXNzZXMuDQpJIGRp c2FncmVlLiBJZiBpdCdzIGEgaG9zdCwgaXQgd2lsbCBqdXN0IHNpbGVudGx5IGRyb3AgdGhvc2Ug cGFja2V0cy4gU3VjaCBhbiBhdHRhY2sgY2FuIGRvIG5vIG1vcmUgZGFtYWdlIHRoYW4gYSBmbG9v ZCBvZiBwYWNrZXRzIHRvIHRoZSBob3N0J3Mgb3duIGFkZHJlc3MsIGFuZCBpbiBtb3N0IGNhc2Vz IGl0IHdpbGwgZG8gbXVjaCBsZXNzLg0KDQoNCsOYICAgIEEgZmxvb2Qgb2YgcGFja2V0cyB0byB0 aGUgaG9zdHPigJlzIG93biBhZGRyZXNzIHdpbGwgcmVzdWx0IGluIERlc3RpbmF0aW9uIFVucmVh Y2hhYmxlDQoNCsOYICAgIFBvcnQgVW5yZWFjaGFibGUgbWVzc2FnZXMuIFRoaXMgd2lsbCAgY2F1 c2UgYSBsZWdpdGltYXRlIHNvdXJjZSB0byBjZWFzZSBzZW5kaW5nDQoNCsOYICAgIHBhY2tldHMg dG8gdGhlIHVucmVhY2hhYmxlIHBvcnQuDQo= --_000_38d4a1701dd64a62b93e087f7c42756bXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KcC5tLTc5ODU1MTI4NTY0OTIxNzc5MjltMTA4NzQwNDA4MjYwMTA0MDY5 NG1zb2xpc3RwYXJhZ3JhcGgsIGxpLm0tNzk4NTUxMjg1NjQ5MjE3NzkyOW0xMDg3NDA0MDgyNjAx MDQwNjk0bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm0tNzk4NTUxMjg1NjQ5MjE3NzkyOW0xMDg3NDA0 MDgyNjAxMDQwNjk0bXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTptXy03OTg1NTEy ODU2NDkyMTc3OTI5bV8xMDg3NDA0MDgyNjAxMDQwNjk0bXNvbGlzdHBhcmFncmFwaDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjYzMDQw MjYyMTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTM1 NzA0OTQyIC0xNDA2NjAyMTA4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTcyMjcxMTU1MjsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwNjIzMDc0NjAg LTEyOTcwNTAxMjAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlbG93OjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExvcmVu em8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIFNlcHRlbWJlciAxNSwgMjAxNyAxMDoyNSBBTTxicj4NCjxiPlRvOjwvYj4gVGVt cGxpbiwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gdjZvcHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDku dHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgMTA6MTkgQU0sIFRlbXBsaW4s IEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iIHRh cmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0tNzk4NTUxMjg1NjQ5MjE3NzkyOW0x MDg3NDA0MDgyNjAxMDQwNjk0bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhvc3RzIGRvIG5vdCBzZW5kIERlc3RpbmF0 aW9uIFVucmVhY2hhYmxlcyB3aXRoIGNvZGUgQWRkcmVzcyBVbnJlYWNoYWJsZTs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS03OTg1NTEyODU2NDkyMTc3OTI5bTEwODc0MDQwODI2 MDEwNDA2OTRtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+b25seSByb3V0ZXJzIGNhbiBkbyB0aGF0LiB0aGF0IGlzIHdo eSB0aGUgcm91dGVyIG5lZWRzIHRvIGNvbnNpZGVyIHRoZSBwcmVmaXg8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0ibS03OTg1NTEyODU2NDkyMTc3OTI5bTEwODc0MDQwODI2MDEwNDA2 OTRtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+YXMgb24tbGluayBhbmQgZG8gYWRkcmVzcyByZXNvbHV0aW9uIG9uIGJl aGFsZiBvZiB0aGUgaG9zdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3Ugd2FudCB0byBkaXN0aW5ndWlzaCAmcXVv dDtob3N0JnF1b3Q7IHZzICZxdW90O3JvdXRlciZxdW90OyBpbiB0aGlzIHNlbnNlLCB0aGVuIHRo ZSBob3N0IHdpbGwgbm90IHNlbmQgZGVzdGluYXRpb24gdW5yZWFjaGFibGVzIGF0IGFsbCwgYW5k IEkgdGhpbmsgdGhhdCdzIGZpbmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5n cztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlzIGlzIGFib3V0IHNpbXBs ZSBob3N0cywgYW5kIG5vdCBob3N0cyB0aGF0IGFjdCBhcyByb3V0ZXJzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO3RleHQtaW5kZW50OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5n ZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Ib3N0cyBjYW4gc2VuZCBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSDi gJMgUG9ydCBVbnJlYWNoYWJsZTsgdGhleSBjYW5ub3Qgc2VuZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO3Rl eHQtaW5kZW50OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7 Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5EZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSDigJMgQWRkcmVzcyBVbnJlYWNoYWJs ZSBleGNlcHQgdG8gdGhlaXIgb3duIGxvY2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6 MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0 OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PmFwcGxpY2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0tNzk4NTUxMjg1NjQ5MjE3NzkyOW0xMDg3NDA0MDgyNjAx MDQwNjk0bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj5JZiBub3QsIGl0IGNhbiBjaG9vc2Ugbm90IHRvIGRvIHNvLiBBZGRpdGlvbmFs bHksIG9uZSBvZiB0aGUgZGVzaXJhYmxlIHByb3BlcnRpZXMgb2YgdGhpcyBzY2hlbWUgaXMgdGhh dA0KIHRoZSByb3V0ZXIgZG9lcyBub3QgbmVlZCB0byBzdG9yZSBhbGwgaG9zdCBhZGRyZXNzZXMg aW4gaXRzIE5EIGNhY2hlLiBUaGF0IHNpbXBsaWZpZXMgaW1wbGVtZW50YXRpb24gYW5kIHByb3Rl Y3RzIGZyb20gYSBudW1iZXIgb2Ygc3RhdGUgZXhoYXVzdGlvbiBhdHRhY2tzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Im0tNzk4NTUxMjg1NjQ5MjE3NzkyOW0xMDg3NDA0MDgyNjAxMDQwNjk0 bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNlZSBteSByZXBseSB0byBEYXZpZC4gSSB0aGluayB0 aGUgcm91dGVyIG5lZWRzIHRvIHByb3RlY3QgdGhlIGhvc3QgYWdhaW5zdDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJtLTc5ODU1MTI4NTY0OTIxNzc5MjltMTA4NzQwNDA4MjYwMTA0 MDY5NG1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hIGZsb29kIG9mIHBhY2tldHMgd2l0aCAocG90 ZW50aWFsbHkpIHNwb29mZWQgZGVzdGluYXRpb24gYWRkcmVzc2VzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpc2Fn cmVlLiBJZiBpdCdzIGEgaG9zdCwgaXQgd2lsbCBqdXN0IHNpbGVudGx5IGRyb3AgdGhvc2UgcGFj a2V0cy4gU3VjaCBhbiBhdHRhY2sgY2FuIGRvIG5vIG1vcmUgZGFtYWdlIHRoYW4gYSBmbG9vZCBv ZiBwYWNrZXRzIHRvIHRoZSBob3N0J3Mgb3duIGFkZHJlc3MsIGFuZCBpbiBtb3N0IGNhc2VzIGl0 IHdpbGwgZG8gbXVjaCBsZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO3Rl eHQtaW5kZW50OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7 Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5BIGZsb29kIG9mIHBhY2tldHMgdG8gdGhlIGhvc3Rz4oCZcyBvd24gYWRkcmVz cyB3aWxsIHJlc3VsdCBpbiBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu O3RleHQtaW5kZW50OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGlu Z3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5Qb3J0IFVucmVhY2hhYmxlIG1lc3NhZ2VzLiBUaGlzIHdpbGwmbmJzcDsg Y2F1c2UgYSBsZWdpdGltYXRlIHNvdXJjZSB0byBjZWFzZSBzZW5kaW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldpbmdk aW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPnBhY2tldHMgdG8gdGhlIHVucmVhY2hhYmxlIHBvcnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_38d4a1701dd64a62b93e087f7c42756bXCH150608nwnosboeingcom_-- From nobody Fri Sep 15 10:36:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AFE133039 for ; Fri, 15 Sep 2017 10:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 jLtOXGETLSTY for ; Fri, 15 Sep 2017 10:36:28 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C603132A89 for ; Fri, 15 Sep 2017 10:36:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8FHaRPN031667; Fri, 15 Sep 2017 10:36:28 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8FHaLQd031269 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Sep 2017 10:36:21 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Sep 2017 10:36:21 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 15 Sep 2017 10:36:20 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0R353fXvPDrEeoXyoh+k1EZqK2AYpwgAClIID//4rzsIAAd8+A//+K8tCAAAJAwA== Date: Fri, 15 Sep 2017 17:36:20 +0000 Message-ID: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_e9b73f75e23749fb8d74dd83dff0dec4XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:36:30 -0000 --_000_e9b73f75e23749fb8d74dd83dff0dec4XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgaXMgYSBiaXQgbW9yZSB0byB0aGlzIGRpc2N1c3Npb24gcmVnYXJkaW5nIGhhdmluZyB0 aGUgcm91dGVyIHBlcmZvcm0gYWRkcmVzcw0KcmVzb2x1dGlvbi4gVGhlIHJvdXRlciBpcyBsaWtl bHkgdG8gYmUgY29ubmVjdGVkIHRvIHZlcnkgcm9idXN0IGluZnJhc3RydWN0dXJlLCBlLmcuLA0K MTBHQiBFdGhlcm5ldCBvciB0aGUgbGlrZS4gTWVhbndoaWxlLCB0aGUgaG9zdCB3aWxsIGJlIGNv bm5lY3RlZCB0byBzb21lIHdpcmVsZXNzDQpsaW5rIHdpdGggYmFuZHdpZHRoIHNldmVyYWwgb3Jk ZXJzIG9mIG1hZ25pdHVkZSBsZXNzLiBUaGF0IGlzIHdoeSBJIHRoaW5rIHRoZSByb3V0ZXINCnNo b3VsZCBwcm90ZWN0IHRoZSBob3N0Lg0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IHY2b3BzIFtt YWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlbXBsaW4sIEZyZWQg TA0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMTcgMTA6MzAgQU0NClRvOiBMb3Jlbnpv IENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4NCkNjOiB2Nm9wc0BpZXRmLm9yZw0KU3ViamVj dDogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1w cmVmaXgtcGVyLWhvc3QtMDkudHh0DQoNCkJlbG93Og0KDQpGcm9tOiBMb3JlbnpvIENvbGl0dGkg W21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAxNSwg MjAxNyAxMDoyNSBBTQ0KVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5n LmNvbTxtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+DQpDYzogdjZvcHNAaWV0Zi5v cmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDkudHh0DQoN Ck9uIEZyaSwgU2VwIDE1LCAyMDE3IGF0IDEwOjE5IEFNLCBUZW1wbGluLCBGcmVkIEwgPEZyZWQu TC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+PiB3 cm90ZToNCg0KPiAgSG9zdHMgZG8gbm90IHNlbmQgRGVzdGluYXRpb24gVW5yZWFjaGFibGVzIHdp dGggY29kZSBBZGRyZXNzIFVucmVhY2hhYmxlOw0KDQo+ICBvbmx5IHJvdXRlcnMgY2FuIGRvIHRo YXQuIHRoYXQgaXMgd2h5IHRoZSByb3V0ZXIgbmVlZHMgdG8gY29uc2lkZXIgdGhlIHByZWZpeA0K DQo+ICBhcyBvbi1saW5rIGFuZCBkbyBhZGRyZXNzIHJlc29sdXRpb24gb24gYmVoYWxmIG9mIHRo ZSBob3N0Lg0KSWYgeW91IHdhbnQgdG8gZGlzdGluZ3Vpc2ggImhvc3QiIHZzICJyb3V0ZXIiIGlu IHRoaXMgc2Vuc2UsIHRoZW4gdGhlIGhvc3Qgd2lsbCBub3Qgc2VuZCBkZXN0aW5hdGlvbiB1bnJl YWNoYWJsZXMgYXQgYWxsLCBhbmQgSSB0aGluayB0aGF0J3MgZmluZS4NCg0KDQrDmCAgIE15IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlzIGlzIGFib3V0IHNpbXBsZSBob3N0cywgYW5kIG5vdCBo b3N0cyB0aGF0IGFjdCBhcyByb3V0ZXJzLg0KDQrDmCAgIEhvc3RzIGNhbiBzZW5kIERlc3RpbmF0 aW9uIFVucmVhY2hhYmxlIOKAkyBQb3J0IFVucmVhY2hhYmxlOyB0aGV5IGNhbm5vdCBzZW5kDQoN CsOYICAgRGVzdGluYXRpb24gVW5yZWFjaGFibGUg4oCTIEFkZHJlc3MgVW5yZWFjaGFibGUgZXhj ZXB0IHRvIHRoZWlyIG93biBsb2NhbA0KDQrDmCAgIGFwcGxpY2F0aW9ucy4NCg0KIElmIG5vdCwg aXQgY2FuIGNob29zZSBub3QgdG8gZG8gc28uIEFkZGl0aW9uYWxseSwgb25lIG9mIHRoZSBkZXNp cmFibGUgcHJvcGVydGllcyBvZiB0aGlzIHNjaGVtZSBpcyB0aGF0IHRoZSByb3V0ZXIgZG9lcyBu b3QgbmVlZCB0byBzdG9yZSBhbGwgaG9zdCBhZGRyZXNzZXMgaW4gaXRzIE5EIGNhY2hlLiBUaGF0 IHNpbXBsaWZpZXMgaW1wbGVtZW50YXRpb24gYW5kIHByb3RlY3RzIGZyb20gYSBudW1iZXIgb2Yg c3RhdGUgZXhoYXVzdGlvbiBhdHRhY2tzLg0KDQo+ICAgIFNlZSBteSByZXBseSB0byBEYXZpZC4g SSB0aGluayB0aGUgcm91dGVyIG5lZWRzIHRvIHByb3RlY3QgdGhlIGhvc3QgYWdhaW5zdA0KDQo+ ICAgIGEgZmxvb2Qgb2YgcGFja2V0cyB3aXRoIChwb3RlbnRpYWxseSkgc3Bvb2ZlZCBkZXN0aW5h dGlvbiBhZGRyZXNzZXMuDQpJIGRpc2FncmVlLiBJZiBpdCdzIGEgaG9zdCwgaXQgd2lsbCBqdXN0 IHNpbGVudGx5IGRyb3AgdGhvc2UgcGFja2V0cy4gU3VjaCBhbiBhdHRhY2sgY2FuIGRvIG5vIG1v cmUgZGFtYWdlIHRoYW4gYSBmbG9vZCBvZiBwYWNrZXRzIHRvIHRoZSBob3N0J3Mgb3duIGFkZHJl c3MsIGFuZCBpbiBtb3N0IGNhc2VzIGl0IHdpbGwgZG8gbXVjaCBsZXNzLg0KDQoNCsOYICAgQSBm bG9vZCBvZiBwYWNrZXRzIHRvIHRoZSBob3N0c+KAmXMgb3duIGFkZHJlc3Mgd2lsbCByZXN1bHQg aW4gRGVzdGluYXRpb24gVW5yZWFjaGFibGUNCg0Kw5ggICBQb3J0IFVucmVhY2hhYmxlIG1lc3Nh Z2VzLiBUaGlzIHdpbGwgIGNhdXNlIGEgbGVnaXRpbWF0ZSBzb3VyY2UgdG8gY2Vhc2Ugc2VuZGlu Zw0KDQrDmCAgIHBhY2tldHMgdG8gdGhlIHVucmVhY2hhYmxlIHBvcnQuDQo= --_000_e9b73f75e23749fb8d74dd83dff0dec4XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm0tNzk4NTUxMjg1NjQ5MjE3NzkyOW0xMDg3NDA0MDgyNjAx MDQwNjk0bXNvbGlzdHBhcmFncmFwaCwgbGkubS03OTg1NTEyODU2NDkyMTc3OTI5bTEwODc0MDQw ODI2MDEwNDA2OTRtc29saXN0cGFyYWdyYXBoLCBkaXYubS03OTg1NTEyODU2NDkyMTc3OTI5bTEw ODc0MDQwODI2MDEwNDA2OTRtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fLTc5 ODU1MTI4NTY0OTIxNzc5MjltXzEwODc0MDQwODI2MDEwNDA2OTRtc29saXN0cGFyYWdyYXBoOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjYzMDQwMjYyMTsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTM1NzA0OTQyIC0xNDA2NjAyMTA4IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCglt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6MTcyMjcxMTU1MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwNjIzMDc0NjAgLTEyOTcwNTAxMjAgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoZXJlIGlzIGEgYml0IG1vcmUgdG8gdGhpcyBkaXNjdXNzaW9uIHJlZ2FyZGlu ZyBoYXZpbmcgdGhlIHJvdXRlciBwZXJmb3JtIGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+cmVz b2x1dGlvbi4gVGhlIHJvdXRlciBpcyBsaWtlbHkgdG8gYmUgY29ubmVjdGVkIHRvIHZlcnkgcm9i dXN0IGluZnJhc3RydWN0dXJlLCBlLmcuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4xMEdCIEV0aGVybmV0 IG9yIHRoZSBsaWtlLiBNZWFud2hpbGUsIHRoZSBob3N0IHdpbGwgYmUgY29ubmVjdGVkIHRvIHNv bWUgd2lyZWxlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+bGluayB3aXRoIGJhbmR3aWR0aCBzZXZlcmFs IG9yZGVycyBvZiBtYWduaXR1ZGUgbGVzcy4gVGhhdCBpcyB3aHkgSSB0aGluayB0aGUgcm91dGVy PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPnNob3VsZCBwcm90ZWN0IHRoZSBob3N0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHY2 b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ VGVtcGxpbiwgRnJlZCBMPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgU2VwdGVtYmVyIDE1LCAy MDE3IDEwOjMwIEFNPGJyPg0KPGI+VG86PC9iPiBMb3JlbnpvIENvbGl0dGkgJmx0O2xvcmVuem9A Z29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVl LWlwdjYtcHJlZml4LXBlci1ob3N0LTA5LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZWxvdzo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBMb3JlbnpvIENvbGl0dGkgWzxhIGhyZWY9Im1haWx0bzpsb3JlbnpvQGdvb2ds ZS5jb20iPm1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgU2VwdGVtYmVyIDE1LCAyMDE3IDEwOjI1IEFNPGJyPg0KPGI+VG86PC9iPiBUZW1w bGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t Ij5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhy ZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVl LWlwdjYtcHJlZml4LXBlci1ob3N0LTA5LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgU2VwIDE1LCAy MDE3IGF0IDEwOjE5IEFNLCBUZW1wbGluLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbTwvYT4mZ3Q7IHdyb3RlOjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibS03OTg1NTEyODU2NDkyMTc3 OTI5bTEwODc0MDQwODI2MDEwNDA2OTRtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsNCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SG9zdHMgZG8gbm90IHNlbmQgRGVz dGluYXRpb24gVW5yZWFjaGFibGVzIHdpdGggY29kZSBBZGRyZXNzIFVucmVhY2hhYmxlOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTc5ODU1MTI4NTY0OTIxNzc5MjltMTA4NzQw NDA4MjYwMTA0MDY5NG1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOw0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5vbmx5IHJvdXRlcnMgY2FuIGRvIHRoYXQuIHRoYXQg aXMgd2h5IHRoZSByb3V0ZXIgbmVlZHMgdG8gY29uc2lkZXIgdGhlIHByZWZpeDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTc5ODU1MTI4NTY0OTIxNzc5MjltMTA4NzQwNDA4MjYw MTA0MDY5NG1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5hcyBvbi1saW5rIGFuZCBkbyBhZGRyZXNzIHJlc29sdXRpb24g b24gYmVoYWxmIG9mIHRoZSBob3N0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSB3YW50IHRvIGRpc3Rpbmd1aXNo ICZxdW90O2hvc3QmcXVvdDsgdnMgJnF1b3Q7cm91dGVyJnF1b3Q7IGluIHRoaXMgc2Vuc2UsIHRo ZW4gdGhlIGhvc3Qgd2lsbCBub3Qgc2VuZCBkZXN0aW5hdGlvbiB1bnJlYWNoYWJsZXMgYXQgYWxs LCBhbmQgSSB0aGluayB0aGF0J3MgZmluZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+TXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoaXMgaXMgYWJvdXQgc2ltcGxl IGhvc3RzLCBhbmQgbm90IGhvc3RzIHRoYXQgYWN0IGFzIHJvdXRlcnMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldpbmdk aW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkhvc3RzIGNhbiBzZW5kIERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIOKAkyBQb3J0 IFVucmVhY2hhYmxlOyB0aGV5IGNhbm5vdCBzZW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47dGV4dC1pbmRl bnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRl c3RpbmF0aW9uIFVucmVhY2hhYmxlIOKAkyBBZGRyZXNzIFVucmVhY2hhYmxlIGV4Y2VwdCB0byB0 aGVpciBvd24gbG9jYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YXBwbGljYXRpb25zLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0tNzk4NTUxMjg1NjQ5MjE3 NzkyOW0xMDg3NDA0MDgyNjAxMDQwNjk0bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj5JZiBub3QsIGl0IGNhbiBjaG9vc2Ugbm90IHRv IGRvIHNvLiBBZGRpdGlvbmFsbHksIG9uZSBvZiB0aGUgZGVzaXJhYmxlIHByb3BlcnRpZXMgb2Yg dGhpcyBzY2hlbWUgaXMgdGhhdA0KIHRoZSByb3V0ZXIgZG9lcyBub3QgbmVlZCB0byBzdG9yZSBh bGwgaG9zdCBhZGRyZXNzZXMgaW4gaXRzIE5EIGNhY2hlLiBUaGF0IHNpbXBsaWZpZXMgaW1wbGVt ZW50YXRpb24gYW5kIHByb3RlY3RzIGZyb20gYSBudW1iZXIgb2Ygc3RhdGUgZXhoYXVzdGlvbiBh dHRhY2tzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tNzk4NTUxMjg1NjQ5MjE3NzkyOW0x MDg3NDA0MDgyNjAxMDQwNjk0bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNlZSBteSByZXBseSB0 byBEYXZpZC4gSSB0aGluayB0aGUgcm91dGVyIG5lZWRzIHRvIHByb3RlY3QgdGhlIGhvc3QgYWdh aW5zdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTc5ODU1MTI4NTY0OTIxNzc5 MjltMTA4NzQwNDA4MjYwMTA0MDY5NG1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hIGZsb29kIG9m IHBhY2tldHMgd2l0aCAocG90ZW50aWFsbHkpIHNwb29mZWQgZGVzdGluYXRpb24gYWRkcmVzc2Vz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGRpc2FncmVlLiBJZiBpdCdzIGEgaG9zdCwgaXQgd2lsbCBqdXN0IHNpbGVu dGx5IGRyb3AgdGhvc2UgcGFja2V0cy4gU3VjaCBhbiBhdHRhY2sgY2FuIGRvIG5vIG1vcmUgZGFt YWdlIHRoYW4gYSBmbG9vZCBvZiBwYWNrZXRzIHRvIHRoZSBob3N0J3Mgb3duIGFkZHJlc3MsIGFu ZCBpbiBtb3N0IGNhc2VzIGl0IHdpbGwgZG8gbXVjaCBsZXNzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO3RleHQtaW5kZW50OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+ DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BIGZsb29kIG9mIHBhY2tldHMgdG8gdGhlIGhvc3Rz4oCZ cyBvd24gYWRkcmVzcyB3aWxsIHJlc3VsdCBpbiBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO3RleHQtaW5kZW50OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+DQo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5Qb3J0IFVucmVhY2hhYmxlIG1lc3NhZ2VzLiBUaGlzIHdpbGwm bmJzcDsgY2F1c2UgYSBsZWdpdGltYXRlIHNvdXJjZSB0byBjZWFzZSBzZW5kaW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47dGV4dC1pbmRlbnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm80Ij4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7D mDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPnBhY2tldHMgdG8gdGhlIHVucmVhY2hhYmxlIHBvcnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_e9b73f75e23749fb8d74dd83dff0dec4XCH150608nwnosboeingcom_-- From nobody Fri Sep 15 10:39:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF5113305F for ; Fri, 15 Sep 2017 10:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5lA3iJlebnPV for ; Fri, 15 Sep 2017 10:39:21 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0139132A89 for ; Fri, 15 Sep 2017 10:39:21 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id m103so10126207iod.13 for ; Fri, 15 Sep 2017 10:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0NNe6Uc8ydUYjFUyS3z+2jyUgQTXb0oxXoW/+pbHgnE=; b=ZkeXv/lm1rdBoJdkj+q8O3vqJYrawprDuQF1AMs82Da/6dWUAB4XN85ApDs368n8IZ sQtiEkgsCRzA/CkQ3hQZSu8f5njE93RbFa8a+hHDk2CwHmKHnwfw8ulBrxPXwPOW2My0 ssMCOH7F4KlJNUfX8fHFaznbYyVd1iH0nO4ki7QUJBwN6eoDzyrlpKR33/IAQJtAd4Kw 8OUG1MFG9u6GcUnAkQBP8aPXU7aP+/36OwggbbbazcS7gIxu19QQpafotzkyhRWlRFrU wu/LVBYYqtcBCnze5K/ztZfjY78C0gChi4MOhq5eqzfqljEN14azuIeX9wtnrL3dcmEs pkFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0NNe6Uc8ydUYjFUyS3z+2jyUgQTXb0oxXoW/+pbHgnE=; b=layKnGEPz2KvKYlMN3ZE1iuYevEP3SAoxBmxUxZiu0aaOwkLIYQiAk4VGa36X+5+9i TGECl4ZfJwGYTMUXumtnhZClRwbNHjp8J0RG+JW1r73xv1PV9wUvGt/2dNSJenHRZn3r QATC9FCBLHenDyMLQjnZAw3wZZimpRnNZNzjlOpIhtUj/iCd9J+w+fXJh1o6PSZAD6M2 QbMnNN++Bu4Vy48WyI5wsh/F0AyzPy7RK/YWrj/FqM+LHjWifHM9C+be959i7AGPPxBv Adq7WlpnSmoyZP+BwXDFKXEutxI8m/fBLZuwIct8qKSc/TYk+Mk+kVby4HunRMkuXaOG CJcg== X-Gm-Message-State: AHPjjUhRMCArm7qB7MCVxr2zCi+UbJbZKkNmr70Igd7jr/K0+zEUj4/o l2+mAIpPSQNc5qU/axHoOYim2WarnyN+MoJQIKtBqw== X-Google-Smtp-Source: AOwi7QBHWd9nlhXrmrk+cDC38DTuIcuelHrBsPfORmzjwNS8scadGXNuT51bNuAPuDi4gfrqYN3TLh8998GixKTChV4= X-Received: by 10.107.143.10 with SMTP id r10mr8381827iod.172.1505497160399; Fri, 15 Sep 2017 10:39:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Fri, 15 Sep 2017 10:38:57 -0700 (PDT) In-Reply-To: <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Fri, 15 Sep 2017 10:38:57 -0700 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c060ade753fe005593ddf09" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:39:23 -0000 --94eb2c060ade753fe005593ddf09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 15, 2017 at 10:30 AM, Templin, Fred L wrote: > > =C3=98 My understanding is that this is about simple hosts, and not ho= sts > that act as routers. > > =C3=98 Hosts can send Destination Unreachable =E2=80=93 Port Unreachab= le; they > cannot send > > =C3=98 Destination Unreachable =E2=80=93 Address Unreachable except to= their own > local > > =C3=98 applications. > Right. Then the attack that you are theorizing will not cause any unreachables to be sent, and that's fine. I disagree. If it's a host, it will just silently drop those packets. Such > an attack can do no more damage than a flood of packets to the host's own > address, and in most cases it will do much less. > > > > =C3=98 A flood of packets to the hosts=E2=80=99s own address will resu= lt in > Destination Unreachable > > =C3=98 Port Unreachable messages. This will cause a legitimate source= to > cease sending > > =C3=98 packets to the unreachable port. > Sure. But you were talking about DOS attacks, and those are neither legitimate sources nor likely to stop sending packets in response to unreachable errors :-) --94eb2c060ade753fe005593ddf09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 15, 2017 at 10:30 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:=C2=A0

=C3=98=C2=A0= =C2=A0=C2=A0 My understanding is that this is= about simple hosts, and not hosts that act as routers.

=C3=98=C2=A0= =C2=A0=C2=A0 Hosts can send Destination Unrea= chable =E2=80=93 Port Unreachable; they cannot send

=C3=98=C2=A0= =C2=A0=C2=A0 Destination Unreachable =E2=80= =93 Address Unreachable except to their own local

=C3=98=C2=A0= =C2=A0=C2=A0 applications.

Right. Then the attack = that you are theorizing will not cause any unreachables to be sent, and tha= t's fine.

I disagree. If it's a host, it will just silentl= y drop those packets. Such an attack can do no more damage than a flood of = packets to the host's own address, and in most cases it will do much le= ss.

=C2=A0

=C3=98=C2=A0= =C2=A0=C2=A0 A flood of packets to the hosts= =E2=80=99s own address will result in Destination Unreachable=

=C3=98=C2=A0= =C2=A0=C2=A0 Port Unreachable messages. This = will=C2=A0 cause a legitimate source to cease sending<= /p>

=C3=98=C2=A0= =C2=A0=C2=A0 packets to the unreachable port.=

Sure. But you were talking about DOS attacks, and those = are neither legitimate sources nor likely to stop sending packets in respon= se to unreachable errors :-)
--94eb2c060ade753fe005593ddf09-- From nobody Fri Sep 15 10:51:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7B7133039 for ; Fri, 15 Sep 2017 10:51:53 -0700 (PDT) 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_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 yAnHoTWfFOUA for ; Fri, 15 Sep 2017 10:51:52 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEEA01326F3 for ; Fri, 15 Sep 2017 10:51:52 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 435A6B8E for ; Fri, 15 Sep 2017 17:51:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWFO5AulrFVf for ; Fri, 15 Sep 2017 12:51:52 -0500 (CDT) Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id D067B850 for ; Fri, 15 Sep 2017 12:51:51 -0500 (CDT) Received: by mail-lf0-f72.google.com with SMTP id l196so2373366lfl.2 for ; Fri, 15 Sep 2017 10:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lLFGhedajtMZZn466aYVkIuiKOVjhN0VxWRRq+VAikg=; b=kSJHlAY1eFrmAZtFx1u/rrD4q+AsrDodjiKWvW27go1F8xwkaqbWj8IC1zne1hoJvc Y2h2Rv0GW35f27wn4YcNh4BobcJQPs5ILAJyJ7f2kAiY2StvUbCmwPNSJEP/dtkUYa3D +s7W1ml92HIqzbUo5fGPRUwBo+mO3ILE7V2xKui/0rhpj/Yt8QujWcxfihZ4UeUipyDU FrerYCwWjSxsdJ5NfmUS5JGcRpG6rVC3nrC3ly5OJWH4ywYd/O4ghw87cMATb+fomaQX 58HldrwQ21M1SzFWWyZKOEObEAXoEVmaf7XdTDDVHJ5arLkyKZ94CWzkeLmdOBzbbFmp JnSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lLFGhedajtMZZn466aYVkIuiKOVjhN0VxWRRq+VAikg=; b=pYwByAqWp77tN9NhQEFBOu1JS+4gFSEDhzH6Jx4wBSbtkjR/bQex0nMM+E5iBNh5rM xoWELkGdcb3eCJHFKOjHajWUHVylfThqLkA32NNWx1d+3Dn6slVINj1QWyegFs6T7Jhl 8e9U1Sk2hPB2hASgrgfeup2hasStmQKQWyw6oItTSda2OXPGghEocHIiJCMIGkniKPWN qjjkTF7oRQ2ebh06Kl3WdEmhuMae2LicmK2lrEPPcSgnDOOmLhBJW4KEwceL4K2XAgwT um4ubGuymDYs8OBIH7aRJ1CrBTSNnj2XE+mA04gZladvriRpAcPpys9Fyb4nwR0veTwC 5xBQ== X-Gm-Message-State: AHPjjUiBKpqbvctl7bUP7ux7ZXbZotG7pawavcWMwnPbjANbzd5S4o91 XnPiZUdPXH3fDC7HX+RS/hPqFXU2JLqjJQ78m5y4QlmAUZQ6KO1NMVYT4NoFTPP3GM94bxuL5+Y ovYyJFgOBVIkT5czot2PM5KZhjQ== X-Received: by 10.25.147.142 with SMTP id w14mr1137147lfk.32.1505497909863; Fri, 15 Sep 2017 10:51:49 -0700 (PDT) X-Google-Smtp-Source: AOwi7QCYam6GabtmP6+yRXPrLxdv6h8Z7kRrgqcUFJSkc9kW/jGl5uS9Pn9qPY1J4v133lZXfgT0WZDw5WeKrR0jYhM= X-Received: by 10.25.147.142 with SMTP id w14mr1137137lfk.32.1505497909642; Fri, 15 Sep 2017 10:51:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Fri, 15 Sep 2017 10:51:48 -0700 (PDT) In-Reply-To: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: David Farmer Date: Fri, 15 Sep 2017 12:51:48 -0500 Message-ID: To: Lorenzo Colitti Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="f403045f4cbc1d6d8005593e0c42" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 17:51:54 -0000 --f403045f4cbc1d6d8005593e0c42 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 12:18 PM, Lorenzo Colitti wrote: > On Fri, Sep 15, 2017 at 7:40 AM, David Farmer wrote: >> >> >> When the First Hop Provider Router sends a solicited RA response, or >> periodically sends unsolicited RAs, the RA MUST be sent only to the >> subscriber that has been assigned the Unique IPv6 prefix contained in the >> RA. This is achieved by sending a multicast RA response or unsolicited RAs >> to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6, >> but instead of using the link-layer multicast address associated with the >> all-nodes group, the link-layer unicast address of the subscriber that has >> been assigned the Unique IPv6 prefix contained in the RA MUST be used as >> the link-layer destination RFC6085 [RFC6085]. Or, optionally in some >> cases, a unicast RA response could be sent as detailed in [RFC4861] section >> 6.2.6, nevertheless unsolicited RAs are always sent to the all-nodes group. >> >> > That would help, yes. I would replace "unicast RA response" with > "solicited RAs" but otherwise LGTM. > Ok how about this then, as the word "unicast" does need to be in the sentence someplace, otherwise how do you distinguish it from the option above, or find the right part of section 6.2.6 for the details; When the First Hop Provider Router sends a solicited RA response, or periodically sends unsolicited RAs, the RA MUST be sent only to the subscriber that has been assigned the Unique IPv6 prefix contained in the RA. This is achieved by sending a solicited RA response or unsolicited RAs to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6, but instead of using the link-layer multicast address associated with the all-nodes group, the link-layer unicast address of the subscriber that has been assigned the Unique IPv6 prefix contained in the RA MUST be used as the link-layer destination RFC6085 [RFC6085]. Or, optionally in some cases, a solicited RA response could be sent unicast as detailed in [RFC4861] section 6.2.6, nevertheless unsolicited RAs are always sent to the all-nodes group. -- =============================================== 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 =============================================== --f403045f4cbc1d6d8005593e0c42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 15, 2017 at 12:18 PM, Lorenzo Colitti <= ;lorenzo@google.com= > wrote:
On = Fri, Sep 15, 2017 at 7:40 AM, David Farmer <farmer@umn.edu> wro= te:

When t= he First Hop Provider Router sends a solicited RA response, or periodically= sends unsolicited RAs, the RA MUST be sent only to the subscriber that has= been assigned the Unique IPv6 prefix contained in the RA. This is achieved= by sending a multicast RA response or unsolicited RAs to the all-nodes gro= up, as detailed in [RFC4861] section 6.2.4 and 6.2.6, but instead of using = the link-layer multicast address associated with the all-nodes group, the l= ink-layer unicast address of the subscriber that has been assigned the Uniq= ue IPv6 prefix contained in the RA MUST be used as the link-layer destinati= on RFC6085 [RFC6085].=C2=A0 Or, optionally in some cases, a unicast RA resp= onse could be sent as detailed in [RFC4861] section 6.2.6, nevertheless uns= olicited RAs are always sent to the all-nodes group.

That would help, yes. I would replace "un= icast RA response" with "solicited RAs" but otherwise LGTM.<= /div>

Ok how about this then, as the word "unicast" does need t= o be in the sentence someplace, otherwise how do you distinguish it from th= e option above, or find the right part of section 6.2.6 for the details;=C2= =A0

When the First Hop Provider Router= sends a solicited RA response, or periodically sends unsolicited RAs, the = RA MUST be sent only to the subscriber that has been assigned the Unique IP= v6 prefix contained in the RA. This is achieved by sending a solicited=C2= =A0RA response or unsolicited RAs to the all-nodes group, as detailed in [R= FC4861] section 6.2.4 and 6.2.6, but instead of using the link-layer multic= ast address associated with the all-nodes group, the link-layer unicast add= ress of the subscriber that has been assigned the Unique IPv6 prefix contai= ned in the RA MUST be used as the link-layer destination RFC6085 [RFC6085].= Or, optionally in some cases, a solicited=C2=A0RA response could be sent u= nicast as detailed in [RFC4861] section 6.2.6, nevertheless unsolicited RAs= are always sent to the all-nodes group.

--
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
Network= ing & Telecommunication Services
Office of Information TechnologyUniversity of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2= =A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0= =C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
--f403045f4cbc1d6d8005593e0c42-- From nobody Fri Sep 15 11:22:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D20B133453 for ; Fri, 15 Sep 2017 11:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8azpq4irOhAb for ; Fri, 15 Sep 2017 11:22:29 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0171330A9 for ; Fri, 15 Sep 2017 11:22:28 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id i6so1931807ywc.9 for ; Fri, 15 Sep 2017 11:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BEJjObvLEVWQWyg7ZLlqsype4Ahn/vYvuPKJTMK4sww=; b=Rh2VPf9sa+dN4A3pymHRD9EV1tUlZBMts7z07aWwqKNYsr/BmBWVT8EH31/ugosu6d TLck2IhqSPmnDSWwAHks2xNrSgG6sj3GyTUcnAFDP53imof2q3YEAYMa3HAFRimAmEO3 t2M8EWYT9G6LAgJfwOnifuMt/Km9pRmVq2eqgw8GXDjFWqdXqplaYOwhQKCU9ETsk7Ms NoN4prykr9R2+qdzCSTWcOsW0MXExYP4NckbX5PPGVzQiy4sy4sRTyQfEBZZLYzx7mhY nyVjlGT78/xVPmdodnD7nmDWTvuLywszGYyghkE6Za7XGJ6vMd6LewFa/PreJq3CYxX+ L8fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BEJjObvLEVWQWyg7ZLlqsype4Ahn/vYvuPKJTMK4sww=; b=Sc6+lMRXHie08qVISd7CP6/g3LWzdpf1mFRR363gLlMTEU78z4j9YLZWThneSGUEjE AYNmY3SdSPlPRzj/5BxJhLMm1FsfF6m8GSptZyoccP3NzoefLLtkORyhlFzzCHAcS/iw psD8zDWsNBUU2BUnKe994xGDjgYqt7NhaxO6IzaZizSWzYj5gOo04Vnb9XRdGLfCNRPX 8aqqt6FR7tCjH1txNDg6/YkEH+r99LxgKgpcrUGGuKvcf3sq/ajpDPeRUIl838oClzvp 4nLuunB0+DkTjVsBMQdDKgKyPcgNUmSNo18F76DBbCGQ7OGARtnXWnH3ZgdoLA+Ucnph RVvw== X-Gm-Message-State: AHPjjUhoMK5d1N0bgwxvGo/PYSwE/DZWbuB48h/P/PIVW9Z/NeWWfT53 0sUTxg2V/9La6umR/c22mcIe8Gdf+9Xb4PGRBXyiUA== X-Google-Smtp-Source: ADKCNb4CLerXmEIGfHnxtap48p002GNKprHa6WSq+NoRVg4d0SQvJkdia2/cP/uLr4fcdRtJpo5x0R8hfRwobbpldz4= X-Received: by 10.129.153.81 with SMTP id q78mr22403643ywg.133.1505499747851; Fri, 15 Sep 2017 11:22:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Fri, 15 Sep 2017 11:22:07 -0700 (PDT) In-Reply-To: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: Lorenzo Colitti Date: Fri, 15 Sep 2017 11:22:07 -0700 Message-ID: To: David Farmer Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0b8290ae890b05593e7931" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 18:22:30 -0000 --94eb2c0b8290ae890b05593e7931 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 10:51 AM, David Farmer wrote: > Ok how about this then, as the word "unicast" does need to be in the > sentence someplace, otherwise how do you distinguish it from the option > above, or find the right part of section 6.2.6 for the details; > > When the First Hop Provider Router sends a solicited RA response, or > periodically sends unsolicited RAs, the RA MUST be sent only to the > subscriber that has been assigned the Unique IPv6 prefix contained in the > RA. This is achieved by sending a solicited RA response or unsolicited RAs > to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6, > but instead of using the link-layer multicast address associated with the > all-nodes group, the link-layer unicast address of the subscriber that has > been assigned the Unique IPv6 prefix contained in the RA MUST be used as > the link-layer destination RFC6085 [RFC6085]. Or, optionally in some cases, > a solicited RA response could be sent unicast as detailed in [RFC4861] > section 6.2.6, nevertheless unsolicited RAs are always sent to the > all-nodes group. > > It's a bit confusing to say "unicast" in both options. How about saying, "a solicited response could be sent unicast to the link-local address of the host as detailed in [RFC4861] section 6.2.6"? --94eb2c0b8290ae890b05593e7931 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 15, 2017 at 10:51 AM, David Farmer <farmer@umn.edu> wro= te:
<= div class=3D"gmail_extra">
Ok how about this then= , as the word "unicast" does need to be in the sentence someplace= , otherwise how do you distinguish it from the option above, or find the ri= ght part of section 6.2.6 for the details;=C2=A0

When the First Hop Provider Router sends a solicited RA response= , or periodically sends unsolicited RAs, the RA MUST be sent only to the su= bscriber that has been assigned the Unique IPv6 prefix contained in the RA.= This is achieved by sending a solicited=C2=A0RA response or unsolicited RA= s to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6,= but instead of using the link-layer multicast address associated with the = all-nodes group, the link-layer unicast address of the subscriber that has = been assigned the Unique IPv6 prefix contained in the RA MUST be used as th= e link-layer destination RFC6085 [RFC6085]. Or, optionally in some cases, a= solicited=C2=A0RA response could be sent unicast as detailed in [RFC4861] = section 6.2.6, nevertheless unsolicited RAs are always sent to the all-node= s group.

It's = a bit confusing to say "unicast" in both options. How about sayin= g, "a solicited response could be sent unicast to the link-local addre= ss of the host as detailed in [RFC4861] section 6.2.6"?
--94eb2c0b8290ae890b05593e7931-- From nobody Fri Sep 15 11:55:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D20132D7B for ; Fri, 15 Sep 2017 11:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 WWbC-wCqzwBA for ; Fri, 15 Sep 2017 11:55:04 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A75B132D8A for ; Fri, 15 Sep 2017 11:55:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8FIt3UA029870; Fri, 15 Sep 2017 11:55:03 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8FIt0Rm029736 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Sep 2017 11:55:00 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Sep 2017 11:54:59 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 15 Sep 2017 11:54:59 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0R353fXvPDrEeoXyoh+k1EZqK2AYpwgAClIID//4rzsIAAd8+A//+K8tCAAHjkgP//nihQ Date: Fri, 15 Sep 2017 18:54:59 +0000 Message-ID: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_cf26a5eb91324ada8adbae5569fa37e6XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 18:55:06 -0000 --_000_cf26a5eb91324ada8adbae5569fa37e6XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGlkZW50aWZpZWQgYSBEb1MgdmVjdG9yIHRoYXQgY2FuIGJlIG1pdGlnYXRlZCBpZiB0 aGUgcm91dGVyIHVzZXMgYWRkcmVzcw0KcmVzb2x1dGlvbiB0byBwcm90ZWN0IHRoZSBob3N0LiBJ ZiBpdCBkb2VzIHRoYXQsIHRoZSByb3V0ZXIgU0hPVUxEIHNlbmQgRFVzLg0KDQpGcmVkDQoNCkZy b206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNlbnQ6IEZy aWRheSwgU2VwdGVtYmVyIDE1LCAyMDE3IDEwOjM5IEFNDQpUbzogVGVtcGxpbiwgRnJlZCBMIDxG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZp eC1wZXItaG9zdC0wOS50eHQNCg0KT24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgMTA6MzAgQU0sIFRl bXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KDQo+ICAgIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhh dCB0aGlzIGlzIGFib3V0IHNpbXBsZSBob3N0cywgYW5kIG5vdCBob3N0cyB0aGF0IGFjdCBhcyBy b3V0ZXJzLg0KDQo+ICAgIEhvc3RzIGNhbiBzZW5kIERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIOKA kyBQb3J0IFVucmVhY2hhYmxlOyB0aGV5IGNhbm5vdCBzZW5kDQoNCj4gICAgRGVzdGluYXRpb24g VW5yZWFjaGFibGUg4oCTIEFkZHJlc3MgVW5yZWFjaGFibGUgZXhjZXB0IHRvIHRoZWlyIG93biBs b2NhbA0KDQo+ICAgIGFwcGxpY2F0aW9ucy4NClJpZ2h0LiBUaGVuIHRoZSBhdHRhY2sgdGhhdCB5 b3UgYXJlIHRoZW9yaXppbmcgd2lsbCBub3QgY2F1c2UgYW55IHVucmVhY2hhYmxlcyB0byBiZSBz ZW50LCBhbmQgdGhhdCdzIGZpbmUuDQoNCkkgZGlzYWdyZWUuIElmIGl0J3MgYSBob3N0LCBpdCB3 aWxsIGp1c3Qgc2lsZW50bHkgZHJvcCB0aG9zZSBwYWNrZXRzLiBTdWNoIGFuIGF0dGFjayBjYW4g ZG8gbm8gbW9yZSBkYW1hZ2UgdGhhbiBhIGZsb29kIG9mIHBhY2tldHMgdG8gdGhlIGhvc3QncyBv d24gYWRkcmVzcywgYW5kIGluIG1vc3QgY2FzZXMgaXQgd2lsbCBkbyBtdWNoIGxlc3MuDQoNCg0K PiAgICBBIGZsb29kIG9mIHBhY2tldHMgdG8gdGhlIGhvc3Rz4oCZcyBvd24gYWRkcmVzcyB3aWxs IHJlc3VsdCBpbiBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZQ0KDQo+ICAgIFBvcnQgVW5yZWFjaGFi bGUgbWVzc2FnZXMuIFRoaXMgd2lsbCAgY2F1c2UgYSBsZWdpdGltYXRlIHNvdXJjZSB0byBjZWFz ZSBzZW5kaW5nDQoNCj4gICAgcGFja2V0cyB0byB0aGUgdW5yZWFjaGFibGUgcG9ydC4NClN1cmUu IEJ1dCB5b3Ugd2VyZSB0YWxraW5nIGFib3V0IERPUyBhdHRhY2tzLCBhbmQgdGhvc2UgYXJlIG5l aXRoZXIgbGVnaXRpbWF0ZSBzb3VyY2VzIG5vciBsaWtlbHkgdG8gc3RvcCBzZW5kaW5nIHBhY2tl dHMgaW4gcmVzcG9uc2UgdG8gdW5yZWFjaGFibGUgZXJyb3JzIDotKQ0K --_000_cf26a5eb91324ada8adbae5569fa37e6XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubS0x OTk4ODk4NDc5MDMzNDA0NDYxbXNvbGlzdHBhcmFncmFwaCwgbGkubS0xOTk4ODk4NDc5MDMzNDA0 NDYxbXNvbGlzdHBhcmFncmFwaCwgZGl2Lm0tMTk5ODg5ODQ3OTAzMzQwNDQ2MW1zb2xpc3RwYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8tMTk5ODg5ODQ3OTAzMzQwNDQ2MW1zb2xpc3RwYXJh Z3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgaGF2ZSBpZGVudGlm aWVkIGEgRG9TIHZlY3RvciB0aGF0IGNhbiBiZSBtaXRpZ2F0ZWQgaWYgdGhlIHJvdXRlciB1c2Vz IGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+cmVzb2x1dGlvbiB0byBwcm90ZWN0IHRoZSBob3N0 LiBJZiBpdCBkb2VzIHRoYXQsIHRoZSByb3V0ZXIgU0hPVUxEIHNlbmQgRFVzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExvcmVuem8g Q29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBG cmlkYXksIFNlcHRlbWJlciAxNSwgMjAxNyAxMDozOSBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxp biwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gdjZvcHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDkudHh0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgMTA6MzAgQU0sIFRlbXBsaW4sIEZy ZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iIHRhcmdl dD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0tMTk5ODg5ODQ3OTAzMzQwNDQ2MW1zb2xp c3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldp bmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5NeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyBpcyBhYm91 dCBzaW1wbGUgaG9zdHMsIGFuZCBub3QgaG9zdHMgdGhhdCBhY3QgYXMgcm91dGVycy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS0xOTk4ODk4NDc5MDMzNDA0NDYxbXNvbGlzdHBh cmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rp bmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkhvc3RzIGNhbiBzZW5kIERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIOKA kyBQb3J0IFVucmVhY2hhYmxlOyB0aGV5IGNhbm5vdCBzZW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Im0tMTk5ODg5ODQ3OTAzMzQwNDQ2MW1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0 OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5EZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSDigJMgQWRkcmVzcyBVbnJlYWNoYWJsZSBleGNlcHQg dG8gdGhlaXIgb3duIGxvY2FsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tMTk5 ODg5ODQ3OTAzMzQwNDQ2MW1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hcHBsaWNhdGlvbnMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UmlnaHQuIFRoZW4gdGhlIGF0dGFjayB0aGF0IHlvdSBhcmUgdGhlb3JpemluZyB3aWxs IG5vdCBjYXVzZSBhbnkgdW5yZWFjaGFibGVzIHRvIGJlIHNlbnQsIGFuZCB0aGF0J3MgZmluZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkkgZGlzYWdyZWUuIElmIGl0J3MgYSBob3N0LCBpdCB3aWxsIGp1c3Qgc2lsZW50bHkgZHJvcCB0 aG9zZSBwYWNrZXRzLiBTdWNoIGFuIGF0dGFjayBjYW4gZG8gbm8gbW9yZSBkYW1hZ2UgdGhhbiBh IGZsb29kIG9mIHBhY2tldHMgdG8gdGhlIGhvc3QncyBvd24gYWRkcmVzcywgYW5kIGluIG1vc3Qg Y2FzZXMgaXQNCiB3aWxsIGRvIG11Y2ggbGVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTE5OTg4OTg0NzkwMzM0MDQ0NjFtc29saXN0cGFy YWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGlu Z3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+QSBmbG9vZCBvZiBwYWNrZXRzIHRvIHRoZSBob3N0c+KAmXMgb3duIGFk ZHJlc3Mgd2lsbCByZXN1bHQgaW4gRGVzdGluYXRpb24gVW5yZWFjaGFibGU8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0ibS0xOTk4ODk4NDc5MDMzNDA0NDYxbXNvbGlzdHBhcmFncmFw aCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2Nv bG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlBvcnQgVW5yZWFjaGFibGUgbWVzc2FnZXMuIFRoaXMgd2lsbCZuYnNwOyBjYXVz ZSBhIGxlZ2l0aW1hdGUgc291cmNlIHRvIGNlYXNlIHNlbmRpbmc8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ibS0xOTk4ODk4NDc5MDMzNDA0NDYxbXNvbGlzdHBhcmFncmFwaCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPnBhY2tldHMgdG8gdGhlIHVucmVhY2hhYmxlIHBvcnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VyZS4gQnV0IHlvdSB3ZXJlIHRhbGtpbmcg YWJvdXQgRE9TIGF0dGFja3MsIGFuZCB0aG9zZSBhcmUgbmVpdGhlciBsZWdpdGltYXRlIHNvdXJj ZXMgbm9yIGxpa2VseSB0byBzdG9wIHNlbmRpbmcgcGFja2V0cyBpbiByZXNwb25zZSB0byB1bnJl YWNoYWJsZSBlcnJvcnMgOi0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_cf26a5eb91324ada8adbae5569fa37e6XCH150608nwnosboeingcom_-- From nobody Fri Sep 15 12:03:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9E51341D3 for ; Fri, 15 Sep 2017 12:03:43 -0700 (PDT) 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_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 52tb8GU-2lNF for ; Fri, 15 Sep 2017 12:03:42 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33A8913352D for ; Fri, 15 Sep 2017 12:03:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id BD29C209 for ; Fri, 15 Sep 2017 19:03:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHkr2IV45x1M for ; Fri, 15 Sep 2017 14:03:41 -0500 (CDT) Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 2CBCC1C6 for ; Fri, 15 Sep 2017 14:03:40 -0500 (CDT) Received: by mail-lf0-f69.google.com with SMTP id q132so2490545lfe.1 for ; Fri, 15 Sep 2017 12:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=13gT5oTjQX/ZeC7X3RLAH+EqY8vcnFD43EG7C7EcgYg=; b=jXiZKV6upXvyfKHwS427cLL9bzvZm4hNM6OxvqpCHIa5aZxP1XqH9DCpkf4YaJBNv3 C0Zt+oMqqNGQu3rfy7qekAIcrh/zWZFgeoVdPUiWB2xIKRmG1lOJPSVPVfBQ5Pkt+DX5 vImMMs/x0d7ZqvPUfN04o16u1LfCmHPCeHQ7YnEut3dxIX+hpICDb9PSd+frgIj8fn2L 1NbCw1YVh2Za/IM1oeTe08x2ld4YXwup6lUt1BYplFTZBijbYdX4RA14TCU9k5S8CVh6 BWJ64qlu4Ul4MCJIsNzLK4Qn/P5bywhsMLro7FFeUgiRwqKNL0R7xtJO+97Cw7ubdsUn LpMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=13gT5oTjQX/ZeC7X3RLAH+EqY8vcnFD43EG7C7EcgYg=; b=eFIUwG+5oGpmXfg6U6ij32p4UO24T9OruvNabkQaJ+ZB+uncI6Wz7P8OzogdadjSJE m/9+ZDbTOJKSxum/wzZn59e+tkSIaK3IXeYTTNrXhjpc5O5HMRBDhQQ2QLnv8H5lZlq0 Abz8BX3fLTbsFrj09I781jhjvJJzQLtZQoXXbqoUuJcvRldeEGxFVSHe0ECz/jDJZvi4 OGfxzOOIhR3EuY6TCv6Dg+V1vS4C0oqeQTOy9c+RxQ8FGiPo35qWcCx9g4EAaeaFbo1e Pn3AY/xf+y03K69kDRJJtyGl0WPaqTXoHgYsAk74+t3GrnSCuaIMcFNwkzeNrjZr1Ful 96Kg== X-Gm-Message-State: AHPjjUgmPcwzy/VvFO8cB9GqoPLC8y4OxZusaDwpVKn2lUbwHS2TkC8j zTeQFUCw2QOT5CNsL7LCybyUkW691ZWzIolkZ7XNUyaSL/nG+lHownW07fkFPXG4kBIMMIpUHDH Kdchv0u8x31vQ4oJ++YT860kCig== X-Received: by 10.25.147.142 with SMTP id w14mr1209272lfk.32.1505502219403; Fri, 15 Sep 2017 12:03:39 -0700 (PDT) X-Google-Smtp-Source: AOwi7QBxY3FM4tK5bV2IU9d9st6UHq8ZwtdqC4COdvNXPpytiByhUWDpcsUEL5P8GZb/YRp7C/wet4W1IyNGt6i+FIQ= X-Received: by 10.25.147.142 with SMTP id w14mr1209260lfk.32.1505502218964; Fri, 15 Sep 2017 12:03:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Fri, 15 Sep 2017 12:03:38 -0700 (PDT) In-Reply-To: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <583C8B13-6947-405A-959C-CC8A19A58C3D@nokia.com> From: David Farmer Date: Fri, 15 Sep 2017 14:03:38 -0500 Message-ID: To: Lorenzo Colitti Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="f403045f4cbcf88a6605593f0cd7" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 19:03:43 -0000 --f403045f4cbcf88a6605593f0cd7 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 1:22 PM, Lorenzo Colitti wrote: > On Fri, Sep 15, 2017 at 10:51 AM, David Farmer wrote: > >> Ok how about this then, as the word "unicast" does need to be in the >> sentence someplace, otherwise how do you distinguish it from the option >> above, or find the right part of section 6.2.6 for the details; >> >> When the First Hop Provider Router sends a solicited RA response, or >> periodically sends unsolicited RAs, the RA MUST be sent only to the >> subscriber that has been assigned the Unique IPv6 prefix contained in the >> RA. This is achieved by sending a solicited RA response or unsolicited RAs >> to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6, >> but instead of using the link-layer multicast address associated with the >> all-nodes group, the link-layer unicast address of the subscriber that has >> been assigned the Unique IPv6 prefix contained in the RA MUST be used as >> the link-layer destination RFC6085 [RFC6085]. Or, optionally in some cases, >> a solicited RA response could be sent unicast as detailed in [RFC4861] >> section 6.2.6, nevertheless unsolicited RAs are always sent to the >> all-nodes group. >> >> > It's a bit confusing to say "unicast" in both options. How about saying, > "a solicited response could be sent unicast to the link-local address of > the host as detailed in [RFC4861] section 6.2.6"? > Ok, I think that will work, it lets you find the right part of section 6.2.6, but is sufficiently distinguished from the link-layer unicast discussion above it. however a few minor tweaks, we're using the term subscriber not host. When the First Hop Provider Router sends a solicited RA response, or periodically sends unsolicited RAs, the RA MUST be sent only to the subscriber that has been assigned the Unique IPv6 prefix contained in the RA. This is achieved by sending a solicited RA response or unsolicited RAs to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6, but instead of using the link-layer multicast address associated with the all-nodes group, the link-layer unicast address of the subscriber that has been assigned the Unique IPv6 prefix contained in the RA MUST be used as the link-layer destination RFC6085 [RFC6085]. Or, optionally in some cases, a solicited RA response could be sent unicast to the link-local address of the subscriber as detailed in [RFC4861] section 6.2.6, nevertheless unsolicited RAs are always sent to the all-nodes group. The RA contains two important parameters for the subscriber to consume: ... -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f403045f4cbcf88a6605593f0cd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 15, 2017 at 1:22 PM, Lorenzo Colitti <= lorenzo@google.com<= /a>> wrote:
=
On F= ri, Sep 15, 2017 at 10:51 AM, David Farmer <farmer@umn.edu> wro= te:
<= div class=3D"gmail_extra">
Ok how about this then= , as the word "unicast" does need to be in the sentence someplace= , otherwise how do you distinguish it from the option above, or find the ri= ght part of section 6.2.6 for the details;=C2=A0

When the First Hop Provider Router sends a solicited RA response= , or periodically sends unsolicited RAs, the RA MUST be sent only to the su= bscriber that has been assigned the Unique IPv6 prefix contained in the RA.= This is achieved by sending a solicited=C2=A0RA response or unsolicited RA= s to the all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6,= but instead of using the link-layer multicast address associated with the = all-nodes group, the link-layer unicast address of the subscriber that has = been assigned the Unique IPv6 prefix contained in the RA MUST be used as th= e link-layer destination RFC6085 [RFC6085]. Or, optionally in some cases, a= solicited=C2=A0RA response could be sent unicast as detailed in [RFC4861] = section 6.2.6, nevertheless unsolicited RAs are always sent to the all-node= s group.

It's = a bit confusing to say "unicast" in both options. How about sayin= g, "a solicited response could be sent unicast to the link-local addre= ss of the host as detailed in [RFC4861] section 6.2.6"?

Ok, I think that wi= ll work, it lets you find the right part of section 6.2.6, but is sufficien= tly distinguished from the link-layer unicast discussion above it. however = a few minor tweaks, we're using the term subscriber not host.

<= div class=3D"gmail_extra">When the First Hop Provider Router sends a solici= ted RA response, or periodically sends unsolicited RAs, the RA MUST be sent= only to the subscriber that has been assigned the Unique IPv6 prefix conta= ined in the RA. This is achieved by sending a solicited=C2=A0RA response or= unsolicited RAs to the all-nodes group, as detailed in [RFC4861] section 6= .2.4 and 6.2.6, but instead of using the link-layer multicast address assoc= iated with the all-nodes group, the link-layer unicast address of the subsc= riber that has been assigned the Unique IPv6 prefix contained in the RA MUS= T be used as the link-layer destination RFC6085 [RFC6085]. Or, optionally i= n some cases, a solicited RA response could be sent unicast to the link-loc= al address of the subscriber=C2=A0as detailed in [RFC4861] section 6.2.6, n= evertheless unsolicited RAs are always sent to the all-nodes group.

=
The RA contains= two important parameters for the subscriber to consume: ...
--
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dav= id Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.eduNetworking & Telecommunication Services
Office of Information Tech= nology
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
--f403045f4cbcf88a6605593f0cd7-- From nobody Fri Sep 15 12:26:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20021341E3 for ; Fri, 15 Sep 2017 12:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 z26dXz8qKGOY for ; Fri, 15 Sep 2017 12:26:35 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E2D1341E7 for ; Fri, 15 Sep 2017 12:26:35 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id s62so2036164ywg.0 for ; Fri, 15 Sep 2017 12:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6bHHS7VTYl56+dCPUx8mcoSpQ1l0SP6qz91irTdB+pI=; b=Tg9Vn1xxf3ESUg0sLnZBgSvYN5hY7ndax2Q8JxWQC2agUGP9NlLbHZZ/FK3Y5MoBAL CzXQahFvnF6bE08SmWFo/Tmto1cY/M3RRvevLdMKa3ZLh/7F/bElkkJE0epQWv8/isd3 Vny3TRKbgTznaVBPLjL/c0FturohMZAJ0kHNyQ50RMuMxfY+sDI3mE6oH2Qh/tWQl+C3 wifB1WhnRmYmSlSZRMPbYLCKuFbPA1TmnuPSN9mjgaUsxRsgk4QKH7GAl0j7M/vF3Oa4 f5+SaA+HX8L/xkfFMImgOqEVo+g6EzdJBMQKSF8/+bti+rFL2Z7500ihEa+zw9TlYX8U 3xgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6bHHS7VTYl56+dCPUx8mcoSpQ1l0SP6qz91irTdB+pI=; b=bn3XMynH8i2Psy86Bun6XyBpk2lYDd7BLEY/mfzDw9ablrPDMHp28GP6xcy3H3NZ5k PUQiaHyjv+cAHADhTxee+SHDb0os1xi/r0zzEIeNw4KGGuGh0nMCkX5HatKkK4xS3cRg CnpBDr9raRl5rbcw5mlvszRQISphvMLY8ecswCMbxXCmbnhMMTT0CqcYSLs0Oii2W/wN 8Wg8CL/AmqwZR0Al3uAxx1K3tHMzPU0vPDu+mIUp7dxlPgt2xDNoWHSK0hDMaZWkn06x Vzin5Vt4NHVIrgKe4G1/ZO8ZbecK6pGx5fmoxfil1lLzsp6Z9iUI/AupsDeRMiZ0dkZP rcYA== X-Gm-Message-State: AHPjjUh/37mMzerIZ0TC8sRRH8u5fx4u4GNe6/H0epJuZK0a3YtO8FuK B2pw21oqCGh/g8e5AkUJLpHw1zGXpo42THsO7whtPw== X-Google-Smtp-Source: AOwi7QCoFIWgUE82XVCpOMhvDVyO/EHlFv8XVPEddTSQrDbryf0ms1gfb3Qtnkqb91BqZZp0wBmXdMjOc8IU6lOPON4= X-Received: by 10.37.116.83 with SMTP id p80mr23074894ybc.34.1505503593656; Fri, 15 Sep 2017 12:26:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Fri, 15 Sep 2017 12:26:12 -0700 (PDT) In-Reply-To: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Fri, 15 Sep 2017 12:26:12 -0700 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a114dafeee90e1805593f5ef7" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 19:26:37 -0000 --001a114dafeee90e1805593f5ef7 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 11:54 AM, Templin, Fred L wrote: > I have identified a DoS vector that can be mitigated if the router uses > address > > resolution to protect the host. If it does that, the router SHOULD send > DUs. > Right. But OTOH, the DoS vector that you found is strictly less damaging than if the DoS targeted one of the host's IP addresses. Also, your suggested mitigation (sending DUs) requires that the router must keep all addresses in its ND cache, and that means that the DoS vector you identified is still a DoS vector, but this time on the router's ND cache. Also, your suggested mitigation creates an additional attack vector: malicious customers can mount an ND cache entry on the router by configuring lots of addresses and arranging to receive traffic on them. This is extremely simple to mount: a host can simply send a trivial 10pps of ping packets (or DNS queries, or...) to each of 100 remote destinations, with each packet coming from a different address. That can cause the router to attempt to create 1000 ND cache entries per second. You might want to try that on some routers and see how badly they fall over. --001a114dafeee90e1805593f5ef7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 15, 2017 at 11:54 AM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:

I have identified a DoS vector that c= an be mitigated if the router uses address

resolution to protect the host. If it= does that, the router SHOULD send DUs.

=

Right. But OTOH, the DoS vector that you found is stric= tly less damaging than if the DoS targeted one of the host's IP address= es.

Also, your suggested mitigation (sending DUs) = requires that the router must keep all addresses in its ND cache, and that = means that the DoS vector you identified is still a DoS vector, but this ti= me on the router's ND cache.

Also, your sugges= ted mitigation creates an additional attack vector: malicious customers can= mount an ND cache entry on the router by configuring lots of addresses and= arranging to receive traffic on them. This is extremely simple to mount: a= host can simply send a trivial 10pps of ping packets (or DNS queries, or..= .) to each of 100 remote destinations, with each packet coming from a diffe= rent address. That can cause the router to attempt to create 1000 ND cache = entries per second. You might want to try that on some routers and see how = badly they fall over.
--001a114dafeee90e1805593f5ef7-- From nobody Fri Sep 15 12:57:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C68133207 for ; Fri, 15 Sep 2017 12:57:39 -0700 (PDT) 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_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 o8XJxk2ApK0E for ; Fri, 15 Sep 2017 12:57:37 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B16B1331F5 for ; Fri, 15 Sep 2017 12:57:37 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id A3839B36 for ; Fri, 15 Sep 2017 19:57:36 +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 RTsKsKLGiod7 for ; Fri, 15 Sep 2017 14:57:36 -0500 (CDT) Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 142D65C2 for ; Fri, 15 Sep 2017 14:57:35 -0500 (CDT) Received: by mail-lf0-f69.google.com with SMTP id h80so2550693lfe.7 for ; Fri, 15 Sep 2017 12:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AXaErIKtescJZfb5Cfv+slZcpZSS2evXjKHDOWOni/k=; b=ofZ5/bU4Fw7k1EGlnUhrytcmGt0y1jgdPTUvgS4QBwIzX4N9MAl8C7/zsZ1bj3p09s BA9CfmLkQi4MIy3BLO4vUXOWyCCFJYIq6MWWoebAljvzwGTyOp9PXk4eoSx2R5EATVMS QOH5RH072bkjCoYl5H13QZgHiekBI72xg3AqtO27qrwkI1pDGA+fzfFWDv5RuAlDHUqX 68mPm6QipyWxi0mk2Wrw4li7zUOBn4YxfQxMaL+fXuf8V5Xl7Xf8sWYZzqE/uxnpM4/v gC+cHLIfOlCsmKZfD8NLC4lQxl6DO4VOo56drJldo/aLv7mwnBp0ghmYEtjIif8Ze7LA R0Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AXaErIKtescJZfb5Cfv+slZcpZSS2evXjKHDOWOni/k=; b=ZgregOHHFmVFfQMKlp72oKOXLp3CCvj93X+ARSs/lCj1Nu47v4JIjx5DZD8mWlFoTh sVZIh8BYqjFQD5lyr6zsvC4cjBiuxOcIyVYFgiMZuC0VLw2QNlmp1BTIB/E80NEnkP+Z zArE1qyMPyjAlP/kRkVP9AVFJV1XCcPx8JmohlLm4PHhNqhDZnFZ7KzT3wRzCBipMl5X GDf7l+AjbmL+w6AMLZAkFwM+ft+4/7VRfwjqePPZoAi1OagiGAOuWNlCnPXX3dbwskVq kBEKYRWZ8zI6stTYD2VdAw3O7d+UmBrUx+e10WIq0B0v1q5IgGA+rFV83C3IdSmfYIss x0pQ== X-Gm-Message-State: AHPjjUhguPCGidszO9kUxexBARO0WwB8KyadC4vp4kBEHJlgCmRS8OdN mr0Fo83o61qWrIjuLFrwOlUvUuN/2vYES0m/Jc2v28J3XaI3A0LLIax/xL7Ss43bpWkqjM50YWj LBBTYoxwV/jT2i56DHE1s0Utjmw== X-Received: by 10.25.89.206 with SMTP id n197mr1074703lfb.52.1505505454582; Fri, 15 Sep 2017 12:57:34 -0700 (PDT) X-Google-Smtp-Source: AOwi7QDiYZRV4h0aR3FPaKwXr13V+ZZ2G+FeV/JvIaCCJTNjyHh4Wkj15E2ByqwaFXn056hwb3GQHlxuDKq0UvWshm0= X-Received: by 10.25.89.206 with SMTP id n197mr1074699lfb.52.1505505454343; Fri, 15 Sep 2017 12:57:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Fri, 15 Sep 2017 12:57:33 -0700 (PDT) In-Reply-To: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> From: David Farmer Date: Fri, 15 Sep 2017 14:57:33 -0500 Message-ID: To: "Templin, Fred L" Cc: Lorenzo Colitti , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a11404efcd0662a05593fcd91" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 19:57:39 -0000 --001a11404efcd0662a05593fcd91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But in order to mitigate one DDOS vector, and not a very typical one for that matter, you eliminate the scaleability advantages provided by not tracking the addresses used within each unique prefix. Furthermore, that and many other DDOS vectors can be detected and mitigated by several other means. I can't think of how else to provide the scaleability advantages from not tracking the addresses used in the unique prefixes. I have routers that can handle several millions of IPv6 routes, but they can only track 250k neighbor associations. Thats is effectively 50K hosts as we see on average 5 neighbor associations per host, I need better neighbor discovery scaleability. I already separate DDOS detection and mittigation, that will cover that more effectively than the one DDOS vector you are talking about. At most noting that DUs are not provided by the First hop router for unused addresses within the unique prefix, seems reasonable so no one is surprised by the behavior. Furthermore, ICMP is by no mean guaranteed to get across the Internet anyway, it's filtered in far too many places. Thanks. On Fri, Sep 15, 2017 at 1:54 PM, Templin, Fred L wrote: > I have identified a DoS vector that can be mitigated if the router uses > address > > resolution to protect the host. If it does that, the router SHOULD send > DUs. > > > > Fred > > > > *From:* Lorenzo Colitti [mailto:lorenzo@google.com] > *Sent:* Friday, September 15, 2017 10:39 AM > *To:* Templin, Fred L > *Cc:* v6ops@ietf.org > *Subject:* Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6- > prefix-per-host-09.txt > > > > On Fri, Sep 15, 2017 at 10:30 AM, Templin, Fred L < > Fred.L.Templin@boeing.com> wrote: > > =C3=98 My understanding is that this is about simple hosts, and not ho= sts > that act as routers. > > =C3=98 Hosts can send Destination Unreachable =E2=80=93 Port Unreachab= le; they > cannot send > > =C3=98 Destination Unreachable =E2=80=93 Address Unreachable except to= their own > local > > =C3=98 applications. > > Right. Then the attack that you are theorizing will not cause any > unreachables to be sent, and that's fine. > > > > I disagree. If it's a host, it will just silently drop those packets. Suc= h > an attack can do no more damage than a flood of packets to the host's own > address, and in most cases it will do much less. > > > > =C3=98 A flood of packets to the hosts=E2=80=99s own address will resu= lt in > Destination Unreachable > > =C3=98 Port Unreachable messages. This will cause a legitimate source= to > cease sending > > =C3=98 packets to the unreachable port. > > Sure. But you were talking about DOS attacks, and those are neither > legitimate sources nor likely to stop sending packets in response to > unreachable errors :-) > > _______________________________________________ > 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 --001a11404efcd0662a05593fcd91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But in order to mitigate one DDOS vector, and not a very t= ypical one for that matter, you eliminate the scaleability advantages provi= ded by not tracking the addresses used within each unique prefix. Furthermo= re, that and many other DDOS vectors can be detected and mitigated by sever= al other means. I can't think of how else to provide the scaleability a= dvantages from not tracking the addresses used in the unique prefixes. =C2= =A0

I have routers that can handle several millions of I= Pv6 routes, but they can only track 250k neighbor associations.=C2=A0 Thats= is effectively=C2=A050K hosts as we see on average 5 neighbor associations= per host, I need better neighbor discovery scaleability.=C2=A0=C2=A0I alre= ady separate DDOS detection and mittigation, that will cover that more effe= ctively than the one DDOS vector you are talking about.

=
At most noting that DUs are not provided by the First hop router= for unused addresses within the unique prefix, seems reasonable so no one = is surprised by the behavior.=C2=A0

Furthermore, I= CMP is by no mean guaranteed to get across the Internet anyway, it's fi= ltered in far too many places.

Thanks.=C2=A0

On Fri, Sep 15, 2017 at 1:54 PM, Templin, Fred L <Fre= d.L.Templin@boeing.com> wrote:

I have identified a DoS vector that can be m= itigated if the router uses address

resolution to protect the host. If it does t= hat, the router SHOULD send DUs.

=C2=A0

Fred

=C2=A0

From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Friday, September 15, 2017 10:39 AM
To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: v6ops@ietf.o= rg
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-p= refix-per-host-09.txt

=C2=A0

On Fri, Sep 15, 2017 at 10:30 AM, Templin, Fred L &l= t;Fred.L.Tem= plin@boeing.com> wrote:=C2=A0

=C3=98=C2=A0=C2= =A0=C2=A0 My understanding is that this is about simple hosts, and not= hosts that act as routers.

=C3=98=C2=A0=C2= =A0=C2=A0 Hosts can send Destination Unreachable =E2=80=93 Port Unreac= hable; they cannot send

=C3=98=C2=A0=C2= =A0=C2=A0 Destination Unreachable =E2=80=93 Address Unreachable except= to their own local

=C3=98=C2=A0=C2= =A0=C2=A0 applications.

Right. Then the attack that you are theorizing will = not cause any unreachables to be sent, and that's fine.

=C2=A0

I disagree. If it's a host, it will just silentl= y drop those packets. Such an attack can do no more damage than a flood of = packets to the host's own address, and in most cases it will do much less.

=C2=A0

=C3=98=C2=A0=C2= =A0=C2=A0 A flood of packets to the hosts=E2=80=99s own address will r= esult in Destination Unreachable

=C3=98=C2=A0=C2= =A0=C2=A0 Port Unreachable messages. This will=C2=A0 cause a legitimat= e source to cease sending

=C3=98=C2=A0=C2= =A0=C2=A0 packets to the unreachable port.

Sure. But you were talking about DOS attacks, and th= ose are neither legitimate sources nor likely to stop sending packets in re= sponse to unreachable errors :-)


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




--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0 Em= ail:farmer@umn.edu
Networking & Telecommunication Services
Of= fice of Information Technology
University of Minnesota=C2=A0=C2=A0
2= 218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Min= neapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a11404efcd0662a05593fcd91-- From nobody Fri Sep 15 14:15:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750D8134216 for ; Fri, 15 Sep 2017 14:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 BoKgYoiwUotn for ; Fri, 15 Sep 2017 14:15:11 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6409133209 for ; Fri, 15 Sep 2017 14:15:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8FLFAWI053563; Fri, 15 Sep 2017 14:15:11 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8FLF6Jp053522 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Sep 2017 14:15:06 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Sep 2017 14:15:06 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 15 Sep 2017 14:15:06 -0700 From: "Templin, Fred L" To: Lorenzo Colitti CC: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0R353fXvPDrEeoXyoh+k1EZqK2AYpwgAClIID//4rzsIAAd8+A//+K8tCAAHjkgP//nihQAA/57gAACzSPwA== Date: Fri, 15 Sep 2017 21:15:06 +0000 Message-ID: <9bc9d9b064154c719960ae6a594240c6@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_9bc9d9b064154c719960ae6a594240c6XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 21:15:13 -0000 --_000_9bc9d9b064154c719960ae6a594240c6XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NClNl bnQ6IEZyaWRheSwgU2VwdGVtYmVyIDE1LCAyMDE3IDEyOjI2IFBNDQpUbzogVGVtcGxpbiwgRnJl ZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2 LXByZWZpeC1wZXItaG9zdC0wOS50eHQNCg0KT24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgMTE6NTQg QU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KSSBoYXZlIGlkZW50aWZpZWQgYSBEb1Mg dmVjdG9yIHRoYXQgY2FuIGJlIG1pdGlnYXRlZCBpZiB0aGUgcm91dGVyIHVzZXMgYWRkcmVzcw0K cmVzb2x1dGlvbiB0byBwcm90ZWN0IHRoZSBob3N0LiBJZiBpdCBkb2VzIHRoYXQsIHRoZSByb3V0 ZXIgU0hPVUxEIHNlbmQgRFVzLg0KDQpSaWdodC4gQnV0IE9UT0gsIHRoZSBEb1MgdmVjdG9yIHRo YXQgeW91IGZvdW5kIGlzIHN0cmljdGx5IGxlc3MgZGFtYWdpbmcgdGhhbiBpZiB0aGUgRG9TIHRh cmdldGVkIG9uZSBvZiB0aGUgaG9zdCdzIElQIGFkZHJlc3Nlcy4NCg0KDQrDmCAgVGhlIGhvc3Qg Y2FuIGFkZHJlc3MgdGhpcyBieSB1c2luZyBwcml2YWN5IGFkZHJlc3Nlcy4NCg0KQWxzbywgeW91 ciBzdWdnZXN0ZWQgbWl0aWdhdGlvbiAoc2VuZGluZyBEVXMpDQoNCg0Kw5ggIEFjdHVhbGx5LCB0 aGUgcHJpbWFyeSBtaXRpZ2F0aW9uIGlzIGZvciB0aGUgcm91dGVyIHRvIGRvIGFkZHJlc3MgcmVz b2x1dGlvbi4gU2VuZGluZyBvcg0KDQrDmCAgbm90IHNlbmRpbmcgRFVzIHdvdWxkIGJlIGRlY2lk ZWQgZm9sbG93aW5nIHN1Y2Nlc3Mgb3IgZmFpbHVyZSBvZiBhZGRyZXNzIHJlc29sdXRpb24uDQoN CnJlcXVpcmVzIHRoYXQgdGhlIHJvdXRlciBtdXN0IGtlZXAgYWxsIGFkZHJlc3NlcyBpbiBpdHMg TkQgY2FjaGUsIGFuZCB0aGF0IG1lYW5zIHRoYXQgdGhlIERvUyB2ZWN0b3IgeW91IGlkZW50aWZp ZWQgaXMgc3RpbGwgYSBEb1MgdmVjdG9yLCBidXQgdGhpcyB0aW1lIG9uIHRoZSByb3V0ZXIncyBO RCBjYWNoZS4NCg0KDQrDmCAgUHJlc3VtYWJseSB0aGUgcm91dGVyIG1haW50YWlucyBhbiBMUlUg Y29sbGVjdGlvbiBvZiBhIGZpbml0ZSBzdXBwbHkgb2YgbmJyIGNhY2hlDQoNCsOYICBlbnRyaWVz IGluc3RlYWQgb2YganVzdCBlYXRpbmcgdXAgYWxsIG9mIGl0cyBtZW1vcnkuDQoNCkFsc28sIHlv dXIgc3VnZ2VzdGVkIG1pdGlnYXRpb24gY3JlYXRlcyBhbiBhZGRpdGlvbmFsIGF0dGFjayB2ZWN0 b3I6IG1hbGljaW91cyBjdXN0b21lcnMgY2FuIG1vdW50IGFuIE5EIGNhY2hlIGVudHJ5IG9uIHRo ZSByb3V0ZXIgYnkgY29uZmlndXJpbmcgbG90cyBvZiBhZGRyZXNzZXMgYW5kIGFycmFuZ2luZyB0 byByZWNlaXZlIHRyYWZmaWMgb24gdGhlbS4gVGhpcyBpcyBleHRyZW1lbHkgc2ltcGxlIHRvIG1v dW50OiBhIGhvc3QgY2FuIHNpbXBseSBzZW5kIGEgdHJpdmlhbCAxMHBwcyBvZiBwaW5nIHBhY2tl dHMgKG9yIEROUyBxdWVyaWVzLCBvci4uLikgdG8gZWFjaCBvZiAxMDAgcmVtb3RlIGRlc3RpbmF0 aW9ucywgd2l0aCBlYWNoIHBhY2tldCBjb21pbmcgZnJvbSBhIGRpZmZlcmVudCBhZGRyZXNzLiBU aGF0IGNhbiBjYXVzZSB0aGUgcm91dGVyIHRvIGF0dGVtcHQgdG8gY3JlYXRlIDEwMDAgTkQgY2Fj aGUgZW50cmllcyBwZXIgc2Vjb25kLiBZb3UgbWlnaHQgd2FudCB0byB0cnkgdGhhdCBvbiBzb21l IHJvdXRlcnMgYW5kIHNlZSBob3cgYmFkbHkgdGhleSBmYWxsIG92ZXIuDQoNCg0Kw5ggIFRoZSBy b3V0ZXIgY2FuIG1haW50YWluIGFuIExSVSBuYnIgY2FjaGUgZW50cnkgb24gYSBwZXIgc3Vic2Ny aWJlcg0KDQrDmCAgYmFzaXMgc28gdGhhdCBhIG1hbGljaW91cyBzdWJzY3JpYmVyIGNhbm5vdCBk ZWdyYWRlIHRoZSBzZXJ2aWNlIGZvciBhbGwuDQoNCg0KDQpUaGFua3MgLSBGcmVkDQo= --_000_9bc9d9b064154c719960ae6a594240c6XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv UGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NzgwNjEwODA4Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjM1Mzc3OTI0IDE2 MDMwNjk3NzIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1z dGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IExvcmVuem8g Q29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBG cmlkYXksIFNlcHRlbWJlciAxNSwgMjAxNyAxMjoyNiBQTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxp biwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gdjZvcHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMDkudHh0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgMTE6NTQgQU0sIFRlbXBsaW4sIEZy ZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iIHRhcmdl dD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGhhdmUgaWRlbnRpZmllZCBhIERv UyB2ZWN0b3IgdGhhdCBjYW4gYmUgbWl0aWdhdGVkIGlmIHRoZSByb3V0ZXIgdXNlcyBhZGRyZXNz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+cmVzb2x1dGlvbiB0byBwcm90ZWN0IHRoZSBob3N0LiBJZiBp dCBkb2VzIHRoYXQsIHRoZSByb3V0ZXIgU0hPVUxEIHNlbmQgRFVzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5SaWdodC4gQnV0IE9UT0gsIHRoZSBEb1MgdmVjdG9yIHRoYXQgeW91IGZvdW5k IGlzIHN0cmljdGx5IGxlc3MgZGFtYWdpbmcgdGhhbiBpZiB0aGUgRG9TIHRhcmdldGVkIG9uZSBv ZiB0aGUgaG9zdCdzIElQIGFkZHJlc3Nlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDEu MjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPlRoZSBob3N0IGNhbiBhZGRyZXNzIHRoaXMgYnkgdXNpbmcgcHJpdmFjeSBhZGRyZXNzZXMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFs c28sIHlvdXIgc3VnZ2VzdGVkIG1pdGlnYXRpb24gKHNlbmRpbmcgRFVzKTxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BY3R1 YWxseSwgdGhlIHByaW1hcnkgbWl0aWdhdGlvbiBpcyBmb3IgdGhlIHJvdXRlciB0byBkbyBhZGRy ZXNzIHJlc29sdXRpb24uIFNlbmRpbmcgb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+bm90IHNlbmRpbmcgRFVzIHdvdWxkIGJl IGRlY2lkZWQgZm9sbG93aW5nIHN1Y2Nlc3Mgb3IgZmFpbHVyZSBvZiBhZGRyZXNzIHJlc29sdXRp b24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+cmVxdWlyZXMgdGhhdCB0aGUgcm91dGVyIG11c3Qga2VlcCBhbGwgYWRkcmVzc2Vz IGluIGl0cyBORCBjYWNoZSwgYW5kIHRoYXQgbWVhbnMgdGhhdCB0aGUgRG9TIHZlY3RvciB5b3Ug aWRlbnRpZmllZCBpcyBzdGlsbCBhIERvUyB2ZWN0b3IsIGJ1dCB0aGlzIHRpbWUgb24gdGhlIHJv dXRlcidzIE5EIGNhY2hlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+UHJlc3VtYWJs eSB0aGUgcm91dGVyIG1haW50YWlucyBhbiBMUlUgY29sbGVjdGlvbiBvZiBhIGZpbml0ZSBzdXBw bHkgb2YgbmJyIGNhY2hlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6NDYuNXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ZW50cmllcyBpbnN0ZWFkIG9mIGp1c3QgZWF0aW5nIHVw IGFsbCBvZiBpdHMgbWVtb3J5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbHNvLCB5b3VyIHN1Z2dlc3RlZCBtaXRpZ2F0aW9uIGNyZWF0ZXMg YW4gYWRkaXRpb25hbCBhdHRhY2sgdmVjdG9yOiBtYWxpY2lvdXMgY3VzdG9tZXJzIGNhbiBtb3Vu dCBhbiBORCBjYWNoZSBlbnRyeSBvbiB0aGUgcm91dGVyIGJ5IGNvbmZpZ3VyaW5nIGxvdHMgb2Yg YWRkcmVzc2VzIGFuZCBhcnJhbmdpbmcgdG8gcmVjZWl2ZSB0cmFmZmljIG9uIHRoZW0uIFRoaXMg aXMgZXh0cmVtZWx5IHNpbXBsZSB0byBtb3VudDoNCiBhIGhvc3QgY2FuIHNpbXBseSBzZW5kIGEg dHJpdmlhbCAxMHBwcyBvZiBwaW5nIHBhY2tldHMgKG9yIEROUyBxdWVyaWVzLCBvci4uLikgdG8g ZWFjaCBvZiAxMDAgcmVtb3RlIGRlc3RpbmF0aW9ucywgd2l0aCBlYWNoIHBhY2tldCBjb21pbmcg ZnJvbSBhIGRpZmZlcmVudCBhZGRyZXNzLiBUaGF0IGNhbiBjYXVzZSB0aGUgcm91dGVyIHRvIGF0 dGVtcHQgdG8gY3JlYXRlIDEwMDAgTkQgY2FjaGUgZW50cmllcyBwZXIgc2Vjb25kLiBZb3UgbWln aHQNCiB3YW50IHRvIHRyeSB0aGF0IG9uIHNvbWUgcm91dGVycyBhbmQgc2VlIGhvdyBiYWRseSB0 aGV5IGZhbGwgb3Zlci48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi IHN0eWxlPSJtYXJnaW4tbGVmdDo0Ni41cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgcm91dGVyIGNhbiBtYWludGFpbiBhbiBMUlUg bmJyIGNhY2hlIGVudHJ5IG9uIGEgcGVyIHN1YnNjcmliZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo1MS43NXB0O3RleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+YmFzaXMgc28gdGhh dCBhIG1hbGljaW91cyBzdWJzY3JpYmVyIGNhbm5vdCBkZWdyYWRlIHRoZSBzZXJ2aWNlIGZvciBh bGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_9bc9d9b064154c719960ae6a594240c6XCH150608nwnosboeingcom_-- From nobody Fri Sep 15 14:23:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981C013421D for ; Fri, 15 Sep 2017 14:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 51C4MW4g8l0e for ; Fri, 15 Sep 2017 14:23:25 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEBA133209 for ; Fri, 15 Sep 2017 14:23:25 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id D3C452D505E; Fri, 15 Sep 2017 21:23:21 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D8392108D2E83; Fri, 15 Sep 2017 23:23:19 +0200 (CEST) From: Ole Troan Message-Id: <57417A52-D570-4F6C-AF44-54623A45121C@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_524B6E9F-FBEC-4710-8D42-2AC8E293969F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 15 Sep 2017 23:23:18 +0200 In-Reply-To: Cc: Lorenzo Colitti , "v6ops@ietf.org" To: "Templin, Fred L" References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 21:23:27 -0000 --Apple-Mail=_524B6E9F-FBEC-4710-8D42-2AC8E293969F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > I have identified a DoS vector that can be mitigated if the router = uses address > resolution to protect the host. If it does that, the router SHOULD = send DUs. The implementation we did of this was for the sole purpose of _not_ = having to do address resolution... Cheers, Ole >=20 > From: Lorenzo Colitti [mailto:lorenzo@google.com] > Sent: Friday, September 15, 2017 10:39 AM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt >=20 > On Fri, Sep 15, 2017 at 10:30 AM, Templin, Fred L = wrote: > =C3=98 My understanding is that this is about simple hosts, and not = hosts that act as routers. >=20 > =C3=98 Hosts can send Destination Unreachable =E2=80=93 Port = Unreachable; they cannot send >=20 > =C3=98 Destination Unreachable =E2=80=93 Address Unreachable except = to their own local >=20 > =C3=98 applications. >=20 > Right. Then the attack that you are theorizing will not cause any = unreachables to be sent, and that's fine. >=20 > I disagree. If it's a host, it will just silently drop those packets. = Such an attack can do no more damage than a flood of packets to the = host's own address, and in most cases it will do much less. >=20 > =C3=98 A flood of packets to the hosts=E2=80=99s own address will = result in Destination Unreachable >=20 > =C3=98 Port Unreachable messages. This will cause a legitimate = source to cease sending >=20 > =C3=98 packets to the unreachable port. >=20 > Sure. But you were talking about DOS attacks, and those are neither = legitimate sources nor likely to stop sending packets in response to = unreachable errors :-) > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_524B6E9F-FBEC-4710-8D42-2AC8E293969F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZvETHAAoJEL7aWKiYQt92C78QALIgIO2C7CrldKrM7cZfjzWK Y5g+FQy0trDkWMnR/7R4zOL7H/jcFyvdFme/SbMwwqlQ4ig2HnVr+vA1vuQ3IBZ9 3hClE9dGX4oafbAqEBJZXCFAYxaQK3iTEHAdw9+rlSko/5ZOWm8glgL4m+kHgK1N oNFpg+JrpoWYaccsf03AaJ7OER6XK9L4hf24YRx5KlxSq6qbOW4dB3t6GhjeWgRs EjtkKu8C2Z6n9IhMOHns8ThQQpOkRL9kypjBhtzHA3zDMy10nbB+hfKrl37kUPbW R3BxqT1fK5jCURiONQxFpQdlaEDcsxa3Wpo5T+KAqma9E8ubQfiZVB2A1CnVTh5E jfzqqxF2vJ8IaWC/gdIFLz3EmdKSNlvHtLjLktyAEQhXAM0r1yoRSJgpIHpXGzS6 OvmA2f7bmqjshz1e9L/06ux8d1STFWUX7cqkqJRoZuhIrNIgRuQbDtsNUqS61XWA tZcdEyfbqp+wucXqtd5qmInUCBhhprVMRKPgOF54C1z0B7nxM7B+3ShTvEKPP6cr 3CYsb/g9bpRSFdxbpRvlUuSrXdh5JpA+so51ukCZGWzsyrC2p3blivs8Z6TuNFkB W1yS3PSIHS0pnQo8SBI/UWDK5s1yjP4nBfWPUog7UFU8Y2ZVHg2fi5vRx5diuJIm MYvcFq3TphYSmkkZ8t3/ =1YpT -----END PGP SIGNATURE----- --Apple-Mail=_524B6E9F-FBEC-4710-8D42-2AC8E293969F-- From nobody Fri Sep 15 14:24:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56779132620 for ; Fri, 15 Sep 2017 14:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 vIlnGFtKlpwx for ; Fri, 15 Sep 2017 14:24:52 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B884213421A for ; Fri, 15 Sep 2017 14:24:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8FLOpqU002978; Fri, 15 Sep 2017 14:24:51 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8FLOhCs002446 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Sep 2017 14:24:43 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Sep 2017 14:24:42 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 15 Sep 2017 14:24:42 -0700 From: "Templin, Fred L" To: David Farmer CC: Lorenzo Colitti , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0R353fXvPDrEeoXyoh+k1EZqK2AYpwgAClIID//4rzsIAAd8+A//+K8tCAAHjkgP//nihQABESOIAAC/+Y0A== Date: Fri, 15 Sep 2017 21:24:42 +0000 Message-ID: <333255d8411f4394a09521728b73101e@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_333255d8411f4394a09521728b73101eXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 21:24:54 -0000 --_000_333255d8411f4394a09521728b73101eXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNClNlZSBiZWxvdzoNCg0KRnJlZA0KDQpGcm9tOiBEYXZpZCBGYXJtZXIgW21h aWx0bzpmYXJtZXJAdW1uLmVkdV0NClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDE1LCAyMDE3IDEy OjU4IFBNDQpUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0K Q2M6IExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPjsgdjZvcHNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVl LWlwdjYtcHJlZml4LXBlci1ob3N0LTA5LnR4dA0KDQpCdXQgaW4gb3JkZXIgdG8gbWl0aWdhdGUg b25lIERET1MgdmVjdG9yLCBhbmQgbm90IGEgdmVyeSB0eXBpY2FsIG9uZSBmb3IgdGhhdCBtYXR0 ZXIsDQoNCg0Kw5ggIFdoYXQgbWF0dGVycyBpcyB0aGF0IHRoZSBhdHRhY2sgd2FzIG5vdCBrbm93 biB1bnRpbCBub3cuIE5vdyBpdCBpcw0KDQrDmCAga25vd24sIHNvIGlmIHdlIHdpbGwgZGVwbG95 IHRoaXMgd2Ugd2lsbCBzZWUgaWYgaXQgYmVjb21lcyB0eXBpY2FsLg0KDQoNCnlvdSBlbGltaW5h dGUgdGhlIHNjYWxlYWJpbGl0eSBhZHZhbnRhZ2VzIHByb3ZpZGVkIGJ5IG5vdCB0cmFja2luZyB0 aGUgYWRkcmVzc2VzIHVzZWQgd2l0aGluIGVhY2ggdW5pcXVlIHByZWZpeC4gRnVydGhlcm1vcmUs IHRoYXQgYW5kIG1hbnkgb3RoZXIgRERPUyB2ZWN0b3JzIGNhbiBiZSBkZXRlY3RlZCBhbmQgbWl0 aWdhdGVkIGJ5IHNldmVyYWwgb3RoZXIgbWVhbnMuIEkgY2FuJ3QgdGhpbmsgb2YgaG93IGVsc2Ug dG8gcHJvdmlkZSB0aGUgc2NhbGVhYmlsaXR5IGFkdmFudGFnZXMgZnJvbSBub3QgdHJhY2tpbmcg dGhlIGFkZHJlc3NlcyB1c2VkIGluIHRoZSB1bmlxdWUgcHJlZml4ZXMuDQoNCg0Kw5ggIFRoZSBy b3V0ZXIgaGFzIGEgZmluaXRlIG5laWdoYm9yIGNhY2hlLCBidXQgaXQgaGFzIHRoZSBtZWFucyB0 byBtYW5hZ2UNCg0Kw5ggIHRoZSBjYWNoZSAoZS5nLiwgTFJVKSBpbiB0aGUgZmFjZSBvZiBhbiBh dHRhY2suIEFuZCwgSSB0aGluayBpdCBpcyByZWFzb25hYmxlDQoNCsOYICB0byBleHBlY3QgdGhh dCBhbiBhdHRhY2sgb2YgdGhpcyBuYXR1cmUgd291bGQgYmUgc2hvcnQtbGl2ZWQgYW5kIG5vdA0K DQrDmCAgb25lIHRoYXQgd291bGQgcGVyc2lzdCBmb3IgZGF5cyBhbmQgZGF5cyB1bnRpbCB0aGUg c291cmNlIGlzIGlkZW50aWZpZWQuDQoNCkkgaGF2ZSByb3V0ZXJzIHRoYXQgY2FuIGhhbmRsZSBz ZXZlcmFsIG1pbGxpb25zIG9mIElQdjYgcm91dGVzLCBidXQgdGhleSBjYW4gb25seSB0cmFjayAy NTBrIG5laWdoYm9yIGFzc29jaWF0aW9ucy4gIFRoYXRzIGlzIGVmZmVjdGl2ZWx5IDUwSyBob3N0 cyBhcyB3ZSBzZWUgb24gYXZlcmFnZSA1IG5laWdoYm9yIGFzc29jaWF0aW9ucyBwZXIgaG9zdCwg SSBuZWVkIGJldHRlciBuZWlnaGJvciBkaXNjb3Zlcnkgc2NhbGVhYmlsaXR5Lg0KDQoNCsOYICBS aWdodCwgYnV0IHRoZSBuZWlnaGJvciBjYWNoZSBsaW1pdCBkb2VzIG5vdCBsaW1pdCB0aGUgbnVt YmVyIG9mIGhvc3RzDQoNCsOYICBpZiB0aGUgcm91dGVyIG1hbmFnZXMgaXQgdXNpbmcgTFJVIHJl cGxhY2VtZW50IG9mIHN0YWxlIGVudHJpZXMuIFdvcnN0DQoNCsOYICBjYXNlIGlzIHRoYXQgdGhl cmUgbWF5IGJlIGV4dHJhIE5TL05BIHRyYWZmaWMgaWYgdGhlIHN5c3RlbSBpcyB1bmRlcg0KDQrD mCAgYXR0YWNrIG9yIGFsbCBzdWJzY3JpYmVycyBhcmUgdXNpbmcgYWxsIG9mIHRoZWlyIGFkZHJl c3NlcyBhbGwgb2YgdGhlIHRpbWUuDQoNCg0KSSBhbHJlYWR5IHNlcGFyYXRlIERET1MgZGV0ZWN0 aW9uIGFuZCBtaXR0aWdhdGlvbiwgdGhhdCB3aWxsIGNvdmVyIHRoYXQgbW9yZSBlZmZlY3RpdmVs eSB0aGFuIHRoZSBvbmUgRERPUyB2ZWN0b3IgeW91IGFyZSB0YWxraW5nIGFib3V0Lg0KDQoNCsOY ICAgIEkgY2Fu4oCZdCBwYXJzZSB0aGlzLg0KDQpBdCBtb3N0IG5vdGluZyB0aGF0IERVcyBhcmUg bm90IHByb3ZpZGVkIGJ5IHRoZSBGaXJzdCBob3Agcm91dGVyIGZvciB1bnVzZWQgYWRkcmVzc2Vz IHdpdGhpbiB0aGUgdW5pcXVlIHByZWZpeCwgc2VlbXMgcmVhc29uYWJsZSBzbyBubyBvbmUgaXMg c3VycHJpc2VkIGJ5IHRoZSBiZWhhdmlvci4NCg0KDQrDmCAgICBEVSBpcyBvbmx5IGEgU0hPVUxE IGFzIEkgaGF2ZSBhbHJlYWR5IGFncmVlZC4gQnV0LCBhZGRyZXNzIHJlc29sdXRpb24gcHJvdGVj dGlvbg0KDQrDmCAgICBvZiBob3N0cyBpcyB0aGUgcHJpbWFyeSBtaXRpZ2F0aW9uLg0KDQpGdXJ0 aGVybW9yZSwgSUNNUCBpcyBieSBubyBtZWFuIGd1YXJhbnRlZWQgdG8gZ2V0IGFjcm9zcyB0aGUg SW50ZXJuZXQgYW55d2F5LCBpdCdzIGZpbHRlcmVkIGluIGZhciB0b28gbWFueSBwbGFjZXMuDQoN Cg0Kw5ggICAgUmlnaHQsIERVIGlzIG9ubHkgYSBTSE9VTEQuIEJ1dCwgaXQgaXMgYSBzdHJvbmcg U0hPVUxELg0KDQpUaGFua3MuDQoNCk9uIEZyaSwgU2VwIDE1LCAyMDE3IGF0IDE6NTQgUE0sIFRl bXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRl bXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KSSBoYXZlIGlkZW50aWZpZWQgYSBEb1MgdmVjdG9y IHRoYXQgY2FuIGJlIG1pdGlnYXRlZCBpZiB0aGUgcm91dGVyIHVzZXMgYWRkcmVzcw0KcmVzb2x1 dGlvbiB0byBwcm90ZWN0IHRoZSBob3N0LiBJZiBpdCBkb2VzIHRoYXQsIHRoZSByb3V0ZXIgU0hP VUxEIHNlbmQgRFVzLg0KDQpGcmVkDQoNCkZyb206IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxv cmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tPl0NClNlbnQ6IEZyaWRh eSwgU2VwdGVtYmVyIDE1LCAyMDE3IDEwOjM5IEFNDQpUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4N CkNjOiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1w ZXItaG9zdC0wOS50eHQNCg0KT24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgMTA6MzAgQU0sIFRlbXBs aW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWlsdG86RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KDQo+ICAgIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0 aGlzIGlzIGFib3V0IHNpbXBsZSBob3N0cywgYW5kIG5vdCBob3N0cyB0aGF0IGFjdCBhcyByb3V0 ZXJzLg0KDQo+ICAgIEhvc3RzIGNhbiBzZW5kIERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIOKAkyBQ b3J0IFVucmVhY2hhYmxlOyB0aGV5IGNhbm5vdCBzZW5kDQoNCj4gICAgRGVzdGluYXRpb24gVW5y ZWFjaGFibGUg4oCTIEFkZHJlc3MgVW5yZWFjaGFibGUgZXhjZXB0IHRvIHRoZWlyIG93biBsb2Nh bA0KDQo+ICAgIGFwcGxpY2F0aW9ucy4NClJpZ2h0LiBUaGVuIHRoZSBhdHRhY2sgdGhhdCB5b3Ug YXJlIHRoZW9yaXppbmcgd2lsbCBub3QgY2F1c2UgYW55IHVucmVhY2hhYmxlcyB0byBiZSBzZW50 LCBhbmQgdGhhdCdzIGZpbmUuDQoNCkkgZGlzYWdyZWUuIElmIGl0J3MgYSBob3N0LCBpdCB3aWxs IGp1c3Qgc2lsZW50bHkgZHJvcCB0aG9zZSBwYWNrZXRzLiBTdWNoIGFuIGF0dGFjayBjYW4gZG8g bm8gbW9yZSBkYW1hZ2UgdGhhbiBhIGZsb29kIG9mIHBhY2tldHMgdG8gdGhlIGhvc3QncyBvd24g YWRkcmVzcywgYW5kIGluIG1vc3QgY2FzZXMgaXQgd2lsbCBkbyBtdWNoIGxlc3MuDQoNCg0KPiAg ICBBIGZsb29kIG9mIHBhY2tldHMgdG8gdGhlIGhvc3Rz4oCZcyBvd24gYWRkcmVzcyB3aWxsIHJl c3VsdCBpbiBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZQ0KDQo+ICAgIFBvcnQgVW5yZWFjaGFibGUg bWVzc2FnZXMuIFRoaXMgd2lsbCAgY2F1c2UgYSBsZWdpdGltYXRlIHNvdXJjZSB0byBjZWFzZSBz ZW5kaW5nDQoNCj4gICAgcGFja2V0cyB0byB0aGUgdW5yZWFjaGFibGUgcG9ydC4NClN1cmUuIEJ1 dCB5b3Ugd2VyZSB0YWxraW5nIGFib3V0IERPUyBhdHRhY2tzLCBhbmQgdGhvc2UgYXJlIG5laXRo ZXIgbGVnaXRpbWF0ZSBzb3VyY2VzIG5vciBsaWtlbHkgdG8gc3RvcCBzZW5kaW5nIHBhY2tldHMg aW4gcmVzcG9uc2UgdG8gdW5yZWFjaGFibGUgZXJyb3JzIDotKQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9w c0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQoNCg0KDQotLQ0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCkRhdmlkIEZhcm1lciAgICAgICAgICAgICAgIEVtYWls OmZhcm1lckB1bW4uZWR1PG1haWx0bzpFbWFpbCUzQWZhcm1lckB1bW4uZWR1Pg0KTmV0d29ya2lu ZyAmIFRlbGVjb21tdW5pY2F0aW9uIFNlcnZpY2VzDQpPZmZpY2Ugb2YgSW5mb3JtYXRpb24gVGVj aG5vbG9neQ0KVW5pdmVyc2l0eSBvZiBNaW5uZXNvdGENCjIyMTggVW5pdmVyc2l0eSBBdmUgU0Ug ICAgICAgIFBob25lOiA2MTItNjI2LTA4MTUNCk1pbm5lYXBvbGlzLCBNTiA1NTQxNC0zMDI5ICAg Q2VsbDogNjEyLTgxMi05OTUyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0K --_000_333255d8411f4394a09521728b73101eXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLmdtYWlsLW02Mjg4MTkwMjIwNjM5NTA0MTg1bS0xOTk4ODk4 NDc5MDMzNDA0NDYxbXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbTYyODgxOTAyMjA2Mzk1MDQx ODVtLTE5OTg4OTg0NzkwMzM0MDQ0NjFtc29saXN0cGFyYWdyYXBoLCBkaXYuZ21haWwtbTYyODgx OTAyMjA2Mzk1MDQxODVtLTE5OTg4OTg0NzkwMzM0MDQ0NjFtc29saXN0cGFyYWdyYXBoDQoJe21z by1zdHlsZS1uYW1lOmdtYWlsLW1fNjI4ODE5MDIyMDYzOTUwNDE4NW0tMTk5ODg5ODQ3OTAzMzQw NDQ2MW1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6NTM5NzgwNDgwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczoxNzU5NTU4Mzc0IDEzMzU4OTAzMTYgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkhpIERhdmlkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ U2VlIGJlbG93OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJl ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IERhdmlkIEZhcm1lciBbbWFpbHRvOmZhcm1lckB1bW4uZWR1XQ0KPGJyPg0K PGI+U2VudDo8L2I+IEZyaWRheSwgU2VwdGVtYmVyIDE1LCAyMDE3IDEyOjU4IFBNPGJyPg0KPGI+ VG86PC9iPiBUZW1wbGluLCBGcmVkIEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBMb3JlbnpvIENvbGl0dGkgJmx0O2xvcmVuem9AZ29vZ2xlLmNvbSZn dDs7IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA5LnR4 dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C dXQgaW4gb3JkZXIgdG8gbWl0aWdhdGUgb25lIERET1MgdmVjdG9yLCBhbmQgbm90IGEgdmVyeSB0 eXBpY2FsIG9uZSBmb3IgdGhhdCBtYXR0ZXIsPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2hhdCBtYXR0ZXJzIGlzIHRoYXQgdGhlIGF0dGFj ayB3YXMgbm90IGtub3duIHVudGlsIG5vdy4gTm93IGl0IGlzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmtub3duLCBzbyBpZiB3ZSB3 aWxsIGRlcGxveSB0aGlzIHdlIHdpbGwgc2VlIGlmIGl0IGJlY29tZXMgdHlwaWNhbC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnlvdSBlbGltaW5hdGUgdGhlIHNjYWxlYWJpbGl0eSBhZHZhbnRhZ2VzIHBy b3ZpZGVkIGJ5IG5vdCB0cmFja2luZyB0aGUgYWRkcmVzc2VzIHVzZWQgd2l0aGluIGVhY2ggdW5p cXVlIHByZWZpeC4gRnVydGhlcm1vcmUsIHRoYXQgYW5kIG1hbnkgb3RoZXIgRERPUyB2ZWN0b3Jz IGNhbiBiZSBkZXRlY3RlZCBhbmQgbWl0aWdhdGVkIGJ5IHNldmVyYWwgb3RoZXIgbWVhbnMuIEkg Y2FuJ3QgdGhpbmsgb2YgaG93IGVsc2UNCiB0byBwcm92aWRlIHRoZSBzY2FsZWFiaWxpdHkgYWR2 YW50YWdlcyBmcm9tIG5vdCB0cmFja2luZyB0aGUgYWRkcmVzc2VzIHVzZWQgaW4gdGhlIHVuaXF1 ZSBwcmVmaXhlcy48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGUgcm91dGVyIGhhcyBhIGZpbml0ZSBuZWlnaGJvciBjYWNoZSwgYnV0IGl0 IGhhcyB0aGUgbWVhbnMgdG8gbWFuYWdlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoZSBjYWNoZSAoZS5nLiwgTFJVKSBpbiB0aGUg ZmFjZSBvZiBhbiBhdHRhY2suIEFuZCwgSSB0aGluayBpdCBpcyByZWFzb25hYmxlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRvIGV4 cGVjdCB0aGF0IGFuIGF0dGFjayBvZiB0aGlzIG5hdHVyZSB3b3VsZCBiZSBzaG9ydC1saXZlZCBh bmQgbm90PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7D mDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPm9uZSB0aGF0IHdvdWxkIHBlcnNpc3QgZm9yIGRheXMgYW5kIGRheXMgdW50aWwg dGhlIHNvdXJjZSBpcyBpZGVudGlmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHJvdXRlcnMg dGhhdCBjYW4gaGFuZGxlIHNldmVyYWwgbWlsbGlvbnMgb2YgSVB2NiByb3V0ZXMsIGJ1dCB0aGV5 IGNhbiBvbmx5IHRyYWNrIDI1MGsgbmVpZ2hib3IgYXNzb2NpYXRpb25zLiZuYnNwOyBUaGF0cyBp cyBlZmZlY3RpdmVseSZuYnNwOzUwSyBob3N0cyBhcyB3ZSBzZWUgb24gYXZlcmFnZSA1IG5laWdo Ym9yIGFzc29jaWF0aW9ucyBwZXIgaG9zdCwgSSBuZWVkIGJldHRlciBuZWlnaGJvciBkaXNjb3Zl cnkNCiBzY2FsZWFiaWxpdHk8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlJpZ2h0 LCBidXQgdGhlIG5laWdoYm9yIGNhY2hlIGxpbWl0IGRvZXMgbm90IGxpbWl0IHRoZSBudW1iZXIg b2YgaG9zdHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmlmIHRoZSBy b3V0ZXIgbWFuYWdlcyBpdCB1c2luZyBMUlUgcmVwbGFjZW1lbnQgb2Ygc3RhbGUgZW50cmllcy4g V29yc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjoj MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmNhc2UgaXMgdGhh dCB0aGVyZSBtYXkgYmUgZXh0cmEgTlMvTkEgdHJhZmZpYyBpZiB0aGUgc3lzdGVtIGlzIHVuZGVy PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3 RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5hdHRhY2sgb3IgYWxsIHN1 YnNjcmliZXJzIGFyZSB1c2luZyBhbGwgb2YgdGhlaXIgYWRkcmVzc2VzIGFsbCBvZiB0aGUgdGlt ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxyZWFkeSBzZXBhcmF0ZSBERE9TIGRldGVjdGlvbiBhbmQg bWl0dGlnYXRpb24sIHRoYXQgd2lsbCBjb3ZlciB0aGF0IG1vcmUgZWZmZWN0aXZlbHkgdGhhbiB0 aGUgb25lIERET1MgdmVjdG9yIHlvdSBhcmUgdGFsa2luZyBhYm91dC48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO3Rl eHQtaW5kZW50OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7 Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5JIGNhbuKAmXQgcGFyc2UgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCBtb3N0IG5vdGlu ZyB0aGF0IERVcyBhcmUgbm90IHByb3ZpZGVkIGJ5IHRoZSBGaXJzdCBob3Agcm91dGVyIGZvciB1 bnVzZWQgYWRkcmVzc2VzIHdpdGhpbiB0aGUgdW5pcXVlIHByZWZpeCwgc2VlbXMgcmVhc29uYWJs ZSBzbyBubyBvbmUgaXMgc3VycHJpc2VkIGJ5IHRoZSBiZWhhdmlvci48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RFUgaXMgb25seSBhIFNIT1VMRCBhcyBJ IGhhdmUgYWxyZWFkeSBhZ3JlZWQuIEJ1dCwgYWRkcmVzcyByZXNvbHV0aW9uIHByb3RlY3Rpb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWluZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+b2YgaG9zdHMgaXMgdGhlIHByaW1hcnkgbWl0 aWdhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkZ1cnRoZXJtb3JlLCBJQ01QIGlzIGJ5IG5vIG1lYW4gZ3VhcmFudGVlZCB0 byBnZXQgYWNyb3NzIHRoZSBJbnRlcm5ldCBhbnl3YXksIGl0J3MgZmlsdGVyZWQgaW4gZmFyIHRv byBtYW55IHBsYWNlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjt0ZXh0LWlu ZGVudDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9y OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+UmlnaHQsIERVIGlzIG9ubHkgYSBTSE9VTEQuIEJ1dCwgaXQgaXMgYSBzdHJvbmcgU0hP VUxELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhhbmtzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBT ZXAgMTUsIDIwMTcgYXQgMTo1NCBQTSwgVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVmPSJtYWls dG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQuTC5UZW1w bGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkkgaGF2ZSBpZGVudGlmaWVkIGEgRG9TIHZlY3RvciB0aGF0IGNhbiBiZSBt aXRpZ2F0ZWQgaWYgdGhlIHJvdXRlciB1c2VzIGFkZHJlc3M8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5y ZXNvbHV0aW9uIHRvIHByb3RlY3QgdGhlIGhvc3QuIElmIGl0IGRvZXMgdGhhdCwgdGhlIHJvdXRl ciBTSE9VTEQgc2VuZCBEVXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+RnJlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBMb3JlbnpvIENvbGl0dGkgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bG9yZW56b0Bn b29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIFNlcHRlbWJlciAxNSwg MjAxNyAxMDozOSBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVm PSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQu TC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFp bHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZv cHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA5LnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBG cmksIFNlcCAxNSwgMjAxNyBhdCAxMDozMCBBTSwgVGVtcGxpbiwgRnJlZCBMICZsdDs8YSBocmVm PSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkZyZWQu TC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9ImdtYWls LW02Mjg4MTkwMjIwNjM5NTA0MTg1bS0xOTk4ODk4NDc5MDMzNDA0NDYxbXNvbGlzdHBhcmFncmFw aCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2Nv bG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlzIGlzIGFib3V0IHNpbXBsZSBo b3N0cywgYW5kIG5vdCBob3N0cyB0aGF0IGFjdCBhcyByb3V0ZXJzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNjI4ODE5MDIyMDYzOTUwNDE4NW0tMTk5ODg5ODQ3OTAz MzQwNDQ2MW1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ib3N0cyBjYW4gc2VuZCBEZXN0aW5hdGlv biBVbnJlYWNoYWJsZSDigJMgUG9ydCBVbnJlYWNoYWJsZTsgdGhleSBjYW5ub3Qgc2VuZDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNjI4ODE5MDIyMDYzOTUwNDE4NW0t MTk5ODg5ODQ3OTAzMzQwNDQ2MW1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5EZXN0aW5hdGlvbiBV bnJlYWNoYWJsZSDigJMgQWRkcmVzcyBVbnJlYWNoYWJsZSBleGNlcHQgdG8gdGhlaXIgb3duIGxv Y2FsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW02Mjg4MTkwMjIwNjM5 NTA0MTg1bS0xOTk4ODk4NDc5MDMzNDA0NDYxbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOY PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFwcGxp Y2F0aW9ucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlJpZ2h0LiBUaGVuIHRoZSBhdHRhY2sgdGhhdCB5b3UgYXJlIHRo ZW9yaXppbmcgd2lsbCBub3QgY2F1c2UgYW55IHVucmVhY2hhYmxlcyB0byBiZSBzZW50LCBhbmQg dGhhdCdzIGZpbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRp c2FncmVlLiBJZiBpdCdzIGEgaG9zdCwgaXQgd2lsbCBqdXN0IHNpbGVudGx5IGRyb3AgdGhvc2Ug cGFja2V0cy4gU3VjaCBhbiBhdHRhY2sgY2FuIGRvIG5vIG1vcmUgZGFtYWdlIHRoYW4gYSBmbG9v ZCBvZiBwYWNrZXRzIHRvIHRoZSBob3N0J3Mgb3duIGFkZHJlc3MsIGFuZCBpbiBtb3N0IGNhc2Vz IGl0DQogd2lsbCBkbyBtdWNoIGxlc3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTYyODgxOTAyMjA2Mzk1MDQxODVtLTE5OTg4OTg0 NzkwMzM0MDQ0NjFtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+w5g8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QSBmbG9vZCBvZiBwYWNrZXRzIHRv IHRoZSBob3N0c+KAmXMgb3duIGFkZHJlc3Mgd2lsbCByZXN1bHQgaW4gRGVzdGluYXRpb24gVW5y ZWFjaGFibGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTYyODgxOTAy MjA2Mzk1MDQxODVtLTE5OTg4OTg0NzkwMzM0MDQ0NjFtc29saXN0cGFyYWdyYXBoIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3 RCI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ UG9ydCBVbnJlYWNoYWJsZSBtZXNzYWdlcy4gVGhpcyB3aWxsJm5ic3A7IGNhdXNlIGEgbGVnaXRp bWF0ZSBzb3VyY2UgdG8gY2Vhc2Ugc2VuZGluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJnbWFpbC1tNjI4ODE5MDIyMDYzOTUwNDE4NW0tMTk5ODg5ODQ3OTAzMzQwNDQ2MW1zb2xp c3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldp bmdkaW5ncztjb2xvcjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5wYWNrZXRzIHRvIHRoZSB1bnJlYWNoYWJsZSBwb3J0Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3VyZS4gQnV0 IHlvdSB3ZXJlIHRhbGtpbmcgYWJvdXQgRE9TIGF0dGFja3MsIGFuZCB0aG9zZSBhcmUgbmVpdGhl ciBsZWdpdGltYXRlIHNvdXJjZXMgbm9yIGxpa2VseSB0byBzdG9wIHNlbmRpbmcgcGFja2V0cyBp biByZXNwb25zZSB0byB1bnJlYWNoYWJsZSBlcnJvcnMgOi0pPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCkRh dmlkIEZhcm1lciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZuYnNwOyA8YSBocmVmPSJtYWlsdG86RW1haWwlM0FmYXJtZXJAdW1uLmVkdSIgdGFyZ2V0PSJf YmxhbmsiPg0KRW1haWw6ZmFybWVyQHVtbi5lZHU8L2E+PGJyPg0KTmV0d29ya2luZyAmYW1wOyBU ZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlczxicj4NCk9mZmljZSBvZiBJbmZvcm1hdGlvbiBUZWNo bm9sb2d5PGJyPg0KVW5pdmVyc2l0eSBvZiBNaW5uZXNvdGEmbmJzcDsmbmJzcDsgPGJyPg0KMjIx OCBVbml2ZXJzaXR5IEF2ZSBTRSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQaG9uZTogNjEy LTYyNi0wODE1PGJyPg0KTWlubmVhcG9saXMsIE1OIDU1NDE0LTMwMjkmbmJzcDsmbmJzcDsgQ2Vs bDogNjEyLTgxMi05OTUyPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_333255d8411f4394a09521728b73101eXCH150608nwnosboeingcom_-- From nobody Fri Sep 15 14:26:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5513421D for ; Fri, 15 Sep 2017 14:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FI8cT-FvGB6T for ; Fri, 15 Sep 2017 14:26:25 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E575132620 for ; Fri, 15 Sep 2017 14:26:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8FLQOsg065385; Fri, 15 Sep 2017 14:26:24 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8FLQLDA065360 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Sep 2017 14:26:21 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Sep 2017 14:26:20 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 15 Sep 2017 14:26:20 -0700 From: "Templin, Fred L" To: Ole Troan CC: Lorenzo Colitti , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0R353fXvPDrEeoXyoh+k1EZqK2AYpwgAClIID//4rzsIAAd8+A//+K8tCAAHjkgP//nihQABQQ4gAADpweQA== Date: Fri, 15 Sep 2017 21:26:20 +0000 Message-ID: <1617a42e3ba444dabdea3a556ed880d3@XCH15-06-08.nw.nos.boeing.com> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> <57417A52-D570-4F6C-AF44-54623A45121C@employees.org> In-Reply-To: <57417A52-D570-4F6C-AF44-54623A45121C@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 21:26:27 -0000 SGkgT2xlLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE9sZSBUcm9h biBbbWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnXQ0KPiBTZW50OiBGcmlkYXksIFNlcHRlbWJl ciAxNSwgMjAxNyAyOjIzIFBNDQo+IFRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20+DQo+IENjOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT47 IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA5LnR4dA0KPiANCj4gPiBJ IGhhdmUgaWRlbnRpZmllZCBhIERvUyB2ZWN0b3IgdGhhdCBjYW4gYmUgbWl0aWdhdGVkIGlmIHRo ZSByb3V0ZXIgdXNlcyBhZGRyZXNzDQo+ID4gcmVzb2x1dGlvbiB0byBwcm90ZWN0IHRoZSBob3N0 LiBJZiBpdCBkb2VzIHRoYXQsIHRoZSByb3V0ZXIgU0hPVUxEIHNlbmQgRFVzLg0KPiANCj4gVGhl IGltcGxlbWVudGF0aW9uIHdlIGRpZCBvZiB0aGlzIHdhcyBmb3IgdGhlIHNvbGUgcHVycG9zZSBv ZiBfbm90XyBoYXZpbmcgdG8gZG8gYWRkcmVzcyByZXNvbHV0aW9uLi4uDQoNClRoZW4sIHRoZSBm bG9vZGdhdGVzIGFyZSBvcGVuIGFuZCB0aGUgaG9zdCBjYW4gYmUgRG9TJ2QuIFRoZSBhdHRhY2sg cHJvZmlsZQ0Kd291bGQgbm90IGJlIHRvbyBmYXIgZGlmZmVyZW50IHRoYW4gdGhlIERZTiBhdHRh Y2sgYmFjayBsYXN0IE9jdG9iZXIuDQoNClRoYW5rcyAtIEZyZWQNCg0KPiBDaGVlcnMsDQo+IE9s ZQ0KPiANCj4gDQo+ID4NCj4gPiBGcm9tOiBMb3JlbnpvIENvbGl0dGkgW21haWx0bzpsb3Jlbnpv QGdvb2dsZS5jb21dDQo+ID4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMTUsIDIwMTcgMTA6Mzkg QU0NCj4gPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0K PiA+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTA5LnR4dA0K PiA+DQo+ID4gT24gRnJpLCBTZXAgMTUsIDIwMTcgYXQgMTA6MzAgQU0sIFRlbXBsaW4sIEZyZWQg TCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4gw5ggICAgTXkgdW5kZXJz dGFuZGluZyBpcyB0aGF0IHRoaXMgaXMgYWJvdXQgc2ltcGxlIGhvc3RzLCBhbmQgbm90IGhvc3Rz IHRoYXQgYWN0IGFzIHJvdXRlcnMuDQo+ID4NCj4gPiDDmCAgICBIb3N0cyBjYW4gc2VuZCBEZXN0 aW5hdGlvbiBVbnJlYWNoYWJsZSDigJMgUG9ydCBVbnJlYWNoYWJsZTsgdGhleSBjYW5ub3Qgc2Vu ZA0KPiA+DQo+ID4gw5ggICAgRGVzdGluYXRpb24gVW5yZWFjaGFibGUg4oCTIEFkZHJlc3MgVW5y ZWFjaGFibGUgZXhjZXB0IHRvIHRoZWlyIG93biBsb2NhbA0KPiA+DQo+ID4gw5ggICAgYXBwbGlj YXRpb25zLg0KPiA+DQo+ID4gUmlnaHQuIFRoZW4gdGhlIGF0dGFjayB0aGF0IHlvdSBhcmUgdGhl b3JpemluZyB3aWxsIG5vdCBjYXVzZSBhbnkgdW5yZWFjaGFibGVzIHRvIGJlIHNlbnQsIGFuZCB0 aGF0J3MgZmluZS4NCj4gPg0KPiA+IEkgZGlzYWdyZWUuIElmIGl0J3MgYSBob3N0LCBpdCB3aWxs IGp1c3Qgc2lsZW50bHkgZHJvcCB0aG9zZSBwYWNrZXRzLiBTdWNoIGFuIGF0dGFjayBjYW4gZG8g bm8gbW9yZSBkYW1hZ2UgdGhhbiBhIGZsb29kIG9mIHBhY2tldHMgdG8gdGhlDQo+IGhvc3QncyBv d24gYWRkcmVzcywgYW5kIGluIG1vc3QgY2FzZXMgaXQgd2lsbCBkbyBtdWNoIGxlc3MuDQo+ID4N Cj4gPiDDmCAgICBBIGZsb29kIG9mIHBhY2tldHMgdG8gdGhlIGhvc3Rz4oCZcyBvd24gYWRkcmVz cyB3aWxsIHJlc3VsdCBpbiBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZQ0KPiA+DQo+ID4gw5ggICAg UG9ydCBVbnJlYWNoYWJsZSBtZXNzYWdlcy4gVGhpcyB3aWxsICBjYXVzZSBhIGxlZ2l0aW1hdGUg c291cmNlIHRvIGNlYXNlIHNlbmRpbmcNCj4gPg0KPiA+IMOYICAgIHBhY2tldHMgdG8gdGhlIHVu cmVhY2hhYmxlIHBvcnQuDQo+ID4NCj4gPiBTdXJlLiBCdXQgeW91IHdlcmUgdGFsa2luZyBhYm91 dCBET1MgYXR0YWNrcywgYW5kIHRob3NlIGFyZSBuZWl0aGVyIGxlZ2l0aW1hdGUgc291cmNlcyBu b3IgbGlrZWx5IHRvIHN0b3Agc2VuZGluZyBwYWNrZXRzIGluDQo+IHJlc3BvbnNlIHRvIHVucmVh Y2hhYmxlIGVycm9ycyA6LSkNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+IHY2b3BzQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Fri Sep 15 14:55:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D343132620 for ; Fri, 15 Sep 2017 14:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tOjO7yB3HQnr for ; Fri, 15 Sep 2017 14:55:13 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78042132199 for ; Fri, 15 Sep 2017 14:55:13 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 68FF02D505E; Fri, 15 Sep 2017 21:55:11 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 4C426108DB597; Fri, 15 Sep 2017 23:55:09 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A39B9123-425F-49BF-9F36-1BC51514B632"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 15 Sep 2017 23:55:08 +0200 In-Reply-To: <1617a42e3ba444dabdea3a556ed880d3@XCH15-06-08.nw.nos.boeing.com> Cc: Lorenzo Colitti , "v6ops@ietf.org" To: "Templin, Fred L" References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> <57417A52-D570-4F6C-AF44-54623A45121C@employees.org> <1617a42e3ba444dabdea3a556ed880d3@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 21:55:15 -0000 --Apple-Mail=_A39B9123-425F-49BF-9F36-1BC51514B632 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> -----Original Message----- >> From: Ole Troan [mailto:otroan@employees.org] >> Sent: Friday, September 15, 2017 2:23 PM >> To: Templin, Fred L >> Cc: Lorenzo Colitti ; v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: = draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt >>=20 >>> I have identified a DoS vector that can be mitigated if the router = uses address >>> resolution to protect the host. If it does that, the router SHOULD = send DUs. >>=20 >> The implementation we did of this was for the sole purpose of _not_ = having to do address resolution... >=20 > Then, the floodgates are open and the host can be DoS'd. The attack = profile > would not be too far different than the DYN attack back last October. as in the host will receive packets that it will drop? how is that any different from an attacker just sending more traffic to = one of the host's addresses than it can handle. not sure I'm getting what the issue is here. Cheers, Ole --Apple-Mail=_A39B9123-425F-49BF-9F36-1BC51514B632 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZvEw9AAoJEL7aWKiYQt92op0P/2TkgUJaAqV0o6g/srPNHqQq If16Zj4+uGz32xKVpeJAkJkRsIgEWfTO04IO0QQ0qv/y8CoX3WsM4vIPTNdIork0 3PlyA0tpspApshXzAlX8IxZuAXs/uYl0ur1hiw9CjKNALk9/YQgc5O562tx4qld4 hvGBBFwxDXwkrQ+UGY1zr2dIKh/U8Aa295fNULvKk84H6GL3M0fzeolqyC7Bg0s6 0lr4QwyEX26plvPOdW5zroW+j2oHR4hhGC1qsuXsn1rODx9GThVmLhNnk1n+spxq t/thYBQUQr6D+o9DsJ8cY28JDBue2JgNBKTDu/pMKatAf/h2HI08K3FeT6cjcy5T pO2ucHzlasyOXtylmLlnAtDW3/KQ8KnS9mGSQs+ZYtn55fQya8UTJPAtMhU4umlF ITQ7dVT98BVo1Lj496zKXd0kRCsvlH9pf/BtmuZq01qSEasVKeM0D71T7AMXK56A xiS1YTwuwkEqFBn0GrOFmxc1CPCfEm1CNaDiVs6otK1UN/Ewc/L15QkdnuhBg+tA cy7Et992NFkQyFLfzoM0rZ+1t5SPiRo8iZXA4AIyQMa45W4XDyNc8D1jHUmEVLYp uHkuSBQDmLv5XJwOK7JYtYiYUL6XOwQOUJn41dZU87fycZziBbEyXjvcZRTZcm9Z J8pU+jJtD2AvNnOgBWoJ =4AAy -----END PGP SIGNATURE----- --Apple-Mail=_A39B9123-425F-49BF-9F36-1BC51514B632-- From nobody Fri Sep 15 16:07:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40C31320D9 for ; Fri, 15 Sep 2017 16:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsSOhkF8MU_x for ; Fri, 15 Sep 2017 16:07:37 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49689120724 for ; Fri, 15 Sep 2017 16:07:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8FN7ajX010660; Fri, 15 Sep 2017 16:07:36 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8FN7WXq010636 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 15 Sep 2017 16:07:33 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 15 Sep 2017 16:07:32 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Fri, 15 Sep 2017 16:07:31 -0700 From: "Templin, Fred L" To: Ole Troan CC: Lorenzo Colitti , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt Thread-Index: AQHTLY0R353fXvPDrEeoXyoh+k1EZqK2AYpwgAClIID//4rzsIAAd8+A//+K8tCAAHjkgP//nihQABQQ4gAADpweQP//lAMAgABjsNA= Date: Fri, 15 Sep 2017 23:07:31 +0000 Message-ID: References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> <57417A52-D570-4F6C-AF44-54623A45121C@employees.org> <1617a42e3ba444dabdea3a556ed880d3@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 23:07:39 -0000 Hi Ole, > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: Friday, September 15, 2017 2:55 PM > To: Templin, Fred L > Cc: Lorenzo Colitti ; v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-= host-09.txt >=20 > >> -----Original Message----- > >> From: Ole Troan [mailto:otroan@employees.org] > >> Sent: Friday, September 15, 2017 2:23 PM > >> To: Templin, Fred L > >> Cc: Lorenzo Colitti ; v6ops@ietf.org > >> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-p= er-host-09.txt > >> > >>> I have identified a DoS vector that can be mitigated if the router us= es address > >>> resolution to protect the host. If it does that, the router SHOULD se= nd DUs. > >> > >> The implementation we did of this was for the sole purpose of _not_ ha= ving to do address resolution... > > > > Then, the floodgates are open and the host can be DoS'd. The attack pro= file > > would not be too far different than the DYN attack back last October. >=20 > as in the host will receive packets that it will drop? > how is that any different from an attacker just sending more traffic to o= ne of the host's addresses than it can handle. Here, the attacker only needs to know the host's prefix; it does not need to know any of the host's addresses. The router will deliver all packets destined to any address within the prefix to the host unconditionally. This defeats the host's mitigation of using privacy addresses to avoid an off-path attacker somehow discovering its address and sending a flood of packets. Thanks - Fred=20 > not sure I'm getting what the issue is here. >=20 > Cheers, > Ole From nobody Fri Sep 15 16:29:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48FF1321C9 for ; Fri, 15 Sep 2017 16:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 XT4vNzzMW4Iz for ; Fri, 15 Sep 2017 16:29:16 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D7C1321A7 for ; Fri, 15 Sep 2017 16:29:16 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l4so2302212ywa.6 for ; Fri, 15 Sep 2017 16:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kbJDUqnobizLzhzIfJE/w15pPMnQpxXYcCtASYEMXLM=; b=S2VYVbKDmBe1a6ZlV5k8dv98FqtGcti6ELSLNn4ga8sXJnOieeO9cwADNfr4ievrnR 2KXhahPsz837iz9U+8u0aPM+lJujMkda7jY/Yo8barcVF71HkWaSzyf8lNIthHZjLRSc kWn1ovrlT0aByFfCYdoC14+lwB5+K6fPJgJx4sVuD8gYm30Egyd+lidF3tmkNepI6H2C b3R/BV6u7vzHnvCHvHxO9sfDZIVSTMcXDh/u7Lr1Y1IDXni3724JhPffsATJ64eCH7ve icwZzEeLDqJp1SZp464a/FFhmehhtEhHpDofmoy4fl8MeHZoIa1Azmgy+LcrC2t99Baa VlVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kbJDUqnobizLzhzIfJE/w15pPMnQpxXYcCtASYEMXLM=; b=azYS8Ob5RsS23uZKUeZJQIoXBXn7N06/ZNO8brJGcww7mErSmNNZpUde5KJEVPQ3w3 w68UnebbpmEagF1tQ0YXVbucbIUT4pxgVmWjQMer2LOnHrtHMAbgw1p2WCFvrR6tgVZL wPrb2xTLIouqxsgssk2y6ltgs/h5Ke7jaoHGWxIuGTcHzqmC3JTuBRJ8smphoFHYlivK paxnGnKPNXyD6p/qqmDdZr21zUeV3XRvf7NN81vPzJQlhRzM9XVhFVe+pNSmU+/Trzl1 OzmPyh5O5ZvD7ZJ/7f6skd/RC3rYNCi+00hM8NvzfPU3CYZMwnKtUc+i1d+aGK4v1/fU ogZA== X-Gm-Message-State: AHPjjUgr6YsPIKXWc6wdF+RNC9kg5KjmRuWQ8PKWDtIFonsetaa727Rq lMf4C+iKaWo8G7wJOatS3WtIf0bPyvG1B47Bsi2jN5qK X-Google-Smtp-Source: ADKCNb4sbqwz4EAziOsTjj8tiBemA06OGFZnhr8WDpeINOMeiotFueCvTFKeBq/6t4bFpXOrYGdWzsasjQvrdYAKvgM= X-Received: by 10.37.53.134 with SMTP id c128mr22569067yba.336.1505518155622; Fri, 15 Sep 2017 16:29:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Fri, 15 Sep 2017 16:28:54 -0700 (PDT) In-Reply-To: <57417A52-D570-4F6C-AF44-54623A45121C@employees.org> References: <150541619338.18973.1376799734453993603@ietfa.amsl.com> <8d9f60f3eeb04a9f9b2d49cc1549288c@XCH15-06-08.nw.nos.boeing.com> <0e85678e70b243709887ad4a2f21e5fd@XCH15-06-08.nw.nos.boeing.com> <38d4a1701dd64a62b93e087f7c42756b@XCH15-06-08.nw.nos.boeing.com> <57417A52-D570-4F6C-AF44-54623A45121C@employees.org> From: Lorenzo Colitti Date: Fri, 15 Sep 2017 16:28:54 -0700 Message-ID: To: Ole Troan Cc: "Templin, Fred L" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a114bbba6def2af055942c243" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-09.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 23:29:19 -0000 --001a114bbba6def2af055942c243 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 2:23 PM, Ole Troan wrote: > > I have identified a DoS vector that can be mitigated if the router uses > address > > resolution to protect the host. If it does that, the router SHOULD send > DUs. > > The implementation we did of this was for the sole purpose of _not_ having > to do address resolution... > Exactly. --001a114bbba6def2af055942c243 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 15, 2017 at 2:23 PM, Ole Troan <otroan@employees.org> wrote:
> I have = identified a DoS vector that can be mitigated if the router uses address > resolution to protect the host. If it does that, the router SHOULD sen= d DUs.

The implementation we did of this was for the sole purpose of _not_ = having to do address resolution...

Exac= tly.=C2=A0
--001a114bbba6def2af055942c243-- From nobody Sun Sep 17 20:25:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820C2132713 for ; Sat, 16 Sep 2017 15:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNZGjIphJpoM for ; Sat, 16 Sep 2017 15:29:59 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740B71321BB for ; Sat, 16 Sep 2017 15:29:59 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id k20so3896387wre.4 for ; Sat, 16 Sep 2017 15:29:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vpnICkhfgSTxqaFtRWbaO0poLxJwgtyWtGUiJgYmTow=; b=0mSKETvLCuornzG+fHQaBMGmL4sB3e2GUWtNW6rw1K+xSEz5KMzUf7Zl1HvQPLdYO8 jC+Ef7qryGmLQ1gY0WQtQ1EZ80Eksg7SKeAu8NyV5zg+gUxOdS2OyB6owOgtNcsXUEd6 xqVrMh7bcHBInKjAiHAV4qhprml2mhf7i3g9njLJKjKvr4CDBNr2KkE4V0kd2v3FemHe iBfPID4SSNifB2RnjbJMLnCcJBcJsjCha8i3PUWfJSlErOF7iEXgSX/ipYhy7iUiDEsE iVq+qzXJxeMZoodFI6D6u1sJIS0Lko+M8C8gB7aoeZ8bhAxFWTX6nvvLGYlwhQIo5l7W nFjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vpnICkhfgSTxqaFtRWbaO0poLxJwgtyWtGUiJgYmTow=; b=J6q0hST+tVpC+Ew0iwSi2u0pquf+Yi5LtRAPIQZb7vpo3EwWwdS9bkx/B53fdCau5s p/u/RhPRcFBkhChKf3RQrzSHbIj9oSAA3dsutLze2spD58m2eduH+HhM9Gf4qovC20Uc 9z9bMvK5Fsw2GSBpRLF2hlPKBsrCo0WbLZSFzy81I4VNVk+VNmmbf0YGTYc8Oa9nyeVF Yc2Kv+4aZlo9hHK3DO5OKEJRJgxdbu+6xrIeWolqNj+0oelOmsRJq/GhBBbUfTyviJrl FHXOAI/IPhqel8W80m3vb/QyirIvsGr0Um2XRF1gotZT4h0wAFCZaOMI5tOxsOBHL6ci nN4w== X-Gm-Message-State: AHPjjUgfHqP3rKcOkVVnX0M0lrKAiLoY80GQXajKS8najycSmF856qFU jYbiVpN/ctxJg5wtZEfU9sRupfMU4wtHWTIOvuzMDQ== X-Google-Smtp-Source: ADKCNb6LD0nTHk0v4jKItkdxXz2V9vDcSf/CjdINu8lA6qA8ww+kBNeEyCMckz7vaSnLg/AbxvIl0RIOl5EPZeDPI1Y= X-Received: by 10.223.156.199 with SMTP id h7mr22105662wre.170.1505600997775; Sat, 16 Sep 2017 15:29:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.141 with HTTP; Sat, 16 Sep 2017 15:29:17 -0700 (PDT) In-Reply-To: <150522719582.4692.5662383794098533190.idtracker@ietfa.amsl.com> References: <150522719582.4692.5662383794098533190.idtracker@ietfa.amsl.com> From: Warren Kumari Date: Sat, 16 Sep 2017 18:29:17 -0400 Message-ID: To: IETF Discuss Cc: Ron Bonica , V6ops Chairs , draft-ietf-v6ops-rfc6555bis@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Sun, 17 Sep 2017 20:25:27 -0700 Subject: Re: [v6ops] Last Call: (Happy Eyeballs Version 2: Better Connectivity Using Concurrency) to Proposed Standard X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 22:30:01 -0000 [ - IETF announce, v6ops to BCC (to cut down on clutter) ] On Tue, Sep 12, 2017 at 10:39 AM, The IESG wrote: > > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: - 'Happy Eyeballs Version 2: Better > Connectivity Using Concurrency' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2017-09-26. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginning of > the Subject line to allow automated sorting. > > Abstract > > > Many communication protocols operated over the modern Internet use > host names. These often resolve to multiple IP addresses, each of > which may have different performance and connectivity > characteristics. Since specific addresses or address families (IPv4 > or IPv6) may be blocked, broken, or sub-optimal on a network, clients > that attempt multiple connections in parallel have a higher chance of > establishing a connection sooner. This document specifies > requirements for algorithms that reduce this user-visible delay and > provides an example algorithm. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > After the IETF LC was started the authors became aware that their employer might possibly have some IPR associated with this document. They are checking with their legal team to determine if this is the case, and will file the necessary disclosures if there is. I felt I should make the community aware, and also wanted to explicitly thank the authors for giving us a heads up. Warren. > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Sep 18 11:18:10 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9466F133211; Mon, 18 Sep 2017 11:17:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150575867755.15571.8632904574264251001@ietfa.amsl.com> Date: Mon, 18 Sep 2017 11:17:57 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 18:17:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt Pages : 9 Date : 2017-09-18 Abstract: This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique service provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 18 11:27:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC66132D49 for ; Mon, 18 Sep 2017 11:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWTZjD5CIPCe for ; Mon, 18 Sep 2017 11:27:20 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50109.outbound.protection.outlook.com [40.107.5.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54AA133055 for ; Mon, 18 Sep 2017 11:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jFm93W+TtC3LBs57SvWdRmT24XdBNxoxfNSQQvsa8Fc=; b=gsxAU2bl262xwDAauAIBdLdqag5NEr0KReYr0JJwIH10RXNiclhEbDPQNM3rAg2mFiBZVqdBqNlHuREfmdclIAnYjDkHs5W3PmyMXJQHcGVL7ZA/YLIinSI+eO38h1judLFe1sdLd+DzfDu7SFe6Ab5JQHLgAMAITrbofhPrPYY= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB3378.eurprd07.prod.outlook.com (10.171.189.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Mon, 18 Sep 2017 18:27:16 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be%13]) with mapi id 15.20.0077.008; Mon, 18 Sep 2017 18:27:15 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt Thread-Index: AQHTMKqSHyyFE1ISGU+DcnGVKp+tvaK7F7KA Date: Mon, 18 Sep 2017 18:27:15 +0000 Message-ID: <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> In-Reply-To: <150575867755.15571.8632904574264251001@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.242.26.240] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB3378; 6:zdy+VL1NgXNNMh5eUGoPEudneeyuKoWawqMtS0lUIV9hhTT1NvTAhLEWApOs3l+Dv4E0BDf4g3V6wQSIe84gk1eG+KnUf+AhFvUzvm4Y+oFLP4nhf6HitnTBnnjm58femjWLxJ07SAV0yk5vB1sVK6EpYhk7RSiBDS80KD8ybCpMz6IXSMQVDrAxUp9q+feBymDqNE6k9cBaK0ZXyGM5+oCfCSCBPRLtVXf2IAN2r3SRSqgkIpEhhsJlP8hO3MvIxInePe2GRDhEAS/1Pv79uVO6tVV1f0RkfEaOpffv8OYX6pPALefnRfL4dHv57x4H32m5utdY1gClbuCvDQPnfA==; 5:Ov6UfczVKmH1y1S8o66kbR/nBd0GUcNyIdnVAf5JKALO71W8fxJ9sPRrYEJlcyFomeV4t69a4wWbvv134BhMjpJAmsg7Zhf65V6k5BtVZc7zAYj+xSjzG6JlQeEu78uxzjCw/4FjQApcpk53zEqmYg==; 24:+Jo/JNAj12z1neNwtmz1PqBWf6sfcB0KxQb605PcTr1yzgyWG3GFuG+Mv2qy+eaC3W2zwx0NQG4FJ3Pfdoxzwu/T5npY2aF9kh8rSf63fts=; 7:3Mpr9aVfaDXop6lqs4lxIUS+rnlD5XjullJa7qonNa3wmuqAeR3MW294fZpjHVqnkmUBGoq+CmBtTk2LX0ehoomswYtew0+dpFK+1l8qRyrmiT+sBJj1NGlZ1dkJ7CcuLt1wJ/3nPbwQwrhJOF9sD8dCxQFDqEXFC1IyW8IgKcnQ6h6YkEgY51KOV6pKDcuk+MGSQ76pusnyj31NcuopRR2dY0d4EBEKt474re+eMes= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6d512bfc-a4e1-431d-512e-08d4fec2e380 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR07MB3378; x-ms-traffictypediagnostic: AM4PR07MB3378: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3378; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3378; x-forefront-prvs: 04347F8039 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(377424004)(24454002)(189002)(199003)(105586002)(68736007)(3660700001)(82746002)(33656002)(5640700003)(6486002)(5250100002)(316002)(6506006)(6436002)(25786009)(2900100001)(54356999)(76176999)(2501003)(83716003)(106356001)(2351001)(97736004)(305945005)(8936002)(81156014)(81166006)(478600001)(2906002)(2950100002)(6246003)(14454004)(6916009)(66066001)(101416001)(36756003)(53546010)(966005)(7736002)(189998001)(86362001)(229853002)(3280700002)(99286003)(6306002)(230783001)(5660300001)(8676002)(50986999)(6512007)(53936002)(3846002)(6116002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3378; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2017 18:27:15.8623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3378 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 18:27:22 -0000 DQpAYWxsLCB0aGlzIHZlcnNpb24gc2hvdWxkIG5vdyBoYXZlIGFsbCBhZ3JlZWQgY2hhbmdlcyBh cyBkaXNjdXNzZWQgdml2aWRseSBkdXJpbmcgaW4gbGFzdCBmZXcgd2Vla3MgYXQgdjZvcHMuDQoN CkcvDQoNCg0KDQpPbiAxOC8wOS8yMDE3LCAyMDoxNywgInY2b3BzIG9uIGJlaGFsZiBvZiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmciIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgQSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz IGRpcmVjdG9yaWVzLg0KICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIElQdjYg T3BlcmF0aW9ucyBXRyBvZiB0aGUgSUVURi4NCiAgICANCiAgICAgICAgICAgIFRpdGxlICAgICAg ICAgICA6IFVuaXF1ZSBJUHY2IFByZWZpeCBQZXIgSG9zdA0KICAgICAgICAgICAgQXV0aG9ycyAg ICAgICAgIDogSm9obiBKYXNvbiBCcnpvem93c2tpDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBHdW50ZXIgVmFuIERlIFZlbGRlDQogICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTEwLnR4dA0KICAgIAlQYWdlcyAg ICAgICAgICAgOiA5DQogICAgCURhdGUgICAgICAgICAgICA6IDIwMTctMDktMTgNCiAgICANCiAg ICBBYnN0cmFjdDoNCiAgICAgICBUaGlzIGRvY3VtZW50IG91dGxpbmVzIGFuIGFwcHJvYWNoIHV0 aWxpc2luZyBleGlzdGluZyBJUHY2IHByb3RvY29scw0KICAgICAgIHRvIGFsbG93IGhvc3RzIHRv IGJlIGFzc2lnbmVkIGEgdW5pcXVlIElQdjYgcHJlZml4IChpbnN0ZWFkIG9mIGENCiAgICAgICB1 bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLiAgQmVuZWZpdHMg b2YgdW5pcXVlDQogICAgICAgSVB2NiBwcmVmaXggb3ZlciBhIHVuaXF1ZSBzZXJ2aWNlIHByb3Zp ZGVyIElQdjYgYWRkcmVzcyBpbmNsdWRlDQogICAgICAgaW1wcm92ZWQgaG9zdCBpc29sYXRpb24g YW5kIGVuaGFuY2VkIHN1YnNjcmliZXIgbWFuYWdlbWVudCBvbiBzaGFyZWQNCiAgICAgICBuZXR3 b3JrIHNlZ21lbnRzLg0KICAgIA0KICAgIA0KICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0Lw0KICAg IA0KICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAg ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2 Ni1wcmVmaXgtcGVyLWhvc3QtMTANCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTEwDQog ICAgDQogICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 Og0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXY2b3Bz LXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0xMA0KICAgIA0KICAgIA0KICAgIFBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24NCiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgIA0KICAgIEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQogICAgdjZv cHNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQogICAgDQoNCg== From nobody Mon Sep 18 11:47:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9281241F3 for ; Mon, 18 Sep 2017 11:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbwBPdPFO3Lu for ; Mon, 18 Sep 2017 11:47:21 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B19126BF3 for ; Mon, 18 Sep 2017 11:47:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8IIlK5h041839; Mon, 18 Sep 2017 11:47:21 -0700 Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8IIlF84041689 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 18 Sep 2017 11:47:15 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 18 Sep 2017 11:47:14 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 18 Sep 2017 11:47:14 -0700 From: "Templin, Fred L" To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt Thread-Index: AQHTMKqSHyyFE1ISGU+DcnGVKp+tvaK7F7KA///fypA= Date: Mon, 18 Sep 2017 18:47:14 +0000 Message-ID: References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> In-Reply-To: <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 18:47:23 -0000 Hi Gunter, I think the document could benefit from adding the following text: "After advertising the prefix, the router can regard the prefix as either= on-link or not on-link. If on-link, the router performs address resolution for IPv= 6 destinations that match the prefix and follows [RFC4443] procedures for returning De= stination Unreachable messages if address resolution fails. This protects the hos= t from receiving unwanted packets for IPv6 addresses that the host is not curr= ently using, but requires the router to maintain state. If not on-link, the router u= nconditionally delivers all packets for IPv6 destinations that match the prefix to the= host, where the host will silently drop any packets that do not match one of its co= nfigured addresses. This allows the router to remain stateless, but can deliver = unwanted packets to the host even if the host is using techniques such as IPv6 p= rivacy addressing [RFC4941][RFC7721] in an attempt to avoid the same." Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Van De Velde, Gu= nter (Nokia - BE/Antwerp) > Sent: Monday, September 18, 2017 11:27 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-= host-10.txt >=20 >=20 > @all, this version should now have all agreed changes as discussed vividl= y during in last few weeks at v6ops. >=20 > G/ >=20 >=20 >=20 > On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" > wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.tx= t > Pages : 9 > Date : 2017-09-18 >=20 > Abstract: > This document outlines an approach utilising existing IPv6 protoco= ls > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of uniqu= e > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shar= ed > network segments. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-= per-host/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-h= ost-10 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-pr= efix-per-host-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pref= ix-per-host-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of sub= mission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Sep 18 12:28:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2C11326ED for ; Mon, 18 Sep 2017 12:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 tTFZYTBu0lKx for ; Mon, 18 Sep 2017 12:28:24 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65731320D8 for ; Mon, 18 Sep 2017 12:28:24 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id D66A66B5 for ; Mon, 18 Sep 2017 19:28:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXUq5ANKvXrs for ; Mon, 18 Sep 2017 14:28:23 -0500 (CDT) Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 78C7D686 for ; Mon, 18 Sep 2017 14:28:23 -0500 (CDT) Received: by mail-lf0-f72.google.com with SMTP id m199so964676lfe.3 for ; Mon, 18 Sep 2017 12:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GDBmOIh2wjqJGLEhiMxOsyZickp8sgVs0U0hxOcMD/s=; b=SYfu2CzcOkBeripLliwEV+hmx+tJmAUdsoaKt725rmFRTTx0iixhCuAqrc15d54ls3 0MngeHwbhHvvGGnGcvGVuGIB3q9/Ki6zkfWWOFT9HCSSmNHukxLyAguP5Ef1O1vWnq+O Gz63lt0fS4CbSQniqvhqNSmUouF+K5GMl1jVOubVl/gwx+rpGwMn8jnYax5y0vzxklFE fCYWjESR/1V94jUX0iVRzFu56nSyCXjLqaw8tUB+ZELki59Hya7rV9tnQQAVpgYMv0Nf Y7dKtTQF37nefuKcUuLk9lFOuh+SXuX+tvKV35yiowL2Rl47c9jFkexrbeVxqvJY4vj4 Swyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GDBmOIh2wjqJGLEhiMxOsyZickp8sgVs0U0hxOcMD/s=; b=lkXahyjiqQ01fiapcAC4dMCTx3qNkFXXqge6jb2kypNBlSNDn5DVee3wAPZp0W8nsE sxi1dRnCKdHX/d0CvdQSc3L2cwxSsBjz3qVqUKF4ipPLg4TUPH/ed2cmmkUcHaontm/K YrqCAZaFShG0yJ1mZOE0leDMSdwD4o71yT9Xs4E6q+6Kt2gZBKEKQwur8cS34+SFMbYD F0bsvnhgk17X7laYOgEgsJjej6s+VNvcrTvR0HqPuMQwN39vc3gQlDAtzcivXvj1yX4y rkHHLAbVuEoA84iRaTHu8muTtW2METAlhxZV2bG7++Xv49IP0hucoAbiiCxhE1ihqXGu fktQ== X-Gm-Message-State: AHPjjUhiVXIEBvhzgUmilydVo9BoxRk3Tyxb52Y0v3lygXHru4CXRfup gJzclzrFIoY0rBEqIs4fBebnIRfSslmWxVMfYklhSaHDTkJux0atrOYMTlAY/chaIWYj/6nOTsi FxvsFliWVnbZVTP13oLwv/VZUTg== X-Received: by 10.25.22.106 with SMTP id m103mr3739413lfi.168.1505762902033; Mon, 18 Sep 2017 12:28:22 -0700 (PDT) X-Google-Smtp-Source: AOwi7QB5VViv/9B6+NPcto5UNG2yjs9KMFTVvEHbI1NS8y45uZsqHpo2tgqfIJ43ttF2uy/rXWQ9qeHnrdJmHALMaV8= X-Received: by 10.25.22.106 with SMTP id m103mr3739406lfi.168.1505762901852; Mon, 18 Sep 2017 12:28:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Mon, 18 Sep 2017 12:28:21 -0700 (PDT) In-Reply-To: <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> From: David Farmer Date: Mon, 18 Sep 2017 14:28:21 -0500 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a11407d24e19b3f05597bbe19" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 19:28:27 -0000 --001a11407d24e19b3f05597bbe19 Content-Type: text/plain; charset="UTF-8" LGTM! On Mon, Sep 18, 2017 at 1:27 PM, Van De Velde, Gunter (Nokia - BE/Antwerp) < gunter.van_de_velde@nokia.com> wrote: > > @all, this version should now have all agreed changes as discussed vividly > during in last few weeks at v6ops. > > G/ > > > > On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" < > v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6- > prefix-per-host-10.txt > Pages : 9 > Date : 2017-09-18 > > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique- > ipv6-prefix-per-host/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6- > prefix-per-host-10 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops- > unique-ipv6-prefix-per-host-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique- > ipv6-prefix-per-host-10 > > > 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 > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --001a11407d24e19b3f05597bbe19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
LGTM!

On Mon, Sep 18, 2017 at 1:27 PM, Van De Velde, Gunter (Nokia - BE/Antw= erp) <gunter.van_de_velde@nokia.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
@all, this version should now have all agreed changes as discussed vividly = during in last few weeks at v6ops.

G/



On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" <v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts directories.
=C2=A0 =C2=A0 This draft is a work item of the IPv6 Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Unique IPv6 Prefix Per Host
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: John Jason Brzozowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gunter Van De Velde
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-unique-ipv6-prefix-per-host-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-18

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document outlines an approach utilising exi= sting IPv6 protocols
=C2=A0 =C2=A0 =C2=A0 =C2=A0to allow hosts to be assigned a unique IPv6 pref= ix (instead of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0unique IPv6 address from a shared IPv6 prefix).= =C2=A0 Benefits of unique
=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 prefix over a unique service provider IPv6 = address include
=C2=A0 =C2=A0 =C2=A0 =C2=A0improved host isolation and enhanced subscriber = management on shared
=C2=A0 =C2=A0 =C2=A0 =C2=A0network segments.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://= datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/

=C2=A0 =C2=A0 There are also htmlized versions available at:
=C2=A0 =C2=A0 https://too= ls.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10<= /a>
=C2=A0 =C2=A0 h= ttps://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6= -prefix-per-host-10

=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pre= fix-per-host-10


=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.= org.

=C2=A0 =C2=A0 Internet-Drafts are also available by anonymous FTP at:
=C2=A0 =C2=A0 ftp://ftp.ietf.org/internet-drafts/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/v6ops


_______________________________________________
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 Email:farmer@umn.edu
Networking & = Telecommunication Services
Office of Information Technology
Universit= y of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: = 612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
--001a11407d24e19b3f05597bbe19-- From nobody Mon Sep 18 13:25:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB6513302A for ; Mon, 18 Sep 2017 13:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIRllvrCvz_F for ; Mon, 18 Sep 2017 13:25:30 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170D9132D42 for ; Mon, 18 Sep 2017 13:25:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v8IKPT05041318; Mon, 18 Sep 2017 13:25:29 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v8IKPNcS040899 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Mon, 18 Sep 2017 13:25:23 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 18 Sep 2017 13:25:22 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 18 Sep 2017 13:25:22 -0700 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: I-D Action: draft-templin-v6ops-pdhost-08.txt Thread-Index: AQHTMLqOrcrgokXiyk+iTwx3byVZOKK7E/5g Date: Mon, 18 Sep 2017 20:25:22 +0000 Message-ID: <5211e01a3b804577a76a707021fbd980@XCH15-06-08.nw.nos.boeing.com> References: <150576558265.15549.2669766058235367337@ietfa.amsl.com> In-Reply-To: <150576558265.15549.2669766058235367337@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [v6ops] I-D Action: draft-templin-v6ops-pdhost-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 20:25:32 -0000 See attached for the latest version of "IPv6 Prefix Delegation for End Syst= ems". This version resolves the list comments from Fred Baker and Ole Troan. This is about prefix delegation to end systems. It is different than 'draft-ietf-v6ops-unique-ipv6-prefix-per-host' in that the end system expli= citly participates in the prefix delegation and maintenance procedures, and there= fore knows that the prefix has been delegated for its own exclusive use. This al= lows the end system to autoconfigure addresses for itself without having to perf= orm DAD over the upstream interface for each address. Again, "unique-ipv6-prefix-per-host" is not a prefix delegation service whe= reas this document is. Both will be useful for their own respective use cases, s= o the two should be seen as complimentary and not in competition. Comments on the list would be appreciated. Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Monday, September 18, 2017 1:13 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-pdhost-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 Prefix Delegation for End Systems Author : Fred L. Templin Filename : draft-templin-v6ops-pdhost-08.txt Pages : 10 Date : 2017-09-18 Abstract: IPv6 prefixes are typically delegated to requesting routers which then use them to number their downstream-attached links and networks. This document considers the case when the "requesting router" is actually an end system which receives a delegated prefix that it can use for its own sub-delegation and/or multi-addressing purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-v6ops-pdhost-08 https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-08 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 Mon Sep 18 18:31:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416AC1323B4 for ; Mon, 18 Sep 2017 18:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMX5GXrrUTFa for ; Mon, 18 Sep 2017 18:31:21 -0700 (PDT) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8660E128D0D for ; Mon, 18 Sep 2017 18:31:21 -0700 (PDT) Received: by mail-pg0-x234.google.com with SMTP id b11so1143770pgn.12 for ; Mon, 18 Sep 2017 18:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4A0z2FkgvaymsD//TKEk3Ntdm/0XqVwLPuY/WE5Wpxg=; b=qsz92vlVIrh60iNKIXR3h+vZ1EqaUtAElJdndDc/ywZvHu/fVMMoy8ohIy3e02HBTk ncXMNiCzErs9akAfZm1YvNdHk8UU7Sc0feUs/ncPO/PmViHpSBK/zeqSEZKL82umR2SJ OS6u6jLuiOJIbkpszMUc1JwZ0XykkXKE7il4rvQF6CYCzbigm/0WNUNcRrdDEbv2Mrt/ y021XeL05hMJfCfRDm0J3uew63EtVqh84T6FLWFunITB08z01unfaHzdLPwR8htkjiND PSGlfbbjt03yw2wUPW2fBZOgWUoH6uBMrhh3jcqgsM7O19jhrVpjpbMhTHNeWLKCFqg7 +I1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=4A0z2FkgvaymsD//TKEk3Ntdm/0XqVwLPuY/WE5Wpxg=; b=iQXboHFjHeqtYXA8Aw0k1R9Ywhor1GxVy8vO3+6RFhABPHcAL+RZ6XI8JiBFBoy1Ef iE0folf1u/oYL1rasI5SAE3pj9rworgtSpPH93j5C1TATcgY3ARBmsVOC8K9cFdVCdW2 BmgauBPrJ+gfY/eLq/7+HhKkHymWiprh6c32q2+dDxaZg8qzuhT5Qs9DIsLVjNkke9Y7 qhS9k0HyfLGY+UB+qsSjv0WqJ5BTFVr+HgwX+2LnlluTuEFEJTw75nOJjpeg24BD9XgR LT7bua0fqiUlleaTg2YHPMVrDE34vtWZpoZaPWRH2vb8m1pnu7EAtJqOFGwdG3oj2cZ/ +KQg== X-Gm-Message-State: AHPjjUg8zmDZY+N796gvzAn2AxweL4ktXER2/Ao0QAIrt128nCi0gE1o 86lM+9vNKyTj3Ti9 X-Google-Smtp-Source: AOwi7QCqJTvaMYlVb6SFccsq+726LYOmAjpAOadbHcVha2DTD6RL2CWHrJhYABmWXZzHUszWgOihhA== X-Received: by 10.98.156.207 with SMTP id u76mr438468pfk.190.1505784680081; Mon, 18 Sep 2017 18:31:20 -0700 (PDT) Received: from [172.24.23.195] ([202.36.244.181]) by smtp.gmail.com with ESMTPSA id s184sm740142pfb.123.2017.09.18.18.31.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 18:31:19 -0700 (PDT) To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5ed2d4a0-3dac-eaad-c476-9e26e2c3c964@gmail.com> Date: Tue, 19 Sep 2017 13:31:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 01:31:23 -0000 Works for me, thanks. Regards Brian On 19/09/2017 06:27, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > > @all, this version should now have all agreed changes as discussed vividly during in last few weeks at v6ops. > > G/ > > > > On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt > Pages : 9 > Date : 2017-09-18 > > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-10 > > > 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 > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > . > From nobody Mon Sep 18 18:48:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72162120724 for ; Mon, 18 Sep 2017 18:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 WQggHkeJXlaQ for ; Mon, 18 Sep 2017 18:48:26 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1924413239C for ; Mon, 18 Sep 2017 18:48:26 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id 6so514929itl.1 for ; Mon, 18 Sep 2017 18:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t0jjUCkLvr1AmqijFiFOTXbrL+tba/npUi0X9bxlnkY=; b=OkQeomVhPqmR5snjYljMb9egrF104GkeV3aNCM3lq2nvKYjcyi1SEqQQX6QiDOSQhe JH9l0/kqblh4ilDEkaNwUvfNg/Sz1w1kWtqKLeJE9gJNT6XF8o2W8THlCUufOcogjw93 UvnrLskKFmQSTvZOfFCtMvZxS73QvEMHk9/3oubf+8+jT9Cy1kJxEJBegwaN1cp3Fngd nMC3W/YVxWGt2jparzyPI5t4DJOCqHUiS41OTEFsxTYLtZ7wmMuf/9hMquL3V0sGQQrj gfwoWloHb8vXzzAVyRttkRovOkSLEPQMkhDsQMcosIi03kGGripZd5ln7Fvx7k/HcZb7 IqAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t0jjUCkLvr1AmqijFiFOTXbrL+tba/npUi0X9bxlnkY=; b=kzhQrjCljnEAXltupKQPmx/UnHeaZhFPYW23mPZ9nocho4JOUXUHZdt7EW5VQilHv4 QEgjsE1RGaUSvk8gvnHN6SzrtoxXwY6k9x4k+MTuQrSiikbV+Iz9jRuXSdul5i2jCXpe UuPLleAf1597zd59pgpxy4SoLizz4VIH/x3PQacFcOfKMBEH/U3HAzuhubOrM8MUVqlJ GGPPwudxOXd88ttHWPPh5BgPYRoRk9eMXCFXGqkGQ3eAIf8vo9hPGAMXf0/9FSjQ7ySQ xtv09Sl5zsgQIp/dVm8Da43GXNPt9AiRrteCbDbAX7gFAVGZ1CIQ2beNBg9iqSH6es4h 3CKA== X-Gm-Message-State: AHPjjUhdDr0dRbgOR1njio02EIAPgP9P2ps+hcDDjgxpSJCrgExgud4S qtSMRKQWtxUDhEGLYEHg78FRgWAUyqZVtxM+5oXCkw== X-Google-Smtp-Source: AOwi7QBpHB2+cmMeb0JSRR0T1UZdrHkIwN7tnnhKtxB57HDPDikrRDhh8zak+4UJJ77yl8YbHlJ2oU6STRJ9brStpkU= X-Received: by 10.36.200.132 with SMTP id w126mr155320itf.101.1505785705096; Mon, 18 Sep 2017 18:48:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Mon, 18 Sep 2017 18:48:04 -0700 (PDT) In-Reply-To: <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> From: Lorenzo Colitti Date: Tue, 19 Sep 2017 10:48:04 +0900 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0602560fe13c0559810e97" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 01:48:28 -0000 --94eb2c0602560fe13c0559810e97 Content-Type: text/plain; charset="UTF-8" We still need to address the issue of the RA lifetimes in the presence of mobile devices that drop multicast packets. If the RA interval is set to 600s (recommended by 7772), and devices drop 2/3 multicast packets, then 29% of the time, after 30 minutes the device's IPv6 addresses will be deprecated and the device will start preferring IPv4 over IPv6. On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) < gunter.van_de_velde@nokia.com> wrote: > > @all, this version should now have all agreed changes as discussed vividly > during in last few weeks at v6ops. > > G/ > > > > On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" < > v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6- > prefix-per-host-10.txt > Pages : 9 > Date : 2017-09-18 > > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique- > ipv6-prefix-per-host/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6- > prefix-per-host-10 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops- > unique-ipv6-prefix-per-host-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique- > ipv6-prefix-per-host-10 > > > 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 > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c0602560fe13c0559810e97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We still need to address the issue of the RA lifetimes in = the presence of mobile devices that drop multicast packets.

<= div>If the RA interval is set to 600s (recommended by 7772), and devices dr= op 2/3 multicast packets, then 29% of the time, after 30 minutes the device= 's IPv6 addresses will be deprecated and the device will start preferri= ng IPv4 over IPv6.

On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, Gunter (Nokia -= BE/Antwerp) <gunter.van_de_velde@nokia.com> wro= te:

@all, this version should now have all agreed changes as discussed vividly = during in last few weeks at v6ops.

G/



On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" <v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts directories.
=C2=A0 =C2=A0 This draft is a work item of the IPv6 Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Unique IPv6 Prefix Per Host
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: John Jason Brzozowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gunter Van De Velde
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-unique-ipv6-prefix-per-host-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-18

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document outlines an approach utilising exi= sting IPv6 protocols
=C2=A0 =C2=A0 =C2=A0 =C2=A0to allow hosts to be assigned a unique IPv6 pref= ix (instead of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0unique IPv6 address from a shared IPv6 prefix).= =C2=A0 Benefits of unique
=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 prefix over a unique service provider IPv6 = address include
=C2=A0 =C2=A0 =C2=A0 =C2=A0improved host isolation and enhanced subscriber = management on shared
=C2=A0 =C2=A0 =C2=A0 =C2=A0network segments.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://= datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/

=C2=A0 =C2=A0 There are also htmlized versions available at:
=C2=A0 =C2=A0 https://too= ls.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10<= /a>
=C2=A0 =C2=A0 h= ttps://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6= -prefix-per-host-10

=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pre= fix-per-host-10


=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.= org.

=C2=A0 =C2=A0 Internet-Drafts are also available by anonymous FTP at:
=C2=A0 =C2=A0 ftp://ftp.ietf.org/internet-drafts/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/v6ops


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

--94eb2c0602560fe13c0559810e97-- From nobody Mon Sep 18 19:22:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834D5126D0C for ; Mon, 18 Sep 2017 19:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmhTLTwLkhaC for ; Mon, 18 Sep 2017 19:22:06 -0700 (PDT) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9150C1201F8 for ; Mon, 18 Sep 2017 19:22:06 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-09v.sys.comcast.net with ESMTP id u8AUd2CnYS8pqu8AodARAN; Tue, 19 Sep 2017 02:22:06 +0000 Received: from [192.168.1.19] ([67.188.94.126]) by resomta-po-13v.sys.comcast.net with SMTP id u8AmdhCKtBsPAu8AndqGJS; Tue, 19 Sep 2017 02:22:06 +0000 From: Tony Li Message-Id: <1C18D9FE-4848-4513-987D-75E0D4DC0F4B@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_4D32E48F-0439-4B38-988C-CB43AE214F80" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 18 Sep 2017 19:22:03 -0700 In-Reply-To: Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" To: Lorenzo Colitti References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> X-Mailer: Apple Mail (2.3273) X-CMAE-Envelope: MS4wfNkIGagwTVIq7bsJF64/DVomHqZt/qfjxDjj+Q5nwZAIq6DH1TXgj+zMIFXe1ZqC6f+lWImZMjX8yycnci4JYmQUwh0CyOyAebv8bE8v8v6qobujOdQY DBhk5PiHSTnh1PfvAR/5XWWsGYkqRQGeKT1H04hm6F18m+BTO1B41lIId6KERzRKfCceq8l4NJW7t2WUgISgwwVzqQwhsYiNNGKaI1lmHKCjoM/4hjY6oCzg Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 02:22:08 -0000 --Apple-Mail=_4D32E48F-0439-4B38-988C-CB43AE214F80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Seems to me that if something is experiencing 66% packet loss for 30 = minutes that it should prefer disconnection. That=E2=80=99s wholly = unusable=E2=80=A6 Tony > On Sep 18, 2017, at 6:48 PM, Lorenzo Colitti = wrote: >=20 > We still need to address the issue of the RA lifetimes in the presence = of mobile devices that drop multicast packets. >=20 > If the RA interval is set to 600s (recommended by 7772), and devices = drop 2/3 multicast packets, then 29% of the time, after 30 minutes the = device's IPv6 addresses will be deprecated and the device will start = preferring IPv4 over IPv6. >=20 > On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, Gunter (Nokia - = BE/Antwerp) > wrote: >=20 > @all, this version should now have all agreed changes as discussed = vividly during in last few weeks at v6ops. >=20 > G/ >=20 >=20 >=20 > On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org = " on behalf of internet-drafts@ietf.org = > wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt > Pages : 9 > Date : 2017-09-18 >=20 > Abstract: > This document outlines an approach utilising existing IPv6 = protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of = a > unique IPv6 address from a shared IPv6 prefix). Benefits of = unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on = shared > network segments. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-h= ost/ = >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-1= 0 = > = https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-= per-host-10 = >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-pe= r-host-10 = >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at = tools.ietf.org . >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ = >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_4D32E48F-0439-4B38-988C-CB43AE214F80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Seems to = me that if something is experiencing 66% packet loss for 30 minutes that = it should prefer disconnection. That=E2=80=99s wholly = unusable=E2=80=A6

Tony


On = Sep 18, 2017, at 6:48 PM, Lorenzo Colitti <lorenzo@google.com> = wrote:

We still need to address the issue of the RA = lifetimes in the presence of mobile devices that drop multicast = packets.

If the RA = interval is set to 600s (recommended by 7772), and devices drop 2/3 = multicast packets, then 29% of the time, after 30 minutes the device's = IPv6 addresses will be deprecated and the device will start preferring = IPv4 over IPv6.

On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, = Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:

@all, this version should now have all agreed changes as discussed = vividly during in last few weeks at v6ops.

G/



On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" <v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:


    A New Internet-Draft is available from the on-line = Internet-Drafts directories.
    This draft is a work item of the IPv6 Operations WG of the = IETF.

            Title      =      : Unique IPv6 Prefix Per Host
            Authors      =    : John Jason Brzozowski
                    =           Gunter Van De Velde
        Filename        : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt
        Pages          =  : 9
        Date          =   : 2017-09-18

    Abstract:
       This document outlines an approach utilising = existing IPv6 protocols
       to allow hosts to be assigned a unique IPv6 = prefix (instead of a
       unique IPv6 address from a shared IPv6 = prefix).  Benefits of unique
       IPv6 prefix over a unique service provider = IPv6 address include
       improved host isolation and enhanced = subscriber management on shared
       network segments.


    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/

    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10
    https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10

    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-per-host-10


    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


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

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

= --Apple-Mail=_4D32E48F-0439-4B38-988C-CB43AE214F80-- From nobody Mon Sep 18 19:26:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06601321B6 for ; Mon, 18 Sep 2017 19:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 A8m-7eS3UmRr for ; Mon, 18 Sep 2017 19:26:35 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 559A51201F8 for ; Mon, 18 Sep 2017 19:26:35 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id r131so7659694itc.1 for ; Mon, 18 Sep 2017 19:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d950Moce1oiOGIcmKesO2piMcWOnhsYt/g/D5O1eJ0g=; b=FcrG32bys96u0TohwwK2+pJ3jFbFd78HDGml9Pn4ilev0lxrNXBikf1ogQuScnuxfC 1mYuClpN0ENrGsC4itwdlHZ5gQKldWzgGUarKkRoSXlDaIqNmPVWRACu5gfsr5w7b+xP zyCJmY5V1LXCot+neXm5qy7LhFa2o8dtq1SSCrBuAFKGgdiDo6eeVHmPEXzUof5ENnaw LzaILiB3Njn6NOLaTnfck8RTvwU8bVqffGGMpHeztfALGh1qisFpS7B13XzZ0zkAIQtA ucsEFKe4il8BwyO76Ib4l3Xnx/iQR6CCthS4MlLWxZX8O/+7viLEnSl/VZVrA8fKjyVe hoSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d950Moce1oiOGIcmKesO2piMcWOnhsYt/g/D5O1eJ0g=; b=EY1Fc6E8eWnYR6TfCCcf5i1oiuTKpgtwbKGspwfU5Y9JX2/PGnGOdMJL43ja67AOXO DX5m0vVUpSROH4eX1cA2I0v5fvVrXd7O1R/n5D23QoouwFvr8XVmo4mEmc+xEamqMjbi blsTWpl9lp2bJ0VUmFCg6vkE9L+4QQVijcXZRe2nq/4b0+21zO7V4CEcUOhwCyrBCifh PBdhLt1gvQyF4bXpMWDwLlAstj4g3WEdUazotWOY2lkXugDm8Bb7RLM366gGEaC45OoJ 824jyiq9/Ccc71moD4xqG2bnQOQaF16yCZzkYwzFNFuqY06+t8xAyQcIi58MSJcR/l68 yJiw== X-Gm-Message-State: AHPjjUi7ClZoL5C8C28s5lwzJY241hVaw63MIN0RVxVFIDmd7sm1tTyg /WDIsQZ6XH+DjkDqaQGtSbtoiAvT38sSTYpAJd3AsA== X-Google-Smtp-Source: AOwi7QAXsEY9+nfb7YxT8nauv3enFyE+k2CMWpevgsXD2ar0VeIYN2mJvIO5sE0pP/wUUKGK/n79IR/aAP77psbcUB4= X-Received: by 10.36.107.21 with SMTP id v21mr220092itc.43.1505787994236; Mon, 18 Sep 2017 19:26:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Mon, 18 Sep 2017 19:26:13 -0700 (PDT) In-Reply-To: <1C18D9FE-4848-4513-987D-75E0D4DC0F4B@tony.li> References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> <1C18D9FE-4848-4513-987D-75E0D4DC0F4B@tony.li> From: Lorenzo Colitti Date: Mon, 18 Sep 2017 19:26:13 -0700 Message-ID: To: Tony Li Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="f40304360e88818d8b0559819600" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 02:26:38 -0000 --f40304360e88818d8b0559819600 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable And yet, the reality is that lots of mobile devices listen to only one out of X wifi multicast/broadcast packets when the screen is off. I would suggest trying it on your phone and see what it does. On Mon, Sep 18, 2017 at 7:22 PM, Tony Li wrote: > > Seems to me that if something is experiencing 66% packet loss for 30 > minutes that it should prefer disconnection. That=E2=80=99s wholly unusab= le=E2=80=A6 > > Tony > > > On Sep 18, 2017, at 6:48 PM, Lorenzo Colitti wrote: > > We still need to address the issue of the RA lifetimes in the presence of > mobile devices that drop multicast packets. > > If the RA interval is set to 600s (recommended by 7772), and devices drop > 2/3 multicast packets, then 29% of the time, after 30 minutes the device'= s > IPv6 addresses will be deprecated and the device will start preferring IP= v4 > over IPv6. > > On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, Gunter (Nokia - BE/Antwerp= ) > wrote: > >> >> @all, this version should now have all agreed changes as discussed >> vividly during in last few weeks at v6ops. >> >> G/ >> >> >> >> On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" < >> v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IPv6 Operations WG of the IETF. >> >> Title : Unique IPv6 Prefix Per Host >> Authors : John Jason Brzozowski >> Gunter Van De Velde >> Filename : draft-ietf-v6ops-unique-ipv6-p >> refix-per-host-10.txt >> Pages : 9 >> Date : 2017-09-18 >> >> Abstract: >> This document outlines an approach utilising existing IPv6 >> protocols >> to allow hosts to be assigned a unique IPv6 prefix (instead of a >> unique IPv6 address from a shared IPv6 prefix). Benefits of uniq= ue >> IPv6 prefix over a unique service provider IPv6 address include >> improved host isolation and enhanced subscriber management on >> shared >> network segments. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv >> 6-prefix-per-host/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-pre >> fix-per-host-10 >> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-uniqu >> e-ipv6-prefix-per-host-10 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ip >> v6-prefix-per-host-10 >> >> >> 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 >> >> >> _______________________________________________ >> 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 > > > --f40304360e88818d8b0559819600 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And yet, the reality is that lots of mobile devices listen= to only one out of X wifi multicast/broadcast packets when the screen is o= ff.

I would suggest trying it on your phone and see what= it does.

On Mon, Sep 18, 2017 at 7:22 PM, Tony Li <tony.li@tony.li> wrote:

Seems to me that if something is experiencing 66% p= acket loss for 30 minutes that it should prefer disconnection. That=E2=80= =99s wholly unusable=E2=80=A6

Tony
<= div>

On Sep 18, 2017, at 6= :48 PM, Lorenzo Colitti <lorenzo@google.com> wrote:

We still need to a= ddress the issue of the RA lifetimes in the presence of mobile devices that= drop multicast packets.

If the RA interval is set to 60= 0s (recommended by 7772), and devices drop 2/3 multicast packets, then 29% = of the time, after 30 minutes the device's IPv6 addresses will be depre= cated and the device will start preferring IPv4 over IPv6.

On Tue, Sep 19, 2017 a= t 3:27 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <= gunter.v= an_de_velde@nokia.com> wrote:

@all, this version should now have all agreed changes as discussed vividly = during in last few weeks at v6ops.

G/



On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" <v6ops-bounces@iet= f.org on behalf of internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts directories.
=C2=A0 =C2=A0 This draft is a work item of the IPv6 Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Unique IPv6 Prefix Per Host
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: John Jason Brzozowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gunter Van De Velde
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-unique-ipv6-prefix-per-host-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-18

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document outlines an approach utilising exi= sting IPv6 protocols
=C2=A0 =C2=A0 =C2=A0 =C2=A0to allow hosts to be assigned a unique IPv6 pref= ix (instead of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0unique IPv6 address from a shared IPv6 prefix).= =C2=A0 Benefits of unique
=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 prefix over a unique service provider IPv6 = address include
=C2=A0 =C2=A0 =C2=A0 =C2=A0improved host isolation and enhanced subscriber = management on shared
=C2=A0 =C2=A0 =C2=A0 =C2=A0network segments.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://= datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/

=C2=A0 =C2=A0 There are also htmlized versions available at:
=C2=A0 =C2=A0 https://too= ls.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10<= /a>
=C2=A0 =C2=A0 h= ttps://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6= -prefix-per-host-10

=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pre= fix-per-host-10


=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf= .org.

=C2=A0 =C2=A0 Internet-Drafts are also available by anonymous FTP at:
=C2=A0 =C2=A0 ftp://ftp.ietf.org/internet-drafts/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/v6ops


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

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


--f40304360e88818d8b0559819600-- From nobody Mon Sep 18 20:05:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0D91321B6 for ; Mon, 18 Sep 2017 20:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.039 X-Spam-Level: X-Spam-Status: No, score=-4.039 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xnRa2iDK53oy for ; Mon, 18 Sep 2017 20:05:40 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44DA12426E for ; Mon, 18 Sep 2017 20:05:39 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 2D535B6 for ; Tue, 19 Sep 2017 03:05:39 +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 NKrOO-567KIV for ; Mon, 18 Sep 2017 22:05:38 -0500 (CDT) Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 99E9071A for ; Mon, 18 Sep 2017 22:05:38 -0500 (CDT) Received: by mail-lf0-f71.google.com with SMTP id q132so1650959lfe.1 for ; Mon, 18 Sep 2017 20:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xmyNcLNIP7cCtOHa8LEE2zUHCB53dR3odT94s6xbirU=; b=askDEJFg81+2G+JjLd+JxbV00QtW+TzSDDi6WA22mnA7UrP8ExAR5ZNrpFrGm394FC JenMTHy+H4QpySct7N9WtoNkSJ/UY62cwxLuWr9hwmLHGq4Zq0DKBJl2JB9Jw7T85yr1 D4bmz14K0SuQI3JJtLr6c7ZLoHZD6GqcaAYKHTnkF0+T3uXTYNUppxVGkA732+h22CPK g6MT4H3xG8W+/i0FymhdFxDDo88Xm/p2Wmvf4E6p8b9U5Pl/9aY7GLqapyw91fWy0lEm NlS2p5YkDzrC1BOjVFf4fb8C520B0e4w0qTKWVzYch3Q8sFOSa8pTFJiVOJtpB7FWc2D PLuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xmyNcLNIP7cCtOHa8LEE2zUHCB53dR3odT94s6xbirU=; b=I8SSzfXzDHOIaY6dN6xoNJHskhIB1+D7yKC6gU3Td4xbWcm70tyQNqxsEwC1/4vc8R dgS2aC0I0UYhyUnUfE0Ucz2i+cdfp9smt6+ZIA8JTlVgGDNQyrqqdwEVjcu2rA7z19RE uwNa7WMLEJtivuR5mHPpUjQv2kxgPtgUSs5VRNcyYRBEsJ333dS5MG2qpVt5oKnAMwZO L9+ReTpH9IovDUnKoqlszl8YFajZ8oJq5OgdM4syOy90gaZC2aPGTSCF/Dcvw9cKMuYv Lke8yFVbVZrdrxARnQuBdtEEbreS5DgCc48YilWaMGjuErCqYxKDc01qsTK4CymVmZx7 dOGw== X-Gm-Message-State: AHPjjUiE5xWG+pgJM2md09Jiq/4FNcscLZNYVGk+VVgrHtyZ/gkKd+q5 JZiJj2oGrBh54CP3P+5qGyHz6DIO/CTZPWj3dH91sKB6mqAMf4BLOkgqwW1+z0bCXgC+ky/7IKn ZKKq3sNST/py6h9a7+U4yb/fXJg== X-Received: by 10.46.88.20 with SMTP id m20mr7835453ljb.72.1505790337226; Mon, 18 Sep 2017 20:05:37 -0700 (PDT) X-Google-Smtp-Source: AOwi7QClQtQSyu0iMt6q7HSAW6eeW5WLPxAZpF7O5EWGxh5Ae2yorp0gS5Eh1lAbzVnP11KPtwvkMrVI9ZntZ7qYPiY= X-Received: by 10.46.88.20 with SMTP id m20mr7835450ljb.72.1505790337007; Mon, 18 Sep 2017 20:05:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Mon, 18 Sep 2017 20:05:36 -0700 (PDT) In-Reply-To: References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> <1C18D9FE-4848-4513-987D-75E0D4DC0F4B@tony.li> From: David Farmer Date: Mon, 18 Sep 2017 22:05:36 -0500 Message-ID: To: Lorenzo Colitti Cc: Tony Li , "v6ops@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" Content-Type: multipart/alternative; boundary="f4030438d53424d6580559822292" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 03:05:42 -0000 --f4030438d53424d6580559822292 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable However, in this case the RAs are not Multicast, at least at the link-layer. So, RA reception should be much less of a problem. That's not to say the recommended RA lifetimes shouldn't be adjusted appropriately though. On Mon, Sep 18, 2017 at 9:26 PM, Lorenzo Colitti wrote= : > And yet, the reality is that lots of mobile devices listen to only one ou= t > of X wifi multicast/broadcast packets when the screen is off. > > I would suggest trying it on your phone and see what it does. > > On Mon, Sep 18, 2017 at 7:22 PM, Tony Li wrote: > >> >> Seems to me that if something is experiencing 66% packet loss for 30 >> minutes that it should prefer disconnection. That=E2=80=99s wholly unusa= ble=E2=80=A6 >> >> Tony >> >> >> On Sep 18, 2017, at 6:48 PM, Lorenzo Colitti wrote: >> >> We still need to address the issue of the RA lifetimes in the presence o= f >> mobile devices that drop multicast packets. >> >> If the RA interval is set to 600s (recommended by 7772), and devices dro= p >> 2/3 multicast packets, then 29% of the time, after 30 minutes the device= 's >> IPv6 addresses will be deprecated and the device will start preferring I= Pv4 >> over IPv6. >> >> On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, Gunter (Nokia - >> BE/Antwerp) wrote: >> >>> >>> @all, this version should now have all agreed changes as discussed >>> vividly during in last few weeks at v6ops. >>> >>> G/ >>> >>> >>> >>> On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" < >>> v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the IPv6 Operations WG of the IETF. >>> >>> Title : Unique IPv6 Prefix Per Host >>> Authors : John Jason Brzozowski >>> Gunter Van De Velde >>> Filename : draft-ietf-v6ops-unique-ipv6-p >>> refix-per-host-10.txt >>> Pages : 9 >>> Date : 2017-09-18 >>> >>> Abstract: >>> This document outlines an approach utilising existing IPv6 >>> protocols >>> to allow hosts to be assigned a unique IPv6 prefix (instead of a >>> unique IPv6 address from a shared IPv6 prefix). Benefits of >>> unique >>> IPv6 prefix over a unique service provider IPv6 address include >>> improved host isolation and enhanced subscriber management on >>> shared >>> network segments. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv >>> 6-prefix-per-host/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-pre >>> fix-per-host-10 >>> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-uniqu >>> e-ipv6-prefix-per-host-10 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ip >>> v6-prefix-per-host-10 >>> >>> >>> 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 >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --=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 --f4030438d53424d6580559822292 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
However, in this case the RAs are not Multicast, at least = at the link-layer. So, RA reception should be much less of a problem. That&= #39;s not to say the recommended RA lifetimes shouldn't be adjusted app= ropriately though. =C2=A0=C2=A0

On Mon, Sep 18, 2017 at 9:26 PM, Lorenzo Colitti <lorenzo@g= oogle.com> wrote:
And yet, the reality is that lots of mobile dev= ices listen to only one out of X wifi multicast/broadcast packets when the = screen is off.

I would suggest trying it on your phone a= nd see what it does.

On Mon, Sep 18, 2017 at 7:22 PM, Tony Li <tony.li@tony.li> wrote:
<= div style=3D"word-wrap:break-word">

Seems to me that if = something is experiencing 66% packet loss for 30 minutes that it should pre= fer disconnection. That=E2=80=99s wholly unusable=E2=80=A6

Tony



=
We still need to address the issue of the RA lifetimes in = the presence of mobile devices that drop multicast packets.

<= div>If the RA interval is set to 600s (recommended by 7772), and devices dr= op 2/3 multicast packets, then 29% of the time, after 30 minutes the device= 's IPv6 addresses will be deprecated and the device will start preferri= ng IPv4 over IPv6.

On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, Gunter (Nokia -= BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:

@all, this version should now have all agreed changes as discussed vividly = during in last few weeks at v6ops.

G/



On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" <v6ops-bounces@iet= f.org on behalf of internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts directories.
=C2=A0 =C2=A0 This draft is a work item of the IPv6 Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Unique IPv6 Prefix Per Host
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: John Jason Brzozowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gunter Van De Velde
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-unique-ipv6-prefix-per-host-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-18

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document outlines an approach utilising exi= sting IPv6 protocols
=C2=A0 =C2=A0 =C2=A0 =C2=A0to allow hosts to be assigned a unique IPv6 pref= ix (instead of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0unique IPv6 address from a shared IPv6 prefix).= =C2=A0 Benefits of unique
=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 prefix over a unique service provider IPv6 = address include
=C2=A0 =C2=A0 =C2=A0 =C2=A0improved host isolation and enhanced subscriber = management on shared
=C2=A0 =C2=A0 =C2=A0 =C2=A0network segments.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://= datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/

=C2=A0 =C2=A0 There are also htmlized versions available at:
=C2=A0 =C2=A0 https://too= ls.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10<= /a>
=C2=A0 =C2=A0 h= ttps://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6= -prefix-per-host-10

=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pre= fix-per-host-10


=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf= .org.

=C2=A0 =C2=A0 Internet-Drafts are also available by anonymous FTP at:
=C2=A0 =C2=A0 ftp://ftp.ietf.org/internet-drafts/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/v6ops


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

_______________________________________________
v6ops mailing list<= br>v6ops@ietf.orghttps://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 Em= ail:farmer@umn.edu
Networking & Telecommunication Services
Of= fice of Information Technology
University of Minnesota=C2=A0=C2=A0
2= 218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Min= neapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f4030438d53424d6580559822292-- From nobody Mon Sep 18 23:52:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2779126E64 for ; Mon, 18 Sep 2017 23:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgE9zTPFvuIV for ; Mon, 18 Sep 2017 23:52:07 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E03A3126DFE for ; Mon, 18 Sep 2017 23:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1505803924; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=q6a6zHo2POYWVDsrAiWJzp68/2AuDC/uwcqNTwdiIIM=; b=agzQR1BMYiv4u3Y4O3TN4cV5UFPq4P71YJqU3SgQZQr9XkGCtoQoLh21Zk67eHt5jxqGDd9t0FKG/UDChjwctNVRm9Jofer3CK/6KvlblBHSvguFX+nai5q0wLVobTgSo7qiSkybsJmr4gxZrGVnZyRrsJYYL8mloLeJf9eNHK0= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0079.outbound.protection.outlook.com [94.245.120.79]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-116-F-fsinvYPj-AxO4lu8id_w-1; Tue, 19 Sep 2017 07:52:01 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1154.eurprd07.prod.outlook.com (10.163.188.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Tue, 19 Sep 2017 06:52:00 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590%14]) with mapi id 15.20.0077.009; Tue, 19 Sep 2017 06:52:00 +0000 From: Tim Chown To: Brian E Carpenter CC: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt Thread-Index: AQHTMKqd0jFOYC5Fek2QlvqqJVuCg6K69iuAgAB2eYCAAFmcuA== Date: Tue, 19 Sep 2017 06:52:00 +0000 Message-ID: <361764A2-E598-49B8-91E9-D2D54D72B8F0@jisc.ac.uk> References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com>, <5ed2d4a0-3dac-eaad-c476-9e26e2c3c964@gmail.com> In-Reply-To: <5ed2d4a0-3dac-eaad-c476-9e26e2c3c964@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:a88:d510:1101:fc4e:8315:5f47:6831] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1154; 20:h/11f3EG7amWHit7MI4jk6K7rqfURPUEQU5ufKyck8tKzuNeFNfNV4Upre1w11whrKrEcdOd+n7ybPXcxGzXre3HojOCSRLeeF1/kcgfmf2FHb45amT9T//hxxHgv/F4SxDakHbYkXLsnFWzldS2V6fU35vP9szBuYPV0cc40V4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6a420b54-d7b5-4437-2dd6-08d4ff2aed95 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1154; x-ms-traffictypediagnostic: AM3PR07MB1154: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1154; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1154; x-forefront-prvs: 04359FAD81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39830400002)(377424004)(24454002)(189002)(199003)(76176999)(74482002)(189998001)(54356999)(81166006)(86362001)(8676002)(230783001)(5250100002)(81156014)(3280700002)(7736002)(83716003)(25786009)(101416001)(36756003)(6116002)(3660700001)(102836003)(305945005)(50986999)(2906002)(8936002)(106356001)(105586002)(6486002)(39060400002)(2900100001)(5660300001)(33656002)(54906002)(53546010)(53936002)(14454004)(6306002)(6436002)(6512007)(82746002)(478600001)(99286003)(6506006)(6246003)(6916009)(42882006)(4326008)(97736004)(2950100002)(316002)(229853002)(72206003)(786003)(966005)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1154; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2017 06:52:00.4362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1154 X-MC-Unique: F-fsinvYPj-AxO4lu8id_w-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 06:52:09 -0000 Yep, thanks Gunter. Tim > On 19 Sep 2017, at 02:31, Brian E Carpenter = wrote: >=20 > Works for me, thanks. >=20 > Regards > Brian >=20 >> On 19/09/2017 06:27, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: >>=20 >> @all, this version should now have all agreed changes as discussed vivid= ly during in last few weeks at v6ops. >>=20 >> G/ >>=20 >>=20 >>=20 >> On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >> This draft is a work item of the IPv6 Operations WG of the IETF. >>=20 >> Title : Unique IPv6 Prefix Per Host >> Authors : John Jason Brzozowski >> Gunter Van De Velde >> Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-10= .txt >> Pages : 9 >> Date : 2017-09-18 >>=20 >> Abstract: >> This document outlines an approach utilising existing IPv6 protoco= ls >> to allow hosts to be assigned a unique IPv6 prefix (instead of a >> unique IPv6 address from a shared IPv6 prefix). Benefits of uniqu= e >> IPv6 prefix over a unique service provider IPv6 address include >> improved host isolation and enhanced subscriber management on shar= ed >> network segments. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-= per-host/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-h= ost-10 >> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-pr= efix-per-host-10 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pref= ix-per-host-10 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of sub= mission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> . >>=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Tue Sep 19 00:05:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D37127517 for ; Tue, 19 Sep 2017 00:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3s9p5U7jennb for ; Tue, 19 Sep 2017 00:05:55 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3FB126DFE for ; Tue, 19 Sep 2017 00:05:55 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id m103so7719099iod.13 for ; Tue, 19 Sep 2017 00:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=upWvehFBHz2h/8o9ruD6MLBCFt7hdibd63SDW87NDPc=; b=YJcYyht6ORfF5FOukzjDhbV3ngrLG11ZyW5tkUW/h14HIH/L4GccBjjjXO7WlRl9DY zTw9qBBDFau/5AZX3wqPZDjjZTWZ1ZDkIR2WLrLd7XnPVhDcCkX8agXbKu9q/FutxXNW D71vKO1jUZfXCdQejAr2KSD0CqB50eYBU09PxI3s4HVLakH01C7Mqe51kOv+Ap8n1sqA 2jK4WnYs0n2kWIHRCYZ3vumBiIbjiuYn7cxtWvmyaZpEBNbIG6MPGeJThQ2Snsy9vLKy 2BeFVsblaMiimy/ZrcD+vaioYn4cbpt5QhVyeB0SHx31LRjbQDmNXUMmfUNO8lwkUVdk 1FYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=upWvehFBHz2h/8o9ruD6MLBCFt7hdibd63SDW87NDPc=; b=SIXEVSAmsGMnyuXyoQfM+MmVftK1fe4dlJam7F5Z4iYXptHTXVPE/N3Z5bg7whaOzH EOg+a83mn9fnXnzP9SZeBY7H5vXclxd46EoKrx8ipI/AwxwmlIcEWSZjHk6+SrR1ZahT 6GJcdioPQYXZg8LyWWVNGm4B0W+dWm3oaxkCDIzN/igoWJoyJ4JIu23J0DujcExKJEF8 c9hgBTsfViC0UUZe4SlUr2ibGYp1SEu89sOfT2X8Qyusc2UtAB+FZWCdEGqYJJix5JAm 8QOg6cR2t8LHqaciltDf6IyMAgMu6Ne0jW9qF0vbAevHV1KxL3q9VuN8kF53JwHYhpb+ EASA== X-Gm-Message-State: AHPjjUh0Ol5W3vL6IURq+bn8qtq48nEoD1y6DVD3GlV/Pk5u5yqlR19r F8TcCjaM0yTJRKER4o1q/I+qbOnc3ObnDOTldjwPVA== X-Google-Smtp-Source: AOwi7QD739ho8tF5q9DYwLIoklH34BFOxI/NiZ7C0Sxjoum2hVrFDb7qdzyRjbb9dbWTfoe8MrVFxETAW1fyQB2gjf8= X-Received: by 10.107.175.10 with SMTP id y10mr536319ioe.222.1505804749775; Tue, 19 Sep 2017 00:05:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Tue, 19 Sep 2017 00:05:29 -0700 (PDT) In-Reply-To: References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> <1C18D9FE-4848-4513-987D-75E0D4DC0F4B@tony.li> From: Lorenzo Colitti Date: Tue, 19 Sep 2017 16:05:29 +0900 Message-ID: To: David Farmer Cc: Tony Li , "v6ops@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" Content-Type: multipart/alternative; boundary="001a11449b2c36933e0559857d0e" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 07:05:58 -0000 --001a11449b2c36933e0559857d0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable True. Should the draft note that sending RAs unicast helps ensure that they are received on devices that drop multicast, or is that problem too specific to current implementations? (Though I don't see this changing any time soon...) On Tue, Sep 19, 2017 at 12:05 PM, David Farmer wrote: > However, in this case the RAs are not Multicast, at least at the > link-layer. So, RA reception should be much less of a problem. That's not > to say the recommended RA lifetimes shouldn't be adjusted appropriately > though. > > On Mon, Sep 18, 2017 at 9:26 PM, Lorenzo Colitti > wrote: > >> And yet, the reality is that lots of mobile devices listen to only one >> out of X wifi multicast/broadcast packets when the screen is off. >> >> I would suggest trying it on your phone and see what it does. >> >> On Mon, Sep 18, 2017 at 7:22 PM, Tony Li wrote: >> >>> >>> Seems to me that if something is experiencing 66% packet loss for 30 >>> minutes that it should prefer disconnection. That=E2=80=99s wholly unus= able=E2=80=A6 >>> >>> Tony >>> >>> >>> On Sep 18, 2017, at 6:48 PM, Lorenzo Colitti wrote= : >>> >>> We still need to address the issue of the RA lifetimes in the presence >>> of mobile devices that drop multicast packets. >>> >>> If the RA interval is set to 600s (recommended by 7772), and devices >>> drop 2/3 multicast packets, then 29% of the time, after 30 minutes the >>> device's IPv6 addresses will be deprecated and the device will start >>> preferring IPv4 over IPv6. >>> >>> On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, Gunter (Nokia - >>> BE/Antwerp) wrote: >>> >>>> >>>> @all, this version should now have all agreed changes as discussed >>>> vividly during in last few weeks at v6ops. >>>> >>>> G/ >>>> >>>> >>>> >>>> On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" < >>>> v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the IPv6 Operations WG of the IETF. >>>> >>>> Title : Unique IPv6 Prefix Per Host >>>> Authors : John Jason Brzozowski >>>> Gunter Van De Velde >>>> Filename : draft-ietf-v6ops-unique-ipv6-p >>>> refix-per-host-10.txt >>>> Pages : 9 >>>> Date : 2017-09-18 >>>> >>>> Abstract: >>>> This document outlines an approach utilising existing IPv6 >>>> protocols >>>> to allow hosts to be assigned a unique IPv6 prefix (instead of = a >>>> unique IPv6 address from a shared IPv6 prefix). Benefits of >>>> unique >>>> IPv6 prefix over a unique service provider IPv6 address include >>>> improved host isolation and enhanced subscriber management on >>>> shared >>>> network segments. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv >>>> 6-prefix-per-host/ >>>> >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-pre >>>> fix-per-host-10 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-uniqu >>>> e-ipv6-prefix-per-host-10 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ip >>>> v6-prefix-per-host-10 >>>> >>>> >>>> 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.or= g >>>> . >>>> >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> > > > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > --001a11449b2c36933e0559857d0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
True. Should the draft note that sending RAs unicast helps= ensure that they are received on devices that drop multicast, or is that p= roblem too specific to current implementations? (Though I don't see thi= s changing any time soon...)


<= div class=3D"gmail_quote">On Tue, Sep 19, 2017 at 12:05 PM, David Farmer <far= mer@umn.edu> wrote:
However, in this case the RAs are not Multicast, at least at the = link-layer. So, RA reception should be much less of a problem. That's n= ot to say the recommended RA lifetimes shouldn't be adjusted appropriat= ely though. =C2=A0=C2=A0

On Mon, Sep 18, 2017 at = 9:26 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
And yet, th= e reality is that lots of mobile devices listen to only one out of X wifi m= ulticast/broadcast packets when the screen is off.

I wou= ld suggest trying it on your phone and see what it does.

On Mon, Sep 18, 2017 at = 7:22 PM, Tony Li <tony.li@tony.li> wrote:
<= br>
Seems to me that if something is experiencing 66% packet loss= for 30 minutes that it should prefer disconnection. That=E2=80=99s wholly = unusable=E2=80=A6

Tony


<= blockquote type=3D"cite">
On Sep 18, 2017, at 6:48 PM, Lorenzo Colitti = <lorenzo@google.= com> wrote:

We still need to address the issue of the RA lif= etimes in the presence of mobile devices that drop multicast packets.
<= br>
If the RA interval is set to 600s (recommended by 7772), and = devices drop 2/3 multicast packets, then 29% of the time, after 30 minutes = the device's IPv6 addresses will be deprecated and the device will star= t preferring IPv4 over IPv6.

On Tue, Sep 19, 2017 at 3:27 AM, Van De Velde, Gunte= r (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com= > wrote:
@all, this version should now have all agreed changes as discussed vividly = during in last few weeks at v6ops.

G/



On 18/09/2017, 20:17, "v6ops on behalf of internet-drafts@ietf.org" <v6ops-bounces@iet= f.org on behalf of internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts directories.
=C2=A0 =C2=A0 This draft is a work item of the IPv6 Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Unique IPv6 Prefix Per Host
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: John Jason Brzozowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gunter Van De Velde
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-unique-ipv6-prefix-per-host-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-18

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document outlines an approach utilising exi= sting IPv6 protocols
=C2=A0 =C2=A0 =C2=A0 =C2=A0to allow hosts to be assigned a unique IPv6 pref= ix (instead of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0unique IPv6 address from a shared IPv6 prefix).= =C2=A0 Benefits of unique
=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 prefix over a unique service provider IPv6 = address include
=C2=A0 =C2=A0 =C2=A0 =C2=A0improved host isolation and enhanced subscriber = management on shared
=C2=A0 =C2=A0 =C2=A0 =C2=A0network segments.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://= datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/

=C2=A0 =C2=A0 There are also htmlized versions available at:
=C2=A0 =C2=A0 https://too= ls.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-10<= /a>
=C2=A0 =C2=A0 h= ttps://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6= -prefix-per-host-10

=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pre= fix-per-host-10


=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf= .org.

=C2=A0 =C2=A0 Internet-Drafts are also available by anonymous FTP at:
=C2=A0 =C2=A0 ftp://ftp.ietf.org/internet-drafts/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/v6ops


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

_______________________________________________
v6ops mailing list<= br>v6ops@ietf.orghttps://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 Email:farme= r@umn.edu
Networking & Telecommunication Services
Office of I= nformation Technology
University of Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Ce= ll: 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

--001a11449b2c36933e0559857d0e-- From nobody Tue Sep 19 02:38:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7611270AB for ; Tue, 19 Sep 2017 02:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-pToCkU2OqD for ; Tue, 19 Sep 2017 02:38:14 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090BC126BF0 for ; Tue, 19 Sep 2017 02:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1505813892; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=zq37Cpl78rhO5lDBd7trrEcPEsQQ51QMDketnQG4FZs=; b=Ou9obFURFu6pSS19pgNpv9oaQPe0MRa2YIh1nPaPTfll+BCQtY03uPx8mvwvyTseKagRPNPoUehw6wOApXgcoCWybwQ8Lvb31U+OpNldUwORgSyhDdRqRURmXVGf76y+OVgxNS6ou8Lj0MC+OyDKt/2MnA6kz87twFgiIgdNZcE= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0175.outbound.protection.outlook.com [213.199.154.175]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-131-D9Uce-caNZKmqbZBrGoSNg-1; Tue, 19 Sep 2017 10:38:09 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0726.eurprd07.prod.outlook.com (10.160.6.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Tue, 19 Sep 2017 09:38:08 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590%14]) with mapi id 15.20.0077.009; Tue, 19 Sep 2017 09:38:08 +0000 From: Tim Chown To: Lorenzo Colitti CC: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt Thread-Index: AQHTMKqd0jFOYC5Fek2QlvqqJVuCg6K69iuAgAB7KgCAAINUgA== Date: Tue, 19 Sep 2017 09:38:07 +0000 Message-ID: <9A4ECE3B-24FF-42D3-A3DA-DCC20D412939@jisc.ac.uk> References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:6dd2:19ac:fd8:146c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0726; 20:RxKy3o1byH1Gq14v1LAS+3M1iTArdNm0bbyRqA59Jo4k+5CSb2h6mT/Zo+JT1xTfzSYCGDSBTGh08VAEgDwVNWMNLbkIu/xAMv4jbEsy0GLeiqSPiEGGfGcqeNVAAi2O9MUXJg+ZXkRAvmejpiML5/FjjCctAnhcnBVDRIUUouQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: dccd4037-b12c-4c06-45c7-08d4ff4222a5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0726; x-ms-traffictypediagnostic: AM3PR07MB0726: x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(920507026)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0726; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0726; x-forefront-prvs: 04359FAD81 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(377454003)(199003)(24454002)(377424004)(189002)(2900100001)(50226002)(57306001)(14454004)(72206003)(53546010)(966005)(230783001)(478600001)(8676002)(76176999)(81166006)(81156014)(6916009)(50986999)(42882006)(2950100002)(6436002)(86362001)(8936002)(6506006)(229853002)(68736007)(6486002)(36756003)(101416001)(74482002)(5660300001)(5250100002)(6246003)(2906002)(25786009)(33656002)(99286003)(34040400001)(305945005)(7736002)(4326008)(6306002)(105586002)(786003)(6512007)(54906002)(316002)(106356001)(3660700001)(83716003)(53936002)(3280700002)(82746002)(189998001)(102836003)(6116002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0726; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2017 09:38:07.9326 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0726 X-MC-Unique: D9Uce-caNZKmqbZBrGoSNg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 09:38:16 -0000 U28gUkZDNzc3MiBzdWdnZXN0cyB0aGF0IDYwMHMgaXMgYSByZWFzb25hYmxlIGZyZXF1ZW5jeSBm b3IgUkFzIChpdCBzYXlzIDcgUkFzIHBlciBob3VyIGluIFNlY3Rpb24gNCkuDQoNCkJ1dCBkcmFm dC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdCBkb2VzbuKAmXQgaW5jbHVk ZSB0aGUgb3RoZXIgYWR2aWNlIGluIHRoYXQgU2VjdGlvbiBmb3IgZGVmYXVsdCBsaWZldGltZXMg KDUtMTAgdGltZXMgdGhlIFJBIHBlcmlvZCkuICANCg0KR2l2ZW4gUkZDNzc3MiBpcyBhIEJDUCwg YW55IHNwZWNpZmljIHNldHRpbmdzIGdpdmVuIGluIGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlw djYtcHJlZml4LXBlci1ob3N0IHNob3VsZCBmb2xsb3cgdGhhdCBndWlkYW5jZSwgc2hvdWxkbuKA mXQgaXQ/ICBBcyBpdCBzdGFuZHMsIG9ubHkgdGhlIFJBIGZyZXF1ZW5jeSBwYXJ0IG9mIFJGQzc3 NzIgaXMgaW5jbHVkZWQsIG5vdCB0aGUgbGlmZXRpbWUgZ3VpZGFuY2UuICBJdCBzZWVtcyB0aGF0 IGRyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0IGNob29zZXMgbm90 IHRvIGZvbGxvdyB0aGUgZ3VpZGFuY2UgYmVjYXVzZSDigJx0byByZWR1Y2UgdW5kZXNpcmVkIHJl c291cmNlIGNvbnN1bXB0aW9uLCBzdWNoIGFzIGluIHRoZSBjYXNlIG9mIFdpRmkgaG90c3BvdHMs IGlzIHRvIHJlbW92ZSBzdWJzY3JpYmVyIGNvbnRleHQgYXMgcXVpY2tseSBhcyBwb3NzaWJsZSB3 aGVuIGEgZGV2aWNlIG9yIHN1YnNjcmliZXIgYmVjb21lcyBub24tYWN0aXZlLuKAnSAgSeKAmWQg Y2VydGFpbmx5IHByZWZlciB0byBzZWUgdGhlIHRyYWRlb2ZmIGZhdm91cmluZyB0aGUgdXNlciBh bm90aGVyIGRldmljZS4NCg0KVGltIA0KDQo+IE9uIDE5IFNlcCAyMDE3LCBhdCAwMjo0OCwgTG9y ZW56byBDb2xpdHRpIDxsb3JlbnpvQGdvb2dsZS5jb20+IHdyb3RlOg0KPiANCj4gV2Ugc3RpbGwg bmVlZCB0byBhZGRyZXNzIHRoZSBpc3N1ZSBvZiB0aGUgUkEgbGlmZXRpbWVzIGluIHRoZSBwcmVz ZW5jZSBvZiBtb2JpbGUgZGV2aWNlcyB0aGF0IGRyb3AgbXVsdGljYXN0IHBhY2tldHMuDQo+IA0K PiBJZiB0aGUgUkEgaW50ZXJ2YWwgaXMgc2V0IHRvIDYwMHMgKHJlY29tbWVuZGVkIGJ5IDc3NzIp LCBhbmQgZGV2aWNlcyBkcm9wIDIvMyBtdWx0aWNhc3QgcGFja2V0cywgdGhlbiAyOSUgb2YgdGhl IHRpbWUsIGFmdGVyIDMwIG1pbnV0ZXMgdGhlIGRldmljZSdzIElQdjYgYWRkcmVzc2VzIHdpbGwg YmUgZGVwcmVjYXRlZCBhbmQgdGhlIGRldmljZSB3aWxsIHN0YXJ0IHByZWZlcnJpbmcgSVB2NCBv dmVyIElQdjYuDQo+IA0KPiBPbiBUdWUsIFNlcCAxOSwgMjAxNyBhdCAzOjI3IEFNLCBWYW4gRGUg VmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8Z3VudGVyLnZhbl9kZV92ZWxkZUBu b2tpYS5jb20+IHdyb3RlOg0KPiANCj4gQGFsbCwgdGhpcyB2ZXJzaW9uIHNob3VsZCBub3cgaGF2 ZSBhbGwgYWdyZWVkIGNoYW5nZXMgYXMgZGlzY3Vzc2VkIHZpdmlkbHkgZHVyaW5nIGluIGxhc3Qg ZmV3IHdlZWtzIGF0IHY2b3BzLg0KPiANCj4gRy8NCj4gDQo+IA0KPiANCj4gT24gMTgvMDkvMjAx NywgMjA6MTcsICJ2Nm9wcyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8 djZvcHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPiB3cm90ZToNCj4gDQo+IA0KPiAgICAgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiAgICAg VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRpb25zIFdHIG9mIHRo ZSBJRVRGLg0KPiANCj4gICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogVW5pcXVlIElQdjYg UHJlZml4IFBlciBIb3N0DQo+ICAgICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IEpvaG4gSmFz b24gQnJ6b3pvd3NraQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHdW50ZXIgVmFu IERlIFZlbGRlDQo+ICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi12Nm9wcy11 bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMTAudHh0DQo+ICAgICAgICAgUGFnZXMgICAgICAg ICAgIDogOQ0KPiAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTctMDktMTgNCj4gDQo+ICAg ICBBYnN0cmFjdDoNCj4gICAgICAgIFRoaXMgZG9jdW1lbnQgb3V0bGluZXMgYW4gYXBwcm9hY2gg dXRpbGlzaW5nIGV4aXN0aW5nIElQdjYgcHJvdG9jb2xzDQo+ICAgICAgICB0byBhbGxvdyBob3N0 cyB0byBiZSBhc3NpZ25lZCBhIHVuaXF1ZSBJUHY2IHByZWZpeCAoaW5zdGVhZCBvZiBhDQo+ICAg ICAgICB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLiAgQmVu ZWZpdHMgb2YgdW5pcXVlDQo+ICAgICAgICBJUHY2IHByZWZpeCBvdmVyIGEgdW5pcXVlIHNlcnZp Y2UgcHJvdmlkZXIgSVB2NiBhZGRyZXNzIGluY2x1ZGUNCj4gICAgICAgIGltcHJvdmVkIGhvc3Qg aXNvbGF0aW9uIGFuZCBlbmhhbmNlZCBzdWJzY3JpYmVyIG1hbmFnZW1lbnQgb24gc2hhcmVkDQo+ ICAgICAgICBuZXR3b3JrIHNlZ21lbnRzLg0KPiANCj4gDQo+ICAgICBUaGUgSUVURiBkYXRhdHJh Y2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBl ci1ob3N0Lw0KPiANCj4gICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWls YWJsZSBhdDoNCj4gICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXY2 b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0xMA0KPiAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZp eC1wZXItaG9zdC0xMA0KPiANCj4gICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9u IGlzIGF2YWlsYWJsZSBhdDoNCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0xMA0KPiANCj4g DQo+ICAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+ICAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gICAg IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN Cj4gICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiAgICAgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgIHY2b3Bz IG1haWxpbmcgbGlzdA0KPiAgICAgdjZvcHNAaWV0Zi5vcmcNCj4gICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4g djZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K From nobody Tue Sep 19 02:56:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AF21323B8 for ; Tue, 19 Sep 2017 02:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ATnfGJAP2h9p for ; Tue, 19 Sep 2017 02:56:53 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A80E126BF0 for ; Tue, 19 Sep 2017 02:56:53 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 1FA632D4F88; Tue, 19 Sep 2017 09:56:51 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 4BD90109DB21E; Tue, 19 Sep 2017 11:56:48 +0200 (CEST) From: Ole Troan Message-Id: <591DD234-4ECD-4528-8A46-B70744A6F3EE@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_12E348B0-CD67-4149-B3A6-73D1ACEAA424"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 19 Sep 2017 11:56:47 +0200 In-Reply-To: <9A4ECE3B-24FF-42D3-A3DA-DCC20D412939@jisc.ac.uk> Cc: Lorenzo Colitti , "v6ops@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Tim Chown References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> <9A4ECE3B-24FF-42D3-A3DA-DCC20D412939@jisc.ac.uk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 09:56:54 -0000 --Apple-Mail=_12E348B0-CD67-4149-B3A6-73D1ACEAA424 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tim, > So RFC7772 suggests that 600s is a reasonable frequency for RAs (it = says 7 RAs per hour in Section 4). It's difficult to see that 7772 is directly applicable. Given that this = unique-prefix uses L2 unicast not multicast. It would be interesting to see the same measurement being done on = unique-prefix. Barring actual science behind these recommendations I'd prefer that = unique-prefix didn't recommend timers overriding 4861 at all. Ole >=20 > But draft-ietf-v6ops-unique-ipv6-prefix-per-host doesn=E2=80=99t = include the other advice in that Section for default lifetimes (5-10 = times the RA period). >=20 > Given RFC7772 is a BCP, any specific settings given in = draft-ietf-v6ops-unique-ipv6-prefix-per-host should follow that = guidance, shouldn=E2=80=99t it? As it stands, only the RA frequency = part of RFC7772 is included, not the lifetime guidance. It seems that = draft-ietf-v6ops-unique-ipv6-prefix-per-host chooses not to follow the = guidance because =E2=80=9Cto reduce undesired resource consumption, such = as in the case of WiFi hotspots, is to remove subscriber context as = quickly as possible when a device or subscriber becomes non-active.=E2=80=9D= I=E2=80=99d certainly prefer to see the tradeoff favouring the user = another device. --Apple-Mail=_12E348B0-CD67-4149-B3A6-73D1ACEAA424 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZwOnfAAoJEL7aWKiYQt92vwcP/iEVggw9kty1fYOFAyhL0rVd +WSQJ/FK+ZW5yMgRbSXvwLnjaQIjk2ulJBHJjT78hfB1jFc79RgZB56aJYuufgM/ 5qxnFM1IRw+PKgzLDuMhO2G8FquZ/Cew/XOpanCBIYDx1iUIUtYZiMSpELkYdxUf 6dqlPOpGdgmhJ7SwzQplyr0x1FZudk9AANu8jwTL6pAj0Sn0keoRPL5eet+AhkrZ vQGFxOm2fifxTtAkeGyXsVSWQpSzus8JUUY7mbWzGwzqMj/e8q5+0cDHHZvKLCUA ba4QyhdDzlRRbztt2YDZcqJ09904TFpVT/zKyMWWAIa/hICmwGO3CO5+g0lOdMiR 4Y51zbOxI2/v/nGeNhfuaUyPfQSfAOMr5zHYmJ81zRJ33vz6UMjPPQ/P8qATDPLS vx3YqUMkYg6NlJ4IrIUjuvtY0A+d9p6U0Q7/IshRLT9cspKKt4ZYDn1s1FsqjGUF 1+n7l7iynXx+rHz5xAoZyqJO9jiEjNv6UOuXSFrnJulnSyKXYfqR/lxb63Q47DYa pvjcM1TXc2XqoahvAvG3UCLFO35HuYqkBrhotVP64BHwdtCQOW+hx3M83W3Q/zxG drtN/9pWkAAyfCNRZH1lerhA1KQQcrvqo2UauFJywHpU+uPh9o5NWGeGW/ryjzYa 8ohTr+bCo9aXxzqw+Do8 =+9an -----END PGP SIGNATURE----- --Apple-Mail=_12E348B0-CD67-4149-B3A6-73D1ACEAA424-- From nobody Tue Sep 19 04:45:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E14A134220 for ; Tue, 19 Sep 2017 04:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 S54k6WZEerKm for ; Tue, 19 Sep 2017 04:45:42 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E83134218 for ; Tue, 19 Sep 2017 04:45:36 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id w9so2270654ywi.11 for ; Tue, 19 Sep 2017 04:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jyMvbM/d5yvjsDbGFLJxQviD7CjID2HaEUurnpMy/D8=; b=o/srDyvReq54TTY2kSlYUyi3W3+yW7BA2tcRw45DLeIilJpr88L/LWur8+NqpK8WGV VpO5jrF4gFAL9J5sHeLxL7QG6Mk/JcP1J41hSdyKUyE/StBD74jAnPqESu4WqZpzx4Sp FKeiNkHs/eQiVS58aKsAFmwirtyErtOlZeYzhpvNlHo2S6124nofX1S+tHOB0Sdc4p7U INuLvuTs6heB1WzY1kR73hV0GJVcwjnBBYJiFIvn6hQlcIUy3R78yA1Qs4qe5VW9YUf+ UZbndn+JM3xD31Rn/gqg/0B8v6yGYDAQqUWy9d9nktvdEXGAe5s5WDxgarZ3SWqZ4tmF 8ZVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jyMvbM/d5yvjsDbGFLJxQviD7CjID2HaEUurnpMy/D8=; b=bSukKTbdTThlb1OOBavukpNWHskifUOL6P3+Dirp9qtYHNCCZudn80+5khK8xbKvMG c1loDYpynvW+XPWPJvRvFg1BRGXbx9gIQE2d2rFz+MkXucKGSy/l8o34dctTP5D4up/d PE8yuVVe/d6+HKFHrYmrSYNCoWzDBKX60g48MsZMsyugApq5ksbDZ47zwPDGUhbS8B0X dhBSIJ+p0hCLvaxEXUAr5c3ymKWqGoZ2YgMmVg1oFFLqPBHlhFvvZv9fUZSVGchiKCtZ od1MWGDUfztHLzjv+LVB1Dw7kLkvrbo5CvNUMVYWjnRS4mNCvNWLI7C2ArsnYnKJlAGP Zn6g== X-Gm-Message-State: AHPjjUi7a/vonSp1hWMUfUf1lzbKT/cxJV9XJBmK1hczouzpMLglW3yW GtjPXncdrW6Hup9WY/sQkOzZxuR/6kaH4ebazaJ1WSp3 X-Google-Smtp-Source: AOwi7QBAM5RI32R58RA20AWN4QnWxXIF8D1jEFdc7v9bDJmm9+Aq0CRyKgHDUIBkQruU1ku+TUyjYCjWHGQ7weWPCDg= X-Received: by 10.37.53.134 with SMTP id c128mr339303yba.336.1505821535520; Tue, 19 Sep 2017 04:45:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Tue, 19 Sep 2017 04:45:34 -0700 (PDT) Received: by 10.37.214.213 with HTTP; Tue, 19 Sep 2017 04:45:34 -0700 (PDT) In-Reply-To: <591DD234-4ECD-4528-8A46-B70744A6F3EE@employees.org> References: <150575867755.15571.8632904574264251001@ietfa.amsl.com> <2019D66A-0F28-4EC0-8008-1F284834CAFA@nokia.com> <9A4ECE3B-24FF-42D3-A3DA-DCC20D412939@jisc.ac.uk> <591DD234-4ECD-4528-8A46-B70744A6F3EE@employees.org> From: Lorenzo Colitti Date: Tue, 19 Sep 2017 20:45:34 +0900 Message-ID: To: Ole Troan Cc: Tim Chown , "v6ops@ietf.org WG" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" Content-Type: multipart/alternative; boundary="001a114bbba6b8ce0a055989658d" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-10.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 11:45:44 -0000 --001a114bbba6b8ce0a055989658d Content-Type: text/plain; charset="UTF-8" On Sep 19, 2017 18:56, "Ole Troan" wrote: It's difficult to see that 7772 is directly applicable. Given that this unique-prefix uses L2 unicast not multicast. It would be interesting to see the same measurement being done on unique-prefix. Why do you say 7772 is not applicable? The power numbers in that RFC reflect only the power consumption of the CPU, not of the radio, so they should be equally correct for unicast and multicast. On 802.11, unicast is more expensive because the received unicast RA needs to be ACKed. --001a114bbba6b8ce0a055989658d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sep 19, 2017 18:56, "Ole Troan" <otroan@employees.org> wrote:
It's difficult to see that 7772 is directly applicable. Given that thi= s unique-prefix uses L2 unicast not multicast.
It would be interesting to see the same measurement being done on unique-pr= efix.

Why do you say 7772 is not applicable? The power numbers in that= RFC reflect only the power consumption of the CPU, not of the radio, so th= ey should be equally correct for unicast and multicast.

On 802.11, unicast is more expensive becaus= e the received unicast RA needs to be ACKed.
--001a114bbba6b8ce0a055989658d-- From nobody Tue Sep 19 05:24:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0FB13421F for ; Tue, 19 Sep 2017 05:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jV8FlGFkErLN for ; Tue, 19 Sep 2017 05:24:55 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B41D13421C for ; Tue, 19 Sep 2017 05:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505823866; x=1506428666; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=lSJywgFF9Q5hzTbod/QuKFAgyD46Nm1lrLOMezMwZKU=; b=kpciw1HxZ3mw9 /hEk9os//hOh1lB98eDDYVTOPNBGHapvkzYbb/lMjEj81wcOenECoA2S27v/Cqh9 mmtuDz2VE3rwKFZ9pkGv4/wECn5u1YMbdHKj/Mq44jC7dD5NnYTErE1hZbXMhK6A bnl3JW5Lz65HSVKt7UP8SJfleeAWic= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=l+IBEsS2JkibROXH8hc8OViXD7/amvXoXR1sjW4ZrkmRSpquXYq6J36D7qlm 5mWgqB/MAmjGEoIUNfFUHJNIiuwtvFtdVI6qWqYAby2r02u6jr1sthu20 ScJadAgNIS5dHxw8cL7Ar9FcCgtz//hcDEDJawUjpfAtFcFwdLJKws=; X-MDAV-Processed: mail.consulintel.es, Tue, 19 Sep 2017 14:24:26 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 19 Sep 2017 14:24:26 +0200 Received: from [100.124.9.206] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005560063.msg for ; Tue, 19 Sep 2017 14:24:25 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170919:md50005560063::ESnOgl0cgakmmkBe:00003zzX X-Return-Path: prvs=1435462033=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Tue, 19 Sep 2017 09:23:52 -0300 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: reclassify 464XLAT as standard instead of info Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 12:24:57 -0000 Hi all, RFC6877 (464XLAT) is an informational document. However, this transition mechanism is the one that has a bigger deployment = in terms of number of subscribers using it (hundreds of millions), which I = think is even more than ALL the other transition mechanism together. Doesn=E2=80=99t make any sense, in my opinion to keep it as an informationa= l document, while we have many others that are standards track and don=E2= =80=99t have such level of deployment. I was commenting this last week with a couple of the co-authors of this doc= ument, and they have the same opinion. So, should we aim to do this? Can we even consider moving it to STD? Regards, Jordi =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Sep 19 09:23:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEF3133085 for ; Tue, 19 Sep 2017 09:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Glo__UYap9ti for ; Tue, 19 Sep 2017 09:23:06 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF8F134294 for ; Tue, 19 Sep 2017 09:23:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JGN3XL007859 for ; Tue, 19 Sep 2017 18:23:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AD21E20E3D8 for ; Tue, 19 Sep 2017 18:23:03 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A30A920E30D for ; Tue, 19 Sep 2017 18:23:03 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8JGN3F3020067 for ; Tue, 19 Sep 2017 18:23:03 +0200 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> Date: Tue, 19 Sep 2017 18:23:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 16:23:08 -0000 Sounds as trying to impose 464xlat to everyone else? My little IoT IPv6 cellular device does not run 464xlat and neither IPv4. If 464xlat becomes Stds Track does it mean that it MUST run 464xlat? I would disagree with that. Alex Le 19/09/2017 à 14:23, JORDI PALET MARTINEZ a écrit : > Hi all, > > RFC6877 (464XLAT) is an informational document. > > However, this transition mechanism is the one that has a bigger deployment in terms of number of subscribers using it (hundreds of millions), which I think is even more than ALL the other transition mechanism together. > > Doesn’t make any sense, in my opinion to keep it as an informational document, while we have many others that are standards track and don’t have such level of deployment. > > I was commenting this last week with a couple of the co-authors of this document, and they have the same opinion. > > So, should we aim to do this? > > Can we even consider moving it to STD? > > Regards, > Jordi > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Sep 19 09:55:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4486313307D for ; Tue, 19 Sep 2017 09:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Pj5xQDt1uS0 for ; Tue, 19 Sep 2017 09:55:54 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43E9124207 for ; Tue, 19 Sep 2017 09:55:54 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id b70so110057pfl.8 for ; Tue, 19 Sep 2017 09:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=V6R7xaCyEZNK/B+rlS1+kHVAO8azN4K/wV5eGTEA5C8=; b=hoDtn3momnGvWGGw7sRgqU/a1FUUYWdKg/ZsFHa5ysglxIjg/Lyog+xYqJFPYSjs8k h4tQyZhkJ4CeugsB2edMDSdIjnpqHoiZYmwX8gCZZiajFzqfQvKvz6C0bNWxrrbjQuOY vqYrBV86l4+pnhGEY5/nZPr0nQPQHx7uUJZIf4f49ytyhwa9EM33FGlabS+p8aITlUXA z7uLLn88tPO7WWyNXdS4iimwu72LRYOJrc/vTxZgw1dQ1m7ntyCNo4X/ChhQ8zgNDPz9 hriJORQjsd3XhbKlOL16Ul/kpNu7Pr4i60Z6Tm4k6s1Ni1XW1oPs1tUqqanL3sVAgpoQ OycQ== 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=V6R7xaCyEZNK/B+rlS1+kHVAO8azN4K/wV5eGTEA5C8=; b=gUC/Q8ErbS8q0hQzYm6O7wVfJmPhZBa7GuHm7HGiUyZvnbusuDYoWj+zO7q0dgS5n7 VXnyvP6tFUNxdU9cuXMIg9tjp2ObQ70OWQX7ZEfcUNhK96Hu+L+2PN8cp1babzAMltJP wmfaKodCFtIjnibNbja2SF27/4E9d8WlB2f9oa+AWY5BjJcqLqu8UooKOzbazooufWpi YPbFeOB/67btI15PDXCIHt21DZmACn5outvpnBpMz+123qdtcJ7ZYs4Aea9UOrIy//Ea n5r6vu/B4Zg2vCe9YpPNXiGwTJ5Z8U/0TyV35n/iSn4dUSG73mq8qN1FojJOomujREgJ ieNg== X-Gm-Message-State: AHPjjUis3a6SKCsiNKmgQxbbp82oJamAhO0KZUCV9aIllhp6JiWktwkS EbPkd+fjmiwl0q1jDei6pH2nPQ== X-Google-Smtp-Source: AOwi7QDPIGkbdk5FuGo3YzRzqsWnN+Kp9xjW1yB2JMfeu/01F83AVAP4Tc/nhtvCBgnnCmR153iFlg== X-Received: by 10.98.159.137 with SMTP id v9mr1846120pfk.49.1505840154304; Tue, 19 Sep 2017 09:55:54 -0700 (PDT) Received: from [10.1.60.111] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id z187sm5540983pfb.60.2017.09.19.09.55.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 09:55:53 -0700 (PDT) From: Ted Lemon Message-Id: <0CD21368-3E62-4CBA-9EC5-C02C7850FCE7@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5EEA1300-DABA-42E5-9AC3-99599C6CAB06" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 19 Sep 2017 12:55:51 -0400 In-Reply-To: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> Cc: v6ops@ietf.org To: Alexandre Petrescu References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 16:55:56 -0000 --Apple-Mail=_5EEA1300-DABA-42E5-9AC3-99599C6CAB06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 19, 2017, at 12:23 PM, Alexandre Petrescu = wrote: > My little IoT IPv6 cellular device does not run 464xlat and neither = IPv4. If 464xlat becomes Stds Track does it mean that it MUST run = 464xlat? I would disagree with that. Um, when does standards track ever mean this, Alex? The answer is = never. What it means for a document to be standards track is that it = has IETF consensus as a standard, not that you are required to implement = it. Does your little IoT device implement XMPP? That's a standard... :) --Apple-Mail=_5EEA1300-DABA-42E5-9AC3-99599C6CAB06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Sep 19, 2017, at 12:23 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
My little IoT IPv6 cellular device does = not run 464xlat and neither IPv4.  If 464xlat becomes Stds Track = does it mean that it MUST run 464xlat?  I would disagree with = that.

Um, when does standards track ever mean this, = Alex?   The answer is never.   What it means for a document to = be standards track is that it has IETF consensus as a standard, not that = you are required to implement it.   Does your little IoT device = implement XMPP?   That's a standard...

:)

= --Apple-Mail=_5EEA1300-DABA-42E5-9AC3-99599C6CAB06-- From nobody Tue Sep 19 10:05:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D92134295 for ; Tue, 19 Sep 2017 10:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofkH8l2kFJ3W for ; Tue, 19 Sep 2017 10:05:28 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0473C1331C1 for ; Tue, 19 Sep 2017 10:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505840723; x=1506445523; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=AwotELWzLlcMB+QY2/tQEowYv m6M6oXSxHUokFvtkOw=; b=jd2WNrFHj7qSQCCuCroBCp7nfbInnF/XBomF6Rzmh xi+F6AP4JSEWiUoOR/j0Pklx+XTJ6SZqp6pJyOdUcHh+ntESB+gCW8+xYSv4gxQV WZ/D6pjKjqS5C0Ksu30BcvzAm5gMXD3ZgBoAsG13PwEgCmRENCC7VStsJUIFmAdj Ho= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=OK9t/KKX4IV5ErTRaa+CoHSMdLH+EZCOAjgEDJa0ttqHpp4Af8vDvmgZ5EC1 NJuSwMfl72BSkw7U8rqXBAmn2FAyQb1TyK9PeBK+dk6xI03bN32sTLSWy dRffzTTmCk+pdvlPz31ZdgHuczm0rgcQc7X+uRLQHGxRDcjm2gipE4=; X-MDAV-Processed: mail.consulintel.es, Tue, 19 Sep 2017 19:05:23 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 19 Sep 2017 19:05:23 +0200 Received: from [45.6.254.173] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005560272.msg for ; Tue, 19 Sep 2017 19:05:22 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170919:md50005560272::UWBPj3c9nkkn/bm/:00005Ipw X-MDRemoteIP: 45.6.254.173 X-Return-Path: prvs=1435462033=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Tue, 19 Sep 2017 14:05:19 -0300 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> In-Reply-To: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 17:05:30 -0000 Not at all, just to avoid this protocol to be discriminated compared to oth= ers. No reason to have some of the standard and others informational, even less = if this is the one with has a bigger deployment. Just my opinion, but based= in facts. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: martes, 19 de septiembre de 2017, 13:23 Para: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info Sounds as trying to impose 464xlat to everyone else? =20 My little IoT IPv6 cellular device does not run 464xlat and neither=20 IPv4. If 464xlat becomes Stds Track does it mean that it MUST run=20 464xlat? I would disagree with that. =20 Alex =20 Le 19/09/2017 =C3=A0 14:23, JORDI PALET MARTINEZ a =C3=A9crit : > Hi all, >=20 > RFC6877 (464XLAT) is an informational document. >=20 > However, this transition mechanism is the one that has a bigger deplo= yment in terms of number of subscribers using it (hundreds of millions), wh= ich I think is even more than ALL the other transition mechanism together. >=20 > Doesn=E2=80=99t make any sense, in my opinion to keep it as an inform= ational document, while we have many others that are standards track and do= n=E2=80=99t have such level of deployment. >=20 > I was commenting this last week with a couple of the co-authors of th= is document, and they have the same opinion. >=20 > So, should we aim to do this? >=20 > Can we even consider moving it to STD? >=20 > Regards, > Jordi > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Sep 19 12:33:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA94134384 for ; Tue, 19 Sep 2017 12:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 978wO9IQG0Iq for ; Tue, 19 Sep 2017 12:33:05 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F5A134386 for ; Tue, 19 Sep 2017 12:33:04 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JJX2QB003940 for ; Tue, 19 Sep 2017 21:33:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6186620E6D6 for ; Tue, 19 Sep 2017 21:33:02 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 57B1220E3DF for ; Tue, 19 Sep 2017 21:33:02 +0200 (CEST) Received: from [132.166.84.160] ([132.166.84.160]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8JJX1W0019867 for ; Tue, 19 Sep 2017 21:33:01 +0200 To: v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 19 Sep 2017 21:33:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 19:33:07 -0000 Le 19/09/2017 à 19:05, JORDI PALET MARTINEZ a écrit : > Not at all, just to avoid this protocol to be discriminated compared to others. 464xlat has more success than other transition mechanisms. I saw it for myself. Yet it's about IPv4. How about Historical. Alex > > No reason to have some of the standard and others informational, even less if this is the one with has a bigger deployment. Just my opinion, but based in facts. > > Regards, > Jordi > > > -----Mensaje original----- > De: v6ops en nombre de Alexandre Petrescu > Responder a: > Fecha: martes, 19 de septiembre de 2017, 13:23 > Para: > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info > > Sounds as trying to impose 464xlat to everyone else? > > My little IoT IPv6 cellular device does not run 464xlat and neither > IPv4. If 464xlat becomes Stds Track does it mean that it MUST run > 464xlat? I would disagree with that. > > Alex > > Le 19/09/2017 à 14:23, JORDI PALET MARTINEZ a écrit : > > Hi all, > > > > RFC6877 (464XLAT) is an informational document. > > > > However, this transition mechanism is the one that has a bigger deployment in terms of number of subscribers using it (hundreds of millions), which I think is even more than ALL the other transition mechanism together. > > > > Doesn’t make any sense, in my opinion to keep it as an informational document, while we have many others that are standards track and don’t have such level of deployment. > > > > I was commenting this last week with a couple of the co-authors of this document, and they have the same opinion. > > > > So, should we aim to do this? > > > > Can we even consider moving it to STD? > > > > Regards, > > Jordi > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Sep 19 12:37:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C8B134389 for ; Tue, 19 Sep 2017 12:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bal2XXnm3Fyf for ; Tue, 19 Sep 2017 12:37:43 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E494134373 for ; Tue, 19 Sep 2017 12:37:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JJbeBq011134; Tue, 19 Sep 2017 21:37:40 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8D42E20E79A; Tue, 19 Sep 2017 21:37:40 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6A80720E30D; Tue, 19 Sep 2017 21:37:40 +0200 (CEST) Received: from [132.166.84.160] ([132.166.84.160]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8JJbd3k021382; Tue, 19 Sep 2017 21:37:40 +0200 To: Ted Lemon Cc: v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <0CD21368-3E62-4CBA-9EC5-C02C7850FCE7@fugue.com> From: Alexandre Petrescu Message-ID: <6619c568-a43d-d78a-8953-896ed5156c65@gmail.com> Date: Tue, 19 Sep 2017 21:37:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0CD21368-3E62-4CBA-9EC5-C02C7850FCE7@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 19:37:45 -0000 Le 19/09/2017 18:55, Ted Lemon a crit: > On Sep 19, 2017, at 12:23 PM, Alexandre Petrescu > > wrote: >> My little IoT IPv6 cellular device does not run 464xlat and neither >> IPv4. If 464xlat becomes Stds Track does it mean that it MUST run >> 464xlat? I would disagree with that. > > Um, when does standards track ever mean this, Alex? Right, and I agree with your XMPP comment. But is 464xlat some software feature that only Android implements? I did not see it on yocto. > The answer is > never. What it means for a document to be standards track is that it > has IETF consensus as a standard, consensus and? Alex not that you are required to implement > it. Does your little IoT device implement XMPP? That's a standard... > > :) > From nobody Tue Sep 19 13:27:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A5113439C for ; Tue, 19 Sep 2017 13:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq0IFPPDAXpo for ; Tue, 19 Sep 2017 13:27:56 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AD451320D8 for ; Tue, 19 Sep 2017 13:27:56 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id n69so1980438ioi.5 for ; Tue, 19 Sep 2017 13:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DxPsQxGpZBgyY0OGVN31eBBwawvDp4SSncKGI7yqMSA=; b=A6e6FulXSNQcP+O2qC+nw+ZoP8NMrMItp0vBjAhEZN/wZC272KakxQGQKJs2I9j5gt pWlYrLEgbckeIR1hwSNwQYorh9r6WbSL02cCNHxbKGVUmViyHN8bsJqp6XB014B8vgjO WCikvi3sF++moGeGKxdq33O5ri8UQr1TgswT4EUpDCRbr3wPVO2bLDCN/b0Nlwv45Yyb nCG5I0gcrtNri+QMPRsMZXV8Ke1/eMkrpCGHFGqYo9V6mng+NW5U3A7pPezsKqfPI0Va YncysVBE2teAJPssJUpZABkxMmrETUgXntWsUvtoM4KVl/Ky3OOgHjphtKrDxbxCSzuR /6GQ== 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=DxPsQxGpZBgyY0OGVN31eBBwawvDp4SSncKGI7yqMSA=; b=r0JvyBFIyEA9fnmEv3zJCNIgsZkclMAOIrdJQZEXEwYUbZy+hkIIxYu50Ou1jlZp3U IdFdByiMO8lmX5iDyBSG20hgnkdFE+kRTnfqdBUoZ1lVelUJhe9zsccjzqbTr9F5X5QS IhEHY/GN2sRQOgHbdhMONN3MvSNDfYR21KriTYM9LH+0N9BPf/KGFqWOcvfn8zDY2+28 WACrFEx6aW9dKT30B5TwT75Y8NldbBgNjSgDZqOEQyEs+y7shQJDIk6ydIJ9W509wNkZ KbGFCiSi/6SKGU1+nbWykPkM1WCpSNsNluUDuTwy7zi9gK1Tmzsr/M945NTwjREs3xPD rU9w== X-Gm-Message-State: AHPjjUi4uZrwbauQzzk+xi/m339T1UDktu8Qy8U2/4lhVYSc1AHqdVqZ ZaVHZ2BratD3743+Lkes+44ZWJR2 X-Google-Smtp-Source: AOwi7QDf80vWEzDVuFAY/3/thutFfecvjHhGJ+RIWlC6WIBCEy0BXwwShqbA4Tpsbhs41d6p17RzsQ== X-Received: by 10.202.49.69 with SMTP id x66mr2810182oix.115.1505852874230; Tue, 19 Sep 2017 13:27:54 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1da8? ([2600:8802:5600:e::1da8]) by smtp.gmail.com with ESMTPSA id o54sm840727otc.51.2017.09.19.13.27.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 13:27:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: Date: Tue, 19 Sep 2017 13:27:51 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 20:27:58 -0000 Hmm. Wearing the chair hat, but not making pronouncements. Thinking = through the options and considerations. Some reading matter: https://tools.ietf.org/html/rfc2026#section-5 https://tools.ietf.org/html/rfc6410 RFC 2026 section 4 as updated by 6410.=20 https://tools.ietf.org/html/rfc6782 https://tools.ietf.org/html/rfc7269 https://tools.ietf.org/html/rfc7335 https://tools.ietf.org/html/rfc7445 https://tools.ietf.org/html/rfc7849 https://tools.ietf.org/html/rfc7934 I would agree that informational status is probably inappropriate at = this point. I'll note that the progression is not all that unusual; GRE, = for example, was originally informational (RFC 1701), was taken to = Proposed Standard in RFC 2784, and has been updated by RFC 2890. If it = were taken to Internet Standard, we would need to demonstrate the points = raised in https://tools.ietf.org/html/rfc6410#section-2.2. What gives me pause in using the PS/IS standards track is the issue of = interoperation of multiple implementations. I'm not entirely sure what = that means in an operational procedure or service, which is in my = perception what 464XLAT is. If that is the interoperation of multiple = networks, it might be the interoperation of an IPv6-only (subset of a) = network with other IPv4 networks, as the interoperation of that same = network with IPv6 networks or networks with IPv6 capabilities doesn't = require such services. The description of a BCP in RFC 2026 sounds more = like what we're looking at here. My thought at the moment (which I can be argued out of) is that the = right status is BCP, and that we would want an updated document that = captures anything we have learned since RFC 6877 was published. > On Sep 19, 2017, at 5:23 AM, JORDI PALET MARTINEZ = wrote: >=20 > Hi all, >=20 > RFC6877 (464XLAT) is an informational document. >=20 > However, this transition mechanism is the one that has a bigger = deployment in terms of number of subscribers using it (hundreds of = millions), which I think is even more than ALL the other transition = mechanism together. >=20 > Doesn=E2=80=99t make any sense, in my opinion to keep it as an = informational document, while we have many others that are standards = track and don=E2=80=99t have such level of deployment. >=20 > I was commenting this last week with a couple of the co-authors of = this document, and they have the same opinion. >=20 > So, should we aim to do this? >=20 > Can we even consider moving it to STD? >=20 > Regards, > Jordi >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 19 13:37:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C08E1343A5 for ; Tue, 19 Sep 2017 13:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py8yIhozr0sB for ; Tue, 19 Sep 2017 13:36:57 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE2513306C for ; Tue, 19 Sep 2017 13:36:57 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id u18so468134pgo.0 for ; Tue, 19 Sep 2017 13:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=a8Imh85vwf2hGrNhLSw6Hcro0SqPzh2U9g0g2JXgLaQ=; b=RfTgow5mRPGZAYkGuHl1TC0vm1Wb0oM2l++lXpXyuDCcfQP/F24rp8y5Zt3nH/DGPQ BHOWlwrT3cM10KNLbN4ZUiSdkh0xTina+pErw+VWnX6lvkpy6NoPYVYru7uXKMBvdPzc D9H2FM/ZuWmim3SqANgsdk21nRIoSeB7i/C8tWnsVsw92tDvDXMkn8pcycDBiEZX23v5 rrCktIl/BHe6oKjnX9vUupowhSzyt2Q3OIGnCR+0gHxL+NENWA8T3CgBOk3Ltb8xIAqD UsJgUWFai7qRcEcgdgt86AFQ2eH8Fyn4nugPCeSS6jvoKOgh+/KMerYIGOf0gXTS7JXs tAHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=a8Imh85vwf2hGrNhLSw6Hcro0SqPzh2U9g0g2JXgLaQ=; b=qqKEQ/WZmyJPNgDugWdvMuPo+EpEKjlusryXg7MNCPIbtmNWkLpfbG/+EqEATSLpXw wHBCGZH9rA7x2arEVJshmtO7F72BD7dKUGnBFbf4UvkMV2mC+NWzwEp7ainRr4Isv1cW CbuWSHN8lGORlT7+vyK5O8mkQi4VlpmAZoRSqWq40Mp5g6AsXeieNzKCS7hnmYI25lAl NTdIPu4w/rqss48uthAy4JOvyZKT1H9VRvPE1z3j6Q1yN2kj0toGRP987mEwfdI7lpGW COA17oJjDNkO7Tqm+OGY1oLg9GudlwiNn1/CS4wnAnkoeZzISix08L/aVbIYkWkuAFem L9Eg== X-Gm-Message-State: AHPjjUjF86W0dzFS9Sm4Jva9/rk3EhXYeNMFVChFL4uXMphOlEWjfr1H f9y3Ny3T/vQTPwf/3ks2CgG5Hw== X-Google-Smtp-Source: AOwi7QD1HSd4S7s342bXskIQU+xof+qjshQ1x/fEcmTnFo4SCPy6TLnPux/oLPbZxJY1tubbStnWBw== X-Received: by 10.84.230.229 with SMTP id e92mr2370498plk.259.1505853416595; Tue, 19 Sep 2017 13:36:56 -0700 (PDT) Received: from ?IPv6:2406:e007:57a7:1:28cc:dc4c:9703:6781? ([2406:e007:57a7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y16sm792210pfe.68.2017.09.19.13.36.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 13:36:55 -0700 (PDT) To: v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 20 Sep 2017 08:36:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 20:36:59 -0000 On 20/09/2017 00:23, JORDI PALET MARTINEZ wrote: > Hi all, >=20 > RFC6877 (464XLAT) is an informational document. >=20 > However, this transition mechanism is the one that has a bigger deploym= ent in terms of number of subscribers using it (hundreds of millions), wh= ich I think is even more than ALL the other transition mechanism together= =2E >=20 > Doesn=E2=80=99t make any sense, in my opinion to keep it as an informat= ional document, while we have many others that are standards track and do= n=E2=80=99t have such level of deployment. >=20 > I was commenting this last week with a couple of the co-authors of this= document, and they have the same opinion. >=20 > So, should we aim to do this? >=20 > Can we even consider moving it to STD? It seems reasonable to me, but probably needs a new RFC, because of the "Status of this memo" section, so I expect that would lead to nitpicking discussions. Do the authors have the energy for that? Brian >=20 > Regards, > Jordi > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disc= losure, copying, distribution or use of the contents of this information,= even if partially, including attached files, is strictly prohibited and = will be considered a criminal offense. If you are not the intended recipi= ent be aware that any disclosure, copying, distribution or use of the con= tents of this information, even if partially, including attached files, i= s strictly prohibited, will be considered a criminal offense, so you must= reply to the original sender to inform about this communication and dele= te it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Tue Sep 19 13:41:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B5F1343A0 for ; Tue, 19 Sep 2017 13:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-ZM4PYEJ6PP for ; Tue, 19 Sep 2017 13:41:54 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EFB13439C for ; Tue, 19 Sep 2017 13:41:53 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id d16so2070213ioj.3 for ; Tue, 19 Sep 2017 13:41:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mlrIrLDCaH6DzS/aQOiI+YVuDoXQcdCZSiZOJgJ6mkY=; b=szpStYP6ZcNLX1bWA2sCQkT/O3e65p8K3tEjgDP9ZeTFL3chGf7IvC13sfMJSjSCIB idd98yUypI6DLcTOQ8e4kAozkn6vfYphHV2lDU/6c4OdlbNeKwhjq6JYCshoMTXrue3c fmiqHOnt42IkcxAeX5KRKT3isanCGMtqX/Ca4ziiB36ttp/NHzEXuA5HKg/GBn4LgQle QUmBrr8mAB2DNjVhsclvEFSxLJfKIFuMTXNvzsatHM82YWzse2WFfNHcBG8RVYrPAb70 lJlWX07KFYUt0+RNIRGYWIF69P/odQvSb5/GOlkMGMjYYYUwLLpWwz7qq9TAr2ZpNamb WWVA== 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=mlrIrLDCaH6DzS/aQOiI+YVuDoXQcdCZSiZOJgJ6mkY=; b=CutooB/3C6RKgDORy7L6xZOnTb9oDv6le3GsRoA9foTj2ZZ6tSq2/B1UrgZ09RMBAS g1MFa6douZT/xy6ifAyw28JIjvD20lP665qVgifshpnd2paEg1OyM9317+i3qBkiOZto A+DGgsq2idAFZTs1w1Qkj6MipW5Hby3KaVYEPsa+AS3L4fDyiy/PBYOCT8SS6uemT5UM I9cfa2moGm0tfQOGUyuFFNNoExElUfvoKORUj/FpWlj9AM8BV60lI2A//k4rnHnz2HJ+ Krsouz0vbOF74eJDnPaGK30IdaQ/YwuSgyA6fdCMfIb9+AlTZOF1r7IvbgLunQd7U9j1 9kMQ== X-Gm-Message-State: AHPjjUiV4st+zzbvbwvE4kXroZQtBZYXskWG8VBAHI0yGRf8A3wr2I45 gM0JGyFt+N4UCXN0n3TLjAQ= X-Google-Smtp-Source: AOwi7QBj9K/e00/A2+AlMiAAOuXL1KR72MhlU5VG665hdmk63YnO8aptyu2/g94g0vXQRCMWv3cqWA== X-Received: by 10.202.207.144 with SMTP id f138mr2775825oig.37.1505853713138; Tue, 19 Sep 2017 13:41:53 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1da8? ([2600:8802:5600:e::1da8]) by smtp.gmail.com with ESMTPSA id c126sm101223oia.35.2017.09.19.13.41.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 13:41:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: Date: Tue, 19 Sep 2017 13:41:50 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 20:41:56 -0000 Chair hat off. If it were ONLY about IPv4, I might agree with you, or suggest another = working group. 464XLAT is about connecting an IPv6-only (subset of a) = network to an IPv4 network, which I would think remains a current issue. = If we're serious about talking about IPv6-only networks, an important = part of that is helping people get there. That has been my argument for = doing anything related to transition mechanisms, in v6ops or anywhere = else.=20 If we were to declare anything HISTORIC, it would be other transition = mechanisms that have been documented but not widely found useful. We = killed 6to4 and Teredo... > On Sep 19, 2017, at 12:33 PM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 19/09/2017 =C3=A0 19:05, JORDI PALET MARTINEZ a =C3=A9crit : >> Not at all, just to avoid this protocol to be discriminated compared = to others. >=20 > 464xlat has more success than other transition mechanisms. I saw it = for myself. >=20 > Yet it's about IPv4. >=20 > How about Historical. >=20 > Alex >=20 >> No reason to have some of the standard and others informational, even = less if this is the one with has a bigger deployment. Just my opinion, = but based in facts. >> Regards, >> Jordi >> -----Mensaje original----- >> De: v6ops en nombre de Alexandre Petrescu = >> Responder a: >> Fecha: martes, 19 de septiembre de 2017, 13:23 >> Para: >> Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info >> Sounds as trying to impose 464xlat to everyone else? >> My little IoT IPv6 cellular device does not run 464xlat and = neither >> IPv4. If 464xlat becomes Stds Track does it mean that it MUST = run >> 464xlat? I would disagree with that. >> Alex >> Le 19/09/2017 =C3=A0 14:23, JORDI PALET MARTINEZ a =C3=A9crit = : >> > Hi all, >> > >> > RFC6877 (464XLAT) is an informational document. >> > >> > However, this transition mechanism is the one that has a bigger = deployment in terms of number of subscribers using it (hundreds of = millions), which I think is even more than ALL the other transition = mechanism together. >> > >> > Doesn=E2=80=99t make any sense, in my opinion to keep it as an = informational document, while we have many others that are standards = track and don=E2=80=99t have such level of deployment. >> > >> > I was commenting this last week with a couple of the co-authors = of this document, and they have the same opinion. >> > >> > So, should we aim to do this? >> > >> > Can we even consider moving it to STD? >> > >> > Regards, >> > Jordi >> > >> > >> > >> > >> > ********************************************** >> > IPv4 is over >> > Are you ready for the new Internet ? >> > http://www.consulintel.es >> > The IPv6 Company >> > >> > This electronic message contains information which may be = privileged or confidential. The information is intended to be for the = exclusive use of the individual(s) named above and further = non-explicilty authorized disclosure, copying, distribution or use of = the contents of this information, even if partially, including attached = files, is strictly prohibited and will be considered a criminal offense. = If you are not the intended recipient be aware that any disclosure, = copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited, will be = considered a criminal offense, so you must reply to the original sender = to inform about this communication and delete it. >> > >> > >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Sep 19 13:56:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0CA1321A4 for ; Tue, 19 Sep 2017 13:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-RJIdRtCvWn for ; Tue, 19 Sep 2017 13:56:16 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA69C1321CB for ; Tue, 19 Sep 2017 13:56:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JKuE63022623 for ; Tue, 19 Sep 2017 22:56:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 05C1620E6A2 for ; Tue, 19 Sep 2017 22:56:14 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F031C2019BC for ; Tue, 19 Sep 2017 22:56:13 +0200 (CEST) Received: from [132.166.84.39] ([132.166.84.39]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8JKuDN1000483 for ; Tue, 19 Sep 2017 22:56:13 +0200 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: Date: Tue, 19 Sep 2017 22:56:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 20:56:18 -0000 From my humble experience of following IPv6 cellular deployments, I noticed that once 464XLAT got proposed DHCPv6 service was removed. It was suggested that that was the 'standard' (464XLAT) and that everyone would do it. I am not able to explain the relationship 464XLAT-yes / DHCPv6-no, unless I make some speculations. To avoid me speculating, I would like to ask you: do you think there is any relationship between the two? Do you think DHCPv6 is still necessary when 464XLAT runs? Do you think 464XLAT hampers somehow the deployment of DHCPv6 (just like 64share does with DHCPv6-PD)? I would like to say that if you consider 464XLAT to be a good Android technology on good cellular networks - I agree with you. Just I doubt about the StdsTrack. Alex PS: if you have time: From the software side, I can say that some non-Android IoT device connects ok to IPv6 cellular network and does not use 464XLAT. It does not need IPv4 connectivity to the IPv4 Internet. I wonder whether the client-side 464XLAT implementation is open-source? Is it a kernel module or userspace? Is there an option "464XLAT support" in the kernel? Or maybe there is no client-side 464XLAT (and all happens in the network)? Or maybe it is a binary in the modem that implements 464xlat, and not the open-source in the linux. Le 19/09/2017 à 14:23, JORDI PALET MARTINEZ a écrit : > Hi all, > > RFC6877 (464XLAT) is an informational document. > > However, this transition mechanism is the one that has a bigger > deployment in terms of number of subscribers using it (hundreds of > millions), which I think is even more than ALL the other transition > mechanism together. > > Doesn’t make any sense, in my opinion to keep it as an informational > document, while we have many others that are standards track and > don’t have such level of deployment. > > I was commenting this last week with a couple of the co-authors of > this document, and they have the same opinion. > > So, should we aim to do this? > > Can we even consider moving it to STD? > > Regards, Jordi > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Sep 19 14:16:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DF21342D9 for ; Tue, 19 Sep 2017 14:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ru87Qh-sNz7 for ; Tue, 19 Sep 2017 14:15:57 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC9C1321A4 for ; Tue, 19 Sep 2017 14:15:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8JLFsgG033541; Tue, 19 Sep 2017 23:15:54 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D634620E85F; Tue, 19 Sep 2017 23:15:54 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BFEE120E85A; Tue, 19 Sep 2017 23:15:54 +0200 (CEST) Received: from [132.166.84.37] ([132.166.84.37]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8JLFr0J021012; Tue, 19 Sep 2017 23:15:54 +0200 To: Fred Baker Cc: v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 19 Sep 2017 23:15:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 21:15:58 -0000 Hi Fred, Let me comment. Le 19/09/2017 à 22:41, Fred Baker a écrit : > Chair hat off. > > If it were ONLY about IPv4, I might agree with you, or suggest > another working group. 464XLAT is about connecting an IPv6-only > (subset of a) network to an IPv4 network, If it is an IPv6-only (subset of a) network then it must run DHCPv6-PD to get a prefix. DHCPv6-PD is Standards Track. I did not see DHCPv6-PD on networks where 464XLAT is present. Second, when you say connecting IPv6-only network to an IPv4-only network: GTPU does that already. A pure IPv6 IoT device that does not run 464XLAT connects to a cellular network and its IPv6 traffic gets encap/decap into an IPv4 network by using IPv6-in-GTP. GTP is an IPv4 protocol. A packet dump sent by the IPv6 IoT Router and captured on the PGW looks like this. This capture was run on a network that does not use 464XLAT. INBOUND>>>>> 15:47:48:883 Eventid:142004(3) GTPU Rx PDU, from [IPv4-address]:2152 to [IPv4-address-2]:2152 (129) TEID: 0x80072183, Message type: GTP_TPDU_MSG (0xFF) Sequence Number:: NA GTP HEADER FOLLOWS: [snip] GTP HEADER ENDS. Payload protocol: IPv6 PROTOCOL PAYLOAD FOLLOWS: fe80::b9d9:c10a:2c2d:3c3b.546 > ff02::2.546: [udp sum ok] IPv6 Header Follows: [snip] PROTOCOL PAYLOAD ENDS. Alex From nobody Tue Sep 19 14:31:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C2013308F for ; Tue, 19 Sep 2017 14:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf83Ws0_SGIY for ; Tue, 19 Sep 2017 14:31:55 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5C3132D42 for ; Tue, 19 Sep 2017 14:31:54 -0700 (PDT) Received: from [10.0.5.241] (r190-64-69-50.su-static.adinet.com.uy [190.64.69.50] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v8JLUnI0021075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Sep 2017 14:30:51 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: Date: Tue, 19 Sep 2017 18:30:47 -0300 Cc: Fred Baker , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Tue, 19 Sep 2017 14:30:53 -0700 (PDT) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 21:31:56 -0000 > On Sep 19, 2017, at 6:15 PM, Alexandre Petrescu = wrote: >=20 > Hi Fred, >=20 > Let me comment. >=20 > Le 19/09/2017 =C3=A0 22:41, Fred Baker a =C3=A9crit : >> Chair hat off. >> If it were ONLY about IPv4, I might agree with you, or suggest >> another working group. 464XLAT is about connecting an IPv6-only >> (subset of a) network to an IPv4 network, >=20 > If it is an IPv6-only (subset of a) network then it must run DHCPv6-PD = to get a prefix. DHCPv6-PD is Standards Track. I did not see DHCPv6-PD = on networks where 464XLAT is present. This statement simply isn=E2=80=99t true. Lots of IPv6 only networks exist that do not use DHCP at all. Owen From nobody Tue Sep 19 17:03:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9736C1331B0 for ; Tue, 19 Sep 2017 17:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWLdcwgwXPlr for ; Tue, 19 Sep 2017 17:02:59 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17DAC1330B2 for ; Tue, 19 Sep 2017 17:02:58 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id l74so353566oih.1 for ; Tue, 19 Sep 2017 17:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sgCjmgDKvnD7CbYM/1q7DUOrquciGV/+hjjhQeAYVeE=; b=XsrJ33iRE6UvcGhNEHE0mJ9DqWpDQtejxjS+c4MFRRGPHSXFEur9Xtb7U1J69YSFle 1BMTHh3pnmP/0U4RFiDs5sAmrakGUiD7f4wJdzUAGW5pRHz97xY0g1/Nsmf1XPY7G63j AVZR3EgSNSov4CYD4RRD9Viwe8K0Y2CasyTs+82XyTqszcBwCwhZrurOgOkPX9KaLrYY TyU6ZvrWaUEG9oUyvccjn7DqVaxpkIKC9jAeuKN1Dzx4Ef+FlriNzkRqb84xJXzPboXw 4E+GYaQLF8ZtmbI+AfEvqXNXzJVw5Ae+FK9iKWhEZAKJt3BIr29VNKKqMHINinLZtz2l oihw== 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=sgCjmgDKvnD7CbYM/1q7DUOrquciGV/+hjjhQeAYVeE=; b=HfM2JC2RrGtzT7L0907c4TyS9Kik3dsT9XGQwiGnOMSwGzSwR532Fj3FPLlZa/aDvZ BX0yZlgmpFKF1wAlAc5byBmDyk7+42KlV8nu/oZT0q9FcD6iVSuHYEF3lrF6mms+tCCB +sMyE0+gvD7weJMpGbn9TdFswmlBARTGF57p/KYJtlKGNPVPbQmvwrEq3ECGP3RBl341 4xVFwq+5tUDbTEPDJlzssYBO0qREy66gzSjj9uNUHYl+bwSTWdjslOSZXonNTDJAiXd8 BgSlMTU8wIUAMl6V6D3uXQYNeiYLbSXz9k2XQvmTXU0LQpPryiFytNo6HREBUnXnne5R S/bw== X-Gm-Message-State: AHPjjUiKLrLBnZ87ntbBut8q9xTdJXDZpat+uKANNj1oNRuBfwvRdt7H 7GW28m3HPDBmWEGeoHnJwoc= X-Google-Smtp-Source: AOwi7QBfZ7G+SygdbZEpgnCMrli3ngT36x+Y5MgJNM4KbERcuUnzj2pdOgi9Npnpx+3XWrwGCovUwg== X-Received: by 10.202.237.23 with SMTP id l23mr3564070oih.63.1505865777387; Tue, 19 Sep 2017 17:02:57 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1da8? ([2600:8802:5600:e::1da8]) by smtp.gmail.com with ESMTPSA id p40sm961362otd.18.2017.09.19.17.02.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Sep 2017 17:02:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: Date: Tue, 19 Sep 2017 17:02:54 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 00:03:00 -0000 > On Sep 19, 2017, at 2:15 PM, Alexandre Petrescu = wrote: >=20 > Hi Fred, >=20 > Let me comment. >=20 > Le 19/09/2017 =C3=A0 22:41, Fred Baker a =C3=A9crit : >> Chair hat off. >> If it were ONLY about IPv4, I might agree with you, or suggest >> another working group. 464XLAT is about connecting an IPv6-only >> (subset of a) network to an IPv4 network, >=20 > If it is an IPv6-only (subset of a) network then it must run DHCPv6-PD = to get a prefix. DHCPv6-PD is Standards Track. I did not see DHCPv6-PD = on networks where 464XLAT is present. Let's agree that it has to have a prefix. T-Mobile, for example, has a = prefix. Cameron Byrne, from T-Mobile, is a co-author of 464XLAT. > Second, when you say connecting IPv6-only network to an IPv4-only = network: GTPU does that already. Which is great if you're going to a mobile network. If you're going = anywhere else on the Internet, a mobile-only protocol doesn't do much = for you. That's why we defined 464XLAT.= From nobody Tue Sep 19 17:41:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E336133061 for ; Tue, 19 Sep 2017 17:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBbydwhaadcM for ; Tue, 19 Sep 2017 17:41:05 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DED3133054 for ; Tue, 19 Sep 2017 17:41:05 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 38BB524B2CF; Wed, 20 Sep 2017 00:40:22 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 681EF160083; Wed, 20 Sep 2017 00:40:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 52449160084; Wed, 20 Sep 2017 00:40:29 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0LNOdkcpCbO4; Wed, 20 Sep 2017 00:40:29 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 07FD3160083; Wed, 20 Sep 2017 00:40:29 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8122186C0A4E; Wed, 20 Sep 2017 10:40:25 +1000 (AEST) To: Fred Baker Cc: Alexandre Petrescu , v6ops@ietf.org From: Mark Andrews References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> In-reply-to: Your message of "Tue, 19 Sep 2017 17:02:54 -0700." <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> Date: Wed, 20 Sep 2017 10:40:25 +1000 Message-Id: <20170920004025.8122186C0A4E@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 00:41:07 -0000 In message <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com>, Fred Baker writes: > > > > On Sep 19, 2017, at 2:15 PM, Alexandre Petrescu > wrote: > > > > Hi Fred, > > > > Let me comment. > > > > Le 19/09/2017 22:41, Fred Baker a crit : > >> Chair hat off. > >> If it were ONLY about IPv4, I might agree with you, or suggest > >> another working group. 464XLAT is about connecting an IPv6-only > >> (subset of a) network to an IPv4 network, > > > > If it is an IPv6-only (subset of a) network then it must run DHCPv6-PD > to get a prefix. DHCPv6-PD is Standards Track. I did not see DHCPv6-PD > on networks where 464XLAT is present. > > Let's agree that it has to have a prefix. T-Mobile, for example, has a > prefix. Cameron Byrne, from T-Mobile, is a co-author of 464XLAT. > > > Second, when you say connecting IPv6-only network to an IPv4-only > network: GTPU does that already. > > Which is great if you're going to a mobile network. If you're going > anywhere else on the Internet, a mobile-only protocol doesn't do much for > you. That's why we defined 464XLAT. We defined 464XLAT because people deployed DNS64/NAT64 despite all its flaws because the proponents of DNS64/NAT64 made lots of claims that failed to eventuate in reality. 464XLAT exists to work around the limitations of DNS64/NAT64. Claims like we don't need to make changes to the node, yet we have a CLATs being installed in every node. Claims like DNS64 is the only way to move traffic to IPv6. Traffic moves to IPv6 just fine using address sorting. Claims like we will naturally know when to turn off the DNS64/NAT64 but we can't do that with any other method. Hogwash. Now we have a complicated encapsulation/translation scheme that requires payload translation at both ends being promoted over simple IPv4 in IPv6 encapsulation. 464XLAT has zero benefits over simple IPv4 in IPv6 encapsulation. Complicated -> more bugs, more testing required, more cost and reluctance to go to IPv6 at all. NAT64 and 464XLAT makes it impossible to write a new protocol that embeds IP addresses based on the transport being used. All of DNS64, NAT64 and 464XLAT should be made historic despite their prevalence. They are all bad engineering. Yes, this is betamax vs vhs. Unfortunately we don't have DVD's coming along to wipe out the bad market decision. We are going to be left with the consequences of this bad engineering for decades to come. Mark > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Sep 19 17:45:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B423133073 for ; Tue, 19 Sep 2017 17:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9irjef751Mhm for ; Tue, 19 Sep 2017 17:45:07 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B984133071 for ; Tue, 19 Sep 2017 17:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505868302; x=1506473102; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=y9zwg8hUAL5qlL9rphEvwQoNA x5eE8KlsqTOzkQK6wg=; b=IgTTixf4RMqmidspfA86rmbm55IF/Hsj0o8Hvsuvt 5K1HzDeDIeWGpwRqBaKL4hT91HlwXgFFHZdaLar7Du0DCEwnO/MTGkuDFUz5riry ejg8DiP6nSxKKuJ70i2bQ8EXbwaF7i9CqhYzGR3aV403mHJBP5rUSx40PGpsWm9i 5w= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Xii8Ut11m/xnwLj1tGTl+qoMr5ifzJ3MaWDP4/8K2TkNF8139S7QhARKDKJt I77RvBt4vdIY5ifEwUkqzJHsgCWlrhN0y89pP9tOOkOvU6sv/KiR5t2OQ hinHYvqS6Ce1lI0TwBhud0wrfkz39zFCKdFcGn805zeBzr19hRTExU=; X-MDAV-Processed: mail.consulintel.es, Wed, 20 Sep 2017 02:45:02 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 20 Sep 2017 02:45:01 +0200 Received: from [10.0.5.203] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005560636.msg for ; Wed, 20 Sep 2017 02:45:01 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170920:md50005560636::tu0PgVHGB8zcXrD6:00001LPS X-Return-Path: prvs=143688d48d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Tue, 19 Sep 2017 21:44:39 -0300 From: JORDI PALET MARTINEZ To: Message-ID: <42850F48-98C1-4EA3-8753-A7D950069C65@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 00:45:15 -0000 I will wait for the authors to confirm, but if they don=E2=80=99t have the = energy, I=E2=80=99m ready to volunteer for that. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Organizaci=C3=B3n: University of Auckland Responder a: Fecha: martes, 19 de septiembre de 2017, 17:37 Para: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info On 20/09/2017 00:23, JORDI PALET MARTINEZ wrote: > Hi all, >=20 > RFC6877 (464XLAT) is an informational document. >=20 > However, this transition mechanism is the one that has a bigger deplo= yment in terms of number of subscribers using it (hundreds of millions), wh= ich I think is even more than ALL the other transition mechanism together. >=20 > Doesn=E2=80=99t make any sense, in my opinion to keep it as an inform= ational document, while we have many others that are standards track and do= n=E2=80=99t have such level of deployment. >=20 > I was commenting this last week with a couple of the co-authors of th= is document, and they have the same opinion. >=20 > So, should we aim to do this? >=20 > Can we even consider moving it to STD? =20 It seems reasonable to me, but probably needs a new RFC, because of the "Status of this memo" section, so I expect that would lead to nitpickin= g discussions. Do the authors have the energy for that? =20 Brian =20 >=20 > Regards, > Jordi > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Sep 19 17:51:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357F6133055 for ; Tue, 19 Sep 2017 17:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar61iY8PZR9v for ; Tue, 19 Sep 2017 17:51:49 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229D9133023 for ; Tue, 19 Sep 2017 17:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505868707; x=1506473507; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=elFEcupuCZQHri6glBEyb4mFQ Iy7nwUg41ks5HPkE7w=; b=CDzyDp7qu9EFNk8mk59XQyFMVDu1TYpLU7hEDbC4J PVGGkOEDKmDi5Hboyt+Fa5/l7woduvmGw8ik0mW0yVoChuHOMcyLeYuHhy2096sY +f3Bqkkq4EKkndK39+gqBQ7wJ/lxEoGY4q2d/wH3C/fqYdq0rOQbhDAbLgyaitcN 9M= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=PR0MRKqmCLV3RCQIlE2+vUQOFBgzVwDvz1Zdp9w3rf7K8MBdlN0fGpQcJhLJ ius9O2ShrAMnevAyUoEhGI/cz6o3FcMcbzrytS9Uk1aMv/6tuguJb8XRm tBy/9GGDgi8D8QV/4/sogC7vFHCA+odKFow0owLwwFqkpyWnNrIu7Y=; X-MDAV-Processed: mail.consulintel.es, Wed, 20 Sep 2017 02:51:47 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 20 Sep 2017 02:51:44 +0200 Received: from [10.0.5.203] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005560643.msg for ; Wed, 20 Sep 2017 02:51:44 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170920:md50005560643::rtQtIqppuw9c3hJ1:00000cTr X-Return-Path: prvs=143688d48d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Tue, 19 Sep 2017 21:51:33 -0300 From: JORDI PALET MARTINEZ To: Message-ID: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 00:51:51 -0000 I=E2=80=99ve deployed 464XLAT in cellular networks with SLAAC but also with= DHCPv6-PD using LTE =E2=80=9Crouters=E2=80=9D. Same for residential networ= ks. I don=E2=80=99t think one or the other is relevant to the suggestion I=E2= =80=99m doing about reclassifying it as standard. If you do it with SLAAC, as described in the RFC, the NAT46 will be statefu= l (by means of a previous NAT44) because you don=E2=80=99t have a specific = /64 for the translation. Otherwise will be stateless. The CLAT, which is the =E2=80=9Cclient=E2=80=9D side (run in a cellular pho= ne or a CPE or OS), is available in open source. Just look at the OpenWRT i= mplementation, but I=E2=80=99m sure there are others. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: martes, 19 de septiembre de 2017, 17:56 Para: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info From my humble experience of following IPv6 cellular deployments, I noticed that once 464XLAT got proposed DHCPv6 service was removed. It was suggested that that was the 'standard' (464XLAT) and that everyone would do it. =20 I am not able to explain the relationship 464XLAT-yes / DHCPv6-no, unless I make some speculations. =20 To avoid me speculating, I would like to ask you: do you think there is any relationship between the two? Do you think DHCPv6 is still necessary when 464XLAT runs? Do you think 464XLAT hampers somehow the deployment of DHCPv6 (just like 64share does with DHCPv6-PD)? =20 I would like to say that if you consider 464XLAT to be a good Android technology on good cellular networks - I agree with you. Just I doubt about the StdsTrack. =20 Alex =20 PS: if you have time: From the software side, I can say that some non-Android IoT device connects ok to IPv6 cellular network and does not use 464XLAT. It does not need IPv4 connectivity to the IPv4 Internet. =20 I wonder whether the client-side 464XLAT implementation is open-source? Is it a kernel module or userspace? Is there an option "464XLAT support" in the kernel? Or maybe there is no client-side 464XLAT (and all happens in the network)? Or maybe it is a binary in the modem that implements 464xlat, and not the open-source in the linux. =20 =20 =20 Le 19/09/2017 =C3=A0 14:23, JORDI PALET MARTINEZ a =C3=A9crit : > Hi all, >=20 > RFC6877 (464XLAT) is an informational document. >=20 > However, this transition mechanism is the one that has a bigger=20 > deployment in terms of number of subscribers using it (hundreds of=20 > millions), which I think is even more than ALL the other transition= =20 > mechanism together. >=20 > Doesn=E2=80=99t make any sense, in my opinion to keep it as an inform= ational=20 > document, while we have many others that are standards track and=20 > don=E2=80=99t have such level of deployment. >=20 > I was commenting this last week with a couple of the co-authors of=20 > this document, and they have the same opinion. >=20 > So, should we aim to do this? >=20 > Can we even consider moving it to STD? >=20 > Regards, Jordi >=20 >=20 >=20 >=20 > ********************************************** IPv4 is over Are you= =20 > ready for the new Internet ? http://www.consulintel.es The IPv6=20 > Company >=20 > This electronic message contains information which may be privileged= =20 > or confidential. The information is intended to be for the exclusive= =20 > use of the individual(s) named above and further non-explicilty=20 > authorized disclosure, copying, distribution or use of the contents= =20 > of this information, even if partially, including attached files, is= =20 > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Sep 19 18:10:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D0D1326ED for ; Tue, 19 Sep 2017 18:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 36XlD6VvGzxh for ; Tue, 19 Sep 2017 18:10:32 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD8F5124B18 for ; Tue, 19 Sep 2017 18:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1505869832; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ScGrXKUEYV0lt9NNC0kSHnFCRsfyMZGBxHTWS4pwkeE=; b=ZKdTht2gBBN62BUCyBNn8NHy5Cj0a4whDIUDm0bnq+SV873ojajB9kLpe0HTmSpM DOPfIT3hkU7jehg3Pn+nwvObrdCEDxdAJqHesG3Ua2ChOdRCjlT4USKs2IGwN+ZP 4H8qF4wNqkl8CwghpqxLwsW3SrdZXiLGmx5EtoVBmGfsh4doBuJJBfzYhTSyY6om InVNPz0vnpLoQJB4BDA0/blnzwel1hYx6Wz8t9jV2kvYmsOw5ouYhurCUkUXzSph W57Xs+EVu5/ZPFYe8MhhsgP4IVMPXgqDXkW/1NbHJQ9E2glaUM/tqwfiEaYc+AP+ WWpQVaIfRP3T0A736G0dvg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 42.44.11091.800C1C95; Tue, 19 Sep 2017 18:10:32 -0700 (PDT) X-AuditID: 11973e15-061ff70000002b53-3f-59c1c0082cec Received: from koseret.apple.com (koseret.apple.com [17.151.62.39]) by relay6.apple.com (Apple SCV relay) with SMTP id F9.CE.03275.800C1C95; Tue, 19 Sep 2017 18:10:32 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from da0602a-dhcp112.apple.com (da0602a-dhcp112.apple.com [17.226.23.112]) by koseret.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OWK00L3F0LKK510@koseret.apple.com>; Tue, 19 Sep 2017 18:10:32 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> Date: Tue, 19 Sep 2017 18:10:31 -0700 Cc: v6ops@ietf.org Content-transfer-encoding: quoted-printable Message-id: <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUi2FAYpctx4GCkwYYVGhZ/j39mtjh9bC+z A5PHuv0BHkuW/GQKYIrisklJzcksSy3St0vgyvix7Th7wQzWivtth9gbGCewdDFycEgImEic 3h/fxcjFISSwmkni3oJmti5GTrD4/AXNzCC2kMAWRomXa3RAbF4BQYkfk++B9TILqEtMmZIL 0buYSeLy77ksIDXCAtISXRfuskLYzhKrH7xkB6lnE9CSOLDGCCTMKeAkcfjYYbDxLAKqEq// LAGzmQWEJBZf+84IYWtLPHl3gRVirY3E5H+9LBC71jBKLOxoYwdJiAjISdxd0coIcbOsxK3Z l5hBiiQEfrJKnJ11hnUCo/AsJHfPQrh7FpIdCxiZVzEK5SZm5uhm5pnpJRYU5KTqJefnbmIE BfV0O9EdjGdWWR1iFOBgVOLhDbA6GCnEmlhWXJl7iFGag0VJnFd+OlBIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QD49QOHuvvTb2lCUUCGk3BCSdm7ODWfrkkOvQNy7Ev7JlnX6xa/CfB9MHB lQzfz6vNWbG5b9p8rlNGzZO6fIMXn/I23//jyV0VBZ/nga8jZjNx3ftjf5Ot3eNkqWrRhEue ui9vRZpGlG4/fefhFf3Jpw8vfHa9+Y7scksNB4Pgc3LT64+q9ue8T1diKc5INNRiLipOBAB+ TWlpSwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUiON1OXZfjwMFIg9WHVC3+Hv/MbHH62F5m ByaPdfsDPJYs+ckUwBTFZZOSmpNZllqkb5fAlfFj23H2ghmsFffbDrE3ME5g6WLk5JAQMJGY v6CZGcQWEtjCKPFyjQ6IzSsgKPFj8j2gGg4OZgF1iSlTcrsYuYBKFjNJXP49F6xXWEBaouvC XVYI21li9YOX7CD1bAJaEgfWGIGEOQWcJA4fOww2nkVAVeL1nyVgNrOAkMTia98ZIWxtiSfv LrBCrLWRmPyvlwVi1xpGiYUdbewgCREBOYm7K1oZIW6Wlbg1+xLzBEaBWUhOnYVw6iwkYxcw Mq9iFChKzUmsNNNLLCjISdVLzs/dxAgKw4bCqB2MDcutDjEKcDAq8fD+MD8YKcSaWFZcmXuI UYKDWUmEt3QvUIg3JbGyKrUoP76oNCe1+BCjNAeLkjhv7gyglEB6YklqdmpqQWoRTJaJg1Oq gdHbp7At79Gm84kTVj+XebrqwLMWlzp2I3u+fRpSK9WcrbfskJz2f7bHg8e/zl504r1axJTt sNRfKtCWbemiCsdD20VFlnOE8TvpfXKYWcm98ZLDkoMzLaZaRNnNU7hnMpdHz3cx2zLnOJnP RT+u11Q7H5uqxFHtpZRVs8pvqd9xVjPnOCshMSWW4oxEQy3mouJEAH8FSD4/AgAA Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 01:10:34 -0000 > On Sep 19, 2017, at 17:51, JORDI PALET MARTINEZ = wrote: >=20 > If you do it with SLAAC, as described in the RFC, the NAT46 will be = stateful (by means of a previous NAT44) because you don=E2=80=99t have a = specific /64 for the translation. Otherwise will be stateless. I don't think that's correct. In order to make 464XLAT stateless you = need a separate /128, not /64. And SLAAC allows you to generate that = extra /128. As far as I know, this is how Android works. As far the discussion of changing the Category of the RFC, I'm not sure = what it accomplishes, and whether it's worth spending time on. David= From nobody Tue Sep 19 18:34:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF6C133070 for ; Tue, 19 Sep 2017 18:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy315XobfJnm for ; Tue, 19 Sep 2017 18:34:29 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A641320DC for ; Tue, 19 Sep 2017 18:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505871266; x=1506476066; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=CLYEj8nlAevaESzYcACeakx9B ipDJJXt14kvrrctTpk=; b=lGZQx9uqkqwwwptVtFGbB071efZjDQ5yIg2xRWuhB Ujgj53WvGgbBpR3oDlXkQTGDZcK1e1IAd7aIl2ULgasMDLXRxYGSI+xbMTs7zzrN J3ReygXhzbfUt/Zwi4Si4I/QQI0N3J27aGhwDlJuJI9WT0gf9HqYQ8UmOJMpqfnQ /s= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=j5BedfTbahu38cB9/xyBCrhTnvxC8BY0aeezcz5p/DtSWEODribu3SgQJucY A4bakvv9x7rDRz6PL3hJ2RRJIAZpldlp7OrUksBdmTmMSFvw4HtYVXKIC UGaGSU1a5R6glNc40/CxFuJeMmW/x+1YaqnCmnd3XDXcFmxGMB+XzE=; X-MDAV-Processed: mail.consulintel.es, Wed, 20 Sep 2017 03:34:24 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 20 Sep 2017 03:34:23 +0200 Received: from [10.0.5.203] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005560702.msg for ; Wed, 20 Sep 2017 03:34:22 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170920:md50005560702::pK/+287FMMPUo115:00004x+O X-Return-Path: prvs=143688d48d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Tue, 19 Sep 2017 22:34:11 -0300 From: JORDI PALET MARTINEZ To: Message-ID: <1B4AAE0F-0F5E-49F5-A35B-57F3372A11EB@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> In-Reply-To: <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 01:34:33 -0000 I think you may be right, it makes sense that a single /128 will be able to= allow that, but I think it is clear that needs to be a different one that = the CLAT WAN interface. I guess the authors indicated a separated /64 as it= seems easier to allocate it than a single address if you=E2=80=99re using = DHCPv6-PD. I was just recalling what is in the actual RFC: 6.3. IPv6 Prefix Handling There are two relevant IPv6 prefixes that the CLAT must be aware of. First, CLAT must know its own IPv6 prefixes. The CLAT should acquire a /64 for the uplink interface, a /64 for all downlink interfaces, and a dedicated /64 prefix for the purpose of sending and receiving statelessly translated packets. When a dedicated /64 prefix is not available for translation from DHCPv6-PD [RFC3633], the CLAT may perform NAT44 for all IPv4 LAN packets so that all the LAN-originated IPv4 packets appear from a single IPv4 address and are then statelessly translated to one interface IPv6 address that is claimed by the CLAT via the Neighbor Discovery Protocol (NDP) and defended with Duplicate Address Detection (DAD). Regards, Jordi =20 -----Mensaje original----- De: en nombre de David Schinazi Responder a: Fecha: martes, 19 de septiembre de 2017, 22:21 Para: CC: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info =20 > On Sep 19, 2017, at 17:51, JORDI PALET MARTINEZ wrote: >=20 > If you do it with SLAAC, as described in the RFC, the NAT46 will be s= tateful (by means of a previous NAT44) because you don=E2=80=99t have a spe= cific /64 for the translation. Otherwise will be stateless. =20 I don't think that's correct. In order to make 464XLAT stateless you ne= ed a separate /128, not /64. And SLAAC allows you to generate that extra /1= 28. As far as I know, this is how Android works. =20 As far the discussion of changing the Category of the RFC, I'm not sure= what it accomplishes, and whether it's worth spending time on. =20 David =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Sep 19 22:04:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099EE13303A for ; Tue, 19 Sep 2017 22:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL7JJf6c1MFW for ; Tue, 19 Sep 2017 22:04:21 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA21132FA7 for ; Tue, 19 Sep 2017 22:04:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8K54CLZ031693; Wed, 20 Sep 2017 07:04:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 23543201ED0; Wed, 20 Sep 2017 07:04:12 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0965E200ED2; Wed, 20 Sep 2017 07:04:12 +0200 (CEST) Received: from [132.166.84.27] ([132.166.84.27]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8K54BEW003583; Wed, 20 Sep 2017 07:04:11 +0200 To: Owen DeLong Cc: Fred Baker , v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> From: Alexandre Petrescu Message-ID: <84a25d02-45ab-0403-6899-4e26843a76e3@gmail.com> Date: Wed, 20 Sep 2017 07:04:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 05:04:23 -0000 Le 19/09/2017 à 23:30, Owen DeLong a écrit : > >> On Sep 19, 2017, at 6:15 PM, Alexandre Petrescu wrote: >> >> Hi Fred, >> >> Let me comment. >> >> Le 19/09/2017 à 22:41, Fred Baker a écrit : >>> Chair hat off. >>> If it were ONLY about IPv4, I might agree with you, or suggest >>> another working group. 464XLAT is about connecting an IPv6-only >>> (subset of a) network to an IPv4 network, >> >> If it is an IPv6-only (subset of a) network then it must run DHCPv6-PD to get a prefix. DHCPv6-PD is Standards Track. I did not see DHCPv6-PD on networks where 464XLAT is present. > > This statement simply isn’t true. > > Lots of IPv6 only networks exist that do not use DHCP at all. I mean IPv6 subnet like a cellular-WiFi-Ethernet small router. That is mobile, needs a prefix. And I mean DHCPv6-PD, not DHCP. Those IPv6 networks that dont need PD are those that are not mobile. Alex > > Owen > > > From nobody Tue Sep 19 22:07:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD67F13303A for ; Tue, 19 Sep 2017 22:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FUZZY_MILLION=2.505, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDFnB1Q75ltD for ; Tue, 19 Sep 2017 22:07:31 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A46B132FA7 for ; Tue, 19 Sep 2017 22:07:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8K57TL3032701; Wed, 20 Sep 2017 07:07:29 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B3F23201510; Wed, 20 Sep 2017 07:07:29 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A72BB201472; Wed, 20 Sep 2017 07:07:29 +0200 (CEST) Received: from [132.166.84.27] ([132.166.84.27]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8K57S8w005677; Wed, 20 Sep 2017 07:07:29 +0200 To: Fred Baker Cc: v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> From: Alexandre Petrescu Message-ID: <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> Date: Wed, 20 Sep 2017 07:07:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 05:07:33 -0000 Le 20/09/2017 à 02:02, Fred Baker a écrit : > > >> On Sep 19, 2017, at 2:15 PM, Alexandre Petrescu >> wrote: >> >> Hi Fred, >> >> Let me comment. >> >> Le 19/09/2017 à 22:41, Fred Baker a écrit : >>> Chair hat off. If it were ONLY about IPv4, I might agree with >>> you, or suggest another working group. 464XLAT is about >>> connecting an IPv6-only (subset of a) network to an IPv4 >>> network, >> >> If it is an IPv6-only (subset of a) network then it must run >> DHCPv6-PD to get a prefix. DHCPv6-PD is Standards Track. I did >> not see DHCPv6-PD on networks where 464XLAT is present. > > Let's agree that it has to have a prefix. T-Mobile, for example, has > a prefix. Cameron Byrne, from T-Mobile, is a co-author of 464XLAT. Hello to Mr. Byrne. That prefix is not DHCPv6-PD. That prefix is an INFORMATIONAL method that is 64share. The StdsTrack method is DHCPv6-PD. If one looks at making 464XLAT StdsTrack one also considers 64share to go StdsTrack. >> Second, when you say connecting IPv6-only network to an IPv4-only >> network: GTPU does that already. > > Which is great if you're going to a mobile network. If you're going > anywhere else on the Internet, a mobile-only protocol doesn't do much > for you. That's why we defined 464XLAT. Well, I dont think 464XLAT is deployed anywhere else than on cellular. These are the big numbers that the Original Poster talked about: miliions of users - they are on cellular. Alex > From nobody Tue Sep 19 22:16:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129B0132F30 for ; Tue, 19 Sep 2017 22:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unlvX0pTGzji for ; Tue, 19 Sep 2017 22:16:25 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71609132D49 for ; Tue, 19 Sep 2017 22:16:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8K5GNQc027717 for ; Wed, 20 Sep 2017 07:16:23 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6DA322048DE for ; Wed, 20 Sep 2017 07:16:23 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 645C32047B7 for ; Wed, 20 Sep 2017 07:16:23 +0200 (CEST) Received: from [132.166.84.27] ([132.166.84.27]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8K5GMZO012244 for ; Wed, 20 Sep 2017 07:16:23 +0200 To: v6ops@ietf.org References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> From: Alexandre Petrescu Message-ID: <82b2f184-f7e3-b8f2-ea39-c2801ba71738@gmail.com> Date: Wed, 20 Sep 2017 07:16:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 05:16:27 -0000 Le 20/09/2017 à 02:51, JORDI PALET MARTINEZ a écrit : > I’ve deployed 464XLAT in cellular networks with SLAAC but also with > DHCPv6-PD using LTE “routers”. I would like to ask you which LTE modem was inside the LTE router? Because the Balong modem in some Huawei smartphones, and the some Qualcomm MDM8xxxx series in some IoT devices block DHCPv6 messages. Was the LTE network providing a DHCPv6-PD server? > Same for residential networks. Residential network is a different matter. The residential network I live on is not 464XLAT. And that has some users too. > I don’t think one or the other is relevant to the suggestion I’m > doing about reclassifying it as standard. Why? > If you do it with SLAAC, as described in the RFC, Jordi - one cant get a prefix with SLAAC. If there's some RFC saying the contrary then that's INFORMAITONAL and should stay that way. > the NAT46 will be stateful (by means of a previous NAT44) I guess we dont want either kind of NATx to be any form of StdsTrack. > because you > don’t have a specific /64 for the translation. Otherwise will be > stateless. > > The CLAT, which is the “client” side (run in a cellular phone or a > CPE or OS), is available in open source. Just look at the OpenWRT > implementation, but I’m sure there are others. OpenWRT is made for residential networks, not for cellular. For example, it has an 'odhcp' client very thin which is very good. But it takes time and effort to bring it to cellular modem. The modem is different in cellular vs residential gw. The size of devices is maybe an order of magnitutde different (think set-top-box vs matchbox). I am not sure which part of OpenWRT (a whole OS distribution) you mean for 'CLAT'. Is there some CLAT command line. Alex From nobody Tue Sep 19 22:26:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4CC132F2C for ; Tue, 19 Sep 2017 22:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SxbfrEL4uA4 for ; Tue, 19 Sep 2017 22:26:05 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B99126B71 for ; Tue, 19 Sep 2017 22:26:05 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8K5Q3Qw030653 for ; Wed, 20 Sep 2017 07:26:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A5976200ED2 for ; Wed, 20 Sep 2017 07:26:03 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 989A6204902 for ; Wed, 20 Sep 2017 07:26:03 +0200 (CEST) Received: from [132.166.84.27] ([132.166.84.27]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8K5Q26h018104 for ; Wed, 20 Sep 2017 07:26:03 +0200 To: v6ops@ietf.org References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <1B4AAE0F-0F5E-49F5-A35B-57F3372A11EB@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Wed, 20 Sep 2017 07:26:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1B4AAE0F-0F5E-49F5-A35B-57F3372A11EB@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 05:26:07 -0000 Le 20/09/2017 à 03:34, JORDI PALET MARTINEZ a écrit : > I think you may be right, it makes sense that a single /128 will be able to allow that, but I think it is clear that needs to be a different one that the CLAT WAN interface. I guess the authors indicated a separated /64 as it seems easier to allocate it than a single address if you’re using DHCPv6-PD. I was just recalling what is in the actual RFC: > > 6.3. IPv6 Prefix Handling > > There are two relevant IPv6 prefixes that the CLAT must be aware of. > > First, CLAT must know its own IPv6 prefixes. The CLAT should acquire > a /64 for the uplink interface, a /64 for all downlink interfaces Why does it say '/64'? Why not '/63'? > and a dedicated /64 prefix for the purpose of sending and receiving > statelessly translated packets. When a dedicated /64 prefix is not > available for translation from DHCPv6-PD [RFC3633], In cases where this is not available it's because it is a chicken and egg problem. Some modem manufacturers say that because IETF does recommend RA instead of DHCP then they stop forwarding DHCP through their modems. They wrongly understand what IETF recommends. We have to go through tedious emails among us in v6ops to explain what really the recommendation is with respect to DHCPv6 vs RA. Some operator say that because modems dont support then operator does not deploy DHCPv6-PD. Some people say that modem should not do any sort of IP related stuff, whereas the modem people say that's the only way they can build one modem able to connect to so many different cellular network (it's not only the frequencies and codecs that change but also the way they set up the connections). One should also know that at some point some modem did implement somehow correctly some DHCPv6 form of 'proxy', yet that became to block DHCPv6 altogether recently. > the CLAT may > perform NAT44 for all IPv4 LAN packets 'may'? Or MAY? Make NATx a StdsTrack? Alex > so that all the LAN-originated > IPv4 packets appear from a single IPv4 address and are then > statelessly translated to one interface IPv6 address that is claimed > by the CLAT via the Neighbor Discovery Protocol (NDP) and defended > with Duplicate Address Detection (DAD). > > Regards, > Jordi > > > -----Mensaje original----- > De: en nombre de David Schinazi > Responder a: > Fecha: martes, 19 de septiembre de 2017, 22:21 > Para: > CC: > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info > > > > On Sep 19, 2017, at 17:51, JORDI PALET MARTINEZ wrote: > > > > If you do it with SLAAC, as described in the RFC, the NAT46 will be stateful (by means of a previous NAT44) because you don’t have a specific /64 for the translation. Otherwise will be stateless. > > I don't think that's correct. In order to make 464XLAT stateless you need a separate /128, not /64. And SLAAC allows you to generate that extra /128. As far as I know, this is how Android works. > > As far the discussion of changing the Category of the RFC, I'm not sure what it accomplishes, and whether it's worth spending time on. > > David > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Sep 19 23:03:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5CD1331FF for ; Tue, 19 Sep 2017 23:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.504 X-Spam-Level: X-Spam-Status: No, score=0.504 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_MILLION=2.505, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 9qguQ1DLAMBn for ; Tue, 19 Sep 2017 23:03:47 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606AF1331F5 for ; Tue, 19 Sep 2017 23:03:47 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id g29so1184450wrg.11 for ; Tue, 19 Sep 2017 23:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zWJf0CeTGzuf8k44n5RYEocVmFv8hf4DlVXPI225b7E=; b=CBr+CZ7VzyurOrDRYJyjtVtsYlGhMK4EOaHOgSRzmg5Bq2wAb0d6Ep6eGWetmKm+/L jG2KmIA0sMabzmOaZMRpB2h1GFrg9ui07NlW4P/Y8AUvQbEAWYLhKqMl2gvbOWsbW7fb j1bDC4V+seYzXw8fbf40dg0dEuD5kZjsiHWSTz4jwcibDGejxi9tsa6uPenpSx5TVpfi rlSOSjAvB9IeRBWH1yVw8r7nlaOzGL94nYZKhQJ7XCdmFk5Gq6Gn3MYhAVKyWWApzb3q dxIqTJJ+spBIqMG+8LGfXP/Cfj8aFXT/01nJv5AxuM9OyPrLLuoKVWPb4w3/8NiBcWcF Ne9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zWJf0CeTGzuf8k44n5RYEocVmFv8hf4DlVXPI225b7E=; b=mCIUm6ICXWFFWmLz8fMSQV/36d+A74dPRyctViAg0tAxyK+sSNQHQA14l1PLTfTaR1 JEvCmMY8VsywYHh+9KX59eo6p6nlZOAIjCAnM/Kqq7VKeAG0EU/TsmxHkMy2v4+R/EBs wkBmxhYG/JFPT9w7XHrUGtMyYJdpMXwD6PxbbAOSzkewiQjRjURm4dQ9sYYpVnj58Hnv AreGa943865a5ilVCNkrYnzDOI5iGC32Wh96KoK1y1ltXLBwLcUomeoREuk0bilFdpCE 0jAA+acTAHdCCl766/Q4+TUY+5DZ+51gnCJUrZtZyP8zs4TmnVm+2U3k9KO4yBeNOULN Qjwg== X-Gm-Message-State: AHPjjUild1cRfeh/wpRNW83gLOLderHYHZeRBXjmyNUZPhvGpD3a5RaK bqpvv+x8Btlh/fK/4deb/Ey/+nwHiykUqUkU7beEwA== X-Google-Smtp-Source: AOwi7QD0WgDpdaogod/ipA6Y4/aRBUU7uGZCzSROPUbbhWyaBRLx1optcK+7m8+QdFyHSBiEflUwY+lmpHZXakKbbCs= X-Received: by 10.223.176.46 with SMTP id f43mr3594312wra.206.1505887425665; Tue, 19 Sep 2017 23:03:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Tue, 19 Sep 2017 23:03:24 -0700 (PDT) In-Reply-To: <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> From: Erik Kline Date: Wed, 20 Sep 2017 15:03:24 +0900 Message-ID: To: Alexandre Petrescu Cc: Fred Baker , "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11438d5a1a3d42055998bdb7" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 06:03:49 -0000 --001a11438d5a1a3d42055998bdb7 Content-Type: text/plain; charset="UTF-8" There seem to be some misconceptions flying around here. > Well, I dont think 464XLAT is deployed anywhere else than on cellular. These > are the big numbers that the Original Poster talked about: miliions of users > - they are on cellular. 464xlat is a client-side bit of code (the NAT64+DNS64 in the network is the "other half"). It is primarily implemented in mobile devices, and primarily in Android, to be more specific. As such, the number of 464xlat capable nodes is numbered in the /billions/. There are also some wifi (and wired) networks that are IPv6-only with NAT64+DNS64; mobile networks aren't the only ones. NAT64+DNS64 is easily the single most successful IPv6 transition technology on the planet ([a] if one excludes "dualstack", [b] queue the Sean Spicer jokes). 464xlat can help ease things on the client side, but it's not the only way to do it (cf. iOS). --001a11438d5a1a3d42055998bdb7 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgb5UzM1D4FP1cG2VhgaivUH5ZEqUD5Pdj DDHf5e4xxk4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTIw MDYwMzQ2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAE0ia+/OgyA2OxKcOW+TL4BUksFZnSwCfcTe6aC/da14jYLC+l6h aDANeQd4FTGcgY/lCikbTZdg4GQsoOINqZ5zDw2CCuZmThxdBGMAmR3endnTk+4a1X9srZZxdiiy VptSaDsABTuRG+N1cXzG6RBacBUkWnBdvWJwC0tmDFtFcpfpLETKk8RAgupIgjAX3Beuxxzo96rp D1espeWRcVa4srEK71oHovxaJuQacvK0DfnQrjsX8QZfzzrsOdXvxkowT6dhUKrSd1qZw28fCls7 32vBWqtMHGuLvbhZ9WvG0161QgC4ADObQizLp5LGzSV/iu8Ty4ErLjz9LU7ZWzk= --001a11438d5a1a3d42055998bdb7-- From nobody Wed Sep 20 02:43:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BFC1342E6 for ; Wed, 20 Sep 2017 02:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATu_4XDS2GP4 for ; Wed, 20 Sep 2017 02:43:35 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40121.outbound.protection.outlook.com [40.107.4.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17279133323 for ; Wed, 20 Sep 2017 02:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a0WC4PXTtFukCO4bpeTjINBFUTrv2A+VC6uuPXoFC5o=; b=HShKGdr9dESfePlPnJMbI57t2Bc+GshuLcb92II2wGxbCmV2Z3+gZaM4m6tnAuq7OxF3nwRSZ9/rJwYzGb2su/CHgEifnzTGISVrcjkRe9PN/uJ7yCFRBWPbrOHRWrVwbZ0hcUbIjXjBGYVlXu64Omp1RvYnTArTg5YhvlbXDxw= Received: from pc6 (109.146.128.123) by HE1PR0701MB3001.eurprd07.prod.outlook.com (2603:10a6:3:4d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 20 Sep 2017 09:43:32 +0000 Message-ID: <021e01d331f4$b1444920$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Fred Baker" , "JORDI PALET MARTINEZ" Cc: References: Date: Wed, 20 Sep 2017 10:41:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.146.128.123] X-ClientProxiedBy: AM5P194CA0021.EURP194.PROD.OUTLOOK.COM (2603:10a6:203:8f::31) To HE1PR0701MB3001.eurprd07.prod.outlook.com (2603:10a6:3:4d::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 56807761-7d41-4b58-6ace-08d5000c0eba X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB3001; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 3:0v06KmRM7s1DEoSn946hvWVPMoaeeIyf4yC0BJsAbQZP3eZ67Ym0Pj9//CX0hmz+o1lkPFTtERP2QvcU8gC3DwV6fHIirukdfdRQgUKgwHdokJcgCEI6UOs5THAJxSD1AWXZIAeZNO/ED+1CM+cGXqXy5hKBytSJm+w+qRF4bRhz9pAcu1qB8uCa7KJtGLuxXnDkUa6qlBm78yF6syi8eLITV/rkVTzNxFdU/xJ6b9sIcBBePKbeQQMhC8F827b+; 25:zD19QuTbLcxaGblCU+GDVfaUnTggv3fOLXRZ/FX6DFs3KkUaw+RptHvNrrHqSyolapNygc8BW/mLdmBIzHOghX3gFn2KR7U7R8TI/n1icdK68D7lpbGFh5Kj08/mdAFokjWcVD3++gsFo2SkVg27jqal3B2A/yStyjTmYiyAESGHPzkXTapfO16TSom10/jM5eKjO1RyoTZSWKqleZQ7samCkLYRKITYG1gv1p9a4QaaiTuNdxTF56i68kCWBNN3J5MrjOxv+/c9n5rm9HkYWLNyil1/0LJh0DlxVEQoYnL7IlI7h0sHNDLjjCVVxgEI7RNO4ggi1Jq+FxMnpP3Yrw==; 31:2AbEHrAs+XM5BvrkGRNUfVkjm4pY/9E17EZie4nQQk2wVWOz/bvuYkufuhPDLEFf8TN87gHWdw61XaauQ5wp5pHNlKDA4aD3Z4PBwGEnXe+QubQ0gb5dk4zsLk4Lzvqq73AUMAJXlld3tsNVnu4lJ8QoyTKcT2XhSj8fH67tJCbJVDX6WAB6sW8O6/qMc+o+E0inh1bnkChOI8WiuGzuSAAX6IDSupXsAS6tK2Kwzvk= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3001: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 20:vXXmRtG/rEL8RF6aUxZr0I/3GRLAxzxH6jc64m2+Xn0bwh0f0GCxD5t953g8LakLheuj5o3HhtdpWVssI19rYx/q9kg5Hf3Tha2zS47jmbP/GdcZ3BH0iR6xlo+LZmL2LCgPpEQShY01ZRUswKRxjxw8GCXhkUqKpRsoRomWMXMy7+cGs1nXZ4gqg9lWbPGHBHdsfGEa1IcHl5YiiAeGnTnhVgxYil0V8pU9rg/S8+FJlsPgDtFeTOVKSvPTTkwKTL+e7DkYJ7P0DVlySi/opcOEehxJeQkUSvnPyzPTS7ZEwo7ESQvWJ5R3r+yUqZ6Nk+07PLRc1mgGWiaHI1OORg==; 4:1YPCvoVUlUWxY8FP20ob9KBVtVuNU9S5oxIa8TLdQlF5joyxlUpA3wnb9rCMBtwWIH47qkkD0iMemv601KNiFAkIDJPE9CPO/DiWoJO9/MlNWb9PpyRCiIh4I8U7aFt3A0RFuriurciylqTNVw7ZBuqhdqTCS5d1ARyY2/4dKC2Hg1H9cEDlaFiaW/A+B7iXWgk5iles8kLWOjNWmSzxD7cvOQ/RtQpnhCG82Jqmm2iDr8LOxE50Ep66YU8r+xFo X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(61426038)(61427038)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3001; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3001; X-Forefront-PRVS: 04362AC73B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(13464003)(377454003)(53754006)(24454002)(199003)(189002)(86362001)(189998001)(4720700003)(478600001)(9686003)(23676002)(66066001)(101416001)(6486002)(44736005)(62236002)(44716002)(6306002)(47776003)(81166006)(8936002)(50986999)(2906002)(8676002)(81686999)(81156014)(76176999)(110136005)(81816999)(16526017)(966005)(6116002)(14496001)(1556002)(316002)(5890100001)(1456003)(3846002)(97736004)(84392002)(229853002)(53546010)(5660300001)(50466002)(53936002)(7736002)(305945005)(53386004)(61296003)(25786009)(6496005)(39060400002)(68736007)(6246003)(4326008)(50226002)(2870700001)(33646002)(116806002)(106356001)(105586002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3001; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDE7MjM6NVh3bDZkdmRWQ3c4ZlVLMkg0MU5HQmNy?= =?utf-8?B?RlVYWTlXYk9SUHIrOEo2d05VbWVZUWVhM1ZQN2xqSyt0VGJNQnMxL09hdVh5?= =?utf-8?B?ZXUydFNMWXkyV2R3NmNOais1aXlMdGwwZXhYYWtiQUhvTVFVaGpTaDB0cW5z?= =?utf-8?B?Qmh2TzJ1OG9aREVOelVvVGhQMGxBRGwxdlRET3VaVzcybEpVNEFBK3BsVkgx?= =?utf-8?B?MEZ5YVUzaVEvejF4cFAxM3VvWmVZQndHbXhkcDljb1NIdVZPOWlxUjlxU05z?= =?utf-8?B?MHdlT1lVNFc4QzROZWNPOElqeVh2anZkRXV6TGJEeDI5WWJkdW8wZlB5WXhl?= =?utf-8?B?NEhCemhYMXo0b2VtTElMZU1uc2tqbW9hVEZQWktqZDNMaEtFSnhFRnpDRW9P?= =?utf-8?B?V0dwcHJEeUtldnR1ckxLVlFYR25xQ3l2WlR3WVc0dlFQcGdaZWpVeTFSdkR2?= =?utf-8?B?SGdmdEFqWnlyZWV3dW55bUJpbFZJTlcxeEFrS3VFMjc2OEtJT1c0NHcrbFM4?= =?utf-8?B?L1BTeEZnVTJYUHpHQkkxTmZjK2xUZTJObnpmcGFSdVFWcVJZOFhxejVnbTRu?= =?utf-8?B?aTBpTmI0alFwZE9xKzlGZFYwL2hmTS9UWXRKZlJkemJiNG9WRWI3WjNFTHpE?= =?utf-8?B?V2lvdCtyK1F4dDBiblA1dU5KRHIzOTRlMW9tU2FLNGtuVkpnTmFQN3FPamY1?= =?utf-8?B?aWltb2FnV1pVeldUV0pqZnpsYTE3eFhFNk5NZzF1R1VqbnZhU2cvbEY1RTll?= =?utf-8?B?SjJBTW5aVS9ocnVVTjRmMW9VRTZESW1NSGg1SFR1UnNzUzcwU0NBNUtNK2dD?= =?utf-8?B?ZTdLUTFuTE1CSWh1LzY5ZFliY3czK1BWT052NERHMGwrOEE1VXhuTWZNcElV?= =?utf-8?B?UUExU0pOOXU0TXFtTjc5T2NtRFAzT0hVQzBieE9Dam1jSXVackxlUDEveW4v?= =?utf-8?B?bTFQZGgraDRrN2xRWWVvOXA1SFVESnJGa2NVZTFmbEdlVjNkQlFZa3JPdUdz?= =?utf-8?B?d3MxVENIcVplZmgxa3dGUmZUUk55VDJzUHQyZnNZS2hKTlJ5WUJjMUczdm9u?= =?utf-8?B?NHo3Qk9mVHo5THVucEdFQ1QyRUhDU1ZJVGlpdDEyTGlWaWs2Vm9ZTElJczd1?= =?utf-8?B?MXJVNzducHF3MGc3RU41ZVJqY0w2RjdJSkNmbG5SYms0Z1J1UlQrckZZMmg4?= =?utf-8?B?RWJRcDJXcWNOWm56Ukl0T0k0UlNOalhVakdxQ0M4WFVqUE5wOTh6RE1temYv?= =?utf-8?B?bnNvZXAxRDk4ODNSYk5YYlA3WlFhaWE0QnI3QWhlNy9hNlZQdTdPamI1Rzd6?= =?utf-8?B?SXlGZjZ1djV3bnpWcVg5TFdmSFU2WFM0WU5zSUo0eS9pVnErekg3Y0U1NzJV?= =?utf-8?B?Ui9DMDQ1Z3FUUXJwM1pHN04xUzcxSTRHeW5neXVmYlNjdlZhbGEzNHVjcXBF?= =?utf-8?B?WGdhMGxXNm9zV3JUS1M0ZGMxUy9vc0s2cmptL2RleW40dWc0bTdHbHgrOXM4?= =?utf-8?B?WXg5dmQxUExPa1pmb2VOUnJncXRKV2lHODRWNWpYZ29uRCtpZ0hCVXVVTXdk?= =?utf-8?B?QU1uNy82Z3JBTXRhR1dBaGtIMnQzc3kyc1lNMWRMTWFBTFc1S1k5aUVZYzJr?= =?utf-8?B?blQwMUVJOElqdmFNaWJjQWgvamp3bkRGa2NIWDZMZ3M0TldvNXUxdkgyWG05?= =?utf-8?B?Vy9mYW8zaGtuaHhxQ3BPYXptckoycjBVYkxrRnFsNHhKSGx6U01YdE1FQUVi?= =?utf-8?B?T3NOa0djS3RDWHdJenJudzJ1ZHVuSDh6cHowV3IrdU1LdlhlR2laMjY5ZHRS?= =?utf-8?B?Qk81MGdhOVVsT3BhYzFpMzJzOHkzaXRhRW5tTkRxUERCSzJPK0hhUlJPSFJk?= =?utf-8?B?WWg2Ujc1UTRZSGx5L1RNVktKdWVrdlJUM1BOdGNXRkxsL0pYS2ljYWo3OCtO?= =?utf-8?B?N2drWGVCZElVM0hsZFZ6RDlaMkwvY280UzNUNXkyeHp6OTJreUFKQTN3NC9B?= =?utf-8?B?S1FxbFJvZTNWUWVVMkI3TXBEUnNYU2orNkNPOEdGZEkrNWUxNFhSdXpIVzJi?= =?utf-8?B?Y3BwbG50NklYTVphejBZV3BRZzc1eG9pZzNIdGxEcnpIUzN6QzJ4emphMDhC?= =?utf-8?B?bGtzUT09?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3001; 6:jgH5+M5qzCI6YW9Eg8I77mU5uFqwpeGzL5mvCfZ9ITSFW7ZpGtvtpMdJWY2PYB8sjv+uJe3S4yfKwoqyShpxnlSpVRJ1Gwq6YVuJKsZZGnRt63+GNN0W8q+mVGGy89mn38RuqpUlZUGILUj1hknz7JeGEWj8c5Z9vrWtQSqEvi4OhpyVLkw/p6PYohygINIv/iDdlIy9kntACpcC644RFs2msPVzGxO0vvZDkF6ymJwD0wOqoTuurUysAcMdcZuEqGnUDOaiDVsoTEgLvdjRfLYO/nMbNfArm5cjdwRV/CboBb63ex6GZbb1PvY0CIWWq7gf+nLLBmXR8B1AB0YaWg==; 5:73TOODvEJM5e73ps3wlsLyZY3nsCrq41crdpAx/dSvM3Yy6xLtBMdhnPLSzy+q4K0m7uNpys+KkdK1miBuwICjnUo9WN5DdhG0oUZpLl9RdCP0t+TJpMUSGPKb9ngqKvcM9XeR8UG69L6t935w5sRA==; 24:705cTPuVGbjfz1td++6kSdMcM1eSARvYw1Zwz0dC1vIizxWSFROqmbeASlmDq3n3Bpx6GYuuItBPBWCOOQGpIWj9Hyv5UG96S3yYn5zUybQ=; 7:UO0876M4/AaCGGNWT06MQclx2aTteIVUOfb9VEo7RKBaUYiA9jS4xV/ZShh/vq2QYFzJ1hz2PoJNjcQ40JfHK1JGW3Q9dXSZU3ecLv38BR6me151cz+TU76S2D52hqq2D5EUIEsTbrDhuLz506nh9qZ/5sfgNJJZeNNrKP4/im+YF7wA6R4/OiCh9p/0mo/No7LSFupM4N1u1UFztpZaVxMK22O6OJGI3boN//Waxmg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Sep 2017 09:43:32.4811 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3001 Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 09:43:38 -0000 ----- Original Message ----- From: "Fred Baker" To: "JORDI PALET MARTINEZ" Cc: Sent: Tuesday, September 19, 2017 9:27 PM > Hmm. Wearing the chair hat, but not making pronouncements. Thinking through the options and considerations. Fred What was the final resolution of the IPR claim by China Mobile relating to this work that caused much bemusement at the time of the approval thereof and which also may have been a factor in changing the status from BCP to Informational? Tom Petch > > Some reading matter: > https://tools.ietf.org/html/rfc2026#section-5 > https://tools.ietf.org/html/rfc6410 > RFC 2026 section 4 as updated by 6410. > > https://tools.ietf.org/html/rfc6782 > https://tools.ietf.org/html/rfc7269 > https://tools.ietf.org/html/rfc7335 > https://tools.ietf.org/html/rfc7445 > https://tools.ietf.org/html/rfc7849 > https://tools.ietf.org/html/rfc7934 > > I would agree that informational status is probably inappropriate at this point. I'll note that the progression is not all that unusual; GRE, for example, was originally informational (RFC 1701), was taken to Proposed Standard in RFC 2784, and has been updated by RFC 2890. If it were taken to Internet Standard, we would need to demonstrate the points raised in https://tools.ietf.org/html/rfc6410#section-2.2. > > What gives me pause in using the PS/IS standards track is the issue of interoperation of multiple implementations. I'm not entirely sure what that means in an operational procedure or service, which is in my perception what 464XLAT is. If that is the interoperation of multiple networks, it might be the interoperation of an IPv6-only (subset of a) network with other IPv4 networks, as the interoperation of that same network with IPv6 networks or networks with IPv6 capabilities doesn't require such services. The description of a BCP in RFC 2026 sounds more like what we're looking at here. > > My thought at the moment (which I can be argued out of) is that the right status is BCP, and that we would want an updated document that captures anything we have learned since RFC 6877 was published. > > > On Sep 19, 2017, at 5:23 AM, JORDI PALET MARTINEZ wrote: > > > > Hi all, > > > > RFC6877 (464XLAT) is an informational document. > > > > However, this transition mechanism is the one that has a bigger deployment in terms of number of subscribers using it (hundreds of millions), which I think is even more than ALL the other transition mechanism together. > > > > Doesn’t make any sense, in my opinion to keep it as an informational document, while we have many others that are standards track and don’t have such level of deployment. > > > > I was commenting this last week with a couple of the co-authors of this document, and they have the same opinion. > > > > So, should we aim to do this? > > > > Can we even consider moving it to STD? > > > > Regards, > > Jordi > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 20 05:55:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB78132939 for ; Wed, 20 Sep 2017 05:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FUZZY_MILLION=2.505, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzdIykLkuKZk for ; Wed, 20 Sep 2017 05:55:02 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1069C1321C7 for ; Wed, 20 Sep 2017 05:55:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8KCsxKZ029291; Wed, 20 Sep 2017 14:54:59 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7030220793D; Wed, 20 Sep 2017 14:54:59 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 60C9E2018A3; Wed, 20 Sep 2017 14:54:59 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8KCsxgH003716; Wed, 20 Sep 2017 14:54:59 +0200 To: Erik Kline Cc: Fred Baker , "v6ops@ietf.org" References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 20 Sep 2017 14:54:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 12:55:03 -0000 No need to stress terms like billions; that's what modem manufacturers put on the market too routinely. Maybe we can talk trillions of IoT devices. Maybe we can use the SI prefixes, like exa, or peta. That aside, I would like to ask you whether the CLAT src on Android is something I could look at? Alex Le 20/09/2017 à 08:03, Erik Kline a écrit : > There seem to be some misconceptions flying around here. > >> Well, I dont think 464XLAT is deployed anywhere else than on cellular. These >> are the big numbers that the Original Poster talked about: miliions of users >> - they are on cellular. > > 464xlat is a client-side bit of code (the NAT64+DNS64 in the network > is the "other half"). It is primarily implemented in mobile devices, > and primarily in Android, to be more specific. > > As such, the number of 464xlat capable nodes is numbered in the /billions/. > > There are also some wifi (and wired) networks that are IPv6-only with > NAT64+DNS64; mobile networks aren't the only ones. > > NAT64+DNS64 is easily the single most successful IPv6 transition > technology on the planet ([a] if one excludes "dualstack", [b] queue > the Sean Spicer jokes). 464xlat can help ease things on the client > side, but it's not the only way to do it (cf. iOS). > From nobody Wed Sep 20 06:17:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042AA13214D for ; Wed, 20 Sep 2017 06:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.504 X-Spam-Level: X-Spam-Status: No, score=0.504 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_MILLION=2.505, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wxnlr3SCq7Pv for ; Wed, 20 Sep 2017 06:17:52 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512D51331E7 for ; Wed, 20 Sep 2017 06:17:52 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id l22so2154598wrc.10 for ; Wed, 20 Sep 2017 06:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vx0OhNEFlBUmYR3wUHBZoiUYgGD/BeOkXSsuZm7AVvA=; b=tVOY5rz0LIAUAHOyO3QyVFJbbtJWOOQzw32qH2vBBfgX1fxOQlinxttSpWcwAuvZVj NrJTndyaHQU1MHi5KGBvMWll0/bpdRIoETAVu2NeQRMjBXKfmPo1p7nRLPNZBG8JUjEw Bu86gtXBuLJg3NKARNK7ZdIwtAY4Ml8Kcqi6DQDCHmvONpeLSImL0FhQoxGtJxEJYHSq xfwVAEgsJI7KJSV7nXyQRSeDgU/FD2Rsjkl7LflrJJ1kikELQiI3I+RYc46uwMfCh6ay W651ozGrlac04sZcx6gMCzoCOzNz3hYaKipjUUfLGk7ocFJnvK6nkzQlLjKjFT9swVpf dsEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vx0OhNEFlBUmYR3wUHBZoiUYgGD/BeOkXSsuZm7AVvA=; b=MD2UI+jGatGy1xUQD0QIeFMq9afsOIpBChAebcnzshQRgC93qY+x0p6PX2ip1X4bFN p6JCSe08n0k8B1LJOVZqusvLfYT/JbrylQ4CeIxh1XRSnHEFdvCDo1QVhBk0MfmJOaTx iduzpnpwYpIyGHgckXwPndbsiMmeKHXfxEs35oCxyk7oIVl2Ggyt/AvSZDj97rbCx58m 1Rrk2xaYM/Mq2z9Y6Yj0nfY2Q397a/6ieshNeyHep6Rrltaw5E7pu6zeAM17E8MmCWfz U6n6XcQM3VptVT5bQFttKIVCegPER/lyisjlrWWNSWpfsI9BAGMddooJoL9PH/90qGk4 g04w== X-Gm-Message-State: AHPjjUhFWoqjPkAaKAAB0h3Be9I8x51B+1Nzw5zAOKIkQ7VdgjaHKqvG vicf+4IgJwavZ3/J73gsYjh+1uXsmczRylxn0zkmiA== X-Google-Smtp-Source: AOwi7QB2225gAUG0En0KV0pT/+cMpwsdnN04+bUWqUSH673b+E+/F2jhi+rU09jrPfiaOrFx3BCQyi3e7s1KsXiyOIE= X-Received: by 10.223.176.46 with SMTP id f43mr4847113wra.206.1505913470401; Wed, 20 Sep 2017 06:17:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Wed, 20 Sep 2017 06:17:29 -0700 (PDT) In-Reply-To: References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> From: Erik Kline Date: Wed, 20 Sep 2017 22:17:29 +0900 Message-ID: To: Alexandre Petrescu Cc: Fred Baker , "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11438d5a80407705599ecdb6" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 13:17:54 -0000 --001a11438d5a80407705599ecdb6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://android.googlesource.com/platform/external/android-clat/ On 20 September 2017 at 21:54, Alexandre Petrescu wrote: > No need to stress terms like billions; that's what modem manufacturers pu= t > on the market too routinely. Maybe we can talk trillions of IoT devices. > Maybe we can use the SI prefixes, like exa, or peta. > > That aside, I would like to ask you whether the CLAT src on Android is > something I could look at? > > Alex > > > Le 20/09/2017 =C3=A0 08:03, Erik Kline a =C3=A9crit : >> >> There seem to be some misconceptions flying around here. >> >>> Well, I dont think 464XLAT is deployed anywhere else than on cellular. >>> These >>> are the big numbers that the Original Poster talked about: miliions of >>> users >>> - they are on cellular. >> >> >> 464xlat is a client-side bit of code (the NAT64+DNS64 in the network >> is the "other half"). It is primarily implemented in mobile devices, >> and primarily in Android, to be more specific. >> >> As such, the number of 464xlat capable nodes is numbered in the >> /billions/. >> >> There are also some wifi (and wired) networks that are IPv6-only with >> NAT64+DNS64; mobile networks aren't the only ones. >> >> NAT64+DNS64 is easily the single most successful IPv6 transition >> technology on the planet ([a] if one excludes "dualstack", [b] queue >> the Sean Spicer jokes). 464xlat can help ease things on the client >> side, but it's not the only way to do it (cf. iOS). >> > --001a11438d5a80407705599ecdb6 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgihEvUb6qNR5vf7hKYpBrkLe/Hs5QU2Cm FbS9uc1+5xUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTIw MTMxNzUwWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBACQQcwXou/5AA08Npt2kxC9KSRzfF/K53671jHe8HO518oZjyzMG VS5HQyyT+CAhHAB6FJE2YeFKVMf9McqklMHDFzC1j+Nk3ojDvHsTPkYenog4LrPwiBK8T9doDl3O CyXlYfPDkJdiC+8Q9919HHYUDqYEhBckuRd6d7fyzn6NaHDpUAUvv6fjX0qhqg6Emw2SQBPy7BjY XRhaPxWlCGGbHSB/BuUpe97JRd6RjDEKyAdydNJWL0925mh09RH36mOKtzDQ9X3RiIYakWL47/sl fjLVudk+H48qg+qfqU9T1Xfc4lMU4O2Pol9U+eRRCJ9vYFFMFn3wjLlmNx+jmcI= --001a11438d5a80407705599ecdb6-- From nobody Wed Sep 20 06:19:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31851331E7 for ; Wed, 20 Sep 2017 06:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.505 X-Spam-Level: X-Spam-Status: No, score=0.505 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_MILLION=2.505] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqIsAvmD3fvd for ; Wed, 20 Sep 2017 06:19:27 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73C0133205 for ; Wed, 20 Sep 2017 06:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505913563; x=1506518363; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=aicoEcOxQfjsUWK84W2FJc0sS hAvAlvYSzZhNp/gaUc=; b=nbayvvKXJzM5W+q8jf4yxmWAcI6w5LmhMO8TcNSEM GMT85uj3z8MkKAoEvnkEY8xmzuh/RPulinjWRsjq1XE5wyh3CE2tOdT99aE3ElVZ CnrWKmUR495WK8r32GBb1x4CbWavkWwTu8+77yRavu9DRYoL3GprGPLGobA1uqV3 Fk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=lWbnBFyMT6hw1JwdhxqWDsbgGmu83UIk8tDsCgIw6qO1kzLvyJET23EBbXTE 8lgNtVGI1uH+XqoNQ/nNyh2xyZQcfqT1r0eSad9eAQ/0AL1JAoqHb3pKO jGdTG9DizeKaleM3ZyZ/LI1jOuMaGAQFBKl7k5YHcdSphV08Z33tHE=; X-MDAV-Processed: mail.consulintel.es, Wed, 20 Sep 2017 15:19:23 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 20 Sep 2017 15:19:22 +0200 Received: from [45.6.249.104] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005561232.msg for ; Wed, 20 Sep 2017 15:19:22 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170920:md50005561232::PCitZ0uOJVSUw6Lu:00006CEh X-Return-Path: prvs=143688d48d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Wed, 20 Sep 2017 10:19:15 -0300 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es X-Spam-Prev-Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info Archived-At: Subject: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 13:19:28 -0000 Google is your friend: https://android.googlesource.com/platform/external/android-clat/ Same for other questions that you asked before =E2=80=A6 you can find it al= so for OpenWRT. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: mi=C3=A9rcoles, 20 de septiembre de 2017, 9:55 Para: Erik Kline CC: "v6ops@ietf.org" Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info No need to stress terms like billions; that's what modem manufacturers= =20 put on the market too routinely. Maybe we can talk trillions of IoT=20 devices. Maybe we can use the SI prefixes, like exa, or peta. =20 That aside, I would like to ask you whether the CLAT src on Android is= =20 something I could look at? =20 Alex =20 Le 20/09/2017 =C3=A0 08:03, Erik Kline a =C3=A9crit : > There seem to be some misconceptions flying around here. >=20 >> Well, I dont think 464XLAT is deployed anywhere else than on cellula= r. These >> are the big numbers that the Original Poster talked about: miliions = of users >> - they are on cellular. >=20 > 464xlat is a client-side bit of code (the NAT64+DNS64 in the network > is the "other half"). It is primarily implemented in mobile devices, > and primarily in Android, to be more specific. >=20 > As such, the number of 464xlat capable nodes is numbered in the /bill= ions/. >=20 > There are also some wifi (and wired) networks that are IPv6-only with > NAT64+DNS64; mobile networks aren't the only ones. >=20 > NAT64+DNS64 is easily the single most successful IPv6 transition > technology on the planet ([a] if one excludes "dualstack", [b] queue > the Sean Spicer jokes). 464xlat can help ease things on the client > side, but it's not the only way to do it (cf. iOS). >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Sep 20 06:28:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070C0134217 for ; Wed, 20 Sep 2017 06:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FUZZY_MILLION=2.505, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iL1XFnY08eP5 for ; Wed, 20 Sep 2017 06:28:09 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69B713214D for ; Wed, 20 Sep 2017 06:28:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8KDS7VZ036229 for ; Wed, 20 Sep 2017 15:28:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 02288207B23 for ; Wed, 20 Sep 2017 15:28:07 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EB1AF207ADD for ; Wed, 20 Sep 2017 15:28:06 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8KDS58T007340 for ; Wed, 20 Sep 2017 15:28:06 +0200 To: v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> From: Alexandre Petrescu Message-ID: <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> Date: Wed, 20 Sep 2017 15:28:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 13:28:11 -0000 Le 20/09/2017 à 15:19, JORDI PALET MARTINEZ a écrit : > Google is your friend: > > https://android.googlesource.com/platform/external/android-clat/ Google is my friend. Ctrl-F also, and that page does not seem to display any correction that says "DHCP" in the last 3 and a half years. But I think CLAT should run DHCP somehow, otherwise it's a non standard way to get Prefix Delegation. Does it? (I may download it later and look at it). As long as these two things stay distinct they are in competition. Once you make 464XLAT StdsTrack you cant also keep DHCPv6-PD as StdsTrack - they are on the same layer. But yes, you can keep XMPP on the StdsTrack, because it's on another layer. Alex > > Same for other questions that you asked before … you can find it also for OpenWRT. > > Regards, > Jordi > > > -----Mensaje original----- > De: v6ops en nombre de Alexandre Petrescu > Responder a: > Fecha: miércoles, 20 de septiembre de 2017, 9:55 > Para: Erik Kline > CC: "v6ops@ietf.org" > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info > > No need to stress terms like billions; that's what modem manufacturers > put on the market too routinely. Maybe we can talk trillions of IoT > devices. Maybe we can use the SI prefixes, like exa, or peta. > > That aside, I would like to ask you whether the CLAT src on Android is > something I could look at? > > Alex > > Le 20/09/2017 à 08:03, Erik Kline a écrit : > > There seem to be some misconceptions flying around here. > > > >> Well, I dont think 464XLAT is deployed anywhere else than on cellular. These > >> are the big numbers that the Original Poster talked about: miliions of users > >> - they are on cellular. > > > > 464xlat is a client-side bit of code (the NAT64+DNS64 in the network > > is the "other half"). It is primarily implemented in mobile devices, > > and primarily in Android, to be more specific. > > > > As such, the number of 464xlat capable nodes is numbered in the /billions/. > > > > There are also some wifi (and wired) networks that are IPv6-only with > > NAT64+DNS64; mobile networks aren't the only ones. > > > > NAT64+DNS64 is easily the single most successful IPv6 transition > > technology on the planet ([a] if one excludes "dualstack", [b] queue > > the Sean Spicer jokes). 464xlat can help ease things on the client > > side, but it's not the only way to do it (cf. iOS). > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 20 06:34:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5153313214D for ; Wed, 20 Sep 2017 06:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FUZZY_MILLION=2.505, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRqthAUBFd9M for ; Wed, 20 Sep 2017 06:34:23 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87031133205 for ; Wed, 20 Sep 2017 06:34:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8KDYLYU038905 for ; Wed, 20 Sep 2017 15:34:22 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E80CC207B55 for ; Wed, 20 Sep 2017 15:34:21 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DDFC3207B23 for ; Wed, 20 Sep 2017 15:34:21 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8KDYKfp013606 for ; Wed, 20 Sep 2017 15:34:21 +0200 To: v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Wed, 20 Sep 2017 15:34:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 13:34:25 -0000 Le 20/09/2017 à 15:19, JORDI PALET MARTINEZ a écrit : > Google is your friend: > > https://android.googlesource.com/platform/external/android-clat/ > > Same for other questions that you asked before … you can find it also for OpenWRT. Jordi, please let me ask again: I would like to ask you which LTE modem was inside the LTE router? Because the Balong modem in some Huawei smartphones, and some Qualcomm MDM8xxxx series in some IoT devices block DHCPv6 messages. OpenWRT is an OS, not a modem. An OS runs on many kinds of modems. Some modems block DHCP altogether. You cant just redirect me to OpenWRT. Alex > > Regards, > Jordi > > > -----Mensaje original----- > De: v6ops en nombre de Alexandre Petrescu > Responder a: > Fecha: miércoles, 20 de septiembre de 2017, 9:55 > Para: Erik Kline > CC: "v6ops@ietf.org" > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info > > No need to stress terms like billions; that's what modem manufacturers > put on the market too routinely. Maybe we can talk trillions of IoT > devices. Maybe we can use the SI prefixes, like exa, or peta. > > That aside, I would like to ask you whether the CLAT src on Android is > something I could look at? > > Alex > > Le 20/09/2017 à 08:03, Erik Kline a écrit : > > There seem to be some misconceptions flying around here. > > > >> Well, I dont think 464XLAT is deployed anywhere else than on cellular. These > >> are the big numbers that the Original Poster talked about: miliions of users > >> - they are on cellular. > > > > 464xlat is a client-side bit of code (the NAT64+DNS64 in the network > > is the "other half"). It is primarily implemented in mobile devices, > > and primarily in Android, to be more specific. > > > > As such, the number of 464xlat capable nodes is numbered in the /billions/. > > > > There are also some wifi (and wired) networks that are IPv6-only with > > NAT64+DNS64; mobile networks aren't the only ones. > > > > NAT64+DNS64 is easily the single most successful IPv6 transition > > technology on the planet ([a] if one excludes "dualstack", [b] queue > > the Sean Spicer jokes). 464xlat can help ease things on the client > > side, but it's not the only way to do it (cf. iOS). > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 20 06:35:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D240F133074 for ; Wed, 20 Sep 2017 06:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.505 X-Spam-Level: X-Spam-Status: No, score=0.505 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_MILLION=2.505] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cOO_wgGo7TQ for ; Wed, 20 Sep 2017 06:35:29 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4896F134222 for ; Wed, 20 Sep 2017 06:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505914525; x=1506519325; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=tKNG2LruXIa5y2+11jkXHi7eO rcorS2kyupRpLHZ8yU=; b=VVMXq56ZHtlQOSgbVm27t0Z4xjXeB8J4TclUY3lV9 aZSoOdZa39Jgg3cVSGnRKGjJcqBEzbxJPS6Uby4W3J24mG7q8rzCAIG8ZQI9bavh lutLMN5JzbQiRObTRmhIuEOJzVeM4vCQxFiwR5RsAq5F6/bDDYIoFQAEojNvbgG6 gM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=WCk2j7JFTnAHXDhbR1fUdFCz+LnrYIWQaNwX+wJTPCBkGGUg23zr8BeU2Jmw FY2Co3pINS9a8n600sYvQYiEzxaRT0hTNKx/K/X6PPDnqgaePAnr5YYQA 3EtZhpBg5bLsiRq/EQ1s+Rd0gX45KLO1veZmg/A+PTxbStOusO+SqQ=; X-MDAV-Processed: mail.consulintel.es, Wed, 20 Sep 2017 15:35:25 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 20 Sep 2017 15:35:24 +0200 Received: from [45.6.249.104] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005561247.msg for ; Wed, 20 Sep 2017 15:35:24 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170920:md50005561247::P4M53ViBIIptzY8L:00003PQR X-Return-Path: prvs=143688d48d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Wed, 20 Sep 2017 10:35:21 -0300 From: JORDI PALET MARTINEZ To: Message-ID: <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> Thread-Topic: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> In-Reply-To: <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es X-Spam-Prev-Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as Archived-At: Subject: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 13:35:32 -0000 Why you try to mix things? CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a way to provision= addresses/prefixes. No sense to mix all them. Many other transition mechanisms don=E2=80=99t state if SLAAC or DHCPv6 is = used or not, and I think is perfectly correct. Regarsd, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: mi=C3=A9rcoles, 20 de septiembre de 2017, 10:28 Para: Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as s= tandard instead of info =20 =20 Le 20/09/2017 =C3=A0 15:19, JORDI PALET MARTINEZ a =C3=A9crit : > Google is your friend: >=20 > https://android.googlesource.com/platform/external/android-clat/ =20 Google is my friend. =20 Ctrl-F also, and that page does not seem to display any correction that= =20 says "DHCP" in the last 3 and a half years. =20 But I think CLAT should run DHCP somehow, otherwise it's a non standard= =20 way to get Prefix Delegation. Does it? (I may download it later and= =20 look at it). =20 As long as these two things stay distinct they are in competition. =20 Once you make 464XLAT StdsTrack you cant also keep DHCPv6-PD as=20 StdsTrack - they are on the same layer. =20 But yes, you can keep XMPP on the StdsTrack, because it's on another la= yer. =20 Alex =20 >=20 > Same for other questions that you asked before =E2=80=A6 you can find= it also for OpenWRT. >=20 > Regards, > Jordi > =20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Alexandre Petrescu > Responder a: > Fecha: mi=C3=A9rcoles, 20 de septiembre de 2017, 9:55 > Para: Erik Kline > CC: "v6ops@ietf.org" > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info >=20 > No need to stress terms like billions; that's what modem manufac= turers > put on the market too routinely. Maybe we can talk trillions of= IoT > devices. Maybe we can use the SI prefixes, like exa, or peta. > =20 > That aside, I would like to ask you whether the CLAT src on Andr= oid is > something I could look at? > =20 > Alex > =20 > Le 20/09/2017 =C3=A0 08:03, Erik Kline a =C3=A9crit : > > There seem to be some misconceptions flying around here. > > > >> Well, I dont think 464XLAT is deployed anywhere else than on = cellular. These > >> are the big numbers that the Original Poster talked about: mi= liions of users > >> - they are on cellular. > > > > 464xlat is a client-side bit of code (the NAT64+DNS64 in the n= etwork > > is the "other half"). It is primarily implemented in mobile d= evices, > > and primarily in Android, to be more specific. > > > > As such, the number of 464xlat capable nodes is numbered in th= e /billions/. > > > > There are also some wifi (and wired) networks that are IPv6-on= ly with > > NAT64+DNS64; mobile networks aren't the only ones. > > > > NAT64+DNS64 is easily the single most successful IPv6 transiti= on > > technology on the planet ([a] if one excludes "dualstack", [b]= queue > > the Sean Spicer jokes). 464xlat can help ease things on the c= lient > > side, but it's not the only way to do it (cf. iOS). > > > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Sep 20 06:39:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933651331E7 for ; Wed, 20 Sep 2017 06:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.505 X-Spam-Level: X-Spam-Status: No, score=0.505 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_MILLION=2.505] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpjNKsqbocBS for ; Wed, 20 Sep 2017 06:39:03 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1E3133053 for ; Wed, 20 Sep 2017 06:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505914741; x=1506519541; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=+MqFmGn7mtvk2w3Co/gmQ6Wvx kjfmEekpmCTutu/pk4=; b=hP4LNnaV3in6XsUbCmpMf4ymR7wSFsHov15EMjqRK PeYZKiZj4FI21NqYmRR+Jma/l/kP8jZWQhrIS1pbckw4xrUdutD9HJQlukQUMUNg Xv/QtSClTd/t5cxsxohNWc5r0nOgWISM7/LPXjn6kUfDN8IPyJLldmREUZfr3oha as= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=orVl2aGCyMyCXzlJ4mYAQT+Wtt+3yHA76Vwk3Dy9mWvU1xrY1D3qeT/kvuMq FhN8s+r1TPbVKFp5L6L8DI+z0BTMXEC3twI+/jaqtCr9fSIpJNxb8Kn2z 9EC+2V0ZvZAFnsLdZS6ATrvvrgpFvFePGkaXSIYbBnAqn+vxVzdP94=; X-MDAV-Processed: mail.consulintel.es, Wed, 20 Sep 2017 15:39:01 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 20 Sep 2017 15:39:00 +0200 Received: from [45.6.249.104] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005561250.msg for ; Wed, 20 Sep 2017 15:38:59 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170920:md50005561250::3EOehGNpEwAJ7lb2:000017Xv X-Return-Path: prvs=143688d48d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Wed, 20 Sep 2017 10:38:52 -0300 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es X-Spam-Prev-Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as Archived-At: Subject: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 13:39:05 -0000 Don=E2=80=99t know the chipset hardware details. In our trials, they were several models from well know Chinese vendors. I really doubt chipsets block DHCPv6 messages. You should contact those chi= pset vendors and make sure about that. https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xlat= .sh Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: mi=C3=A9rcoles, 20 de septiembre de 2017, 10:34 Para: Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as s= tandard instead of info =20 =20 Le 20/09/2017 =C3=A0 15:19, JORDI PALET MARTINEZ a =C3=A9crit : > Google is your friend: >=20 > https://android.googlesource.com/platform/external/android-clat/ >=20 > Same for other questions that you asked before =E2=80=A6 you can find= it also for OpenWRT. =20 Jordi, please let me ask again: I would like to ask you which LTE modem= =20 was inside the LTE router? =20 Because the Balong modem in some Huawei smartphones, and some Qualcomm MDM8xxxx series in some IoT devices block DHCPv6 messages. =20 OpenWRT is an OS, not a modem. An OS runs on many kinds of modems.=20 Some modems block DHCP altogether. =20 You cant just redirect me to OpenWRT. =20 Alex =20 >=20 > Regards, > Jordi > =20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Alexandre Petrescu > Responder a: > Fecha: mi=C3=A9rcoles, 20 de septiembre de 2017, 9:55 > Para: Erik Kline > CC: "v6ops@ietf.org" > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info >=20 > No need to stress terms like billions; that's what modem manufac= turers > put on the market too routinely. Maybe we can talk trillions of= IoT > devices. Maybe we can use the SI prefixes, like exa, or peta. > =20 > That aside, I would like to ask you whether the CLAT src on Andr= oid is > something I could look at? > =20 > Alex > =20 > Le 20/09/2017 =C3=A0 08:03, Erik Kline a =C3=A9crit : > > There seem to be some misconceptions flying around here. > > > >> Well, I dont think 464XLAT is deployed anywhere else than on = cellular. These > >> are the big numbers that the Original Poster talked about: mi= liions of users > >> - they are on cellular. > > > > 464xlat is a client-side bit of code (the NAT64+DNS64 in the n= etwork > > is the "other half"). It is primarily implemented in mobile d= evices, > > and primarily in Android, to be more specific. > > > > As such, the number of 464xlat capable nodes is numbered in th= e /billions/. > > > > There are also some wifi (and wired) networks that are IPv6-on= ly with > > NAT64+DNS64; mobile networks aren't the only ones. > > > > NAT64+DNS64 is easily the single most successful IPv6 transiti= on > > technology on the planet ([a] if one excludes "dualstack", [b]= queue > > the Sean Spicer jokes). 464xlat can help ease things on the c= lient > > side, but it's not the only way to do it (cf. iOS). > > > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Sep 20 06:44:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD2A1331E7 for ; Wed, 20 Sep 2017 06:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FUZZY_MILLION=2.505, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3giEHKciLn7 for ; Wed, 20 Sep 2017 06:44:24 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A722133074 for ; Wed, 20 Sep 2017 06:44:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8KDiMVL043356 for ; Wed, 20 Sep 2017 15:44:22 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 681F2207B51 for ; Wed, 20 Sep 2017 15:44:22 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5DFEC207B43 for ; Wed, 20 Sep 2017 15:44:22 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8KDiLE2022722 for ; Wed, 20 Sep 2017 15:44:22 +0200 To: v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> From: Alexandre Petrescu Message-ID: <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> Date: Wed, 20 Sep 2017 15:44:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 13:44:26 -0000 Le 20/09/2017 à 15:35, JORDI PALET MARTINEZ a écrit : > Why you try to mix things? I dont mix. You want a unique STdsTRack. Do you think the place is empty? As I said already, there is already IPv6-in-GTP for transitioning and DHCPv6-PD for Prefix Delegation. These are standards. > CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a way to provision addresses/prefixes. > > No sense to mix all them. That's a problem. You want them to work together, not to compete. You want them to have different functions. But the function to get a prefix is a unique function. > Many other transition mechanisms don’t state if SLAAC or DHCPv6 is used or not, and I think is perfectly correct. Most of them are not dynamic in nature anyways, whereas CLAT seems to be. As long as they dont claim, and they abstain from to dynamically set a prefix on the network they are fine with respect to DHCP-PD. But once CLAT gets into statements qualifying which is better SLAAC-vs-DHCP then we have a big problem. Alex > > Regarsd, > Jordi > > > -----Mensaje original----- > De: v6ops en nombre de Alexandre Petrescu > Responder a: > Fecha: miércoles, 20 de septiembre de 2017, 10:28 > Para: > Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info > > > > Le 20/09/2017 à 15:19, JORDI PALET MARTINEZ a écrit : > > Google is your friend: > > > > https://android.googlesource.com/platform/external/android-clat/ > > Google is my friend. > > Ctrl-F also, and that page does not seem to display any correction that > says "DHCP" in the last 3 and a half years. > > But I think CLAT should run DHCP somehow, otherwise it's a non standard > way to get Prefix Delegation. Does it? (I may download it later and > look at it). > > As long as these two things stay distinct they are in competition. > > Once you make 464XLAT StdsTrack you cant also keep DHCPv6-PD as > StdsTrack - they are on the same layer. > > But yes, you can keep XMPP on the StdsTrack, because it's on another layer. > > Alex > > > > > Same for other questions that you asked before … you can find it also for OpenWRT. > > > > Regards, > > Jordi > > > > > > -----Mensaje original----- > > De: v6ops en nombre de Alexandre Petrescu > > Responder a: > > Fecha: miércoles, 20 de septiembre de 2017, 9:55 > > Para: Erik Kline > > CC: "v6ops@ietf.org" > > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info > > > > No need to stress terms like billions; that's what modem manufacturers > > put on the market too routinely. Maybe we can talk trillions of IoT > > devices. Maybe we can use the SI prefixes, like exa, or peta. > > > > That aside, I would like to ask you whether the CLAT src on Android is > > something I could look at? > > > > Alex > > > > Le 20/09/2017 à 08:03, Erik Kline a écrit : > > > There seem to be some misconceptions flying around here. > > > > > >> Well, I dont think 464XLAT is deployed anywhere else than on cellular. These > > >> are the big numbers that the Original Poster talked about: miliions of users > > >> - they are on cellular. > > > > > > 464xlat is a client-side bit of code (the NAT64+DNS64 in the network > > > is the "other half"). It is primarily implemented in mobile devices, > > > and primarily in Android, to be more specific. > > > > > > As such, the number of 464xlat capable nodes is numbered in the /billions/. > > > > > > There are also some wifi (and wired) networks that are IPv6-only with > > > NAT64+DNS64; mobile networks aren't the only ones. > > > > > > NAT64+DNS64 is easily the single most successful IPv6 transition > > > technology on the planet ([a] if one excludes "dualstack", [b] queue > > > the Sean Spicer jokes). 464xlat can help ease things on the client > > > side, but it's not the only way to do it (cf. iOS). > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 20 06:50:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1453B132F2E for ; Wed, 20 Sep 2017 06:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FUZZY_MILLION=2.505, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvFfPNsedjWL for ; Wed, 20 Sep 2017 06:50:26 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B450126B6D for ; Wed, 20 Sep 2017 06:50:26 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8KDoOmb013975 for ; Wed, 20 Sep 2017 15:50:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1339A207B6A for ; Wed, 20 Sep 2017 15:50:24 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 0A9A7207115 for ; Wed, 20 Sep 2017 15:50:24 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8KDoND5028850 for ; Wed, 20 Sep 2017 15:50:23 +0200 To: v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Wed, 20 Sep 2017 15:50:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 13:50:33 -0000 Le 20/09/2017 à 15:38, JORDI PALET MARTINEZ a écrit : > Don’t know the chipset hardware details. We cant make statements of functionality if we dont know which platform supports it. > In our trials, they were several models from well know Chinese > vendors. Which ones? Is Balong among them? > I really doubt chipsets block DHCPv6 messages. Jordi - I doubted too. But then I checked. I worked with operator and hw manufacturer. I got advice from v6ops members. We issued DHCP packets from linux and captured what arrives at PGW. After months of test, I tell it is extremely likely the modem blocks. Operator informs me it is extremely unlikely the BS, SGW and PGW blocks DHCP. The linux does not block anything, it's open source, I checked. What modems block is the following: std DHCP ports, multicast IP dst address of DHCP. What modems dont block is the following: DHCP packets sent on non-std DHCP ports, or on unicast addresses. There is no open source for these modems. > You should contact > those chipset vendors and make sure about that. YEs, done that. After discussion I can say that they feel like it's good to block it; they sometimes say "because that's the design". I dont know what the design is that, but DHCPv6-PD is certainly not a design to block. I wonder where do the modem manufacturers get the idea that a good design is one that does not do DHCP. Alex > > https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xlat.sh > > Regards, Jordi > > > -----Mensaje original----- De: v6ops en > nombre de Alexandre Petrescu Responder > a: Fecha: miércoles, 20 de septiembre > de 2017, 10:34 Para: Asunto: Re: [v6ops] [*SPAM* > Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of > info > > > > Le 20/09/2017 à 15:19, JORDI PALET MARTINEZ a écrit : >> Google is your friend: >> >> https://android.googlesource.com/platform/external/android-clat/ >> >> Same for other questions that you asked before … you can find it >> also for OpenWRT. > > Jordi, please let me ask again: I would like to ask you which LTE > modem was inside the LTE router? > > Because the Balong modem in some Huawei smartphones, and some > Qualcomm MDM8xxxx series in some IoT devices block DHCPv6 messages. > > OpenWRT is an OS, not a modem. An OS runs on many kinds of modems. > Some modems block DHCP altogether. > > You cant just redirect me to OpenWRT. > > Alex > >> >> Regards, Jordi >> >> >> -----Mensaje original----- De: v6ops en >> nombre de Alexandre Petrescu >> Responder a: Fecha: miércoles, 20 de >> septiembre de 2017, 9:55 Para: Erik Kline CC: >> "v6ops@ietf.org" Asunto: Re: [v6ops] reclassify >> 464XLAT as standard instead of info >> >> No need to stress terms like billions; that's what modem >> manufacturers put on the market too routinely. Maybe we can talk >> trillions of IoT devices. Maybe we can use the SI prefixes, like >> exa, or peta. >> >> That aside, I would like to ask you whether the CLAT src on Android >> is something I could look at? >> >> Alex >> >> Le 20/09/2017 à 08:03, Erik Kline a écrit : >>> There seem to be some misconceptions flying around here. >>> >>>> Well, I dont think 464XLAT is deployed anywhere else than on >>>> cellular. These are the big numbers that the Original Poster >>>> talked about: miliions of users - they are on cellular. >>> >>> 464xlat is a client-side bit of code (the NAT64+DNS64 in the >>> network is the "other half"). It is primarily implemented in >>> mobile devices, and primarily in Android, to be more specific. >>> >>> As such, the number of 464xlat capable nodes is numbered in the >>> /billions/. >>> >>> There are also some wifi (and wired) networks that are IPv6-only >>> with NAT64+DNS64; mobile networks aren't the only ones. >>> >>> NAT64+DNS64 is easily the single most successful IPv6 transition >>> technology on the planet ([a] if one excludes "dualstack", [b] >>> queue the Sean Spicer jokes). 464xlat can help ease things on >>> the client side, but it's not the only way to do it (cf. iOS). >>> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> ********************************************** IPv4 is over Are you >> ready for the new Internet ? http://www.consulintel.es The IPv6 >> Company >> >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be for >> the exclusive use of the individual(s) named above and further >> non-explicilty authorized disclosure, copying, distribution or use >> of the contents of this information, even if partially, including >> attached files, is strictly prohibited and will be considered a >> criminal offense. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents >> of this information, even if partially, including attached files, >> is strictly prohibited, will be considered a criminal offense, so >> you must reply to the original sender to inform about this >> communication and delete it. >> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 20 08:14:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A49134222 for ; Wed, 20 Sep 2017 08:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.595 X-Spam-Level: X-Spam-Status: No, score=-3.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, FUZZY_MILLION=2.505, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2x8oLfmed5P for ; Wed, 20 Sep 2017 08:14:14 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFB113214D for ; Wed, 20 Sep 2017 08:14:13 -0700 (PDT) Received: from rev-2001-13c7-7003-eventos.lacnic.net (rev-2001-13c7-7003-eventos.lacnic.net [IPv6:2001:13c7:7003:200:18e1:f2c1:ded:bb79] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v8KFD7ZH008067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Sep 2017 08:13:10 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_B1A8DB36-2095-4A07-B3E8-161751045A72" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> Date: Wed, 20 Sep 2017 12:13:10 -0300 Cc: v6ops@ietf.org Message-Id: <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 20 Sep 2017 08:13:12 -0700 (PDT) Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 15:14:16 -0000 --Apple-Mail=_B1A8DB36-2095-4A07-B3E8-161751045A72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 20/09/2017 =C3=A0 15:35, JORDI PALET MARTINEZ a =C3=A9crit : >> Why you try to mix things? >=20 > I dont mix. You want a unique STdsTRack. Do you think the place is = empty? I=E2=80=99m not sure where you get =E2=80=9Cunique=E2=80=9D. I think = Jordi wants 464XLAT moved to Standards track rather than informational. = I don=E2=80=99t see anything about unique in his request. > As I said already, there is already IPv6-in-GTP for transitioning and = DHCPv6-PD for Prefix Delegation. These are standards. I guess the question I have for this statement is =E2=80=9Cwhy is this = relevant to whether or not we move 464XLAT to standard?=E2=80=9D >> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a way to = provision addresses/prefixes. >> No sense to mix all them. >=20 > That's a problem. You want them to work together, not to compete. This makes no sense to me. IMHO, they don=E2=80=99t compete and CLAT can = work regardless of how the IPv6 address on the client is obtained, = whether SLAAC, DHCPv6, static, or otherwise. > You want them to have different functions. CLAT doesn=E2=80=99t have an IPv6 address assignment function so they = do, in fact, have different functions. > But the function to get a prefix is a unique function. CLAT doesn=E2=80=99t have anything to do with getting a prefix for IPv6. >> Many other transition mechanisms don=E2=80=99t state if SLAAC or = DHCPv6 is used or not, and I think is perfectly correct. >=20 > Most of them are not dynamic in nature anyways, whereas CLAT seems to = be. My understanding is that CLAT is dynamic only on the IPv4 side. On the = IPv6 side, to the best of my knowledge, it just uses whatever IPv6 = address is available on the client=E2=80=99s interface(s). > As long as they dont claim, and they abstain from to dynamically set a = prefix on the network they are fine with respect to DHCP-PD. >=20 > But once CLAT gets into statements qualifying which is better = SLAAC-vs-DHCP then we have a big problem. Sigh=E2=80=A6 I agree that there=E2=80=99s no reason for CLAT to make = any such statement. If the current CLAT RFC(s) do, then, perhaps we = should argue for cleaning that up as part of the process of moving = towards a standards track RFC, but if that=E2=80=99s what you=E2=80=99re = on about here, then just say that. You=E2=80=99ve wasted multiple = messages talking about completely orthogonal issues where the above = statement is the first clue you=E2=80=99ve provided about what is = apparently your actual concern. Owen >=20 > Alex >=20 >> Regarsd, >> Jordi >> -----Mensaje original----- >> De: v6ops en nombre de Alexandre Petrescu = >> Responder a: >> Fecha: mi=C3=A9rcoles, 20 de septiembre de 2017, 10:28 >> Para: >> Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify = 464XLAT as standard instead of info >> Le 20/09/2017 =C3=A0 15:19, JORDI PALET MARTINEZ a = =C3=A9crit : >> > Google is your friend: >> > >> > = https://android.googlesource.com/platform/external/android-clat/ >> Google is my friend. >> Ctrl-F also, and that page does not seem to display any = correction that >> says "DHCP" in the last 3 and a half years. >> But I think CLAT should run DHCP somehow, otherwise it's a = non standard >> way to get Prefix Delegation. Does it? (I may download it later = and >> look at it). >> As long as these two things stay distinct they are in = competition. >> Once you make 464XLAT StdsTrack you cant also keep DHCPv6-PD = as >> StdsTrack - they are on the same layer. >> But yes, you can keep XMPP on the StdsTrack, because it's on = another layer. >> Alex >> > >> > Same for other questions that you asked before =E2=80=A6 you = can find it also for OpenWRT. >> > >> > Regards, >> > Jordi >> > >> > >> > -----Mensaje original----- >> > De: v6ops en nombre de Alexandre = Petrescu >> > Responder a: >> > Fecha: mi=C3=A9rcoles, 20 de septiembre de 2017, 9:55 >> > Para: Erik Kline >> > CC: "v6ops@ietf.org" >> > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of = info >> > >> > No need to stress terms like billions; that's what modem = manufacturers >> > put on the market too routinely. Maybe we can talk = trillions of IoT >> > devices. Maybe we can use the SI prefixes, like exa, or = peta. >> > >> > That aside, I would like to ask you whether the CLAT src = on Android is >> > something I could look at? >> > >> > Alex >> > >> > Le 20/09/2017 =C3=A0 08:03, Erik Kline a =C3=A9crit : >> > > There seem to be some misconceptions flying around here. >> > > >> > >> Well, I dont think 464XLAT is deployed anywhere else = than on cellular. These >> > >> are the big numbers that the Original Poster talked = about: miliions of users >> > >> - they are on cellular. >> > > >> > > 464xlat is a client-side bit of code (the NAT64+DNS64 in = the network >> > > is the "other half"). It is primarily implemented in = mobile devices, >> > > and primarily in Android, to be more specific. >> > > >> > > As such, the number of 464xlat capable nodes is numbered = in the /billions/. >> > > >> > > There are also some wifi (and wired) networks that are = IPv6-only with >> > > NAT64+DNS64; mobile networks aren't the only ones. >> > > >> > > NAT64+DNS64 is easily the single most successful IPv6 = transition >> > > technology on the planet ([a] if one excludes = "dualstack", [b] queue >> > > the Sean Spicer jokes). 464xlat can help ease things on = the client >> > > side, but it's not the only way to do it (cf. iOS). >> > > >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> > >> > >> > >> > ********************************************** >> > IPv4 is over >> > Are you ready for the new Internet ? >> > http://www.consulintel.es >> > The IPv6 Company >> > >> > This electronic message contains information which may be = privileged or confidential. The information is intended to be for the = exclusive use of the individual(s) named above and further = non-explicilty authorized disclosure, copying, distribution or use of = the contents of this information, even if partially, including attached = files, is strictly prohibited and will be considered a criminal offense. = If you are not the intended recipient be aware that any disclosure, = copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited, will be = considered a criminal offense, so you must reply to the original sender = to inform about this communication and delete it. >> > >> > >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops >> > >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --Apple-Mail=_B1A8DB36-2095-4A07-B3E8-161751045A72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:



Le 20/09/2017 =C3=A0 15:35, JORDI PALET = MARTINEZ a =C3=A9crit :
Why you try to mix things?

I dont mix.  You want = a unique STdsTRack.  Do you think the place is empty?

I=E2=80=99m not sure where you get =E2=80=9Cunique=E2=80=9D= . I think Jordi wants 464XLAT moved to Standards track rather than = informational. I don=E2=80=99t see anything about unique in his = request.

As I said already, there = is already IPv6-in-GTP for transitioning and DHCPv6-PD for Prefix = Delegation. These are standards.

I guess the = question I have for this statement is =E2=80=9Cwhy is this relevant to = whether or not we move 464XLAT
to standard?=E2=80=9D
<= br class=3D"">
CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a = way to provision addresses/prefixes.
No sense to mix all = them.

That's a problem.  You want them to = work  together, not to compete.

This makes no = sense to me. IMHO, they don=E2=80=99t compete and CLAT can work = regardless of how the IPv6 address on the client is obtained, whether = SLAAC, DHCPv6, static, or otherwise.

You want them to have = different functions.

CLAT doesn=E2=80=99= t have an IPv6 address assignment function so they do, in fact, have = different functions.

But the function to get a = prefix is a unique function.

CLAT doesn=E2=80=99= t have anything to do with getting a prefix for IPv6.

Many other transition mechanisms don=E2=80=99t state if SLAAC = or DHCPv6 is used or not, and I think is perfectly correct.

Most of them are not dynamic in nature anyways, = whereas CLAT seems to be.

My understanding = is that CLAT is dynamic only on the IPv4 side. On the IPv6 side, to the = best of my knowledge, it just uses whatever IPv6 address is available on = the client=E2=80=99s interface(s).

As long as they dont = claim, and they abstain from to dynamically set a prefix on the network = they are fine with respect to DHCP-PD.

But once CLAT gets into statements qualifying = which is better SLAAC-vs-DHCP then we have a big problem.

Sigh=E2=80=A6 I agree that there=E2=80=99s no reason = for CLAT to make any such statement. If the current CLAT RFC(s) do, = then, perhaps we should argue for cleaning that up as part of the = process of moving towards a standards track RFC, but if that=E2=80=99s = what you=E2=80=99re on about here, then just say that. You=E2=80=99ve = wasted multiple messages talking about completely orthogonal issues = where the above statement is the first clue you=E2=80=99ve provided = about what is apparently your actual concern.

Owen


Alex

Regarsd,Jordi
 -----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Alexandre = Petrescu <alexandre.petrescu@gmail.com>
Responder = a: <alexandre.petrescu@gmail.com>
Fecha: = mi=C3=A9rcoles, 20 de septiembre de 2017, 10:28
Para: = <v6ops@ietf.org>Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: = reclassify 464XLAT as standard instead of info
          &nb= sp;   Le 20/09/2017 =C3=A0 15:19, JORDI PALET MARTINEZ a = =C3=A9crit :
    > Google is your = friend:
    >
    > https://android.googlesource.com/platform/external/android-clat= /
         Google = is my friend.
         Ctrl-F = also, and that page does not seem to display any correction that
    says "DHCP" in the last 3 and a half = years.
         But I = think CLAT should run DHCP somehow, otherwise it's a non standard
    way to get Prefix Delegation. =  Does it?  (I may download it later and
    look at it).
         As long = as these two things stay distinct they are in competition.
         Once = you make 464XLAT StdsTrack you cant also keep DHCPv6-PD as
    StdsTrack - they are on the same = layer.
         But = yes, you can keep XMPP on the StdsTrack, because it's on another = layer.
         Alex
         >
    > Same for other questions that = you asked before =E2=80=A6 you can find it also for OpenWRT.
    >
    > Regards,
    > Jordi
    >
    >
    > -----Mensaje original-----
    > De: v6ops <v6ops-bounces@ietf.org> en nombre de Alexandre = Petrescu <alexandre.petrescu@gmail.com>
    > Responder a: <alexandre.petrescu@gmail.com>
    > Fecha: mi=C3=A9rcoles, 20 de = septiembre de 2017, 9:55
    > = Para: Erik Kline <ek@google.com>
    > CC: "v6ops@ietf.org" <v6ops@ietf.org>
    > Asunto: Re: [v6ops] reclassify = 464XLAT as standard instead of info
    >
    >      No = need to stress terms like billions; that's what modem manufacturers
    > =      put on the market too routinely. =  Maybe we can talk trillions of IoT
    > =      devices.  Maybe we can use the SI = prefixes, like exa, or peta.
    >    > =      That aside, I would like to ask you = whether the CLAT src on Android is
    > =      something I could look at?
    >
    > =      Alex
    >
    >      Le = 20/09/2017 =C3=A0 08:03, Erik Kline a =C3=A9crit :
    > =      > There seem to be some misconceptions = flying around here.
    > =      >
    > =      >> Well, I dont think 464XLAT is = deployed anywhere else than on cellular. These
    > =      >> are the big numbers that the = Original Poster talked about: miliions of users
    > =      >> - they are on cellular.
    > =      >
    > =      > 464xlat is a client-side bit of code = (the NAT64+DNS64 in the network
    >=      > is the "other half").  It is = primarily implemented in mobile devices,
    > =      > and primarily in Android, to be more = specific.
    > =      >
    > =      > As such, the number of 464xlat = capable nodes is numbered in the /billions/.
    > =      >
    > =      > There are also some wifi (and wired) = networks that are IPv6-only with
    > =      > NAT64+DNS64; mobile networks aren't = the only ones.
    > =      >
    > =      > NAT64+DNS64 is easily the single most = successful IPv6 transition
    > =      > technology on the planet ([a] if one = excludes "dualstack", [b] queue
    >=      > the Sean Spicer jokes). =  464xlat can help ease things on the client
    > =      > side, but it's not the only way to do = it (cf. iOS).
    > =      >
    >
    > =      ____________________________________________= ___
    > =      v6ops mailing list
    >      v6ops@ietf.org
    >      https://www.ietf.org/mailman/listinfo/v6ops
    >
    >
    >
    >
    > = **********************************************
    > IPv4 is over
    > Are you ready for the new = Internet ?
    > http://www.consulintel.es
    > The IPv6 Company
    >
    > This electronic message contains = information which may be privileged or confidential. The information is = intended to be for the exclusive use of the individual(s) named above = and further non-explicilty authorized disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited and will be considered a criminal = offense. If you are not the intended recipient be aware that any = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited, will be considered a criminal offense, so you must reply to = the original sender to inform about this communication and delete it.
    >
    >
    >
    > = _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > = https://www.ietf.org/mailman/listinfo/v6ops
    >
         _________= ______________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
    ***************************************= *******
IPv4 is over
Are you ready for the = new Internet ?
http://www.consulintel.es
The IPv6 = Company
This electronic message contains information which = may be privileged or confidential. The information is intended to be for = the exclusive use of the individual(s) named above and further = non-explicilty authorized disclosure, copying, distribution or use of = the contents of this information, even if partially, including attached = files, is strictly prohibited and will be considered a criminal offense. = If you are not the intended recipient be aware that any disclosure, = copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited, will be = considered a criminal offense, so you must reply to the original sender = to inform about this communication and delete it.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

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

= --Apple-Mail=_B1A8DB36-2095-4A07-B3E8-161751045A72-- From nobody Wed Sep 20 08:22:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41CC132198 for ; Wed, 20 Sep 2017 08:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ekqk0glUZTC8 for ; Wed, 20 Sep 2017 08:22:10 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7933132125 for ; Wed, 20 Sep 2017 08:22:09 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id a137so5362003wma.0 for ; Wed, 20 Sep 2017 08:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UQeVNJl9I2+4DvqyXbOkzfMfxmN+U89+y3V1IzIYARw=; b=QQfi71Ol9UE8b+bN36Qixfx5BXQS9Z8T2K3bz2TIlWQ8tP3e0DLy3wGYobAgHFcn5k 3IaH+IW3/ZqECtIUzEyjA8ESFBFLN3y3nkE8ugfO8eO2OPu+DmyJxjlPI5/Pvr0FffFu hat20RFld76aSL+iIVjaCcI4iSzoXI/jebbK1sbHC1DRbD6G7gEbip/kVDyeus6tJLju yhvRgVXi0XklGFqXEXMDXdDsfVldYzD+YOXuK346wPmVqbfYu9HQqkbRfOdDGljho/YI fKm94D7xciuskUHXPg1WKHI+5VjTgF8MHcEepZ3xqJllWWaNIg/Us9W3GPDoYJKB4Bms 6MZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UQeVNJl9I2+4DvqyXbOkzfMfxmN+U89+y3V1IzIYARw=; b=KjwNRXI3jYM5X/QzOhPuqs9hirqDgq6bp8IM7O0uO5sjjHHF2pQnVZMSwKVd0gvhdD ed0pcDeko1Fn7EXGwXpuUyDonAg/vFVv4jUk9HxpYVeNU1uHU4bbT71PrZLOOf74vqBp I3siWG99eZCYrQkMREVsWM+ryu5J72IeZM46Fb7/QPov305IFbFU2CasEgki8ZNdjj4F BywA3RUxh6B86NU+J7IpBV6tiIqVNzv27HGVyGVEt+VFfmHXbAs07WUso00GTacq+SqA 2dj5hIq3Zser0mMN2WDOEZnmUcKgsHLu38x4+XFh9S+H5vVqBX1mbM+LytD0L+0kRsy/ ZmgA== X-Gm-Message-State: AHPjjUgnD5FQ73wJMGOLVTXiJqZ6wMiLcVQ3mrG58ey+Bp8zkGzl2XH+ Wwq6/cPg53ygckI6bqRzWG4qHVX4JkZylV679UcjgA== X-Google-Smtp-Source: AOwi7QAlm5g9SbCGGK22XpvVmBAQRs0hgp/ZZV9IpcwVEU6YLZFA2BsEQjHJI+Sv1nAac8/fEqsBB4tu0LTOKpYHyiY= X-Received: by 10.28.63.145 with SMTP id m139mr4801120wma.5.1505920927797; Wed, 20 Sep 2017 08:22:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Wed, 20 Sep 2017 08:21:46 -0700 (PDT) In-Reply-To: <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> From: Erik Kline Date: Thu, 21 Sep 2017 00:21:46 +0900 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114b427cff8c5e0559a089fa" Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 15:22:12 -0000 --001a114b427cff8c5e0559a089fa Content-Type: text/plain; charset="UTF-8" > Ctrl-F also, and that page does not seem to display any correction that says > "DHCP" in the last 3 and a half years. > > But I think CLAT should run DHCP somehow, otherwise it's a non standard way > to get Prefix Delegation. Does it? (I may download it later and look at > it). There is no PD wrt 464xlat. The /64 is implicitly delegated to the mobile per the 3GPP architecture, as I'm sure you well know. If you want to know how the device learns the DNS64/NAT64 prefix then see https://tools.ietf.org/html/rfc7050 . --001a114b427cff8c5e0559a089fa Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgM0pFtQW8AOdjMVQTBCxQ3ZZiMiBwZgPA ruya7KziDDMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTIw MTUyMjA4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBABDlNU+xtcwXnos17AhSF9EfGeJGA6+je8djgeQSlSDXHTGhw6TW 7lP6oXhvQAAadb1KWS2hpmTHT6GZeCTmqfVve43V7jlGOrlg154XTw0dbfNHZKXbZ/J3bJq5SLCz EaptU2yxxQ540PdZ7i7KoTZJZqi6obd/vxLzezCH9t8eQJKx6iiK6ouwhCt1bSynMinbyNWQgqZi SiQE7gU3dBuCAFha80ZN3Fn7gM3oLyLXExWnFmxEoziCetIubh2juEeZyAKFr9RE1wDMKm83dyfy MheKY5w1hNlahDvJITGHyxKJ7V33MEiWirVQQyfKbJa4PvOyDJCu18KfNej95yI= --001a114b427cff8c5e0559a089fa-- From nobody Wed Sep 20 08:26:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E25132C3F for ; Wed, 20 Sep 2017 08:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FUZZY_MILLION=2.505, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzAkGR_CTaAH for ; Wed, 20 Sep 2017 08:26:29 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A022E1321A0 for ; Wed, 20 Sep 2017 08:26:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8KFQNce002586; Wed, 20 Sep 2017 17:26:23 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EF62720EB31; Wed, 20 Sep 2017 17:26:22 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E145F20EB2E; Wed, 20 Sep 2017 17:26:22 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8KFQMcN001319; Wed, 20 Sep 2017 17:26:22 +0200 To: Owen DeLong Cc: v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> From: Alexandre Petrescu Message-ID: <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> Date: Wed, 20 Sep 2017 17:26:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 15:26:31 -0000 Le 20/09/2017 à 17:13, Owen DeLong a écrit : > >> On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu >> > >> wrote: >> >> >> >> Le 20/09/2017 à 15:35, JORDI PALET MARTINEZ a écrit : >>> Why you try to mix things? >> >> I dont mix.  You want a unique STdsTRack.  Do you think the place is >> empty? > > I’m not sure where you get “unique”. I think Jordi wants 464XLAT moved > to Standards track rather than informational. I don’t see anything about > unique in his request. > >> As I said already, there is already IPv6-in-GTP for transitioning and >> DHCPv6-PD for Prefix Delegation. These are standards. > > I guess the question I have for this statement is “why is this relevant > to whether or not we move 464XLAT > to standard?” BEcause 464XLAT is a transitioning mechanism and IPv6-in-GTP is a transitioning mechanism too, which is deployed too. >>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a way to >>> provision addresses/prefixes. >>> No sense to mix all them. >> >> That's a problem.  You want them to work  together, not to compete. > > This makes no sense to me. IMHO, they don’t compete and CLAT can work > regardless of how the IPv6 address on the client is obtained, whether > SLAAC, DHCPv6, static, or otherwise. But you dont want CLAT's IPv6-in-IPv4 together with GTP encapsulation - that's too many encapsulations. >> You want them to have different functions. > > CLAT doesn’t have an IPv6 address assignment function so they do, in > fact, have different functions. > >> But the function to get a prefix is a unique function. > > CLAT doesn’t have anything to do with getting a prefix for IPv6. But it only works with a /64. It means it cant work when DHCPv6-PD gives it a /63. >>> Many other transition mechanisms don’t state if SLAAC or DHCPv6 is >>> used or not, and I think is perfectly correct. >> >> Most of them are not dynamic in nature anyways, whereas CLAT seems to be. > > My understanding is that CLAT is dynamic only on the IPv4 side. On the > IPv6 side, to the best of my knowledge, it just uses whatever IPv6 > address is available on the client’s interface(s). > >> As long as they dont claim, and they abstain from to dynamically set a >> prefix on the network they are fine with respect to DHCP-PD. >> >> But once CLAT gets into statements qualifying which is better >> SLAAC-vs-DHCP then we have a big problem. > > Sigh… I agree that there’s no reason for CLAT to make any such > statement. If the current CLAT RFC(s) do, then, perhaps we should argue > for cleaning that up as part of the process of moving towards a > standards track RFC, but if that’s what you’re on about here, then just > say that. You’ve wasted multiple messages talking about completely > orthogonal issues where the above statement is the first clue you’ve > provided about what is apparently your actual concern. I dont think it's orthogonal. Alex > > Owen > >> >> Alex >> >>> Regarsd, >>> Jordi >>>  -----Mensaje original----- >>> De: v6ops > en >>> nombre de Alexandre Petrescu >> > >>> Responder a: >> > >>> Fecha: miércoles, 20 de septiembre de 2017, 10:28 >>> Para: > >>> Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify >>> 464XLAT as standard instead of info >>>               Le 20/09/2017 à 15:19, JORDI PALET MARTINEZ a écrit : >>>     > Google is your friend: >>>     > >>>     > https://android.googlesource.com/platform/external/android-clat/ >>>          Google is my friend. >>>          Ctrl-F also, and that page does not seem to display any >>> correction that >>>     says "DHCP" in the last 3 and a half years. >>>          But I think CLAT should run DHCP somehow, otherwise it's a >>> non standard >>>     way to get Prefix Delegation.  Does it?  (I may download it later and >>>     look at it). >>>          As long as these two things stay distinct they are in >>> competition. >>>          Once you make 464XLAT StdsTrack you cant also keep DHCPv6-PD as >>>     StdsTrack - they are on the same layer. >>>          But yes, you can keep XMPP on the StdsTrack, because it's on >>> another layer. >>>          Alex >>>          > >>>     > Same for other questions that you asked before … you can find >>> it also for OpenWRT. >>>     > >>>     > Regards, >>>     > Jordi >>>     > >>>     > >>>     > -----Mensaje original----- >>>     > De: v6ops >> > en nombre de Alexandre Petrescu >>> > >>>     > Responder a: >> > >>>     > Fecha: miércoles, 20 de septiembre de 2017, 9:55 >>>     > Para: Erik Kline > >>>     > CC: "v6ops@ietf.org " >> > >>>     > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info >>>     > >>>     >      No need to stress terms like billions; that's what modem >>> manufacturers >>>     >      put on the market too routinely.  Maybe we can talk >>> trillions of IoT >>>     >      devices.  Maybe we can use the SI prefixes, like exa, or peta. >>>     > >>>     >      That aside, I would like to ask you whether the CLAT src >>> on Android is >>>     >      something I could look at? >>>     > >>>     >      Alex >>>     > >>>     >      Le 20/09/2017 à 08:03, Erik Kline a écrit : >>>     >      > There seem to be some misconceptions flying around here. >>>     >      > >>>     >      >> Well, I dont think 464XLAT is deployed anywhere else >>> than on cellular. These >>>     >      >> are the big numbers that the Original Poster talked >>> about: miliions of users >>>     >      >> - they are on cellular. >>>     >      > >>>     >      > 464xlat is a client-side bit of code (the NAT64+DNS64 in >>> the network >>>     >      > is the "other half").  It is primarily implemented in >>> mobile devices, >>>     >      > and primarily in Android, to be more specific. >>>     >      > >>>     >      > As such, the number of 464xlat capable nodes is numbered >>> in the /billions/. >>>     >      > >>>     >      > There are also some wifi (and wired) networks that are >>> IPv6-only with >>>     >      > NAT64+DNS64; mobile networks aren't the only ones. >>>     >      > >>>     >      > NAT64+DNS64 is easily the single most successful IPv6 >>> transition >>>     >      > technology on the planet ([a] if one excludes >>> "dualstack", [b] queue >>>     >      > the Sean Spicer jokes).  464xlat can help ease things on >>> the client >>>     >      > side, but it's not the only way to do it (cf. iOS). >>>     >      > >>>     > >>>     >      _______________________________________________ >>>     >      v6ops mailing list >>>     > v6ops@ietf.org >>>     > https://www.ietf.org/mailman/listinfo/v6ops >>>     > >>>     > >>>     > >>>     > >>>     > ********************************************** >>>     > IPv4 is over >>>     > Are you ready for the new Internet ? >>>     > http://www.consulintel.es >>>     > The IPv6 Company >>>     > >>>     > This electronic message contains information which may be >>> privileged or confidential. The information is intended to be for the >>> exclusive use of the individual(s) named above and further >>> non-explicilty authorized disclosure, copying, distribution or use of >>> the contents of this information, even if partially, including >>> attached files, is strictly prohibited and will be considered a >>> criminal offense. If you are not the intended recipient be aware that >>> any disclosure, copying, distribution or use of the contents of this >>> information, even if partially, including attached files, is strictly >>> prohibited, will be considered a criminal offense, so you must reply >>> to the original sender to inform about this communication and delete it. >>>     > >>>     > >>>     > >>>     > _______________________________________________ >>>     > v6ops mailing list >>>     > v6ops@ietf.org >>>     > https://www.ietf.org/mailman/listinfo/v6ops >>>     > >>>          _______________________________________________ >>>     v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>     ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.consulintel.es >>> The IPv6 Company >>> This electronic message contains information which may be privileged >>> or confidential. The information is intended to be for the exclusive >>> use of the individual(s) named above and further non-explicilty >>> authorized disclosure, copying, distribution or use of the contents >>> of this information, even if partially, including attached files, is >>> strictly prohibited and will be considered a criminal offense. If you >>> are not the intended recipient be aware that any disclosure, copying, >>> distribution or use of the contents of this information, even if >>> partially, including attached files, is strictly prohibited, will be >>> considered a criminal offense, so you must reply to the original >>> sender to inform about this communication and delete it. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 20 08:28:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56D81321A0 for ; Wed, 20 Sep 2017 08:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYdVjoCO0zWk for ; Wed, 20 Sep 2017 08:28:40 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70EA413301F for ; Wed, 20 Sep 2017 08:28:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8KFSc54003529; Wed, 20 Sep 2017 17:28:38 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7C29B20EB50; Wed, 20 Sep 2017 17:28:38 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6532020EB2E; Wed, 20 Sep 2017 17:28:38 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8KFScDm002870; Wed, 20 Sep 2017 17:28:38 +0200 To: Erik Kline Cc: "v6ops@ietf.org" References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 20 Sep 2017 17:28:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 15:28:42 -0000 Le 20/09/2017 à 17:21, Erik Kline a écrit : >> Ctrl-F also, and that page does not seem to display any correction that says >> "DHCP" in the last 3 and a half years. >> >> But I think CLAT should run DHCP somehow, otherwise it's a non standard way >> to get Prefix Delegation. Does it? (I may download it later and look at >> it). > > There is no PD wrt 464xlat. The /64 is implicitly delegated to the > mobile per the 3GPP architecture, as I'm sure you well know. I well know 3GPP architecture and 3GPP deployment allows for PD. That is not /64 explicit, and it is any length. The fact that CLAT wants it to be 64 it is CLAT problem that should be solved in CLAT. > If you want to know how the device learns the DNS64/NAT64 prefix then > see https://tools.ietf.org/html/rfc7050 . Noted. Alex > From nobody Wed Sep 20 08:31:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D066C1321A0 for ; Wed, 20 Sep 2017 08:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMduVX_mH2Xs for ; Wed, 20 Sep 2017 08:31:35 -0700 (PDT) Received: from atl4mhob13.registeredsite.com (atl4mhob13.registeredsite.com [209.17.115.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F78132D54 for ; Wed, 20 Sep 2017 08:31:35 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob13.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8KFVWZB001675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Sep 2017 11:31:32 -0400 Received: (qmail 6507 invoked by uid 0); 20 Sep 2017 15:31:32 -0000 X-TCPREMOTEIP: 72.221.14.183 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.183) by 0 with ESMTPA; 20 Sep 2017 15:31:32 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Wed, 20 Sep 2017 11:31:25 -0400 From: Lee Howard To: Brian E Carpenter , Philip Homburg , Message-ID: Thread-Topic: [v6ops] LAN behavior when there's no IPv4 Internet access References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 15:31:42 -0000 On 9/11/17, 8:59 PM, "v6ops on behalf of Brian E Carpenter" wrote: > >The thing is that if a home network includes a Windows 98 client and a >Windows 10 client, and has no WAN IPv4 service, there will be dual stack >sites that are accessible from Windows 10 and unreachable from Windows 98. >That translates into help desk calls. Is that a problem we need to solve? The successor version, Windows 2000, has 0.00% market share. https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10& qpcustomd=0 Yes, there are devices that require IPv4 that are much newer than Microsoft Windows, such as Microsoft Xbox. Someday, those will be so old that hobbysists will enjoy cobbling ways to get them to interoperate. Lee From nobody Wed Sep 20 08:45:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2441321A0 for ; Wed, 20 Sep 2017 08:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyZnfPubIUkk for ; Wed, 20 Sep 2017 08:45:29 -0700 (PDT) Received: from atl4mhob10.registeredsite.com (atl4mhob10.registeredsite.com [209.17.115.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E499613202D for ; Wed, 20 Sep 2017 08:45:28 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob10.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8KFjQqM003953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 20 Sep 2017 11:45:26 -0400 Received: (qmail 31297 invoked by uid 0); 20 Sep 2017 15:45:26 -0000 X-TCPREMOTEIP: 72.221.14.183 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.183) by 0 with ESMTPA; 20 Sep 2017 15:45:24 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Wed, 20 Sep 2017 11:45:17 -0400 From: Lee Howard To: , Message-ID: Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 15:45:30 -0000 On 9/19/17, 8:23 AM, "v6ops on behalf of JORDI PALET MARTINEZ" wrote: >Hi all, > >RFC6877 (464XLAT) is an informational document. >... > >Can we even consider moving it to STD? I don=E2=80=99t think v6ops can promote it to Standard, or Standards Track. Our charter doesn=E2=80=99t explicitly say we=E2=80=99re not allowed to do standards work, = but I would want to hear from our AD and check with 6man before promoting it. Generally, the two tests are rough consensus and multiple interoperable implementations.=20 Lee From nobody Wed Sep 20 08:53:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110DC13420B for ; Wed, 20 Sep 2017 08:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkvxoSqCDWwe for ; Wed, 20 Sep 2017 08:52:57 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1BF1331D9 for ; Wed, 20 Sep 2017 08:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505922774; x=1506527574; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=EXn7gCDEk7H6Lpmv1VpzxyHX2 4vLzocsDL2vwrZtLuY=; b=fI/dSD2iFvmeF1tsQzDFhNV/prmt8Q008RGAq7lql 9eDSMZWpdWnAnMRsDK6XP3N87etXuJuvW7x2ivpU1OkdAfEdoOAtfxMC1wbHU06C tmhruQhhIKPdx59f68X/h8u/XApCkW/DDDB6g6APwD7aTFe5h1YPUtIQh8iSj5Jo tA= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=nhzWmxykwRINRAYygE0k5WPRPivbAJgPZ5tn6nrRLfWEFD4+0LFoHM+lLebM ld5uywyn/yD5KBZRIhB2Y7PZLq8vXHjyBHVgj7zSoyLg9Ev8CWM0qWs10 BKt9Cuoi7NADeku0NT8OJRJKst1myphyis8EQujIbMFXUgtRZg8nmU=; X-MDAV-Processed: mail.consulintel.es, Wed, 20 Sep 2017 17:52:54 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 20 Sep 2017 17:52:53 +0200 Received: from [45.6.249.104] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005561387.msg for ; Wed, 20 Sep 2017 17:52:52 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170920:md50005561387::6lzd7MSvfuH7AOBA:00001pHz X-Return-Path: prvs=143688d48d=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Wed, 20 Sep 2017 12:52:47 -0300 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 15:52:59 -0000 >From my perspective, there are multiple interoperable specs. We have severa= l CLAT client implementations/vendors, from different vendors, and they wor= k fine in the same and different operators and interoperate with different = NAT64 and DNS64 vendors/implementations. What I=E2=80=99m not sure is, because 464XLAT is basically RFC6145 (SIIT) += RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are alrea= dy Standards track, if we need also to move them to STD in that case, etc. I guess we may need a chapter update, but I really think should not be a pr= oblem and we must do that. Saludos, Jordi =20 -----Mensaje original----- De: Lee Howard Responder a: Fecha: mi=C3=A9rcoles, 20 de septiembre de 2017, 12:45 Para: , Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info =20 =20 On 9/19/17, 8:23 AM, "v6ops on behalf of JORDI PALET MARTINEZ" wrote: =20 >Hi all, > >RFC6877 (464XLAT) is an informational document. >... > >Can we even consider moving it to STD? =20 =20 I don=E2=80=99t think v6ops can promote it to Standard, or Standards Tr= ack. Our charter doesn=E2=80=99t explicitly say we=E2=80=99re not allowed to do = standards work, but I would want to hear from our AD and check with 6man before promoting i= t. =20 Generally, the two tests are rough consensus and multiple interoperable implementations.=20 =20 Lee =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Sep 20 10:20:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B282813232C for ; Wed, 20 Sep 2017 10:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zbFFlOhO3u7l for ; Wed, 20 Sep 2017 10:20:25 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17233124207 for ; Wed, 20 Sep 2017 10:20:24 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 93FFD442AE for ; Wed, 20 Sep 2017 19:20:22 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 7CACF442A9; Wed, 20 Sep 2017 19:20:22 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 63AFF33014; Wed, 20 Sep 2017 19:20:22 +0200 (CEST) Date: Wed, 20 Sep 2017 19:20:22 +0200 From: Gert Doering To: Brian E Carpenter Cc: Philip Homburg , v6ops@ietf.org Message-ID: <20170920172022.GB45648@Space.Net> References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 17:20:26 -0000 Hi, On Tue, Sep 12, 2017 at 12:59:02PM +1200, Brian E Carpenter wrote: > The thing is that if a home network includes a Windows 98 client and a > Windows 10 client, and has no WAN IPv4 service, there will be dual stack > sites that are accessible from Windows 10 and unreachable from Windows 98. > That translates into help desk calls. If there is a future home network that has IPv6, no IPv4, and *Windows 98*, IPv6-only is the least of the worries that the owner of said network should have... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Sep 20 12:36:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FBF134319 for ; Wed, 20 Sep 2017 12:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.596 X-Spam-Level: X-Spam-Status: No, score=-3.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, FUZZY_MILLION=2.505, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp_LARuiNJx7 for ; Wed, 20 Sep 2017 12:36:48 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9759B13430E for ; Wed, 20 Sep 2017 12:36:47 -0700 (PDT) Received: from rev-2001-13c7-7003-eventos.lacnic.net (rev-2001-13c7-7003-eventos.lacnic.net [IPv6:2001:13c7:7003:200:20c6:84e8:735b:93df] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v8KJZf4W007367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Sep 2017 12:35:45 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> Date: Wed, 20 Sep 2017 16:35:43 -0300 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Wed, 20 Sep 2017 12:35:46 -0700 (PDT) Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 19:36:51 -0000 > On Sep 20, 2017, at 12:26 PM, Alexandre Petrescu = wrote: >=20 >=20 >=20 > Le 20/09/2017 =C3=A0 17:13, Owen DeLong a =C3=A9crit : >>> On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu = > = wrote: >>>=20 >>>=20 >>>=20 >>> Le 20/09/2017 =C3=A0 15:35, JORDI PALET MARTINEZ a =C3=A9crit : >>>> Why you try to mix things? >>>=20 >>> I dont mix. You want a unique STdsTRack. Do you think the place is = empty? >> I=E2=80=99m not sure where you get =E2=80=9Cunique=E2=80=9D. I think = Jordi wants 464XLAT moved to Standards track rather than informational. = I don=E2=80=99t see anything about unique in his request. >>> As I said already, there is already IPv6-in-GTP for transitioning = and DHCPv6-PD for Prefix Delegation. These are standards. >> I guess the question I have for this statement is =E2=80=9Cwhy is = this relevant to whether or not we move 464XLAT >> to standard?=E2=80=9D >=20 > BEcause 464XLAT is a transitioning mechanism and IPv6-in-GTP is a = transitioning mechanism too, which is deployed too. So what? ISIS is a Standard and so is OSPF=E2=80=A6 both are IGPs. For that matter, so is RIPv2. There are lots of cases where more than one solution to the same problem = becomes a standards track RFC. For that matter, DHCPv6 and SLAAC are both standards. Both do address = assignment. >=20 >>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a way to = provision addresses/prefixes. >>>> No sense to mix all them. >>>=20 >>> That's a problem. You want them to work together, not to compete. >> This makes no sense to me. IMHO, they don=E2=80=99t compete and CLAT = can work regardless of how the IPv6 address on the client is obtained, = whether SLAAC, DHCPv6, static, or otherwise. >=20 > But you dont want CLAT's IPv6-in-IPv4 together with GTP encapsulation = - that's too many encapsulations. True, but I don=E2=80=99t want ISIS and OSPF running on the same links, = either. Not sure I understand why this is a relevant topic here. Operators are = capable of choosing the standard that best meets their needs from = multiple standards. Choice is often a good thing. This is an example of = such a case. >=20 >>> You want them to have different functions. >> CLAT doesn=E2=80=99t have an IPv6 address assignment function so they = do, in fact, have different functions. >>> But the function to get a prefix is a unique function. >> CLAT doesn=E2=80=99t have anything to do with getting a prefix for = IPv6. >=20 > But it only works with a /64. It means it cant work when DHCPv6-PD = gives it a /63. You=E2=80=99re making no sense here. An interface would still get a /64 = from the /63 or /56 or /48 or whatever, so CLAT would still be perfectly = capable of operating after the /64 was assigned to the interface. >=20 >>>> Many other transition mechanisms don=E2=80=99t state if SLAAC or = DHCPv6 is used or not, and I think is perfectly correct. >>>=20 >>> Most of them are not dynamic in nature anyways, whereas CLAT seems = to be. >> My understanding is that CLAT is dynamic only on the IPv4 side. On = the IPv6 side, to the best of my knowledge, it just uses whatever IPv6 = address is available on the client=E2=80=99s interface(s). >>> As long as they dont claim, and they abstain from to dynamically set = a prefix on the network they are fine with respect to DHCP-PD. >>>=20 >>> But once CLAT gets into statements qualifying which is better = SLAAC-vs-DHCP then we have a big problem. >> Sigh=E2=80=A6 I agree that there=E2=80=99s no reason for CLAT to make = any such statement. If the current CLAT RFC(s) do, then, perhaps we = should argue for cleaning that up as part of the process of moving = towards a standards track RFC, but if that=E2=80=99s what you=E2=80=99re = on about here, then just say that. You=E2=80=99ve wasted multiple = messages talking about completely orthogonal issues where the above = statement is the first clue you=E2=80=99ve provided about what is = apparently your actual concern. >=20 > I dont think it's orthogonal. It really is. Really. Owen >=20 > Alex >> Owen >>>=20 >>> Alex >>>=20 >>>> Regarsd, >>>> Jordi >>>> -----Mensaje original----- >>>> De: v6ops > = en nombre de Alexandre Petrescu > >>>> Responder a: > >>>> Fecha: mi=C3=A9rcoles, 20 de septiembre de 2017, 10:28 >>>> Para: > >>>> Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify = 464XLAT as standard instead of info >>>> Le 20/09/2017 =C3=A0 15:19, JORDI PALET MARTINEZ a = =C3=A9crit : >>>> > Google is your friend: >>>> > >>>> > = https://android.googlesource.com/platform/external/android-clat/ >>>> Google is my friend. >>>> Ctrl-F also, and that page does not seem to display any = correction that >>>> says "DHCP" in the last 3 and a half years. >>>> But I think CLAT should run DHCP somehow, otherwise it's a = non standard >>>> way to get Prefix Delegation. Does it? (I may download it = later and >>>> look at it). >>>> As long as these two things stay distinct they are in = competition. >>>> Once you make 464XLAT StdsTrack you cant also keep = DHCPv6-PD as >>>> StdsTrack - they are on the same layer. >>>> But yes, you can keep XMPP on the StdsTrack, because it's = on another layer. >>>> Alex >>>> > >>>> > Same for other questions that you asked before =E2=80=A6 you = can find it also for OpenWRT. >>>> > >>>> > Regards, >>>> > Jordi >>>> > >>>> > >>>> > -----Mensaje original----- >>>> > De: v6ops > en nombre de Alexandre Petrescu = > >>>> > Responder a: > >>>> > Fecha: mi=C3=A9rcoles, 20 de septiembre de 2017, 9:55 >>>> > Para: Erik Kline > >>>> > CC: "v6ops@ietf.org " > >>>> > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of = info >>>> > >>>> > No need to stress terms like billions; that's what modem = manufacturers >>>> > put on the market too routinely. Maybe we can talk = trillions of IoT >>>> > devices. Maybe we can use the SI prefixes, like exa, or = peta. >>>> > >>>> > That aside, I would like to ask you whether the CLAT src = on Android is >>>> > something I could look at? >>>> > >>>> > Alex >>>> > >>>> > Le 20/09/2017 =C3=A0 08:03, Erik Kline a =C3=A9crit : >>>> > > There seem to be some misconceptions flying around = here. >>>> > > >>>> > >> Well, I dont think 464XLAT is deployed anywhere else = than on cellular. These >>>> > >> are the big numbers that the Original Poster talked = about: miliions of users >>>> > >> - they are on cellular. >>>> > > >>>> > > 464xlat is a client-side bit of code (the NAT64+DNS64 = in the network >>>> > > is the "other half"). It is primarily implemented in = mobile devices, >>>> > > and primarily in Android, to be more specific. >>>> > > >>>> > > As such, the number of 464xlat capable nodes is = numbered in the /billions/. >>>> > > >>>> > > There are also some wifi (and wired) networks that are = IPv6-only with >>>> > > NAT64+DNS64; mobile networks aren't the only ones. >>>> > > >>>> > > NAT64+DNS64 is easily the single most successful IPv6 = transition >>>> > > technology on the planet ([a] if one excludes = "dualstack", [b] queue >>>> > > the Sean Spicer jokes). 464xlat can help ease things = on the client >>>> > > side, but it's not the only way to do it (cf. iOS). >>>> > > >>>> > >>>> > _______________________________________________ >>>> > v6ops mailing list >>>> > v6ops@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/v6ops >>>> > >>>> > >>>> > >>>> > >>>> > ********************************************** >>>> > IPv4 is over >>>> > Are you ready for the new Internet ? >>>> > http://www.consulintel.es >>>> > The IPv6 Company >>>> > >>>> > This electronic message contains information which may be = privileged or confidential. The information is intended to be for the = exclusive use of the individual(s) named above and further = non-explicilty authorized disclosure, copying, distribution or use of = the contents of this information, even if partially, including attached = files, is strictly prohibited and will be considered a criminal offense. = If you are not the intended recipient be aware that any disclosure, = copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited, will be = considered a criminal offense, so you must reply to the original sender = to inform about this communication and delete it. >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > v6ops mailing list >>>> > v6ops@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/v6ops >>>> > >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> ********************************************** >>>> IPv4 is over >>>> Are you ready for the new Internet ? >>>> http://www.consulintel.es >>>> The IPv6 Company >>>> This electronic message contains information which may be = privileged or confidential. The information is intended to be for the = exclusive use of the individual(s) named above and further = non-explicilty authorized disclosure, copying, distribution or use of = the contents of this information, even if partially, including attached = files, is strictly prohibited and will be considered a criminal offense. = If you are not the intended recipient be aware that any disclosure, = copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited, will be = considered a criminal offense, so you must reply to the original sender = to inform about this communication and delete it. >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Sep 20 12:38:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB9E134319 for ; Wed, 20 Sep 2017 12:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNOycfqfZ6yA for ; Wed, 20 Sep 2017 12:38:34 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1769913430E for ; Wed, 20 Sep 2017 12:38:33 -0700 (PDT) Received: from [45.6.255.5] ([45.6.255.5]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v8KJbO28007531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Sep 2017 12:37:29 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: Date: Wed, 20 Sep 2017 16:37:27 -0300 Cc: Alexandre Petrescu , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> To: Erik Kline X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Wed, 20 Sep 2017 12:37:30 -0700 (PDT) Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 19:38:35 -0000 > On Sep 20, 2017, at 12:21 PM, Erik Kline wrote: >=20 >> Ctrl-F also, and that page does not seem to display any correction = that says >> "DHCP" in the last 3 and a half years. >>=20 >> But I think CLAT should run DHCP somehow, otherwise it's a non = standard way >> to get Prefix Delegation. Does it? (I may download it later and = look at >> it). >=20 > There is no PD wrt 464xlat. The /64 is implicitly delegated to the > mobile per the 3GPP architecture, as I'm sure you well know. Isn=E2=80=99t that an artifact of 3GPP and not 464XLAT? My understanding is that 464XLAT CLAT can work with any interface that = has a /64 on the interface, regardless of how it was assigned to the = interface. > If you want to know how the device learns the DNS64/NAT64 prefix then > see https://tools.ietf.org/html/rfc7050 . If 3GPP is baked into 464XLAT, then I agree we still have work to = generalize it before making it STD. Owen From nobody Wed Sep 20 13:35:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6FF1320B5 for ; Wed, 20 Sep 2017 13:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwK5nnh0Qc8U for ; Wed, 20 Sep 2017 13:35:17 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0D81321D8 for ; Wed, 20 Sep 2017 13:35:16 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id y29so2105233pff.0 for ; Wed, 20 Sep 2017 13:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=di1STYImEM/iqZEskvp/o8IVoUmgipxr6qz/TUQ4J+0=; b=h40LANdKbCL47jt7+5jZhuVbKKbNX6V05apBgLnJPgP8jF6rbcrj7tVpJXMrRHJNwu W/3+5gLv4o+hKwv6mQUbpVkeaNMvQqEQAx5Ua3pWzMnXJYLGNiuwUt/kLOXgpu5+RtZe nHzMs0SNxgChsozO+Qct5KpjYxkImkFAZzlCP2QidwsHgqkHgkYtnRcVxZpYO+r+Kt6Q VXy5hYdfeHUPMKS0gUnUR/rZ52anPKponNO0cPbBlflCR2zJtBBRBH8XkCIpc0LAAiyJ 6m33cXcM3jYL861NiA8ouc2nvHrtqYvdczD+5mLCgvJQQSLqRxcGgPfm6ArqSHReWwa/ FjqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=di1STYImEM/iqZEskvp/o8IVoUmgipxr6qz/TUQ4J+0=; b=THCgEj+e8cLWFyM7Y1/XK7C+uD397Fwn8SmQv5OpwthMf5DEqozQbC7QHc5hIrbWpJ 1Ke0iXDWfyK/zK/romcse0DTsTY5mTq0hme1WW1COJueXhruv99YRzAoQoa/qA/49K3G tuwrCGQVfS9HvCiuCgO6PtfuYtSGGc9iCDufSqHjotnc7OZDtKemwkZaV2Pnl9PQs6T9 5Turamsh+DOFW0Jdbk2KN0FCz4Db+nukLQMURxhUdL/8dggLb1uBZTtliQzRVKhRtwX2 9+PfrW+GH71V+iwkoEHofMF39k7ezTpTkjiZ/vqni0Y0PcOMIvNFOEH14E+gNEqslHsP CWpQ== X-Gm-Message-State: AHPjjUhsSa31hFutHozmNx3fch2MfTALHTd6jfXNRAXza0+HTS87AO94 3j8qcq0PxaPrTxthJgacLfVZ5/rz X-Google-Smtp-Source: AOwi7QAq0Efdrylh09FNRYaxhBuSE1Yeg206dr9pp3yToPMzeLHWeH1lqcU1t2HVb+2ZtgCZsyFt8A== X-Received: by 10.84.238.206 with SMTP id l14mr3250705pln.156.1505939715358; Wed, 20 Sep 2017 13:35:15 -0700 (PDT) Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s68sm10966401pfd.72.2017.09.20.13.35.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 13:35:14 -0700 (PDT) To: Gert Doering Cc: Philip Homburg , v6ops@ietf.org References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> <20170920172022.GB45648@Space.Net> From: Brian E Carpenter Organization: University of Auckland Message-ID: <1a1fa476-ae2a-cf0a-f30c-473ff26da5b1@gmail.com> Date: Thu, 21 Sep 2017 08:35:18 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170920172022.GB45648@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 20:35:19 -0000 On 21/09/2017 05:20, Gert Doering wrote: > Hi, > > On Tue, Sep 12, 2017 at 12:59:02PM +1200, Brian E Carpenter wrote: >> The thing is that if a home network includes a Windows 98 client and a >> Windows 10 client, and has no WAN IPv4 service, there will be dual stack >> sites that are accessible from Windows 10 and unreachable from Windows 98. >> That translates into help desk calls. > > If there is a future home network that has IPv6, no IPv4, and *Windows 98*, > IPv6-only is the least of the worries that the owner of said network > should have... You're missing my point. Obviously Win98 was a provocative example, but the point is that ISPs will do whatever they have to do to avoid help desk calls. If switching off IPv4 generates help desk calls, they will never do it. EOM. Brian From nobody Wed Sep 20 13:55:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D958C1321D8 for ; Wed, 20 Sep 2017 13:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyiSsxSQ0txg for ; Wed, 20 Sep 2017 13:55:08 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DBF1320D8 for ; Wed, 20 Sep 2017 13:55:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8KKt3AG036410; Wed, 20 Sep 2017 22:55:03 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 72C0F20EC9E; Wed, 20 Sep 2017 22:55:03 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6538520EDBB; Wed, 20 Sep 2017 22:55:03 +0200 (CEST) Received: from [132.166.84.33] ([132.166.84.33]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8KKt2uC005923; Wed, 20 Sep 2017 22:55:03 +0200 To: Owen DeLong Cc: v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> From: Alexandre Petrescu Message-ID: Date: Wed, 20 Sep 2017 22:55:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 20:55:11 -0000 Le 20/09/2017 à 21:35, Owen DeLong a écrit : > >> On Sep 20, 2017, at 12:26 PM, Alexandre Petrescu >> wrote: >> >> >> >> Le 20/09/2017 à 17:13, Owen DeLong a écrit : >>>> On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu >>>> >>> > wrote: >>>> >>>> >>>> >>>> Le 20/09/2017 à 15:35, JORDI PALET MARTINEZ a écrit : >>>>> Why you try to mix things? >>>> >>>> I dont mix. You want a unique STdsTRack. Do you think the >>>> place is empty? >>> I’m not sure where you get “unique”. I think Jordi wants 464XLAT >>> moved to Standards track rather than informational. I don’t see >>> anything about unique in his request. >>>> As I said already, there is already IPv6-in-GTP for >>>> transitioning and DHCPv6-PD for Prefix Delegation. These are >>>> standards. >>> I guess the question I have for this statement is “why is this >>> relevant to whether or not we move 464XLAT to standard?” >> >> BEcause 464XLAT is a transitioning mechanism and IPv6-in-GTP is a >> transitioning mechanism too, which is deployed too. > > So what? > > ISIS is a Standard and so is OSPF… both are IGPs. For that matter, > so is RIPv2. YEs, and each uses some distinct number, maybe a UDP port number. They can work simultaneously on a Router. But you cant have simultaneously CLAT and DHCPv6-PD on the same client. Because CLAT wants that to be a /64 prefix. It will break when the client gets a /63. Moreover, design suggestions from CLAT assume that /64 is sufficient. That is wrong - /64 is not sufficient. > There are lots of cases where more than one solution to the same > problem becomes a standards track RFC. But one wont prohibit the other. CLAT prohibits DHCPv6-PD. > For that matter, DHCPv6 and SLAAC are both standards. Both do > address assignment. Err, I agree. Yet CLAT does not agree. CLAT does not rely on DHCP to get an address. Why? IT does not rely on DHCPv6-PD to get a prefix. Why? >>>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a >>>>> way to provision addresses/prefixes. No sense to mix all >>>>> them. >>>> >>>> That's a problem. You want them to work together, not to >>>> compete. >>> This makes no sense to me. IMHO, they don’t compete and CLAT can >>> work regardless of how the IPv6 address on the client is >>> obtained, whether SLAAC, DHCPv6, static, or otherwise. >> >> But you dont want CLAT's IPv6-in-IPv4 together with GTP >> encapsulation - that's too many encapsulations. > > True, but I don’t want ISIS and OSPF running on the same links, > either. At some point there is some Gateway that is possible, which runs both protocols OSPF and ISIS. But there cant be conversion between CLAT and DHCP. > Not sure I understand why this is a relevant topic here. Operators > are capable of choosing the standard that best meets their needs > from multiple standards. Choice is often a good thing. This is an > example of such a case. Operators are influenced by Device availability. If Android is what is available, then operators want to satisfy this. If Android does CLAT, then operators choose to not implement DHCPv6-PD, because DHCPv6-PD is part of DHCPv6, and because CLAT does not need DHCPv6. I dont know how to explain this better to you. Android is very important to operators. >>>> You want them to have different functions. >>> CLAT doesn’t have an IPv6 address assignment function so they >>> do, in fact, have different functions. >>>> But the function to get a prefix is a unique function. >>> CLAT doesn’t have anything to do with getting a prefix for IPv6. >> >> But it only works with a /64. It means it cant work when >> DHCPv6-PD gives it a /63. > > You’re making no sense here. An interface would still get a /64 from > the /63 or /56 or /48 or whatever, so CLAT would still be perfectly > capable of operating after the /64 was assigned to the interface. To be tried, before arguing. Can you try? Do you think a WiFi tablet behind a smartphone-on-cellular that uses a prefix obtained with DHCPv6-PD and re-advertised with RA would be able to get through that CLAT ok, and talk to IPv4 servers? If you could try this, then we can have an answer on whether or not I make sense. Before that, we cant say CLAT and DHCPv6-PD are ok. >>>>> Many other transition mechanisms don’t state if SLAAC or >>>>> DHCPv6 is used or not, and I think is perfectly correct. >>>> >>>> Most of them are not dynamic in nature anyways, whereas CLAT >>>> seems to be. >>> My understanding is that CLAT is dynamic only on the IPv4 side. >>> On the IPv6 side, to the best of my knowledge, it just uses >>> whatever IPv6 address is available on the client’s interface(s). >>>> As long as they dont claim, and they abstain from to >>>> dynamically set a prefix on the network they are fine with >>>> respect to DHCP-PD. >>>> >>>> But once CLAT gets into statements qualifying which is better >>>> SLAAC-vs-DHCP then we have a big problem. >>> Sigh… I agree that there’s no reason for CLAT to make any such >>> statement. If the current CLAT RFC(s) do, then, perhaps we >>> should argue for cleaning that up as part of the process of >>> moving towards a standards track RFC, but if that’s what you’re >>> on about here, then just say that. You’ve wasted multiple >>> messages talking about completely orthogonal issues where the >>> above statement is the first clue you’ve provided about what is >>> apparently your actual concern. >> >> I dont think it's orthogonal. > > It really is. I tell you it is not. As long as CLAT does not agree there is DHCPv6-PD and IPv6-in-GTP then we have little to talk about. We have a new transition method that appeared just because an OS creator (Android) is not able, or not willing(?) to push their own suppliers hardware vendors into implementing forwarding of DHCPv6-PD into their modems. Android created a software tool (CLAT) that is totally runnable in the linux (not in the modem), so it is totally under their control (not modem) just to avoid the hardware modem problem. That's not the right thing to do: the modem has to be fixed. Android CLAT is also ignoring that IPv6-in-GTP exists (GTP is an IPv4 protocol at 3GPP), because the GTP part happens in the modem, and Android does not control the modem. If Android wanted "IPv6-only" devices then the right thing to do is to create an IPv6 version of GTP, or, even better, get rid of GTP altogheter. But that again - it's in the modem. Nothing of this is orthogonal to CLAT: CLAT does some things because the modem is forcing it into doing. Alex From nobody Wed Sep 20 14:41:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3BC1320D8 for ; Wed, 20 Sep 2017 14:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VqTL1iXvrhEE for ; Wed, 20 Sep 2017 14:41:56 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CB212421A for ; Wed, 20 Sep 2017 14:41:56 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 6A42C2D4FE9; Wed, 20 Sep 2017 21:41:54 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D7BDC10B89917; Wed, 20 Sep 2017 23:41:52 +0200 (CEST) From: Ole Troan Message-Id: <3F99667F-56A6-487E-9AA6-D0FCB0BB4450@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_16E5F533-45BB-4806-8552-02AB95FA84A8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 20 Sep 2017 23:41:51 +0200 In-Reply-To: Cc: Owen DeLong , v6ops@ietf.org To: Alexandre Petrescu References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 21:41:57 -0000 --Apple-Mail=_16E5F533-45BB-4806-8552-02AB95FA84A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > But you cant have simultaneously CLAT and DHCPv6-PD on the same = client. > Because CLAT wants that to be a /64 prefix. It will break when the > client gets a /63. >=20 > Moreover, design suggestions from CLAT assume that /64 is sufficient. > That is wrong - /64 is not sufficient. >=20 >> There are lots of cases where more than one solution to the same = problem becomes a standards track RFC. >=20 > But one wont prohibit the other. >=20 > CLAT prohibits DHCPv6-PD. RFC6877 section 6.3 states the opposite. Ole --Apple-Mail=_16E5F533-45BB-4806-8552-02AB95FA84A8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZwuCgAAoJEL7aWKiYQt92vOYQALJVgYf/XYluCGWGF6y1XiEj xc1VZE2thx4NhjhF/rpxIEYIELgl8mJcqEDoz9ioLAHjL7OnOkRxWjzd82CLmcXa M0K0KkA2bK9YL08MWLYv4FEpCJYOK8/+QH6SZ4pronN3yGWXx1fajPG1XQFBiOBb G3C589iPO7/jxM8jwWlPiUeV4ca+qmOQ3CbElhJrEIZNnpdPf5wNajLDx+Q8IaPS rSrgu4OKopCq6N24pF5MM/2peKXad2zxNy6sWGB8Xc1RnwSTZB8hKGKbhfjuNclw Lc7YH1Ubae603PMnnQPtda5Eti+kg7hEXww0Awme+9xpUl0q9pcbXCo3OcuAEDk3 7G8zl8W55ycMq5UHbzN3IdmTdaLpH5seRYZChW8y47r8YWK2ch/cIbJEgacCJjcq d5nlNYyY8LnRIrdX+E6jBqkp1Z5jrKKzjcgeA9vXeCVXrGoqQtSxexVRhv7eWm2A 51AIxBLPBYzIg26TPacDA/c4g0nZe7jYVRD/yQFdqJvj9GCdbgUslxZAVRlM3r8o fhCKaTLWpEx1+RQAvIiJhfGQLnlm3fAb2sHY2H6FRkxTCq0n3DV+R01GPlKE9WW7 s9+aOlmLbjvNSVXXloMKZIm5Bm+MzyKMVgMIcEcY6kQeYPvQYUKW+BIgynt7NN5e a7ygTAXbkzOtnOTHuR29 =JduE -----END PGP SIGNATURE----- --Apple-Mail=_16E5F533-45BB-4806-8552-02AB95FA84A8-- From nobody Wed Sep 20 14:44:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7AE13422B for ; Wed, 20 Sep 2017 14:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGXhCPUpCNw6 for ; Wed, 20 Sep 2017 14:44:44 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 339D812421A for ; Wed, 20 Sep 2017 14:44:44 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id D05A02D5060; Wed, 20 Sep 2017 21:44:43 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B2F1110B8A61C; Wed, 20 Sep 2017 23:44:41 +0200 (CEST) From: Ole Troan Message-Id: <30557544-8312-4361-8CD4-E819E8C97814@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_4961FD43-FD71-4729-A25C-86241DE1844A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 20 Sep 2017 23:44:41 +0200 In-Reply-To: Cc: jordi.palet@consulintel.es, v6ops@ietf.org To: Lee Howard References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 21:44:45 -0000 --Apple-Mail=_4961FD43-FD71-4729-A25C-86241DE1844A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> RFC6877 (464XLAT) is an informational document. >> ... >>=20 >> Can we even consider moving it to STD? >=20 >=20 > I don=E2=80=99t think v6ops can promote it to Standard, or Standards = Track. Our > charter doesn=E2=80=99t explicitly say we=E2=80=99re not allowed to do = standards work, but > I would want to hear from our AD and check with 6man before promoting = it. 6man doesn't do IPv4. > Generally, the two tests are rough consensus and multiple = interoperable > implementations. Ole --Apple-Mail=_4961FD43-FD71-4729-A25C-86241DE1844A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZwuFJAAoJEL7aWKiYQt92gWcQAKYv9HLcQt8SeP2X6gdwvp99 0l/fcu/gMtnhQuPOMVVBmCanLfayYxg/g/ekHogg4b1kiU2Hpoe0CJiZwb1A4czW AqfbQcrZkJN69/FV02uaSKUqncgJ60Gmk0Yf8pFm4EdpckSkNOwQSbPEN3Ba0g4a T5zsTfk+4EVvUhB5B381NrOEM5CmK3CTHWXTQSAoQS3nVz4WUWElVF7NJard5Rci /tmJk0ioRJ0nW8wEiuiwOh5/U++ZKBUU55Ya6w7ixYhPZppxQunEEIhkFWc2VBvi mvLx+dNjeO7FDc2kWMXwkdh3o/uP9a1kSgjgEAOaXkS3/FCAhDJMFVo3h5oj5q7v ow04t1s7syn8so+lwUjTsuQ091e7eTNjyCTzn3Qcm1DMn2sN9eweWWbD5cOx6w6N Tvzgmt8mkGgcthU2JYWKLWFB+aIcc2h+T3piA5IZff5liA/c+r1bXfBnCQDm2hv0 CMOKChO1qRzPe/3TvWws6bAXaLxtM/ROkcb6pBe8CAZQtRRAVkNg4m+IY7imDWpI 7sprDUIUB12Z0C+TvZouYempV65h2kgpRY1emmqhw27Pi4eLZnv6ivxcJdGD8KvB 1I4gyOP6YftjxJDV6NJ6ExUcQECqjH4bvWtw9AVYO+QhpTu2p2w6zMgZUC2jF4/F cNAnUVVpj5lHl67dhvqT =F9UL -----END PGP SIGNATURE----- --Apple-Mail=_4961FD43-FD71-4729-A25C-86241DE1844A-- From nobody Wed Sep 20 15:29:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D331321CB for ; Wed, 20 Sep 2017 15:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9hTk0o7rH9q for ; Wed, 20 Sep 2017 15:29:51 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD7B1320D8 for ; Wed, 20 Sep 2017 15:29:51 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id i6so2914083ywc.9 for ; Wed, 20 Sep 2017 15:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cm9LUtduWg1VyoGawM3UemP9ooMCbQPDxLX4mxrR8SY=; b=a9SFWVCn99pZKj1WqdjaH+xKUtzLkb+t1quN4qGHh0kKT5PLYnW3PF/HFU6JkrvWox mVk6+HElLK4J+itdaiZaNFoPOuUBWQYWJhLwQqV0GXCqcIA4fdtlxqbZpA60yiF202mU ZVfmvzTs4q5bjdiZX65uXjEeKGcYLf/ViOD9o3qJEzTrJjRiRG4UU9P98T7agfrLrsr4 mwc5focSm2BTLmFlPQ334pxqGAwOH8oss5f3fGQYTPDMB3M7lIuMEoCLQ4HYVyx4PhyE vOAjFfgkoY7w8J8xOwnBLriNXQ2lVtOwwHtsRAh648Nr1YE22qlb6XyxpWDhqMkSNYdt yqYg== 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=Cm9LUtduWg1VyoGawM3UemP9ooMCbQPDxLX4mxrR8SY=; b=npt5VFPkeUMxzAQlBJ6SJjUX8XF24BjK1+19qOsaHQk03aCX48P1B9WPkbJDZqUT4F LsggKQbfH2ZGW7XjfAYI3z5S0o1palgxNDYMWy01I7+/oyIqNNr3+gievBPCBwDjej/z ciCapcVQblvq8W30GgFpDaOMsK14bZ3oIsg43M5+FecI78T0jYEd7GoSKgU2i7DniPc8 1aPYNZyd3fZ+4sGKuXm1vVe/okVw1+Jn3nQNPJbZz/EYU616of3lAzuZoP8sJr8WEMGU JwOS215qtPfOSdoLVNRBrkMpLNosvmbUa3jZj4gX5a0mfSpYFhzO4bumDPSnBjyxCok7 DNxQ== X-Gm-Message-State: AHPjjUiywRLMlLi4pSvB/kl148u9iOy4Q0+RxU6lv3CvD+3aatT3Byop HsgQpUEPugOSUh/2c0vj0Rp2jkINsLwznrt3OU4= X-Google-Smtp-Source: AOwi7QCNNqrCWSZ7ztG4d4kn193afgBxlNZNjpHG3poNY6WO6oL9bRLBnLY9JDsMdTq+m7jvryE+/oFGBJkuaPiYPOo= X-Received: by 10.129.232.4 with SMTP id a4mr185783ywm.294.1505946590830; Wed, 20 Sep 2017 15:29:50 -0700 (PDT) MIME-Version: 1.0 References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> In-Reply-To: From: Ca By Date: Wed, 20 Sep 2017 22:29:39 +0000 Message-ID: To: Alexandre Petrescu , Owen DeLong Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="089e082230a498ff320559a68319" Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 22:29:54 -0000 --089e082230a498ff320559a68319 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alexandre, There are several statements you made that i not consistent with my understanding. On Wed, Sep 20, 2017 at 1:55 PM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Le 20/09/2017 =C3=A0 21:35, Owen DeLong a =C3=A9crit : > > > >> On Sep 20, 2017, at 12:26 PM, Alexandre Petrescu > >> wrote: > >> > >> > >> > >> Le 20/09/2017 =C3=A0 17:13, Owen DeLong a =C3=A9crit : > >>>> On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu > >>>> >>>> > wrote: > >>>> > >>>> > >>>> > >>>> Le 20/09/2017 =C3=A0 15:35, JORDI PALET MARTINEZ a =C3=A9crit : > >>>>> Why you try to mix things? > >>>> > >>>> I dont mix. You want a unique STdsTRack. Do you think the > >>>> place is empty? > >>> I=E2=80=99m not sure where you get =E2=80=9Cunique=E2=80=9D. I think = Jordi wants 464XLAT > >>> moved to Standards track rather than informational. I don=E2=80=99t s= ee > >>> anything about unique in his request. > >>>> As I said already, there is already IPv6-in-GTP for > >>>> transitioning and DHCPv6-PD for Prefix Delegation. These are > >>>> standards. > >>> I guess the question I have for this statement is =E2=80=9Cwhy is thi= s > >>> relevant to whether or not we move 464XLAT to standard?=E2=80=9D > >> > >> BEcause 464XLAT is a transitioning mechanism and IPv6-in-GTP is a > >> transitioning mechanism too, which is deployed too. > > IPv6-in-GTP is a transport mechanism with mobility. It does not help an ipv6-only node communicate with an ipv4 internet. That said, my deployment includes both IPv6-in-GTP and 464xlat simulatenously > > So what? > > > > ISIS is a Standard and so is OSPF=E2=80=A6 both are IGPs. For that matt= er, > > so is RIPv2. > > YEs, and each uses some distinct number, maybe a UDP port number. They > can work simultaneously on a Router. > > But you cant have simultaneously CLAT and DHCPv6-PD on the same client. I do not agree, Please state what is structurally preventing this. RFC6877 specifically calls for using dhcpv6-pd > Because CLAT wants that to be a /64 prefix. It will break when the > client gets a /63. > It requires a /64, which may come to the CLAT via a /56 via dhcpv6-pd > Moreover, design suggestions from CLAT assume that /64 is sufficient. > That is wrong - /64 is not sufficient. It is sufficient for CLAT function of execuating rfc6145. CLAT just rfc6145. > > > There are lots of cases where more than one solution to the same > > problem becomes a standards track RFC. > > But one wont prohibit the other. > > CLAT prohibits DHCPv6-PD. > Not correct. > > For that matter, DHCPv6 and SLAAC are both standards. Both do > > address assignment. > > Err, I agree. Yet CLAT does not agree. CLAT does not rely on DHCP to > get an address. Why? IT does not rely on DHCPv6-PD to get a prefix. Wh= y? > > >>>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a > >>>>> way to provision addresses/prefixes. No sense to mix all > >>>>> them. > >>>> > >>>> That's a problem. You want them to work together, not to > >>>> compete. > >>> This makes no sense to me. IMHO, they don=E2=80=99t compete and CLAT = can > >>> work regardless of how the IPv6 address on the client is > >>> obtained, whether SLAAC, DHCPv6, static, or otherwise. > >> > >> But you dont want CLAT's IPv6-in-IPv4 together with GTP > >> encapsulation - that's too many encapsulations. > > > > True, but I don=E2=80=99t want ISIS and OSPF running on the same links, > > either. > > At some point there is some Gateway that is possible, which runs both > protocols OSPF and ISIS. But there cant be conversion between CLAT and > DHCP. > Not correct, again. Please see rfc6877. > > Not sure I understand why this is a relevant topic here. Operators > > are capable of choosing the standard that best meets their needs > > from multiple standards. Choice is often a good thing. This is an > > example of such a case. > > Operators are influenced by Device availability. This operator (and esteamed co-authors) saw a problem, came to the ietf, worked with Android open source, worked with v6ops, and specified 464xlat. Device availabilty followed. If Android is what is > available, then operators want to satisfy this. If Android does CLAT, > then operators choose to not implement DHCPv6-PD, because DHCPv6-PD is > part of DHCPv6, and because CLAT does not need DHCPv6. > Again. Dhcpv6-pd and 464xlat are compatible and their deployment motivations are largely orthogonal. > I dont know how to explain this better to you. > > Android is very important to operators. > > >>>> You want them to have different functions. > >>> CLAT doesn=E2=80=99t have an IPv6 address assignment function so they > >>> do, in fact, have different functions. > >>>> But the function to get a prefix is a unique function. > >>> CLAT doesn=E2=80=99t have anything to do with getting a prefix for IP= v6. > >> > >> But it only works with a /64. It means it cant work when > >> DHCPv6-PD gives it a /63. > > > > You=E2=80=99re making no sense here. An interface would still get a /64= from > > the /63 or /56 or /48 or whatever, so CLAT would still be perfectly > > capable of operating after the /64 was assigned to the interface. > Owen is correct here. > To be tried, before arguing. > > Can you try? Seems you are the one interested in this area. The Android source code is available for you. > > Do you think a WiFi tablet behind a smartphone-on-cellular that uses a > prefix obtained with DHCPv6-PD and re-advertised with RA would be able > to get through that CLAT ok, and talk to IPv4 servers? > > If you could try this, then we can have an answer on whether or not I > make sense. > > Before that, we cant say CLAT and DHCPv6-PD are ok. > We can say the specification allows CLAT and DHCPv6-PD to work together. Running code is an exercise left to those with a demand for that usecase. > >>>>> Many other transition mechanisms don=E2=80=99t state if SLAAC or > >>>>> DHCPv6 is used or not, and I think is perfectly correct. > >>>> > >>>> Most of them are not dynamic in nature anyways, whereas CLAT > >>>> seems to be. > >>> My understanding is that CLAT is dynamic only on the IPv4 side. > >>> On the IPv6 side, to the best of my knowledge, it just uses > >>> whatever IPv6 address is available on the client=E2=80=99s interface(= s). > >>>> As long as they dont claim, and they abstain from to > >>>> dynamically set a prefix on the network they are fine with > >>>> respect to DHCP-PD. > >>>> > >>>> But once CLAT gets into statements qualifying which is better > >>>> SLAAC-vs-DHCP then we have a big problem. > >>> Sigh=E2=80=A6 I agree that there=E2=80=99s no reason for CLAT to make= any such > >>> statement. If the current CLAT RFC(s) do, then, perhaps we > >>> should argue for cleaning that up as part of the process of > >>> moving towards a standards track RFC, but if that=E2=80=99s what you= =E2=80=99re > >>> on about here, then just say that. You=E2=80=99ve wasted multiple > >>> messages talking about completely orthogonal issues where the > >>> above statement is the first clue you=E2=80=99ve provided about what = is > >>> apparently your actual concern. > >> > >> I dont think it's orthogonal. > > > > It really is. > > I tell you it is not. > agreeing with Owen, it is orthogonal. > As long as CLAT does not agree there is DHCPv6-PD and IPv6-in-GTP then > we have little to talk about. > 3 different things CLAT is just rfc6145 Ipv6-in-GTP is just an ip in UDP tunnel for mobility in 3gpp infrastructure, it has nothing to do with the internet or the UE Dhcpv6-pd ... assignes prefixes. 3 different and orthogonal things. > We have a new transition method that appeared just because an OS creator > (Android) is not able, or not willing(?) to push their own suppliers > hardware vendors into implementing forwarding of DHCPv6-PD into their > modems. > Again, 464xlat was not pushed by Android, it was pulled by operators in the ietf > Android created a software tool (CLAT) that is totally runnable in the > linux (not in the modem), so it is totally under their control (not > modem) just to avoid the hardware modem problem. That's not the right > thing to do: the modem has to be fixed. Modem is the wrong place ... > > Android CLAT is also ignoring that IPv6-in-GTP exists (GTP is an IPv4 > protocol at 3GPP), because the GTP part happens in the modem, and > Android does not control the modem. > > If Android wanted "IPv6-only" devices then the right thing to do is to > create an IPv6 version of GTP, or, even better, get rid of GTP > altogheter. But that again - it's in the modem. > > Nothing of this is orthogonal to CLAT: CLAT does some things because the > modem is forcing it into doing. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --089e082230a498ff320559a68319 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alexandre,

There are several statements you m= ade that i not consistent with my understanding.=C2=A0

On Wed, Sep 20, 2017 at 1:55 PM Alexandre Pe= trescu <alexandre.petres= cu@gmail.com> wrote:
Le 20/0= 9/2017 =C3=A0 21:35, Owen DeLong a =C3=A9crit :
>
>> On Sep 20, 2017, at 12:26 PM, Alexandre Petrescu
>> <alexandre.petrescu@gmail.com> wrote:
>>
>>
>>
>> Le 20/09/2017 =C3=A0 17:13, Owen DeLong a =C3=A9crit :
>>>> On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu
>>>> <alexandre.petrescu@gmail.com
>>>> <mailto:alexandre.petrescu@gmail.com>> wrote:
>>>>
>>>>
>>>>
>>>> Le 20/09/2017 =C3=A0 15:35, JORDI PALET MARTINEZ a =C3=A9c= rit :
>>>>> Why you try to mix things?
>>>>
>>>> I dont mix.=C2=A0 You want a unique STdsTRack.=C2=A0 Do yo= u think the
>>>> place is empty?
>>> I=E2=80=99m not sure where you get =E2=80=9Cunique=E2=80=9D. I= think Jordi wants 464XLAT
>>> moved to Standards track rather than informational. I don=E2= =80=99t see
>>> anything about unique in his request.
>>>> As I said already, there is already IPv6-in-GTP for
>>>> transitioning and DHCPv6-PD for Prefix Delegation. These a= re
>>>> standards.
>>> I guess the question I have for this statement is =E2=80=9Cwhy= is this
>>> relevant to whether or not we move 464XLAT to standard?=E2=80= =9D
>>
>> BEcause 464XLAT is a transitioning mechanism and IPv6-in-GTP is a<= br> >> transitioning mechanism too, which is deployed too.
>

IPv6-in-GTP = is a transport mechanism with mobility. It does not help an ipv6-only node = communicate with an ipv4 internet.=C2=A0

That said, my deployment includes both IPv6-in-GTP and= 464xlat simulatenously=C2=A0


> So what?
>
> ISIS is a Standard and so is OSPF=E2=80=A6 both are IGPs. For that mat= ter,
> so is RIPv2.

YEs, and each uses some distinct number, maybe a UDP port number.=C2=A0 The= y
can work simultaneously on a Router.

But you cant have simultaneously CLAT and DHCPv6-PD on the same client.

I do not agree, =C2= =A0Please state what is structurally preventing this.=C2=A0 RFC6877 specifi= cally calls for using dhcpv6-pd


=C2=A0 Because CLAT wants that to be a /64 prefix.=C2=A0 It will break when= the
client gets a /63.

It requires a /6= 4, which may come to the CLAT via a /56 via dhcpv6-pd=C2=A0


Moreover, design suggestions from CLAT assume that /64 is sufficient.
That is wrong - /64 is not sufficient.

It is sufficient for CLAT function of execuating rfc6= 145. CLAT just rfc6145.=C2=A0



> There are lots of cases where more than one solution to the same
> problem becomes a standards track RFC.

But one wont prohibit the other.

CLAT prohibits DHCPv6-PD.

Not correct. =C2= =A0


> For that matter, DHCPv6 and SLAAC are both standards. Both do
> address assignment.

Err, I agree.=C2=A0 Yet CLAT does not agree.=C2=A0 CLAT does not rely on DH= CP to
get an address.=C2=A0 Why?=C2=A0 IT does not rely on DHCPv6-PD to get a pre= fix.=C2=A0 Why?

>>>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) = is a
>>>>> way to provision addresses/prefixes. No sense to mix a= ll
>>>>> them.
>>>>
>>>> That's a problem.=C2=A0 You want them to work=C2=A0 to= gether, not to
>>>> compete.
>>> This makes no sense to me. IMHO, they don=E2=80=99t compete an= d CLAT can
>>> work regardless of how the IPv6 address on the client is
>>> obtained, whether SLAAC, DHCPv6, static, or otherwise.
>>
>> But you dont want CLAT's IPv6-in-IPv4 together with GTP
>> encapsulation - that's too many encapsulations.
>
> True, but I don=E2=80=99t want ISIS and OSPF running on the same links= ,
> either.

At some point there is some Gateway that is possible, which runs both
protocols OSPF and ISIS.=C2=A0 But there cant be conversion between CLAT an= d
DHCP.

Not correct, aga= in. Please see rfc6877.=C2=A0


> Not sure I understand why this is a relevant topic here. Operators
> are capable of choosing the standard that best meets their needs
> from multiple standards. Choice is often a good thing. This is an
> example of such a case.

Operators are influenced by Device availability.=C2=A0

This operator (and esteamed co-author= s) =C2=A0saw a problem, came to the ietf, worked with Android open source, = worked with v6ops, and specified 464xlat.=C2=A0

=
Device availabilty followed.=C2=A0

If Android is what is
available, then operators want to satisfy this.=C2=A0 If Android does CLAT,=
then operators choose to not implement DHCPv6-PD, because DHCPv6-PD is
part of DHCPv6, and because CLAT does not need DHCPv6.

Again. Dhcpv6-pd= and 464xlat are compatible and their deployment motivations are largely or= thogonal.=C2=A0


I dont know how to explain this better to you.

Android is very important to operators.

>>>> You want them to have different functions.
>>> CLAT doesn=E2=80=99t have an IPv6 address assignment function = so they
>>> do, in fact, have different functions.
>>>> But the function to get a prefix is a unique function.
>>> CLAT doesn=E2=80=99t have anything to do with getting a prefix= for IPv6.
>>
>> But it only works with a /64.=C2=A0 It means it cant work when
>> DHCPv6-PD gives it a /63.
>
> You=E2=80=99re making no sense here. An interface would still get a /6= 4 from
> the /63 or /56 or /48 or whatever, so CLAT would still be perfectly > capable of operating after the /64 was assigned to the interface.

Owen is correct = here.=C2=A0


To be tried, before arguing.

Can you try?

Seem= s you are the one interested in this area. =C2=A0
The Android source code is available for you.=C2= =A0



Do you think a WiFi tablet behind a smartphone-on-cellular that uses a
prefix obtained with DHCPv6-PD and re-advertised with RA would be able
to get through that CLAT ok, and talk to IPv4 servers?

If you could try this, then we can have an answer on whether or not I
make sense.

Before that, we cant say CLAT and DHCPv6-PD are ok.

We can say the s= pecification allows CLAT and DHCPv6-PD to work together.=C2=A0 Running code= is an exercise left to those with a demand for that usecase.=C2=A0



>>>>> Many other transition mechanisms don=E2=80=99t state i= f SLAAC or
>>>>> DHCPv6 is used or not, and I think is perfectly correc= t.
>>>>
>>>> Most of them are not dynamic in nature anyways, whereas CL= AT
>>>> seems to be.
>>> My understanding is that CLAT is dynamic only on the IPv4 side= .
>>> On the IPv6 side, to the best of my knowledge, it just uses >>> whatever IPv6 address is available on the client=E2=80=99s int= erface(s).
>>>> As long as they dont claim, and they abstain from to
>>>> dynamically set a prefix on the network they are fine with=
>>>> respect to DHCP-PD.
>>>>
>>>> But once CLAT gets into statements qualifying which is bet= ter
>>>> SLAAC-vs-DHCP then we have a big problem.
>>> Sigh=E2=80=A6 I agree that there=E2=80=99s no reason for CLAT = to make any such
>>> statement. If the current CLAT RFC(s) do, then, perhaps we
>>> should argue for cleaning that up as part of the process of >>> moving towards a standards track RFC, but if that=E2=80=99s wh= at you=E2=80=99re
>>> on about here, then just say that. You=E2=80=99ve wasted multi= ple
>>> messages talking about completely orthogonal issues where the<= br> >>> above statement is the first clue you=E2=80=99ve provided abou= t what is
>>> apparently your actual concern.
>>
>> I dont think it's orthogonal.
>
> It really is.

I tell you it is not.

agreeing with Ow= en, it is orthogonal.=C2=A0


As long as CLAT does not agree there is DHCPv6-PD and IPv6-in-GTP then
we have little to talk about.

3 different thin= gs

CLAT is just rfc6145<= /div>

Ipv6-in-GTP is just an i= p in UDP tunnel for mobility in 3gpp infrastructure, it has nothing to do w= ith the internet or the UE

Dhcpv6-pd ... assignes prefixes.=C2=A0

=
3 different and orthogonal things.=C2=A0




We have a new transition method that appeared just because an OS creator (Android) is not able, or not willing(?) to push their own suppliers
hardware vendors into implementing forwarding of DHCPv6-PD into their
modems.

Again, 464xlat w= as not pushed by Android, it was pulled by operators in the ietf


Android created a software tool (CLAT) that is totally runnable in the
linux (not in the modem), so it is totally under their control (not
modem) just to avoid the hardware modem problem.=C2=A0 That's not the r= ight
thing to do: the modem has to be fixed.

<= /div>
Modem is the wrong place ...
=


Android CLAT is also ignoring that IPv6-in-GTP exists (GTP is an IPv4
protocol at 3GPP), because the GTP part happens in the modem, and
Android does not control the modem.

If Android wanted "IPv6-only" devices then the right thing to do = is to
create an IPv6 version of GTP, or, even better, get rid of GTP
altogheter.=C2=A0 But that again - it's in the modem.

Nothing of this is orthogonal to CLAT: CLAT does some things because the modem is forcing it into doing.

Alex

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--089e082230a498ff320559a68319-- From nobody Wed Sep 20 18:00:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8042132944 for ; Wed, 20 Sep 2017 18:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj2ZzM3Q_IyQ for ; Wed, 20 Sep 2017 18:00:44 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B93113293A for ; Wed, 20 Sep 2017 18:00:44 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id i197so7542464ioe.9 for ; Wed, 20 Sep 2017 18:00:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ENmPO5nz3yOojsOWAL/4lwjf3YTJEdQ5lLNzGyQQ5/A=; b=d/LaV/q8hfoKRHyuv0uvWVHXKuiR8HzU96UilTHqoFXDbKdMlvAo5v2IF9n6Y1Clt/ rH/kM1NRlipGfLW77Otv1WYZ4EV3C+mgc9qAApLDZTwFwXxu6pN2ulJoHpsnhHtz2bdq a10QRfaYkppuTd/G9EoX96YjqlygmpapUZeECsq9M/d09aS6KnLsFYiqaH7OmL0mnt4I 6AUjOEm+gu5ypG2ZCpRhxzOdrIDLpv9l8MsKzL/Pbo7rvKAD1jMAQazCFiJHxpgzHBUz HE9sCikEasKP/0bJ6+DpEQyFuRMabomSnS/mLzSYUJ/VxR5RddqddMHkfkNMw/dHrbHL 3tgQ== 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=ENmPO5nz3yOojsOWAL/4lwjf3YTJEdQ5lLNzGyQQ5/A=; b=obmHidve6gD1CCQGoTqCA3QFdirZkuuDKUIHQGv5mW2mkXTHUSIvE9YMG+RC60Tlde pfCF477wxgShoFZVHQf8MXVOxl7JEI58XB6UAJ6rotH0Kxmj/7KOL9cLEW5j5NqW1n6D P4MTvv1LQtMFPjIgWQWo41S8VeyAdX/eKhrg5b7bI5IULZb//2eHL20+CNYcuDTQBGXB SoArAbmkSlm42/rOVDVy9IPvqD8IhgVy5Uzr8zdqbZSIgi2duGKacPofz8soG3EreXCU 9I440NJ6+rg7nJLcPn2ZtwOH8BrnUp72ZjqgbPZuDaS8EqzLsIhB10rBCUn9ZTrAHx/1 df2A== X-Gm-Message-State: AHPjjUhMcnqUieIXUS+dKeHdRYVT9iN3jFWlKm8IggzrtS9Y8KIDKjcZ WrcvYx34gnv+7EGOOcDqNZU= X-Google-Smtp-Source: AOwi7QBT1GfCHc6a+j6XBE4m/l4r1MNCKR/eWkrWXjj0TneqegLl3/AMq+nTVD5V8c1OSoExunz6Iw== X-Received: by 10.202.184.69 with SMTP id i66mr562619oif.241.1505955643649; Wed, 20 Sep 2017 18:00:43 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1da8? ([2600:8802:5600:e::1da8]) by smtp.gmail.com with ESMTPSA id c137sm610228oig.12.2017.09.20.18.00.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 18:00:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: Date: Wed, 20 Sep 2017 18:00:40 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> References: To: JORDI PALET MARTINEZ X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 01:00:46 -0000 > On Sep 20, 2017, at 8:52 AM, JORDI PALET MARTINEZ = wrote: >=20 >> =46rom my perspective, there are multiple interoperable specs. We = have several CLAT client implementations/vendors, from different = vendors, and they work fine in the same and different operators and = interoperate with different NAT64 and DNS64 vendors/implementations. >=20 > What I=E2=80=99m not sure is, because 464XLAT is basically RFC6145 = (SIIT) + RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), = which are already Standards track, if we need also to move them to STD = in that case, etc. I'll repeat myself earlier. Looking at the definitions of the terms, = there is no reason it can't or shouldn't be BCP, which our charter does = allow us to do, and which is a one-shot standard more appropriate to the = case (IMHO). If you want it to be a standardard, a BCP is a standard. = Let's advance it to BCP.= From nobody Wed Sep 20 19:21:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1E91320DC for ; Wed, 20 Sep 2017 19:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pN3rtirQjOe for ; Wed, 20 Sep 2017 19:21:29 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 50164128D0D for ; Wed, 20 Sep 2017 19:21:28 -0700 (PDT) Received: from [10.0.5.241] (r190-64-69-50.su-static.adinet.com.uy [190.64.69.50] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v8L2K6nF014520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Sep 2017 19:20:16 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_8ED1E896-CFE7-4BAE-841C-E5760A164B4F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: Date: Wed, 20 Sep 2017 23:20:04 -0300 Cc: v6ops@ietf.org Message-Id: <8F15B155-55C9-4016-A55C-25DB745FE217@delong.com> References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [192.159.10.2]); Wed, 20 Sep 2017 19:20:26 -0700 (PDT) Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 02:21:32 -0000 --Apple-Mail=_8ED1E896-CFE7-4BAE-841C-E5760A164B4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 20, 2017, at 5:55 PM, Alexandre Petrescu = wrote: >=20 > Le 20/09/2017 =C3=A0 21:35, Owen DeLong a =C3=A9crit : >>> On Sep 20, 2017, at 12:26 PM, Alexandre Petrescu = wrote: >>> Le 20/09/2017 =C3=A0 17:13, Owen DeLong a =C3=A9crit : >>>>> On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu = > = wrote: >>>>> Le 20/09/2017 =C3=A0 15:35, JORDI PALET MARTINEZ a =C3=A9crit : >>>>>> Why you try to mix things? >>>>> I dont mix. You want a unique STdsTRack. Do you think the place = is empty? >>>> I=E2=80=99m not sure where you get =E2=80=9Cunique=E2=80=9D. I = think Jordi wants 464XLAT moved to Standards track rather than = informational. I don=E2=80=99t see anything about unique in his request. >>>>> As I said already, there is already IPv6-in-GTP for transitioning = and DHCPv6-PD for Prefix Delegation. These are standards. >>>> I guess the question I have for this statement is =E2=80=9Cwhy is = this relevant to whether or not we move 464XLAT to standard?=E2=80=9D >>> BEcause 464XLAT is a transitioning mechanism and IPv6-in-GTP is a = transitioning mechanism too, which is deployed too. >> So what? >> ISIS is a Standard and so is OSPF=E2=80=A6 both are IGPs. For that = matter, >> so is RIPv2. >=20 > YEs, and each uses some distinct number, maybe a UDP port number. = They > can work simultaneously on a Router. I suppose you could, technically, run ISIS and OSPF on the same router = at the same time, but down that path lies madness. > But you cant have simultaneously CLAT and DHCPv6-PD on the same = client. > Because CLAT wants that to be a /64 prefix. It will break when the > client gets a /63. Again, I don=E2=80=99t entirely buy this because if the client gets an = IA_PD /63, I=E2=80=99m not sure CLAT cares. CLAT cares about either the = IA_NA or the interface address assigned by the DHCP client (which should = be a /64). > Moreover, design suggestions from CLAT assume that /64 is sufficient. > That is wrong - /64 is not sufficient. If you feel strongly about this, publish an ID obsoleting the current = CLAT specification and arguing for more than a /64. >> There are lots of cases where more than one solution to the same = problem becomes a standards track RFC. >=20 > But one wont prohibit the other. >=20 > CLAT prohibits DHCPv6-PD. Continuing to say this doesn=E2=80=99t make it true. >> For that matter, DHCPv6 and SLAAC are both standards. Both do >> address assignment. >=20 > Err, I agree. Yet CLAT does not agree. CLAT does not rely on DHCP to > get an address. Why? IT does not rely on DHCPv6-PD to get a prefix. = Why? Neither do any Android phones, nor do the vast majority of systems that = I administer. What=E2=80=99s your point? IMHO, no protocol should _RELY_ on DHCPv6 or DHCPv6_PD, but, instead, = they should all function regardless of the mechanism by which addresses = are assigned. Arguably you could say that insisting a link is a /64 is = not valid and you might have a case there, but even there, I think for = some things, that ship has sailed. >>>>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a way to = provision addresses/prefixes. No sense to mix all them. >>>>> That's a problem. You want them to work together, not to = compete. >>>> This makes no sense to me. IMHO, they don=E2=80=99t compete and = CLAT can work regardless of how the IPv6 address on the client is = obtained, whether SLAAC, DHCPv6, static, or otherwise. >>> But you dont want CLAT's IPv6-in-IPv4 together with GTP = encapsulation - that's too many encapsulations. >> True, but I don=E2=80=99t want ISIS and OSPF running on the same = links, either. >=20 > At some point there is some Gateway that is possible, which runs both > protocols OSPF and ISIS. But there cant be conversion between CLAT = and > DHCP. Right, because CLAT doesn=E2=80=99t assign addresses and DHCP doesn=E2=80=99= t provide a gateway between IPv4 and IPv6. That=E2=80=99s sort of like saying there can=E2=80=99t be conversion = between RIP and TELNET. It=E2=80=99s true, but I=E2=80=99m not sure why it matters. >> Not sure I understand why this is a relevant topic here. Operators = are capable of choosing the standard that best meets their needs >> from multiple standards. Choice is often a good thing. This is an >> example of such a case. >=20 > Operators are influenced by Device availability. If Android is what = is > available, then operators want to satisfy this. If Android does CLAT, > then operators choose to not implement DHCPv6-PD, because DHCPv6-PD is > part of DHCPv6, and because CLAT does not need DHCPv6. Sorry, but this is absurd logic. The reason operators choose not to implement DHCPv6-PD in = android-centric networks is because Android doesn=E2=80=99t support = DHCPv6. That is a completely orthogonal issue to whether android = supports 464XLAT/CLAT or not. That would be sort of like saying =E2=80=9CBecause my linux system is = running Quagga and speaks OSPF, it can=E2=80=99t handle SSH sessions.=E2=80= =9D The lack of DHCPv6 on Android devices is (as near as I can tell) largely = a religious position taken by Lorenzo. This situation existed long before CLAT and if they chose to put DHCPv6 = clients on Android, it wouldn=E2=80=99t eliminate their ability to run = CLAT. > I dont know how to explain this better to you. I=E2=80=99m not the one who seems to be misunderstanding the situation. > Android is very important to operators. And? Android supports 464XLAT. It=E2=80=99s not going to support DHCPv6 = until someone convinces Lorenzo (or someone above him at Alphabits) to = do so. Support could be added without breaking 464XLAT/CLAT, so I really = don=E2=80=99t see why you are connecting these two things other than = perhaps in your mind they are connected because Lorenzo was also one of = the early backers of 464XlAT. >>>>> You want them to have different functions. >>>> CLAT doesn=E2=80=99t have an IPv6 address assignment function so = they >>>> do, in fact, have different functions. >>>>> But the function to get a prefix is a unique function. >>>> CLAT doesn=E2=80=99t have anything to do with getting a prefix for = IPv6. >>> But it only works with a /64. It means it cant work when >>> DHCPv6-PD gives it a /63. >> You=E2=80=99re making no sense here. An interface would still get a = /64 from the /63 or /56 or /48 or whatever, so CLAT would still be = perfectly capable of operating after the /64 was assigned to the = interface. >=20 > To be tried, before arguing. >=20 > Can you try? >=20 > Do you think a WiFi tablet behind a smartphone-on-cellular that uses a > prefix obtained with DHCPv6-PD and re-advertised with RA would be able > to get through that CLAT ok, and talk to IPv4 servers? I don=E2=80=99t see why not. Admittedly, I don=E2=80=99t bother to try, = I have enough IPv4 addresses on the networks I run that dual stack is a = perfectly viable solution and the idea of all of these silly variants of = the NAT shell game just turn my stomach. However, I recognize the real = need in the real world for them. Now, a counter-question=E2=80=A6 Do you think a WiFi tablet behind that = same smart-phone-on-cellular that gets its address via static or some = other address assignment mechanism would have the same difficulty? If = not, why not? > If you could try this, then we can have an answer on whether or not I > make sense. >=20 > Before that, we cant say CLAT and DHCPv6-PD are ok. You=E2=80=99re making the bold assertion that CLAT fails if the /64 on = the interface is assigned by some mechanism other than 64share. As far = as I=E2=80=99m concerned, it=E2=80=99s not my responsibility to prove = that assertion false, it=E2=80=99s up to you to provide some factual = basis behind the assertion and/or some proof that it is valid. > Nothing of this is orthogonal to CLAT: CLAT does some things because = the > modem is forcing it into doing. Probably now is the time for us to (as usual) agree to disagree=E2=80=A6 Regardless of the reason CLAT was created, it is now widely deployed and = very popular. It is a pragmatic solution. Deploying it does not break = any of the protocols that are near and dear to your heart. It provides = an optional way to deal with circumstances where those protocols are not = the best choice for the operator regardless of the reasons behind that. Would it be nice to get the modem vendors to fix the silicon? Sure. But = reality check here=E2=80=A6 They=E2=80=99re not going to retroactively = replace the silicon in billions of smart phones even if they can be = convinced to correct future chipsets. As such, the =E2=80=9Cright = thing=E2=80=9D is completely infeasible in the real world. So again, I say that fixing the chipsets, DHCPv6, and IPv6-in-GTP are = all orthogonal to this discussion because there is no inherent conflict = in deploying CLAT on the phone, it simply provides yet another option = for accomplishing a similar task. In fact, unless I misunderstood IPv6-in-GTP, 464XLAT solves a different = problem than IPv6-in-GTP in that IPv6-in-GTP provides (roughly) the = cellular equivalent of a 6in4 tunnel rather than providing a mechanism = for an IPv6-only device to speak to an IPv4 device at the far end. Owen --Apple-Mail=_8ED1E896-CFE7-4BAE-841C-E5760A164B4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Sep 20, 2017, at 5:55 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:

Le 20/09/2017 =C3=A0 21:35, Owen DeLong a =C3=A9cr= it :
On Sep 20, 2017, at 12:26 PM, Alexandre = Petrescu <alexandre.petrescu@gmail.com> wrote:
Le = 20/09/2017 =C3=A0 17:13, Owen DeLong a =C3=A9crit :
On Sep 20, 2017, at 10:44 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> wrote:
Le 20/09/2017 =C3=A0 15:35, JORDI PALET MARTINEZ a =C3=A9crit = :
Why you try to mix = things?
I dont mix.  You want a unique = STdsTRack.  Do you think the place is empty?
I=E2=80=99m not sure where you get =E2=80=9Cunique= =E2=80=9D. I think Jordi wants 464XLAT moved to Standards track rather = than informational. I don=E2=80=99t see anything about unique in his = request.
As I said = already, there is already IPv6-in-GTP for transitioning and DHCPv6-PD = for Prefix Delegation. These are standards.
I = guess the question I have for this statement is =E2=80=9Cwhy is this = relevant to whether or not we move 464XLAT to standard?=E2=80=9D
BEcause 464XLAT is a transitioning mechanism and = IPv6-in-GTP is a transitioning mechanism too, which is deployed too.
So what?
ISIS is a Standard and so = is OSPF=E2=80=A6 both are IGPs. For that matter,
so is = RIPv2.

YEs, and each uses some distinct number, = maybe a UDP port number.  They
can work simultaneously on a = Router.

I suppose you = could, technically, run ISIS and OSPF on the same router at the same = time, but down that path lies madness.

But you cant have simultaneously CLAT and = DHCPv6-PD on the same client.
Because CLAT wants that to be a /64 = prefix.  It will break when the
client gets a /63.

Again, I don=E2=80=99t entirely buy this because if the = client gets an IA_PD /63, I=E2=80=99m not sure CLAT cares. CLAT cares = about either the IA_NA or the interface address assigned by the DHCP = client (which should be a /64).

Moreover, design = suggestions from CLAT assume that /64 is sufficient.
That is wrong - /64 is not = sufficient.

If you feel = strongly about this, publish an ID obsoleting the current CLAT = specification and arguing for more than a /64.

There are lots of cases where more than one solution to the = same problem becomes a standards track RFC.
But one wont prohibit the = other.

CLAT prohibits = DHCPv6-PD.

Continuing to = say this doesn=E2=80=99t make it true.

For that matter, DHCPv6 and SLAAC are both standards. Both = do
address assignment.

Err, I agree.  Yet = CLAT does not agree.  CLAT does not rely on DHCP to
get an address.  Why? =  IT does not rely on DHCPv6-PD to get a prefix. =  Why?

Neither do any = Android phones, nor do the vast majority of systems that I = administer.

What=E2=80=99s your = point?

IMHO, no protocol should = _RELY_ on DHCPv6 or DHCPv6_PD, but, instead, they should all function = regardless of the mechanism by which addresses are assigned. Arguably = you could say that insisting a link is a /64 is not valid and you might = have a case there, but even there, I think for some things, that ship = has sailed.

CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a = way to provision addresses/prefixes. No sense to mix all them.
That's a problem.  You want them to work =  together, not to compete.
This makes no = sense to me. IMHO, they don=E2=80=99t compete and CLAT can work = regardless of how the IPv6 address on the client is obtained, whether = SLAAC, DHCPv6, static, or otherwise.
But you = dont want CLAT's IPv6-in-IPv4 together with GTP encapsulation - that's = too many encapsulations.
True, but I don=E2=80=99= t want ISIS and OSPF running on the same links, either.

At some point there is some Gateway that is = possible, which runs both
protocols OSPF and ISIS.  But there = cant be conversion between CLAT and
DHCP.

Right, because = CLAT doesn=E2=80=99t assign addresses and DHCP doesn=E2=80=99t provide a = gateway between IPv4 and IPv6.

That=E2=80=99s sort of like saying there can=E2=80=99= t be conversion between RIP and TELNET.

It=E2=80=99s true, but I=E2=80=99m not sure why it = matters.

Not sure I understand why this is a relevant topic here. = Operators are capable of choosing the standard that best meets their = needs
from multiple standards. Choice is often a good = thing. This is an
example of such a case.

Operators are influenced by Device availability. =  If Android is what is
available, then operators want to satisfy = this.  If Android does CLAT,
then operators choose to not implement = DHCPv6-PD, because DHCPv6-PD is
part of DHCPv6, and because CLAT does not = need DHCPv6.

Sorry, but this = is absurd logic.

The reason = operators choose not to implement DHCPv6-PD in android-centric networks = is because Android doesn=E2=80=99t support DHCPv6. That is a completely = orthogonal issue to whether android supports 464XLAT/CLAT or = not.

That would be sort of like = saying =E2=80=9CBecause my linux system is running Quagga and speaks = OSPF, it can=E2=80=99t handle SSH sessions.=E2=80=9D

The lack of DHCPv6 on Android devices is (as near = as I can tell) largely a religious position taken by = Lorenzo.

This situation existed long = before CLAT and if they chose to put DHCPv6 clients on Android, it = wouldn=E2=80=99t eliminate their ability to run CLAT.

I dont know how to explain this better to = you.

I=E2=80=99m not = the one who seems to be misunderstanding the situation.

Android is very important to = operators.

And? Android = supports 464XLAT. It=E2=80=99s not going to support DHCPv6 until someone = convinces Lorenzo (or someone above him at Alphabits) to do so. Support = could be added without breaking 464XLAT/CLAT, so I really don=E2=80=99t = see why you are connecting these two things other than perhaps in your = mind they are connected because Lorenzo was also one of the early = backers of 464XlAT.

You want them to have = different functions.
CLAT doesn=E2=80=99t = have an IPv6 address assignment function so they
do, in = fact, have different functions.
But the function to get a prefix is a unique function.
CLAT doesn=E2=80=99t have anything to do with = getting a prefix for IPv6.
But it only works = with a /64.  It means it cant work when
DHCPv6-PD = gives it a /63.
You=E2=80=99re making no = sense here. An interface would still get a /64 from the /63 or /56 or = /48 or whatever, so CLAT would still be perfectly capable of operating = after the /64 was assigned to the interface.

To be tried, before arguing.

Can you try?

Do you think a WiFi tablet behind a = smartphone-on-cellular that uses a
prefix obtained with DHCPv6-PD and = re-advertised with RA would be able
to get through that CLAT ok, and talk to = IPv4 servers?

I don=E2=80=99t = see why not. Admittedly, I don=E2=80=99t bother to try, I have enough = IPv4 addresses on the networks I run that dual stack is a perfectly = viable solution and the idea of all of these silly variants of the NAT = shell game just turn my stomach. However, I recognize the real need in = the real world for them.

Now, a = counter-question=E2=80=A6 Do you think a WiFi tablet behind that same = smart-phone-on-cellular that gets its address via static or some other = address assignment mechanism would have the same difficulty? If not, why = not?

If you could try this, then we can have = an answer on whether or not I
make sense.

Before that, we cant say CLAT and DHCPv6-PD are = ok.

You=E2=80=99re = making the bold assertion that CLAT fails if the /64 on the interface is = assigned by some mechanism other than 64share. As far as I=E2=80=99m = concerned, it=E2=80=99s not my responsibility to prove that assertion = false, it=E2=80=99s up to you to provide some factual basis behind the = assertion and/or some proof that it is valid.

Nothing of this is orthogonal to CLAT: CLAT does = some things because the
modem is forcing it into doing.

Probably now is the time for us to (as usual) = agree to disagree=E2=80=A6

Regardless of the reason CLAT was created, it is now widely = deployed and very popular. It is a pragmatic solution. Deploying it does = not break any of the protocols that are near and dear to your heart. It = provides an optional way to deal with circumstances where those = protocols are not the best choice for the operator regardless of the = reasons behind that.

Would it be nice to get the modem vendors to fix the silicon? = Sure. But reality check here=E2=80=A6 They=E2=80=99re not going to = retroactively replace the silicon in billions of smart phones even if = they can be convinced to correct future chipsets. As such, the =E2=80=9Cri= ght thing=E2=80=9D is completely infeasible in the real world.

So again, I say that = fixing the chipsets, DHCPv6, and IPv6-in-GTP are all orthogonal to this = discussion because there is no inherent conflict in deploying CLAT on = the phone, it simply provides yet another option for accomplishing a = similar task.

In= fact, unless I misunderstood IPv6-in-GTP, 464XLAT solves a different = problem than IPv6-in-GTP in that IPv6-in-GTP provides (roughly) the = cellular equivalent of a 6in4 tunnel rather than providing a mechanism = for an IPv6-only device to speak to an IPv4 device at the far = end.

Owen

= --Apple-Mail=_8ED1E896-CFE7-4BAE-841C-E5760A164B4F-- From nobody Wed Sep 20 21:54:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28893134327 for ; Wed, 20 Sep 2017 21:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkxYXIJNVgrW for ; Wed, 20 Sep 2017 21:54:09 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F45D1342C2 for ; Wed, 20 Sep 2017 21:54:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8L4s2it018937; Thu, 21 Sep 2017 06:54:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CE3D920228B; Thu, 21 Sep 2017 06:54:02 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C58E520203D; Thu, 21 Sep 2017 06:54:02 +0200 (CEST) Received: from [132.166.84.14] ([132.166.84.14]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8L4s2CL016391; Thu, 21 Sep 2017 06:54:02 +0200 To: Ole Troan Cc: Owen DeLong , v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <3F99667F-56A6-487E-9AA6-D0FCB0BB4450@employees.org> From: Alexandre Petrescu Message-ID: Date: Thu, 21 Sep 2017 06:54:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <3F99667F-56A6-487E-9AA6-D0FCB0BB4450@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 04:54:11 -0000 Le 20/09/2017 23:41, Ole Troan a crit : >> But you cant have simultaneously CLAT and DHCPv6-PD on the same >> client. Because CLAT wants that to be a /64 prefix. It will break >> when the client gets a /63. >> >> Moreover, design suggestions from CLAT assume that /64 is >> sufficient. That is wrong - /64 is not sufficient. >> >>> There are lots of cases where more than one solution to the same >>> problem becomes a standards track RFC. >> >> But one wont prohibit the other. >> >> CLAT prohibits DHCPv6-PD. > > RFC6877 section 6.3 states the opposite. Ole, RFCs are one thing, and I agree with you. And here we do RFCs. But very much of what RFCs do is from implementations. It's hard to claim RFC this and RFC that if on the other hand it is clear that Android blocks[*] DHCPv6 straight. It looks like we would stick our head in the sand. Androids are very numerous devices, and RFCs are less numerous. Here, in this operations group, there is need that Android accepts these RFCs. And we need that before we even talk moving an Android-only CLAT from INFORMATIONAL to something else. Alex PS: to support the claim that Android explicitely blocks DHCPv6, I can provide pointers to public Google pages, numerous requests of DHCPv6 integration in Android (to avoid need of 'rooting' the devices), the availability of DHCPv6 app in Android store that runs only on WiFi and must 'root', invitations from competitor OSs to bring DHCPv6 there instead of Android, and more. > > Ole > From nobody Wed Sep 20 22:22:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9930134324 for ; Wed, 20 Sep 2017 22:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsHcTDE-Y4At for ; Wed, 20 Sep 2017 22:22:40 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC2B1321A1 for ; Wed, 20 Sep 2017 22:22:39 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8L5MUaa061742; Thu, 21 Sep 2017 07:22:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EEDEF202090; Thu, 21 Sep 2017 07:22:30 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DF17C20203D; Thu, 21 Sep 2017 07:22:30 +0200 (CEST) Received: from [132.166.84.14] ([132.166.84.14]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8L5MTkd031968; Thu, 21 Sep 2017 07:22:30 +0200 To: Ca By , Owen DeLong Cc: v6ops@ietf.org References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> From: Alexandre Petrescu Message-ID: <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> Date: Thu, 21 Sep 2017 07:22:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 05:22:43 -0000 In this email, the important part are at the beginning. The rest is repetition. Le 21/09/2017 à 00:29, Ca By a écrit : [...] > IPv6-in-GTP is a transport mechanism with mobility. It does not help an > ipv6-only node communicate with an ipv4 internet. It helps to transport the IPv6 packets through the intermediary network that is IPv4-only. The intermediary network is made of modem, base station, SGW and PGW. The linux part is not the modem. > > That said, my deployment includes both IPv6-in-GTP and 464xlat > simulatenously So, you have 2 encapsulations, right? [...] > But you cant have simultaneously CLAT and DHCPv6-PD on the same client. > > > I do not agree,  Please state what is structurally preventing this. > RFC6877 specifically calls for using dhcpv6-pd RFC is one thing, but many implementations block some RFCs. What structurally prevents this is that there are very numerous Android devices. Each of these Android device has a structural risk if it wants to 'root'. If the 'root' operation fails you can structurally through it out a window. Android refuses to include DHCPv6-PD client in the main OS (public URL available upon request). Because of that, one has to 'root' the device in order to include it. Second, the modem part of many Android devices block DHCPv6. Private indication of the dhcpv6 file blocking it is available upon request. It is confidential information. The rights are to Qualcom and Balong. On another hand, I would like you to ask me what structurally does _not_ prevent Android to run DHCPv6-PD. If you did, I would tell you this: the operator does not oppose running DHCPv6-PD (some already run); operator does not block DHCPv6 std ports, nor DHCPv6 std multicast; router manufacturer does offer DHCPv6-PD server in the infrastructure; open source software does exist for DHCPv6-PD server; 3GPP specs do tell DHCPv6-PD should run; Android app DHCPv6 does exist on Store; many flavors of DHCPv6-PD software was compiled and run on Android. Less important repetitions follow: > >   Because CLAT wants that to be a /64 prefix.  It will break when the > client gets a /63. > > > It requires a /64, which may come to the CLAT via a /56 via dhcpv6-pd It "can"? I dont think it can. See above the reasons. Basically, Android opposes the inclusion of DHCPv6 software altogether in their code. DHCPv6-PD can not run without DHCPv6 code. But if you are afraid of IA_NA, dont mistake: DHCPv6 code has an option called IA_PD (or -P in some implementations) that makes that even if the DHCPv6 entire binary is present on the file system, only the IA_PD part is called (not the IA_NA). That's why we have to be careful with words like "it can", or "is orthogonal to", or "is independent of", or "CLAT regardless of RA or DHCP". It's not that way. It is that CLAT means no DHCP. > > > Moreover, design suggestions from CLAT assume that /64 is sufficient. > That is wrong - /64 is not sufficient. > > > It is sufficient for CLAT function of execuating rfc6145. CLAT just > rfc6145. No. When you make such statement - have you tried? > > There are lots of cases where more than one solution to the same > > problem becomes a standards track RFC. > > But one wont prohibit the other. > > CLAT prohibits DHCPv6-PD. > > > Not correct. See above. CLAT is what makes Android to explicitely not want DHCP. Because CLAT says "we are independent of SLAAC or DHCP", but they also say "so we use _only_ SLAAC". If you wanted to support your statement, then you showed me some implementation in where CLAT and DHCPv6 worked together. There is no such. > > > > For that matter, DHCPv6 and SLAAC are both standards. Both do > > address assignment. > > Err, I agree.  Yet CLAT does not agree.  CLAT does not rely on DHCP to > get an address.  Why?  IT does not rely on DHCPv6-PD to get a > prefix.  Why? > > >>>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a > >>>>> way to provision addresses/prefixes. No sense to mix all > >>>>> them. > >>>> > >>>> That's a problem.  You want them to work  together, not to > >>>> compete. > >>> This makes no sense to me. IMHO, they don’t compete and CLAT can > >>> work regardless of how the IPv6 address on the client is > >>> obtained, whether SLAAC, DHCPv6, static, or otherwise. > >> > >> But you dont want CLAT's IPv6-in-IPv4 together with GTP > >> encapsulation - that's too many encapsulations. > > > > True, but I don’t want ISIS and OSPF running on the same links, > > either. > > At some point there is some Gateway that is possible, which runs both > protocols OSPF and ISIS.  But there cant be conversion between CLAT and > DHCP. > > > Not correct, again. Please see rfc6877. See public URL in which discussion illustrates Android does not want DHCPv6. See Android app on Android store that runs DHCPv6, but which is not integrated in Android. Running it requires 'root'. > > > > Not sure I understand why this is a relevant topic here. Operators > > are capable of choosing the standard that best meets their needs > > from multiple standards. Choice is often a good thing. This is an > > example of such a case. > > Operators are influenced by Device availability. > > > This operator (and esteamed co-authors)  saw a problem, came to the > ietf, worked with Android open source, worked with v6ops, and specified > 464xlat. Another operator has an option in which DHCPv6 is there. Android blocks that. Fix Android. Modem blocks that - fix modem. > > Device availabilty followed. > > If Android is what is > available, then operators want to satisfy this.  If Android does CLAT, > then operators choose to not implement DHCPv6-PD, because DHCPv6-PD is > part of DHCPv6, and because CLAT does not need DHCPv6. > > > Again. Dhcpv6-pd and 464xlat are compatible and their deployment > motivations are largely orthogonal. "Compatible", but have you tried? > I dont know how to explain this better to you. > > Android is very important to operators. > > >>>> You want them to have different functions. > >>> CLAT doesn’t have an IPv6 address assignment function so they > >>> do, in fact, have different functions. > >>>> But the function to get a prefix is a unique function. > >>> CLAT doesn’t have anything to do with getting a prefix for IPv6. > >> > >> But it only works with a /64.  It means it cant work when > >> DHCPv6-PD gives it a /63. > > > > You’re making no sense here. An interface would still get a /64 from > > the /63 or /56 or /48 or whatever, so CLAT would still be perfectly > > capable of operating after the /64 was assigned to the interface. > > > Owen is correct here. > > > To be tried, before arguing. > > Can you try? > > > Seems you are the one interested in this area. > > The Android source code is available for you. That is true to some extent. SOme smartphone manufacturers do offer the source code of their platforms, yes. Some still not, but will come. On another hand, in order to make my own OS I must 'root' the device. That's a risk. The other option is that the responsible numerous Android devices take pride (not oppose) some RFCs like the ones you mention, before blocking them. > Do you think a WiFi tablet behind a smartphone-on-cellular that uses a > prefix obtained with DHCPv6-PD and re-advertised with RA would be able > to get through that CLAT ok, and talk to IPv4 servers? > > If you could try this, then we can have an answer on whether or not I > make sense. > > Before that, we cant say CLAT and DHCPv6-PD are ok. > > > We can say the specification allows CLAT and DHCPv6-PD to work > together.  Running code is an exercise left to those with a demand for > that usecase. Promoting an RFC from INFO to StdsTrack demandes usecase. > >>>>> Many other transition mechanisms don’t state if SLAAC or > >>>>> DHCPv6 is used or not, and I think is perfectly correct. > >>>> > >>>> Most of them are not dynamic in nature anyways, whereas CLAT > >>>> seems to be. > >>> My understanding is that CLAT is dynamic only on the IPv4 side. > >>> On the IPv6 side, to the best of my knowledge, it just uses > >>> whatever IPv6 address is available on the client’s interface(s). > >>>> As long as they dont claim, and they abstain from to > >>>> dynamically set a prefix on the network they are fine with > >>>> respect to DHCP-PD. > >>>> > >>>> But once CLAT gets into statements qualifying which is better > >>>> SLAAC-vs-DHCP then we have a big problem. > >>> Sigh… I agree that there’s no reason for CLAT to make any such > >>> statement. If the current CLAT RFC(s) do, then, perhaps we > >>> should argue for cleaning that up as part of the process of > >>> moving towards a standards track RFC, but if that’s what you’re > >>> on about here, then just say that. You’ve wasted multiple > >>> messages talking about completely orthogonal issues where the > >>> above statement is the first clue you’ve provided about what is > >>> apparently your actual concern. > >> > >> I dont think it's orthogonal. > > > > It really is. > > I tell you it is not. > > > agreeing with Owen, it is orthogonal. Orthogonal. > > > As long as CLAT does not agree there is DHCPv6-PD and IPv6-in-GTP then > we have little to talk about. > > > 3 different things > > CLAT is just rfc6145 > > Ipv6-in-GTP is just an ip in UDP tunnel for mobility in 3gpp > infrastructure, it has nothing to do with the internet or the UE > > Dhcpv6-pd ... assignes prefixes. > > 3 different and orthogonal things. > > > > > We have a new transition method that appeared just because an OS creator > (Android) is not able, or not willing(?) to push their own suppliers > hardware vendors into implementing forwarding of DHCPv6-PD into their > modems. > > > Again, 464xlat was not pushed by Android, it was pulled by operators in > the ietf Operators also ask what Android wants. Operators dont oppose DHCPv6-PD. 3GPP doesnt either. Yet Android refuses DHCPv6-PD. > Android created a software tool (CLAT) that is totally runnable in the > linux (not in the modem), so it is totally under their control (not > modem) just to avoid the hardware modem problem.  That's not the right > thing to do: the modem has to be fixed. > > > Modem is the wrong place ... Modem manufacturers say differently. Modem manufacturers do implement IP features. Sometimes they block RFCs, just like Android blocks DHCP too. But they found a sort of living together: it's the old Host-IMP interface. The Host (Android) does some stuff assuming their matter is 'orthogonal' to the IMP (Qualcom). However, for the IMP we are not allowed to know what it does and for Android we are not allowed to ask them do DHCP. That's not an interface: it is independence, orthogonality. That leads to problems. Alex > > > > Android CLAT is also ignoring that IPv6-in-GTP exists (GTP is an IPv4 > protocol at 3GPP), because the GTP part happens in the modem, and > Android does not control the modem. > > If Android wanted "IPv6-only" devices then the right thing to do is to > create an IPv6 version of GTP, or, even better, get rid of GTP > altogheter.  But that again - it's in the modem. > > Nothing of this is orthogonal to CLAT: CLAT does some things because the > modem is forcing it into doing. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 20 22:39:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321F9132D4B for ; Wed, 20 Sep 2017 22:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uHrtB_GMLEK for ; Wed, 20 Sep 2017 22:39:33 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF8F1321A1 for ; Wed, 20 Sep 2017 22:39:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8L5dSIL029905; Thu, 21 Sep 2017 07:39:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1364C20231C; Thu, 21 Sep 2017 07:39:28 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 04AEF202305; Thu, 21 Sep 2017 07:39:28 +0200 (CEST) Received: from [132.166.84.14] ([132.166.84.14]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8L5dRCG010174; Thu, 21 Sep 2017 07:39:27 +0200 To: Owen DeLong Cc: v6ops@ietf.org References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8F15B155-55C9-4016-A55C-25DB745FE217@delong.com> From: Alexandre Petrescu Message-ID: <8f09d369-0936-8c42-2d2d-54075a7810cb@gmail.com> Date: Thu, 21 Sep 2017 07:39:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <8F15B155-55C9-4016-A55C-25DB745FE217@delong.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 05:39:35 -0000 Le 21/09/2017 à 04:20, Owen DeLong a écrit : [...] >> But you cant have simultaneously CLAT and DHCPv6-PD on the same client. >> Because CLAT wants that to be a /64 prefix.  It will break when the >> client gets a /63. > > Again, I don’t entirely buy this because if the client gets an IA_PD > /63, I’m not sure CLAT cares. Yes, not sure either, but have you tried? Do you understand this 'root' problem? [...] >> Moreover, design suggestions from CLAT assume that /64 is sufficient. >> That is wrong - /64 is not sufficient. > > If you feel strongly about this, publish an ID obsoleting the current > CLAT specification and arguing for more than a /64. There is an Analysis of /64 boundary RFC, osme proposal to the Addr Archi RFC which has strong opposition too from, err, you will see. That's done. >>> There are lots of cases where more than one solution to the same >>> problem becomes a standards track RFC. >> >> But one wont prohibit the other. >> >> CLAT prohibits DHCPv6-PD. > > Continuing to say this doesn’t make it true. There is truth in trying: try it. >>> For that matter, DHCPv6 and SLAAC are both standards. Both do >>> address assignment. >> >> Err, I agree.  Yet CLAT does not agree.  CLAT does not rely on DHCP to >> get an address.  Why?  IT does not rely on DHCPv6-PD to get a prefix. >>  Why? > > Neither do any Android phones, nor do the vast majority of systems that > I administer. > > What’s your point? > > IMHO, no protocol should _RELY_ on DHCPv6 or DHCPv6_PD, but, instead, > they should all function regardless of the mechanism by which addresses > are assigned. I can agree with the principle, but in practice the situation may have another light. > Arguably you could say that insisting a link is a /64 is > not valid and you might have a case there, but even there, I think for > some things, that ship has sailed. Ship sailed... > >>>>>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a way to >>>>>>> provision addresses/prefixes. No sense to mix all them. >>>>>> That's a problem.  You want them to work  together, not to compete. >>>>> This makes no sense to me. IMHO, they don’t compete and CLAT can >>>>> work regardless of how the IPv6 address on the client is obtained, >>>>> whether SLAAC, DHCPv6, static, or otherwise. >>>> But you dont want CLAT's IPv6-in-IPv4 together with GTP >>>> encapsulation - that's too many encapsulations. >>> True, but I don’t want ISIS and OSPF running on the same links, either. >> >> At some point there is some Gateway that is possible, which runs both >> protocols OSPF and ISIS.  But there cant be conversion between CLAT and >> DHCP. > > Right, because CLAT doesn’t assign addresses and DHCP doesn’t provide a > gateway between IPv4 and IPv6. > > That’s sort of like saying there can’t be conversion between RIP and TELNET. > > It’s true, but I’m not sure why it matters. On Android, what makes HTTP more successful than Telnet to access remote computers is that you dont need root access to run HTTP. You dont need root access for CLAT to run, but you do for DHCPv6-PD. >>> Not sure I understand why this is a relevant topic here. Operators >>> are capable of choosing the standard that best meets their needs >>> from multiple standards. Choice is often a good thing. This is an >>> example of such a case. >> >> Operators are influenced by Device availability.  If Android is what is >> available, then operators want to satisfy this.  If Android does CLAT, >> then operators choose to not implement DHCPv6-PD, because DHCPv6-PD is >> part of DHCPv6, and because CLAT does not need DHCPv6. > > Sorry, but this is absurd logic. > > The reason operators choose not to implement DHCPv6-PD in > android-centric networks is because Android doesn’t support DHCPv6. That > is a completely orthogonal issue to whether android supports > 464XLAT/CLAT or not. Android says CLAT is sufficient. Please look at the public discussion on public URL about DHCPv6, CLAT, and everything. > > That would be sort of like saying “Because my linux system is running > Quagga and speaks OSPF, it can’t handle SSH sessions.” > > The lack of DHCPv6 on Android devices is (as near as I can tell) largely > a religious position taken by Lorenzo. > > This situation existed long before CLAT and if they chose to put DHCPv6 > clients on Android, it wouldn’t eliminate their ability to run CLAT. I agree. But I think they dont. > >> I dont know how to explain this better to you. > > I’m not the one who seems to be misunderstanding the situation. > >> Android is very important to operators. > > And? Android supports 464XLAT. It’s not going to support DHCPv6 until > someone convinces Lorenzo (or someone above him at Alphabits) to do so. > Support could be added without breaking 464XLAT/CLAT, so I really don’t > see why you are connecting these two things other than perhaps in your > mind they are connected because Lorenzo was also one of the early > backers of 464XlAT. BEcause Lorenzo makes same argument against DHCPv6. Were Lorenzo (because you name him) to agree DHCPv6 is necessary on Android, then many things would change, including CLAT. If CLAT works ok with DHCPv6-PD, then I have no problem with CLAT. If CLAT works ok with only 64share (and not with DHCPv6-PD), then I disagree with both CLAT and 64share. That will bring you even further back, but that's the way it is. > >>>>>> You want them to have different functions. >>>>> CLAT doesn’t have an IPv6 address assignment function so they >>>>> do, in fact, have different functions. >>>>>> But the function to get a prefix is a unique function. >>>>> CLAT doesn’t have anything to do with getting a prefix for IPv6. >>>> But it only works with a /64.  It means it cant work when >>>> DHCPv6-PD gives it a /63. >>> You’re making no sense here. An interface would still get a /64 from >>> the /63 or /56 or /48 or whatever, so CLAT would still be perfectly >>> capable of operating after the /64 was assigned to the interface. >> >> To be tried, before arguing. >> >> Can you try? >> >> Do you think a WiFi tablet behind a smartphone-on-cellular that uses a >> prefix obtained with DHCPv6-PD and re-advertised with RA would be able >> to get through that CLAT ok, and talk to IPv4 servers? > > I don’t see why not. Admittedly, I don’t bother to try, I have enough > IPv4 addresses on the networks I run that dual stack is a perfectly > viable solution and the idea of all of these silly variants of the NAT > shell game just turn my stomach. However, I recognize the real need in > the real world for them. > > Now, a counter-question… Do you think a WiFi tablet behind that same > smart-phone-on-cellular that gets its address via static or some other > address assignment mechanism would have the same difficulty? If not, why > not? I think the smartphone will get a prefix from the operator that is very different than the prefix that is assigned on the smartphone interface. The tablet will use that prefix to form an address. The smartphone has a different address and prefix on its CLAT-supporting interface. I am afraid there is some non-working there. I did not try it. I am stumbling on this 'root' feature. Make CLAT StdsTrack - but does it work with DHCPv6-PD? > >> If you could try this, then we can have an answer on whether or not I >> make sense. >> >> Before that, we cant say CLAT and DHCPv6-PD are ok. > > You’re making the bold assertion that CLAT fails if the /64 on the > interface is assigned by some mechanism other than 64share. As far as > I’m concerned, it’s not my responsibility to prove that assertion false, > it’s up to you to provide some factual basis behind the assertion and/or > some proof that it is valid. That's about the effort - who does the effort. I did some part of it: I shown DHCPv6-PD is possible on cellular, that modems have some problem, and that there is a 'root' problem. All these are questions that were raised on the list. I think it is up on the CLAT proponents to move on StdsTrack to answer to questions like: is CLAT compatible with existing protocols. Its not sufficient to say it's orthogonal. That does not mean anything. > >> Nothing of this is orthogonal to CLAT: CLAT does some things because the >> modem is forcing it into doing. > > Probably now is the time for us to (as usual) agree to disagree… > > Regardless of the reason CLAT was created, it is now widely deployed and > very popular. It is a pragmatic solution. Deploying it does not break > any of the protocols that are near and dear to your heart. It does not work with DHCPv6-PD. It provides > an optional way to deal with circumstances where those protocols are not > the best choice for the operator regardless of the reasons behind that. > > Would it be nice to get the modem vendors to fix the silicon? Sure. But > reality check here… They’re not going to retroactively replace the > silicon in billions of smart phones even if they can be convinced to > correct future chipsets. As such, the “right thing” is completely > infeasible in the real world. I disagree. Some look at this seriously. > > So again, I say that fixing the chipsets, DHCPv6, and IPv6-in-GTP are > all orthogonal to this discussion because there is no inherent conflict > in deploying CLAT on the phone, it simply provides yet another option > for accomplishing a similar task. > > In fact, unless I misunderstood IPv6-in-GTP, 464XLAT solves a different > problem than IPv6-in-GTP in that IPv6-in-GTP provides (roughly) the > cellular equivalent of a 6in4 tunnel rather than providing a mechanism > for an IPv6-only device to speak to an IPv4 device at the far end. For some reason, I think we discussed this already. Alex > > Owen > From nobody Wed Sep 20 22:46:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6021321A1 for ; Wed, 20 Sep 2017 22:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 mh9LDFVZHpzu for ; Wed, 20 Sep 2017 22:46:52 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB20213207A for ; Wed, 20 Sep 2017 22:46:51 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id u11so3365236ywh.7 for ; Wed, 20 Sep 2017 22:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ls2YrKSclRJW8ruXVu4bqrBuGV05eqY2d5B0TMnY6Mw=; b=gP1DGKQQllsxPHNuZU3RW6MRIiLH0tHn0JRSUG+gm6ZVx5QZ7U3UWWMN9Bwsm+nLlT X7haywPnyqUCGG4qflc8Kgo6wPUYKF+vL7n5019c2SYXSlN/9SalJ0IV/PdAhBbz1LDV ClY44iL4yXRUtiqzNb6LQh1jeymDUWq3kgA/pEaYIAhGEMMPPY64tRrasdYiqHJ+wdUq WlDlcP5pJ06/2z/pi6Mv6Y9jvLwOrLB8q/Z4Y/ESl2+rZQe+/ehAi05t5dq2s/6cDWxq AEwaOb2ICbCmaJfxlQCem3M5H0R6/rGzfFsp4tp7C/oRhR15suamA0Mv73NMLpeNe8IA mHXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ls2YrKSclRJW8ruXVu4bqrBuGV05eqY2d5B0TMnY6Mw=; b=VhZX4xZmNOw5PDnINXMlt/ZrDEsT77OQ1QkSjum+6z4Qx6+R3DCxD9GubmGXMu6wpk N2tU28iXD+dVDTLhB9JOiNH0Itan9jHT8ra073nijZcxdJ+CLorK8IeXCE8W0n228s0l 9y/0eYz8lxjKmslg455kCV8QHNqj9DDYeLSLr+N9RUvdQydPfkejFpptkR2UsGxfRSGr mz07qD39VntYa+SvdxfekLg8QYXb2/tmnTiyNcBCdLNx+rf5p0PAS7IQFz2f+/W5lkkJ 3fI9wyCA/X09zgkS2cL79shYAH5qC+tMGOJ/QnFIa+ZVuJN9zZIJJjiavxGJNoyEp+tM dZKg== X-Gm-Message-State: AHPjjUi9qwZbGv4jt/WIO7EsNBI5L7OLARaETjUEbG0Mjfgt2B50xX39 Nhjva7CIWj6aisKU2Q7Dbm/ckSwALSj3ZCER+0Qkeg== X-Google-Smtp-Source: AOwi7QDU4XxsRe2iVKFBcaIwZf4p3df6OiUeCylyeqznjZ4Ib66+o9bKltICZ+Oz4WNiFUO+QJGImxbBlfpHL+ZMtT0= X-Received: by 10.129.153.81 with SMTP id q78mr811106ywg.133.1505972810571; Wed, 20 Sep 2017 22:46:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Wed, 20 Sep 2017 22:46:29 -0700 (PDT) In-Reply-To: <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> From: Lorenzo Colitti Date: Thu, 21 Sep 2017 14:46:29 +0900 Message-ID: To: David Schinazi Cc: Jordi Palet Martinez , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c0b82906afd5a0559ac9e88" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 05:46:54 -0000 --94eb2c0b82906afd5a0559ac9e88 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 20, 2017 at 10:10 AM, David Schinazi wrote: > > If you do it with SLAAC, as described in the RFC, the NAT46 will be > stateful (by means of a previous NAT44) because you don=E2=80=99t have a = specific > /64 for the translation. Otherwise will be stateless. > > I don't think that's correct. In order to make 464XLAT stateless you need > a separate /128, not /64. And SLAAC allows you to generate that extra /12= 8. > As far as I know, this is how Android works. > The NAT46 part of 464xlat is always stateless. Device-originated traffic does not require any NAT table entries. On Android, the IPv4 stack emits packets using an IPv4 address in 192.0.0.0/29 and then we statelessly translate them to IPv6. However, when enabling IPv4 tethering, devices behind the hotspot are NATed, so that, say, 192.168.43.12 first goes through stateful NAT44 to 192.0.0.4 before being statelessly translated to IPv6. Instead of NAT4464, it would have been possible to use extra IPv6 addresses to represent the tethered devices. On mobile networks, which provide a dedicated /64 and guarantee no collisions the implementation could just statelessly translate 192.168.43.12 to c0a8:2b0c and store that in a well-known place in the IID somewhere. On networks that have other devices on them the translation would need to be stateful, and in order to make it stateless, another prefix could be requested (e.g., via DHCPv6 PD). In effect that would change NAT4464 back to NAT464 On Android we chose not to do this because of the extra complexity. We already had to support IPv4 NAT for native IPv4 connections, and it seemed pointless to save an extra NAT step when the packet always has to go through a stateful NAT64 anyway. As far the discussion of changing the Category of the RFC, I'm not sure > what it accomplishes, and whether it's worth spending time on. > +1 --94eb2c0b82906afd5a0559ac9e88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 20, 2017 at 10:10 AM, David Schinazi <dschinazi@apple.com&g= t; wrote:
> If you do it with SLAAC, as described in the RFC, the NAT46 will be s= tateful (by means of a previous NAT44) because you don=E2=80=99t have a spe= cific /64 for the translation. Otherwise will be stateless.

I don't think that's correct. In order to make 464XLAT state= less you need a separate /128, not /64. And SLAAC allows you to generate th= at extra /128. As far as I know, this is how Android works.

The NAT46 part of 464xlat is always stateless. Device-= originated traffic does not require any NAT table entries. On Android, the = IPv4 stack=C2=A0emits packets using an IPv4 address in 192.0.0.0/29 and then we statelessly translate them to IPv6= . However, when enabling IPv4 tethering, devices behind the hotspot are NAT= ed, so that, say, 192.168.43.12 first goes through stateful NAT44 to 192.0.= 0.4 before being statelessly translated to IPv6.

I= nstead of NAT4464, it would have been possible to use extra IPv6 addresses = to represent the tethered devices. On mobile networks, which provide a dedi= cated /64 and guarantee no collisions the implementation could just statele= ssly translate 192.168.43.12 to c0a8:2b0c and store that in a well-known pl= ace in the IID somewhere. On networks that have other devices on them the t= ranslation would need to be stateful, and in order to make it stateless, an= other prefix could be requested (e.g., via DHCPv6 PD). In effect that would= change NAT4464 back to NAT464

On Android we chose= not to do this because of the extra complexity. We already had to support = IPv4 NAT for native IPv4 connections, and it seemed pointless to save an ex= tra NAT step when the packet always has to go through a stateful NAT64 anyw= ay.

A= s far the discussion of changing the Category of the RFC, I'm not sure = what it accomplishes, and whether it's worth spending time on.

+1=C2=A0
--94eb2c0b82906afd5a0559ac9e88-- From nobody Wed Sep 20 23:49:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BF913304D for ; Wed, 20 Sep 2017 23:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIbsozupMG5u for ; Wed, 20 Sep 2017 23:49:44 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BBE132D14 for ; Wed, 20 Sep 2017 23:49:44 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8L6ngei084506 for ; Thu, 21 Sep 2017 08:49:42 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 597FB202315 for ; Thu, 21 Sep 2017 08:49:42 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 509682022FA for ; Thu, 21 Sep 2017 08:49:42 +0200 (CEST) Received: from [132.166.84.14] ([132.166.84.14]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8L6nfmt025870 for ; Thu, 21 Sep 2017 08:49:42 +0200 To: v6ops@ietf.org References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> From: Alexandre Petrescu Message-ID: <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> Date: Thu, 21 Sep 2017 08:49:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 06:49:46 -0000 Lorenzo - I am not interfering with your discussion, but let me say this. Le 21/09/2017 à 07:46, Lorenzo Colitti a écrit : [...] > Instead of NAT4464, it would have been possible to use extra IPv6 > addresses to represent the tethered devices. If you can make DHCPv6-PD software available on Android without needing to root-risk the device, then I can look at making DHCPv6-PD deliver these extra addresses. > On mobile networks, which provide a dedicated /64 and guarantee no > collisions Some cellular mobile network provides a dedicated /64 per UE, but also DHCPv6-PD service, at the same time. I would like to use that, on Android. > the implementation could just statelessly translate 192.168.43.12 to > c0a8:2b0c and store that in a well-known place in the IID somewhere. > On networks that have other devices on them the translation would > need to be stateful, and in order to make it stateless, another > prefix could be requested (e.g., via DHCPv6 PD). In effect that would > change NAT4464 back to NAT464 I will try to understand that, but see above what I can do. Alex > On Android we chose not to do this because of the extra complexity. > We already had to support IPv4 NAT for native IPv4 connections, and > it seemed pointless to save an extra NAT step when the packet always > has to go through a stateful NAT64 anyway. > > As far the discussion of changing the Category of the RFC, I'm not > sure what it accomplishes, and whether it's worth spending time on. > > > +1 > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Sep 20 23:52:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A4E1330B2 for ; Wed, 20 Sep 2017 23:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 Sy5H8vd2hmud for ; Wed, 20 Sep 2017 23:52:29 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF5BE132D14 for ; Wed, 20 Sep 2017 23:52:28 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id t127so3426921ywg.4 for ; Wed, 20 Sep 2017 23:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=33rAT+XhpSJve4/LSY549BPZIEAjXo82q/o3ekDKPFk=; b=oewvqfkrXp0dZiP+x2DZcjRiWpUvU/OIgOuvpGlw2HxtBqqyNXTy+SmRkycc2puLmY ycr8U2tKOZkuT2mnDgbnRZcgODziJF5x2vBR1a7JT4V1gxjsLdezEqNmtZBuJ4pLk9ET sOmWMYjFwoNCXvlHFzYWP6vvEo9Z5wX0NCWISrPrQ/FOARYNtviRwR6LoTXOSj/OyW/V fZt3hsf2bBtbMUrj1q+BKRu0mpDGeXy1m6/Wy+FVQLOKu32e1tbJ63N2GvNxmpm9uRxE xM6n6QKvmsfDhyNvdSk8wVXp5RKo6jQRAJdJzum5fXmbe8ckbKss9qzr1ZgiK5mwW4pC SOdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=33rAT+XhpSJve4/LSY549BPZIEAjXo82q/o3ekDKPFk=; b=gDtfEiXhZPzSX58rCnHx7c9+cGalSjgmoH3PgEbvRNEF3tXznmopcrcF8+9rr/PG9r P2SWKIxCgPLw97ilxM+TMcdxxokc8dPC6m2xUdFrwvzBHbViODeoAZcxL4K77tzBaX4k KSpI9IsF5lO5RV6Ahn1bTog6gUZr5PsyJW1ETN3bcrlvycuXHR2AuUgnHs6SGNtqrRGD XRofpt08aV6sJpQv/blrHjTI4jP+KGYc0GJTwBwk08vv+J+rVWMDKlT1J2/d+AOmuUht 7XmRQmtT5i2+CaVcUWrh+W+OJVAArHv1BIcCaOcGj9VSwxvjtYJhuf7DLVFN6X0KGcgh 91JA== X-Gm-Message-State: AHPjjUi711BOJe0h+fWRJB2W6V+pK0LzlKJkYnMOLzKR+Vgnn5raAGnU R+zeyk7y0ggfbOHZKMq6fcJvn440jTArq08W3BGSDjFV X-Google-Smtp-Source: AOwi7QBq+VKASDRwD44zjSp2B0ArzDbewplQj7YKm9Fe1bNe5RiGYW7Mn+9kWF6aNLlGR6PbuaJBNKdLi0HhWkPvsko= X-Received: by 10.37.204.137 with SMTP id l131mr886012ybf.259.1505976747592; Wed, 20 Sep 2017 23:52:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Wed, 20 Sep 2017 23:52:06 -0700 (PDT) In-Reply-To: <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> From: Lorenzo Colitti Date: Thu, 21 Sep 2017 15:52:06 +0900 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c07d2481538d60559ad8917" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 06:52:30 -0000 --94eb2c07d2481538d60559ad8917 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 21, 2017 at 3:49 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Instead of NAT4464, it would have been possible to use extra IPv6 >> addresses to represent the tethered devices. >> > > If you can make DHCPv6-PD software available on Android without needing > to root-risk the device, then I can look at making DHCPv6-PD deliver > these extra addresses. There's no need for any extra addresses. The traffic is already NATed once and making IPv4 go from 4464 to 464 is not worth the additional complexity, particularly because the tethered clients will have end-to-end IPv6. --94eb2c07d2481538d60559ad8917 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 21, 2017 at 3:49 PM, Alexandre Petrescu <alexandre.petr= escu@gmail.com> wrote:
Instead of NAT4464, it would have been pos= sible to use extra IPv6 addresses to represent the tethered devices.

If you can make DHCPv6-PD software available on Android without needing
to root-risk the device, then I can look at making DHCPv6-PD deliver
these extra addresses.

There's no need = for=C2=A0any extra addresses. The traffic is already NATed once and making = IPv4 go from 4464 to 464 is not worth the additional complexity, particular= ly because the tethered clients will have end-to-end IPv6.
--94eb2c07d2481538d60559ad8917-- From nobody Thu Sep 21 01:00:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56652133072 for ; Thu, 21 Sep 2017 01:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.31 X-Spam-Level: X-Spam-Status: No, score=-5.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G6uVKYrMvwK for ; Thu, 21 Sep 2017 01:00:32 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CFF71329B5 for ; Thu, 21 Sep 2017 01:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1505980830; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=TubfpDTKV+v1R2km3hg7/3BDbRfiOfxF0HIN3JUNfqg=; b=Fz+QM8O/7y7V7THRymdz2DeLe7LEHndMnjUeU2tkGlxlhd+Ou6r/sCujkqnirF+4iLBxrkOCfE2Cb25ClhHKWhqTFD2zWA2X8kYNfxW7hU9o/W0XgFPJnfOdSzM1kO58FPDGP0Mc0cmlkrXuK5IjsM4neNbNCsC//Jp71q894aM= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0214.outbound.protection.outlook.com [213.199.154.214]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-34-TPBMd-1QNbW_peUeuazdSw-1; Thu, 21 Sep 2017 09:00:26 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1075.eurprd07.prod.outlook.com (10.163.187.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 21 Sep 2017 08:00:25 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590%14]) with mapi id 15.20.0077.011; Thu, 21 Sep 2017 08:00:24 +0000 From: Tim Chown To: Fred Baker CC: JORDI PALET MARTINEZ , "v6ops@ietf.org" Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info Thread-Index: AQHTMid0qF8DhAQaXUakhFSla/huRKK97LOAgACZEwCAAHVHgA== Date: Thu, 21 Sep 2017 08:00:24 +0000 Message-ID: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> In-Reply-To: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1075; 20:sGu5CygGL0yW2A9WxNaKIdeDmfveiEPrH/z6rW7Y3l1D02cX0An2/LbBzanUklpkP8KUA/Tm35gmItJYdufA0An5fKuAc+/bJV/8V5PCYX5zRczQwE0RwnqLJT0T45pavxuAafCK7ZXggeFbB8WayUrwpV/GwCsRCAH5B1TTuCk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8de89e3e-f00f-4931-bdf5-08d500c6d0d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1075; x-ms-traffictypediagnostic: AM3PR07MB1075: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1075; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1075; x-forefront-prvs: 04371797A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(24454002)(377454003)(189002)(199003)(3660700001)(99286003)(4326008)(83716003)(82746002)(6506006)(39060400002)(189998001)(2900100001)(50226002)(6436002)(81156014)(105586002)(8936002)(106356001)(74482002)(2950100002)(81166006)(86362001)(6916009)(68736007)(42882006)(25786009)(7736002)(6116002)(3846002)(102836003)(6486002)(97736004)(316002)(786003)(53546010)(54906003)(36756003)(101416001)(2906002)(76176999)(3280700002)(6512007)(50986999)(6246003)(8676002)(33656002)(72206003)(305945005)(53936002)(57306001)(14454004)(5250100002)(66066001)(478600001)(229853002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1075; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2017 08:00:24.9190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1075 X-MC-Unique: TPBMd-1QNbW_peUeuazdSw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 08:00:36 -0000 SGkgRnJlZCwNCg0KPiBPbiAyMSBTZXAgMjAxNywgYXQgMDI6MDAsIEZyZWQgQmFrZXIgPGZyZWRi YWtlci5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPj4gT24gU2VwIDIwLCAyMDE3LCBhdCA4 OjUyIEFNLCBKT1JESSBQQUxFVCBNQVJUSU5FWiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+ IHdyb3RlOg0KPj4gDQo+Pj4gRnJvbSBteSBwZXJzcGVjdGl2ZSwgdGhlcmUgYXJlIG11bHRpcGxl IGludGVyb3BlcmFibGUgc3BlY3MuIFdlIGhhdmUgc2V2ZXJhbCBDTEFUIGNsaWVudCBpbXBsZW1l bnRhdGlvbnMvdmVuZG9ycywgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycywgYW5kIHRoZXkgd29yayBm aW5lIGluIHRoZSBzYW1lIGFuZCBkaWZmZXJlbnQgb3BlcmF0b3JzIGFuZCBpbnRlcm9wZXJhdGUg d2l0aCBkaWZmZXJlbnQgTkFUNjQgYW5kIEROUzY0IHZlbmRvcnMvaW1wbGVtZW50YXRpb25zLg0K Pj4gDQo+PiBXaGF0IEnigJltIG5vdCBzdXJlIGlzLCBiZWNhdXNlIDQ2NFhMQVQgaXMgYmFzaWNh bGx5IFJGQzYxNDUgKFNJSVQpICsgUkZDNjE0NiAoU3RhdGVmdWwgTkFUNjQpIGFuZCBhbHNvIGNh biB1c2UgUkZDNjE0NyAoRE5TNjQpLCB3aGljaCBhcmUgYWxyZWFkeSBTdGFuZGFyZHMgdHJhY2ss IGlmIHdlIG5lZWQgYWxzbyB0byBtb3ZlIHRoZW0gdG8gU1REIGluIHRoYXQgY2FzZSwgZXRjLg0K PiANCj4gSSdsbCByZXBlYXQgbXlzZWxmIGVhcmxpZXIuIExvb2tpbmcgYXQgdGhlIGRlZmluaXRp b25zIG9mIHRoZSB0ZXJtcywgdGhlcmUgaXMgbm8gcmVhc29uIGl0IGNhbid0IG9yIHNob3VsZG4n dCBiZSBCQ1AsIHdoaWNoIG91ciBjaGFydGVyIGRvZXMgYWxsb3cgdXMgdG8gZG8sIGFuZCB3aGlj aCBpcyBhIG9uZS1zaG90IHN0YW5kYXJkIG1vcmUgYXBwcm9wcmlhdGUgdG8gdGhlIGNhc2UgKElN SE8pLiBJZiB5b3Ugd2FudCBpdCB0byBiZSBhIHN0YW5kYXJkYXJkLCBhIEJDUCBpcyBhIHN0YW5k YXJkLiBMZXQncyBhZHZhbmNlIGl0IHRvIEJDUC4NCg0KSSB0aGluayB0aGVyZeKAmXMgYW4gYXJn dW1lbnQgZm9yIHRoaXMuDQoNCkJ1dCB0aGVyZSB3aWxsIGJlIHBlb3BsZSB3aG8gd2lsbCBhcmd1 ZSB0aGF0IGVuY2Fwc3VsYXRpb24gaXMgdGhlIOKAmGJlc3TigJkgcHJhY3RpY2UuICBJcyB0aGVy ZSBzY29wZSBmb3IgYSBCQ1AgYnkgdHJhbnNsYXRpb24gYW5kIGEgQkNQIGJ5IGVuY2Fwc3VsYXRp b24/ICBPciB3b3VsZCB0aGUgQkNQIHNheSBOQVQ2NC9ETlM2NC80NjRYTEFUIGlzIHRoZSBiZXN0 IHdheSB0byBzZXJ2ZSBub2RlcyBpbiBhbiBJUHY2LW9ubHkgbmV0d29yaz8NCg0KV2l0aCBJUHY0 IE5BVCwgdGhlIElFVEYgZGlkbuKAmXQgZGVmaW5lIHNwZWNpZmljIE5BVCBtZWNoYW5pc21zLCBz byB3ZSBlbmRlZCB1cCB3aXRoIG1hbnkgdmFyaWV0aWVzLCB3aXRoIGRpZmZlcmVudCBwcm9wZXJ0 aWVzLiBUaGVyZeKAmXMgYW4gYXJndW1lbnQgYWxzbyBJIHRoaW5rIHRvIG5haWwgZG93biBvbmUg c2luZ2xlIGJlc3QgdHJhbnNsYXRpb24gYXBwcm9hY2guDQoNClRpbQ== From nobody Thu Sep 21 01:02:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E19E134304 for ; Thu, 21 Sep 2017 01:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.31 X-Spam-Level: X-Spam-Status: No, score=-5.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7-LKlqT8coB for ; Thu, 21 Sep 2017 01:02:19 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5821329B5 for ; Thu, 21 Sep 2017 01:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1505980937; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=Ap0Djy+8Jktd+rqwMtWOSd7EWpj0I17iuJ5o8hCdTDc=; b=M4dj0jCkgOjZLqfnjcVBVIMSdFPXrXFl8MA5Uc8wZyyuIaPy8LfTdN8iPqnM0cRhWGaEm+jJ3uTP7ZG9aEjws4dVzfjj2ASoaVe0u8XwK+qg3X2LC/hIcu1vuroYMPqdQo+Mo8KII1Q9Z+3fG2CP33zEusHAgC+60Jk9wK8zEt4= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0208.outbound.protection.outlook.com [213.199.154.208]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-32-TAzTJJs9PlGOyWNuMCT2Ng-1; Thu, 21 Sep 2017 09:02:13 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB465.eurprd07.prod.outlook.com (10.242.113.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 21 Sep 2017 08:02:11 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590%14]) with mapi id 15.20.0077.011; Thu, 21 Sep 2017 08:02:11 +0000 From: Tim Chown To: Alexandre Petrescu CC: Ole Troan , "v6ops@ietf.org" Thread-Topic: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info Thread-Index: AQHTMiM47BtgCrn3L0KXBwQzDrO91qK95VoAgABFq4CAABYogIAADRWAgAB4wQCAADSSAA== Date: Thu, 21 Sep 2017 08:02:11 +0000 Message-ID: <6499D02A-F773-433B-BD42-40109E20E424@jisc.ac.uk> References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <3F99667F-56A6-487E-9AA6-D0FCB0BB4450@employees.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB465; 20:MhPJxa0pd+k93HCIhMEAffhFT2gtReAW9tqMqRUTA6IM4XVwXsiNzaBZ0mOkEcNVn/ghRMdHY11Iyc31Kn+mseahnClIZcyccloQDLVTmpKfRNX04T7cnHiKvPR3CLtIS8QZwFTmeS8BR629Z9KjXCFlK8ibuX9bph4k8MWh3BM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e2aea84f-32b6-44fb-ebfb-08d500c71057 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB465; x-ms-traffictypediagnostic: AM3PR07MB465: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB465; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB465; x-forefront-prvs: 04371797A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(24454002)(8676002)(81166006)(76176999)(81156014)(50986999)(25786009)(6916009)(68736007)(42882006)(8936002)(50226002)(6506006)(6436002)(6486002)(5250100002)(2950100002)(2906002)(93886005)(33656002)(3280700002)(3660700001)(14454004)(97736004)(74482002)(53546010)(229853002)(966005)(305945005)(36756003)(6306002)(478600001)(6246003)(99286003)(53936002)(83716003)(101416001)(6116002)(102836003)(39060400002)(2900100001)(7736002)(86362001)(189998001)(72206003)(82746002)(106356001)(3846002)(5660300001)(6512007)(105586002)(66066001)(4326008)(54906003)(786003)(316002)(57306001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB465; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <672909EE9A14ED498197C941E51A2867@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2017 08:02:11.4701 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB465 X-MC-Unique: TAzTJJs9PlGOyWNuMCT2Ng-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 08:02:21 -0000 SGksDQoNCj4gT24gMjEgU2VwIDIwMTcsIGF0IDA1OjU0LCBBbGV4YW5kcmUgUGV0cmVzY3UgPGFs ZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gTGUgMjAvMDkvMjAxNyDD oCAyMzo0MSwgT2xlIFRyb2FuIGEgw6ljcml0IDoNCj4+PiBCdXQgeW91IGNhbnQgaGF2ZSBzaW11 bHRhbmVvdXNseSBDTEFUIGFuZCBESENQdjYtUEQgb24gdGhlIHNhbWUNCj4+PiBjbGllbnQuIEJl Y2F1c2UgQ0xBVCB3YW50cyB0aGF0IHRvIGJlIGEgLzY0IHByZWZpeC4gIEl0IHdpbGwgYnJlYWsN Cj4+PiB3aGVuIHRoZSBjbGllbnQgZ2V0cyBhIC82My4NCj4+PiBNb3Jlb3ZlciwgZGVzaWduIHN1 Z2dlc3Rpb25zIGZyb20gQ0xBVCBhc3N1bWUgdGhhdCAvNjQgaXMNCj4+PiBzdWZmaWNpZW50LiBU aGF0IGlzIHdyb25nIC0gLzY0IGlzIG5vdCBzdWZmaWNpZW50Lg0KPj4+PiBUaGVyZSBhcmUgbG90 cyBvZiBjYXNlcyB3aGVyZSBtb3JlIHRoYW4gb25lIHNvbHV0aW9uIHRvIHRoZSBzYW1lDQo+Pj4+ IHByb2JsZW0gYmVjb21lcyBhIHN0YW5kYXJkcyB0cmFjayBSRkMuDQo+Pj4gQnV0IG9uZSB3b250 IHByb2hpYml0IHRoZSBvdGhlci4NCj4+PiBDTEFUIHByb2hpYml0cyBESENQdjYtUEQuDQo+PiBS RkM2ODc3IHNlY3Rpb24gNi4zIHN0YXRlcyB0aGUgb3Bwb3NpdGUuDQo+IA0KPiBPbGUsDQo+IA0K PiBSRkNzIGFyZSBvbmUgdGhpbmcsIGFuZCBJIGFncmVlIHdpdGggeW91LiAgQW5kIGhlcmUgd2Ug ZG8gUkZDcy4NCj4gDQo+IEJ1dCB2ZXJ5IG11Y2ggb2Ygd2hhdCBSRkNzIGRvIGlzIGZyb20gaW1w bGVtZW50YXRpb25zLg0KPiANCj4gSXQncyBoYXJkIHRvIGNsYWltIFJGQyB0aGlzIGFuZCBSRkMg dGhhdCBpZiBvbiB0aGUgb3RoZXIgaGFuZCBpdCBpcyBjbGVhciB0aGF0IEFuZHJvaWQgYmxvY2tz WypdIERIQ1B2NiBzdHJhaWdodC4gIEl0IGxvb2tzIGxpa2Ugd2Ugd291bGQgc3RpY2sgb3VyIGhl YWQgaW4gdGhlIHNhbmQuDQo+IA0KPiBBbmRyb2lkcyBhcmUgdmVyeSBudW1lcm91cyBkZXZpY2Vz LCBhbmQgUkZDcyBhcmUgbGVzcyBudW1lcm91cy4NCj4gDQo+IEhlcmUsIGluIHRoaXMgb3BlcmF0 aW9ucyBncm91cCwgdGhlcmUgaXMgbmVlZCB0aGF0IEFuZHJvaWQgYWNjZXB0cyB0aGVzZQ0KPiBS RkNzLg0KPiANCj4gQW5kIHdlIG5lZWQgdGhhdCBiZWZvcmUgd2UgZXZlbiB0YWxrIG1vdmluZyBh biBBbmRyb2lkLW9ubHkgQ0xBVCBmcm9tDQo+IElORk9STUFUSU9OQUwgdG8gc29tZXRoaW5nIGVs c2UuDQoNClRoZXJl4oCZcyBub3cgQ0xBVCBzdXBwb3J0IGluIHZhcmlvdXMgV2luZG93cyBwbGF0 Zm9ybXMgdG9vLCBpc27igJl0IHRoZXJlPw0KDQpJIGRvbuKAmXQgdGhpbmsgd2Ugc2hvdWxkIHRh bmdsZSB1cCB0aGUgYWRkcmVzcyBjb25maWd1cmF0aW9uIGRlYmF0ZSB3aXRoIDQ2NFhMQVQgKGFz IG11Y2ggYXMgSeKAmWQgcGVyc29uYWxseSBsaWtlIHRvIHNlZSBBbmRyb2lkIHN1cHBvcnQgREhD UHY2Li4pLg0KDQpUaW0NCg0KPiBBbGV4DQo+IFBTOiB0byBzdXBwb3J0IHRoZSBjbGFpbSB0aGF0 IEFuZHJvaWQgZXhwbGljaXRlbHkgYmxvY2tzIERIQ1B2NiwgSSBjYW4NCj4gcHJvdmlkZSBwb2lu dGVycyB0byBwdWJsaWMgR29vZ2xlIHBhZ2VzLCBudW1lcm91cyByZXF1ZXN0cyBvZiBESENQdjYN Cj4gaW50ZWdyYXRpb24gaW4gQW5kcm9pZCAodG8gYXZvaWQgbmVlZCBvZiAncm9vdGluZycgdGhl IGRldmljZXMpLCB0aGUNCj4gYXZhaWxhYmlsaXR5IG9mIERIQ1B2NiBhcHAgaW4gQW5kcm9pZCBz dG9yZSB0aGF0IHJ1bnMgb25seSBvbiBXaUZpIGFuZA0KPiBtdXN0ICdyb290JywgaW52aXRhdGlv bnMgZnJvbSBjb21wZXRpdG9yIE9TcyB0byBicmluZyBESENQdjYgdGhlcmUNCj4gaW5zdGVhZCBv ZiBBbmRyb2lkLCBhbmQgbW9yZS4NCj4gDQo+PiBPbGUNCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2 Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzDQo+IA0KDQo= From nobody Thu Sep 21 01:02:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA80A134457 for ; Thu, 21 Sep 2017 01:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnYh3OilnGmX for ; Thu, 21 Sep 2017 01:02:34 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B52133072 for ; Thu, 21 Sep 2017 01:02:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8L82VUE005854; Thu, 21 Sep 2017 10:02:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 580F42034FE; Thu, 21 Sep 2017 10:02:31 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 411DE203513; Thu, 21 Sep 2017 10:02:31 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8L82UWD023666; Thu, 21 Sep 2017 10:02:31 +0200 To: Lorenzo Colitti Cc: "v6ops@ietf.org WG" References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> From: Alexandre Petrescu Message-ID: <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> Date: Thu, 21 Sep 2017 10:02:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 08:02:37 -0000 Le 21/09/2017 à 08:52, Lorenzo Colitti a écrit : > On Thu, Sep 21, 2017 at 3:49 PM, Alexandre Petrescu > > wrote: > > Instead of NAT4464, it would have been possible to use extra > IPv6 addresses to represent the tethered devices. > > > If you can make DHCPv6-PD software available on Android without needing > to root-risk the device, then I can look at making DHCPv6-PD deliver > these extra addresses. > > > There's no need for any extra addresses. The traffic is already NATed > once and making IPv4 go from 4464 to 464 is not worth the additional > complexity, particularly because the tethered clients will have > end-to-end IPv6. I am not sure how the tethered clients will have end-to-end IPv6 if they dont have a prefix dedicated to them. Or maybe do you propose that to be 64share? Alex From nobody Thu Sep 21 01:05:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18C9133072 for ; Thu, 21 Sep 2017 01:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zowSS8Vrz1LV for ; Thu, 21 Sep 2017 01:05:06 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87437132025 for ; Thu, 21 Sep 2017 01:05:06 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 31DE82D5024; Thu, 21 Sep 2017 08:05:05 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C2CE210B9FF0D; Thu, 21 Sep 2017 10:05:02 +0200 (CEST) From: Ole Troan Message-Id: <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_06A222FF-7A28-4F11-A996-6C96B0A1BA27"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 21 Sep 2017 10:05:01 +0200 In-Reply-To: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> Cc: Fred Baker , "v6ops@ietf.org" To: Tim Chown References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 08:05:09 -0000 --Apple-Mail=_06A222FF-7A28-4F11-A996-6C96B0A1BA27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>>> =46rom my perspective, there are multiple interoperable specs. We = have several CLAT client implementations/vendors, from different = vendors, and they work fine in the same and different operators and = interoperate with different NAT64 and DNS64 vendors/implementations. >>>=20 >>> What I=E2=80=99m not sure is, because 464XLAT is basically RFC6145 = (SIIT) + RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), = which are already Standards track, if we need also to move them to STD = in that case, etc. >>=20 >> I'll repeat myself earlier. Looking at the definitions of the terms, = there is no reason it can't or shouldn't be BCP, which our charter does = allow us to do, and which is a one-shot standard more appropriate to the = case (IMHO). If you want it to be a standardard, a BCP is a standard. = Let's advance it to BCP. >=20 > I think there=E2=80=99s an argument for this. >=20 > But there will be people who will argue that encapsulation is the = =E2=80=98best=E2=80=99 practice. Is there scope for a BCP by = translation and a BCP by encapsulation? Or would the BCP say = NAT64/DNS64/464XLAT is the best way to serve nodes in an IPv6-only = network? >=20 > With IPv4 NAT, the IETF didn=E2=80=99t define specific NAT mechanisms, = so we ended up with many varieties, with different properties. There=E2=80= =99s an argument also I think to nail down one single best translation = approach. Yes, I do wonder in what alternate universe the IETF consensus is that = best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-) Ole --Apple-Mail=_06A222FF-7A28-4F11-A996-6C96B0A1BA27 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZw3KuAAoJEL7aWKiYQt92sIAP/Ah+BskyoaubQhEG06vjeiYd htw4N7GyR7pg7MvhrZmtkprPYdb4L7/RlOBJAQJ+0RQNn/Pm/G57ocs6mkoKLYif fAl/l5uw3hp7VlgS5aszmHneGJHwGL/80+/Bka284nqM2OP7Oq2JyjFh9n76wHzv r4J+vXv23r5CyrrkHZ7oGAfhfoqVWrC0jAhkxhOj7X/axr3JSj4vburpPtgGB+zU RAYtYU7POp/NFtzFNfEmGMF4uoO+FVgi7RU8kKaIJeKDDQVe9JkM0gR6HGpADDuW xV5l5nScaz4lOl/4dBUsU7Z07GcLicHREkaHmPj+58GNp3Y+/dGBtHRH8RdjB3yr O7Ka6ynAoIcocUh3az/0GA4OVfpqa4jumIT1APuZPnUwLQZALZR/yoj5BX2tVHO/ 3cCt491aEEgWZ50fGEAhG83AF0tq56gB9faLDiSHYpWeA3HsNnb6z16dVhwCkdnv //AT/Qq//xt6XlcaQV/DGQdcqLh/WdkDypYiHcKmuX90Vx0NPp82doVLG4xcHbfA PzyjsQT4gBrGnRs8cdiDXjrjsNu1UvsPdcP4uv/Z1MnZNOl6WSyeIwKyAvsExSIf /iGvqQKlQDJQWTnoq4L5xyDw8ELCWE10WJYKm/5rQoqe6kR56Pjcw0mILEQNSDCn 3bvIp8OTwihXuluQx7vp =mM/T -----END PGP SIGNATURE----- --Apple-Mail=_06A222FF-7A28-4F11-A996-6C96B0A1BA27-- From nobody Thu Sep 21 01:10:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44921286C7 for ; Thu, 21 Sep 2017 01:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, MISSING_HEADERS=1.021, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5BJeYOVop1g for ; Thu, 21 Sep 2017 01:10:08 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A77132025 for ; Thu, 21 Sep 2017 01:10:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8L8A6BK125928 for ; Thu, 21 Sep 2017 10:10:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 36A8020262F for ; Thu, 21 Sep 2017 10:10:06 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 274082025F1 for ; Thu, 21 Sep 2017 10:10:06 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8L8A5j9032541 for ; Thu, 21 Sep 2017 10:10:06 +0200 Cc: "v6ops@ietf.org WG" References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> From: Alexandre Petrescu Message-ID: <888e6f9c-3351-2e50-a12e-bf5280d81294@gmail.com> Date: Thu, 21 Sep 2017 10:10:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Forget CLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 08:10:11 -0000 Le 21/09/2017 à 08:52, Lorenzo Colitti a écrit : > On Thu, Sep 21, 2017 at 3:49 PM, Alexandre Petrescu > > wrote: [...] > There's no need for any extra addresses. I think we should stop here. Forget CLAT. Alex From nobody Thu Sep 21 01:14:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D061331FF for ; Thu, 21 Sep 2017 01:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgDivdYCa0iP for ; Thu, 21 Sep 2017 01:14:25 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7651331F6 for ; Thu, 21 Sep 2017 01:14:25 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id F00DB34C31C; Thu, 21 Sep 2017 08:13:53 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D8AD2160077; Thu, 21 Sep 2017 08:13:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 832EE160073; Thu, 21 Sep 2017 08:13:53 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id j38KFPizBq7Z; Thu, 21 Sep 2017 08:13:53 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 04BE2160036; Thu, 21 Sep 2017 08:13:53 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 900B087819F5; Thu, 21 Sep 2017 18:13:50 +1000 (AEST) To: Ole Troan Cc: Tim Chown , "v6ops@ietf.org" From: Mark Andrews References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> In-reply-to: Your message of "Thu, 21 Sep 2017 10:05:01 +0200." <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> Date: Thu, 21 Sep 2017 18:13:50 +1000 Message-Id: <20170921081350.900B087819F5@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 08:14:26 -0000 In message <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org>, Ole Troan writes: > > >>>> From my perspective, there are multiple interoperable specs. We have > >>>> several CLAT client implementations/vendors, from different vendors, and > >>>> they work fine in the same and different operators and interoperate with > >>>> different NAT64 and DNS64 vendors/implementations. > >>> > >>> What I’m not sure is, because 464XLAT is basically RFC6145 (SIIT) + > >>> RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are > >>> already Standards track, if we need also to move them to STD in that > >>> case, etc. > >> > >> I'll repeat myself earlier. Looking at the definitions of the terms, > >> there is no reason it can't or shouldn't be BCP, which our charter does > >> allow us to do, and which is a one-shot standard more appropriate to the > >> case (IMHO). If you want it to be a standardard, a BCP is a standard. > >> Let's advance it to BCP. > > > > I think there’s an argument for this. > > > > But there will be people who will argue that encapsulation is the > > ‘best’ practice. Is there scope for a BCP by translation and a BCP by > > encapsulation? Or would the BCP say NAT64/DNS64/464XLAT is the best way > > to serve nodes in an IPv6-only network? > > > > With IPv4 NAT, the IETF didn’t define specific NAT mechanisms, so we > > ended up with many varieties, with different properties. There’s an > > argument also I think to nail down one single best translation approach. > > Yes, I do wonder in what alternate universe the IETF consensus is that > best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-) > > Ole Hopefully not this one. Just because there is a $billion company doing something it doesn't make it best practice. There is also plenty of PD-Lite out there which has none of the side effects of NAT46 + NAT64 + DNS64. Mar -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Sep 21 01:31:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F8113207A for ; Thu, 21 Sep 2017 01:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEPG6Z3Uv6Px for ; Thu, 21 Sep 2017 01:31:14 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041EA127517 for ; Thu, 21 Sep 2017 01:31:14 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id AE453AF; Thu, 21 Sep 2017 10:31:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1505982670; bh=kWzpGXhVN3TwrEuaftRvixOZtKjcnuxiY506JGf4/MU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=4Sei8s4My4LqMPcUnHqTRSlQJpNVJuGD+GZgH7DE+gGnd6q6X5kusVUCKa9XmrTWB LSLIaqwepiN7azCTIUb38O0si1vyePAN3KUk1JYHMt4vO8HYkWW94d90Hl+hpZRGNx CicUDtdcDHuap2AcoUJxJv8UusuoJWIzb6tLnlIk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9650184; Thu, 21 Sep 2017 10:31:10 +0200 (CEST) Date: Thu, 21 Sep 2017 10:31:10 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Lorenzo Colitti , "v6ops@ietf.org WG" In-Reply-To: <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> Message-ID: References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 08:31:21 -0000 On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > I am not sure how the tethered clients will have end-to-end IPv6 if they > dont have a prefix dedicated to them. Or maybe do you propose that to > be 64share? That's what android already does, and have done for years. Probably Apple iOS devices as well. RFC7278. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 21 01:34:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8B11331FF for ; Thu, 21 Sep 2017 01:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8KImJ3pjjQm for ; Thu, 21 Sep 2017 01:34:25 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A7B1323B4 for ; Thu, 21 Sep 2017 01:34:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8L8YMxr139574; Thu, 21 Sep 2017 10:34:22 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B131A2038CB; Thu, 21 Sep 2017 10:34:22 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9861620387A; Thu, 21 Sep 2017 10:34:22 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8L8YM4s025873; Thu, 21 Sep 2017 10:34:22 +0200 To: Mikael Abrahamsson Cc: Lorenzo Colitti , "v6ops@ietf.org WG" References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 21 Sep 2017 10:34:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 08:34:27 -0000 Le 21/09/2017 à 10:31, Mikael Abrahamsson a écrit : > On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > >> I am not sure how the tethered clients will have end-to-end IPv6 if >> they dont have a prefix dedicated to them.  Or maybe do you propose >> that to be 64share? > > That's what android already does, and have done for years. Probably > Apple iOS devices as well. RFC7278. So you propose moving 64share to BCP as well? Alex > From nobody Thu Sep 21 01:35:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAA7133054 for ; Thu, 21 Sep 2017 01:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXLydSGXijBb for ; Thu, 21 Sep 2017 01:35:33 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793B213301E for ; Thu, 21 Sep 2017 01:35:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8L8ZVVj140229 for ; Thu, 21 Sep 2017 10:35:31 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B5068204A17 for ; Thu, 21 Sep 2017 10:35:31 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A0E652039D5 for ; Thu, 21 Sep 2017 10:35:31 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8L8ZVwV027179 for ; Thu, 21 Sep 2017 10:35:31 +0200 From: Alexandre Petrescu To: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> Message-ID: <77592521-3c68-e894-1792-d0349217ca14@gmail.com> Date: Thu, 21 Sep 2017 10:35:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] dont reclassify 464XLAT as BCP instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 08:35:35 -0000 Mr. Baker, With all due respect, here is my comment. Le 21/09/2017 à 03:00, Fred Baker a écrit : > > >> On Sep 20, 2017, at 8:52 AM, JORDI PALET MARTINEZ >> wrote: >> >>> From my perspective, there are multiple interoperable specs. We >>> have several CLAT client implementations/vendors, from different >>> vendors, and they work fine in the same and different operators >>> and interoperate with different NAT64 and DNS64 >>> vendors/implementations. >> >> What I’m not sure is, because 464XLAT is basically RFC6145 (SIIT) >> + RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which >> are already Standards track, if we need also to move them to STD >> in that case, etc. > > I'll repeat myself earlier. Looking at the definitions of the terms, > there is no reason it can't or shouldn't be BCP, which our charter > does allow us to do, and which is a one-shot standard more > appropriate to the case (IMHO). If you want it to be a standardard, > a BCP is a standard. Let's advance it to BCP. I would not suggest making something that relies on IPv4, or an INFORMATIONAL 64share, a BCP. For the 'billions' argument - it is the easiness of duplicating matters on Computers, not about their righteousness. One can duplicate good things, but one can also duplicate bad things, with the same easiness. Alex From nobody Thu Sep 21 01:48:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7758513448D for ; Thu, 21 Sep 2017 01:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkst6QMYC-jw for ; Thu, 21 Sep 2017 01:48:37 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F62913447E for ; Thu, 21 Sep 2017 01:48:37 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7CB59AF; Thu, 21 Sep 2017 10:48:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1505983715; bh=ixZSrXGRDc3uZ6Bi+8cN1ZYlqYR1DlyIw5vG4bOsWf0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=xsWVppD7qmndunXAgbvhFAu342wG9QrA8WX92SyYcT2B8Lub62unNH6gB+bZZ3ZF1 6CsbIknFk/nFcp4+Wh+clQ+XgsdSxeKSZAxn01OT0liKVxxm+BauSTd4DOQXJwgCHW jtNWBm0JmQ28GcaE8PyY3Tjyb/eIv7Q+pHIaKPQA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7A37C84; Thu, 21 Sep 2017 10:48:35 +0200 (CEST) Date: Thu, 21 Sep 2017 10:48:35 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: "v6ops@ietf.org WG" In-Reply-To: Message-ID: References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-1154239519-1505983715=:29378" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 08:48:38 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1154239519-1505983715=:29378 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > > > Le 21/09/2017 à 10:31, Mikael Abrahamsson a écrit : >> On Thu, 21 Sep 2017, Alexandre Petrescu wrote: >> >>> I am not sure how the tethered clients will have end-to-end IPv6 if they >>> dont have a prefix dedicated to them.  Or maybe do you propose that to be >>> 64share? >> >> That's what android already does, and have done for years. Probably Apple >> iOS devices as well. RFC7278. > > So you propose moving 64share to BCP as well? I am not proposing anything. I have no objections to it being moved to BCP though, sounds like a good idea. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1154239519-1505983715=:29378-- From nobody Thu Sep 21 03:20:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90938134835 for ; Thu, 21 Sep 2017 03:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 tEXfyAb8KT_L for ; Thu, 21 Sep 2017 03:20:31 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09FD0134838 for ; Thu, 21 Sep 2017 03:20:24 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id u205so3725863ywa.5 for ; Thu, 21 Sep 2017 03:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WN3TelueaKoRbuQB2Z87DKbtkjmq5h+iK0Bu7HBQ+Yg=; b=v1vDUhwu8H0YCrQXMpIkV+aldEPs2aQRAsYNRMVGbMewgHoWS3QQ97FrPGJ68MN/pr ryyzej50aewI+yKdZBDk1dNq9KhzdKDcF5eemeQbh/PBthkCvT6X7ATHVElq2rEIvr5C FmEOWs+OeqoAZUERI95GPaT8/aPCOmLREPVdm1Hc6GsV0qutwYGfL+d5QcgRi80V+9d7 IKM7lydP/fVQe0mQjJrdUeQaGU8T3EMgIB2isOq7GVyGiPpnfG3kdY7p4+dE7eA1vqEk T/d45lA1VUj3gP7HvJ9Akazejw54fWdvXiyyTq82LEbFkBnFjDh+eD2VUBWj0h6qjIry czVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WN3TelueaKoRbuQB2Z87DKbtkjmq5h+iK0Bu7HBQ+Yg=; b=j0HJhlz0FgNwI5Ni1hezUzkOILEq7Xhqqw2ASyADxP6KEipgYv2jeNHb1CngKwP0by WBi2OMOiRK7coaME0L6dCHlbVAJ6vZsID9zJqPOi9ucKLTO8pMDntXmCjedTTZG1suuf AxkFapXtQNRkfW8lN4XCPrLDAHNJex7HaKI3PmVohNwngg8fdWnUY48LNW+2WPOIQokQ hm9OTjkBnl58qyax2ggg4IqPNSevMYu23AX2vYT6EikWbq8WXzyU7kIHJsbOOKQVcmwX nuj6jkgDmW1BSuUUhn6HM3SewJM6MJizHLsTo/wluMbQDqa58Il6sJhhXOEzEqJoLxwx bSrw== X-Gm-Message-State: AHPjjUgOEpaVKxIWoulYqnMpcRAQcUdV97HojIal4XjhWgn1sAZTLqcr sGM2LbstiCjddUW4Ava7TROhfqI2cm7o0/NNume92Q== X-Google-Smtp-Source: AOwi7QDLIBkuft9wSImovvRaNtQ5tr6s57h8c4nv4F1f/IUkNgWF+Idi9W5IMPwWJfM4+hRCX3xVknCbcWDS93Ik/Pg= X-Received: by 10.37.16.193 with SMTP id 184mr1286077ybq.178.1505989223798; Thu, 21 Sep 2017 03:20:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Thu, 21 Sep 2017 03:20:03 -0700 (PDT) In-Reply-To: <888e6f9c-3351-2e50-a12e-bf5280d81294@gmail.com> References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <888e6f9c-3351-2e50-a12e-bf5280d81294@gmail.com> From: Lorenzo Colitti Date: Thu, 21 Sep 2017 19:20:03 +0900 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a113eddbab8ef2b0559b07082" Archived-At: Subject: Re: [v6ops] Forget CLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 10:20:36 -0000 --001a113eddbab8ef2b0559b07082 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 21, 2017 at 5:10 PM, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > There's no need for any extra addresses. >> > > I think we should stop here. > > Forget CLAT. > No, sorry. We shouldn't forget something that tens of millions of Internet users use every day. To be clear: I don't think we need to do anything about 464xlat. We have an RFC. We have implementations. They work. Nothing special to be done here. But we should not forget about the technologies that real world networks are built on. If we do that, the IETF will rapidly become irrelevant. --001a113eddbab8ef2b0559b07082 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 21, 2017 at 5:10 PM, Alexandre Petrescu <alexandre.petr= escu@gmail.com> wrote:
There'= s no need for=C2=A0any extra addresses.

I think we should stop here.

Forget CLAT.

No, sorry. We shouldn'= t forget something that tens of millions of Internet users use every day.

To be clear: I don't think we need to do anythi= ng about 464xlat. We have an RFC. We have implementations. They work. Nothi= ng special to be done here. But we should not forget about the technologies= that real world networks are built on.=C2=A0If we do that, the IETF will r= apidly become irrelevant.
--001a113eddbab8ef2b0559b07082-- From nobody Thu Sep 21 03:29:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C1B134878 for ; Thu, 21 Sep 2017 03:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTCESDmxXpyo for ; Thu, 21 Sep 2017 03:28:58 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D5B13486E for ; Thu, 21 Sep 2017 03:28:57 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8LAStrF032522; Thu, 21 Sep 2017 12:28:55 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 77736204D43; Thu, 21 Sep 2017 12:28:55 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 607BA204A18; Thu, 21 Sep 2017 12:28:55 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8LASth5024939; Thu, 21 Sep 2017 12:28:55 +0200 To: Lorenzo Colitti Cc: "v6ops@ietf.org WG" References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <888e6f9c-3351-2e50-a12e-bf5280d81294@gmail.com> From: Alexandre Petrescu Message-ID: <1952654c-519d-2740-e026-e447caf57a86@gmail.com> Date: Thu, 21 Sep 2017 12:28:55 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Forget CLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 10:28:59 -0000 Le 21/09/2017 à 12:20, Lorenzo Colitti a écrit : > On Thu, Sep 21, 2017 at 5:10 PM, Alexandre Petrescu > > wrote: > > There's no need for any extra addresses. > > > I think we should stop here. > > Forget CLAT. > > > No, sorry. We shouldn't forget something that tens of millions of > Internet users use every day. > > To be clear: I don't think we need to do anything about 464xlat. We have > an RFC. We have implementations. They work. Nothing special to be done > here. But we should not forget about the technologies that real world > networks are built on. If we do that, the IETF will rapidly become > irrelevant. It's as if I talk about some funny networks on another planet? I propose we discuss responsibly, Lorenzo. Alex From nobody Thu Sep 21 03:33:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B711348BE for ; Thu, 21 Sep 2017 03:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPA78nT_UcPO for ; Thu, 21 Sep 2017 03:33:44 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501A81348BC for ; Thu, 21 Sep 2017 03:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505990021; x=1506594821; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=LCk/PFniq2sEt6SJUUaQM4Xbg iNM9CF/Si/xyt3bmfc=; b=Xta47q3hgjdBYiAgHHd0WLrvbQkt18qBPok1MhLld oGpbA8iADI/Q0mzyN0TXYIDHWgCdT2jZ6HlWMMRmCyBEcBEdGTQ58wZw5qWMIFNn OnNV2pbAS2XCD5Lc+jXgmzcxNCVAUG14YGEdhR1+duFHi+k3ObrjbgQays8E8FWZ fo= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=kjPapezn2A3Pp5L90ziNE0fP6+kKaKDYshQ8aJJEirw/SCr0aPLP8M2SDZfs sY2ieYj/Zx4y9E/8pv8bB/aCu0wrBSlOh3YLA3NnuUc3lllKqBE0IAt5w LrNYJka4rEpy0oguhRHOFbkXEs2uvjwulWbqjYuGUwJ1kXEBcMWYSk=; X-MDAV-Processed: mail.consulintel.es, Thu, 21 Sep 2017 12:33:41 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 21 Sep 2017 12:33:40 +0200 Received: from [10.0.5.203] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005562101.msg for ; Thu, 21 Sep 2017 12:33:40 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170921:md50005562101::hmehMLfGj7vSXjEU:000000lv X-Return-Path: prvs=14370a98a6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Thu, 21 Sep 2017 07:33:36 -0300 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org WG" Message-ID: <78CED789-6366-4CE0-8CC9-E630B13F743C@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 10:33:46 -0000 Yes, why not? Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: jueves, 21 de septiembre de 2017, 5:35 Para: Mikael Abrahamsson CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info =20 =20 Le 21/09/2017 =C3=A0 10:31, Mikael Abrahamsson a =C3=A9crit : > On Thu, 21 Sep 2017, Alexandre Petrescu wrote: >=20 >> I am not sure how the tethered clients will have end-to-end IPv6 if= =20 >> they dont have a prefix dedicated to them. Or maybe do you propose= =20 >> that to be 64share? >=20 > That's what android already does, and have done for years. Probably= =20 > Apple iOS devices as well. RFC7278. =20 So you propose moving 64share to BCP as well? =20 Alex =20 >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Sep 21 03:57:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F2C1348EB for ; Thu, 21 Sep 2017 03:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMd5WRsBpZcr for ; Thu, 21 Sep 2017 03:57:13 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71A21348DF for ; Thu, 21 Sep 2017 03:57:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8LAvBa5044115 for ; Thu, 21 Sep 2017 12:57:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 13C53207C5B for ; Thu, 21 Sep 2017 12:57:11 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 09A6D202DEB for ; Thu, 21 Sep 2017 12:57:11 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8LAvAWN015966 for ; Thu, 21 Sep 2017 12:57:10 +0200 To: v6ops@ietf.org References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> <78CED789-6366-4CE0-8CC9-E630B13F743C@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Thu, 21 Sep 2017 12:57:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <78CED789-6366-4CE0-8CC9-E630B13F743C@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 10:57:14 -0000 Le 21/09/2017 à 12:33, JORDI PALET MARTINEZ a écrit : > Yes, why not? Because DHCPv6-PD does that. Alex > > Regards, > Jordi > > > -----Mensaje original----- > De: v6ops en nombre de Alexandre Petrescu > Responder a: > Fecha: jueves, 21 de septiembre de 2017, 5:35 > Para: Mikael Abrahamsson > CC: "v6ops@ietf.org WG" > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info > > > > Le 21/09/2017 à 10:31, Mikael Abrahamsson a écrit : > > On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > > > >> I am not sure how the tethered clients will have end-to-end IPv6 if > >> they dont have a prefix dedicated to them. Or maybe do you propose > >> that to be 64share? > > > > That's what android already does, and have done for years. Probably > > Apple iOS devices as well. RFC7278. > > So you propose moving 64share to BCP as well? > > Alex > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Sep 21 03:58:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F0F1348EE for ; Thu, 21 Sep 2017 03:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8TkngIP-39c for ; Thu, 21 Sep 2017 03:57:57 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4991348E9 for ; Thu, 21 Sep 2017 03:57:57 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4EC0540EC9 for ; Thu, 21 Sep 2017 12:57:55 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 476E140BA2; Thu, 21 Sep 2017 12:57:54 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 390E88AB2; Thu, 21 Sep 2017 12:57:54 +0200 (CEST) Date: Thu, 21 Sep 2017 12:57:54 +0200 From: Gert Doering To: Brian E Carpenter Cc: Gert Doering , Philip Homburg , v6ops@ietf.org Message-ID: <20170921105754.GC45648@Space.Net> References: <90BCC38D-5B70-40EB-ACD5-925BA94C4A22@gmail.com> <3c683efc-44a4-8a75-5c02-736cf247cd4d@gmail.com> <20170920172022.GB45648@Space.Net> <1a1fa476-ae2a-cf0a-f30c-473ff26da5b1@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PGSCMQbQsZJTAnAf" Content-Disposition: inline In-Reply-To: <1a1fa476-ae2a-cf0a-f30c-473ff26da5b1@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] LAN behavior when there's no IPv4 Internet access X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 10:57:59 -0000 --PGSCMQbQsZJTAnAf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Sep 21, 2017 at 08:35:18AM +1200, Brian E Carpenter wrote: > You're missing my point. Obviously Win98 was a provocative example, but t= he > point is that ISPs will do whatever they have to do to avoid help desk ca= lls. > If switching off IPv4 generates help desk calls, they will never do it. E= OM. True. But if you can make a few millions by selling off your IPv4 address block, this might counter a few helpdesk calls... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --PGSCMQbQsZJTAnAf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnDmy8ACgkQ31bAZeTO f8UNvhAAkAAwCZXLICAFgCrRBPThJB78Ph3c5F8JPEwZ9ITiDauMM/aQQ1hlc+Xk KjPRLoW3NXCUEdOlvEqRVJf+R2Q+t127JQpFfMpkLtMmUVccqwFfMly1yZjeIRCv KjmkRT8p0yyYaQAsY63tysiUTTSxI8LopoS3du2hJbf3Q0y1LX14xFOfTJqd45e2 wjpeYodBmxFI2Agy6we5i9LrBqIdcTNgfmqhlrldkQXwDc38X4MfvYZ4ntoBeuEr 2EAgXO+HMwsKQvB64g33IHjQpox94lYv4EaalMbE/iJv7FuIw9kD/ItfDGOkdwWF dOMT85nMSmhw0HuhVfc7iJhxCxl0f+wjzK9pmWDmI6q6MKWlsNIuM/plT4SMj4dZ VEH/UW0rI4l8jULOiZetrNJ6zkcGFXIqzQJncWJfz7z9zn0jjaCK5ndkqtwGIsM1 K/xhWQFQwKAoEJ2cviZsxLfLoXHNNJyGrkavoysrtPhat711sW6wxH4ibZxu5gov 3CjEOraGd94hyA9ngB1VNEds8FcYdCnmp6pNxVeP1ItmhloUATgPe0FIBFq/rfW8 3FRZZWez3+r9MLBTYDTNxx9Da3Tr4o5KgDbhXDIdM1zEezZSIKeDef3BBrvkwkUf V34Bvv75JOrEaaW7lUyIFk3JXkfQOyL2AFD92AfiBaq8W6Qvaag= =lLau -----END PGP SIGNATURE----- --PGSCMQbQsZJTAnAf-- From nobody Thu Sep 21 04:03:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A11B1348F3 for ; Thu, 21 Sep 2017 04:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhRNPODqXcr8 for ; Thu, 21 Sep 2017 04:03:36 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B58133078 for ; Thu, 21 Sep 2017 04:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1505991814; x=1506596614; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=3TI3R/zdGtRCWEavgP86m8VIg 3sB91D/RfslMj/My8s=; b=Qj3vm4OhOYso/WE1TFUe6GmXIIRbogu2I4V0E10S1 RUuDNZS8KsrRiICA0lOj8Y2c+t6yxYEBZpvhVrzsj7vueGZJrsGHtlsVe+k/VLKC z2a/4MwEP++Moz0wvIpDfoqU1wpzWqB7zCEksG+OmpKypuZcQt4ktBv6hOfhBtjb rc= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=GyWbnlqZ+75Hvkv8/pQcrP0UoNlQrKgPBClj2hLlAPU/6jSe8JZ87bF2WBoL DPcq7QE+YaUayoVyH2c7GxUkUcxr2t5UtsW8Xi8ZdbDFcwYCQ/oZ5uOPM hrHkdzQST0ZF4YOeBY+G8D0rC1FmKCYup3QzXPyUKENx4w8JYN5UyA=; X-MDAV-Processed: mail.consulintel.es, Thu, 21 Sep 2017 13:03:34 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 21 Sep 2017 13:03:33 +0200 Received: from [10.0.5.203] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005562122.msg for ; Thu, 21 Sep 2017 13:03:32 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170921:md50005562122::P13t0AHEHtis26ll:0000E3WX X-Return-Path: prvs=14370a98a6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Thu, 21 Sep 2017 08:03:24 -0300 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> <78CED789-6366-4CE0-8CC9-E630B13F743C@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 11:03:38 -0000 DHCPv6-PD is a good thing to have. I=E2=80=99ve confronted thoughts on DHCP= v6 vs SLAAC =E2=80=A6 However, I understand it will be nice to have DHCPv6 = implemented everywhere, as for example enterprise environments prefer a mor= e controlled environment. However, having DHCPv6 doesn=E2=80=99t exclude having 64share as well. Otherwise, if we follow your suggestion, we should cleanup 60-70% of the pr= otocols that we have, because they are redundant. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: jueves, 21 de septiembre de 2017, 7:57 Para: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info =20 =20 Le 21/09/2017 =C3=A0 12:33, JORDI PALET MARTINEZ a =C3=A9crit : > Yes, why not? =20 Because DHCPv6-PD does that. =20 Alex =20 >=20 > Regards, > Jordi > =20 >=20 > -----Mensaje original----- > De: v6ops en nombre de Alexandre Petrescu > Responder a: > Fecha: jueves, 21 de septiembre de 2017, 5:35 > Para: Mikael Abrahamsson > CC: "v6ops@ietf.org WG" > Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info >=20 > =20 > =20 > Le 21/09/2017 =C3=A0 10:31, Mikael Abrahamsson a =C3=A9crit : > > On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > > > >> I am not sure how the tethered clients will have end-to-end I= Pv6 if > >> they dont have a prefix dedicated to them. Or maybe do you p= ropose > >> that to be 64share? > > > > That's what android already does, and have done for years. Pro= bably > > Apple iOS devices as well. RFC7278. > =20 > So you propose moving 64share to BCP as well? > =20 > Alex > =20 > > > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Sep 21 04:10:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41411348FB for ; Thu, 21 Sep 2017 04:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YMkjQf7pgov for ; Thu, 21 Sep 2017 04:10:41 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B02132D41 for ; Thu, 21 Sep 2017 04:10:40 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8LBAca7001196 for ; Thu, 21 Sep 2017 13:10:38 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7BF60207CEC for ; Thu, 21 Sep 2017 13:10:38 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7264E207CEB for ; Thu, 21 Sep 2017 13:10:38 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8LBAb5K026022 for ; Thu, 21 Sep 2017 13:10:37 +0200 To: v6ops@ietf.org References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> <78CED789-6366-4CE0-8CC9-E630B13F743C@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Thu, 21 Sep 2017 13:10:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 11:10:44 -0000 Le 21/09/2017 à 13:03, JORDI PALET MARTINEZ a écrit : > DHCPv6-PD is a good thing to have. I’ve confronted thoughts on DHCPv6 > vs SLAAC … However, I understand it will be nice to have DHCPv6 > implemented everywhere, as for example enterprise environments prefer > a more controlled environment. > > However, having DHCPv6 doesn’t exclude having 64share as well. It does: try to run both on a computer and you will see. In practice: a particular operator had to make some choice some time. That choice led to either 64share on an APN, or DHCPv6-PD on another APN. They had some reason to put each such thing on a distinct APN. It's not simply a matter of having two distinct RFCs. I can live with thousands of RFCs if you wish. But I cant live with different APN each for an RFC. I dont want a Connection Management software to switch between APNs like that. I am not sure whether I explain this ok, but that's the way it is. > Otherwise, if we follow your suggestion, we should cleanup 60-70% of > the protocols that we have, because they are redundant. In this discussion we talk 64share and DHCPv6-PD. Pick one. (for the other 60-70% protocols in MIB we can discuss separately if you wish). Alex > > Regards, Jordi > > > -----Mensaje original----- De: v6ops en > nombre de Alexandre Petrescu Responder > a: Fecha: jueves, 21 de septiembre de > 2017, 7:57 Para: Asunto: Re: [v6ops] reclassify > 464XLAT as standard instead of info > > > > Le 21/09/2017 à 12:33, JORDI PALET MARTINEZ a écrit : >> Yes, why not? > > Because DHCPv6-PD does that. > > Alex > >> >> Regards, Jordi >> >> >> -----Mensaje original----- De: v6ops en >> nombre de Alexandre Petrescu >> Responder a: Fecha: jueves, 21 de >> septiembre de 2017, 5:35 Para: Mikael Abrahamsson >> CC: "v6ops@ietf.org WG" Asunto: >> Re: [v6ops] reclassify 464XLAT as standard instead of info >> >> >> >> Le 21/09/2017 à 10:31, Mikael Abrahamsson a écrit : >>> On Thu, 21 Sep 2017, Alexandre Petrescu wrote: >>> >>>> I am not sure how the tethered clients will have end-to-end >>>> IPv6 if they dont have a prefix dedicated to them. Or maybe do >>>> you propose that to be 64share? >>> >>> That's what android already does, and have done for years. >>> Probably Apple iOS devices as well. RFC7278. >> >> So you propose moving 64share to BCP as well? >> >> Alex >> >>> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> ********************************************** IPv4 is over Are you >> ready for the new Internet ? http://www.consulintel.es The IPv6 >> Company >> >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be for >> the exclusive use of the individual(s) named above and further >> non-explicilty authorized disclosure, copying, distribution or use >> of the contents of this information, even if partially, including >> attached files, is strictly prohibited and will be considered a >> criminal offense. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents >> of this information, even if partially, including attached files, >> is strictly prohibited, will be considered a criminal offense, so >> you must reply to the original sender to inform about this >> communication and delete it. >> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Sep 21 05:03:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8911320C9 for ; Thu, 21 Sep 2017 05:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 gdTRBJpqyDBK for ; Thu, 21 Sep 2017 05:02:55 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26173134B3F for ; Thu, 21 Sep 2017 05:02:55 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id p10so3878596ywh.8 for ; Thu, 21 Sep 2017 05:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rSdkiRTGb8IuI/VZDBhZ3Jzp6nPqasnO54/GazI6UmI=; b=JxaYGW45tuG7yJ1f2sP7IKE6UMkoEkYQGFTnxtPQzU9Iza7l50Ban/hI0Ny/sxPwUj wJMTakgLVJpfKXugc2dawSTzWoQPu/UenV/13uTC+XMzkdhOH7/mEcd/znezisTFfVE+ GfPqyKx93e6WL1CcB3oxHn9lotmvw8ZEFRJJxLt+p77CkzQNyeNaWE88t/U0qUF55KtC awWBqFg0+L+a53T3kAnBY+3oDSWSqv5LtbmtlFwyGqon+WNrn4Q609T9n5FQu2OsBEm1 JO6M1YVN28QLonVSD1bS0oh/Owi5xvElOgdQ+EUzToy4U/L0dEZ/KM6yE6vYBkUtZC87 0Y7A== 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=rSdkiRTGb8IuI/VZDBhZ3Jzp6nPqasnO54/GazI6UmI=; b=jDoLRWzzXuOPkf8BYlJ+GNplerjSmsmDMDq3KffOzGipBnYAsCbX6hkY/7663Y60rr ug1XqdhVo/Old1Wt+LcBOw3Sbnr7m/BdMZq6OpBSMS2En5b4kmmaPNKOwFEWfxFjlOab GpP+RKDNirBUyA3FLKJA+CNuY61hdkWRzQOC5yI9wG8hUc9YntydI/tKi/0AeflpqdvT 5GjNZN1bcSsGyOe/aS4yQUuRk/aQMB7qsgBhI02/zevNzyDG5XEUAgDfxZ+om4qsQ48a lHXvQJcLpGdW8teOOpNZ90MB3DUk1XpvdDMZ/+D8tlJYniBVvkxtXbeHhpX9yMe79H4q N06g== X-Gm-Message-State: AHPjjUht/s/+Shq3Ea+GT8TNA0UBrSpdfL172hfJJeGb100eAcJir1d+ ERvBP20Fvbx1ioc0nLpZ5NE9zrP3PJcHNs6l/uY= X-Google-Smtp-Source: AOwi7QBQqtq2q0BpQATFetuvAPptx98LgY9TAmWbWvzC0m5ERabUQd+U3ojNH++J1j9VK2EiD3bL7EtVSnbEiZ6AT9w= X-Received: by 10.129.153.81 with SMTP id q78mr1400507ywg.133.1505995374223; Thu, 21 Sep 2017 05:02:54 -0700 (PDT) MIME-Version: 1.0 References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> In-Reply-To: <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> From: Ca By Date: Thu, 21 Sep 2017 12:02:43 +0000 Message-ID: To: Alexandre Petrescu , Owen DeLong Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0b82905085730559b1dfd0" Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 12:02:58 -0000 --94eb2c0b82905085730559b1dfd0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 20, 2017 at 10:22 PM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > In this email, the important part are at the beginning. The rest is > repetition. > > Le 21/09/2017 =C3=A0 00:29, Ca By a =C3=A9crit : > [...] > > > IPv6-in-GTP is a transport mechanism with mobility. It does not help an > > ipv6-only node communicate with an ipv4 internet. > > It helps to transport the IPv6 packets through the intermediary network > that is IPv4-only. The intermediary network is made of modem, base > station, SGW and PGW. The linux part is not the modem. Not correct. GTP only runs, in LTE, from the eNB to the SGW / PGW. There is not GTP on the UE or modem. > > > > That said, my deployment includes both IPv6-in-GTP and 464xlat > > simulatenously > > So, you have 2 encapsulations, right? Only GTP is encap. You can think of 464 translation scenario (ipv4 literals) as being encap in v6 to nat64 ... but i see it as translation not encap > > [...] > > But you cant have simultaneously CLAT and DHCPv6-PD on the same > client. > > > > > > I do not agree, Please state what is structurally preventing this. > > RFC6877 specifically calls for using dhcpv6-pd > > RFC is one thing, but many implementations block some RFCs. > > What structurally prevents this is that there are very numerous Android > devices. > Say the same about Apple. Show me Apple running dhcpv6 on LTE interface. > Each of these Android device has a structural risk if it wants to > 'root'. If the 'root' operation fails you can structurally through it > out a window. > > Android refuses to include DHCPv6-PD client in the main OS (public URL > available upon request). Because of that, one has to 'root' the device > in order to include it. > > Second, the modem part of many Android devices block DHCPv6. Private > indication of the dhcpv6 file blocking it is available upon request. It > is confidential information. The rights are to Qualcom and Balong. > > On another hand, I would like you to ask me what structurally does _not_ > prevent Android to run DHCPv6-PD. If you did, I would tell you this: > the operator does not oppose running DHCPv6-PD (some already run); > operator does not block DHCPv6 std ports, nor DHCPv6 std multicast; > router manufacturer does offer DHCPv6-PD server in the infrastructure; > open source software does exist for DHCPv6-PD server; 3GPP specs do tell > DHCPv6-PD should run; Android app DHCPv6 does exist on Store; many > flavors of DHCPv6-PD software was compiled and run on Android. > > Less important repetitions follow: > > > > > Because CLAT wants that to be a /64 prefix. It will break when > the > > client gets a /63. > > > > > > It requires a /64, which may come to the CLAT via a /56 via dhcpv6-pd > > It "can"? > > I dont think it can. See above the reasons. Basically, Android opposes > the inclusion of DHCPv6 software altogether in their code. > > DHCPv6-PD can not run without DHCPv6 code. > > But if you are afraid of IA_NA, dont mistake: DHCPv6 code has an option > called IA_PD (or -P in some implementations) that makes that even if the > DHCPv6 entire binary is present on the file system, only the IA_PD part > is called (not the IA_NA). > > That's why we have to be careful with words like "it can", or "is > orthogonal to", or "is independent of", or "CLAT regardless of RA or DHCP= ". > > It's not that way. It is that CLAT means no DHCP. > This seems to be your unique perspective > > > > > > Moreover, design suggestions from CLAT assume that /64 is sufficien= t. > > That is wrong - /64 is not sufficient. > > > > > > It is sufficient for CLAT function of execuating rfc6145. CLAT just > > rfc6145. > > No. > > When you make such statement - have you tried? > Not for me to try. I do not care about dhcpv6. I am telling you what is in the rfc, this is the ietf. We do rfc. There is a lot in the world outside of rfc, i agree. But that is for you to handle in the world outside the ietf. > > > There are lots of cases where more than one solution to the same > > > problem becomes a standards track RFC. > > > > But one wont prohibit the other. > > > > CLAT prohibits DHCPv6-PD. > > > > > > Not correct. > > See above. CLAT is what makes Android to explicitely not want DHCP. > > Because CLAT says "we are independent of SLAAC or DHCP", but they also > say "so we use _only_ SLAAC". > > If you wanted to support your statement, then you showed me some > implementation in where CLAT and DHCPv6 worked together. There is no suc= h. > > > > > > > > For that matter, DHCPv6 and SLAAC are both standards. Both do > > > address assignment. > > > > Err, I agree. Yet CLAT does not agree. CLAT does not rely on DHCP > to > > get an address. Why? IT does not rely on DHCPv6-PD to get a > > prefix. Why? > > > > >>>>> CLAT is a transition mechanism. SLAAC or DHCPv6 (-PD) is a > > >>>>> way to provision addresses/prefixes. No sense to mix all > > >>>>> them. > > >>>> > > >>>> That's a problem. You want them to work together, not to > > >>>> compete. > > >>> This makes no sense to me. IMHO, they don=E2=80=99t compete an= d CLAT can > > >>> work regardless of how the IPv6 address on the client is > > >>> obtained, whether SLAAC, DHCPv6, static, or otherwise. > > >> > > >> But you dont want CLAT's IPv6-in-IPv4 together with GTP > > >> encapsulation - that's too many encapsulations. > > > > > > True, but I don=E2=80=99t want ISIS and OSPF running on the same= links, > > > either. > > > > At some point there is some Gateway that is possible, which runs bo= th > > protocols OSPF and ISIS. But there cant be conversion between CLAT > and > > DHCP. > > > > > > Not correct, again. Please see rfc6877. > > See public URL in which discussion illustrates Android does not want > DHCPv6. > See Android app on Android store that runs DHCPv6, but which is not > integrated in Android. Running it requires 'root'. > > > > > > > > > Not sure I understand why this is a relevant topic here. Operato= rs > > > are capable of choosing the standard that best meets their needs > > > from multiple standards. Choice is often a good thing. This is a= n > > > example of such a case. > > > > Operators are influenced by Device availability. > > > > > > This operator (and esteamed co-authors) saw a problem, came to the > > ietf, worked with Android open source, worked with v6ops, and specified > > 464xlat. > > Another operator has an option in which DHCPv6 is there. > > Android blocks that. > > Fix Android. > Modem blocks that - fix modem. > > > > > Device availabilty followed. > > > > If Android is what is > > available, then operators want to satisfy this. If Android does > CLAT, > > then operators choose to not implement DHCPv6-PD, because DHCPv6-PD > is > > part of DHCPv6, and because CLAT does not need DHCPv6. > > > > > > Again. Dhcpv6-pd and 464xlat are compatible and their deployment > > motivations are largely orthogonal. > > "Compatible", but have you tried? > > > > I dont know how to explain this better to you. > > > > Android is very important to operators. > > > > >>>> You want them to have different functions. > > >>> CLAT doesn=E2=80=99t have an IPv6 address assignment function = so they > > >>> do, in fact, have different functions. > > >>>> But the function to get a prefix is a unique function. > > >>> CLAT doesn=E2=80=99t have anything to do with getting a prefix= for IPv6. > > >> > > >> But it only works with a /64. It means it cant work when > > >> DHCPv6-PD gives it a /63. > > > > > > You=E2=80=99re making no sense here. An interface would still ge= t a /64 > from > > > the /63 or /56 or /48 or whatever, so CLAT would still be > perfectly > > > capable of operating after the /64 was assigned to the interface= . > > > > > > Owen is correct here. > > > > > > To be tried, before arguing. > > > > Can you try? > > > > > > Seems you are the one interested in this area. > > > > The Android source code is available for you. > > That is true to some extent. SOme smartphone manufacturers do offer the > source code of their platforms, yes. Some still not, but will come. > > On another hand, in order to make my own OS I must 'root' the device. > That's a risk. > > The other option is that the responsible numerous Android devices take > pride (not oppose) some RFCs like the ones you mention, before blocking > them. > > > Do you think a WiFi tablet behind a smartphone-on-cellular that use= s > a > > prefix obtained with DHCPv6-PD and re-advertised with RA would be > able > > to get through that CLAT ok, and talk to IPv4 servers? > > > > If you could try this, then we can have an answer on whether or not= I > > make sense. > > > > Before that, we cant say CLAT and DHCPv6-PD are ok. > > > > > > We can say the specification allows CLAT and DHCPv6-PD to work > > together. Running code is an exercise left to those with a demand for > > that usecase. > > Promoting an RFC from INFO to StdsTrack demandes usecase. > > > >>>>> Many other transition mechanisms don=E2=80=99t state if SLAA= C or > > >>>>> DHCPv6 is used or not, and I think is perfectly correct. > > >>>> > > >>>> Most of them are not dynamic in nature anyways, whereas CLAT > > >>>> seems to be. > > >>> My understanding is that CLAT is dynamic only on the IPv4 side= . > > >>> On the IPv6 side, to the best of my knowledge, it just uses > > >>> whatever IPv6 address is available on the client=E2=80=99s int= erface(s). > > >>>> As long as they dont claim, and they abstain from to > > >>>> dynamically set a prefix on the network they are fine with > > >>>> respect to DHCP-PD. > > >>>> > > >>>> But once CLAT gets into statements qualifying which is better > > >>>> SLAAC-vs-DHCP then we have a big problem. > > >>> Sigh=E2=80=A6 I agree that there=E2=80=99s no reason for CLAT = to make any such > > >>> statement. If the current CLAT RFC(s) do, then, perhaps we > > >>> should argue for cleaning that up as part of the process of > > >>> moving towards a standards track RFC, but if that=E2=80=99s wh= at you=E2=80=99re > > >>> on about here, then just say that. You=E2=80=99ve wasted multi= ple > > >>> messages talking about completely orthogonal issues where the > > >>> above statement is the first clue you=E2=80=99ve provided abou= t what is > > >>> apparently your actual concern. > > >> > > >> I dont think it's orthogonal. > > > > > > It really is. > > > > I tell you it is not. > > > > > > agreeing with Owen, it is orthogonal. > > Orthogonal. > > > > > > > As long as CLAT does not agree there is DHCPv6-PD and IPv6-in-GTP > then > > we have little to talk about. > > > > > > 3 different things > > > > CLAT is just rfc6145 > > > > Ipv6-in-GTP is just an ip in UDP tunnel for mobility in 3gpp > > infrastructure, it has nothing to do with the internet or the UE > > > > Dhcpv6-pd ... assignes prefixes. > > > > 3 different and orthogonal things. > > > > > > > > > > We have a new transition method that appeared just because an OS > creator > > (Android) is not able, or not willing(?) to push their own supplier= s > > hardware vendors into implementing forwarding of DHCPv6-PD into the= ir > > modems. > > > > > > Again, 464xlat was not pushed by Android, it was pulled by operators in > > the ietf > > Operators also ask what Android wants. > > Operators dont oppose DHCPv6-PD. 3GPP doesnt either. Yet Android > refuses DHCPv6-PD. > Operating not opposing dhcp is not enough. This is the part you need to work on outside the ietf. > > Android created a software tool (CLAT) that is totally runnable in > the > > linux (not in the modem), so it is totally under their control (not > > modem) just to avoid the hardware modem problem. That's not the > right > > thing to do: the modem has to be fixed. > > > > > > Modem is the wrong place ... > > Modem manufacturers say differently. > > Modem manufacturers do implement IP features. Sometimes they block > RFCs, just like Android blocks DHCP too. > > But they found a sort of living together: it's the old Host-IMP interface= . > > The Host (Android) does some stuff assuming their matter is 'orthogonal' > to the IMP (Qualcom). However, for the IMP we are not allowed to know > what it does and for Android we are not allowed to ask them do DHCP. > > That's not an interface: it is independence, orthogonality. > > That leads to problems. > > Alex > > > > > > > > > Android CLAT is also ignoring that IPv6-in-GTP exists (GTP is an IP= v4 > > protocol at 3GPP), because the GTP part happens in the modem, and > > Android does not control the modem. > > > > If Android wanted "IPv6-only" devices then the right thing to do is > to > > create an IPv6 version of GTP, or, even better, get rid of GTP > > altogheter. But that again - it's in the modem. > > > > Nothing of this is orthogonal to CLAT: CLAT does some things becaus= e > the > > modem is forcing it into doing. > > > > Alex > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > --94eb2c0b82905085730559b1dfd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Sep 20, 2017 = at 10:22 PM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
In this email, the important part are at the beginning.=C2= =A0 The rest is
repetition.

Le 21/09/2017 =C3=A0 00:29, Ca By a =C3=A9crit=C2=A0:
[...]

> IPv6-in-GTP is a transport mechanism with mobility. It does not help a= n
> ipv6-only node communicate with an ipv4 internet.

It helps to transport the IPv6 packets through the intermediary network
that is IPv4-only.=C2=A0 The intermediary network is made of modem, base station, SGW and PGW.=C2=A0 The linux part is not the modem.

Not correct. GTP only runs, in = LTE, from the eNB to the SGW / PGW.=C2=A0 There is not GTP on the UE or mod= em.=C2=A0

<= br> >
> That said, my deployment includes both IPv6-in-GTP and 464xlat
> simulatenously

So, you have 2 encapsulations, right?

Only GTP is encap. You can think of 464 translation sc= enario (ipv4 literals) as being encap in v6 to nat64 ... but i see it as tr= anslation not encap=C2=A0



[...]
>=C2=A0 =C2=A0 =C2=A0But you cant have simultaneously CLAT and DHCPv6-PD= on the same client.
>
>
> I do not agree, =C2=A0Please state what is structurally preventing thi= s.
> RFC6877 specifically calls for using dhcpv6-pd

RFC is one thing, but many implementations block some RFCs.

What structurally prevents this is that there are very numerous Android
devices.

Say the same abo= ut Apple. Show me Apple running dhcpv6 on LTE interface.=C2=A0


Each of these Android device has a structural risk if it wants to
'root'.=C2=A0 If the 'root' operation fails you can structu= rally through it
out a window.

Android refuses to include DHCPv6-PD client in the main OS (public URL
available upon request).=C2=A0 Because of that, one has to 'root' t= he device
in order to include it.

Second, the modem part of many Android devices block DHCPv6.=C2=A0 Private<= br> indication of the dhcpv6 file blocking it is available upon request.=C2=A0 = It
is confidential information.=C2=A0 The rights are to Qualcom and Balong.
On another hand, I would like you to ask me what structurally does _not_ prevent Android to run DHCPv6-PD.=C2=A0 If you did, I would tell you this:<= br> the operator does not oppose running DHCPv6-PD (some already run);
operator does not block DHCPv6 std ports, nor DHCPv6 std multicast;
router manufacturer does offer DHCPv6-PD server in the infrastructure;
open source software does exist for DHCPv6-PD server; 3GPP specs do tell DHCPv6-PD should run; Android app DHCPv6 does exist on Store; many
flavors of DHCPv6-PD software was compiled and run on Android.

Less important repetitions follow:

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Because CLAT wants that to be a /64 prefix.= =C2=A0 It will break when the
>=C2=A0 =C2=A0 =C2=A0client gets a /63.
>
>
> It requires a /64, which may come to the CLAT via a /56 via dhcpv6-pd<= br>
It "can"?

I dont think it can.=C2=A0 See above the reasons.=C2=A0 Basically, Android = opposes
the inclusion of DHCPv6 software altogether in their code.

DHCPv6-PD can not run without DHCPv6 code.

But if you are afraid of IA_NA, dont mistake: DHCPv6 code has an option
called IA_PD (or -P in some implementations) that makes that even if the DHCPv6 entire binary is present on the file system, only the IA_PD part
is called (not the IA_NA).

That's why we have to be careful with words like "it can", or= "is
orthogonal to", or "is independent of", or "CLAT regard= less of RA or DHCP".

It's not that way.=C2=A0 It is that CLAT means no DHCP.

This seems to be= your unique perspective=C2=A0


>
>
>=C2=A0 =C2=A0 =C2=A0Moreover, design suggestions from CLAT assume that = /64 is sufficient.
>=C2=A0 =C2=A0 =C2=A0That is wrong - /64 is not sufficient.
>
>
> It is sufficient for CLAT function of execuating rfc6145. CLAT just > rfc6145.

No.

When you make such statement - have you tried?

Not for me to tr= y. I do not care about dhcpv6.=C2=A0

I am telling you what is in the rfc, this is the ietf. We do r= fc. There is a lot in the world outside of rfc, i agree. But that is for yo= u to handle in the world outside the ietf.=C2=A0

>=C2=A0 =C2=A0 =C2=A0 > There are lots of cases where more than one s= olution to the same
>=C2=A0 =C2=A0 =C2=A0 > problem becomes a standards track RFC.
>
>=C2=A0 =C2=A0 =C2=A0But one wont prohibit the other.
>
>=C2=A0 =C2=A0 =C2=A0CLAT prohibits DHCPv6-PD.
>
>
> Not correct.

See above.=C2=A0 CLAT is what makes Android to explicitely not want DHCP.
Because CLAT says "we are independent of SLAAC or DHCP", but they= also
say "so we use _only_ SLAAC".

If you wanted to support your statement, then you showed me some
implementation in where CLAT and DHCPv6 worked together.=C2=A0 There is no = such.

>
>
>=C2=A0 =C2=A0 =C2=A0 > For that matter, DHCPv6 and SLAAC are both st= andards. Both do
>=C2=A0 =C2=A0 =C2=A0 > address assignment.
>
>=C2=A0 =C2=A0 =C2=A0Err, I agree.=C2=A0 Yet CLAT does not agree.=C2=A0 = CLAT does not rely on DHCP to
>=C2=A0 =C2=A0 =C2=A0get an address.=C2=A0 Why?=C2=A0 IT does not rely o= n DHCPv6-PD to get a
>=C2=A0 =C2=A0 =C2=A0prefix.=C2=A0 Why?
>
>=C2=A0 =C2=A0 =C2=A0 >>>>> CLAT is a transition mechanis= m. SLAAC or DHCPv6 (-PD) is a
>=C2=A0 =C2=A0 =C2=A0 >>>>> way to provision addresses/pr= efixes. No sense to mix all
>=C2=A0 =C2=A0 =C2=A0 >>>>> them.
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> That's a problem.=C2=A0 You w= ant them to work=C2=A0 together, not to
>=C2=A0 =C2=A0 =C2=A0 >>>> compete.
>=C2=A0 =C2=A0 =C2=A0 >>> This makes no sense to me. IMHO, they= don=E2=80=99t compete and CLAT can
>=C2=A0 =C2=A0 =C2=A0 >>> work regardless of how the IPv6 addre= ss on the client is
>=C2=A0 =C2=A0 =C2=A0 >>> obtained, whether SLAAC, DHCPv6, stat= ic, or otherwise.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> But you dont want CLAT's IPv6-in-IPv4= together with GTP
>=C2=A0 =C2=A0 =C2=A0 >> encapsulation - that's too many encap= sulations.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > True, but I don=E2=80=99t want ISIS and OSPF = running on the same links,
>=C2=A0 =C2=A0 =C2=A0 > either.
>
>=C2=A0 =C2=A0 =C2=A0At some point there is some Gateway that is possibl= e, which runs both
>=C2=A0 =C2=A0 =C2=A0protocols OSPF and ISIS.=C2=A0 But there cant be co= nversion between CLAT and
>=C2=A0 =C2=A0 =C2=A0DHCP.
>
>
> Not correct, again. Please see rfc6877.

See public URL in which discussion illustrates Android does not want DHCPv6= .

See Android app on Android store that runs DHCPv6, but which is not
integrated in Android.=C2=A0 Running it requires 'root'.


>
>
>=C2=A0 =C2=A0 =C2=A0 > Not sure I understand why this is a relevant = topic here. Operators
>=C2=A0 =C2=A0 =C2=A0 > are capable of choosing the standard that bes= t meets their needs
>=C2=A0 =C2=A0 =C2=A0 > from multiple standards. Choice is often a go= od thing. This is an
>=C2=A0 =C2=A0 =C2=A0 > example of such a case.
>
>=C2=A0 =C2=A0 =C2=A0Operators are influenced by Device availability. >
>
> This operator (and esteamed co-authors) =C2=A0saw a problem, came to t= he
> ietf, worked with Android open source, worked with v6ops, and specifie= d
> 464xlat.

Another operator has an option in which DHCPv6 is there.

Android blocks that.

Fix Android.

Modem blocks that - fix modem.

>
> Device availabilty followed.
>
>=C2=A0 =C2=A0 =C2=A0If Android is what is
>=C2=A0 =C2=A0 =C2=A0available, then operators want to satisfy this.=C2= =A0 If Android does CLAT,
>=C2=A0 =C2=A0 =C2=A0then operators choose to not implement DHCPv6-PD, b= ecause DHCPv6-PD is
>=C2=A0 =C2=A0 =C2=A0part of DHCPv6, and because CLAT does not need DHCP= v6.
>
>
> Again. Dhcpv6-pd and 464xlat are compatible and their deployment
> motivations are largely orthogonal.

"Compatible", but have you tried?


>=C2=A0 =C2=A0 =C2=A0I dont know how to explain this better to you.
>
>=C2=A0 =C2=A0 =C2=A0Android is very important to operators.
>
>=C2=A0 =C2=A0 =C2=A0 >>>> You want them to have different f= unctions.
>=C2=A0 =C2=A0 =C2=A0 >>> CLAT doesn=E2=80=99t have an IPv6 add= ress assignment function so they
>=C2=A0 =C2=A0 =C2=A0 >>> do, in fact, have different functions= .
>=C2=A0 =C2=A0 =C2=A0 >>>> But the function to get a prefix = is a unique function.
>=C2=A0 =C2=A0 =C2=A0 >>> CLAT doesn=E2=80=99t have anything to= do with getting a prefix for IPv6.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> But it only works with a /64.=C2=A0 It me= ans it cant work when
>=C2=A0 =C2=A0 =C2=A0 >> DHCPv6-PD gives it a /63.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > You=E2=80=99re making no sense here. An inter= face would still get a /64 from
>=C2=A0 =C2=A0 =C2=A0 > the /63 or /56 or /48 or whatever, so CLAT wo= uld still be perfectly
>=C2=A0 =C2=A0 =C2=A0 > capable of operating after the /64 was assign= ed to the interface.
>
>
> Owen is correct here.
>
>
>=C2=A0 =C2=A0 =C2=A0To be tried, before arguing.
>
>=C2=A0 =C2=A0 =C2=A0Can you try?
>
>
> Seems you are the one interested in this area.
>
> The Android source code is available for you.

That is true to some extent.=C2=A0 SOme smartphone manufacturers do offer t= he
source code of their platforms, yes.=C2=A0 Some still not, but will come.
On another hand, in order to make my own OS I must 'root' the devic= e.
That's a risk.

The other option is that the responsible numerous Android devices take
pride (not oppose) some RFCs like the ones you mention, before blocking
them.

>=C2=A0 =C2=A0 =C2=A0Do you think a WiFi tablet behind a smartphone-on-c= ellular that uses a
>=C2=A0 =C2=A0 =C2=A0prefix obtained with DHCPv6-PD and re-advertised wi= th RA would be able
>=C2=A0 =C2=A0 =C2=A0to get through that CLAT ok, and talk to IPv4 serve= rs?
>
>=C2=A0 =C2=A0 =C2=A0If you could try this, then we can have an answer o= n whether or not I
>=C2=A0 =C2=A0 =C2=A0make sense.
>
>=C2=A0 =C2=A0 =C2=A0Before that, we cant say CLAT and DHCPv6-PD are ok.=
>
>
> We can say the specification allows CLAT and DHCPv6-PD to work
> together.=C2=A0 Running code is an exercise left to those with a deman= d for
> that usecase.

Promoting an RFC from INFO to StdsTrack demandes usecase.

>=C2=A0 =C2=A0 =C2=A0 >>>>> Many other transition mechani= sms don=E2=80=99t state if SLAAC or
>=C2=A0 =C2=A0 =C2=A0 >>>>> DHCPv6 is used or not, and I = think is perfectly correct.
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> Most of them are not dynamic in n= ature anyways, whereas CLAT
>=C2=A0 =C2=A0 =C2=A0 >>>> seems to be.
>=C2=A0 =C2=A0 =C2=A0 >>> My understanding is that CLAT is dyna= mic only on the IPv4 side.
>=C2=A0 =C2=A0 =C2=A0 >>> On the IPv6 side, to the best of my k= nowledge, it just uses
>=C2=A0 =C2=A0 =C2=A0 >>> whatever IPv6 address is available on= the client=E2=80=99s interface(s).
>=C2=A0 =C2=A0 =C2=A0 >>>> As long as they dont claim, and t= hey abstain from to
>=C2=A0 =C2=A0 =C2=A0 >>>> dynamically set a prefix on the n= etwork they are fine with
>=C2=A0 =C2=A0 =C2=A0 >>>> respect to DHCP-PD.
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> But once CLAT gets into statement= s qualifying which is better
>=C2=A0 =C2=A0 =C2=A0 >>>> SLAAC-vs-DHCP then we have a big = problem.
>=C2=A0 =C2=A0 =C2=A0 >>> Sigh=E2=80=A6 I agree that there=E2= =80=99s no reason for CLAT to make any such
>=C2=A0 =C2=A0 =C2=A0 >>> statement. If the current CLAT RFC(s)= do, then, perhaps we
>=C2=A0 =C2=A0 =C2=A0 >>> should argue for cleaning that up as = part of the process of
>=C2=A0 =C2=A0 =C2=A0 >>> moving towards a standards track RFC,= but if that=E2=80=99s what you=E2=80=99re
>=C2=A0 =C2=A0 =C2=A0 >>> on about here, then just say that. Yo= u=E2=80=99ve wasted multiple
>=C2=A0 =C2=A0 =C2=A0 >>> messages talking about completely ort= hogonal issues where the
>=C2=A0 =C2=A0 =C2=A0 >>> above statement is the first clue you= =E2=80=99ve provided about what is
>=C2=A0 =C2=A0 =C2=A0 >>> apparently your actual concern.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> I dont think it's orthogonal.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > It really is.
>
>=C2=A0 =C2=A0 =C2=A0I tell you it is not.
>
>
> agreeing with Owen, it is orthogonal.

Orthogonal.

>
>
>=C2=A0 =C2=A0 =C2=A0As long as CLAT does not agree there is DHCPv6-PD a= nd IPv6-in-GTP then
>=C2=A0 =C2=A0 =C2=A0we have little to talk about.
>
>
> 3 different things
>
> CLAT is just rfc6145
>
> Ipv6-in-GTP is just an ip in UDP tunnel for mobility in 3gpp
> infrastructure, it has nothing to do with the internet or the UE
>
> Dhcpv6-pd ... assignes prefixes.
>
> 3 different and orthogonal things.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0We have a new transition method that appeared just = because an OS creator
>=C2=A0 =C2=A0 =C2=A0(Android) is not able, or not willing(?) to push th= eir own suppliers
>=C2=A0 =C2=A0 =C2=A0hardware vendors into implementing forwarding of DH= CPv6-PD into their
>=C2=A0 =C2=A0 =C2=A0modems.
>
>
> Again, 464xlat was not pushed by Android, it was pulled by operators i= n
> the ietf

Operators also ask what Android wants.

Operators dont oppose DHCPv6-PD.=C2=A0 3GPP doesnt either.=C2=A0 Yet Androi= d
refuses DHCPv6-PD.

Operating not op= posing dhcp is not enough. This is the part you need to work on outside the= ietf.=C2=A0

v6ops@ietf.org <mailto:v6ops@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/list= info/v6ops
>
--94eb2c0b82905085730559b1dfd0-- From nobody Thu Sep 21 06:31:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B45B134B4E for ; Thu, 21 Sep 2017 06:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSE6cKjg8Xgz for ; Thu, 21 Sep 2017 06:31:26 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024B4134B4F for ; Thu, 21 Sep 2017 06:31:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8LDVLub012276; Thu, 21 Sep 2017 15:31:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6F602207FEE; Thu, 21 Sep 2017 15:31:21 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 60376201492; Thu, 21 Sep 2017 15:31:21 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8LDVKjv025084; Thu, 21 Sep 2017 15:31:21 +0200 To: Ca By , Owen DeLong Cc: v6ops@ietf.org References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> From: Alexandre Petrescu Message-ID: <3c8584d6-278a-751a-ecd8-d1c9b2cc2206@gmail.com> Date: Thu, 21 Sep 2017 15:31:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 13:31:29 -0000 Le 21/09/2017 à 14:02, Ca By a écrit : [...] > > IPv6-in-GTP is a transport mechanism with mobility. It does not > help an > > ipv6-only node communicate with an ipv4 internet. > > It helps to transport the IPv6 packets through the intermediary network > that is IPv4-only.  The intermediary network is made of modem, base > station, SGW and PGW.  The linux part is not the modem. > > > Not correct. GTP only runs, in LTE, from the eNB to the SGW / PGW. > There is not GTP on the UE or modem. Ok, I can agree if you say so. I can not capture packets on the UE to confirm or infirm; the "UE" is the "modem", that's how Balong calls it; there is no source code for that part. It seems that you tried to capture on modem? Or is it that somebody told this to you? Or is it that it is in the 3GPP specs? The doubt I have is the following: operator tells that the Terminal does some form of connection setup. I dont see it. Operator does not see it either. I speculate that that connection setup includes GTP. It's a speculation. I do see packets on PGW that show IPv6 encapsulated in GTP (an IPv4 protocol). My point is that even then, there _is_ encapsulation. > > That said, my deployment includes both IPv6-in-GTP and 464xlat > > simulatenously > > So, you have 2 encapsulations, right? > > > Only GTP is encap. You can think of 464 translation scenario (ipv4 > literals) as being encap in v6 to nat64 ... but i see it as translation > not encap So we dont end up with double encapsulation, but we end up with encapsulation _and_ translation. Other less prestigious transition mechanisms use just one. Why should we use two? > [...] > >     But you cant have simultaneously CLAT and DHCPv6-PD on the > same client. > > > > > > I do not agree,  Please state what is structurally preventing this. > > RFC6877 specifically calls for using dhcpv6-pd > > RFC is one thing, but many implementations block some RFCs. > > What structurally prevents this is that there are very numerous Android > devices. > > > Say the same about Apple. Show me Apple running dhcpv6 on LTE interface. For that, I would need to acquire an Apple smartphone, and a development kit. I dont know how how much things cost. If I can get one for trial, I am highly interested. I wonder whether one has to root-risk the iPhone before able to compile a poor man's DHCPv6-PD client on it? This is a show-stopper, I wont risk. What are the DHCPv6-PD clients available that compile on Apple iPhone? Maybe python library scapy is known to work there, or not. I wonder what modem is inside an Apple iPhone (is it Qualcomm, which MDM version of the QDSP6 - is it MDM8xxx series - that is known to bloc). Or is it some other brand of modem. With these at hand, I can try to work on something of Apple iPhone running DHCPv6-PD on its LTE interface. [...] > It's not that way.  It is that CLAT means no DHCP. > > > This seems to be your unique perspective No, repeating what I said to others: some operator does 64share on an APN, and DHCPv6-PD on another APN. This makes no sense and it's hard to live with. The invoked reason is that "464XLAT DNS-some4-6 figure is the new standard" and especially it is supported by Android, which are very numerous. [...]> >     Moreover, design suggestions from CLAT assume that /64 is > sufficient. > >     That is wrong - /64 is not sufficient. > > > > > > It is sufficient for CLAT function of execuating rfc6145. CLAT just > > rfc6145. > > No. > > When you make such statement - have you tried? > > > Not for me to try. I do not care about dhcpv6. > > I am telling you what is in the rfc, this is the ietf. We do rfc. There > is a lot in the world outside of rfc, i agree. But that is for you to > handle in the world outside the ietf. But now you want to make a new RFC status. That should be done responsibly. You should know the potential consequences. One of the potential consequences is that we go with DHCPv6-PD on an APN and 64share on another APN. Alex [snip] From nobody Thu Sep 21 06:40:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84885134B4E for ; Thu, 21 Sep 2017 06:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGlZv1UAVIJH for ; Thu, 21 Sep 2017 06:40:29 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B49D132F8F for ; Thu, 21 Sep 2017 06:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506001224; x=1506606024; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=h7j7NjjZdnPLUkvJYFC0137bn K229uXeBXQ+zCUWjkk=; b=X7K7om7cpAmWrCLPkj5x7oCIkK/9J5jLNBrvwdoTc NneUDQpXfUd1Z033KeXF8xQlYmaiUSbrKoXLeFX4IPdlhNy42Ca3nOtoumzsHQBi q4jPmjdWeZkV/5tVEpuWPe+RA/lM+lxofK5/oWVW1NAjyHKH7+0kxeDmujoKTWa0 vM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=DkrLkQHClQpQoes5djKbU4zp4CQRQVQg/dzS4WPUR1g20gokAAqKP6cJqTQl wRdOjCNMuUAYdVVysyeRxcIuQW90FMs16HOOIIiXSwerKz1EcjeFjHMLg jjTTWUD5kGVYsAyEm6J+P7cc1UMjmBO9/dX1T/q8kU1KSb2g3xiTzA=; X-MDAV-Processed: mail.consulintel.es, Thu, 21 Sep 2017 15:40:24 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 21 Sep 2017 15:40:23 +0200 Received: from [45.6.251.164] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005562208.msg for ; Thu, 21 Sep 2017 15:40:21 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170921:md50005562208::mJcperbk6TGGMxC4:00001fVl X-MDRemoteIP: 45.6.251.164 X-Return-Path: prvs=14370a98a6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Thu, 21 Sep 2017 10:40:17 -0300 From: JORDI PALET MARTINEZ To: Message-ID: <0DD8E948-A2B3-46B9-9FF7-DA9A83503BBA@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> <78CED789-6366-4CE0-8CC9-E630B13F743C@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 13:40:31 -0000 My guess, didn't tired that, is that if and implementation is using both DH= CPv6-PD and 64share, it should be possible to have a single APN. You just n= eed to not =E2=80=9Cforce=E2=80=9D the use of the PD if is not being reques= ted by the UE. Is a quick though, but don't see a problem on that. By the way, if the operator was having problems with DHCPv6-PD, it means th= at the chipset was not filtering that as you indicated before, so blame som= e chipset vendors, not the IETF. I also see a valid case for having 2 APNs. 1) for LTE broadband routers tha= t require more than a /64 (and thus DHCPv6-PD), and 2) for the rest that ar= e regular UEs and only require a /64 (64share for the tethering) Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: jueves, 21 de septiembre de 2017, 8:11 Para: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info =20 =20 Le 21/09/2017 =C3=A0 13:03, JORDI PALET MARTINEZ a =C3=A9crit : > DHCPv6-PD is a good thing to have. I=E2=80=99ve confronted thoughts o= n DHCPv6 > vs SLAAC =E2=80=A6 However, I understand it will be nice to have DHCP= v6 > implemented everywhere, as for example enterprise environments prefer > a more controlled environment. >=20 > However, having DHCPv6 doesn=E2=80=99t exclude having 64share as well= . =20 It does: try to run both on a computer and you will see. =20 In practice: a particular operator had to make some choice some time.= =20 That choice led to either 64share on an APN, or DHCPv6-PD on another=20 APN. They had some reason to put each such thing on a distinct APN. =20 It's not simply a matter of having two distinct RFCs. I can live with= =20 thousands of RFCs if you wish. But I cant live with different APN each= =20 for an RFC. =20 I dont want a Connection Management software to switch between APNs lik= e=20 that. =20 I am not sure whether I explain this ok, but that's the way it is. =20 > Otherwise, if we follow your suggestion, we should cleanup 60-70% of > the protocols that we have, because they are redundant. =20 In this discussion we talk 64share and DHCPv6-PD. Pick one. =20 (for the other 60-70% protocols in MIB we can discuss separately if you= =20 wish). =20 Alex =20 >=20 > Regards, Jordi >=20 >=20 > -----Mensaje original----- De: v6ops en > nombre de Alexandre Petrescu Responder > a: Fecha: jueves, 21 de septiembre de > 2017, 7:57 Para: Asunto: Re: [v6ops] reclassify > 464XLAT as standard instead of info >=20 >=20 >=20 > Le 21/09/2017 =C3=A0 12:33, JORDI PALET MARTINEZ a =C3=A9crit : >> Yes, why not? >=20 > Because DHCPv6-PD does that. >=20 > Alex >=20 >>=20 >> Regards, Jordi >>=20 >>=20 >> -----Mensaje original----- De: v6ops en >> nombre de Alexandre Petrescu =20 >> Responder a: Fecha: jueves, 21 de >> septiembre de 2017, 5:35 Para: Mikael Abrahamsson >> CC: "v6ops@ietf.org WG" Asunto: >> Re: [v6ops] reclassify 464XLAT as standard instead of info >>=20 >>=20 >>=20 >> Le 21/09/2017 =C3=A0 10:31, Mikael Abrahamsson a =C3=A9crit : >>> On Thu, 21 Sep 2017, Alexandre Petrescu wrote: >>>=20 >>>> I am not sure how the tethered clients will have end-to-end >>>> IPv6 if they dont have a prefix dedicated to them. Or maybe do >>>> you propose that to be 64share? >>>=20 >>> That's what android already does, and have done for years. >>> Probably Apple iOS devices as well. RFC7278. >>=20 >> So you propose moving 64share to BCP as well? >>=20 >> Alex >>=20 >>>=20 >>=20 >> _______________________________________________ v6ops mailing list= =20 >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >>=20 >> ********************************************** IPv4 is over Are you >> ready for the new Internet ? http://www.consulintel.es The IPv6 >> Company >>=20 >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be for >> the exclusive use of the individual(s) named above and further >> non-explicilty authorized disclosure, copying, distribution or use >> of the contents of this information, even if partially, including >> attached files, is strictly prohibited and will be considered a >> criminal offense. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents >> of this information, even if partially, including attached files, >> is strictly prohibited, will be considered a criminal offense, so >> you must reply to the original sender to inform about this >> communication and delete it. >>=20 >>=20 >>=20 >> _______________________________________________ v6ops mailing list= =20 >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company >=20 > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Sep 21 06:52:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2101913307E for ; Thu, 21 Sep 2017 06:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jlksHqMWWZT for ; Thu, 21 Sep 2017 06:52:37 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ADA01321C7 for ; Thu, 21 Sep 2017 06:52:36 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4E9DD40BA5 for ; Thu, 21 Sep 2017 15:52:35 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 390BB40B9E; Thu, 21 Sep 2017 15:52:35 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 2AFAA342D2; Thu, 21 Sep 2017 15:52:35 +0200 (CEST) Date: Thu, 21 Sep 2017 15:52:35 +0200 From: Gert Doering To: JORDI PALET MARTINEZ Cc: v6ops@ietf.org Message-ID: <20170921135235.GF45648@Space.Net> References: <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> <78CED789-6366-4CE0-8CC9-E630B13F743C@consulintel.es> <0DD8E948-A2B3-46B9-9FF7-DA9A83503BBA@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DD8E948-A2B3-46B9-9FF7-DA9A83503BBA@consulintel.es> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 13:52:44 -0000 Hi, On Thu, Sep 21, 2017 at 10:40:17AM -0300, JORDI PALET MARTINEZ wrote: > I also see a valid case for having 2 APNs. 1) for LTE broadband routers that require more than a /64 (and thus DHCPv6-PD), and 2) for the rest that are regular UEs and only require a /64 (64share for the tethering) The claim that you need multiple APNs for that is not logical. The basic function "assign a /64 for each PDP" is 3GPP standard, any APN needs to do that (and that's the /64 you use for 64share). The extra function "DHCPv6-PD" is conceptually totally independent - you need an IPv6 capable link, nothing else, and whether or not a /64 has been assigned is not relevant for PD. Now, if a given *vendor* can only turn on one or the other on their gear is an implementation choice, and that REALLY doesn't belong here - if at all, it's a 3GPP standardization topic ("if you add DHCPv6PD, you MUST continue to provide a /64 for each subscriber"). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Sep 21 06:56:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3FC1330B0 for ; Thu, 21 Sep 2017 06:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnvMXoGFbrce for ; Thu, 21 Sep 2017 06:56:13 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B833913235C for ; Thu, 21 Sep 2017 06:56:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8LDuBrt014420 for ; Thu, 21 Sep 2017 15:56:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 21BA7208077 for ; Thu, 21 Sep 2017 15:56:11 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 186FC207FD4 for ; Thu, 21 Sep 2017 15:56:11 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8LDuAgp016192 for ; Thu, 21 Sep 2017 15:56:10 +0200 To: v6ops@ietf.org References: <6BD0B640-8853-4B32-9B30-936D8F58000F@consulintel.es> <8503DEC8-026D-4AA2-A887-87B29A2B2611@apple.com> <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> <78CED789-6366-4CE0-8CC9-E630B13F743C@consulintel.es> <0DD8E948-A2B3-46B9-9FF7-DA9A83503BBA@consulintel.es> From: Alexandre Petrescu Message-ID: <820bfbf9-5f6d-f15c-8fca-494dda790d31@gmail.com> Date: Thu, 21 Sep 2017 15:56:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0DD8E948-A2B3-46B9-9FF7-DA9A83503BBA@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 13:56:15 -0000 Le 21/09/2017 à 15:40, JORDI PALET MARTINEZ a écrit : > My guess, didn't tired that, is that if and implementation is using > both DHCPv6-PD and 64share, it should be possible to have a single > APN. You just need to not “force” the use of the PD if is not being > requested by the UE. Is a quick though, but don't see a problem on > that. Dont standardize on something that you think it may work. We should be sure it works. > By the way, if the operator was having problems with DHCPv6-PD, No, the operator had no problems with DHCPv6-PD. They had problems with DHCPv6 - they found it superfluous. Android did 464xlat, 64share and NAT-figurex-figurey, so everything was fine. > it means that the chipset was not filtering that as you indicated > before, so blame some chipset vendors, not the IETF. At some point in time, some modems (e.g. a modem in Huawei E392 USB dongle) acted as a sort of DHCPv6 Server. My linux issued DHCPv6 requests, someone answered, and the operator said it isnt them. So it was the modem. Newer modems like MDM8xxx dont even bother to answer - they simply block. Moreover, the designers ack they are blocking it, 'because noone needs it'. > I also see a valid case for having 2 APNs. 1) for LTE broadband > routers that require more than a /64 (and thus DHCPv6-PD), and 2) for > the rest that are regular UEs and only require a /64 (64share for the > tethering) I can agree to that use case of LTE broadband router vs smartphone, or one for M2M "Business" devices and one for smartphones. But two APNs, both for smartphones to connect, is not viable. You want one APN and many kinds of smartphones and cars to connect to that single APN. (there are long discussions about this, and in the past one has seen movements in that direction) Alex From nobody Thu Sep 21 06:57:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6816133343 for ; Thu, 21 Sep 2017 06:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctt7i95WfZMp for ; Thu, 21 Sep 2017 06:57:01 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB3E13307E for ; Thu, 21 Sep 2017 06:57:01 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5E144AF; Thu, 21 Sep 2017 15:56:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506002219; bh=Qp95EGcgnojaYBLR0RQ0d2xyiutpupunWCY4t6qqEBQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=CJdZ955E9bcv7fW2aZNPufrNAwuYbGAhuzzHU+kKoohMO+PDpMgHgNycvihcVntFH baEPKK6UE4gmc3gom1v80GnHM09CoQosZLwGXY2GnAxROxsZoARdMyfimZa5am9I3x fJKkTTT2RAVFw8fdKj5dcAaSFkah71XaPmBo9DHs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 44F9D84; Thu, 21 Sep 2017 15:56:59 +0200 (CEST) Date: Thu, 21 Sep 2017 15:56:59 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Ca By , Owen DeLong , v6ops@ietf.org In-Reply-To: <3c8584d6-278a-751a-ecd8-d1c9b2cc2206@gmail.com> Message-ID: References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <3c8584d6-278a-751a-ecd8-d1c9b2cc2206@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 13:57:04 -0000 On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > Ok, I can agree if you say so. I can not capture packets on the UE to > confirm or infirm; the "UE" is the "modem", that's how Balong calls it; > there is no source code for that part. > > It seems that you tried to capture on modem? Or is it that somebody > told this to you? Or is it that it is in the 3GPP specs? It's in the 3GPP spec. In 3G it's GTP GGSN-RNC, and then it's handled by the RLC layer between RNC and UE. I'd imagine it's something similar in LTE but then instead between UE and eNodB (since there is no RNC). > The doubt I have is the following: operator tells that the Terminal does > some form of connection setup. I dont see it. Operator does not see it > either. I speculate that that connection setup includes GTP. It's a > speculation. > > I do see packets on PGW that show IPv6 encapsulated in GTP (an IPv4 > protocol). GTP can be either IPv4 or IPv6, and the encapsulated packets can be either IPv4 or IPv6 (and probably other protocols as well, I haven't used it for anything else). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 21 07:04:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA72913235C for ; Thu, 21 Sep 2017 07:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06sFFnVcKHN5 for ; Thu, 21 Sep 2017 07:04:18 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EDEE1321C7 for ; Thu, 21 Sep 2017 07:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506002655; x=1506607455; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=GwNQP3Khs3+xtyRceaAnNzIrw oz1vMIeNP5zC8OSjaU=; b=YcaosnYonFayD3rnVAxSGz3Cow7lKuOL1QDuBiZAH DQIWaYsz0g+YYRF3oOmXa0NArNF9/R8Zw0yWTIlEjjxj4Ms69nH4a9RlBSnmGRcD QzixTg/UZfzguwMsyVQH9J3cpJtdKCtBkybQZhFRvGYvkPpwMtsQfUy1QLEYcDJz tg= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=A8l2SgE7vWTcP/VKE5w0hRxBVTBtziDQ2IfIQP7K0UnXY+0a7PoPxgq2VtVe zUskYkDPCMZUVDPRImjsNp8DD6gIr6MCgasSLBT6xS5geR1XAhQPCVYhc eWxnOGhBu9ef5xbOHmrEci2UPbexfmcccXxgNsf1jwPijgskSF8MNE=; X-MDAV-Processed: mail.consulintel.es, Thu, 21 Sep 2017 16:04:15 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 21 Sep 2017 16:04:15 +0200 Received: from [45.6.251.164] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005562228.msg for ; Thu, 21 Sep 2017 16:04:15 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170921:md50005562228::I87ya5a/1HZk7Inx:00001HMG X-MDRemoteIP: 45.6.251.164 X-Return-Path: prvs=14370a98a6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Thu, 21 Sep 2017 11:04:10 -0300 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <376bfd13-8f22-3255-0f3b-d077cc205cc9@gmail.com> <55371780-be6c-49e6-fe40-bf3b4c05fcfd@gmail.com> <78CED789-6366-4CE0-8CC9-E630B13F743C@consulintel.es> <0DD8E948-A2B3-46B9-9FF7-DA9A83503BBA@consulintel.es> <20170921135235.GF45648@Space.Net> In-Reply-To: <20170921135235.GF45648@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 14:04:20 -0000 You=E2=80=99re right, that=E2=80=99s why I said quick thought because I=E2= =80=99ve seen operators doing that actually (two APNs one for broadband LTE= , one for smartphones) ;-) So, a single APN, provides by default a /64. Then if it is a broadband rout= er starts DHCPv6-PD (not sure then if NO need to use RFC6603 for excluding = the WAN link if the initial =E2=80=9Cdefault=E2=80=9D /64 was already used = as well for the WAN link). Regards, Jordi =20 -----Mensaje original----- De: Gert Doering Responder a: Fecha: jueves, 21 de septiembre de 2017, 10:52 Para: JORDI PALET MARTINEZ CC: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info Hi, =20 On Thu, Sep 21, 2017 at 10:40:17AM -0300, JORDI PALET MARTINEZ wrote: > I also see a valid case for having 2 APNs. 1) for LTE broadband route= rs that require more than a /64 (and thus DHCPv6-PD), and 2) for the rest t= hat are regular UEs and only require a /64 (64share for the tethering) =20 The claim that you need multiple APNs for that is not logical. =20 The basic function "assign a /64 for each PDP" is 3GPP standard, any AP= N needs to do that (and that's the /64 you use for 64share). =20 The extra function "DHCPv6-PD" is conceptually totally independent - yo= u need an IPv6 capable link, nothing else, and whether or not a /64 has b= een assigned is not relevant for PD. =20 =20 Now, if a given *vendor* can only turn on one or the other on their gea= r=20 is an implementation choice, and that REALLY doesn't belong here - if a= t all, it's a 3GPP standardization topic ("if you add DHCPv6PD, you MUST continue to provide a /64 for each subscriber"). =20 Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? =20 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Cule= mann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Sep 21 07:07:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A0E13235C for ; Thu, 21 Sep 2017 07:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJknINRknSdK for ; Thu, 21 Sep 2017 07:07:39 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2726132D96 for ; Thu, 21 Sep 2017 07:07:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8LE7Wi2018866; Thu, 21 Sep 2017 16:07:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4DA9A20F001; Thu, 21 Sep 2017 16:07:32 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2D9F920EFF9; Thu, 21 Sep 2017 16:07:32 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8LE7VqC027228; Thu, 21 Sep 2017 16:07:31 +0200 To: Mikael Abrahamsson Cc: Ca By , Owen DeLong , v6ops@ietf.org References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <3c8584d6-278a-751a-ecd8-d1c9b2cc2206@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 21 Sep 2017 16:07:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------E82BAB2501900778ADDC75B4" Content-Language: fr Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 14:07:41 -0000 This is a multi-part message in MIME format. --------------E82BAB2501900778ADDC75B4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 21/09/2017 à 15:56, Mikael Abrahamsson a écrit : > On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > >> Ok, I can agree if you say so.  I can not capture packets on the UE to >> confirm or infirm; the "UE" is the "modem", that's how Balong calls >> it; there is no source code for that part. >> >> It seems that you tried to capture on modem?  Or is it that somebody >> told this to you?  Or is it that it is in the 3GPP specs? > > It's in the 3GPP spec. In 3G it's GTP GGSN-RNC, and then it's handled by > the RLC layer between RNC and UE. I'd imagine it's something similar in > LTE but then instead between UE and eNodB (since there is no RNC). So you mean the UE does GTP? (Mr. Byrne and another person said that GTP is not run in the UE.) But has one tried it? I am asking you because of this: the 3GPP and IETF specs say that DHCPv6 should run on the Client and on the Server. There is no notion of "proxy DHCP". Yet modems do just that: some run DHCPv6, some block DHCPv6 - all non-standard ways of DHCP. They are like middle-boxes, trying to be transparent. By this logic, could it be that some modem implements also GTP? >> The doubt I have is the following: operator tells that the Terminal >> does some form of connection setup.  I dont see it.  Operator does not >> see it >>  either.  I speculate that that connection setup includes GTP.  It's a >> speculation. >> >> I do see packets on PGW that show IPv6 encapsulated in GTP (an IPv4 >> protocol). > > GTP can be either IPv4 or IPv6, and the encapsulated packets can be > either IPv4 or IPv6 (and probably other protocols as well, I haven't > used it for anything else). When I read that, I wonder whether it is better to encapsulate IPv6 in GTP-that-uses-IPv6addresses-as-src-and-dst? Alex --------------E82BAB2501900778ADDC75B4 Content-Type: message/rfc822; name="Message joint" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Message joint" X-Mozilla-Keys: Received: from muguet2.intra.cea.fr (132.166.192.7) by EXCAH-A3.intra.cea.fr (132.166.88.77) with Microsoft SMTP Server id 14.3.319.2; Mon, 17 Jul 2017 23:43:07 +0200 Received: from epeire2.extra.cea.fr (epeire2.extra.cea.fr [132.167.198.32]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-in-1.4) with ESMTP id v6HLh7Wg006875 for ; Mon, 17 Jul 2017 23:43:07 +0200 Received: from epeire2.extra.cea.fr (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 11124553EFB for ; Mon, 17 Jul 2017 23:43:07 +0200 (CEST) Received: from cirse-smtp-in.extra.cea.fr (cirse-smtp-in.extra.cea.fr [132.167.192.147]) by epeire2.extra.cea.fr (Postfix) with ESMTP id 43B19553A87 for ; Mon, 17 Jul 2017 23:43:06 +0200 (CEST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-in-4.0) with ESMTP id v6HLh15f029307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 17 Jul 2017 23:43:06 +0200 Received: from spool.mail.gandi.net (mspool1-d.mgt.gandi.net [10.0.21.131]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 09DB71720A1; Mon, 17 Jul 2017 23:43:00 +0200 (CEST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) by spool.mail.gandi.net (Postfix) with ESMTPS id 8F54922604A for ; Mon, 17 Jul 2017 23:43:00 +0200 (CEST) Received: by mail-lf0-x232.google.com with SMTP id z78so1513605lff.0 for ; Mon, 17 Jul 2017 14:43:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:delivered-to:dkim-filter:dkim-signature:from:to :cc:subject:thread-topic:thread-index:date:message-id:references :in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=rTUgTxJDccE3Y5KjrVXAQuT6nfBOOm6Pc0MAYl3FXYY=; b=TSangzCkVYLcN14QPVWj7A5rweMJn2XySLO73W1fY4ClmkXLMpURvTQEEJNx3921bn U6m84TA0rxTX4mqth7rYjuHEVYoOC70c7D/sW7UT4Hmy+wM114fdB+83yLt0evOZvnB4 htz2I+peIBmveCaG5wHzXXv3SJQLjgzr2tw0h3nMLYT48n7qiQ7CmKo9prnSxil+/Ugz 2mGnWOk/Ly03eXqlWZver+FhrbzDN7AxRF+4oVsisyf0ShHZOdh6aPnjX86WqRlcdTsn CNKG6EqaS2+ZIaNwUSKbp/kly7Xjux5y1YsDvp4LOLrHjXN++xbRbfSCxXTzJdgEHGOe 83/w== X-Gm-Message-State: AIVw113CJnPtzQ6imM95a1ookWL8l9VG16jl0RzShF56L+mnsCdcC7LE LwnezS3AfymiNBeOgb5t07pJ5wH0OQ2GTXpY8wEQIg== X-Received: by 10.25.28.77 with SMTP id c74mr8780489lfc.32.1500327780014; Mon, 17 Jul 2017 14:43:00 -0700 (PDT) X-Forwarded-To: alexandru.petrescu@incognitus.eu X-Forwarded-For: alexandre.petrescu@gmail.com alexandru.petrescu@incognitus.eu Delivered-To: alexandre.petrescu@gmail.com Received: by 10.25.68.25 with SMTP id r25csp5010463lfa; Mon, 17 Jul 2017 14:42:58 -0700 (PDT) X-Received: by 10.28.147.200 with SMTP id v191mr6137945wmd.95.1500327778870; Mon, 17 Jul 2017 14:42:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1500327778; cv=none; d=google.com; s=arc-20160816; b=LlZaGhFxOKAY+lit0ca9d0/5UN1gDSHXt+D55Uzd2xe+2wsW42B4oCaicG3dFhjwIa e5B/jSEefaHgbbZxdOonb0h/kEB9A+VJ7lJsTQRF1S6iEtI+GH7eqwjhhTGINuPlf/Og zFMtVdLadeS2WaH+/BgJtQeYdc+eDGckvjKFdL5rtUNY8FS6vt9RzinlnvZop7DTYQ+S PNS5Z4vGKAJcs/4a5HwfMolV9O48eb2GgNW4C2HHSR2LGMni8SSFbJd8gaWQ8FX+RjCs liYquWEftoS8Z8vGE4YMh+R8vIN+auk2Cf6k0HGPtViIlWUOqQgpCHSoq9Z88qrGDu51 dqlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:content-transfer-encoding:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from:dkim-signature:dkim-filter :arc-authentication-results; bh=rTUgTxJDccE3Y5KjrVXAQuT6nfBOOm6Pc0MAYl3FXYY=; b=yyKSeLXuiqv9AKD1bZqNaOV+buBLHfuiRWFtTiP6eKEzTh4W3AR8vV9911B2pFqxmt qgm1w8FuaF9Y/6C79kZbNN77n/8pqsUOhC5dIFlRcGN1nc6lnllAK6Mrj3QmbFa9SQbq Yj0sb9nB0a0kiP8luSyzVOQFSH3wY0qfciePdqav3zQrFouMUX6sSYeiiscxV80gUXxo ZF8vKhtJ9DtRBmJSMxkkUXdFkiHXgBlVP8BJm9cNuwe02f3Hquv0jM2E5WuX3gIz17js Ty/94JCX96jnexql/ME+kXmJR0ziiFyM7gDULc20WPSDQOFhQPLvGKX6CG1wreiej8UB 9vfA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@t-mobile.cz header.b=JDqFnw7g; spf=pass (google.com: domain of ales.vizdal@t-mobile.cz designates 93.153.104.87 as permitted sender) smtp.mailfrom=ales.vizdal@t-mobile.cz; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=t-mobile.cz Received: from ctxmailhub.t-mobile.cz (ctxmailhub.t-mobile.cz. [93.153.104.87]) by mx.google.com with ESMTPS id y2si210989wrc.329.2017.07.17.14.42.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2017 14:42:58 -0700 (PDT) Received-SPF: pass (google.com: domain of ales.vizdal@t-mobile.cz designates 93.153.104.87 as permitted sender) client-ip=93.153.104.87; Authentication-Results: mx.google.com; dkim=pass header.i=@t-mobile.cz header.b=JDqFnw7g; spf=pass (google.com: domain of ales.vizdal@t-mobile.cz designates 93.153.104.87 as permitted sender) smtp.mailfrom=ales.vizdal@t-mobile.cz; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=t-mobile.cz X-Hostname: ctxmailhub.t-mobile.cz DKIM-Filter: OpenDKIM Filter v2.10.3 ctxmailhub.t-mobile.cz 53FC62E23F9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=t-mobile.cz; s=dkim2016; t=1500327776; bh=rTUgTxJDccE3Y5KjrVXAQuT6nfBOOm6Pc0MAYl3FXYY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=JDqFnw7gsR87aA/yiqfoOMvTJANIChY4HNqOatVz9W81nESLSJa7bYt+xNQYhC2z5 xHqplxJ8Mi90//IEv6+RBXN+8sSIVSgpdDhbkFgRA0OWmBHcv8QtWKWrSjaGgCRBWC NaPVXKf+PtPMVNjvz9JDNvFkq/Axxzb1gAjR/XHdFEAl+OaE/Dva7ijkDNpIGLuFa3 7iIR3UX19/ETg9R254tvTrzF5TG+Ogq5YHHeudBShTOm1f5MnZRhDjT7WBJnSFvpvR qP3mLdwMfwuEejkxK3OvhgkGcPzsB7+LelZq9he5mB1W2bKn8YgffBbTGUojj5wQzd Ptj2lMAzeuLQg== From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= To: Alexandre Petrescu CC: Ted Lemon , dhcwg , "Bernie Volz (volz)" Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-rfc3315bis-09.txt - questions about Solicit Prefix Delegation Thread-Index: AQHS/M+G8BPWcnoA8ku2dlH89fUEWaJThLcAgAALPQCAACR7y///5TaAgATz+PA= Date: Mon, 17 Jul 2017 21:42:56 +0000 Message-ID: <6606c293c34d405e8153273a4bdeb357@srvhk403.rdm.cz> References: <149869621720.6575.278128190348174876@ietfa.amsl.com> <08e4e953-3a68-d6cb-6066-f60514ef0ac5@gmail.com> <3285281858d043649d507b6bda7b8646@XCH-ALN-003.cisco.com> <1f94b780-59c1-42ce-936d-0c8a71143444@gmail.com> <37917a26062f4e4c9715d324604e4d01@XCH-ALN-003.cisco.com> <5fdc7054-7012-30ee-dec7-618f3cd3646f@gmail.com> <6f811cd2-61f1-05c2-1ede-b6933fa1dbb3@gmail.com> <0ea332fc-79a0-4ae9-50fc-465f2389157a@gmail.com> <243e84a0-2804-d1a3-2d9d-4969c83e81df@gmail.com> In-Reply-To: <243e84a0-2804-d1a3-2d9d-4969c83e81df@gmail.com> Accept-Language: en-GB, cs-CZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-CFilter-Loop: Forwarded X-Spam-Level: X-CEA-Source: externe X-CEA-Spam: 8% X-CEA-Spam-Report: The following antispam rules were triggered by this message: Rule Score Description MULTIPLE_RCPTS 0.100 To or Cc suggests the message has a number of recipients. HTML_00_01 0.050 Message is 0-1% HTML HTML_00_10 0.050 Message is 0-10% HTML CTE_BASE64 0.000 Content-Transfer-Encoding is base64 DKIM_SIGNATURE 0.000 DKIM_Signature IN_REP_TO 0.000 Found a In-Reply-To header LEGITIMATE_SIGNS 0.000 Themes of legitimate signs MSG_THREAD 0.000 Possible discussion thread MULTIPLE_REAL_RCPTS 0.000 The recipients suggest that the mail is less likely a spam REFERENCES 0.000 Has a valid-looking References header X-CEA-Spam-Hits: MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, CTE_BASE64 0, DKIM_SIGNATURE 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_COMMON 0, __FRAUD_REFNUM 0, __FRAUD_WEBMAIL 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HIGHBITS 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MSGID_32HEX 0, __MULTIPLE_RCPTS_CC_X2 0, __MULTIPLE_URI_TEXT 0, __NO_HTML_TAG_RAW 0, __RCVD_GOOGLE_IPV6 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NS , __URI_WITHOUT_PATH 0, __URI_WITH_PATH 0, __X_FORWARDED_FOR_GMAIL 0, __X_FORWARDED_TO 0, __YOUTUBE_RCVD 0 Return-Path: alexandre.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com X-MS-Exchange-Organization-AuthSource: EXCAH-A3.intra.cea.fr X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.100.1062-23070.007 X-TM-AS-Result: No--30.475200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-MS-Exchange-Organization-AVStamp-Mailbox: SMEXyGDz;1340700;0;This mail has been scanned by Trend Micro ScanMail for Microsoft Exchange; X-MS-Exchange-Organization-SCL: 0 MIME-Version: 1.0 cmVzcG9uc2UgaW5saW5lDQoNCkFsZXMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEFsZXhhbmRyZSBQZXRyZXNjdSBbbWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBn bWFpbC5jb21dDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAxNCwgMjAxNyA5OjUwIFBNDQo+IFRvOiBW w616ZGFsIEFsZcWhIDxhbGVzLnZpemRhbEB0LW1vYmlsZS5jej4NCj4gQ2M6IFRlZCBMZW1vbiA8 bWVsbG9uQGZ1Z3VlLmNvbT47IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz47IEJlcm5pZSBWb2x6DQo+ ICh2b2x6KSA8dm9sekBjaXNjby5jb20+DQo+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtZGhjLXJmYzMzMTViaXMtMDkudHh0IC0gcXVlc3Rpb25zDQo+IGFib3V0 IFNvbGljaXQgUHJlZml4IERlbGVnYXRpb24NCj4NCj4NCj4NCj4gTGUgMTQvMDcvMjAxNyDDoCAy MToyNiwgVsOtemRhbCBBbGXFoSBhIMOpY3JpdCA6DQo+ID4NCj4gPg0KPiA+PiBPbiAxNCBKdWwg MjAxNywgYXQgMjE6MTUsIEFsZXhhbmRyZSBQZXRyZXNjdQ0KPiA+PiA8YWxleGFuZHJlLnBldHJl c2N1QGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4+DQo+ID4+PiBMZSAxNC8wNy8yMDE3IMOgIDIwOjM1 LCBUZWQgTGVtb24gYSDDqWNyaXQgOiBTbyBhcmUgdGhlIERIQ1AgY2xpZW50cw0KPiA+Pj4geW91 IGFyZSB0YWxraW5nIGFib3V0IHNldHRpbmcgdGhlIElQIGhlYWRlciBob3AgY291bnQgdG8NCj4g Pj4+ICAwLzEsIG9yIHRoZSBESENQIGhlYWRlciBob3AtY291bnQgZmllbGQgdG8gMC8xPyAgIFRo YXQgaXMsIHdoYXQNCj4gPj4+ICBpcyB0aGUgYmVoYXZpb3IgeW91IGFyZSBjb25jZXJuZWQgYWJv dXQsIGFuZCB3aHkgZG8geW91IHRoaW5rIGl0DQo+ID4+PiBtaWdodCBjYXVzZSBhIHByb2JsZW0g aW4gdGhpcyBjYXNlPw0KPiA+Pg0KPiA+PiBTb21lIGNsaWVudHMgSSBhbSB0YWxraW5nIGFib3V0 IGlzc3VlIERIQ1AgU29saWNpdCB3aXRoIEhvcCBMaW1pdA0KPiA+PiBmaWVsZCBpbiB0aGUgSVB2 NiBiYXNlIGhlYWRlciAobm90IERIQ1AgVURQIGhlYWRlcikgd2l0aCB2YWx1ZSAxLg0KPiA+Pg0K PiA+PiBUaGlzIFNvbGljaXQgaXMgc2VudCBvbiBhIGNlbGx1bGFyIG5ldHdvcmsuICBUaGUgY2Vs bHVsYXIgbmV0d29yaw0KPiA+PiBlbmNhcHN1bGF0ZXMgYXQgc29tZSBwb2ludCBpbiBJUHY0LCBh bmQgZnVydGhlciBkZWNhcHN1bGF0ZXMuICBUaGUNCj4gPj4gZW5jYXBzdWxhdGlvbiBwcm90b2Nv bCBpcyBjYWxsZWQgIkdUUFUiIGJ5IHNvbWUgbm9uLXdpcmVzaGFyayBwYWNrZXQNCj4gPj4gZHVt cCBmb3JtYXQsIHdpdGggZmllbGRzIGxpa2UgIlRFSUQiLCAiR1RQX1RQRFVfTVNHIi4gIFRoaXMg IGNlbGx1bGFyDQo+ID4+IG5ldHdvcmsgZG9lcyBub3Qgb2ZmZXIgSVB2NCBhY2Nlc3MgdG8gZW5k IHVzZXIsIGl0IG9ubHkgb2ZmZXJzIElQdjYuDQo+ID4+DQo+ID4+IFRoZXJlIGlzIG5vIEdUUCBS RkMuDQo+ID4NCj4gPiBHVFAgYWthIEdQUlMgVHVubmVsbGluZyBQcm90b2NvbCBoYXMgYmVlbiBz cGVjaWZpZWQgYnkgM0dQUC4NCj4gPg0KPiA+IEl0IHN0YXJ0cyBhdCB0aGUgZU5vZGVCIGFuZCB0 ZXJtaW5hdGVzIGF0IHRoZSBQR1cgd2hlcmUgdGhlIERIQ1ANCj4gPiBzZXJ2ZXIvcmVsYXkgd291 bGQgc2l0Lg0KPg0KPiBZb3Ugc2VlLCBJIGFtIGFsc28gdG9sZCB0aGF0IG15ICJNVCIgKCJNb2Jp bGUgVGVybWluYWwiPykgdGVybWluYXRlcyBHVFAuICBJDQo+IGd1ZXNzIGJvdGggYXJlIHBvc3Np YmxlICh0ZXJtaW5hdGUgc29tZSB0aW1lcyBhdCBlTm9kZUIgYW5kIG90aGVyIHRpbWVzIGF0DQo+ IE1UKS4NCg0KSSBjYW4gb25seSByZWNvbW1lbmQgY2hlY2tpbmcgdGhlIDNHUFAgdGVjaG5pY2Fs IHNwZWNpZmljYXRpb24gZGVhbGluZyB3aXRoIHRoZSBhcmNoaXRlY3R1cmUgYW5kIHByb3RvY29s IGRldGFpbHMuDQpHb29nbGUgd2lsbCBoZWxwLg0KDQo+IE9yIG90aGVyd2lzZSB0aGUgZXhwcmVz c2lvbiAidGVybWluYXRlIGF0IiBtYXkgaGF2ZSBkaWZmZXJlbnQgbWVhbmluZ3MgdG8NCj4gZGlm ZmVyZW50IHBlb3BsZS4NCj4NCj4gPj4gVGhlcmUgaXMgYW4gUkZDIGZvciAiR2VuZXJpYyBQYWNr ZXQgVHVubmVsbGluZyBpbiBJUHY2Ii4gIFRoaXMgUkZDDQo+ID4+IHNheXMgdGhhdCBlbmNhcC9k ZWNhcCBkZWNyZW1lbnRzIHRoZSBIb3AgTGltaXQuDQo+ID4+DQo+ID4+IFRoaXMgcmFpc2VzIGEg cG90ZW50aWFsIHNwZWN1bGF0aW9uIHRoYXQgdGhlIG5ldHdvcmsgZHJvcHMgYW4NCj4gPj4gaW5j b21pbmcgcGFja2V0IHRoYXQgaGFzIEhvcCBMaW1pdCAxLg0KPiA+Pg0KPiA+PiBJdCBtYXkgYmUg dGhhdCB0aGUgR1RQIGVuY2Fwc3VsYXRpb24gKG5vIFJGQykgZG9lcyBub3QgZGVjcmVtZW50IHRo ZQ0KPiA+PiBIb3AgTGltaXQgb2YgYSBwYWNrZXQtdG8tYmUtZW5jYXBzdWxhdGVkLiAgSW4gdGhp cyBjYXNlIHRoZXJlIGlzIG5vDQo+ID4+IHByb2JsZW0gd2l0aCBESENQIFNvbGljaXQgaGF2aW5n IEhvcCBMaW1pdCAxLg0KPiA+DQo+ID4gSXQgc2hhbGwga2VlcCB0aGUgcGFja2V0IGFzLWlzLCBz aW5jZSBpdCBpcyBub3QgdmlzaWJsZSBmcm9tDQo+ID4gdXNlci9kYXRhLXBsYW5lIHBvaW50IG9m IHZpZXcuDQo+DQo+IEkgZG9udCB1bmRlcnN0YW5kIHRoYXQuICBOb3Qgc3VyZSB3aGF0IHlvdSBt ZWFuIGJ5IHVzZXItZGF0YSBwbGFuZXMuDQoNCllvdSBjYW4gaW1hZ2luZSB0aGF0IHlvdXIgSVAg dHJhZmZpYyAob3JpZ2luYXRlZCBieSB0aGUgVUUgb3IgZGV2aWNlcyBiZWhpbmQgdGhlIFVFKSBp cyBhIHBheWxvYWQgdG8gdGhlIE1vYmlsZSBOZXR3b3JrLg0KSXQgaXMgcmVjZWl2ZWQgb24gdGhl IHJhZGlvIGludGVyZmFjZSBvZiB0aGUgZU5vZGVCIHRoYXQgcHV0cyB0aGUgcGFja2V0IGludG8g dGhlIEdUUCwgdGhlcmUgaXMgbm8gcm91dGluZyBpbnZvbHZlZC4NCkluIG90aGVyIHdvcmRzLCB5 b3VyIFVFIGlzIGFzc2lnbmVkIGFuIElQIGFkZHJlc3MgLyBJUHY2IHByZWZpeCwgdGhlIEwzIG5l eHQgaG9wIGlzIHRoZSBHR1NOL1BHVywgc28gYW55IG90aGVyIG5vZGUgYmV0d2Vlbg0KeW91ciBV RSBhbmQgdGhlIEdHU04vUEdXIGRvZXMgbm90IGNoYW5nZSB0aGUgcGFja2V0IGFzIGl0IGZvcndh cmRzIGJhc2VkIG9uIHRoZSBHVFAgaGVhZGVyLg0KDQo+IFRoZSBJUCBIb3AgTGltaXQgaXMgaW4g dGhlIElQIGhlYWRlci4gIFNvbWUgSVAgdHVubmVsbGluZyBtZWNoYW5pc21zIGRvIHRvdWNoDQo+ IHRoZSBIb3AgTGltaXQgb2YgdGhlIGVuY2Fwc3VsYXRlZCBwYWNrZXQuICBXaHkgd291bGQgR1RQ IGJlIGRpZmZlcmVudCB0aGFuDQo+IHRoZSBvdGhlciBJUCB0dW5uZWxsaW5nIG1lY2hhbmlzbXM/ DQoNCkFzIHN0YXRlZCBhYm92ZSwgdGhlcmUgaXMgbm8gcm91dGluZyBpbnZvbHZlZC4gV2hhdCBp cyByZWNlaXZlZCBvbiB0aGUgcmFkaW8gaW50ZXJmYWNlIGlzIGVuY2Fwc3VsYXRlZCBpbnRvIEdU UCBhbmQgZm9yd2FyZGVkIHRvd2FyZHMgdGhlIEdHU04vUEdXLg0KDQo+ID4gSSBzdWdnZXN0IGEg ZGVlcCBkaXZlIGludG8gM0dQUCBzcGVjcyAuLi4NCj4NCj4gSXQgaXMgY2VydGFpbmx5IGFkdmFu dGFnZW91cyB0byB1bmRlcnN0YW5kIHRoZSAzR1BQIHNwZWNzLg0KDQpJdCBpcyBrZXkgdG8gdW5k ZXJzdGFuZCB0aGUgYXJjaGl0ZWN0dXJlIC4uLg0KDQo+IEJ1dCBJJ2QgcmF0aGVyIGNvbnNpZGVy IHB1dHRpbmcgdGhhdCBpbnRvIGFuIEludGVybmV0IERyYWZ0Lg0KDQpOb3Qgc3VyZSBpZiByZWNh c3RpbmcgM0dQUCwgRVRTSSwgQkJGIGFuZCBvdGhlciBzcGVjcyBhcyBJRCdzIHdvdWxkIGhlbHAu DQoNCj4gQWxleA0KPg0KPiA+DQo+ID4+IEFsZXgNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4+IE9u IEZyaSwgSnVsIDE0LCAyMDE3IGF0IDg6MzIgUE0sIEFsZXhhbmRyZSBQZXRyZXNjdQ0KPiA+Pj4g PGFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20gPG1haWx0bzphbGV4YW5kcmUucGV0cmVzY3VA Z21haWwuY29tPj4NCj4gPj4+IHdyb3RlOiBMZSAxMy8wNy8yMDE3IMOgIDIzOjE0LCBUZWQgTGVt b24gYSDDqWNyaXQgOiBPbiBKdWwgMTMsIDIwMTcNCj4gPj4+IDE2OjAxLCAiQWxleGFuZHJlIFBl dHJlc2N1IiA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbQ0KPiA+Pj4gPG1haWx0bzphbGV4 YW5kcmUucGV0cmVzY3VAZ21haWwuY29tPg0KPiA+Pj4gPG1haWx0bzphbGV4YW5kcmUucGV0cmVz Y3VAZ21haWwuY29tDQo+ID4+PiA8bWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb20+ Pj4gd3JvdGU6IE15IG9wcGluaW9uIGlzIHRvDQo+ID4+PiBtYWtlIERIQ1Agc3BlYyBIb3AgTGlt aXQgPiAxLiAgSW4gb3JkZXIgdG8gbWFrZSBzdXJlIHRoYXQgdGhlDQo+ID4+PiBlbmNhcC9kZWNh cCBvZiBESENQIFNvbGljaXQgaW4gSVB2NCBHVFAgaGFwcGVuaW5nIG9uIGEgY2VsbHVsYXIgbGlu aw0KPiA+Pj4gZG9lcyBub3QgZHJvcCBpdCB0byAwIHVwb24gZGVjYXAuIElmIGEgbGluayBsb2Nh bCBzb3VyY2VkIG11bHRpY2FzdA0KPiA+Pj4gd2l0aCBhIGhvcCBsaW1pdCBvZiBvbmUgaXMgZHJv cHBlZCBiZXR3ZWVuIHNlbmRlciBhbmQgcmVjZWl2ZXIsIGlwDQo+ID4+PiBpcyBicm9rZW4gb24g dGhhdCBsaW5rLCBuZSBjJ2VzdCBwYXM/IElmIHRoYXQgbGluayBpcyBhIHJlYWwgbGluaw0KPiA+ Pj4gdGhlbiB5ZXMgLSBpcCBpcyBicm9rZW4gb24gdGhhdCBsaW5rLiBCdXQgaWYgdGhlIGxpbmsg aXMgYSB2aXJ0dWFsDQo+ID4+PiBsaW5rIC0gbGlrZSB3aGVuIG9uIGEgdHVubmVsIC0gdGhlbiBp dCBtYXkgYmUgdGhhdCB0dW5uZWwgd29ya3Mgb3INCj4gPj4+IG5vLiBBbGV4DQo+ID4+DQo+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIGRoY3dnIG1h aWxpbmcgbGlzdA0KPiA+PiBkaGN3Z0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RoY3dnDQo+ID4NCj4gPiBaw6FzYWR5IGtvbXVuaWthY2UsIGt0ZXLDqSBz cG9sZcSNbm9zdCBULU1vYmlsZSBDemVjaCBSZXB1YmxpYyBhLnMuDQo+ID4gdcW+w612w6EgcMWZ aSBzamVkbsOhdsOhbsOtIHNtbHV2LCBqc291IHV2ZWRlbnkNCj4gPiB6ZGU8aHR0cDovL3d3dy50 LQ0KPiBtb2JpbGUuY3ovZGNwdWJsaWMvWmFzYWR5X2tvbXVuaWthY2VfcHJpX3NqZWRuYXZhbmlf c21sdXZfY3oucGRmPi4NCj4gPg0KPiA+DQo+ID4NCj4gTmVuw60tbGkgdiB6w6FzYWTDoWNoIHV2 ZWRlbm8gamluYWssIG5lcMWZZWRzdGF2dWplIHRhdG8genByw6F2YSBrb25lxI1uw70NCj4gPiBu w6F2cmggbmEgdXphdsWZZW7DrSDEjWkgem3Em251IHNtbG91dnkgYW5pIHDFmWlqZXTDrSB0YWtv dsOpaG8gbsOhdnJodS4gVGhlDQo+ID4gY29tbXVuaWNhdGlvbiBwcmluY2lwbGVzIHdoaWNoIFQt TW9iaWxlIEN6ZWNoIFJlcHVibGljIGEucy4gYXBwbGllcw0KPiA+IHdoZW4gbmVnb3RpYXRpbmcg Y29udHJhY3RzIGFyZSBkZWZpbmVkDQo+ID4gaGVyZTxodHRwOi8vd3d3LnQtDQo+IG1vYmlsZS5j ei9kY3B1YmxpYy9aYXNhZHlfa29tdW5pa2FjZV9wcmlfc2plZG5hdmFuaV9zbWx1dl9lbi5wZGY+ Lg0KPiA+DQo+ID4NCj4gPg0KPiBVbmxlc3Mgb3RoZXJ3aXNlIHN0YXRlZCBpbiB0aGUgcHJpbmNp cGxlcywgdGhpcyBtZXNzYWdlIGRvZXMgbm90DQo+ID4gY29uc3RpdHV0ZSB0aGUgZmluYWwgb2Zm ZXIgdG8gY29udHJhY3Qgb3IgYW4gYW1lbmRtZW50IG9mIGEgY29udHJhY3QNCj4gPiBvciBhY2Nl cHRhbmNlIG9mIHN1Y2ggb2ZmZXIuDQo+ID4NCg0KWsOhc2FkeSBrb211bmlrYWNlLCBrdGVyw6kg c3BvbGXEjW5vc3QgVC1Nb2JpbGUgQ3plY2ggUmVwdWJsaWMgYS5zLiB1xb7DrXbDoSBwxZlpIHNq ZWRuw6F2w6Fuw60gc21sdXYsIGpzb3UgdXZlZGVueSB6ZGU8aHR0cDovL3d3dy50LW1vYmlsZS5j ei9kY3B1YmxpYy9aYXNhZHlfa29tdW5pa2FjZV9wcmlfc2plZG5hdmFuaV9zbWx1dl9jei5wZGY+ LiBOZW7DrS1saSB2IHrDoXNhZMOhY2ggdXZlZGVubyBqaW5haywgbmVwxZllZHN0YXZ1amUgdGF0 byB6cHLDoXZhIGtvbmXEjW7DvSBuw6F2cmggbmEgdXphdsWZZW7DrSDEjWkgem3Em251IHNtbG91 dnkgYW5pIHDFmWlqZXTDrSB0YWtvdsOpaG8gbsOhdnJodS4gVGhlIGNvbW11bmljYXRpb24gcHJp bmNpcGxlcyB3aGljaCBULU1vYmlsZSBDemVjaCBSZXB1YmxpYyBhLnMuIGFwcGxpZXMgd2hlbiBu ZWdvdGlhdGluZyBjb250cmFjdHMgYXJlIGRlZmluZWQgaGVyZTxodHRwOi8vd3d3LnQtbW9iaWxl LmN6L2RjcHVibGljL1phc2FkeV9rb211bmlrYWNlX3ByaV9zamVkbmF2YW5pX3NtbHV2X2VuLnBk Zj4uIFVubGVzcyBvdGhlcndpc2Ugc3RhdGVkIGluIHRoZSBwcmluY2lwbGVzLCB0aGlzIG1lc3Nh Z2UgZG9lcyBub3QgY29uc3RpdHV0ZSB0aGUgZmluYWwgb2ZmZXIgdG8gY29udHJhY3Qgb3IgYW4g YW1lbmRtZW50IG9mIGEgY29udHJhY3Qgb3IgYWNjZXB0YW5jZSBvZiBzdWNoIG9mZmVyLg0K --------------E82BAB2501900778ADDC75B4-- From nobody Thu Sep 21 07:47:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28828134B78 for ; Thu, 21 Sep 2017 07:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2eyWsdkCnZY for ; Thu, 21 Sep 2017 07:47:26 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC945134B7F for ; Thu, 21 Sep 2017 07:47:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 41A36AF; Thu, 21 Sep 2017 16:47:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506005242; bh=a2iaKXWiK2nK2iSPv1O/0n1eiLUFPcTThPu6BgkcW6o=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=y97PlnSkwTIqgRON5qO6+KkzrHM3blbouHwYpMlIwPv8uk4635UejWGLEPZmywdxy ByoG/YVU1cssvfvBi05OG6u8m2egVg+zv4+Q6/kpMupxKdfMRLvoj/x4EM0dwS6bMa C0rOgzFKDe/KdTZwx0KzUJ2uGcNRZe7dKSOiyXOU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2842784; Thu, 21 Sep 2017 16:47:22 +0200 (CEST) Date: Thu, 21 Sep 2017 16:47:22 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Ca By , Owen DeLong , v6ops@ietf.org In-Reply-To: Message-ID: References: <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <3c8584d6-278a-751a-ecd8-d1c9b2cc2206@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-633620784-1506005242=:29378" Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 14:47:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-633620784-1506005242=:29378 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > > > Le 21/09/2017 à 15:56, Mikael Abrahamsson a écrit : >> On Thu, 21 Sep 2017, Alexandre Petrescu wrote: >> >>> Ok, I can agree if you say so.  I can not capture packets on the UE to >>> confirm or infirm; the "UE" is the "modem", that's how Balong calls it; >>> there is no source code for that part. >>> >>> It seems that you tried to capture on modem?  Or is it that somebody told >>> this to you?  Or is it that it is in the 3GPP specs? >> >> It's in the 3GPP spec. In 3G it's GTP GGSN-RNC, and then it's handled by >> the RLC layer between RNC and UE. I'd imagine it's something similar in LTE >> but then instead between UE and eNodB (since there is no RNC). > > So you mean the UE does GTP? No. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-633620784-1506005242=:29378-- From nobody Thu Sep 21 07:50:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A8913420C for ; Thu, 21 Sep 2017 07:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFCnqa8VdZnA for ; Thu, 21 Sep 2017 07:50:48 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8927F12ECEC for ; Thu, 21 Sep 2017 07:50:48 -0700 (PDT) Received: from rev-2001-13c7-7003-eventos.lacnic.net (rev-2001-13c7-7003-eventos.lacnic.net [IPv6:2001:13c7:7003:200:89b1:fe18:87f2:4c2d] (may be forged)) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id v8LEndil027076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Sep 2017 07:49:43 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Owen DeLong In-Reply-To: Date: Thu, 21 Sep 2017 11:49:39 -0300 Cc: Ole Troan , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <85d934b3-ae06-c0ea-3519-4069c8387f0a@gmail.com> <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <3F99667F-56A6-487E-9AA6-D0FCB0BB4450@employees.org> ! To: Alexandre Petrescu X-Mailer: Apple Mail (2.3124) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (owen.delong.com [IPv6:2620:0:930::200:2]); Thu, 21 Sep 2017 07:49:46 -0700 (PDT) Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 14:50:50 -0000 > Here, in this operations group, there is need that Android accepts = these > RFCs. I=92m not sure that we want to take on the role of RFC Enforcement = Police in this group. > And we need that before we even talk moving an Android-only CLAT from > INFORMATIONAL to something else. First, I don=92t accept your idea that CLAT is =93Android-only=94. While = Android may be the most prolific example of CLAT implementation, it is = certainly not the only implementation, nor is there anything preventing = CLAT from being deployed in other devices beyond those where it is = currently implemented. It seems clear at this point that your intent is to try and hijack this = thread to apply pressure to Android developers to implement DHCPv6 on = Android. Regardless of the worthiness (or not) of that goal, the simple = reality is that it is a completely orthogonal issue unrelated to 464XLAT = or CLAT in any meaningful way and there=92s simply no validity to your = argument. Jordi, Ole, Cameron, and myself, have all made it clear to you that the = claims you have made in an attempt to tie the issues together are not = supported by the facts. CLAT and DHCP can co-exist on the same network. = CLAT and IPv6-in-GTP can co-exist as well. DHCP is an address and/or prefix assignment mechanism. IPv6-in-GTP is a tunneling mechanism for moving IPv6 packets through an = IPv4 mobile network. CLAT and/or 464XLAT are an IPv6 transition mechanism allowing an = IPv6-only client to connect to IPv4 servers via an IPv6-only network = with appropriate PLAT support. They are three completely separate solution spaces and all three can = co-exist. > Alex > PS: to support the claim that Android explicitely blocks DHCPv6, I can > provide pointers to public Google pages, numerous requests of DHCPv6 > integration in Android (to avoid need of 'rooting' the devices), the > availability of DHCPv6 app in Android store that runs only on WiFi and > must 'root', invitations from competitor OSs to bring DHCPv6 there > instead of Android, and more. We get it=85 Android doesn=92t support DHCPv6 and you don=92t like that. However, this isn=92t about Android, it=92s about 464XLAT and CLAT. = These are protocols, not vendors. Take your Android issues up with the Android developers. They are = unrelated to this thread. Owen From nobody Thu Sep 21 07:54:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82E5134B77 for ; Thu, 21 Sep 2017 07:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VQPFXK2zU27d for ; Thu, 21 Sep 2017 07:54:44 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA2C129A89 for ; Thu, 21 Sep 2017 07:54:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 06C54AF; Thu, 21 Sep 2017 16:54:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506005682; bh=weu+yKNM0CclbdeRwr6uBcgEvwUgN1csholcAi70WGc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lYq/wfjF6cuXqqWY1X3kpO+bjAfAkEuhF4Rk/gnzv+kyRrsLcPPB6pdd9I5NN7oIQ Hj4QrcMLFvdmuX0jHtoezoGT7/AvByF9bGUAP8auejhCJ+cQKoDc6GJJnP8k+HlBuN e+AwUzQIMz4lixKyBIkSrvA7Uah2JrUjN/3ZjZeg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E302A84; Thu, 21 Sep 2017 16:54:41 +0200 (CEST) Date: Thu, 21 Sep 2017 16:54:41 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Ca By , Owen DeLong , v6ops@ietf.org In-Reply-To: Message-ID: References: <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <3c8584d6-278a-751a-ecd8-d1c9b2cc2206@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-128636461-1506005681=:29378" Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 14:54:46 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-128636461-1506005681=:29378 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > > > Le 21/09/2017 à 15:56, Mikael Abrahamsson a écrit : >> On Thu, 21 Sep 2017, Alexandre Petrescu wrote: >> >>> Ok, I can agree if you say so.  I can not capture packets on the UE to >>> confirm or infirm; the "UE" is the "modem", that's how Balong calls it; >>> there is no source code for that part. >>> >>> It seems that you tried to capture on modem?  Or is it that somebody told >>> this to you?  Or is it that it is in the 3GPP specs? >> >> It's in the 3GPP spec. In 3G it's GTP GGSN-RNC, and then it's handled by >> the RLC layer between RNC and UE. I'd imagine it's something similar in LTE >> but then instead between UE and eNodB (since there is no RNC). > > So you mean the UE does GTP? Since at least one more person has asked about this. GTP: GGSN-RNC RLC: RNC-UC GTP tunnel is terminated in RNC and packet is decapsulated before reaching the RLC layer (in the GGSN->UE direction). -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-128636461-1506005681=:29378-- From nobody Thu Sep 21 07:59:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12413307D for ; Thu, 21 Sep 2017 07:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiiyQXeg7Qvm for ; Thu, 21 Sep 2017 07:59:39 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120B0126B6D for ; Thu, 21 Sep 2017 07:59:38 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8LExYVg039852; Thu, 21 Sep 2017 16:59:34 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D6F5C20F079; Thu, 21 Sep 2017 16:59:34 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C97B020F058; Thu, 21 Sep 2017 16:59:34 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8LExY6m010455; Thu, 21 Sep 2017 16:59:34 +0200 To: Mikael Abrahamsson Cc: Ca By , Owen DeLong , v6ops@ietf.org References: <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <3c8584d6-278a-751a-ecd8-d1c9b2cc2206@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 21 Sep 2017 16:59:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 14:59:40 -0000 Le 21/09/2017 à 16:47, Mikael Abrahamsson a écrit : > On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > >> >> >> Le 21/09/2017 à 15:56, Mikael Abrahamsson a écrit : >>> On Thu, 21 Sep 2017, Alexandre Petrescu wrote: >>> >>>> Ok, I can agree if you say so.  I can not capture packets on the UE >>>> to confirm or infirm; the "UE" is the "modem", that's how Balong >>>> calls it; there is no source code for that part. >>>> >>>> It seems that you tried to capture on modem?  Or is it that somebody >>>> told this to you?  Or is it that it is in the 3GPP specs? >>> >>> It's in the 3GPP spec. In 3G it's GTP GGSN-RNC, and then it's handled >>> by the RLC layer between RNC and UE. I'd imagine it's something >>> similar in LTE but then instead between UE and eNodB (since there is >>> no RNC). >> >> So you mean the UE does GTP? > > No. So I understand from three different persons that UE does not use GTP. If nobody else tries, I will have to ask the modem manufacturer. Alex > From nobody Thu Sep 21 08:02:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F75D12ECEC; Thu, 21 Sep 2017 08:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yPhq-trP8P7; Thu, 21 Sep 2017 08:02:43 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661BF126B6D; Thu, 21 Sep 2017 08:02:43 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id w9so4246506ywi.11; Thu, 21 Sep 2017 08:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:mime-version:subject:date:references:to:message-id; bh=ri1KqkSUqNkr9SoESy/6rsqKS+bmqIPF7qAFbnsnUfw=; b=JfUKCdvdre/G4A1Mq+qKa8Obe9yWunAD7JlxZmhTDv6uoakAsRv+o7ipLJGGzGsLuH OHKOZWxk6MjL8x7snZWQlI7gMeL5psMFWKaXBkOU0qOf2TZJNFppOgat14qeoRniU8mf uCcWMUNQyDzxET+IsROrBJsrmhBiFL0UiwQcghN1NeKo6l+S7HTH2egyFZ3IvvvB25Ju rGtVtslqOIdIaxR+plGkeRyk/Hq/WFsgcTwLZvfudOwP3D4HlUEb8DVYMuTOXBp3MBpA rU6qllt7XWqL/zN0rEb7RVb5KFXwC6ZtClpGBhrCYPwnxpMZnXjX2WiC5UEAyHSjQ4jL IcAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:mime-version:subject:date :references:to:message-id; bh=ri1KqkSUqNkr9SoESy/6rsqKS+bmqIPF7qAFbnsnUfw=; b=bwYnK6sNZFKG0J0BfdWK+3HZbUskw51ePgxMntc2LMbFpooHYGiUGIqYNJLdGd5PC+ lCs73tnvvy4sSJXVFyII2M4LVEvHdc8nqIU2LcnQGo0t5skj5aZwBvK5QQOXN2XCUNd8 aQtkoeWsfLkWGV+rNuIPfxkKGmg1QZbpkIuZwP5sOiYmM/vj0VUNyzLNzXFYXuCJnlBU 4TNS5842jfyL1EMANr+Xf6DXAlhpGFF8jl/m7hf1I8AXha6anrh+vTGxwnZhroBvtq2m f3z/C/BpFFcQ85e8fzRzOmBO/2Y9KuoXXQtgF8E6FIOVgGdw4FRgqllIz1/gjN+MP2X5 qLpA== X-Gm-Message-State: AHPjjUhfqYp5mKnPP8fNvH/e70PAznxB1eKRASqzxMBGrqlSI9+lwKak YQee8N2ODGUpVqJ+TfACP5I5M8cn X-Google-Smtp-Source: AOwi7QAgneX2NVvybP0tHfDvrCYPmYYpPhssQ5GB5hoqjJY/uqclVk5c3ro9mTZ90tfB2keGawhDGw== X-Received: by 10.129.172.82 with SMTP id z18mr1807461ywj.277.1506006162203; Thu, 21 Sep 2017 08:02:42 -0700 (PDT) Received: from [10.0.0.12] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id p6sm606108ywp.85.2017.09.21.08.02.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Sep 2017 08:02:40 -0700 (PDT) From: Suresh Krishnan Content-Type: multipart/alternative; boundary="Apple-Mail=_E657DA1A-67A1-4081-A07F-A732B9840C41" Reply-To: int-area Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 21 Sep 2017 11:02:41 -0400 References: <598675A3-39A7-450D-A205-755D457577A8@ericsson.com> To: 6man WG , v6ops@ietf.org, dhcwg Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [v6ops] Fwd: [Int-area] WG Adoption Call: Discovering Provisioning Domain Names and Data X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 15:02:46 -0000 --Apple-Mail=_E657DA1A-67A1-4081-A07F-A732B9840C41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, The intarea working group is considering adoption of a draft = concerning provisioning domains. The response to the adoption call has = been a bit on the quieter side but generally positive. I am spreading = out this adoption call in the hopes of getting wider feedback from = related working groups. Please send your thoughts (Thanks in advance!!) = by September 27th 2017 to the intarea working group mailing list at = int-area@ietf.org. Regards Suresh > Begin forwarded message: >=20 > From: Wassim Haddad > Subject: [Int-area] WG Adoption Call: Discovering Provisioning Domain = Names and Data > Date: September 1, 2017 at 4:14:39 PM EDT > To: > Cc: intarea-chairs@ietf.org >=20 > Dear all, >=20 > Based on the discussion we had at the last intarea WG meeting, we = would like to start a WG adoption call for = draft-bruneau-intarea-provisioning-domains-02 on "Discovering = Provisioning Domain Names and Data=E2=80=9D: >=20 > = https://www.ietf.org/id/draft-bruneau-intarea-provisioning-domains-02.txt >=20 > Please indicate your preferences on the mailling list. The deadline is = September 18th. >=20 >=20 > Regards, >=20 > Wassim & Juan Carlos >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area --Apple-Mail=_E657DA1A-67A1-4081-A07F-A732B9840C41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,
  The intarea working group is = considering adoption of a draft concerning provisioning domains. The = response to the adoption call has been a bit on the quieter side but = generally positive. I am spreading out this adoption call in the hopes = of getting wider feedback from related working groups. Please send your = thoughts (Thanks in advance!!) by September 27th 2017 to the intarea = working group mailing list at int-area@ietf.org.

Regards
Suresh

Begin forwarded message:

From: = Wassim Haddad <wassim.haddad@ericsson.com>
Subject: = [Int-area] WG = Adoption Call: Discovering Provisioning Domain Names and Data
Date: = September 1, 2017 at 4:14:39 PM = EDT
To: = <int-area@ietf.org>
Cc: = intarea-chairs@ietf.org

Dear all,

Based on the discussion we had at the last intarea WG = meeting, we would like to start a WG adoption call for = draft-bruneau-intarea-provisioning-domains-02 on "Discovering = Provisioning Domain Names and Data=E2=80=9D:

https://www.ietf.org/id/draft-bruneau-intarea-provisioning-doma= ins-02.txt

Please indicate your = preferences on the mailling list. The deadline is September 18th.


Regards,

Wassim & Juan Carlos





_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

= --Apple-Mail=_E657DA1A-67A1-4081-A07F-A732B9840C41-- From nobody Thu Sep 21 08:04:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD46134B77 for ; Thu, 21 Sep 2017 08:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTZe8uhLfLUx for ; Thu, 21 Sep 2017 08:04:15 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4E413307D for ; Thu, 21 Sep 2017 08:04:13 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8LF4743041798; Thu, 21 Sep 2017 17:04:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B072C20F0AF; Thu, 21 Sep 2017 17:04:07 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9756F2019FD; Thu, 21 Sep 2017 17:04:07 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8LF47vt014886; Thu, 21 Sep 2017 17:04:07 +0200 To: Owen DeLong Cc: Ole Troan , v6ops@ietf.org References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <3F99667F-56A6-487E-9AA6-D0FCB0BB4450@employees.org> From: Alexandre Petrescu Message-ID: <96c18643-e391-e9c7-7d23-e90bc4827c2d@gmail.com> Date: Thu, 21 Sep 2017 17:04:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 15:04:21 -0000 Le 21/09/2017 16:49, Owen DeLong a crit : [...] > CLAT and DHCP can co-exist on the same network. This is not shown anywhere. I tell you they dont, and they will not. Alex From nobody Thu Sep 21 08:07:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17F4134B82 for ; Thu, 21 Sep 2017 08:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAX0qDNcW2Nv for ; Thu, 21 Sep 2017 08:07:35 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5976134B7F for ; Thu, 21 Sep 2017 08:07:35 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 67111AF; Thu, 21 Sep 2017 17:07:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506006454; bh=gBFoEwzBgaOJyOGYn6N1F4+9wdBNY1FFtpuA20lsio0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=exXRMk7fNNUH02P42EIgUIGSXipBcHuJ9kRyx/tkzRkr8FOgd2D7Ju9eFWPmNETpW BhOWD5FWVXBhxTjJpzfkiwJF8DdSCQWFKRIuLjnuOvs2/PNcjcvYQXMJJbq14q9hd8 l0IOh/xqGlE8LqGnEIRqBPsHMvXbDqenf9/m0WHo= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 63E9684; Thu, 21 Sep 2017 17:07:34 +0200 (CEST) Date: Thu, 21 Sep 2017 17:07:34 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Ca By , Owen DeLong , v6ops@ietf.org In-Reply-To: Message-ID: References: <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <3c8584d6-278a-751a-ecd8-d1c9b2cc2206@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 15:07:38 -0000 On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > So I understand from three different persons that UE does not use GTP. > > If nobody else tries, I will have to ask the modem manufacturer. Correct. The RLC layer is what's run over the "radio". The GTP tunnel header is taken out before it enters this, because it's kind of its own "tunnel". It's the same misconception that there is PPP in 3GPP networks. There isn't, it's just an abstraction between the UE baseband and the operating system. 3G: GTP between GGSN-SGSN-RNC. RLC between RNC-enodb-UE baseband. 4G: GTP between SPGW-enodb RLC between enodb-UE baseband. Then the baseband can have all kinds of interfaces to handoff packets to the kernel. It can pretend to be an ethernet bridge, it can pretend to be PPP tunnel, I'm sure it can pretend to be other things. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 21 08:17:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C055A13304D for ; Thu, 21 Sep 2017 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiRzgjL2qwrX for ; Thu, 21 Sep 2017 08:17:33 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7E4126B6D for ; Thu, 21 Sep 2017 08:17:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8LFHS9Y047273; Thu, 21 Sep 2017 17:17:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7E85E20F125; Thu, 21 Sep 2017 17:17:28 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 73A0020F120; Thu, 21 Sep 2017 17:17:28 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8LFHSLs026418; Thu, 21 Sep 2017 17:17:28 +0200 To: Mikael Abrahamsson Cc: Ca By , Owen DeLong , v6ops@ietf.org References: <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <3c8584d6-278a-751a-ecd8-d1c9b2cc2206@gmail.com> From: Alexandre Petrescu Message-ID: <40ed227b-db4b-a5bf-9af4-014969032fcf@gmail.com> Date: Thu, 21 Sep 2017 17:17:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 15:17:35 -0000 Le 21/09/2017 à 17:07, Mikael Abrahamsson a écrit : > On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > >> So I understand from three different persons that UE does not use GTP. >> >> If nobody else tries, I will have to ask the modem manufacturer. > > Correct. The RLC layer is what's run over the "radio". The GTP tunnel > header is taken out before it enters this, because it's kind of its own > "tunnel". > > It's the same misconception that there is PPP in 3GPP networks. There > isn't, it's just an abstraction between the UE baseband and the > operating system. Yet, Mikael, there is ppp on ARM and there is meaningful dialogue between ARM and something. The operator says they dont do any ppp. So, the modem does a sort of 'ppp proxy' that is not documented anywhere. That's what you call 'misconception' - it's the modem that does things that nobody knows what. > 3G: > GTP between GGSN-SGSN-RNC. > RLC between RNC-enodb-UE baseband. > > 4G: > GTP between SPGW-enodb > RLC between enodb-UE baseband. > > Then the baseband can have all kinds of interfaces to handoff packets to > the kernel. It can pretend to be an ethernet bridge, it can pretend to > be PPP tunnel, I'm sure it can pretend to be other things. YEs. We dont know any of these. It's hard to make any stnadards decision if we dont know this modem behaviour. Imagine it does a sort of 64share itself, and the ARM also does 64share - there are two levels of this 'sharing'. It's not good. Alex From nobody Thu Sep 21 08:20:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB12E132E24 for ; Thu, 21 Sep 2017 08:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMM-FRERI4Y9 for ; Thu, 21 Sep 2017 08:20:40 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DED13247A for ; Thu, 21 Sep 2017 08:20:39 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id w22so4278963ywa.13 for ; Thu, 21 Sep 2017 08:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2h/0hUnRVA8Va45Yd0wjRGOXo7EMkaUQv44NS11BBdo=; b=svl9Mj3FXNqRySt13/IxeCtSgmowIjKeBzjvbrXeC0Lv2iLQS956W0k3cngg36EBxR 4OFnpDgVRYzlx5FOEyy/N9+i6qMBzE+OST5XGCcM3JXYMF51QfS9sfRN+xjpqNu/G+fR 5pd5G1VqdRT4xz8Iu7CrJXOgfFFVYIiCTeDuz3Y8csWvl7h58/rbAbpxnwIMzYRj+Ww/ JM4N/OoQn3VXVCR0Y4Ig9yG/MI7LlQvvkisRjSxnL22h94KW48qnwYR+tMwCN4ht7lJ0 8S/Mgy/INfybdgCBjIjLxDP9wmfQyd2a2we4QpprY78gAMQxAgGD/fin32aPvl8gWZBL gq3Q== 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=2h/0hUnRVA8Va45Yd0wjRGOXo7EMkaUQv44NS11BBdo=; b=PVyiwCPKCNOCZIUKTFI2vPisXkpo1YnjzjBEj6ikvyoQ0CnRUFNK3arNjs6nfWFf+n EtacoypXkoEHieQ2GXbZQaFdDoTIPVJSLtJe7NMKYHqS7AEx2NqPKt3y6b33tr8NsNRm VvReLhafN5rRzzP80EA6TjFfTvyN14XvrGsFOENToqZvZBa/voA08+TNgBPywMJSJ02Y QlgaBfugvtMXrsfPEFwSS/ZQ9JZjtG1R1A4qUAATCVN1CrhZkIu62xlTywNjSjQ4PSDU YsWYfDZ9hlEFHzyf+SRgF+DtTMrQdLS6gqhN0OkXsLqRZ+z5vE2I8tueXJBLqE3DKHZp zC9A== X-Gm-Message-State: AHPjjUjVBUQ4TNsDtFMdWU9qPPRlySiMOnyZIp31nGSXgae9nhOpw2Bz KOFrAGVF32J+T6TmnD2t2RXvNK8nhUSkZzLUV5M= X-Google-Smtp-Source: AOwi7QBh5Bo8PhNwen5fVZE09B0i5mFa818XkZVbS9jVgl90nC1oxpbkE8DFfL7XPfxf7PO0ZCxG7XdkReRQo4MehxM= X-Received: by 10.37.208.203 with SMTP id h194mr616981ybg.503.1506007239106; Thu, 21 Sep 2017 08:20:39 -0700 (PDT) MIME-Version: 1.0 References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <3F99667F-56A6-487E-9AA6-D0FCB0BB4450@employees.org> <96c18643-e391-e9c7-7d23-e90bc4827c2d@gmail.com> In-Reply-To: <96c18643-e391-e9c7-7d23-e90bc4827c2d@gmail.com> From: Ca By Date: Thu, 21 Sep 2017 15:20:27 +0000 Message-ID: To: Alexandre Petrescu , Owen DeLong Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0565d28425b20559b4a270" Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 15:20:43 -0000 --94eb2c0565d28425b20559b4a270 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 21, 2017 at 8:04 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Le 21/09/2017 =C3=A0 16:49, Owen DeLong a =C3=A9crit : > [...] > > CLAT and DHCP can co-exist on the same network. > > This is not shown anywhere. > > I tell you they dont, and they will not. > > Alex OpenWrt / LEDE supports both CLAT and dhcpv6-pd https://forum.openwrt.org/viewtopic.php?id=3D59528 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c0565d28425b20559b4a270 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Sep 21, 2017 = at 8:04 AM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Le 21/09/2017 =C3=A0 16:49, Owen DeLong a =C3=A9crit :
[...]
> CLAT and DHCP can co-exist on the same network.

This is not shown anywhere.

I tell you they dont, and they will not.

Alex

OpenWrt / LE= DE supports both CLAT and dhcpv6-pd







_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--94eb2c0565d28425b20559b4a270-- From nobody Thu Sep 21 08:24:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5BD132E24 for ; Thu, 21 Sep 2017 08:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h43l85HOUIb8 for ; Thu, 21 Sep 2017 08:24:12 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386A213247A for ; Thu, 21 Sep 2017 08:24:12 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id w9so4295985ywi.11 for ; Thu, 21 Sep 2017 08:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EzukmnuYr5QzoYwBg2SRLjfGKV10j4MZ6NrYuhPoUuQ=; b=mZdG9DJOGWlCy/glm8TrIgH4K+dCyQuWtf20kJocIXcm7EONP3uc54FtTFaniNwTBN SdeELvcw4ZEJD1oclVZuce9qeDEFbg1XxiOiZA9v9rC86MVxdquzEfzzyyDPcOLSwt0S PZTDPK1kCGwOeoc6jcyFDGF4ZkLvUObgX6yMkQe//116a2aKUi+p4w6i/MU1YUxbK1RK ivtJ/nxhhWfiz/d5YNmhuytrKfw84cuiLmzVZOkzLc70trqX1Y++XPXLmC3BtRM9K0D0 HyoB7imbk8x3rZlLbuFidD9Cj1Ii0pZIuM0C/Aq29XP6usozHAVrHxO2pFQlDZ8HrdYq NzBA== 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=EzukmnuYr5QzoYwBg2SRLjfGKV10j4MZ6NrYuhPoUuQ=; b=iPx9oop6m02zWU/Q+uaAj4quZ7J9dvRztkzd41ugvT9lw6pYFhxC1Linj0i2iZkrPh mMid7ESfkk3UuvQpybsc4SKRzmwoDvoQsLTTeN1JxBuJ8p/HYwP2eqB2kDs3ENdTdgGp tDV5pkx63Y8SSpSyvNsMmuvFKL16iLiF9UZGmlKRbK2MywMCRB0DOXrF2DZ/69FW0v64 TzxJ5kC1XnlW6yCGiPY3P3KMPIx/yCYvrw5uS1TK5HTg06wP60dXIZya/yO2fULytjlP gnxrO8vIOcccIIbXYOUtEuKPXchoEZdxnhKlSBog8RfYC+SAJPBIAV7DtZOMVBVVpS4n BT+A== X-Gm-Message-State: AHPjjUiP7pxDILhJK7bHafMwCrUyhCwVCJcyatS0HVo5fiOlrWi48sc6 Ucf2jzNLj5YaiFwV3TquEtgLIw41OtbrgHHljJ4= X-Google-Smtp-Source: AOwi7QA8JXrKMJWwKcyB+4HIkpxObl7P171tgO8T5/V+YDzF23CWtu9ng95ci4POiHDnsOALHtGvRliwZA46jaTSYKQ= X-Received: by 10.37.188.204 with SMTP id l12mr1838799ybm.326.1506007451513; Thu, 21 Sep 2017 08:24:11 -0700 (PDT) MIME-Version: 1.0 References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <3F99667F-56A6-487E-9AA6-D0FCB0BB4450@employees.org> <96c18643-e391-e9c7-7d23-e90bc4827c2d@gmail.com> In-Reply-To: From: Ca By Date: Thu, 21 Sep 2017 15:24:00 +0000 Message-ID: To: Alexandre Petrescu , Owen DeLong Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="089e082658fc2d383f0559b4afc2" Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 15:24:14 -0000 --089e082658fc2d383f0559b4afc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 21, 2017 at 8:20 AM Ca By wrote: > On Thu, Sep 21, 2017 at 8:04 AM Alexandre Petrescu < > alexandre.petrescu@gmail.com> wrote: > >> Le 21/09/2017 =C3=A0 16:49, Owen DeLong a =C3=A9crit : >> [...] >> > CLAT and DHCP can co-exist on the same network. >> >> This is not shown anywhere. >> >> I tell you they dont, and they will not. >> >> Alex > > > OpenWrt / LEDE supports both CLAT and dhcpv6-pd > > https://forum.openwrt.org/viewtopic.php?id=3D59528 > > > Better links for one page view of support of CLAT and dhcp https://wiki.openwrt.org/doc/uci/network6 But i agree with Owen, this point and conversation is not useful / helpful. > > >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > --089e082658fc2d383f0559b4afc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Sep 21, 2017 = at 8:20 AM Ca By <cb.list6@gmail.c= om> wrote:
On Thu, Sep 21, 2017 at 8:04 AM Alexandr= e Petrescu <alexandre.petrescu@gmail.com> wrote:
Le 21/09/2017 =C3=A0 16:49, Owen DeLong a =C3=A9crit :
[...]
> CLAT and DHCP can co-exist on the same network.

This is not shown anywhere.

I tell you they dont, and they will not.

Alex

OpenWrt / LEDE supports both CLAT and dhcpv= 6-pd




Better links for one page view of support of CLAT and = dhcp

But i agree with Owen, this point and conv= ersation is not useful / helpful. =C2=A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


<= br>
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--089e082658fc2d383f0559b4afc2-- From nobody Thu Sep 21 08:25:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4012113247A for ; Thu, 21 Sep 2017 08:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJV-papNDxy2 for ; Thu, 21 Sep 2017 08:25:35 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6E6126B6D for ; Thu, 21 Sep 2017 08:25:35 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8LFPSgB126209; Thu, 21 Sep 2017 17:25:28 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0C8DC20F026; Thu, 21 Sep 2017 17:25:28 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F0C6B207C4A; Thu, 21 Sep 2017 17:25:27 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8LFPRRA032314; Thu, 21 Sep 2017 17:25:27 +0200 To: Ca By , Owen DeLong Cc: v6ops@ietf.org References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <3F99667F-56A6-487E-9AA6-D0FCB0BB4450@employees.org> <96c18643-e391-e9c7-7d23-e90bc4827c2d@gmail.com> From: Alexandre Petrescu Message-ID: <31cb26f1-3fbf-fcc6-3948-3878a4b792bb@gmail.com> Date: Thu, 21 Sep 2017 17:25:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 15:25:37 -0000 Le 21/09/2017 à 17:20, Ca By a écrit : > > On Thu, Sep 21, 2017 at 8:04 AM Alexandre Petrescu > > wrote: > > Le 21/09/2017 à 16:49, Owen DeLong a écrit : > [...] > > CLAT and DHCP can co-exist on the same network. > > This is not shown anywhere. > > I tell you they dont, and they will not. > > Alex > > > OpenWrt / LEDE supports both CLAT and dhcpv6-pd Good, but have you tried OpenWRT CLAT and dhcpv6-pd on cellular at the same time? I tell you they dont run together neither on OpenWRT nor anywhere else. If you claim otherwise: please tell me the modem name, manufacturer. Alex From nobody Thu Sep 21 08:36:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B039813214D for ; Thu, 21 Sep 2017 08:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 z84xATelnrN4 for ; Thu, 21 Sep 2017 08:36:01 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847BD126B6D for ; Thu, 21 Sep 2017 08:36:00 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id g29so4887919wrg.11 for ; Thu, 21 Sep 2017 08:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WqFs7d5V8SoIgUPjTBPOuecAWUhXHRvVMWg4WyYQ+yA=; b=npYEogLIFwKkK4S9m780acI/XYY4T73tlxTR2/+nMeF3smDx66iOsHQ/nrRLzq96Ko hR/udA+JP7goT7LAvbMhb9BRw/fQr6MNtvF9v0zhtGjogMsohoL4CIA2bv7Qr+oqOgTU G/g/JmKKtHscdday1w0DsL2I8/3w5RfQK/WEM2yen8qkc75KlHmrDR95fKCTNLReCiD2 mfstfid4zDPZtbmKBN7U6JtrlWS13AfJziu9YCQGDVgYKE5Mn0rvn0BTsffz09SdYQco hl4yRGNWOh0/Qgjwgi+HRogX+4OBeW+n5J9mqXLRIa8/NlpZt6yMS0ErZ4Uln9usprS2 wIiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WqFs7d5V8SoIgUPjTBPOuecAWUhXHRvVMWg4WyYQ+yA=; b=YY4aIrI6dNhtff4rxb+s27s/K1ESBbyxFlTDsa0ooGuzIm6rtheS14Y3oomfLeV0nW 01ghuBgPNzvhyqog5+8gwKpAIEdud76xs3bGmzKGO64lAgYMacJpN9nVlfAIOoDdJuNC PZZBqgcFbp5NhXJlDxPh+Ih/xHjwLGex15SGl3zq8MNXzEE4rpo4qNSTPBUxSLWGOdQu m+kSOq0wC52LqPFH1fZY6wnkxuJeA4/XKF4QMoMq1WYVi/8nDnbDcM41eNQRGp4eedNt RqvHEIrrb9YcXXgjSqbHhOz8VwHT1aJi6Zcv30BcIVBELAWHdW0PIQvBT6n8DiPuFoub F1bg== X-Gm-Message-State: AHPjjUgfXRAW/BVTzsuOMafCrKQUGxKJj/XH2Zbc4wR0iBYoUpiUYVf7 +cSSdr1FSaXqU5hiaYp64JkkxQ2T0O9NPHfyNZhkig== X-Google-Smtp-Source: AOwi7QDuaf1lgU+G/vdIHRJ6xFeo4i6sjVRchMRt78gwO0t/gVBlv3S8mbgaah8YKz6839K+QjC1edPkZwAOvtLPv0M= X-Received: by 10.223.163.83 with SMTP id d19mr2315384wrb.84.1506008158726; Thu, 21 Sep 2017 08:35:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Thu, 21 Sep 2017 08:35:37 -0700 (PDT) In-Reply-To: References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <3F99667F-56A6-487E-9AA6-D0FCB0BB4450@employees.org> <96c18643-e391-e9c7-7d23-e90bc4827c2d@gmail.com> From: Erik Kline Date: Fri, 22 Sep 2017 00:35:37 +0900 Message-ID: To: Ca By Cc: Alexandre Petrescu , Owen DeLong , "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045f1a605c0c3d0559b4d9e1" Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 15:36:03 -0000 --f403045f1a605c0c3d0559b4d9e1 Content-Type: text/plain; charset="UTF-8" > But i agree with Owen, this point and conversation is not useful / helpful. +1 --f403045f1a605c0c3d0559b4d9e1 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgEb7STMyks70mRdSm8Vkx0eUphqh54lom EBNNutHaCEwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTIx MTUzNTU5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBADKm5yLAV+dQcM2pnMmZOryh6ma9AjfAm7kXGL/wOXmwmXyCPXQB 6xD0PQuILU9GzK7VZIxS/vhCsV5BtWXtQz4G1L2LSEZ0YlT606zoNBkFVrkhRhcZNGjVaTGpksO+ ks/ievaxnZfgkrwbX26S6URhrrWp72A2RM5LSQkQZtdaQ8fUYZF+V8MDxwk+sd9Il3kqJDcq86dU qIIZkpc94nl1seVik3mN7pDl3FJ8faFGEnYYoG7WTSXcTY1e8genfdcYFCMssDLa+O/LTrQDnIH+ IQbF0r47R5/v0XUHsIhD3Dil/zQP2HY3J1z+c8YvstXpCMBtLYRTXRS2Y8Z96jU= --f403045f1a605c0c3d0559b4d9e1-- From nobody Thu Sep 21 09:03:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C56134217 for ; Thu, 21 Sep 2017 09:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEniHxZZzlFo for ; Thu, 21 Sep 2017 09:03:22 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FB1132125 for ; Thu, 21 Sep 2017 09:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506009799; x=1506614599; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=5CtrJ9b0wvOVJ9Pbj26GmAQKmwCBPrjQhfsFQ8oOrX4=; b=qkg/D+93VL+be XKczDa2B4JhL7oVPvjm3eXyxoocfYb8qbhig9AfzR520b2JTxXNgDear6ua4U0dn vQdFIzOTEHIlRtYbNlxDIwv67Bck76zVlzwk0724sXRNzBB7SZIXV7qpZOcwFUsJ YRqxvoWuyr4EIp+Vuq+s/R3gBeg1pQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=IY63bE7etPkFbzxj7Tie491H8NPpUi62zEI9qTyEL2hepTRHGPN/BMPa6sbM fee/Z7Bt5WSCOxCbchVuJ3/d2FsPtFZ9YHDoeKDAEcWdRaDJXNnvgAADa TppYNRcvNk2xcuudyhczFpFH59Uj7OGsdi+i/SCx6fqWnxazyMWCzY=; X-MDAV-Processed: mail.consulintel.es, Thu, 21 Sep 2017 18:03:19 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 21 Sep 2017 18:03:16 +0200 Received: from [45.6.251.164] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005562332.msg for ; Thu, 21 Sep 2017 18:03:15 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170921:md50005562332::UeVTCOSHJ72nhY5I:00000DKS X-MDRemoteIP: 45.6.251.164 X-Return-Path: prvs=14370a98a6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Thu, 21 Sep 2017 13:03:09 -0300 From: JORDI PALET MARTINEZ To: Message-ID: <9AE0D6C9-56DC-4B52-8F29-C4B3991D0D1A@consulintel.es> Thread-Topic: reclassify 464XLAT as standard instead of info Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 16:03:25 -0000 And I can confirm it works, tested many times in different networks, many d= ifferent devices. Saludos, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Ca By Responder a: Fecha: jueves, 21 de septiembre de 2017, 12:21 Para: Alexandre Petrescu , Owen DeLong CC: Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/= 3.3] Re: reclassify 464XLAT as standard instead of info =20 On Thu, Sep 21, 2017 at 8:04 AM Alexandre Petrescu wrote: =20 =20 Le 21/09/2017 =C3=A0 16:49, Owen DeLong a =C3=A9crit : [...] > CLAT and DHCP can co-exist on the same network. =20 This is not shown anywhere. =20 I tell you they dont, and they will not. =20 Alex =20 =20 OpenWrt / LEDE supports both CLAT and dhcpv6-pd =20 https://forum.openwrt.org/viewtopic.php?id=3D59528 =20 =20 =20 =20 =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Sep 21 09:04:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1946F1331E3 for ; Thu, 21 Sep 2017 09:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usQ8IxLl6zp2 for ; Thu, 21 Sep 2017 09:04:26 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469F713247A for ; Thu, 21 Sep 2017 09:04:26 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CE427AF; Thu, 21 Sep 2017 18:04:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506009863; bh=Q+ggmCFNUUOk7XyJG4OTOsL1e4DReynMkbMosD0iIPE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=3dK2YDZaN9IeJEuUQDo0m/DaDQe0C4fz8fcGMgCreaKMNWDUowsVheZxRgDgaa4fI 4wRI08+Uv/M0sLEpjWXSyIFMI0zLkxqe7wyfYb1BmL/7IyP8wyHzrv3VGy2yS0oo6j fiRvbPRLQaPo6tHCxSSJPKnU9OLu3G5GcSAIBYWs= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CC27D84; Thu, 21 Sep 2017 18:04:23 +0200 (CEST) Date: Thu, 21 Sep 2017 18:04:23 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Ca By , Owen DeLong , v6ops@ietf.org In-Reply-To: <31cb26f1-3fbf-fcc6-3948-3878a4b792bb@gmail.com> Message-ID: References: <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <3F99667F-56A6-487E-9AA6-D0FCB0BB4450@employees.org> <96c18643-e391-e9c7-7d23-e90bc4827c2d@gmail.com> <31cb26f1-3fbf-fcc6-3948-3878a4b792bb@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 16:04:28 -0000 On Thu, 21 Sep 2017, Alexandre Petrescu wrote: > Good, but have you tried OpenWRT CLAT and dhcpv6-pd on cellular at the > same time? I tell you they dont run together neither on OpenWRT nor > anywhere else. > > If you claim otherwise: please tell me the modem name, manufacturer. There is nothing in the standards that tell us these can't be used together. What you're talking about is an implementation problem, not a standardisation problem. Just because current modem implementations do the wrong thing doesn't mean this can't work. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 21 09:06:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE010132125 for ; Thu, 21 Sep 2017 09:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaEe-HGZdFXA for ; Thu, 21 Sep 2017 09:06:26 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E00013247A for ; Thu, 21 Sep 2017 09:06:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8LG6ONE014116 for ; Thu, 21 Sep 2017 18:06:24 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6083020F183 for ; Thu, 21 Sep 2017 18:06:24 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 56EEB20F152 for ; Thu, 21 Sep 2017 18:06:24 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8LG6NVY029576 for ; Thu, 21 Sep 2017 18:06:24 +0200 To: v6ops@ietf.org References: <9AE0D6C9-56DC-4B52-8F29-C4B3991D0D1A@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Thu, 21 Sep 2017 18:06:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <9AE0D6C9-56DC-4B52-8F29-C4B3991D0D1A@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 16:06:29 -0000 And I ask you again: what modem was that? Alex Le 21/09/2017 à 18:03, JORDI PALET MARTINEZ a écrit : > And I can confirm it works, tested many times in different networks, many different devices. > > Saludos, > Jordi > > > -----Mensaje original----- > De: v6ops en nombre de Ca By > Responder a: > Fecha: jueves, 21 de septiembre de 2017, 12:21 > Para: Alexandre Petrescu , Owen DeLong > CC: > Asunto: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info > > > On Thu, Sep 21, 2017 at 8:04 AM Alexandre Petrescu wrote: > > > Le 21/09/2017 à 16:49, Owen DeLong a écrit : > [...] > > CLAT and DHCP can co-exist on the same network. > > This is not shown anywhere. > > I tell you they dont, and they will not. > > Alex > > > OpenWrt / LEDE supports both CLAT and dhcpv6-pd > > https://forum.openwrt.org/viewtopic.php?id=59528 > > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Sep 21 13:39:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CD0133072 for ; Thu, 21 Sep 2017 13:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWgTjZNcVoMD for ; Thu, 21 Sep 2017 13:39:29 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B32133065 for ; Thu, 21 Sep 2017 13:39:29 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id j16so4148044pga.1 for ; Thu, 21 Sep 2017 13:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qO6wMSugkbRntEp5VAio9HA1gnDfNIhGnDEComCH3Ok=; b=tDoOQLZlyswWKYwPFdT+FWN6P/y0UcgPDHcy+b3rmDPJmOufpnmrlh28f6LPbXr1aA W8rDOotCoSNR8g5AdpKPPK3kp0U8O3Ku9WbbDQBbaS7Wxj+7miol/RAPnMa9pau34BBD bkvQjeWPpSxSd7XVRT3/9wLSsmBOlPXyKImXwYycqTcQwcKZcsVdOwpozNgKStKWO0t3 FZTMzMyVJvX/BNgKHzKOqCjrUjg51h48LCqkTcZTkpeOtNqR2taXHEt7wxBfbcBqu9B0 3OssnyTNlCLeDKkPx80yabtQUTap9qKBBnqJgcMTzjbqVNd0ArEQwExT1KgJNAkTUjdo Spgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=qO6wMSugkbRntEp5VAio9HA1gnDfNIhGnDEComCH3Ok=; b=l6UVYd3i0wfRmp/VC7fv81DeWaQPSlXceep+tyXfI/7wcV/oZzJVk1gCOi7h5H1DVR kUH/kT6VzOvWAJyX7rnnzjiVRpIpzRf4NyxLERA4CdFGkQVXNZKYAyo0EbQl+ShEj87s 8bFMHD0G8f77XE1JUSoOcYonoePfutuNlrmkTObeg3q+JvWt8eHzfDxaKcon+w2TYm1K ulGGvE1h7Rv4TevWqfZ7rkrtmT56r2AQbJrxCentQEaxkrg4fgvSWMxooIMJ29AN7Z7w EuOjc5826pz913YZuRHooHvBiJuD1SpcpUqimz3WvzxVvYKk39RkjhawV4wQDsFlIV0v Ks7g== X-Gm-Message-State: AHPjjUj5yhg4IfwU3sC/6a5oDLW0SzEdFFJt8D4FBfr/SdbH18zXYJDk L4yhNkYMskjW/Ror1qzQjxwdOw== X-Google-Smtp-Source: AOwi7QAtcoNpJPkSY4dSIIdf1d2TYAQceXtvNtjB9WrvH6Itgyl67bRCUx66pw68H95V2gUuwiqYTQ== X-Received: by 10.99.96.10 with SMTP id u10mr7000515pgb.370.1506026368222; Thu, 21 Sep 2017 13:39:28 -0700 (PDT) Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s81sm5314685pfg.162.2017.09.21.13.39.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Sep 2017 13:39:27 -0700 (PDT) To: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 22 Sep 2017 08:39:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 20:39:31 -0000 On 21/09/2017 20:05, Ole Troan wrote: >>>>> From my perspective, there are multiple interoperable specs. We hav= e several CLAT client implementations/vendors, from different vendors, an= d they work fine in the same and different operators and interoperate wit= h different NAT64 and DNS64 vendors/implementations. >>>> >>>> What I=E2=80=99m not sure is, because 464XLAT is basically RFC6145 (= SIIT) + RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which = are already Standards track, if we need also to move them to STD in that = case, etc. >>> >>> I'll repeat myself earlier. Looking at the definitions of the terms, = there is no reason it can't or shouldn't be BCP, which our charter does a= llow us to do, and which is a one-shot standard more appropriate to the c= ase (IMHO). If you want it to be a standardard, a BCP is a standard. Let'= s advance it to BCP. >> >> I think there=E2=80=99s an argument for this. >> >> But there will be people who will argue that encapsulation is the =E2=80= =98best=E2=80=99 practice. Is there scope for a BCP by translation and a= BCP by encapsulation? Or would the BCP say NAT64/DNS64/464XLAT is the b= est way to serve nodes in an IPv6-only network? >> >> With IPv4 NAT, the IETF didn=E2=80=99t define specific NAT mechanisms,= so we ended up with many varieties, with different properties. There=E2=80= =99s an argument also I think to nail down one single best translation ap= proach. >=20 > Yes, I do wonder in what alternate universe the IETF consensus is that = best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-) We have a problem in that people confuse "a standard" with "the standard"= and "a best current practice" with "the best current prcatice". But in the en= d that's just a matter of wording in the Abstract and Introduction. We say: if you= want to run a pure IPv6 network service while supporting IPv4-only clients and= servers, and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a good wa= y to do it. That does sound like a BCP to me. Brian From nobody Thu Sep 21 13:47:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86F31330B3 for ; Thu, 21 Sep 2017 13:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 1CduvDEb4PvD for ; Thu, 21 Sep 2017 13:47:12 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A6F133187 for ; Thu, 21 Sep 2017 13:47:11 -0700 (PDT) Received: from [192.168.10.119] (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id B04AD2D5060; Thu, 21 Sep 2017 20:47:09 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-BDC38B8D-094F-40D1-B461-D7A593BB1BB6 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15A372) In-Reply-To: Date: Thu, 21 Sep 2017 22:47:05 +0200 Cc: v6ops@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <2423DC8E-DE6A-4B81-8969-C7A7DDD74126@employees.org> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> To: Brian E Carpenter Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 20:47:14 -0000 --Apple-Mail-BDC38B8D-094F-40D1-B461-D7A593BB1BB6 Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable > On 21 Sep 2017, at 22:39, Brian E Carpenter w= rote: >=20 > On 21/09/2017 20:05, Ole Troan wrote: >>>>>> =46rom my perspective, there are multiple interoperable specs. We hav= e several CLAT client implementations/vendors, from different vendors, and t= hey work fine in the same and different operators and interoperate with diff= erent NAT64 and DNS64 vendors/implementations. >>>>>=20 >>>>> What I=81fm not sure is, because 464XLAT is basically RFC6145 (SIIT) += RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are alread= y Standards track, if we need also to move them to STD in that case, etc. >>>>=20 >>>> I'll repeat myself earlier. Looking at the definitions of the terms, th= ere is no reason it can't or shouldn't be BCP, which our charter does allow u= s to do, and which is a one-shot standard more appropriate to the case (IMHO= ). If you want it to be a standardard, a BCP is a standard. Let's advance it= to BCP. >>>=20 >>> I think there=81fs an argument for this. >>>=20 >>> But there will be people who will argue that encapsulation is the =81ebe= st=81f practice. Is there scope for a BCP by translation and a BCP by encap= sulation? Or would the BCP say NAT64/DNS64/464XLAT is the best way to serve= nodes in an IPv6-only network? >>>=20 >>> With IPv4 NAT, the IETF didn=81ft define specific NAT mechanisms, so we e= nded up with many varieties, with different properties. There=81fs an argume= nt also I think to nail down one single best translation approach. >>=20 >> Yes, I do wonder in what alternate universe the IETF consensus is that be= st current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-) >=20 > We have a problem in that people confuse "a standard" with "the standard" a= nd > "a best current practice" with "the best current prcatice". But in the end= that's > just a matter of wording in the Abstract and Introduction. We say: if you w= ant > to run a pure IPv6 network service while supporting IPv4-only clients and s= ervers, > and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a good way= to do it. >=20 > That does sound like a BCP to me. Quite the contrary.=20 =81gDo not wish to...=81h isn=81ft a qualifier for deciding if this is what t= he community considers best current practice.=20 Rfc2026 does actually say: The BCP subseries of the RFC series is designed to be a way to standardize p= ractices and the results of community deliberations. A BCP document is subje= ct to the same basic set of procedures as standards track documents and thus= is a vehicle by which the IETF community can define and ratify the communit= y's best current thinking on a statement of principle or on what is believed= to be the best way to perform some operations or IETF process function. Ole= --Apple-Mail-BDC38B8D-094F-40D1-B461-D7A593BB1BB6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 21 Se= p 2017, at 22:39, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On 21/09/2017 20:05, Ole Troan wrote:
=
=46rom my perspe= ctive, there are multiple interoperable specs. We have several CLAT client i= mplementations/vendors, from different vendors, and they work fine in the sa= me and different operators and interoperate with different NAT64 and DNS64 v= endors/implementations.
<= blockquote type=3D"cite">

What I=E2=80=99m not sure is, because 464XLAT is basically RFC6145 (SIIT) += RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are alread= y Standards track, if we need also to move them to STD in that case, etc.
<= br>
I'll repeat myself earlier= . Looking at the definitions of the terms, there is no reason it can't or sh= ouldn't be BCP, which our charter does allow us to do, and which is a one-sh= ot standard more appropriate to the case (IMHO). If you want it to be a stan= dardard, a BCP is a standard. Let's advance it to BCP.

I think there=E2=80=99s an argument for this.

But there will be people who will argue t= hat encapsulation is the =E2=80=98best=E2=80=99 practice.  Is there sco= pe for a BCP by translation and a BCP by encapsulation?  Or would the B= CP say NAT64/DNS64/464XLAT is the best way to serve nodes in an IPv6-only ne= twork?

With IPv4 NAT, the IETF didn=E2=80= =99t define specific NAT mechanisms, so we ended up with many varieties, wit= h different properties. There=E2=80=99s an argument also I think to nail dow= n one single best translation approach.
=

Yes, I do wonder in what alternate universe the IETF consensus i= s that best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-)

We have a problem in that peopl= e confuse "a standard" with "the standard" and
"a best curre= nt practice" with "the best current prcatice". But in the end that's<= br>just a matter of wording in the Abstract and Introduction. We say: i= f you want
to run a pure IPv6 network service while supporti= ng IPv4-only clients and servers,
and do not wish to use any= form of IPv4-in-IPv6 tunnel, here is a good way to do it.
<= /span>
That does sound like a BCP to me.

Quite the contrary. 
=E2=80=9CDo not wish to...=E2= =80=9D isn=E2=80=99t a qualifier for deciding if this is what the community c= onsiders best current practice. 

Rfc2026 does a= ctually say:
The BCP subseries of the RFC series is designed to b=
e a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

Ole
= --Apple-Mail-BDC38B8D-094F-40D1-B461-D7A593BB1BB6-- From nobody Thu Sep 21 15:33:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A2C126E64 for ; Thu, 21 Sep 2017 15:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brFsJw6KD00L for ; Thu, 21 Sep 2017 15:33:11 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E6F120724 for ; Thu, 21 Sep 2017 15:33:11 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id AE2E734B3FD; Thu, 21 Sep 2017 22:33:08 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 91733160036; Thu, 21 Sep 2017 22:33:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 70EF5160086; Thu, 21 Sep 2017 22:33:08 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 37flt48992kI; Thu, 21 Sep 2017 22:33:08 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 0C985160036; Thu, 21 Sep 2017 22:33:08 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B72A8878E716; Fri, 22 Sep 2017 08:33:05 +1000 (AEST) To: Brian E Carpenter Cc: v6ops@ietf.org From: Mark Andrews References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> In-reply-to: Your message of "Fri, 22 Sep 2017 08:39:34 +1200." Date: Fri, 22 Sep 2017 08:33:05 +1000 Message-Id: <20170921223305.B72A8878E716@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 22:33:14 -0000 In message , Brian E Carpenter w rites: > On 21/09/2017 20:05, Ole Troan wrote: > >>>>> From my perspective, there are multiple interoperable specs. We > have several CLAT client implementations/vendors, from different vendors, > and they work fine in the same and different operators and interoperate > with different NAT64 and DNS64 vendors/implementations. > >>>> > >>>> What Im not sure is, because 464XLAT is basically RFC6145 (SIIT) + > RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are > already Standards track, if we need also to move them to STD in that > case, etc. > >>> > >>> I'll repeat myself earlier. Looking at the definitions of the terms, > there is no reason it can't or shouldn't be BCP, which our charter does > allow us to do, and which is a one-shot standard more appropriate to the > case (IMHO). If you want it to be a standardard, a BCP is a standard. > Let's advance it to BCP. > >> > >> I think theres an argument for this. > >> > >> But there will be people who will argue that encapsulation is the best > practice. Is there scope for a BCP by translation and a BCP by > encapsulation? Or would the BCP say NAT64/DNS64/464XLAT is the best way > to serve nodes in an IPv6-only network? > >> > >> With IPv4 NAT, the IETF didnt define specific NAT mechanisms, so we > ended up with many varieties, with different properties. Theres an > argument also I think to nail down one single best translation approach. > > > > Yes, I do wonder in what alternate universe the IETF consensus is that > best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-) > > We have a problem in that people confuse "a standard" with "the standard" > and > "a best current practice" with "the best current prcatice". But in the > end that's > just a matter of wording in the Abstract and Introduction. We say: if you > want > to run a pure IPv6 network service while supporting IPv4-only clients and > servers, > and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a good > way to do it. I'd argue it is a "way to do it". Good is not a adjective I'd apply to it as it has lots of side effects that impact others that are NOT using it the same way as NAT impacts every developer that uses IPv4. Because 464XLAT is almost always deployed with DNS64 (there are potentially other ways to learn the address mappings): YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING TERMINATED ON A IPV6 NODE. This restricts what you can do with that connection. This impacts on EVERY developer. DNS64/NAT64 and 464XLAT needs to die and the earth needs to be salted where they are buried. They are not like NAT44 where there no other viable alternative. There are plenty of alternatives. Mark > That does sound like a BCP to me. > > Brian > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Sep 21 21:44:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975C6133075 for ; Thu, 21 Sep 2017 21:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6axYJHc8txJ for ; Thu, 21 Sep 2017 21:44:00 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8883F133071 for ; Thu, 21 Sep 2017 21:44:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8M4hwdZ108394 for ; Fri, 22 Sep 2017 06:43:58 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3ACE12014DA for ; Fri, 22 Sep 2017 06:43:58 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 31128200FA0 for ; Fri, 22 Sep 2017 06:43:58 +0200 (CEST) Received: from [132.166.84.3] ([132.166.84.3]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8M4hvbq015128 for ; Fri, 22 Sep 2017 06:43:57 +0200 To: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> From: Alexandre Petrescu Message-ID: <61549b08-a85d-cf88-3a61-69e67480333d@gmail.com> Date: Fri, 22 Sep 2017 06:43:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 04:44:04 -0000 Le 21/09/2017 à 22:39, Brian E Carpenter a écrit : > On 21/09/2017 20:05, Ole Troan wrote: >>>>>> From my perspective, there are multiple interoperable specs. We have several CLAT client implementations/vendors, from different vendors, and they work fine in the same and different operators and interoperate with different NAT64 and DNS64 vendors/implementations. >>>>> >>>>> What I’m not sure is, because 464XLAT is basically RFC6145 (SIIT) + RFC6146 (Stateful NAT64) and also can use RFC6147 (DNS64), which are already Standards track, if we need also to move them to STD in that case, etc. >>>> >>>> I'll repeat myself earlier. Looking at the definitions of the terms, there is no reason it can't or shouldn't be BCP, which our charter does allow us to do, and which is a one-shot standard more appropriate to the case (IMHO). If you want it to be a standardard, a BCP is a standard. Let's advance it to BCP. >>> >>> I think there’s an argument for this. >>> >>> But there will be people who will argue that encapsulation is the ‘best’ practice. Is there scope for a BCP by translation and a BCP by encapsulation? Or would the BCP say NAT64/DNS64/464XLAT is the best way to serve nodes in an IPv6-only network? >>> >>> With IPv4 NAT, the IETF didn’t define specific NAT mechanisms, so we ended up with many varieties, with different properties. There’s an argument also I think to nail down one single best translation approach. >> >> Yes, I do wonder in what alternate universe the IETF consensus is that best current practice is NAT44 -> NAT46 -> NAT64 + DNS64. ;-) > > We have a problem in that people confuse "a standard" with "the standard" and > "a best current practice" with "the best current prcatice". But in the end that's > just a matter of wording in the Abstract and Introduction. We say: if you want > to run a pure IPv6 network service while supporting IPv4-only clients and servers, > and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a good way to do it. > > That does sound like a BCP to me. I could agree if it were "ABCP" for _a_ BCP. But I am afraid in English you cant say "a Best", there is only "one Best" and maybe "a Better". WE dont say several "Bests". You may know better, though. Alex > > Brian > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Sep 21 22:58:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AC6134217 for ; Thu, 21 Sep 2017 22:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aplwvBLtl6Lb for ; Thu, 21 Sep 2017 22:58:39 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0895133323 for ; Thu, 21 Sep 2017 22:58:38 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id m127so775245wmm.3 for ; Thu, 21 Sep 2017 22:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/PTkpQr2xe6qIfTz0wT/e0U/FLDvq8XioHHld5D85vs=; b=ZRyoxblNdG942Ni5Mnw9DfJyp16PkUu8Y04E2+seK+JNZjUt1kbgGFtHHIKSYeMHLz BnNpeffKnY8OJn24zXABpg3euq+lJQn0no4meO9oe8uVVagXgfnhyt/GgJbHRSXt+ghT fMJIVQ6ozPNjNVwiNyGXhwsMEvNKbu4DILbDfJAW/zhTpzO/nrE4f6ZUrc432MSAOD0E eo61/zeDXHsKuUbBP/ZRny2RKW4S/3TS6UW1wFiOhgAcM2oMlBHn2q4UFAYunV9Xv5BJ wkIrhimrAsn8aO2zBlHCNr/VLpyUPb4IE2WYYy3IKiKFzu4YmDuZf0c4A0sni+JyOs+q NHxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/PTkpQr2xe6qIfTz0wT/e0U/FLDvq8XioHHld5D85vs=; b=CIvn9a4gZGv9speTBFYlMTHKOaKxV2wihmvl3xs1RhSMDiKJOusR6rtXqwjT09PJNZ RzaR72fNivt5tVppWRNo2qqMBezMpFRO+Xl2wHSevGaTW5tkZXo0OQIGvPbUkH6fGtSP wpU0Mgq5rhRO8df6Sfig1h48H0iHp+sJBUqk7cCprGjyRT1oZnVPWg92E5y0lo9HzyCe TgZ0896An2YEZ8ENlHmBX84bI5/Itav2O5pW8xBjVUtaRapOUDVHWg/FgnRFP1xXxYWq SLz5mOm3rlbgo3q3Oq/ruClQ/5BGwUOwDGMF5rLBfJUz+wqc4rTHi1u4YviWxmdkvUOw gsVQ== X-Gm-Message-State: AHPjjUiJe/bMUbq2yy2PzZf6R1EJ6F6okwcK890B61ZQ6fFljN988UXk Ivh2xO951ZBNPeqejNL1gshgyPPgjNg2IsMdrlbXSw== X-Google-Smtp-Source: AOwi7QDWJIW8A9vg/sVitiJggbTg31rrHBOdR2LJocj3pl9bcD3UMUXoCk4kH7Eslm0GTVZPSUoRSJWMktmcSH4hUX4= X-Received: by 10.28.64.6 with SMTP id n6mr3014349wma.61.1506059916996; Thu, 21 Sep 2017 22:58:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Thu, 21 Sep 2017 22:58:15 -0700 (PDT) In-Reply-To: <20170921223305.B72A8878E716@rock.dv.isc.org> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> From: Erik Kline Date: Fri, 22 Sep 2017 14:58:15 +0900 Message-ID: To: Mark Andrews Cc: Brian E Carpenter , "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114b32ec645e0f0559c0e652" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 05:58:41 -0000 --001a114b32ec645e0f0559c0e652 Content-Type: text/plain; charset="UTF-8" > I'd argue it is a "way to do it". Good is not a adjective I'd apply > to it as it has lots of side effects that impact others that are > NOT using it the same way as NAT impacts every developer that uses > IPv4. > > Because 464XLAT is almost always deployed with DNS64 (there are > potentially other ways to learn the address mappings): > > YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING > TERMINATED ON A IPV6 NODE. This restricts what you can do with > that connection. This impacts on EVERY developer. This is a good point. Apps that connect to an IPv4-only destination via DNS64/NAT64 won't know that they cannot, for example, pass an IPv6 address as a useful reference/token. If they could discover/be told the DNS64 prefix then app could figure this out for themselves, but that is indeed unwanted complexity. Note that with 464xlat/clat in theory this problem could be avoided in the case where IPv4 literals are used (without a getaddrinfo trick that returns AAAAs for IPv4 literals, of course ;-). Nevertheless, this isn't all that helpful. > DNS64/NAT64 and 464XLAT needs to die and the earth needs to be > salted where they are buried. They are not like NAT44 where there > no other viable alternative. There are plenty of alternatives. We'll see if folks (specifically mobile operators--the bulk of NAT64/DNS64 deployment) deploy DS-Lite or MAP-E... --001a114b32ec645e0f0559c0e652 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgR6Wtt4nAYeO/D5gsNAvPLguhU9mwlmTF 7HAi+d+9+aQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTIy MDU1ODM3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAD/+gRsOwQDtjl7rA3Mw+frn+7Eq0mX3tn+QwomLjT/BuGWYrBRR w4FxxZT/v2O8zTQ/hnVBo2G3Mq6g6AR+Enk9OKDdB5wdP1uGUo+dmwu8+biN5X7GiN6IaABiGQje cOCXZa+1z4yCq0e8acUTZ8fKDR3dU25wqmY9gjD50kZ74XRT/FqKPPhRBjdiV7OU8XoocSPsq9Uy m3wlHx+O3pqKzDooi9Eq31VIsuHk9cS26DqUMYauJCf7/HoEigixNTFDlgNsZmnEncyZXVc+T3Wu glidhCaHGTjgfFMwKhgdgMXrHYMfY8a4vEsdaVkXE1p4E2IsIKWIRTa9qGsaexQ= --001a114b32ec645e0f0559c0e652-- From nobody Thu Sep 21 23:18:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5F2132981 for ; Thu, 21 Sep 2017 23:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 HWfCgzUkbw9J for ; Thu, 21 Sep 2017 23:18:07 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D07D126DFE for ; Thu, 21 Sep 2017 23:18:07 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id v36so871598ioi.1 for ; Thu, 21 Sep 2017 23:18:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RbNQbpIL8P3RIPnxl/TGQXhXaonBj7POYEWIMwxX0TY=; b=uxXI6qDMdB4J9RTFv2LWArL+haPgardLbSFNRK8kquIV+5YGrvYX8wQNBqLGUBN9Zo G6kc/hxglzSrQDUBsHLZR/18cAcxU1RzwKQRzwVpzRUGh5frc87d929kBbVWQzR7unih rUm8pYnZPxRHNdSI1cUtezZNVepK1e+vha1kuoV/HJqrz9MTUluh+re153WuP3Q4cfNI umTfJbu+eG6bj9pNsDc8NzFllAH9Ay7CXQQeyvahoGTGFonuLgGAIolusipY8sw5mpq9 +SyL2s2nqBeen9+eQ4bdfedonpItF7nagc8O5Dn6bkuGBojThxWcaE7WtxNdI9gWLGce NquQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RbNQbpIL8P3RIPnxl/TGQXhXaonBj7POYEWIMwxX0TY=; b=q9ZZUC1iuc4yYIMW+MA7fWL88QL1nyzxoWSVA8EpZWsu0WgQfDd9jATONcz2AOIY05 ZvvL0SSaIAiuo1IRntCWOp0DsDeLD2mGRsjGOssS5XPRg16M/eTLqQwrvSgDDiLo3m6+ waWNBmaEttRWPI7LmJOzriy7yLPW83vkj+PRJUG4zgpSGqLjWlcS9KILQ96cxnSgYCGP g1C0LGW1y8G0o/KcM0Xxf2ds3Znoab6Ea1wRJdaKzjZvWQhsr0NLfqMFwny+YFs2DVPK 2BxrNxHNrE19/Z17PZ1yRLQrBFh+/7Kf3opAfhyqa7a1GW+z1gZ6o52lywOUQyar5oCL sw/Q== X-Gm-Message-State: AHPjjUjWi0jgKjfV/fihUmKiR1UybWfLk3bY9A0+aN6XXT7JTAdwaT/L m3XOqsxI5gWG6p2bxaN1Y9efHEyyNN4dVBASUKFvQA== X-Google-Smtp-Source: AOwi7QBvDt9emTgDMKvEM9eA0xcpY/Inlje5a9ed/BOjWfuQnkwinGH2sRnm+J4vHu8OF8s8Fd8H6JBhqHcgTA8rLy4= X-Received: by 10.107.52.205 with SMTP id b196mr6710511ioa.4.1506061086513; Thu, 21 Sep 2017 23:18:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Thu, 21 Sep 2017 23:17:45 -0700 (PDT) In-Reply-To: <20170921223305.B72A8878E716@rock.dv.isc.org> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> From: Lorenzo Colitti Date: Fri, 22 Sep 2017 15:17:45 +0900 Message-ID: To: Mark Andrews Cc: Brian E Carpenter , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a114410cc12b0660559c12c2d" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 06:18:08 -0000 --001a114410cc12b0660559c12c2d Content-Type: text/plain; charset="UTF-8" On Fri, Sep 22, 2017 at 7:33 AM, Mark Andrews wrote: > Because 464XLAT is almost always deployed with DNS64 (there are > potentially other ways to learn the address mappings): > > YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING > TERMINATED ON A IPV6 NODE. > Why don't you? All you need to do is compare the destination address with the NAT64 prefix. If it's in that prefix, then it's an IPv4 node, otherwise it's an IPv6 node. --001a114410cc12b0660559c12c2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Sep 22, 2017 at 7:33 AM, Mark Andrews <marka@isc.org> wrote:=
Because 464XLAT is almost always deploye= d with DNS64 (there are
potentially other ways to learn the address mappings):

YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING
TERMINATED ON A IPV6 NODE.

Why don'= t you? All you need to do is compare the destination address with the NAT64= prefix. If it's in that prefix, then it's an IPv4 node, otherwise = it's an IPv6 node.
--001a114410cc12b0660559c12c2d-- From nobody Fri Sep 22 00:07:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240E9132932 for ; Fri, 22 Sep 2017 00:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNt5pjtqbFyJ for ; Fri, 22 Sep 2017 00:07:25 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D3B1252BA for ; Fri, 22 Sep 2017 00:07:25 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id F3F4734B072; Fri, 22 Sep 2017 07:07:22 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E0CE7160074; Fri, 22 Sep 2017 07:07:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CE4B7160042; Fri, 22 Sep 2017 07:07:22 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id E9qdwRJe4A_f; Fri, 22 Sep 2017 07:07:22 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7F865160031; Fri, 22 Sep 2017 07:07:22 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 74AA687A424E; Fri, 22 Sep 2017 17:07:19 +1000 (AEST) To: Lorenzo Colitti Cc: Brian E Carpenter , "v6ops@ietf.org WG" From: Mark Andrews References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> In-reply-to: Your message of "Fri, 22 Sep 2017 15:17:45 +0900." Date: Fri, 22 Sep 2017 17:07:19 +1000 Message-Id: <20170922070719.74AA687A424E@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 07:07:27 -0000 In message , Lorenzo Colitti writes: > On Fri, Sep 22, 2017 at 7:33 AM, Mark Andrews wrote: > > > Because 464XLAT is almost always deployed with DNS64 (there are > > potentially other ways to learn the address mappings): > > > > YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING > > TERMINATED ON A IPV6 NODE. > > > > Why don't you? All you need to do is compare the destination address with > the NAT64 prefix. If it's in that prefix, then it's an IPv4 node, otherwise > it's an IPv6 node. Thank you for proving my point. IPv6 applications need to add code to WORKAROUND breakages caused by NAT64 the way they need add WORKAROUNDS for the NAT breakages even if they are not using NAT64 or NAT respectively. The cancer that is NAT64 needs to be eradicated. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Sep 22 00:09:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544C41342A8 for ; Fri, 22 Sep 2017 00:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 x0djvBwJyfmc for ; Fri, 22 Sep 2017 00:09:33 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775311342A6 for ; Fri, 22 Sep 2017 00:09:33 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id l39so194587wrl.12 for ; Fri, 22 Sep 2017 00:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M0QnWPv/GivuAf1MhhwCfQRYb5BBhpOq0RrkuVUioIs=; b=awHeiKT9c6A0cgX+LQ5Ykk28rJaRD46ibPw7WKGYJtIV39/vHBoKPs9GD1FhHJhrZw kAa8aVblgBQvrzFEHEY0o7k8oAQWBjTSRVx9JsXP/HogQ5+i9BYgLTQXSgpjLpcQ9C/D X3rjId4AgDAhyvSVDx6Jx5YU5ynBYXIpoA4L8ybdHVgZMQnbU6J8P8c5KW1k5mguko0A bsMfcSBRjAmoT7GuhcaUnO4MyOTH5p1oSGlcJuBgxtl+9US8jc6YAhRn1TiuUJWPUIaW hK3Dy+RIfGh71yWsjj/s/VXkeyUiatUwnaxCDzjESBGY57wfBWXYL8d+Ycoqs89LDRVU fVyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M0QnWPv/GivuAf1MhhwCfQRYb5BBhpOq0RrkuVUioIs=; b=bTJ1DZoITseSVhZadPwi/ZRLmNMhVIa4HtUBZ7C6dIQ5wvirPvQkIhLakOx7ZLyT81 hqQktKWxTd/6YBgbiVQM8nXi5wHgANvA9FoSf2XW9XH83CpwdDk9X0mZT1M1xGWmwc2J qWBW70WsP0kpbTxp8nkOA50YN52UPzP5S5Uu8gtgsYJ7TrXIOVorRsxUL4PeB+NLZleF 62nKvTfb+JuEKOeYFFqCkFT3ejcfJw2X8LSahcy6i6HbtwMwmEM2BL4RpI4nnoQNJixC dIHXYrl8Ju09VpAipjspbayPhJuLBDoh3f2JUPsMAEdlV5ZF4eFfweYH11u5e2yrhS5h 3YHQ== X-Gm-Message-State: AHPjjUjsoiDNc0LyOakcfrI4F6rZ8MWNjhdXyFfH8a88fC402tudFfrn i1V1IdoCI68S3VzoBrjwwFuT4tBxNYphmR+hEi/XoA== X-Google-Smtp-Source: AOwi7QBYVzqmBwL1O3yJazoXkNO7KPhoGQJPYWxrdzxSFtE9KFwzykaeHHqtSYtZkFJOZjWhwY4ELlGj7OGNSG0nXa8= X-Received: by 10.223.176.46 with SMTP id f43mr4159856wra.206.1506064171758; Fri, 22 Sep 2017 00:09:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Fri, 22 Sep 2017 00:09:10 -0700 (PDT) In-Reply-To: <20170922070719.74AA687A424E@rock.dv.isc.org> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> From: Erik Kline Date: Fri, 22 Sep 2017 16:09:10 +0900 Message-ID: To: Mark Andrews Cc: Lorenzo Colitti , "v6ops@ietf.org WG" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11438d5afd69690559c1e330" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 07:09:35 -0000 --001a11438d5afd69690559c1e330 Content-Type: text/plain; charset="UTF-8" On 22 September 2017 at 16:07, Mark Andrews wrote: > > In message , Lorenzo Colitti writes: >> On Fri, Sep 22, 2017 at 7:33 AM, Mark Andrews wrote: >> >> > Because 464XLAT is almost always deployed with DNS64 (there are >> > potentially other ways to learn the address mappings): >> > >> > YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING >> > TERMINATED ON A IPV6 NODE. >> > >> >> Why don't you? All you need to do is compare the destination address with >> the NAT64 prefix. If it's in that prefix, then it's an IPv4 node, otherwise >> it's an IPv6 node. > > Thank you for proving my point. > > IPv6 applications need to add code to WORKAROUND breakages caused > by NAT64 the way they need add WORKAROUNDS for the NAT breakages > even if they are not using NAT64 or NAT respectively. The cancer > that is NAT64 needs to be eradicated. Sounds more like the cancer that is IPv4 is what needs eradicating... --001a11438d5afd69690559c1e330 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgqj30EDGRve2d2prsBzxwRPFiQunouv0z mGY4rZbAlmQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTIy MDcwOTMyWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBACz5L9G7M5i66KDqwBlZ13nhrzYrBftgK14cacbKofWrCFU3M5gR 0xnVBQKOqpEpdcrOMuz78i8xdLNqSAxKcZQtAz4lVDxDgVB/1xUChXaD4aVNoOPMb28q0pH2kvIV 5OpwBEjhkBztZ0Dd4v8kt6RrdncPTtWcbR+qpEaMTQ9S7zsqsXAt5kdzqMOKUGNePcrFEWTxZMGL oMnFH4L0+lAPB+zDDs/dQ0qRq5wsdgmDHxwfhQqvUxredUbfSZKnKEXaHUbo+gBN2zdp6yi+jMh6 Ib7vLD05e/AjBFpSjYNznrdZDVZw8PAHq9EqQOh6TXZuVN4m1sPhqKsiJI1mslw= --001a11438d5afd69690559c1e330-- From nobody Fri Sep 22 00:22:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE811342CA for ; Fri, 22 Sep 2017 00:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pTf3jxfvpJP0 for ; Fri, 22 Sep 2017 00:22:22 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34FE8133187 for ; Fri, 22 Sep 2017 00:22:22 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 6698E2D4FE9; Fri, 22 Sep 2017 07:22:19 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5B14C10C4A3C2; Fri, 22 Sep 2017 09:22:17 +0200 (CEST) From: Ole Troan Message-Id: <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_6BC794F6-A100-4134-8045-BF2AC7064560"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 22 Sep 2017 09:22:15 +0200 In-Reply-To: <20170921223305.B72A8878E716@rock.dv.isc.org> Cc: Brian E Carpenter , v6ops@ietf.org To: Mark Andrews References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 07:22:24 -0000 --Apple-Mail=_6BC794F6-A100-4134-8045-BF2AC7064560 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> We have a problem in that people confuse "a standard" with "the = standard" >> and >> "a best current practice" with "the best current prcatice". But in = the >> end that's >> just a matter of wording in the Abstract and Introduction. We say: if = you >> want >> to run a pure IPv6 network service while supporting IPv4-only clients = and >> servers, >> and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a = good >> way to do it. >=20 > I'd argue it is a "way to do it". Good is not a adjective I'd apply > to it as it has lots of side effects that impact others that are > NOT using it the same way as NAT impacts every developer that uses > IPv4. >=20 > Because 464XLAT is almost always deployed with DNS64 (there are > potentially other ways to learn the address mappings): >=20 > YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING > TERMINATED ON A IPV6 NODE. This restricts what you can do with > that connection. This impacts on EVERY developer. >=20 > DNS64/NAT64 and 464XLAT needs to die and the earth needs to be > salted where they are buried. They are not like NAT44 where there > no other viable alternative. There are plenty of alternatives. =46rom the perspective of forcing every IPv6 application to have to be = able to deal with connecting to an IPv4 endpoint. Breaking DNSSEC. Requiring stateful devices in the network. I would suggest this belongs in the newly invented document category: = WCP - Worst Current Practice. Ole --Apple-Mail=_6BC794F6-A100-4134-8045-BF2AC7064560 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZxLooAAoJEL7aWKiYQt92acYP/2MU9x5/BambbIE73UJ6mc3w 3AlfGT/bE/dd2Iu+I/iRAszA0L1nxT9oXQTeqv4FzCNHsw6porxDQmSTqMmIU4Dc MYO7CQ7dBz2B+N1U1vlHiTgUjxe6mWX/pu1iUXZn0ADIr/+kMWHmjyh5t5J/9Rpd RQNAo24IwazvOjubvu80hvD0yPijWVD7iyQFabDOpac3Yvikqznng9gISNOdaAxC TGqsr4wEFNPpaTOUYiHZFOeOpinV11lbMGPvZ0L2jo7rL5t21mOUienfiEs/LU27 T8f45hE7BKSTakB2CYD1dfQJ35MBSZgl5FbYMaR8sJu7iz/iM8glxhhvMh4nRQLV PyyAACQHVMIa2gQBuBf4inQHLp2rReoLkBLSP3IrWm596sfEcEz7zT8OxONFGr/y 24PvESwxDNwctiB5MI/UcAQzGfZBTuFBOT/tWKW+L0StrXgzBajJGeC+7Pa1r5n9 DGWg8p8H3wjhDDoYBOgQS+rpZsIYFw5G9DReazHo9Gx50EJqUazliBHiDZlA0G3s /tVTqgETZZ9t27SLW35vEXzjWdxguMspApqSFC1EPCt3mpwxjoWvCiYzK5AAClQE febPEYNOuxXYxKR9TQttxpu143z81Bw/YqQCr0knjXKcMKLFjlck9n3oyagMm3a9 F3LNs65aOeOpO5mMqi4/ =dz99 -----END PGP SIGNATURE----- --Apple-Mail=_6BC794F6-A100-4134-8045-BF2AC7064560-- From nobody Fri Sep 22 04:46:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CEC134306 for ; Fri, 22 Sep 2017 04:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FAKE_REPLY_C=1.486, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhpPRiQdyu4N for ; Fri, 22 Sep 2017 04:46:29 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0111.outbound.protection.outlook.com [104.47.0.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92D0132D51 for ; Fri, 22 Sep 2017 04:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1JMJ1eP9ocqbYPHriwy9K6ug52Ke3tSrN5BF51qr82U=; b=C3lhboT67JT1rW+kzEN9LjxuruMbejvedoGVWL57NE2yw7LMQwFec3oGD7TErIv55gc5vajZx1HRYQfRC25ywHgqTMXm2Hxb4zQ/DxxjkhbNkOMdTHvDOKEEikuEFEnJe/giOgXQ4RN1qs5UmX1rFRmh6/ITFNWBDi9UbNlADx0= Received: from pc6 (109.146.128.123) by AM5PR0701MB2996.eurprd07.prod.outlook.com (2603:10a6:203:48::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 22 Sep 2017 11:46:25 +0000 Message-ID: <011901d33398$2ee547e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Fred Baker" , "JORDI PALET MARTINEZ" Cc: Date: Fri, 22 Sep 2017 12:04:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.146.128.123] X-ClientProxiedBy: DB6PR07CA0010.eurprd07.prod.outlook.com (2603:10a6:6:2d::20) To AM5PR0701MB2996.eurprd07.prod.outlook.com (2603:10a6:203:48::18) X-MS-Office365-Filtering-Correlation-Id: 50884a11-b721-47a8-7e5b-08d501af8e3f X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2996; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 3:ltMcCENQMwL/jhbAwsLpKPwT5+iqriJzCWRMFxyl9tdeHaKNG5wnQNZ9Ya1ekS/97XuZOocb2HeKMGP7b9ik9PDmltY/hdj2AZ6hqFLmwbWsILOsZCMQtN2VY//xyl1wwiSdQHJdI4W/aaTXqvKCsZPTMWEiSCiEZKAdPKG5RhrV0bc9HI7kN0bCdF7EGeWiOw6Cm/4QT+9vca3L8XW0b5A/vgw0TY/cy2+DvRWzC5KorabuDmCwUW4skn2pstIP; 25:NXEtnELqctLHf94rzabvvKCnz5G//bFUeSjy+53Gf9+vDJ9sl4DyYBdV7o/BDTLNncP2am1GocLF1owUPvvOxTrc+jVQ0LP5nEJvKU/Xhe0wg/K+5jdut6/54hbCmBvYizc0sdvT4k5CBPqKTOkXmB6iQJFg2OLtzvxbXWWt38693h0j9YkY7bTKoa/lK2ORpgE5uu5gkRMob3LMfYCQOIi0UEn9sPebq4A7o3G67SFA73RgJuBZ1FYKa0uTlZ1Ry8vSgaoFIIkL9MOpCybidXazsUDzlfVekG0uuPYS+OMl4sMbe60dxSyJnehNBjABPVCWGQsRwKq+fFKde6UB7Q==; 31:12peT5Ko6iICBwebPbM5eLnd37f+PeKnjng8hyNkBb0lhJYfg7xFciqopNMDG7ETKuXofJxGEYaINw+dVbRNWa88qxIXhl+SFj+4/Z2iCeteJSY+iHv1dvsfTwwC10CAQyWxquwguv4Pv+zz7wIR+ddcsSnIj2N+aYGOYxuOnzhJDVCSnH7X7yz50OtMZ7IEM0uvCVCFILkhAAi/kE2mdRsAgmJZo8AWGvha3xz4QgE= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM5PR0701MB2996: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 20:Nkqifmjy3jHfdntj5xTRJLzti8cJp/3SC8OBsqvtQbcywJ/w70Bt97yHOAan6sAfc71myTUH6WcQd2yyppeiUPO4hgtgYVOMgvrBxXR6viPKtTAMAF9PgBFRWNO1xEpnlKPkOh2v+YsaLPVon/TYTlnFgc+g08AIFXvz2vnts/nMr39sEd1PwfkRdEyPyWZFNCs0uOLmKMmpQ6G9OOTfcj1NgCMZv7vT58wnR6foGUHlZFDDxKGD73Y1951Ix1vsf5N97vljSc9iBr6qViOi2ea2LUdWT2Ps77hiLdjedLAOsNn6kthAAff2rXfD7zGg0ULwBgNCyRjoRtzi98Verg==; 4:jDHwccYIMLfckJLyBxjJ7JuLff/RH+zWMJ5Jo/NK7+BwqqitrypZprRzpS4BwUvqwY7y/XxzgoW+kzQZcSdWtmxjTUZBpg15HcclU+lYkkhdp0VCjjgs1Ja3VAOagZaFzhwoMvU/3mw90cioIns4qP8nbR5JsdybEzLfY6zWRA/0uzuRsrPIuN5at4HFP/3ODHB3fIcynI96VSCLCGH+VlPsWXls2XrunKYo+QAJz6XVKwhPua7/4vzBWcKNzGIYV59DvX9/S5Xl9fqm4akhsgL1Igl833O3QNt5RyyLFJY= X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(61426038)(61427038)(6041248)(20161123558100)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2996; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2996; X-Forefront-PRVS: 0438F90F17 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(377454003)(199003)(24454002)(53754006)(13464003)(189002)(44736005)(4720700003)(44716002)(47776003)(6116002)(53386004)(62236002)(316002)(16526017)(110136005)(5890100001)(2870700001)(1556002)(53546010)(6246003)(6496005)(39060400002)(25786009)(478600001)(50466002)(97736004)(5660300001)(50226002)(66066001)(68736007)(966005)(23676002)(33646002)(14496001)(81156014)(8936002)(101416001)(8676002)(81166006)(189998001)(1456003)(7736002)(9686003)(305945005)(116806002)(86362001)(81686999)(6486002)(6666003)(81816999)(3846002)(53936002)(4326008)(229853002)(106356001)(2906002)(6306002)(61296003)(105586002)(50986999)(84392002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2996; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTY7MjM6MHhvak56N3VWZWVKOXRBVmtqc0hqT1Rn?= =?utf-8?B?b0JYM21lU09xMG9TY1QyVUlxaVJTeVdqZmV1dHRrMVV6UFM4cEFLWWhtYmtt?= =?utf-8?B?Q3lDRVhMUjN2Vm9uMVNOYko0NGx4SHMrYVV4VzBwa2ticm9acmlhZ0E0bnJV?= =?utf-8?B?VlhKK0xmSUdxdThON3R1TDZMSkFPOTRGNm1BMGxJZllTWHFaQUZrbzZXQVNY?= =?utf-8?B?SkNIbnNXQ2R0aWlHVEwvYk1xc2ZndFlRa1dDRUVFRzlQc3Zmb0Rwc0NrUCtT?= =?utf-8?B?N0VLWnFlbm5CNHkrT1FNNllXT044eDgvbGk3VVc0TW9pS05IVkk5YlFsZzRp?= =?utf-8?B?Mys1V2lCb1R6dTByL0NoN0lpVEZjckRhd2VUNURXMGRJUWo5V2plNkQzb0tz?= =?utf-8?B?TCtGdWpjQzV4QWRuQk12dWxOZCt2NEJvZGdGMmVUVklKUFhQaytjd3RKSG13?= =?utf-8?B?UzV0c0s2UmFHN000dkpNSEcrYzY1UjV6Mi9kZVJkaWlvb2RzMUwxYnBGbVp3?= =?utf-8?B?MU9lSzhneS9QSlpSbWRiMVVwMjNaeFNwTGhCSUVUd1RHMEFFU3JqN21zOU1r?= =?utf-8?B?Yzd2SnE5U3pJTzRuVXhOb3dQMHZDNjB0WkZ5eGVtcU5USjk4cUdpWEg1VHMr?= =?utf-8?B?UlJmZ3oyWUM2L2VNYzdGSWxYZzYxdkdqQUtlSld0dkFUTlU1cVFBNGcrLytL?= =?utf-8?B?UjI5WG9ielY1MnliWDVENDViOVFSMHk1a0JGa3ZrVWVUS1kyY2tnck9kaWdi?= =?utf-8?B?djZQVUljeUVxcHZQc2lxV0dhSXg5d1hqdyt5WWNYejlQSkxGWDhRQTRkMkRY?= =?utf-8?B?NGtQcnlMMmZydGRLRzJaVEFxUm9vbTl2Z1NvbXF2aWR3NjlwOW55c1pwRVpG?= =?utf-8?B?N090blZvbmJmT2J6V1NjV1QzV3hxOTZEWk1haEhDSjd3dCsrMkM2T2lnVnNP?= =?utf-8?B?dFNBZmpiR0JvMmpxY0lFaDA4WkJrbDlOZGhya3JwQW5GQllsWW5jL1BrVnA5?= =?utf-8?B?dlRlbGFQNm9aRFV5YVdYalA5YjNYbEZwRWpYaEFxcTViNTh4R09nOXM4VGlD?= =?utf-8?B?cmMyWFRtbnRCUXVkVmxJV0kxTTV0YVpKMGw5bVYvOXVjc2hJdmM1ZkVPN2o4?= =?utf-8?B?YlhUVkdNc1J6aXY2S3UvM0tZYzdrWTZqNXFtVzAyU2k3OUZ4bjF2Sys2aEg4?= =?utf-8?B?YkhaMS9GNWFnS2dneHFnVkFyeU9WdVA2Ykd1elFsTGJCV3ptYWlreS9jOUhp?= =?utf-8?B?WGlrR0I4Z1g2RHJJdW1YMnMrWDBqNjBraW5QTnRqUzE4NFo0WWxPNlM5VjN2?= =?utf-8?B?ZXRTSk9UTUxqSVFtdnBmY1huT1JHb2xIUWxib3JyNEd6MEd6dlpRVi9LZ3RL?= =?utf-8?B?Sy9RUHdwc0J0bU0wcUlsbmxDbGpXRHBQZVd4cFlqVldzNTlNYU92NmQrSG40?= =?utf-8?B?cDlOOTNrWjQxM0FnaUV2dEVIL0ZwZUEwZEk2R29GUk84NXhYRW1JTStmUVd1?= =?utf-8?B?SU80VmdqTEUwUjNWb21VSDRuR2NpTHVKNy8rOGlKdlBIQXFuSjhqbTlHTDg5?= =?utf-8?B?d3NkWWtXNmFuaThIV3A2UFdxU1FkME1ma1JBeTE1TFpBeUI1cS91RzVDTk0v?= =?utf-8?B?eDIzQzFTMHFUbmRJUFp3YkhTeU5Hb3lMclRRYnRndGwrYVpKSTg4RXNGQmw4?= =?utf-8?B?a3YvbUI5OTdHdGN1ODQ5SFJsV3F2ZEFSTE1hdHhlNHhBWGNDM0E3bXZUOFVt?= =?utf-8?B?N0dvK0N3Q0wreUNjYzRMTXA3U0U4Nmc5TWwycnd0QVpxamdtWGRFTmhKMFlC?= =?utf-8?B?NXo5YnN0YVpqWUNBZVhrQW9OUWIyazhhajhvZXI0Yi9lUWIxNjQ3Q1N4bW1r?= =?utf-8?B?cER2UzJWd1ExNnR1MEh6Vk9vNHIyOE9jdDZUdmFmTUg4YS9pN1RjMHpDNU1Y?= =?utf-8?B?UWxFbTBtUjRUYjVmREl6czZjS1JFUmZlZnpuYXJ5dFFaS0JYSUUvSFpGVXox?= =?utf-8?B?SFMxMUcvbzYxUFc1N0pYR0Y4Y24xRWI4MnBQVGhJK2luS1FLV2MxMlJna2p3?= =?utf-8?B?MGsvOTdPL0pqQmQ2NjhydXBWKy84aG5ZdFNrRkFsVmwvanhrK1E2dytlcnla?= =?utf-8?B?Y2MyZz09?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2996; 6:tG5lrT48Evt6fZSvg8FEahXfyyUd4/EpIyWxIN2XcgD5azg+502fFHMIMBcUsoH06dNQcnb49UkvDyNjMKpAkk5KlwHw387iCmTyf8KFIJZncKPQAAx9yZxlqIhyLvxO4wjQxKErSe1imhLW/roIueHPMMIYodGFpo9zBdJEuZgeGjHjjWHRADTbJH2ouNrE7MAKbCD7rZGvSESl9UOQ1VVO9gK/aLGO2OjgGPe60Km/bHMz3HmwbovhJnaIMFaKw+GzCNKUTjzWWCJotevQyRMvGEz1gglWc+4FVjEcQx2JbtIWCeosB7xainZik1xQdmQALZbQsbrEj247nZg85Q==; 5:v3t/La6OtPCSNvJ8mC0R7raSVh4IoTjCAy76CVv9zq5XY+UWq33wo7rcWOBUqPW1OjETkoTNXH2Gby3zlmo+9Dgku9H2hwctHOyqkHSDZu/Jv+ro6iXSJ/9/xuLw/dz87+7UF//Eh4fEtzWhieb2yg==; 24:5x+qSbvob79aNN9/5+78poDoGxlnlGiot5D2IxjiZGnnAOceW2qQ1uSLtO6QKM7ugXsjBTYgZV3FVOZXm34CfH4tVUM9ca6FvhwzHDnay7I=; 7:12llKOTykw3baFwRm5Jfbe1gKYuqjOEi2Q5vI1MyjURvAZ+zzExltqoVR/KzDiofZ9R6+pxplVnRnhOWRuO4yAbIld+MS/4/2N+TLDPNv9NCgFjKYtn0Zhf/XmhIQ+K+QVSQc6cmJhqacLyUnhFIU2xahEXht1qjMiKS3hr5lfr1f5dHOEbTLwRUOla/Uek6FuhnNkwHNvavh0jVH7ME09Zw5NzpN+KBNITHw03/D6g= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2017 11:46:25.6161 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2996 Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 11:46:32 -0000 Having done my own homework, the IPR datatracker records IPR against two of the drafts that became RFC6877 and so, by implication, against the RFC itself. My recollection is that this was seen as ok for Informational but not for BCP and was a factor in the change of status of the prospective RFC for it to be Informational. Tom Petch ----- Original Message ----- From: "t.petch" To: "Fred Baker" ; "JORDI PALET MARTINEZ" Cc: Sent: Wednesday, September 20, 2017 10:41 AM Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info > ----- Original Message ----- > From: "Fred Baker" > To: "JORDI PALET MARTINEZ" > Cc: > Sent: Tuesday, September 19, 2017 9:27 PM > > > Hmm. Wearing the chair hat, but not making pronouncements. Thinking > through the options and considerations. > > Fred > > What was the final resolution of the IPR claim by China Mobile relating > to this work that caused much bemusement at the time of the approval > thereof and which also may have been a factor in changing the status > from BCP to Informational? > > Tom Petch > > > > > Some reading matter: > > https://tools.ietf.org/html/rfc2026#section-5 > > https://tools.ietf.org/html/rfc6410 > > RFC 2026 section 4 as updated by 6410. > > > > https://tools.ietf.org/html/rfc6782 > > https://tools.ietf.org/html/rfc7269 > > https://tools.ietf.org/html/rfc7335 > > https://tools.ietf.org/html/rfc7445 > > https://tools.ietf.org/html/rfc7849 > > https://tools.ietf.org/html/rfc7934 > > > > I would agree that informational status is probably inappropriate at > this point. I'll note that the progression is not all that unusual; GRE, > for example, was originally informational (RFC 1701), was taken to > Proposed Standard in RFC 2784, and has been updated by RFC 2890. If it > were taken to Internet Standard, we would need to demonstrate the points > raised in https://tools.ietf.org/html/rfc6410#section-2.2. > > > > What gives me pause in using the PS/IS standards track is the issue of > interoperation of multiple implementations. I'm not entirely sure what > that means in an operational procedure or service, which is in my > perception what 464XLAT is. If that is the interoperation of multiple > networks, it might be the interoperation of an IPv6-only (subset of a) > network with other IPv4 networks, as the interoperation of that same > network with IPv6 networks or networks with IPv6 capabilities doesn't > require such services. The description of a BCP in RFC 2026 sounds more > like what we're looking at here. > > > > My thought at the moment (which I can be argued out of) is that the > right status is BCP, and that we would want an updated document that > captures anything we have learned since RFC 6877 was published. > > > > > On Sep 19, 2017, at 5:23 AM, JORDI PALET MARTINEZ > wrote: > > > > > > Hi all, > > > > > > RFC6877 (464XLAT) is an informational document. > > > > > > However, this transition mechanism is the one that has a bigger > deployment in terms of number of subscribers using it (hundreds of > millions), which I think is even more than ALL the other transition > mechanism together. > > > > > > Doesn’t make any sense, in my opinion to keep it as an informational > document, while we have many others that are standards track and don’t > have such level of deployment. > > > > > > I was commenting this last week with a couple of the co-authors of > this document, and they have the same opinion. > > > > > > So, should we aim to do this? > > > > > > Can we even consider moving it to STD? > > > > > > Regards, > > > Jordi > > > > > > > > > > > > > > > ********************************************** > > > IPv4 is over > > > Are you ready for the new Internet ? > > > http://www.consulintel.es > > > The IPv6 Company > > > > > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive use > of the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution > or use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > From nobody Fri Sep 22 04:48:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8CC134307 for ; Fri, 22 Sep 2017 04:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gayOTjrMp4pc for ; Fri, 22 Sep 2017 04:48:49 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175A3132D51 for ; Fri, 22 Sep 2017 04:48:49 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6A3F240ED3 for ; Fri, 22 Sep 2017 13:48:47 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 471E840ED0; Fri, 22 Sep 2017 13:48:47 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 3840C17633; Fri, 22 Sep 2017 13:48:47 +0200 (CEST) Date: Fri, 22 Sep 2017 13:48:47 +0200 From: Gert Doering To: Mark Andrews Cc: Lorenzo Colitti , "v6ops@ietf.org WG" Message-ID: <20170922114847.GV45648@Space.Net> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170922070719.74AA687A424E@rock.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 11:48:51 -0000 Hi, On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote: > IPv6 applications need to add code to WORKAROUND breakages caused > by NAT64 the way they need add WORKAROUNDS for the NAT breakages > even if they are not using NAT64 or NAT respectively. The cancer > that is NAT64 needs to be eradicated. It will nicely go away if all endpoints are reachable over v6. Please make that happen! Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Sep 22 05:18:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB73134320 for ; Fri, 22 Sep 2017 05:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aNoMT_PrV5bh for ; Fri, 22 Sep 2017 05:18:03 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78DBE1320C9 for ; Fri, 22 Sep 2017 05:18:03 -0700 (PDT) Received: from [192.168.10.5] (77.16.79.77.tmi.telenormobil.no [77.16.79.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 7B3012D5066; Fri, 22 Sep 2017 12:18:00 +0000 (UTC) Content-Type: text/plain; charset=cp932 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15A372) In-Reply-To: <20170922114847.GV45648@Space.Net> Date: Fri, 22 Sep 2017 14:17:55 +0200 Cc: Mark Andrews , "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> To: Gert Doering Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 12:18:05 -0000 Gerd, > On 22 Sep 2017, at 13:48, Gert Doering wrote: >=20 > Hi, >=20 >> On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote: >> IPv6 applications need to add code to WORKAROUND breakages caused >> by NAT64 the way they need add WORKAROUNDS for the NAT breakages >> even if they are not using NAT64 or NAT respectively. The cancer >> that is NAT64 needs to be eradicated. >=20 > It will nicely go away if all endpoints are reachable over v6. I think that=81fs the concern. That it will not.=20 IPv6 applications will have code to accommodate for NAT64 forever.=20 Of course that=81fs slightly tangential to 464xlat which is just a poor IPv4= over IPv6 tunnel with null encap and session state.=20 Ole >=20 > Please make that happen! >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culeman= n > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Sep 22 05:21:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80A313432A for ; Fri, 22 Sep 2017 05:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z5HWrTcNsEd for ; Fri, 22 Sep 2017 05:21:49 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A474413431E for ; Fri, 22 Sep 2017 05:21:48 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id EDEC64291E for ; Fri, 22 Sep 2017 14:21:46 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id DC44842287; Fri, 22 Sep 2017 14:21:46 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id D8BF717728; Fri, 22 Sep 2017 14:21:46 +0200 (CEST) Date: Fri, 22 Sep 2017 14:21:46 +0200 From: Gert Doering To: Ole Troan Cc: Gert Doering , Mark Andrews , "v6ops@ietf.org WG" Message-ID: <20170922122146.GY45648@Space.Net> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pfqPuNG9QX5dciZ9" Content-Disposition: inline In-Reply-To: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 12:21:51 -0000 --pfqPuNG9QX5dciZ9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote: > > On 22 Sep 2017, at 13:48, Gert Doering wrote: > >> On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote: > >> IPv6 applications need to add code to WORKAROUND breakages caused > >> by NAT64 the way they need add WORKAROUNDS for the NAT breakages > >> even if they are not using NAT64 or NAT respectively. The cancer > >> that is NAT64 needs to be eradicated. > >=20 > > It will nicely go away if all endpoints are reachable over v6. >=20 > I think that?fs the concern. That it will not.=20 > IPv6 applications will have code to accommodate for NAT64 forever.=20 Yeah, but you can't have the cake and eat it. Either we go v6-only everywhere, or we keep running IPv4 everywhere until everybody else is done, or we introduce v4/v6 NATs, or we add a CLAT to every single operating system out there. What's it gonna be, boys? (Oh, "or we give up, roll back existing v6 deployments, and live happy with v4 nat forever". FAR less work, and for Joe Average User, it won't make a difference. Facebook and Youtube will continue to work, and their IoT devices will keep drilling holes into firewalls to ensure that they can be exploited no matter what) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --pfqPuNG9QX5dciZ9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnFAFgACgkQ31bAZeTO f8WrRw//a3xZjAzhiK5hI9m0mFG4QVJ/bKf8keSjulE0YGdw+1eE2PoAmgdZTYKT vl2poBV98UnVRpn6OMru+kObCXI7OHY1zZmoqtBboCuqYYofA9rjN4SGdwn7Uagi RtuTBGWm4AjMzQuHzz1if6QZab1sbnh9yKUxBYwAofqVlkOMm166SUGnoYwhixuC /LIgUj53vVC67rPt+fi/UJaFS1Iu1FwaAPHS5vIexDfx8gDsGhfdQGw6OD4x5R9e zU2Apx88O7cEV3xQbgINzBXF6JOGGq06P8t40Ln5WUv1BnrrGuifY3j4MxogGOpy QMLskUMDYbfIg2OrFsaGSYBeuKFgP6f65ZjC2iKXNbqbbDy750/eiw/yp9KVCAoJ fixd1c6itOZsBjZgCZEKmsU9MDhnD5cS3CX0c+I49k3IEHpdNfqk8bB+x6zKraRx iTkWuL3okFFca7JBPZNgdNyTDmteSF0086+yCKkcTOa3XohYCYtjyBMon2dEKCfl AkmYHFoxvMfx20PUGZdkwWJyI+WiM4mDm+F2KiPMO/RWcMfZNj0ZuG4948PH6WhJ ei+yxJAeUPoMnqeSV+CQJrwRSSfm60YbFckocGZ7/4CuA5dmOc9U+KPyERyn7xid hYBeJhoBSdxWA6jx1CTjlCPga5HVpbdDfMkmXSXkUNzRpA6aDrk= =u0No -----END PGP SIGNATURE----- --pfqPuNG9QX5dciZ9-- From nobody Fri Sep 22 05:26:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE1813431D for ; Fri, 22 Sep 2017 05:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ch3qTook7KY3 for ; Fri, 22 Sep 2017 05:26:07 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214D71320C9 for ; Fri, 22 Sep 2017 05:26:07 -0700 (PDT) Received: from [192.168.10.5] (77.16.79.77.tmi.telenormobil.no [77.16.79.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 914B42D4FD0; Fri, 22 Sep 2017 12:26:06 +0000 (UTC) Content-Type: text/plain; charset=cp932 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15A372) In-Reply-To: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> Date: Fri, 22 Sep 2017 14:26:03 +0200 Cc: "v6ops@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <6CEB7DEA-B146-4286-8C3F-1E97C1FD0062@employees.org> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> To: Gert Doering Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 12:26:14 -0000 s/d/t. Sorry.=20 > On 22 Sep 2017, at 14:17, Ole Troan wrote: >=20 > Gerd, >=20 >> On 22 Sep 2017, at 13:48, Gert Doering wrote: >>=20 >> Hi, >>=20 >>> On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote: >>> IPv6 applications need to add code to WORKAROUND breakages caused >>> by NAT64 the way they need add WORKAROUNDS for the NAT breakages >>> even if they are not using NAT64 or NAT respectively. The cancer >>> that is NAT64 needs to be eradicated. >>=20 >> It will nicely go away if all endpoints are reachable over v6. >=20 > I think that=81fs the concern. That it will not.=20 > IPv6 applications will have code to accommodate for NAT64 forever.=20 >=20 > Of course that=81fs slightly tangential to 464xlat which is just a poor IP= v4 over IPv6 tunnel with null encap and session state.=20 >=20 > Ole >=20 >=20 >>=20 >> Please make that happen! >>=20 >> Gert Doering >> -- NetMaster >> --=20 >> have you enabled IPv6 on something today...? >>=20 >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Sep 22 05:44:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA50132D51 for ; Fri, 22 Sep 2017 05:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-kFbhE6D3CG for ; Fri, 22 Sep 2017 05:44:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id CB8AA132031 for ; Fri, 22 Sep 2017 05:44:52 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dvNK7-0000EnC; Fri, 22 Sep 2017 14:44:51 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> In-reply-to: Your message of "Fri, 22 Sep 2017 14:21:46 +0200 ." <20170922122146.GY45648@Space.Net> Date: Fri, 22 Sep 2017 14:44:50 +0200 Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 12:44:55 -0000 >Yeah, but you can't have the cake and eat it. Either we go v6-only >everywhere, or we keep running IPv4 everywhere until everybody else >is done, or we introduce v4/v6 NATs, or we add a CLAT to every single >operating system out there. You left out the option where the CPE or other first hop router offers native IPv4 to the host (probably involving some kind of IPv4 NAT, but that is more or less standard these days) and tunnels the complete IPv4 packet to the network's IPv4 gateway. This avoid all of the NAT64/DNS64 problems. From nobody Fri Sep 22 05:45:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28B3132F76 for ; Fri, 22 Sep 2017 05:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHpJ-bULnFeI for ; Fri, 22 Sep 2017 05:45:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027BA132031 for ; Fri, 22 Sep 2017 05:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9465; q=dns/txt; s=iport; t=1506084311; x=1507293911; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8tJqrWmqvvN4qMcjvX1rEkQ4hegIruoC0cbDV+LcF0A=; b=TAOSju+1rp+ALvLB9eVXJ2d7Ikm2lWWsHRSxnGR1SU5VNi4njb7ST4QL Zle0DSrX5jOHkMGyFNxtFKzMoNX7IraGBRx039VlLUJ9S3r7+xpbek5Vc V0/Jo4T/m1qppNc+UhDN4liMRRo6ZrarSc7iVPkm1MP4l/z5uphtqXrIs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAQCoBMVZ/4YNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy0tZG4nnhGBUiKQaoU/ghIKGAEKhRgChCNBFgECAQEBAQEBAWs?= =?us-ascii?q?ohRkCAQMBAWwLEAIBCD8HJwsUEQIEDgUZiTZkEKkBiwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYMrggKBUYFkKwuCcoQ6hAOCMQWIKZhsAoZheox/DJJ3lRYCERk?= =?us-ascii?q?BgTgBJg4jQg0/eBVJEgGHCnaJVwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,427,1500940800"; d="scan'208,217";a="296840126" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Sep 2017 12:45:10 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v8MCjAkg017695 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Sep 2017 12:45:10 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 22 Sep 2017 07:45:10 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1263.000; Fri, 22 Sep 2017 07:45:10 -0500 From: "Rajiv Asati (rajiva)" To: Gert Doering CC: Ole Troan , "v6ops@ietf.org WG" Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info Thread-Index: AQHTMid0MFsx+pW27UqTI5O/FzE0AKK+QISAgACZFACAAHVGAIAAAUqAgADS0gD//8wEPIAA1YeA//+6It6AAKJbgIAACCSAgAABEwD//7K4HA== Date: Fri, 22 Sep 2017 12:45:10 +0000 Message-ID: References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org>, <20170922122146.GY45648@Space.Net> In-Reply-To: <20170922122146.GY45648@Space.Net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_E991C091EDC54735A52E4C53324ADE39ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 12:45:17 -0000 --_000_E991C091EDC54735A52E4C53324ADE39ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think that there any iOS app that is not IPv6-only compatible (sinc= e the apple AppStore mandate more than a year* ago). Is there one ? If Google playstore could mandate something similar (perhaps, there is one = that I am not aware of), then almost all mobile UEs can happily live with v= 6-only without any Clat function. Better battery life, likely. Hence, There is no need for XLAT being a BCP at this time in that regard. Of course, NAT64 inside the network would still be needed to accommodate th= e smaller (% of traffic) v4-only internet connectivity. But that's an ongo= ing saga of another debate. However, there is one exception - tethering :: if mobile UE is tethered and= the other devices connecting to its W/LAN are stuck in legacy v4-only, the= n mobile ISPs might prefer to not leave them behind to ensure customer expe= rience. What "technical" options do we have then? Well, really two =3D=3D L= et go of v6-only access (provide an IPv4-only APN if tethering is enabled r= esulting in a dual-stack UE) or stick with v6-only access, but turn on CLAT= function !! Cheers, Rajiv * https://developer.apple.com/support/ipv6/ On Sep 22, 2017, at 8:22 AM, Gert Doering > wrote: Hi, On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote: On 22 Sep 2017, at 13:48, Gert Doering > wrote: On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote: IPv6 applications need to add code to WORKAROUND breakages caused by NAT64 the way they need add WORKAROUNDS for the NAT breakages even if they are not using NAT64 or NAT respectively. The cancer that is NAT64 needs to be eradicated. It will nicely go away if all endpoints are reachable over v6. I think that?fs the concern. That it will not. IPv6 applications will have code to accommodate for NAT64 forever. Yeah, but you can't have the cake and eat it. Either we go v6-only everywhere, or we keep running IPv4 everywhere until everybody else is done, or we introduce v4/v6 NATs, or we add a CLAT to every single operating system out there. What's it gonna be, boys? (Oh, "or we give up, roll back existing v6 deployments, and live happy with v4 nat forever". FAR less work, and for Joe Average User, it won't make a difference. Facebook and Youtube will continue to work, and their IoT devices will keep drilling holes into firewalls to ensure that they can be exploited no matter what) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --_000_E991C091EDC54735A52E4C53324ADE39ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don't think that there any iOS app that is not IPv6-only compatible = (since the apple AppStore mandate more than a year* ago). Is there one ?

If Google playstore could mandate something similar (perhaps, there is= one that I am not aware of), then almost all mobile UEs can happily live with v6-only without any Clat function.  Better battery life, likely. 

Hence, There is no need for XLAT being a BCP at this time in that rega= rd. 

Of course, NAT64 inside the network would still be needed to accommoda= te the smaller  (% of traffic) v4-only internet connectivity. But that= 's an ongoing saga of another debate.  



However, there is one exception - tethering :: if mobile UE is tethere= d and the other devices connecting to its W/LAN are stuck in legacy v4-only= , then mobile ISPs might prefer to not leave them behind to ensure customer= experience. What "technical" options do we have then? Well, really two =3D=3D Let go of v6-only access (provide= an IPv4-only APN if tethering is enabled resulting in a dual-stack UE) or = stick with v6-only access, but turn on CLAT function !!


On Sep 22, 2017, at 8:22 AM, Gert Doering <gert@space.net> wrote:

Hi,

On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote:=
On 22 Sep 2017, at 13:48, Gert Doering <= gert@space.net> wrote:
On Fri, Sep 22, 2017 at 05:07:19PM +100= 0, Mark Andrews wrote:
IPv6 applications need to add code to WORKA= ROUND breakages caused
by NAT64 the way they need add WORKAROUNDS = for the NAT breakages
even if they are not using NAT64 or NAT res= pectively.  The cancer
that is NAT64 needs to be eradicated.

It will nicely go away if all endpoints are= reachable over v6.

I think that?fs the concern. That it will n= ot.
IPv6 applications will have code to accommo= date for NAT64 forever.

Yeah, but you can't have the cake and eat it.  Either we go v6-o= nly
everywhere, or we keep running IPv4 everywhere until everybody else
is done, or we introduce v4/v6 NATs, or we add a CLAT to every single=
operating system out there.

What's it gonna be, boys?

(Oh, "or we give up, roll back existing v6 deployments, and live= happy
with v4 nat forever".  FAR less work, and for Joe Average U= ser, it won't
make a difference.  Facebook and Youtube will continue to work, = and
their IoT devices will keep drilling holes into firewalls to ensure t= hat
they can be exploited no matter what)

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

SpaceNet AG          &nb= sp;            =  Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14        &= nbsp; Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen         &nbs= p;         HRB: 136055 (AG Mue= nchen)
Tel: +49 (0)89/32356-444       &nbs= p;   USt-IdNr.: DE813185279
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.i= etf.org/mailman/listinfo/v6ops
--_000_E991C091EDC54735A52E4C53324ADE39ciscocom_-- From nobody Fri Sep 22 05:46:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331BD134322 for ; Fri, 22 Sep 2017 05:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiFfOjqg-BHm for ; Fri, 22 Sep 2017 05:46:43 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4136132031 for ; Fri, 22 Sep 2017 05:46:42 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7ACF9427FD for ; Fri, 22 Sep 2017 14:46:41 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 6CF3A40F13; Fri, 22 Sep 2017 14:46:41 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 5EE77177C6; Fri, 22 Sep 2017 14:46:41 +0200 (CEST) Date: Fri, 22 Sep 2017 14:46:41 +0200 From: Gert Doering To: Philip Homburg Cc: v6ops@ietf.org, Gert Doering Message-ID: <20170922124641.GB45648@Space.Net> References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ew9mJ7yfAEtQK+FR" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 12:46:44 -0000 --Ew9mJ7yfAEtQK+FR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Sep 22, 2017 at 02:44:50PM +0200, Philip Homburg wrote: > >Yeah, but you can't have the cake and eat it. Either we go v6-only > >everywhere, or we keep running IPv4 everywhere until everybody else > >is done, or we introduce v4/v6 NATs, or we add a CLAT to every single > >operating system out there. >=20 > You left out the option where the CPE or other first hop router offers na= tive > IPv4 to the host (probably involving some kind of IPv4 NAT, but that is > more or less standard these days) and tunnels the complete IPv4 packet to > the network's IPv4 gateway. >=20 > This avoid all of the NAT64/DNS64 problems. And why is that a desirable end goal, cement IPv4 in everybody's home networks? Either the goal is "get rid on IPv4 on as many cables as we can" or we can just give up and interconnect IPv4 clouds over NAT gateways, using=20 whatever underlay in between - MPLS, IPv6, IPv4, it will not matter. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --Ew9mJ7yfAEtQK+FR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnFBjAACgkQ31bAZeTO f8WEXRAAjzTZM76c193jz+DwbAO8aeHr/r2iA3wYqO7aG6PEGcRjZ9WKxhuizzgG +QyidLcLrL/RmO3S+Y4PjDR1ZuTCSDriZvBBV/cd5IN0LDcpQ6zoUQ4pvFx4tMkH owq9lzZrqyJasVRGTB6hT1MrB5HfKolbg/oTnTYYLBnIzgpGeKzly0gJ3AaZhCp4 bK+xjBVmO+F2DGRp1Ix2CzfeVVevssyZLfwHGurRIQYkrVtUXXgbmMLfwR6zRIH+ bxCpw5QCQJd77SWQ12NquGLHZSGu9VUI3PFh/thW+/PD3WQhWg6eVcRj3jVFtyGp MkV9viTc17jme/+bLmNcd07BSV4HxtMe+OQquodfSHmhohEsYZ8kdmeTunMFDv9i RBN3DKZ5i9+PxS6zQRi+wwCBFnRVQCAPred05MKYUQCsehPpKPutprZhq0nYt93B Tz9RGqxcXzQwFB+r4AzQFYN46vwjBbisH5VHEdPk3TZs93cNV/9LZQn+mhgegY++ 9OWTq4gyWXN2OOtG+gwXrrdhh/9TCtcdyF+pTEviPo4AQSE0575w0AlFyr4nqbPU 0HjQpxTV/3BciKjSxVveWctZqiqi3Gr5Xyr0S1oUxf/u7Jnz0KscF0ovU9Nwr6Pa qycT8vF0y2dMztIg0jHPC8q8Ev5i2QOM72WI4y+KjBRtieDKy9M= =XZ+h -----END PGP SIGNATURE----- --Ew9mJ7yfAEtQK+FR-- From nobody Fri Sep 22 05:57:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8D134330 for ; Fri, 22 Sep 2017 05:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKoVHSIps_gI for ; Fri, 22 Sep 2017 05:57:49 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id CEB7A134326 for ; Fri, 22 Sep 2017 05:57:46 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #130) id m1dvNWc-0000FgC; Fri, 22 Sep 2017 14:57:46 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922124641.GB45648@Space.Net> In-reply-to: Your message of "Fri, 22 Sep 2017 14:46:41 +0200 ." <20170922124641.GB45648@Space.Net> Date: Fri, 22 Sep 2017 14:57:45 +0200 Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 12:57:50 -0000 >And why is that a desirable end goal, cement IPv4 in everybody's home >networks? > >Either the goal is "get rid on IPv4 on as many cables as we can" or we >can just give up and interconnect IPv4 clouds over NAT gateways, using=20 >whatever underlay in between - MPLS, IPv6, IPv4, it will not matter. I'm perfectly fine with not offering any kind of IPv4 all. Literally, offering no connection at all to the IPv4 internet. What I'm not okay with is pretending that NAT64/DNS64 is a good thing for the internet. If you want to offer some kind of tunneled IPv4, offer a tunnel that preserves IPv4 headers and terminate it at the first hop router. Forcing hosts to deal with NAT64 only serves to decrease the overal reliability of the internet. Terminating NAT64 in a CPE is also bad, but not quite as bad as requiring hosts to deal with NAT64. From nobody Fri Sep 22 06:08:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0B71343C3 for ; Fri, 22 Sep 2017 06:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQsYDCU6R1bv for ; Fri, 22 Sep 2017 06:07:46 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1D213234B for ; Fri, 22 Sep 2017 06:07:46 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id x131so683472ywa.10 for ; Fri, 22 Sep 2017 06:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LBuBvly7GuNprdZ9zDlpud5sGShgvdnryON7UA3SCXg=; b=Akj8dphFhtRjMCuzUh/Z3fVP2rI2nf8XdU7GS7hrvqzMh28u0tZPfhw4vw/1rc4YIL P3hP9xQ1oGabToWKRXA34kMjb8ImvBsNxapcD/H7MjDNELMMijqYMkIu2c9+JoZutk9S j3UW4Kf/KGegx8JbzHC+AOSBl6On9bKZppQkfeQlqonpI0tWEB07RLLvQSnO8jC4z6bh MV9mJsyJYSa2vRGJWL0bpePIBlaNxIwasMoqt0u3U7uJUKn4EwMsXSY2isJt4yVy6hF4 I9uHGku/jW13+RmJB2GLAElwexOzoQ2pa7fTVAWj6nM6q9UVotPKW7lB0GHRVz0qYhEf 8tIA== 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=LBuBvly7GuNprdZ9zDlpud5sGShgvdnryON7UA3SCXg=; b=m5yJxWqKxpUF6+4ibctZFr7kqeNR3L5uBcQlFczct4byWQJBmyVSN2t2y3Y3vHDdIq PZU1YkaZ53S7agMEzpTzZDlHHj2EBzl89W9OMOWcD0NQthcHirzrel8upYmAAKz4kfv3 ayWJkoXSm3PjO1zDpGuUg2o13HVGti1sElxUMgdg2T2pZOBwPGztuVV6HSGmqB+5SAbA BPjYYhUPcM8E390YK134SoiqHjV94yg1jvClzqv3fB8nnyXOZDcxoQCZj23H40/SGgvC cHgoCXlDU6U3GhHDUz9i9h32cIaA0ueV8QVoqZX1s+xsas6rli4inDCXxKpSkmpw8FXC y04A== X-Gm-Message-State: AHPjjUhIT/T49aElcik7Gk+WxJnqrfRvyxI+klhHYyoZuRXJHzevOSoC eIcFGJw3MjosU9P31DiDsc/24bByC37XmeHBUY4= X-Google-Smtp-Source: AOwi7QD7x7IKPhVdRkSJJFHWHY4rKDzrcQmnmEieY1FdSBmqsHk75EOE3YSCMmWRI7BXRXS8TmoNpCWLGmKHODf5ftU= X-Received: by 10.13.202.134 with SMTP id m128mr3852822ywd.42.1506085665740; Fri, 22 Sep 2017 06:07:45 -0700 (PDT) MIME-Version: 1.0 References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> In-Reply-To: From: Ca By Date: Fri, 22 Sep 2017 13:07:34 +0000 Message-ID: To: Gert Doering , "Rajiv Asati (rajiva)" Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a114f1c381b9b920559c6e565" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 13:07:58 -0000 --001a114f1c381b9b920559c6e565 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 22, 2017 at 5:45 AM Rajiv Asati (rajiva) wrote: > > I don't think that there any iOS app that is not IPv6-only compatible > (since the apple AppStore mandate more than a year* ago). Is there one ? > I am simply here to disabuse you of the notion that this rule has been perfect for the folks involved. > If Google playstore could mandate something similar (perhaps, there is one > that I am not aware of), then almost all mobile UEs can happily live with v6-only > without any Clat function. Better battery life, likely. > Fully agree. What if Google playstore cannot / will not enforce such a rule ? We in v6ops / sunset4 are well aware that asking for a poney seldom results in a poney .... hence warty solutions that thread one needle to move another needle. Putting the E back into IETF. > Hence, There is no need for XLAT being a BCP at this time in that regard. > > Of course, NAT64 inside the network would still be needed to accommodate > the smaller (% of traffic) v4-only internet connectivity. But that's an > ongoing saga of another debate. > > > > However, there is one exception - tethering :: > Ah. What little control we have. if mobile UE is tethered and the other devices connecting to its W/LAN are > stuck in legacy v4-only, then mobile ISPs might prefer to not leave them > behind to ensure customer experience. What "technical" options do we have > then? Well, really two == Let go of v6-only access (provide an IPv4-only > APN if tethering is enabled resulting in a dual-stack UE) or stick with > v6-only access, but turn on CLAT function !! > > Cheers, > Rajiv > > > * https://developer.apple.com/support/ipv6/ > > > On Sep 22, 2017, at 8:22 AM, Gert Doering wrote: > > Hi, > > > > On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote: > > On 22 Sep 2017, at 13:48, Gert Doering wrote: > > On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote: > > IPv6 applications need to add code to WORKAROUND breakages caused > > by NAT64 the way they need add WORKAROUNDS for the NAT breakages > > even if they are not using NAT64 or NAT respectively. The cancer > > that is NAT64 needs to be eradicated. > > > It will nicely go away if all endpoints are reachable over v6. > > > I think that?fs the concern. That it will not. > > IPv6 applications will have code to accommodate for NAT64 forever. > > > Yeah, but you can't have the cake and eat it. Either we go v6-only > everywhere, or we keep running IPv4 everywhere until everybody else > is done, or we introduce v4/v6 NATs, or we add a CLAT to every single > operating system out there. > > What's it gonna be, boys? > > (Oh, "or we give up, roll back existing v6 deployments, and live happy > with v4 nat forever". FAR less work, and for Joe Average User, it won't > make a difference. Facebook and Youtube will continue to work, and > their IoT devices will keep drilling holes into firewalls to ensure that > they can be exploited no matter what) > > > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > > > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114f1c381b9b920559c6e565 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Sep 22, 2017 = at 5:45 AM Rajiv Asati (rajiva) <raj= iva@cisco.com> wrote:

I don't think that there any iOS app that is not IPv6-only compati= ble (since the apple AppStore mandate more than a year* ago). Is there one = ?

I am simply here to disabuse you of the notion that this rule has been per= fect for the folks involved.=C2=A0


If Google playstore could mandate something similar (perhaps, there is= one that I am not aware of), then almost all=C2=A0mobile UEs can happily live with=C2=A0v= 6-only without any Clat function.=C2=A0 Better battery life, likely.=C2=A0

Fully agree. What if Google playstore cannot / will not enforce such a rul= e ?=C2=A0 We in v6ops / sunset4 =C2=A0are well aware that asking for a pone= y seldom results in a poney .... hence warty solutions that thread one need= le to move another needle. Putting the E back into IETF.=C2=A0

=
Hence, There is no need for XLAT being a BCP at this time in that rega= rd.=C2=A0

Of course, NAT64 inside the network would still be needed to accommoda= te the smaller =C2=A0(% of traffic) v4-only internet connectivity. But that= 's an ongoing saga of another debate. =C2=A0



However, there is one exception - tethering ::

Ah. What little control we h= ave.=C2=A0


if mobile UE is tethere= d and the other devices connecting to its W/LAN are stuck in legacy v4-only= , then mobile ISPs might prefer to not leave them behind to ensure customer= experience. What "technical" options do we have then? Well, really two =3D=3D Let go of v6-only access (provide= an IPv4-only APN if tethering is enabled resulting in a dual-stack UE) or = stick with v6-only access, but turn on CLAT function !!

Cheers,
Rajiv=C2=A0




On Sep 22, 2017, at 8:22 AM, Gert Doering <gert@space.net> wrote:

Hi,


On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote:
On 22 Sep 2017, at 13:48, Gert Doering <= gert@space.net> = wrote:
On Fri, Sep 22, 2017 at 05:07:19PM +1000, M= ark Andrews wrote:
IPv6 applications need to add code to WORKA= ROUND breakages caused
by NAT64 the way they need add WORKAROUNDS = for the NAT breakages
even if they are not using NAT64 or NAT res= pectively.=C2=A0 The cancer
that is NAT64 needs to be eradicated.

It will nicely go away if all endpoints are= reachable over v6.

<= blockquote type=3D"cite">I think that?fs the concern. That it will no= t.
IPv6 applications will have code to accommo= date for NAT64 forever.

Yeah, but you can't have the cake and eat it.=C2=A0 Either we go = v6-only
everywhere, or we keep running IPv4 everywhere until everybody else
is done, or we introduce v4/v6 NATs, or we add a CLAT to every single=
operating system out there.

<= span>What's it gonna be, boys?

(Oh, "or we give up, roll back existing v6 deployments, and live= happy
with v4 nat forever".=C2=A0 FAR less work, and for Joe Average U= ser, it won't
make a difference.=C2=A0 Facebook and Youtube will continue to work, = and
their IoT devices will keep drilling holes into firewalls to ensure t= hat
they can be exploited no matter what)
=


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

SpaceNet AG =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0HRB: 136055 (AG Mu= enchen)
Tel: +49 (0)89/32356-444 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0USt-IdNr.: DE813185279
<= /div>
_______________________________________________
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a114f1c381b9b920559c6e565-- From nobody Fri Sep 22 06:47:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501DE134325 for ; Fri, 22 Sep 2017 06:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHoTV6mUXFMs for ; Fri, 22 Sep 2017 06:47:34 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C412134307 for ; Fri, 22 Sep 2017 06:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506088051; x=1506692851; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=B4YO9BeZ4h4FMRysfFYm4e0Ui /Fz3fLMds2RZ6Hj26I=; b=TxQsm0eADXdOQiZd057gzPVTf/IGqvnV4fo9JMa43 QM3JS/96T8olo6/063lySP1vMN2g/Fe87CegPDyoXrWD38xZ1cSS+L/Xeeno52fC ByGzkJRC/y6hEuy0VnvS6mFIODtuWjkwexLAD6lGTvSAHxWKkUBbc8qBaZx5dZfR xs= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=WnLwga/B4YEhaIvDhUHri4rE0xCPhlclhKue+guxqKXY2900e6ubtWBce80g GicR5Cb69tVGzr/rk+XYWdtGNyM4B803kGpy6tT6iwW7wdhb8mvMr7Ii/ lr1EiNnt4ai7z6bjq6FCFsEW2pac0o2VvAyplpo1zwNQxjyYFNUYYs=; X-MDAV-Processed: mail.consulintel.es, Fri, 22 Sep 2017 15:47:31 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 22 Sep 2017 15:47:30 +0200 Received: from [45.6.249.44] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005563074.msg for ; Fri, 22 Sep 2017 15:47:29 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170922:md50005563074::vopo8sMcKNFxmIBy:000023MW X-MDRemoteIP: 45.6.249.44 X-Return-Path: prvs=1438bb095a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Fri, 22 Sep 2017 10:47:20 -0300 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org WG" Message-ID: <8682A9F5-7100-4F4A-BC72-39E43AD74D1B@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 13:47:36 -0000 And the issue is that you=E2=80=99re talking only about the cellular networ= ks, but we have the same issue with the residential ones =E2=80=A6 and the = corporates that only use the network to =E2=80=9Cbrowse=E2=80=9D (not to ex= pose services outside). Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de "Rajiv Asati (rajiva)" Responder a: Fecha: viernes, 22 de septiembre de 2017, 9:45 Para: Gert Doering CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info =20 =20 I don't think that there any iOS app that is not IPv6-only compatible (= since the apple AppStore mandate more than a year* ago). Is there one ? =20 =20 If Google playstore could mandate something similar (perhaps, there is = one that I am not aware of), then almost all mobile UEs can happily live wi= th v6-only without any Clat function. Better battery life, likely.=20 =20 =20 Hence, There is no need for XLAT being a BCP at this time in that regar= d.=20 =20 =20 Of course, NAT64 inside the network would still be needed to accommodat= e the smaller (% of traffic) v4-only internet connectivity. But that's an = ongoing saga of another debate. =20 =20 =20 =20 =20 =20 =20 However, there is one exception - tethering :: if mobile UE is tethered= and the other devices connecting to its W/LAN are stuck in legacy v4-only,= then mobile ISPs might prefer to not leave them behind to ensure customer = experience. What "technical" options do we have then? Well, really two =3D=3D Let go of v6-only access (pro= vide an IPv4-only APN if tethering is enabled resulting in a dual-stack UE)= or stick with v6-only access, but turn on CLAT function !! =20 =20 Cheers, Rajiv=20 =20 =20 =20 =20 * https://developer.apple.com/support/ipv6/ =20 =20 =20 =20 =20 On Sep 22, 2017, at 8:22 AM, Gert Doering wrote: =20 =20 =20 Hi, =20 On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote: =20 On 22 Sep 2017, at 13:48, Gert Doering wrote: =20 =20 =20 =20 =20 On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote: =20 =20 =20 =20 =20 =20 =20 IPv6 applications need to add code to WORKAROUND breakages caused =20 =20 =20 =20 =20 =20 =20 by NAT64 the way they need add WORKAROUNDS for the NAT breakages =20 =20 =20 =20 =20 =20 =20 even if they are not using NAT64 or NAT respectively. The cancer =20 =20 =20 =20 =20 =20 =20 that is NAT64 needs to be eradicated. =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 It will nicely go away if all endpoints are reachable over v6. =20 =20 =20 =20 =20 =20 =20 =20 =20 I think that?fs the concern. That it will not.=20 =20 =20 =20 IPv6 applications will have code to accommodate for NAT64 forever. =20 =20 =20 =20 Yeah, but you can't have the cake and eat it. Either we go v6-only everywhere, or we keep running IPv4 everywhere until everybody else is done, or we introduce v4/v6 NATs, or we add a CLAT to every single operating system out there. =20 What's it gonna be, boys? =20 (Oh, "or we give up, roll back existing v6 deployments, and live happy with v4 nat forever". FAR less work, and for Joe Average User, it won'= t make a difference. Facebook and Youtube will continue to work, and their IoT devices will keep drilling holes into firewalls to ensure tha= t they can be exploited no matter what) =20 Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? =20 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Cule= mann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Sep 22 06:59:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806C9132403 for ; Fri, 22 Sep 2017 06:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIkGMqm082Xh for ; Fri, 22 Sep 2017 06:59:39 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EECD13320C for ; Fri, 22 Sep 2017 06:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1506088777; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=FHZkIs9h05+tf8HUkag6ftPAYPF/LFJXvdVvh68JGCo=; b=ZDjYMseZlBYMyh6Pc8p1AkvM73BiC0YDwuo0CmOXxuAqmiX5Nrh5cy8Fi0FFK/6dfP0rvYF70TNMtpkMD3DyHkCsK9TnJVYJ3QOiVYA6UIndNALq/PrFhexqP0UhyrSoxH1K+EwjWv3KCcWYEUOdSytTl/5jy0eF7FnF4LU3/So= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0143.outbound.protection.outlook.com [213.199.154.143]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-22-Pjf1ZjW3Ph28-bd6inV8Uw-1; Fri, 22 Sep 2017 14:59:32 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 22 Sep 2017 13:59:31 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::6d:9ebf:900:b590%14]) with mapi id 15.20.0077.011; Fri, 22 Sep 2017 13:59:31 +0000 From: Tim Chown To: Ole Troan CC: Mark Andrews , "v6ops@ietf.org" Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info Thread-Index: AQHTMid0qF8DhAQaXUakhFSla/huRKK97LOAgACZEwCAAHVHgIAA1DoygAAfxBiAAJOtgIAAbv4A Date: Fri, 22 Sep 2017 13:59:31 +0000 Message-ID: References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> In-Reply-To: <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:c8fe:6741:17e7:e406] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 20:TSOHjBVssKwmZv+jJNT4ZeUT4WB7hg+ZQBKniN0n34qOwJzen167oISBNJE7xQVWTK31ow0KA9It2jHJlrFbdxBMZOSDgCUEjz0B1qfPdS8j5zjfmY9jaa7tiSLQ78GLBTI8IFF5djAg3L2OI8dprZcM3b3uE6wX1HppzPhJ+CI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7f08ab18-8d46-4538-2f9d-08d501c225db x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1140; x-ms-traffictypediagnostic: AM3PR07MB1140: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1140; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1140; x-forefront-prvs: 0438F90F17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(376002)(346002)(189002)(24454002)(199003)(57306001)(6916009)(14454004)(25786009)(106356001)(74482002)(105586002)(6512007)(50986999)(82746002)(50226002)(76176999)(83716003)(53936002)(99286003)(2906002)(102836003)(6116002)(305945005)(7736002)(8936002)(6246003)(81166006)(3280700002)(8676002)(4326008)(81156014)(478600001)(229853002)(189998001)(68736007)(72206003)(2900100001)(2950100002)(6436002)(86362001)(53546010)(3660700001)(42882006)(97736004)(5660300001)(101416001)(93886005)(5250100002)(6506006)(54906003)(316002)(786003)(36756003)(33656002)(6486002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <8086B12D450FA345A8EB5F618D4C78BB@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2017 13:59:31.1791 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1140 X-MC-Unique: Pjf1ZjW3Ph28-bd6inV8Uw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 13:59:41 -0000 > On 22 Sep 2017, at 08:22, Ole Troan wrote: >=20 >>> We have a problem in that people confuse "a standard" with "the standar= d" >>> and >>> "a best current practice" with "the best current prcatice". But in the >>> end that's >>> just a matter of wording in the Abstract and Introduction. We say: if y= ou >>> want >>> to run a pure IPv6 network service while supporting IPv4-only clients a= nd >>> servers, >>> and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a good >>> way to do it. >>=20 >> I'd argue it is a "way to do it". Good is not a adjective I'd apply >> to it as it has lots of side effects that impact others that are >> NOT using it the same way as NAT impacts every developer that uses >> IPv4. >>=20 >> Because 464XLAT is almost always deployed with DNS64 (there are >> potentially other ways to learn the address mappings): >>=20 >> YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING >> TERMINATED ON A IPV6 NODE. This restricts what you can do with >> that connection. This impacts on EVERY developer. >>=20 >> DNS64/NAT64 and 464XLAT needs to die and the earth needs to be >> salted where they are buried. They are not like NAT44 where there >> no other viable alternative. There are plenty of alternatives. >=20 > From the perspective of forcing every IPv6 application to have to be able= to deal with connecting to an IPv4 endpoint. > Breaking DNSSEC. > Requiring stateful devices in the network. >=20 > I would suggest this belongs in the newly invented document category: WCP= - Worst Current Practice. I like that. We could tag quite a few RFCs/protocols as WCP. Starting wit= h IPv4. Tim From nobody Fri Sep 22 07:52:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B2E134479 for ; Fri, 22 Sep 2017 07:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6x8hF0xccTo for ; Fri, 22 Sep 2017 07:52:23 -0700 (PDT) Received: from atl4mhob04.registeredsite.com (atl4mhob04.registeredsite.com [209.17.115.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867881342CC for ; Fri, 22 Sep 2017 07:52:23 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob04.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8MEqKbg002777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Sep 2017 10:52:20 -0400 Received: (qmail 3688 invoked by uid 0); 22 Sep 2017 14:52:20 -0000 X-TCPREMOTEIP: 72.221.14.183 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.183) by 0 with ESMTPA; 22 Sep 2017 14:52:19 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 22 Sep 2017 10:52:10 -0400 From: Lee Howard To: Ole Troan , Gert Doering CC: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> In-Reply-To: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 14:52:25 -0000 Speaking as participant, not as cochair. On 9/22/17, 8:17 AM, "v6ops on behalf of Ole Troan" wrote: >Gerd, > >> On 22 Sep 2017, at 13:48, Gert Doering wrote: >>=20 >> Hi, >>=20 >>> On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote: >>> IPv6 applications need to add code to WORKAROUND breakages caused >>> by NAT64 the way they need add WORKAROUNDS for the NAT breakages >>> even if they are not using NAT64 or NAT respectively. The cancer >>> that is NAT64 needs to be eradicated. >>=20 >> It will nicely go away if all endpoints are reachable over v6. How many significant digits in =E2=80=9Call=E2=80=9D? 90%? 99%? 99.9%? 99.999%? Somewhere in there the engineering tradeoffs start looking different. > >I think that=E2=80=99s the concern. That it will not. >IPv6 applications will have code to accommodate for NAT64 forever. How many significant digits in =E2=80=9Cforever=E2=80=9D? I ask because if an app developer is 99.xx% sure that 99.xx% of users will be on IPv6-enabled devices and networks, then they can remove any compensation for IPv4. Enough years have passed that =E2=80=9Cforever=E2=80=9D isn=E2=80=99t as far off as it used t= o be. Following adoption curves: The majority of hits on Google US will be IPv6 in six months. 80% of hits on Google US will be IPv6 in two and a half years. 90% of hits on Google US will be IPv6 in three and a half years. The majority of hits on Google worldwide will be IPv6 in two years. 80% of hits on Google worldwide will be IPv6 in four years. 90% of hits on Google worldwide will be IPv6 in five years. https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D2000&tim ebackward=3D2064&country=3Dww In IETF time scales, we are about to be overtaken by events. Predicting based on a logistic curve is tricky, but 99% IPv6 is within most of our career lifetimes. How rare does a case have to be before you can decide not to handle it? For that matter, how rare does a case have to be before a network operator decides it=E2=80=99s marginal and can be either outsourced or ignored? Asking for a friend. Lee > >Ole From nobody Fri Sep 22 09:10:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F80013450C for ; Fri, 22 Sep 2017 09:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nVttoP61yaM for ; Fri, 22 Sep 2017 09:10:21 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCDF13305E for ; Fri, 22 Sep 2017 09:10:20 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2958740BA3 for ; Fri, 22 Sep 2017 18:10:19 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1868840BA0; Fri, 22 Sep 2017 18:10:19 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 0A38F17C77; Fri, 22 Sep 2017 18:10:19 +0200 (CEST) Date: Fri, 22 Sep 2017 18:10:18 +0200 From: Gert Doering To: Lee Howard Cc: Ole Troan , Gert Doering , "v6ops@ietf.org WG" Message-ID: <20170922161018.GG45648@Space.Net> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rbPdAdigv99fy+eV" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 16:10:24 -0000 --rbPdAdigv99fy+eV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Sep 22, 2017 at 10:52:10AM -0400, Lee Howard wrote: > Following adoption curves: > The majority of hits on Google US will be IPv6 in six months. > 80% of hits on Google US will be IPv6 in two and a half years. > 90% of hits on Google US will be IPv6 in three and a half years. > The majority of hits on Google worldwide will be IPv6 in two years. > 80% of hits on Google worldwide will be IPv6 in four years. > 90% of hits on Google worldwide will be IPv6 in five years. > https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D20= 00&tim > ebackward=3D2064&country=3Dww I like your optimism :-) But then, I look at mobile operators in Germany - the *incumbent* has=20 done their homework and is providing IPv6, but the "new kids on the block" mobile operators (like, "younger, agile", and all this) are not even having= =20 *plans* for IPv6 yet... And this is only eyeball networks. Right now, there's so much *content* IPv4-only that eyeball networks need to put up CGN boxes to enable reachability to that content - and if these boxes are in place anyway, what incentives does content have to enable IPv6? Looking at the Alexa Top sites, I see lots of red on Eric's=20 page. Basically, everything that's not Google or happens to sit behind Cloudflare (for DE)... :-( Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --rbPdAdigv99fy+eV Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnFNeoACgkQ31bAZeTO f8V/eQ/+JVcKoHE6oFiBS26ofGhOn7QCGWaQ69P5Xl9ctqHlE8EdtgF3fNX85Uck ZhMw2g6IC37mtoH/0R5awip2ulaaequAxaiDXEC102cGWakVifPlR2KjzfntZHLk W4bStsr+L6y3gencSMd5426y8O3x25dhWaSwSjuNGwDK2Uqyp3rTenxv0ZCuAqvs jGLhSq5g1QU3i7408+Z4Z4NzdNE+gk3g5HKvtHikWAP0L7pB10T8AiFla2i99wuZ NB0cAWWtrgoPpkeNc9pcU5+iGgQyiS1vQJ9J3nm/pFssp0e5J3OVrsNYDK8S3DSu lGYMaKe5a9gItWsudG2FrKpaUsA1+F6Oc5bqP6BIDqYVgMvR2Xc9NO5GqAvgMnXT OT9wrdW/eO/VC45K4lfLIl9gQxD4vYUcTmCCQC1Qzhiss1YJKCc4xPm9LHjJdlua hRzc/l9ao9GjiDJnI29sJhokHB+wE1CKVWIMLh6REGbRYyBlBi5j5YVlIGOS34zF m9M0ah0UNlthbXhyQ6ZY/Rbge/z8oepG67aB+Kaa/8scNhUJYbB4DoWlbUUu2c5q 3wLcyXpXTz4AyVXstD5ze5pn2SMXL5hsT3Q0BqAARGSktcEpcHEWM+rqtJEobkH9 fe1hwgWh1dQNiSp+MnsNdsMpbfWsLaafcuqYlITEFKENywpew8c= =wlc9 -----END PGP SIGNATURE----- --rbPdAdigv99fy+eV-- From nobody Fri Sep 22 09:13:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB7C13451F for ; Fri, 22 Sep 2017 09:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFRpTi4Nl2n4 for ; Fri, 22 Sep 2017 09:13:39 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FA413305E for ; Fri, 22 Sep 2017 09:13:38 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 59C1C40BA4 for ; Fri, 22 Sep 2017 18:13:37 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 4541F40BA0; Fri, 22 Sep 2017 18:13:37 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 420C517CAA; Fri, 22 Sep 2017 18:13:37 +0200 (CEST) Date: Fri, 22 Sep 2017 18:13:37 +0200 From: Gert Doering To: Lee Howard Cc: Ole Troan , Gert Doering , "v6ops@ietf.org WG" Message-ID: <20170922161337.GH45648@Space.Net> References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nj8zXuY9jD9xNsUh" Content-Disposition: inline In-Reply-To: <20170922161018.GG45648@Space.Net> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 16:13:40 -0000 --nj8zXuY9jD9xNsUh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Sep 22, 2017 at 06:10:18PM +0200, Gert Doering wrote: > Right now, there's so much *content* IPv4-only that eyeball networks need > to put up CGN boxes to enable reachability to that content - and if these > boxes are in place anyway, what incentives does content have to enable > IPv6? Looking at the Alexa Top sites, I see lots of red on Eric's=20 > page. Basically, everything that's not Google or happens to sit behind > Cloudflare (for DE)... :-( Oh. As a side note, "a fried" tells me that a major audio streaming platform in DE had to turn off IPv6, because Samsung. "If we listen to the stream over IPv4, and the phone goes to sleep, the stream will continue playing. If we listen over IPv6 and the phone goes to sleep, it will stop". Since there is no way to get Samsung to fix their shit (like, Google, having proper requirements for Android vendors...) the radio station decided that it's not worth the hassle and just turned off IPv6 again - much less work than building something into their platforms that redirects broken clients to an IPv4-only site and keeps IPv6 for the rest. And stories like this is why I'm not overly optimistic anymore, after barely 20 years of advocating IPv6. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --nj8zXuY9jD9xNsUh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnFNrAACgkQ31bAZeTO f8Uv4w//ao3BHMOPSdl2j0M93XOQzZrntj2ERXadQgWreqqPmfhqO6chIYcEBp2o IR8BnoD5SkbxFxq5oYPqRrek7N/GhomsYv9miKJOfbPf57JWeSds54GqlShA1wYb I4uQBgqA97N0xg/IomD7B7GF/En6XOYhmCpNKxfuXXSPbgnSSvCHK4iZcrpGZZtj x3ZEsM0baVwGZfcGiUYNmIZn0UXXzJcwo/fm280hjKuZki9zWXVsGnwfGsfsoyVv Ii4ZIEkCgISNXNs3i32cTH8Xir5FGId/Xv0lollPS0+TkAlni+Jy2MfcwcbueK4C 7Xru9Vnw1UQ9YSUTFm1wbjsRo0simAY46+7mpYPs3vnqcCR0zoAoKf1cpI6mD0Ut jfgyfeV9HX0Rn1KxVB8U/lOVnC7CMxbdiqrPykhfeGmzXDt5wPQIc9eQAC8+w7cJ 7NyXaer3Gm2hppjVhOBFGEnpKvSs9WVZ087rDh0cMNNRGi6PuxGmiE+Cg3qiqQyd ZpCEJAGmQ/gfrJuzu9Ka6eD6yB4JnSHbHxe2NVGC2SbVdEQPSgsoZRJUxFBu97Hz xjf4A1A1glU8SoYlGZ255GIJoSY3N20X0bEmokqRfLR6C8SV7oKrZK8lsTctuioi 1b34JaZ6PeUibN/kwVYU97hlDU9vfTJ3gvPproFewD7uq9paaxk= =ama+ -----END PGP SIGNATURE----- --nj8zXuY9jD9xNsUh-- From nobody Fri Sep 22 10:55:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031A4132C3F for ; Fri, 22 Sep 2017 10:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFCkoKL2lbSP for ; Fri, 22 Sep 2017 10:55:30 -0700 (PDT) Received: from atl4mhob23.registeredsite.com (atl4mhob23.registeredsite.com [209.17.115.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3EC0132397 for ; Fri, 22 Sep 2017 10:55:30 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.211]) by atl4mhob23.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8MHtTCK007936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Sep 2017 13:55:29 -0400 Received: (qmail 24980 invoked by uid 0); 22 Sep 2017 17:55:29 -0000 X-TCPREMOTEIP: 72.221.14.183 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.183) by 0 with ESMTPA; 22 Sep 2017 17:55:28 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 22 Sep 2017 13:55:24 -0400 From: Lee Howard To: Lee Howard CC: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 17:55:36 -0000 As to the original question, I have a couple of questions: 1. What is gained by promoting rfc6877 "464XLAT: Combination of Stateful and Stateless Translation=E2=80=9D? Regardless of whether the correct promotion path is BCP or Proposed Standard, what is the goal? 2. rfc2026 =E2=80=9CThe Internet Standards Process=E2=80=9D says a BCP is the "best current thinking on a statement of principle or on what is believed to be the best way to perform some operations.=E2=80=9D What principle or what operations is 464xlat best for? The chairs are working out how to handle this request, and answers to these questions will help us. Thanks, Lee From nobody Fri Sep 22 11:24:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535E81342F3 for ; Fri, 22 Sep 2017 11:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N94qUOrOZojt for ; Fri, 22 Sep 2017 11:24:06 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D6B134584 for ; Fri, 22 Sep 2017 11:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506104563; x=1506709363; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=a8GvVvgSk/pfE3YfThLR61GKo drc0g30BUFGCD6uick=; b=snnhPd/R4X57+2X1JkdeG575YL6X8Jja6m8xF7ckR cPGhOWs2zWMs1JpV4ztg6JTjGOWudOZWY+qaVpRtpj44uhco2vCPzc5JrRUWbMAc 8W1bGWNWPamya/ZY71bCH+KdCGUfToES3sFCTLeND+88jzEM4Nb2KMLnaycb0jCc vE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=OVY9EAINxNlmuKE6rjYirX5GB5tOnzNvYd3X2dstHBkcp2aDQGxn7pDQSGES eIzpJHgH5hstcrzoFzssWm5O9Ul5AL0S3+SIokQx9T5TEzTon2STpR2rF zn0auxBeA9nqO04JZ7/LHh+yIxg7YTFCOsiaHA9ZJ3rSPiB2lQNKHE=; X-MDAV-Processed: mail.consulintel.es, Fri, 22 Sep 2017 20:22:43 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 22 Sep 2017 20:22:42 +0200 Received: from [45.6.249.44] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005563324.msg for ; Fri, 22 Sep 2017 20:22:42 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170922:md50005563324::CyzxJcpYVsLw3PLZ:00007pBw X-Return-Path: prvs=1438bb095a=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Fri, 22 Sep 2017 15:22:35 -0300 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 18:24:08 -0000 Hi Lee, See below in-line. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Lee Howard Responder a: Fecha: viernes, 22 de septiembre de 2017, 14:56 Para: Lee Howard CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info As to the original question, I have a couple of questions: =20 1. What is gained by promoting rfc6877 "464XLAT: Combination of Statefu= l and Stateless Translation=E2=80=9D? Regardless of whether the correct = promotion path is BCP or Proposed Standard, what is the goal? [Jordi] My point is: I understand that when 464XLAT was proposed, it was no= t considered at the same level as other transition mechanisms, which are, f= rom the start, standards track. Now that this is the most successful (in te= rms of number of users vs. all the other transition mechanisms), in my opin= ion there is no reason to discriminate it. So, either we drop to informatio= nal all the transition mechanisms that have so much lower degree of success= or even to historic or deprecated those that are not used. Is a matter of = fairness and recognize the reality. =20 2. rfc2026 =E2=80=9CThe Internet Standards Process=E2=80=9D says a BCP= is the "best current thinking on a statement of principle or on what is believed to = be the best way to perform some operations.=E2=80=9D What principle or wh= at operations is 464xlat best for? =20 [Jordi] Well, I was suggesting standards track, not BCP. So not sure how to= read this question myself. Actually, I=E2=80=99ve drafted already (started= two months ago, and not related at all to this discussion, but for lack of= time availability, haven=E2=80=99t completed it yet, hopefully can have it= early next week) a BCP which initially I=E2=80=99ve titled =E2=80=9C464XLA= T Deployment Guidelines in Operator Networks=E2=80=9D. The idea come out af= ter we had the discussion of deploying at the IETF network 464XLAT instead = of just NAT64. In this document I=E2=80=99m describing how, according to my= experience (and hopefully inputs from others once a first version is publi= shed), 464XLAT is being deployed in both cellular and non-cellular networks= . =20 The chairs are working out how to handle this request, and answers to these questions will help us. =20 Thanks, =20 Lee =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Fri Sep 22 11:29:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DF713458B for ; Fri, 22 Sep 2017 11:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6NCNGaFnBwz for ; Fri, 22 Sep 2017 11:29:11 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B788134588 for ; Fri, 22 Sep 2017 11:29:11 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 3929640BA0 for ; Fri, 22 Sep 2017 20:29:09 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 2885C40B9C; Fri, 22 Sep 2017 20:29:09 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 1A42E17E3F; Fri, 22 Sep 2017 20:29:09 +0200 (CEST) Date: Fri, 22 Sep 2017 20:29:09 +0200 From: Gert Doering To: Lee Howard Cc: "v6ops@ietf.org WG" Message-ID: <20170922182908.GI45648@Space.Net> References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 18:29:13 -0000 Hi, coming back from my old man's rant (apologies) to the original question... On Fri, Sep 22, 2017 at 01:55:24PM -0400, Lee Howard wrote: > As to the original question, I have a couple of questions: > > 1. What is gained by promoting rfc6877 "464XLAT: Combination of Stateful > and Stateless Translation???? Regardless of whether the correct promotion > path is BCP or Proposed Standard, what is the goal? I do not think much is to be gained. Implementations already exist, so pointing to a BCP and asking vendors to "you want this, it's BCP!" (or "Standard") isn't going to change much. CPE vendors will add it if you wave money at them, and not otherwise, no matter what label it carries. > 2. rfc2026 ???The Internet Standards Process??? says a BCP is the "best > current thinking on a statement of principle or on what is believed to be > the best way to perform some operations.??? What principle or what > operations is 464xlat best for? 464xlat is one possible approaches to enabling IPv4-to-IPv4 connections across an IPv6-only network that provides NAT64 services and no tunneling services. So if you have a NAT64 / IPv6-only network already and have to care for IPv4-only applications, this might be the best approach. If you need to transport IPv4 across an IPv6-only network and do not yet have a NAT64 to use, one of the MAP-E/MAP-T stateless "transport" variants might be a *better* solution, given the statelessness of the MAP gateway. So it depends on your network: if you want "IPv6-mostly" with a bit of remaining external IPv4 to be handled by the DNS64/NAT64, and a few stubborn applications insisting on literal IPv4 on the client side, 464xlat is "best". Otherwise, maybe not "WCP", but definitely just "one solution in the toolchest" Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Sep 22 11:48:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50900132697 for ; Fri, 22 Sep 2017 11:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJWRP9OBjm_I for ; Fri, 22 Sep 2017 11:48:50 -0700 (PDT) Received: from atl4mhob01.registeredsite.com (atl4mhob01.registeredsite.com [209.17.115.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF839134597 for ; Fri, 22 Sep 2017 11:48:50 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob01.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8MImlY2031564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Sep 2017 14:48:48 -0400 Received: (qmail 21579 invoked by uid 0); 22 Sep 2017 18:48:47 -0000 X-TCPREMOTEIP: 72.221.14.183 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.183) by 0 with ESMTPA; 22 Sep 2017 18:48:47 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 22 Sep 2017 14:48:44 -0400 From: Lee Howard To: , "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 18:48:53 -0000 On 9/22/17, 2:22 PM, "v6ops on behalf of JORDI PALET MARTINEZ" wrote: >Hi Lee, > >See below in-line. > >Regards, >Jordi >=20 > >-----Mensaje original----- >De: v6ops en nombre de Lee Howard > >Responder a: >Fecha: viernes, 22 de septiembre de 2017, 14:56 >Para: Lee Howard >CC: "v6ops@ietf.org WG" >Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info > > As to the original question, I have a couple of questions: > =20 > 1. What is gained by promoting rfc6877 "464XLAT: Combination of >Stateful > and Stateless Translation=E2=80=9D? Regardless of whether the correct >promotion > path is BCP or Proposed Standard, what is the goal? > >[Jordi] My point is: I understand that when 464XLAT was proposed, it was >not considered at the same level as other transition mechanisms, which >are, from the start, standards track. Now that this is the most >successful (in terms of number of users vs. all the other transition >mechanisms), in my opinion there is no reason to discriminate it. So, >either we drop to informational all the transition mechanisms that have >so much lower degree of success or even to historic or deprecated those >that are not used. Is a matter of fairness and recognize the reality. Well, rfc6877 doesn=E2=80=99t define a new protocol, it describes a way that existing technologies could meet a need. I=E2=80=99m trying to read it as a Technical Specification as defined by rfc2026, and I don=E2=80=99t see how it fit= s. Who is discriminating against the most successful mechanism based on its document track? > =20 > 2. rfc2026 =E2=80=9CThe Internet Standards Process=E2=80=9D says a BCP is the "be= st > current thinking on a statement of principle or on what is believed >to be > the best way to perform some operations.=E2=80=9D What principle or what > operations is 464xlat best for? > =20 >[Jordi] Well, I was suggesting standards track, not BCP. So not sure how >to read this question myself. Actually, I=E2=80=99ve drafted already (started tw= o >months ago, and not related at all to this discussion, but for lack of >time availability, haven=E2=80=99t completed it yet, hopefully can have it early >next week) a BCP which initially I=E2=80=99ve titled =E2=80=9C464XLAT Deployment >Guidelines in Operator Networks=E2=80=9D. The idea come out after we had the >discussion of deploying at the IETF network 464XLAT instead of just >NAT64. In this document I=E2=80=99m describing how, according to my experience >(and hopefully inputs from others once a first version is published), >464XLAT is being deployed in both cellular and non-cellular networks. Maybe I should have also asked the question, =E2=80=9CHow does rfc6877 meet the standard of an Internet Standard according to rfc2026?=E2=80=9D Lee From nobody Fri Sep 22 13:23:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D45F1345C7 for ; Fri, 22 Sep 2017 13:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VO1ceNJLowf9 for ; Fri, 22 Sep 2017 13:23:33 -0700 (PDT) Received: from atl4mhob21.registeredsite.com (atl4mhob21.registeredsite.com [209.17.115.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF1E1332E3 for ; Fri, 22 Sep 2017 13:23:31 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob21.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8MKNSUo067509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 22 Sep 2017 16:23:28 -0400 Received: (qmail 30569 invoked by uid 0); 22 Sep 2017 20:23:28 -0000 X-TCPREMOTEIP: 72.221.14.183 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@72.221.14.183) by 0 with ESMTPA; 22 Sep 2017 20:23:28 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 22 Sep 2017 16:23:24 -0400 From: Lee Howard To: Gert Doering CC: Ole Troan , "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> In-Reply-To: <20170922161018.GG45648@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 20:23:36 -0000 On 9/22/17, 12:10 PM, "Gert Doering" wrote: >Hi, > >On Fri, Sep 22, 2017 at 10:52:10AM -0400, Lee Howard wrote: >> Following adoption curves: >> The majority of hits on Google US will be IPv6 in six months. >> 80% of hits on Google US will be IPv6 in two and a half years. >> 90% of hits on Google US will be IPv6 in three and a half years. >> The majority of hits on Google worldwide will be IPv6 in two years. >> 80% of hits on Google worldwide will be IPv6 in four years. >> 90% of hits on Google worldwide will be IPv6 in five years. >>=20 >>https://www.vyncke.org/ipv6status/project.php?metric=3Dp&timeforward=3D2000&t >>im >> ebackward=3D2064&country=3Dww > >I like your optimism :-) It=E2=80=99s evergreen. > >But then, I look at mobile operators in Germany - the *incumbent* has >done their homework and is providing IPv6, but the "new kids on the block" >mobile operators (like, "younger, agile", and all this) are not even >having=20 >*plans* for IPv6 yet... I wonder if 5G will include native IPv4. Because I was replying to this message, I paused to publish this blog post about who would have the most impact on IPv6 deployment. It=E2=80=99s specific to the US (because worldwide numbers aren=E2=80=99t readily available) but it could be repeated for any other country. http://www.wleecoyote.com/blog/whomatters.htm In Germany, you=E2=80=99re looking for Vodafone, TDDE Telefonica, Digital Ocean, EWE, MNET, Linode, Telecolobus, and O2. Then it=E2=80=99s a long tail of smaller networks. I just ran the numbers, and 76% of Germans without IPv6 are behind Liberty Global, Kabel Deustchland, Telefonica, Deutsche Telekom, and Vodafone. Since DTAG, KD, and LGI have great deployments, I checked: Telefonica alone has 26% of IPv6-incapable users, and Vodafone 16%. Network Size Pct of IPv6-incapable Germans =20 =20 100K-1M 76% =20 =20 10K-100K 16% =20 =20 1K-10K 6% =20 =20 <1K 2% > > >And this is only eyeball networks. > >Right now, there's so much *content* IPv4-only that eyeball networks need >to put up CGN boxes to enable reachability to that content - and if these >boxes are in place anyway, what incentives does content have to enable >IPv6? Looking at the Alexa Top sites, I see lots of red on Eric's >page. Basically, everything that's not Google or happens to sit behind >Cloudflare (for DE)... :-( If 99% of eyeball hardware runs IPv6, then we look more to NAT64 than to 464xlat. And in the U.S., (according to that blog post), AWS and Akamai operate about 25% of the IPv6-incapable domains in the Top 1000. I don=E2=80=99t mean to say that we don=E2=80=99t need transition mechanisms. Transitio= n mechanisms are the way networks can move to IPv6-only [1] at different rates. Lee [1] For low values of =E2=80=9Conly" > >Gert Doering > -- NetMaster >--=20 >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Fri Sep 22 14:25:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8894132620 for ; Fri, 22 Sep 2017 14:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmu0ooSPVYU6 for ; Fri, 22 Sep 2017 14:25:23 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF0B13219B for ; Fri, 22 Sep 2017 14:25:23 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 552FD34C402; Fri, 22 Sep 2017 21:25:01 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 38C88160031; Fri, 22 Sep 2017 21:25:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 20D5316007C; Fri, 22 Sep 2017 21:25:01 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id b83x8W0M54Qo; Fri, 22 Sep 2017 21:25:00 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 80C66160031; Fri, 22 Sep 2017 21:25:00 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E0CFF87B00BA; Sat, 23 Sep 2017 07:25:02 +1000 (AEST) To: Gert Doering Cc: Ole Troan , "v6ops@ietf.org WG" From: Mark Andrews References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> In-reply-to: Your message of "Fri, 22 Sep 2017 14:21:46 +0200." <20170922122146.GY45648@Space.Net> Date: Sat, 23 Sep 2017 07:25:02 +1000 Message-Id: <20170922212502.E0CFF87B00BA@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 21:25:25 -0000 In message <20170922122146.GY45648@Space.Net>, Gert Doering writes: > > Hi, > > On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote: > > > On 22 Sep 2017, at 13:48, Gert Doering wrote: > > >> On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote: > > >> IPv6 applications need to add code to WORKAROUND breakages caused > > >> by NAT64 the way they need add WORKAROUNDS for the NAT breakages > > >> even if they are not using NAT64 or NAT respectively. The cancer > > >> that is NAT64 needs to be eradicated. > > >=20 > > > It will nicely go away if all endpoints are reachable over v6. > >=20 > > I think that?fs the concern. That it will not.=20 > > IPv6 applications will have code to accommodate for NAT64 forever.=20 > > Yeah, but you can't have the cake and eat it. Either we go v6-only > everywhere, or we keep running IPv4 everywhere until everybody else > is done, or we introduce v4/v6 NATs, or we add a CLAT to every single > operating system out there. Or we use any of the *other* IPv4 as a service technologies that are standards track. Some of which are actually being used in broadband deployments today to deliver IPv4 as a service with IPv6 only access networks. DS-Lite (RFC 6333 - Category: Standards Track) MAP-E (RFC 7597 - Category: Standards Track) CLAT is not needed. DNS64 is not needed. NAT64 is not needed. > What's it gonna be, boys? > > (Oh, "or we give up, roll back existing v6 deployments, and live happy > with v4 nat forever". FAR less work, and for Joe Average User, it won't > make a difference. Facebook and Youtube will continue to work, and > their IoT devices will keep drilling holes into firewalls to ensure that > they can be exploited no matter what) Stop exaggerating. Google went and added CLAT to the Android. They can just as easily add DS-Lite to Android and we would have billions of machines that support DS-Lite. Just because NAT64 and 464XLAT are sexy doesn't mean that it is good technology. Mark > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > --pfqPuNG9QX5dciZ9 > Content-Type: application/pgp-signature; name="signature.asc" > > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnFAFgACgkQ31bAZeTO > f8WrRw//a3xZjAzhiK5hI9m0mFG4QVJ/bKf8keSjulE0YGdw+1eE2PoAmgdZTYKT > vl2poBV98UnVRpn6OMru+kObCXI7OHY1zZmoqtBboCuqYYofA9rjN4SGdwn7Uagi > RtuTBGWm4AjMzQuHzz1if6QZab1sbnh9yKUxBYwAofqVlkOMm166SUGnoYwhixuC > /LIgUj53vVC67rPt+fi/UJaFS1Iu1FwaAPHS5vIexDfx8gDsGhfdQGw6OD4x5R9e > zU2Apx88O7cEV3xQbgINzBXF6JOGGq06P8t40Ln5WUv1BnrrGuifY3j4MxogGOpy > QMLskUMDYbfIg2OrFsaGSYBeuKFgP6f65ZjC2iKXNbqbbDy750/eiw/yp9KVCAoJ > fixd1c6itOZsBjZgCZEKmsU9MDhnD5cS3CX0c+I49k3IEHpdNfqk8bB+x6zKraRx > iTkWuL3okFFca7JBPZNgdNyTDmteSF0086+yCKkcTOa3XohYCYtjyBMon2dEKCfl > AkmYHFoxvMfx20PUGZdkwWJyI+WiM4mDm+F2KiPMO/RWcMfZNj0ZuG4948PH6WhJ > ei+yxJAeUPoMnqeSV+CQJrwRSSfm60YbFckocGZ7/4CuA5dmOc9U+KPyERyn7xid > hYBeJhoBSdxWA6jx1CTjlCPga5HVpbdDfMkmXSXkUNzRpA6aDrk= > =u0No > -----END PGP SIGNATURE----- > > --pfqPuNG9QX5dciZ9-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Sep 22 14:27:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385CD133054 for ; Fri, 22 Sep 2017 14:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqG1tnl6v5AT for ; Fri, 22 Sep 2017 14:27:48 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A49133053 for ; Fri, 22 Sep 2017 14:27:48 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0739640B9E for ; Fri, 22 Sep 2017 23:27:47 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id E080540B9D; Fri, 22 Sep 2017 23:27:46 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id D209A34044; Fri, 22 Sep 2017 23:27:46 +0200 (CEST) Date: Fri, 22 Sep 2017 23:27:46 +0200 From: Gert Doering To: Mark Andrews Cc: Gert Doering , Ole Troan , "v6ops@ietf.org WG" Message-ID: <20170922212746.GJ45648@Space.Net> References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="g2mi94udEzaDbVed" Content-Disposition: inline In-Reply-To: <20170922212502.E0CFF87B00BA@rock.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 21:27:50 -0000 --g2mi94udEzaDbVed Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Sep 23, 2017 at 07:25:02AM +1000, Mark Andrews wrote: > Stop exaggerating. Google went and added CLAT to the Android. They > can just as easily add DS-Lite to Android and we would have billions > of machines that support DS-Lite. Just because NAT64 and 464XLAT are > sexy doesn't mean that it is good technology. The goal cannot be to add more stateful machinery in the network, so DS-Lite has a good place in the WCP hall of shame. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --g2mi94udEzaDbVed Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnFgE8ACgkQ31bAZeTO f8XMVA//Qz58VcSRhVlhRQofwDcENBRyCWEPVd3HPhVSeqPkQNbScqpCy5bUpxj5 kwdA8WqZ/98uPPAb707Wik9KKSpSrACOu48RtsVwnz9Mxiuzv+MxtCkKbH1/q816 rRuu+d6nvYEP9tJw3qnQuHUEq1v6TmHDWmSg22kT1K0/b0DYdDn1AAQ/5l6Xl063 McLcYT1E9sjreD3LdMcsI8dE4z8SdZZv3NOP7/mx0P7Ye6BtM04xlgVZH+xmb6lB 65OfjA2DWbJO911OpR6k+L8UAQVGIK7ZkCcq9QMiNs58XWE9rM8SmdWWx0D/3f37 /2QWSOZfZs4Ntff40wqZQ/DLxGFhtww+YdR3Srn1qF7U0um3uDygoluZfD6jE6/b pIB6FD8lUk9CsjTNLwSoq9Hgb3A+boYjzYpDUrddXGFgwytq828JWhCxflVG2oRY XUenHXE2sRZZCjgzqBU0wU6HpRETpnKkETaiH69GSOY/LpEV1ZDPe/eJzxSt5Bvf D6Bbfloxaq6VUnuAnTI3jPQJ8IcqiCPaEiP4Ez3s05j8I81bnkrV7TXZ83FT4awW BH73TI8dbQDElRhlMrLMj01mVSBkBUAyRsRfAMuQMgLYA6/p6ylJ75Lay2b9kT66 toc3HPiWSGksDDA5suiKeQfm2g25ER0Zox+Zkr10WaB1zzJNwpk= =Dx7I -----END PGP SIGNATURE----- --g2mi94udEzaDbVed-- From nobody Fri Sep 22 14:38:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E6E132F3E for ; Fri, 22 Sep 2017 14:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85_5nG1-1Rze for ; Fri, 22 Sep 2017 14:38:40 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D18132143 for ; Fri, 22 Sep 2017 14:38:40 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 8C59624AFA5; Fri, 22 Sep 2017 21:36:45 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E0148160031; Fri, 22 Sep 2017 21:36:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CFDAA16007E; Fri, 22 Sep 2017 21:36:52 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Fl1agjbum5BT; Fri, 22 Sep 2017 21:36:52 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7E16E160031; Fri, 22 Sep 2017 21:36:52 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 736EA87B0253; Sat, 23 Sep 2017 07:36:55 +1000 (AEST) To: Gert Doering Cc: Philip Homburg , v6ops@ietf.org From: Mark Andrews References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922124641.GB45648@Space.Net> In-reply-to: Your message of "Fri, 22 Sep 2017 14:46:41 +0200." <20170922124641.GB45648@Space.Net> Date: Sat, 23 Sep 2017 07:36:55 +1000 Message-Id: <20170922213655.736EA87B0253@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 21:38:42 -0000 In message <20170922124641.GB45648@Space.Net>, Gert Doering writes: > Hi, > > On Fri, Sep 22, 2017 at 02:44:50PM +0200, Philip Homburg wrote: > > >Yeah, but you can't have the cake and eat it. Either we go v6-only > > >everywhere, or we keep running IPv4 everywhere until everybody else > > >is done, or we introduce v4/v6 NATs, or we add a CLAT to every single > > >operating system out there. > > > > You left out the option where the CPE or other first hop router offers > > native > > IPv4 to the host (probably involving some kind of IPv4 NAT, but that is > > more or less standard these days) and tunnels the complete IPv4 packet > > to > > the network's IPv4 gateway. > > > > This avoid all of the NAT64/DNS64 problems. > > And why is that a desirable end goal, cement IPv4 in everybody's home > networks? > > Either the goal is "get rid on IPv4 on as many cables as we can" or we > can just give up and interconnect IPv4 clouds over NAT gateways, using > whatever underlay in between - MPLS, IPv6, IPv4, it will not matter. DS-Lite is a CPE or node based solution like CLAT is a CPE or node based solution. Both can be used in either mode. Mark > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > --Ew9mJ7yfAEtQK+FR > Content-Type: application/pgp-signature; name="signature.asc" > > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnFBjAACgkQ31bAZeTO > f8WEXRAAjzTZM76c193jz+DwbAO8aeHr/r2iA3wYqO7aG6PEGcRjZ9WKxhuizzgG > +QyidLcLrL/RmO3S+Y4PjDR1ZuTCSDriZvBBV/cd5IN0LDcpQ6zoUQ4pvFx4tMkH > owq9lzZrqyJasVRGTB6hT1MrB5HfKolbg/oTnTYYLBnIzgpGeKzly0gJ3AaZhCp4 > bK+xjBVmO+F2DGRp1Ix2CzfeVVevssyZLfwHGurRIQYkrVtUXXgbmMLfwR6zRIH+ > bxCpw5QCQJd77SWQ12NquGLHZSGu9VUI3PFh/thW+/PD3WQhWg6eVcRj3jVFtyGp > MkV9viTc17jme/+bLmNcd07BSV4HxtMe+OQquodfSHmhohEsYZ8kdmeTunMFDv9i > RBN3DKZ5i9+PxS6zQRi+wwCBFnRVQCAPred05MKYUQCsehPpKPutprZhq0nYt93B > Tz9RGqxcXzQwFB+r4AzQFYN46vwjBbisH5VHEdPk3TZs93cNV/9LZQn+mhgegY++ > 9OWTq4gyWXN2OOtG+gwXrrdhh/9TCtcdyF+pTEviPo4AQSE0575w0AlFyr4nqbPU > 0HjQpxTV/3BciKjSxVveWctZqiqi3Gr5Xyr0S1oUxf/u7Jnz0KscF0ovU9Nwr6Pa > qycT8vF0y2dMztIg0jHPC8q8Ev5i2QOM72WI4y+KjBRtieDKy9M= > =XZ+h > -----END PGP SIGNATURE----- > > --Ew9mJ7yfAEtQK+FR-- > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Sep 22 14:53:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110A513292A for ; Fri, 22 Sep 2017 14:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCUaVKyuFxQZ for ; Fri, 22 Sep 2017 14:53:10 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CCE01321DC for ; Fri, 22 Sep 2017 14:53:10 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 0EB4B34C46E; Fri, 22 Sep 2017 21:51:55 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B624B160031; Fri, 22 Sep 2017 21:51:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 874E516007C; Fri, 22 Sep 2017 21:51:54 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Kc84Lh5tnDut; Fri, 22 Sep 2017 21:51:54 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B8600160031; Fri, 22 Sep 2017 21:51:53 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A88E987B03C1; Sat, 23 Sep 2017 07:51:56 +1000 (AEST) To: Ca By Cc: Gert Doering , "Rajiv Asati (rajiva)" , "v6ops@ietf.org WG" From: Mark Andrews References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> In-reply-to: Your message of "Fri, 22 Sep 2017 13:07:34 +0000." Date: Sat, 23 Sep 2017 07:51:56 +1000 Message-Id: <20170922215156.A88E987B03C1@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 21:53:12 -0000 In message , Ca By writes: > On Fri, Sep 22, 2017 at 5:45 AM Rajiv Asati (rajiva) > wrote: > > > > > I don't think that there any iOS app that is not IPv6-only compatible > > (since the apple AppStore mandate more than a year* ago). Is there one ? > > > > I am simply here to disabuse you of the notion that this rule has been > perfect for the folks involved. > > > > If Google playstore could mandate something similar (perhaps, there is one > > that I am not aware of), then almost all mobile UEs can happily live with v > 6-only > > without any Clat function. Better battery life, likely. > > > > Fully agree. What if Google playstore cannot / will not enforce such a rule > ? We in v6ops / sunset4 are well aware that asking for a poney seldom > results in a poney .... hence warty solutions that thread one needle to > move another needle. Putting the E back into IETF. > > > > Hence, There is no need for XLAT being a BCP at this time in that regard. > > > > Of course, NAT64 inside the network would still be needed to accommodate > > the smaller (% of traffic) v4-only internet connectivity. But that's an > > ongoing saga of another debate. > > > > > > > > However, there is one exception - tethering :: > > DS-Lite accomodates tethering. It's in millions of broadband CPE devices today 'tethering' the home IPv4 network to the rest of the world over IPv6 access networks. > Ah. What little control we have. > > > > if mobile UE is tethered and the other devices connecting to its W/LAN are > > stuck in legacy v4-only, then mobile ISPs might prefer to not leave them > > behind to ensure customer experience. What "technical" options do we have > > then? Well, really two == Let go of v6-only access (provide an IPv4-only > > APN if tethering is enabled resulting in a dual-stack UE) or stick with > > v6-only access, but turn on CLAT function !! > > > > Cheers, > > Rajiv > > > > > > * https://developer.apple.com/support/ipv6/ > > > > > > On Sep 22, 2017, at 8:22 AM, Gert Doering wrote: > > > > Hi, > > > > > > > > On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote: > > > > On 22 Sep 2017, at 13:48, Gert Doering wrote: > > > > On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote: > > > > IPv6 applications need to add code to WORKAROUND breakages caused > > > > by NAT64 the way they need add WORKAROUNDS for the NAT breakages > > > > even if they are not using NAT64 or NAT respectively. The cancer > > > > that is NAT64 needs to be eradicated. > > > > > > It will nicely go away if all endpoints are reachable over v6. > > > > > > I think that?fs the concern. That it will not. > > > > IPv6 applications will have code to accommodate for NAT64 forever. > > > > > > Yeah, but you can't have the cake and eat it. Either we go v6-only > > everywhere, or we keep running IPv4 everywhere until everybody else > > is done, or we introduce v4/v6 NATs, or we add a CLAT to every single > > operating system out there. > > > > What's it gonna be, boys? > > > > (Oh, "or we give up, roll back existing v6 deployments, and live happy > > with v4 nat forever". FAR less work, and for Joe Average User, it won't > > make a difference. Facebook and Youtube will continue to work, and > > their IoT devices will keep drilling holes into firewalls to ensure that > > they can be exploited no matter what) > > > > > > > > Gert Doering > > -- NetMaster > > -- > > have you enabled IPv6 on something today...? > > > > SpaceNet AG Vorstand: Sebastian v. Bomhard > > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > > D-80807 Muenchen HRB: 136055 (AG Muenchen) > > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > _______________________________________________ > > > > > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Fri Sep 22 15:50:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667F9132705 for ; Fri, 22 Sep 2017 15:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uipwKZusAxt for ; Fri, 22 Sep 2017 15:50:04 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4501321DE for ; Fri, 22 Sep 2017 15:50:04 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id i130so1300970pgc.3 for ; Fri, 22 Sep 2017 15:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cNNRfB+R055SbDgXPsJaDtxVNeGfXlOWKpRcBDQVtyE=; b=WQs6Y1c+8cE+AgAH84cl310K/OSivLnpggwNB1RHY9uNZnvxzTX319KOyOE6UrIgXw Ou63OlhTSmrfg0qWibjXLOYChw3B6aYMJv4Y5V3WnB+e1c01PuWPYLDxhlTF6xfNzWb9 1Qu3seoSCFrVMZnCyQw1FeKOHZ9m8ASVs07x+XwRUUBKRmhH5PfjyZr7efqZxQ1E8ejq NNH5Ok2JUfYqhJpTzcDaUSfVpQl8qLdXwyst/ZO+WquMkFw3v1Cu3pACJ+LrSRA1lNbj K+i2IyqyZkkOvtONFozI3CCnBomhp3qwjyJtJpZg+viBU+1sz5Tq+9xhqfFwM4PMGZ0K S32A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=cNNRfB+R055SbDgXPsJaDtxVNeGfXlOWKpRcBDQVtyE=; b=bNNKPOwSwpPzcPkb2uiLKWyWIP0AxDcn2laR9FJWgj9D1DveV7WlE5jODlK8AjjDe1 +Nbo6ZKBTO8IjaiOqaculK3FcYw4e1mykBFQYnekuzzAYlnkYyp4ZBOFW/ktYaF1PzqC XxF4VHASfeJ052LMfHnWgndxVQJp9CKFSwh8g8v/pe1lgIXpoh54Pd1qCjy5UQI1by/8 Nv2CnHjmbzGmqTxs9OMsEAVHGnnCvU4xbgpEXm6AOaM4s+Ck4w80M45MpvswcM6QZlCT SgVpqrhMtl9rYuEtlCb++yG+3+nRSDkCSlOHOHhTvm4rHMtR5PrziERHWyNbLxBfHKQe Hg9A== X-Gm-Message-State: AHPjjUgXz37a6vxFhzHR31pkVdBGxIzahvewx4+GqdY0ibx530NfaSnD wakmJN3RyXyu0jysUAKjZKxCTg== X-Google-Smtp-Source: AOwi7QALX3Frw+p/bIpb8xL3AKc82nLw/fwgvg6DnInLxJZDYsGKd0R5549c4zwKMtEAVwfKtJV8qA== X-Received: by 10.99.99.197 with SMTP id x188mr537490pgb.49.1506120603648; Fri, 22 Sep 2017 15:50:03 -0700 (PDT) Received: from ?IPv6:2406:e001:3f51:1:28cc:dc4c:9703:6781? ([2406:e001:3f51:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 89sm1000655pfn.75.2017.09.22.15.50.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Sep 2017 15:50:01 -0700 (PDT) To: Ole Troan Cc: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> Date: Sat, 23 Sep 2017 10:50:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2017 22:50:06 -0000 On 22/09/2017 19:22, Ole Troan wrote: >>> We have a problem in that people confuse "a standard" with "the standard" >>> and >>> "a best current practice" with "the best current prcatice". But in the >>> end that's >>> just a matter of wording in the Abstract and Introduction. We say: if you >>> want >>> to run a pure IPv6 network service while supporting IPv4-only clients and >>> servers, >>> and do not wish to use any form of IPv4-in-IPv6 tunnel, here is a good >>> way to do it. >> >> I'd argue it is a "way to do it". Good is not a adjective I'd apply >> to it as it has lots of side effects that impact others that are >> NOT using it the same way as NAT impacts every developer that uses >> IPv4. >> >> Because 464XLAT is almost always deployed with DNS64 (there are >> potentially other ways to learn the address mappings): >> >> YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING >> TERMINATED ON A IPV6 NODE. This restricts what you can do with >> that connection. This impacts on EVERY developer. >> >> DNS64/NAT64 and 464XLAT needs to die and the earth needs to be >> salted where they are buried. They are not like NAT44 where there >> no other viable alternative. There are plenty of alternatives. > > From the perspective of forcing every IPv6 application to have to be able to deal with connecting to an IPv4 endpoint. > Breaking DNSSEC. > Requiring stateful devices in the network. > > I would suggest this belongs in the newly invented document category: WCP - Worst Current Practice. How about Best Current Practice for the Worst Current Solution? I have never advocated v4/v6 translation. I said it was a bad thing before IPv6 was even designed: https://tools.ietf.org/html/rfc1671#page-3 But we're apparently stuck with it. Brian From nobody Fri Sep 22 17:14:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF521331F2 for ; Fri, 22 Sep 2017 17:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 79vMfM4NF2PO for ; Fri, 22 Sep 2017 17:14:28 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DA913304A for ; Fri, 22 Sep 2017 17:14:28 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id m72so3803872wmc.0 for ; Fri, 22 Sep 2017 17:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+ntFNRu6ID6d5HxXZ3t+t4E5Ahs43fYlr2GfONkB1Vg=; b=JAIUwauVbqLTGRKZRqq81e09mjv7lScGWk21PEWWGCx3Calh8azfXFWe334GoOpZjF 8tBxas08+gE1+A27rxf539p8ZyS99RKuiFeFFbryaWSzHx1dlivtR2/zgHeDAUniKywX 3Lvlr4MSRJ09wdtjjg0fueROv66DlezMpbh/mgtYmS94YOfKEoRvWzPErC2eUA94Ql5d rCiUX7C2XqLS9/ZtTTSnT4ym74qutbycSl1FiL9gOK1sMHmeWiD/rabuTMDu2yKQBtyQ Hc13xYIWLyarI5dAMH9x1Tbx7Hjv9ezHrJQIdWpvSUhOWtdr0BI7IcgXd8vXejINTvk2 yKAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+ntFNRu6ID6d5HxXZ3t+t4E5Ahs43fYlr2GfONkB1Vg=; b=td+VrYgiya5AKiQLsTo33ST2+YuQBq8WRNRUyAYfn1jMMpMP0j7y2diWX55icKgQqt K0Slw/NuQhvlT9K48ibGZQSYfRJ5MFYNmCnE0pkjBl539X7xY7b44e/c2yVjMz7Z6t6a zkyXTicIF+xKSYuO45BtNG8/wLnUwiycMOAKD9zs5K0Fq/5bS/2NUajuIvqB3GlAD4+7 4y6khHk/gXM4Z+wAH2Fhzit2WrvA8FRhNDcvMrxnKFDugfAZGjCYSYJhO0vGYhyF86PJ k5fQc/DTQ6vRJe0YdsOs1o68Y/s2Vsf099OixUi+DVfB7FzsyL7etSls+M+UHVgmDTgC sDwg== X-Gm-Message-State: AHPjjUjHCEk2fWCNPUpCtoHKhsFU7TOwLbgg9E9uRwzFTFZAM8Q/nrzQ yRFGgrHRDhU+aJ4b/KF2Js3xooiLlNaNtsJRKocqUw== X-Google-Smtp-Source: AOwi7QBjB/p8kCxI34jRIqlBsoCf7OYxceltCajVuGyLW81EYSzX2ubl0k+0a2QrNVHvmiOH1PwIMTN6tOKnVO07Vr8= X-Received: by 10.28.64.6 with SMTP id n6mr5412384wma.61.1506125666415; Fri, 22 Sep 2017 17:14:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Fri, 22 Sep 2017 17:14:05 -0700 (PDT) In-Reply-To: <20170922161337.GH45648@Space.Net> References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> <20170922161337.GH45648@Space.Net> From: Erik Kline Date: Sat, 23 Sep 2017 09:14:05 +0900 Message-ID: To: Gert Doering Cc: Lee Howard , "v6ops@ietf.org WG" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114b32ec5d147b0559d035f7" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 00:14:30 -0000 --001a114b32ec5d147b0559d035f7 Content-Type: text/plain; charset="UTF-8" On 23 September 2017 at 01:13, Gert Doering wrote: > Hi, > > On Fri, Sep 22, 2017 at 06:10:18PM +0200, Gert Doering wrote: >> Right now, there's so much *content* IPv4-only that eyeball networks need >> to put up CGN boxes to enable reachability to that content - and if these >> boxes are in place anyway, what incentives does content have to enable >> IPv6? Looking at the Alexa Top sites, I see lots of red on Eric's >> page. Basically, everything that's not Google or happens to sit behind >> Cloudflare (for DE)... :-( > > Oh. As a side note, "a fried" tells me that a major audio streaming > platform in DE had to turn off IPv6, because Samsung. > > "If we listen to the stream over IPv4, and the phone goes to sleep, the > stream will continue playing. If we listen over IPv6 and the phone goes > to sleep, it will stop". > > Since there is no way to get Samsung to fix their shit (like, Google, > having proper requirements for Android vendors...) the radio station > decided that it's not worth the hassle and just turned off IPv6 again - > much less work than building something into their platforms that redirects > broken clients to an IPv4-only site and keeps IPv6 for the rest. A compliance test suite (CTS) test case was added to catch and prevent this behaviour, in the Marshmallow time frame. --001a114b32ec5d147b0559d035f7 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgzFkii4Tqi9AIS/cVlorSRsyoH+XhoD4d 6eCahHzX3aAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTIz MDAxNDI2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAHiOplQQL+Vk/VjJ26BVJCRZhnlcZ+3xpgSGmaJX24TcdzRGEdiT 97cO8juJo9ZpTjSEv3Ad34eqjG1+pmTJZl5h+piJH1ksee3NANt9Ch9M3xCNWPD3dbZrI6nT+ywG wrTZxsimPsHVlhjT58gGj9E0WH0udBL1puirx38SsjTSrVZfLxoDGOoNiN8NER6WNJLOCXL/5V3V J3cceXjN3kF5hKCmVEIv+cBRmE3ernF09DO86Qh5KH+lVv+FnhMY0ELJp2IIGbwl8SUYMIYqffuZ UbICtzUHAfGHqFaWfRTX49vIF+8bE3rdEHJGTWdrXQKp998MEWmZI12Kg2vD7gw= --001a114b32ec5d147b0559d035f7-- From nobody Sat Sep 23 05:08:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723371332D7 for ; Sat, 23 Sep 2017 05:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_ohil32gc7y for ; Sat, 23 Sep 2017 05:08:08 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E772132939 for ; Sat, 23 Sep 2017 05:08:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8NC86hf015059 for ; Sat, 23 Sep 2017 14:08:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8489F20361A for ; Sat, 23 Sep 2017 14:08:06 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7ACCC2029C3 for ; Sat, 23 Sep 2017 14:08:06 +0200 (CEST) Received: from [132.166.84.27] ([132.166.84.27]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8NC85jB028610 for ; Sat, 23 Sep 2017 14:08:06 +0200 To: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> From: Alexandre Petrescu Message-ID: <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> Date: Sat, 23 Sep 2017 14:08:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 12:08:10 -0000 Le 23/09/2017 à 00:50, Brian E Carpenter a écrit : > On 22/09/2017 19:22, Ole Troan wrote: >>>> We have a problem in that people confuse "a standard" with "the >>>> standard" and "a best current practice" with "the best current >>>> prcatice". But in the end that's just a matter of wording in >>>> the Abstract and Introduction. We say: if you want to run a >>>> pure IPv6 network service while supporting IPv4-only clients >>>> and servers, and do not wish to use any form of IPv4-in-IPv6 >>>> tunnel, here is a good way to do it. >>> >>> I'd argue it is a "way to do it". Good is not a adjective I'd >>> apply to it as it has lots of side effects that impact others >>> that are NOT using it the same way as NAT impacts every developer >>> that uses IPv4. >>> >>> Because 464XLAT is almost always deployed with DNS64 (there are >>> potentially other ways to learn the address mappings): >>> >>> YOU DO NOT KNOW IF THE IPV6 CONNECTION YOU ARE MAKING IS BEING >>> TERMINATED ON A IPV6 NODE. This restricts what you can do with >>> that connection. This impacts on EVERY developer. >>> >>> DNS64/NAT64 and 464XLAT needs to die and the earth needs to be >>> salted where they are buried. They are not like NAT44 where >>> there no other viable alternative. There are plenty of >>> alternatives. >> >> From the perspective of forcing every IPv6 application to have to >> be able to deal with connecting to an IPv4 endpoint. Breaking >> DNSSEC. Requiring stateful devices in the network. >> >> I would suggest this belongs in the newly invented document >> category: WCP - Worst Current Practice. > > How about Best Current Practice for the Worst Current Solution? > > I have never advocated v4/v6 translation. I said it was a bad thing > before IPv6 was even designed: > https://tools.ietf.org/html/rfc1671#page-3 Maybe RFC1671 page 3 bullet "C" is a BCP. > But we're apparently stuck with it [tunn/translate/DNS transitioning > mechanisms]. Yet a common denominator among Current Practices of transitioninig is: double stack. A smartphone runs ok native IPv4 and native IPv6 simultaneously, without needing translations nor encapsulations nor DNS v6-v4 mappings. Is double stack BCP? A few RFCs mentioning "dual stack" seem to be on StdsTrack (not BCP). They seem all to involve some tunnelling or translation. But double stack, understood as coexisting simultaneous use of IPv4 and IPv6 independently, on the same Computer, without tunnelling, nor translation, nor DNSv46 - could very well be a BCP. Alex From nobody Sat Sep 23 05:56:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BE413337F for ; Sat, 23 Sep 2017 05:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAthZ4qz5GE0 for ; Sat, 23 Sep 2017 05:56:06 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345E613339A for ; Sat, 23 Sep 2017 05:56:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8NCu0lR042187; Sat, 23 Sep 2017 14:56:00 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5AE632036C2; Sat, 23 Sep 2017 14:56:00 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4B331203565; Sat, 23 Sep 2017 14:56:00 +0200 (CEST) Received: from [132.166.84.27] ([132.166.84.27]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8NCtw2h015646; Sat, 23 Sep 2017 14:55:59 +0200 To: Ca By , Owen DeLong Cc: v6ops@ietf.org References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> From: Alexandre Petrescu Message-ID: <22028868-5f6a-ed5d-dea7-a7347866650a@gmail.com> Date: Sat, 23 Sep 2017 14:55:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - Apple iPhone X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Sep 2017 12:56:09 -0000 Le 21/09/2017 à 14:02, Ca By a écrit : [...] > [...] > >     But you cant have simultaneously CLAT and DHCPv6-PD on the > same client. > > > > > > I do not agree,  Please state what is structurally preventing this. > > RFC6877 specifically calls for using dhcpv6-pd > > RFC is one thing, but many implementations block some RFCs. > > What structurally prevents this is that there are very numerous Android > devices. > > > Say the same about Apple. Show me Apple running dhcpv6 on LTE interface. Nothing would, but I would like to look closer at this for a while. Do you think one needs to root-risk an iPhone before one could add an IP address to its interface? (root-risking is a special operation during boot time whereby one needs a special code from hardware manufacturer, one is asked to agree to the risk of 'rooting' the device, responsibility; this is a make-or-break operation; the device is expensive, so money is at risk - if the operation does not succeed, then the iPhone may die entirely, no way to recover.) Alex From nobody Sun Sep 24 10:50:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096C7132D53 for ; Sun, 24 Sep 2017 10:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGXBUocB_Wu8 for ; Sun, 24 Sep 2017 10:50:51 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F15AB13219C for ; Sun, 24 Sep 2017 10:50:50 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9824740BA0 for ; Sun, 24 Sep 2017 19:50:47 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 786BC406DE; Sun, 24 Sep 2017 19:50:47 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 691EB330A2; Sun, 24 Sep 2017 19:50:47 +0200 (CEST) Date: Sun, 24 Sep 2017 19:50:47 +0200 From: Gert Doering To: Erik Kline Cc: Gert Doering , Lee Howard , "v6ops@ietf.org WG" Message-ID: <20170924175047.GR45648@Space.Net> References: <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> <20170922161337.GH45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary="i2mpxYa7/7AFWjhN" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 17:50:53 -0000 --i2mpxYa7/7AFWjhN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Sep 23, 2017 at 09:14:05AM +0900, Erik Kline wrote: > On 23 September 2017 at 01:13, Gert Doering wrote: > > Oh. As a side note, "a fried" tells me that a major audio streaming > > platform in DE had to turn off IPv6, because Samsung. > > > > "If we listen to the stream over IPv4, and the phone goes to sleep, the > > stream will continue playing. If we listen over IPv6 and the phone goes > > to sleep, it will stop". [..] > A compliance test suite (CTS) test case was added to catch and prevent > this behaviour, in the Marshmallow time frame. This is great news, and thanks for it. Now, how can we get all those vendors with a big S to ship Android upgrades for their phones on the market? (We'd *really* like bring back this host to the IPv6 world... and we can't while the market share of unfixed devices is still so high. So=20 maybe in a year or so...) Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --i2mpxYa7/7AFWjhN Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIODwYJKoZIhvcNAQcCoIIOADCCDfwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggslMIIFcjCCBFqgAwIBAgICAQIwDQYJKoZIhvcNAQEFBQAwgZQxCzAJBgNVBAYTAkRF MQ8wDQYDVQQHEwZNdW5pY2gxFDASBgNVBAoTC1NwYWNlTmV0IEFHMR4wHAYDVQQLExVaZXJ0 aWZpemllcnVuZ3NzdGVsbGUxGTAXBgNVBAMTEFNwYWNlTmV0IFJvb3QgQ0ExIzAhBgkqhkiG 9w0BCQEWFGRhdGFjZW50ZXJAc3BhY2UubmV0MB4XDTExMTAxOTE2MjAzM1oXDTI2MTAxNTE2 MjAzM1owgZQxCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNzcDExFDASBgNVBAoTC1NwYWNlTmV0 IEFHMR8wHQYDVQQLExZad2lzY2hlbnplcnRpZml6aWVydW5nMRswGQYDVQQDExJTcGFjZU5l dCBMZXZlbDIgQ0ExIzAhBgkqhkiG9w0BCQEWFGRhdGFjZW50ZXJAc3BhY2UubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0TZfc3M8GIjLwvISEA8/c5DYYOzGk82PdjkK LzV0KWg5fOL5XN3QZMNjhspIrwNX4KlUfhhlV6XQ0XoYByJ9OS6IeUgK2DeRrCqZ1FC9zxWD MUy56Uq5cULUH+dGRUTnCYUX55VNpVYG8OSSIHO8wl0AsSArTevBkLySdoDNXxeQjEaNPQFG BANiDYCyOtjswsFGM7HleGUfEDgkqFbwsXrcroHL6FIfTQoVQWEN3fY2JbbLXN+xcqOEd4Ih HfDnPCFtiS3ahAJjEOQ42mcfCpwambPX2fHBGhWuQLEropKoy7ba5DVcs/BhsdLxV2Bs/dPx 7ZVEmYLak+hZk1DatwIDAQABo4IByjCCAcYwHQYDVR0OBBYEFI/AuOF8TILZ9MBdi4dYqe5E gHR2MIHBBgNVHSMEgbkwgbaAFGcpxe17gXP8uKsBPqyov4kcFy7koYGapIGXMIGUMQswCQYD VQQGEwJERTEPMA0GA1UEBxMGTXVuaWNoMRQwEgYDVQQKEwtTcGFjZU5ldCBBRzEeMBwGA1UE CxMVWmVydGlmaXppZXJ1bmdzc3RlbGxlMRkwFwYDVQQDExBTcGFjZU5ldCBSb290IENBMSMw IQYJKoZIhvcNAQkBFhRkYXRhY2VudGVyQHNwYWNlLm5ldIIBZTAPBgNVHRMBAf8EBTADAQH/ MAsGA1UdDwQEAwIBvjBMBggrBgEFBQcBAQRAMD4wPAYIKwYBBQUHMAKGMGh0dHA6Ly9ldWts aWQuc3BhY2UubmV0L2NlcnQvc3BhY2VfU3BhY2VSb290LmNlcjBBBgNVHR8EOjA4MDagNKAy hjBodHRwOi8vZXVrbGlkLnNwYWNlLm5ldC9jZXJ0L3NwYWNlX1NwYWNlUm9vdC5jcmwwEQYJ YIZIAYb4QgEBBAQDAgEGMB8GA1UdEQQYMBaBFGRhdGFjZW50ZXJAc3BhY2UubmV0MA0GCSqG SIb3DQEBBQUAA4IBAQAJ0v/AgH8QHyr+bWIavj/z7ITuqPGWEloPbcuw/icljb4mLmAsp8d9 q77k7mXxgzqBmxIrwcuEdL3l22ZrTnWikiYrKMQ97UssNubnVd6p3hD+nOmygusHJ+drSie8 siFokUjlo8tv+bQzriKtLNuwNKHAFvSH3lypBiQvDAyS7ylTgkfM7BDuaLYw3xsBPvCPRI+U /nzh6ACofz+vogWm5VshW+GhqFQBqcL+gMTm1iW8xLNZ0Z542sTdvSK59YgC/Bhp5kXckgFY IMGI5F2LJ83Iw/izBl5aD5j9Cnv/d341fIUvzSHXoXOIYT7UP/pjvZAk1xD332WWfEahTO4O MIIFqzCCBJOgAwIBAgICAzEwDQYJKoZIhvcNAQELBQAwgZQxCzAJBgNVBAYTAkRFMQwwCgYD VQQIEwNzcDExFDASBgNVBAoTC1NwYWNlTmV0IEFHMR8wHQYDVQQLExZad2lzY2hlbnplcnRp Zml6aWVydW5nMRswGQYDVQQDExJTcGFjZU5ldCBMZXZlbDIgQ0ExIzAhBgkqhkiG9w0BCQEW FGRhdGFjZW50ZXJAc3BhY2UubmV0MB4XDTE2MTEwMjEwNTAyM1oXDTE3MTExNjEwNTAyM1ow gZcxCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNzcDExDzANBgNVBAcTBk11bmljaDEUMBIGA1UE ChMLU3BhY2VOZXQgQUcxDjAMBgNVBAsTBXVzZXJzMRUwEwYDVQQDEwxHZXJ0IERvZXJpbmcx HTAbBgkqhkiG9w0BCQEWDmdlcnRAc3BhY2UubmV0MQ0wCwYDVQQrEwRnZXJ0MIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAstQ0lY62WmGZV1NxsT80jMBo1ilFOOo0B2lWYAkK lr0N5gwZOtu6WvGf7kFboCBqGUu+++ZPi6DdOqfyCwgPttrIVJxUHExSaWon0xjvgCvSgfLr dmI4mgm/wAwaStY8cxvO+u0LgKxW2SBxCsba9nVIhMlK/848VhUV0kqunpxwdEk71a65K6J6 UMhMLmyjBHN4lvY54GkfJGRVQneh4is1TraTOTBSEMIfKSe6osiwhqrgW9pORQi1p/0eoitn 5Hv92XZ44zSY7uPD8i5DTuO5oT4AUMMbWSW9k8XwlRLezXs2OBtLExn8eLJCFNAOgtL56F/+ ZN6IGhRmW0CC4wIDAQABo4ICADCCAfwwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw JwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDAzAdBgNVHQ4EFgQUwLN/ sVI7xvpVzcIu9GdYLQ3eysowgcIGA1UdIwSBujCBt4AUj8C44XxMgtn0wF2Lh1ip7kSAdHah gZqkgZcwgZQxCzAJBgNVBAYTAkRFMQ8wDQYDVQQHEwZNdW5pY2gxFDASBgNVBAoTC1NwYWNl TmV0IEFHMR4wHAYDVQQLExVaZXJ0aWZpemllcnVuZ3NzdGVsbGUxGTAXBgNVBAMTEFNwYWNl TmV0IFJvb3QgQ0ExIzAhBgkqhkiG9w0BCQEWFGRhdGFjZW50ZXJAc3BhY2UubmV0ggIBAjBO BggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9ldWtsaWQuc3BhY2UubmV0L2Nl cnQvc3BhY2VfU3BhY2VMZXZlbDIuY2VyMBkGA1UdEQQSMBCBDmdlcnRAc3BhY2UubmV0MB8G A1UdEgQYMBaBFGRhdGFjZW50ZXJAc3BhY2UubmV0MEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6 Ly9ldWtsaWQuc3BhY2UubmV0L2NlcnQvc3BhY2VfU3BhY2VMZXZlbDIuY3JsMA0GCSqGSIb3 DQEBCwUAA4IBAQCbUZCcxxopU5RD9+BfA9u+uhqEl/C45p/7y8/m4ANphan0GCGlTSl8tWZ0 bU+IIOrqG94W9v0MGOUnVUNgHD5VVt9MPZFxUsGn6Ac5CWbAhqClABxZbcQLROguG9JYfTmX Zebl19iUN7vbKvv9U1IFQBGDBlpnm1PtypqsuwXQYQHSZD31XsV7ALMIzAaYhkts9xOySFfm zPlFj3D8pj/vUfbcqaNNOgiZLqEXb71ynXQcA1cEr2iDCLWejfq3BJoxP3fZLjwBY9us7td0 LtRoha/nVvx0HHXFVI1XDwH7tGtN80LzprNTcWltcWEjwk6gD2CNakhew0P2hzIMzEjIMYIC rjCCAqoCAQEwgZswgZQxCzAJBgNVBAYTAkRFMQwwCgYDVQQIEwNzcDExFDASBgNVBAoTC1Nw YWNlTmV0IEFHMR8wHQYDVQQLExZad2lzY2hlbnplcnRpZml6aWVydW5nMRswGQYDVQQDExJT cGFjZU5ldCBMZXZlbDIgQ0ExIzAhBgkqhkiG9w0BCQEWFGRhdGFjZW50ZXJAc3BhY2UubmV0 AgIDMTANBglghkgBZQMEAgEFAKCB5DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzA5MjQxNzUwNDZaMC8GCSqGSIb3DQEJBDEiBCBlgfMVNsgWB2bMYPh3 PwdzQp63/dscEBCjdvpscKD83TB5BgkqhkiG9w0BCQ8xbDBqMAsGCWCGSAFlAwQBKjALBglg hkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBT kDpUcqMwuajPhkxJx+TLuIAg0iiEefU8Z2KIXG03FIFashoQNjERq4JXm+lZgUpNOVnmWTKL 3xbT3MD1Cz03TMPczjsXSXZnRFSIV2Jez1bCioStHy1m7rcPbaM6u7Eok7s4ofcUcfwQtNKd OvqX9t7kU2vHNwQNFTl+7Nh1d4JwTc8mWy9wn2htBL9fXvMnjIMUNP4RUD/gkbuNq1xwhIrh kQS9TMiYhZLEl+BwVn+/sE7ZEjSZl5AD9qKPnB8J+dHpri83pU1iLCPWL79afkSD1GND762r Rjr9ANkqzx6IUTGFAaDNFtaNb0Nq7+ZOwc3Y0EyVzd6sOs1IGJOF --i2mpxYa7/7AFWjhN-- From nobody Sun Sep 24 18:33:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7398133038 for ; Sun, 24 Sep 2017 18:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 44wr5KMe9gEE for ; Sun, 24 Sep 2017 18:33:42 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311FD133020 for ; Sun, 24 Sep 2017 18:33:42 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id u205so3775377ywa.5 for ; Sun, 24 Sep 2017 18:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VJCW1UTs9fgB7UxpFUdzXtA4NfLsVe87qtaD9mcUOQ4=; b=qpr70IgKO81vJsGCEX5XxEY2QuPeEuDQ1HYWzVF+G1Q6/qinLGK6hFJtp8VobFWlYn 15GiBOvRfoRuzdZYDPCPCi65QjhxoL0Kxq+tGMJXDkR2ZyqqrrU+Hyr1YlMrpYNbhUev 6PJIoh4muXB1Z96mtPz3UmHbze4ZFC4g0s1pQ/Idk5zv+0i4128KuNvtcbeNEQb8xGyJ 2SaCgtvdV0Zt9EFp6y9N9yg+tUPIUpUB2xHdWulJFy7462knSwOijWBs88tkzYbLRjqZ bUKnCWjxvEwlZK5Fp92X5Zqzv5zW9UlvDFyVUo2rn28Id5XLVQOJaQlmtFwbp5oG505U QtsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VJCW1UTs9fgB7UxpFUdzXtA4NfLsVe87qtaD9mcUOQ4=; b=OrQO0I5p9CODxBTO5DjzJF2YM3p5adOEPofybFWRRBCbycDS1HwXvQIWWznLo/9bm+ 6Qtv0t7T4avIVi0VZW1P+Yueunb1OBJ8/o5gutPpqw3uHRYwKXbaG46wFiu2NqCG8S+K mTaC+oCD5Fw4wXd0qjaPD9wfn3pC4e4KrrV/HYA8PHPGVh0wPHc01qSpBXyy52r4PmyP WLRZ0m2+E5WmS0LmFaAsY2T41ohy/H07EvZDWPREz4JnCcQ8IL8GHA8qT1mr1PLiMEjo hgGvSriWt/KZw6bVmqYKR9Aeb5WT3zNTLKoMhjNmeDJUGOe4ZN7V0FBmSHb/afIAg1QW SC3g== X-Gm-Message-State: AHPjjUjnhLfeIBozXDQ48QqoXzYW6HOWaGiarWcYhmmVxuCQSiCe7+mJ vL3NjDUaUoAf3eydS0rxE7jS1qE2rbB9N0oW1YdV/0AQ X-Google-Smtp-Source: AOwi7QAmfYLPpuZqmNdrgVJMM1UH1zKQjG2QYSgQHhQcXDaQS2kTWZEKMTZdq3fIwFUSma0mXkO1PCCtPCa5OlEShgM= X-Received: by 10.13.235.84 with SMTP id u81mr3559312ywe.328.1506303220976; Sun, 24 Sep 2017 18:33:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Sun, 24 Sep 2017 18:33:19 -0700 (PDT) In-Reply-To: <20170922161337.GH45648@Space.Net> References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> <20170922161337.GH45648@Space.Net> From: Lorenzo Colitti Date: Mon, 25 Sep 2017 10:33:19 +0900 Message-ID: To: Gert Doering Cc: Lee Howard , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c0880146a0b400559f98c13" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 01:33:44 -0000 --94eb2c0880146a0b400559f98c13 Content-Type: text/plain; charset="UTF-8" On Sat, Sep 23, 2017 at 1:13 AM, Gert Doering wrote: > Since there is no way to get Samsung to fix their shit (like, Google, > having proper requirements for Android vendors...) We actually do have a conformance test for this (but it only affects devices on Android M or later). If you find devices that fail this test, please let us know. --94eb2c0880146a0b400559f98c13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Sep 23, 2017 at 1:13 AM, Gert Doering <gert@space.net> wrot= e:
Since there is no way to get Samsung t= o fix their shit (like, Google,
having proper requirements for Android vendors...)

We actually do have a conformance test for this (but it only affect= s devices on Android M or later). If you find devices that fail this test, = please let us know.
--94eb2c0880146a0b400559f98c13-- From nobody Sun Sep 24 18:36:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D735F132D44 for ; Sun, 24 Sep 2017 18:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 o5X5iWU-_QiY for ; Sun, 24 Sep 2017 18:36:26 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40907132F2E for ; Sun, 24 Sep 2017 18:36:26 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id t127so3775369ywg.4 for ; Sun, 24 Sep 2017 18:36:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vXgx9cCcor/13t+HA+EZ3pcuAZgFOTb18FLAsSqLjFk=; b=CF6RXBI1Vct0jeSFumAhWRNyy29cpLOHyrU8L+PNGuFi1mXdeDYeUULe4u160Vn9fo pMrcJ9FY/2WswM0eXTZdh1vUWDOc5fKg9YeX0QX5Z+w+qCikWRGkESvgtqUhm5qRZj2l dPsTEEYHJUiU/abGEmi65o+oMq6aeZwG2fYHE1nGyuacDsjn9vMxQqbE1WIltVG8H6mx Tpko6bynVB3UTOPQhcWc/mv2pNBFBGnWFlgajb8yYcGvwNMXOmoMtYAwhfm59sIqG9Ni yrb9R6cAnifdLBDCxHJLTJZkQS6BoxfLRfBP+iEZAViw5fv6ORm7vPTz14o8m5t2hH6B SxSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vXgx9cCcor/13t+HA+EZ3pcuAZgFOTb18FLAsSqLjFk=; b=i1edOAg/GCTC8WjEHzxVl+7gCO1yfiNr2YBR0MCt1973MZesSfu0Zx1JPdZ+t0LP+I GONR30e19ZZfRwY+mkf7fRFYSA9Ued4X2lyekQKznROijYqQ2Jf4DaQboruriWo1i/j+ 67cdOQJdhW/fLz6cWM/OkJ5UvinDg85dj2Q0QctVaktUyJ4b6tb97mi9+HRQ9JWJTzrK fMcG5CpIMf2cUftvpz8w3aAUxpljJKxXZcBidtnGIP6JS6NRHWWdHFe1ehKjIXRY82Fw E8bDn0S5kUJVptk0DU/oab8QCX+0ia+nXRxPIDn4ZxuZNh9lYcQxCGs/X9WDHj1keBtY A2xA== X-Gm-Message-State: AHPjjUga36HqUyoBJcVk3Ca3Dnx7SiHpAYAviCmicucsF5l/NIoEGH6S 6ylWjqFHcq1WHqKXNaW7lyQ2f6kl3mF/+8tEdanwkQ== X-Google-Smtp-Source: AOwi7QAeOULr7ftCZrAKfxHWJ+6xOaULL347UjN6UQY/qeHw/XVHPnO+wJkUQfnHxX4SU8PnMrI/lqjYMi/Da4CLsKE= X-Received: by 10.129.165.66 with SMTP id c63mr3739749ywh.143.1506303385253; Sun, 24 Sep 2017 18:36:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Sun, 24 Sep 2017 18:36:04 -0700 (PDT) In-Reply-To: <20170924175047.GR45648@Space.Net> References: <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> <20170922161337.GH45648@Space.Net> <20170924175047.GR45648@Space.Net> From: Lorenzo Colitti Date: Mon, 25 Sep 2017 10:36:04 +0900 Message-ID: To: Gert Doering Cc: Erik Kline , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="94eb2c12926a34421c0559f996d0" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 01:36:28 -0000 --94eb2c12926a34421c0559f996d0 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 25, 2017 at 2:50 AM, Gert Doering wrote: > Now, how can we get all those vendors with a big S to ship Android > upgrades for their phones on the market? > > (We'd *really* like bring back this host to the IPv6 world... and we > can't while the market share of unfixed devices is still so high. So > maybe in a year or so...) Can the radio station hand off to dual-stack URLs for working devices and to IPv4-only URLs for broken devices? For example, based on user-agent? --94eb2c12926a34421c0559f996d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Sep 25, 2017 at 2:50 AM, Gert Doering <gert@space.net> wrot= e:
Now, how can we get all those vendors = with a big S to ship Android
upgrades for their phones on the market?

(We'd *really* like bring back this host to the IPv6 world... and we can't while the market share of unfixed devices is still so high.=C2=A0= So
maybe in a year or so...)

Can the radio sta= tion hand off to dual-stack URLs for working devices and to IPv4-only URLs = for broken devices? For example, based on user-agent?
--94eb2c12926a34421c0559f996d0-- From nobody Sun Sep 24 18:55:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAED1321CB for ; Sun, 24 Sep 2017 18:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bEa_4zQmxvm7 for ; Sun, 24 Sep 2017 18:55:02 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C74113207A for ; Sun, 24 Sep 2017 18:55:02 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id d192so5580314itd.1 for ; Sun, 24 Sep 2017 18:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hNylIY23ypgjNOzU6ldJUCEuc7LXceA9EeH6hdfzw8U=; b=cPirJrqLbMCYgGDEdj1wCwoZbfn7hOaaqaOJYsaQbcTzVE9dOgWMsgx8v4wvTY2gWJ GA9gcqLI0errbrk/AYdDMmWmKxOVaFLtA+IR4T8VtsPbZh5gcPwtjttOF8rO86ispjsD lvHt7UaBVQthGplL2Uu497gcUI5c4npbieIAlRAzTW9/dI9rh95gvem+8B2IDijLnVza ZiUM9hZt6mClrHhnN7nQCLrM2l7PCzTeKgCkNmcBrkO9C2FArpNl7P2f3xRiYQIxedWl 1Z2tRZwosbUPRrL6UEVK8Yzs+TPAb4WB5ShsJjd1YTi030h424pSWrXvBKJMXMq+J06j upUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hNylIY23ypgjNOzU6ldJUCEuc7LXceA9EeH6hdfzw8U=; b=MoLoiDcBESzbzKv2bG2hoPWI7X/D6ja9vQkrX/mDPdFkdfUwBTQQ2wJYaD8dRQhjWs 2pzYTte6zpI72Vx1hIbaDPgM62kwQtuAoDW6JEh/aOJeTnYMsyBqql1vyaUSQzoK43vh rxb0toY56MsrnntllYCx7pPUGeUXHTqGumKjBF+Mhf8LO2ZfNlDdwm8GvJ9FBVYpRnep 6W24YFuhI3iAviEUG6hAODuS6PnZbeaL+and9CMiOA6OmgYNDvmwgbD2uAXXuV1Evb0k bz2VVt/E3CXth1B+lBb/+/XlRHAEvPfKwg9ou2KMOJphefoOhSxIbYweooiUtKgWvdsJ Pffg== X-Gm-Message-State: AHPjjUioqo1uKY4EfdWZb/7hDyqFh+S7+8cPKQ33VvHEgnkisz+otzoS iJd3ED99euHQ+unrwxMTEp9aQnXKc96vanz5y0FfEA== X-Google-Smtp-Source: AOwi7QDNATuVRqS0AnhMAZU2M8Nh2Ypn+pYX6QxyezQadwNXisvTya/Wwc3NAMzZwSihpfOCATwTSy+/w2iYs96u80I= X-Received: by 10.36.121.14 with SMTP id z14mr15553018itc.87.1506304501295; Sun, 24 Sep 2017 18:55:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Sun, 24 Sep 2017 18:54:40 -0700 (PDT) In-Reply-To: <20170922212502.E0CFF87B00BA@rock.dv.isc.org> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> From: Lorenzo Colitti Date: Mon, 25 Sep 2017 10:54:40 +0900 Message-ID: To: Mark Andrews Cc: Gert Doering , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a114aa77cb9a7db0559f9d83f" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 01:55:04 -0000 --001a114aa77cb9a7db0559f9d83f Content-Type: text/plain; charset="UTF-8" On Sat, Sep 23, 2017 at 6:25 AM, Mark Andrews wrote: > Stop exaggerating. Google went and added CLAT to the Android. They > can just as easily add DS-Lite to Android and we would have billions > of machines that support DS-Lite. Just because NAT64 and 464XLAT are > sexy doesn't mean that it is good technology. > We added 464xlat to Android because there were credible deployment plans in place for 464xlat on real networks that Android devices connect to. In hindsight, we were right, as 464xlat went from credible plan to successful deployment with an installed base in the tens of millions. I personally think that if we had not done this, we wouldn't have IPv6-only mobile networks today and we'd all still be lamenting the chicken and egg problem for IPv6-only networks. Getting rid of IPv4 in the network is a great step forward, and as Apple has shown, once that's happened, host OSes can start removing IPv4 access from applications, too. (And make no mistake: without 464xlat, those networks would *not* have gone IPv6-only, and it would have been much harder, or even impossible, for Apple to say that apps must operate in IPv6-only environments, because there would have been no such environments.) DS-Lite has no such credible deployment plans in place. Wifi networks are going to provide IPv4 for many years. Mobile networks were never going to deploy DS-Lite because the encapsulation would have broken their billing platforms. And so, here we are. We'll all get to IPv6-only eventually, and some time after that, we'll get rid of IPv4. At that time, you can salt the earth over 464xlat if you want. But until then, I wouldn't be too eager to bash 464xlat as a technology. It was the right thing to do at the time. --001a114aa77cb9a7db0559f9d83f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Sep 23, 2017 at 6:25 AM, Mark Andrews <marka@isc.org> wrote:=
Stop exaggerating.=C2= =A0 Google went and added CLAT to the Android.=C2=A0 They
can just as easily add DS-Lite to Android and we would have billions
of machines that support DS-Lite.=C2=A0 Just because NAT64 and 464XLAT are<= br> sexy doesn't mean that it is good technology.

=
We added 464xlat to Android because there were credible deployme= nt plans in place for 464xlat on real networks that Android devices connect= to. In hindsight, we were right, as 464xlat went from credible plan to suc= cessful deployment with an installed base in the tens of millions.

I personally think that if we had not done this, we wouldn= 't have IPv6-only mobile networks today and we'd all still be lamen= ting the chicken and egg problem for IPv6-only networks. Getting rid of IPv= 4 in the network is a great step forward, and as Apple has shown, once that= 's happened, host OSes can start removing IPv4 access from applications= , too. (And make no mistake: without 464xlat, those networks would *not* ha= ve gone IPv6-only, and it would have been much harder, or even impossible, = for Apple to say that apps must operate in IPv6-only environments, because = there would have been no such environments.)

DS-Li= te has=C2=A0no such credible deployment plans in place. Wifi networks are g= oing to provide IPv4 for many years. Mobile networks were never going to de= ploy DS-Lite because the encapsulation would have broken their billing plat= forms. And so, here we are.

We'll all get to I= Pv6-only eventually, and some time after that, we'll get rid of IPv4. A= t that time, you can salt the earth over 464xlat if you want. But until the= n, I wouldn't be too eager to bash 464xlat as a technology. It was the = right thing to do at the time.
--001a114aa77cb9a7db0559f9d83f-- From nobody Sun Sep 24 19:03:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD131321F5 for ; Sun, 24 Sep 2017 19:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F5w-2BChWdn for ; Sun, 24 Sep 2017 19:03:54 -0700 (PDT) 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 6791913207A for ; Sun, 24 Sep 2017 19:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4968; q=dns/txt; s=iport; t=1506305034; x=1507514634; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=h4fMGRcSmKnOritG1ZgVJGTJN8b/5VxmPQN10M0XjWc=; b=fNdJbFF+ojq6E0Ym/VGj8w8lGgtDVkWpIFPB6xR+Kg+1brDyoIE1ZM1m MdXNauZ22Qf1359bddCbP65ZrhODbh5FHrMvIbyCj+5VphWRrXKzjHJoe PoG7L6D4byuuRiE4alpvWOF88utXEnq/+aZwM1iYJzO31ILDczOuE+aeU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DCAQC0Y8hZ/4MNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkbieeD4F2mDwKGAuFGAKEJFcBAgEBAQEBAmsohRgBAQEBAgE?= =?us-ascii?q?BATg0CwUJAgIBCBgdARAbDAslAgQOBRkCigADDQgQqhiHLQ2DWAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFBYMmggKBUYFmASuBcIENhEIhAQEeB4M7gjEFiCyYcwK?= =?us-ascii?q?GYXqMf5MGlRkCERkBgTgBV08/eBVJEgGHCnaFWIIzAQEB?= X-IronPort-AV: E=Sophos;i="5.42,434,1500940800"; d="scan'208";a="7554128" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Sep 2017 02:03:37 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8P23bb6000730 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Sep 2017 02:03:37 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 24 Sep 2017 21:03:37 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Sun, 24 Sep 2017 21:03:36 -0500 From: "Rajiv Asati (rajiva)" To: Mark Andrews CC: Ca By , Gert Doering , "v6ops@ietf.org WG" Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info Thread-Index: AQHTMid0MFsx+pW27UqTI5O/FzE0AKK+QISAgACZFACAAHVGAIAAAUqAgADS0gD//8wEPIAA1YeA//+6It6AAKJbgIAACCSAgAABEwD//7K4HAALQo0AAAfhlsgAbVPQDA== Date: Mon, 25 Sep 2017 02:03:36 +0000 Message-ID: <7B8949ED-518B-48E2-B49C-D23F60472399@cisco.com> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> , <20170922215156.A88E987B03C1@rock.dv.isc.org> In-Reply-To: <20170922215156.A88E987B03C1@rock.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 02:03:56 -0000 Pls see inline, > On Sep 23, 2017, at 3:23 AM, Mark Andrews wrote: >=20 >=20 > In message > , Ca By writes: >> On Fri, Sep 22, 2017 at 5:45 AM Rajiv Asati (rajiva) >> wrote: >>=20 >>>=20 >>> I don't think that there any iOS app that is not IPv6-only compatible >>> (since the apple AppStore mandate more than a year* ago). Is there one = ? >>>=20 >>=20 >> I am simply here to disabuse you of the notion that this rule has been >> perfect for the folks involved. >>=20 >>=20 >>> If Google playstore could mandate something similar (perhaps, there is = one >>> that I am not aware of), then almost all mobile UEs can happily live wi= th v >> 6-only >>> without any Clat function. Better battery life, likely. >>>=20 >>=20 >> Fully agree. What if Google playstore cannot / will not enforce such a r= ule >> ? We in v6ops / sunset4 are well aware that asking for a poney seldom >> results in a poney .... hence warty solutions that thread one needle to >> move another needle. Putting the E back into IETF. >>=20 >>=20 >>> Hence, There is no need for XLAT being a BCP at this time in that regar= d. >>>=20 >>> Of course, NAT64 inside the network would still be needed to accommodat= e >>> the smaller (% of traffic) v4-only internet connectivity. But that's a= n >>> ongoing saga of another debate. >>>=20 >>>=20 >>>=20 >>> However, there is one exception - tethering :: >>>=20 >=20 > DS-Lite accomodates tethering. =20 So do 464XLAT, MAP-T/E etc. i agree.=20 However, the point was that CLAT function wouldn't be needed unless tetheri= ng was enabled (assuming apps were v6 compatible).=20 Cheers, Rajiv > It's in millions of broadband CPE devices > today 'tethering' the home IPv4 network to the rest of the world over IPv= 6 > access networks. >=20 >> Ah. What little control we have. >>=20 >>=20 >>> if mobile UE is tethered and the other devices connecting to its W/LAN = are >>> stuck in legacy v4-only, then mobile ISPs might prefer to not leave the= m >>> behind to ensure customer experience. What "technical" options do we ha= ve >>> then? Well, really two =3D=3D Let go of v6-only access (provide an IPv4= -only >>> APN if tethering is enabled resulting in a dual-stack UE) or stick with >>> v6-only access, but turn on CLAT function !! >>>=20 >>> Cheers, >>> Rajiv >>>=20 >>>=20 >>> * https://developer.apple.com/support/ipv6/ >>>=20 >>>=20 >>> On Sep 22, 2017, at 8:22 AM, Gert Doering wrote: >>>=20 >>> Hi, >>>=20 >>>=20 >>>=20 >>> On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote: >>>=20 >>> On 22 Sep 2017, at 13:48, Gert Doering wrote: >>>=20 >>> On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote: >>>=20 >>> IPv6 applications need to add code to WORKAROUND breakages caused >>>=20 >>> by NAT64 the way they need add WORKAROUNDS for the NAT breakages >>>=20 >>> even if they are not using NAT64 or NAT respectively. The cancer >>>=20 >>> that is NAT64 needs to be eradicated. >>>=20 >>>=20 >>> It will nicely go away if all endpoints are reachable over v6. >>>=20 >>>=20 >>> I think that?fs the concern. That it will not. >>>=20 >>> IPv6 applications will have code to accommodate for NAT64 forever. >>>=20 >>>=20 >>> Yeah, but you can't have the cake and eat it. Either we go v6-only >>> everywhere, or we keep running IPv4 everywhere until everybody else >>> is done, or we introduce v4/v6 NATs, or we add a CLAT to every single >>> operating system out there. >>>=20 >>> What's it gonna be, boys? >>>=20 >>> (Oh, "or we give up, roll back existing v6 deployments, and live happy >>> with v4 nat forever". FAR less work, and for Joe Average User, it won'= t >>> make a difference. Facebook and Youtube will continue to work, and >>> their IoT devices will keep drilling holes into firewalls to ensure tha= t >>> they can be exploited no matter what) >>>=20 >>>=20 >>>=20 >>> Gert Doering >>> -- NetMaster >>> -- >>> have you enabled IPv6 on something today...? >>>=20 >>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Cule= mann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >>>=20 >>> _______________________________________________ >>>=20 >>>=20 >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Sun Sep 24 20:31:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A9C13301F for ; Sun, 24 Sep 2017 20:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 E_CoaAodvfR6 for ; Sun, 24 Sep 2017 20:31:47 -0700 (PDT) Received: from atl4mhob09.registeredsite.com (atl4mhob09.registeredsite.com [209.17.115.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D747132620 for ; Sun, 24 Sep 2017 20:31:47 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob09.registeredsite.com (8.14.4/8.14.4) with ESMTP id v8P3ViGT023325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 24 Sep 2017 23:31:44 -0400 Received: (qmail 13451 invoked by uid 0); 25 Sep 2017 03:31:44 -0000 X-TCPREMOTEIP: 97.46.129.6 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?10.248.246.179?) (lee@asgard.org@97.46.129.6) by 0 with ESMTPA; 25 Sep 2017 03:31:37 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Lee Howard Mime-Version: 1.0 (1.0) Date: Sun, 24 Sep 2017 16:45:37 -0400 Message-Id: References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> Cc: v6ops@ietf.org In-Reply-To: <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> To: Alexandre Petrescu X-Mailer: iPhone Mail (14G60) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 03:31:48 -0000 Personal opinion... Sent from my iPhone > On Sep 23, 2017, at 8:08 AM, Alexandre Petrescu wrote: >=20 >=20 >>=20 >=20 > Yet a common denominator among Current Practices of transitioninig is: > double stack. >=20 > A smartphone runs ok native IPv4 and native IPv6 simultaneously, without > needing translations nor encapsulations nor DNS v6-v4 mappings. >=20 > Is double stack BCP? Dual stack doesn't solve the problem IPv6 was created to solve, which is the= lack of available IPv4 addresses.=20 >=20 > A few RFCs mentioning "dual stack" seem to be on StdsTrack (not BCP). > They seem all to involve some tunnelling or translation. >=20 > But double stack, understood as coexisting simultaneous use of IPv4 and > IPv6 independently, on the same Computer, without tunnelling, nor > translation, nor DNSv46 - could very well be a BCP. At best it could be a Brief Current Practice on the way to IPv6 only. In mos= t cases there will be another step: IPv6 plus translation.=20 There's no single best way to manage IPv4 exhaustion. It's stinks, and is go= ing to stink more.=20 Lee >=20 > Alex >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Sep 25 00:08:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A43126B6D for ; Mon, 25 Sep 2017 00:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRMSsq8APsgu for ; Mon, 25 Sep 2017 00:08:03 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1027A1270AB for ; Mon, 25 Sep 2017 00:08:02 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 0328240BA4 for ; Mon, 25 Sep 2017 09:08:00 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id E542240B9F; Mon, 25 Sep 2017 09:07:59 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id D6D4C3C923; Mon, 25 Sep 2017 09:07:59 +0200 (CEST) Date: Mon, 25 Sep 2017 09:07:59 +0200 From: Gert Doering To: Lorenzo Colitti Cc: Gert Doering , Erik Kline , "v6ops@ietf.org WG" Message-ID: <20170925070759.GV45648@Space.Net> References: <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> <20170922161337.GH45648@Space.Net> <20170924175047.GR45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="p0HrOs1DscHOeUIZ" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 07:08:06 -0000 --p0HrOs1DscHOeUIZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Sep 25, 2017 at 10:36:04AM +0900, Lorenzo Colitti wrote: > On Mon, Sep 25, 2017 at 2:50 AM, Gert Doering wrote: >=20 > > Now, how can we get all those vendors with a big S to ship Android > > upgrades for their phones on the market? > > > > (We'd *really* like bring back this host to the IPv6 world... and we > > can't while the market share of unfixed devices is still so high. So > > maybe in a year or so...) >=20 > Can the radio station hand off to dual-stack URLs for working devices and > to IPv4-only URLs for broken devices? For example, based on user-agent? It could. =20 But someone would have to write and test said code, and test across a wide enough range of handsets. But everybody is already busy trying to keep the= =20 service and network itself up and running. So the decision was "turn off= =20 IPv6, it's not making money but causing problems. revisit this later"... With the new information ("newer S* devices might have this fixed"), I can address the topic again, and then see what will happen. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --p0HrOs1DscHOeUIZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnIq00ACgkQ31bAZeTO f8UcKA/8D7BFbtiCVbkUlx/2sAOxOcOAYGlpgpGhsiWrIanVQ7LLF240d7IkqZkB tet7F9Duk+RiKrDPlzWRbXbbWu9MJixbyMBVm0tOUMD22LQa0D1KAwSFZ5uT4t66 /KB5IVAWKvATWsGVbcZursLyYTCrXtQmJmEMdGu8c9SRNobK6QeGSZ0BYkPCZvB9 wa0rnRU63yncdOVKqkb78mt1+P/HK5vbvyctpy17h/jA4rd8lgKy0zQoPNuwpJP/ 7Vt2fRYVNTDbExZxjJmHTykqqQYybJ2Ukvxbih47sNE2q9SN3T4rXZR6C+ds7gz5 BMpH52yPpPHCUeAMJH82kFLDXHmjtGtEZRPhsGHwi/DdcbPrY/MRe50Rz8aEP/1v XLkAHznQSpUPThThAVBG0+CHhEicWlYvm5mxHQgmspbB1wkxqyFxlJIIlq7S7+0P XTmeF5HJkXrUPMJsBYRMt6e8hu9Y6uOEXqdCezTSkAprYm3oFI0F3AollzHPTueQ 5Rmt1S0s0gCsB94QbhZJmkdTfMAHKZHcdZfoJ8Arbehp+bujbmET6HZ3r9U4m8mA ghJ8H0Ujr0UdZE3vdhK1SZkb2cPAnrhtnlxIcqSEmIhydzdDNgUUCAlQQAZmRLeE /DCe+kziqRZ+hY/95KFaXvvXLMr71u2OfFbS+B8us0aQf3NVCSU= =v2C5 -----END PGP SIGNATURE----- --p0HrOs1DscHOeUIZ-- From nobody Mon Sep 25 01:20:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7F3132CE7 for ; Mon, 25 Sep 2017 01:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yjf7g2s4Yje for ; Mon, 25 Sep 2017 01:20:01 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87EFE132939 for ; Mon, 25 Sep 2017 01:20:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8P8JsOK174997; Mon, 25 Sep 2017 10:19:54 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 56F23208EA9; Mon, 25 Sep 2017 10:19:54 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 486B6208B36; Mon, 25 Sep 2017 10:19:54 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8P8JrZp025842; Mon, 25 Sep 2017 10:19:54 +0200 To: Lee Howard Cc: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 10:19:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 08:20:03 -0000 Le 24/09/2017 à 22:45, Lee Howard a écrit : > Personal opinion... > > > Sent from my iPhone > >> On Sep 23, 2017, at 8:08 AM, Alexandre Petrescu >> wrote: >> >> >>> >> >> Yet a common denominator among Current Practices of transitioninig >> is: double stack. >> >> A smartphone runs ok native IPv4 and native IPv6 simultaneously, >> without needing translations nor encapsulations nor DNS v6-v4 >> mappings. >> >> Is double stack BCP? > > Dual stack doesn't solve the problem IPv6 was created to solve, which > is the lack of available IPv4 addresses. I agree. However, during a transition time it is perfectly fine to use double stack (i.e. dual stack without tunnelling, nor translation nor IN A carried by IPv6 messages). It may be a widely used method nobody talks about. It may also be that we do speculate too much on IPv6-only cellular networks. We speculate these are there now, whereas I may speculate it may not really be the case. There are some networks that are IPv6-only-to-end-user yet use GTP-IPv4. In these networks, if there is GTP-IPv4, there could also be a DNSv4 and a NAT. Actually, from where I look, I see many 'double stack' networks like these. >> A few RFCs mentioning "dual stack" seem to be on StdsTrack (not >> BCP). They seem all to involve some tunnelling or translation. >> >> But double stack, understood as coexisting simultaneous use of IPv4 >> and IPv6 independently, on the same Computer, without tunnelling, >> nor translation, nor DNSv46 - could very well be a BCP. > > At best it could be a Brief Current Practice on the way to IPv6 only. :-) I like that. > In most cases there will be another step: IPv6 plus translation. IPv6-IPv4 translations are evil. > There's no single best way to manage IPv4 exhaustion. It's stinks, > and is going to stink more. :-) I can agree to that Alex From nobody Mon Sep 25 01:28:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F721133020 for ; Mon, 25 Sep 2017 01:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NpGNi2umcLq for ; Mon, 25 Sep 2017 01:28:36 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FFC13300C for ; Mon, 25 Sep 2017 01:28:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A1073B1; Mon, 25 Sep 2017 10:28:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506328113; bh=NKxqxEY+fjobiBcfU/P7Ir9K5jPuj1Nz7DBOF15SChM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=RoXcEDG96d1lpo34U8Zpw28cfN3q833OmVWw+g2/Cr3secOfDE6z8ALf1ixVBeFcI BTpZoDXB1SiPsUl99s3ADjb++9bf9jNuVEgUnoUXTYoVnc/QRGQO7mAZGUKiaBhM3A elWu7n5vcFCi/WM4iGD670XpBsNjvCb9ZAxKzH5E= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 72CF2B0; Mon, 25 Sep 2017 10:28:33 +0200 (CEST) Date: Mon, 25 Sep 2017 10:28:33 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Lee Howard , v6ops@ietf.org In-Reply-To: Message-ID: References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 08:28:38 -0000 On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > It may also be that we do speculate too much on IPv6-only cellular > networks. We speculate these are there now, whereas I may speculate it > may not really be the case. There are some networks that are > IPv6-only-to-end-user yet use GTP-IPv4. Are you saying that people from for instance T-Mobile USA saying they're doing IPv6 only GTP (and checking peoples phones the settings are IPv6 and not IPv4v6), are lying? What do you mean by GTP-IPV4? We're talking about what access service is provided to the customers, and there are several that do IPv6 only GTP. Yes, the GTP packets might be carried over IPv4, but the SERVICE provided to the customer is IPv6 only. > Actually, from where I look, I see many 'double stack' networks like > these. There are plenty of examples of IPv4 only, IPv6 only, and IPv4v6 mobile access networks. It's all being done. What the provider chooses to do often has to do with their equipment vendor supports and how many IPv4 addresses they might have. Also operational practices and preferences. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 25 02:06:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF29F13314B for ; Mon, 25 Sep 2017 02:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyBpojYr5jvJ for ; Mon, 25 Sep 2017 02:06:08 -0700 (PDT) Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C6F133091 for ; Mon, 25 Sep 2017 02:06:07 -0700 (PDT) Received: from 10.236.51.103 (EHLO PE16MR03.tp.gk.corp.tepenet) ([10.236.51.103]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id HHB29683; Mon, 25 Sep 2017 11:05:29 +0200 (CEST) From: Kossut Tomasz - Hurt To: Lorenzo Colitti , Mark Andrews , "Erik Kline (ek@google.com)" CC: Gert Doering , "v6ops@ietf.org WG" Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info Thread-Index: AQHTNaKV6eV3QehFxE+9XU+uWne+sqLFQOLw Date: Mon, 25 Sep 2017 09:05:12 +0000 Message-ID: <4bf16a40ffd44e9498babf7094b1e526@orange.com> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> In-Reply-To: Accept-Language: pl-PL, en-US Content-Language: pl-PL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [126.182.101.113] X-TM-AS-Product-Ver: SMEX-12.0.0.1727-8.100.1062-23350.005 X-TM-AS-Result: No--28.150000-0.000000-31 X-TM-AS-MatchedID: 150567-700274-702131-700401-861142-700755-106660-706561-7 00057-700075-106640-702190-704421-390218-709850-106541-701461-702796-709584 -704156-702801-848947-701629-705450-702216-703130-704572-703747-701738-7060 65-709908-703303-188198-700245-701618-121195-863299-712133-707997-710207-70 1848-105700-863828-703267-704989-139704-113220-708196-111604-188119-700362- 705718-700345-701827-700264-702497-704425-700732-701012-701306-852490-70045 0-702638-700758-700537-709859-708075-863174-701594-702791-703707-188038-111 605-700074-303242-700079-111610-188057-188093-148004-148036-148046-148133-2 0020-42003 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Type: multipart/alternative; boundary="_000_4bf16a40ffd44e9498babf7094b1e526orangecom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2017.9.25.81516:17:8.907, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __TO_NAME, __TO_NAME_DIFF_FROM_ACC, __HAS_CC_HDR, __MULTIPLE_RCPTS_CC_X2, __CC_NAME, __CC_NAME_DIFF_FROM_ACC, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __HAS_MSGID, __SANE_MSGID, __MSGID_32HEX, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, WEBMAIL_X_IP_HDR, __MIME_TEXT_P2, __MIME_TEXT_H2, __ANY_URI, __URI_NO_WWW, ECARD_KNOWN_DOMAINS, __SUBJ_ALPHA_NEGATE, __C230066_P5, SUPERLONG_LINE, __MULTIPLE_URI_TEXT, __URI_IN_BODY, __URI_NOT_IMG, __HTML_FONT_BLUE, __STYLE_RATWARE_NEG, __STYLE_TAG, __HAS_HTML, __HTML_TAG_DIV, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_3000_MORE, __MIME_TEXT_H1, __MIME_TEXT_P1, __MIME_HTML, __TAG_EXISTS_HTML, __RATWARE_SIGNATURE_3_N1, __URI_NS, [TRUNCATED] X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0202.59C8C6DA.0056, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine X-Junkmail-IWF: false X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0202.59C8C6DA.0056, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4ce1e9b52a1573593ed55bf8889b4520 Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:06:11 -0000 --_000_4bf16a40ffd44e9498babf7094b1e526orangecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpUcnVlICEgNDY0eGxhdCBlbmFibGVkIElQdjYgdHJhbnNpdGlvbiBmb3IgbW9iaWxlIG5l dHdvcmtzLiBUaGFuayB5b3UgISBJbiBJUHY2LW9ubHkgbmV0d29yayB5b3UgY2FuIGV4cGVjdCB1 cCB0byA2MCUgbmF0aXZlIElQdjYNCkNoZWVycywNClRLDQoNCg0KRnJvbTogTG9yZW56byBDb2xp dHRpIFttYWlsdG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIg MjUsIDIwMTcgMzo1NSBBTQ0KVG86IE1hcmsgQW5kcmV3cw0KQ2M6IEdlcnQgRG9lcmluZzsgdjZv cHNAaWV0Zi5vcmcgV0cNClN1YmplY3Q6IFJlOiBbdjZvcHNdIHJlY2xhc3NpZnkgNDY0WExBVCBh cyBzdGFuZGFyZCBpbnN0ZWFkIG9mIGluZm8NCg0KT24gU2F0LCBTZXAgMjMsIDIwMTcgYXQgNjoy NSBBTSwgTWFyayBBbmRyZXdzIDxtYXJrYUBpc2Mub3JnPG1haWx0bzptYXJrYUBpc2Mub3JnPj4g d3JvdGU6DQpTdG9wIGV4YWdnZXJhdGluZy4gIEdvb2dsZSB3ZW50IGFuZCBhZGRlZCBDTEFUIHRv IHRoZSBBbmRyb2lkLiAgVGhleQ0KY2FuIGp1c3QgYXMgZWFzaWx5IGFkZCBEUy1MaXRlIHRvIEFu ZHJvaWQgYW5kIHdlIHdvdWxkIGhhdmUgYmlsbGlvbnMNCm9mIG1hY2hpbmVzIHRoYXQgc3VwcG9y dCBEUy1MaXRlLiAgSnVzdCBiZWNhdXNlIE5BVDY0IGFuZCA0NjRYTEFUIGFyZQ0Kc2V4eSBkb2Vz bid0IG1lYW4gdGhhdCBpdCBpcyBnb29kIHRlY2hub2xvZ3kuDQoNCldlIGFkZGVkIDQ2NHhsYXQg dG8gQW5kcm9pZCBiZWNhdXNlIHRoZXJlIHdlcmUgY3JlZGlibGUgZGVwbG95bWVudCBwbGFucyBp biBwbGFjZSBmb3IgNDY0eGxhdCBvbiByZWFsIG5ldHdvcmtzIHRoYXQgQW5kcm9pZCBkZXZpY2Vz IGNvbm5lY3QgdG8uIEluIGhpbmRzaWdodCwgd2Ugd2VyZSByaWdodCwgYXMgNDY0eGxhdCB3ZW50 IGZyb20gY3JlZGlibGUgcGxhbiB0byBzdWNjZXNzZnVsIGRlcGxveW1lbnQgd2l0aCBhbiBpbnN0 YWxsZWQgYmFzZSBpbiB0aGUgdGVucyBvZiBtaWxsaW9ucy4NCg0KSSBwZXJzb25hbGx5IHRoaW5r IHRoYXQgaWYgd2UgaGFkIG5vdCBkb25lIHRoaXMsIHdlIHdvdWxkbid0IGhhdmUgSVB2Ni1vbmx5 IG1vYmlsZSBuZXR3b3JrcyB0b2RheSBhbmQgd2UnZCBhbGwgc3RpbGwgYmUgbGFtZW50aW5nIHRo ZSBjaGlja2VuIGFuZCBlZ2cgcHJvYmxlbSBmb3IgSVB2Ni1vbmx5IG5ldHdvcmtzLiBHZXR0aW5n IHJpZCBvZiBJUHY0IGluIHRoZSBuZXR3b3JrIGlzIGEgZ3JlYXQgc3RlcCBmb3J3YXJkLCBhbmQg YXMgQXBwbGUgaGFzIHNob3duLCBvbmNlIHRoYXQncyBoYXBwZW5lZCwgaG9zdCBPU2VzIGNhbiBz dGFydCByZW1vdmluZyBJUHY0IGFjY2VzcyBmcm9tIGFwcGxpY2F0aW9ucywgdG9vLiAoQW5kIG1h a2Ugbm8gbWlzdGFrZTogd2l0aG91dCA0NjR4bGF0LCB0aG9zZSBuZXR3b3JrcyB3b3VsZCAqbm90 KiBoYXZlIGdvbmUgSVB2Ni1vbmx5LCBhbmQgaXQgd291bGQgaGF2ZSBiZWVuIG11Y2ggaGFyZGVy LCBvciBldmVuIGltcG9zc2libGUsIGZvciBBcHBsZSB0byBzYXkgdGhhdCBhcHBzIG11c3Qgb3Bl cmF0ZSBpbiBJUHY2LW9ubHkgZW52aXJvbm1lbnRzLCBiZWNhdXNlIHRoZXJlIHdvdWxkIGhhdmUg YmVlbiBubyBzdWNoIGVudmlyb25tZW50cy4pDQoNCkRTLUxpdGUgaGFzIG5vIHN1Y2ggY3JlZGli bGUgZGVwbG95bWVudCBwbGFucyBpbiBwbGFjZS4gV2lmaSBuZXR3b3JrcyBhcmUgZ29pbmcgdG8g cHJvdmlkZSBJUHY0IGZvciBtYW55IHllYXJzLiBNb2JpbGUgbmV0d29ya3Mgd2VyZSBuZXZlciBn b2luZyB0byBkZXBsb3kgRFMtTGl0ZSBiZWNhdXNlIHRoZSBlbmNhcHN1bGF0aW9uIHdvdWxkIGhh dmUgYnJva2VuIHRoZWlyIGJpbGxpbmcgcGxhdGZvcm1zLiBBbmQgc28sIGhlcmUgd2UgYXJlLg0K DQpXZSdsbCBhbGwgZ2V0IHRvIElQdjYtb25seSBldmVudHVhbGx5LCBhbmQgc29tZSB0aW1lIGFm dGVyIHRoYXQsIHdlJ2xsIGdldCByaWQgb2YgSVB2NC4gQXQgdGhhdCB0aW1lLCB5b3UgY2FuIHNh bHQgdGhlIGVhcnRoIG92ZXIgNDY0eGxhdCBpZiB5b3Ugd2FudC4gQnV0IHVudGlsIHRoZW4sIEkg d291bGRuJ3QgYmUgdG9vIGVhZ2VyIHRvIGJhc2ggNDY0eGxhdCBhcyBhIHRlY2hub2xvZ3kuIEl0 IHdhcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gYXQgdGhlIHRpbWUuDQo= --_000_4bf16a40ffd44e9498babf7094b1e526orangecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZWtzdCBkeW1rYSBabmFrIjsNCglt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2lu LWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0Kc3Bhbi5TdHlsd2lhZG9tb2NpZS1tYWlsMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uVGVrc3RkeW1rYVpuYWsNCgl7bXNvLXN0eWxlLW5hbWU6IlRla3N0 IGR5bWthIFpuYWsiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi VGVrc3QgZHlta2EiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpQTDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjMwMjAwMTI0MzsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjA2MDc4Njc4IC0xMjE2OTU0MjM2IDY4 NDg1MTIzIDY4NDg1MTI1IDY4NDg1MTIxIDY4NDg1MTIzIDY4NDg1MTI1IDY4NDg1MTIxIDY4NDg1 MTIzIDY4NDg1MTI1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsN Cgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo5MzE1NTMxNjM7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2NTI0OTAxMDIgNDQ0 NTEzNTI0IDY4NDg1MTIzIDY4NDg1MTI1IDY4NDg1MTIxIDY4NDg1MTIzIDY4NDg1MTI1IDY4NDg1 MTIxIDY4NDg1MTIzIDY4NDg1MTI1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6IiI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iUEwiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UcnVlICEgNDY0eGxhdCBlbmFibGVkIElQdjYgdHJhbnNpdGlvbiBmb3IgbW9iaWxlIG5l dHdvcmtzLiBUaGFuayB5b3UgISBJbiBJUHY2LW9ubHkgbmV0d29yayB5b3UgY2FuIGV4cGVjdCB1 cCB0byA2MCUgbmF0aXZlIElQdjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRLPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IExvcmVuem8gQ29saXR0aSBbbWFpbHRvOmxvcmVuem9AZ29v Z2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIFNlcHRlbWJlciAyNSwgMjAxNyAz OjU1IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJrIEFuZHJld3M8YnI+DQo8Yj5DYzo8L2I+IEdlcnQg RG9lcmluZzsgdjZvcHNAaWV0Zi5vcmcgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9w c10gcmVjbGFzc2lmeSA0NjRYTEFUIGFzIHN0YW5kYXJkIGluc3RlYWQgb2YgaW5mbzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBTYXQsIFNlcCAyMywgMjAxNyBhdCA2OjI1IEFNLCBNYXJrIEFuZHJl d3MgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrYUBpc2Mub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFy a2FAaXNjLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U3RvcCBleGFnZ2VyYXRpbmcuJm5ic3A7IEdvb2dsZSB3ZW50IGFuZCBhZGRlZCBDTEFU IHRvIHRoZSBBbmRyb2lkLiZuYnNwOyBUaGV5PGJyPg0KY2FuIGp1c3QgYXMgZWFzaWx5IGFkZCBE Uy1MaXRlIHRvIEFuZHJvaWQgYW5kIHdlIHdvdWxkIGhhdmUgYmlsbGlvbnM8YnI+DQpvZiBtYWNo aW5lcyB0aGF0IHN1cHBvcnQgRFMtTGl0ZS4mbmJzcDsgSnVzdCBiZWNhdXNlIE5BVDY0IGFuZCA0 NjRYTEFUIGFyZTxicj4NCnNleHkgZG9lc24ndCBtZWFuIHRoYXQgaXQgaXMgZ29vZCB0ZWNobm9s b2d5LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgYWRk ZWQgNDY0eGxhdCB0byBBbmRyb2lkIGJlY2F1c2UgdGhlcmUgd2VyZSBjcmVkaWJsZSBkZXBsb3lt ZW50IHBsYW5zIGluIHBsYWNlIGZvciA0NjR4bGF0IG9uIHJlYWwgbmV0d29ya3MgdGhhdCBBbmRy b2lkIGRldmljZXMgY29ubmVjdCB0by4gSW4gaGluZHNpZ2h0LCB3ZSB3ZXJlIHJpZ2h0LCBhcyA0 NjR4bGF0IHdlbnQgZnJvbSBjcmVkaWJsZSBwbGFuIHRvIHN1Y2Nlc3NmdWwgZGVwbG95bWVudCB3 aXRoDQogYW4gaW5zdGFsbGVkIGJhc2UgaW4gdGhlIHRlbnMgb2YgbWlsbGlvbnMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcGVyc29uYWxs eSB0aGluayB0aGF0IGlmIHdlIGhhZCBub3QgZG9uZSB0aGlzLCB3ZSB3b3VsZG4ndCBoYXZlIElQ djYtb25seSBtb2JpbGUgbmV0d29ya3MgdG9kYXkgYW5kIHdlJ2QgYWxsIHN0aWxsIGJlIGxhbWVu dGluZyB0aGUgY2hpY2tlbiBhbmQgZWdnIHByb2JsZW0gZm9yIElQdjYtb25seSBuZXR3b3Jrcy4g R2V0dGluZyByaWQgb2YgSVB2NCBpbiB0aGUgbmV0d29yayBpcyBhIGdyZWF0IHN0ZXAgZm9yd2Fy ZCwNCiBhbmQgYXMgQXBwbGUgaGFzIHNob3duLCBvbmNlIHRoYXQncyBoYXBwZW5lZCwgaG9zdCBP U2VzIGNhbiBzdGFydCByZW1vdmluZyBJUHY0IGFjY2VzcyBmcm9tIGFwcGxpY2F0aW9ucywgdG9v LiAoQW5kIG1ha2Ugbm8gbWlzdGFrZTogd2l0aG91dCA0NjR4bGF0LCB0aG9zZSBuZXR3b3JrcyB3 b3VsZCAqbm90KiBoYXZlIGdvbmUgSVB2Ni1vbmx5LCBhbmQgaXQgd291bGQgaGF2ZSBiZWVuIG11 Y2ggaGFyZGVyLCBvciBldmVuIGltcG9zc2libGUsIGZvcg0KIEFwcGxlIHRvIHNheSB0aGF0IGFw cHMgbXVzdCBvcGVyYXRlIGluIElQdjYtb25seSBlbnZpcm9ubWVudHMsIGJlY2F1c2UgdGhlcmUg d291bGQgaGF2ZSBiZWVuIG5vIHN1Y2ggZW52aXJvbm1lbnRzLik8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RFMtTGl0ZSBoYXMmbmJzcDtubyBz dWNoIGNyZWRpYmxlIGRlcGxveW1lbnQgcGxhbnMgaW4gcGxhY2UuIFdpZmkgbmV0d29ya3MgYXJl IGdvaW5nIHRvIHByb3ZpZGUgSVB2NCBmb3IgbWFueSB5ZWFycy4gTW9iaWxlIG5ldHdvcmtzIHdl cmUgbmV2ZXIgZ29pbmcgdG8gZGVwbG95IERTLUxpdGUgYmVjYXVzZSB0aGUgZW5jYXBzdWxhdGlv biB3b3VsZCBoYXZlIGJyb2tlbiB0aGVpciBiaWxsaW5nIHBsYXRmb3Jtcy4gQW5kDQogc28sIGhl cmUgd2UgYXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XZSdsbCBhbGwgZ2V0IHRvIElQdjYtb25seSBldmVudHVhbGx5LCBhbmQgc29tZSB0 aW1lIGFmdGVyIHRoYXQsIHdlJ2xsIGdldCByaWQgb2YgSVB2NC4gQXQgdGhhdCB0aW1lLCB5b3Ug Y2FuIHNhbHQgdGhlIGVhcnRoIG92ZXIgNDY0eGxhdCBpZiB5b3Ugd2FudC4gQnV0IHVudGlsIHRo ZW4sIEkgd291bGRuJ3QgYmUgdG9vIGVhZ2VyIHRvIGJhc2ggNDY0eGxhdCBhcyBhIHRlY2hub2xv Z3kuIEl0IHdhcyB0aGUgcmlnaHQNCiB0aGluZyB0byBkbyBhdCB0aGUgdGltZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_4bf16a40ffd44e9498babf7094b1e526orangecom_-- From nobody Mon Sep 25 02:15:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA9613314B for ; Mon, 25 Sep 2017 02:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62krVH6pVb07 for ; Mon, 25 Sep 2017 02:15:50 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAEDF12008A for ; Mon, 25 Sep 2017 02:15:49 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8P9FhgJ012803; Mon, 25 Sep 2017 11:15:43 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7D2E2202272; Mon, 25 Sep 2017 11:15:43 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6238B202271; Mon, 25 Sep 2017 11:15:43 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8P9Fhux021254; Mon, 25 Sep 2017 11:15:43 +0200 To: Mikael Abrahamsson Cc: Ca By , Owen DeLong , v6ops@ietf.org References: <355FA9BA-CBE9-41AC-8FA6-B44C15C7420B@gmail.com> <58bb7a08-4595-f9b8-0be4-25bb471ca2db@gmail.com> <39456568-1DF0-4D51-8E94-0FDF3595EB31@consulintel.es> <58c5384b-d7d4-f89b-4e1c-f340d2af6630@gmail.com> <8AC03AD2-A7C0-48ED-BFD1-54AEF6A2C29B@consulintel.es> <75a6ea1b-de5d-5b8d-b3d9-d24edbb7bfad@gmail.com> <3521F710-56E4-4950-9EA0-6ECC58219F11@delong.com> <1c0b744f-05ef-6df0-9233-9e86d3de7c8e@gmail.com> <8cdcdb7f-7c21-1501-81b4-8ac34976389b@gmail.com> <3c8584d6-278a-751a-ecd8-d1c9b2cc2206@gmail.com> From: Alexandre Petrescu Message-ID: <64a468a5-1dbf-86e9-429a-b85d8558a257@gmail.com> Date: Mon, 25 Sep 2017 11:15:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] [*SPAM* Score/Req: 3.9/3.3] Re: [*SPAM* Score/Req: 3.9/3.3] Re: reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:15:51 -0000 Le 21/09/2017 à 15:56, Mikael Abrahamsson a écrit : [...] >> I do see packets on PGW that show IPv6 encapsulated in GTP (an IPv4 >> protocol). > > GTP can be either IPv4 or IPv6, Spec please? Alex > and the encapsulated packets can be > either IPv4 or IPv6 (and probably other protocols as well, I haven't > used it for anything else). > From nobody Mon Sep 25 02:19:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBA51330B0 for ; Mon, 25 Sep 2017 02:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti302_jfVGex for ; Mon, 25 Sep 2017 02:19:16 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BD11320C9 for ; Mon, 25 Sep 2017 02:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506331154; x=1506935954; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=kRHvR+xXoXiRKhYh+blgvqjHS +8HG9Mh0W4q59V8bTQ=; b=lSxIJOzZb8B+Su7RBTK0FsCdj0+Eo40fkZwI7OpOi prThiAJv8suSt39ISr6SYsMnkXQpDI7OgCQ7o+ZQM68CEA6m8CdU5Q5SJ8o1wx/i FWFCWoB0ujjZwQsng8DmLc46f9h+xJN+xyZOO6HA7bvhDnn9HHIKVEwkUyZ5+/tG mw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=CrNQrzz8jpckA7ZxWvkRM82Pg+ITWaQkW1RLrIiKyIGbv3v3Fx2U85FHAGEC B/io2LYP8orEppyDz/H36ounwp9F/lw4sZjh+JJG8F8CF2JM0bigtK4h9 X8hI5kWX4mia6szAp80e3cnp4fdmXzuSvs1OAKEYYXj5Ne8Zh07GIo=; X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 11:19:14 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 11:19:13 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005566543.msg for ; Mon, 25 Sep 2017 11:19:12 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170925:md50005566543::v5TTiJGQ04XZFwNQ:00000PPo X-Return-Path: prvs=1441fc161e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Mon, 25 Sep 2017 11:19:08 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org WG" Message-ID: <34D310C2-0947-4868-BDB9-D9828500907F@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:19:18 -0000 Response in-line Saludos, Jordi =20 -----Mensaje original----- De: Lee Howard Responder a: Fecha: viernes, 22 de septiembre de 2017, 20:48 Para: , "v6ops@ietf.org WG" Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info =20 =20 On 9/22/17, 2:22 PM, "v6ops on behalf of JORDI PALET MARTINEZ" wrote: =20 >Hi Lee, > >See below in-line. > >Regards, >Jordi >=20 > >-----Mensaje original----- >De: v6ops en nombre de Lee Howard > >Responder a: >Fecha: viernes, 22 de septiembre de 2017, 14:56 >Para: Lee Howard >CC: "v6ops@ietf.org WG" >Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info > > As to the original question, I have a couple of questions: > =20 > 1. What is gained by promoting rfc6877 "464XLAT: Combination of >Stateful > and Stateless Translation=E2=80=9D? Regardless of whether the cor= rect >promotion > path is BCP or Proposed Standard, what is the goal? > >[Jordi] My point is: I understand that when 464XLAT was proposed, it w= as >not considered at the same level as other transition mechanisms, which >are, from the start, standards track. Now that this is the most >successful (in terms of number of users vs. all the other transition >mechanisms), in my opinion there is no reason to discriminate it. So, >either we drop to informational all the transition mechanisms that hav= e >so much lower degree of success or even to historic or deprecated thos= e >that are not used. Is a matter of fairness and recognize the reality. =20 Well, rfc6877 doesn=E2=80=99t define a new protocol, it describes a way= that existing technologies could meet a need. I=E2=80=99m trying to read it = as a Technical Specification as defined by rfc2026, and I don=E2=80=99t see = how it fits. =20 Who is discriminating against the most successful mechanism based on it= s document track? [Jordi] We (IETF) are discriminating among different transition technologie= s. I understand that is not a new protocol, but I=E2=80=99m sure we can spe= nd some time in investigating other standards track documents that are not = actually =E2=80=9Cprotocols=E2=80=9D per se =E2=80=A6 just ways to do it. U= nfortunately, may operators in the market don=E2=80=99t know all those =E2= =80=9Cdetails=E2=80=9D about the distinction in between an informational, a= BCP, etc., so having =E2=80=9Cother=E2=80=9D transition technologies as no= n-info and this one as info, makes a difference and I=E2=80=99ve heard this= from several people the last weeks (also previously, but I refer to this p= eriod because last weeks, I=E2=80=99ve been in 3 different continents with = people from many different countries). You can read 4.2.2 Informational An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. Which clearly states =E2=80=9Cgeneral information, does not represent an In= ternet community consensus=E2=80=9D =E2=80=A6 which is not true in the sens= e that 464XLAT required consensus to be accepted and published, right? A re= ader that didn=E2=80=99t followed the process don't know the details. > =20 > 2. rfc2026 =E2=80=9CThe Internet Standards Process=E2=80=9D says = a BCP is the "best > current thinking on a statement of principle or on what is believe= d >to be > the best way to perform some operations.=E2=80=9D What principle = or what > operations is 464xlat best for? > =20 >[Jordi] Well, I was suggesting standards track, not BCP. So not sure h= ow >to read this question myself. Actually, I=E2=80=99ve drafted already (= started two >months ago, and not related at all to this discussion, but for lack of >time availability, haven=E2=80=99t completed it yet, hopefully can hav= e it early >next week) a BCP which initially I=E2=80=99ve titled =E2=80=9C464XLAT = Deployment >Guidelines in Operator Networks=E2=80=9D. The idea come out after we h= ad the >discussion of deploying at the IETF network 464XLAT instead of just >NAT64. In this document I=E2=80=99m describing how, according to my ex= perience >(and hopefully inputs from others once a first version is published), >464XLAT is being deployed in both cellular and non-cellular networks. =20 Maybe I should have also asked the question, =E2=80=9CHow does rfc6877 = meet the standard of an Internet Standard according to rfc2026?=E2=80=9D [Jordi] It seems to me (unless missing something) that we are reading RFC20= 26 as if only a new =E2=80=9Cprotocol=E2=80=9D can be actually a standard (= not discussing here what degree of maturity, as that discussion will be onl= y relevant if first we accept that 464XLAT can be reclassified to that), wh= ich is not correct =E2=80=9C=E2=80=9D. To get 464XLAT working you actually = need to implement code in both, the devices (UEs, CEs, etc.) and the networ= k. Reading the definition of TS and AS (section 3.1 and 3.2), it is clear to m= e that 464XLAT can fit in any of both definitions, so that should not be an= issue for this reclassification. =E2=80=9CA TS may be completely self- contained, or it may incorporate material from other specifications by reference to other documents (which might or might not be Internet Standards).=E2=80=9D =20 Lee =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Sep 25 02:20:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5673913308A for ; Mon, 25 Sep 2017 02:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vijcYiPDuQgB for ; Mon, 25 Sep 2017 02:20:07 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3CD61320C9 for ; Mon, 25 Sep 2017 02:20:06 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8P9K1CL010507; Mon, 25 Sep 2017 11:20:01 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 68A3D2091FE; Mon, 25 Sep 2017 11:20:01 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 58D8D20865C; Mon, 25 Sep 2017 11:20:01 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8P9K1Rt025448; Mon, 25 Sep 2017 11:20:01 +0200 To: Mikael Abrahamsson Cc: Lee Howard , v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> From: Alexandre Petrescu Message-ID: <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> Date: Mon, 25 Sep 2017 11:20:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:20:08 -0000 Le 25/09/2017 à 10:28, Mikael Abrahamsson a écrit : > On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > >> It may also be that we do speculate too much on IPv6-only cellular >> networks.  We speculate these are there now, whereas I may speculate >> it may not really be the case.  There are some networks that are >> IPv6-only-to-end-user yet use GTP-IPv4. > > Are you saying that people from for instance T-Mobile USA saying they're > doing IPv6 only GTP No, I would like to ask T-Mobile USA whether they use GTP-IPv6? Or GTP-IPv4? [...] > What do you mean by GTP-IPV4? I mean GTPU protocol that uses IPv4 addresses, and carries IPv6 packets inside; an example packet capture of what I call GTP-IPv4 is the following: > INBOUND>>>>> 15:47:48:883 Eventid:142004(3) > GTPU Rx PDU, from [IPv4-address]:2152 to [IPv4-address-2]:2152 (129) > TEID: 0x80072183, Message type: GTP_TPDU_MSG (0xFF) > Sequence Number:: NA > GTP HEADER FOLLOWS: > [snip] > GTP HEADER ENDS. > Payload protocol: IPv6 > PROTOCOL PAYLOAD FOLLOWS: > fe80::b9d9:c10a:2c2d:3c3b.546 > ff02::2.546: [udp sum ok] > IPv6 Header Follows: > [snip] > PROTOCOL PAYLOAD ENDS. > We're talking about what access service is > provided to the customers, and there are several that do IPv6 only GTP. > Yes, the GTP packets might be carried over IPv4, but the SERVICE > provided to the customer is IPv6 only. Excuse me, Mikael, but it is little possible to claim "IPv6-only" when there is IPv4. One can call it "IPv6-only SERVICE", but there's still IPv4 - so it's an "IPv4-based IPv6-only SERVICE". >> Actually, from where I look, I see many 'double stack' networks like >> these. > > There are plenty of examples of IPv4 only, IPv6 only, and IPv4v6 mobile > access networks. It's all being done. What the provider chooses to do > often has to do with their equipment vendor supports and how many IPv4 > addresses they might have. Also operational practices and preferences. Yes, the operational practices and preferences are very important. Their consequences too. Alex From nobody Mon Sep 25 02:21:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6C71330B0 for ; Mon, 25 Sep 2017 02:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gF24uqFKUcyo for ; Mon, 25 Sep 2017 02:21:00 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB55F1320C9 for ; Mon, 25 Sep 2017 02:20:59 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8P9Kw7G010897 for ; Mon, 25 Sep 2017 11:20:58 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EAD662091D5 for ; Mon, 25 Sep 2017 11:20:57 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E18042090F0 for ; Mon, 25 Sep 2017 11:20:57 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8P9KvA4026531 for ; Mon, 25 Sep 2017 11:20:57 +0200 To: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 11:20:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <4bf16a40ffd44e9498babf7094b1e526@orange.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:21:02 -0000 Le 25/09/2017 à 11:05, Kossut Tomasz - Hurt a écrit : > Hi, > > True ! 464xlat enabled IPv6 transition for mobile networks. Thank you ! > In IPv6-only network you can expect up to 60% native IPv6 ? I thought in an IPv6-only network there is 100% native IPv6? Alex > > Cheers, > > TK > > *From:*Lorenzo Colitti [mailto:lorenzo@google.com] > *Sent:* Monday, September 25, 2017 3:55 AM > *To:* Mark Andrews > *Cc:* Gert Doering; v6ops@ietf.org WG > *Subject:* Re: [v6ops] reclassify 464XLAT as standard instead of info > > On Sat, Sep 23, 2017 at 6:25 AM, Mark Andrews > wrote: > > Stop exaggerating.  Google went and added CLAT to the Android.  They > can just as easily add DS-Lite to Android and we would have billions > of machines that support DS-Lite.  Just because NAT64 and 464XLAT are > sexy doesn't mean that it is good technology. > > We added 464xlat to Android because there were credible deployment plans > in place for 464xlat on real networks that Android devices connect to. > In hindsight, we were right, as 464xlat went from credible plan to > successful deployment with an installed base in the tens of millions. > > I personally think that if we had not done this, we wouldn't have > IPv6-only mobile networks today and we'd all still be lamenting the > chicken and egg problem for IPv6-only networks. Getting rid of IPv4 in > the network is a great step forward, and as Apple has shown, once that's > happened, host OSes can start removing IPv4 access from applications, > too. (And make no mistake: without 464xlat, those networks would *not* > have gone IPv6-only, and it would have been much harder, or even > impossible, for Apple to say that apps must operate in IPv6-only > environments, because there would have been no such environments.) > > DS-Lite has no such credible deployment plans in place. Wifi networks > are going to provide IPv4 for many years. Mobile networks were never > going to deploy DS-Lite because the encapsulation would have broken > their billing platforms. And so, here we are. > > We'll all get to IPv6-only eventually, and some time after that, we'll > get rid of IPv4. At that time, you can salt the earth over 464xlat if > you want. But until then, I wouldn't be too eager to bash 464xlat as a > technology. It was the right thing to do at the time. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Sep 25 02:24:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FA21330B0 for ; Mon, 25 Sep 2017 02:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfPc8SetQ4XM for ; Mon, 25 Sep 2017 02:24:22 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB191320C9 for ; Mon, 25 Sep 2017 02:24:22 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8P9OKlg012483 for ; Mon, 25 Sep 2017 11:24:20 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0643C20916E for ; Mon, 25 Sep 2017 11:24:20 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E6CBC2091AC for ; Mon, 25 Sep 2017 11:24:19 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8P9OJQC029956 for ; Mon, 25 Sep 2017 11:24:19 +0200 To: v6ops@ietf.org References: <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> <20170922161337.GH45648@Space.Net> <20170924175047.GR45648@Space.Net> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 11:24:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:24:24 -0000 Le 25/09/2017 à 03:36, Lorenzo Colitti a écrit : > On Mon, Sep 25, 2017 at 2:50 AM, Gert Doering > wrote: > > Now, how can we get all those vendors with a big S to ship Android > upgrades for their phones on the market? > > (We'd *really* like bring back this host to the IPv6 world... and we > can't while the market share of unfixed devices is still so high.  So > maybe in a year or so...) > > > Can the radio station hand off to dual-stack URLs for working devices > and to IPv4-only URLs for broken devices? For example, based on user-agent? I am not sure what do you mean? There is no 'radio station' in 3GPP. There are however FM radio stations if you wish. Alex > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Sep 25 02:27:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F35133205 for ; Mon, 25 Sep 2017 02:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQOaRUTycUk8 for ; Mon, 25 Sep 2017 02:27:50 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33BFC1331FF for ; Mon, 25 Sep 2017 02:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506331668; x=1506936468; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=neEXzgvyFGEXQAslrYu9lKpwc v+w+D6l3hSUIJ9d47U=; b=LmPdxYs9kS8hseI9iyCrnsh7dT1FRMhrOdMOodYDT wld5LohUlUSGrOSi+2Ex72BzNIEK069CObaeu5Qhzl8cMLVOzdLJUUwG3yLZtwlL 8FhhLfeVzy059rIa8f95ZU100b/ZKYMNJw2IwyUNhs/8//GqJRFdCDwPN8tTE686 Ho= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=MOmA9VtV8M85Aq5vWRcBni+LIR06fX5yK6HLrCaZ/+qvGRqO4YQ6FMI4oC6O 4KwzEZYJ5nqFnJlxJk6jLcHQG70xrdylt9P6dCvlv9N9IrwzV/uudsJZu xaMSJKRqNudr6/h1zSMDh109+n81rjz3Xx9WVhu/qkPPxHfeLUujU4=; X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 11:27:48 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 11:27:47 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005566561.msg for ; Mon, 25 Sep 2017 11:27:47 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170925:md50005566561::zRazc5BFCj+XRRko:000098AQ X-Return-Path: prvs=1441fc161e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Mon, 25 Sep 2017 11:27:46 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:27:52 -0000 If you have IPv6-only access network, which is what 464XLAT is offering, yo= u have 100% IPv6-only in the access network. What you have at the customer sites/LANs and core/transit, is a different h= istory. This is the reason we need to have a clear definition =E2=80=A6 I will try = to update the document this week: draft-palet-ietf-v6ops-ipv6-only Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: lunes, 25 de septiembre de 2017, 11:21 Para: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info =20 =20 Le 25/09/2017 =C3=A0 11:05, Kossut Tomasz - Hurt a =C3=A9crit : > Hi, >=20 > True ! 464xlat enabled IPv6 transition for mobile networks. Thank you= !=20 > In IPv6-only network you can expect up to 60% native IPv6 =20 ? I thought in an IPv6-only network there is 100% native IPv6? =20 Alex =20 >=20 > Cheers, >=20 > TK >=20 > *From:*Lorenzo Colitti [mailto:lorenzo@google.com] > *Sent:* Monday, September 25, 2017 3:55 AM > *To:* Mark Andrews > *Cc:* Gert Doering; v6ops@ietf.org WG > *Subject:* Re: [v6ops] reclassify 464XLAT as standard instead of info >=20 > On Sat, Sep 23, 2017 at 6:25 AM, Mark Andrews > wrote: >=20 > Stop exaggerating. Google went and added CLAT to the Android. They > can just as easily add DS-Lite to Android and we would have billions > of machines that support DS-Lite. Just because NAT64 and 464XLAT are > sexy doesn't mean that it is good technology. >=20 > We added 464xlat to Android because there were credible deployment pl= ans=20 > in place for 464xlat on real networks that Android devices connect to= .=20 > In hindsight, we were right, as 464xlat went from credible plan to=20 > successful deployment with an installed base in the tens of millions. >=20 > I personally think that if we had not done this, we wouldn't have=20 > IPv6-only mobile networks today and we'd all still be lamenting the= =20 > chicken and egg problem for IPv6-only networks. Getting rid of IPv4 i= n=20 > the network is a great step forward, and as Apple has shown, once tha= t's=20 > happened, host OSes can start removing IPv4 access from applications,= =20 > too. (And make no mistake: without 464xlat, those networks would *not= *=20 > have gone IPv6-only, and it would have been much harder, or even=20 > impossible, for Apple to say that apps must operate in IPv6-only=20 > environments, because there would have been no such environments.) >=20 > DS-Lite has no such credible deployment plans in place. Wifi networks= =20 > are going to provide IPv4 for many years. Mobile networks were never= =20 > going to deploy DS-Lite because the encapsulation would have broken= =20 > their billing platforms. And so, here we are. >=20 > We'll all get to IPv6-only eventually, and some time after that, we'l= l=20 > get rid of IPv4. At that time, you can salt the earth over 464xlat if= =20 > you want. But until then, I wouldn't be too eager to bash 464xlat as = a=20 > technology. It was the right thing to do at the time. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Sep 25 02:37:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C238C133208 for ; Mon, 25 Sep 2017 02:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYl0k6R5CJlT for ; Mon, 25 Sep 2017 02:37:53 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BA51331E3 for ; Mon, 25 Sep 2017 02:37:52 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8P9bpGS018324 for ; Mon, 25 Sep 2017 11:37:51 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F16922091BB for ; Mon, 25 Sep 2017 11:37:50 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E8486202272 for ; Mon, 25 Sep 2017 11:37:50 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8P9bosO010729 for ; Mon, 25 Sep 2017 11:37:50 +0200 To: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 11:37:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:37:55 -0000 Le 25/09/2017 à 11:27, JORDI PALET MARTINEZ a écrit : > If you have IPv6-only access network, which is what 464XLAT is > offering, you have 100% IPv6-only in the access network. Is that IPv6-only access network using GTP-IPv6? (a 3GPP spec that may exist that I dont have number) Or is it using ATM? (IPv6 over ATM RFC2492, ATM is widely used to connect in-house networks to an operator) > What you have at the customer sites/LANs and core/transit, is a > different history. > > This is the reason we need to have a clear definition … I will try > to update the document this week: > > draft-palet-ietf-v6ops-ipv6-only > 3. IPv6-only > > IPv6-only MUST be used only if, a complete network, end-to-end, is > actually not forwarding IPv4 at layer-2, which will mean that no-IPv4 > addresses are configured, neither used for management, neither the > network is providing transition/translation support, neither there is > IPv4 transit/peering. Is this "IPv6-only" something wrong? What do you mean by "forwarding IPv4 at layer2". IP is at layer 3, be it v4 or v6. IP encapsulation is also layer 3. Alex > > Regards, Jordi > > > -----Mensaje original----- De: v6ops en > nombre de Alexandre Petrescu > Responder a: Fecha: lunes, 25 de > septiembre de 2017, 11:21 Para: Asunto: Re: [v6ops] > reclassify 464XLAT as standard instead of info > > > > Le 25/09/2017 à 11:05, Kossut Tomasz - Hurt a écrit : >> Hi, >> >> True ! 464xlat enabled IPv6 transition for mobile networks. Thank >> you ! In IPv6-only network you can expect up to 60% native IPv6 > > ? I thought in an IPv6-only network there is 100% native IPv6? > > Alex > >> >> Cheers, >> >> TK >> >> *From:*Lorenzo Colitti [mailto:lorenzo@google.com] *Sent:* Monday, >> September 25, 2017 3:55 AM *To:* Mark Andrews *Cc:* Gert Doering; >> v6ops@ietf.org WG *Subject:* Re: [v6ops] reclassify 464XLAT as >> standard instead of info >> >> On Sat, Sep 23, 2017 at 6:25 AM, Mark Andrews > > wrote: >> >> Stop exaggerating. Google went and added CLAT to the Android. They >> can just as easily add DS-Lite to Android and we would have >> billions of machines that support DS-Lite. Just because NAT64 and >> 464XLAT are sexy doesn't mean that it is good technology. >> >> We added 464xlat to Android because there were credible deployment >> plans in place for 464xlat on real networks that Android devices >> connect to. In hindsight, we were right, as 464xlat went from >> credible plan to successful deployment with an installed base in >> the tens of millions. >> >> I personally think that if we had not done this, we wouldn't have >> IPv6-only mobile networks today and we'd all still be lamenting the >> chicken and egg problem for IPv6-only networks. Getting rid of IPv4 >> in the network is a great step forward, and as Apple has shown, >> once that's happened, host OSes can start removing IPv4 access from >> applications, too. (And make no mistake: without 464xlat, those >> networks would *not* have gone IPv6-only, and it would have been >> much harder, or even impossible, for Apple to say that apps must >> operate in IPv6-only environments, because there would have been no >> such environments.) >> >> DS-Lite has no such credible deployment plans in place. Wifi >> networks are going to provide IPv4 for many years. Mobile networks >> were never going to deploy DS-Lite because the encapsulation would >> have broken their billing platforms. And so, here we are. >> >> We'll all get to IPv6-only eventually, and some time after that, >> we'll get rid of IPv4. At that time, you can salt the earth over >> 464xlat if you want. But until then, I wouldn't be too eager to >> bash 464xlat as a technology. It was the right thing to do at the >> time. >> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If > you are not the intended recipient be aware that any disclosure, > copying, distribution or use of the contents of this information, > even if partially, including attached files, is strictly prohibited, > will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Sep 25 02:48:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD081332C8 for ; Mon, 25 Sep 2017 02:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5YCqMNaXm43r for ; Mon, 25 Sep 2017 02:48:05 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C5C1331F2 for ; Mon, 25 Sep 2017 02:48:05 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id b195so17645184wmb.5 for ; Mon, 25 Sep 2017 02:48:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Km7u52bkA9NutKA2HwS+GsXqb3QcTGtCUOepgF2t9YA=; b=vtJsqx22wHtd2FWYUIBgyWnxwvxKY6LLTCrF0Zn2f1h2fSRFkqFwA9HRmIju3NYxtZ WUeD/yDt8eTQxU+tuGOgolv36FLV9uREdelHpapx9iOOeaSks9jJH8iezbpXiPo8U+5K zMfrlWqrz3SouEHFg1tlL6u8mIOsC1QiDegIrKJxfTtxYGs7+vwcNcQgZu98uwAJledY s2UfxvoQ7Y50nE3L/ArZH2Gh2YtkUPJLbRj1BT4pWXSGzbGuOaGO+I2quIvQ3AaAaGCm QZDtEoUz5+OkMeeooWAxC3xoivQMpMVnTxzXJAVDIT03uCIh9uehgiSPN7iE8NE38F2P sBzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Km7u52bkA9NutKA2HwS+GsXqb3QcTGtCUOepgF2t9YA=; b=NBwjuBEJcNHtNfchYL3PvXCjDwkdUvctyXB3jv65yoKp1XPsOC70AbK2015+I9Teka 390LNIGnN6EKbQUzbkaHCkS6dmpeiCPQkubeuZ+JcbPg8DGawVMx75xYmkKO+R3994l1 fO9Md6cUBZCFzcrNbnGMgSy2anR8TQg/xn0JdIq+t0YiKC4u2eH/2zb6JyGQ08SZWExl VZDEWMJ7gJhXUlxUl163d9bFCwRo5WXo1DYZQLT8LDVpfyh0egsmc5GNlKkKA5MAbCNE Al1BupbG9g3w9Xc039sIGbED34AYtKN0SVAD2fci9xGB5nx9qFqu48PLgnAeBR2aVS0o XeZw== X-Gm-Message-State: AHPjjUi6avaGtPKlNPtPrcNqI1S2tZ0qQRf7jxbLSL+F4YoYb0IPIj5v Yx/IPCN5vHgXya/LXTAYzQNL17DddYsqIWjTa5FAwg== X-Google-Smtp-Source: AOwi7QCiCjjZV4/lkSer+tGhZB0ABoLDmN8Uj9UJsGvodfGc7mZc3jbwrtqBsUiiB6yckBevuW/c5BjFboG5iZoz5tM= X-Received: by 10.28.238.218 with SMTP id j87mr10124894wmi.44.1506332883249; Mon, 25 Sep 2017 02:48:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Mon, 25 Sep 2017 02:47:41 -0700 (PDT) In-Reply-To: References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> From: Erik Kline Date: Mon, 25 Sep 2017 18:47:41 +0900 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1146d9e273b933055a0074fc" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:48:07 -0000 --001a1146d9e273b933055a0074fc Content-Type: text/plain; charset="UTF-8" When speaking from the perspective of a client OS I have frequently observed and understood the phrase "IPv6-only network" to mean that the link to which the client is connected only provisions and forwards IPv6 packets. IPv4 /may/ be available to the client as a service on these "IPv6-only networks" within this definition, whether by 464xlat or VPN or by some other means. But that never seems to change the implied meaning of "IPv6-only network" in these contexts. Just an observation. --001a1146d9e273b933055a0074fc Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgsYgRbapym3/qOrsVIIYRAGK34Gy5/Ig1 xTzpbZppzzowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTI1 MDk0ODAzWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAHr9PXFxan7ZKYwHPtRUEJI1pJ26/IYN803UoouuZf9rPsBqtXZc 3kD5uHVvxMWu3AJOh+upAv/P997lGtB6EXwrpSR+8MxQnC/j13rGLbJBbXXPjNWaHJkmnjB0Foor IlOkRNpX4ZfT0G9qsANEy949q7gCQ3vSRviqpr9bGvSMbxRZJVV8G8cwi9Ut82EoIFvyiqjrY4z+ dSRtgwXKB0v4RbUsHj6rWPPyU3JL9Z+eH74wnknBHvvGePCnYYpFlQIlZSnRKOuSyHD9iqRYFjYV 4Cf8tohJwm+aSxmJ+1MWXXqb+azMyNenEJ+xlVADUBkwhCDHskseshInWCEOk5s= --001a1146d9e273b933055a0074fc-- From nobody Mon Sep 25 02:49:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4E51332F2 for ; Mon, 25 Sep 2017 02:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q447D000anPr for ; Mon, 25 Sep 2017 02:48:59 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA431332D7 for ; Mon, 25 Sep 2017 02:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506332937; x=1506937737; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=9EKKoCAavQR1TUSxWUyfnoEI6 f3gZn1FuhHJmm7AEDs=; b=mUohkgx4e0r6IMETiOPIbiItQI4pzlm3uj8xbNNb5 ecdDLsE0kbRKRT52DnDH4akVppZJeFztSITcllHu7gLpQhqxzBrq9C/vRuanX76g yh6pFC5g0DlmUWe7NULI8DawiiVwGUCe8h2O7o2NRovcn2iXsvFrOX3RdPdEbAeP RE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=DBcIOo1Bo75jTxOexnoSHdM+AnkfEW/YwqW2CS8DX1XSMAHQ6al//kQbTHBd UTjmtzxLa8NXML9W+MsQmC0ErJFRtWj4BMEC/7bWghlt1CEdOh0w3eDsG t8YF+VZyvI9y7j1OijjDmsnWe1/rH4eR1L7DWsm9QwxFjCsg1KeUrM=; X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 11:48:57 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 11:48:56 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005566597.msg for ; Mon, 25 Sep 2017 11:48:55 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170925:md50005566597::fZOAxoQ6EqQdvmGW:00003qPZ X-Return-Path: prvs=1441fc161e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Mon, 25 Sep 2017 11:48:53 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:49:01 -0000 Is this "IPv6-only" something wrong? What do you mean by "forwarding= =20 IPv4 at layer2". IP is at layer 3, be it v4 or v6. IP encapsulation= =20 is also layer 3. =20 I=E2=80=99m going to make it clear in the new version. I mean using the in = a layer 2 link =E2=80=9Cnative IPv4 or native IPv6=E2=80=9D. IPv6-only refe= rs to =E2=80=9Conly=E2=80=9D transporting native IPv6 packets, if IPv4 is t= ranslated or encapsulated on top of IPv6, then IPv4 is using the IPv6 as = =E2=80=9Cif it was=E2=80=9D a layer-2. =20 > > Regards, Jordi >=20 >=20 > -----Mensaje original----- De: v6ops en=20 > nombre de Alexandre Petrescu > Responder a: Fecha: lunes, 25 de > septiembre de 2017, 11:21 Para: Asunto: Re: [v6ops] > reclassify 464XLAT as standard instead of info >=20 >=20 >=20 > Le 25/09/2017 =C3=A0 11:05, Kossut Tomasz - Hurt a =C3=A9crit : >> Hi, >>=20 >> True ! 464xlat enabled IPv6 transition for mobile networks. Thank=20 >> you ! In IPv6-only network you can expect up to 60% native IPv6 >=20 > ? I thought in an IPv6-only network there is 100% native IPv6? >=20 > Alex >=20 >>=20 >> Cheers, >>=20 >> TK >>=20 >> *From:*Lorenzo Colitti [mailto:lorenzo@google.com] *Sent:* Monday,= =20 >> September 25, 2017 3:55 AM *To:* Mark Andrews *Cc:* Gert Doering;=20 >> v6ops@ietf.org WG *Subject:* Re: [v6ops] reclassify 464XLAT as=20 >> standard instead of info >>=20 >> On Sat, Sep 23, 2017 at 6:25 AM, Mark Andrews > > wrote: >>=20 >> Stop exaggerating. Google went and added CLAT to the Android. They >> can just as easily add DS-Lite to Android and we would have=20 >> billions of machines that support DS-Lite. Just because NAT64 and= =20 >> 464XLAT are sexy doesn't mean that it is good technology. >>=20 >> We added 464xlat to Android because there were credible deployment= =20 >> plans in place for 464xlat on real networks that Android devices=20 >> connect to. In hindsight, we were right, as 464xlat went from=20 >> credible plan to successful deployment with an installed base in=20 >> the tens of millions. >>=20 >> I personally think that if we had not done this, we wouldn't have=20 >> IPv6-only mobile networks today and we'd all still be lamenting the >> chicken and egg problem for IPv6-only networks. Getting rid of IPv4 >> in the network is a great step forward, and as Apple has shown, >> once that's happened, host OSes can start removing IPv4 access from >> applications, too. (And make no mistake: without 464xlat, those >> networks would *not* have gone IPv6-only, and it would have been >> much harder, or even impossible, for Apple to say that apps must >> operate in IPv6-only environments, because there would have been no >> such environments.) >>=20 >> DS-Lite has no such credible deployment plans in place. Wifi=20 >> networks are going to provide IPv4 for many years. Mobile networks= =20 >> were never going to deploy DS-Lite because the encapsulation would= =20 >> have broken their billing platforms. And so, here we are. >>=20 >> We'll all get to IPv6-only eventually, and some time after that,=20 >> we'll get rid of IPv4. At that time, you can salt the earth over=20 >> 464xlat if you want. But until then, I wouldn't be too eager to=20 >> bash 464xlat as a technology. It was the right thing to do at the=20 >> time. >>=20 >>=20 >>=20 >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** IPv4 is over Are you= =20 > ready for the new Internet ? http://www.consulintel.es The IPv6=20 > Company >=20 > This electronic message contains information which may be privileged= =20 > or confidential. The information is intended to be for the exclusive= =20 > use of the individual(s) named above and further non-explicilty=20 > authorized disclosure, copying, distribution or use of the contents= =20 > of this information, even if partially, including attached files, is= =20 > strictly prohibited and will be considered a criminal offense. If > you are not the intended recipient be aware that any disclosure, > copying, distribution or use of the contents of this information, > even if partially, including attached files, is strictly prohibited, > will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Sep 25 02:51:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4ECE1331F2 for ; Mon, 25 Sep 2017 02:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZ0OLVbegtCD for ; Mon, 25 Sep 2017 02:51:32 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25E11321A2 for ; Mon, 25 Sep 2017 02:51:31 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8P9pUe2029032 for ; Mon, 25 Sep 2017 11:51:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3FD41209280 for ; Mon, 25 Sep 2017 11:51:30 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 364CB20916E for ; Mon, 25 Sep 2017 11:51:30 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8P9pT3E023153 for ; Mon, 25 Sep 2017 11:51:30 +0200 To: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 11:51:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:51:34 -0000 Le 25/09/2017 à 11:48, JORDI PALET MARTINEZ a écrit : > > Is this "IPv6-only" something wrong? What do you mean by "forwarding > IPv4 at layer2". IP is at layer 3, be it v4 or v6. IP > encapsulation is also layer 3. > > I’m going to make it clear in the new version. I mean using the in a > layer 2 link “native IPv4 or native IPv6”. IPv6-only refers to > “only” transporting native IPv6 packets, if IPv4 is translated or > encapsulated on top of IPv6, then IPv4 is using the IPv6 as “if it > was” a layer-2. The explanation sounds as reasonable beginning, but would need refinement, I think. I also heard the term "native IPv6". This means there is no IPv4. Would you accept a definition of the term "native IPv6" in the draft? Alex > >> >> Regards, Jordi >> >> >> -----Mensaje original----- De: v6ops en >> nombre de Alexandre Petrescu >> Responder a: Fecha: lunes, 25 de >> septiembre de 2017, 11:21 Para: Asunto: Re: >> [v6ops] reclassify 464XLAT as standard instead of info >> >> >> >> Le 25/09/2017 à 11:05, Kossut Tomasz - Hurt a écrit : >>> Hi, >>> >>> True ! 464xlat enabled IPv6 transition for mobile networks. Thank >>> you ! In IPv6-only network you can expect up to 60% native IPv6 >> >> ? I thought in an IPv6-only network there is 100% native IPv6? >> >> Alex >> >>> >>> Cheers, >>> >>> TK >>> >>> *From:*Lorenzo Colitti [mailto:lorenzo@google.com] *Sent:* >>> Monday, September 25, 2017 3:55 AM *To:* Mark Andrews *Cc:* Gert >>> Doering; v6ops@ietf.org WG *Subject:* Re: [v6ops] reclassify >>> 464XLAT as standard instead of info >>> >>> On Sat, Sep 23, 2017 at 6:25 AM, Mark Andrews >> > wrote: >>> >>> Stop exaggerating. Google went and added CLAT to the Android. >>> They can just as easily add DS-Lite to Android and we would have >>> billions of machines that support DS-Lite. Just because NAT64 >>> and 464XLAT are sexy doesn't mean that it is good technology. >>> >>> We added 464xlat to Android because there were credible >>> deployment plans in place for 464xlat on real networks that >>> Android devices connect to. In hindsight, we were right, as >>> 464xlat went from credible plan to successful deployment with an >>> installed base in the tens of millions. >>> >>> I personally think that if we had not done this, we wouldn't have >>> IPv6-only mobile networks today and we'd all still be lamenting >>> the chicken and egg problem for IPv6-only networks. Getting rid >>> of IPv4 in the network is a great step forward, and as Apple has >>> shown, once that's happened, host OSes can start removing IPv4 >>> access from applications, too. (And make no mistake: without >>> 464xlat, those networks would *not* have gone IPv6-only, and it >>> would have been much harder, or even impossible, for Apple to say >>> that apps must operate in IPv6-only environments, because there >>> would have been no such environments.) >>> >>> DS-Lite has no such credible deployment plans in place. Wifi >>> networks are going to provide IPv4 for many years. Mobile >>> networks were never going to deploy DS-Lite because the >>> encapsulation would have broken their billing platforms. And so, >>> here we are. >>> >>> We'll all get to IPv6-only eventually, and some time after that, >>> we'll get rid of IPv4. At that time, you can salt the earth over >>> 464xlat if you want. But until then, I wouldn't be too eager to >>> bash 464xlat as a technology. It was the right thing to do at >>> the time. >>> >>> >>> >>> _______________________________________________ v6ops mailing >>> list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> ********************************************** IPv4 is over Are you >> ready for the new Internet ? http://www.consulintel.es The IPv6 >> Company >> >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be for >> the exclusive use of the individual(s) named above and further >> non-explicilty authorized disclosure, copying, distribution or use >> of the contents of this information, even if partially, including >> attached files, is strictly prohibited and will be considered a >> criminal offense. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents >> of this information, even if partially, including attached files, >> is strictly prohibited, will be considered a criminal offense, so >> you must reply to the original sender to inform about this >> communication and delete it. >> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If > you are not the intended recipient be aware that any disclosure, > copying, distribution or use of the contents of this information, > even if partially, including attached files, is strictly prohibited, > will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Sep 25 02:53:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F1213331E for ; Mon, 25 Sep 2017 02:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKhml5_25WvF for ; Mon, 25 Sep 2017 02:53:17 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7477F13330E for ; Mon, 25 Sep 2017 02:53:17 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5B638B2; Mon, 25 Sep 2017 11:53:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506333195; bh=ZQ3MZmgRfxtAP68OlJD5Lzoy0pmIYQXErhklYU0dcrY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=icXVlijFHQQVR7m8lhDPtsB26yTC1BLMq46NYXkW3g986anqnG7fyZ7vZgRhM1T09 kBWbjP2kLfUCRiNa9hu+om1FRDivTx10nNynuWs+gNo0N/0mf6zkWGz1s1ClM6mwM6 I+yLHhK2+NW0gkLRIqfn4p9BS0fcEpqV8wJ/CoOU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 58D97B1; Mon, 25 Sep 2017 11:53:15 +0200 (CEST) Date: Mon, 25 Sep 2017 11:53:15 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Lee Howard , v6ops@ietf.org In-Reply-To: <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> Message-ID: References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:53:19 -0000 On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > I mean GTPU protocol that uses IPv4 addresses, and carries IPv6 packets This is not something the end user device sees or cares about. Why are you bringing this up? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 25 02:56:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52435133341 for ; Mon, 25 Sep 2017 02:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akkpbxzO9FE1 for ; Mon, 25 Sep 2017 02:56:30 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878D6132EC4 for ; Mon, 25 Sep 2017 02:56:30 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id x54so6226865qth.12 for ; Mon, 25 Sep 2017 02:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=48W0d951Hm34+k+HXs+0bcouTumVNtkTJ4m6XlAX+5w=; b=cnFI4QNpW29Q8pHMs1HJEJ+BoCkEOf9mhRZJQbYZssC3I+R7v4o2BxXF6+yqddYYSM HtSOCQwfVSIB/WU490SwYtyTHZmGA1JvgdXTUOYovC/yJuSPXnC6qfnNDYJaNSJTCwlM sUBWGucrdZBaK5lMa9MVYJMetsEOA3QcaDcX3ZQIb5H1ykO/iHeg/jCsN+SXZ1+8juEr tvknUOeLjZU8rqNpFbzeui0+S0rGM04YEQPSp45Fcw+/cvJdrBQVN/HFENtHPxLK3wWj M0csPTsZuGd+mx/e1pHJCKC98/ZdVc2x1WjfCGdCfTiCH1+PSoB5LFFP4zQ1g6XGzn9O C55Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=48W0d951Hm34+k+HXs+0bcouTumVNtkTJ4m6XlAX+5w=; b=IrRtAIAPpN01kWsLER4rY1jLGEaChI1yDbDuFKtLGEZXyDsetANCSWI4AcMy0vv975 3oXjLTIgOYQhAMQItcdNXKZWetmn+Zy+qcbdM0g+Jpt632plTa/MbWw52rK7UXAxslLF YApa3bE/TR3q342otkNvR07sKxC/ob6/VbGpetelbPxm2i35RK2iM9PDz54KipL7RnaL D9b4I271yKkTXdvx1qVqgKuVqvpKct+py/79p1dBEIOdKkm2NbhpOXGm3Z18nV2pvyjX bHZKU2o+EXZvyjjcPY18cszSPTyuidlIpbkMGv7bbh09niXOOd+bXuxN/ZovbQAW3ARD w1Jw== X-Gm-Message-State: AHPjjUjfdesOE8QeVFUmCLRrMne6GOFgJEbcN3PH8KmBL3GYrb5cUAOO O7rx1ephac4q7zQ0J2HdFncdSoJT X-Received: by 10.237.62.176 with SMTP id n45mr9676152qtf.302.1506333389531; Mon, 25 Sep 2017 02:56:29 -0700 (PDT) Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com. [209.85.220.169]) by smtp.gmail.com with ESMTPSA id p77sm4508098qkp.44.2017.09.25.02.56.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 02:56:28 -0700 (PDT) Received: by mail-qk0-f169.google.com with SMTP id s132so6074315qke.7 for ; Mon, 25 Sep 2017 02:56:28 -0700 (PDT) X-Google-Smtp-Source: AOwi7QCHoHygewTIe+OD+kKt9uFQwbfGDBE6feguoWOnQoNwTapIo9IQvU4sBBW+WVfFTfr9SFD7LYLIDyrGB+WlxAQ= X-Received: by 10.55.159.80 with SMTP id i77mr9764924qke.76.1506333388729; Mon, 25 Sep 2017 02:56:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.101.183 with HTTP; Mon, 25 Sep 2017 02:56:08 -0700 (PDT) In-Reply-To: <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> From: Richard Patterson Date: Mon, 25 Sep 2017 10:56:08 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "v6ops@ietf.org list" Content-Type: multipart/alternative; boundary="001a114d39448c7aaf055a009248" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:56:32 -0000 --001a114d39448c7aaf055a009248 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 25 September 2017 at 10:20, Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > > Le 25/09/2017 =C3=A0 10:28, Mikael Abrahamsson a =C3=A9crit : > >> >> We're talking about what access service is provided to the customers, an= d >> there are several that do IPv6 only GTP. Yes, the GTP packets might be >> carried over IPv4, but the SERVICE provided to the customer is IPv6 only= . >> > > Excuse me, Mikael, but it is little possible to claim "IPv6-only" when > there is IPv4. One can call it "IPv6-only SERVICE", but there's still IP= v4 > - so it's an "IPv4-based IPv6-only SERVICE". > That's like saying 6PE isn't good enough, which is ridiculous. If the end-to-end customer-visible service is IPv6, what's the problem? --001a114d39448c7aaf055a009248 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On 25 September 2017 at 10:20, Alexandre Petrescu <alexandre.pe= trescu@gmail.com> wrote:
Le 25/09/2017 =C3=A0 10:28, Mikael Abrahamsson a =C3=A9crit=C2=A0:

We're talking about what access service is provided to the customers, a= nd there are several that do IPv6 only GTP. Yes, the GTP packets might be c= arried over IPv4, but the SERVICE provided to the customer is IPv6 only.

Excuse me, Mikael, but it is little possible to claim "IPv6-only"= when there is IPv4.=C2=A0 One can call it "IPv6-only SERVICE", b= ut there's still IPv4 - so it's an "IPv4-based IPv6-only SERVI= CE".


That's lik= e saying 6PE isn't good enough, which is ridiculous.
If the e= nd-to-end customer-visible service is IPv6, what's the problem?

--001a114d39448c7aaf055a009248-- From nobody Mon Sep 25 02:57:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229D5133347 for ; Mon, 25 Sep 2017 02:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecVDyOa_uWqG for ; Mon, 25 Sep 2017 02:57:14 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8083E133344 for ; Mon, 25 Sep 2017 02:57:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8P9vBV1026188; Mon, 25 Sep 2017 11:57:11 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 89EA7203DED; Mon, 25 Sep 2017 11:57:11 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7CE1720226F; Mon, 25 Sep 2017 11:57:11 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8P9vBGT028054; Mon, 25 Sep 2017 11:57:11 +0200 To: Erik Kline Cc: "v6ops@ietf.org" References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> From: Alexandre Petrescu Message-ID: <9862ff34-8eea-c18a-88e5-d017630efefa@gmail.com> Date: Mon, 25 Sep 2017 11:57:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 09:57:16 -0000 Erik, I would like to ask you clarification. Le 25/09/2017 à 11:47, Erik Kline a écrit : > When speaking from the perspective of a client OS What is a "client OS"? I think OSs are both clients and servers. > I have frequently observed and understood the phrase "IPv6-only > network" to mean that the link to which the client is connected only > provisions and forwards IPv6 packets. I agree with this definition of "IPv6-only network". I would stress to also mean "no IPv4" - be it encapsulation, translation, or DNS-x-y. > IPv4 /may/ be available to the client as a service on these > "IPv6-only networks" within this definition, Yes. But not as a "service". I never heard about "IP as a service" other than some people at IETF, and other than in the context of a particular operator. IP is not a service. Services are at the services layer. APIs are services, there is remote access service, etc. > whether by 464xlat or VPN or by some other means. VPN and encapsulations are also called "virtual networks". Is the "IPv6-as-a-service" a "virtual network"? If so, we want "IPv6 as a real network". > But that never seems to change the implied meaning of "IPv6-only > network" in these contexts. Depends who you ask. Alex > > Just an observation. > From nobody Mon Sep 25 03:04:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79111332D5 for ; Mon, 25 Sep 2017 03:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL5XQ_ckr3S6 for ; Mon, 25 Sep 2017 03:04:54 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF1C1321A7 for ; Mon, 25 Sep 2017 03:04:53 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8657EB1; Mon, 25 Sep 2017 12:04:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506333891; bh=tI7zvo2o1xe9cADbdjxC42bhSh1HHBUF00/cxSAJv6Q=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=OVvTBO12NR5LNSwgZ0md55lM8GgJ1dkiRbyKEYwKr3M0/zLIF1+VDIrJ5BfbT/+xH ZSSu+XyuRAVkwTE5ar+IPlxZnGGoQQJLxpZfEEFEQjyMvHrqa74T9Bokn5+H+UAmq5 T5mGiQJuqfKsa7yQslKc4dCWX8yYtTpc0MrMKQpU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7049D84; Mon, 25 Sep 2017 12:04:51 +0200 (CEST) Date: Mon, 25 Sep 2017 12:04:51 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Erik Kline , "v6ops@ietf.org" In-Reply-To: <9862ff34-8eea-c18a-88e5-d017630efefa@gmail.com> Message-ID: References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <9862ff34-8eea-c18a-88e5-d017630efefa@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:04:55 -0000 On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > I agree with this definition of "IPv6-only network". I would stress to > also mean "no IPv4" - be it encapsulation, translation, or DNS-x-y. You're in extreme minority to have that definition. I don't care if my IP packet provider carries my packets over POS, ethernet, if they run native IPv4, IPv6 or MPLS in their core, if they use LDPv4 or LDPv6 for their control plane etc. What I care about is what I need to configure my equipment with to talk to them. So an IPv6 only access uses only IPv6 packets in the access line, that the device can see. What happens in the ISP network once the packets hits that part is out of scope for the definition of IPv6 only access. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 25 03:05:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAC1133352 for ; Mon, 25 Sep 2017 03:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 n83EDditCBrL for ; Mon, 25 Sep 2017 03:05:18 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233391321A7 for ; Mon, 25 Sep 2017 03:05:10 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t127so4336883ywg.4 for ; Mon, 25 Sep 2017 03:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zX4a3nmyKp81HUyf1XbSuhipbAdo4E6qGc2XEGHYyAg=; b=HMFPgXPI535UaCW82x2FrEjxjOb4F+wE2GRWHmc0RwxSB16WVpFMLU8HrqqVC0xuOt Qjpy8YN+mUFeiP9Zrqut3mL4no3y2wbhIkjh8uNUDRmt2O7OBV/XL780vLzLBDY6Js5i mUghLaL389PzbqnzZ7aVvUgdcmxMyZwM17F02g03uYMaSXN22RbdxRvzxbZGZXmuiCYf 9q8MROtmDfc/Lo5SpYLhlFkWU/pRepFqAhT3HEqx20gflR3UEf5Op5Tv4JGG3S5F+9+i vMSWsy/Je18S1kXglOiAVgWbw+iMOEmN7k4HflPCIDJpbCcNTBjRCAYGIQZ2JBxWNhTb cfvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zX4a3nmyKp81HUyf1XbSuhipbAdo4E6qGc2XEGHYyAg=; b=EE80qabVJoXtCjhtf6+XfJo7QbQL+nTng9OgDDeZZNTR0nC260vpMHOJh9Qw/GBi5u +LFcuVxJ09eM1yPE2dxUNGb4wn7cj71xQlklY8af5HT0+ZzXP9fb2bLgKou8cVLHCLJP asRYqlVHin12KvIHR9wYte84czExBgEcpmQYF7hAUU5aLOpbtRlqOzUmA6O7qExjEnD0 kNnBe43ZoUevIZxc2alvvk1rK3Xp3w7xb4vX60V+PndKT/2CUDeUpfU9N5AZn+JffeBR +ZVOhvYmj1vtuArwGnE3Er37fvvYt8gPlUguT0IRwH5JklNkutiKZqJyOf0vIs4NX+Pm 9vdg== X-Gm-Message-State: AHPjjUhpK/16TURtubapV481ZnzIWXZWbN50gA1Y0sAymYSqe0LJMmvq OJm73qys4wjfDpVOtzKZM46zFgj1K6YDrt3Wk1le43d/ X-Google-Smtp-Source: AOwi7QCYo4TetHUNR/Yp1NH0+YNSdr1z3LT8FB55PG31Jn+lxA4KUjnHo37o/4kvJa/mUQgcRgJ9wVF2LL9yYcZJ7Fk= X-Received: by 10.129.169.9 with SMTP id g9mr3993356ywh.501.1506333908969; Mon, 25 Sep 2017 03:05:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Mon, 25 Sep 2017 03:04:46 -0700 (PDT) In-Reply-To: <9862ff34-8eea-c18a-88e5-d017630efefa@gmail.com> References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <9862ff34-8eea-c18a-88e5-d017630efefa@gmail.com> From: Erik Kline Date: Mon, 25 Sep 2017 19:04:46 +0900 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114ae65a98a242055a00b17c" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:05:24 -0000 --001a114ae65a98a242055a00b17c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 25 September 2017 at 18:57, Alexandre Petrescu wrote: > Erik, > > I would like to ask you clarification. I'm sorry but there is more clarification asked for and indeed required here than I have time for. Forget I said anything. > > Le 25/09/2017 =C3=A0 11:47, Erik Kline a =C3=A9crit : >> >> When speaking from the perspective of a client OS > > > What is a "client OS"? I think OSs are both clients and servers. > >> I have frequently observed and understood the phrase "IPv6-only network" >> to mean that the link to which the client is connected only provisions a= nd >> forwards IPv6 packets. > > > I agree with this definition of "IPv6-only network". I would stress to > also mean "no IPv4" - be it encapsulation, translation, or DNS-x-y. > >> IPv4 /may/ be available to the client as a service on these "IPv6-only >> networks" within this definition, > > > Yes. But not as a "service". I never heard about "IP as a service" > other than some people at IETF, and other than in the context of a > particular operator. > > IP is not a service. > > Services are at the services layer. APIs are services, there is remote > access service, etc. > >> whether by 464xlat or VPN or by some other means. > > > VPN and encapsulations are also called "virtual networks". > > Is the "IPv6-as-a-service" a "virtual network"? > > If so, we want "IPv6 as a real network". > >> But that never seems to change the implied meaning of "IPv6-only >> network" in these contexts. > > > Depends who you ask. > > Alex > >> >> Just an observation. >> > --001a114ae65a98a242055a00b17c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgN8xc4sGYZdRRbzwV+ob0Lct9voXrM2uf oQ5qQcQPSJ8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTI1 MTAwNTA5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAAmxzgUNOiCqgU94Biul510APQ768q1RaSoaWyFDxZhU20TM1wC9 7ZTpNxKhPXRcIIPP2UKKZo+hajrZYyAKcRPbpRHYMZZv5v7LlYxYGoPONOAhpF6e/1BYGR7+atvu i9VwXIXZRsGmue9MmdHTm6Oqd4SXd/PiPEm2XoWgwWeBYCY5v5BKfERnHhTC0N8w1NUVkqqzWE+k KFiPbWrqtIBdMS6UBSTX26l7g4vpQP03wL6xAm6zEkvRFumUttKqD0uanBnFPa5G/TXoYKBlZBHo IJ+I3bMz3b1OPAcsScMcKV1LmZUtBdMbl7iblseFnqjR5O6cSTZXJmO3MHWfc1A= --001a114ae65a98a242055a00b17c-- From nobody Mon Sep 25 03:07:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB4E1332D5 for ; Mon, 25 Sep 2017 03:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_zavsfqcOva for ; Mon, 25 Sep 2017 03:07:37 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377EF1321A7 for ; Mon, 25 Sep 2017 03:07:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PA7WEp030350; Mon, 25 Sep 2017 12:07:32 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6338E2092DF; Mon, 25 Sep 2017 12:07:32 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 540CC2092D9; Mon, 25 Sep 2017 12:07:32 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PA7W6J005278; Mon, 25 Sep 2017 12:07:32 +0200 To: Mikael Abrahamsson Cc: Lee Howard , v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 12:07:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:07:38 -0000 Le 25/09/2017 à 11:53, Mikael Abrahamsson a écrit : > On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > >> I mean GTPU protocol that uses IPv4 addresses, and carries IPv6 packets > > This is not something the end user device sees or cares about. But the end-user device connects to a network, and you claim that network is IPv6-only. You claim that because there are networks that are IPv6-only then devices must run CLAT. But what is "IPv6-only networks"? Do they use IPv4 though? > Why are > you bringing this up? Because I need to understand whether the APNs dedicated to CLAT run IPv6-only. Do these networks do GTP-v4? And PDP type IPv4-IPv6? One would like to have coherence between IPv4, IPv6, APN type, PDP type, encapsulations, translations. The ideal is "double stack" - no encap, no translation, no IN A in UDPv6 packets, no IN AAAA in UDPv4 packets, and PDP type v4v6. Alex From nobody Mon Sep 25 03:12:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC141332DA for ; Mon, 25 Sep 2017 03:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLoGkXK12Kbh for ; Mon, 25 Sep 2017 03:12:30 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8303133210 for ; Mon, 25 Sep 2017 03:12:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PACRUL032840; Mon, 25 Sep 2017 12:12:27 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D7E1B209280; Mon, 25 Sep 2017 12:12:27 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C7E672091B9; Mon, 25 Sep 2017 12:12:27 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PACR5I009262; Mon, 25 Sep 2017 12:12:27 +0200 To: Mikael Abrahamsson Cc: Erik Kline , "v6ops@ietf.org" References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <9862ff34-8eea-c18a-88e5-d017630efefa@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 12:12:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:12:31 -0000 Le 25/09/2017 à 12:04, Mikael Abrahamsson a écrit : > On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > >> I agree with this definition of "IPv6-only network".  I would stress >> to also mean "no IPv4" - be it encapsulation, translation, or DNS-x-y. > > You're in extreme minority to have that definition. Excuse me, but that's used in many networks. > I don't care if my IP packet provider carries my packets over POS, > ethernet, if they run native IPv4, IPv6 or MPLS in their core, if they > use LDPv4 or LDPv6 for their control plane etc. What I care about is > what I need to configure my equipment with to talk to them. If they _can_ provide IPv4 too, then use it. Dont make funny translations. Translations break other matters in the Internet, like we saw with NAT. > So an IPv6 only access uses only IPv6 packets in the access line, that > the device can see. What happens in the ISP network once the packets > hits that part is out of scope for the definition of IPv6 only access. I agree, but dont make it look as if the network cant do IPv4. If it can, then use it. This very important. Alex > From nobody Mon Sep 25 03:12:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7F51332DA for ; Mon, 25 Sep 2017 03:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaTHj6PnDQJq for ; Mon, 25 Sep 2017 03:12:53 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FA741321A7 for ; Mon, 25 Sep 2017 03:12:52 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 502F9B2; Mon, 25 Sep 2017 12:12:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506334370; bh=QTNL44ChLYLNR7xC8pqLHIHQN63mpY/WSB4Ui/WLyVw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=yfIhP+wKt14D2ctgddRxRrIKftNkDE8GGnsH/lgD9TerppL6tbgIBpvfQIFTVaS0h xeIoWxJqWvyuvUoLkniRM26LKLH55T8eQTjJJcQ+VN5mEATKaIbANXR73WzuI1kiz8 VwMvDKwjn0q1db4asUbJByL4bhbzSyoywqlnWrts= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 376F4B1; Mon, 25 Sep 2017 12:12:50 +0200 (CEST) Date: Mon, 25 Sep 2017 12:12:50 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Lee Howard , v6ops@ietf.org In-Reply-To: Message-ID: References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:12:54 -0000 On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > Because I need to understand whether the APNs dedicated to CLAT run > IPv6-only. Do these networks do GTP-v4? And PDP type IPv4-IPv6? It doesn't matter if it's GTP over IPv4 or IPv6. The end device doesn't care. The important thing is what type of PDP context that is supported. If it's only IPv6 type PDP supoorted (or used), then this is "IPv6 only access". That's all the device sees. What the ISP uses to produce this service is irrelevant in this discussion. > The ideal is "double stack" - no encap, no translation, no IN A in UDPv6 > packets, no IN AAAA in UDPv4 packets, and PDP type v4v6. You're pretty much alone in that definition. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 25 03:19:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000521332D4 for ; Mon, 25 Sep 2017 03:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvLVNVaRDVT9 for ; Mon, 25 Sep 2017 03:19:20 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6611332CE for ; Mon, 25 Sep 2017 03:19:19 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BD22DB1; Mon, 25 Sep 2017 12:19:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506334757; bh=rZ0xFdnJV/v4YKusgdT39D3qJM4Z1fmnZitMgYdoCzk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=0w4w+86ZHB32j8uVQOQ+uqOwi979LEU0hrtzK1BLxEpbvHAy7Ws5qDdPNF4hgsnYy Ps1THBZNBo4hCtmDeWhJcsAaQURSzaOMK62jpoTkdrvyNQvpaE0/HWN2GbyT7kN4Zp /PKquuN09/fxp3rySmLXgE2eA/yFkT/w1EUUN7i0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A3AC084; Mon, 25 Sep 2017 12:19:17 +0200 (CEST) Date: Mon, 25 Sep 2017 12:19:17 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: "v6ops@ietf.org" In-Reply-To: Message-ID: References: <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <9862ff34-8eea-c18a-88e5-d017630efefa@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:19:21 -0000 On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > If it can, then use it. Some people want to migrate away from IPv4 in their networks. This has to be done incrementally, and since encap can be done over IPv4 and IPv6 without the customer seeing any difference, then this is a good way to do things incrementally. So over time we'll see people migrate from LDPv4 to LDPv6, from GTP over IPv4 to GTP over IPv6, from 6PE to 4PE etc. In the end, IPv4 will be a corner case service tunneled/translated over an IPv6 network for most people. We might be up to 20 years out from this being done universally, but that's the end goal for most people who have actually put serious thought into their long time future. I know people who are already trying to do this because they're growing quickly and they don't have IPv4 addresses to spare, to waste on infrastructure use, and using RFC1918 addresses has lots of operational downsides. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 25 03:20:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5288913239C for ; Mon, 25 Sep 2017 03:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuPlunWFPDlF for ; Mon, 25 Sep 2017 03:20:08 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C8B1320DC for ; Mon, 25 Sep 2017 03:20:07 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PAK2No036241; Mon, 25 Sep 2017 12:20:02 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8A9512092C6; Mon, 25 Sep 2017 12:20:02 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7B8A22090B3; Mon, 25 Sep 2017 12:20:02 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PAK2IK014622; Mon, 25 Sep 2017 12:20:02 +0200 To: Mikael Abrahamsson Cc: Lee Howard , v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> From: Alexandre Petrescu Message-ID: <048a5362-39ca-ff67-b897-72ec9d4ecf64@gmail.com> Date: Mon, 25 Sep 2017 12:20:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:20:14 -0000 Le 25/09/2017 à 12:12, Mikael Abrahamsson a écrit : [...] > It doesn't matter if it's GTP over IPv4 or IPv6. The end device > doesn't care. Well it should care. It should care about not breaking the apps that are IPv4, not breaking DHCPv6-PD. And dont try to be smart with funny translation methods; because others tried too. Dumb network. > The important thing is what type of PDP context that is supported. For IPv4 apps, the PDP context type should include IPv4 (in addition to IPv6). That's about it. > If it's only IPv6 type PDP supoorted (or used), then this is "IPv6 > only access". Well, that's "IPv6-only PDP type", it's not "IPv6-only access". The Access Network is a huge concept that I am afraid no-one has seen an IPv6-only version of. > That's all the device sees. What the ISP uses to produce this service > is irrelevant in this discussion. > >> The ideal is "double stack" - no encap, no translation, no IN A in >> UDPv6 packets, no IN AAAA in UDPv4 packets, and PDP type v4v6. > > You're pretty much alone in that definition. Hmm... and how about the many networks that provide simultaneous IPv4 and IPv6 access without any translation, encapsulation nor DNS-v4-v6? If you sum them up I think you end with more than a single mobile operator's subscribers. Look at those stats of IPv6 google http hits - how many come from a single mobile operator's subscribers? All the rest are from "double stack" networks. Alex > From nobody Mon Sep 25 03:20:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1729013331E for ; Mon, 25 Sep 2017 03:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzu-LDZ1yCNM for ; Mon, 25 Sep 2017 03:20:42 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55A11320DC for ; Mon, 25 Sep 2017 03:20:36 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 2E21040EC7 for ; Mon, 25 Sep 2017 12:20:35 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1EB6D40EC6; Mon, 25 Sep 2017 12:20:35 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 107DA8030; Mon, 25 Sep 2017 12:20:35 +0200 (CEST) Date: Mon, 25 Sep 2017 12:20:34 +0200 From: Gert Doering To: Alexandre Petrescu Cc: v6ops@ietf.org Message-ID: <20170925102034.GZ45648@Space.Net> References: <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> <20170922161337.GH45648@Space.Net> <20170924175047.GR45648@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:20:44 -0000 Hi, On Mon, Sep 25, 2017 at 11:24:19AM +0200, Alexandre Petrescu wrote: > I am not sure what do you mean? > > There is no 'radio station' in 3GPP. There are however FM radio > stations if you wish. Please read Lorenzo's mail in-thread, and it will be clear what sort of radio he's talking about. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Sep 25 03:22:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FA31332DA for ; Mon, 25 Sep 2017 03:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwmF21lmIoQy for ; Mon, 25 Sep 2017 03:22:52 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25221332D7 for ; Mon, 25 Sep 2017 03:22:51 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 9D2BB40EC6 for ; Mon, 25 Sep 2017 12:22:50 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 8E9BE40B9D; Mon, 25 Sep 2017 12:22:50 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 8064E8040; Mon, 25 Sep 2017 12:22:50 +0200 (CEST) Date: Mon, 25 Sep 2017 12:22:50 +0200 From: Gert Doering To: Alexandre Petrescu Cc: v6ops@ietf.org Message-ID: <20170925102250.GA45648@Space.Net> References: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:22:53 -0000 Hi, On Mon, Sep 25, 2017 at 11:51:29AM +0200, Alexandre Petrescu wrote: > I also heard the term "native IPv6". This means there is no IPv4. "native IPv6" usually means "IPv6 is not tunneled over IPv4" (where it counts, so don't get started with GTP tunnels again). "native IPv6" doesn't exclude native IPv4 from being on the same link, so this term is totally irrelevant in a 464xlat discussion. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Sep 25 03:25:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF551332D7 for ; Mon, 25 Sep 2017 03:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHnKMM81aTYD for ; Mon, 25 Sep 2017 03:25:51 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FE7132811 for ; Mon, 25 Sep 2017 03:25:50 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PAPmg4042486; Mon, 25 Sep 2017 12:25:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id ADD882092C6; Mon, 25 Sep 2017 12:25:48 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A0981209280; Mon, 25 Sep 2017 12:25:48 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PAPmp8018766; Mon, 25 Sep 2017 12:25:48 +0200 To: Mikael Abrahamsson Cc: "v6ops@ietf.org" References: <20170921223305.B72A8878E716@rock.dv.isc.org> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <9862ff34-8eea-c18a-88e5-d017630efefa@gmail.com> From: Alexandre Petrescu Message-ID: <9b6ac82e-2e82-20a3-40d1-3f955ec58d4f@gmail.com> Date: Mon, 25 Sep 2017 12:25:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:25:53 -0000 Le 25/09/2017 à 12:19, Mikael Abrahamsson a écrit : > On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > >> If it can, then use it. > > Some people want to migrate away from IPv4 in their networks. I aree, should be that direction. > This has to be done incrementally I agree - but start with the network, not with the Terminal. Make first an IPv6-only network. > and since encap can be done over IPv4 and IPv6 without the customer > seeing any difference, then this is a good way to do things > incrementally. It was tried numerous times before CLAT: 3ffe, sixxs, 6to4, DS-MIPv6, and others. > So over time we'll see people migrate from LDPv4 to LDPv6, from GTP > over IPv4 to GTP over IPv6, from 6PE to 4PE etc. During this time you prohibit a number of apps and protocols such as DHCPv6-PD. > In the end, IPv4 will be a corner case service tunneled/translated > over an IPv6 network for most people. We might be up to 20 years out > from this being done universally, but that's the end goal for most > people who have actually put serious thought into their long time > future. I know people who are already trying to do this because > they're growing quickly and they don't have IPv4 addresses to spare, Tell them to do IPv6-PDP-Type v4v6, and NAT for IPv4, and leave IPv6 alone. > to waste on infrastructure use, and using RFC1918 addresses has lots > of operational downsides. CLAT has many operational downsides as well, forget it. Fundamentally the IPv4 NAT issue is the fact that it translates. But CLAT also translates - they both have same issue. Alex > From nobody Mon Sep 25 03:27:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0713134218 for ; Mon, 25 Sep 2017 03:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gonsUBROBZYW for ; Mon, 25 Sep 2017 03:27:01 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54736134215 for ; Mon, 25 Sep 2017 03:27:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PAQxjx042893; Mon, 25 Sep 2017 12:26:59 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A2CDE2091B9; Mon, 25 Sep 2017 12:26:59 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8C44B20916E; Mon, 25 Sep 2017 12:26:59 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PAQx0C019552; Mon, 25 Sep 2017 12:26:59 +0200 To: Gert Doering Cc: v6ops@ietf.org References: <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> <20170922161337.GH45648@Space.Net> <20170924175047.GR45648@Space.Net> <20170925102034.GZ45648@Space.Net> From: Alexandre Petrescu Message-ID: <106a573c-2188-7629-e506-1f4baaf40b8a@gmail.com> Date: Mon, 25 Sep 2017 12:26:59 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170925102034.GZ45648@Space.Net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:27:03 -0000 Le 25/09/2017 à 12:20, Gert Doering a écrit : > Hi, > > On Mon, Sep 25, 2017 at 11:24:19AM +0200, Alexandre Petrescu wrote: >> I am not sure what do you mean? >> >> There is no 'radio station' in 3GPP. There are however FM radio >> stations if you wish. > > Please read Lorenzo's mail in-thread, and it will be clear what sort > of radio he's talking about. Sorry I dont have time. Simply reading that email shows there is no knowledge about handovers. So should not talk about matters where there is knowledge about. Alex > > Gert Doering > -- NetMaster > From nobody Mon Sep 25 03:27:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B833134224 for ; Mon, 25 Sep 2017 03:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xswqpHEjaxqV for ; Mon, 25 Sep 2017 03:27:44 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946461320DC for ; Mon, 25 Sep 2017 03:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506335260; x=1506940060; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=1OJQ7UNf3qEIScyBTnrkcSzw5 qYxD6QI/WnkNpBNTb4=; b=d4J5IY9acosXVEzCGQcMZMsQE5ZkrSuK2lkJFshEz 3GwSbNp7RdYfJ5Po0pkLv0CgkqZv6+Hum/st6nhLetNaGnWqKq9nSpyIie4Lo3ec pbGHLqNqX03PyRMZpHEDXXZh/TSBlVqR2LPRLqi9qyg9ukNB2wwpov2VWLhj5+CR t4= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=rzRZkRNLH5YvvMLl1u6926pqCxU5IbuzUZEhrBp/rwzl8yQtVqk8MSgyA4eF o5S+nqNSp1agic9IcF9jkYJ003pyrDLh5avtQF3ljvqgD8mErRU34E3P3 Bsdj+3MvGLzl7Hcek9bWzhuzYG4mmJcpjTvHjhJB6qY8csfjK5FgTo=; X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 12:27:40 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 12:27:40 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005566650.msg for ; Mon, 25 Sep 2017 12:27:39 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170925:md50005566650::lEE4s71KC9aXBBqB:00001x3d X-Return-Path: prvs=1441fc161e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Mon, 25 Sep 2017 12:27:36 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:27:45 -0000 Maybe you=E2=80=99re not there, but operators live in a world where they do= n=E2=80=99t have any more IPv4 addresses, so double-stack is over in the ac= cess networks. However, there are devices and apps (in both cellular/tether= ing and non-cellular), that are IPv4-only, so user networks/LANs, need some= transition support to make IPv4 transparently available end-to-end. Last week I did a presentation and I was making a joke: - I=E2=80=99ve been told that the only secure thing in this life is death = =E2=80=A6 well not anymore, some scientifics said they are close to find th= e way avoid death =E2=80=A6 So. the new =E2=80=9Cfor sure=E2=80=9D thing in= this life, is that we are going to an IPv6-only world (and I=E2=80=99m ref= erring here to access networks, maybe even some core/distribution networks)= . Saludos, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: lunes, 25 de septiembre de 2017, 12:07 Para: Mikael Abrahamsson CC: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double= stack coexistence Le 25/09/2017 =C3=A0 11:53, Mikael Abrahamsson a =C3=A9crit : > On Mon, 25 Sep 2017, Alexandre Petrescu wrote: >=20 >> I mean GTPU protocol that uses IPv4 addresses, and carries IPv6 pack= ets >=20 > This is not something the end user device sees or cares about. =20 But the end-user device connects to a network, and you claim that=20 network is IPv6-only. =20 You claim that because there are networks that are IPv6-only then=20 devices must run CLAT. =20 But what is "IPv6-only networks"? Do they use IPv4 though? =20 > Why are=20 > you bringing this up? =20 Because I need to understand whether the APNs dedicated to CLAT run=20 IPv6-only. Do these networks do GTP-v4? And PDP type IPv4-IPv6? =20 One would like to have coherence between IPv4, IPv6, APN type, PDP type= ,=20 encapsulations, translations. =20 The ideal is "double stack" - no encap, no translation, no IN A in UDPv= 6=20 packets, no IN AAAA in UDPv4 packets, and PDP type v4v6. =20 Alex =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Sep 25 03:30:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1EA13422B for ; Mon, 25 Sep 2017 03:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlJWzukDHgnz for ; Mon, 25 Sep 2017 03:29:52 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3211320DC for ; Mon, 25 Sep 2017 03:29:51 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PAToHs038884; Mon, 25 Sep 2017 12:29:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 37E77209280; Mon, 25 Sep 2017 12:29:50 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 20C1C209202; Mon, 25 Sep 2017 12:29:50 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PATnwo022019; Mon, 25 Sep 2017 12:29:50 +0200 To: Gert Doering Cc: v6ops@ietf.org References: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> <20170925102250.GA45648@Space.Net> From: Alexandre Petrescu Message-ID: <81661be5-4a1a-1f8a-10d0-829e775546d9@gmail.com> Date: Mon, 25 Sep 2017 12:29:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170925102250.GA45648@Space.Net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:29:53 -0000 Le 25/09/2017 à 12:22, Gert Doering a écrit : > Hi, > > On Mon, Sep 25, 2017 at 11:51:29AM +0200, Alexandre Petrescu wrote: >> I also heard the term "native IPv6". This means there is no IPv4. > > "native IPv6" usually means "IPv6 is not tunneled over IPv4" That's for you. For me "native IPv6" means there is no IPv4. And there are many such networks. > (where it > counts, so don't get started with GTP tunnels again). No, you dont claim anymore these networks are "IPv6-only". They are not. > "native IPv6" doesn't exclude native IPv4 from being on the same link, > so this term is totally irrelevant in a 464xlat discussion. If yous want to sit on an upper layer, looking from there, ignoring there is IPv4 below, then that is your problem. The consequence of that is that your ignorance of IPv4 below you makes you forbid some IPv6 apps. Some of them are, but not limited to, DHCPv6-PD. Alex > > Gert Doering > -- NetMaster > From nobody Mon Sep 25 03:33:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5E713422B for ; Mon, 25 Sep 2017 03:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njNaks4mYj6f for ; Mon, 25 Sep 2017 03:32:59 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148561332D7 for ; Mon, 25 Sep 2017 03:32:59 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3BF8BB1; Mon, 25 Sep 2017 12:32:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506335577; bh=IiCUkp3Kr25Juagl2Wot/1R++r7YMyCiWiOCKkWeCGY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lCu0+gLWTgwoTtZvtq7Zbp41Bs+0XHj+NroXSa9HHY1mCyqOnScwEDnb4IemJbDai 3noRlGUmQAVQkRGUlgGRy8/wHcWFfkMaO5TDUJ3czSRxKEjGJDGgo6+nkWpV4lWt2A x0CzGFN7exlyj7zTt4t4HkqdhNQ1+zdg8O9yY7Ys= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0B0B284; Mon, 25 Sep 2017 12:32:57 +0200 (CEST) Date: Mon, 25 Sep 2017 12:32:57 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Gert Doering , v6ops@ietf.org In-Reply-To: <81661be5-4a1a-1f8a-10d0-829e775546d9@gmail.com> Message-ID: References: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> <20170925102250.GA45648@Space.Net> <81661be5-4a1a-1f8a-10d0-829e775546d9@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:33:00 -0000 On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > The consequence of that is that your ignorance of IPv4 below you makes > you forbid some IPv6 apps. Some of them are, but not limited to, > DHCPv6-PD. This has nothing to do with DHCPv6-PD. DHCPv6-PD works just fine over both GTP-over-IPv4 and GTP-over-IPv6. There is no difference in this application. GTP tunnel is a point-to-point tunnel and it doesn't matter what the infrastructure underneath is. If the UE modem decides to drop IPv6 multicast packets it has received over the RLC layer (which doesn't have IPv4 or IPv6 encap underneath) then that's a bad modem. It has nothing to do with the rest of the discussion. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 25 03:34:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1603A134285 for ; Mon, 25 Sep 2017 03:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuKJLB7CIgDz for ; Mon, 25 Sep 2017 03:34:14 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B043134292 for ; Mon, 25 Sep 2017 03:34:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PAYAKW041751 for ; Mon, 25 Sep 2017 12:34:10 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3C19E209273 for ; Mon, 25 Sep 2017 12:34:10 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 32AE6209353 for ; Mon, 25 Sep 2017 12:34:10 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PAY9q1025358 for ; Mon, 25 Sep 2017 12:34:10 +0200 To: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> From: Alexandre Petrescu Message-ID: <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> Date: Mon, 25 Sep 2017 12:34:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:34:17 -0000 Le 25/09/2017 à 12:27, JORDI PALET MARTINEZ a écrit : > [...] but operators live in a world where they don’t have any more > IPv4 addresses, False, they always have access to NAT space. Keep NAT for IPv4, leave IPv6 alone. > so double-stack is over in the access networks. However, there are > devices and apps (in both cellular/tethering and non-cellular), that > are IPv4-only, so user networks/LANs, need some transition support to > make IPv4 transparently available end-to-end. That need can not be satisfied to a large scale. Make it work inside some domain, with some translation, but cant work for all. It's plain NAT. > Last week I did a presentation and I was making a joke: > > - I’ve been told that the only secure thing in this life is death … > well not anymore, some scientifics said they are close to find the > way avoid death … So. the new “for sure” thing in this life, is that > we are going to an IPv6-only world (and I’m referring here to access > networks, maybe even some core/distribution networks). I agree. Saludos, Alex > > Saludos, Jordi > > > -----Mensaje original----- De: v6ops en > nombre de Alexandre Petrescu Responder > a: Fecha: lunes, 25 de septiembre de > 2017, 12:07 Para: Mikael Abrahamsson CC: > Asunto: Re: [v6ops] reclassify 464XLAT as standard > instead of info - double stack coexistence > > Le 25/09/2017 à 11:53, Mikael Abrahamsson a écrit : >> On Mon, 25 Sep 2017, Alexandre Petrescu wrote: >> >>> I mean GTPU protocol that uses IPv4 addresses, and carries IPv6 >>> packets >> >> This is not something the end user device sees or cares about. > > But the end-user device connects to a network, and you claim that > network is IPv6-only. > > You claim that because there are networks that are IPv6-only then > devices must run CLAT. > > But what is "IPv6-only networks"? Do they use IPv4 though? > >> Why are you bringing this up? > > Because I need to understand whether the APNs dedicated to CLAT run > IPv6-only. Do these networks do GTP-v4? And PDP type IPv4-IPv6? > > One would like to have coherence between IPv4, IPv6, APN type, PDP > type, encapsulations, translations. > > The ideal is "double stack" - no encap, no translation, no IN A in > UDPv6 packets, no IN AAAA in UDPv4 packets, and PDP type v4v6. > > Alex > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If > you are not the intended recipient be aware that any disclosure, > copying, distribution or use of the contents of this information, > even if partially, including attached files, is strictly prohibited, > will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Sep 25 03:37:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3421332D7 for ; Mon, 25 Sep 2017 03:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKvs7EU0X4tc for ; Mon, 25 Sep 2017 03:37:30 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608341321C7 for ; Mon, 25 Sep 2017 03:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506335848; x=1506940648; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=MwZxm8TPRDo0+xA8Rc0tFVXBi JWu2po/m0IiXKrcCjE=; b=aOXfpT8Nd+cTzNIFg/m9I01Tfk2pfSuYh0nPqwsgZ j4MhPePWaC6+7yA9dnx1A3N6kaht6Rs0EWcy31Z8S+MnIZAggDfOhkv2C+sK2fw3 bbacWvETzEaNb6DeNxc9RgeFaIrQvEGXQ0zSpbNP8CwDpgN3f5DHkO41CyBD3FcB AU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=XeuI87hw9oRRPyN8mxwVe+K6VbgND+2Dvkw9yDXyiCEEBmPucRRQeydXMOSb 4EZdJmnzRpETIulp34iJK+qUAtjYK1aJJZetnlSjFqhuKJo7TW475ad8j nYcfBiQa1Aa+EQ/q2Sxj357ACHsXwh08N1+ZqdggXG58qgUaYyYVY8=; X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 12:37:28 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 12:37:28 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005566664.msg for ; Mon, 25 Sep 2017 12:37:27 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170925:md50005566664::XoUQqI3Oq4xecmSJ:0000AYF4 X-Return-Path: prvs=1441fc161e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Mon, 25 Sep 2017 12:37:23 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> In-Reply-To: <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:37:32 -0000 Are you going to pay from your pocket the operators for the extra CGN cost?= They may agree in that case! Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: lunes, 25 de septiembre de 2017, 12:34 Para: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double= stack coexistence =20 =20 Le 25/09/2017 =C3=A0 12:27, JORDI PALET MARTINEZ a =C3=A9crit : > [...] but operators live in a world where they don=E2=80=99t have any= more=20 > IPv4 addresses, =20 False, they always have access to NAT space. =20 Keep NAT for IPv4, leave IPv6 alone. =20 > so double-stack is over in the access networks. However, there are > devices and apps (in both cellular/tethering and non-cellular), that > are IPv4-only, so user networks/LANs, need some transition support to > make IPv4 transparently available end-to-end. =20 That need can not be satisfied to a large scale. Make it work inside= =20 some domain, with some translation, but cant work for all. =20 It's plain NAT. =20 > Last week I did a presentation and I was making a joke: >=20 > - I=E2=80=99ve been told that the only secure thing in this life is d= eath =E2=80=A6=20 > well not anymore, some scientifics said they are close to find the=20 > way avoid death =E2=80=A6 So. the new =E2=80=9Cfor sure=E2=80=9D thin= g in this life, is that > we are going to an IPv6-only world (and I=E2=80=99m referring here t= o access > networks, maybe even some core/distribution networks). =20 I agree. =20 Saludos, =20 Alex =20 >=20 > Saludos, Jordi >=20 >=20 > -----Mensaje original----- De: v6ops en=20 > nombre de Alexandre Petrescu Responder > a: Fecha: lunes, 25 de septiembre de > 2017, 12:07 Para: Mikael Abrahamsson CC: > Asunto: Re: [v6ops] reclassify 464XLAT as standard > instead of info - double stack coexistence >=20 > Le 25/09/2017 =C3=A0 11:53, Mikael Abrahamsson a =C3=A9crit : >> On Mon, 25 Sep 2017, Alexandre Petrescu wrote: >>=20 >>> I mean GTPU protocol that uses IPv4 addresses, and carries IPv6=20 >>> packets >>=20 >> This is not something the end user device sees or cares about. >=20 > But the end-user device connects to a network, and you claim that=20 > network is IPv6-only. >=20 > You claim that because there are networks that are IPv6-only then=20 > devices must run CLAT. >=20 > But what is "IPv6-only networks"? Do they use IPv4 though? >=20 >> Why are you bringing this up? >=20 > Because I need to understand whether the APNs dedicated to CLAT run= =20 > IPv6-only. Do these networks do GTP-v4? And PDP type IPv4-IPv6? >=20 > One would like to have coherence between IPv4, IPv6, APN type, PDP=20 > type, encapsulations, translations. >=20 > The ideal is "double stack" - no encap, no translation, no IN A in=20 > UDPv6 packets, no IN AAAA in UDPv4 packets, and PDP type v4v6. >=20 > Alex >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** IPv4 is over Are you= =20 > ready for the new Internet ? http://www.consulintel.es The IPv6=20 > Company >=20 > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty=20 > authorized disclosure, copying, distribution or use of the contents= =20 > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If=20 > you are not the intended recipient be aware that any disclosure,=20 > copying, distribution or use of the contents of this information,=20 > even if partially, including attached files, is strictly prohibited,= =20 > will be considered a criminal offense, so you must reply to the=20 > original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Sep 25 03:38:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCE91332DA for ; Mon, 25 Sep 2017 03:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQsPrI3tQf1X for ; Mon, 25 Sep 2017 03:38:14 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3DA1321C7 for ; Mon, 25 Sep 2017 03:38:14 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PAcCDT047084; Mon, 25 Sep 2017 12:38:12 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B4D1E20916E; Mon, 25 Sep 2017 12:38:12 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A5B3E20226F; Mon, 25 Sep 2017 12:38:12 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PAcClT027840; Mon, 25 Sep 2017 12:38:12 +0200 To: Mikael Abrahamsson Cc: Gert Doering , v6ops@ietf.org References: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> <20170925102250.GA45648@Space.Net> <81661be5-4a1a-1f8a-10d0-829e775546d9@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 12:38:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:38:16 -0000 Le 25/09/2017 à 12:32, Mikael Abrahamsson a écrit : > On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > >> The consequence of that is that your ignorance of IPv4 below you makes >> you forbid some IPv6 apps.  Some of them are, but not limited to, >> DHCPv6-PD. > > This has nothing to do with DHCPv6-PD. DHCPv6-PD works just fine over > both GTP-over-IPv4 and GTP-over-IPv6. Have you tried? I am afraid it will not work, I explained earlier why, I can explain again if necessary. [...] > If the UE modem decides to drop IPv6 multicast packets it has received > over the RLC layer (which doesn't have IPv4 or IPv6 encap underneath) > then that's a bad modem. It has nothing to do with the rest of the > discussion. It's not only that modem problem I talked about. The fact that DHCPv6-PD does not work on Android has multiple causes. One is the modem. The other is pure human reluctance to allow it to work. The reason invoked for that is that "it is not needed, because CLAT does it". So basically one forbids a pure-IPv6 method (DHCPv6-PD) and recommends a weak IPv4-IPv6 translation method instead. Forget the IPv4-IPv6 translation methods. Alex > From nobody Mon Sep 25 03:41:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84352132F7C for ; Mon, 25 Sep 2017 03:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOZY90j273ml for ; Mon, 25 Sep 2017 03:41:47 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0556F1321C7 for ; Mon, 25 Sep 2017 03:41:46 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PAfjtI048205 for ; Mon, 25 Sep 2017 12:41:45 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 63922209361 for ; Mon, 25 Sep 2017 12:41:45 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 58AB720930C for ; Mon, 25 Sep 2017 12:41:45 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PAfitq032665 for ; Mon, 25 Sep 2017 12:41:45 +0200 To: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 12:41:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:41:49 -0000 Le 25/09/2017 à 12:37, JORDI PALET MARTINEZ a écrit : > Are you going to pay from your pocket the operators for the extra CGN > cost? They may agree in that case! Look to be clear, I am not paying anything from my pocket. Moreover, what I am saying is less cost. CGNs and all computers in the world already run IPv4. Continue do that for IPv4. If you need new IPv4 address space, use NAT. And if you want IPv6, then use all the available IPv6 software for it. It's called "double stack". Dont do v4-v6 translations, because they prohibit you from running some native IPv6 apps. And they are expensive. Alex > > Regards, Jordi > > > -----Mensaje original----- De: v6ops en > nombre de Alexandre Petrescu Responder > a: Fecha: lunes, 25 de septiembre de > 2017, 12:34 Para: Asunto: Re: [v6ops] reclassify > 464XLAT as standard instead of info - double stack coexistence > > > > Le 25/09/2017 à 12:27, JORDI PALET MARTINEZ a écrit : >> [...] but operators live in a world where they don’t have any more >> IPv4 addresses, > > False, they always have access to NAT space. > > Keep NAT for IPv4, leave IPv6 alone. > >> so double-stack is over in the access networks. However, there are >> devices and apps (in both cellular/tethering and non-cellular), >> that are IPv4-only, so user networks/LANs, need some transition >> support to make IPv4 transparently available end-to-end. > > That need can not be satisfied to a large scale. Make it work > inside some domain, with some translation, but cant work for all. > > It's plain NAT. > >> Last week I did a presentation and I was making a joke: >> >> - I’ve been told that the only secure thing in this life is death >> … well not anymore, some scientifics said they are close to find >> the way avoid death … So. the new “for sure” thing in this life, is >> that we are going to an IPv6-only world (and I’m referring here to >> access networks, maybe even some core/distribution networks). > > I agree. > > Saludos, > > Alex > >> >> Saludos, Jordi >> >> >> -----Mensaje original----- De: v6ops en >> nombre de Alexandre Petrescu >> Responder a: Fecha: lunes, 25 de >> septiembre de 2017, 12:07 Para: Mikael Abrahamsson >> CC: Asunto: Re: [v6ops] >> reclassify 464XLAT as standard instead of info - double stack >> coexistence >> >> Le 25/09/2017 à 11:53, Mikael Abrahamsson a écrit : >>> On Mon, 25 Sep 2017, Alexandre Petrescu wrote: >>> >>>> I mean GTPU protocol that uses IPv4 addresses, and carries >>>> IPv6 packets >>> >>> This is not something the end user device sees or cares about. >> >> But the end-user device connects to a network, and you claim that >> network is IPv6-only. >> >> You claim that because there are networks that are IPv6-only then >> devices must run CLAT. >> >> But what is "IPv6-only networks"? Do they use IPv4 though? >> >>> Why are you bringing this up? >> >> Because I need to understand whether the APNs dedicated to CLAT >> run IPv6-only. Do these networks do GTP-v4? And PDP type >> IPv4-IPv6? >> >> One would like to have coherence between IPv4, IPv6, APN type, PDP >> type, encapsulations, translations. >> >> The ideal is "double stack" - no encap, no translation, no IN A in >> UDPv6 packets, no IN AAAA in UDPv4 packets, and PDP type v4v6. >> >> Alex >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> ********************************************** IPv4 is over Are >> you ready for the new Internet ? http://www.consulintel.es The >> IPv6 Company >> >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be for >> the exclusive use of the individual(s) named above and further >> non-explicilty authorized disclosure, copying, distribution or use >> of the contents of this information, even if partially, including >> attached files, is strictly prohibited and will be considered a >> criminal offense. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents >> of this information, even if partially, including attached files, >> is strictly prohibited, will be considered a criminal offense, so >> you must reply to the original sender to inform about this >> communication and delete it. >> >> >> >> _______________________________________________ v6ops mailing list >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Sep 25 03:44:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FBC1331F6 for ; Mon, 25 Sep 2017 03:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ6MXghy_CEE for ; Mon, 25 Sep 2017 03:44:33 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423581321C7 for ; Mon, 25 Sep 2017 03:44:33 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 63D14B1; Mon, 25 Sep 2017 12:44:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506336270; bh=hH2JVaBihuCCg4+zzSIVhRNuoCH4YiM3JRqrFM5M5AE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=IxCMU/+CnpCoFB7fn3eb20KCK1zrZizh4C5feU9M7f93rUuT5iXq4eLFYpMeATZqB bJAur7GsR7gu20dhzr05hvxmer9W78FfaFQdmlJztmeno5ga4hIunWgG/e0oTusXUh 9tLd369Or+jisx0v7QpiXxt8faDSWRpsXUugM+nE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4C59E84; Mon, 25 Sep 2017 12:44:30 +0200 (CEST) Date: Mon, 25 Sep 2017 12:44:30 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: Gert Doering , v6ops@ietf.org In-Reply-To: Message-ID: References: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> <20170925102250.GA45648@Space.Net> <81661be5-4a1a-1f8a-10d0-829e775546d9@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:44:39 -0000 On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > The other is pure human reluctance to allow it to work. The reason invoked > for that is that "it is not needed, because CLAT does it". My guess would be that we do not have DHCPv6-PD in mobile networks because RFC7278 works well enough for most deployment scenarios, and it's a pain to get DHCPv6-PD into both mobile core and UEs (chicken and egg problem, plus "what we have seems to work for most" (ie 64SHARE)). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 25 03:45:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF711342C2 for ; Mon, 25 Sep 2017 03:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFgXIlTnUTaF for ; Mon, 25 Sep 2017 03:45:18 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F5A134293 for ; Mon, 25 Sep 2017 03:45:17 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 93968B1; Mon, 25 Sep 2017 12:45:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506336316; bh=sqJkXk7cCjEjWZzgtAbIgvAYa6KaGWGTjLg8c3XZzls=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=KAVfoPfgz9IIVwiEn3vy7PsV1fgbSH+nSfQ9pKMBmZgGSQP4H9fnYZJ1YKaOx+CqP inEoDizuHReCcnC4l/CCQAK4xBJRSmHzf2hW5oAFy6XQvCLqEx8d8Zq4lHYayQlJSG PDMq+4j07i0oXPTC5fgwQqD8e2Ojjw/hkN0f6Lh0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9094F84; Mon, 25 Sep 2017 12:45:16 +0200 (CEST) Date: Mon, 25 Sep 2017 12:45:16 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:45:19 -0000 On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > It's called "double stack". Actually, it's called "dual stack". -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 25 03:55:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4F9132193 for ; Mon, 25 Sep 2017 03:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJhaOw1zUq-q for ; Mon, 25 Sep 2017 03:55:55 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BAAE1320DC for ; Mon, 25 Sep 2017 03:55:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PAtr6x048473; Mon, 25 Sep 2017 12:55:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 90E1A209353; Mon, 25 Sep 2017 12:55:53 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 814CE209345; Mon, 25 Sep 2017 12:55:53 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PAtrHV011499; Mon, 25 Sep 2017 12:55:53 +0200 To: Mikael Abrahamsson Cc: Gert Doering , v6ops@ietf.org References: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> <20170925102250.GA45648@Space.Net> <81661be5-4a1a-1f8a-10d0-829e775546d9@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 12:55:53 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:55:57 -0000 Le 25/09/2017 à 12:44, Mikael Abrahamsson a écrit : > On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > >> The other is pure human reluctance to allow it to work. The reason >> invoked for that is that "it is not needed, because CLAT does >> it". > > My guess would be that we do not have DHCPv6-PD in mobile networks > because RFC7278 works well enough for most deployment scenarios, If it worked that well it were not INFORMATIONAL. > and it's a pain to get DHCPv6-PD into both mobile core and UEs For UE it is not a pain. Again: for UE it is not a pain. Stop claiming it is a pain. There are DHCPv6 Android apps in the Store doing that. There are numerous software packages running on Androind doing DHCPv6 PD. What _is_ a pain is explicit blocking by Android OS of DHCPv6 software. (the modem pain is nothing compared to the above). > (chicken and egg problem, plus "what we have seems to work for most" > (ie 64SHARE)). I disagree. I dont know what you call "most". 64share is a non-scalable technology, should be get rid of. This 64share, together with the 64bit limit in Address Architecture, stops growth at the edges. Alex > From nobody Mon Sep 25 03:58:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A93132F8F for ; Mon, 25 Sep 2017 03:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soPllMWJnMYN for ; Mon, 25 Sep 2017 03:58:23 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB5F132F7C for ; Mon, 25 Sep 2017 03:58:23 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PAwLxt000480; Mon, 25 Sep 2017 12:58:21 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6E4BD209375; Mon, 25 Sep 2017 12:58:21 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 611D8209345; Mon, 25 Sep 2017 12:58:21 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PAwLDV013042; Mon, 25 Sep 2017 12:58:21 +0200 To: Mikael Abrahamsson Cc: v6ops@ietf.org References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 12:58:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 10:58:24 -0000 Le 25/09/2017 à 12:45, Mikael Abrahamsson a écrit : > On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > >> It's called "double stack". > > Actually, it's called "dual stack". "dual stack" is what involves some encapsulation and some translation. E.g. RFC4213, note the "and": > Dual stack implies providing > complete implementations of both versions of the Internet Protocol > (IPv4 and IPv6), and configured tunneling provides a means to carry > IPv6 packets over unmodified IPv4 routing infrastructures. On another hand, "double stack" is IPv4 and IPv6 at the same time, without any encapsulation nor translation, nor DNS-v4-v6. Just IPv4, IPv6 and DNS. Alex From nobody Mon Sep 25 04:07:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C602E1320DC for ; Mon, 25 Sep 2017 04:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK_tU_XwUdFj for ; Mon, 25 Sep 2017 04:07:17 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B44134218 for ; Mon, 25 Sep 2017 04:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506337634; x=1506942434; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=G56+8Yjp/u/QwvKklYJhyRLZA e5dqFaT11z6cNXDMIk=; b=tsYXVrBP41h8On8HSEQnVFPXKBYq84LrbJhvRdC4n uUfHfbVd1pYqz1bkmb+9RJnVJ/FYZhevMZXLe55NR+357Hxzq2G9jZJqnq4UGi0O RF5/MiF/H77HALl1oUJIkWW+OaBLJUjLU5lxX7z7cq8YBrXKPRykhvA59anLIMev LM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=SUjQbB5pp+OvzwE13qmGZnBcC2Jrl/ga6THTsz2JVY+vJhzXq6UfMZlKr748 PUGmmeL6c89I0XRzaG1HhBkJqBwsJW7jXsD5NoycONoRkM8tq6u3wFDVf PShLnRKlst3d2E0Z6G73TMGEYxLyHBjfOPHDdTGdDWmNgleORUKOCg=; X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 13:07:14 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 13:07:13 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005566725.msg for ; Mon, 25 Sep 2017 13:07:12 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170925:md50005566725::jm7NB5mrkl3q6SWC:00001OED X-Return-Path: prvs=1441fc161e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Mon, 25 Sep 2017 13:07:05 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <31CF5D7F-6A46-463E-883E-16F4DA4CBEE8@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 11:07:19 -0000 Many operators have not CGN yet, so IPv6-only solutions even if they requir= e NAT64 are more efficient (you have even open source for NAT64) and IPv4 u= sage of a few IPv4 public addresses scale much better with NAT64 than in CG= N. And of course, if you have IPv6-only-access it means more and more of yo= ur traffic is going thru to IPv6 destinations, so you have less and less us= age of any transition stuff. In addition to that there are implications in terms of battery and radio ba= ndwidth (keep-alives for CGN), which have much less impact if the access ne= twork is IPv6-only. I=E2=80=99ve not seen any native IPv6 app that gets impacted by transition.= I agree that transition is always imperfect, one way or another for IPv4, = but we need to balance between long-term strategy or staying forever with I= Pv4. Actually 464XLAT is really inexpensive, much less CapEx and OpEx than any o= ther transition and even than dual-stack-access. Saludos, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Alexandre Petrescu Responder a: Fecha: lunes, 25 de septiembre de 2017, 12:42 Para: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double= stack coexistence =20 =20 Le 25/09/2017 =C3=A0 12:37, JORDI PALET MARTINEZ a =C3=A9crit : > Are you going to pay from your pocket the operators for the extra CGN > cost? They may agree in that case! =20 Look to be clear, I am not paying anything from my pocket. =20 Moreover, what I am saying is less cost. =20 CGNs and all computers in the world already run IPv4. Continue do that= =20 for IPv4. =20 If you need new IPv4 address space, use NAT. =20 And if you want IPv6, then use all the available IPv6 software for it. =20 It's called "double stack". =20 Dont do v4-v6 translations, because they prohibit you from running some= =20 native IPv6 apps. And they are expensive. =20 Alex =20 >=20 > Regards, Jordi >=20 >=20 > -----Mensaje original----- De: v6ops en > nombre de Alexandre Petrescu Responder > a: Fecha: lunes, 25 de septiembre de > 2017, 12:34 Para: Asunto: Re: [v6ops] reclassify > 464XLAT as standard instead of info - double stack coexistence >=20 >=20 >=20 > Le 25/09/2017 =C3=A0 12:27, JORDI PALET MARTINEZ a =C3=A9crit : >> [...] but operators live in a world where they don=E2=80=99t have an= y more=20 >> IPv4 addresses, >=20 > False, they always have access to NAT space. >=20 > Keep NAT for IPv4, leave IPv6 alone. >=20 >> so double-stack is over in the access networks. However, there are= =20 >> devices and apps (in both cellular/tethering and non-cellular), >> that are IPv4-only, so user networks/LANs, need some transition >> support to make IPv4 transparently available end-to-end. >=20 > That need can not be satisfied to a large scale. Make it work > inside some domain, with some translation, but cant work for all. >=20 > It's plain NAT. >=20 >> Last week I did a presentation and I was making a joke: >>=20 >> - I=E2=80=99ve been told that the only secure thing in this life is = death >> =E2=80=A6 well not anymore, some scientifics said they are close to = find >> the way avoid death =E2=80=A6 So. the new =E2=80=9Cfor sure=E2=80=9D= thing in this life, is >> that we are going to an IPv6-only world (and I=E2=80=99m referring h= ere to >> access networks, maybe even some core/distribution networks). >=20 > I agree. >=20 > Saludos, >=20 > Alex >=20 >>=20 >> Saludos, Jordi >>=20 >>=20 >> -----Mensaje original----- De: v6ops en=20 >> nombre de Alexandre Petrescu >> Responder a: Fecha: lunes, 25 de >> septiembre de 2017, 12:07 Para: Mikael Abrahamsson >> CC: Asunto: Re: [v6ops] >> reclassify 464XLAT as standard instead of info - double stack >> coexistence >>=20 >> Le 25/09/2017 =C3=A0 11:53, Mikael Abrahamsson a =C3=A9crit : >>> On Mon, 25 Sep 2017, Alexandre Petrescu wrote: >>>=20 >>>> I mean GTPU protocol that uses IPv4 addresses, and carries >>>> IPv6 packets >>>=20 >>> This is not something the end user device sees or cares about. >>=20 >> But the end-user device connects to a network, and you claim that=20 >> network is IPv6-only. >>=20 >> You claim that because there are networks that are IPv6-only then=20 >> devices must run CLAT. >>=20 >> But what is "IPv6-only networks"? Do they use IPv4 though? >>=20 >>> Why are you bringing this up? >>=20 >> Because I need to understand whether the APNs dedicated to CLAT >> run IPv6-only. Do these networks do GTP-v4? And PDP type >> IPv4-IPv6? >>=20 >> One would like to have coherence between IPv4, IPv6, APN type, PDP= =20 >> type, encapsulations, translations. >>=20 >> The ideal is "double stack" - no encap, no translation, no IN A in= =20 >> UDPv6 packets, no IN AAAA in UDPv4 packets, and PDP type v4v6. >>=20 >> Alex >>=20 >> _______________________________________________ v6ops mailing list= =20 >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >>=20 >> ********************************************** IPv4 is over Are >> you ready for the new Internet ? http://www.consulintel.es The >> IPv6 Company >>=20 >> This electronic message contains information which may be >> privileged or confidential. The information is intended to be for >> the exclusive use of the individual(s) named above and further >> non-explicilty authorized disclosure, copying, distribution or use >> of the contents of this information, even if partially, including >> attached files, is strictly prohibited and will be considered a >> criminal offense. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents >> of this information, even if partially, including attached files, >> is strictly prohibited, will be considered a criminal offense, so >> you must reply to the original sender to inform about this >> communication and delete it. >>=20 >>=20 >>=20 >> _______________________________________________ v6ops mailing list= =20 >> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** IPv4 is over Are you > ready for the new Internet ? http://www.consulintel.es The IPv6 > Company >=20 > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ v6ops mailing list=20 > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops >=20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Sep 25 04:09:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315051320DC for ; Mon, 25 Sep 2017 04:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bstDx-D8TnIO for ; Mon, 25 Sep 2017 04:09:12 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A2F134234 for ; Mon, 25 Sep 2017 04:09:12 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4C37DB2; Mon, 25 Sep 2017 13:09:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506337750; bh=mntfzgHjaifRLE4Rmaks/ZCN/aB+tWsAwHKNFSZBH0Y=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ZkfnQTKx+HZhDEIfmIFO1tZy/SylrZAf0IlEsDURs2EKphozeaphXR0ZsjZEV0Zui H2g0bQusI6mDLRDMOvR5dEU02FnK8F4esRzBiSD7MZ2pjjpvQdLpFfazPcCygv/vHI vTqz8jmJTUmQ5wkyq1u3rrfohaoGCCBBJ3d+Ga68= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 49A42B1; Mon, 25 Sep 2017 13:09:10 +0200 (CEST) Date: Mon, 25 Sep 2017 13:09:10 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 11:09:14 -0000 On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > On another hand, "double stack" is IPv4 and IPv6 at the same time, > without any encapsulation nor translation, nor DNS-v4-v6. Just IPv4, > IPv6 and DNS. Where is this defined? I googled for "double stack" and IETF and I got ~900 hits. A lot of them seems to be from native french speakers, so I'd imagine there is some kind of translation from french that means some tend to use "double stack" instead of "dual stack"? "double stack" and IPv6 yields 4k hits. "Dual stack" and ietf yields 75k hits and replacing ietf with ipv6 yields 364k hits. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Sep 25 05:01:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031591332E3 for ; Mon, 25 Sep 2017 05:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qK5WUj_kxTe for ; Mon, 25 Sep 2017 05:00:56 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D361321A1 for ; Mon, 25 Sep 2017 05:00:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PC0rBB073907; Mon, 25 Sep 2017 14:00:53 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 724CA201902; Mon, 25 Sep 2017 14:00:53 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 61D3F20943F; Mon, 25 Sep 2017 14:00:53 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PC0rW4029476; Mon, 25 Sep 2017 14:00:53 +0200 To: Mikael Abrahamsson Cc: v6ops@ietf.org References: <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> From: Alexandre Petrescu Message-ID: <5355a79c-27ae-942c-a970-6f847a181eea@gmail.com> Date: Mon, 25 Sep 2017 14:00:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:00:59 -0000 Le 25/09/2017 à 13:09, Mikael Abrahamsson a écrit : > On Mon, 25 Sep 2017, Alexandre Petrescu wrote: > >> On another hand, "double stack" is IPv4 and IPv6 at the same time, >> without any encapsulation nor translation, nor DNS-v4-v6. Just >> IPv4, IPv6 and DNS. > > Where is this defined? In my emails. > I googled for "double stack" and IETF and I got ~900 hits. So it's a place to grab. I relate "double stack" to a "coexistence" item C) in an earlier RFC INFORMATIONAL by B. Carpenter. With that, I can put up a draft, if you are interested to participate. This kind of "double stack" is what many deployments do, and easier to tell than twisting one's tongue around v6v4v6v4. > A lot of them seems to be from native french speakers, so I'd imagine > there is some kind of translation from french that means some tend to > use "double stack" instead of "dual stack"? "double stack" and IPv6 > yields 4k hits. Well, I am not a native french speaker, but because you make a speculation on how it came up here is an explanation: I wanted to say "dual stack" in our email exchanges, but then I realized some people say "dual stack" to mean simultaneous IPv4 and IPv6 involving some translation/encap/DNSv4v6/sharing (RFCs like RFC6333, RFC5555, RFC4213, RFC4241). On another hand, no RFC talks about "dual stack" as simultaneous use of IPv4 and IPv6 without any form of translation, encap, RH, DNSv4v6, address sharing, etc. So I propose "double stack" for that. At least it's clear what I talk about. Also, if you have some other more English term to denote that, (more English than "double stack"), then I am willing to use it. Alex > > "Dual stack" and ietf yields 75k hits and replacing ietf with ipv6 > yields 364k hits. > From nobody Mon Sep 25 05:04:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A6D1342D6 for ; Mon, 25 Sep 2017 05:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnKCHr7vrmow for ; Mon, 25 Sep 2017 05:04:11 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE921332E3 for ; Mon, 25 Sep 2017 05:04:11 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id F1BB040B9F for ; Mon, 25 Sep 2017 14:04:08 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id E13BD40B9E; Mon, 25 Sep 2017 14:04:08 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id D2D308385; Mon, 25 Sep 2017 14:04:08 +0200 (CEST) Date: Mon, 25 Sep 2017 14:04:08 +0200 From: Gert Doering To: Alexandre Petrescu Cc: Gert Doering , v6ops@ietf.org Message-ID: <20170925120408.GD45648@Space.Net> References: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> <20170922161337.GH45648@Space.Net> <20170924175047.GR45648@Space.Net> <20170925102034.GZ45648@Space.Net> <106a573c-2188-7629-e506-1f4baaf40b8a@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VYtKPK/qBWaYNJoU" Content-Disposition: inline In-Reply-To: <106a573c-2188-7629-e506-1f4baaf40b8a@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:04:14 -0000 --VYtKPK/qBWaYNJoU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Sep 25, 2017 at 12:26:59PM +0200, Alexandre Petrescu wrote: > > Please read Lorenzo's mail in-thread, and it will be clear what sort > > of radio he's talking about. >=20 > Sorry I dont have time. *You* are wasting 100s of man hours by not reading what other people write (or trying to understand). =20 So maybe you should just use your time to *read and think*, instead of=20 massively contributing to the overall noise on this mailing list? > Simply reading that email shows there is no knowledge about handovers. >=20 > So should not talk about matters where there is knowledge about. Please follow your advice. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --VYtKPK/qBWaYNJoU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnI8LYACgkQ31bAZeTO f8UBMw/+NEFDJWAL9Te1K+1nrv+uOuoeovih8PioWYUKrkf+FErrhHH0ZMHIlNop S1q4mCWFDMqXY6E/DCz+rjbHG2lOQYZUJFm66nipci3+MbkrKVrTqsmFNfScaDrq EBMhZiMGxU3E3Yzs09uHMW605uZj8OzhihH+cUyNK+cPJdQ0UbsroUy/sBItVm2T aDuDtL+iqMq1GPP2wZB4L+DnDUi+3suBERIOX6RhoJ2IUXsK+MEUjFG+4NmNH/Nx PzwClJpi1Bp2kTtQCJuP8KGyC4xpBVpvzvHLBq8x7R6ihPCmJTIXuxJIFryjf6MT PrFlRrA5Q8Bznb/9qGfN9xXapCJ+Nh3Bro3pXyGR4DoKyJ2yrnqLpwkkPXcMTAJf NBOT7ENwDDYwWJWeogf7QACNInNqTLFzASKx1MRLxg1K0dP0ZqiFqRrBXPUogAPR RuTjIhSkoCyU3y0rMsDrdYBXR2zCWAEjhO7vNBu5j4hQZlLSbFOEbY9Eb0aNbkrC Nrw/K3sFjwnTbUnRs3fKNs13msv3aCmKUuXKn39xyn+73RxTtVAP+eMvgrwFVvaZ /Htif+xRc4e8JPYwHoEIWgd+bpiWdZadkbLPhsgNEL9sI1KMK0UmWTYkHxooIaO9 rCC9VxPx5GbcgYnJ/OIwtmvVHwZJ0NC9OJp1+U/eHpG/rLoUoVk= =kyDE -----END PGP SIGNATURE----- --VYtKPK/qBWaYNJoU-- From nobody Mon Sep 25 05:05:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BD013239C for ; Mon, 25 Sep 2017 05:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIb6zUq9zSCa for ; Mon, 25 Sep 2017 05:05:11 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389131342DE for ; Mon, 25 Sep 2017 05:05:09 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id DB0B140BA0 for ; Mon, 25 Sep 2017 14:05:07 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id CBC5F40B9E; Mon, 25 Sep 2017 14:05:07 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id C8B258389; Mon, 25 Sep 2017 14:05:07 +0200 (CEST) Date: Mon, 25 Sep 2017 14:05:07 +0200 From: Gert Doering To: Alexandre Petrescu Cc: Gert Doering , v6ops@ietf.org Message-ID: <20170925120507.GE45648@Space.Net> References: <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> <20170925102250.GA45648@Space.Net> <81661be5-4a1a-1f8a-10d0-829e775546d9@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5sEZ4JZyRNYnuJVP" Content-Disposition: inline In-Reply-To: <81661be5-4a1a-1f8a-10d0-829e775546d9@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:05:12 -0000 --5sEZ4JZyRNYnuJVP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Sep 25, 2017 at 12:29:49PM +0200, Alexandre Petrescu wrote: > Le 25/09/2017 =E0 12:22, Gert Doering a =E9crit=A0: > > Hi, > >=20 > > On Mon, Sep 25, 2017 at 11:51:29AM +0200, Alexandre Petrescu wrote: > >> I also heard the term "native IPv6". This means there is no IPv4. > >=20 > > "native IPv6" usually means "IPv6 is not tunneled over IPv4" >=20 > That's for you. >=20 > For me "native IPv6" means there is no IPv4. And there are many such=20 > networks. Would you please just go away? Redefining everything in different ways =66rom everyone else, and then complaining that things will not work out the way you think it is is just wasting everyones time. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --5sEZ4JZyRNYnuJVP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnI8PIACgkQ31bAZeTO f8UVlw/+KZl7Gd2z3o5qZL14r/EnVa4rtU2gqbkFnAJ/BPpwFmhqIwxzo80f9Q4t lF/59tMDdLEhguR9LPPRcm19j7gBiFs+7n0B+YpB5laqUZhAjVf5Iq5S2fu+xCvT sOqanqTZuxprvva97Y7NCCtTIVvoY6sYAWmC3Mb40BzjhYxB5u1EH6YPvISx2M9x q3KEzoyMC1zhwrm9afgYx+6lpMRbIlOJCLPmBDRp0wBjoVWrGZqHDVgjOY7/dCFk eNxKcemkcfFsXRTdSK87jxH8hkjReH3diXj4hrKTl6elf2b8hIbhBPIkxFoMe4QL jEuMWXGdyYcpWx+jpeZ5dXiMePfMeo0Y7+GzDYOl26T3tgTMhuPYwA9n1FG3FJaI hGmExNqEpApTImSoQyGJvkPi/LYrTlsskgoHYCOZ30bh+WT27TRWZx2uvjjKt0pX Gmy3EOExcnplZsnyb60n2yKLGJojr5sG7BQ1OD72+FC3G5nqNZPU1b7t2uUsPb/l ZWkuS6X4Q1oBZYWnpg8yX6VDQU9NCFPysKqmJbj+f+mnCbqqau3ba0kwKbXWOxbf 9I8jHD9ANRpxhK7iKyzqjXdWwIXaquT1xLVzlyCj91b6lbw8E+PK7WU8WG4k4Mbj dgZLY1YwBS/OBR+zxbxqZqQGwG0YZiA2QxAuZml30/EkAeLld5A= =3964 -----END PGP SIGNATURE----- --5sEZ4JZyRNYnuJVP-- From nobody Mon Sep 25 05:20:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A539F1342E9 for ; Mon, 25 Sep 2017 05:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSQ29f73vZQo for ; Mon, 25 Sep 2017 05:20:18 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8EA01342D9 for ; Mon, 25 Sep 2017 05:20:16 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PCKFEU036045 for ; Mon, 25 Sep 2017 14:20:15 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 277F22090DD for ; Mon, 25 Sep 2017 14:20:15 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1E56820226F for ; Mon, 25 Sep 2017 14:20:15 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PCKEcD017498 for ; Mon, 25 Sep 2017 14:20:15 +0200 To: v6ops@ietf.org References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> <31CF5D7F-6A46-463E-883E-16F4DA4CBEE8@consulintel.es> From: Alexandre Petrescu Message-ID: <1feb79f3-0201-605b-7b8a-fe459fdd6376@gmail.com> Date: Mon, 25 Sep 2017 14:20:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <31CF5D7F-6A46-463E-883E-16F4DA4CBEE8@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:20:20 -0000 Le 25/09/2017 à 13:07, JORDI PALET MARTINEZ a écrit : > Many operators have not CGN yet, When they get it it wont be an IPv6 CGN, please. Because CGN means NAT. We dont want NAT in IPv6. > so IPv6-only solutions even if they require NAT64 Dont assume operators to come up with an IPv6 CGN, please. So operators wont require NAT64. Let operators do IPv4 NAT, CGN with IPv4, and native non-translated IPv6 all the way. > are more efficient (you have even open source for NAT64) and IPv4 > usage of a few IPv4 public addresses scale much better with NAT64 > than in CGN. Again: dont translate IPv6 to IPv4 or vice-versa. It becomes a mess, apps dont work. > And of course, if you have IPv6-only-access it means more and more > of your traffic is going thru to IPv6 destinations, so you have less > and less usage of any transition stuff. Yes, that way. > In addition to that there are implications in terms of battery and > radio bandwidth (keep-alives for CGN), which have much less impact > if the access network is IPv6-only. Well, I am not sure what you mean? You seem to be using the keep-alive argument (known for some apps to keem state up in some NATs) to claim that 464XLAT involves the terminal to consume less battery. Keep-alives for NAT will kill the battery - yes, so reduce the time you use IPv4 on the terminal. If you use IPv6 on terminal for same apps your battery will last longer. So I dont understand how NAT keepalives are an argument in favor of a translation mechanism. > I’ve not seen any native IPv6 app that gets impacted by transition. DHCPv6-PD is a native IPv6 app: it runs only IPv6 sockets, and it is an Application in Android Store. However, it is impacted by CLAT. More precisely: when CLAT runs DHCPv6-PD cant run. > I agree that transition is always imperfect, one way or another for > IPv4, but we need to balance between long-term strategy or staying > forever with IPv4. I agree. The strategy is: use IPv4 with NAT (if you dont have enough IPv4 publicly routable addresses), and use IPv6 pure at the same time. In the past there were other strategies like IPv6 growing islands (6bone), or IPv6-IPv4 translations (6to4). > Actually 464XLAT is really inexpensive, much less CapEx and OpEx > than any other transition and even than dual-stack-access. 464XLAT involves some issues with some apps. It's expensive to update apps to work with 464XLAT. Saying that 464XLAT is only part of the network (not in the terminal) is false - there is CLAT in terminal. Double-stack (IPv4-IPv6 PDP type, or PPPoE-v4-and-v6 on ADSL) is the least expensive. Alex From nobody Mon Sep 25 05:21:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CF1134293 for ; Mon, 25 Sep 2017 05:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tARnT0MpKBxp for ; Mon, 25 Sep 2017 05:21:37 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E1511342D9 for ; Mon, 25 Sep 2017 05:21:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PCLZ2R085313; Mon, 25 Sep 2017 14:21:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4AA0520943F; Mon, 25 Sep 2017 14:21:35 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3417C2094F6; Mon, 25 Sep 2017 14:21:35 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PCLYAl018604; Mon, 25 Sep 2017 14:21:35 +0200 To: Gert Doering Cc: v6ops@ietf.org References: <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922161018.GG45648@Space.Net> <20170922161337.GH45648@Space.Net> <20170924175047.GR45648@Space.Net> <20170925102034.GZ45648@Space.Net> <106a573c-2188-7629-e506-1f4baaf40b8a@gmail.com> <20170925120408.GD45648@Space.Net> From: Alexandre Petrescu Message-ID: <434fdffd-6999-b8d6-05ac-c879462c6224@gmail.com> Date: Mon, 25 Sep 2017 14:21:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170925120408.GD45648@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - handover X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:21:38 -0000 Le 25/09/2017 14:04, Gert Doering a crit: [...] >> So should not talk about matters where there is knowledge about. > > Please follow your advice. DO you know what is a handover? Then we can discuss. Alex > > Gert Doering > -- NetMaster > From nobody Mon Sep 25 05:23:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BBC134293 for ; Mon, 25 Sep 2017 05:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY0dJFjpAUIQ for ; Mon, 25 Sep 2017 05:23:15 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2921134239 for ; Mon, 25 Sep 2017 05:23:15 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PCNE2p086279; Mon, 25 Sep 2017 14:23:14 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E60F7201902; Mon, 25 Sep 2017 14:23:13 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id CF29D201163; Mon, 25 Sep 2017 14:23:13 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PCNDtG020070; Mon, 25 Sep 2017 14:23:13 +0200 To: Gert Doering Cc: v6ops@ietf.org References: <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> <20170925102250.GA45648@Space.Net> <81661be5-4a1a-1f8a-10d0-829e775546d9@gmail.com> <20170925120507.GE45648@Space.Net> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 14:23:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170925120507.GE45648@Space.Net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 12:23:22 -0000 Le 25/09/2017 14:05, Gert Doering a crit: > Hi, > > On Mon, Sep 25, 2017 at 12:29:49PM +0200, Alexandre Petrescu wrote: >> Le 25/09/2017 12:22, Gert Doering a crit: >>> Hi, >>> >>> On Mon, Sep 25, 2017 at 11:51:29AM +0200, Alexandre Petrescu wrote: >>>> I also heard the term "native IPv6". This means there is no IPv4. >>> >>> "native IPv6" usually means "IPv6 is not tunneled over IPv4" >> >> That's for you. >> >> For me "native IPv6" means there is no IPv4. And there are many such >> networks. > > Would you please just go away? Redefining everything in different ways > from everyone else, and then complaining that things will not work out > the way you think it is is just wasting everyones time. Excuse me - since when can _you_ ask people to go away, just like that? Have you ever come to a v6ops meeting? If so, maybe we can meet and say hello. BEfore that, I dont think you can talk like that. Alex > > Gert Doering > -- NetMaster > From nobody Mon Sep 25 07:15:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEC2134318 for ; Mon, 25 Sep 2017 07:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBIzOoNI_V5F for ; Mon, 25 Sep 2017 07:15:51 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15C0134220 for ; Mon, 25 Sep 2017 07:15:50 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id o42so8027249wrb.3 for ; Mon, 25 Sep 2017 07:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oCQwRDoGCrlIgFbA5EVQufjblI9C10PkUk6e908CUwA=; b=v3t3Mcre8IWOt4n5aSV66JSyV2ahvABZrzAHEXexxiCed3Efb8NQf+SmVDbfwFtyoa U1HRlGa6Zh+75gnSOGZMZUgJ1lxQHtOBq58NkPT1sEuBPtrxL0pVNmjd0mZUb0twgAJ8 2DIVJWQ3AarwFI7rJ6q60601e+ytXc7qwDwHc2/MQXN/8UlJ+BrSRUxZk8IDsO/ChdE2 BJsR4Y5DcC6NrA4tR9rDT0z4hCRH2pQnQnhfVX5O7IlVrdRzLcEf85iElIGgT+pwUabW kBvmdXp6GFNv7DGIK1Y38/Ujwg3lHlPnZApRl5R3jI1sEih2KmyrJJjA3TGrAH46j2I1 RBTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oCQwRDoGCrlIgFbA5EVQufjblI9C10PkUk6e908CUwA=; b=e0Jg0XPXgDpSdiFqxDjCRGC68/Lg/V4sVdrogyOFaI+6KgJ6KX8MrGtpjNpY3xpniD i22Zh8Vd7R5uMBMPz5LFQCWanm5yXGWiTqZK6M+EbXZg1jnZP4/P3ArE/8yaZ77yG78U SVr05roH9WMXCVwQ81r2Iez5owXTrmvhR0FMAUzzul+YJesHaGqMpoVBH+Sv77rUCqNx ZGW67LJo3JM46HxKD16QOWR+iaOOR52Dh+CdzRaCQyKP6h6ccGwU51OyzL1PoAJKbXnN hJMn2DFWH3ge7MYCBmo/1uqpfOXDfa/fN3JQniVqJmbMxO9+7XuRVXCmQ3IOtS7tBEDv +/Tg== X-Gm-Message-State: AHPjjUhHzOntLgwK+lb9L5V6eubzG0z8JnJUkXWYDvcR3+A0Q8KnhBGf wufiB2nfzFrk633d2dJxEKLxCN0me0bZbE6uwk8cRw== X-Google-Smtp-Source: AOwi7QAkLlel5f99r7XhXkvHsRskfkc9BIsCueDJBUBGU0UN84oicSWbupTH8+9taMAmfde+lcb6MPgJOkzallhSpUQ= X-Received: by 10.223.146.197 with SMTP id 63mr5817499wrn.180.1506348948840; Mon, 25 Sep 2017 07:15:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Mon, 25 Sep 2017 07:15:27 -0700 (PDT) In-Reply-To: <1feb79f3-0201-605b-7b8a-fe459fdd6376@gmail.com> References: <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> <31CF5D7F-6A46-463E-883E-16F4DA4CBEE8@consulintel.es> <1feb79f3-0201-605b-7b8a-fe459fdd6376@gmail.com> From: Erik Kline Date: Mon, 25 Sep 2017 23:15:27 +0900 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0d22c209d1e1055a043267" Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 14:15:53 -0000 --94eb2c0d22c209d1e1055a043267 Content-Type: text/plain; charset="UTF-8" > DHCPv6-PD is a native IPv6 app: it runs only IPv6 sockets, and it is an > Application in Android Store. However, it is impacted by CLAT. More > precisely: when CLAT runs DHCPv6-PD cant run. If this is true then take it up with app author, but there's precisely nothing that makes this adverse interaction a requirement. And don't be mislead by DHCPv6-PD talk in RFC6877 -- it isn't necessary, it's just one way to do things. --94eb2c0d22c209d1e1055a043267 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgd2RIxvF+WGLEr49b7OVDyGwKYMZ4kZaf gyugTcYypuQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTI1 MTQxNTQ5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBACMeDg2TSQHsAbdaTXW01kjInkOihrm3xd4nPtglPTD1Wopzr42o JccmIe0hgelC4iXjFIMYPC83V+uBImdAqDIA3mJs5A395nEo3PneAOgLJKie0yBqWIgpXRAuJZzU 8ok5RHCwN5CioK9X/3bT0FK1bSEQr6yu/+nligHQdu0PHnHdBAADPX3YcJTXfL/0NCZzWi6O+bK/ uIKdlOjN6wsBk9MtSMHLt1fl4MJpqPINZKgpkUzh5x7+3l+VXvBXoxS8mJt91tyoEhw7PvH0paX+ SzRq73qVkUhyoCBc6q7kmjemsW0OlI5q3v9/tMRb+mIzhUzugnESZEqAOWKBCkM= --94eb2c0d22c209d1e1055a043267-- From nobody Mon Sep 25 07:32:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B053B13445A for ; Mon, 25 Sep 2017 07:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu1cqClV8gfM for ; Mon, 25 Sep 2017 07:32:33 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0C313445E for ; Mon, 25 Sep 2017 07:32:03 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PEW1Zt005519; Mon, 25 Sep 2017 16:32:01 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 800222096AA; Mon, 25 Sep 2017 16:32:01 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 71428209360; Mon, 25 Sep 2017 16:32:01 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PEW1g9010128; Mon, 25 Sep 2017 16:32:01 +0200 To: Erik Kline Cc: "v6ops@ietf.org" References: <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <30eddc4a-c2cc-0e6a-9a39-7db255705b16@gmail.com> <7CBE3779-8A7F-4A77-A83A-A73B20600C92@consulintel.es> <1130b720-3b6c-11ed-10dc-35dc4591e402@gmail.com> <254C395D-5903-4C40-857A-24AB396BA1FA@consulintel.es> <31CF5D7F-6A46-463E-883E-16F4DA4CBEE8@consulintel.es> <1feb79f3-0201-605b-7b8a-fe459fdd6376@gmail.com> From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 16:32:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 14:32:34 -0000 Le 25/09/2017 à 16:15, Erik Kline a écrit : >> DHCPv6-PD is a native IPv6 app: it runs only IPv6 sockets, and it is an >> Application in Android Store. However, it is impacted by CLAT. More >> precisely: when CLAT runs DHCPv6-PD cant run. > > If this is true then take it up with app author, but there's precisely > nothing that makes this adverse interaction a requirement. Well, any DHCPv6-PD client needs to add addresses on the interfaces and in the routing table. A favorite OS like Android does not allow it. That's adversity. > And don't be mislead by DHCPv6-PD talk in RFC6877 -- it isn't > necessary, it's just one way to do things. I agree. Also DHCPv6-PD RFC can work on its own. Alex From nick.heatley@bt.com Mon Sep 25 04:56:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188411342D0 for ; Mon, 25 Sep 2017 04:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btgroupcloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CX4bMIiqoNw for ; Mon, 25 Sep 2017 04:56:27 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D052B1332E3 for ; Mon, 25 Sep 2017 04:56:26 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 25 Sep 2017 12:56:46 +0100 Received: from smtpe1.intersmtp.com (10.187.98.11) by EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 25 Sep 2017 12:56:23 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (213.199.154.208) by smtpe1.intersmtp.com (62.239.224.235) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 25 Sep 2017 12:56:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BTGroupCloud.onmicrosoft.com; s=selector1-bt-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bBp+RFu5W+KlwyTtKiIBVKEVUGNDsCqrwV1CLndQhGo=; b=Sq0EcXv4TvXxo5F0ExNtLyElEEZWgx9tpaukCQJAsI/cTHldQxj7xOj1f80IOINxTUm5ar9jaEEStc4IYwyDWTdoWsaUyLhLLLQeTaL815QV2P1P4bIvF9qLQCayfR1wfPRZxKi8SalcxrYN35n4w+I7q7QXSOJv5NBHfGnfb3I= Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM (10.167.24.147) by LO1P123MB0913.GBRP123.PROD.OUTLOOK.COM (10.167.26.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 25 Sep 2017 11:56:21 +0000 Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) by LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) with mapi id 15.20.0077.011; Mon, 25 Sep 2017 11:56:21 +0000 From: "Heatley,N,Nick,TQB R" To: IPv6 Ops WG Thread-Topic: 464xlat case study (was reclassify 464XLAT as standard instead of info) Thread-Index: AdM16ZBiVXxOrrPASdi8hSWu5DH/5g== Date: Mon, 25 Sep 2017 11:56:21 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.heatley@bt.com; x-originating-ip: [77.97.239.204] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LO1P123MB0913; 6:kf9athaEcGTGfglZgpPo614cUdKAE/Qpr6NQVoFTE2LPH5Vi2osFW4+d8K1/f3xC6G85hX5RLj/uMHYA01wRLzZtZImbvBhAkq5Oz4wKGhaqTJEYwurXnNFn3ZIRACllei9qZnHzYLrxVFWOU1uM7IqWC4VaYvZgK3TL4/4gAFNzHYFs00fnOxujctkE66xiDobO8Pa8UOjzCnGoS5Z5U7sqa1/O/IJ0SfuA70+fZ53IwpD5uSCOjnktlIKdjahoRW7soQqDqR397hgDRZNhw8UZ8FTGefDR3SdZ00qxbeKRpGcB1kaRMLnSZtHH+eMJGlcYWXF9ehwAv8BeoLpXGw==; 5:R5JQPKw3TzQDOBGhfJsAN6ETtvBod/j/Ze0Z09/HyqJ0ftMjwWTCJemkUaiz5sYLLiirlHyAcFmMSHUO423MwxrXGWsYppblkLV2EohP9qRbjlVY8SN1gJZYBSXMP1z7j7mFo9bkuwq2qVpZwATvSw==; 24:cEbS2JjJ7SlxMyzgHlItGgj1oadD5dclEKYGvfReSGljJAiHT+nESLoHAyRih8DAbv1ZyS8NSTnldW7kfUm67JXlOjYN98MWWxZMWMoPTEU=; 7:PBoy/YaKp1z5VltrPoM8Oage8aUjrVz5TEdDoTrs1yeYkrz5q9A2KaOaX1TkD/4yzikLGDQ3sGrCTCQbY8wzQb7w4Xjv+C5cI8S2XifyVsWWuKsb02svDuFfqJRC4Mk6F00HiK7bS8001J7JwtVKEtzT8rNbPP0UEbPPS5s0X2pFVx8m+X7wqxGqrLrrAHj1syklEOq2mqqOmCC6EFj0k7ARkVpxEv5NybhlJr9WBwU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 307c97dd-1ce0-4efe-62d8-08d5040c70a7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:LO1P123MB0913; x-ms-traffictypediagnostic: LO1P123MB0913: x-antispam-2: 1 x-exchange-antispam-report-test: UriScan:(190756311086443)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:LO1P123MB0913; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:LO1P123MB0913; x-forefront-prvs: 04410E544A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39830400002)(199003)(189002)(3846002)(102836003)(5660300001)(6116002)(74316002)(25786009)(106356001)(105586002)(790700001)(2906002)(6916009)(97736004)(9686003)(2900100001)(54896002)(8936002)(8676002)(55016002)(86362001)(81156014)(6306002)(3280700002)(3660700001)(81166006)(6506006)(189998001)(33656002)(101416001)(6436002)(77096006)(7736002)(316002)(53936002)(7696004)(54356999)(50986999)(68736007)(66066001)(14454004)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1P123MB0913; H:LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LO1P123MB01168388285206BB7C26F029EA7A0LO1P123MB0116GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Sep 2017 11:56:21.7836 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1P123MB0913 Archived-At: X-Mailman-Approved-At: Mon, 25 Sep 2017 08:19:37 -0700 Subject: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 11:57:14 -0000 --_000_LO1P123MB01168388285206BB7C26F029EA7A0LO1P123MB0116GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIG5vIGFyZ3VtZW50cyBhYm91dCBhcmNoaXRlY3R1cmUsIHRoZXJlIGFyZSBvbmx5 IGFyZ3VtZW50cyBhYm91dCByZXF1aXJlbWVudHMuDQoNCkhlcmUgaXMgbXkgY2FzZSBzdHVkeSBv biBOQVQ2NC9ETlM2NC80NjR4bGF0Lg0KTXkgcmVxdWlyZW1lbnRzOg0KDQogICogICBBIHNvbHV0 aW9uIGZvciBtdWx0aS1taWxsaW9uIG51bWJlcnMgb2YgY29uc3VtZXIgbm9kZXMgKHNtYXJ0cGhv bmVzKQ0KICAqICAgTWl0aWdhdGUgSVB2NCBwcml2YXRlIGFuZCBwdWJsaWMgYWRkcmVzcyBleGhh dXN0aW9uDQogICogICBFbmNhcHN1bGF0aW9uIGlzIG5vdCBjb21wYXRpYmxlIHdpdGggdGhlIGNv cmUgb2YgM0dQUCBtb2JpbGUgbmV0d29ya3Mg4oCTIG9ubHkgdHJhbnNsYXRpb24gaXMg4oCcQ29y ZSAmIFNlcnZpY2UtTEFOIGZyaWVuZGx54oCdLg0KICAqICAgS2VlcCB0aGUgcHJvdmlkZXIgbmV0 d29yayBzaW1wbGUg4oCTIHRoZSBvdmVyaGVhZCBvZiB0d28gYWRkcmVzcyBmYW1pbGllcyBwZXIg Y3VzdG9tZXIgaW4gdGhlIG1vYmlsZSBjb3JlIGlzIHVuZGVzaXJhYmxlIChhcyBpdCBkb3VibGVz IHRoZSBjb250cm9sIHBsYW5lIHNpZ25hbGxpbmcpDQogICogICAyIGNvbnN1bWVyIHVzZWNhc2Vz IChvbiB0aGUgc2FtZSBJbnRlcm5ldCBBUE4pIHRvIGNvbnNpZGVyIOKAkyBvbi1kZXZpY2UgYXBw cyAoc21hcnRwaG9uZSthcHBzKSwgdGV0aGVyaW5nIChzbWFydHBob25lK3dpZmktdGV0aGVyZWQg ZGV2aWNlIG9mIGFuIHVua25vd24gT1MpDQoNClRoYW5rcyB0byBlc3RlZW1lZCBBbmRyb2lkIGRl dmVsb3BlcnMgcHV0dGluZyA0NjR4bGF0IGludG8gQW5kcm9pZCwgb3RoZXJ3aXNlIHRoaXMgd291 bGRu4oCZdCBoYXZlIGhhcHBlbmVkLg0KRE5TNjQvTkFUNjQgZGlkIG5vdCBnZXQgcHV0IGludG8g cHJvZHVjdGlvbiB1bnRpbCA0NjR4bGF0IGFwcGVhcmVkIG9uIEFuZHJvaWQuDQpJIGhhZCB6ZXJv IElQdjYgY2xpZW50cyB1bnRpbCA0NjR4bGF0LCBJUHY2IHdhcyBpbnN1ZmZpY2llbnQgd2l0aG91 dCBpdC4NClByZWZpeC1zaGFyZSArIDQ2NHhsYXQgZ2F2ZSB0aGUgdGV0aGVyaW5nIHVzZS1jYXNl IHN1cHBvcnQuDQoNClRoZSByZXN1bHQgaGFzIGJlZW4gcmFwaWQgZGVwbG95bWVudCwgbWVldGlu ZyBhbGwgdGhlIHJlcXVpcmVtZW50cywgd2UgY3VycmVudGx5IG9ic2VydmUgc29tZXRoaW5nIGxp a2UgNzAlIG9mIGFuIElQdjYtb25seSBkZXZpY2VzIHRyYWZmaWMgaXMgSVB2Ni1JUHY2IGJhc2Vk IChhbmQgTkFULWZyZWUpLg0KSSBoYXZlIGEgZ29vZCBhbW91bnQgb2YgaW50ZXJuYWwgbW9iaWxl IGNvcmUgdHJhZmZpYyB0aGF0IGlzIElQdjYtb25seSAodGhlIGNvbWJpbmF0aW9uIG9mIElQdjYt b25seSBJTVMgQVBOIGZvciBWb1dpZmkgYW5kIFZvTFRFLCBhbmQgdGhpcyBpbnRlcm5ldCBBUE4p Lg0KDQpTbyB0aGlzIGlzIG15IG9waW5pb246IDQ2NHhsYXQgaXMgdGhlIGN1cnJlbnRseSB0aGUg YWRvcHRlZCBhcHByb2FjaCB3aGVuOg0KLSBJUHY0IGFkZHJlc3NlcyBhcmUgKG5lYXIpIGV4aGF1 c3RlZCBmb3IgdGhlIG1hc3MtbWFya2V0LA0KLSBBTkQgdGhlIHByb3ZpZGVyIG5ldHdvcmsgZGVt YW5kcyBhIHRyYW5zbGF0aW9uIHRlY2hub2xvZ3kgKGkuZS4gaW5jb21wYXRpYmxlIHdpdGggZW5j YXBzLikNCi0gQU5EIGF0IHRoZSBjbGllbnQgZW5kLCAgYXBwcyBhcmUgbm90IHB1cmdlZCBvZiBJ UHY0IGxpdGVyYWxzIE9SIHRldGhlcmluZyB0byBhbiB1bmtub3duIE9TIGlzIHJlcXVpcmVkDQoN CldoYXQgaXMgdGhlIHBvaW50IG9mIHNlZWtpbmcgQkNQIGZvciA0NjR4bGF0PyBJIGFtIG5vdCBl bnRpcmVseSBzdXJlLg0KSXQgc2hvdWxkIG5vdCBiZSB0byB0cnkgdG8gc2VsZWN0IEFwcGxlIHZz IEFuZHJvaWQgYXBwcm9hY2hlcywgSSB3YW50IHRvIHNlZSBib3RoIGFwcHJvYWNoZXMgc3VjY2Vz c2Z1bC4NCk1heWJlIGl0IGlzIHRvIGtlZXAgSUVURiByZWxldmFudCB0byB0aGUgcmVhbCB3b3Js ZCByZXF1aXJlbWVudHMgYW5kIHNwZWNpZmljIHVzZWNhc2VzLiBJ4oCZZCBsaWtlIHRvIHNlZSBJ RVRGIGRvIG1vcmUgb24gdXNlY2FzZXMvc29sdXRpb24gY29udGV4dCwgQkNQcyBjYW4gc2V0IHRo ZSBjb250ZXh0LCByaWdodD8NCk1heWJlIEkgY2FuIHVzZSBpdCB0byBoZWxwIGRyaXZlIGFuIElQ djYtb25seSA1Rz8NCk5pY2sNCg== --_000_LO1P123MB01168388285206BB7C26F029EA7A0LO1P123MB0116GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNt Ow0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDo0NTgzMDgyMTU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjYwMjIyMTUwIDE4MTk2OTE0NzIgMTM0ODA3NTU1IDEz NDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1 IDEzNDgwNzU1Nzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7DQoJ bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIG5vIGFyZ3VtZW50cyBhYm91dCBhcmNo aXRlY3R1cmUsIHRoZXJlIGFyZSBvbmx5IGFyZ3VtZW50cyBhYm91dCByZXF1aXJlbWVudHMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgaXMgbXkgY2FzZSBzdHVkeSBvbiBOQVQ2NC9ETlM2 NC80NjR4bGF0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgcmVxdWly ZW1lbnRzOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow Y207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkEgc29sdXRpb24gZm9yIG11bHRpLW1pbGxpb24g bnVtYmVycyBvZiBjb25zdW1lciBub2RlcyAoc21hcnRwaG9uZXMpPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+TWl0aWdhdGUgSVB2NCBwcml2YXRlIGFuZCBwdWJsaWMgYWRkcmVz cyBleGhhdXN0aW9uPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+RW5jYXBzdWxh dGlvbiBpcyBub3QgY29tcGF0aWJsZSB3aXRoIHRoZSBjb3JlIG9mIDNHUFAgbW9iaWxlIG5ldHdv cmtzIOKAkyBvbmx5IHRyYW5zbGF0aW9uIGlzIOKAnENvcmUgJmFtcDsgU2VydmljZS1MQU4gZnJp ZW5kbHnigJ0uPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+S2VlcCB0aGUgcHJv dmlkZXIgbmV0d29yayBzaW1wbGUg4oCTIHRoZSBvdmVyaGVhZCBvZiB0d28gYWRkcmVzcyBmYW1p bGllcyBwZXIgY3VzdG9tZXIgaW4gdGhlIG1vYmlsZSBjb3JlIGlzIHVuZGVzaXJhYmxlIChhcyBp dCBkb3VibGVzIHRoZSBjb250cm9sIHBsYW5lIHNpZ25hbGxpbmcpPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+MiBjb25zdW1lciB1c2VjYXNlcyAob24gdGhlIHNhbWUgSW50ZXJu ZXQgQVBOKSB0byBjb25zaWRlciDigJMgb24tZGV2aWNlIGFwcHMgKHNtYXJ0cGhvbmUmIzQzO2Fw cHMpLCB0ZXRoZXJpbmcgKHNtYXJ0cGhvbmUmIzQzO3dpZmktdGV0aGVyZWQgZGV2aWNlIG9mIGFu IHVua25vd24gT1MpPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyB0byBlc3Rl ZW1lZCBBbmRyb2lkIGRldmVsb3BlcnMgcHV0dGluZyA0NjR4bGF0IGludG8gQW5kcm9pZCwgb3Ro ZXJ3aXNlIHRoaXMgd291bGRu4oCZdCBoYXZlIGhhcHBlbmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RE5TNjQvTkFUNjQgZGlkIG5vdCBnZXQgcHV0IGludG8gcHJvZHVj dGlvbiB1bnRpbCA0NjR4bGF0IGFwcGVhcmVkIG9uIEFuZHJvaWQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhZCB6ZXJvIElQdjYgY2xpZW50cyB1bnRpbCA0NjR4bGF0 LCBJUHY2IHdhcyBpbnN1ZmZpY2llbnQgd2l0aG91dCBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlByZWZpeC1zaGFyZSAmIzQzOyA0NjR4bGF0IGdhdmUgdGhlIHRldGhl cmluZyB1c2UtY2FzZSBzdXBwb3J0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcmVzdWx0 IGhhcyBiZWVuIHJhcGlkIGRlcGxveW1lbnQsIG1lZXRpbmcgYWxsIHRoZSByZXF1aXJlbWVudHMs IHdlIGN1cnJlbnRseSBvYnNlcnZlIHNvbWV0aGluZyBsaWtlIDcwJSBvZiBhbiBJUHY2LW9ubHkg ZGV2aWNlcyB0cmFmZmljIGlzIElQdjYtSVB2NiBiYXNlZCAoYW5kIE5BVC1mcmVlKS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIGdvb2QgYW1vdW50IG9mIGlu dGVybmFsIG1vYmlsZSBjb3JlIHRyYWZmaWMgdGhhdCBpcyBJUHY2LW9ubHkgKHRoZSBjb21iaW5h dGlvbiBvZiBJUHY2LW9ubHkgSU1TIEFQTiBmb3IgVm9XaWZpIGFuZCBWb0xURSwgYW5kIHRoaXMg aW50ZXJuZXQgQVBOKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gdGhpcyBpcyBteSBvcGlu aW9uOiA0NjR4bGF0IGlzIHRoZSBjdXJyZW50bHkgdGhlIGFkb3B0ZWQgYXBwcm9hY2ggd2hlbjo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSVB2NCBhZGRyZXNzZXMgYXJl IChuZWFyKSBleGhhdXN0ZWQgZm9yIHRoZSBtYXNzLW1hcmtldCwgPG86cD4NCjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gQU5EIHRoZSBwcm92aWRlciBuZXR3b3JrIGRlbWFuZHMg YSB0cmFuc2xhdGlvbiB0ZWNobm9sb2d5IChpLmUuIGluY29tcGF0aWJsZSB3aXRoIGVuY2Fwcy4p PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEFORCBhdCB0aGUgY2xpZW50 IGVuZCwgJm5ic3A7YXBwcyBhcmUgbm90IHB1cmdlZCBvZiBJUHY0IGxpdGVyYWxzIE9SIHRldGhl cmluZyB0byBhbiB1bmtub3duIE9TIGlzIHJlcXVpcmVkPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldoYXQgaXMgdGhlIHBvaW50IG9mIHNlZWtpbmcgQkNQIGZvciA0NjR4bGF0PyBJIGFtIG5vdCBl bnRpcmVseSBzdXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2hv dWxkIG5vdCBiZSB0byB0cnkgdG8gc2VsZWN0IEFwcGxlIHZzIEFuZHJvaWQgYXBwcm9hY2hlcywg SSB3YW50IHRvIHNlZSBib3RoIGFwcHJvYWNoZXMgc3VjY2Vzc2Z1bC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1heWJlIGl0IGlzIHRvIGtlZXAgSUVURiByZWxldmFudCB0 byB0aGUgcmVhbCB3b3JsZCByZXF1aXJlbWVudHMgYW5kIHNwZWNpZmljIHVzZWNhc2VzLiBJ4oCZ ZCBsaWtlIHRvIHNlZSBJRVRGIGRvIG1vcmUgb24gdXNlY2FzZXMvc29sdXRpb24gY29udGV4dCwg QkNQcyBjYW4gc2V0IHRoZSBjb250ZXh0LCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1heWJlIEkgY2FuIHVzZSBpdCB0byBoZWxwIGRyaXZlIGFuIElQdjYtb25s eSA1Rz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5pY2s8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_LO1P123MB01168388285206BB7C26F029EA7A0LO1P123MB0116GBRP_-- From nobody Mon Sep 25 09:08:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03DC13448E for ; Mon, 25 Sep 2017 09:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQTLutv6fTGi for ; Mon, 25 Sep 2017 09:08:30 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1847A1344D0 for ; Mon, 25 Sep 2017 09:08:18 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8PG8FfL043501 for ; Mon, 25 Sep 2017 18:08:15 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 56B972098F2 for ; Mon, 25 Sep 2017 18:08:15 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4D542209825 for ; Mon, 25 Sep 2017 18:08:15 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8PG8E4o019414 for ; Mon, 25 Sep 2017 18:08:15 +0200 To: v6ops@ietf.org References: From: Alexandre Petrescu Message-ID: Date: Mon, 25 Sep 2017 18:08:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 16:08:34 -0000 Thanks for the study. IMHO I agree with some points, and disagree with others. Le 25/09/2017 à 13:56, Heatley,N,Nick,TQB R a écrit : > There are no arguments about architecture, there are only arguments > about requirements. > > Here is my case study on NAT64/DNS64/464xlat. > > My requirements: > > * A solution for multi-million numbers of consumer nodes (smartphones) > * Mitigate IPv4 private and public address exhaustion Excuse me, what do you mean by IPv4 private address exhaustion? I know about IPv4 public address exhaustion. It may be that a private exhaustion could be solved by a private IPv4 addressing scheme exclusively, without carving the "64::/" out from precious IPv6. > * Encapsulation is not compatible with the core of 3GPP mobile > networks – only translation is “Core & Service-LAN friendly”. > * Keep the provider network simple – the overhead of two address > families per customer in the mobile core is undesirable (as it > doubles the control plane signalling) I dont know what is the 'double control plane signalling'? In PDP Context setup one just says "type=IPv4IPv6" and it happens very fast. Then there is an IPv4 address and an IPv6 address on the device. > * 2 consumer usecases (on the same Internet APN) to consider – > on-device apps (smartphone+apps), tethering > (smartphone+wifi-tethered device of an unknown OS) Do you consider cars too? Because it may be that what you can do for smartphones wont work for cars. > Thanks to esteemed Android developers putting 464xlat into Android, > otherwise this wouldn’t have happened. > > DNS64/NAT64 did not get put into production until 464xlat appeared on > Android. > > I had zero IPv6 clients until 464xlat, IPv6 was insufficient without it. I agree, now you can tell customers to use IPv6 in all confidence, because IPv4 is there too. But tell them too that's not true IPv6. It is IPv6 with some INFORMATIONAL tweaks. That's somehow a surrogate "IPv6-ready" like in "HDReady". > Prefix-share + 464xlat gave the tethering use-case support. Good, but wont work for cars, and nor for Road-Side Units, or other bigger moving networks. In a car there are multiple IPv6 subnets, whereas 64share does only 1. A Road-Side Unit connected on IPv6 cellular also uses multiple IPv6 subnets. > The result has been rapid deployment, Rapid deployment of a surrogate IPv6. > meeting all the requirements, Who set these requirements? Is there an RFC containing these reqs? > we > currently observe something like 70% of an IPv6-only devices traffic is > IPv6-IPv6 based (and NAT-free). YEt it does not scale beyond that. The only way to scale it is to sell more smartphones. At the same time, you block all other devices (watches, cars, IoT) from connecting. You want them all to connect to the Internet _through_ smartphones? > I have a good amount of internal mobile core traffic that is IPv6-only > (the combination of IPv6-only IMS APN for VoWifi and VoLTE, and this > internet APN). > > So this is my opinion: 464xlat is the currently the adopted approach when: > > - IPv4 addresses are (near) exhausted for the mass-market, _Public_ IPv4 addresses are exhausted. It means new operators wont get any more IPv4. Old big operators already have huge IPv4 space. If there is some internal-company too many 10.s everywhere, maybe re-design the internal-company addressing architecture. > - AND the provider network demands a translation technology (i.e. > incompatible with encaps.) The provider network should never demand a translation technology. Because translation technology (and encap for that matter) is what actually _restrains_ the possibilities of growth in the future. > - AND at the client end,  apps are not purged of IPv4 literals OR > tethering to an unknown OS is required I dont understand? We do want apps purged of IPv4 literals, right? "Tethering to an unknown OS is required" - I dont know what you mean. > What is the point of seeking BCP for 464xlat? I am not entirely sure. > > It should not be to try to select Apple vs Android approaches, I want to > see both approaches successful. I agree. > Maybe it is to keep IETF relevant to the real world requirements and > specific usecases. I agree. > I’d like to see IETF do more on usecases/solution > context, BCPs can set the context, right? Yes, it would be good to come up with usecases, problem statement, before engaging in new work. > Maybe I can use it to help drive an IPv6-only 5G? Good intention. Do they (5G) have a GTP-IPv6-only version? No encapsulation, just IPv6. Does the 5G connection setup mechanism provide a /63 prefix for end-user? (or is it still the same old 64 SLAAC everywhere). Alex > Nick > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Sep 25 12:06:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47018134553 for ; Mon, 25 Sep 2017 12:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lMtR0lUwyhd for ; Mon, 25 Sep 2017 12:06:16 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07629134552 for ; Mon, 25 Sep 2017 12:06:16 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id l74so8476777oih.1 for ; Mon, 25 Sep 2017 12:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IUJPnaxGte30nOUoff7TP6lqxNZ43KushpF9xHEdC5c=; b=TWkV53H/m7XiBsLwUD0Ztio/SnphExZg4pqeMIzrpmFm4XIsSLrYwv10p+JEitw4tc lPmTvWAuzInWBurwiuhf2qiilzC7LCW9GGUPxwJVvlq9eOuN3dM1cplxJxwl05ZMi8P/ mkimLqqVFw9cQx9K0OG4G2VecEO9WYv6XJW4sVADVqjtM1zq2q1hYmUQk8kERQ6O/Ej3 Xq8KHNKxleQh5SMHxf+OKq/QLK3jjL/ex2xeRYcB3K8s3sgLWPJjAec9A2crEcrBf8G6 Vho9beUIOAGRtMosqGxDGgU1/reW4LtwyO8tcG81CcaJInqn6oLU9tRYItX5iu0etef0 0DGA== 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=IUJPnaxGte30nOUoff7TP6lqxNZ43KushpF9xHEdC5c=; b=G7/omBJ+QrhON7ixHxxqVVaSD8EuRWPg6c1YpJSSWF07ZYja4y5xRirkn2Z29SREKZ RMeMit9Hhg+MYXLR510L5k0tSZrxg4Lg5vKfgAt8gywglo1AKxMS9p8xyAr1M+Wlj7vt N+gViqPJ+ZW0nyDYM39Il/oIu0Jg6b6IQj/valgGp5fAfbTx3bRplyR8Fq6T3tEg6AQo OTDzt1aZzvDr0mCS2m744kCSVEyM1Mu7jUJlaml+TdV/oTkssuijVWS7N6UQgHwqRvE7 EXZ5GjMKwOTk8WSliiHmp9dTSV9vzqdhkZOnJF4DkLtr4pjaS5XW7KQ8hV9nqhMEpRkf PcSw== X-Gm-Message-State: AHPjjUgj1/Ek2qo/xS1cHJZPVkQnrI+AsbdH1fvsuhLcyTsFnxXJwYP/ 0kRK7MrAc2H7g1v0/dIrGIU= X-Google-Smtp-Source: AOwi7QDzopJ3RL2rt896UYEoCuqRQAMCJPRb7t2LZJKB2WhsG9RpbMzcu2dZMDrl1vvyqYlvQ46aGA== X-Received: by 10.157.44.199 with SMTP id e7mr688439otd.75.1506366375455; Mon, 25 Sep 2017 12:06:15 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::163f? ([2600:8802:5600:e::163f]) by smtp.gmail.com with ESMTPSA id w43sm405683ota.9.2017.09.25.12.06.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 12:06:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: Date: Mon, 25 Sep 2017 12:06:13 -0700 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <71DC2E77-20D3-4EC8-95B1-96070DA135E7@gmail.com> References: To: Alexandre Petrescu X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:06:17 -0000 > On Sep 25, 2017, at 9:08 AM, Alexandre Petrescu = wrote: >=20 > Excuse me, what do you mean by IPv4 private address exhaustion? Several companies, notably Microsoft and Comcast in the v6ops context, = and said that they were running out not only of public space but, within = their networks, private space. In the CGN context, this (in part, there = were other considerations) resulted in us requesting an additional RFC = 1918-like prefix for the space between a presumed NAT'd private address = space and a CGN.= From nobody Mon Sep 25 12:19:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C996013455A for ; Mon, 25 Sep 2017 12:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJSzN8iU3sf1 for ; Mon, 25 Sep 2017 12:19:46 -0700 (PDT) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CFCC132125 for ; Mon, 25 Sep 2017 12:19:46 -0700 (PDT) Received: by mail-pg0-x241.google.com with SMTP id i130so5365021pgc.0 for ; Mon, 25 Sep 2017 12:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=X6EvsQ0IrjwZIY0dgbn3wdg+ukREPFUebkPjWYF1dik=; b=OgHf99tN6XUQ5l2GbPyyMyf1mJAQTwKCBnTQ/8uyH4ckTwOBH9ixIir2NRT6h6PRuB xglDHacwv69U/JCmH6DliFpA5nDl2z6iTAYoDdZfVBwqtkjM/9I1QMDifGix0LyjG6OT iPpnWGhoaOxj1tJqCN0bLHxGkCymhN3noa1fbXONCfu0qjFJPUTpyEdvSzis5Wf4Rldi DL60BTfScleRgmVZRNG9O64Afsmhd8B5JB1V8iOUwFTb8xAaA5JRfnIrvaXjeIZCqlyA B/E7tur5xWp5puc12LtSd0uSZA2b+4JZhLA7vNRPBG7WRlLvmN+we6/cG2iLyEtS4R37 mpgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=X6EvsQ0IrjwZIY0dgbn3wdg+ukREPFUebkPjWYF1dik=; b=R/MiBdFGvw1pxr47gXnaeUdz2oLYmfqfEBb7X/yM2x0NsO+cYmqPAlyvXRfw/WnCsU +0HBEIe5X5XEmCkhrxf+AKmdVIm+jmpfwqHbpDwREoKo1Utf18mlJ2GlQKCVi2HnEoFK bzsdk69Mf0K/XrPZ9yEa2Q0GO386QlaHjNvTTuYixRV3duox70yoiI1pcZKTuq4jylPG wvQcslttYt6KRAOURvMhcl6xtWzXVZkszgTsI0dHD2p7m1dyyyA351m6q9xzDksgv83b jGnR2toDDokP2Y+njonMeA/zpsArGQU+rzZSKhRMWL1ACvPSjPZsWcm98nyPK5Td6S6H ltlQ== X-Gm-Message-State: AHPjjUjC8ADZW9OJOeolvrucYaBKuYkxLKFZtkOhZpkQtg93lW+XOTLd Kv4DN3KWnwmAnU9R1wR9GVStt5TI X-Google-Smtp-Source: AOwi7QD9hC2+JDpXT05+6GCbSyhzDedUOTlb/WtiMRZA6cidhucYzVvMjke3VoNaiO6SaLcEurGaHA== X-Received: by 10.99.179.66 with SMTP id x2mr8536582pgt.336.1506367185914; Mon, 25 Sep 2017 12:19:45 -0700 (PDT) Received: from ?IPv6:2406:e007:7d76:1:28cc:dc4c:9703:6781? ([2406:e007:7d76:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b75sm15865492pfc.29.2017.09.25.12.19.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 12:19:45 -0700 (PDT) To: v6ops@ietf.org References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0b02c1eb-a693-b8d3-da32-06eaf4ae2bce@gmail.com> Date: Tue, 26 Sep 2017 08:19:45 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:19:48 -0000 On 25/09/2017 09:45, Lee Howard wrote: > Personal opinion... =2E.. > Dual stack doesn't solve the problem IPv6 was created to solve, which i= s the lack of available IPv4 addresses.=20 That made me sit up. In a sense it's true, but the reason for dual stack as the original co-existence mechanism was so that *servers* could serve both legacy (IPv4) and current (IPv6) clients throughout the transition period. So dual stack, all the way from the server to to the client's provider edge, was very much part of solving the lack of IPv4 addresses. This became inadequate because too many ISPs and hosting providers were too slow to support IPv6. That's why we're now in translation hell. On 25/09/2017 23:27, JORDI PALET MARTINEZ wrote: > Maybe you=E2=80=99re not there, but operators live in a world where the= y don=E2=80=99t have any more IPv4 addresses, so double-stack is over in = the access networks.=20 That isn't true everywhere. There are still plenty of places where consum= er ISPs have IPv4 addresses for new customers (one per customer, of course). Of c= ourse, this won't be true for much longer. Therefore: > Maybe you=E2=80=99re not there, but operators live in a world where the= y don=E2=80=99t have any more IPv4 addresses, so double-stack is over in = the access networks. However, there are devices and apps (in both cellula= r/tethering and non-cellular), that are IPv4-only, so user networks/LANs,= need some transition support to make IPv4 transparently available end-to= -end. Yes, sadly. And in that situation, stating that 464XLAT is BCP seems quit= e reasonable. Sad but true. Brian From nobody Mon Sep 25 12:25:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B132113456C for ; Mon, 25 Sep 2017 12:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsuJDSJD1oEX for ; Mon, 25 Sep 2017 12:25:46 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5766F132153 for ; Mon, 25 Sep 2017 12:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506367544; x=1506972344; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=UNwPyY5DDuSh8s5uGObcfdXEQ DyKdzFSmjZ2VqFanEo=; b=nYQdNyf9UQxMIdRxZ0OI9f1e2T90ES+5002zcZgeh aIHNBbpXxkZvvB4JtfFdC8HWZP5mBQ76hItUAUUWWz16Fy2c31pzYiaos6lUtBn5 rg3BgwZp+3qabxoH4n4Y2+Yx36DVkZ1QPlE8U3BCPP5m82IigToHQLOqyvwUgMTA Js= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=EEF40x8emR5KgNH54iUssn5Lbq9MjZU9jFLs1wFKSkTS0OIomfmGP/frIH1l ppYf474tio5VgsXJ8kGAmJ8w3arkcuk4fqn88sV18Gr42jHWhySktMvQG U4xD6nKCdX3mFG+5L8GTwWsm8ryKVLhKj+eZvGaxVYGTKOmiBUW2Is=; X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 21:25:44 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 21:25:44 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005567527.msg for ; Mon, 25 Sep 2017 21:25:43 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170925:md50005567527::Q0TNqfrdGxrxbIhH:00001JPe X-Return-Path: prvs=1441fc161e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Mon, 25 Sep 2017 21:25:38 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <0b02c1eb-a693-b8d3-da32-06eaf4ae2bce@gmail.com> In-Reply-To: <0b02c1eb-a693-b8d3-da32-06eaf4ae2bce@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:25:49 -0000 I guess the main issue is that we miscalculated how much time will take for= the operators/hosting providers to deploy IPv6. If the =E2=80=9Cdeployment=E2=80=9D work was started just 3-4 years before,= the situation will be now totally different =E2=80=A6 (and that will mean = that we will had spent much less effort in finding new and =E2=80=9Cbest=E2= =80=9D transition mechanisms, etc.). Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Organizaci=C3=B3n: University of Auckland Responder a: Fecha: lunes, 25 de septiembre de 2017, 21:20 Para: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double= stack coexistence On 25/09/2017 09:45, Lee Howard wrote: > Personal opinion... ... > Dual stack doesn't solve the problem IPv6 was created to solve, which= is the lack of available IPv4 addresses.=20 =20 That made me sit up. In a sense it's true, but the reason for dual stac= k as the original co-existence mechanism was so that *servers* could serv= e both legacy (IPv4) and current (IPv6) clients throughout the transition period. So dual stack, all the way from the server to to the client's provider edge, was very much part of solving the lack of IPv4 addresses= . =20 This became inadequate because too many ISPs and hosting providers were too slow to support IPv6. That's why we're now in translation hell. =20 On 25/09/2017 23:27, JORDI PALET MARTINEZ wrote: =20 > Maybe you=E2=80=99re not there, but operators live in a world where t= hey don=E2=80=99t have any more IPv4 addresses, so double-stack is over in = the access networks.=20 =20 That isn't true everywhere. There are still plenty of places where cons= umer ISPs have IPv4 addresses for new customers (one per customer, of course). Of= course, this won't be true for much longer. Therefore: =20 > Maybe you=E2=80=99re not there, but operators live in a world where t= hey don=E2=80=99t have any more IPv4 addresses, so double-stack is over in = the access networks. However, there are devices and apps (in both cellular/= tethering and non-cellular), that are IPv4-only, so user networks/LANs, nee= d some transition support to make IPv4 transparently available end-to-end. =20 Yes, sadly. And in that situation, stating that 464XLAT is BCP seems qu= ite reasonable. Sad but true. =20 Brian =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Sep 25 12:30:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDE4132153 for ; Mon, 25 Sep 2017 12:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH6dQpxR1P-s for ; Mon, 25 Sep 2017 12:30:27 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45CC7132125 for ; Mon, 25 Sep 2017 12:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506367825; x=1506972625; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=tBuKBEMvmPELoLVFF7GwWiga8 FrAy/Zg2Ps1Hz6+SR4=; b=PB2oV7617AEdEwIJEO8ZbsB8jgk2568ADeBB2EXyJ 34d6NFI52YpkvJVG8X0Cp6PIXcQWhqO2sZgEmrJHOXxFl+KHMrwI05rWgo/BgS0h lvUGS8UuwX4WrvqVebvXR85hzyU0awV1WfyJKYoTDj5dSnzoE+6ppoVI9ffPsEEP sw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=UiD6a/JpPK3jJoDFQeNrwWJBYgjQ4j8k30D4XKaLvzrcFuICZVBzzrr/VrUO TMl++i1Ii9Vo22u+lZFHCCxBilWjUfBr62jS8uhq26PX3H+3haZ+XhuYR DI3/yNjxDtTL0bbEMB+ZExNICn7ZrSHXe4RiDhRNWaYTrM4Tg7QUJ4=; X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 21:30:25 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 21:30:24 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005567543.msg for ; Mon, 25 Sep 2017 21:30:23 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170925:md50005567543::QJ+3hcPbplOVCebZ:00003SlA X-Return-Path: prvs=1441fc161e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Mon, 25 Sep 2017 21:30:20 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <31C96F2A-9A0D-46C0-B03F-F0E39A35BAD5@consulintel.es> Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence References: <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <20170921223305.B72A8878E716@rock.dv.isc.org> <122454EE-64C5-4768-A6A9-1AD0E872F5F9@employees.org> <2a879713-bfd0-2ba0-cb67-53726f6e1faf@gmail.com> <41c808ef-b2c0-6e74-e61d-e89fcebe5e0a@gmail.com> <0b02c1eb-a693-b8d3-da32-06eaf4ae2bce@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - double stack coexistence X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:30:29 -0000 Clarifying myself =E2=80=A6 in the sense that having deployed IPv6 much ear= lier will have avoided exhausting IPv4 addresses *before* IPv6 is actually = deployed in s sufficient % of the networks. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de JORDI PALET MARTINEZ Responder a: Fecha: lunes, 25 de septiembre de 2017, 21:26 Para: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - double= stack coexistence I guess the main issue is that we miscalculated how much time will take= for the operators/hosting providers to deploy IPv6. =20 If the =E2=80=9Cdeployment=E2=80=9D work was started just 3-4 years bef= ore, the situation will be now totally different =E2=80=A6 (and that will m= ean that we will had spent much less effort in finding new and =E2=80=9Cbes= t=E2=80=9D transition mechanisms, etc.). =20 Regards, Jordi =20 =20 -----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Organizaci=C3=B3n: University of Auckland Responder a: Fecha: lunes, 25 de septiembre de 2017, 21:20 Para: Asunto: Re: [v6ops] reclassify 464XLAT as standard instead of info - do= uble stack coexistence =20 On 25/09/2017 09:45, Lee Howard wrote: > Personal opinion... ... > Dual stack doesn't solve the problem IPv6 was created to solve, w= hich is the lack of available IPv4 addresses.=20 =20 That made me sit up. In a sense it's true, but the reason for dual = stack as the original co-existence mechanism was so that *servers* could = serve both legacy (IPv4) and current (IPv6) clients throughout the transi= tion period. So dual stack, all the way from the server to to the client= 's provider edge, was very much part of solving the lack of IPv4 addre= sses. =20 This became inadequate because too many ISPs and hosting providers = were too slow to support IPv6. That's why we're now in translation hell. =20 On 25/09/2017 23:27, JORDI PALET MARTINEZ wrote: =20 > Maybe you=E2=80=99re not there, but operators live in a world whe= re they don=E2=80=99t have any more IPv4 addresses, so double-stack is over= in the access networks.=20 =20 That isn't true everywhere. There are still plenty of places where = consumer ISPs have IPv4 addresses for new customers (one per customer, of course)= . Of course, this won't be true for much longer. Therefore: =20 > Maybe you=E2=80=99re not there, but operators live in a world whe= re they don=E2=80=99t have any more IPv4 addresses, so double-stack is over= in the access networks. However, there are devices and apps (in both cellu= lar/tethering and non-cellular), that are IPv4-only, so user networks/LANs,= need some transition support to make IPv4 transparently available end-to-e= nd. =20 Yes, sadly. And in that situation, stating that 464XLAT is BCP seem= s quite reasonable. Sad but true. =20 Brian =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Sep 25 12:31:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3613219C for ; Mon, 25 Sep 2017 12:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHyo99-Efndn for ; Mon, 25 Sep 2017 12:31:34 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F8B132D89 for ; Mon, 25 Sep 2017 12:31:34 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id u130so8126013oib.11 for ; Mon, 25 Sep 2017 12:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7Vs2MeyUPPlm+50O4SOi8JYQ8H8p5v5hHq580j80DsU=; b=letR5np/vwrZWQopII00YFsh8mL2Hc2Mh7Am9ZuTtA5mbKDnS9LIIkMQYqVHnd/FUW FB9DzFE+1JszpSvluhua/4jjORC0KYuPK+jb+vyQwJTSHkl+9VpI+K2PROxLPl1TCDbb 1svuN91gUuQSoG3ZfmGwAjvDi0oIQSby0ZzK6as441EI7Q88/ekKSyN0uD5jSEAxTd1m REWTDeUY3M0rx1ZPr0BVmX3Q2RvPDnqoctVgpzV+i/q5sT0lcT7BX8zCgytuA9vaCHkP nzxuFSe2bdQ/IJYPosowKIoW97VTcIWcIERB1tYGloXZ7QXQ+z5LtJgdggOwrYtrkx1X nyjg== 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=7Vs2MeyUPPlm+50O4SOi8JYQ8H8p5v5hHq580j80DsU=; b=DHRYf+2u3btmNOiPwUWomDnhaZeJ7NU3DvMo8+pl6EOYsLmKNmAreUWt510VP+5y/v niYmqslhi2VsYHKGUxRXPPUwnE7DjFzkY/sA0tWctuqWjmK8tuloNtsF1QQD/YJs8Xn/ /ct5xpR5JcpwLR+9gUpt8Q8uGNMUoLL5AhE3Y8Tt4HBq/AcT8Wqu7+SAWXbAKpEXg/0p Te+/yDImE3oyxjiX8zUuBcgC4s4o70lRuOWtXQB8M1ZkjwOoT9NN1gyc/SKFhhvX9nHi zdnFq4pEcYfwjYSpKvik6/n3wV8WDNYwwB64qs/+ZfcBX3WxbHsCNePh3JHVzpzvSKnL 5kRA== X-Gm-Message-State: AHPjjUgcyNASoDtBgkWUboZz6uzyddHAnZ+om6Ya8pBO8AWoXhiFho/k f1geNdktVB55723s+i8EYGz9kuW2 X-Google-Smtp-Source: AOwi7QDsinuiqUFu4MtcEYuLuS0GtDI0rU9pS55GvaCOSn7lHrFp96+zH2SGtQiUJOS8Z1DxH7bCjw== X-Received: by 10.202.177.70 with SMTP id a67mr10357921oif.35.1506367893864; Mon, 25 Sep 2017 12:31:33 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::163f? ([2600:8802:5600:e::163f]) by smtp.gmail.com with ESMTPSA id u13sm404253otg.30.2017.09.25.12.31.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Sep 2017 12:31:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: Fred Baker In-Reply-To: <20170925120507.GE45648@Space.Net> Date: Mon, 25 Sep 2017 12:31:31 -0700 Cc: v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <79BA8440-3BF6-42B1-9B90-C37BBB2FB66A@gmail.com> References: <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> <20170925102250.GA45648@Space.Net> <81661be5-4a1a-1f8a-10d0-829e775546d9@gmail.com> <20170925120507.GE45648@Space.Net> To: Gert Doering , Alexandre Petrescu X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:31:36 -0000 Speaking as chair, the person who can actually ask someone to "please go = away". I'm not asking anyone to "go away". I will note that IETF working groups = do much of their work on mailing lists, and have active participants who = operate on their lists primarily, and in some cases only, on those = lists. You are each active in v6ops, and appreciated by the chairs. That said, Alexandre, I have to agree with Gert that the views you have = expressed in the past few days have added little to the discussion. They = differ from many of the networks and deployments discussed in v6ops, and = aren't particularly helpful. In specific cases, as others have noted, = they are incorrect. What I, as chair, will ask - of each of us - is that if you have = comments to make that are personal rather than technical, please address = them privately to the person in question. We have close to 1000 people = on this mailing list, and the other 999 don't really need the noise. > On Sep 25, 2017, at 5:05 AM, Gert Doering wrote: >=20 > Hi, >=20 > On Mon, Sep 25, 2017 at 12:29:49PM +0200, Alexandre Petrescu wrote: >> Le 25/09/2017 =C3=A0 12:22, Gert Doering a =C3=A9crit : >>> Hi, >>>=20 >>> On Mon, Sep 25, 2017 at 11:51:29AM +0200, Alexandre Petrescu wrote: >>>> I also heard the term "native IPv6". This means there is no IPv4. >>>=20 >>> "native IPv6" usually means "IPv6 is not tunneled over IPv4" >>=20 >> That's for you. >>=20 >> For me "native IPv6" means there is no IPv4. And there are many such=20= >> networks. >=20 > Would you please just go away? Redefining everything in different = ways > from everyone else, and then complaining that things will not work out > the way you think it is is just wasting everyones time. >=20 > Gert Doering > -- NetMaster > --=20 > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. = Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Sep 25 12:34:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFC713457C for ; Mon, 25 Sep 2017 12:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzHu4iwYpyGa for ; Mon, 25 Sep 2017 12:34:15 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425A8132125 for ; Mon, 25 Sep 2017 12:34:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.111] (unknown [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 2BF0E1BC37 for ; Mon, 25 Sep 2017 19:34:11 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: <71DC2E77-20D3-4EC8-95B1-96070DA135E7@gmail.com> Date: Mon, 25 Sep 2017 20:34:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <79925FFC-05F5-473E-8167-EB719E5ACAF8@thehobsons.co.uk> References: <71DC2E77-20D3-4EC8-95B1-96070DA135E7@gmail.com> To: "v6ops@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:34:17 -0000 Fred Baker wrote: > Several companies, notably Microsoft and Comcast in the v6ops context, = and said that they were running out not only of public space but, within = their networks, private space. In the CGN context, this (in part, there = were other considerations) resulted in us requesting an additional RFC = 1918-like prefix for the space between a presumed NAT'd private address = space and a CGN. While I'd never considered that before now, it makes sense. 10/8 only = has 16 million addresses (or, say, 65k /24s), plus another million for = 172/12 and another 65k for 192.168/16. Given that (for example) Azure = uses a lot of RFC1918 addressing internally, it's not hard to see how = they could be running into problems. From nobody Mon Sep 25 12:50:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40A134575 for ; Mon, 25 Sep 2017 12:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLZDp9dxpgPZ for ; Mon, 25 Sep 2017 12:50:53 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FA7134582 for ; Mon, 25 Sep 2017 12:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506369051; x=1506973851; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=/ekDvldaDv5QmJ+K9fHsz18OV ndUfCQf1xB48rAKcrg=; b=LPIuQ5bW27kZpAD3M9Rq8Ac6O8OTQcYphgHfbx8Mo zS+X5CzdsWmHSbqug/K1QZ6t8ZRFE40mzfQgaPqOTeN3gxOpS4sgJFaDO8HkyKcT azeemiw92NbbfaTky6vRD3OU5BUz78oolvVmRpUbsfGVGg/sMrC6bVf620R+2sej FI= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=irsX+qy36z29njuJH/tBsM+fblQSlfqbUomSSoTNXfL2sI4l7kFW1Gi9SFAc Vp9Im9IAzfNqq0O8t8noiIX7CfTeqFAGWwkwI8q69+diq6InCa01/b882 M5vku7V64A3SdmL2B0gd5//UItPlhFanzH+Ry2Y5kF5HF+VF1CFJo0=; X-MDAV-Processed: mail.consulintel.es, Mon, 25 Sep 2017 21:50:51 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 25 Sep 2017 21:50:51 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005567578.msg for ; Mon, 25 Sep 2017 21:50:50 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170925:md50005567578::oMQQ2m9/OI4Q2PE6:00003Fgj X-Return-Path: prvs=1441fc161e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Mon, 25 Sep 2017 21:50:48 +0200 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: <4D460AEB-2B9F-4A99-B64C-10DE5EE5BEF8@consulintel.es> Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) References: <71DC2E77-20D3-4EC8-95B1-96070DA135E7@gmail.com> <79925FFC-05F5-473E-8167-EB719E5ACAF8@thehobsons.co.uk> In-Reply-To: <79925FFC-05F5-473E-8167-EB719E5ACAF8@thehobsons.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 19:50:55 -0000 If I=E2=80=99m correct, this was the reason big cable operators such as Com= cast, pushed CableLabs to accept IPv6 for the management network at least i= n DOCSIS 3.0, as they had already run out of RFC1918 space, so they need to= duplicate it across his own network, a big trouble =E2=80=A6 I think SoftB= ank run into the same problem, probably just a few really big operators, bu= t a big mess for them. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Simon Hobson Responder a: Fecha: lunes, 25 de septiembre de 2017, 21:34 Para: "v6ops@ietf.org list" Asunto: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard = instead of info) Fred Baker wrote: =20 > Several companies, notably Microsoft and Comcast in the v6ops context= , and said that they were running out not only of public space but, within = their networks, private space. In the CGN context, this (in part, there wer= e other considerations) resulted in us requesting an additional RFC 1918-li= ke prefix for the space between a presumed NAT'd private address space and = a CGN. =20 While I'd never considered that before now, it makes sense. 10/8 only h= as 16 million addresses (or, say, 65k /24s), plus another million for 172/1= 2 and another 65k for 192.168/16. Given that (for example) Azure uses a lot= of RFC1918 addressing internally, it's not hard to see how they could be r= unning into problems. =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Sep 25 13:41:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011FB134581 for ; Mon, 25 Sep 2017 13:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn0Bo5ZdoJqY for ; Mon, 25 Sep 2017 13:41:03 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F160013219F for ; Mon, 25 Sep 2017 13:41:02 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 7704040ECC for ; Mon, 25 Sep 2017 22:41:00 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 6823340ECB; Mon, 25 Sep 2017 22:41:00 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 59A1BA5C3; Mon, 25 Sep 2017 22:41:00 +0200 (CEST) Date: Mon, 25 Sep 2017 22:41:00 +0200 From: Gert Doering To: Alexandre Petrescu Cc: Gert Doering , v6ops@ietf.org Message-ID: <20170925204100.GJ45648@Space.Net> References: <20170922161018.GG45648@Space.Net> <20170922161337.GH45648@Space.Net> <20170924175047.GR45648@Space.Net> <20170925102034.GZ45648@Space.Net> <106a573c-2188-7629-e506-1f4baaf40b8a@gmail.com> <20170925120408.GD45648@Space.Net> <434fdffd-6999-b8d6-05ac-c879462c6224@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ImDQVvcpB8Lz2VYf" Content-Disposition: inline In-Reply-To: <434fdffd-6999-b8d6-05ac-c879462c6224@gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info - handover X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 20:41:05 -0000 --ImDQVvcpB8Lz2VYf Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Sep 25, 2017 at 02:21:34PM +0200, Alexandre Petrescu wrote: > Le 25/09/2017 =E0 14:04, Gert Doering a =E9crit=A0: > [...] > >> So should not talk about matters where there is knowledge about. > > Please follow your advice. > DO you know what is a handover? I do :-) > Then we can discuss. No. You are beyond hope. You are ignoring advice from people that have the operatinal experience, are making up your own meanings for industry accepted terms, and are generally confusing everything possible on all possible layers. There is no way to discuss with you before you learn to *read* and *think*, and this will be my last response to you (until then). Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --ImDQVvcpB8Lz2VYf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAlnJadkACgkQ31bAZeTO f8XPcQ/+I8CsnAx3+wqaNVNS/3ewSskm/yKum3p8XMIJFHrsQsfdHHXIwT9LzuO1 z2mhty/7nYCc1oX0aZ+5mDzMWyxI+vR7tOFJZ8YftxGI5JUnTfPLtZ99VHDvBWxZ mPReEipQciuF+5dJvmT+nDsutapoD/KmYJ61q/DDYw4UHmFjewo+Je0j8pYETviT 80HztzPthODd/aqeHPaM/wIVC4MZvypbMxuLJs8uwGmo+SbrNZQ1pZzvOYEZcbdl wmwGiXInRsq0WduPxn8gLv73IWH+h9EhwTlJXRyeNb9P3+udARDN+93yPHUClDnP GOGQ3eoMgRV/DCzPbouAu+fAy5XFAYTeq6YogfpNmkdqe4KQR6rsqziZVSCzVZQg RMx1DS2wUjks6jq48AKU22fDzvB6cU2h5oLnsgCp5RxI4Fy/Dye6xIEXSshcgFNO fQK+wSQPe5wUyGXye0BluR43nDVtNjsaf62tP3BklELeF4UYzyknKHvSuaXHhnK/ iysQ1MJFaiEZxQXzzMXkf8H0Huzk72JZZXMojHuhIR6N/Vv9UsJc/hm4fFH0WoyJ Oj4aLiMwfyCvZ17r9sIZTIidnUu72iPcstnywiTa2zz4JgxeWMwBMvejf97QWUR+ WUC7iWwXMj5ZM362tyd5YjeWimA9Zdio7hzRGfhGp7mxSdEKQSQ= =xrO+ -----END PGP SIGNATURE----- --ImDQVvcpB8Lz2VYf-- From nobody Mon Sep 25 15:50:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B761345DB for ; Mon, 25 Sep 2017 15:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQVwhimME0Tq for ; Mon, 25 Sep 2017 15:50:35 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAE9124239 for ; Mon, 25 Sep 2017 15:50:35 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5409F34A07F; Mon, 25 Sep 2017 22:50:32 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 165C916007E; Mon, 25 Sep 2017 22:50:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0007116007B; Mon, 25 Sep 2017 22:50:31 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 07Fy1oAHLOp8; Mon, 25 Sep 2017 22:50:31 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 906E7160050; Mon, 25 Sep 2017 22:50:31 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DABE487DE1F6; Tue, 26 Sep 2017 08:50:28 +1000 (AEST) To: "Heatley,N,Nick,TQB R" Cc: IPv6 Ops WG From: Mark Andrews References: In-reply-to: Your message of "Mon, 25 Sep 2017 11:56:21 +0000." Date: Tue, 26 Sep 2017 08:50:28 +1000 Message-Id: <20170925225028.DABE487DE1F6@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2017 22:50:37 -0000 In message , "Heatley,N,Nick,TQB R" writes: > There are no arguments about architecture, there are only arguments about > requirements. > > Here is my case study on NAT64/DNS64/464xlat. > My requirements: > > * A solution for multi-million numbers of consumer nodes (smartphones) > * Mitigate IPv4 private and public address exhaustion > * Encapsulation is not compatible with the core of 3GPP mobile > networks only translation is Core & Service-LAN friendly. > * Keep the provider network simple the overhead of two address > families per customer in the mobile core is undesirable (as it doubles > the control plane signalling) > * 2 consumer usecases (on the same Internet APN) to consider > on-device apps (smartphone+apps), tethering (smartphone+wifi-tethered > device of an unknown OS) The problem with those requirement is that miss the most important one. Don't do damage. DNS64 does damage to the DNS. NAT64 does damage to IPv6. DNS64/NAT64 and 464XLAT externalise the cost of not upgrading the billing software to unwrap the encapsulation. > Thanks to esteemed Android developers putting 464xlat into Android, > otherwise this wouldnt have happened. > DNS64/NAT64 did not get put into production until 464xlat appeared on > Android. > I had zero IPv6 clients until 464xlat, IPv6 was insufficient without it. > Prefix-share + 464xlat gave the tethering use-case support. > The result has been rapid deployment, meeting all the requirements, we > currently observe something like 70% of an IPv6-only devices traffic is > IPv6-IPv6 based (and NAT-free). Just running the dual stack and a regular CGN rather than a NAT64 also achieves that as IPv6 nodes prefer IPv6 over IPv4 as the transport. > I have a good amount of internal mobile core traffic that is IPv6-only > (the combination of IPv6-only IMS APN for VoWifi and VoLTE, and this > internet APN). > > So this is my opinion: 464xlat is the currently the adopted approach when: > - IPv4 addresses are (near) exhausted for the mass-market, > - AND the provider network demands a translation technology (i.e. > incompatible with encaps.) > - AND at the client end, apps are not purged of IPv4 literals OR > tethering to an unknown OS is required AND you are willing to be selfish and ignore the costs you are externalising on everyone else. No network DEMANDS translation technology. You could have spent a little bit of developer time and upgraded the billing software to understand about encapsulation. Its a very simple concept. Even the most junior of developers could have done this. > What is the point of seeking BCP for 464xlat? I am not entirely sure. > It should not be to try to select Apple vs Android approaches, I want to > see both approaches successful. > Maybe it is to keep IETF relevant to the real world requirements and > specific usecases. Id like to see IETF do more on usecases/solution > context, BCPs can set the context, right? > Maybe I can use it to help drive an IPv6-only 5G? > Nick -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Sep 25 20:48:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A98134654; Mon, 25 Sep 2017 20:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qj2B9LXks4RO; Mon, 25 Sep 2017 20:48:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C224C1321B6; Mon, 25 Sep 2017 20:48:44 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPH57332; Tue, 26 Sep 2017 03:48:43 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 26 Sep 2017 04:48:42 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.187]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Tue, 26 Sep 2017 11:48:34 +0800 From: wangzitao To: "draft-ietf-v6ops-rfc6555bis.all@ietf.org" , "ops-dir@ietf.org" , "v6ops@ietf.org" Thread-Topic: Opsdir last call review of draft-ietf-v6ops-rfc6555bis-05 Thread-Index: AdM2ei/eNr5+iiczQaiB16FoxZShig== Date: Tue, 26 Sep 2017 03:48:33 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.152] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2AEC1824DGGEMM506MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59C9CE1B.004A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.187, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2c90f4370f701f0b1b97ef8a859612b6 Archived-At: Subject: [v6ops] Opsdir last call review of draft-ietf-v6ops-rfc6555bis-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 03:48:47 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2AEC1824DGGEMM506MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reviewer: Zitao WANG Review result: Ready I have reviewed draft-ietf-v6ops-rfc6555bis-05 as part of the Operational d= irectorate's ongoing effort to review all IETF documents being processed by= the IESG. These comments were written with the intent of improving the op= erational aspects of the IETF drafts. Comments that are not addressed in la= st call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any ot= her last call comments. "This document specifies requirements for algorithms that reduce this user-= visible delay and provides an example algorithm, and expands on "Happy Eyeb= alls" [RFC6555], a technique of reducing user-visible delays on dual-stack = hosts. Now that this approach has been deployed at scale and measured for = several years, the algorithm specification can be refined to improve its re= liability and generalization. This document recommends an algorithm of rac= ing resolved addresses that has several stages of ordering and racing to av= oid delays to the user whenever possible, while preferring the use of IPv6.= Specifically, it discusses how to handle DNS queries when starting a conn= ection on a dual-stack client, how to create an ordered list of destination= addresses to which to attempt connections, and how to race the connection = attempts." My overall view of the document is 'Ready' for publication. One small comment is that there are some id-nits, please fix it in next ver= sion: (See RFCs 3967 and 4897 for information about using normative referenc= es to lower-maturity documents in RFCs) =3D=3D Missing Reference: 'Section 3' is mentioned on line 120, but not d= efined =3D=3D Missing Reference: 'Section 4' is mentioned on line 164, but not d= efined =3D=3D Missing Reference: 'Section 5' is mentioned on line 202, but not d= efined =3D=3D Missing Reference: 'Section 6' is mentioned on line 169, but not d= efined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (=3D=3D), 3 comments = (--). --_000_E6BC9BBCBCACC246846FC685F9FF41EA2AEC1824DGGEMM506MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reviewer: Zitao WANG

Review result: Ready

 

I have reviewed draft-ietf-v6ops-rfc6555bis-05 as= part of the Operational directorate's ongoing effort to review all IETF do= cuments being processed by the IESG.  These comments were written with= the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call m= ay be included in AD reviews during the IESG review.

Document editors and WG chairs should treat these= comments just like any other last call comments.

 

"This document specifies requirements for al= gorithms that reduce this user-visible delay and provides an example algori= thm, and expands on "Happy Eyeballs" [RFC6555], a technique of re= ducing user-visible delays on dual-stack hosts.  Now that this approach has been deployed at scale and measured for several= years, the algorithm specification can be refined to improve its reliabili= ty and generalization.  This document recommends an algorithm of racin= g resolved addresses that has several stages of ordering and racing to avoid delays to the user whenever possibl= e, while preferring the use of IPv6.  Specifically, it discusses how t= o handle DNS queries when starting a connection on a dual-stack client, how= to create an ordered list of destination addresses to which to attempt connections, and how to race the connection = attempts.”

 

My overall view of the document is 'Ready' for pu= blication.

 

One small comment is that there are some id-nits,= please fix it in next version:

 

     (See RFCs 3967 and 48= 97 for information about using normative references

     to lower-maturity doc= uments in RFCs)

 

  =3D=3D Missing Reference: 'Section 3' i= s mentioned on line 120, but not defined

 

  =3D=3D Missing Reference: 'Section 4' i= s mentioned on line 164, but not defined

 

  =3D=3D Missing Reference: 'Section 5' i= s mentioned on line 202, but not defined

 

  =3D=3D Missing Reference: 'Section 6' i= s mentioned on line 169, but not defined

 

 

     Summary: 0 errors (**= ), 0 flaws (~~), 4 warnings (=3D=3D), 3 comments (--).

 

 

 

 

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2AEC1824DGGEMM506MBXchi_-- From nobody Tue Sep 26 14:14:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80CE13445F for ; Tue, 26 Sep 2017 14:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btgroupcloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16Cg_zrVGx-U for ; Tue, 26 Sep 2017 14:14:48 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3966133083 for ; Tue, 26 Sep 2017 14:14:47 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.bt.com (10.187.98.12) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 26 Sep 2017 22:15:10 +0100 Received: from smtpe1.intersmtp.com (10.187.98.11) by EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 26 Sep 2017 22:14:44 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (213.199.154.213) by smtpe1.intersmtp.com (62.239.224.235) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 26 Sep 2017 22:14:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BTGroupCloud.onmicrosoft.com; s=selector1-bt-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wrfc5r28t31GYFy95lBtz/y8AfdmUUnZWTkUBacn9jQ=; b=Ay4K4VgW/sNVJN59q3EMA5TjjNB6feX5YFN/ToT3VJPMBhj0/0u20njy16QSsiuCWijbYyaQHwvJ8ZnRztkT6inevFm2aqm4JNSgh6bluO3uyF51ZXMQ6X/kES+rHCXu3ZJfXBTTPdIRW9D8MxJtOpm+7OW9mP6ieXgyrGojF0s= Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM (10.167.24.147) by LO1P123MB0882.GBRP123.PROD.OUTLOOK.COM (10.167.25.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Tue, 26 Sep 2017 21:14:42 +0000 Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) by LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) with mapi id 15.20.0077.011; Tue, 26 Sep 2017 21:14:41 +0000 From: "Heatley,N,Nick,TQB R" To: Mark Andrews CC: IPv6 Ops WG Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) Thread-Index: AdM16ZBiVXxOrrPASdi8hSWu5DH/5gAZyZY1AC5K0hA= Date: Tue, 26 Sep 2017 21:14:41 +0000 Message-ID: References: <20170925225028.DABE487DE1F6@rock.dv.isc.org> In-Reply-To: <20170925225028.DABE487DE1F6@rock.dv.isc.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.heatley@bt.com; x-originating-ip: [77.97.239.204] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LO1P123MB0882; 6:02g6V9L1B8jA3D+JwLBdN2oBBByXEjXFknO8D90uVxP+utejJ9q6gdQWfggpCVW8Bi1PXkhJkuTDjDJRqN1FLptEuz+vPdutf2n3KLY098q+271LreLU3UUtExbt59Lkwk7pt+j573DTdT2NsiCy7A/X1CmB5RQi+o/blazRE9aGnx1aK7Znw5ixK04/nTDz/tjBiIqj4M4k5fHxKHAJMmD+3feirKWSDDw8gHkuvEqgO8cP3ITML+paYz6UQxxry+D8ZXESgpoPC78rdZ7C6bT3QyyGerdULwm9kFOCPLjvC6cf1UieLfG2X4zdbE9JD6ghjEDxm2VD3AbnBB26Gg==; 5:iWikBzHirllC2Rd9+KRXPfL8+S75FXYGTwVGk2h01kDR9MitKMwSfImCZJ5NIRs7xoBTC/6ZYRlk+npFcs+IN2Y73kXdEWbVXuW2tc25vEa1QUzPo1yK/qU0WNUhTMXb7YhbWU0TvbWSpu/bJtNDpA==; 24:X3/JXHVxsqTQxICRQbiRhzLKX9mu2fH8HODNgXUsjGPe9nTcVjWQnACWTeCUyaS9cKUYueA398F3duJj5VhaZW97vKdWm91f79WIEmGxNWc=; 7:gBy4JLFmkp+Rym6RKpl736F4HF39FJ8lNDNaBnLNdfW1YRlZapmcGxOcIUCnS9nIX5IZVsAHdzTOCz7G8OoXF6k6pGa+Z/TlOSM77Lxeo49dHRkAmDmE2YdixopcDvYwJT1l7V8QHHQa9PG9nR/DbleKWMsA/dsfsYQ12blFYxeSpSzJNEbZ+IYHgwAAKpfDxkAZPuCoRQonLrzb9ex5+4ej45AgkKkdda8ROkxgLqc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c70a856a-04a4-420d-edd1-08d505239aa7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:LO1P123MB0882; x-ms-traffictypediagnostic: LO1P123MB0882: x-antispam-2: 1 x-exchange-antispam-report-test: UriScan:(146908506813832)(190756311086443)(189930954265078)(175275609761927); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:LO1P123MB0882; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:LO1P123MB0882; x-forefront-prvs: 0442E569BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(13464003)(199003)(66066001)(6506006)(4326008)(81156014)(6116002)(3846002)(74316002)(102836003)(25786009)(97736004)(189998001)(86362001)(9686003)(68736007)(53936002)(2900100001)(81166006)(478600001)(305945005)(7736002)(2950100002)(54356999)(5660300001)(3280700002)(76176999)(33656002)(6916009)(7696004)(101416001)(229853002)(53546010)(316002)(8676002)(106356001)(6436002)(77096006)(55016002)(3660700001)(105586002)(14454004)(2906002)(6246003)(50986999)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1P123MB0882; H:LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2017 21:14:41.8234 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1P123MB0882 Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 21:14:51 -0000 TWFyaywgV2hhdCBpcyB0aGlzIGVuY2Fwc3VsYXRpb24gc29sdXRpb24/IA0KVGhlcmUgaXMgbm8g cnVubmluZyBjb2RlIGZvciB0aGlzIG9uIGNsaWVudCBkZXZpY2VzLCBhcyBmYXIgYXMgSSBrbm93 IC0gcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHdlIHNldCB2YXJpb3VzIHZlbmRvcnMnICJqdW5pb3Ig ZGV2ZWxvcGVycyIgb24gdmFyaW91cyBwYXJ0cyBvZiAzR1BQIGNvcmUgc3RhY2vwn5iKLg0KDQpU aGUgYWx0ZXJuYXRpdmUgZm9yIGFuIG9wZXJhdG9yIGNvbmNlcm5lZCB3aXRoIGV4aGF1c3Rpb24g b2YgcHJpdmF0ZSBhZGRyZXNzaW5nLCBpcyB0byBzdGFydCBydW5uaW5nIG92ZXJsYXBwaW5nIGNv cGllcyBvZiB0aGUgcHJpdmF0ZSBhZGRyZXNzIHJhbmdlczsgZm9yIGRpZmZlcmVudCBjdXN0b21l ciBzZWdtZW50cyBvciBkYXRhIGNlbnRyZXMgb3IgcmVnaW9ucyBvZiB0aGUgbmV0d29yay4NCkkg YW0gZGVhZGx5IHNlcmlvdXMgYWJvdXQgdGhpcywgdGhpcyBpcyB3aGF0IG9wZXJhdG9ycyBoYXZl IGRvbmUuIFRoaXMgY29tZXMgd2l0aCBvciB3aXRob3V0IElQdjYsIGJlY2F1c2UgaWYgeW91IGhh dmUgdG8gcnVuIHY0IHdoeSBhZGQgaW4gYSBzZWNvbmQgYWRkcmVzcyBmYW1pbHk/DQpJIGd1ZXNz IHlvdSB3aWxsIGJlIGhhcHB5IHdpdGggdGhpcyBvdXRjb21lIGJlY2F1c2UgeW91IGJlbGlldmUg TkFUNDQgQ0dOIGlzIHN1cGVyaW9yIHRvIE5BVDY0IENHTi4gQnV0IEkgdGhpbmsgeW91IGFyZSBt aXNzaW5nIHRoZSBwb2ludC4NCkFzIG90aGVycyBoYXZlIHN0YXRlZCwgeW91ciBwZXJjZWl2ZWQg aXNzdWVzIGFyZSBhbGwgcHJvYmxlbXMgdGllZCB0byBJUHY0LiBJIGhhdmUgYSB3YXkgdGhhdCBk cml2ZXMgSVB2Ni1vbmx5IGluIG15IG5ldHdvcmsuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IE1hcmsgQW5kcmV3cyBbbWFpbHRvOm1hcmthQGlzYy5vcmddIA0KU2VudDog MjUgU2VwdGVtYmVyIDIwMTcgMjM6NTANClRvOiBIZWF0bGV5LE4sTmljayxUUUIgUiA8bmljay5o ZWF0bGV5QGJ0LmNvbT4NCkNjOiBJUHY2IE9wcyBXRyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3Y2b3BzXSA0NjR4bGF0IGNhc2Ugc3R1ZHkgKHdhcyByZWNsYXNzaWZ5IDQ2NFhMQVQg YXMgc3RhbmRhcmQgaW5zdGVhZCBvZiBpbmZvKQ0KDQoNCkluIG1lc3NhZ2UgPExPMVAxMjNNQjAx MTY4Mzg4Mjg1MjA2QkI3QzI2RjAyOUVBN0EwQExPMVAxMjNNQjAxMTYuR0JSUDEyMy5QUk9ELk9V VExPT0suQ09NPiwgIkhlYXRsZXksTixOaWNrLFRRQiBSIiB3cml0ZXM6DQo+IFRoZXJlIGFyZSBu byBhcmd1bWVudHMgYWJvdXQgYXJjaGl0ZWN0dXJlLCB0aGVyZSBhcmUgb25seSBhcmd1bWVudHMg DQo+IGFib3V0IHJlcXVpcmVtZW50cy4NCj4NCj4gSGVyZSBpcyBteSBjYXNlIHN0dWR5IG9uIE5B VDY0L0ROUzY0LzQ2NHhsYXQuDQo+IE15IHJlcXVpcmVtZW50czoNCj4NCj4gICAqICAgQSBzb2x1 dGlvbiBmb3IgbXVsdGktbWlsbGlvbiBudW1iZXJzIG9mIGNvbnN1bWVyIG5vZGVzIChzbWFydHBo b25lcykNCj4gICAqICAgTWl0aWdhdGUgSVB2NCBwcml2YXRlIGFuZCBwdWJsaWMgYWRkcmVzcyBl eGhhdXN0aW9uDQo+ICAgKiAgIEVuY2Fwc3VsYXRpb24gaXMgbm90IGNvbXBhdGlibGUgd2l0aCB0 aGUgY29yZSBvZiAzR1BQIG1vYmlsZQ0KPiBuZXR3b3JrcyAgb25seSB0cmFuc2xhdGlvbiBpcyBD b3JlICYgU2VydmljZS1MQU4gZnJpZW5kbHkuDQo+ICAgKiAgIEtlZXAgdGhlIHByb3ZpZGVyIG5l dHdvcmsgc2ltcGxlICB0aGUgb3ZlcmhlYWQgb2YgdHdvIGFkZHJlc3MNCj4gZmFtaWxpZXMgcGVy IGN1c3RvbWVyIGluIHRoZSBtb2JpbGUgY29yZSBpcyB1bmRlc2lyYWJsZSAoYXMgaXQgZG91Ymxl cyANCj4gdGhlIGNvbnRyb2wgcGxhbmUgc2lnbmFsbGluZykNCj4gICAqICAgMiBjb25zdW1lciB1 c2VjYXNlcyAob24gdGhlIHNhbWUgSW50ZXJuZXQgQVBOKSB0byBjb25zaWRlcg0KPiBvbi1kZXZp Y2UgYXBwcyAoc21hcnRwaG9uZSthcHBzKSwgdGV0aGVyaW5nIChzbWFydHBob25lK3dpZmktdGV0 aGVyZWQgDQo+IGRldmljZSBvZiBhbiB1bmtub3duIE9TKQ0KDQpUaGUgcHJvYmxlbSB3aXRoIHRo b3NlIHJlcXVpcmVtZW50IGlzIHRoYXQgbWlzcyB0aGUgbW9zdCBpbXBvcnRhbnQgb25lLg0KDQoJ RG9uJ3QgZG8gZGFtYWdlLg0KDQpETlM2NCBkb2VzIGRhbWFnZSB0byB0aGUgRE5TLg0KTkFUNjQg ZG9lcyBkYW1hZ2UgdG8gSVB2Ni4NCg0KRE5TNjQvTkFUNjQgYW5kIDQ2NFhMQVQgZXh0ZXJuYWxp c2UgdGhlIGNvc3Qgb2Ygbm90IHVwZ3JhZGluZyB0aGUgYmlsbGluZyBzb2Z0d2FyZSB0byB1bndy YXAgdGhlIGVuY2Fwc3VsYXRpb24uDQoNCj4gVGhhbmtzIHRvIGVzdGVlbWVkIEFuZHJvaWQgZGV2 ZWxvcGVycyBwdXR0aW5nIDQ2NHhsYXQgaW50byBBbmRyb2lkLCANCj4gb3RoZXJ3aXNlIHRoaXMg d291bGRudCBoYXZlIGhhcHBlbmVkLg0KPiBETlM2NC9OQVQ2NCBkaWQgbm90IGdldCBwdXQgaW50 byBwcm9kdWN0aW9uIHVudGlsIDQ2NHhsYXQgYXBwZWFyZWQgb24gDQo+IEFuZHJvaWQuDQo+IEkg aGFkIHplcm8gSVB2NiBjbGllbnRzIHVudGlsIDQ2NHhsYXQsIElQdjYgd2FzIGluc3VmZmljaWVu dCB3aXRob3V0IGl0Lg0KPiBQcmVmaXgtc2hhcmUgKyA0NjR4bGF0IGdhdmUgdGhlIHRldGhlcmlu ZyB1c2UtY2FzZSBzdXBwb3J0Lg0KPiBUaGUgcmVzdWx0IGhhcyBiZWVuIHJhcGlkIGRlcGxveW1l bnQsIG1lZXRpbmcgYWxsIHRoZSByZXF1aXJlbWVudHMsIHdlIA0KPiBjdXJyZW50bHkgb2JzZXJ2 ZSBzb21ldGhpbmcgbGlrZSA3MCUgb2YgYW4gSVB2Ni1vbmx5IGRldmljZXMgdHJhZmZpYyANCj4g aXMNCj4gSVB2Ni1JUHY2IGJhc2VkIChhbmQgTkFULWZyZWUpLg0KDQpKdXN0IHJ1bm5pbmcgdGhl IGR1YWwgc3RhY2sgYW5kIGEgcmVndWxhciBDR04gcmF0aGVyIHRoYW4gYSBOQVQ2NCBhbHNvIGFj aGlldmVzIHRoYXQgYXMgSVB2NiBub2RlcyBwcmVmZXIgSVB2NiBvdmVyIElQdjQgYXMgdGhlIHRy YW5zcG9ydC4NCg0KPiBJIGhhdmUgYSBnb29kIGFtb3VudCBvZiBpbnRlcm5hbCBtb2JpbGUgY29y ZSB0cmFmZmljIHRoYXQgaXMgSVB2Ni1vbmx5IA0KPiAodGhlIGNvbWJpbmF0aW9uIG9mIElQdjYt b25seSBJTVMgQVBOIGZvciBWb1dpZmkgYW5kIFZvTFRFLCBhbmQgdGhpcyANCj4gaW50ZXJuZXQg QVBOKS4NCj4NCj4gU28gdGhpcyBpcyBteSBvcGluaW9uOiA0NjR4bGF0IGlzIHRoZSBjdXJyZW50 bHkgdGhlIGFkb3B0ZWQgYXBwcm9hY2ggd2hlbjoNCj4gLSBJUHY0IGFkZHJlc3NlcyBhcmUgKG5l YXIpIGV4aGF1c3RlZCBmb3IgdGhlIG1hc3MtbWFya2V0LA0KPiAtIEFORCB0aGUgcHJvdmlkZXIg bmV0d29yayBkZW1hbmRzIGEgdHJhbnNsYXRpb24gdGVjaG5vbG9neSAoaS5lLg0KPiBpbmNvbXBh dGlibGUgd2l0aCBlbmNhcHMuKQ0KPiAtIEFORCBhdCB0aGUgY2xpZW50IGVuZCwgIGFwcHMgYXJl IG5vdCBwdXJnZWQgb2YgSVB2NCBsaXRlcmFscyBPUiANCj4gdGV0aGVyaW5nIHRvIGFuIHVua25v d24gT1MgaXMgcmVxdWlyZWQNCg0KQU5EIHlvdSBhcmUgd2lsbGluZyB0byBiZSBzZWxmaXNoIGFu ZCBpZ25vcmUgdGhlIGNvc3RzIHlvdSBhcmUgZXh0ZXJuYWxpc2luZyBvbiBldmVyeW9uZSBlbHNl Lg0KDQpObyBuZXR3b3JrIERFTUFORFMgdHJhbnNsYXRpb24gdGVjaG5vbG9neS4gIFlvdSBjb3Vs ZCBoYXZlIHNwZW50IGEgbGl0dGxlIGJpdCBvZiBkZXZlbG9wZXIgdGltZSBhbmQgdXBncmFkZWQg dGhlIGJpbGxpbmcgc29mdHdhcmUgdG8gdW5kZXJzdGFuZCBhYm91dCBlbmNhcHN1bGF0aW9uLiAg SXRzIGEgdmVyeSBzaW1wbGUgY29uY2VwdC4gIEV2ZW4gdGhlIG1vc3QganVuaW9yIG9mIGRldmVs b3BlcnMgY291bGQgaGF2ZSBkb25lIHRoaXMuDQoNCj4gV2hhdCBpcyB0aGUgcG9pbnQgb2Ygc2Vl a2luZyBCQ1AgZm9yIDQ2NHhsYXQ/IEkgYW0gbm90IGVudGlyZWx5IHN1cmUuDQo+IEl0IHNob3Vs ZCBub3QgYmUgdG8gdHJ5IHRvIHNlbGVjdCBBcHBsZSB2cyBBbmRyb2lkIGFwcHJvYWNoZXMsIEkg d2FudCANCj4gdG8gc2VlIGJvdGggYXBwcm9hY2hlcyBzdWNjZXNzZnVsLg0KPiBNYXliZSBpdCBp cyB0byBrZWVwIElFVEYgcmVsZXZhbnQgdG8gdGhlIHJlYWwgd29ybGQgcmVxdWlyZW1lbnRzIGFu ZCANCj4gc3BlY2lmaWMgdXNlY2FzZXMuIElkIGxpa2UgdG8gc2VlIElFVEYgZG8gbW9yZSBvbiB1 c2VjYXNlcy9zb2x1dGlvbiANCj4gY29udGV4dCwgQkNQcyBjYW4gc2V0IHRoZSBjb250ZXh0LCBy aWdodD8NCj4gTWF5YmUgSSBjYW4gdXNlIGl0IHRvIGhlbHAgZHJpdmUgYW4gSVB2Ni1vbmx5IDVH Pw0KPiBOaWNrDQoNCi0tDQpNYXJrIEFuZHJld3MsIElTQw0KMSBTZXltb3VyIFN0LiwgRHVuZGFz IFZhbGxleSwgTlNXIDIxMTcsIEF1c3RyYWxpYQ0KUEhPTkU6ICs2MSAyIDk4NzEgNDc0MiAgICAg ICAgICAgICAgICAgSU5URVJORVQ6IG1hcmthQGlzYy5vcmcNCg== From nobody Tue Sep 26 14:59:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E25F134499 for ; Tue, 26 Sep 2017 14:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 EJPbNISt_gta for ; Tue, 26 Sep 2017 14:59:29 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08D5134493 for ; Tue, 26 Sep 2017 14:59:29 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id c137so6639117pga.11 for ; Tue, 26 Sep 2017 14:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wvBazr2Hl43hlJ+S8xeL/6n9nM0yqTgyfuwKaAkMoO4=; b=aF/39IYsTwXC9yGA8kwkIsfbdofhBf4RWYF5G7+4bT6bbQYO24gdaSXvTjMCphaqWK 62DUbCPOTfzAw34BuO+0Zx4WYiz9WNvgr+q0rOc+DbZUsR0NGL9GxufuzaBekVqxEdCX pFyDI7KnCKavYx9Ju6s1Mb2EaDl5PmPjTNwm+Gr26g48YWCPRAAFAHYGvnJaeFw5l/Ay metfq7tRFluyekYXVclSeZfVNlVhFYSVQKJ7MRN2XR4cJHKv4tyhqKdOC7uY9gTC5Ux1 ds+mZWvnAvwnoDIQkBnAiT2+3gkC3+nVAnbz5O3bBpa/3YJoNX+JjpW4XCmJbcdKLAxK UalQ== 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=wvBazr2Hl43hlJ+S8xeL/6n9nM0yqTgyfuwKaAkMoO4=; b=JP7M19cVijSq3KbcnBckCursfwR9bhI0RTButkS0f4wUZpTcay/4DmzKOdmhFnMlP5 049nfdiBNsEOivCEKBD5u0ShuY0admRiOiR9bodYSHfc46VizgrzIZhDlKExDTVRgZvH GGDmLeC3KB97efSRVDDglUmlCKU50cFP03lBvAk1QIw7XVX9es2M7fVbd5mEPD+IxkEI Pc18MnZLIms8zQEcHMQOv25nxiYgBO7ObYelFP8yOZrqNXnSEigpaqcS6lWyVsfIadqG VgjFW7Reu98zU/WjPXTqKyB+ZCk+QPfn+HF4y+lLtIq/KSILXKOwzNZhAbJz7jNsdNdO GKBQ== X-Gm-Message-State: AHPjjUh3Q6J1Lx4HQ775M2CKEezTCN85KesHgATMSuhaIAOpxYsZ28cb 57juizGiy6T9rPncHPpPZmvVog== X-Google-Smtp-Source: AOwi7QDzsePJ1YzUyXYjxNIX0cJ+5/Pu52g+mjIJ80u9pNDYwULu0OmTUuTsRzZGd2+n5qKNXkGrfg== X-Received: by 10.84.230.134 with SMTP id e6mr5391069plk.46.1506463169003; Tue, 26 Sep 2017 14:59:29 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:916e:c73b:d1cf:8010? ([2620:0:10e7:10:916e:c73b:d1cf:8010]) by smtp.gmail.com with ESMTPSA id i84sm17313630pfj.105.2017.09.26.14.59.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Sep 2017 14:59:28 -0700 (PDT) From: james woodyatt Message-Id: <46045DAA-9096-43BA-A5FD-571232767726@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_85B1F795-CB45-4314-986D-165D2D8628DA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 26 Sep 2017 14:59:27 -0700 In-Reply-To: Cc: IPv6 Ops WG To: "Heatley,N,Nick,TQB R" References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 21:59:32 -0000 --Apple-Mail=_85B1F795-CB45-4314-986D-165D2D8628DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 25, 2017, at 04:56, Heatley,N,Nick,TQB R = wrote: >=20 > So this is my opinion: 464xlat is the currently the adopted approach = when: > - IPv4 addresses are (near) exhausted for the mass-market,=20 > - AND the provider network demands a translation technology (i.e. = incompatible with encaps.) > - AND at the client end, apps are not purged of IPv4 literals OR = tethering to an unknown OS is required For the first two bullet items and the second half of the third bullet = item, you only need NAT64+DNS64, not the whole of 464XLAT. You only put the CLAT on the handset for one thing, and one thing only: = dealing with applications that still use IPv4 literals, and it=E2=80=99s = not the only way to skin that cat, c.f. the approach used by Apple, = which uses a bump-in-the-stack at a higher layer of the operating system = instead of using the CLAT according to 464XLAT. It works fine in all the = cases anyone really cares about, and when the apps that still use IPv4 = literals are all retired from service, it won=E2=80=99 t be necessary = ever again. --james woodyatt > --Apple-Mail=_85B1F795-CB45-4314-986D-165D2D8628DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Sep 25, 2017, at = 04:56, Heatley,N,Nick,TQB R <nick.heatley@bt.com> wrote:

So this = is my opinion: 464xlat is the currently the adopted approach when:
- = IPv4 addresses are (near) exhausted for the mass-market, 
- = AND the provider network demands a translation technology (i.e. = incompatible with encaps.)
- AND at = the client end,  apps are not purged of IPv4 literals OR tethering = to an unknown OS is required

For the first two bullet = items and the second half of the third bullet item, you only need = NAT64+DNS64, not the whole of 464XLAT.

You only put the CLAT on the handset = for one thing, and one thing only: dealing with applications that still = use IPv4 literals, and it=E2=80=99s not the only way to skin that cat, = c.f. the approach used by Apple, which uses a bump-in-the-stack at a = higher layer of the operating system instead of using the CLAT according = to 464XLAT. It works fine in all the cases anyone really cares about, = and when the apps that still use IPv4 literals are all retired from = service, it won=E2=80=99 t be necessary ever again.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_85B1F795-CB45-4314-986D-165D2D8628DA-- From nobody Tue Sep 26 15:25:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C78E134499 for ; Tue, 26 Sep 2017 15:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnTUqhyz20GU for ; Tue, 26 Sep 2017 15:25:51 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F08011344B2 for ; Tue, 26 Sep 2017 15:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506464689; x=1507069489; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=9fe7/giHiNqXK0BxA1rYn5hfh Otislj/BZAqywEVbtg=; b=SOn2EzmUFNED++I0GRRhGt09dWrgL1T7d2GLcM64B N/7K8r8XfJ7c3tZnTfusUsA2/IE63grwphMKhdqYreUqWGiXxpV8oZWPq5uJmcJi riKllF8eLCocCkFQqP2+4A7BpiyovL/rnY8opE573Q74ZW6dAStigCwc25jXGszr rs= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=eYEDK8i2GKozfvWRwDGzGb1q3NXsofmEzlDRgfOVHJBKu4Ty6gp6qR/QmWiN A2QBWVYYhUzMEsfQiS5rlP8juo4gv5kHIbpqw8UrvrKCvzUy5Az2PCS22 tolz3mClTEGkEmuDaLntKjHcr8NhvlZjIXIL5cbBcnlP553FamcbuU=; X-MDAV-Processed: mail.consulintel.es, Wed, 27 Sep 2017 00:24:49 +0200 X-Spam-Processed: mail.consulintel.es, Wed, 27 Sep 2017 00:24:32 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005568960.msg for ; Wed, 27 Sep 2017 00:24:32 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170926:md50005568960::EKQz5GpA2LHe3k/i:00000VJB X-Return-Path: prvs=1442ddc204=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Wed, 27 Sep 2017 00:24:39 +0200 From: JORDI PALET MARTINEZ To: IPv6 Ops WG Message-ID: <0E294BEB-F115-4345-9715-4997A49F362C@consulintel.es> Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> In-Reply-To: <46045DAA-9096-43BA-A5FD-571232767726@google.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 22:25:53 -0000 Hi James, Basically, we could say that CLAT or the bump-in-the-stack, have the same r= esult. May be the difference is that CLAT can be also in CPEs, which I=E2=80=99m n= ot sure in the case of the bump-in-the-stack. However, I recall having asked some of the Apple folks working on the HE up= date (not sure if it was David or Tomy), and unless I misunderstood it, bum= p-in-the-stack doesn=E2=80=99t solve the tethering problem or something els= e (not working for literals or apps that use sock api). Again, I=E2=80=99m = not sure what was the issue, so I maybe expressing it incorrectly here, but= it will be interesting to clarify. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de james woodyatt Responder a: Fecha: martes, 26 de septiembre de 2017, 23:59 Para: "Heatley,N,Nick,TQB R" CC: IPv6 Ops WG Asunto: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard = instead of info) =20 On Sep 25, 2017, at 04:56, Heatley,N,Nick,TQB R w= rote: =20 =20 So this is my opinion: 464xlat is the currently the adopted approach wh= en: - IPv4 addresses are (near) exhausted for the mass-market,=20 - AND the provider network demands a translation technology (i.e. incom= patible with encaps.) - AND at the client end, apps are not purged of IPv4 literals OR tethe= ring to an unknown OS is required =20 =20 =20 =20 =20 For the first two bullet items and the second half of the third bullet = item, you only need NAT64+DNS64, not the whole of 464XLAT. =20 You only put the CLAT on the handset for one thing, and one thing only:= dealing with applications that still use IPv4 literals, and it=E2=80=99s n= ot the only way to skin that cat, c.f. the approach used by Apple, which us= es a bump-in-the-stack at a higher layer of the operating system instead of= using the CLAT according to 464XLAT. It works fine in all the cases anyone= really cares about, and when the apps that still use IPv4 literals are all= retired from service, it won=E2=80=99 t be necessary ever again. =20 --james woodyatt =20 =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue Sep 26 16:45:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07151344BA for ; Tue, 26 Sep 2017 16:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgElqTKouFSK for ; Tue, 26 Sep 2017 16:45:21 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BE11344BD for ; Tue, 26 Sep 2017 16:45:19 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id CEA8424B348; Tue, 26 Sep 2017 23:44:38 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 60342160052; Tue, 26 Sep 2017 23:44:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3F954160087; Tue, 26 Sep 2017 23:44:46 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xQo0rMeF8cfY; Tue, 26 Sep 2017 23:44:46 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B99D7160052; Tue, 26 Sep 2017 23:44:45 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 9E339881608F; Wed, 27 Sep 2017 09:44:40 +1000 (AEST) To: "Heatley,N,Nick,TQB R" Cc: IPv6 Ops WG From: Mark Andrews References: <20170925225028.DABE487DE1F6@rock.dv.isc.org> In-reply-to: Your message of "Tue, 26 Sep 2017 21:14:41 +0000." Date: Wed, 27 Sep 2017 09:44:40 +1000 Message-Id: <20170926234440.9E339881608F@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 23:45:23 -0000 In message , "Heatley,N,Nick,TQB R" writes: > Mark, What is this encapsulation solution? DS-Lite or MAP-E. > There is no running code for this on client devices, as far as I know - > regardless of whether we set various vendors' "junior developers" on > various parts of 3GPP core stack. Well there is running code for both DS-Lite and I'm pretty sure there is running code for MAP-E. Millions of broadband CPE routers do DS-Lite today. Given the rate phones get broken, which is the only reason Apple can get away with their aggressive deprecation strategy, if you deployed to day you would have a very large deployed base in 3 years. Remember the phone and operator can support NAT64/DNS64 and DS-Lite and/or MAP-E at the same time and the operator can see with a 100% accuracy which devices support DS-Lite or MAP-E as they advertise the fact that they do. This allows the operator to see when legacy NAT64/DNS64 population gets low enough for it to be switched off. Alternatively they can play APN games. > The alternative for an operator concerned with exhaustion of private > addressing, is to start running overlapping copies of the private address > ranges; for different customer segments or data centres or regions of the > network. > I am deadly serious about this, this is what operators have done. This > comes with or without IPv6, because if you have to run v4 why add in a > second address family? Because the operating cost get higher and higher. Because you still need to add more public IPv4 addresses as your customer base increases. > I guess you will be happy with this outcome because you believe NAT44 CGN > is superior to NAT64 CGN. But I think you are missing the point. > As others have stated, your perceived issues are all problems tied to > IPv4. I have a way that drives IPv6-only in my network. You have a way that puts costs on everyone else. It isn't the only way. DS-Lite is a IPv6-only solution all the way to the end device. MAP-E is a IPv6-only solution all the way to the end device. DS-Lite and MAP-E both support tethered devices. DS-Lite the device doesn't perform NAT on the IPv4 traffic. MAP-E the device needs to NAT the IPv4 traffic in the MAP address/port range. Mark > -----Original Message----- > From: Mark Andrews mailto:marka@isc.org > Sent: 25 September 2017 23:50 > To: Heatley,N,Nick,TQB R > Cc: IPv6 Ops WG > Subject: Re: v6ops 464xlat case study (was reclassify 464XLAT as standard > instead of info) > > > In message > .COM>, "Heatley,N,Nick,TQB R" writes: > > There are no arguments about architecture, there are only arguments > > about requirements. > > > > Here is my case study on NAT64/DNS64/464xlat. > > My requirements: > > > > * A solution for multi-million numbers of consumer nodes > (smartphones) > > * Mitigate IPv4 private and public address exhaustion > > * Encapsulation is not compatible with the core of 3GPP mobile > > networks only translation is Core & Service-LAN friendly. > > * Keep the provider network simple the overhead of two address > > families per customer in the mobile core is undesirable (as it doubles > > the control plane signalling) > > * 2 consumer usecases (on the same Internet APN) to consider > > on-device apps (smartphone+apps), tethering (smartphone+wifi-tethered > > device of an unknown OS) > > The problem with those requirement is that miss the most important one. > > Don't do damage. > > DNS64 does damage to the DNS. > NAT64 does damage to IPv6. > > DNS64/NAT64 and 464XLAT externalise the cost of not upgrading the billing > software to unwrap the encapsulation. > > > Thanks to esteemed Android developers putting 464xlat into Android, > > otherwise this wouldnt have happened. > > DNS64/NAT64 did not get put into production until 464xlat appeared on > > Android. > > I had zero IPv6 clients until 464xlat, IPv6 was insufficient without it. > > Prefix-share + 464xlat gave the tethering use-case support. > > The result has been rapid deployment, meeting all the requirements, we > > currently observe something like 70% of an IPv6-only devices traffic > > is > > IPv6-IPv6 based (and NAT-free). > > Just running the dual stack and a regular CGN rather than a NAT64 also > achieves that as IPv6 nodes prefer IPv6 over IPv4 as the transport. > > > I have a good amount of internal mobile core traffic that is IPv6-only > > (the combination of IPv6-only IMS APN for VoWifi and VoLTE, and this > > internet APN). > > > > So this is my opinion: 464xlat is the currently the adopted approach > when: > > - IPv4 addresses are (near) exhausted for the mass-market, > > - AND the provider network demands a translation technology (i.e. > > incompatible with encaps.) > > - AND at the client end, apps are not purged of IPv4 literals OR > > tethering to an unknown OS is required > > AND you are willing to be selfish and ignore the costs you are > externalising on everyone else. > > No network DEMANDS translation technology. You could have spent a little > bit of developer time and upgraded the billing software to understand > about encapsulation. Its a very simple concept. Even the most junior of > developers could have done this. > > > What is the point of seeking BCP for 464xlat? I am not entirely sure. > > It should not be to try to select Apple vs Android approaches, I want > > to see both approaches successful. > > Maybe it is to keep IETF relevant to the real world requirements and > > specific usecases. Id like to see IETF do more on usecases/solution > > context, BCPs can set the context, right? > > Maybe I can use it to help drive an IPv6-only 5G? > > Nick > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Sep 26 21:47:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC121321CB for ; Tue, 26 Sep 2017 21:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 QzCjCDHWQv5u for ; Tue, 26 Sep 2017 21:47:29 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC15B13422B for ; Tue, 26 Sep 2017 21:47:29 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id i6so8526280ywc.9 for ; Tue, 26 Sep 2017 21:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qyCqqeULnQwe59rIBYWGoaj4I5QjWm1GEetynSeGs7I=; b=O/TYk0NNAIY1bckJM2lBR0hZLfgdXF9fWcLcubIXku0VjtOubUhjz7HSi/P6zjboAP l3UsJgUr75V+2Dy1dEibspe8ijs8aCjVyiRLu7OGIVJC8ACeSS77xZgCyoAEDA3zwd53 8WUO7ml7Qs+Ese+B5HYn3v2e0HjuuCBPH5Pk6Qvx8PnCLGjwEEWcmPaiaqRhtxEQnNza hR6xMmh5ORmbCBmBOuZSodd6Q6IG6iYlScuPu5Jp0I9/+YvYlP1OuSUECg2d4sovAqda sPywvj1u1ynfulM6h+VvoU1kXVF57WUwWM/CGXuCuJKrQAgjf9nIcyNOaXTVSjykSMQQ NxPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qyCqqeULnQwe59rIBYWGoaj4I5QjWm1GEetynSeGs7I=; b=LwOjGywCxto9fUkuoDQ+u5Vx3c/PYAcq2lotN8Ym9RFj2GRVMLpN9Itf5dUJYDJQUz rsHU1kP53Yli6aYqUI9Ub+hh9CUp0XbCGhGLCSMODtq+zUSrDB3/T9KM21Hr/YVWpduc AAn5fRJ/syFo1YSf32EgQID6cZffFQVVMWhcxEX+WNtNq64nKFjtvcwOMrpc9Hu+r+zw yWEAX2g/g5qbl9TfMl9p44rNqmEMmvFOLC/9BK3UxMULacmvQQ+SxBXFc22iue4fhpn9 dJGMryIctRGn3mhEAOj6YHxVkGuoPjCM5PY5mECCmRWLiwRpAoi+clQ7lpgSzaa6HlIK VZGA== X-Gm-Message-State: AHPjjUjF899ATnfWvAttqCMVrlBqhF8a8Z8hs7Q11kiS562mH6f+Ltwf MMCZ62BvJGxg9Mu4Sjuru0HI51dZzHZOttqV6TAFhQ== X-Google-Smtp-Source: AOwi7QA/QB/n80tKhgNsZo3/uWweuoq14yIF/aqoYMbtpPNNVGffZnHG0jPIpARfZs5YWzX4bvFupcfQPk6+iXbezCk= X-Received: by 10.129.165.66 with SMTP id c63mr79195ywh.143.1506487648491; Tue, 26 Sep 2017 21:47:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Tue, 26 Sep 2017 21:47:07 -0700 (PDT) In-Reply-To: <46045DAA-9096-43BA-A5FD-571232767726@google.com> References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> From: Lorenzo Colitti Date: Wed, 27 Sep 2017 13:47:07 +0900 Message-ID: To: james woodyatt Cc: "Heatley, N, Nick, TQB R" , IPv6 Ops WG Content-Type: multipart/alternative; boundary="94eb2c12926a2689e0055a247d7b" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 04:47:33 -0000 --94eb2c12926a2689e0055a247d7b Content-Type: text/plain; charset="UTF-8" On Wed, Sep 27, 2017 at 6:59 AM, james woodyatt wrote: > c.f. the approach used by Apple, which uses a bump-in-the-stack at a > higher layer of the operating system instead of using the CLAT > My understanding is that the approach used by Apple requires that applications be modified. That's feasible given that Apple controls the app store, but it's not feasible for most OSes. --94eb2c12926a2689e0055a247d7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Sep 27, 2017 at 6:59 AM, james woodyatt <jhw@google.com> = wrote:
c.f. the approach used by Apple, which uses a bump-in-the-stack at a= higher layer of the operating system instead of using the CLAT
=

My understanding is that the approach used= by Apple requires that applications be modified. That's feasible given= that Apple controls the app store, but it's not feasible for most OSes= .
--94eb2c12926a2689e0055a247d7b-- From nobody Wed Sep 27 11:09:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC0B134ED5 for ; Wed, 27 Sep 2017 11:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuWSrkXU3HZm for ; Wed, 27 Sep 2017 11:08:58 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BF7134ED7 for ; Wed, 27 Sep 2017 11:08:58 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id x78so7630887pff.10 for ; Wed, 27 Sep 2017 11:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=Fj3KBUue1ANgZbE5qhG9gzklnXhtsvZ2vE65RDSi/Hs=; b=sPbKHyqWhjkRiC1Xzpa96sJfyXu1VkRMcfW0FRUkaK1FRUlEh8ombF4C/l505Etdcz Hw6LRMs1udLUE0Zy9n99tg6esNPa2YRByMjryjwrPvZGvwdFbCwDsCCj5Jh/bNV94hP0 tRTr3Q05PWaxq6OkaX7whw+0lDrhXORuPMkQQPkM0fo2AqRYjuZ3ekQOHGeNf6WHp8Jp 37i5rF7GU4IBRWRhTV1YOs7+ib1nc9z/dblEfY0zHxbs73jszTmHkWaJ4+KxuGZchf+j hjyMb7BbeK332rOqtjL0azg9PmGi4F1CIZ5BMsbxv41gZsa5yJlYMqR//nmFhZgRSm3D UpBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=Fj3KBUue1ANgZbE5qhG9gzklnXhtsvZ2vE65RDSi/Hs=; b=izy3kQjcNyNB/ok5z8+ec7HP+lxwVAzdJjHiA/f9tGcfJy7xJF0JbLYc0//gVx/qrS EA8nv4T89KAcOEbblaZnu8SmzUaNUWjATeMJAiS8VC34XQVsmWEeBCgSjVxjEq1kSMy6 ZRTB/XhA9W/xS9IrgGjZOTTshT4CkEOCxHbBuv6xl7R7PO5eEvX2t0c3y+0CqsbrhpvE NBROFIN1Q+arwNAu8ApZcE3nrXz3sCErM1Wh3HQAMGJjzRN5D0toKk/HSI0/H+glJEcZ kF3LQzIsm/Hf+JUfM2mzU0LruMIrj6FaWVcdO4IEVsGQaKauC0ehwIj6vXT8xjCnzrSv +L/Q== X-Gm-Message-State: AHPjjUj8yzWERS1285NvucRrrEoEJSnTDUsGvaRpeQlDKnvNf1iqYTmQ MDDf8Vig5C1TG3boXCOo40y0zjAqaYs= X-Google-Smtp-Source: AOwi7QDWN2SBPVT0t2T8mxQBgWQ8eUwWOKqWepL3D4ViHAdPWlKlMFdKlDjsJx+X0UFIS2av+NhmYQ== X-Received: by 10.99.95.204 with SMTP id t195mr2022404pgb.68.1506535737647; Wed, 27 Sep 2017 11:08:57 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:a888:544a:118b:9f49? ([2620:0:10e7:10:a888:544a:118b:9f49]) by smtp.gmail.com with ESMTPSA id i189sm11424564pfg.159.2017.09.27.11.08.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 11:08:57 -0700 (PDT) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_CE93BA02-5A2C-4AF9-A5B9-BA99BBE83EAF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 27 Sep 2017 11:08:55 -0700 References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> To: IPv6 Ops WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 18:09:00 -0000 --Apple-Mail=_CE93BA02-5A2C-4AF9-A5B9-BA99BBE83EAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 26, 2017, at 21:47, Lorenzo Colitti wrote: > On Wed, Sep 27, 2017 at 6:59 AM, james woodyatt > wrote: > c.f. the approach used by Apple, which uses a bump-in-the-stack at a = higher layer of the operating system instead of using the CLAT >=20 > My understanding is that the approach used by Apple requires that = applications be modified. That's feasible given that Apple controls the = app store, but it's not feasible for most OSes. You deleted the key phrase in my earlier message: >> ...in all the cases anyone really cares about=E2=80=A6 Nobody really cares about the apps that can=E2=80=99t (or won=E2=80=99t) = be updated. People pretend to care about those apps, but only because it provides a = convenient argument for doing what they were planning to do all along: = which is to try to keep IPv4 as viable as possible, for as long as = necessary, in the hopes of delaying the transition to IPv6 indefinitely. = Furthermore, we pretend to take their pose seriously, because otherwise = we=E2=80=99d have to stick our necks out and defend the IPv6 transition = on its technical merits: which we long ago debauched when we decided it = was perfectly okay for IPv6 to be basically nothing more than IPv4 with = bigger address numbers. --james woodyatt > --Apple-Mail=_CE93BA02-5A2C-4AF9-A5B9-BA99BBE83EAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Sep 26, 2017, at 21:47, Lorenzo Colitti <lorenzo@google.com> = wrote:
On Wed, Sep 27, 2017 at 6:59 AM, james woodyatt = <jhw@google.com> wrote:
c.f. the = approach used by Apple, which uses a bump-in-the-stack at a higher layer = of the operating system instead of using the = CLAT

My understanding is that the approach used by Apple requires = that applications be modified. That's feasible given that Apple controls = the app store, but it's not feasible for most = OSes.

You deleted the key phrase = in my earlier message:

...in all = the cases anyone really cares about=E2=80=A6

Nobody really cares about the apps that can=E2=80=99= t (or won=E2=80=99t) be updated.

People pretend to care about those apps, but only = because it provides a convenient argument for doing what they were = planning to do all along: which is to try to keep IPv4 as viable as = possible, for as long as necessary, in the hopes of delaying the = transition to IPv6 indefinitely. Furthermore, we pretend to take their = pose seriously, because otherwise we=E2=80=99d have to stick our necks = out and defend the IPv6 transition on its technical merits: which we = long ago debauched when we decided it was perfectly okay for IPv6 to be = basically nothing more than IPv4 with bigger address = numbers.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_CE93BA02-5A2C-4AF9-A5B9-BA99BBE83EAF-- From nobody Wed Sep 27 11:32:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33341342F5 for ; Wed, 27 Sep 2017 11:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZH7mZM--txhk for ; Wed, 27 Sep 2017 11:31:58 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6971A1330AE for ; Wed, 27 Sep 2017 11:31:57 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id o42so18029915wrb.3 for ; Wed, 27 Sep 2017 11:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=FnkBOfGQ7D5zwBwE8MxIwCs+9OutY5+Oqsuc/eDsoxw=; b=VO2fe24P5LukVVwTAfc1jdE8q/nNfSiHGBVKqoWYPjcLyMjUaCd9TNOooj3PPndPhH S1MrDzUjZ+4eKBWGOs82lUGOrjtGmQJhvrLSFEZORViYgTP0zhELzNrLklJ+UdZ+JNmF MPAvawWRhtbXUzJdk63F8BLfvE/XAJ1eLRamKZtcpPlk9lSCoGhZIjA3JQV7FRnbXoaH imhiWVkKrFGsKGjAo4abBUDzRk52dMq5qLbXXwkh+AnqEqZ3GQJDI9ra62xhEutKXXz7 qSks6n2/EjUZtwIP8qY3anMJhyQ1Vrq9TH4XswwcZD98xTR7BW4FrEaQFBqSck2pluez 3ACQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=FnkBOfGQ7D5zwBwE8MxIwCs+9OutY5+Oqsuc/eDsoxw=; b=Xpiegss4E0ASTDi3MRVfpfEuWQR86zZwhGeGIeNw81S3tOX0lYYJOp/7xCgBqAyREC iMJLKp1IY96RYENr7pwvrFah4MNUjOYz7pnkbfFQtopewdHxORgcVyCM+6NGEnciYTHo DRa1VBdpiN5ho1imOCkChkdMaU+tsV+YBO8aVk8C7TrALoaaKmhVs8Fb4Rtt/v7993pM NYYYvk/PiV+ZH28tFuD+EDP7Ldb39MQdsN+uyP0f01fMhAjQMFPcZz7oP9fkk682JKgm zJ/SrrWDl2UldzHO5t0IWPS16Bvulbl6Uw16DngK4D0L5OW+N8hCohLtnlZ3yBTW7KvX eeqQ== X-Gm-Message-State: AHPjjUhlsslm0/ruyl4Op3P/aceEpMjMYVeEosRalv1h8JxqCRHwzeI3 07KY3vL+t8CRC9crN1ESmdfiWV34 X-Google-Smtp-Source: AOwi7QAxleIuX0z+peLMgoYhubmQ/LucJpykZjcLw/bGfPXFNWdd5u1HXmghCl/bfTsOmCFczq1Zvw== X-Received: by 10.223.161.23 with SMTP id o23mr2444771wro.103.1506537115844; Wed, 27 Sep 2017 11:31:55 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1006? ([2600:8802:5600:e::1006]) by smtp.gmail.com with ESMTPSA id e77sm5012849wmi.29.2017.09.27.11.31.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 11:31:55 -0700 (PDT) From: Fred Baker Content-Type: multipart/alternative; boundary="Apple-Mail=_3D3BA431-8777-42BC-9278-2DA50F993BF7" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Message-Id: <2FEB5084-E312-497B-8923-6C4F90EDC9EB@gmail.com> References: To: v6ops list Date: Wed, 27 Sep 2017 11:31:51 -0700 X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: [v6ops] Fwd: Bounce action notification X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 18:32:01 -0000 --Apple-Mail=_3D3BA431-8777-42BC-9278-2DA50F993BF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Over the past few months, the chairs have seen quite a number of = messages like this. An inquiry to AMS (who manages IETF mailing lists) = tells us that this mostly has to do with corporate policies around = security, bouncing messages that lack a specific header, or have it, or = have it and it's wrong. Specifically: On Jul 18, 2017, at 7:22 AM, Glen wrote: > Not a glitch, and not anything that happened with the mailing lists. >=20 > Alas, this is a case where Yahoo had implemented a very hard-reject > policy against SPF violations, and I suspect what's happened is that > they've now "extended" that policy to their foreign servers. We've > known for quite some time that nobody @yahoo.com can effectively > participate in any mailing lists (anywhere) because of this - now it > seems that everyone at @yahoo.* is also affected by this. >=20 > = http://www.pcworld.com/article/2141120/yahoo-email-antispoofing-policy-bre= aks-mailing-lists.html > et al >=20 > There is not, alas, anything I can do. You might wish to warn - by > direct email - your @yahoo.* users about this; on the other hand, they > probably already know. They're going to need to move to Google, or > any other, more sane ISP that doesn't have the cavalier attitude Yahoo > does towards their users. Also, at least with IPv6 addresses, there is an additional issue with = PTR records (reverse DNS). Note that PTR records in IPv6 are = non-trivial; if I get a lookup for 2001:db8::1's name = (1.0.0.0.0.0.db8.2001@example.com), the name server pretty much needs to = ping the address (because it might be a temporary address or an address = in a prefix allocated to a host), and in the event of a response, = *create* a valid PTR record. There is little chance with SLAAC+privacy = for a PTR record to be predefined. Just looking at the population of the list, I think it's possible that = we have lost 250 people in 2017.=20 Now, if that's 250 people who now have different addresses or should = have dropped off the list and are now ignoring it, so be it. But If you = know of people who are wondering what's up with the list, this is a = place they should check. =20 > Begin forwarded message: >=20 > From: mailman@ietf.org > Subject: Bounce action notification > Date: September 27, 2017 at 11:10:39 AM PDT > To: v6ops-owner@ietf.org >=20 > This is a Mailman mailing list bounce action notice: >=20 > List: v6ops > Member: d.sturek@att.net > Action: Subscription disabled. > Reason: Excessive or fatal bounces. >=20 >=20 >=20 > The triggering bounce notice is attached below. >=20 > Questions? Contact the Mailman site administrator at mailman@ietf.org. >=20 > From: Mail Delivery Subsystem > Subject: Returned mail: see transcript for details > Date: September 27, 2017 at 11:09:04 AM PDT > To: >=20 >=20 > The original message was received at Wed, 27 Sep 2017 14:09:04 -0400 > from mail.ietf.org [4.31.198.44] >=20 > ----- The following addresses had permanent fatal errors ----- > > (reason: 554 5.7.9 Message not accepted for policy reasons. See = https://help.yahoo.com/kb/postmaster/SLN7253.html) >=20 > ----- Transcript of session follows ----- > ... while talking to mx-sbc.mail.am0.yahoodns.net.: >>>> DATA > <<< 554 5.7.9 Message not accepted for policy reasons. See = https://help.yahoo.com/kb/postmaster/SLN7253.html > 554 5.0.0 Service unavailable > Reporting-MTA: dns; alpd683.prodigy.net > Received-From-MTA: DNS; mail.ietf.org > Arrival-Date: Wed, 27 Sep 2017 14:09:04 -0400 >=20 > Final-Recipient: RFC822; d.sturek@att.net > Action: failed > Status: 5.0.0 > Remote-MTA: DNS; mx-sbc.mail.am0.yahoodns.net > Diagnostic-Code: SMTP; 554 5.7.9 Message not accepted for policy = reasons. See https://help.yahoo.com/kb/postmaster/SLN7253.html > Last-Attempt-Date: Wed, 27 Sep 2017 14:09:04 -0400 > X-Originating-IP: [4.31.198.44] > Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) > by alpd683.prodigy.net (8.14.4 IN altR5 TLS/8.14.4) with ESMTP = id v8RI92rC049329 > (version=3DTLSv1/SSLv3 cipher=3DDHE-RSA-AES256-SHA bits=3D256 = verify=3DNO) > for ; Wed, 27 Sep 2017 14:09:04 -0400 > Received: from ietfa.amsl.com (localhost [IPv6:::1]) > by ietfa.amsl.com (Postfix) with ESMTP id E724E134ED7; > Wed, 27 Sep 2017 11:09:01 -0700 (PDT) > DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple; d=3Dietf.org;= s=3Dietf1; > t=3D1506535742; bh=3D7O1wOFMrwUQIVvh8nID+3KjOu472rwlpAthFrAj+WV8=3D= ; > h=3DFrom:Date:References:To:In-Reply-To:Subject:List-Id: > = List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe; > = b=3Da7zJliNYLQ+x40LGqH74rJJ39oECp9t4irpT987QBFpmgqYfTpummrqFeOA+ZBgbI > = cJHsk8L7cQmI34TZDlOSxNbsmhwyJFoTFrioV7hrEknlTkbXqIt256a3laWkQVKvJW > 7tpmsz8YVkE6FOL5ngNwve+bUi0Gky+dxNGlH2RU=3D > X-Original-To: v6ops@ietfa.amsl.com > Delivered-To: v6ops@ietfa.amsl.com > Received: from localhost (localhost [127.0.0.1]) > by ietfa.amsl.com (Postfix) with ESMTP id EDC0B134ED5 > for ; Wed, 27 Sep 2017 11:08:59 -0700 (PDT) > X-Virus-Scanned: amavisd-new at amsl.com > X-Spam-Flag: NO > X-Spam-Score: -2 > X-Spam-Level:=20 > X-Spam-Status: No, score=3D-2 tagged_above=3D-999 required=3D5 = tests=3D[BAYES_00=3D-1.9,=20 > DKIM_SIGNED=3D0.1, DKIM_VALID=3D-0.1, DKIM_VALID_AU=3D-0.1, > HTML_MESSAGE=3D0.001, SPF_PASS=3D-0.001] autolearn=3Dham = autolearn_force=3Dno > Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=3Dpass = (2048-bit key) > header.d=3Dgoogle.com > Received: from mail.ietf.org ([4.31.198.44]) > by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) > with ESMTP id HuWSrkXU3HZm for ; > Wed, 27 Sep 2017 11:08:58 -0700 (PDT) > Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com > [IPv6:2607:f8b0:400e:c00::229]) > (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) > (No client certificate requested) > by ietfa.amsl.com (Postfix) with ESMTPS id B3BF7134ED7 > for ; Wed, 27 Sep 2017 11:08:58 -0700 (PDT) > Received: by mail-pf0-x229.google.com with SMTP id x78so7630887pff.10 > for ; Wed, 27 Sep 2017 11:08:58 -0700 (PDT) > DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; = d=3Dgoogle.com; s=3D20161025; > h=3Dfrom:mime-version:subject:date:references:to:in-reply-to:message-id;= > bh=3DFj3KBUue1ANgZbE5qhG9gzklnXhtsvZ2vE65RDSi/Hs=3D; > b=3DsPbKHyqWhjkRiC1Xzpa96sJfyXu1VkRMcfW0FRUkaK1FRUlEh8ombF4C/l505Etdcz > Hw6LRMs1udLUE0Zy9n99tg6esNPa2YRByMjryjwrPvZGvwdFbCwDsCCj5Jh/bNV94hP0 > tRTr3Q05PWaxq6OkaX7whw+0lDrhXORuPMkQQPkM0fo2AqRYjuZ3ekQOHGeNf6WHp8Jp > 37i5rF7GU4IBRWRhTV1YOs7+ib1nc9z/dblEfY0zHxbs73jszTmHkWaJ4+KxuGZchf+j > hjyMb7BbeK332rOqtjL0azg9PmGi4F1CIZ5BMsbxv41gZsa5yJlYMqR//nmFhZgRSm3D > UpBQ=3D=3D > X-Google-DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; > d=3D1e100.net; s=3D20161025; > h=3Dx-gm-message-state:from:mime-version:subject:date:references:to > :in-reply-to:message-id; > bh=3DFj3KBUue1ANgZbE5qhG9gzklnXhtsvZ2vE65RDSi/Hs=3D; > b=3Dizy3kQjcNyNB/ok5z8+ec7HP+lxwVAzdJjHiA/f9tGcfJy7xJF0JbLYc0//gVx/qrS > EA8nv4T89KAcOEbblaZnu8SmzUaNUWjATeMJAiS8VC34XQVsmWEeBCgSjVxjEq1kSMy6 > ZRTB/XhA9W/xS9IrgGjZOTTshT4CkEOCxHbBuv6xl7R7PO5eEvX2t0c3y+0CqsbrhpvE > NBROFIN1Q+arwNAu8ApZcE3nrXz3sCErM1Wh3HQAMGJjzRN5D0toKk/HSI0/H+glJEcZ > kF3LQzIsm/Hf+JUfM2mzU0LruMIrj6FaWVcdO4IEVsGQaKauC0ehwIj6vXT8xjCnzrSv > +L/Q=3D=3D > X-Gm-Message-State: = AHPjjUj8yzWERS1285NvucRrrEoEJSnTDUsGvaRpeQlDKnvNf1iqYTmQ > MDDf8Vig5C1TG3boXCOo40y0zjAqaYs=3D > X-Google-Smtp-Source: = AOwi7QDWN2SBPVT0t2T8mxQBgWQ8eUwWOKqWepL3D4ViHAdPWlKlMFdKlDjsJx+X0UFIS2av+N= hmYQ=3D=3D > X-Received: by 10.99.95.204 with SMTP id = t195mr2022404pgb.68.1506535737647; > Wed, 27 Sep 2017 11:08:57 -0700 (PDT) > Received: from ?IPv6:2620::10e7:10:a888:544a:118b:9f49? > ([2620:0:10e7:10:a888:544a:118b:9f49]) > by smtp.gmail.com with ESMTPSA id = i189sm11424564pfg.159.2017.09.27.11.08.56 > for > (version=3DTLS1_2 cipher=3DECDHE-RSA-AES128-GCM-SHA256 bits=3D128/128); > Wed, 27 Sep 2017 11:08:57 -0700 (PDT) > From: james woodyatt > Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) > Date: Wed, 27 Sep 2017 11:08:55 -0700 > References: = > <46045DAA-9096-43BA-A5FD-571232767726@google.com> > > To: IPv6 Ops WG > In-Reply-To: = > Message-Id: > X-Mailer: Apple Mail (2.3273) > Archived-At: = > Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as = standard > instead of info) > X-BeenThere: v6ops@ietf.org > X-Mailman-Version: 2.1.22 > Precedence: list > List-Id: v6ops discussion list > List-Unsubscribe: , > > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > > Content-Type: multipart/mixed; = boundary=3D"=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D43547268162911520= 07=3D=3D" > Errors-To: v6ops-bounces@ietf.org > Sender: "v6ops" >=20 >=20 --Apple-Mail=_3D3BA431-8777-42BC-9278-2DA50F993BF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Over = the past few months, the chairs have seen quite a number of messages = like this. An inquiry to AMS (who manages IETF mailing lists) tells us = that this mostly has to do with corporate policies around security, = bouncing messages that lack a specific header, or have it, or have it = and it's wrong. Specifically:

On Jul 18, = 2017, at 7:22 AM, Glen <glen@amsl.com> wrote:
Not a glitch, = and not anything that happened with the mailing lists.

Alas, this is a case where Yahoo had implemented a very = hard-reject
policy against SPF violations, and I suspect = what's happened is that
they've now "extended" that policy = to their foreign servers.  We've
known for quite some = time that nobody @yahoo.com can effectively
participate in = any mailing lists (anywhere) because of this - now it
seems = that everyone at @yahoo.* is also affected by this.

http://www.pcworld.com/article/2141120/yahoo-email-antispoofing= -policy-breaks-mailing-lists.html
et al

There is not, alas, anything I can do. =  You might wish to warn - by
direct email - your = @yahoo.* users about this; on the other hand, they
probably = already know.  They're going to need to move to Google, or
any other, more sane ISP that doesn't have the cavalier = attitude Yahoo
does towards their users.

Also, at least with IPv6 addresses, there is an additional = issue with PTR records (reverse DNS). Note that PTR records in IPv6 are = non-trivial; if I get a lookup for 2001:db8::1's name (1.0.0.0.0.0.db8.2001@example.com), the name server pretty = much needs to ping the address (because it might be a temporary address = or an address in a prefix allocated to a host), and in the event of a = response, *create* a valid PTR record. There is little chance with = SLAAC+privacy for a PTR record to be predefined.

Just looking at the population of the = list, I think it's possible that we have lost 250 people in = 2017. 

Now,= if that's 250 people who now have different addresses or should have = dropped off the list and are now ignoring it, so be it. But If you know = of people who are wondering what's up with the list, this is a place = they should check.
 


Begin forwarded message:

From: = mailman@ietf.org
Subject: = Bounce action = notification
Date: September 27, 2017 at 11:10:39 AM PDT
To: = v6ops-owner@ietf.org

This is a Mailman mailing list bounce action = notice:

   List: =       v6ops
=    Member:     d.sturek@att.net
   Action: =     Subscription disabled.
=    Reason:     Excessive or fatal = bounces.



The = triggering bounce notice is attached below.

Questions? Contact the Mailman site administrator at mailman@ietf.org.

From: Mail Delivery Subsystem <MAILER-DAEMON@alpd683.prodigy.net>
Subject: Returned mail: see transcript for details
Date: September 27, 2017 at 11:09:04 AM PDT
To: = <v6ops-bounces@ietf.org>


The original message was received at Wed, 27 = Sep 2017 14:09:04 -0400
from mail.ietf.org = [4.31.198.44]

  ----- The = following addresses had permanent fatal errors -----
<d.sturek@att.net>
   (reason: 554 5.7.9 Message not accepted = for policy reasons.  See https://help.yahoo.com/kb/postmaster/SLN7253.html)

  ----- Transcript of session = follows -----
... while talking to mx-sbc.mail.am0.yahoodns.net.:
DATA
<<< 554 5.7.9 = Message not accepted for policy reasons.  See https://help.yahoo.com/kb/postmaster/SLN7253.html
554 5.0.0 Service unavailable
Reporting-MTA: = dns; alpd683.prodigy.net
Received-From-MTA: DNS; = mail.ietf.org
Arrival-Date: Wed, 27 Sep 2017 14:09:04 -0400
Final-Recipient: RFC822; d.sturek@att.net
Action: failed
Status: 5.0.0
Remote-MTA: DNS; mx-sbc.mail.am0.yahoodns.net
Diagnostic-Code:= SMTP; 554 5.7.9 Message not accepted for policy reasons.  See https://help.yahoo.com/kb/postmaster/SLN7253.html
Last-Attempt-Date: Wed, 27 Sep 2017 14:09:04 -0400
X-Originating-IP: [4.31.198.44]
Received: from = mail.ietf.org (mail.ietf.org = [4.31.198.44])
by alpd683.prodigy.net = (8.14.4 IN altR5 TLS/8.14.4) with ESMTP id v8RI92rC049329
= (version=3DTLSv1/SSLv3 cipher=3DDHE-RSA-AES256-SHA bits=3D256 = verify=3DNO)
for <d.sturek@att.net>; = Wed, 27 Sep 2017 14:09:04 -0400
Received: from ietfa.amsl.com (localhost = [IPv6:::1])
by ietfa.amsl.com (Postfix) = with ESMTP id E724E134ED7;
Wed, 27 Sep 2017 11:09:01 -0700 = (PDT)
DKIM-Signature: v=3D1; a=3Drsa-sha256; = c=3Drelaxed/simple; d=3Dietf.org; s=3Dietf1;
= t=3D1506535742; = bh=3D7O1wOFMrwUQIVvh8nID+3KjOu472rwlpAthFrAj+WV8=3D;
= h=3DFrom:Date:References:To:In-Reply-To:Subject:List-Id:
= = List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe;
= b=3Da7zJliNYLQ+x40LGqH74rJJ39oECp9t4irpT987QBFpmgqYfTpummrqFeOA+ZBg= bI
= = cJHsk8L7cQmI34TZDlOSxNbsmhwyJFoTFrioV7hrEknlTkbXqIt256a3laWkQVKvJW
= 7tpmsz8YVkE6FOL5ngNwve+bUi0Gky+dxNGlH2RU=3D
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from = localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) = with ESMTP id EDC0B134ED5
for <v6ops@ietfa.amsl.com>; Wed, 27 Sep 2017 11:08:59 -0700 = (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=3D-2 = tagged_above=3D-999 required=3D5 tests=3D[BAYES_00=3D-1.9,
= DKIM_SIGNED=3D0.1, DKIM_VALID=3D-0.1, DKIM_VALID_AU=3D-0.1,
HTML_MESSAGE=3D0.001, SPF_PASS=3D-0.001] autolearn=3Dham = autolearn_force=3Dno
Authentication-Results: ietfa.amsl.com = (amavisd-new); dkim=3Dpass (2048-bit key)
header.d=3Dgoogle.com
Received: from mail.ietf.org ([4.31.198.44])
by localhost = (ietfa.amsl.com = [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id = HuWSrkXU3HZm for <v6ops@ietfa.amsl.com>;
Wed, 27 Sep 2017 = 11:08:58 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com
= [IPv6:2607:f8b0:400e:c00::229])
(using TLSv1.2 with = cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No = client certificate requested)
by ietfa.amsl.com (Postfix) = with ESMTPS id B3BF7134ED7
for <v6ops@ietf.org>; Wed, = 27 Sep 2017 11:08:58 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id = x78so7630887pff.10
for <v6ops@ietf.org>; Wed, = 27 Sep 2017 11:08:58 -0700 (PDT)
DKIM-Signature: v=3D1; = a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dgoogle.com; s=3D20161025;
= h=3Dfrom:mime-version:subject:date:references:to:in-reply-to:message-id; bh=3DFj3KBUue1ANgZbE5qhG9gzklnXhtsvZ2vE65RDSi/Hs=3D;
= b=3DsPbKHyqWhjkRiC1Xzpa96sJfyXu1VkRMcfW0FRUkaK1FRUlEh8ombF4C/l505Etdcz
= Hw6LRMs1udLUE0Zy9n99tg6esNPa2YRByMjryjwrPvZGvwdFbCwDsCCj5Jh/bNV94hP0
= tRTr3Q05PWaxq6OkaX7whw+0lDrhXORuPMkQQPkM0fo2AqRYjuZ3ekQOHGeNf6WHp8Jp
= 37i5rF7GU4IBRWRhTV1YOs7+ib1nc9z/dblEfY0zHxbs73jszTmHkWaJ4+KxuGZchf+j
= hjyMb7BbeK332rOqtjL0azg9PmGi4F1CIZ5BMsbxv41gZsa5yJlYMqR//nmFhZgRSm3D
UpBQ=3D=3D
X-Google-DKIM-Signature: v=3D1; = a=3Drsa-sha256; c=3Drelaxed/relaxed;
d=3D1e100.net; s=3D20161025;
= h=3Dx-gm-message-state:from:mime-version:subject:date:references:to
:in-reply-to:message-id;
= bh=3DFj3KBUue1ANgZbE5qhG9gzklnXhtsvZ2vE65RDSi/Hs=3D;
= b=3Dizy3kQjcNyNB/ok5z8+ec7HP+lxwVAzdJjHiA/f9tGcfJy7xJF0JbLYc0//gVx/qrS
= EA8nv4T89KAcOEbblaZnu8SmzUaNUWjATeMJAiS8VC34XQVsmWEeBCgSjVxjEq1kSMy6
= ZRTB/XhA9W/xS9IrgGjZOTTshT4CkEOCxHbBuv6xl7R7PO5eEvX2t0c3y+0CqsbrhpvE
= NBROFIN1Q+arwNAu8ApZcE3nrXz3sCErM1Wh3HQAMGJjzRN5D0toKk/HSI0/H+glJEcZ
= kF3LQzIsm/Hf+JUfM2mzU0LruMIrj6FaWVcdO4IEVsGQaKauC0ehwIj6vXT8xjCnzrSv
+L/Q=3D=3D
X-Gm-Message-State: = AHPjjUj8yzWERS1285NvucRrrEoEJSnTDUsGvaRpeQlDKnvNf1iqYTmQ
= MDDf8Vig5C1TG3boXCOo40y0zjAqaYs=3D
X-Google-Smtp-Source: = AOwi7QDWN2SBPVT0t2T8mxQBgWQ8eUwWOKqWepL3D4ViHAdPWlKlMFdKlDjsJx+X0UFIS2av+N= hmYQ=3D=3D
X-Received: by 10.99.95.204 with SMTP id = t195mr2022404pgb.68.1506535737647;
Wed, 27 Sep 2017 = 11:08:57 -0700 (PDT)
Received: from = ?IPv6:2620::10e7:10:a888:544a:118b:9f49?
= ([2620:0:10e7:10:a888:544a:118b:9f49])
by smtp.gmail.com with = ESMTPSA id i189sm11424564pfg.159.2017.09.27.11.08.56
for = <v6ops@ietf.org> (version=3DTLS1_2 cipher=3DECDHE-RSA-AES128-GCM-SHA256 = bits=3D128/128);
Wed, 27 Sep 2017 11:08:57 -0700 (PDT)
From: james woodyatt <jhw@google.com>
Mime-Version: 1.0 (Mac = OS X Mail 10.3 \(3273\))
Date: Wed, 27 Sep 2017 11:08:55 = -0700
References: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PR= OD.OUTLOOK.COM>
<46045DAA-9096-43BA-A5FD-571232767726@google.com>
<CAKD1Yr3vziaHfkR+hQ7QHXaz7QraKH2HLUVXUW63GpnOAj4JoQ@mail.gmail.= com>
To: IPv6 Ops WG <v6ops@ietf.org>
In-Reply-To: <CAKD1Yr3vziaHfkR+hQ7QHXaz7QraKH2HLUVXUW63GpnOAj4JoQ@mail.gmail.= com>
Message-Id: <E72C3FBE-57A4-4058-B9E5-F7392C9E9101@google.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: = <https://mailarchive.ietf.org/arch/msg/v6ops/olObdk7kM-E30JbTDGx= 83B-AgKQ>
Subject: Re: [v6ops] 464xlat case study = (was reclassify 464XLAT as standard
instead of info)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list = <v6ops.ietf.org>List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>,
<mailto:v6ops-request@ietf.org?subject=3Dunsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=3Dhelp>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>,
<mailto:v6ops-request@ietf.org?subject=3Dsubscribe>
Content-Type: multipart/mixed; = boundary=3D"=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D43547268162911520= 07=3D=3D"
Errors-To: v6ops-bounces@ietf.org
Sender: "v6ops" = <v6ops-bounces@ietf.org>


= --Apple-Mail=_3D3BA431-8777-42BC-9278-2DA50F993BF7-- From nobody Wed Sep 27 13:51:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F9A134455 for ; Wed, 27 Sep 2017 13:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btgroupcloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTQfYJlI-oX7 for ; Wed, 27 Sep 2017 13:51:13 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F701350AC for ; Wed, 27 Sep 2017 13:51:12 -0700 (PDT) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A005ED61.bt.com (10.187.98.10) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 27 Sep 2017 21:51:10 +0100 Received: from smtpe1.intersmtp.com (10.187.98.11) by EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 27 Sep 2017 21:51:10 +0100 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (213.199.154.209) by smtpe1.intersmtp.com (62.239.224.235) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 27 Sep 2017 21:51:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BTGroupCloud.onmicrosoft.com; s=selector1-bt-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O7yv35AZvuIi/rjF+A8QeVpxDPhoyFGqMebG8+QRWb4=; b=a5kBgHCOPNKdVu1jaYLS8xxSNk0u4/ULtWWsTYUbQLkYR5k9of0sEYV5AtCdtO8rZLcWT7YtsUQBjbTuYj1WK6klIfdflkbT+JO5obD1Q0GbKwxwNZoNQyBELhLh+9c35C0+9M2mO2qr8s+yxhhfCc3VBbcEROhLPb/sTq/bPu4= Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM (10.167.24.147) by LO1P123MB1090.GBRP123.PROD.OUTLOOK.COM (10.167.27.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 27 Sep 2017 20:51:04 +0000 Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) by LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) with mapi id 15.20.0077.016; Wed, 27 Sep 2017 20:51:04 +0000 From: "Heatley,N,Nick,TQB R" To: IPv6 Ops WG , james woodyatt Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) Thread-Index: AdM16ZBiVXxOrrPASdi8hSWu5DH/5gBKSg6AAA4804AAHACmgAAFqakl Date: Wed, 27 Sep 2017 20:51:03 +0000 Message-ID: References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.heatley@bt.com; x-originating-ip: [40.68.209.210] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LO1P123MB1090; 6:zkF7Afwo7KZUpKT/jsaOA6I1MKWaoXSNZb+oDlK/pxejqybTST+gBeJliFjLqhJusEtmegBjn7sH4RQTpfj9byYBa6c0UV6LMnF8cqhNrg5NXvc++J3mHqqJLWc9NgDBVdsfRCmbQpzCF0QTJ3dN1pNn7BZoVFCy+HwR7GbUTTqQkbVPfG97TrkdlPsLrvZ+9iv7Ac43fXqpeHBTs0NxWtR8eZiJj2hwaalkYJwsW6ojDIXaYRPkYJjs+4nLnqCWdGkWcdUnVyp7AAwsdWU9JAUkqjeivKop7ZypKdYS+4rJbdkfdYeVgaKWNXxxxG9Akd8ul59Y8AKcjKoEZHOSTA==; 5:KfEwvw1vSFxIITRsdlBzFACB7h8yc4HTGTd/4WGJ0Oa6BVme3nXqKKEuY6ftpcmhds9oGHSizx1NtQZtqQNBdtLaNaF1/P84Gg3IZgwFrIQ6OtCTno9t0dmA8B29Vv/jstcO3XrLyx5D7YHK+omlKw==; 24:uZguZ99M9cVBd8id7l729NP0snoe+v2m7AoPvx8852tRSV+NS04mQT/m+d5TAeQJtKvIRxgFWpC2SWLv5J9ultNSnNSeS2s6iy/jHRdldoI=; 7:CCqYVYO8k3Pwvt3BEZK3u7mgjM8Wanv2rMurnpt7L4Ofi+WOWr1NSId7WShWxRDcJZMf/83TD4kXEO6ZdjyCXaf2i3BdSb6EahTxbR4vgkUzrlr/73o9cU+F+B//76rjcwzJKSCADinHaWPVdDjfEgYqBvATxngpE42XmxfRlbgpNvdzqJBnl7L015JotKgxZZFwU6tXh42/pE8t+GPA3jHPiESpMe1gQJ5+PZvD1rc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 329be496-ed9e-4efb-e84a-08d505e977f5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:LO1P123MB1090; x-ms-traffictypediagnostic: LO1P123MB1090: x-antispam-2: 1 x-exchange-antispam-report-test: UriScan:(278428928389397)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(920507026)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:LO1P123MB1090; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:LO1P123MB1090; x-forefront-prvs: 04433051BF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39830400002)(346002)(24454002)(377454003)(189002)(199003)(33656002)(478600001)(97736004)(110136005)(53546010)(316002)(7696004)(93886005)(66066001)(45080400002)(2900100001)(5660300001)(86362001)(189998001)(54356999)(6246003)(105586002)(106356001)(102836003)(3846002)(6116002)(50986999)(76176999)(606006)(53936002)(6436002)(3660700001)(14454004)(3280700002)(101416001)(25786009)(55016002)(8936002)(54896002)(68736007)(74316002)(229853002)(236005)(6506006)(77096006)(2950100002)(9686003)(7736002)(8676002)(81166006)(6306002)(81156014)(2906002)(34040400001); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1P123MB1090; H:LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LO1P123MB0116805F9A18932E2D0694FEEA780LO1P123MB0116GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2017 20:51:03.9041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1P123MB1090 Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 20:51:16 -0000 --_000_LO1P123MB0116805F9A18932E2D0694FEEA780LO1P123MB0116GBRP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Stop speculating. A specific example: certain vpn clients, still in service, fail when tether= ed to a nat64/dns64 device. Typically, a customer is tethering their work m= achine to their personal handset. NAT64/DNS64 does not provide what the cli= ent needs and neither can the OS. Such client SW may be older but is still = in service, they are not yet end of support. Customers care if this breaks. So do I, this is doing harm. And no, they wo= n't revert to their corp IT dept. They know this relates to their provider. With 464xlat these usecases simply work. I have zero calls into customer services concerning devices with 464xlat. 464xlat is the reason why IPv6-only can work where the end OS is unknown. IPv6-only for the handset mass-market is the way to mitigate exhaustion. Get Outlook for Android ________________________________ From: v6ops on behalf of james woodyatt Sent: Wednesday, September 27, 2017 7:08:55 PM To: IPv6 Ops WG Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard= instead of info) On Sep 26, 2017, at 21:47, Lorenzo Colitti > wrote: On Wed, Sep 27, 2017 at 6:59 AM, james woodyatt > wrote: c.f. the approach used by Apple, which uses a bump-in-the-stack at a higher= layer of the operating system instead of using the CLAT My understanding is that the approach used by Apple requires that applicati= ons be modified. That's feasible given that Apple controls the app store, b= ut it's not feasible for most OSes. You deleted the key phrase in my earlier message: ...in all the cases anyone really cares about=85 Nobody really cares about the apps that can=92t (or won=92t) be updated. People pretend to care about those apps, but only because it provides a con= venient argument for doing what they were planning to do all along: which i= s to try to keep IPv4 as viable as possible, for as long as necessary, in t= he hopes of delaying the transition to IPv6 indefinitely. Furthermore, we p= retend to take their pose seriously, because otherwise we=92d have to stick= our necks out and defend the IPv6 transition on its technical merits: whic= h we long ago debauched when we decided it was perfectly okay for IPv6 to b= e basically nothing more than IPv4 with bigger address numbers. --james woodyatt > --_000_LO1P123MB0116805F9A18932E2D0694FEEA780LO1P123MB0116GBRP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Stop speculating.

A specific example: certain vpn clients, still in service, fail when tether= ed to a nat64/dns64 device. Typically, a customer is tethering their work m= achine to their personal handset. NAT64/DNS64 does not provide what the cli= ent needs and neither can the OS. Such client SW may be older but is still in service, they are not yet end = of support.

Customers care if this breaks. So do I, this is doing harm. And no, they wo= n't revert to their corp IT dept. They know this relates to their provider.=
With 464xlat these usecases simply work.
I have zero calls into customer services concerning devices with 464xlat.
464xlat is the reason why IPv6-only can work where the end OS is unknown.
IPv6-only for the handset mass-market is the way to mitigate exhaustion.

From: v6ops <v6ops-bounc= es@ietf.org> on behalf of james woodyatt <jhw@google.com>
Sent: Wednesday, September 27, 2017 7:08:55 PM
To: IPv6 Ops WG
Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as s= tandard instead of info)
 
On Sep 26, 2017, at 21:47, Lorenzo Colitti <lorenzo@google.com> wrote:
On Wed, Sep 27, 2017 at 6:59 AM, james woodyatt = <jhw@goog= le.com> wrote:
c.f. the approach used by Apple, which uses a bump-in-the-s= tack at a higher layer of the operating system instead of using the CLAT

My understanding is that the approach used by Apple require= s that applications be modified. That's feasible given that Apple controls = the app store, but it's not feasible for most OSes.

You deleted the key phrase in my earlier message:

...in all the cases anyone really care= s about=85

Nobody really cares about the apps that can=92t (or won=92t) be update= d.

People pretend to care about those apps, but only because it provides = a convenient argument for doing what they were planning to do all along: wh= ich is to try to keep IPv4 as viable as possible, for as long as necessary,= in the hopes of delaying the transition to IPv6 indefinitely. Furthermore, we pretend to take their pose seriously= , because otherwise we=92d have to stick our necks out and defend the IPv6 = transition on its technical merits: which we long ago debauched when we dec= ided it was perfectly okay for IPv6 to be basically nothing more than IPv4 with bigger address numbers.


--james woodyatt <jhw@google.com>



--_000_LO1P123MB0116805F9A18932E2D0694FEEA780LO1P123MB0116GBRP_-- From nobody Wed Sep 27 15:22:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E03513514B for ; Wed, 27 Sep 2017 15:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 eCcilofagL1O for ; Wed, 27 Sep 2017 15:22:25 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF59B13448E for ; Wed, 27 Sep 2017 15:22:25 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id b70so7947335pfl.8 for ; Wed, 27 Sep 2017 15:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NJxgq1Jwc+6pq5cBYUFkmTJUfmUp3TOt9GNguYYXejk=; b=B/RJT2bGRmgvYxuWPVATT/7bn2yQgeH232JkDNSXklCuQ344bKLe7CEw5LcsqRfQlA oUKiaMekfBxQrBoalWWCuhIE9iMVA2Sra9xRJJ0idJPVDs8T20SoKNbWy5cOFbWaibmM mUgwKSIDY1K8QZNtfwGp7hK3e/Jqva7YCmsTvTEo82LyPUVnfMX7aGT56S/Koav5Gs7k p5038CUuSdGmgqA6yqPoAogrLBgZVmXqxjy6cOZoduh5RFzmAef8vE11LKfw8ns+h8+k zE/gW5J2/sNaidsl9C0XavtmsmhUixuIiXgbOA3tSpI924a5lFKVf0bvK64/ggboJ+1E a5vw== 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=NJxgq1Jwc+6pq5cBYUFkmTJUfmUp3TOt9GNguYYXejk=; b=s5CsJocDWm6sqvYsVYjivdL1laOLi4681KPd06y/157RGZ8Vf0176cMD/HhfR+TlKN E/Xfzsq64twE6GZsfqRZkP23VY+HBV9j3LudR2q7WncmpvD3VP9+wyCr2H6ZzMnNwBJp sLrRMtP7HW/1uahLb+ZzBTh1yPIHpE/cUwAudDdpYF76G/7YRNcNPzGLiqWjK0Dh4/D4 2bRN/FZQa/+rBHHXeHXuf8pnRLOuEq27mGJtsF8aisyQnkrk1Za+NmZZM9Sb21Rh8eXK VKCXsdz4PfJqfUatcIHaeoAukxGV8Hold5oU570GgP5UmBqwXpuhZg7TUyz8LX1D2TF2 FdeQ== X-Gm-Message-State: AHPjjUiDG39BeLgPQV2AdgGfRUu+uVomapM3yBY/Y34wBcrVFTNM/4ef 8LY6KvbuYC78N/tAbNWUqEa6IFjGa7U= X-Google-Smtp-Source: AOwi7QBV46QjOt71DjYaUvPobuvhjEqahuqTQOjSxEIWEimT9QQH+z560RdlCNVhzEp+WUsswYzcyA== X-Received: by 10.99.171.9 with SMTP id p9mr2546863pgf.30.1506550945394; Wed, 27 Sep 2017 15:22:25 -0700 (PDT) Received: from ?IPv6:2620::10e7:10:a888:544a:118b:9f49? ([2620:0:10e7:10:a888:544a:118b:9f49]) by smtp.gmail.com with ESMTPSA id c82sm2140pfe.172.2017.09.27.15.22.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 15:22:24 -0700 (PDT) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_35C71371-8092-4057-8026-DA6211D30507" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 27 Sep 2017 15:22:23 -0700 In-Reply-To: Cc: IPv6 Ops WG To: "Heatley,N,Nick,TQB R" References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 22:22:27 -0000 --Apple-Mail=_35C71371-8092-4057-8026-DA6211D30507 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Sep 27, 2017, at 13:51, Heatley,N,Nick,TQB R = wrote: >=20 > certain vpn clients, still in service, fail - If those apps are still in service, then they can be updated. - If they can be updated for security, then they can be updated for = IPv6-only operation without 464XLAT. - If they won=E2=80=99t be updated, then keeping them in service is a = security problem. --james woodyatt > --Apple-Mail=_35C71371-8092-4057-8026-DA6211D30507 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Sep 27, 2017, at 13:51, Heatley,N,Nick,TQB R <nick.heatley@bt.com>= wrote:

certain vpn = clients, still in service, fail

- If those apps are = still in service, then they can be updated.
- If = they can be updated for security, then they can be updated for IPv6-only = operation without 464XLAT.
- If they won=E2=80=99t = be updated, then keeping them in service is a security = problem.


--james woodyatt <jhw@google.com>



= --Apple-Mail=_35C71371-8092-4057-8026-DA6211D30507-- From nobody Wed Sep 27 15:35:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CE3134498 for ; Wed, 27 Sep 2017 15:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwCyDwz-lb-S for ; Wed, 27 Sep 2017 15:35:01 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A91135151 for ; Wed, 27 Sep 2017 15:35:00 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id k10so3591487wrk.3 for ; Wed, 27 Sep 2017 15:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dKipHMEXVevbIZ/tKSP/O70IF8/zBybNE3Xm8fWBUVU=; b=rh29EFEewzzyIOYWf24Leplcvg6qzCK0KHijP1JtHLoaxonHUmhjHf3VtNrQ7rTcNU i+oKGpubFkUVYHC65fIdXh4+eRb3uBt+OMCXkH4oQDfkmci8+UvQRTklR8mb0ZCBZWM1 wnLOJ0j6XKZx3JPrTgTV3Ik19hlpUKsOMEGOo7698+ak4X95R6pNOzI0T0npruGl86p9 zGgWY6OumKiyX4DgqYYbP1BsXN186t1osGXR6Qy1yYI3npHuvjF8UV+8TFV9dIjnq56b 3gp4mhMMmeudTyV4FnnnXCDQ0GrhMUhs7oVLEq1zOD9XNpHWmmAL2A6ignYzao8t8itb /nDQ== 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=dKipHMEXVevbIZ/tKSP/O70IF8/zBybNE3Xm8fWBUVU=; b=P4U9bGdFhJ0AcpsqD7YVIp839cJanw3tzQW8Z4j78g9Oa/1HlXlFj8GxfH5hzKvQSi 0q3wTn51uj/xq2vG4USpNs0bt0EOdwYr5bR2u4XwcnpHhTc+3XIpz/YLBDNdeTWW32HE ViF1bK3eT+rQf0MYg0WpfC7FA6/QFj79ZN/r8uD23rddi/7Lelrs43NgQS4DP0Cxf3wY tAc/fCr3RVy5OjdtVpH20Qi3tO+8HQZsRlcPIXh4cQAaKismAs//Fz4lkzMyGVWiQn7n BfuE8AwZmq29Fs9LRGzqwh675Y8bRcfHrOWk3zNP49v9Oz7ZWEpniiBviuG7KG9VxXTW m+eQ== X-Gm-Message-State: AHPjjUh64SlWERvFXKV4AhM9PrqdiGpWBijEsT2fLVDFlei4VxAp+FiP ErMbdqinZZfZuSulsqheAck= X-Google-Smtp-Source: AOwi7QBiWrkkXZDbV+aeyQTHJM3iYPtn8MVCrWxL3vPOwNIbvdMHsI0HZpco2RJb71xACcChRzCupQ== X-Received: by 10.223.131.66 with SMTP id 60mr2552215wrd.171.1506551698925; Wed, 27 Sep 2017 15:34:58 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1639? ([2600:8802:5600:e::1639]) by smtp.gmail.com with ESMTPSA id 25sm61960wrv.8.2017.09.27.15.34.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 15:34:57 -0700 (PDT) From: Fred Baker Message-Id: <79987AA4-5C58-43D1-929C-377AC988057A@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_33DB8EFE-B368-478D-91ED-DBFF09B18037"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Date: Wed, 27 Sep 2017 15:34:54 -0700 In-Reply-To: Cc: "Heatley, N, Nick, TQB R" , IPv6 Ops WG To: james woodyatt References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 22:35:02 -0000 --Apple-Mail=_33DB8EFE-B368-478D-91ED-DBFF09B18037 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 27, 2017, at 3:22 PM, james woodyatt wrote: >=20 > - If those apps are still in service, then they can be updated. Perhaps, if someone has the right source and the authority to do so. We = ran into that with the Millennium bug; quite often, the COBOL program = containing the two bytes that needed to become four wasn't available to = be updated. The company it came from had long since gone out of business = or whatever, meaning that the application had to be redeveloped or = replaced. Even for products whose developers are among us, the = developers may not be interested in doing so. GPGTools on Apple machines = ran across that a couple of years ago. I have apps on my phone that I = have had to trade out for others because they suddenly didn't work and = weren't being updated on some given OS level. I would be careful with sweeping generalizations. They usually have = obvious and important exceptions. --Apple-Mail=_33DB8EFE-B368-478D-91ED-DBFF09B18037 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlnMJ44ACgkQEhdRnd2G P+DgwhAAiIfXfmNnLnGqdKycIOpxzcNHsno8rgb21rjfGp4Y34EOASbL5uxspuu1 DJuzx3sTzUux/OFHiunCpsy3D8+rJPjRh1wXOTrZCCXd+sDOYHSP7BBfmc4ZNikn 0rrr6gpT6Zg3+8UrZdYTIrribpXIbxQvHTYoz7l335XpPYp6+tJ5aHhygdd/gwTn htaTSMi1twv5w6braaAgHy2cw4U3tn0Z0VsGFer/dIrCZuVyl+3adRec1UhCmQZp R1pE4h+FKsMue/mZReK2vCofYlaPbyNiAJ0w66R5R1eMF0ilFPqmpIge8fzMFaR1 EOrBCGHohBeiyjqAy44WAc40S4RLN1rTTKCxV8aezBMqMtpVswVHQobIa6lxPUTi C++njj1pFDMBdrtutT+WvJZ4qMapCrF1yPvzwgOzd1eXDmTxGro0q3rF2ix0vzlR mlsHG93DSn0y2VaqDuL/6gl9ZQQrUHVIe1mrQsGyoslQdZqWsNKDWhB1BlrSENOr N8x8gGCcgAalCdZZLvNEdBTtnVAl2cYCmmDuLCN8b5rDdEmx+Z7yg3xhLhcV7+Mm 7sDCGl90yeNWxvLWHBPuWWJEkhBWMRYvHss3Eyh7oIqdOskggYQOOMkVRNMp+lxU LGIUV05CqduS1eFKutU39PvRKyCwyp9NXfrKUNQCrnC8AmFUYS0= =/vnd -----END PGP SIGNATURE----- --Apple-Mail=_33DB8EFE-B368-478D-91ED-DBFF09B18037-- From nobody Wed Sep 27 15:43:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761C5135160 for ; Wed, 27 Sep 2017 15:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mA9JmKF70jYw for ; Wed, 27 Sep 2017 15:43:28 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC3E13515F for ; Wed, 27 Sep 2017 15:43:28 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id CC34E2D4FA6; Wed, 27 Sep 2017 22:43:26 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B22DB10F7B3B4; Thu, 28 Sep 2017 00:43:23 +0200 (CEST) From: Ole Troan Message-Id: <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F7C77F1E-F1AC-4843-B425-452150726B38"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 28 Sep 2017 00:43:23 +0200 In-Reply-To: Cc: IPv6 Ops WG , james woodyatt To: "Heatley,N,Nick,TQB R" References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 22:43:30 -0000 --Apple-Mail=_F7C77F1E-F1AC-4843-B425-452150726B38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > A specific example: certain vpn clients, still in service, fail when = tethered to a nat64/dns64 device. Typically, a customer is tethering = their work machine to their personal handset. NAT64/DNS64 does not = provide what the client needs and neither can the OS. Such client SW may = be older but is still in service, they are not yet end of support. >=20 > Customers care if this breaks. So do I, this is doing harm. And no, = they won't revert to their corp IT dept. They know this relates to their = provider. > With 464xlat these usecases simply work. > I have zero calls into customer services concerning devices with = 464xlat. >=20 > 464xlat is the reason why IPv6-only can work where the end OS is = unknown. > IPv6-only for the handset mass-market is the way to mitigate = exhaustion. 464xlat is a mechanism to deliver IPv4 service across an IPv6 transport. Yes, it mitigates exhaustion. - By sharing a single IPv4 address among = more and more end-users. It's just like any other CGN, with the differences being that you need = CE support and you can disable IPv4 in the access network. MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much all do = the same. The main difference is where session state is kept. 464XLAT or more commonly deployed 44464XLAT is the worst of any = combination. It keeps sessions state both at the CE/CLAT and the = BR/PLAT. Building scalable stateful devices is hard and expensive. And = in the case of IPv4 sharing mechanisms unnecessary. Ole --Apple-Mail=_F7C77F1E-F1AC-4843-B425-452150726B38 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlnMKYsACgkQvtpYqJhC 33YYsg/+O7TYTkSMRt9N0/T/cyJDwUyQRlr6lOiPerIlIinxXHmf4mrp3dCqzk+7 XxbSmTGjaPC7KECt4/Ra/EQQv+j8ogrXSmN3F0zMADPv40etQCLHvieZGbsxlIrE OL0NyafVSgO+EylcXplLcst/KwlXvBaRhHyySoAINi9J8fiWVL5HWV5qc/jBXniD 8M4HFzyTLFtD+DbeFr6xeTsMxWGnmmddL0SlKNa7MsXqh9pHa7GalyesRejmNJoi glLm3YVnOBmjvpJVj5rY9yF5c9EY5rpS0bSsB5VE2cV5sheGir65jxP15pRizrgj lAlxbD21V8Ga3zOWMqnyaQgXNN3ZMp9MxWw8mQo2uLrO/FQMtI0CCUtStM9t1HdI usotNSFH9BXMxGnxMse7YpZuowgkum1bqsp7E4nhwhgp6OZ0C8TyJer0qdq7yMDs cjKg7TyI26MUXxJ0p50qA7sLV4fRalno2QZFMtrwr6OdQvvgplUm8SbWkllp/b3O 9632D13pkWyV7/uOSqGvis4vjO1Ben02f1EagvnT1kvjBx4jYK2DdT+xZ936v3Lp p3aXm574oQiYbMhBXufINwHI//otVoh8NCuV84OJS9fMsQoKXWBNjDWs4BspiKYn 4Rdx6591v84gSxFHQ8zyYTzfOWokEfGtiqgjWPxHDCJM5JmUgCE= =4kdP -----END PGP SIGNATURE----- --Apple-Mail=_F7C77F1E-F1AC-4843-B425-452150726B38-- From nobody Wed Sep 27 16:37:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E302913515A for ; Wed, 27 Sep 2017 16:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA7ISDa29QtA for ; Wed, 27 Sep 2017 16:37:30 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0272E135187 for ; Wed, 27 Sep 2017 16:37:29 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id u11so10427873ywh.7 for ; Wed, 27 Sep 2017 16:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RL+HXgy38zavVDx0CF1iB1SIK6U2W7EZ4jtoSbYhjPk=; b=BceEAqq1F0YRYmUAFVsSUgoC1Dka53Dy2LjTFMUp7g3f+4gN9mu2zS2vnXI/lAM37z bVk1A83VMYiKf1AW13cISWqF1Gl5oqKz8WnP0yx2D8LNMeWo+4IdwyeyJjzMUIPRnUrY X0xLeFG5BVk1TREK01tgUC17ZC88MFXNJZscJ4/yEib6PpIZR3PMsW/HrIhhJ8921RRX y8J2Zk8tcU6N3YdzkE/JPmMESxjv5SA2j6kAdu3lquEMFJSDNC8DUFzJokHIfGMEkKot zk2egPPrCNchZFXeI0xWAN8jOxmoTLmSnpOOVLyRzfs6O04FwEGObjtnY2WUako2eOWf CeMw== 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=RL+HXgy38zavVDx0CF1iB1SIK6U2W7EZ4jtoSbYhjPk=; b=W6JJts3/J02TX9/oTVl/Pr6sjOKxfrnh+94YCv9P7nVGR3q2SdqBYVKB9n01m1LdPX mAX5yS8wYULqjNpduqXBPob4sK/uD00Gs0I0pEMzuBQtHab1COfrj2mDVua/EOwvbX9A ZxtpOm/ebWBfQnJXbM8MMlol2p8GWxBgbL9uuBNMpZMu8l/8gSqsquBcYJ5GaEQ3HBJi m2xHtLzfdNcSsQqRKQBZPwfkhBLawyWz6OYWJdO3N/WxlT69RF7lGQDuAN0UjgY3mpJ1 Dp/yzHMARRULdhby3aAQrYkSYlLdnRQCzcH2lc0oiqwFIES3qWoHTOt+4759hg7qOTzu OxFQ== X-Gm-Message-State: AHPjjUiDpOuWOntivhBCATawisOWqltS5rg3Ci5ybMYf/QeRDCvYnWsd xBuRICiKBLQaaM+ZQ+7uJKGJtUyqo+gx9SstHbA= X-Google-Smtp-Source: AOwi7QAsGYN2A81Z5pbDERPgVQTnpRcG8MEpQCifuhlTFmL3iRuRZstjv3P2jqxwiMdvR7owqEGxwRAqeBeRlvajxdM= X-Received: by 10.13.239.2 with SMTP id y2mr2173000ywe.65.1506555449133; Wed, 27 Sep 2017 16:37:29 -0700 (PDT) MIME-Version: 1.0 References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> In-Reply-To: <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> From: Ca By Date: Wed, 27 Sep 2017 23:37:18 +0000 Message-ID: To: "Heatley, N, Nick, TQB R" , Ole Troan Cc: IPv6 Ops WG , james woodyatt Content-Type: multipart/alternative; boundary="94eb2c0350586155d6055a3446a5" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2017 23:37:33 -0000 --94eb2c0350586155d6055a3446a5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 27, 2017 at 3:43 PM Ole Troan wrote: > > A specific example: certain vpn clients, still in service, fail when > tethered to a nat64/dns64 device. Typically, a customer is tethering thei= r > work machine to their personal handset. NAT64/DNS64 does not provide what > the client needs and neither can the OS. Such client SW may be older but = is > still in service, they are not yet end of support. > > > > Customers care if this breaks. So do I, this is doing harm. And no, the= y > won't revert to their corp IT dept. They know this relates to their > provider. > > With 464xlat these usecases simply work. > > I have zero calls into customer services concerning devices with 464xla= t. > > > > 464xlat is the reason why IPv6-only can work where the end OS is unknow= n. > > IPv6-only for the handset mass-market is the way to mitigate exhaustion= . > > 464xlat is a mechanism to deliver IPv4 service across an IPv6 transport. > Yes, it mitigates exhaustion. - By sharing a single IPv4 address among > more and more end-users. > It's just like any other CGN, with the differences being that you need CE > support and you can disable IPv4 in the access network. > > MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much all do > the same. > The main difference is where session state is kept. > > 464XLAT or more commonly deployed 44464XLAT is the worst of any > combination. It keeps sessions state both at the CE/CLAT and the BR/PLAT. > Building scalable stateful devices is hard and expensive. And in the case > of IPv4 sharing mechanisms unnecessary. > > Ole Ole, Mark, and James =E2=80=94 always good to have the non-operator viewpoi= nt. Insightful observations as always. Nick has offered the =E2=80=9Chey we did 464xlat, it worked, no regrets=E2= =80=9D case study, also insightful. I am trying to stay out of this discussion about purity of one solution vs the other. I was happy to leave that discussion years ago and move on with real work. But i like helping people, so i can share some insight Slide 4 of a deck https://www.ietf.org/proceedings/98/slides/slides-98-maprg-measuring-trends= -in-ipv6-support-tommy-pauly-00.pdf The blue area is not one of constant growth. The lesson is that what James said does not fly with mobile subscribers that can change carriers. They want their =E2=80=9Cbroken=E2=80=9D apps. That said, i have it on good word= that blue blob is thriving now that we added some additional control points to allows people to use =E2=80=9Cbroken=E2=80=9D apps. Life is good. Another data point http://www.worldipv6launch.org/measurements/ As of today in the top 25, Numbers 7, 11, 17, 18 (i think), and 20 have deployed 464xlat. Pretty good real world stats moving real v6 packets for what Ole calls =E2=80=9Cthe worst=E2=80=9D and Mark calls =E2=80=9Csexy=E2= =80=9D. And, i will reinterate an important point Nick made. The majority of traffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And a sliver of traffic requires 464XLAT or 4464. Those numbers are all growing in the right direction, more e2e v6. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --94eb2c0350586155d6055a3446a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Sep 27,= 2017 at 3:43 PM Ole Troan <otroan@employees.org> wrote:
> A specific example: certain vpn clients, still in servi= ce, fail when tethered to a nat64/dns64 device. Typically, a customer is te= thering their work machine to their personal handset. NAT64/DNS64 does not = provide what the client needs and neither can the OS. Such client SW may be= older but is still in service, they are not yet end of support.
>
> Customers care if this breaks. So do I, this is doing harm. And no, th= ey won't revert to their corp IT dept. They know this relates to their = provider.
> With 464xlat these usecases simply work.
> I have zero calls into customer services concerning devices with 464xl= at.
>
> 464xlat is the reason why IPv6-only can work where the end OS is unkno= wn.
> IPv6-only for the handset mass-market is the way to mitigate exhaustio= n.

464xlat is a mechanism to deliver IPv4 service across an IPv6 transport. Yes, it mitigates exhaustion. - By sharing a single IPv4 address among more= and more end-users.
It's just like any other CGN, with the differences being that you need = CE support and you can disable IPv4 in the access network.

MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much all do the= same.
The main difference is where session state is kept.

464XLAT or more commonly deployed 44464XLAT is the worst of any combination= . It keeps sessions state both at the CE/CLAT and the BR/PLAT. Building sca= lable stateful devices is hard and expensive. And in the case of IPv4 shari= ng mechanisms unnecessary.

Ole

Ole, Mark, an= d James =E2=80=94 always good to have the non-operator viewpoint.=C2=A0 Ins= ightful observations as always.=C2=A0

Nick = has offered the =E2=80=9Chey we did 464xlat, it worked, no regrets=E2=80=9D= case study, also insightful.=C2=A0

I am trying to stay out of this discussion about purity of one = solution vs the other.=C2=A0 I was happy to leave that discussion years ago= and move on with real work.=C2=A0

But i like helping people, so i can share some insight=C2=A0

Slide 4 of a deck=C2=A0

The blue area is not one of constant growt= h.=C2=A0 The lesson is that what James said does not fly with mobile subscr= ibers that can change carriers.=C2=A0 They want their =E2=80=9Cbroken=E2=80= =9D apps. That said, i have it on good word that blue blob is =C2=A0thrivin= g now that we added some additional control points to allows people to use = =E2=80=9Cbroken=E2=80=9D apps.=C2=A0 Life is good.=C2=A0

Another data point
=

--94eb2c0350586155d6055a3446a5-- From nobody Wed Sep 27 17:28:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660D51351E9 for ; Wed, 27 Sep 2017 17:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nLfO2DGgeVR for ; Wed, 27 Sep 2017 17:28:56 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798591351E8 for ; Wed, 27 Sep 2017 17:28:56 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id B73EC24B140; Thu, 28 Sep 2017 00:27:09 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 34993160093; Thu, 28 Sep 2017 00:27:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 01164160091; Thu, 28 Sep 2017 00:27:17 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0_nJEYCPxq2Y; Thu, 28 Sep 2017 00:27:16 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 58CA1160090; Thu, 28 Sep 2017 00:27:16 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A92A2885F18B; Thu, 28 Sep 2017 10:27:12 +1000 (AEST) To: Ca By Cc: "Heatley, N, Nick, TQB R" , Ole Troan , james woodyatt , IPv6 Ops WG From: Mark Andrews References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> In-reply-to: Your message of "Wed, 27 Sep 2017 23:37:18 +0000." Date: Thu, 28 Sep 2017 10:27:12 +1000 Message-Id: <20170928002712.A92A2885F18B@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 00:28:58 -0000 In message , Ca By writes: > > On Wed, Sep 27, 2017 at 3:43 PM Ole Troan wrote: > > > > A specific example: certain vpn clients, still in service, fail when > > > tethered to a nat64/dns64 device. Typically, a customer is tethering > > > their work machine to their personal handset. NAT64/DNS64 does not > > > provide what the client needs and neither can the OS. Such client SW > > > may be older but is still in service, they are not yet end of support. > > > > > > Customers care if this breaks. So do I, this is doing harm. And no, > > > they won't revert to their corp IT dept. They know this relates to their > > > provider. > > > With 464xlat these usecases simply work. > > > I have zero calls into customer services concerning devices with > > > 464xlat. > > > > > > 464xlat is the reason why IPv6-only can work where the end OS is > > > unknown. IPv6-only for the handset mass-market is the way to mitigate > > > exhaustion. > > > > 464xlat is a mechanism to deliver IPv4 service across an IPv6 transport. > > Yes, it mitigates exhaustion. - By sharing a single IPv4 address among > > more and more end-users. > > It's just like any other CGN, with the differences being that you need > > CE support and you can disable IPv4 in the access network. > > > > MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much all do > > the same. > > The main difference is where session state is kept. > > > > 464XLAT or more commonly deployed 44464XLAT is the worst of any > > combination. It keeps sessions state both at the CE/CLAT and the > > BR/PLAT. > > Building scalable stateful devices is hard and expensive. And in the > > case of IPv4 sharing mechanisms unnecessary. > > > > Ole > > > Ole, Mark, and James — always good to have the non-operator viewpoint. > Insightful observations as always. > > Nick has offered the “hey we did 464xlat, it worked, no regrets” case > study, also insightful. > > I am trying to stay out of this discussion about purity of one solution vs > the other. I was happy to leave that discussion years ago and move on > with > real work. > > But i like helping people, so i can share some insight > > Slide 4 of a deck > > https://www.ietf.org/proceedings/98/slides/slides-98-maprg-measuring-trend > s-in-ipv6-support-tommy-pauly-00.pdf > > The blue area is not one of constant growth. The lesson is that what > James > said does not fly with mobile subscribers that can change carriers. They > want their “broken” apps. That said, i have it on good word that blue blob > is thriving now that we added some additional control points to allows > people to use “broken” apps. Life is good. > > Another data point > > http://www.worldipv6launch.org/measurements/ > > As of today in the top 25, Numbers 7, 11, 17, 18 (i think), and 20 have > deployed 464xlat. Pretty good real world stats moving real v6 packets for > what Ole calls “the worst” and Mark calls “sexy”. I said other people think it is "sexy". I'm with Ole, it is the worst of the solutions. It breaks DNSSEC as it depends on DNS64. Applications have to deal with "this connection may be NAT'd to IPv4" which impacts on those not using 464xlat or NAT64/DNS64. It requires application gateways on both ends. It requires complicated code on both end. > And, i will reinterate an important point Nick made. The majority of > traffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And a > sliver of traffic requires 464XLAT or 4464. Those numbers are all growing > in the right direction, more e2e v6. > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Sep 27 18:56:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B5913523F for ; Wed, 27 Sep 2017 18:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7naS2TLF1gv for ; Wed, 27 Sep 2017 18:56:56 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5F113232C for ; Wed, 27 Sep 2017 18:56:55 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id u11so64790ywh.7 for ; Wed, 27 Sep 2017 18:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2v3d6B4zQZt52Fctv3NbaUAHv+0wD5+ePfyolFQIZuQ=; b=Giv/H5+qCaIlddzFOi0yFSd22LWky17wCRCNrfU/sMsK7m4/QzjRZqT29pVI6qJ8O0 TGz8g4YNWZGNLlzFFaPbV0sSu4/j8C00RkwLTDD1zLx6bP8Lffvhc557B9JiN5rSJuOY mLlagr/sOXdxmu8oUidPtES6mfG7Xp1fpR+DpgAxb01cci7CiI254Q8c16gOmWGZ46Y6 1rAELk9i/el4G567WTqn+rJlYbytr30UYNTqfL8vcfvBC946Wgj5SDWkQsZCBR/cjGEh D4ijM3k8Fk/9Pl2oOmDAdzy4FDIJXJ2USPfg3HVWpllTricXBtt/kkBACw0RbsIVJTfa wfHQ== 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=2v3d6B4zQZt52Fctv3NbaUAHv+0wD5+ePfyolFQIZuQ=; b=fbb3S7cQdWafMH4/X8CZ5+7TUe8bFCjT3pKx4hYfjq4rafGzVyiA2dUQ84U+USzcAk SW20t/pINj3fUvNedLY4GyJrnSt9z+eNfVrVeekuSFMWEiKaXPVbzGUdhkWFLOrWTRTT H80cRMcCEIaxI9yjxRMP7/s2hPqHAjjDa/G9XgCWtS3+AQTaIVfqNN/M/iy0LDz2hKRE OcVRK437gaUQx6a12ARISvLAlD6waGhAgxBi5KMcZt//Z/qssztgW0/rxiL3A5Vd9IWE fPfzrFKAB3HWmW1O3eAyTxecCDJwx74iEqjlCYyeNyXYk8TdzYC+RAm/XeNmyVcCXI6h 9E+A== X-Gm-Message-State: AHPjjUi7sCVK2uL86ZCf+4mLnYxwPNCmDhL2SKBvXLIchD1whH6TwIB9 /KEUWGJLSNS+eWRJUDk74Yb6oIzKMcTJN/IIBks= X-Google-Smtp-Source: AOwi7QB6ACsy3BMnXkeJW5Z87wVz3Y6IUXhh/ec0xIV0+Ay+pOAqy5A5VVx+V3lDxRYt2hrfM0Hq6H2pjQ1tsT5hWZ8= X-Received: by 10.13.239.2 with SMTP id y2mr2383141ywe.65.1506563815029; Wed, 27 Sep 2017 18:56:55 -0700 (PDT) MIME-Version: 1.0 References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928002712.A92A2885F18B@rock.dv.isc.org> In-Reply-To: <20170928002712.A92A2885F18B@rock.dv.isc.org> From: Ca By Date: Thu, 28 Sep 2017 01:56:44 +0000 Message-ID: To: Mark Andrews Cc: "Heatley, N, Nick, TQB R" , IPv6 Ops WG , Ole Troan , james woodyatt Content-Type: multipart/alternative; boundary="94eb2c03505806bf0e055a3639d0" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 01:56:58 -0000 --94eb2c03505806bf0e055a3639d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 27, 2017 at 5:28 PM Mark Andrews wrote: > > In message < > CAD6AjGQdMFgv4727wHm41HmEyo2Z-PCabPHPSRSVwOi_rey7OQ@mail.gmail.com>, Ca > By writes: > > > > On Wed, Sep 27, 2017 at 3:43 PM Ole Troan wrote: > > > > > > A specific example: certain vpn clients, still in service, fail whe= n > > > > tethered to a nat64/dns64 device. Typically, a customer is tetherin= g > > > > their work machine to their personal handset. NAT64/DNS64 does not > > > > provide what the client needs and neither can the OS. Such client S= W > > > > may be older but is still in service, they are not yet end of > support. > > > > > > > > Customers care if this breaks. So do I, this is doing harm. And no, > > > > they won't revert to their corp IT dept. They know this relates to > their > > > > provider. > > > > With 464xlat these usecases simply work. > > > > I have zero calls into customer services concerning devices with > > > > 464xlat. > > > > > > > > 464xlat is the reason why IPv6-only can work where the end OS is > > > > unknown. IPv6-only for the handset mass-market is the way to mitiga= te > > > > exhaustion. > > > > > > 464xlat is a mechanism to deliver IPv4 service across an IPv6 > transport. > > > Yes, it mitigates exhaustion. - By sharing a single IPv4 address amon= g > > > more and more end-users. > > > It's just like any other CGN, with the differences being that you nee= d > > > CE support and you can disable IPv4 in the access network. > > > > > > MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much all = do > > > the same. > > > The main difference is where session state is kept. > > > > > > 464XLAT or more commonly deployed 44464XLAT is the worst of any > > > combination. It keeps sessions state both at the CE/CLAT and the > > > BR/PLAT. > > > Building scalable stateful devices is hard and expensive. And in the > > > case of IPv4 sharing mechanisms unnecessary. > > > > > > Ole > > > > > > Ole, Mark, and James =E2=80=94 always good to have the non-operator vie= wpoint. > > Insightful observations as always. > > > > Nick has offered the =E2=80=9Chey we did 464xlat, it worked, no regrets= =E2=80=9D case > > study, also insightful. > > > > I am trying to stay out of this discussion about purity of one solution > vs > > the other. I was happy to leave that discussion years ago and move on > > with > > real work. > > > > But i like helping people, so i can share some insight > > > > Slide 4 of a deck > > > > > https://www.ietf.org/proceedings/98/slides/slides-98-maprg-measuring-tren= d > > s-in-ipv6-support-tommy-pauly-00.pdf > > > > The blue area is not one of constant growth. The lesson is that what > > James > > said does not fly with mobile subscribers that can change carriers. Th= ey > > want their =E2=80=9Cbroken=E2=80=9D apps. That said, i have it on good = word that blue > blob > > is thriving now that we added some additional control points to allows > > people to use =E2=80=9Cbroken=E2=80=9D apps. Life is good. > > > > Another data point > > > > http://www.worldipv6launch.org/measurements/ > > > > As of today in the top 25, Numbers 7, 11, 17, 18 (i think), and 20 have > > deployed 464xlat. Pretty good real world stats moving real v6 packets > for > > what Ole calls =E2=80=9Cthe worst=E2=80=9D and Mark calls =E2=80=9Csexy= =E2=80=9D. > > I said other people think it is "sexy". I'm with Ole, it is the worst > of the solutions. Ethernet is also the worst. Token ring is much more elegant than ethernet too. And packet over sonet is much more industrial than ethernet. Yet the chaotic mess ethernet is ubiquitous. Why? Because people had a relatively good experience deploying it. > > It breaks DNSSEC as it depends on DNS64. > Applications have to deal with "this connection may be NAT'd to > IPv4" > which impacts on those not using 464xlat or NAT64/DNS64. > It requires application gateways on both ends. > It requires complicated code on both end. > > > And, i will reinterate an important point Nick made. The majority of > > traffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And = a > > sliver of traffic requires 464XLAT or 4464. Those numbers are all > growing > > in the right direction, more e2e v6. > > > > > > > > > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --94eb2c03505806bf0e055a3639d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Sep 27, 2017 = at 5:28 PM Mark Andrews <marka@isc.org<= /a>> wrote:

In message <CAD6AjGQdMFgv4727wHm41HmEyo2Z-P= CabPHPSRSVwOi_rey7OQ@mail.gmail.com>, Ca By writes:
>
> On Wed, Sep 27, 2017 at 3:43 PM Ole Troan <otroan@employees.org> wrote:
>
> > > A specific example: certain vpn clients, still in service, f= ail when
> > > tethered to a nat64/dns64 device. Typically, a customer is t= ethering
> > > their work machine to their personal handset. NAT64/DNS64 do= es not
> > > provide what the client needs and neither can the OS. Such c= lient SW
> > > may be older but is still in service, they are not yet end o= f support.
> > >
> > > Customers care if this breaks. So do I, this is doing harm. = And no,
> > > they won't revert to their corp IT dept. They know this = relates to their
> > > provider.
> > > With 464xlat these usecases simply work.
> > > I have zero calls into customer services concerning devices = with
> > > 464xlat.
> > >
> > > 464xlat is the reason why IPv6-only can work where the end O= S is
> > > unknown. IPv6-only for the handset mass-market is the way to= mitigate
> > > exhaustion.
> >
> > 464xlat is a mechanism to deliver IPv4 service across an IPv6 tra= nsport.
> > Yes, it mitigates exhaustion. - By sharing a single IPv4 address = among
> > more and more end-users.
> > It's just like any other CGN, with the differences being that= you need
> > CE support and you can disable IPv4 in the access network.
> >
> > MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much = all do
> > the same.
> > The main difference is where session state is kept.
> >
> > 464XLAT or more commonly deployed 44464XLAT is the worst of any > > combination. It keeps sessions state both at the CE/CLAT and the<= br> > > BR/PLAT.
> > Building scalable stateful devices is hard and expensive. And in = the
> > case of IPv4 sharing mechanisms unnecessary.
> >
> > Ole
>
>
> Ole, Mark, and James =E2=80=94 always good to have the non-operator vi= ewpoint.
> Insightful observations as always.
>
> Nick has offered the =E2=80=9Chey we did 464xlat, it worked, no regret= s=E2=80=9D case
> study, also insightful.
>
> I am trying to stay out of this discussion about purity of one solutio= n vs
> the other.=C2=A0 I was happy to leave that discussion years ago and mo= ve on
> with
> real work.
>
> But i like helping people, so i can share some insight
>
> Slide 4 of a deck
>
> https://www.ietf.org/= proceedings/98/slides/slides-98-maprg-measuring-trend
> s-in-ipv6-support-tommy-pauly-00.pdf
>
> The blue area is not one of constant growth.=C2=A0 The lesson is that = what
> James
> said does not fly with mobile subscribers that can change carriers.=C2= =A0 They
> want their =E2=80=9Cbroken=E2=80=9D apps. That said, i have it on good= word that blue blob
> is=C2=A0 thriving now that we added some additional control points to = allows
> people to use =E2=80=9Cbroken=E2=80=9D apps.=C2=A0 Life is good.
>
> Another data point
>
> http://www.worldipv6launch.org/measurements/ >
> As of today in the top 25, Numbers 7, 11, 17, 18 (i think), and 20 hav= e
> deployed 464xlat.=C2=A0 Pretty good real world stats moving real v6 pa= ckets for
> what Ole calls =E2=80=9Cthe worst=E2=80=9D and Mark calls =E2=80=9Csex= y=E2=80=9D.

I said other people think it is "sexy".=C2=A0 I'm with Ole, i= t is the worst
of the solutions.

Ethernet is also the worst.=C2=A0

Token ring is much more elegant than ethernet too.=C2=A0 And pac= ket over sonet is much more industrial than ethernet.=C2=A0

Yet the chaotic mess ethernet is ubiq= uitous.=C2=A0 Why?=C2=A0 Because people had a relatively good experience de= ploying it.=C2=A0



=C2=A0 =C2=A0 =C2=A0 =C2=A0 It breaks DNSSEC as it depends on DNS64.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Applications have to deal with "this conne= ction may be NAT'd to IPv4"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which impacts on those not using 464xlat or NAT= 64/DNS64.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 It requires application gateways on both ends.<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 It requires complicated code on both end.

> And, i will reinterate an important point Nick made. The majority of > traffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And= a
> sliver of traffic requires 464XLAT or 4464.=C2=A0 Those numbers are al= l growing
> in the right direction, more e2e v6.
>
>
>
>
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/v6ops=
> >
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0INTERNET: mark= a@isc.org
--94eb2c03505806bf0e055a3639d0-- From nobody Wed Sep 27 19:17:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A4E13525D for ; Wed, 27 Sep 2017 19:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 3pnhK7UFpcLv for ; Wed, 27 Sep 2017 19:17:29 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AF8E135259 for ; Wed, 27 Sep 2017 19:17:29 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id p10so84164ywh.8 for ; Wed, 27 Sep 2017 19:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8iqPmWvTYC6ubdyo2ZxPijcARscIR3rMA/U8PlRQRy8=; b=GP3NXMVI4J16EZ2GBqjoJ0luMMLkfj+21xkg1Kqok6kq1hTvfcx7ANfSjxi6puSTQ2 MPPOgM2+btIFQ/3SjxlAOKrVDWA69Qua0qsKT2mN6k2kJIhEG05jR7dDtXKoRXLf4gwA ggksHrtjOPeMVSWXIQuAfAmSie7uzh7j9weCUxQxwJ0aInzCv36Bs9qO4FVm0RQxpMEd rXnEEu7ijPr45a34Gf7X4iUq8m/WHh3maY3jbC7UnJRKJkwLOki9CsLm5GczdGGlHfRG fLrc8rdplVQyBjA70XyAkZYW87/R7zlZZGbkkIYmhZOMueIXApewTRebf4YjCfDhxb8/ TlVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8iqPmWvTYC6ubdyo2ZxPijcARscIR3rMA/U8PlRQRy8=; b=YqcqCMmyHqWYNglrPFtFtZkALZIr5S+egRreTF838LZIjvfpGWkdmXx6iBWcV8cq37 8WH43unT/b4iTeeq9FwPxHPiGg5C7Br07/CF8mFaW+4/FN0sdEjGvpq/yBkwzT5dtm1S 1lW3Hyg0LEvp9Yghsym7Ywd4noPPmafua8qsK+dtp7bLWmkeBZC05JffWKQQod2ZlL4T z+vGJZBylCMByKw0E/NXpCphEV0vx/dtCghRYAdAFbL2WeSOQ9dQcYXbhG5jAe5xW+oz ifesY+2QL78MX+YjLeNAiXxxxLzYi9Sa1kSSQkjdDMjm4I2lZ2V25GLOTZc1bayR/2os HU+w== X-Gm-Message-State: AHPjjUjmrPAQeREFhI5AI9QNh3doq1NhPDZX5/VcE6KtHumLgrUyCYB6 ZBsLobQtQ307bL6qS2k3PsbRvU/V6jFs2O7xgAIDug== X-Google-Smtp-Source: AOwi7QAmrrjlLeUxsA92yvzrryqWkEMdvOE2XopDmb6DUYdeE5af9Tel/fltGsnDRmEBSwVaXnUSeKdN6PcGioTKBF0= X-Received: by 10.37.91.69 with SMTP id p66mr2425136ybb.423.1506565047860; Wed, 27 Sep 2017 19:17:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Wed, 27 Sep 2017 19:17:04 -0700 (PDT) In-Reply-To: References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> From: Lorenzo Colitti Date: Thu, 28 Sep 2017 11:17:04 +0900 Message-ID: To: james woodyatt Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary="001a1140f45282e438055a36828f" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 02:17:30 -0000 --001a1140f45282e438055a36828f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 28, 2017 at 3:08 AM, james woodyatt wrote: > > My understanding is that the approach used by Apple requires that > applications be modified. That's feasible given that Apple controls the a= pp > store, but it's not feasible for most OSes. > > > You deleted the key phrase in my earlier message: > > ...in all the cases anyone really cares about=E2=80=A6 > > > Nobody really cares about the apps that can=E2=80=99t (or won=E2=80=99t) = be updated. > Those apps' users care. The Apple strategy only works if the OS vendor can make it clear to app developers that supporting IPv6 is a requirement in order to continue to run on the platform. That simply isn't feasible for most OSes. --001a1140f45282e438055a36828f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 28, 2017 at 3:08 AM, james woodyatt <jhw@google.com> = wrote:
<= div class=3D"gmail_extra">
My understanding = is that the approach used by Apple requires that applications be modified. = That's feasible given that Apple controls the app store, but it's n= ot feasible for most OSes.

You deleted the key phrase in= my earlier message:

...in all the cases anyone really cares about=E2=80= =A6

Nobody really cares about the a= pps that can=E2=80=99t (or won=E2=80=99t) be updated.

Those apps' users care. The Apple strategy only = works if the OS vendor can make it clear to app developers that supporting = IPv6 is a requirement in order to continue to run on the platform. That sim= ply isn't feasible for most OSes.
--001a1140f45282e438055a36828f-- From nobody Wed Sep 27 19:49:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB37135274 for ; Wed, 27 Sep 2017 19:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 J0lbi88rs7Qh for ; Wed, 27 Sep 2017 19:49:13 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67419135266 for ; Wed, 27 Sep 2017 19:49:13 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id q80so121172ywg.2 for ; Wed, 27 Sep 2017 19:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pkd80173K6YlV4R1SmVvjY/eskCkkbb2GIEDQ04OSvk=; b=FBWjOAwMPHAdz0+yoOrqgZJ25dPXQEeMQmDsoPV+Cbp4J+jgJfYvW2nvVjdrA6skHw cyVwbye4PGE9jGYyWDQr6tz7fiAgbcE3kZv5yIHJcQDAnYCpbVFhPBB+uS8ScHXVj2Wx TQJW5UE+qNtIWlL27/2jB37iffJm3idXy7WWu2i3vLS+OjHKwPQ/P/vVUftRukT77dSA EiNNJWcKHi5B46xRc96mXYphe6FhSnPUomOVdotCWqxUrg+pplPDxI3XEOrzLh7TqXRi 6NGGZ7wHVS/hWQlINC/kRmbYcDmRL08Es1S7pT2Dvb1Vsw0XFFjlxeUE2T2Wviwh6Gt7 9BLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pkd80173K6YlV4R1SmVvjY/eskCkkbb2GIEDQ04OSvk=; b=N2BjGbH1ArxaM75R3C5EXoDAcfRS8bg1uy1qbzpwyD7ut/As27qiuiVbGuGJJU05iA NXHtUTASITzAL9SLLgwfQqWdeY+Sy42DY0R6QtZZz7QmQtL34dc2OBZKMGKakzunFobZ jNn3bGd8LVOGWfvAm3PzBVnFlFjFwIJsx8b1qNCapkmpY9FPrtA1nz59BYISMJdTbs+9 tZladi/lHpMMzlM/ZthXkyGDSCHr3NhI5dvWo2TQzx9BQqUvWeSW7vIR4eVcopUSDVXz fTno3V2hB68U6fW+kpDspmr6ElF4X6aGUCmAEnzRC6IIvjXWPWoTX1KBumCmrJ1YBwb7 4VpA== X-Gm-Message-State: AHPjjUjzYTZEozHEUYgrU4+7N8FVBwaxyJy65Q759B8NSbaGh/TUhdx9 6OXk0R5/tocAVPLNhCnA73mXBvKtsVyXUnLH3knBHQ== X-Google-Smtp-Source: AOwi7QBz/5GzmZsXJqPI8tyDFrtTW58OewO3isbkH87Ho5nH+etiS8szaPes3tJ51dI+aKEqoFmqIOiNY3ba7hE5lvs= X-Received: by 10.37.16.193 with SMTP id 184mr2456522ybq.178.1506566952320; Wed, 27 Sep 2017 19:49:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Wed, 27 Sep 2017 19:48:51 -0700 (PDT) In-Reply-To: References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> From: Lorenzo Colitti Date: Thu, 28 Sep 2017 11:48:51 +0900 Message-ID: To: Ca By Cc: "Heatley, N, Nick, TQB R" , Ole Troan , james woodyatt , IPv6 Ops WG Content-Type: multipart/alternative; boundary="001a113eddba0687b3055a36f4c2" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 02:49:15 -0000 --001a113eddba0687b3055a36f4c2 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 28, 2017 at 8:37 AM, Ca By wrote: > And, i will reinterate an important point Nick made. The majority of > traffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And a > sliver of traffic requires 464XLAT or 4464. Those numbers are all growing > in the right direction, more e2e v6. > What he said. For many operators, the choice was between a) 60% (and growing) native IPv6 traffic, 30% NAT64 traffic, and 5% NAT464 traffic, and b) 100% NAT44 traffic. --001a113eddba0687b3055a36f4c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 28, 2017 at 8:37 AM, Ca By <cb.list6@gmail.com> wro= te:
And, i will reinterate an important point Nick mad= e. The majority of traffic goes e2e ipv6. A minority of traffic requires NA= T64/DNS64. And a sliver of traffic requires 464XLAT or 4464.=C2=A0 Those nu= mbers are all growing in the right direction, more e2e v6.=C2=A0

What= he said.=C2=A0For many operators, the ch= oice was between a) 60% (and growing) native IPv6 traffic, 30% NAT64 traffi= c, and 5% NAT464 traffic, and b) 100% NAT44 traffic.
--001a113eddba0687b3055a36f4c2-- From nobody Wed Sep 27 19:58:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFDB13527A for ; Wed, 27 Sep 2017 19:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ItZCMfdiDJiH for ; Wed, 27 Sep 2017 19:58:06 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D44135273 for ; Wed, 27 Sep 2017 19:58:06 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id u205so128128ywa.5 for ; Wed, 27 Sep 2017 19:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/k/3aadAV+vyJpmWg7lefqv/I+dzQxdzXsgDb0RBMfo=; b=H7FX2KWaezTg3gDrdncCzbrl/5Wxyn4P4UoD9HCN7XQ5/53EhaleqqLE7pGBiC6cY4 Jsc6FGuSsPtnM3bIcs7iB2NAnzh2sbeI2uQ/7lYzS/QgmiHWoPlfpvtsNB+jpcZblB4l F014PIh9Ql/1gjh3SaGIxEmd4QU1aLKURq4c1mR3v+hq4qwSb6LfiAp1Lscyc8VAXOUv gaGn6oVUd/z4nW9qiI7GzEj/3E7Xb/FlQhcOi8xr/Ox2PLvy9u8X1GKpnCIJPIREoFUv ND4dj8quUjDgNiqVLqiyW/DoFHgux+0DnAT6t0L7LKxPV6eim98K6r3l0zmdKOFwFWZF j1yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/k/3aadAV+vyJpmWg7lefqv/I+dzQxdzXsgDb0RBMfo=; b=YJ2WAO9OZjSi0kI4VIWsh53sOC1HBTOQyVUTC3Ia0jsQ+XFealOxiFjCk8+b/K87JX YX33BunXL4iX03cncmrGB0ayPKjk3ilICtV9inmuEqkhqVZsTTNuvsam+AhNs5jmSYKc m/cqswRbJt+9U8DIgopm4vMByY9ZlY35f45/xgkuudbgBLSh/ylvqbqBIqRxXNkA/jGC JqusvGDYQtVPQWq9tN6bKOAdymy26551ISQO7xTHGvkzNbZpZd617YnmB79bppqyhAW8 qCrDafsu/AGq5l8vH7WyxLvWNQxE/cWlwE1Xtd1sUGKKKHS35/tF7l1E6VlqQGYJeEjy tGjg== X-Gm-Message-State: AHPjjUgZ12RU07e+jT5YXKOtM5rZQm2GvsSxzRsUq2yICRu+pOf+Zr9i Rny0iEgZB/f8xYYsRpz1UJ06dUJ1pTnbeDZOdwXLNA== X-Google-Smtp-Source: AOwi7QC4GBcZkF9aEqJXe+ahB/ij5nvWME1slctf0OwOBitUlKZGWNoCvdpcx5xxAcRnyQZFmV47UePuzfwTay6lCK0= X-Received: by 10.129.116.69 with SMTP id p66mr2520072ywc.264.1506567485273; Wed, 27 Sep 2017 19:58:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Wed, 27 Sep 2017 19:57:44 -0700 (PDT) In-Reply-To: <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> From: Lorenzo Colitti Date: Thu, 28 Sep 2017 11:57:44 +0900 Message-ID: To: Ole Troan Cc: "Heatley, N, Nick, TQB R" , james woodyatt , IPv6 Ops WG Content-Type: multipart/alternative; boundary="001a1141aa08cac79b055a3713b3" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 02:58:07 -0000 --001a1141aa08cac79b055a3713b3 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 28, 2017 at 7:43 AM, Ole Troan wrote: > 464XLAT or more commonly deployed 44464XLAT is the worst of any > combination. It keeps sessions state both at the CE/CLAT and the BR/PLAT. > Building scalable stateful devices is hard and expensive. And in the case > of IPv4 sharing mechanisms unnecessary. > Many would feel that that's working as intended, and that the role of the technology is *not* to deliver the highest-possible quality IPv4 experience. The role of the technology is to *unblock IPv6-only* by providing *compatibility mode* IPv4 service. In practice that turns out to be a good incentive for app developers to upgrade to IPv6. That incentive is not present in dual-stack networks. --001a1141aa08cac79b055a3713b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 28, 2017 at 7:43 AM, Ole Troan <otroan@employees.org> wrote:
464XLAT or= more commonly deployed 44464XLAT is the worst of any combination. It keeps= sessions state both at the CE/CLAT and the BR/PLAT. Building scalable stat= eful devices is hard and expensive. And in the case of IPv4 sharing mechani= sms unnecessary.

Many would feel that t= hat's working as intended, and that the role of the technology is *not*= to deliver the highest-possible quality IPv4 experience. The role of the t= echnology is to *unblock IPv6-only* by providing=C2=A0=C2=A0*compatibility = mode* IPv4 service. In practice that turns out to be a good incentive for a= pp developers to upgrade to IPv6. That incentive is not present in dual-sta= ck networks.
--001a1141aa08cac79b055a3713b3-- From nobody Wed Sep 27 20:10:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0AB132F69 for ; Wed, 27 Sep 2017 20:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ7OSy7DuTAX for ; Wed, 27 Sep 2017 20:10:34 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE16413295C for ; Wed, 27 Sep 2017 20:10:34 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 6571134D85C; Thu, 28 Sep 2017 03:06:34 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 42BAA160081; Thu, 28 Sep 2017 03:06:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 17DAA160082; Thu, 28 Sep 2017 03:06:34 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YPMGXG3ZB9oJ; Thu, 28 Sep 2017 03:06:34 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 72171160081; Thu, 28 Sep 2017 03:06:33 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DD2D08867238; Thu, 28 Sep 2017 13:06:30 +1000 (AEST) To: Lorenzo Colitti Cc: Ca By , "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt From: Mark Andrews References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> In-reply-to: Your message of "Thu, 28 Sep 2017 11:48:51 +0900." Date: Thu, 28 Sep 2017 13:06:30 +1000 Message-Id: <20170928030630.DD2D08867238@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 03:10:36 -0000 In message , Lorenzo Colitti writes: > On Thu, Sep 28, 2017 at 8:37 AM, Ca By wrote: > > > And, i will reinterate an important point Nick made. The majority of > > traffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And a > > sliver of traffic requires 464XLAT or 4464. Those numbers are all growing > > in the right direction, more e2e v6. > > > > What he said. For many operators, the choice was between a) 60% (and > growing) native IPv6 traffic, 30% NAT64 traffic, and 5% NAT464 traffic, and > b) 100% NAT44 traffic. Garbage. At worst it would have been growing IPv6 traffic + dropping NAT44 traffic. THE OPERATORS ONLY HAD TO TURN ON DUAL STACK. Dual stack was being delivered by some operators before DNS64 and NAT64 even existed. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Sep 27 20:57:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B23913529F for ; Wed, 27 Sep 2017 20:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 k6TjGPzbcqcM for ; Wed, 27 Sep 2017 20:57:48 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61191321DE for ; Wed, 27 Sep 2017 20:57:48 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id i6so178333ywc.9 for ; Wed, 27 Sep 2017 20:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KfXqmjmrTo7XnNNpdyMKEjYvNchKz2f1P2F+yJaymn4=; b=hbSBovY9uCcou/AaMnH1SZXzPKLzEE4zRBr9vrsIkBJURCcCsKejWbnRRUbi/BTnfs daurjMQlOUm+B0S1p+LhdALSLm9caSkrH5xTjvjXYdetscPmn/7RrEUBQnC5FTnAS4AH f3rF9aVu509oQlrC8k7pWmBHDaFwGcN1qIMtBPKaR9Yw7rtemE8rvVooOGmuGdYaSeue cr6U1k0yFAfj04XkXgWSzpMkolFdk9de1v/GuCy5w8I97ZSX67/Gak/JGStcqOVCpZUq /oxPOJFIU3D0IcON7kYz6qI0I+LnJh3GqGxIhJVoNGRDj+x6osdr+wGLZpTwQ7WzDPuq onVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KfXqmjmrTo7XnNNpdyMKEjYvNchKz2f1P2F+yJaymn4=; b=QxQOOc9B8zt6r2Xgx1x6lWqEN5HlLNPdMc6IoE9YNhb0utlYXTbkkq0gZo+QQCcgNX gAgEx8hB3rp760qvzg4KqYTIPYqETU6rinUs3IpQaZ78sswN6KwCipZQKvvLPnVrS60v H+6uSP2yxMlH8XQmBYiq0wkXV+J6AJN+hgqISxVeq5j2WfeqRhcFLllFkedlbZhND205 lJiLWmFU14Er+HMgI7IxG4tVjIlPtDZrquxQ6ADXi8B6u7UasMV2r1PE6EbBFZuwX13z NdoO6HXF0pPUEP8Uzbb5NEweAPCXbX2pgebjm8yRmBErL9P2C7LSzLWaU4UIr1oc0Ar0 Yt/A== X-Gm-Message-State: AHPjjUgMNhMc4SPdXP0f+w0dl1HkQWMXmoywiGCvXAANJDklxG1BNBs1 lZ5QvsFBRGg3PD4qimYzNulgwe9Bmn64ll9k/dX83KGm+ps= X-Google-Smtp-Source: AOwi7QBoHJ9OaoTqmee7km5YXWnIUS+CWGD3Fi7c8BLuAWZRZRK9s01FU6tADmCitWX0u8vJT+meIuP3EOyTy/RdBEw= X-Received: by 10.129.165.66 with SMTP id c63mr2610257ywh.143.1506571067533; Wed, 27 Sep 2017 20:57:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.214.213 with HTTP; Wed, 27 Sep 2017 20:57:26 -0700 (PDT) In-Reply-To: <20170928030630.DD2D08867238@rock.dv.isc.org> References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> From: Lorenzo Colitti Date: Thu, 28 Sep 2017 12:57:26 +0900 Message-ID: To: Mark Andrews Cc: Ca By , "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt Content-Type: multipart/alternative; boundary="94eb2c12926a4fd925055a37e9f6" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 03:57:50 -0000 --94eb2c12926a4fd925055a37e9f6 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 28, 2017 at 12:06 PM, Mark Andrews wrote: > > What he said. For many operators, the choice was between a) 60% (and > > growing) native IPv6 traffic, 30% NAT64 traffic, and 5% NAT464 traffic, > and > > b) 100% NAT44 traffic. > > Garbage. At worst it would have been growing IPv6 traffic + dropping > NAT44 traffic. THE OPERATORS ONLY HAD TO TURN ON DUAL STACK. > I take it you're not aware that certain 3GPP network releases don't support dual-stack at all but do support IPv6-only. --94eb2c12926a4fd925055a37e9f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 28, 2017 at 12:06 PM, Mark Andrews <marka@isc.org> wrote= :
> What he said. For many operators, the choice was between a) 6= 0% (and
> growing) native IPv6 traffic, 30% NAT64 traffic, and 5% NAT464 traffic= , and
> b) 100% NAT44 traffic.

Garbage.=C2=A0 At worst it would have been growing IPv6 traffic= + dropping
NAT44 traffic.=C2=A0 THE OPERATORS ONLY HAD TO TURN ON DUAL STACK.

I take it you're not aware that certain 3GP= P network releases don't support dual-stack at all but do support IPv6-= only.
--94eb2c12926a4fd925055a37e9f6-- From nobody Wed Sep 27 21:08:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCDA1352AE for ; Wed, 27 Sep 2017 21:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etFKd-TzSQ-p for ; Wed, 27 Sep 2017 21:08:23 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDDDD1352AA for ; Wed, 27 Sep 2017 21:08:23 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id CA2DB34B9E1; Thu, 28 Sep 2017 04:08:19 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id ADFBE160081; Thu, 28 Sep 2017 04:08:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 93938160082; Thu, 28 Sep 2017 04:08:19 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JdQ7tyKX7YEU; Thu, 28 Sep 2017 04:08:19 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 17E1A160081; Thu, 28 Sep 2017 04:08:19 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 17EA78867885; Thu, 28 Sep 2017 14:08:17 +1000 (AEST) To: Ca By Cc: "Heatley, N, Nick, TQB R" , IPv6 Ops WG , Ole Troan , james woodyatt From: Mark Andrews References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928002712.A92A2885F18B@rock.dv.isc.org> In-reply-to: Your message of "Thu, 28 Sep 2017 01:56:44 +0000." Date: Thu, 28 Sep 2017 14:08:17 +1000 Message-Id: <20170928040817.17EA78867885@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 04:08:25 -0000 In message , Ca By writes: > On Wed, Sep 27, 2017 at 5:28 PM Mark Andrews wrote: > > > > > In message < > > CAD6AjGQdMFgv4727wHm41HmEyo2Z-PCabPHPSRSVwOi_rey7OQ@mail.gmail.com>, Ca > > By writes: > > > > > > On Wed, Sep 27, 2017 at 3:43 PM Ole Troan > wrote: > > > > > > > > A specific example: certain vpn clients, still in service, fail > when > > > > > tethered to a nat64/dns64 device. Typically, a customer is > tethering > > > > > their work machine to their personal handset. NAT64/DNS64 does not > > > > > provide what the client needs and neither can the OS. Such client > SW > > > > > may be older but is still in service, they are not yet end of > > support. > > > > > > > > > > Customers care if this breaks. So do I, this is doing harm. And > no, > > > > > they won't revert to their corp IT dept. They know this relates to > > their > > > > > provider. > > > > > With 464xlat these usecases simply work. > > > > > I have zero calls into customer services concerning devices with > > > > > 464xlat. > > > > > > > > > > 464xlat is the reason why IPv6-only can work where the end OS is > > > > > unknown. IPv6-only for the handset mass-market is the way to > mitigate > > > > > exhaustion. > > > > > > > > 464xlat is a mechanism to deliver IPv4 service across an IPv6 > > transport. > > > > Yes, it mitigates exhaustion. - By sharing a single IPv4 address > among > > > > more and more end-users. > > > > It's just like any other CGN, with the differences being that you > need > > > > CE support and you can disable IPv4 in the access network. > > > > > > > > MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much > all do > > > > the same. > > > > The main difference is where session state is kept. > > > > > > > > 464XLAT or more commonly deployed 44464XLAT is the worst of any > > > > combination. It keeps sessions state both at the CE/CLAT and the > > > > BR/PLAT. > > > > Building scalable stateful devices is hard and expensive. And in the > > > > case of IPv4 sharing mechanisms unnecessary. > > > > > > > > Ole > > > > > > > > > Ole, Mark, and James — always good to have the non-operator viewpoint. > > > Insightful observations as always. > > > > > > Nick has offered the “hey we did 464xlat, it worked, no regrets” case > > > study, also insightful. > > > > > > I am trying to stay out of this discussion about purity of one > solution > > vs > > > the other. I was happy to leave that discussion years ago and move on > > > with > > > real work. > > > > > > But i like helping people, so i can share some insight > > > > > > Slide 4 of a deck > > > > > > > > > https://www.ietf.org/proceedings/98/slides/slides-98-maprg-measuring-trend > > > s-in-ipv6-support-tommy-pauly-00.pdf > > > > > > The blue area is not one of constant growth. The lesson is that what > > > James > > > said does not fly with mobile subscribers that can change carriers. > They > > > want their “broken” apps. That said, i have it on good word that blue > > blob > > > is thriving now that we added some additional control points to > allows > > > people to use “broken” apps. Life is good. > > > > > > Another data point > > > > > > http://www.worldipv6launch.org/measurements/ > > > > > > As of today in the top 25, Numbers 7, 11, 17, 18 (i think), and 20 > have > > > deployed 464xlat. Pretty good real world stats moving real v6 packets > > for > > > what Ole calls “the worst” and Mark calls “sexy”. > > > > I said other people think it is "sexy". I'm with Ole, it is the worst > > of the solutions. > > > Ethernet is also the worst. > > Token ring is much more elegant than ethernet too. And packet over sonet > is much more industrial than ethernet. > > Yet the chaotic mess ethernet is ubiquitous. Why? Because people had a > relatively good experience deploying it. Last time I looked my using ethernet doesn't impact on your using some other layer 2 technology. DNS64/NAT64 impacts on those not using the technology. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Sep 27 22:15:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7781352CB for ; Wed, 27 Sep 2017 22:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr9jfY29oV9W for ; Wed, 27 Sep 2017 22:15:47 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC931326ED for ; Wed, 27 Sep 2017 22:15:47 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id r74so992901wme.5 for ; Wed, 27 Sep 2017 22:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HPvRE6UaS0XPfoVJ0EjWDXjkUb+wfwploV1W3OU4vks=; b=RsGFm0N7d/t/BV6xJVCNdUVt/B5bz0ItRKYRRn9Xd1+Kh/B5xgrxN3OEjE3BqwyFL+ d0jtkNsHjk6+fhBdxO0Yz36ZIdF8ozzvsXQJJY/PCKv6wq0lCj+jP5daPJb2vNLjQ5sS 2g9ZBD0k4D6j/ZFEDdmlmRn5wu7sNIDSWu69WGaiopmc0F32uYiZU2PJfFNibAONk7JO TZzSoFaA2Qhu8eXz7A7hfesMDKgM0RkfaZOpAzzWJMwr2zIrucswRf4cqxTYxqqEtG85 mqKRgP30SrC7UK17iyQ6E9mzHamUYZjIv5lnTVcHBbH0kSCRZZYpxJN6y+6QnyY8aAv0 5Juw== 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=HPvRE6UaS0XPfoVJ0EjWDXjkUb+wfwploV1W3OU4vks=; b=s/Ht0hzSj1U3uoWgkfRAMVTqNjdFmIURym4XuuRQtVNyl5xeM00L67OM/9hAIVDdeQ v9244eV9kNVtZzZcsjVB9Ltp62ivoku6I0fRESC41CZYiC/9U7TjtNbDxIVx9SzdN9rj k0n71ct4s0AULTFifmw4zxMbSNAUBljiF41lWBiG4FycOUZTk3I2Krr3Unp0K8g4gcd4 +gi8XKhw496rzosLNVaxN+jhxLsqpy5tHkZf2lx4q4cNGsaw8haAb+8RMMrBtnTCtpHa GYi28NLOJZpEFHr1ONEwF4oJRBSsMIKCewlHuZalOIQDdmy0E41ynh2Cvl/Z6yDv5uH/ 9owg== X-Gm-Message-State: AHPjjUiUhdVM8BCs7K9oDcITVX1H51xk252JbNxZrBQEJ9x0Ytgen0iI +92VHKDiXV8MCnI2wp8zxLw= X-Google-Smtp-Source: AOwi7QCHID1KLB1SF8M9xyY9WehUrNnBMMJDgsBvGjPHb/KvUjjl6l7PqNCCA5SlyrJbqoHS4PiYmA== X-Received: by 10.28.147.8 with SMTP id v8mr2244524wmd.104.1506575745778; Wed, 27 Sep 2017 22:15:45 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::13f1? ([2600:8802:5600:e::13f1]) by smtp.gmail.com with ESMTPSA id 193sm745655wmh.47.2017.09.27.22.15.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 22:15:44 -0700 (PDT) From: Fred Baker Message-Id: <0C14ACDC-DBDD-4D8C-BBBD-60CA8E0982A2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0479BD1E-CA6A-4381-881F-FD665D0341BB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Date: Wed, 27 Sep 2017 22:15:41 -0700 In-Reply-To: Cc: Ca By , "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt To: Lorenzo Colitti References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 05:15:49 -0000 --Apple-Mail=_0479BD1E-CA6A-4381-881F-FD665D0341BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 27, 2017, at 7:48 PM, Lorenzo Colitti = wrote: >=20 > On Thu, Sep 28, 2017 at 8:37 AM, Ca By wrote: > And, i will reinterate an important point Nick made. The majority of = traffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And a = sliver of traffic requires 464XLAT or 4464. Those numbers are all = growing in the right direction, more e2e v6. >=20 > What he said. For many operators, the choice was between a) 60% (and = growing) native IPv6 traffic, 30% NAT64 traffic, and 5% NAT464 traffic, = and b) 100% NAT44 traffic. And, of course, as IPv6 grows, the reason to translate it diminishes. Frankly, chair hat off, I'm happy enough seeing IPv6-only domains and = 464XLAT where it has to be. The thing for us to focus on right now, I = think, is enterprise deployment - at least at their front doors, their = web sites and their mail servers. The less folks need IPv4 to talk with = their business partners, the less the iron lungs are necessary. =46rom = my perspective, that problem eventually takes care of itself. Metcalf's = law: the value of a network is a function of the number of it's users. --Apple-Mail=_0479BD1E-CA6A-4381-881F-FD665D0341BB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlnMhX0ACgkQEhdRnd2G P+CfNRAAw8Qg/ezIQwsZuLfZJswvU7E1I14H/yEiHOS3NAI8k1FFAXVXLusn5mJL 4Cm3fYc3IFxsI8wIkDMsClMleHnIF/QvkABMTIuegQF03kZOwsbbpZgwkbufUtop mbElAmsmXcC3H37fNLoXvtMNnENaQX+9uINOfhct1FKhPLg39ibK8gnnzcNtjNFP TrFzvIZ3B00X8FY9JzVq8mL4Y4qgQpazNoRKa2evcfAqwAllgFmiG91dZKC45FuJ REWAED44NpcI3U7bEoBPUD2Cou6wnP11BKl0+rfxlsioQZ7EAgY/XO1oFMysWIxw g4Xy48+GQeX7iETWleTUVTCq/DqoD4ONl3tYDxBYJjnPVq5p92lOeH4p+EwWb9ND N8kMOs+2hUPYr9aNVw0uGjddmlmn8IVgtwpeNjlxyZVdjNl21qenpXyuYwzqYLm4 wigBZ5e7aDRlOqYL4t2vsAKXNeYiC6MUxkkO21HP635058QriD7leO1G52tSBtL3 HJ+N9hEJTKNfJw0diqAu97qOGhTxtPg5Gr65+j0qwJ3jf+Gokg6Ymt8vVoVbSe8V 68T244wz1rdVHsEA8zPODRko1x+SJTuEQ4yM/M+e/cEy8pwMLYMO/r0hmItf4jxQ VBh9h2i+YrthG8okgXJceW+HbdpoXknSld6A0Tugm4a4Uc0AUQ8= =BzW1 -----END PGP SIGNATURE----- --Apple-Mail=_0479BD1E-CA6A-4381-881F-FD665D0341BB-- From nobody Wed Sep 27 22:19:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1541352CC for ; Wed, 27 Sep 2017 22:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3g79O2R-wSFm for ; Wed, 27 Sep 2017 22:19:03 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1351326ED for ; Wed, 27 Sep 2017 22:19:02 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id m72so487553wmc.0 for ; Wed, 27 Sep 2017 22:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xoqpzdE0qP2DxUeeR7xVMQdQiAsDeR7kdDEj+ZJGGWc=; b=qqHHgokcR56/ymVczT0Ul6h3//iefGxgpzANMyzmn//1kTDYGAHfZ4Y+cRFDeeqvcv 2OwXS5o+Kil66ZaleCWtVvCwwIA9CsKuRXq8rlBu+zqhqd3FolHQ7tNM5AilF9sJ/qDJ cqq1UxjPBp9lrFjCafu+D9T+viANCDc57lN0NaQRqX6MvQjmJbFa3GFiNcRyPUt/M1pU tMSJxr3lZBX2Alj5sE8b7ehNPa1LTnoZQfm6MN1qTW3F3Bay1CGX9hjTxpJSX2TYtUhe pEq1RQRH6O2iQfEiqDDdHOR2BRpzFieDsNjmO7SQD3NLqCZVs2MwVWeRIP/VwQ0yquei rZhA== 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=xoqpzdE0qP2DxUeeR7xVMQdQiAsDeR7kdDEj+ZJGGWc=; b=V/0gMlwhlPEl1kyibt/MHDXgKn3uUBQdWob6SaYp3eqTSKKMvhXXDumZsq8sqEyDND F8BPSIqQ28P5sVwqM7CtCiJn53VtyNIBU00mCuJExZM1DidCTiY9sU/3giEKTB1Uxvzc 8qgAzJIDE3r+jKHY4J3nSZIULkXcc7VDw5I8ac2EJ5kPq7JJYK2sNC3GsDUp4zpajVuK zX0hVoQmSGZas6HdKRy5gC4/k2xZlm+cclhZ4jU/Y5oeJDzYCIrugaP04NiJIDvLjB95 c6mDbwzvfQdtAvL1F5VhCtVVm8xATRu3O43VCswm/HgFivMNGYCO1kyeouaXd/wDcHhP tQCg== X-Gm-Message-State: AHPjjUgUf1mwOMc9WCvv0h53vRtOpcxXNQuHxI30/+adiDTQ9lJnuoHn ZwM0u5iyoJ2hBY9txB/spME= X-Google-Smtp-Source: AOwi7QBdpM/DWLtcWooY7DrsOkL5b+JC+6qadvA+Hzb3yDxbow5oEZPvkhy8iF1gzRRsN9eMLnvBmQ== X-Received: by 10.28.5.141 with SMTP id 135mr1803272wmf.112.1506575941355; Wed, 27 Sep 2017 22:19:01 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::13f1? ([2600:8802:5600:e::13f1]) by smtp.gmail.com with ESMTPSA id e77sm710304wmi.29.2017.09.27.22.18.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 22:19:00 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1032B1BD-8B1D-45BA-BB3D-0771DE454583"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Date: Wed, 27 Sep 2017 22:18:56 -0700 In-Reply-To: <0C14ACDC-DBDD-4D8C-BBBD-60CA8E0982A2@gmail.com> Cc: Ca By , "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt , Lorenzo Colitti To: Mark Andrews References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <0C14ACDC-DBDD-4D8C-BBBD-60CA8E0982A2@gmail.com> X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 05:19:04 -0000 --Apple-Mail=_1032B1BD-8B1D-45BA-BB3D-0771DE454583 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 27, 2017, at 10:15 PM, Fred Baker = wrote: > I'm happy enough seeing IPv6-only domains and 464XLAT where it has to = be. Dual Stack was and to some extent is necessary. It's a lot easier to = deploy IPv6 in a working IPv4 network than to set up a green field. The = thing is: how long do you want to run IPv4 after you need it? If you're = going to translate IPv4 at the edge anyway, it doesn't matter so much = what you're translating from. You can simplify your own network now. --Apple-Mail=_1032B1BD-8B1D-45BA-BB3D-0771DE454583 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlnMhkAACgkQEhdRnd2G P+AkkBAAm9SqhKyj0Cz8dlUjG6npN5YzYgsIox2XEZ6zh7BPbOet4gpF0wnpsolV /Z0ZmZ7oBdV7kBDQQZOcqS+V9ZcYD42fUOepOmvRmJ/zEB2kxscJCEYYJiPa4MXm qyxL8QXh+e5LiV/Ordj15Xj1yBhhN1FofIHz22bWhsHZPv/5oXuAAY9FKeXAB8Pa KF/riTqdjq+YUZy+88PwKI4uS6vgyTx6gJiU/brXZ/XAFaz0Wyomov/GiLJTZSHG nAL1wdFabs0Uj9zvFvnzXw2N8sf8IJ+jFgOnf0OOXm0yiHT0ieZ+QYII+M2D+kT0 2ko8YqqlB2jR2JZxJELtv+9PDrahWh58t8GOdrzEo6mze0BwThaxRdOUlufoeVGM 2JPsh6Guz+aIlvIa8kT9/fLcOBREryMyluasyWj3kXWx3NkpxORZetD1egrgT7M1 vdmMXj3B6BPordDIcMKOl6VhpAJ8SXYQq0pqqsuq8Ecb1IkqkU4e3DuBBVO2M4/X g8yWqXyrRL2ITaRrzmeKUwQwiG1l5QHGhppcdrNS2qsioqn5rVxO7WHjCNjdjglY q4qql3CDTouIz14bhIBej14qYweAYxogjM0dcXP0GPECz7HtKduIaF8Y6RpXX1vU DVLkXxPBm38XFXZCfNUvTfVJ9qF6oEZL64H0KmKtbimh2a7+goc= =bvx0 -----END PGP SIGNATURE----- --Apple-Mail=_1032B1BD-8B1D-45BA-BB3D-0771DE454583-- From nobody Wed Sep 27 22:57:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA97134C4E for ; Wed, 27 Sep 2017 22:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYv19gk7l3t7 for ; Wed, 27 Sep 2017 22:57:09 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE6B1349D2 for ; Wed, 27 Sep 2017 22:57:08 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 710ADAF; Thu, 28 Sep 2017 07:57:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506578226; bh=rz3j8BT9N+R9PgMubVakbkWRQmVF17Dcn9WWA0UsFY4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ljmukzipPpnvilI1+uHRJPIX1wEsBPQeXGS7Peg6h6L2rYyV2jth3CBgAsUIEbnSC e/i+UriHIQKuq36i/miqNSksRxA6BrmPkXmj75qFxy5dx8pJPwJshfW/kEsxFJ/k/Z Nfv7CAlxRBGfsJbNyTGC46PhRqTOuPoZyjrWNTXc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 55A8E84; Thu, 28 Sep 2017 07:57:06 +0200 (CEST) Date: Thu, 28 Sep 2017 07:57:06 +0200 (CEST) From: Mikael Abrahamsson To: Mark Andrews cc: Lorenzo Colitti , "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt In-Reply-To: <20170928030630.DD2D08867238@rock.dv.isc.org> Message-ID: References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 05:57:11 -0000 On Thu, 28 Sep 2017, Mark Andrews wrote: > Garbage. At worst it would have been growing IPv6 traffic + dropping > NAT44 traffic. THE OPERATORS ONLY HAD TO TURN ON DUAL STACK. NAT64 and the other ipv4-over-ipv6 technologies have the advantage of allowing not having to deploy IPv4 at the edge with all that entails in form of BCP38 functions, routing protocols, addressing, CGN boxes traffic needs to be routed to, etc. Instead you can put your NAT64 machines whereever they fit best and don't have to worry about how to get your RFC1918 prefix traffic to it. Instead it's tunneled there. Less complexity. So while I sympathize your "breaks DNSSEC" objection, 464XLAT actually doesn't do that. DNS64 does. If all devices had 464XLAT then you wouldn't have to do DNS64 (apart from the well-known "prefix detection" zones. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Sep 27 23:23:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5288135133 for ; Wed, 27 Sep 2017 23:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc3c2iev8Hak for ; Wed, 27 Sep 2017 23:22:58 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D971321CB for ; Wed, 27 Sep 2017 23:22:58 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 4D0AB3499D0; Thu, 28 Sep 2017 06:22:55 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 12B12160081; Thu, 28 Sep 2017 06:22:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D8B1E160082; Thu, 28 Sep 2017 06:22:54 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TjA7oa4kTS22; Thu, 28 Sep 2017 06:22:54 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 5FF22160081; Thu, 28 Sep 2017 06:22:54 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DD352886ACEC; Thu, 28 Sep 2017 16:22:51 +1000 (AEST) To: Mikael Abrahamsson Cc: Lorenzo Colitti , "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt From: Mark Andrews References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> In-reply-to: Your message of "Thu, 28 Sep 2017 07:57:06 +0200." Date: Thu, 28 Sep 2017 16:22:51 +1000 Message-Id: <20170928062251.DD352886ACEC@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 06:23:00 -0000 In message , Mikael Abrah amsson writes: > On Thu, 28 Sep 2017, Mark Andrews wrote: > > > Garbage. At worst it would have been growing IPv6 traffic + dropping > > NAT44 traffic. THE OPERATORS ONLY HAD TO TURN ON DUAL STACK. > > NAT64 and the other ipv4-over-ipv6 technologies have the advantage of > allowing not having to deploy IPv4 at the edge with all that entails in > form of BCP38 functions, routing protocols, addressing, CGN boxes traffic > needs to be routed to, etc. Instead you can put your NAT64 machines > whereever they fit best and don't have to worry about how to get your > RFC1918 prefix traffic to it. Instead it's tunneled there. Less > complexity. And how does that relate to the statement I said garbage too? It doesn't. It wasn't A or B. It was A or B or C or D or E or F. I just presented a C to prove that A or B was a wrong description. I've got zero objections to IPv6-only access networks. I have objections to NAT64/DNS64 and 464XLAT as the technology to deliver IPv4 access over it. > So while I sympathize your "breaks DNSSEC" objection, 464XLAT actually > doesn't do that. DNS64 does. If all devices had 464XLAT then you wouldn't > have to do DNS64 (apart from the well-known "prefix detection" zones. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Sep 28 00:10:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342D7135338 for ; Thu, 28 Sep 2017 00:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZqvwsSIylHP for ; Thu, 28 Sep 2017 00:10:47 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CEF135333 for ; Thu, 28 Sep 2017 00:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506582645; x=1507187445; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=6Nr6XIOkb52Uhw7FiCgMqR5R+ QfiS8tSdApbKuggGsk=; b=NKhgC9luh9yAEGxyH3peMC2vjF2t2OnX4AWDtyCvs nuqFBPgm0X7QYQtwgqxaDmuFoVFnHajtulQ+GoucQwAmAL+4uPRbqCYQ3O99ffIz Jy+V8bcD3Vt1TfI/+m/lfvDYJ86yi8BYWN5kAzARM5OVaAK0DhxYWd/PhgmFQE8q 7w= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=AxgUfcYFITA2pr14g4oseILCviW0rWSvO96qSEEYIE6MQWD67zNTPNcoaflv 53E3RnmPVu+Tb0hrpKDNeg1dwZmDY++QqHGAgr0+vlA6+LKGnyYsGakF6 1EY8x2ajMgy/9d3wTlhgqgggZgPwXeEwq01+95MSrYAB1hYKsKDkgI=; X-MDAV-Processed: mail.consulintel.es, Thu, 28 Sep 2017 09:10:45 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 28 Sep 2017 09:10:44 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005570421.msg for ; Thu, 28 Sep 2017 09:10:44 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170928:md50005570421::BYolgcdSH1ZvZYkF:00003VHq X-Return-Path: prvs=14445c1049=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Thu, 28 Sep 2017 09:10:42 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <3376C47E-6565-4FC6-9D4A-E734F33E25AB@consulintel.es> Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 07:10:49 -0000 Even better =E2=80=A6 you can deploy 464XLAT with DNS64 aware DNS validator= s, so actually DNSSEC is not broken, so it is a matter of doing the things = correctly. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Responder a: Fecha: jueves, 28 de septiembre de 2017, 7:57 Para: Mark Andrews CC: "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt Asunto: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard = instead of info) On Thu, 28 Sep 2017, Mark Andrews wrote: =20 > Garbage. At worst it would have been growing IPv6 traffic + dropping > NAT44 traffic. THE OPERATORS ONLY HAD TO TURN ON DUAL STACK. =20 NAT64 and the other ipv4-over-ipv6 technologies have the advantage of= =20 allowing not having to deploy IPv4 at the edge with all that entails in= =20 form of BCP38 functions, routing protocols, addressing, CGN boxes traff= ic=20 needs to be routed to, etc. Instead you can put your NAT64 machines=20 whereever they fit best and don't have to worry about how to get your= =20 RFC1918 prefix traffic to it. Instead it's tunneled there. Less=20 complexity. =20 So while I sympathize your "breaks DNSSEC" objection, 464XLAT actually= =20 doesn't do that. DNS64 does. If all devices had 464XLAT then you wouldn= 't=20 have to do DNS64 (apart from the well-known "prefix detection" zones. =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Sep 28 00:27:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6D11353BD for ; Thu, 28 Sep 2017 00:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9AVBBoxvezRF for ; Thu, 28 Sep 2017 00:27:24 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50B813546D for ; Thu, 28 Sep 2017 00:23:55 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 007BC2D509E; Thu, 28 Sep 2017 07:23:53 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0790710F8A7C0; Thu, 28 Sep 2017 09:23:51 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AA7CED89-0EAC-42AC-A2B0-F00197EE4424"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 28 Sep 2017 09:23:50 +0200 In-Reply-To: Cc: Mark Andrews , "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt To: Mikael Abrahamsson References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 07:27:26 -0000 --Apple-Mail=_AA7CED89-0EAC-42AC-A2B0-F00197EE4424 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Garbage. At worst it would have been growing IPv6 traffic + dropping >> NAT44 traffic. THE OPERATORS ONLY HAD TO TURN ON DUAL STACK. >=20 > NAT64 and the other ipv4-over-ipv6 technologies have the advantage of = allowing not having to deploy IPv4 at the edge with all that entails in = form of BCP38 functions, routing protocols, addressing, CGN boxes = traffic needs to be routed to, etc. Instead you can put your NAT64 = machines whereever they fit best and don't have to worry about how to = get your RFC1918 prefix traffic to it. Instead it's tunneled there. Less = complexity. This discussion would benefit from us using terms with precision. NAT64 is not an IPv4 over IPv6 technology. NAT64 allows an IPv6 = application to speak to an IPv4 application. NAT64 + DNS64 has the issue of breaking DNS64, and forcing every IPv6 = application for eternity to be restricted in functionality to what an = IPv4 application can do. 464xlat, while reusing the NAT64 component on the network side (which is = just a CGN btw), offers shared IPv4 service. =46rom the "user" = perspective the '6' part really doesn't matter. It could be any form of = transport. >=20 > So while I sympathize your "breaks DNSSEC" objection, 464XLAT actually = doesn't do that. DNS64 does. If all devices had 464XLAT then you = wouldn't have to do DNS64 (apart from the well-known "prefix detection" = zones. I don't understand what you mean here. These are in my mind two = completely different use cases. NAT64+DNS64 solves the problem of an IPv6 application talking to an IPv4 = application (and we can argue if that should really be solved at all). = 464XLAT solves the problem, of IPv4 exhaustion by extending IPv4 to live = forever (sic!). (Yeah, that last one was meant to be a little = provocative, but We are currently in a state where 32 + 16 > 128 appears = true). Best regards, Ole --Apple-Mail=_AA7CED89-0EAC-42AC-A2B0-F00197EE4424 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlnMo4YACgkQvtpYqJhC 33Zi8A/9HXggwgqQXbbsNNlDyehOZxupiP/fjiEnpBeNvEo1LN0BF0aOGtFTarwm 13gHpFeRX80Rti1Wps2/RZ1uKawfUdYGyD2zBq5TRLnlcuP4vFrjxKrAd+d4NUEK G0jQI6zsYKiSjKINUr4I+ksUb2IMs/FwPUq+HMgIrtGNBlHV3xW7gyRKHxDL4JSO eI5Zvs9B7weDFWg6ah84qktXowwVz41n9aySuLYHLKC+rl6TUqQNQM1m0hWiTBkV WTkAxyff43ThTZFKFa6s3ftXRG+MDVSueNRHSpmPfpClwFjB/VSe3EiQo216PBJA g5NRaaMyhOEW6nbNePpSRoJotzhswL6m19FFHFshDOdJV4SoAbKV36ubL8Add4Aj 01y/Mk5jxQ2I3UDWqk0AbyiKXkpRs6E9Swzr9E54iyDawsLTlsM2hAjdCjXfRyls lcHdHItRbXoiPYJbKL9msFPzuDzIGr3fTj5z/qihz6ODwDHs0soMuw3HLCllTY2t 3VujSSsaOzs1mcPNV93h40KJ/qosKIjLNVUSk0P5+IXqFd0DX8mSWwdpnA/QELa4 e4IkSDC1DAg5qUvw9Ui9WOZNzecsGuUvJlWfdI/RZfRI2yVsLZ0dj7Jm7NwlWbP1 C7p1X22fD8HCWwwiN3DWiERDFp6VT1LDAG5x+jjmHnT1xWNBvFQ= =sRSy -----END PGP SIGNATURE----- --Apple-Mail=_AA7CED89-0EAC-42AC-A2B0-F00197EE4424-- From nobody Thu Sep 28 00:41:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E42A1353B4 for ; Thu, 28 Sep 2017 00:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFLKdV5fz2ml for ; Thu, 28 Sep 2017 00:41:37 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C30C1353CD for ; Thu, 28 Sep 2017 00:41:13 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id AE92424AE68; Thu, 28 Sep 2017 07:41:00 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 22DCF160090; Thu, 28 Sep 2017 07:41:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 05EC0160091; Thu, 28 Sep 2017 07:41:08 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id juYu6b-c7gM1; Thu, 28 Sep 2017 07:41:07 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9C575160090; Thu, 28 Sep 2017 07:41:07 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BCB99886E538; Thu, 28 Sep 2017 17:41:05 +1000 (AEST) To: Mikael Abrahamsson Cc: Lorenzo Colitti , "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt From: Mark Andrews References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> In-reply-to: Your message of "Thu, 28 Sep 2017 07:57:06 +0200." Date: Thu, 28 Sep 2017 17:41:05 +1000 Message-Id: <20170928074105.BCB99886E538@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 07:41:41 -0000 In message , Mikael Abrah amsson writes: > So while I sympathize your "breaks DNSSEC" objection, 464XLAT actually > doesn't do that. DNS64 does. If all devices had 464XLAT then you wouldn't > have to do DNS64 (apart from the well-known "prefix detection" zones. You do know the RFC 7050 doesn't work with DNSSEC validation enabled. RFC 7050 specifies CD=0. ipv4only.arpa/AAAA (CD=0) -> validating recursive server (or local validating cache) ipv4only.arpa/AAAA (CD=0) -> DNS64 server ipv4only.arpa/AAAA ANCOUNT>0 -> validating recursive server (or local validating cache) rejected as ipv4only.arpa is signed. SERVFAIL -> client Lets try with CD=1 ipv4only.arpa/AAAA (CD=1) -> validating recursive server (or local validating cache) ipv4only.arpa/AAAA (CD=1) -> DNS64 server (no synthesis as CD=1) ipv4only.arpa/AAAA ANCOUNT=0 -> validating recursive server (or local validating cache) ipv4only.arpa/AAAA ANCOUNT=0 -> client (no prefixea found) To get it to work the validating recursive server has to detect that prefix discover is occuring. Perform its own prefix discovery. Synthesis a prefix discover response. So yes 464XLAT does require DNSSEC to be broken. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Sep 28 00:58:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BCC1354F5 for ; Thu, 28 Sep 2017 00:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptRACVPs8v02 for ; Thu, 28 Sep 2017 00:58:27 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FE2135516 for ; Thu, 28 Sep 2017 00:58:17 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 16DC6AF; Thu, 28 Sep 2017 09:58:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506585495; bh=aavzwkpslDHP7I7gJFl0tEs+FFaJ83M7YX/4XraBLew=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=IvaInKKLbODFsGC35c8bIJMGE/fcxSDjfGhRtXSdgZFrqtvM+SRgSGrptH+Zb9eDP 9bbykbFHwJjBKRFc5Q17trnHclTkPrSgP+9cUIGxjmrlorRACYKmoFtlBeEUnny6qv Iue5pAnJYDhH7zMiaOcZek6RM5TCJV+9eoP+NdeE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0056F84; Thu, 28 Sep 2017 09:58:14 +0200 (CEST) Date: Thu, 28 Sep 2017 09:58:14 +0200 (CEST) From: Mikael Abrahamsson To: Mark Andrews cc: IPv6 Ops WG In-Reply-To: <20170928074105.BCB99886E538@rock.dv.isc.org> Message-ID: References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 07:58:29 -0000 On Thu, 28 Sep 2017, Mark Andrews wrote: > You do know the RFC 7050 doesn't work with DNSSEC validation enabled. > RFC 7050 specifies CD=0. Correct. I don't get your point. This is the local resolver on the device trying to figure out where the NAT64 prefix is. Of course it can't do validation on this specific query. We all know DNS64+NAT64(+464XLAT) isn't optimal, but neither is your suggestion to "just run dual stack". -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 28 01:06:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DD913555E for ; Thu, 28 Sep 2017 01:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AzbA5iTWU87 for ; Thu, 28 Sep 2017 01:05:58 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 260D2135562 for ; Thu, 28 Sep 2017 01:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1506585844; x=1507190644; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=yKXkvYSjG2xdgHW8oii1o9VbB w9cGWNv+hBQJJmqHkI=; b=Hn48cxpFIVqDWq0DAikO3EU2hlNuCZeH+GDX3B643 MMNpKfMmjk+eJKR3bcH7aoO1cQvtNuR2/gnEvLIrG1DTVj6uJYvJdSU5ivczjhg5 qD3CRVckvE4JWoTU+MH2Ncsj2L7BMDU833ENZNS6FcYrc/iFZdMEze+iFC7KGimx uk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=difA0lhvM5Y0TyMSPslpl5W7Y51eo7zGL0Y0ZGUN1M3U8hnRCHC9D7XeI+IH m8hBr3Z4bznjB2ZMQYEi1ckaTaTLGx+0QEe7AALy27lUDlSfIfG8/DKoC 9R6hd62sacVBUZvP9OpSVO5QQ5Ajpc7mcSmpm4B9y62T3amF4iyS7U=; X-MDAV-Processed: mail.consulintel.es, Thu, 28 Sep 2017 10:04:04 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 28 Sep 2017 10:04:03 +0200 Received: from [10.10.10.135] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005570486.msg for ; Thu, 28 Sep 2017 10:04:03 +0200 X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0) X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:170928:md50005570486::tAKFKfTZRgkzV8Tg:00003JjI X-Return-Path: prvs=14445c1049=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Thu, 28 Sep 2017 10:04:03 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <911FED7C-63A7-4F55-A3FE-F97B492E4E82@consulintel.es> Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> In-Reply-To: <20170928074105.BCB99886E538@rock.dv.isc.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 08:06:00 -0000 You can have a DNS validator, aware of DNS64. In the worst case, if you don=E2=80=99t like having a DNS validator aware o= f DNS64, a much simpler solution is to NOT use DNS64. 464XLAT works also in that scenario, you just force all the IPv4-only traff= ic to be translated at both sides the CLAT and the PLAT. This is not worse = than when you do NAT44. As this traffic is going to be less and less IPv4, again this is not an iss= ue. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Mark Andrews Responder a: Fecha: jueves, 28 de septiembre de 2017, 9:42 Para: Mikael Abrahamsson CC: "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt Asunto: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard = instead of info) =20 In message , Mika= el Abrah amsson writes: > So while I sympathize your "breaks DNSSEC" objection, 464XLAT actuall= y=20 > doesn't do that. DNS64 does. If all devices had 464XLAT then you woul= dn't=20 > have to do DNS64 (apart from the well-known "prefix detection" zones. =20 You do know the RFC 7050 doesn't work with DNSSEC validation enabled. RFC 7050 specifies CD=3D0. =20 ipv4only.arpa/AAAA (CD=3D0) -> validating recursive server=20 (or local validating cache) ipv4only.arpa/AAAA (CD=3D0) -> DNS64 server ipv4only.arpa/AAAA ANCOUNT>0 -> validating recursive server (or local validating cache) =20 rejected as ipv4only.arpa is signed. =20 SERVFAIL -> client =20 Lets try with CD=3D1 =20 ipv4only.arpa/AAAA (CD=3D1) -> validating recursive server=20 (or local validating cache) ipv4only.arpa/AAAA (CD=3D1) -> DNS64 server (no synthesis as CD=3D1= ) ipv4only.arpa/AAAA ANCOUNT=3D0 -> validating recursive server (or local validating cache) ipv4only.arpa/AAAA ANCOUNT=3D0 -> client (no prefixea found) =20 To get it to work the validating recursive server has to detect that prefix discover is occuring. Perform its own prefix discovery. Synthesis a prefix discover response. =20 So yes 464XLAT does require DNSSEC to be broken. =20 Mark --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Sep 28 01:15:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EC31344E9 for ; Thu, 28 Sep 2017 01:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MvZIsIJMN_z9 for ; Thu, 28 Sep 2017 01:14:59 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35427133074 for ; Thu, 28 Sep 2017 01:14:59 -0700 (PDT) Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 75C002D5063; Thu, 28 Sep 2017 08:14:58 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E9DE110F996C0; Thu, 28 Sep 2017 10:14:56 +0200 (CEST) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6328DB19-32A5-4219-9A2A-713B314EF12E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 28 Sep 2017 10:14:56 +0200 In-Reply-To: Cc: Mark Andrews , IPv6 Ops WG To: Mikael Abrahamsson References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 08:15:05 -0000 --Apple-Mail=_6328DB19-32A5-4219-9A2A-713B314EF12E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> You do know the RFC 7050 doesn't work with DNSSEC validation enabled. = RFC 7050 specifies CD=3D0. >=20 > Correct. I don't get your point. This is the local resolver on the = device trying to figure out where the NAT64 prefix is. Of course it = can't do validation on this specific query. >=20 > We all know DNS64+NAT64(+464XLAT) isn't optimal, but neither is your = suggestion to "just run dual stack". I believe you are misrepresenting Mark's position. It's perfectly fine to run an "IPv4 life extension mechanism" + IPv6, = but without NAT64/DNS64. Ole --Apple-Mail=_6328DB19-32A5-4219-9A2A-713B314EF12E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEEIHjMMkzxtT+/bDNdvtpYqJhC33YFAlnMr4AACgkQvtpYqJhC 33btJw//fUrQaOnQqalblcu1lhR/NpKinSi4snLD+JMPy6DZSQZC9tmMQjblWjmi WVSS1A3XXkrWH6wicNhhTYcbYDj2E2/JhAHDccXncXyctfvMRfxSLwY1CcHxL/sp I10j3NXphDJPZh95/XmU2d9ZV40j5nfZldJfWfAK0Yh7tlwporR0Vwv6JDfPLYY1 TsDHKqIpEr/OtBfu7ykYMnev+njn4IEeUUSnuKpWa69VpTMz3Wj4Wwk8cjS+NKd8 xj1k8fXBgeVM+YTxIV+8isp6D89iwtDlo1KNOzNloiDe3QCE6X3jiZ5qbbj+S63e eXQuxtd9K7FmVGQrWrf7WsmOUgdCF0bnHAyduQCRkMwfcqwJXSI3JdQAnT4z/Yn2 A2gFFOh5RT/pvd51OVluBYGnrHsZIYXTtTtbR3g963fBjxZHr4QwuIYqKyggzq4U HOQ2mtBx2edbrRakdG/4sTVKJnKlE+/PkMhQXYcXNR2vbkFhT3fTr+Az81FpIoKF cr6YD5Ywwc7IZ6ZMAAV0aVkcmzz+5+3AEy1yE0rbHkDyrvdMkE5zBVGemLH6ufdw JFlRVZ+0murHwrb5baaIo39dXaG/DUMqN2kUxIYdYRFYlcfOLaWhnkot4W2YtYsL WSm5j9hKFs9QucoTaDgcIHduw4gzy8PP05mmBs9Kt1G9GZ3RSGc= =GtTs -----END PGP SIGNATURE----- --Apple-Mail=_6328DB19-32A5-4219-9A2A-713B314EF12E-- From nobody Thu Sep 28 01:16:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B43A1344CF for ; Thu, 28 Sep 2017 01:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDp-oyXLNGtH for ; Thu, 28 Sep 2017 01:16:00 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7F86134650 for ; Thu, 28 Sep 2017 01:15:59 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 8C0F434CCAB; Thu, 28 Sep 2017 08:15:29 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 73EF3160090; Thu, 28 Sep 2017 08:15:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 62A2E160082; Thu, 28 Sep 2017 08:15:29 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LTvTHSC00S1F; Thu, 28 Sep 2017 08:15:29 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 21711160048; Thu, 28 Sep 2017 08:15:29 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 21D9F886EF0C; Thu, 28 Sep 2017 18:15:27 +1000 (AEST) To: Mikael Abrahamsson Cc: IPv6 Ops WG From: Mark Andrews References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> In-reply-to: Your message of "Thu, 28 Sep 2017 09:58:14 +0200." Date: Thu, 28 Sep 2017 18:15:27 +1000 Message-Id: <20170928081527.21D9F886EF0C@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 08:16:01 -0000 In message , Mikael Abrah amsson writes: > On Thu, 28 Sep 2017, Mark Andrews wrote: > > > You do know the RFC 7050 doesn't work with DNSSEC validation enabled. > > RFC 7050 specifies CD=0. > > Correct. I don't get your point. This is the local resolver on the device > trying to figure out where the NAT64 prefix is. Of course it can't do > validation on this specific query. Why shouldn't it? DNS64+NAT64 and 464XLAT require all sorts of hacks to be deployed to otherwise correctly functioning pieces of software just to get them working. DS-Lite, MAP-E and MAP-T just require the node to request the parameters using DHCP (the thing that is supposed to be used for configuring the system) then bring up a interface appropriately configured. > We all know DNS64+NAT64(+464XLAT) isn't optimal, but neither is your > suggestion to "just run dual stack". I've been arguing that one should run DS-Lite or MAP-T or MAP-E though I don't alway mention all three. The "just run dual stack" was pointing out Lorenzo's statement that it was DNS64/NAT64 or IPv4-only was a false dicotomy. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Sep 28 01:33:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B448135601 for ; Thu, 28 Sep 2017 01:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGGDJ5AAvH6v for ; Thu, 28 Sep 2017 01:33:02 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400271355F5 for ; Thu, 28 Sep 2017 01:32:55 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 021C924AF7B; Thu, 28 Sep 2017 08:31:27 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8F261160048; Thu, 28 Sep 2017 08:31:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 60C79160082; Thu, 28 Sep 2017 08:31:34 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id s0yePElgIbY0; Thu, 28 Sep 2017 08:31:34 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id D721C160048; Thu, 28 Sep 2017 08:31:33 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B6CD1886F0C8; Thu, 28 Sep 2017 18:31:31 +1000 (AEST) To: jordi.palet@consulintel.es Cc: v6ops@ietf.org From: Mark Andrews References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <911FED7C-63A7-4F55-A3FE-F97B492E4E82@consulintel.es> In-reply-to: Your message of "Thu, 28 Sep 2017 10:04:03 +0200." <911FED7C-63A7-4F55-A3FE-F97B492E4E82@consulintel.es> Date: Thu, 28 Sep 2017 18:31:31 +1000 Message-Id: <20170928083131.B6CD1886F0C8@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 08:33:03 -0000 In message <911FED7C-63A7-4F55-A3FE-F97B492E4E82@consulintel.es>, JORDI PALET M ARTINEZ writes: > You can have a DNS validator, aware of DNS64. > > In the worst case, if you dont like having a DNS validator aware of > DNS64, a much simpler solution is to NOT use DNS64. > > 464XLAT works also in that scenario, you just force all the IPv4-only > traffic to be translated at both sides the CLAT and the PLAT. This is not > worse than when you do NAT44. > > As this traffic is going to be less and less IPv4, again this is not an > issue. > > Regards, > Jordi Please go and re-read what is below. You cannot discover the prefix using correctly configured DNS software as things currently stand. Now if you tell IANA to add a insecure delegation for ipv4only.arpa one can discover the prefix but as things currently stand it is impossible. Mark > -----Mensaje original----- > De: v6ops en nombre de Mark Andrews > > Responder a: > Fecha: jueves, 28 de septiembre de 2017, 9:42 > Para: Mikael Abrahamsson > CC: "Heatley, N, Nick, TQB R" , IPv6 Ops WG > , james woodyatt > Asunto: Re: v6ops 464xlat case study (was reclassify 464XLAT as standard > instead of info) > > > In message , > Mikael Abrah > amsson writes: > > So while I sympathize your "breaks DNSSEC" objection, 464XLAT > actually > > doesn't do that. DNS64 does. If all devices had 464XLAT then you > wouldn't > > have to do DNS64 (apart from the well-known "prefix detection" > zones. > > You do know the RFC 7050 doesn't work with DNSSEC validation enabled. > RFC 7050 specifies CD=0. > > ipv4only.arpa/AAAA (CD=0) -> validating recursive server > (or local validating cache) > ipv4only.arpa/AAAA (CD=0) -> DNS64 server > ipv4only.arpa/AAAA ANCOUNT>0 -> validating recursive server > (or local validating cache) > > rejected as ipv4only.arpa is signed. > > SERVFAIL -> client > > Lets try with CD=1 > > ipv4only.arpa/AAAA (CD=1) -> validating recursive server > (or local validating cache) > ipv4only.arpa/AAAA (CD=1) -> DNS64 server (no synthesis as CD=1) > ipv4only.arpa/AAAA ANCOUNT=0 -> validating recursive server > (or local validating cache) > ipv4only.arpa/AAAA ANCOUNT=0 -> client (no prefixea found) > > To get it to work the validating recursive server has to detect > that prefix discover is occuring. Perform its own prefix discovery. > Synthesis a prefix discover response. > > So yes 464XLAT does require DNSSEC to be broken. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Sep 28 01:47:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A2D1345DF for ; Thu, 28 Sep 2017 01:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 9fyegLLzc39G for ; Thu, 28 Sep 2017 01:47:42 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA221345FA for ; Thu, 28 Sep 2017 01:47:38 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id g29so1336326wrg.11 for ; Thu, 28 Sep 2017 01:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s7IcbHs3R6WcVHca7lfBB/CPoeKMfQtw7mID/SuYC9E=; b=kO1Ldyz2Vc/+J96uKUmKMKXMFN4UJ1xiZHNaakRGQDT5DFQJgqMnpsUsaiuhvBvAai E/5FguiR1K27/nMTjG5jd0mZsZN7EhuNfWzbqZQxx1bubSsd+CRrSBDTltaWcyP1KKDs 0Mlc34VhyhpG0/hPCMJ34ov22sI9Nt5uQtaWinp9OC6s5YzsxiIAT/PLEcfP/r7EWjoA 26SXUcyYFLClM3A+guHu1i0dQDk/FtXdodEUxsNVqkXfeIFLdtxq/btx8/TCevIm1Q9I IU1hPYRz8Aey7sm8jBOSGxq2WPKTHMCFhv0Cr/U/5LPHSpZvmUe75kq1YJ2n/2nPsccg TZEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s7IcbHs3R6WcVHca7lfBB/CPoeKMfQtw7mID/SuYC9E=; b=toXq5iKxnG/cX9MI1+JDfUSmPtVMSlTt2RSVxIpUq2ilKk9NZ07YvoKNQU5WdNA4Eu lsJo7xgqLrfCSiwrUPZhXJEht+ckJWAK2ROhb1Zu8oWnXUFSAPWHxr5uTwTEcYf6Bm7Y yTRYcaLnk5nE1Y1GwUDS9butCoBdt3SR35X1v/e1BEi90otYdG3l+CvK7QhTTrX53eYT 6CJPSnrkq8vpkOIIpmZtvy3U3QQJBgWt71TzN3x5/5Owwh4iFa7q3YTvd8qjC5AEUnhR +hz42CncRS74CJb9SkVq9PIba6uf1FG+nNqhd8bww3YBInv4uneqvFWVlRmYvJjRnq8L aDvw== X-Gm-Message-State: AHPjjUjK0rsmHBtDVYKzqXzEogieGO4cKWDfdYKoW6gTM7ARGCAsJkRR BwZ2t8zs46WHyBffiKuQZBgjkU0YuAU0uxMx/xxYHw== X-Google-Smtp-Source: AOwi7QBMU7DMrcFUJ2p4F7ErYsnDOzxXZdOzr7ERKumBK9guUnEmU9hhnoij8WXN0AfM5CHIiMCu7cSQbJ+OhMOSpT0= X-Received: by 10.223.176.46 with SMTP id f43mr4137225wra.206.1506588456880; Thu, 28 Sep 2017 01:47:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Thu, 28 Sep 2017 01:47:15 -0700 (PDT) In-Reply-To: <20170928081527.21D9F886EF0C@rock.dv.isc.org> References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> From: Erik Kline Date: Thu, 28 Sep 2017 17:47:15 +0900 Message-ID: To: Mark Andrews Cc: Mikael Abrahamsson , IPv6 Ops WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11438d5ad49b96055a3bf5ec" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 08:47:45 -0000 --001a11438d5ad49b96055a3bf5ec Content-Type: text/plain; charset="UTF-8" On 28 September 2017 at 17:15, Mark Andrews wrote: > > In message , Mikael Abrah > amsson writes: >> On Thu, 28 Sep 2017, Mark Andrews wrote: >> >> > You do know the RFC 7050 doesn't work with DNSSEC validation enabled. >> > RFC 7050 specifies CD=0. >> >> Correct. I don't get your point. This is the local resolver on the device >> trying to figure out where the NAT64 prefix is. Of course it can't do >> validation on this specific query. > > Why shouldn't it? DNS64+NAT64 and 464XLAT require all sorts of > hacks to be deployed to otherwise correctly functioning pieces of > software just to get them working. > > DS-Lite, MAP-E and MAP-T just require the node to request the > parameters using DHCP (the thing that is supposed to be used for > configuring the system) then bring up a interface appropriately > configured. And here we come to yet another problem that was unsolved in mobile networks at the time. At the time the 464xlat/CLAT work was done in Android (c. 2009) I don't think mobile networks really supported DHCPv6. Additionally, at that time many 3GPP networks didn't support IPv4v6 PDN types but rather required separate IPv4-only and IPv6-only PDNs to effect dualstack (but the operators could be charged on a per-PDN basis meaning it doubled the cost to add IPv6). So what was really wanted at that time was: [a] a way to reach the IPv4 Internet from an IPv6-only APN, *and* [b] a provisioning mechanism that: [i] didn't use the DHCPv6 that wasn't available in the network, and [ii] didn't require forklifting 3GPP deployed hardware/software I suppose we could have tried to fetch a JSON config file from some HTTP/S service constructed from the APN name or something... =) -Erik I can just feel all the "android and dhcpv6" screeds being written right now... --001a11438d5ad49b96055a3bf5ec Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgdIxgNHYcp1S9d8xNMdadXzhY8gDSQgCr 1wYJvO4D+mMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTI4 MDg0NzM3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAAHp4atJgKbVdA0ynUcxG1pzo5WYZ1LUnkqLQN+9x0mUHSpVZ/Fp cba8dnOh7VjOT5iHljjEXTEY3kz+eT9+uRY+qqnem8pGUcCXNLXdKL15ySmDDVEtm5kWrP7aMgqd pHlfSRwPwk6yBo6LIShdoduvv82HJTugUFUpn6+6idjJctYTdjc3dtu4lRrDGHcsG2itIfHPRTFq m4M9UUpZGuAq9QcjGRgT4hcRocqOz32EyHClNZS5ubs0CZ9BysPZn4qCbP9cucfk8JFUvZP6Rgux 7MS/yo1IDubGxWDxuznZj5PeIUyswbsynofy/dnHhtOMC2NFErvLgp1gxW/eTfk= --001a11438d5ad49b96055a3bf5ec-- From nobody Thu Sep 28 01:53:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59D0134657 for ; Thu, 28 Sep 2017 01:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qaBrslfphiZ for ; Thu, 28 Sep 2017 01:53:44 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DAF134654 for ; Thu, 28 Sep 2017 01:53:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5F69AB1; Thu, 28 Sep 2017 10:53:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506588822; bh=iPtLJYGvHVrRX+Yb1yNsjBz/XXbQbGIpJuX1sOPiCxA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Jo3+3FZyVXkBQuSChHXd+4w+pvDe5SDpbtaTYnNJCjXA6IozA3U9zA1lZHU0LFQn+ kvZ5mF6yjeZVWTUbmjw00+J92LoYoQw7UMabvoApzO4aZGaoCJpcvWuje1iCLT4vse YUeYfSJpR5ZpQ/ue0cRLrlSdZyeOcmu9PZKQ9lcI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 47E8FAF; Thu, 28 Sep 2017 10:53:42 +0200 (CEST) Date: Thu, 28 Sep 2017 10:53:42 +0200 (CEST) From: Mikael Abrahamsson To: Erik Kline cc: IPv6 Ops WG In-Reply-To: Message-ID: References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 08:53:46 -0000 On Thu, 28 Sep 2017, Erik Kline wrote: > I can just feel all the "android and dhcpv6" screeds being written right > now... Do any other mobile operating systems do DHCPv6 on the GTP tunnel? It's been too many years since I last looked at GTP packet traces to remember if this was done or not. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 28 02:06:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436F5134566 for ; Thu, 28 Sep 2017 02:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vKULu3lyVlni for ; Thu, 28 Sep 2017 02:06:27 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B97A13453C for ; Thu, 28 Sep 2017 02:06:27 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id m72so838270wmc.1 for ; Thu, 28 Sep 2017 02:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tCXNSHfzgK11mDTOZjHmUv8tmqJoPFLh59JQCTHxvmU=; b=tF8xu6JtMrQWCPt1a6izczUzjRcGCdNozuFr8RwLgS/T2l8XPN7gXh3gaE3QsZKVpU iO+KcwiwMp6VkTUwgOmGYvlkq4LCDJVZYHfK+jjpnYD1w2pRR54KVYVC5QN0PXwwo/ki wMEVrT9xAkzt7PG8K5u7OLhjQgZ0t4e6kEct0GS/JkiytwjAEKVtOEAHy7Zyhdm63k0w QrR7Kclv60SbCQayHs+AL6cNSFgER3sJ1VHriMyRQ6W6DJDfRVz+37vTluUPfU8Q+3UY clKAKFHyn5JxpDHrgQqfNi/Na/UAp/lRJ8okYwlaBXlbgOwD80mMPoSmYex7NfsZ+d2A SCIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tCXNSHfzgK11mDTOZjHmUv8tmqJoPFLh59JQCTHxvmU=; b=qTLqsREb4XvwdjqEf4Npru9q+D+VwiHLWQDQuxz5Ewsh2OvzvTlIOlvgqgdtGo4rOB 1wyH6lb7JTjB2mXuuipIZfoPTf/c+gS0PRoqXr/U55nc3HO8MRgKwg5fkoKhu1A2Tj2D d7ZzGzt7lA88kS0X23isYjjklN5DsaarjVJgut/VwWlb+CmkG3GglMh4ePSl40xHzigU /8zOV2m46IlgzM8SpBj3pWLsyxofDFO3LH0K3i3Pv5gkCXWJ0NsYn5Xw3bq9W4aqefrQ bzfjUj87y78MTF78Sp8cBc38aYz2TTZtxTQ8Zw0dUWxcDvs2ZkFdhDbdxCqtl3Rggw5R filQ== X-Gm-Message-State: AHPjjUhQUwG8MZ254GXu+qSQ/yVnKr6fUpIj8IKVRLNzk4fn7utm6hU/ vdOQDcHE4BirI2004YkNoi97bEzVhTNd7YZIdwogxQ== X-Google-Smtp-Source: AOwi7QC9KUa1dL6Y0Cqu5SDDFjH7n4KcIllrXEJw097wB2CJZQO1g7gQhNQLx4VBrPyIEfAMke3U+RPiVDypsetueb0= X-Received: by 10.28.64.6 with SMTP id n6mr423150wma.61.1506589585176; Thu, 28 Sep 2017 02:06:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Thu, 28 Sep 2017 02:06:04 -0700 (PDT) In-Reply-To: References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> From: Erik Kline Date: Thu, 28 Sep 2017 18:06:04 +0900 Message-ID: To: Mikael Abrahamsson Cc: IPv6 Ops WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114b32ec147d2b055a3c392f" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 09:06:33 -0000 --001a114b32ec147d2b055a3c392f Content-Type: text/plain; charset="UTF-8" On 28 September 2017 at 17:53, Mikael Abrahamsson wrote: > On Thu, 28 Sep 2017, Erik Kline wrote: > >> I can just feel all the "android and dhcpv6" screeds being written right >> now... > > > Do any other mobile operating systems do DHCPv6 on the GTP tunnel? It's been > too many years since I last looked at GTP packet traces to remember if this > was done or not. I've no idea. Nor do I know what might happen to various networks if DHCPv6 requests were to be made on the mobile interface (even if the O bit /were/ observed to be set). The stories of billing system crashes and so on from the early days of v6 on mobile leave me somewhat suspicious. I have been wondering about asking for an API to the modem to query for the 3GPP release number of the network as a hint for expected capabilities, but that kinda seems both excessive and like a layering violation. ;-) --001a114b32ec147d2b055a3c392f Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgEXlURXHD6K8OT+O056sBCYN154N3IPI6 SOuHZQQO0/gwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTI4 MDkwNjI1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAHMIHi7xUQxYk5OlwJb8jZRWiv/YZ4rjlMfK7+Gb/HIlvKt08pO8 L7Dc0M1T8nECELpztAO2EbASeuWaB3iPUQ8MEnYR1C4o3Ue1k6aMEKTEZstXxXVrsTOJWPh2lTjN NTpIli+4ReGNxMLac/O/xNUV98uq7VVZweHqWLcglScWXu3Zn7ZFbUL1pq2T/AuTW9kDA29YQ9C7 motiLKV1gAFJwb7aZJuQ1VwsrJo13K7NNO9+LkueDoqYtUhVBvCrDyxxVPytG4pm1gMka4mvEL3k CEnvmhjrAqc/WmH06UvXu86sSpb6jLwoHePk6BilaaihDJdhUIlBfQg7/Bo9MH4= --001a114b32ec147d2b055a3c392f-- From nobody Thu Sep 28 02:44:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2E11345DE for ; Thu, 28 Sep 2017 02:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tflTNjmnbLRW for ; Thu, 28 Sep 2017 02:44:07 -0700 (PDT) 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 A338A1345DD for ; Thu, 28 Sep 2017 02:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9525; q=dns/txt; s=iport; t=1506591847; x=1507801447; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=E34tWU+wCw1EEe7UBhh9aGQjaK8ShPEx2Bt2t8Agcyo=; b=UeAUTA98qewrixcx+CunEWTccp8MLSO9FnhWLaowgQXCkBCA8mLz3w+O auSc0GpqZnLZMvsrwocPKJIj/9EX8/J4nn6DGxsKDF/P8K/sU8G6l16oe NJrNoYn6IVcEMtuTj0pzLLHnJlUh6Z/KOmmr4Nd8uAoyaYc/hCCgSsUdG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAQDNw8xZ/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1xkbieDeJl9kmOGcQNcChgBBYUdAhqETFcBAgEBAQEBAmsohRk?= =?us-ascii?q?CAQMBASFLCxACAQgOMQMCAgIlCxQRAgQOBYlNZBCnHIIniwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYMrggKBUYIVgn2EcimCfC+CMQWYT4hWApRdkwaVHwIRGQG?= =?us-ascii?q?BOAFXTz94FUkSAYU8gU52AYhPAQEB?= X-IronPort-AV: E=Sophos;i="5.42,449,1500940800"; d="scan'208,217";a="9278814" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 09:44:06 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8S9i63E021058 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Sep 2017 09:44:06 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 28 Sep 2017 04:44:05 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Thu, 28 Sep 2017 04:44:05 -0500 From: "Rajiv Asati (rajiva)" To: Erik Kline CC: Mikael Abrahamsson , IPv6 Ops WG Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) Thread-Index: AdM16ZBiVXxOrrPASdi8hSWu5DH/5gBUxEOAAA4804AAHACngAAFqZaAAAPsVoAAAeIOAAAGsJeA//+yUQuAAIJHAP//yXnCgABYXwD//7E2X4AAXHyAgAABzgCAAAN0AP//ts7a Date: Thu, 28 Sep 2017 09:44:05 +0000 Message-ID: References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_F3AFCB3900D04E3CAC90E06038AC5230ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 09:44:10 -0000 --_000_F3AFCB3900D04E3CAC90E06038AC5230ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEbyBhbnkgb3RoZXIgbW9iaWxlIG9wZXJhdGluZyBzeXN0ZW1zIGRvIERIQ1B2NiBvbiB0aGUg R1RQIHR1bm5lbD8gSXQncyBiZWVuDQoNCkkgY291bGQgZG91YmxlIGNoZWNrIENQRSByb3V0ZXJz IHN1Y2ggYXMgSVNSODE5IHdpdGggTFRFIFdBTiB1cGxpbmsgc3VwcG9ydCBESENQdjYuDQoNClNl cGFyYXRlbHksIGZyb20gUEdXIHBvaW50IG9mIHZpZXcsIERIQ1B2NiB3aXRoaW4gYW4gQVBOIHNl ZW1zIHRvIGJlIHN1cHBvcnRlZCAtDQoNCmh0dHBzOi8vd3d3LmNpc2NvLmNvbS9jL2VuL3VzL3Rk L2RvY3Mvd2lyZWxlc3MvYXNyXzUwMDAvMjAvUC1HVy9iXzIwX1BHV19BZG1pbi9iXzE5X1BHV19B ZG1pbl9jaGFwdGVyXzAxMC5odG1sI3Rhc2tfMzA5ZWI5ODYtNDUxMC00MjVhLTgxZWQtODMzMDE4 ZTcwOTIxDQoNCi8vDQpUaGUgc3lzdGVtIGNhbiBiZSBjb25maWd1cmVkIHRvIHVzZSB0aGUgRHlu YW1pYyBIb3N0IENvbnRyb2wgUHJvdG9jb2wgKERIQ1ApIGZvciBJUHY2IHRvIGVuYWJsZSB0aGUg REhDUCBzZXJ2ZXJzIHRvIHBhc3MgdGhlIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBzdWNoIGFz IElQdjYgbmV0d29yayBhZGRyZXNzZXMgdG8gSVB2NiBub2Rlcy4gREhDUHY2IGNvbmZpZ3VyYXRp b24gaXMgZG9uZSB3aXRoaW4gYW4gQVBOLg0KLy8NCg0KDQoNCkkgaGF2ZSBiZWVuIHdvbmRlcmlu ZyBhYm91dCBhc2tpbmcgZm9yIGFuIEFQSSB0byB0aGUgbW9kZW0gdG8gcXVlcnkNCmZvciB0aGUg M0dQUCByZWxlYXNlIG51bWJlciBvZiB0aGUgbmV0d29yayBhcyBhIGhpbnQgZm9yIGV4cGVjdGVk DQpjYXBhYmlsaXRpZXMsIGJ1dCB0aGF0IGtpbmRhIHNlZW1zIGJvdGggZXhjZXNzaXZlIGFuZCBs aWtlIGEgbGF5ZXJpbmcNCg0KR2l2ZW4gYWxsIHRoZSB0aGluZyB0aGF0IGdldCBxdWVyaWVkIGFu ZCBmZXRjaGVkIGJ5IGFwcHMsIGZldGNoaW5nIHRoZSByZWwjIGJlaW5nIHVzZWQgKGFzc3VtaW5n IGF2YWlsYWJsZSkgd291bGQgYWRkIGEgZHJvcCB0byB0aGUgb2NlYW4uIDopDQoNCkNoZWVycywN ClJhaml2IEFzYXRpDQpEaXN0aW5ndWlzaGVkIEVuZ2luZWVyLCBDaXNjbyBTZXJ2aWNlcw0KDQoN Ck9uIFNlcCAyOCwgMjAxNywgYXQgMTE6MDYgQU0sIEVyaWsgS2xpbmUgPGVrQGdvb2dsZS5jb208 bWFpbHRvOmVrQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KT24gMjggU2VwdGVtYmVyIDIwMTcgYXQg MTc6NTMsIE1pa2FlbCBBYnJhaGFtc3NvbiA8c3dtaWtlQHN3bS5wcC5zZTxtYWlsdG86c3dtaWtl QHN3bS5wcC5zZT4+IHdyb3RlOg0KT24gVGh1LCAyOCBTZXAgMjAxNywgRXJpayBLbGluZSB3cm90 ZToNCg0KSSBjYW4ganVzdCBmZWVsIGFsbCB0aGUgImFuZHJvaWQgYW5kIGRoY3B2NiIgc2NyZWVk cyBiZWluZyB3cml0dGVuIHJpZ2h0DQpub3cuLi4NCg0KDQpEbyBhbnkgb3RoZXIgbW9iaWxlIG9w ZXJhdGluZyBzeXN0ZW1zIGRvIERIQ1B2NiBvbiB0aGUgR1RQIHR1bm5lbD8gSXQncyBiZWVuDQp0 b28gbWFueSB5ZWFycyBzaW5jZSBJIGxhc3QgbG9va2VkIGF0IEdUUCBwYWNrZXQgdHJhY2VzIHRv IHJlbWVtYmVyIGlmIHRoaXMNCndhcyBkb25lIG9yIG5vdC4NCg0KSSd2ZSBubyBpZGVhLiAgTm9y IGRvIEkga25vdyB3aGF0IG1pZ2h0IGhhcHBlbiB0byB2YXJpb3VzIG5ldHdvcmtzIGlmDQpESENQ djYgcmVxdWVzdHMgd2VyZSB0byBiZSBtYWRlIG9uIHRoZSBtb2JpbGUgaW50ZXJmYWNlIChldmVu IGlmIHRoZSBPDQpiaXQgL3dlcmUvIG9ic2VydmVkIHRvIGJlIHNldCkuICBUaGUgc3RvcmllcyBv ZiBiaWxsaW5nIHN5c3RlbSBjcmFzaGVzDQphbmQgc28gb24gZnJvbSB0aGUgZWFybHkgZGF5cyBv ZiB2NiBvbiBtb2JpbGUgbGVhdmUgbWUgc29tZXdoYXQNCnN1c3BpY2lvdXMuDQoNCkkgaGF2ZSBi ZWVuIHdvbmRlcmluZyBhYm91dCBhc2tpbmcgZm9yIGFuIEFQSSB0byB0aGUgbW9kZW0gdG8gcXVl cnkNCmZvciB0aGUgM0dQUCByZWxlYXNlIG51bWJlciBvZiB0aGUgbmV0d29yayBhcyBhIGhpbnQg Zm9yIGV4cGVjdGVkDQpjYXBhYmlsaXRpZXMsIGJ1dCB0aGF0IGtpbmRhIHNlZW1zIGJvdGggZXhj ZXNzaXZlIGFuZCBsaWtlIGEgbGF5ZXJpbmcNCnZpb2xhdGlvbi4gIDstKQ0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0K djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K --_000_F3AFCB3900D04E3CAC90E06038AC5230ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+RG8gYW55IG90aGVyIG1vYmls ZSBvcGVyYXRpbmcgc3lzdGVtcyBkbyBESENQdjYgb24gdGhlIEdUUCB0dW5uZWw/IEl0J3MgYmVl bjwvc3Bhbj48L2ZvbnQ+PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9kaXY+ DQo8ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUs IDApOyI+SSBjb3VsZCBkb3VibGUgY2hlY2sgQ1BFIHJvdXRlcnMgc3VjaCBhcyBJU1I4MTkgd2l0 aCBMVEUgV0FOIHVwbGluayBzdXBwb3J0IERIQ1B2Ni4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj5TZXBhcmF0ZWx5LCBmcm9tIFBHVyBwb2ludCBvZiB2aWV3LCBE SENQdjYgd2l0aGluIGFuIEFQTiBzZWVtcyB0byBiZSBzdXBwb3J0ZWQgLSZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6Ly93d3cuY2lzY28uY29tL2Mv ZW4vdXMvdGQvZG9jcy93aXJlbGVzcy9hc3JfNTAwMC8yMC9QLUdXL2JfMjBfUEdXX0FkbWluL2Jf MTlfUEdXX0FkbWluX2NoYXB0ZXJfMDEwLmh0bWwjdGFza18zMDllYjk4Ni00NTEwLTQyNWEtODFl ZC04MzMwMThlNzA5MjEiPmh0dHBzOi8vd3d3LmNpc2NvLmNvbS9jL2VuL3VzL3RkL2RvY3Mvd2ly ZWxlc3MvYXNyXzUwMDAvMjAvUC1HVy9iXzIwX1BHV19BZG1pbi9iXzE5X1BHV19BZG1pbl9jaGFw dGVyXzAxMC5odG1sI3Rhc2tfMzA5ZWI5ODYtNDUxMC00MjVhLTgxZWQtODMzMDE4ZTcwOTIxPC9h PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Ly88L2Rpdj4NCjxkaXY+PHNwYW4gc3R5 bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5UaGUgc3lzdGVt IGNhbiBiZSBjb25maWd1cmVkIHRvIHVzZSB0aGUgRHluYW1pYyBIb3N0IENvbnRyb2wgUHJvdG9j b2wgKERIQ1ApIGZvciBJUHY2IHRvIGVuYWJsZSB0aGUgREhDUCBzZXJ2ZXJzIHRvIHBhc3MgdGhl IGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBzdWNoIGFzIElQdjYgbmV0d29yayBhZGRyZXNzZXMg dG8gSVB2NiBub2Rlcy4NCiBESENQdjYgY29uZmlndXJhdGlvbiBpcyBkb25lIHdpdGhpbiBhbiBB UE4uPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdi YSgyNTUsIDI1NSwgMjU1LCAwKTsiPi8vPC9zcGFuPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iYmFja2dyb3Vu ZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPkkgaGF2ZSBiZWVuIHdvbmRlcmluZyBh Ym91dCBhc2tpbmcgZm9yIGFuIEFQSSB0byB0aGUgbW9kZW0gdG8gcXVlcnk8YnI+DQpmb3IgdGhl IDNHUFAgcmVsZWFzZSBudW1iZXIgb2YgdGhlIG5ldHdvcmsgYXMgYSBoaW50IGZvciBleHBlY3Rl ZDxicj4NCmNhcGFiaWxpdGllcywgYnV0IHRoYXQga2luZGEgc2VlbXMgYm90aCBleGNlc3NpdmUg YW5kIGxpa2UgYSBsYXllcmluZzwvc3Bhbj48L2ZvbnQ+PC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCkdpdmVuIGFsbCB0aGUgdGhpbmcgdGhhdCBnZXQgcXVlcmllZCBhbmQgZmV0Y2hl ZCBieSBhcHBzLCBmZXRjaGluZyB0aGUgcmVsIyBiZWluZyB1c2VkIChhc3N1bWluZyBhdmFpbGFi bGUpIHdvdWxkIGFkZCBhIGRyb3AgdG8gdGhlIG9jZWFuLiA6KTxicj4NCjxicj4NCjxkaXY+Q2hl ZXJzLA0KPGRpdj5SYWppdiBBc2F0aTwvZGl2Pg0KPGRpdj5EaXN0aW5ndWlzaGVkIEVuZ2luZWVy LCBDaXNjbyBTZXJ2aWNlczwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pjxicj4NCk9uIFNlcCAyOCwgMjAxNywgYXQgMTE6MDYgQU0sIEVyaWsgS2xpbmUgJmx0 OzxhIGhyZWY9Im1haWx0bzpla0Bnb29nbGUuY29tIj5la0Bnb29nbGUuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNw YW4+T24gMjggU2VwdGVtYmVyIDIwMTcgYXQgMTc6NTMsIE1pa2FlbCBBYnJhaGFtc3NvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnN3bWlrZUBzd20ucHAuc2UiPnN3bWlrZUBzd20ucHAuc2U8L2E+Jmd0 OyB3cm90ZTo8L3NwYW4+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+T24gVGh1 LCAyOCBTZXAgMjAxNywgRXJpayBLbGluZSB3cm90ZTo8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+SSBjYW4ganVzdCBmZWVsIGFsbCB0aGUgJnF1b3Q7YW5kcm9pZCBhbmQgZGhjcHY2JnF1b3Q7 IHNjcmVlZHMgYmVpbmcgd3JpdHRlbiByaWdodDwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPm5vdy4uLjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkRvIGFueSBvdGhlciBtb2JpbGUg b3BlcmF0aW5nIHN5c3RlbXMgZG8gREhDUHY2IG9uIHRoZSBHVFAgdHVubmVsPyBJdCdzIGJlZW48 L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ dG9vIG1hbnkgeWVhcnMgc2luY2UgSSBsYXN0IGxvb2tlZCBhdCBHVFAgcGFja2V0IHRyYWNlcyB0 byByZW1lbWJlciBpZiB0aGlzPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPndhcyBkb25lIG9yIG5vdC48L3NwYW4+PGJyPg0KPC9ibG9ja3F1 b3RlPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPkkndmUgbm8gaWRlYS4gJm5ic3A7Tm9yIGRv IEkga25vdyB3aGF0IG1pZ2h0IGhhcHBlbiB0byB2YXJpb3VzIG5ldHdvcmtzIGlmPC9zcGFuPjxi cj4NCjxzcGFuPkRIQ1B2NiByZXF1ZXN0cyB3ZXJlIHRvIGJlIG1hZGUgb24gdGhlIG1vYmlsZSBp bnRlcmZhY2UgKGV2ZW4gaWYgdGhlIE88L3NwYW4+PGJyPg0KPHNwYW4+Yml0IC93ZXJlLyBvYnNl cnZlZCB0byBiZSBzZXQpLiAmbmJzcDtUaGUgc3RvcmllcyBvZiBiaWxsaW5nIHN5c3RlbSBjcmFz aGVzPC9zcGFuPjxicj4NCjxzcGFuPmFuZCBzbyBvbiBmcm9tIHRoZSBlYXJseSBkYXlzIG9mIHY2 IG9uIG1vYmlsZSBsZWF2ZSBtZSBzb21ld2hhdDwvc3Bhbj48YnI+DQo8c3Bhbj5zdXNwaWNpb3Vz Ljwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+SSBoYXZlIGJlZW4gd29uZGVy aW5nIGFib3V0IGFza2luZyBmb3IgYW4gQVBJIHRvIHRoZSBtb2RlbSB0byBxdWVyeTwvc3Bhbj48 YnI+DQo8c3Bhbj5mb3IgdGhlIDNHUFAgcmVsZWFzZSBudW1iZXIgb2YgdGhlIG5ldHdvcmsgYXMg YSBoaW50IGZvciBleHBlY3RlZDwvc3Bhbj48YnI+DQo8c3Bhbj5jYXBhYmlsaXRpZXMsIGJ1dCB0 aGF0IGtpbmRhIHNlZW1zIGJvdGggZXhjZXNzaXZlIGFuZCBsaWtlIGEgbGF5ZXJpbmc8L3NwYW4+ PGJyPg0KPHNwYW4+dmlvbGF0aW9uLiAmbmJzcDs7LSk8L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+ djZvcHMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzp2Nm9w c0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F3AFCB3900D04E3CAC90E06038AC5230ciscocom_-- From nobody Thu Sep 28 02:47:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5571345EB for ; Thu, 28 Sep 2017 02:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKqdsbioAukU for ; Thu, 28 Sep 2017 02:47:55 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72347134509 for ; Thu, 28 Sep 2017 02:47:55 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8S9lqSB001865; Thu, 28 Sep 2017 11:47:52 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D3AAE2056BE; Thu, 28 Sep 2017 11:47:52 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id BC95A2053DB; Thu, 28 Sep 2017 11:47:52 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8S9lq0T001868; Thu, 28 Sep 2017 11:47:52 +0200 To: Fred Baker Cc: v6ops@ietf.org References: <71DC2E77-20D3-4EC8-95B1-96070DA135E7@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 28 Sep 2017 11:47:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <71DC2E77-20D3-4EC8-95B1-96070DA135E7@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 09:47:57 -0000 Le 25/09/2017 à 21:06, Fred Baker a écrit : > > >> On Sep 25, 2017, at 9:08 AM, Alexandre Petrescu >> wrote: >> >> Excuse me, what do you mean by IPv4 private address exhaustion? > > Several companies, notably Microsoft and Comcast in the v6ops > context, and said that they were running out not only of public > space but, within their networks, private space. In one company I looked at they didnt run out of public IPv4 space, yet they preferred to extend their internal network by adding private IPv4 space - reasons invoked relate some times the security of NAT, other times to other reasons. Running out of private space is probably not a reason that a reasonable sysadmin could invoke. One can not run out of private space. But one can mis-design a network - yes. Alex In the CGN context, this > (in part, there were other considerations) resulted in us requesting > an additional RFC 1918-like prefix for the space between a presumed > NAT'd private address space and a CGN. > From nobody Thu Sep 28 02:48:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862531345EE for ; Thu, 28 Sep 2017 02:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjAGwW8hR-u6 for ; Thu, 28 Sep 2017 02:48:38 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85551345EB for ; Thu, 28 Sep 2017 02:48:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8S9mZPh030806; Thu, 28 Sep 2017 11:48:35 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AAD552056BB; Thu, 28 Sep 2017 11:48:35 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9B6A22055D1; Thu, 28 Sep 2017 11:48:35 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8S9mZ7K002245; Thu, 28 Sep 2017 11:48:35 +0200 To: Fred Baker , Gert Doering Cc: v6ops list References: <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <4bf16a40ffd44e9498babf7094b1e526@orange.com> <0E9B8640-E102-4AB0-8908-28A988795861@consulintel.es> <2292D724-BF30-4530-A6BE-0B33E30043D0@consulintel.es> <20170925102250.GA45648@Space.Net> <81661be5-4a1a-1f8a-10d0-829e775546d9@gmail.com> <20170925120507.GE45648@Space.Net> <79BA8440-3BF6-42B1-9B90-C37BBB2FB66A@gmail.com> From: Alexandre Petrescu Message-ID: <4cea1c48-4298-9512-5d0d-53e9f51a4536@gmail.com> Date: Thu, 28 Sep 2017 11:48:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <79BA8440-3BF6-42B1-9B90-C37BBB2FB66A@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 09:48:39 -0000 Noted Le 25/09/2017 à 21:31, Fred Baker a écrit : > Speaking as chair, the person who can actually ask someone to "please go away". > > I'm not asking anyone to "go away". I will note that IETF working groups do much of their work on mailing lists, and have active participants who operate on their lists primarily, and in some cases only, on those lists. You are each active in v6ops, and appreciated by the chairs. > > That said, Alexandre, I have to agree with Gert that the views you have expressed in the past few days have added little to the discussion. They differ from many of the networks and deployments discussed in v6ops, and aren't particularly helpful. In specific cases, as others have noted, they are incorrect. > > What I, as chair, will ask - of each of us - is that if you have comments to make that are personal rather than technical, please address them privately to the person in question. We have close to 1000 people on this mailing list, and the other 999 don't really need the noise. > >> On Sep 25, 2017, at 5:05 AM, Gert Doering wrote: >> >> Hi, >> >> On Mon, Sep 25, 2017 at 12:29:49PM +0200, Alexandre Petrescu wrote: >>> Le 25/09/2017 à 12:22, Gert Doering a écrit : >>>> Hi, >>>> >>>> On Mon, Sep 25, 2017 at 11:51:29AM +0200, Alexandre Petrescu wrote: >>>>> I also heard the term "native IPv6". This means there is no IPv4. >>>> >>>> "native IPv6" usually means "IPv6 is not tunneled over IPv4" >>> >>> That's for you. >>> >>> For me "native IPv6" means there is no IPv4. And there are many such >>> networks. >> >> Would you please just go away? Redefining everything in different ways >> from everyone else, and then complaining that things will not work out >> the way you think it is is just wasting everyones time. >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Thu Sep 28 02:58:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5236C134629 for ; Thu, 28 Sep 2017 02:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzKv6EEy_834 for ; Thu, 28 Sep 2017 02:58:49 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3333F13462A for ; Thu, 28 Sep 2017 02:58:49 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 72C9BB1; Thu, 28 Sep 2017 11:58:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506592726; bh=f5ktRSTbzuUCTp2FGG5JRUzjO7ODRinBW1NXVZcpaJ8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=2GlkoX5H/iWRdjyW/Kmal+4a9YbjPBQQfuZApzLkKvBuJU1BKDjCfllAM0qus4sLX J2tsFiljDNIF23bT4XLMrXDr3bhBg6zukAVf43KItN7bbMa7do2Z8fHMUHNrWyKoIe 6rlY3qkrh27RuzSt7Hk3/oSf7C+FY/OVtq7qDR5U= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 70B69AF; Thu, 28 Sep 2017 11:58:46 +0200 (CEST) Date: Thu, 28 Sep 2017 11:58:46 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <71DC2E77-20D3-4EC8-95B1-96070DA135E7@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 09:58:51 -0000 On Thu, 28 Sep 2017, Alexandre Petrescu wrote: > Running out of private space is probably not a reason that a reasonable > sysadmin could invoke. One can not run out of private space. But one > can mis-design a network - yes. Yet large network providers have said they have this exact problem. For instance some with a lot more than 16M devices to manage. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Sep 28 02:59:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA6313462A for ; Thu, 28 Sep 2017 02:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rGhVr6YN-Q7 for ; Thu, 28 Sep 2017 02:59:38 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05110134570 for ; Thu, 28 Sep 2017 02:59:37 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8S9xaFF037333; Thu, 28 Sep 2017 11:59:36 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 42AAA205701; Thu, 28 Sep 2017 11:59:36 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2C3DA205582; Thu, 28 Sep 2017 11:59:36 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8S9xZWG009113; Thu, 28 Sep 2017 11:59:36 +0200 To: Mikael Abrahamsson Cc: v6ops@ietf.org References: <71DC2E77-20D3-4EC8-95B1-96070DA135E7@gmail.com> From: Alexandre Petrescu Message-ID: <53a14c91-2d46-8084-4a21-e2bd2f0c0cc9@gmail.com> Date: Thu, 28 Sep 2017 11:59:35 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 09:59:39 -0000 Le 28/09/2017 à 11:58, Mikael Abrahamsson a écrit : > On Thu, 28 Sep 2017, Alexandre Petrescu wrote: > >> Running out of private space is probably not a reason that a >> reasonable sysadmin could invoke.  One can not run out of private >> space.  But one can mis-design a network - yes. > > Yet large network providers have said they have this exact problem. For > instance some with a lot more than 16M devices to manage. I agree with you. Alex > From nobody Thu Sep 28 04:42:45 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 673E6132D44; Thu, 28 Sep 2017 04:42:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150659896337.13704.16305576151522889075@ietfa.amsl.com> Date: Thu, 28 Sep 2017 04:42:43 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 11:42:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-11.txt Pages : 9 Date : 2017-09-28 Abstract: This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique service provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-11 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-11 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 Thu Sep 28 05:19:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67383134705 for ; Thu, 28 Sep 2017 05:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gt6FMQmcn-5j for ; Thu, 28 Sep 2017 05:19:13 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40137.outbound.protection.outlook.com [40.107.4.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B7E13292F for ; Thu, 28 Sep 2017 05:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DaFIy6WK8NmrD6qT6uvl1NajaPCFIsCaD1BCdFFLnSY=; b=rMZniki6HtY+iVdxYL9VWWHJr4jK7FtXUl/PV388RayzWF/bEYUuN5XQqHUfe4/oPVqSeRvu7oi10dn7hENZSKh9SHB3Rv5/MA/GXYfyi66F9FAjnrftfLGhO2iM5iK2ifNzt4HQ2Wwb7wPSwYsDt0SPbjQdeqZWaC7DtvOrJ48= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1716.eurprd07.prod.outlook.com (10.166.133.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 28 Sep 2017 12:19:10 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be%13]) with mapi id 15.20.0077.016; Thu, 28 Sep 2017 12:19:10 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-11.txt Thread-Index: AQHTOFP9NUuAVAYm+UaHO5fnr9uLiw== Date: Thu, 28 Sep 2017 12:19:10 +0000 Message-ID: <504C386B-260F-452E-8195-3A6E3D3BF40B@nokia.com> References: <150659896337.13704.16305576151522889075@ietfa.amsl.com> In-Reply-To: <150659896337.13704.16305576151522889075@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.135.12.190] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1716; 6:tvE/DL0TSVRLHsvKtuBdqPTVZSwCi0BoPanM8qrQ7PcZHjj/93gJ2dPdKPzZQaphoaNYvE4/zdfmnZYzulUUJOJCPa6dnqg4PJ5Wbu/8XqJ4ew1O5LLV2u8HdaFExPffwH6SBIa7ZrXZGxb94AjiDouBsyfW6E2sN0tz0yN8ZJC1bQNJXm9lZqpfBtZ5gpKxL5TQzJ3DqUUM0HgUJuFl+3b7o7ykStMV6bW+b6gZQKcn1os3qJ9qlFQx7tb1LfAUW/9EvyEmOWBNYvgGf2PvmXc5GyjlaHfpzYWHyrqp/NzydJVgi738SYk7lZgxU20Jk1PxjVSa/7+kLk+z4h9ZPQ==; 5:AF9kEwjiqnX2anjTkpiv7A/IyMs1M6XRrFw9vF86jlPCCMkT7bnZ4pQOI32uJA/RC736ZC9rvjXBBnF5t71V+nvpXvhhLMVpfebvAC89LG32rbW9ubdzcOdEYeJErdePr6+6MfN9e5k5Q26FJYzCZg==; 24:CMpEDl6YooSY1J7lr19TbXxQT96cZcALXSiC1OfoIXrDf+w5L2CHy56HCeffcoda588thqq9nP9AoOD/KSVsEFsljQZLxtUnhKnJNK0FnCE=; 7://rKdDs8qhyHme45MEH93h4SNhp6mxIvj7fw9Gg2xc1XA60VBxTZlNdgJKA+Fw4IXK+PEHcT+BKcY+n7/1+Rg2oijnU00suUtrEdbD219g1bfoXF11LBIR0r39k1BWCf3cS8jaYgEfR90ZRr2i53GqK8L0kzAm6cKSWg64gbnN726ArYFannKsjv6E/gLfOhQo+Zx/oOu9qXhhyX/QR9fn8sjLqN6wxDdJPps65J76s= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d4f98a9c-d6eb-4ea5-769f-08d5066b1fd7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR07MB1716; x-ms-traffictypediagnostic: AM4PR07MB1716: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB1716; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB1716; x-forefront-prvs: 0444EB1997 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(24454002)(189002)(199003)(377424004)(6506006)(5640700003)(189998001)(2900100001)(6436002)(66066001)(6486002)(2950100002)(966005)(6916009)(97736004)(99286003)(53936002)(6512007)(86362001)(229853002)(2501003)(230783001)(478600001)(5250100002)(76176999)(54356999)(6306002)(8936002)(6246003)(2351001)(316002)(53546010)(81156014)(81166006)(305945005)(8676002)(102836003)(3846002)(6116002)(68736007)(105586002)(7736002)(50986999)(106356001)(82746002)(25786009)(3280700002)(2906002)(101416001)(3660700001)(83716003)(36756003)(33656002)(5660300001)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1716; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4A5FCE1E81454F429CF8051BD6D8BF2B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2017 12:19:10.7337 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1716 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 12:19:15 -0000 VGhpcyBsYXRlc3QgdmVyc2lvbiBoYXMgZmV3IGlkbml0cyBhbmQgcmVhZGFiaWxpdHkgaW1wcm92 ZW1lbnRzLg0KDQpHLw0KDQpPbiAyOC8wOS8yMDE3LCAxMzo0MiwgInY2b3BzIG9uIGJlaGFsZiBv ZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzIGRpcmVjdG9yaWVzLg0KICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl IElQdjYgT3BlcmF0aW9ucyBXRyBvZiB0aGUgSUVURi4NCiAgICANCiAgICAgICAgICAgIFRpdGxl ICAgICAgICAgICA6IFVuaXF1ZSBJUHY2IFByZWZpeCBQZXIgSG9zdA0KICAgICAgICAgICAgQXV0 aG9ycyAgICAgICAgIDogSm9obiBKYXNvbiBCcnpvem93c2tpDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBHdW50ZXIgVmFuIERlIFZlbGRlDQogICAgCUZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0LTExLnR4dA0KICAgIAlQ YWdlcyAgICAgICAgICAgOiA5DQogICAgCURhdGUgICAgICAgICAgICA6IDIwMTctMDktMjgNCiAg ICANCiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGlzIGRvY3VtZW50IG91dGxpbmVzIGFuIGFwcHJv YWNoIHV0aWxpc2luZyBleGlzdGluZyBJUHY2IHByb3RvY29scw0KICAgICAgIHRvIGFsbG93IGhv c3RzIHRvIGJlIGFzc2lnbmVkIGEgdW5pcXVlIElQdjYgcHJlZml4IChpbnN0ZWFkIG9mIGENCiAg ICAgICB1bmlxdWUgSVB2NiBhZGRyZXNzIGZyb20gYSBzaGFyZWQgSVB2NiBwcmVmaXgpLiAgQmVu ZWZpdHMgb2YgdW5pcXVlDQogICAgICAgSVB2NiBwcmVmaXggb3ZlciBhIHVuaXF1ZSBzZXJ2aWNl IHByb3ZpZGVyIElQdjYgYWRkcmVzcyBpbmNsdWRlDQogICAgICAgaW1wcm92ZWQgaG9zdCBpc29s YXRpb24gYW5kIGVuaGFuY2VkIHN1YnNjcmliZXIgbWFuYWdlbWVudCBvbiBzaGFyZWQNCiAgICAg ICBuZXR3b3JrIHNlZ21lbnRzLg0KICAgIA0KICAgIA0KICAgIFRoZSBJRVRGIGRhdGF0cmFja2Vy IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0 Lw0KICAgIA0KICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBh dDoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy11bmlx dWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMTENCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVlLWlwdjYtcHJlZml4LXBlci1ob3N0 LTExDQogICAgDQogICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRm LXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0xMQ0KICAgIA0KICAgIA0KICAgIFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgIA0KICAgIEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICBmdHA6Ly9m dHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgdjZvcHMgbWFpbGluZyBsaXN0DQog ICAgdjZvcHNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzDQogICAgDQoNCg== From nobody Thu Sep 28 05:29:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41031346F8 for ; Thu, 28 Sep 2017 05:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_AVSkbrSOPH for ; Thu, 28 Sep 2017 05:29:46 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758FE132D79 for ; Thu, 28 Sep 2017 05:29:46 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l4so857379ywa.6 for ; Thu, 28 Sep 2017 05:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=waojmvryCJAIfi1RVw/MG+EAvUJ+h4D6wSVIXqUijtw=; b=hbz4LW6CGWvhEYxFaB2AXowPQvVZRXRU8Z1QwWgSI5Nbh9+E0P5Qnj145NbNzSOiuq XnRiP3dHeQyfSiOZ9xMNCodnZbeOcnDzl1E6yswz0l3P/hp7R74y248y9UgSikfQJsOo JLUlTBGn3tZ4/oxod28IRVDFb9sPaZx8RjjEry588J9EkHzkZ6+hi9ttNHbkblt05Fq1 8BpEGTDtepF0VY+XrZ5qERJezIYr4RvUzK4NPHSYSwL3MVY/sfuWjhYVlRqkU1d7UMtz kXBklnK0yzGA4kyzL8MmfniAn0FHVqKPtpWk+chuEUAU66u9NpQ9UCdj3UFIidB6LQGD Tzkw== 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=waojmvryCJAIfi1RVw/MG+EAvUJ+h4D6wSVIXqUijtw=; b=rhhmRwtv9/CwigZo08W8PqMQhHoklw0JS2UB+hStKOj/WrwpUxph07gRFQiDVSV/Y8 WOEcvLKKd/gvTtEJHF36h4l/sYzhdnY4J78R5hkjZxr7Al/m7meypCsVbL/cdUla1+LX s39XMppOZUrnT0GSDOzw0NHp5/9v/fjxLc22vugFMHZ25wvUYzu1pvMTMZ1u35luErfU NFSKFhii467bn0CLNaNPFacrNpNDs3zjqN5y4gfe+h8CcdV4toTLZICGYnIxDiDVyMaV n1wzzcMW56TrYY2+9ET/ILA6JBVAKUoomrjNGnDoCRE0FevuKG/q3mAn8iiLD/cO42cS dePQ== X-Gm-Message-State: AHPjjUg2N6ShOJBnLup5YNiEkqjYk6onrfW9B756xbPQX7XH4gE+A0/G o71/DcBLt95CqIcZJzPTNRRGewL9QwTbHLuhaec= X-Google-Smtp-Source: AOwi7QAIS/fI51p+F/3dht1oWPVzZ1q7dlIEQiPY4U14pnjoFYSJpT2Bpv5c0+1ZYo43vLBxPQoPzg1NO1Y68Y9IuzM= X-Received: by 10.13.202.134 with SMTP id m128mr3380038ywd.42.1506601785689; Thu, 28 Sep 2017 05:29:45 -0700 (PDT) MIME-Version: 1.0 References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> In-Reply-To: From: Ca By Date: Thu, 28 Sep 2017 12:29:34 +0000 Message-ID: To: Erik Kline , "Rajiv Asati (rajiva)" Cc: IPv6 Ops WG Content-Type: multipart/alternative; boundary="001a114f1c38410bde055a3f1035" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 12:29:49 -0000 --001a114f1c38410bde055a3f1035 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 28, 2017 at 2:44 AM Rajiv Asati (rajiva) wrote: > > Do any other mobile operating systems do DHCPv6 on the GTP tunnel? It's > been > > > I could double check CPE routers such as ISR819 with LTE WAN uplink > support DHCPv6. > > Separately, from PGW point of view, DHCPv6 within an APN seems to be > supported - > > > https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/20/P-GW/b_20_PGW_= Admin/b_19_PGW_Admin_chapter_010.html#task_309eb986-4510-425a-81ed-833018e7= 0921 > > // > The system can be configured to use the Dynamic Host Control Protocol > (DHCP) for IPv6 to enable the DHCP servers to pass the configuration > parameters such as IPv6 network addresses to IPv6 nodes. DHCPv6 > configuration is done within an APN. > // > > I may be wrong here, but these instruction likely do not allow the client mobile to run dhcpv6 What is likely happening here is the Cisco gateway is running SLAAC to the mobile but selecting / registering the addresses from an external dhcpv6 server. Here is the hint from the doc that the gateway is the dhcpv6 client, not the mobile, and thus no support for dhcpv6 / map to the client ( i may be wrong) =E2=80=9C - client identifier command configures the client-identifier, which is sent to the external DHCP server. By default, IMSI is sent. Another available option is MSISDN. - =E2=80=9C > > I have been wondering about asking for an API to the modem to query > for the 3GPP release number of the network as a hint for expected > capabilities, but that kinda seems both excessive and like a layering > > > Given all the thing that get queried and fetched by apps, fetching the > rel# being used (assuming available) would add a drop to the ocean. :) > > Cheers, > Rajiv Asati > Distinguished Engineer, Cisco Services > > > On Sep 28, 2017, at 11:06 AM, Erik Kline wrote: > > On 28 September 2017 at 17:53, Mikael Abrahamsson > wrote: > > On Thu, 28 Sep 2017, Erik Kline wrote: > > > I can just feel all the "android and dhcpv6" screeds being written right > > now... > > > > Do any other mobile operating systems do DHCPv6 on the GTP tunnel? It's > been > > too many years since I last looked at GTP packet traces to remember if th= is > > was done or not. > > > I've no idea. Nor do I know what might happen to various networks if > DHCPv6 requests were to be made on the mobile interface (even if the O > bit /were/ observed to be set). The stories of billing system crashes > and so on from the early days of v6 on mobile leave me somewhat > suspicious. > > I have been wondering about asking for an API to the modem to query > for the 3GPP release number of the network as a hint for expected > capabilities, but that kinda seems both excessive and like a layering > violation. ;-) > > _______________________________________________ > 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 > --001a114f1c38410bde055a3f1035 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Sep 28, 2017 = at 2:44 AM Rajiv Asati (rajiva) <raj= iva@cisco.com> wrote:

Do any other mobile operating systems do DHCPv6= on the GTP tunnel? It's been

I could double check CPE routers such as ISR819 with LTE WAN uplink = support DHCPv6.=C2=A0

Separately, from PGW point of view, DHCPv6 within an APN seems to be s= upported -=C2=A0


//
The system can be= configured to use the Dynamic Host Control Protocol (DHCP) for IPv6 to ena= ble the DHCP servers to pass the configuration parameters such as IPv6 netw= ork addresses to IPv6 nodes. DHCPv6 configuration is done within an APN.
//


I may be wrong here, but these instruction likely do not allow the client = mobile to run dhcpv6

Wha= t is likely happening here is the Cisco gateway is running SLAAC to the mob= ile but selecting / registering the addresses from an external dhcpv6 serve= r.=C2=A0

Here is the hin= t from the doc that the gateway is the dhcpv6 client, not the mobile, and t= hus no support for dhcpv6 / map to the client ( i may be wrong)

=E2=80=9C

  • client identifier=C2=A0command config= ures the client-identifier, which is sent to the external DHCP server. By d= efault, IMSI is sent. Another available option is MSISDN.

  • =E2=80=9C





I have been wondering about asking for an API t= o the modem to query
for the 3GPP release number of the network as a hint for expected
capabilities, but that kinda seems both excessive and like a layering

Given all the thing that get queried and fetched by apps, fetching the rel#= being used (assuming available) would add a drop to the ocean. :)

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services


On Sep 28, 2017, at 11:06 AM, Erik Kline <ek@google.com> wrote:

On 28 September 2017 at 17:53, Mikael Abrahamsson <swmike@swm.pp.se> wrote:=
On Thu, 28 Sep 2017, Erik Kline wrote:

I can just feel all the "android and d= hcpv6" screeds being written right
now...


Do any other mobile operating systems do DH= CPv6 on the GTP tunnel? It's been
too many years since I last looked at GTP p= acket traces to remember if this
was done or not.

I've no idea.=C2=A0 Nor do I know what might happen to various ne= tworks if
DHCPv6 requests were to be made on the mobile interface (even if the = O
bit /were/ observed to be set).=C2=A0 The stories of billing system c= rashes
and so on from the early days of v6 on mobile leave me somewhat
suspicious.

I have been wondering about asking for an API to the modem to query
for the 3GPP release number of the network as a hint for expected
capabilities, but that kinda seems both excessive and like a layering=
violation. =C2=A0;-)
_______________________________________________
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
--001a114f1c38410bde055a3f1035-- From nobody Thu Sep 28 05:47:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C67B134703 for ; Thu, 28 Sep 2017 05:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btgroupcloud.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5v89pA1N9jm for ; Thu, 28 Sep 2017 05:47:47 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [62.239.224.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7651345AE for ; Thu, 28 Sep 2017 05:47:46 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.bt.com (10.187.98.13) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 28 Sep 2017 13:47:49 +0100 Received: from smtpe1.intersmtp.com (10.187.98.12) by EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 28 Sep 2017 13:47:43 +0100 Received: from EUR02-VE1-obe.outbound.protection.outlook.com (213.199.154.53) by smtpe1.intersmtp.com (62.239.224.236) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 28 Sep 2017 13:48:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=BTGroupCloud.onmicrosoft.com; s=selector1-bt-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U0+xc1s2UwiuRjk05UPP/Z//SNTpbRQ07ve89FDrBwI=; b=oLCN8N3sj2aUgJxPJxfLTnX/AIxVXs/StCjaIyfhE18juBxj+Do3i1wfBuKkaUvsXj9GbekEIJP3e3aYRA1AjMQOyWfgsCk2vsGv82SruEm9RGRcUfpnpiZcUV4zJZFGDwN1q5vH1mEfl16nP1PDzhqh6DN3113/iiXnXzfEQUc= Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM (10.167.24.147) by LO1P123MB0610.GBRP123.PROD.OUTLOOK.COM (10.167.28.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 28 Sep 2017 12:47:39 +0000 Received: from LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) by LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM ([10.167.24.147]) with mapi id 15.20.0077.016; Thu, 28 Sep 2017 12:47:39 +0000 From: "Heatley,N,Nick,TQB R" To: Lorenzo Colitti , Fred Baker CC: Ca By , IPv6 Ops WG , james woodyatt Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) Thread-Index: AdM16ZBiVXxOrrPASdi8hSWu5DH/5gBKSg6AAA4804AAHACmgAAFqaklAAPsRIAAAeINAAAGsJeAAAUgy4AADyAYuA== Date: Thu, 28 Sep 2017 12:47:39 +0000 Message-ID: References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> , <0C14ACDC-DBDD-4D8C-BBBD-60CA8E0982A2@gmail.com> In-Reply-To: <0C14ACDC-DBDD-4D8C-BBBD-60CA8E0982A2@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nick.heatley@bt.com; x-originating-ip: [40.68.209.210] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LO1P123MB0610; 6:w7ywcZ4JpwuUidKESAaYZ99WW6ufygyxBVZ/RJ21cTafp/pKEZ26nLP/OXKiCwXM4Xuz/OGIaFDROndIbwyG9Z+2eWj1wHiszV8INrxR06GO+Z608aybCSVkOPkxF56HJHpI6P9uoLn/d4D9o5a+GfUlwd7Ydkpn3evnAk73SV7KgOgEtqmZwB5Jz5gIFEcD02iv/1aMIsK9l/UvF1zGt1DZ+7Ud8J2HY/jLygyTNc7HCLzjQwBKiJbVlMJ4UOBiv5xgVNv7drfOIAHxHgLKMA4Ywk98DG1OivYOZmCbwcpN8ehgSqQSQM3TtP28P3KJoGlgCrC3gJNwD80XLeHW1A==; 5:TD+xqtFAQyPpmsnKane3sBLMNx0etnPBV++6LDNepWInNWWPTixOMm3vN5tpygzqFfxO+TkuZ/MzifPuT2Uuk76nkO7LxAxgYdUzhFUFJdFYppXH/oe41ZQ45dUmAScN1Sx3eZVGqeMWBcvc9BoKqQ==; 24:MJnfO0ChhcV3VBvqmSprG6QSptmEjFaDNFVCh58uJBmgItD1nDHfoISkpfwTx295CEjnJZZMc1E5k3RYQ9ZFW65B1AloRHViv0lbMtmA0u8=; 7:Wl3hTX4XQEPY8QWXmaFDyghW6+WUSD9vNyYG1w8Fao9NxG9L3+RiAOSLYx/MkG4fqtEAdJhp/oKjBC3o72ogPGX3tJsr2B9rJXeoYTV8MKEdLVNOGZKBdopM3TRYi5gSKtxXz0ebdQeqbVpxAzPKuRkVApTqq2PWnY56voCaGcNlOneulm1mc0EEKAr4CEsPPSRkM4chxI3Uo3gouJScga/nqdFe5qU51SiONsuwwCg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0b9db5dc-e7ba-4ac2-6249-08d5066f1a48 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:LO1P123MB0610; x-ms-traffictypediagnostic: LO1P123MB0610: x-antispam-2: 1 x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(920507026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:LO1P123MB0610; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:LO1P123MB0610; x-forefront-prvs: 0444EB1997 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(24454002)(189002)(377454003)(199003)(33656002)(5660300001)(25786009)(3660700001)(3846002)(3280700002)(102836003)(54906003)(6116002)(2906002)(74316002)(106356001)(110136005)(34040400001)(7736002)(39060400002)(53936002)(93886005)(6246003)(53546010)(55016002)(86362001)(236005)(189998001)(6306002)(54896002)(9686003)(229853002)(101416001)(7696004)(478600001)(66066001)(4326008)(6506006)(50986999)(76176999)(54356999)(14454004)(6436002)(8936002)(8676002)(105586002)(45080400002)(81166006)(81156014)(316002)(2900100001)(2950100002)(77096006)(606006)(68736007)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO1P123MB0610; H:LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LO1P123MB0116446311598298D86DCD92EA790LO1P123MB0116GBRP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Sep 2017 12:47:39.3006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO1P123MB0610 Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 12:47:50 -0000 --_000_LO1P123MB0116446311598298D86DCD92EA790LO1P123MB0116GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What enterprises need from us is a vision of interconnected networks. In other words, how do we bring on the next 4 billion end points, and what = are the recommended steps to get there. That is what i thought this BCP discussion should be judged against. The pr= otocol purity stuff, in the absence of running code or real end to end solu= tions, its a real turn off. It is footnote stuff. If all mobile operators moved to ipv6-only with the hacks we have discussed= , is that the best thing we can do currently and better than do nothing? If= yes then we have a BCP. Nick Get Outlook for Android From: Fred Baker Sent: Thursday, September 28, 2017 5:15:41 AM To: Lorenzo Colitti Cc: Ca By; Heatley,N,Nick,TQB R; IPv6 Ops WG; james woodyatt Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard= instead of info) > On Sep 27, 2017, at 7:48 PM, Lorenzo Colitti wrote: > > On Thu, Sep 28, 2017 at 8:37 AM, Ca By wrote: > And, i will reinterate an important point Nick made. The majority of traf= fic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And a sliver= of traffic requires 464XLAT or 4464. Those numbers are all growing in the= right direction, more e2e v6. > > What he said. For many operators, the choice was between a) 60% (and grow= ing) native IPv6 traffic, 30% NAT64 traffic, and 5% NAT464 traffic, and b) = 100% NAT44 traffic. And, of course, as IPv6 grows, the reason to translate it diminishes. Frankly, chair hat off, I'm happy enough seeing IPv6-only domains and 464XL= AT where it has to be. The thing for us to focus on right now, I think, is = enterprise deployment - at least at their front doors, their web sites and = their mail servers. The less folks need IPv4 to talk with their business pa= rtners, the less the iron lungs are necessary. From my perspective, that pr= oblem eventually takes care of itself. Metcalf's law: the value of a networ= k is a function of the number of it's users. --_000_LO1P123MB0116446311598298D86DCD92EA790LO1P123MB0116GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
What enterprises need from us is a vision of interconnected networks.
In other words, how do we bring on the next 4 billion end points, and what = are the recommended steps to get there.

That is what i thought this BCP discussion should be judged against. The pr= otocol purity stuff, in the absence of running code or real end to end solu= tions, its a real turn off. It is footnote stuff.
If all mobile operators moved to ipv6-only with the hacks we have discussed= , is that the best thing we can do currently and better than do nothing? If= yes then we have a BCP.
Nick

From: Fred Ba= ker <fredbaker.ietf@gmail.com>
Sent: Thursda= y, September 28, 2017 5:15:41 AM
To: Lorenzo C= olitti
Cc: Ca By; He= atley,N,Nick,TQB R; IPv6 Ops WG; james woodyatt
Subject: Re: = [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of i= nfo)
 


> On Sep 27, 2017, at 7:48 PM, Lorenzo Colitti <lorenzo@google.com>= ; wrote:
>
> On Thu, Sep 28, 2017 at 8:37 AM, Ca By <cb.list6@gmail.com> wrot= e:
> And, i will reinterate an important point Nick made. The majority of t= raffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And a sli= ver of traffic requires 464XLAT or 4464.  Those numbers are all growin= g in the right direction, more e2e v6.
>
> What he said. For many operators, the choice was between a) 60% (and g= rowing) native IPv6 traffic, 30% NAT64 traffic, and 5% NAT464 traffic, and = b) 100% NAT44 traffic.

And, of course, as IPv6 grows, the reason to translate it diminishes.

Frankly, chair hat off, I'm happy enough seeing IPv6-only domains and 464XL= AT where it has to be. The thing for us to focus on right now, I think, is = enterprise deployment - at least at their front doors, their web sites and = their mail servers. The less folks need IPv4 to talk with their business partners, the less the iron lungs ar= e necessary. From my perspective, that problem eventually takes care of its= elf. Metcalf's law: the value of a network is a function of the number of i= t's users.

--_000_LO1P123MB0116446311598298D86DCD92EA790LO1P123MB0116GBRP_-- From nobody Thu Sep 28 05:50:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933B713304E for ; Thu, 28 Sep 2017 05:50:40 -0700 (PDT) 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, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2i6-vK3-W0dt for ; Thu, 28 Sep 2017 05:50:38 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A186132811 for ; Thu, 28 Sep 2017 05:50:38 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4CC8FB1; Thu, 28 Sep 2017 14:50:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506603036; bh=ju3RfT+HZkahX/4naVmICtln7Kb68hSvLbgjr0hhiU8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=pVphlI62rnqTtoarmjDWswjrgYXUUeKE3xVvevi8qRV0k2G0i6JAtjc3rJGH7IG+D z51rHv13zGPjfp/02y/hI8XnE3tXHEL74BlyYin7WY6nGyoyLQbcr101EYy4UxOjfc tPpogEkXSHdIoKnTNcU0SVYJIKiw8byX7dvumbKo= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 34992AF; Thu, 28 Sep 2017 14:50:36 +0200 (CEST) Date: Thu, 28 Sep 2017 14:50:36 +0200 (CEST) From: Mikael Abrahamsson To: Ca By cc: IPv6 Ops WG In-Reply-To: Message-ID: References: <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-137064504-14900332-1506603036=:18564" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 12:50:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-14900332-1506603036=:18564 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 28 Sep 2017, Ca By wrote: > I may be wrong here, but these instruction likely do not allow the client > mobile to run dhcpv6 https://tools.ietf.org/html/rfc6653 There is also this gem that I found: http://www.google.sr/patents/US9491036 Wonder if that's causing a problem in implementing DHCPv6-PD in SPGW. Anyhow, TS 23.401 says: "The UE uses DHCPv6 to request additional IPv6 prefixes (i.e. prefixes in addition to the default prefix) from the PDN GW after completing stateless IPv6 address autoconfiguration procedures. The UE acts as a "Requesting Router" as described in RFC 3633 [21] and inserts one or more IA_PD option(s) into a DHCPv6 Solicit message sent from the UE to the PDN GW. The PDN GW acts as the DHCP server and fulfils the role of a "Delegating Router" according to RFC 3633 [21]. The UE optionally includes the RAPID_COMMIT option in the DHCPv6 Solicit message to trigger two-message DHCPv6 procedure instead of the four-message DHCPv6 procedure. The UE shall include OPTION_PD_EXCLUDE option code in an OPTION_ORO option to indicate support for prefix exclusion. In response to the DHCPv6 Solicit message, the UE receives a DHCPv6 Reply message with one or more IA_PD prefix(es) for every IA_PD option that it sent in the DHCPv6 Solicit message. The PDN GW delegates a prefix excluding the default prefix with help of OPTION_PD_EXCLUDE. Prefix exclusion procedures shall follow IETF RFC 6603 [70]." Seems to me that in the standardization documents, it's perfectly fine for UE to request prefix using standard DHCPv6-PD, and this is the way it was intended to be done. In 5.3.1.2.3 there is also talk about stateless DHCPv6: "5.3.1.2.3 IPv6 parameter configuration via stateless DHCPv6 The UE may use stateless DHCPv6 for additional parameter configuration. The PDN GW acts as the DHCP server. When PLMN based parameter configuration is used, the PDN GW provides the requested parameters from locally provisioned database. When external PDN based parameter configuration is used, the PDN GW obtains the requested configuration parameters from the external PDN as described in the previous clauses. When the PDN GW acts as a DHCPv6 server towards the UE, the PDN GW may act as DHCPv6 client towards the external PDN to request the configuration parameters for the UE. If RADIUS or Diameter is used towards the external PDN as described in TS 29.061 [38], the requested configuration parameters can be fetched as part of these procedures." There is also this overview text: Both EPS network elements and UE may support the following mechanisms: a. IPv4 address allocation and IPv4 parameter configuration after the attach procedure via DHCPv4 according to RFC 2131 [19] and RFC 4039 [25]; b. IPv6 parameter configuration via Stateless DHCPv6 according to RFC 3736 [20]. c. Allocation of IPv6 prefixes using DHCPv6 according to RFC 3633 [21]. So it's pretty obvious that DHCPv6 is a thing in 3GPP networks, but it's optional to implement. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-14900332-1506603036=:18564-- From nobody Thu Sep 28 06:08:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C26134725 for ; Thu, 28 Sep 2017 06:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Px56nUSjKUgu for ; Thu, 28 Sep 2017 06:08:20 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DB4133044 for ; Thu, 28 Sep 2017 06:08:19 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1774840ECF for ; Thu, 28 Sep 2017 15:08:18 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 06AC040BA0; Thu, 28 Sep 2017 15:08:18 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id 038AA76570; Thu, 28 Sep 2017 15:08:18 +0200 (CEST) Date: Thu, 28 Sep 2017 15:08:17 +0200 From: Gert Doering To: Mark Andrews Cc: Lorenzo Colitti , "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt Message-ID: <20170928130817.GE45648@Space.Net> References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170928030630.DD2D08867238@rock.dv.isc.org> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 13:08:22 -0000 Hi, On Thu, Sep 28, 2017 at 01:06:30PM +1000, Mark Andrews wrote: > Dual stack was being delivered by some operators before DNS64 and > NAT64 even existed. Which mobile(!) operator did that? My recollection was "T-Mobile USA was the first mobile carrier of all to deliver IPv6, and they did IPv6-only with DNS64/NAT64". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Sep 28 07:05:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABC3133055 for ; Thu, 28 Sep 2017 07:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvXxyGpsBfAD for ; Thu, 28 Sep 2017 07:05:41 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BADA1321A1 for ; Thu, 28 Sep 2017 07:05:41 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id w9so1058657ywi.11 for ; Thu, 28 Sep 2017 07:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zRplD3vQUGbDkBNGCoT4VZOVSpircJjvooB9CijcSJw=; b=GFHX/+P0Tp5ZTmUm0pA78P/HVLuu8a4FqT95aQ+F4UCVxD/tSvXKV+3e8LrlybW9Gg kGT9PqhHrHPDWm2BCW8rvrB7Hk9L6dOCAqHRTABSNeDG1Zx23k2wvxj1ZHEF6sLRGa6z kRxKqobm5gufgW6IqpF87IcCpZPKQ0m+1u6aip5vWte5Pyl3Iu+hajDzOHpeoGmHVkGK Ox+ip0jeRnwi9bjdbkK8kO1dZb7T3y3qINWACkRj6Y6oni6cc6MWFQgZAk8rpwZkqP/y fuYsXzhVm1ygl1g0N2X2MDDkBgeN5XYYhTBuew1gFPTh/saOL+TXu5o6EaaU64fPKXd9 kezw== 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=zRplD3vQUGbDkBNGCoT4VZOVSpircJjvooB9CijcSJw=; b=gpXM+5rBiTeFkuqyIQIC/Dh4cC72vICs1/zrbi2M6qqGmrmRabVy8gq2c3Q2U5y5DM KSED8LVyK4MZSxxvCoo8cMPO6on2sA5+BDHNyJZ01690xigipQNsOuwsROiBBu1bjTyQ WW3Gh5lfJKyyzEfSzck+yS74SKTR7NbN8BM7rUP/am9T1lSZMNUUmWWZW/L7QBWYaDnZ 5AB3Pa21Wr7fNg46jnkNQ18mgCNk0sN4f84DV+Il+SNZP1fHuiAQa7PcE9i1mNmXstLp TjHWtANLfNRHq0uwKXkDv3ZIkIbH9YGqUhz35LqgZvRav05e0MZfuWEblF+/QJ3HviuC t4xg== X-Gm-Message-State: AHPjjUj/bPijHIivj3axxwcPgdqhbNKRSqY+r+vsAxHw5sMEdf0oCpD2 EsnD4XIUlCNvoS0lOrj3/sFXO7M1T7j3tOqLPz0= X-Google-Smtp-Source: AOwi7QCJKEYQMfZuESCqU6Idskt8rQHvcpJS99q4/ZL+VQuJle2oFWXQ02hbshAg3oFH6a6H70DMy/o2urtIJVFayL0= X-Received: by 10.13.202.134 with SMTP id m128mr3610855ywd.42.1506607540411; Thu, 28 Sep 2017 07:05:40 -0700 (PDT) MIME-Version: 1.0 References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928130817.GE45648@Space.Net> In-Reply-To: <20170928130817.GE45648@Space.Net> From: Ca By Date: Thu, 28 Sep 2017 14:05:29 +0000 Message-ID: To: Gert Doering , Mark Andrews Cc: "Heatley, N, Nick, TQB R" , IPv6 Ops WG , james woodyatt Content-Type: multipart/alternative; boundary="001a114f1c38432249055a4067a6" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 14:05:48 -0000 --001a114f1c38432249055a4067a6 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 28, 2017 at 6:08 AM Gert Doering wrote: > Hi, > > On Thu, Sep 28, 2017 at 01:06:30PM +1000, Mark Andrews wrote: > > Dual stack was being delivered by some operators before DNS64 and > > NAT64 even existed. > > Which mobile(!) operator did that? > > My recollection was "T-Mobile USA was the first mobile carrier of all to > deliver IPv6, and they did IPv6-only with DNS64/NAT64". > Verizon Wireless was before T-Mobile with a large scale production deployment, they were dual-stack. > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114f1c38432249055a4067a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Sep 28, 2017 = at 6:08 AM Gert Doering <gert@space.ne= t> wrote:
Hi,

On Thu, Sep 28, 2017 at 01:06:30PM +1000, Mark Andrews wrote:
> Dual stack was being delivered by some operators before DNS64 and
> NAT64 even existed.

Which mobile(!) operator did that?

My recollection was "T-Mobile USA was the first mobile carrier of all = to
deliver IPv6, and they did IPv6-only with DNS64/NAT64".

=C2=A0Verizon Wi= reless was before T-Mobile with a large scale production deployment, they w= ere dual-stack.=C2=A0


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

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.:= DE813185279

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--001a114f1c38432249055a4067a6-- From nobody Thu Sep 28 07:09:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2848A13314B for ; Thu, 28 Sep 2017 07:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 vYtmT31jBhEw for ; Thu, 28 Sep 2017 07:09:03 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF6C133079 for ; Thu, 28 Sep 2017 07:09:03 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id AAF53A39 for ; Thu, 28 Sep 2017 14:09:02 +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 rRENYMouh7NV for ; Thu, 28 Sep 2017 09:09:02 -0500 (CDT) Received: from mail-wr0-f198.google.com (mail-wr0-f198.google.com [209.85.128.198]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 3D6DDA0D for ; Thu, 28 Sep 2017 09:09:02 -0500 (CDT) Received: by mail-wr0-f198.google.com with SMTP id z46so2403890wrz.2 for ; Thu, 28 Sep 2017 07:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h+/DHnccxPNejF+xCXq9UrQdMByBweWPXEuJIzQwBfQ=; b=CkLruguzMIFuJYbKI8uu8tgGWr/9uLWeyr+maqlGKtTbqFelPwGR47QvnfcM8Ms2Sj eZe9XakTx6Q9NwV++T+KbtgqLEu9Wyuxthbx+r8db43cerH9FxwBG4s5EMWGx6N8pdQA XbTsdmiu4oY26FlRMMv6rEp13RVcUHLmG5Dga72SZr9VlbW0abGFIK6tzred1GdkZx0A X72Hn9KH52hRzRlbYtj7cH+tttijQ+2zjLaHzIhKE2MGu8QX/jPMjqjtoHoR7OqpEbTh fUSHQZWvxPnSDBPO1TQ9ITaWN2zLoty55ypt8Z78gbkNdudraDfhvQAKCZklNWbOu6Hr 5xtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h+/DHnccxPNejF+xCXq9UrQdMByBweWPXEuJIzQwBfQ=; b=Bob9gtL748k7mfT94GuRxHep7gpFI2TjYfb462KkCvTs9zIh/FDkZ0YjPkxqXY2zvk 74DumwP1vwdvhKvZ4jxQL7bPQVd3WQ4Eu1fb0g7FbkPZPbL7zMLHCq7GcIwzp2tZtqja 7pox0ZRXK0KgIP1r4gUwQiTEo2aj5bkwVdLxSdbr7JAKadEftt+3smHULr3sCuge85BX 6+GTU2uXnR6sA/SmCcn/qAMRXX6PXVzzOIhFbu0+UXvR+yZA11pbfLIWWkTNYCgeqxU6 7RPhPUsGmN2EZLHX3FuyO7IMA9FsA4w+LlzwiJvzV7gOOcWpZ1zdOkm4Bcj7pVs8Gxrg 7EuA== X-Gm-Message-State: AHPjjUg4Et8uDBgNt1NWrYq6JcAhGOsro6ipKMw84OBuVPuh93PZTsUq WltBcI3SF02tFecoj900QJtFKy9zfYUtqjcBby9JvI8/z0ASFhqTh30mJibuaMgfhU+T9cLmOjH gtuRx+88yNkQoPNq/cQn1ZogIVA== X-Received: by 10.46.18.71 with SMTP id t68mr2068086lje.132.1506607740935; Thu, 28 Sep 2017 07:09:00 -0700 (PDT) X-Google-Smtp-Source: AOwi7QCnY11F9lbXiaGbgUcM8hajp79NSH6hQWSNo2b0b0bE2i3+L87rNAeEpHqgiSdgWuHqIs5DpNQV1+llx8ReCl0= X-Received: by 10.46.18.71 with SMTP id t68mr2068080lje.132.1506607740715; Thu, 28 Sep 2017 07:09:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Thu, 28 Sep 2017 07:08:59 -0700 (PDT) In-Reply-To: <504C386B-260F-452E-8195-3A6E3D3BF40B@nokia.com> References: <150659896337.13704.16305576151522889075@ietfa.amsl.com> <504C386B-260F-452E-8195-3A6E3D3BF40B@nokia.com> From: David Farmer Date: Thu, 28 Sep 2017 09:08:59 -0500 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a114cf2d6339127055a407313" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 14:09:07 -0000 --001a114cf2d6339127055a407313 Content-Type: text/plain; charset="UTF-8" I like most of the changes, however I find the following bullet somewhat confusing; o Maximum IPv6 Router Advertisement Interval = 300s (or when battery consumption is a concern then a MinRtrAdvInterval of 514 seconds (1/7 of an hour) is better according RFC7772 [RFC7772]). It starts out talking about the *Maximum* Router Advertisement Interval, then with little explanation shifts to talking about the *Minimum* Router Advertisement Interval, I fear this will easily confuse any casual readers. Furthermore, the IPv6 router implementations I'm familiar with, don't allow you to directly set the Minimum Router Advertisement Interval, it is automatically computed as 75% of the Maximum Router Advertisement Interval, as recommended in RFC4861. Therefore, in such implementations the Maximum Router Advertisement Interval would need to be set at 685 seconds. Also, as Lorenzo pointed out, there is no discussion of IPv6 Router LifeTime, which is also discussed in RFC7772. I suggest the following; o Maximum IPv6 Router Advertisement Interval = 300s (or when battery consumption is a concern 685s, see Note below) o IPv6 Router LifeTime = 3600s (see Note below) ... Note: When servicing large numbers of battery powered devices, RFC7772 recommends a maximum of 7 RAs per hour and a 45-90 minute IPv6 Router Lifetime. To achieve a maximum of 7 RAs per hour a MinRtrAdvInterval of 514 seconds (1/7 of an hour) is needed, many router implementation determine MinRtrAdvInterval = 0.75 * MaxRtrAdvInterval, as recommended in RFC4861 section 6.2.1. Therefore, a Maximum IPv6 Router Advertisement Interval of 685s is recommended. As for the recommended IPv6 Router Lifetime, since this technique requires that the RAs are sent using the link-layer unicast address of the subscriber, the concerns over multicast delivery discussed in RFC7772 are already mitigated, therefore the above suggestion of 3600s (an hour) is deemed sufficient for this use case. Thanks. On Thu, Sep 28, 2017 at 7:19 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) < gunter.van_de_velde@nokia.com> wrote: > This latest version has few idnits and readability improvements. > > G/ > > On 28/09/2017, 13:42, "v6ops on behalf of internet-drafts@ietf.org" < > v6ops-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : draft-ietf-v6ops-unique-ipv6-p > refix-per-host-11.txt > Pages : 9 > Date : 2017-09-28 > > Abstract: > This document outlines an approach utilising existing IPv6 protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on shared > network segments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv > 6-prefix-per-host/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-pre > fix-per-host-11 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-uniqu > e-ipv6-prefix-per-host-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ip > v6-prefix-per-host-11 > > > 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 > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --001a114cf2d6339127055a407313 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like most of the changes, however I find the following b= ullet somewhat confusing;

o=C2=A0 Maximum IPv6 Router Adverti= sement Interval =3D 300s (or when battery
=C2=A0 =C2=A0consumptio= n is a concern then a MinRtrAdvInterval of 514 seconds
=C2=A0 =C2= =A0(1/7 of an hour) is better according RFC7772 [RFC7772]).
=C2=A0
It starts out talking about the *Maximum* Router A= dvertisement Interval, then with little explanation shifts to talking about= the *Minimum* Router Advertisement Interval, I fear this will easily confu= se any casual readers.=C2=A0 Furthermore, the IPv6 router implementations I= 'm familiar with, don't allow you to directly set the Minimum Route= r Advertisement Interval, it is automatically computed as 75% of the Maximu= m Router Advertisement Interval,=C2=A0as recommended in RFC4861. Therefore,= in such implementations the Maximum Router Advertisement Interval would ne= ed to be set at 685 seconds.

Also, as Lorenzo poin= ted out, there is no discussion of=C2=A0IPv6 Router LifeTime, which is also discussed in RFC7772.= =C2=A0

I suggest the following;

o=C2=A0 Maximu= m IPv6 Router Advertisement Interval =3D 300s (or when battery
=C2=A0 =C2=A0 consumption is a concern 685s, see N= ote below)

o=C2=A0 IPv6 Router LifeTime =3D 3600s (see= Note below)

...

Note: Whe= n servicing large numbers of battery powered devices, RFC7772 recommends a = maximum of 7 RAs per hour and a 45-90 minute IPv6 Router Lifetime.=C2=A0To achieve a maxim= um of=C2=A07 RAs per hour a MinRtrAdvInterval=C2=A0of 514 seconds (1/7 of a= n hour) is needed, many router implementation determine MinRtrAdvInterval = =3D 0.75 * MaxRtrAdvInterval, as recommended in RFC4861 section 6.2.1. Ther= efore, a Maximum IPv6 Router Advertisement Interval of 685s is recommended.= As for the recommended IPv6 Router Lifetime, since this technique requires that the RAs a= re sent using the link-layer unicast address of the subscriber, the concern= s over multicast delivery discussed in RFC7772 are already mitigated, there= fore the above suggestion of 3600s (an hour) is deemed sufficient for this = use case.

Thanks.

On Thu, Sep 28, 2017 at= 7:19 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <<= a href=3D"mailto:gunter.van_de_velde@nokia.com" target=3D"_blank">gunter.va= n_de_velde@nokia.com> wrote:
This latest version has few idnits and readabilit= y improvements.

G/

On 28/09/2017, 13:42, "v6ops on behalf of internet-drafts@ietf.org" <v6ops-bounces@iet= f.org on behalf of internet-drafts@ietf.org> wrote:


=C2=A0 =C2=A0 A New Internet-Draft is available from the on-line Internet-D= rafts directories.
=C2=A0 =C2=A0 This draft is a work item of the IPv6 Operations WG of the IE= TF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0: Unique IPv6 Prefix Per Host
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: John Jason Brzozowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gunter Van De Velde
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-v6ops-unique-ipv6-prefix-per-host-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-09-28

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document outlines an approach utilising exi= sting IPv6 protocols
=C2=A0 =C2=A0 =C2=A0 =C2=A0to allow hosts to be assigned a unique IPv6 pref= ix (instead of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0unique IPv6 address from a shared IPv6 prefix).= =C2=A0 Benefits of unique
=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 prefix over a unique service provider IPv6 = address include
=C2=A0 =C2=A0 =C2=A0 =C2=A0improved host isolation and enhanced subscriber = management on shared
=C2=A0 =C2=A0 =C2=A0 =C2=A0network segments.


=C2=A0 =C2=A0 The IETF datatracker status page for this draft is:
=C2=A0 =C2=A0 https://= datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-= host/

=C2=A0 =C2=A0 There are also htmlized versions available at:
=C2=A0 =C2=A0 https://too= ls.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-11<= /a>
=C2=A0 =C2=A0 h= ttps://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6= -prefix-per-host-11

=C2=A0 =C2=A0 A diff from the previous version is available at:
=C2=A0 =C2=A0 htt= ps://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pre= fix-per-host-11


=C2=A0 =C2=A0 Please note that it may take a couple of minutes from the tim= e of submission
=C2=A0 =C2=A0 until the htmlized version and diff are available at tools.ietf.= org.

=C2=A0 =C2=A0 Internet-Drafts are also available by anonymous FTP at:
=C2=A0 =C2=A0 ftp://ftp.ietf.org/internet-drafts/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/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 Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information = Technology
University of Minnesota=C2=A0=C2=A0
2218 University Ave S= E=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapolis, MN 554= 14-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
--001a114cf2d6339127055a407313-- From nobody Thu Sep 28 09:15:46 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C919134228; Thu, 28 Sep 2017 09:15:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Weis To: Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-rfc6555bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150661534403.27693.10060826661300587258@ietfa.amsl.com> Date: Thu, 28 Sep 2017 09:15:44 -0700 Archived-At: Subject: [v6ops] Secdir last call review of draft-ietf-v6ops-rfc6555bis-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 16:15:44 -0000 Reviewer: Brian Weis Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. >From the Introduction, "This document expands on "Happy Eyeballs" [RFC6555], a technique of reducing user-visible delays on dual-stack hosts." It lists a set of steps by which a client can asynchronously perform IPv6 and IPv4 DNS queries, and also semantics on how to handle the replies such that the user delay is minimized. The Security Considerations section simply states "This memo has no direct security considerations.", and I believe this is true. However, I wonder about "indirect" security considerations. RFC 6555 warns several times against breaking a browser's same-origin policy, which seems to me to be an "indirect" security consideration. I realize that browser policies have changed considerably since RFC 6555 was published, and I personally do not know if same-origin is still in general use or whether there are other newer but similar issues of which an implementor should be aware. But if there are, then this section should note them. Otherwise, I consider the document ready to be published. From nobody Thu Sep 28 10:00:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D410B1342E6 for ; Thu, 28 Sep 2017 10:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAvcK4oM96eA for ; Thu, 28 Sep 2017 10:00:38 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907B4132025 for ; Thu, 28 Sep 2017 10:00:38 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id r74so3563875wme.5 for ; Thu, 28 Sep 2017 10:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=E+6boN8QlfjhtR9JWGW+I3Jw5O9AwboOxEhAIj67aqs=; b=EKe+ujhn4w6CNaTjKdwbAZfkFpCLGpxMw1RDBiGM764OeeuDvDDRke6s3o7L4lQ46c d/YAYwojEYMYTQT7fl8/8C+tqdb2/LmImlCjKxIFPfF++79wPvkiA5G3700TYGgVy0yx Q/5aPVUIDUEmBK4U6tbKM3ryLJxKJXaBm79I6ONHt7MbA1F00Agwvf+rt7r+W8Gg4uja oasjVIXZjTDKafYkjHaL5W8csbuYT/wbrGxB7nQ85bCMp9Nq0PhIcLp4FUS46XThx35D lFmnFKK/3y8DFt7izD0H3qhssS6aOJV+BsgqLhHqvYhi5393+2Qq05VUVF08mNB2v1jR Sykg== 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+6boN8QlfjhtR9JWGW+I3Jw5O9AwboOxEhAIj67aqs=; b=LLdQJHuIgCWzFbX2zzISc08n0c6ON/BIskklTjwfzaAnySKY3WW5KGQ/tDKMAPVmsZ HS0dPp+seBh1ka5dCH9C4dHHqvfFOOhSxd2aJQWpZduWrtfAdMiqsm9wxjwAbotE19qC 1feRrVAwAWNhUOT42wzbHHGqGHdZ6zSI/1zHhy6f0S4WQhq3kyhpHFu0+/UTOPRNOM5o cvQLlTQfLu6fYUck7tp7ixPeTmGYtIyiKJFOdpVtn0fCKaup0JX50FYDVu934N4dFgrq rQvp2zI2CltdXkI3lNSkL9Z0dQtTJ5SPmPVe1104DThC8SCv7+7zcNAnBoyD5OzlkZMX O8Ww== X-Gm-Message-State: AMCzsaUEffs7ZSurP4jsvwU66KMImUw5UduKat7KYScwgYpMEvbYcR4K NKtEENG6L/QvTyzohVBmM0Q= X-Google-Smtp-Source: AOwi7QDx/iwfSrX1lE5eEINq7IK41o7I3CcXctrXMxd13nxKG+OmydsdF6iNdDLtsWG8DgJcqbx5tg== X-Received: by 10.28.74.89 with SMTP id x86mr1707832wma.57.1506618037080; Thu, 28 Sep 2017 10:00:37 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::119b? ([2600:8802:5600:e::119b]) by smtp.gmail.com with ESMTPSA id v5sm551460wme.5.2017.09.28.10.00.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Sep 2017 10:00:35 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_128B12C8-6B7B-4CE4-BBD3-3C6128571071"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Date: Thu, 28 Sep 2017 10:00:32 -0700 In-Reply-To: Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" To: David Farmer References: <150659896337.13704.16305576151522889075@ietfa.amsl.com> <504C386B-260F-452E-8195-3A6E3D3BF40B@nokia.com> X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 17:00:40 -0000 --Apple-Mail=_128B12C8-6B7B-4CE4-BBD3-3C6128571071 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 28, 2017, at 7:08 AM, David Farmer wrote: >=20 > I like most of the changes, however I find the following bullet = somewhat confusing; >=20 > o Maximum IPv6 Router Advertisement Interval =3D 300s (or when = battery > consumption is a concern then a MinRtrAdvInterval of 514 seconds > (1/7 of an hour) is better according RFC7772 [RFC7772]). >=20 > It starts out talking about the *Maximum* Router Advertisement = Interval, then with little explanation shifts to talking about the = *Minimum* Router Advertisement Interval, I fear this will easily confuse = any casual readers. Furthermore, the IPv6 router implementations I'm = familiar with, don't allow you to directly set the Minimum Router = Advertisement Interval, it is automatically computed as 75% of the = Maximum Router Advertisement Interval, as recommended in RFC4861. = Therefore, in such implementations the Maximum Router Advertisement = Interval would need to be set at 685 seconds. >=20 > Also, as Lorenzo pointed out, there is no discussion of IPv6 Router = LifeTime, which is also discussed in RFC7772. The bit about the inter-router-advertisement interval was at my = suggestion. Lorenzo had complained that the draft didn't do anything to = meet RFC 7772. That was changed somewhere between -07 and -10. However, = it resulted in only specifying MaxRtrAdvInterval. If we want to have no = more than seven RAs per hour (per RFC 7772), it is MinRtrAdvInterval = that is important. 514=3D3600/7, hence the specification of = MinRtrAdvInterval. May I suggest you suggest text? What would you like it to say? --Apple-Mail=_128B12C8-6B7B-4CE4-BBD3-3C6128571071 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlnNKrAACgkQEhdRnd2G P+B8ww//eIEPfs9PIu5OqWcpfU5tTNRyBoOWpQ6PqZ8Sch2SYbLqIbNDST7Dg3kO vDm5hagmtoYyHEy5g/vvW5c5pkm9ycWvY8IqHgwB8g8GrSkodrcu+uq/5RCmh7H8 3eKwUiRtJOeF4oziK3LZMQbczbRZlTK3nPbLHtZ4WEO+/PDf1Aq3/cqCOVau6xZw l+LOAgTWQP7kxHcoYfVtm50LliAWxJu5Xk0O3CuIoVOZPPEzHWRWOSr2ewfeu1nN F/YVEe6efbnzI1KbWLk4lOnT1zgCgS74LRwTfI9xvnjM99qWjhGx5MLMu238NMkH uzcGNIwsv3Yqg3By7FN8MfqxJT13INveuYuhVGs4WHNzAB/yws3U1q4RQ60+Vh0k ctT3klv75QdcRH/lK2JIgET9vYLCiSobdYPgmwrgka2veCl/vJy7ocZi5aXwZEGf ynxDvDG16wGL6vtFVHcoWG9juxAi2lnpxiAyBGBbrXCqfBoLJeu7E6kbeHlQSNRq WQGaxEg9I8jSNL/bWFSg3pi5XvU82mSDE7p5r8k44lJlelgCxsHROLx1lAs68Ovr XjI8l8KeyQ6YmQl+ad5+gMqzM2dTaoDwrukcjn/tgId765bNf23aDGzeg1akWNLx /LLZIG3Rbl2RouNWeFQFVyt5nu4Z7iNl7CIOOlfF0sI7/g5r80o= =zA0h -----END PGP SIGNATURE----- --Apple-Mail=_128B12C8-6B7B-4CE4-BBD3-3C6128571071-- From nobody Thu Sep 28 14:40:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538E61349D5 for ; Thu, 28 Sep 2017 14:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, 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 FeQyBE8NdcnR for ; Thu, 28 Sep 2017 14:40:42 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E64132F2C for ; Thu, 28 Sep 2017 14:40:42 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 9564BB47 for ; Thu, 28 Sep 2017 21:40:41 +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 nK9Tdlr5Nnnp for ; Thu, 28 Sep 2017 16:40:41 -0500 (CDT) Received: from mail-wr0-f199.google.com (mail-wr0-f199.google.com [209.85.128.199]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 30D6AB34 for ; Thu, 28 Sep 2017 16:40:41 -0500 (CDT) Received: by mail-wr0-f199.google.com with SMTP id f51so3735960wrf.3 for ; Thu, 28 Sep 2017 14:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r0sag9FwM87A3Fsj09AEw/+TG1NEFlclmkbrmWRB8Yo=; b=Xd2Ds3RG2nPhu9mhsFI25BsReeTSeFStyC1wvMzlFD3jyWr9HcVN3Q24GilpLbzHZj i1brAXa2OaFxKRfFqxU2YZjg0B5x1YjKxNuXh+/0p85Qee0q5TSCC9vtJYiiq9x10NrA a3OT7hSJLllG3C+HY/7tYEHoDLsoXbrxO90T/SNdRrpw9vs2tvrCocbs0qpmSgHATB79 TBG8txZMefXwejEO45IJEs8KR2mkOLoMqQodPhaWsC/p3zOBIzIjyRzKgxPVKI66spxG c5T63nbqxk3PHu8yz8gSFqb3li/vfBbCbOUOeAS8VBv7MMCi9MbrGhJfPiJJKTN2KzrI gRYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r0sag9FwM87A3Fsj09AEw/+TG1NEFlclmkbrmWRB8Yo=; b=bdBbAbzMOW4M3hWA1iupjpjkl/yoXgK/i7qoE0WDZaps09KDadAXRZpFCu80OZnecV 0YuASPolpKrVgW3z6/clUReeWkbTNyfOCQ0TyEE399xLwdfGbHf4Q2KDkWv/AXlo9g/B hC/35MKlL9884YDc4sGscH65bJ8Clb7icN8mwpkNwgkyydITharTmC1vZinisTJh2z7c 4mKdkNkYC/AgMg6aW/PZYSmI9xxgAFCYNyuomJuQMg1who9D2k7o/OFptZho0X4JZceM tmIO0HJWzVq0UTqQU/zO/KcA2tOPGy0mT5qBwh2frPlS0/sPWkxSVTl3y9GAcRsduvxA jxmA== X-Gm-Message-State: AHPjjUi3+i35gEqkxpr5MIkXDhYf6Tzuod5C+lIq3qhaCSdbI4l1H6GD ntsd46SmAg/yErOLq/XZ0C1GLQIPneop4eCIa76KCBUrsjtbHZhwNGMWZaZIOkLFBWNJAqILA9+ finNCDAgTuFxa1kxhqFqVfqMzfQ== X-Received: by 10.46.88.68 with SMTP id x4mr2603251ljd.138.1506634839663; Thu, 28 Sep 2017 14:40:39 -0700 (PDT) X-Google-Smtp-Source: AOwi7QB0irLtJCbzUraaaMkBo/ltjOVJAWJOg9eTmEh2UwReAqlBxpeYASYxcS/azsMDrLD6c5co7+A5KfsPthRNLI4= X-Received: by 10.46.88.68 with SMTP id x4mr2603247ljd.138.1506634839444; Thu, 28 Sep 2017 14:40:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.25.212 with HTTP; Thu, 28 Sep 2017 14:40:38 -0700 (PDT) In-Reply-To: References: <150659896337.13704.16305576151522889075@ietfa.amsl.com> <504C386B-260F-452E-8195-3A6E3D3BF40B@nokia.com> From: David Farmer Date: Thu, 28 Sep 2017 16:40:38 -0500 Message-ID: To: Fred Baker Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="f4030438e988696a9c055a46c25a" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2017 21:40:44 -0000 --f4030438e988696a9c055a46c25a Content-Type: text/plain; charset="UTF-8" On Thu, Sep 28, 2017 at 12:00 PM, Fred Baker wrote: > > > > On Sep 28, 2017, at 7:08 AM, David Farmer wrote: > > > > I like most of the changes, however I find the following bullet somewhat > confusing; > > > > o Maximum IPv6 Router Advertisement Interval = 300s (or when battery > > consumption is a concern then a MinRtrAdvInterval of 514 seconds > > (1/7 of an hour) is better according RFC7772 [RFC7772]). > > > > It starts out talking about the *Maximum* Router Advertisement Interval, > then with little explanation shifts to talking about the *Minimum* Router > Advertisement Interval, I fear this will easily confuse any casual > readers. Furthermore, the IPv6 router implementations I'm familiar with, > don't allow you to directly set the Minimum Router Advertisement Interval, > it is automatically computed as 75% of the Maximum Router Advertisement > Interval, as recommended in RFC4861. Therefore, in such implementations the > Maximum Router Advertisement Interval would need to be set at 685 seconds. > > > > Also, as Lorenzo pointed out, there is no discussion of IPv6 Router > LifeTime, which is also discussed in RFC7772. > > The bit about the inter-router-advertisement interval was at my > suggestion. Lorenzo had complained that the draft didn't do anything to > meet RFC 7772. That was changed somewhere between -07 and -10. However, it > resulted in only specifying MaxRtrAdvInterval. If we want to have no more > than seven RAs per hour (per RFC 7772), it is MinRtrAdvInterval that is > important. 514=3600/7, hence the specification of MinRtrAdvInterval. > > May I suggest you suggest text? What would you like it to say? > I did suggest some text, but I didn't correctly remembered what RFC4861 says, so how about this; o Maximum IPv6 Router Advertisement Interval (MaxRtrAdvInterval) = 300s (or when battery consumption is a concern 686s, see Note below) o IPv6 Router LifeTime = 3600s (see Note below) ... Note: When servicing large numbers of battery powered devices, RFC7772 suggests a maximum of 7 RAs per hour and a 45-90 minute IPv6 Router Lifetime. To achieve a maximum of 7 RAs per hour, the Minimum IPv6 Router Advertisement Interval (MinRtrAdvInterval) is the important parameter, and MUST be greater than or equal to 514 seconds (1/7 of an hour). Further as discussed in RFC4861 section 6.2.1, MinRtrAdvInterval <= 0.75 * MaxRtrAdvInterval, therefore MaxRtrAdvInterval MUST additionally be greater than or equal to 686 seconds. As for the recommended IPv6 Router Lifetime, since this technique requires that RAs are sent using the link-layer unicast address of the subscriber, the concerns over multicast delivery discussed in RFC7772 are already mitigated, therefore the above suggestion of 3600 seconds (an hour) seems sufficient for this use case. This keeps the table compact and easily understandable, providing the details in a paragraph following the table. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== --f4030438e988696a9c055a46c25a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Sep 28, 2017 at 12:00 PM, Fred Baker <fredbaker.ietf@gm= ail.com> wrote:


> On Sep 28, 2017, at 7:08 AM, David Farmer <farmer@umn.edu> wrote:
>
> I like most of the changes, however I find the following bullet somewh= at confusing;
>
> o=C2=A0 Maximum IPv6 Router Advertisement Interval =3D 300s (or when b= attery
>=C2=A0 =C2=A0 consumption is a concern then a MinRtrAdvInterval of 514 = seconds
>=C2=A0 =C2=A0 (1/7 of an hour) is better according RFC7772 [RFC7772]).<= br> >
> It starts out talking about the *Maximum* Router Advertisement Interva= l, then with little explanation shifts to talking about the *Minimum* Route= r Advertisement Interval, I fear this will easily confuse any casual reader= s.=C2=A0 Furthermore, the IPv6 router implementations I'm familiar with= , don't allow you to directly set the Minimum Router Advertisement Inte= rval, it is automatically computed as 75% of the Maximum Router Advertiseme= nt Interval, as recommended in RFC4861. Therefore, in such implementations = the Maximum Router Advertisement Interval would need to be set at 685 secon= ds.
>
> Also, as Lorenzo pointed out, there is no discussion of IPv6 Router Li= feTime, which is also discussed in RFC7772.

The bit about the inter-router-advertisement interval was at my suggestion.= Lorenzo had complained that the draft didn't do anything to meet RFC 7= 772. That was changed somewhere between -07 and -10. However, it resulted i= n only specifying MaxRtrAdvInterval. If we want to have no more than seven = RAs per hour (per RFC 7772), it is MinRtrAdvInterval that is important. 514= =3D3600/7, hence the specification of MinRtrAdvInterval.

May I suggest you suggest text? What would you like it to say?

I did suggest some text, but I didn't correctly = remembered what RFC4861 says, so how about this;

o=C2=A0 Ma= ximum IPv6 Router Advertisement Interval (MaxRtrAdvInterval) =3D 300s (or w= hen battery
=C2=A0 =C2=A0 consumption is a concern 686s, see Note below)
<= div class=3D"gmail_extra">

o=C2=A0 IPv6 Router LifeTim= e =3D 3600s (see Note below)

...

Note: When servicing large numbers of battery powered devices, RFC7772 s= uggests a maximum of 7 RAs per hour and a 45-90 minute IPv6 Router Lifetime= . To achieve a maximum of 7 RAs per hour, the Minimum IPv6 Router Advertise= ment Interval (MinRtrAdvInterval) is the important parameter, and MUST be g= reater than or equal to=C2=A0514 seconds (1/7 of an hour). Further as discu= ssed in RFC4861 section 6.2.1,=C2=A0MinRtrAdvInterval=C2=A0<=3D 0.75 * MaxRtrAdvInterva= l, therefore MaxRtrAdvInterval MUST additionally be greater than or equal t= o 686 seconds. As for the recommended IPv6 Router Lifetime, since this tech= nique requires that RAs are sent using the link-layer unicast address of th= e subscriber, the concerns over multicast delivery discussed in RFC7772 are= already mitigated, therefore the above suggestion of 3600 seconds=C2=A0(an= hour) seems sufficient for this use case.

This keeps the table compact and easily understandable, providing t= he details in a paragraph following the table.

Thanks.

=

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0 Email= :farmer@umn.edu
Networking & Telecommunication Services
Offic= e of Information Technology
University of Minnesota=C2=A0=C2=A0
2218= University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Min= neapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f4030438e988696a9c055a46c25a-- From nobody Fri Sep 29 00:40:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA4A127005 for ; Fri, 29 Sep 2017 00:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwxJFBR0IL8j for ; Fri, 29 Sep 2017 00:40:00 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432A9126DD9 for ; Fri, 29 Sep 2017 00:40:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8T7dwmE006487 for ; Fri, 29 Sep 2017 09:39:58 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A3F55203483 for ; Fri, 29 Sep 2017 09:39:58 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9AAFA2032B1 for ; Fri, 29 Sep 2017 09:39:58 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8T7dwds019880 for ; Fri, 29 Sep 2017 09:39:58 +0200 To: v6ops@ietf.org References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> From: Alexandre Petrescu Message-ID: <0bc67bdb-a62e-b3aa-9dad-afe589b0d230@gmail.com> Date: Fri, 29 Sep 2017 09:39:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 07:40:03 -0000 Hi Erik, Le 28/09/2017 à 11:06, Erik Kline a écrit : > On 28 September 2017 at 17:53, Mikael Abrahamsson > wrote: >> On Thu, 28 Sep 2017, Erik Kline wrote: >> >>> I can just feel all the "android and dhcpv6" screeds being >>> written right now... >> >> >> Do any other mobile operating systems do DHCPv6 on the GTP tunnel? >> It's been too many years since I last looked at GTP packet traces >> to remember if this was done or not. > > I've no idea. Nor do I know what might happen to various networks > if DHCPv6 requests were to be made on the mobile interface (even if > the O bit /were/ observed to be set). The stories of billing system > crashes and so on from the early days of v6 on mobile leave me > somewhat suspicious. > > I have been wondering about asking for an API to the modem to query > for the 3GPP release number of the network as a hint for expected > capabilities, but that kinda seems both excessive and like a > layering violation. ;-) I heard about a recent IETF protocol "DLEP" that communicates between the computer and the modem. Looking at it I see it has a 'Status' message in which one could probably put that 3GPP release number semantics. Alex > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Sep 29 00:54:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9708A1344ED for ; Fri, 29 Sep 2017 00:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wqs8IJKhqWfk for ; Fri, 29 Sep 2017 00:54:09 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89063134481 for ; Fri, 29 Sep 2017 00:54:09 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v8T7s7fj014837 for ; Fri, 29 Sep 2017 09:54:07 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E60BF202260 for ; Fri, 29 Sep 2017 09:54:07 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DC5EA20080A for ; Fri, 29 Sep 2017 09:54:07 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v8T7s7pG029546 for ; Fri, 29 Sep 2017 09:54:07 +0200 To: v6ops@ietf.org References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> From: Alexandre Petrescu Message-ID: Date: Fri, 29 Sep 2017 09:54:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] DHCPv6-PD presence on OSs, and GTP question (was: 464xlat case study (was reclassify 464XLAT as standard instead of info)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 07:54:11 -0000 Mikael, I would like to reply, and also ask a few GTP questions publicly. Le 28/09/2017 à 10:53, Mikael Abrahamsson a écrit : > On Thu, 28 Sep 2017, Erik Kline wrote: > >> I can just feel all the "android and dhcpv6" screeds being written >> right now... > > Do any other mobile operating systems do DHCPv6 on the GTP tunnel? I have seen DHCPv6-PD Solicits on Android and on Sierra Legato OS. > It's been too many years since I last looked at GTP packet traces to > remember if this was done or not. Having loooked at GTP packet traces, I suppose one looked at 3GPP specs as well. I would like to ask whether by 3GPP specs the GTP packets can optionally be transported in IPv6 messages? 3GPP spec "GTP" Rel 15 of September 2017 says this: > UDP/IP is the only path protocol defined to transfer GTP messages in > the version 1 of GTP. A User Datagram Protocol (UDP) compliant with > IETF RFC 768 [13] shall be used. In practice, a packet capture on PGW shows an IPv6 DHCPv6-PD Solicit message, preceded by a GTP-U Header, which is itself preceded by a "GTPU Rx PDU" which is an IPv4 UDP packet. The UDPv4 port number that transports GTP packets is 2152, reserved at IANA and at that 3GPP spec. This is the example packet capture I am talking about: Friday August 11 2017 INBOUND>>>>> 15:45:22:470 Eventid:142004(3) GTPU Rx PDU, from [IPv4-address]:2152 to [IPv4-address2]:2152 (129) TEID: 0x80072183, Message type: GTP_TPDU_MSG (0xFF) Sequence Number:: NA GTP HEADER FOLLOWS: Version number: 1 Protocol type: 1 (GTP C/U) [snip] GTP HEADER ENDS. Payload protocol: IPv6 PROTOCOL PAYLOAD FOLLOWS: fe80::b9d9:c10a:2c2d:3c3b.546 > ff02::2.546: [udp sum ok] IPv6 Header Follows: [snip] IA_PD Option Follows: Option Type: 0x0019 (OPTION_IA_PD) Option Length: 0x0029 IA ID: 0x00000000 (0) T1: 0x00000e10 (3600) T2: 0x00001518 (5400) IA_PD Prefix Option Follows: Option Type: 0x001a (OPTION_IA_PD_PREFIX) Option Length: 0x0019 (25) IA Prefix Addr: ::/56 PL Time: 0x00000e10 (3600) VL Time: 0x00001518 (5400) [hlim 1] (len 81) PROTOCOL PAYLOAD ENDS. From nobody Fri Sep 29 01:01:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87614134481 for ; Fri, 29 Sep 2017 01:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qCqaZ46Ecj8W for ; Fri, 29 Sep 2017 01:00:59 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6DF12895E for ; Fri, 29 Sep 2017 01:00:58 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id a43so988247wrc.0 for ; Fri, 29 Sep 2017 01:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FYpqP9AdzjGFkTSU0d0gxbgh0DF5AXRgh67A2iw8A8g=; b=e/+e0NvplwlrDsBxz3HonWwuGRFaQmQEU1/bfwZZLp/v/6OC1MM4Uj0kSeGXJ9vkrV XjwSo6TXs+nnYH/9kbcu/cM+bxnZblPgCPiHrV++6VZ6lqampfHqR/LDYnnRCFN65iQx tag0nxL1MyJaIDclV3wpd6aRDhF/mvnZZ6fZAQG3D5yVjVp6N6gq2593l8MvCH3AT0xu DESFLTUePtvdSCI4Qb0eeSLBWzWB6z1zOB1vxIXa7Nzbj3wHoYN7Cvk7y9idVbgdpcvR nkORT6fMSMD/AtHtnieGLUC1BPBBiM1vjqtE27ncWWexHwU8zSZ9NvEeRhJC2bl/IwGm iNcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FYpqP9AdzjGFkTSU0d0gxbgh0DF5AXRgh67A2iw8A8g=; b=nyElavC7Y0T2zjyB3cC8LpnUN+CcCcT//Q20hklxKEVQk+tfd7UhBrsYBvNtI0tTES HCEndxRdPbPwNYJSwyVAhk2ppA2HXcY20DnohntdYtS19wcxx6fA3Ok9osZbR1UyK8Fq uhHtRUiAzbg7G2g2YKd94n503F3s+C0yWcDPf+MLSsdgxFaNOSs/obJPJDl7Vh85J5p4 jXkm4AFVhCTX8Nya28Od0tFc3usv1hAaqIQItdQzsv0S4vRSH9BoBGnJuU+7z9ut5L2M 3TAmId9sT0BsbsuP4jkJJwjh13hClT6AlzS5P2UalFfa8Qy5udXxb62ujCsfIhG/zXTV jYTQ== X-Gm-Message-State: AHPjjUisQgLtRgqitzJNQ+ltN1ECv+B40g4o5f66Rye5GtI+0fkeF1pN eR65+KJltoDkTT2hFR9007iz+H1MpevotdqUl67Y6Q== X-Google-Smtp-Source: AOwi7QANusYy8sogJohPo46sCx3tqbxPkMq4zMApQUnCLecWSVUObCgYqYMH9N1eQuYagsZY3ASkgcWTglMGHRwOJu8= X-Received: by 10.223.171.74 with SMTP id r10mr7385933wrc.86.1506672056791; Fri, 29 Sep 2017 01:00:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.213.9 with HTTP; Fri, 29 Sep 2017 01:00:35 -0700 (PDT) In-Reply-To: <0bc67bdb-a62e-b3aa-9dad-afe589b0d230@gmail.com> References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> <0bc67bdb-a62e-b3aa-9dad-afe589b0d230@gmail.com> From: Erik Kline Date: Fri, 29 Sep 2017 17:00:35 +0900 Message-ID: To: Alexandre Petrescu Cc: "v6ops@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1b5342c5bb05055a4f6c6d" Archived-At: Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 08:01:06 -0000 --94eb2c1b5342c5bb05055a4f6c6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 29 September 2017 at 16:39, Alexandre Petrescu wrote: > Hi Erik, > > > Le 28/09/2017 =C3=A0 11:06, Erik Kline a =C3=A9crit : >> >> On 28 September 2017 at 17:53, Mikael Abrahamsson >> wrote: >>> >>> On Thu, 28 Sep 2017, Erik Kline wrote: >>> >>>> I can just feel all the "android and dhcpv6" screeds being >>>> written right now... >>> >>> >>> >>> Do any other mobile operating systems do DHCPv6 on the GTP tunnel? >>> It's been too many years since I last looked at GTP packet traces >>> to remember if this was done or not. >> >> >> I've no idea. Nor do I know what might happen to various networks >> if DHCPv6 requests were to be made on the mobile interface (even if >> the O bit /were/ observed to be set). The stories of billing system >> crashes and so on from the early days of v6 on mobile leave me >> somewhat suspicious. >> >> I have been wondering about asking for an API to the modem to query for >> the 3GPP release number of the network as a hint for expected capabiliti= es, >> but that kinda seems both excessive and like a >> layering violation. ;-) > > > I heard about a recent IETF protocol "DLEP" that communicates between > the computer and the modem. Looking at it I see it has a 'Status' > message in which one could probably put that 3GPP release number semantic= s. https://tools.ietf.org/html/rfc8175 does indeed look quite interesting, tha= nks! --94eb2c1b5342c5bb05055a4f6c6d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgy3j5W1BdzBP6ry0vbIIGhevYJ0262CtF bQlfZSMbtRIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTI5 MDgwMDU3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAJLMxo+NtBjYzvM7cBFUW1G3gXZcXBAEO4naeLlcgxJ0qLK78kNC SRHDMzgk9QiKrfp1XlPU7DPjQn2ux1o1AMTe5RW/BtitzT5eXoiwz1cMbNQSXxRjPRTvx0rztqQa dFRyTmSeZpaNPaimUY1R99hosIgpE7oH9Rc0yTdibM/bKbBJNfLx9JTplGYBOokEET9/NdAuMJnW vnXMOHehoIXbDwaxgkXsIj/nDH1HUssd36AmCzwfEgsPzVqYlHfLniFoaahNJTCZpA/i5KLmk7Gv +gZ87Vi1biKBkoqCenwWJtdpoG5kxtbkVD34/KbxqbIF5SOigaPawME1mLVXdVE= --94eb2c1b5342c5bb05055a4f6c6d-- From nobody Fri Sep 29 01:12:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D56B134481; Fri, 29 Sep 2017 01:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F-AUiThQkPh; Fri, 29 Sep 2017 01:12:15 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40136.outbound.protection.outlook.com [40.107.4.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE5EA12895E; Fri, 29 Sep 2017 01:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LO7xn0MTkKYpxvuDXbZan2Nzd1xrQmd1FMzZzhvJ9Z4=; b=OeLM6vloeVRyNZ3XFe+jhEkakmLYcscqrGGstHpE3wR6MiWhfMHKuA0oR7XsVVVK6Y4qDRvj/LaJUCzCZG+/PCu7ct/r/09S+mscC0DN/cQiI+ouExA0ril7iiJmahSDmTR2D2eBKD75ltII3E2VjCoRqME0wy8J0t5RRkRFcAw= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1714.eurprd07.prod.outlook.com (10.166.133.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 29 Sep 2017 08:12:12 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be%13]) with mapi id 15.20.0077.016; Fri, 29 Sep 2017 08:12:12 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "opsec@ietf.org" CC: "draft-ietf-opsec-ipv6-eh-filtering@ietf.org" , "v6ops@ietf.org" Thread-Topic: WGLC for draft-ietf-opsec-ipv6-eh-filtering-03 Thread-Index: AQHTOPqnaanFnY3C/0OsRx2AxtJLKQ== Date: Fri, 29 Sep 2017 08:12:12 +0000 Message-ID: <8C3BB7BE-4E84-4D44-8DA9-BBE80EA51752@nokia.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [135.245.212.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1714; 6:E8881pu1+oWoAc2GXw/6yQpUlonPzdJIc8gqo/t4G/LXC1lNSFxzE5F13uHNK+2BnI4hMFLM0dOi7v89rVh+XwFMxLgeFtjvZZUMRnJyX1Xwh5razeGXll8OUnuZMAIh8hRwinif81eCT+tubyGfYVLBjgY8dz35mZoNcQpm8cGbpzlNTrCCVsv0031Pk9I/SleAYpnDqmt6rwZY7fBsA1/LusD0eFEXHCM3oFuF2nOretbbFzin/22XAXs7k0k0+sIbDt2+8UpAZuPqSR9/En5IvtVmrR1hW9PqZW111hpsFKBSr8ojsG9ZwM1o4SBlW1SVg5gucHdRzFqb9CHVCw==; 5:brlKyf4IuIdctiU6puoDwu1agMc6wY/DtERgwPRV7/iqX1lurbDtjvu/0Wrk3YnqpvZGpBV0VK84HkVDJrBjeWjN7/CRjn7J8v3M5josjXuYgeIKm+MUAqfW7Dt2ZS08N0LHZCDO7+jjxdKq6MPZLaAe4AY/fsj4h0NY/wWsdVw=; 24:Z7k93lw+T3BKH5LH56vTtsKfKOoBIDJNwcIh0sUhZztzoCxwJbzCudPcx4Pa8emAMDvNSkf76kQ8FyeUn0qakcwyw6eSJddSft60RJu72Mc=; 7:dFr7UxjWxw5tsG7G48u0Jvsk3U45EuI+/xVAgyjokro+RURJDRXWygf8UeES9dRnCdl2pKMpb0OCaEnxKuJFd+qDbDtRGTs7DwUdU+qoKM8OM1yYzpmSM+/fkD1ZydbH8NLy2pOGDxgIKP+k6FJHczu1kFAu+gqxwc4yTRq5Tcqa+wg4o1gfwMcSL05buibNDPRwrELhuOvmxKHjI1tEhKM788+pkgycUO5Fi02VE88= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2e304e24-381f-458a-485e-08d50711c9d4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR07MB1714; x-ms-traffictypediagnostic: AM4PR07MB1714: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB1714; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB1714; x-forefront-prvs: 0445A82F82 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(189002)(199003)(101416001)(3280700002)(54896002)(2501003)(316002)(6116002)(14454004)(6512007)(5660300001)(99286003)(102836003)(5250100002)(81156014)(105586002)(81166006)(2351001)(83716003)(189998001)(7736002)(106356001)(54906003)(1730700003)(36756003)(33656002)(53936002)(8936002)(230783001)(236005)(68736007)(54356999)(6916009)(3846002)(2900100001)(6506006)(6486002)(25786009)(50986999)(4326008)(478600001)(97736004)(966005)(86362001)(82746002)(6436002)(6306002)(5640700003)(450100002)(66066001)(8676002)(3660700001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1714; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_8C3BB7BE4E844D448DA9BBE80EA51752nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2017 08:12:12.3514 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1714 Archived-At: Subject: [v6ops] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 08:12:17 -0000 --_000_8C3BB7BE4E844D448DA9BBE80EA51752nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyB0byBvcGVuIGEgdHdvIHdlZWsgV0dMQyBmb3IgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtb3BzZWMtaXB2Ni1laC1maWx0ZXJpbmctMDMuDQpJZiB5b3UgaGF2 ZSBub3QgcmVhZCBpdCwgcGxlYXNlIGRvIHNvIG5vdy4gWW91IG1heSBzZW5kIG5pdHMgdG8gdGhl IGF1dGhvciwgYnV0IHN1YnN0YW50aXZlIGRpc2N1c3Npb24gc2hvdWxkIGdvIHRvIHRoZSBvcHNl Y0BpZXRmLm9yZzxtYWlsdG86b3BzZWNAaWV0Zi5vcmc+IGxpc3QuDQooV2hpbGUgVjZPUFMgV0cg aXMgaW4gY2MgYmVjYXVzZSBvZiBjbG9zZSBhbGlnbm1lbnQgd2l0aCB0aGUgV0cgZXhwZXJ0aXNl IGFyZWEsIG1heSB3ZSBhc2sgdG8gc2VuZCBmZWVkYmFjayBhbmQgY29tbWVudHMgaW4gdGhlIE9Q U0VDIFdHKQ0KDQpXZSB3aWxsIGNsb3NlIHRoZSBjYWxsIG9uIDEzIE9jdG9iZXIgMjAxNw0KDQpH dW50ZXIgJiBFcmljDQpPUFNFQyBXRyBjby1jaGFpcnMNCg0K --_000_8C3BB7BE4E844D448DA9BBE80EA51752nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <7EB51D97015AA64D95A172619A4DABBD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MCAw IDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhpcyBpcyB0byBvcGVu IGEgdHdvIHdlZWsgV0dMQyBmb3ImbmJzcDtodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1vcHNlYy1pcHY2LWVoLWZpbHRlcmluZy0wMy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SWYg eW91IGhhdmUgbm90IHJlYWQgaXQsIHBsZWFzZSBkbyBzbyBub3cuIFlvdSBtYXkgc2VuZCBuaXRz IHRvIHRoZSBhdXRob3IsIGJ1dCBzdWJzdGFudGl2ZSBkaXNjdXNzaW9uIHNob3VsZCBnbyB0byB0 aGUNCjxhIGhyZWY9Im1haWx0bzpvcHNlY0BpZXRmLm9yZyI+b3BzZWNAaWV0Zi5vcmc8L2E+IGxp c3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPihXaGlsZSBWNk9QUyBXRyBpcyBpbiBjYyBiZWNhdXNlIG9m IGNsb3NlIGFsaWdubWVudCB3aXRoIHRoZSBXRyBleHBlcnRpc2UgYXJlYSwgbWF5IHdlIGFzayB0 byBzZW5kIGZlZWRiYWNrIGFuZCBjb21tZW50cyBpbiB0aGUgT1BTRUMgV0cpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XZSB3aWxsIGNsb3NlIHRoZSBjYWxsIG9u IDEzIE9jdG9iZXIgMjAxNzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+R3VudGVyICZhbXA7IEVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+T1BTRUMgV0cgY28tY2hhaXJz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8C3BB7BE4E844D448DA9BBE80EA51752nokiacom_-- From nobody Fri Sep 29 01:45:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8A6126BF0 for ; Fri, 29 Sep 2017 01:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llTYIf5vf7c4 for ; Fri, 29 Sep 2017 01:45:03 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829A9132941 for ; Fri, 29 Sep 2017 01:45:03 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CBE7AB1; Fri, 29 Sep 2017 10:44:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506674699; bh=d0OTdqp4CFUbhjHSRK5Rs8+kRb5FSOWreIUpJgPBKsw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=t1IA5qYyIXj4lfHoi9Oo6rOfjXB+zTOH1HhjfXrEeIjSyT/fS6UdZDgs3mfU3AmFZ N7pfv9bH6a3sv79U8MyaMeZaaBcBaZ5h+fb1ZgBLVCk9ZcgamzjdVrIw9khjtYSImQ +LiSA1inMBikvcWDSsOpcckXWWlGShfKokrDSJPQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C83D1AF; Fri, 29 Sep 2017 10:44:59 +0200 (CEST) Date: Fri, 29 Sep 2017 10:44:59 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <46045DAA-9096-43BA-A5FD-571232767726@google.com> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] DHCPv6-PD presence on OSs, and GTP question (was: 464xlat case study (was reclassify 464XLAT as standard instead of info)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 08:45:09 -0000 On Fri, 29 Sep 2017, Alexandre Petrescu wrote: > I would like to ask whether by 3GPP specs the GTP packets can optionally > be transported in IPv6 messages? > > 3GPP spec "GTP" Rel 15 of September 2017 says this: >> UDP/IP is the only path protocol defined to transfer GTP messages in >> the version 1 of GTP. A User Datagram Protocol (UDP) compliant with >> IETF RFC 768 [13] shall be used. > > In practice, a packet capture on PGW shows an IPv6 DHCPv6-PD Solicit > message, preceded by a GTP-U Header, which is itself preceded by a "GTPU > Rx PDU" which is an IPv4 UDP packet. > > The UDPv4 port number that transports GTP packets is 2152, reserved at > IANA and at that 3GPP spec. It's an implementation detail whether this is carried over IPv4 or IPv6. UDP can be carried by both. If you read 29.060 it talks about GTP over both IPv4 and IPv6: "If an IPv4/IPv6 capable SGSN received IPv4 GGSN addresses from the old SGSN, it shall include IPv4 addresses in the fields SGSN Address for Control Plane and SGSN Address for User Traffic and IPv6 addresses in the fields Alternative SGSN Address for Control Plane and Alternative SGSN Address for User Traffic. Otherwise, an IPv4/IPv6 capable SGSN shall use only SGSN IPv6 addresses if it has GGSN IPv6 addresses available. If the GGSN supports IPv6 below GTP, it shall store and use the IPv6 SGSN addresses for communication with the SGSN and ignore the IPv4 SGSN addresses. If the GGSN supports only IPv4 below GTP, it shall store and use the IPv4 SGSN addresses for communication with the SGSN and ignore the IPv6 SGSN addresses. When active contexts are being redistributed due to load sharing, G-PDUs that are in transit across the Gn-interface are in an undetermined state and may be lost." "below GTP" seems to indicate what protocol GTP is run over. There is a lot more text in TS 29.060 regarding this, but interested parties can read it and form their own opinion. To me it's clear that 3GPP has done the work to try to achieve so you can standards-based build a network with no IPv4 addresses used for infrastructure. If this works in real life in shipping products, that's a whole other question. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Sep 29 03:10:32 2017 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E6A1320B5; Fri, 29 Sep 2017 03:10:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150667982622.13933.4662167540602943664@ietfa.amsl.com> Date: Fri, 29 Sep 2017 03:10:26 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 10:10:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Unique IPv6 Prefix Per Host Authors : John Jason Brzozowski Gunter Van De Velde Filename : draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.txt Pages : 9 Date : 2017-09-29 Abstract: This document outlines an approach utilising existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of unique IPv6 prefix over a unique service provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-12 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 29 03:12:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CB913422B for ; Fri, 29 Sep 2017 03:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dUvnbEZt4rT for ; Fri, 29 Sep 2017 03:12:55 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0121.outbound.protection.outlook.com [104.47.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5842D1320B5 for ; Fri, 29 Sep 2017 03:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mkbVGjPMNnYnEb32t8dtcpLJv3f/URBB0giLV3F7jtw=; b=E9G+VVRu7ifYhs2UsgKgvLmmh7B50kDxk27GDgmc3J9qc72m7Kc16w87n5xRKt60KitA+uXJT4CIOG+NWGK+BvKahD6ep0jpGApHSFpmjBm9o5xLKJHIPbq5Wv8CXMgAI25EL/IlRHBF+0oh1ARDELtySWYpqNyeY9sDtbEgDwg= Received: from AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) by AM4PR07MB1715.eurprd07.prod.outlook.com (10.166.133.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 29 Sep 2017 10:12:52 +0000 Received: from AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be]) by AM4PR07MB1715.eurprd07.prod.outlook.com ([fe80::443d:e764:4c02:61be%13]) with mapi id 15.20.0077.016; Fri, 29 Sep 2017 10:12:52 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "v6ops@ietf.org" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.txt Thread-Index: AQHTOQs/ZbeoqApraEGLvvxUdiBcb6LLpO2A Date: Fri, 29 Sep 2017 10:12:51 +0000 Message-ID: <4C4C203E-894F-4DF0-B8AB-DDABC8930D07@nokia.com> References: <150667982622.13933.4662167540602943664@ietfa.amsl.com> In-Reply-To: <150667982622.13933.4662167540602943664@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [135.245.212.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR07MB1715; 6:90MCl5wEFFBRyzKxuIACDkFEn9xDefCHRAsBt99M7VUul+43h8SRa/bhgLe0/jdiIjeCcs2J+MSLJZwgfQEDRXKzI9Tk+zV3fBSUtLSFjpSklLqhDf7B9sFTpTIyqAa4Vg443MWFKJSHNsUxFUKwxfM2fB6LXsBfHh+EO/7nLwtJzQFLjKeiS1A45YaUE/BH8+8wPc6RhhnR2RmSLC+8qh1tIj4miGyZQkGFMWzVT0QB2U2G9GqYnPL74pMgKrUvyQ4pH1zu7lIUfM3XbVeW9d5wzROP3mOkGjvwvcGwxsyYwTb785/Lf+RYblZ/ghmhqa/xd+XWhI/SB7kVcZaj4A==; 5:Bzo5znTQa6+RJCG+/My30E1JfzBwazP6VnvBIziwtYSli3gB+y2bCLPvG7WOP9JDRQI4itHZEClJXon5j85k10zMpIkkohaWOA7THeCNXyCGyXQSByfMzqGK6lZwt+33Hy/PbidWydllWTzJnWoKCA==; 24:Gmy4KRZ2nYm+cSVpJs3p0Js4XvFikZ3FBvlMtMPL+02eFfpTJPZOuSosCqLaV2/xY1YwIiOaUhg2L5YV+MDWtWuMzAuQZE1ex8QcPiI7Iec=; 7:PTGuNndFMDH7psHyKX477jwzfzSuAKQt007NSg4zvfcXmPDizLBd3I2h9NTgPAQHk+vDz0OkW8ioBnlehYOeQ3QCt9gYB6GsoYqHzfkTPs9oUNaMwPjIA0Fj9+MSJqZLbcIfcSP66e7qJCE0Ylk14n2lyceOSxs02tW6fhl32xTFGhSRxgGk0OVrvz8zagv+EWdiWY4Uq1dZgmDhR5s4AT+Jg2Re3AvqUYsNDipybas= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6ea34bbc-9ada-44d9-50a3-08d50722a4f8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:AM4PR07MB1715; x-ms-traffictypediagnostic: AM4PR07MB1715: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB1715; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB1715; x-forefront-prvs: 0445A82F82 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(189002)(377424004)(24454002)(199003)(6486002)(6306002)(33656002)(8676002)(6436002)(6506006)(97736004)(83716003)(230783001)(7736002)(81156014)(5640700003)(81166006)(8936002)(305945005)(2351001)(106356001)(53546010)(14454004)(2906002)(5250100002)(2501003)(2900100001)(82746002)(68736007)(86362001)(105586002)(101416001)(6512007)(54356999)(316002)(36756003)(102836003)(6116002)(50986999)(76176999)(3280700002)(3660700001)(3846002)(6246003)(189998001)(99286003)(53936002)(66066001)(229853002)(25786009)(966005)(6916009)(5660300001)(2950100002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB1715; H:AM4PR07MB1715.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Sep 2017 10:12:51.9406 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB1715 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 10:12:58 -0000 VGhpcyBsYXRlc3QgdmVyc2lvbiBpbmNsdWRlcyB0aGUgc3VnZ2VzdGVkIHRleHQgZnJvbSBEYXZp ZCBGYXJtZXIgYW5kIHRoZSBmaXggb24g4oCcRmlyc3QgSG9wIFJvdXRlcuKAnS4NCg0KS2luZCBS ZWdhcmRzLA0KRy8NCg0KT24gMjkvMDkvMjAxNywgMTI6MTAsICJ2Nm9wcyBvbiBiZWhhbGYgb2Yg aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8djZvcHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KICAgIA0KICAgIEEgTmV3 IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy YWZ0cyBkaXJlY3Rvcmllcy4NCiAgICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBJ UHY2IE9wZXJhdGlvbnMgV0cgb2YgdGhlIElFVEYuDQogICAgDQogICAgICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBVbmlxdWUgSVB2NiBQcmVmaXggUGVyIEhvc3QNCiAgICAgICAgICAgIEF1dGhv cnMgICAgICAgICA6IEpvaG4gSmFzb24gQnJ6b3pvd3NraQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgR3VudGVyIFZhbiBEZSBWZWxkZQ0KICAgIAlGaWxlbmFtZSAgICAgICAgOiBkcmFm dC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0xMi50eHQNCiAgICAJUGFn ZXMgICAgICAgICAgIDogOQ0KICAgIAlEYXRlICAgICAgICAgICAgOiAyMDE3LTA5LTI5DQogICAg DQogICAgQWJzdHJhY3Q6DQogICAgICAgVGhpcyBkb2N1bWVudCBvdXRsaW5lcyBhbiBhcHByb2Fj aCB1dGlsaXNpbmcgZXhpc3RpbmcgSVB2NiBwcm90b2NvbHMNCiAgICAgICB0byBhbGxvdyBob3N0 cyB0byBiZSBhc3NpZ25lZCBhIHVuaXF1ZSBJUHY2IHByZWZpeCAoaW5zdGVhZCBvZiBhDQogICAg ICAgdW5pcXVlIElQdjYgYWRkcmVzcyBmcm9tIGEgc2hhcmVkIElQdjYgcHJlZml4KS4gIEJlbmVm aXRzIG9mIHVuaXF1ZQ0KICAgICAgIElQdjYgcHJlZml4IG92ZXIgYSB1bmlxdWUgc2VydmljZSBw cm92aWRlciBJUHY2IGFkZHJlc3MgaW5jbHVkZQ0KICAgICAgIGltcHJvdmVkIGhvc3QgaXNvbGF0 aW9uIGFuZCBlbmhhbmNlZCBzdWJzY3JpYmVyIG1hbmFnZW1lbnQgb24gc2hhcmVkDQogICAgICAg bmV0d29yayBzZWdtZW50cy4NCiAgICANCiAgICANCiAgICBUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC8N CiAgICANCiAgICBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6 DQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdW5pcXVl LWlwdjYtcHJlZml4LXBlci1ob3N0LTEyDQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXVuaXF1ZS1pcHY2LXByZWZpeC1wZXItaG9zdC0x Mg0KICAgIA0KICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDoNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi12 Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QtMTINCiAgICANCiAgICANCiAgICBQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBJbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KICAg IHY2b3BzQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0KICAgIA0KDQo= From nobody Fri Sep 29 14:19:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FC0132EDA for ; Fri, 29 Sep 2017 14:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka800L7_5xqZ for ; Fri, 29 Sep 2017 14:19:06 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89FC132A05 for ; Fri, 29 Sep 2017 14:19:05 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id p187so1424865oif.4 for ; Fri, 29 Sep 2017 14:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=oSt6aUj73NmgVB8UOvUt3045kuuymsQ4+c0l24LlqEU=; b=vRm/bqvm3U+Q6u+O7RlNHqSY7maZiuHX00GZmEagUG6fNBgIW0ssLXLnvQSFXF9SEI wng5YmRUMToJavi3RKBGWPE+G9DGmjMGpPZ/CuQ6YSu3sWrz9AIax39Ladox3qXD7TKu NMJP5wAJH2WGArq93oxVQZkNFvwJcGQjGL0IkkLBK27HVPgJHQk8rT3abs2c7IvntC8p mdhrDMM3yUo9xwcChxfqg2sylvNf7HkCzzhYrLGS/JVsN36ZGtiiUjr4S06Rb2Y9qLNl qpN44m+qTMyPmJac5xs6Mjf25z+aQSGwuJ3wGy/0yLjYcMGkzLqlain9tySLhIi94T7s A8vg== 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=oSt6aUj73NmgVB8UOvUt3045kuuymsQ4+c0l24LlqEU=; b=fuF9hLNqjbNQGbvoApFLjCJndZzEMPrZ3kdKWy/7n7R5bK16aoh5Nyr1lhRTG8mCT3 g2Bh5pe1x9pqn5uYs58NE5diZkX0lAQck4mtFvnCS6qD2DIxF8xQFZC2/q9uyUpdU02K 4bsS1daA1P3qdBiKUDRmKCL+O00IsIVv1IgB9KCTFqVagsua8CUhxEEMePDtEz88Hxqn DDbasG6+P3UN/nS/1sz1tp7JdYQHbIrcEek7UmWwHbZ8nNox0y7HaFOE6Ib5e2RjZlnh mc2ziEAIhF5ZfhvLvhHahYf51+SWCnuumery7S//k5mnfkGq9x3fpXXwfFmGTATZ8XHW Ixaw== X-Gm-Message-State: AMCzsaXY1Z29wekWCYhh9jiNcldNdy3qiI8UuxdGEn4r3oLyNtfdEpLN u4YXOmu9LlHEY1PUQkFeaPc= X-Google-Smtp-Source: AOwi7QCyq0yx0hhABhR6il9di1z2sJ7L1XdjHXU7zXJWnA6Ls+TxnFpvQMr9CwvY/l5Io2ltwQDF9Q== X-Received: by 10.157.15.34 with SMTP id 31mr3374474ott.235.1506719945357; Fri, 29 Sep 2017 14:19:05 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::1238? ([2600:8802:5600:e::1238]) by smtp.gmail.com with ESMTPSA id u16sm2441246otc.13.2017.09.29.14.19.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Sep 2017 14:19:04 -0700 (PDT) From: Fred Baker Message-Id: <9C84BB1D-ACA7-4C84-8BBB-E4589FFFD42E@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C5763B28-6CE4-4B60-8D01-264269AD3200"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.2\)) Date: Fri, 29 Sep 2017 14:19:01 -0700 In-Reply-To: <4C4C203E-894F-4DF0-B8AB-DDABC8930D07@nokia.com> Cc: "v6ops@ietf.org" To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Warren Kumari References: <150667982622.13933.4662167540602943664@ietfa.amsl.com> <4C4C203E-894F-4DF0-B8AB-DDABC8930D07@nokia.com> X-Mailer: Apple Mail (2.3445.4.2) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 21:19:08 -0000 --Apple-Mail=_C5763B28-6CE4-4B60-8D01-264269AD3200 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks much. I believe that addresses the issues raised on the list, in = IETF LC, and by the IESG - or at least the ones that have been collected = in one place. I'll bet the RFC Editor changes "The authors would like to explicit = thank" to "The authors would like to explicit*LY* thank"... With that, let me ask the working group to give this one last review, = ending October 6. After that, Warren, the ball is in your court. > On Sep 29, 2017, at 3:12 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) = wrote: >=20 > This latest version includes the suggested text from David Farmer and = the fix on =E2=80=9CFirst Hop Router=E2=80=9D. >=20 > Kind Regards, > G/ >=20 > On 29/09/2017, 12:10, "v6ops on behalf of internet-drafts@ietf.org" = wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 > Title : Unique IPv6 Prefix Per Host > Authors : John Jason Brzozowski > Gunter Van De Velde > Filename : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.txt > Pages : 9 > Date : 2017-09-29 >=20 > Abstract: > This document outlines an approach utilising existing IPv6 = protocols > to allow hosts to be assigned a unique IPv6 prefix (instead of a > unique IPv6 address from a shared IPv6 prefix). Benefits of = unique > IPv6 prefix over a unique service provider IPv6 address include > improved host isolation and enhanced subscriber management on = shared > network segments. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-h= ost/ >=20 > There are also htmlized versions available at: > = https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-1= 2 > = https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-= per-host-12 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-pe= r-host-12 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at = tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_C5763B28-6CE4-4B60-8D01-264269AD3200 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlnOuMUACgkQEhdRnd2G P+BqWxAAgntcxwiC2Re2tvOPVrk4he/lMrK1I0ZXNIDnZCKxDMRQijCXG+2POCgk v1Xb7Ykm5ro+tyVeN57sba+863EsER+CR0bXNGZWuIsRjSm9Ne4pyvIPbxD4btjF IO9K5nCDBiuxJuSb58uZbSRBkrzjpUztAegXEBXAXZATkL1uPNLONpyscpGsbbN6 YwCHbrOiaLGnR8qwPWpipdKwOve+4jwAZUAajwgqHlvnO3IH4Z6tWfxF0cvDU54d rqWCBhyB3KRBRunUXEfOdK8K9tdQZrJKMomHDrPR9jv6D5QA9mcOIQx5j5nkmjWF faK/HBTIaKvenVmoyb0h9fjLTz+cdq3PVKEkR3Pwi3WAp88wiLr4RiQkuRmXFIb+ PSlg5hYr/CSoD4JIouoAVCsLMsgs5zDGi7BN0mnGEjU1BUQayPLqEHTNiwluJegu PEWGKUPUtUSN9XISnk11zHU2KshiVrnb2jCp5rWadnGbs/Mn+usbnMnVbOorb+32 YZ7lUzVnnOA7sypC8zg3/0qnSRafKgktxmWaKoJhiIor9RRCnZDmrqKVkwWjNNJT OvHxaATcO+daNTL5z7cPVo56JRrSMOdJH/FlAUS480vZqbJhOwWedRv15fqwfEQY w1e0yup/qa0EkhWD5XEdtT47hYIePnjwtACIZusbUzfO+N1kw3U= =fQP4 -----END PGP SIGNATURE----- --Apple-Mail=_C5763B28-6CE4-4B60-8D01-264269AD3200-- From nobody Sat Sep 30 10:48:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8638E1331FF for ; Sat, 30 Sep 2017 10:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGwMtISBkklL for ; Sat, 30 Sep 2017 10:47:58 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE2F13320B for ; Sat, 30 Sep 2017 10:47:58 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id q124so4227346wmb.0 for ; Sat, 30 Sep 2017 10:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=OeTfBQx/z6k4XTuUgvah7cRGJCD7ac43d9IDxH6Qk4k=; b=VdvYdKlj9tpRZZPwFo3agIiOrtD/AQwbZM0iiFLPrqB+ZzuX14g7LGcCVeK+8bXWdQ qTw8QX7oITx2UtogaM2/9tcM1iqk8jegtg/DojiSiTGGUxIZgOn0VcpyPax6Zr2A6RiN puEy5vSskYN1SsjPBm/ldxtPOoExoPkyW+ChYCM1a/w9xMx+uB0ggDW7lVInpb2guLLk FNavBrCrRYHU8rYzAbcw39q4Mznu+1UjknC0EHa0JkzmM6Kw+9Fdu5lR5LTon4ZWKcYG 2yVgqsXU6AdqIFb6jgfTn1cwkhMGV79g9cKMETTmCou2VJnJ24SLnQSXtLqxLQMckBMw C1/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=OeTfBQx/z6k4XTuUgvah7cRGJCD7ac43d9IDxH6Qk4k=; b=FZ+CD/4MPcDUcEcSqjzfQu7mbbpkBpVwjPgiQDiBSZhWX+CXoqRazCfQkGF26bnVOF JGv/0fUTH2IMBiYhrY36HPgPB/sk6plh96c32EcCIq+PWN4c/ev9KliWqawTER4L4Pqk VEizAC0XVrSuUl9QanOhUaxbuwWEs+vaCGWzdl7q/KMrESk4PC6vVDo8olVkVoCvwNqt EXRakfCTuL98vsXxm3qaqZii/rkoQnj3a4hiVQzFCCH06kZpxal/r7dZdtyU6+EHPk8I HEw4rP4/2CR2CwuJWYFUIPGBvDpHgGakObAQTvIg/Rvm6KG5infBXfO8eHwm9keDBg4C CqQQ== X-Gm-Message-State: AMCzsaVc7erErcz8AI7ra4dh2X6F/6aKDEzwU+s+ATh7Oofkmj6JpIME 1MO359KJlIvIGzbEhEx+/N+9r0Y6 X-Google-Smtp-Source: AOwi7QBI7HOuOgwsgLVOcKm4E5QTqpkIQtGIXENG9HVDxp6eIPFiEPovvowTq44L+KH+6+DWEEaunw== X-Received: by 10.28.5.141 with SMTP id 135mr5992173wmf.112.1506793676755; Sat, 30 Sep 2017 10:47:56 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:e::19fb? ([2600:8802:5600:e::19fb]) by smtp.gmail.com with ESMTPSA id q4sm7133185wmd.19.2017.09.30.10.47.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Sep 2017 10:47:55 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_CD5EB2D1-F066-4DDF-842D-5BF4148C4023"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.2\)) Date: Sat, 30 Sep 2017 10:47:51 -0700 References: <150667982622.13933.4662167540602943664@ietfa.amsl.com> <4C4C203E-894F-4DF0-B8AB-DDABC8930D07@nokia.com> <9C84BB1D-ACA7-4C84-8BBB-E4589FFFD42E@gmail.com> To: Warren Kumari , "v6ops@ietf.org" In-Reply-To: <9C84BB1D-ACA7-4C84-8BBB-E4589FFFD42E@gmail.com> Message-Id: <8EFD16FF-A105-4D1D-B08E-75D5332B6D8C@gmail.com> X-Mailer: Apple Mail (2.3445.4.2) Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 17:48:00 -0000 --Apple-Mail=_CD5EB2D1-F066-4DDF-842D-5BF4148C4023 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I suspect I was not sufficiently clear in this email. Let me be more = clear. After draft-ietf-v6ops-unique-ipv6-prefix-per-host-07 left the working = group, it had the usual IETF Last Call, Directorate Reviews, and IESG = Review. There were a number of comments. The chairs and the authors = walked through the comments, and it is our belief that they have all = been satisfactorily addressed. At this point, we would like for any remaining issues to be brought up = and addressed in the working group before we send it back to Warren. Hence, please consider draft-ietf-v6ops-unique-ipv6-prefix-per-host-12 = to be in working group last call until October 6. If there are remaining = issues, let's get them sorted out. > On Sep 29, 2017, at 2:19 PM, Fred Baker = wrote: >=20 > Thanks much. I believe that addresses the issues raised on the list, = in IETF LC, and by the IESG - or at least the ones that have been = collected in one place. >=20 > I'll bet the RFC Editor changes "The authors would like to explicit = thank" to "The authors would like to explicit*LY* thank"... >=20 > With that, let me ask the working group to give this one last review, = ending October 6. After that, Warren, the ball is in your court. >=20 >> On Sep 29, 2017, at 3:12 AM, Van De Velde, Gunter (Nokia - = BE/Antwerp) wrote: >>=20 >> This latest version includes the suggested text from David Farmer and = the fix on =E2=80=9CFirst Hop Router=E2=80=9D. >>=20 >> Kind Regards, >> G/ >>=20 >> On 29/09/2017, 12:10, "v6ops on behalf of internet-drafts@ietf.org" = wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the IPv6 Operations WG of the IETF. >>=20 >> Title : Unique IPv6 Prefix Per Host >> Authors : John Jason Brzozowski >> Gunter Van De Velde >> Filename : = draft-ietf-v6ops-unique-ipv6-prefix-per-host-12.txt >> Pages : 9 >> Date : 2017-09-29 >>=20 >> Abstract: >> This document outlines an approach utilising existing IPv6 = protocols >> to allow hosts to be assigned a unique IPv6 prefix (instead of a >> unique IPv6 address from a shared IPv6 prefix). Benefits of = unique >> IPv6 prefix over a unique service provider IPv6 address include >> improved host isolation and enhanced subscriber management on = shared >> network segments. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-h= ost/ >>=20 >> There are also htmlized versions available at: >> = https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-1= 2 >> = https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-= per-host-12 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-prefix-pe= r-host-12 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at = tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail=_CD5EB2D1-F066-4DDF-842D-5BF4148C4023 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlnP2McACgkQEhdRnd2G P+AKYRAAhvAMGb8r/qAdag9Dxl35hIsq/sVCj4ePBPUGsCOWNpilaWNfuGHMCjF+ JFtU1+ewc2q/eFFDQmTW3BVKBNNNDJjWpMEJ28dj0YjjUrqYEoCLZopkw06dj6OM qCU0UnXOsieYYnaJeARSLQ1w5V8mwFIWRcu0Bnev7kjlwrdjMJfOz5ANW0jcri2W k9tArCafunnZrBhGkkNrc058OuJqaOm7ObQtk4k+rHOtMf+ysAelrkSFbbwq9QQ8 5RbZADbzNeO8S65Stcd3UCnaNWHX5uYqjdzTX3b7L+7hsFQcYI4AL6/fngSjmWkC s2HT/tfDLfbzg05FghHsK+XkouZXqr7P1S0vAx7qwCL62MbFLWiinvT2YcLJ7R70 +IO5ANbcs/UTemMrG44knB/STGU5yvCZxGN3N4GqkFmTODU5AVJ/pg8o5BV8gP0G //16X0Agd2WSNccrXolz4f6bv98NnceCqqAU/ArG9/WqLlTF5WmxrC8JElAKNRQ3 EYt9UtGW0j3oJPe3zrQpCKtAQw5iG/Mm7RmPrC/Mt4CRaSHYqzHdP/DlvMuwCevo 6AdN9PxIYVtStE/EavwTlkYqlpUYAwAgiKGiZ//0zksMTTcWbOJp7Kx9cBa4CE80 TS8unug/At9tgepUgbVGPGE5Yj3ZAWC+CbCU3xhhrZ5wHdDIqa4= =X2Ez -----END PGP SIGNATURE----- --Apple-Mail=_CD5EB2D1-F066-4DDF-842D-5BF4148C4023--