From nobody Wed Nov 1 01:06:37 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4959E13F580 for ; Wed, 1 Nov 2017 01:06: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 Q39O8G-sA300 for ; Wed, 1 Nov 2017 01:06:33 -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 D290C13F627 for ; Wed, 1 Nov 2017 01:06:33 -0700 (PDT) Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 619092D4FD1; Wed, 1 Nov 2017 08:06:33 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 9559B20088A54C; Wed, 1 Nov 2017 09:06:31 +0100 (CET) From: Ole Troan Message-Id: <0A9B4172-15B4-4FE1-B5C9-8FE4A468644A@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_0665BD30-07E4-4BFC-9A0B-4B2A6A09DDAF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP Date: Wed, 1 Nov 2017 09:06:30 +0100 In-Reply-To: Cc: Michael Richardson , 6man WG To: Mark Smith References: <6286.1509408085@obiwan.sandelman.ca> <25055.1509413008@obiwan.sandelman.ca> <19111.1509476559@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 08:06:36 -0000 --Apple-Mail=_0665BD30-07E4-4BFC-9A0B-4B2A6A09DDAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, > So truly "inserting" (cut, insert, glue) into an existing packet is = not something that has been part of any IETF protocol as far as I'm = aware. IPsec (and some of the IPv6 transitioning work) introduced = Bump-in-the-wire and Bump-in-the-stack. Both are header insertion. The BITW IPsec, is an IPsec transport offloaded to a security gateway. = See RFC4301. Best regards, Ole --Apple-Mail=_0665BD30-07E4-4BFC-9A0B-4B2A6A09DDAF 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+/bDNdvtpYqJhC33YFAln5gIYACgkQvtpYqJhC 33atPBAAzWm65RUM6N6KTlugnZAzX9We0af9OSE7Rh4lVHiXeHHdJVBccFwFVVWg xd/a47ZhaQ7nISoiXTfx5endtRp3Yewh/O3DGpuK8wIX4PNsZhIY3sAZqJRyrQaj AS7R0PuGcJcjK4+57giSb1RXHSFpGtQDYAOWV1OTcS3t8LX0UQfhfAA2VRxJg5eq ayPAb3WvRaYEot8wVoT1iBqRAOxIZ4oIPriIdEmGGKIMuMKzDlr8rc02JrRpg7Ns qWTA2hPOe7ilFlOOV8Bi6qi41JHjOmG9daGuqrtMNWWytKo7lV9ZqEgcGjBj9Ila 3Z/9U3i0+J6YUx+4WpbAsxYyX9e1yqsy8PsbJomtoEkehIWyEPLw6VCliyMe1MGA VatWn1odGPGrOuYbGsAj8KlsrEg+PMJb3XinjhuvD0XyzNrvI6Wkeyzx0ixrxSDx Qmc/FGtjk9dSZxMGmeDzAK1tJq++LMMjvNTeZs/Qjdp8FB4elY1FdpsmalTWKl1J mpxVWolIX3coyjoXwdC6Ndmvy96hgBSQV2NMCVehBeqwVtp+vaWwbhaQ0hGEa6nh vtvnlzrGf9pVsTZ3+4CszzzwQ5BTWp0YEgphOvCJbme9M+iy7svw6EgVuK6lzsZa vUe1iVvk3ndkf/RgFPQL6S+fihDfrWyIAcA4/W++bWCdOQOzKe0= =NmWs -----END PGP SIGNATURE----- --Apple-Mail=_0665BD30-07E4-4BFC-9A0B-4B2A6A09DDAF-- From nobody Wed Nov 1 03:46:32 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B21913F6DD for ; Wed, 1 Nov 2017 03:46: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 Hx48FKP8J1vA for ; Wed, 1 Nov 2017 03:46:28 -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 EEDA513B10E for ; Wed, 1 Nov 2017 03:46:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id ABFADB5; Wed, 1 Nov 2017 11:46:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1509533185; bh=TK/co7yQ3n1L/CKKiXAkVQqIAlCkjV7IGcV3uS/JgX4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=g9Zi/794BIQHrROpxBDx3ZSCJhXYnaM35tvyjmYiDum/0rdtvE3oBFw/ZP0S8xvpG ZjHGKY2nQlEJvnkkVeZjxOcsQxV9/8/7zPy4P9ycSwAza7cu7xbzsDnpWpljbNjzK/ pfh3VnFt9h1PSZYtPldUKac267eJ3ve9uVkG1dpo= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A7169B3; Wed, 1 Nov 2017 11:46:25 +0100 (CET) Date: Wed, 1 Nov 2017 11:46:25 +0100 (CET) From: Mikael Abrahamsson To: Michael Richardson cc: 6man WG Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP In-Reply-To: <6286.1509408085@obiwan.sandelman.ca> Message-ID: References: <6286.1509408085@obiwan.sandelman.ca> 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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 10:46:30 -0000 On Mon, 30 Oct 2017, Michael Richardson wrote: > And I think that most host stacks discard such things unless configured to > expect a tunnel from D. Agreed. > What to do? > > I'd like to make it clear that the above construct is valid and that hosts > SHOULD process it to remove the first IPIP hader and then process the packet > as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then discard) Ok. If it's configured to expect this kind of IPIP tunnel, agreed. Automatically, I don't think it should do this. It should not be default behaviour. Otoh I agree that ripping of a header isn't "forwarding" and shouldn't count as such. A 6to4 enabled host with forwarding disabled, receiving a 6to4 packet addressed to itself, should indeed take off the header and then process the inner packet. If the OS comes by default with 6to4 enabled, then I expect it to be able to handle 6to4 packets coming to it. I wouldn't expect it to behave this way if 6to4 is turned off, then it should just drop the packet. > As an aside, it would also be nice if we could say that an IPsec AH > header with an unknown SPI should be skipped as if it wasn't even there > (including any subsequent IP header as above..) This is essentially a > similar situation. I suspect that this statement is even more > controversial. If the device isn't configured to do IPsec (even by default), then I don't think it should do what you describe. It just seems weird to have end nodes strip off headers to try to gain access to whatever might be in there, at all costs, because it might be relevant to it (or not). If it receives an MPLS labeled packet and the device understands MPLS, should it start ripping off labels even if MPLS has been turned off on the device? I believe users and admins would be very astonished if end systems started doing these things. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Nov 1 13:17:53 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C0D13FEAE for ; Wed, 1 Nov 2017 13:17: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, 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 n8xeZvCxD-vm for ; Wed, 1 Nov 2017 13:17:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D604C13FEAC for ; Wed, 1 Nov 2017 13:17:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6555520089; Wed, 1 Nov 2017 16:18:44 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 18D3581DB3; Wed, 1 Nov 2017 16:17:50 -0400 (EDT) From: Michael Richardson To: Mark Smith cc: 6man WG Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP In-Reply-To: References: <6286.1509408085@obiwan.sandelman.ca> <25055.1509413008@obiwan.sandelman.ca> <19111.1509476559@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 20:17:52 -0000 --=-=-= Content-Type: text/plain Mark Smith wrote: > I think we need to be clear about what is "inserting" is. To me, the word > "inserting" means inserting to into something that already exists and has > previously been created - cut apart, insert, glue back together. You can mince words here if you like, I don't mind. If someone wants to add a packet by encapsulating with a new IP header, then they have to pick a destination address for that header, and if they keep the same destination as the inner one, then the end host has to process two headers. So, if one wants to make the advice of 8200 useable in practice, then one has to fix 6463. If one argues that this will hard and shouldn't be done, then 8200 must be wrong in some way. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAln6K+0ACgkQgItw+93Q 3WWrfAf/XZseWy1lehEOLgiSSYU7nFkpMaJudmrH2WYixtbUmmbxTVzari6S9vUH 0QDL2G4zlOzIH4B1fRcAEyQPATM3uHjkq9BZBlxRK9h/n1LK6SCPGfr79sp7lMoe +dqyX5YXuolbmPLnPwVuwNEbW9TReuZ9q3ABYynTKm3B50qJMamsrAyM0fyPWSR0 ENvffYEPLWCCYvbp7f1YFycRL4G/sMTbV/Bfig38C1rl5S62yC8LBsDabqc3T7gu k0Kt06sCoUwo6UEHVFltLiWMQ7iCXgM5QaGQx5x7URjD5jY1llC6o85RHpiX9atg BqkEpC+fxzrLQgR6R5RflkI04wS0eg== =AQI+ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 1 13:25:02 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4028713F5D8 for ; Wed, 1 Nov 2017 13:25: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQvKYoM_r7Z3 for ; Wed, 1 Nov 2017 13:24:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB3413F54D for ; Wed, 1 Nov 2017 13:24:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E072420089; Wed, 1 Nov 2017 16:25:51 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8F5E381DB3; Wed, 1 Nov 2017 16:24:57 -0400 (EDT) From: Michael Richardson To: Mikael Abrahamsson cc: 6man WG Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP In-Reply-To: References: <6286.1509408085@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 20:25:00 -0000 --=-=-= Content-Type: text/plain Mikael Abrahamsson wrote: > On Mon, 30 Oct 2017, Michael Richardson wrote: >> And I think that most host stacks discard such things unless configured to >> expect a tunnel from D. > Agreed. >> What to do? >> >> I'd like to make it clear that the above construct is valid and that hosts >> SHOULD process it to remove the first IPIP hader and then process the packet >> as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then discard) > Ok. If it's configured to expect this kind of IPIP tunnel, > agreed. Automatically, I don't think it should do this. It should not be > default behaviour. Otoh I agree that ripping of a header isn't "forwarding" > and shouldn't count as such. A 6to4 enabled host with forwarding disabled, > receiving a 6to4 packet addressed to itself, should indeed take off the > header and then process the inner packet. > If the OS comes by default with 6to4 enabled, then I expect it to be able to > handle 6to4 packets coming to it. I wouldn't expect it to behave this way if > 6to4 is turned off, then it should just drop the packet. Fair enough for 6to4. Having 6to4 on or off is a useful setting that the end-host should control, and for which the end-host gets some defined benefit. Removing redundant IPIP headers at the end-host provides no benefit to the end-host. The end-host does this in order to facilitate some unknown service in the middle that did something. If we want to enable such things to work without prior permission (cf: "permissionless innovation") then we need to fix hosts to do this. There is also a hack that we could employ to sit on the fence. We could decide that the destination address should no longer be B, but instead it could be some well known same-prefix-as-B::anycast-IID, and have the last router remove the outer IPIP header. This seems gross in many many ways, but might make everyone happy. >> As an aside, it would also be nice if we could say that an IPsec AH header >> with an unknown SPI should be skipped as if it wasn't even there (including >> any subsequent IP header as above..) This is essentially a similar >> situation. I suspect that this statement is even more controversial. > If the device isn't configured to do IPsec (even by default), then I don't > think it should do what you describe. Yet we skip other extension headers in order to find the ULP. In fact, a host that has *NO* IPsec code *at all* will skip it as an unknown header.... Because we got this wrong, we couldn't use AH to secure ND or any other multicast (like OSPF) without causing of a flag day. AH became totally USELESS. It was sad. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAln6LZkACgkQgItw+93Q 3WXqSAf/ce6vXO9utVuZR55lrM3r1p6WwTGYWb0/FZbH71HIM4V3t2Yxvsk7jB+m PgbbUEOkvuqPUCvvvHdIN457IQmCgyw+OePep+MAH1Xz35PNMyKHUhErwrcrrQQU 5SWlg2yiG4+E9AUyZfDljb4Ybh6OKrXuk7QPNg2lQwmyx/4EiRUYGvILlcARhjPJ XV4Lzcv9wEZME+6jcUPzmJZkgPaEiNSu+mNxChUVBdwvHJnar/nt3Kg6f3bVPABC vs58JOTM7ymYz8ynrcLsSIyho+98HmKr0Cn5c6AKDqXj9ACxPSzA0wwxFpRUzZXO iTC28/XFUh6OfIs+x4BXnZ5C9sNj6A== =sxG2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 1 19:32:20 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB52013F722 for ; Wed, 1 Nov 2017 19:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 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, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9iRR68MVr20 for ; Wed, 1 Nov 2017 19:32:17 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35E013F600 for ; Wed, 1 Nov 2017 19:32:17 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 8B84AABAD0 for ; Wed, 1 Nov 2017 22:32:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=gYM h41TQPf+1vqfR4+EHhwJLynQ=; b=gmpDXG6hHp/ESYP2YBhVA1n8HHXIxy6wWPj 3Q9u0mYeLax+iRajb3bybUi47JUqeeQtNwH0BkT4o92jk8DJUESzQWY9F4C1QRBc xOv3mXTXT7jKLyDWjcj/TBzsjQe6Dgz5dQn+ufUJm8eVydTtzJFGCFV416G9eWfV 3s5/YUJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= R2qscUl8PW4qHFFDnWeG9pdimEd5uzeBLqUbVlSmQArXke/AWKDrQ5LxMKMbyaUy rvIVUqm48Fz04xIuTM1CJeQEJ2bSNJ79/l1QipFNGFiK+2B+Lk4/y6EfTcNsQscz JowPAiOaOHnT2J7LW2ayNQiFCHHGi7XzBHtmscbgWcY= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 84899ABACF for ; Wed, 1 Nov 2017 22:32:16 -0400 (EDT) Received: from mail-qk0-f182.google.com (unknown [209.85.220.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 25053ABACE for ; Wed, 1 Nov 2017 22:32:16 -0400 (EDT) Received: by mail-qk0-f182.google.com with SMTP id m189so5086278qke.4 for ; Wed, 01 Nov 2017 19:32:16 -0700 (PDT) X-Gm-Message-State: AMCzsaX7ZlwJf50kHi52zER9W6CbgXl9T226yrbxP3bKVV8kdHcaJQcW ox+T4XCdb1QAf+86mCEA9z2c0N2s2SYDauiK8uE= X-Google-Smtp-Source: ABhQp+R7ifgyQcUpbcCTotha1LSNQdjEgPOuALX4H3tFW/uqkowv+nwR8V4hvqQ8+ne1jcQ/FUnBK2dWZOwD1mUc7Oc= X-Received: by 10.55.170.15 with SMTP id t15mr2738329qke.232.1509589935726; Wed, 01 Nov 2017 19:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.38.241 with HTTP; Wed, 1 Nov 2017 19:31:55 -0700 (PDT) From: "C. M. Heard" Date: Wed, 1 Nov 2017 19:31:55 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP To: 6man WG Cc: Michael Richardson Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 0A851492-BF76-11E7-AC36-8EF31968708C-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 02:32:19 -0000 On Wed, 01 Nov 2017, Michael Richardson wrote: > Yet we skip other extension headers in order to find the ULP. Not so. An end node that encounters an unrecognized extension header is not supposed to skip the unrecognized extension header; it is supposed to discard the packet. See Section 4 of RFC 8200: If, as a result of processing a header, the destination node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. Substantially the same language appears in Section 4 of RFC 2460. It is, in fact, impossible to reliably tell the difference between an unknown extension header and an unknown upper layer protocol because they are drawn from the same numbering space. That fact has been discussed here on more than one occasion. > In fact, a host that has *NO* IPsec code *at all* will skip it as an unknown > header.... Because we got this wrong, we couldn't use AH to secure ND or any > other multicast (like OSPF) without causing of a flag day. AH became totally > USELESS. It was sad. There may be problems with AH, but that is not one of them. Mike Heard From nobody Thu Nov 2 04:23:40 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B5C13F6F1 for ; Thu, 2 Nov 2017 04:23:39 -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_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=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 Ftj0SAKwZYUW for ; Thu, 2 Nov 2017 04:23: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 464A213F6C9 for ; Thu, 2 Nov 2017 04:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1509621815; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=9tfnZPbg9ByZy+TraMMETTpUXu0l6KzggXe4b29sYPk=; b=Cp9aHF0Vq+LXgcnas8NFzVqZdNtfvy2iquCIXW6x5MdljjQoEwFl7hzGvxlNtRr3oh1GJLdieJ1wmrxQBvluSCT65gms187AyNBsEgSai+Fwf0Oa7VPGzmNWiPdsuvVpltml4rBPFTfjqbvu6ygvY93UhvfAUSwziBgZJgBJkjI= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp0053.outbound.protection.outlook.com [213.199.154.53]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-67-QZcToU2-MWikA5BjBIBQlg-1; Thu, 02 Nov 2017 11:23:31 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Thu, 2 Nov 2017 11:23:29 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0218.004; Thu, 2 Nov 2017 11:23:29 +0000 From: Tim Chown To: Michael Richardson CC: Mark Smith , 6man WG Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP Thread-Topic: Updating to RFC6434 to deal with 8200-style header insertion by IPIP Thread-Index: AQHTUduNvqPz1IcGUEyBNF2bHgm6GqL9Jb0AgAAEQQCAAHcwgIAAsL+AgABsDACAATtKAIAA/QgA Date: Thu, 2 Nov 2017 11:23:29 +0000 Message-ID: <460D9142-43AE-4B5F-AABA-4E3E8B322AB4@jisc.ac.uk> References: <6286.1509408085@obiwan.sandelman.ca> <25055.1509413008@obiwan.sandelman.ca> <19111.1509476559@obiwan.sandelman.ca> <17463.1509567470@obiwan.sandelman.ca> In-Reply-To: <17463.1509567470@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) x-originating-ip: [2001:a88:d510:1101:347c:9966:7017:389f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 20:H6Q+4nNjy8S/j04ajMGxvsj3FlCc83rE1rhMy07fHem7k6brqnvN/xINoBp9bmNnVzCQ/2eJOPUYfdRFE1phRPpWIQjMyeWtPMupm9vWGE4paWeiZ2FQXAa1vw9vN/QR9fkWdpl5mwXNNNrcOV3sa91uP78jucsmC88Js84I9fU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1b026109-8440-4193-7e9d-08d521e424db x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1139; x-ms-traffictypediagnostic: AM3PR07MB1139: 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)(3231020)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1139; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(24454002)(189002)(199003)(101416001)(3660700001)(189998001)(53546010)(2900100001)(14454004)(6246003)(74482002)(39060400002)(3280700002)(50986999)(76176999)(2906002)(53936002)(5250100002)(6436002)(106356001)(99286004)(97736004)(6506006)(33656002)(6512007)(105586002)(2950100002)(5660300001)(42882006)(82746002)(229853002)(68736007)(81166006)(478600001)(81156014)(72206003)(8676002)(50226002)(83716003)(57306001)(102836003)(7736002)(6116002)(25786009)(305945005)(316002)(786003)(93886005)(8936002)(36756003)(4326008)(54906003)(86362001)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <5D4B73B3292B7D4D94C09B2A8296108B@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 1b026109-8440-4193-7e9d-08d521e424db X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 11:23:29.6792 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139 X-MC-Unique: QZcToU2-MWikA5BjBIBQlg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 11:23:39 -0000 SGkgTWljaGFlbCwNCg0KPiBPbiAxIE5vdiAyMDE3LCBhdCAyMDoxNywgTWljaGFlbCBSaWNoYXJk c29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiANCj4gDQo+IE1hcmsgU21pdGgg PG1hcmt6enpzbWl0aEBnbWFpbC5jb20+IHdyb3RlOg0KPj4gSSB0aGluayB3ZSBuZWVkIHRvIGJl IGNsZWFyIGFib3V0IHdoYXQgaXMgImluc2VydGluZyIgaXMuIFRvIG1lLCB0aGUgd29yZA0KPj4g Imluc2VydGluZyIgbWVhbnMgaW5zZXJ0aW5nIHRvIGludG8gc29tZXRoaW5nIHRoYXQgYWxyZWFk eSBleGlzdHMgYW5kIGhhcw0KPj4gcHJldmlvdXNseSBiZWVuIGNyZWF0ZWQgLSBjdXQgYXBhcnQs IGluc2VydCwgZ2x1ZSBiYWNrIHRvZ2V0aGVyLg0KPiANCj4gWW91IGNhbiBtaW5jZSB3b3JkcyBo ZXJlIGlmIHlvdSBsaWtlLCBJIGRvbid0IG1pbmQuDQo+IA0KPiBJZiBzb21lb25lIHdhbnRzIHRv IGFkZCBhIHBhY2tldCBieSBlbmNhcHN1bGF0aW5nIHdpdGggYSBuZXcgSVAgaGVhZGVyLCB0aGVu DQo+IHRoZXkgaGF2ZSB0byBwaWNrIGEgZGVzdGluYXRpb24gYWRkcmVzcyBmb3IgdGhhdCBoZWFk ZXIsIGFuZCBpZiB0aGV5IGtlZXAgdGhlDQo+IHNhbWUgZGVzdGluYXRpb24gYXMgdGhlIGlubmVy IG9uZSwgdGhlbiB0aGUgZW5kIGhvc3QgaGFzIHRvIHByb2Nlc3MgdHdvIGhlYWRlcnMuDQo+IA0K PiBTbywgaWYgb25lIHdhbnRzIHRvIG1ha2UgdGhlIGFkdmljZSBvZiA4MjAwIHVzZWFibGUgaW4g cHJhY3RpY2UsIHRoZW4gb25lDQo+IGhhcyB0byBmaXggNjQ2My4NCj4gDQo+IElmIG9uZSBhcmd1 ZXMgdGhhdCB0aGlzIHdpbGwgaGFyZCBhbmQgc2hvdWxkbid0IGJlIGRvbmUsIHRoZW4gODIwMCBt dXN0IGJlDQo+IHdyb25nIGluIHNvbWUgd2F5Lg0KDQpTbyB0aGUgNm1hbiBjaGFpcnMgd2VyZSBx dWl0ZSBrZWVuIHRoYXQgd2UgdHJ5IHRvIHB1c2ggNjQzNC1iaXMgdG8gYSBjb25jbHVzaW9uIGlu IFNpbmdhcG9yZSwgd2hpY2ggaXMgYSBnb2FsIHRoZSBhdXRob3JzIGFyZSB2ZXJ5IGhhcHB5IHRv IHNoYXJlLg0KDQpPYnZpb3VzbHksIHJlb3BlbmluZyB0aGlzIGlzc3VlIG1heSBwcm92ZSB0byBi ZSBjb250ZW50aW91cy4gIFRoZSBzaW1wbGVzdCBhbmQgZWFzaWVzdCBhbnN3ZXIgaXMgdG8gcHVu dCBpdCB0byBhIHNlcGFyYXRlIGRyYWZ0LCBhbmQgd3JhcCB1cCA2NDM0LWJpcy4gSSAqdGhpbmsq IHRoZSBvbmx5IG90aGVyIGNvbnRlbnRpb3VzIGlzc3VlIHRoYXTigJlzIHN0aWxsIG9wZW4gZm9y IHRoZSAtYmlzIGlzIHdoYXQgd2UgY2hvb3NlIHRvIHNheSwgb3Igbm90IHNheSwgYWJvdXQgUkFz IHZzIERIQ1B2Ni4gIEluIG15IHZpZXcsIHdoZXJldmVyIHBvc3NpYmxlIHdlIHNob3VsZCBiZSBq dXN0IGluY2x1ZGluZyBwb2ludGVycyB0byBleGlzdGluZyB0ZXh0IGluIG90aGVyIFJGQ3MsIGFu ZCBtaW5pbWlzaW5nIGFueSBhZGRpdGlvbmFsIGludGVycHJldGF0aW9uLg0KDQpIYXZpbmcgc2Fp ZCB0aGF0LCB3aHkgZG9u4oCZdCB5b3UgdHJ5IHRvIHdyaXRlIHNvbWUgc3VjY2luY3QgdGV4dCBp biBhZHZhbmNlIG9mIHRoZSBTaW5nYXBvcmUgNm1hbiBzbG90LCBwb3N0IGl0LCBhbmQgc2VlIHdo YXQgdGhlIHJlYWN0aW9uIGlzPyAgV29yc3QgY2FzZSwgeW914oCZbGwgdGhlbiBoYXZlIHRoZSBi YXNpcyBmb3IgYSBzZXBhcmF0ZSBkcmFmdC4NCg0KVGlt From nobody Thu Nov 2 04:57:49 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8E8139982 for ; Thu, 2 Nov 2017 04:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUB7RmYJ_nWU for ; Thu, 2 Nov 2017 04:57:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F2D413968C for ; Thu, 2 Nov 2017 04:57:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 008992058F; Thu, 2 Nov 2017 07:58:42 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6F40180696; Thu, 2 Nov 2017 07:57:45 -0400 (EDT) From: Michael Richardson To: "C. M. Heard" cc: 6man WG Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 11:57:48 -0000 --=-=-= Content-Type: text/plain C. M. Heard wrote: > On Wed, 01 Nov 2017, Michael Richardson wrote: >> Yet we skip other extension headers in order to find the ULP. > Not so. An end node that encounters an unrecognized extension header is Both AH and IPIP are well known and recognized extension headers. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAln7CDkACgkQgItw+93Q 3WVnHwgAhwAQ8HR9FhIERApdH0ndHDjyFkA7n4NOoA9tIAWVVwohZSXWfwLzzczI NPZDtwwBTbgIGmRgEhnrJj26hVN5qQ/MT4Fe1ShPFYEXtPoaw7uN3anA0EMUPPcb AS78Txm4cPtM2xB13XRbnXRS5EpeIqjTUmCXfJP4uxs6DDGx4Udqb3WS6C3XfHPn 3bvwYrnjbfYiMksyYh3M2PaIbqP3MEMj0xNVLuIHUKymjv6DOGJ6f7IpzfG14+Mg yD0eSAimGb0CXMlZoDpitWRfbXbUqGcVvGS1KC3r96jKKbnApRmMCrWLwO7VmDkT tCbgPYgy23i3ghLolaSSWt+cmQtxbQ== =9N3R -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 2 06:04:03 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4084813F613 for ; Thu, 2 Nov 2017 06:04:02 -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 1dhU36ZJr7nN for ; Thu, 2 Nov 2017 06:04:00 -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 17701138103 for ; Thu, 2 Nov 2017 06:03:53 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7F439B6; Thu, 2 Nov 2017 14:03:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1509627830; bh=3Bbiq8CLrgrVYihGjF07LrH05mM5v+9FjyGs1DcLlHU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=tIZnIf9ipWHNndQCl3913ji7PL2Tk/omvQHz1p7wERJShuvwQxIle6va6/JUC4PJD XL18bplXW55v0SXCEDYNMQ9UYPcudqqgDpWc2lIIW5i7eV3Ju6sSdu5S/IaSWhfypD EfPzjsWvsGax+1N1Wd0tW42Yo+HeAMiZmjuL4SRA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 7C3A2B5; Thu, 2 Nov 2017 14:03:50 +0100 (CET) Date: Thu, 2 Nov 2017 14:03:50 +0100 (CET) From: Mikael Abrahamsson To: Michael Richardson cc: 6man WG Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP In-Reply-To: <19087.1509567897@obiwan.sandelman.ca> Message-ID: References: <6286.1509408085@obiwan.sandelman.ca> <19087.1509567897@obiwan.sandelman.ca> 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: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 13:04:02 -0000 On Wed, 1 Nov 2017, Michael Richardson wrote: > Removing redundant IPIP headers at the end-host provides no benefit to the > end-host. The end-host does this in order to facilitate some unknown service > in the middle that did something. If we want to enable such things to work > without prior permission (cf: "permissionless innovation") then we need to > fix hosts to do this. I don't think we should. Whatever is done in the middle that does encap, should also make sure it's decap:ed before it reaches the end host. > > If the device isn't configured to do IPsec (even by default), then I don't > > think it should do what you describe. > > Yet we skip other extension headers in order to find the ULP. > In fact, a host that has *NO* IPsec code *at all* will skip it as an unknown > header.... Because we got this wrong, we couldn't use AH to secure ND or any > other multicast (like OSPF) without causing of a flag day. AH became totally > USELESS. It was sad. Right. I forgot that IPSEC is an extension header in IPv6, I tought of it as something that was encapsulated. So I take back what I said. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Nov 2 08:26:54 2017 Return-Path: X-Original-To: ipv6@ietfa.amsl.com Delivered-To: ipv6@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C73B13F58F for ; Thu, 2 Nov 2017 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_fBrOo_Ugka for ; Thu, 2 Nov 2017 08:26:52 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD41139680 for ; Thu, 2 Nov 2017 08:26:51 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 62849B6878 for ; Thu, 2 Nov 2017 11:26:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=nFmF4Wc4lTmBCnPJTSmilVXhiFs=; b=WwnU/K dErHipn7hGysXb9LVUtwMBALtuogPmyFRNrcbiML8cvlGvuOJplB7ea2z8sXIL2u EpR37K9cIpkkq6NUznpYt05OGMI5kz55kbm6pJ2YHE1yGFByklaEAiW9zP57db3Q XPh6Dib4rQ5Tb1x+jCa3V6f8i3IQI1FmV0NEA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=ElQBd96l/buhcz6S/ZhFhpaoKAeYjwRB dZRqrLS1Xqbv3buJCa5JA7F5lnWQnYBiCUVGUbqSvA7M0t+IpgMEV5KNiKJ+jsWn dLW013xJSqInxcbVTcwnezkL8e1X4i4HIHUM4CBP/XYBF18DOFzDuPJg1HFvYexg 6ibhw8i/4kM= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 59352B6877 for ; Thu, 2 Nov 2017 11:26:50 -0400 (EDT) Received: from mail-qk0-f177.google.com (unknown [209.85.220.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id E4B63B6873 for ; Thu, 2 Nov 2017 11:26:49 -0400 (EDT) Received: by mail-qk0-f177.google.com with SMTP id o187so6590056qke.7 for ; Thu, 02 Nov 2017 08:26:49 -0700 (PDT) X-Gm-Message-State: AMCzsaUjdvYPN/V0xQvZd9Qe+V0QgRdCIdNvmI7DvgS2ffW5B4PXuTQV y53vFJal3utM/Nuo9VDcLgOPxVYf8cByPI4L+sI= X-Google-Smtp-Source: ABhQp+SHS6YNPbwvpc4hgdFLIoz4kktHJ7PGxrXNQqgZpcvFg6wI15WzrUmlxlXL3PXYytsIOgL7mLVT8SMVhR3Lyz8= X-Received: by 10.55.217.215 with SMTP id q84mr4889804qkl.197.1509636409459; Thu, 02 Nov 2017 08:26:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.38.241 with HTTP; Thu, 2 Nov 2017 08:26:29 -0700 (PDT) In-Reply-To: <23308.1509623865@obiwan.sandelman.ca> References: <23308.1509623865@obiwan.sandelman.ca> From: "C. M. Heard" Date: Thu, 2 Nov 2017 08:26:29 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP To: 6man WG Cc: Michael Richardson , Mikael Abrahamsson Content-Type: multipart/alternative; boundary="001a1147a300ed0d58055d019d51" X-Pobox-Relay-ID: 3F0E7FE8-BFE2-11E7-8810-8EF31968708C-06080547!pb-smtp1.pobox.com Archived-At: X-BeenThere: ipv6@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IPv6 Maintenance Working Group \(6man\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:26:53 -0000 --001a1147a300ed0d58055d019d51 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 2, 2017, Michael Richardson wrote: > > C. M. Heard wrote: > > On Wed, 01 Nov 2017, Michael Richardson wrote: > >> Yet we skip other extension headers in order to find the ULP. > > > Not so. An end node that encounters an unrecognized extension header > is > > Both AH and IPIP are well known and recognized extension headers. > Not to a node that does not have any IPsec code at all (or that has IPsec turned off). On Wed, 1 Nov 2017, Mikael Abrahamsson wrote: > > > If the device isn't configured to do IPsec (even by default), then I don't > > think it should do what you describe. > > Yet we skip other extension headers in order to find the ULP. > In fact, a host that has *NO* IPsec code *at all* will skip it as an unknown > header.... Because we got this wrong, we couldn't use AH to secure ND or any > other multicast (like OSPF) without causing of a flag day. AH became totally > USELESS. It was sad. > > > Right. I forgot that IPSEC is an extension header in IPv6, I tought of it as > something that was encapsulated. So I take back what I said. No, you were right the first time. Unknown extension headers are not skipped; they cause the packet to be discarded (see RFC 8200, Sec 4). Mike Heard --001a1147a300ed0d58055d019d51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 2, 2017, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

C. M. Heard <heard@pobox.com> = wrote:
=C2=A0 =C2=A0 > On Wed, 01 Nov 2017, Michael Richardson wrote:
=C2=A0 =C2=A0 >> Yet we skip other extension headers in order to find= the ULP.

=C2=A0 =C2=A0 > Not so. An end node that encounters an unrecognized exte= nsion header is

Both AH and IPIP are well known and recognized extension headers.

Not to a node that does not have any IPse= c code at all (or that has IPsec turned off).

=C2= =A0On Wed, 1 Nov 2017,=C2=A0Mikael Abrahamsson wrote:

   > =
If the device isn't configured to do IPsec (even by default), then I do=
n't
   > think it should do what you describe.

Yet we skip other extension headers in order to find the ULP.
In fact, a host that has *NO* IPsec code *at all* will skip it as an unknow=
n
header....  Because we got this wrong, we couldn't use AH to secure ND =
or any
other multicast (like OSPF) without causing of a flag day.  AH became total=
ly
USELESS.  It was sad.


Right. I forgot that IPSEC is an extension head=
er in IPv6, I tought of it=C2=A0as some=
thing that was encapsulated. So I take back what I said.
<=
div>
No, you were righ=
t the first time. Unknown extension headers are not skipped; they cause the=
 packet to be discarded (see RFC 8200, Sec 4).

Mik=
e Heard









--001a1147a300ed0d58055d019d51--


From nobody Thu Nov  2 09:48:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A5513F74C for ; Thu,  2 Nov 2017 09:48: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 BFcvZSaZ6joz for ; Thu,  2 Nov 2017 09:48:37 -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 F2B4A13F58F for ; Thu,  2 Nov 2017 09:48:36 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2EA27B6; Thu,  2 Nov 2017 17:48:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1509641314; bh=Ny+9END9xALZGgVR9he3rmSHw9eFURhM0R4x+RtjF4c=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=VkNHgyIpcTiNksksr+u8/DuDvZBmZ6+4EilW5tQrpKu0raQLSgaq+hHx0QKPnXjNc QPELkuO5C16VxiSGZ7s1vlZ4UrUzKUDIUCqEiQZ04hkLC0RhJgV10OKY6zLVRVZOSb /7CaJmtJhnx5dHFq0iYYSTAk9yckFi+imHJv9k7s=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2C1B3B5; Thu,  2 Nov 2017 17:48:34 +0100 (CET)
Date: Thu, 2 Nov 2017 17:48:34 +0100 (CET)
From: Mikael Abrahamsson 
To: "C. M. Heard" 
cc: 6man WG , Michael Richardson 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
In-Reply-To: 
Message-ID: 
References:  <23308.1509623865@obiwan.sandelman.ca> 
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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Nov 2017 16:48:39 -0000

On Thu, 2 Nov 2017, C. M. Heard wrote:

>> Right. I forgot that IPSEC is an extension header in IPv6, I tought of it as
>> something that was encapsulated. So I take back what I said.
>
> No, you were right the first time. Unknown extension headers are not
> skipped; they cause the packet to be discarded (see RFC 8200, Sec 4).

Sure, but if the device understands IPSEC but has it turned off, what 
should it do?

I don't know.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Thu Nov  2 11:04:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C9A13F742 for ; Thu,  2 Nov 2017 11:04:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCR3Q8WyZw16 for ; Thu,  2 Nov 2017 11:04:52 -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 0E87F13F54B for ; Thu,  2 Nov 2017 11:04:52 -0700 (PDT)
Received: by mail-wr0-x235.google.com with SMTP id g90so369724wrd.6 for ; Thu, 02 Nov 2017 11:04:51 -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=bI6O4Am2MkPGWvKA9MGfhLM6fSd27IwgzglQrz7iTks=; b=oaXmRK8voNSXArgJPdBX9IBZMzdK2GDxN0pwTV7UuX4wDjgokj9noCvQCzgMfcQEi2 De0EbFt2SlbBD2tVOLiFlg3zJJRmeSwu51Lb7o0l/JYXsxjYavXVuLsOPfEwVtjaxF0K yQePfStM7vxkwsmYfd9c7VgyZTDYJH/csdBcyBWIP3z/KRYupYjWEjrOHy1A56XfLfp5 +dMgY3LGitxESXwQYLp/z0zg91/2IDG3gIIfazgkcYjbOxgEBbVyaXq9mU9eK+YiH58B TS8ohIx9089x0rA+EeVkkleQ+4kN/eDSSJobQhYYFLKO4GcP1v+tQWJxRk32sUG3k1xk Vu3Q==
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=bI6O4Am2MkPGWvKA9MGfhLM6fSd27IwgzglQrz7iTks=; b=bpzWZtVyxQZ5+RnPhZDCZAsiQL0W1c6GkG9fAc5B1vjFyGOAth8esdbCRD5KemKJU+ h4Sx/dYYMVpu64aiFt93LrVTQZPElzbV/w0xclPx6dciswiY7lJ/2MePWSoMhaSTDmFs XhUoqQyg2EcwAmEA5KC9qPbEiIVC6Kkg06r5Bbd3DD+0vg0fXuv3I9OxKD2SDlacbHHi BkSPiWmOIwGb8OYQILkFWWM+iYFV2GZw1HdVWIE6ndw9bnCJu8uD7WZCsYEqSR/2DWgh YfAA2neqK2Vl5xPWm/Wtox2CJJLn7xcrZjVZ2JKMXjMtO6589LBx6iyucrTp5i3n3Ms3 FKqQ==
X-Gm-Message-State: AMCzsaUUAQdHZ7HHRpGZ/PDinwQlzdp5X7bZRpW3NVkNQfvCuISNV+6M PWrFc/7ZyXePLC456mg5gvI7eQ0P
X-Google-Smtp-Source: ABhQp+QWrkKjTMQZgRBAtKUTO4AvN0uzV+YslM6ofS+l8xGEAi0Uz7pHvUsyWHftb4fjsh4Gd36XqA==
X-Received: by 10.223.195.147 with SMTP id p19mr3639421wrf.176.1509645890595;  Thu, 02 Nov 2017 11:04:50 -0700 (PDT)
Received: from [172.20.3.117] (bba409691.alshamil.net.ae. [83.110.17.243]) by smtp.gmail.com with ESMTPSA id n14sm267326wmh.37.2017.11.02.11.04.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 11:04:49 -0700 (PDT)
From: Fred Baker 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_8B9752DB-041D-4FB8-8D78-8F158D2211C4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.11\))
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Date: Thu, 2 Nov 2017 22:04:46 +0400
In-Reply-To: 
Cc: "C. M. Heard" , Michael Richardson , 6man WG 
To: Mikael Abrahamsson 
References:  <23308.1509623865@obiwan.sandelman.ca>  
X-Mailer: Apple Mail (2.3445.5.11)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Nov 2017 18:04:54 -0000

--Apple-Mail=_8B9752DB-041D-4FB8-8D78-8F158D2211C4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Nov 2, 2017, at 8:48 PM, Mikael Abrahamsson  =
wrote:
>=20
> Sure, but if the device understands IPSEC but has it turned off, what =
should it do?

It should behave as if it doesn't understand it. In context, it doesn't.

--Apple-Mail=_8B9752DB-041D-4FB8-8D78-8F158D2211C4
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+AFAln7Xj4ACgkQEhdRnd2G
P+Cr6Q/9GfMhW3+WJyrh3koKRWOoJOtEyratngaHzFv7FV3I+fxoSh/U7zfPHO1E
x+X1ghmijU1hYbfHhkYYlIyEMFhYAdlhsaOdBL9PJPpWL5zOTshaUdv/nfjl4kuJ
aY7KfCFqiH8c0ZEri732wL2zTrzziAwFAdV+Su/sjFPK6cu1/eAcS9tlQ2W8CRnD
JjgX1r6+HzrBRV7OMwXd0NwFK2Nt0m1zaClqnIUfHxb18tPS3uTBR0WpB5f9nAmr
8rG98ToD9fdguNmoCz6FNC+9hHTSJlitrVD4T7qeXNahZazwsPSOIA+LUDxe3s11
K8uFtax3I+hcgUZ4wgx+uPXSChW6sHKXbPXopRf4RCE/mXofXUZX6K0Gt+VrdOKw
EwgSTMkFAbTHYUF5tSWQhJItO9etletJzqAvDGFOuDRx8lO/d1m+PearFrQGaJEL
Wu4sBOI3pdklVJkpZ/ttRHq9GLCGgyoEIy9IBita2+d1Ma0FX7b6NKn3Va3VHB3r
pzgGFKbUliIz2F50XlVPdkZKpa6GYcAAU3s2pu9ypApfZuahgUqp4Rtj5Wv4clKV
LTgV9/PSc0Y56itPLPWPjCWAJY7WZS1bMCrxVievvC11ocquv+nAJC9L2RqRSHFa
IscSrMGUVpO30MxcnqJtaMnKY8OP+3Sl0m2QgNAMdoX/LG8GRTs=
=Ynf6
-----END PGP SIGNATURE-----

--Apple-Mail=_8B9752DB-041D-4FB8-8D78-8F158D2211C4--


From nobody Thu Nov  2 12:33:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF9F139504 for ; Thu,  2 Nov 2017 12:33: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, 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 NyYqi46fiCxQ for ; Thu,  2 Nov 2017 12:33:49 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94940139612 for ; Thu,  2 Nov 2017 12:33:49 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id a192so475818pge.9 for ; Thu, 02 Nov 2017 12:33:49 -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=v6Y0rmm1+m7Y7sPK0vu5HCButAJfu/1sxzS1DNcsD9k=; b=Patxw0S7sB5lX3tjzoupLDXxwjC9j41TkM5lIVGZ1Qt75HKSB3m6tjodA42856ZQNj dA0gb/5Awc1OfsXdDSixFxgN0ZCAWEbNToPuk7DKq4doyG4/WfAWBgP8LaE0tj/IK8S1 iwOb5ZWGAJXI7fFriO9HAyw9pW8RaX6z+HMsLF7VyUfhe/poMcswm8AhtS/AN24EgXAm EBr5M3nYvnZEBi7dAnNgZPBT6OrQoU+nnYkx3TFcw9pIRP5vWAibQABJLmH3WQRTpKwl YAYCrKKkVt5Nm4x3xj8XQnZBDdUu2uv9lW9wIfGq/W3s6k00ZiABxclVE52mdWmmrMLX qZtA==
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=v6Y0rmm1+m7Y7sPK0vu5HCButAJfu/1sxzS1DNcsD9k=; b=bEPp3mWo6zOlaoQ0ZbrhBlC3OPucBZvqcy7SyXxFr7vC2872kHcUns8sIt5nJRtNze KhPEfSPwrAPIAKl6v9jXeqL7s6SYOuO4lymXpKMAO3j2cGKdE4P8UcVaOLnw7XENtGUu tsRJ7NsHWIrEShTZOdrkWjQ8lk/QQKXQMtvTWdUbdquJogCGeEN6XOPLjdM9HttYyCOv 23zPG8i/JONRhB30OWLyTZYvhJsi9DtEbE1lA73oGcrGGGCrDS3T1Fetqm0rzPdn9LiG b1s1tZ/1p/XojeCigi/Q9GvHmUsIz7ijoSiOS5OsjFRsVdZeFIH3u6xoPweZtMn2jy4e usDw==
X-Gm-Message-State: AMCzsaWJ4JQAZKdjnAchJU7ZhvfUSBnSHw2OkKjyqvN8K1VZ4SKKewVF S3RN7XA3zrblw+d0Yg8+eNoOKQ==
X-Google-Smtp-Source: ABhQp+R1GFsY9iIUECRUY4S8M/FbNf3gNqMPz7+wciWtN/POKJKZdH/tH3hsmZ/KPF9KjgV5qDV/HQ==
X-Received: by 10.84.133.132 with SMTP id f4mr4323568plf.197.1509651228840; Thu, 02 Nov 2017 12:33:48 -0700 (PDT)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v190sm6666871pgv.25.2017.11.02.12.33.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 12:33:47 -0700 (PDT)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: "C. M. Heard" , 6man WG 
Cc: Michael Richardson 
References:  <23308.1509623865@obiwan.sandelman.ca> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Fri, 3 Nov 2017 08:33:51 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Nov 2017 19:33:52 -0000

On 03/11/2017 04:26, C. M. Heard wrote:
> On Thu, Nov 2, 2017, Michael Richardson  wrote:
> 
>>
>> C. M. Heard  wrote:
>>     > On Wed, 01 Nov 2017, Michael Richardson wrote:
>>     >> Yet we skip other extension headers in order to find the ULP.
>>
>>     > Not so. An end node that encounters an unrecognized extension header
>> is
>>
>> Both AH and IPIP are well known and recognized extension headers.

AH is an extension header. "IPIP" isn't. It's Protocol 41, and Protocol 41
is otherwise known as IPv6. (That's why it's also called IPPROTO_IPV6).
In RFC8200 terms that makes it an "upper-layer header". Strictly speaking,
RFC8200 doesn't specify what to do with an unrecognized upper-layer header.

    Brian

>>
> 
> Not to a node that does not have any IPsec code at all (or that has IPsec
> turned off).
> 
>  On Wed, 1 Nov 2017, Mikael Abrahamsson wrote:
> 
>>
>>    > If the device isn't configured to do IPsec (even by default), then I don't
>>    > think it should do what you describe.
>>
>> Yet we skip other extension headers in order to find the ULP.
>> In fact, a host that has *NO* IPsec code *at all* will skip it as an unknown
>> header....  Because we got this wrong, we couldn't use AH to secure ND or any
>> other multicast (like OSPF) without causing of a flag day.  AH became totally
>> USELESS.  It was sad.
>>
>>
>> Right. I forgot that IPSEC is an extension header in IPv6, I tought of it as
>> something that was encapsulated. So I take back what I said.
> 
> 
> No, you were right the first time. Unknown extension headers are not
> skipped; they cause the packet to be discarded (see RFC 8200, Sec 4).
> 
> Mike Heard
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Thu Nov  2 12:36:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E386813F8E4 for ; Thu,  2 Nov 2017 12:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjuwMxtBBd-Q for ; Thu,  2 Nov 2017 12:36:25 -0700 (PDT)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E499F13F8E5 for ; Thu,  2 Nov 2017 12:36:24 -0700 (PDT)
Received: by mail-pg0-x232.google.com with SMTP id a192so481117pge.9 for ; Thu, 02 Nov 2017 12:36:24 -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=8mx2aG6kkotoMsQupUxQispAR4t5Mm3ffH1c2YgGDqM=; b=ZDUhRPGWqZ5maRpm6iMpiNFM+OH5BGjfUWfCUt0HkFMSF2E6Fkmpe7JMqSAaCl8vsR 8u8gE+WleYl+ktp4PNrgTgc6rh2cm2TC4V8qC5YDlSv66cdrMswzdTdg5ZC051095nP/ 5zZL2j9qyc0PZ1peVqMIIhR5ZjwgQTyzIxTAJEMlQtSYqXghdJRKXITjL+lwqeT/mAXV P9toPV/f5NBy27DFpd0H15F9z9VHumTGrU1OlZnXsopeLO9ZDgZtVQX2+9SjJjwtZulF LdrpLgepudSaVSkKMHxYFL87plbQ1OkQMGHPw/Yq5hGvnArnBQB8ID4SDaOTiWdHEA+Z yDlQ==
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=8mx2aG6kkotoMsQupUxQispAR4t5Mm3ffH1c2YgGDqM=; b=mT+Cd1u2K+57dfqMlBAaS0kZbAn7E0/JqQmqNkZYOJ8fWiZM/s7SzCzfbHZx9du9La fovoypkRB95WSnaRlKuol8AO77Xl/LdsWO91bKhWThRro+5hnEmCFnBPOSiuIBvfGZ6b KvsmAeMJtjSjNtBqeSsrjzJcV0a3ZRkQpEGM4CN5K606E0JsRjTFY+ZvZyfjxHq6Ayf1 WirVrXxfa91lF+t3+HjYiDSrjwOWPOx1CN9nByIn6oNzD1e7Om+ONkPa/o2p/GSD6QEj b4rCou0JcmSvLtfi1GLdPqb08g09xr2n+Gf/M1StqlKhg62rVYsUspESWJFDE0fTpPad d/Yg==
X-Gm-Message-State: AMCzsaU6ak+x/zkAz4LoyxA58fugEKDTAoWznoHhQLgKie9ckJVz7E0G m+Aj1YEw0YIaru5dgZYJ768ysQ==
X-Google-Smtp-Source: ABhQp+QkIHhPGN77Eh8kSFcgf/4923PrAW4nDS+gPqpVPokSWVlIQGLrMTP5alNF04QV/haPuDZmZA==
X-Received: by 10.101.86.196 with SMTP id w4mr4746027pgs.335.1509651384200; Thu, 02 Nov 2017 12:36:24 -0700 (PDT)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b28sm8541449pfl.86.2017.11.02.12.36.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 12:36:23 -0700 (PDT)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Tim Chown , Michael Richardson 
Cc: 6man WG 
References:  <6286.1509408085@obiwan.sandelman.ca>  <25055.1509413008@obiwan.sandelman.ca>  <19111.1509476559@obiwan.sandelman.ca>  <17463.1509567470@obiwan.sandelman.ca> <460D9142-43AE-4B5F-AABA-4E3E8B322AB4@jisc.ac.uk>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <0237774e-3af9-e58a-05ca-c7088813c21e@gmail.com>
Date: Fri, 3 Nov 2017 08:36:27 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <460D9142-43AE-4B5F-AABA-4E3E8B322AB4@jisc.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Nov 2017 19:36:27 -0000

On 03/11/2017 00:23, Tim Chown wrote:
> Hi Michael,
>=20
>> On 1 Nov 2017, at 20:17, Michael Richardson  wr=
ote:
>>
>>
>> Mark Smith  wrote:
>>> I think we need to be clear about what is "inserting" is. To me, the =
word
>>> "inserting" means inserting to into something that already exists and=
 has
>>> previously been created - cut apart, insert, glue back together.
>>
>> You can mince words here if you like, I don't mind.
>>
>> If someone wants to add a packet by encapsulating with a new IP header=
, then
>> they have to pick a destination address for that header, and if they k=
eep the
>> same destination as the inner one, then the end host has to process tw=
o headers.
>>
>> So, if one wants to make the advice of 8200 useable in practice, then =
one
>> has to fix 6463.
>>
>> If one argues that this will hard and shouldn't be done, then 8200 mus=
t be
>> wrong in some way.
>=20
> So the 6man chairs were quite keen that we try to push 6434-bis to a co=
nclusion in Singapore, which is a goal the authors are very happy to shar=
e.
>=20
> Obviously, reopening this issue may prove to be contentious.  The simpl=
est and easiest answer is to punt it to a separate draft, and wrap up 643=
4-bis. I *think* the only other contentious issue that=E2=80=99s still op=
en for the -bis is what we choose to say, or not say, about RAs vs DHCPv6=
=2E  In my view, wherever possible we should be just including pointers t=
o existing text in other RFCs, and minimising any additional interpretati=
on.

Yes. I think it would be a misuse of a "node requirements" document to sp=
ecify
something that isn't already well specified elsewhere.

> Having said that, why don=E2=80=99t you try to write some succinct text=
 in advance of the Singapore 6man slot, post it, and see what the reactio=
n is?  Worst case, you=E2=80=99ll then have the basis for a separate draf=
t.

We need this. Michael is correct that it's a gap in the standards.

    Brian

>=20
> Tim
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From nobody Thu Nov  2 13:55:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A5713F95F for ; Thu,  2 Nov 2017 13:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.2
X-Spam-Level: 
X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Mz6LzFuknEY for ; Thu,  2 Nov 2017 13:55:50 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2ACE13F95E for ; Thu,  2 Nov 2017 13:55:49 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5AA7EBD1B9 for ; Thu,  2 Nov 2017 16:55:46 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=OSmzzT0vAKHsy73jkVEGBsfSH5Q=; b=Jj95FI 4c8M/aqh9QTxorwDLU0ENzcWLTntSh4a7a8w9VjXL91q4GecM+wOXJKydLjRQZqO /xECAdJjmDzeFrx71528uvneVBERI2HFokLPg6zrmvgnY77Pow7aseVjTybdzXYY 4zKwsUR33CnxFj1j1Bix3pY0FKjbSg80pgagE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=VnR03qTYlggNummxFzkGWkkukXhTn0co MOl8TI+WR3u2jK3gnUbZ+7rxD33aufiiTNE2tjwl9ZJoNAhf7sQrUl80tWF9b9JO k5r0ojC5XGrW7E7U6MO2+eUmQX2cHoUU8iWPMATvv0TEDCa7zh95Y0+87CUEg4Hc rGnse1QgAAo=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 522E2BD1B8 for ; Thu,  2 Nov 2017 16:55:46 -0400 (EDT)
Received: from mail-qk0-f177.google.com (unknown [209.85.220.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id C5F00BD1B4 for ; Thu,  2 Nov 2017 16:55:45 -0400 (EDT)
Received: by mail-qk0-f177.google.com with SMTP id o187so958737qke.7 for ; Thu, 02 Nov 2017 13:55:45 -0700 (PDT)
X-Gm-Message-State: AJaThX4f3GL2ZBetY7sMZNcxC1dnm0elmGut/+7YH6Qf1mYEQrBaulrD bOFJp/gSWbwlpBwzb0TUJcSZSOYPqE9jtcMJ1MM=
X-Google-Smtp-Source: ABhQp+Qmfr429/5K/ktRBoFEs/hcPZYDErWXIiIpQS0H/tejYJiCPIoPcO89YvBrDKwLkKyx3NTUkjiOAfJFz2fd5co=
X-Received: by 10.55.97.202 with SMTP id v193mr6354959qkb.165.1509656144974; Thu, 02 Nov 2017 13:55:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.38.241 with HTTP; Thu, 2 Nov 2017 13:55:24 -0700 (PDT)
In-Reply-To: 
References:  <23308.1509623865@obiwan.sandelman.ca>  
From: "C. M. Heard" 
Date: Thu, 2 Nov 2017 13:55:24 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: 6man WG 
Cc: Mikael Abrahamsson , Michael Richardson 
Content-Type: multipart/alternative; boundary="94eb2c05b7d8411a4a055d063698"
X-Pobox-Relay-ID: 328F1966-C010-11E7-9FB9-575F0C78B957-06080547!pb-smtp2.pobox.com
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Nov 2017 20:55:51 -0000

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

On Thu, Nov 2, 2017 at 9:48 AM, Mikael Abrahamsson  wrote:

> On Thu, 2 Nov 2017, C. M. Heard wrote:
>
> Right. I forgot that IPSEC is an extension header in IPv6, I tought of it
>>> as
>>> something that was encapsulated. So I take back what I said.
>>>
>>
>> No, you were right the first time. Unknown extension headers are not
>> skipped; they cause the packet to be discarded (see RFC 8200, Sec 4).
>>
>
> Sure, but if the device understands IPSEC but has it turned off, what
> should it do?
>
> I don't know.


Presumably, it should behave as if no SPIs were configured. It would the
treat every IPsec packet as if it had an unknown SPI and discard it. Of
course, an IPsec implementation could have an "AH Bypass" option, but that
would be non-standard behaviour.

--cmh

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


On T=
hu, Nov 2, 2017 at 9:48 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Thu, 2 Nov 2017, C. =
M. Heard wrote:





Right. I forgot that IPSEC is an extension header in IPv6, I tought of it a=
s

something that was encapsulated. So I take back what I said.





No, you were right the first time. Unknown extension headers are not

skipped; they cause the packet to be discarded (see RFC 8200, Sec 4).





Sure, but if the device understands IPSEC but has it turned off, what shoul=
d it do?



I don't know.

Presumably, it should beh=
ave as if no SPIs were configured. It would the treat every IPsec packet as=
 if it had an unknown SPI and discard it. Of course, an IPsec implementatio=
n could have an "AH Bypass" option, but that would be non-standar=
d behaviour.

--cmh


--94eb2c05b7d8411a4a055d063698--


From nobody Thu Nov  2 14:31:01 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E2F13F9D2 for ; Thu,  2 Nov 2017 14:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZaZqeJyy89y for ; Thu,  2 Nov 2017 14:30:58 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA9F13F9CE for ; Thu,  2 Nov 2017 14:30:57 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 4E9ABBD9D7 for ; Thu,  2 Nov 2017 17:30:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=o7SY+laxAo2rKHelEqOY4T+5E4I=; b=DQgvHF pTQ1ed2rBz3W8js3B2BiUcb2CNbD/O9b2gsGIJxQjsqK1KYin/xULguHGf3k6vNC HrywtlbvLog6UsWtf8Xnsh5tB+v0SommE+AhDRTztOP/x2JLqhSAfV+PDgj0UJvm DUAS5gBFe5R9XkYwPhI69EXZgUeCnOi88i1RI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=kCqWzro4TvMwU3DUxK52Q+SO4lJZaFo6 y18II2UCZ/7KElGeoc6SHz7oZdCtd470gS7OD5VmSVY7w2atufxM9X9ld1agz+Wv bVV0U6DW1MjF862RrcMOttC3Dzkd5baBRx5OG63eElodfjmo0+tu2eSSJT7CAXde iMk0Rzj0EmA=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 44DBABD9D5 for ; Thu,  2 Nov 2017 17:30:57 -0400 (EDT)
Received: from mail-qk0-f176.google.com (unknown [209.85.220.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id D314CBD9D3 for ; Thu,  2 Nov 2017 17:30:56 -0400 (EDT)
Received: by mail-qk0-f176.google.com with SMTP id f199so1085006qke.2 for ; Thu, 02 Nov 2017 14:30:56 -0700 (PDT)
X-Gm-Message-State: AJaThX6eUzmoaJp0WeEinr6Jpfo75QV845cC0dL7OfqPgWc3z865eXie Fl5f1KGRL3byOBzj1KwQ6/KrSXHl19BEsZIQrpg=
X-Google-Smtp-Source: ABhQp+Q70dp0TGfh8kkace+aa6puBUIF1DnFDOFtWUz4BjeKf5ttLhpfzW/VlB7jWKXBLhggtzn0i6oWf/IwDZ9x9ms=
X-Received: by 10.55.101.81 with SMTP id z78mr6819628qkb.161.1509658256038; Thu, 02 Nov 2017 14:30:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.38.241 with HTTP; Thu, 2 Nov 2017 14:30:35 -0700 (PDT)
In-Reply-To: 
References:  <23308.1509623865@obiwan.sandelman.ca>  
From: "C. M. Heard" 
Date: Thu, 2 Nov 2017 14:30:35 -0700
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: 6man WG 
Cc: Brian E Carpenter , Michael Richardson 
Content-Type: multipart/alternative; boundary="94eb2c057972155f90055d06b441"
X-Pobox-Relay-ID: 1CD852C2-C015-11E7-A80C-575F0C78B957-06080547!pb-smtp2.pobox.com
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Nov 2017 21:31:00 -0000

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

On Thu, Nov 2, 2017 at 12:33 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 03/11/2017 04:26, C. M. Heard wrote:
> > On Thu, Nov 2, 2017, Michael Richardson  wrote:
> >
> >>
> >> C. M. Heard  wrote:
> >>     > On Wed, 01 Nov 2017, Michael Richardson wrote:
> >>     >> Yet we skip other extension headers in order to find the ULP.
> >>
> >>     > Not so. An end node that encounters an unrecognized extension
> header
> >> is
> >>
> >> Both AH and IPIP are well known and recognized extension headers.
>
> AH is an extension header. "IPIP" isn't. It's Protocol 41, and Protocol 41
> is otherwise known as IPv6. (That's why it's also called IPPROTO_IPV6).
> In RFC8200 terms that makes it an "upper-layer header". Strictly speaking,
> RFC8200 doesn't specify what to do with an unrecognized upper-layer header.
>

Actually, it does, and the disposition is exactly the same as for an
unrecognzed
extension header. Both come under the heading of ICMP Code 1 ("unrecognized
Next Header type encountered").  See the second paragraph on page 9. Indeed,
it could hardly be done any other way, since it's not possible for a node
to tell
whether an unrecognized Next Header type represents an extension header
or an upper-layer header.

--cmh

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


On T=
hu, Nov 2, 2017 at 12:33 PM, Brian E Carpenter <brian.e.carpente=
r@gmail.com> wrote:
On 03/11/2017 04:26, C. M. Heard wrote:

> On Thu, Nov 2, 2017, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

>

>>

>> C. M. Heard <heard@pobox.com=
> wrote:

>>=C2=A0 =C2=A0 =C2=A0> On Wed, 01 Nov 2017, Michael Richardson wr=
ote:

>>=C2=A0 =C2=A0 =C2=A0>> Yet we skip other extension headers in=
 order to find the ULP.

>>

>>=C2=A0 =C2=A0 =C2=A0> Not so. An end node that encounters an unr=
ecognized extension header

>> is

>>

>> Both AH and IPIP are well known and recognized extension headers.<=
br>


AH is an extension header. "IPIP" isn't. It's Prot=
ocol 41, and Protocol 41

is otherwise known as IPv6. (That's why it's also called IPPROTO_IP=
V6).

In RFC8200 terms that makes it an "upper-layer header". Strictly =
speaking,

RFC8200 doesn't specify what to do with an unrecognized upper-layer hea=
der.

Actually, it does, and the disposi=
tion is exactly the same as for an unrecognzed
extension header. =
Both come under the heading of ICMP Code 1=C2=A0("unrecognized
Next Header=C2=A0type encountered").=C2=A0 See the second p=
aragraph=C2=A0o=
n page 9. Indeed,
it could hardly be done any other way, since it's not=C2=
=A0possible for=
 a node to tell
whether an=C2=A0unrecognized Next Header=C2=A0type=C2=A0represents an extension header
or an upper-layer header.

--cmh


--94eb2c057972155f90055d06b441--


From nobody Thu Nov  2 18:44:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D5D13FB10 for ; Thu,  2 Nov 2017 18:44:27 -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 1OvjldU6DYfG for ; Thu,  2 Nov 2017 18:44:25 -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 7971313FB0F for ; Thu,  2 Nov 2017 18:44:25 -0700 (PDT)
Received: by mail-pf0-x22c.google.com with SMTP id n89so1048660pfk.11 for ; Thu, 02 Nov 2017 18:44:25 -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=W6BVvf4ttR6OmFD9gP9Mzt43lAuJ3Da1LnRAuEx+LaQ=; b=ZV8FnFw+U1e9snOcqPPM9ezkpBqdlYpDWyVHf03c6Rtp4reaCY4UF4yiNokdCgo7uM ams87zknGmdls46IMvyH/nPNgGpnqS7WhLJUfVM+Ouc31XpBqBqSb7TNTdnYOz83I029 QVlp2MNGAiHv5xKSMMUcNFaE1Qi0jAV42jOuSkekJi6ikoR+JOOAFFWHKlw0t9z733sZ WgpS8FlSupCZw7a66fPg/SPy5oSIPeZLh3ZqR2IZgBvkdbHJj6oBXECJj7EFn94oKwqa lnAAwxmBIz4xUKAjnSPCqXjsaIsp/QCSDw2QOtIjbupm4pVBF6Cc1m3mb3LxhgS1Pox0 1avA==
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=W6BVvf4ttR6OmFD9gP9Mzt43lAuJ3Da1LnRAuEx+LaQ=; b=cGJbk+330ytU1nE3W8/4Y8owBkDBEPGXsqxKeLHy+h4Q7R9YmYGQawZntpXTF91iej WoYnAlYPMsXp+qEwdmYfyYz8hYGoDtkvtgL0kD7Jb5smlRB0tnWMYByuyuXF9YGT8rDZ U0c8sBuGV1e+es9lCy66tv13d6DUPmn+Bc1sWt+LllaBbelrvakovet3IEedqPGnsUWb H5BBgN1rhXJS00nzCB+Qk8HF6EKjSn8GOIXWjE+ZzuYQXqPhK+b4lP3F4dZxIBVqR0AF cG5zL7eia/CV/UGEv/o1bQKzYkZldmel6+fK5K9r4c8+8GVBGU9QarEt2iRcFwV1mBHI MEYg==
X-Gm-Message-State: AMCzsaWNCTrsxLqlYvECDpeCJGcH26rjGQDbFrnEQV6uFXizlLvlWZAd MfJBGXw6n1wjteyLG0QtQfE=
X-Google-Smtp-Source: ABhQp+SRhUvLK1cbHACadnrqsp93BROpS2beHSSqB7W8sEggNEJFkALTZn0Oe8ITDC8peXMzj+0mTA==
X-Received: by 10.99.103.5 with SMTP id b5mr5554427pgc.447.1509673464944; Thu, 02 Nov 2017 18:44:24 -0700 (PDT)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t2sm8444796pfk.90.2017.11.02.18.44.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 18:44:24 -0700 (PDT)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: "C. M. Heard" , 6man WG 
Cc: Michael Richardson 
References:  <23308.1509623865@obiwan.sandelman.ca>   
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Fri, 3 Nov 2017 14:44:29 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 03 Nov 2017 01:44:27 -0000

On 03/11/2017 10:30, C. M. Heard wrote:
> On Thu, Nov 2, 2017 at 12:33 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>> On 03/11/2017 04:26, C. M. Heard wrote:
>>> On Thu, Nov 2, 2017, Michael Richardson  wrote:
>>>
>>>>
>>>> C. M. Heard  wrote:
>>>>     > On Wed, 01 Nov 2017, Michael Richardson wrote:
>>>>     >> Yet we skip other extension headers in order to find the ULP.
>>>>
>>>>     > Not so. An end node that encounters an unrecognized extension
>> header
>>>> is
>>>>
>>>> Both AH and IPIP are well known and recognized extension headers.
>>
>> AH is an extension header. "IPIP" isn't. It's Protocol 41, and Protocol 41
>> is otherwise known as IPv6. (That's why it's also called IPPROTO_IPV6).
>> In RFC8200 terms that makes it an "upper-layer header". Strictly speaking,
>> RFC8200 doesn't specify what to do with an unrecognized upper-layer header.
>>
> 
> Actually, it does, and the disposition is exactly the same as for an
> unrecognzed
> extension header. Both come under the heading of ICMP Code 1 ("unrecognized
> Next Header type encountered").  See the second paragraph on page 9. Indeed,
> it could hardly be done any other way, since it's not possible for a node
> to tell
> whether an unrecognized Next Header type represents an extension header
> or an upper-layer header.

Yes, that particular elephant stands politely and quietly in the corner
of the room. However, I'd just read the text you cite when I wrote my
message and I'll stick to what I said: we *specify* action for an
unrecognized extension header, but we ignore the elephant and *don't*
specify action for an unrecognized ULP. Consider it a drafting error,
or a design error. I agree with you about the practical effect: an
unexpected IPIP packet is likely to generate ICMP 1 today.

   Brian


From nobody Sat Nov  4 18:32:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4D613FC39 for ; Sat,  4 Nov 2017 18:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1C5YG4pmMy5 for ; Sat,  4 Nov 2017 18:32:31 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD91913FC38 for ; Sat,  4 Nov 2017 18:32:30 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 24D91200F4; Sat,  4 Nov 2017 21:33:35 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BFADF81F0B; Sat,  4 Nov 2017 21:32:29 -0400 (EDT)
From: Michael Richardson 
To: Mikael Abrahamsson 
cc: "C. M. Heard" , 6man WG 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
In-Reply-To: 
References:  <23308.1509623865@obiwan.sandelman.ca>  
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 01:32:35 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Mikael Abrahamsson  wrote:
    >>> Right. I forgot that IPSEC is an extension header in IPv6, I tought
    >>> of it as something that was encapsulated. So I take back what I sai=
d.
    >>=20
    >> No, you were right the first time. Unknown extension headers are not
    >> skipped; they cause the packet to be discarded (see RFC 8200, Sec 4).

    > Sure, but if the device understands IPSEC but has it turned off, what
    > should it do?

    > I don't know.

Exactly.
Depends entirely on what "turned off" means.
Probably it means that the SPI# is not configured.
For ESP, dropping the packet makes sense, because you can't decrypt and you
can't know what's "beyond" the ESP without knowing the parameters (so even
ESP_NULL encryption can't be skipped).

But, AH has the property that we *know* it's not encrypted, and we know the
size of everything, and so we can just skip things if the integrity check is
not for us.

If we can gotten that right, we could have used AH for multicasted traffic,
and even for some interesting uses where we want to authenticate that things
went through certain routers.


=2D-=20
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAln+ai0ACgkQgItw+93Q
3WXg1QgAj+ETQp3Vj5RGPY4Nyi8F8wvupXZPIscE1O6Ef8zYG8f2Qx+72mhtoxnm
BRuDKoNt70qoaqKr1DaS47kligPheGVYsnNr/Hj9HbyaQ7Ffo2owmpbUEgXUG8zE
+rOyZ+2U/zFKtxvQyxcB0Zdv05a1HAPpDFYq4U+cWQZTUcMDc9tJcqecDvI5uKsk
VLtYNz183WnlwVGPdaBMYMnVKOI3madrFePf+XcKkLmsiZdoafJINWBYjjn0opZ+
rjRzd8+IMF9kHbRWQLNbYa3st5tcJBF5UY2tWFJp9ssZ1dhkfP5kvtEv3Sv4SHkC
cdltLakMNbS6lmSxJv2lVZsGB+1DbA==
=40Hp
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Sat Nov  4 18:37:06 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1393613FC38 for ; Sat,  4 Nov 2017 18:37: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 TVwko1daiYVX for ; Sat,  4 Nov 2017 18:37:03 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C415613FAE3 for ; Sat,  4 Nov 2017 18:37:03 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0D5D1200F4; Sat,  4 Nov 2017 21:38:08 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A556181F0B; Sat,  4 Nov 2017 21:37:02 -0400 (EDT)
From: Michael Richardson 
To: Brian E Carpenter 
cc: "C. M. Heard" , 6man WG 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
In-Reply-To: 
References:  <23308.1509623865@obiwan.sandelman.ca>    
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 05 Nov 2017 01:37:05 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Brian E Carpenter  wrote:
    > Yes, that particular elephant stands politely and quietly in the corn=
er
    > of the room. However, I'd just read the text you cite when I wrote my
    > message and I'll stick to what I said: we *specify* action for an
    > unrecognized extension header, but we ignore the elephant and *don't*
    > specify action for an unrecognized ULP. Consider it a drafting error,
    > or a design error. I agree with you about the practical effect: an
    > unexpected IPIP packet is likely to generate ICMP 1 today.

okay, so shouldn't 6463 fix this part at least?

=2D-=20
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAln+az4ACgkQgItw+93Q
3WWCHggAll6FSHOP6IKSmrGu3Kq6GZ/l/dsY9IlxTi88JbJRce9Pnmpo0ByCFn6J
Ft2elKOcAYRN3naaEcJSH9vmtRK4KZvaOpnVGCKaXXgygr71bhNGUa/cHaLavASD
fgUJ9O3Rf4vmRKFA1Nai3luJEXogZQuLcxJxe6NGhnUf9MjdrYlc3obUF6U/nNHQ
X62pl16JA1+6aoct6m1qXeSRppKErorkzQK5Hgb8j5tnauK5g4cNoYwjatKcYjVU
EzsStNbdQIUR1SpYlApMRF7XOgU7J2iDBXScZOboDXqfve0Rs6fMa4zOj6KUFr4d
9LVKNMWqe22uelChor83RzTuQslEuw==
=MDkL
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Nov  6 02:30:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12DD613FB93 for ; Mon,  6 Nov 2017 02:30:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCaNSahm00gJ for ; Mon,  6 Nov 2017 02:30:21 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B9613FA82 for ; Mon,  6 Nov 2017 02:30:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1509964218; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=GVA4vjYz4CWp6kjlEuQKmAXMvGBi1qP7QZD9MsXB/e4=; b=VYyjnxppznjv5CTvVzzlcdYAO4RK/rIOHUQU8+iJ70nGtsU3uT3GQNg4XTpb7evgiCmaVTUXeVWKHbruV+9T/0w2PP0Sr4OtgusyK4NDD0QykTdbtg8BTIcY4uthi/jYa496YYXFOq1vb8vGYiN78tAiRrpzAii883ZoSYKmyL8=
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0180.outbound.protection.outlook.com [213.199.180.180]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-112-VSe_eHIxNJGB_9yDwVw1Zw-1; Mon, 06 Nov 2017 10:30:16 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Mon, 6 Nov 2017 10:30:14 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0218.005; Mon, 6 Nov 2017 10:30:14 +0000
From: Tim Chown 
To: Michael Richardson 
CC: Brian E Carpenter , "C. M. Heard" , 6man WG 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Topic: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Index: AQHTU4K/vqPz1IcGUEyBNF2bHgm6GqMFBj08gAInMQA=
Date: Mon, 6 Nov 2017 10:30:14 +0000
Message-ID: 
References:  <23308.1509623865@obiwan.sandelman.ca>     <7923.1509845822@obiwan.sandelman.ca>
In-Reply-To: <7923.1509845822@obiwan.sandelman.ca>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [194.82.140.195]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 20:DHjTlCpRY2F7HWO8dfGLh/OWH71QQA5MtSOREgpuWBQb+z4GFAJ293wHZAhBml1a6G1QMiE5fx4le3ps/PBlDMc0tWayGQWpbaENVGtl9AekGnhm4qxUAga01RcGb/Hn+p5CvvI9hBVfa/tYGOs9RZttuAFzaVk1nrp/HKDgc8w=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b02f34dc-ae84-418f-3d88-08d525015e1c
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249); SRVR:AM3PR07MB1138; 
x-ms-traffictypediagnostic: AM3PR07MB1138:
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)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3231021)(6041248)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1138; 
x-forefront-prvs: 048396AFA0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(24454002)(199003)(50226002)(101416001)(106356001)(76176999)(86362001)(25786009)(53936002)(478600001)(6512007)(6116002)(3846002)(102836003)(72206003)(5250100002)(39060400002)(83716003)(50986999)(6246003)(66066001)(6506006)(8676002)(81156014)(57306001)(105586002)(68736007)(81166006)(6436002)(6486002)(229853002)(8936002)(54906003)(189998001)(786003)(316002)(3280700002)(3660700001)(2900100001)(33656002)(8656006)(82746002)(5660300001)(7736002)(2950100002)(74482002)(97736004)(99286004)(305945005)(14454004)(53546010)(93886005)(36756003)(2906002)(42882006)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; 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-Network-Message-Id: b02f34dc-ae84-418f-3d88-08d525015e1c
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2017 10:30:14.5959 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138
X-MC-Unique: VSe_eHIxNJGB_9yDwVw1Zw-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 10:30:23 -0000

SGkgTWljaGFlbCwNCg0KPiBPbiA1IE5vdiAyMDE3LCBhdCAwMTozNywgTWljaGFlbCBSaWNoYXJk
c29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiANCj4gDQo+IEJyaWFuIEUgQ2Fy
cGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPj4gWWVzLCB0aGF0
IHBhcnRpY3VsYXIgZWxlcGhhbnQgc3RhbmRzIHBvbGl0ZWx5IGFuZCBxdWlldGx5IGluIHRoZSBj
b3JuZXINCj4+IG9mIHRoZSByb29tLiBIb3dldmVyLCBJJ2QganVzdCByZWFkIHRoZSB0ZXh0IHlv
dSBjaXRlIHdoZW4gSSB3cm90ZSBteQ0KPj4gbWVzc2FnZSBhbmQgSSdsbCBzdGljayB0byB3aGF0
IEkgc2FpZDogd2UgKnNwZWNpZnkqIGFjdGlvbiBmb3IgYW4NCj4+IHVucmVjb2duaXplZCBleHRl
bnNpb24gaGVhZGVyLCBidXQgd2UgaWdub3JlIHRoZSBlbGVwaGFudCBhbmQgKmRvbid0Kg0KPj4g
c3BlY2lmeSBhY3Rpb24gZm9yIGFuIHVucmVjb2duaXplZCBVTFAuIENvbnNpZGVyIGl0IGEgZHJh
ZnRpbmcgZXJyb3IsDQo+PiBvciBhIGRlc2lnbiBlcnJvci4gSSBhZ3JlZSB3aXRoIHlvdSBhYm91
dCB0aGUgcHJhY3RpY2FsIGVmZmVjdDogYW4NCj4+IHVuZXhwZWN0ZWQgSVBJUCBwYWNrZXQgaXMg
bGlrZWx5IHRvIGdlbmVyYXRlIElDTVAgMSB0b2RheS4NCj4gDQo+IG9rYXksIHNvIHNob3VsZG4n
dCA2NDYzIGZpeCB0aGlzIHBhcnQgYXQgbGVhc3Q/DQoNClRoZSBxdWVzdGlvbiBpcyB3aGV0aGVy
IHdlIGFkZCBzdWNoIOKAnGdhcHPigJ0gdG8gNjQzNC1iaXMsIG9yIHNwaW4gdXAgYSBuZXcgZHJh
ZnQgdG8gdXBkYXRlIDgyMDAsIHdoaWNoIG1pZ2h0IHRoZW4gYmUgcmVmbGVjdGVkIGluIGEgZnV0
dXJlIE5vZGUgUmVxcyB1cGRhdGUuDQoNCknigJltIGVhc3kgZWl0aGVyIHdheSBhcyBhbiBhdXRo
b3Igb2YgdGhlIGRvYywgYnV0IHdvdWxkIGVyciB0b3dhcmRzIG1pbmltaXNpbmcgYWRkaW5nIG5l
dyBtYXRlcmlhbCB0byA2NDM0LWJpcywgYW5kIHRyeWluZyB3aGVyZSBwb3NzaWJsZSB0byBqdXN0
IHBvaW50IHRvIGV4aXN0aW5nIGRvY3VtZW50cy4gDQoNClNvbWUgaW5wdXQgZnJvbSB0aGUgY2hh
aXJzIHdvdWxkIGJlIHdlbGNvbWUuDQoNClRpbQ==


From nobody Mon Nov  6 03:11:02 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B78913FAF3 for ; Mon,  6 Nov 2017 03:11:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eggdTcBDegX0 for ; Mon,  6 Nov 2017 03:10:59 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ADA113FAE1 for ; Mon,  6 Nov 2017 03:10:59 -0800 (PST)
Received: from h.hanazo.no (unknown [173.38.220.35]) (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 8B0372D50CA; Mon,  6 Nov 2017 11:10:57 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C05BB200A59020; Mon,  6 Nov 2017 12:10:53 +0100 (CET)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_C6DC8B9E-7253-4166-A32A-9D33472537DD"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Date: Mon, 6 Nov 2017 12:10:52 +0100
In-Reply-To: 
Cc: Michael Richardson , "C. M. Heard" , 6man WG 
To: Tim Chown 
References:  <23308.1509623865@obiwan.sandelman.ca>     <7923.1509845822@obiwan.sandelman.ca> 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 11:11:01 -0000

--Apple-Mail=_C6DC8B9E-7253-4166-A32A-9D33472537DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Tim,

>>> Yes, that particular elephant stands politely and quietly in the =
corner
>>> of the room. However, I'd just read the text you cite when I wrote =
my
>>> message and I'll stick to what I said: we *specify* action for an
>>> unrecognized extension header, but we ignore the elephant and =
*don't*
>>> specify action for an unrecognized ULP. Consider it a drafting =
error,
>>> or a design error. I agree with you about the practical effect: an
>>> unexpected IPIP packet is likely to generate ICMP 1 today.
>>=20
>> okay, so shouldn't 6463 fix this part at least?
>=20
> The question is whether we add such =E2=80=9Cgaps=E2=80=9D to =
6434-bis, or spin up a new draft to update 8200, which might then be =
reflected in a future Node Reqs update.
> I=E2=80=99m easy either way as an author of the doc, but would err =
towards minimising adding new material to 6434-bis, and trying where =
possible to just point to existing documents.
>=20
> Some input from the chairs would be welcome.

If we are talking about the action for unrecognised next headers, I do =
not see a gap in existing specifications.
If one want to engage in the sport of extreme hair splitting, I wouldn't =
mind if 6434bis were to add some a descriptive paragraph of =
"unrecognized next header including ULP are discarded as specified in =
8200...".

If we are talking about the issue of IP in IP encapsulated packets sent =
to a unsuspecting host, that in my opinion requires a new document.

Best regards,
Ole


--Apple-Mail=_C6DC8B9E-7253-4166-A32A-9D33472537DD
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+/bDNdvtpYqJhC33YFAloAQzwACgkQvtpYqJhC
33a8Aw/+KJWoERa1HgeN/fQUj5urOSsLCzid13yrrdUwwFX+RDF+mcu/EkSzVqwB
3iaREM1ewAfNFgwxzonPkU8pdTzm1YY6BgdwVhJu0XY6EoR+2L8WQla29mOdmwLM
ezhN+JdfEWKmMY/i9BhVj9ZoaXBP7MoIfenmU1uSuAOsmr9+sEVKRR+VgLkIUwW2
0TKkn0gZVo+NnDMsheEBEXICMCUAbyRn+/QKY9h83EMfqyAaSHz/ANuvEQ813ZaN
IOouqJUWttAKG3U4qQgootZV9GXh5VBPLzaCBoXHMGHm87BeV/NaJbicNeFoOBH3
cTOz79tU+ZUHgiwrzLMCeNnW6vnAkGWUZxoNW7x96CZOQrfc4A/DyoaztZcz3d/t
m0zEXeyTxpypXm3IkzXek9b62xCMAZrIInZ/95j5hcA0wpwmx3qdjsB8rIvB7k/b
vQWLyYr53dJtBMZYeeNjzY6ox/lNZXUPPZjCKjHbtULr4pVb4bZX/JbI7SWmZC/d
PtStiAx69sZhyZ7FSbYwwjplRsYPa4WlQm5QbU0J3/JSVqw0QnuFz6aTW6oWBmiO
J18UtPc7dHGC1h8EZCW2CjZHUVOCnRinsXt+r9cTM30b7jEleu7jCgLP+yGdHfDq
qEF1E3mIeUWWs3r6BmeUfUi7NlDb8/9rRwo9JdcjzOZ529eJVFQ=
=zaQJ
-----END PGP SIGNATURE-----

--Apple-Mail=_C6DC8B9E-7253-4166-A32A-9D33472537DD--


From nobody Mon Nov  6 03:36:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB62013FB5C for ; Mon,  6 Nov 2017 03:36:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJtutjFW3JUA for ; Mon,  6 Nov 2017 03:36:49 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8694013FB31 for ; Mon,  6 Nov 2017 03:36:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1509968207; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=QFWVd7EtrRAhmzZOe53PX0L0i7F3XiDzNddxc5hrFpU=; b=Clmolqbc2xFdu1ZKBaesvVza2vGAyvxyktu0cs+tp5dx+A5HjJ365uUD6CuBmlYJH4O+3MJaEgU4xfqy4oBAdhfX5JSO5aj8dyqgEnErV+5xd4zvHWTDhwoxg3X7yIYFC/AOqmLESAE5x5oKerraif+Yni8TlVPgpqRffi5iqLY=
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0119.outbound.protection.outlook.com [213.199.154.119]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-2-3Ek6SkGrNdqy_2c0crDGmg-1; Mon, 06 Nov 2017 11:36:35 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Mon, 6 Nov 2017 11:36:34 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0218.005; Mon, 6 Nov 2017 11:36:34 +0000
From: Tim Chown 
To: Ole Troan 
CC: Michael Richardson , "C. M. Heard" , 6man WG 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Topic: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Index: AQHTU4K/vqPz1IcGUEyBNF2bHgm6GqMFBj08gAInMQCAAAtdAIAABy2A
Date: Mon, 6 Nov 2017 11:36:34 +0000
Message-ID: <602A126A-86C5-4F8C-AFED-B3A2BCE12BB8@jisc.ac.uk>
References:  <23308.1509623865@obiwan.sandelman.ca>     <7923.1509845822@obiwan.sandelman.ca>  
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.3445.4.7)
x-originating-ip: [194.82.140.195]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 20:0IZgs/DGg2zekjngyUGK5uDtHEk4siqhau7BjoGwbNRpS5HRXEq/6rDjed+QfB4/yAEiorQ/oa/2v6/jx870na/vaTVSN5ajftIk1Uz4b4obJsAnUp+He79vfMGh49NHZC4jK0jDYXQoLvR7U0ctK3fVUkY70/bpxAltRNFahrc=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: dff81674-fc15-4361-8c64-08d5250aa24a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249); SRVR:AM3PR07MB1138; 
x-ms-traffictypediagnostic: AM3PR07MB1138:
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)(3231021)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1138; 
x-forefront-prvs: 048396AFA0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(24454002)(189002)(8656006)(82746002)(2900100001)(33656002)(7736002)(6916009)(5660300001)(229853002)(8936002)(316002)(189998001)(3280700002)(3660700001)(786003)(54906003)(53546010)(36756003)(93886005)(14454004)(305945005)(4326008)(2906002)(42882006)(2950100002)(74482002)(99286004)(97736004)(53936002)(25786009)(3846002)(102836003)(6116002)(72206003)(478600001)(6512007)(50226002)(101416001)(86362001)(106356001)(76176999)(105586002)(81156014)(8676002)(57306001)(6486002)(6436002)(81166006)(68736007)(50986999)(6246003)(66066001)(83716003)(5250100002)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <0617009EED5C214C954A333009D26DFF@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: dff81674-fc15-4361-8c64-08d5250aa24a
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2017 11:36:34.4707 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138
X-MC-Unique: 3Ek6SkGrNdqy_2c0crDGmg-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 11:36:52 -0000

PiBPbiA2IE5vdiAyMDE3LCBhdCAxMToxMCwgT2xlIFRyb2FuIDxvdHJvYW5AZW1wbG95ZWVzLm9y
Zz4gd3JvdGU6DQo+IA0KPiBUaW0sDQo+IA0KPj4+PiBZZXMsIHRoYXQgcGFydGljdWxhciBlbGVw
aGFudCBzdGFuZHMgcG9saXRlbHkgYW5kIHF1aWV0bHkgaW4gdGhlIGNvcm5lcg0KPj4+PiBvZiB0
aGUgcm9vbS4gSG93ZXZlciwgSSdkIGp1c3QgcmVhZCB0aGUgdGV4dCB5b3UgY2l0ZSB3aGVuIEkg
d3JvdGUgbXkNCj4+Pj4gbWVzc2FnZSBhbmQgSSdsbCBzdGljayB0byB3aGF0IEkgc2FpZDogd2Ug
KnNwZWNpZnkqIGFjdGlvbiBmb3IgYW4NCj4+Pj4gdW5yZWNvZ25pemVkIGV4dGVuc2lvbiBoZWFk
ZXIsIGJ1dCB3ZSBpZ25vcmUgdGhlIGVsZXBoYW50IGFuZCAqZG9uJ3QqDQo+Pj4+IHNwZWNpZnkg
YWN0aW9uIGZvciBhbiB1bnJlY29nbml6ZWQgVUxQLiBDb25zaWRlciBpdCBhIGRyYWZ0aW5nIGVy
cm9yLA0KPj4+PiBvciBhIGRlc2lnbiBlcnJvci4gSSBhZ3JlZSB3aXRoIHlvdSBhYm91dCB0aGUg
cHJhY3RpY2FsIGVmZmVjdDogYW4NCj4+Pj4gdW5leHBlY3RlZCBJUElQIHBhY2tldCBpcyBsaWtl
bHkgdG8gZ2VuZXJhdGUgSUNNUCAxIHRvZGF5Lg0KPj4+IA0KPj4+IG9rYXksIHNvIHNob3VsZG4n
dCA2NDYzIGZpeCB0aGlzIHBhcnQgYXQgbGVhc3Q/DQo+PiANCj4+IFRoZSBxdWVzdGlvbiBpcyB3
aGV0aGVyIHdlIGFkZCBzdWNoIOKAnGdhcHPigJ0gdG8gNjQzNC1iaXMsIG9yIHNwaW4gdXAgYSBu
ZXcgZHJhZnQgdG8gdXBkYXRlIDgyMDAsIHdoaWNoIG1pZ2h0IHRoZW4gYmUgcmVmbGVjdGVkIGlu
IGEgZnV0dXJlIE5vZGUgUmVxcyB1cGRhdGUuDQo+PiBJ4oCZbSBlYXN5IGVpdGhlciB3YXkgYXMg
YW4gYXV0aG9yIG9mIHRoZSBkb2MsIGJ1dCB3b3VsZCBlcnIgdG93YXJkcyBtaW5pbWlzaW5nIGFk
ZGluZyBuZXcgbWF0ZXJpYWwgdG8gNjQzNC1iaXMsIGFuZCB0cnlpbmcgd2hlcmUgcG9zc2libGUg
dG8ganVzdCBwb2ludCB0byBleGlzdGluZyBkb2N1bWVudHMuDQo+PiANCj4+IFNvbWUgaW5wdXQg
ZnJvbSB0aGUgY2hhaXJzIHdvdWxkIGJlIHdlbGNvbWUuDQo+IA0KPiBJZiB3ZSBhcmUgdGFsa2lu
ZyBhYm91dCB0aGUgYWN0aW9uIGZvciB1bnJlY29nbmlzZWQgbmV4dCBoZWFkZXJzLCBJIGRvIG5v
dCBzZWUgYSBnYXAgaW4gZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMuDQo+IElmIG9uZSB3YW50IHRv
IGVuZ2FnZSBpbiB0aGUgc3BvcnQgb2YgZXh0cmVtZSBoYWlyIHNwbGl0dGluZywgSSB3b3VsZG4n
dCBtaW5kIGlmIDY0MzRiaXMgd2VyZSB0byBhZGQgc29tZSBhIGRlc2NyaXB0aXZlIHBhcmFncmFw
aCBvZiAidW5yZWNvZ25pemVkIG5leHQgaGVhZGVyIGluY2x1ZGluZyBVTFAgYXJlIGRpc2NhcmRl
ZCBhcyBzcGVjaWZpZWQgaW4gODIwMC4uLiIuDQo+IA0KPiBJZiB3ZSBhcmUgdGFsa2luZyBhYm91
dCB0aGUgaXNzdWUgb2YgSVAgaW4gSVAgZW5jYXBzdWxhdGVkIHBhY2tldHMgc2VudCB0byBhIHVu
c3VzcGVjdGluZyBob3N0LCB0aGF0IGluIG15IG9waW5pb24gcmVxdWlyZXMgYSBuZXcgZG9jdW1l
bnQuDQoNClRoYW5rcyBPbGUuDQoNClRpbQ==


From nobody Mon Nov  6 08:33:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6939B13FB3B for ; Mon,  6 Nov 2017 08:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS5C81y6YsFC for ; Mon,  6 Nov 2017 08:33:11 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7BE13FB1D for ; Mon,  6 Nov 2017 08:33:10 -0800 (PST)
Received: from [192.168.3.67] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 277B88014D; Mon,  6 Nov 2017 17:33:06 +0100 (CET)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Michael Richardson , 6man WG 
References:  <6286.1509408085@obiwan.sandelman.ca>  <25055.1509413008@obiwan.sandelman.ca>  <19111.1509476559@obiwan.sandelman.ca>
From: Fernando Gont 
Message-ID: <37b32942-7d1a-dfd8-288d-ce1f937fc484@gont.com.ar>
Date: Mon, 6 Nov 2017 13:15:43 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <19111.1509476559@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 16:33:14 -0000

On 10/31/2017 04:02 PM, Michael Richardson wrote:
> 
> Ole Troan  wrote:
>     > Without having thought very much about it... I do think requiring a
>     > host to accept tunnelled packets to itself by default or not, requires
>     > further considerations.
> 
> I agree: it requires further consideration.
> 
>     > I am aware of no implementation that would support this. I would also
>     > be worried about this opening the door for "alternate" paths into the
>     > host stack.
> 
> I agree. Nobody does it this way.
> Yet 8200 (and 2460 before it) says that this is the way to insert headers.

No. EHs are not inserted or removed. When you do IPinIP, you are
creating a brad-new packet, *not* inserting EHs in the existing packet.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Mon Nov  6 09:00:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8BE13F584 for ; Mon,  6 Nov 2017 09:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 mkdV-IYG3FA8 for ; Mon,  6 Nov 2017 09:00:19 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355EB13FAF7 for ; Mon,  6 Nov 2017 09:00:19 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id p1so11793839qtg.2 for ; Mon, 06 Nov 2017 09:00:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M8VINWRTaxug6UU9U9/Sw2/FnPGznrXq416ZuYY0RjY=; b=ryKez6YIWLkzhDBEwCwFFF379WW0awfkOw6/khfltszPPfuG+d0VMvaGLExhORSo0b w99flSOFskLXgnviVEZ3vxnbI8dB25rKjP9I4DtD2Sh5VW22FMsxbdjFaKrpzhceeqHD t5NEV2HtmmYd2adUgG57FVyp5UtrJJagAas0AR880nRnFLIj1QT3EclTGgan17nVyvrF FHVfgAaAmPjk5LJqR3VzmoCLnxOeM3mEVAjUR7lswb8tfvKdGsyZNQRajx8JTLAkPRVi 1O6C5K0llpELQCOeWqIzZTbXBf/gQaB/3MPNauphc9KzM9F5O7/NL+WEl1Q5nolTlEn5 bBfQ==
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=M8VINWRTaxug6UU9U9/Sw2/FnPGznrXq416ZuYY0RjY=; b=NiOukHPBlpwUdpCPsGNKsPZ5twEw0So+CZlA9JqYcZdVIUrPJ/nKSi1tihjN42SqjC 0efAh63vOP5q84T8dFOm/b5vyzJxhMysuEsmr8Sx3o/M+E1vTDO5e2KV6AEXWcW9Hqlh OpwJ5tSoL8O4lDrETk1X85SvB99WivycKD5zKtH0wObp0fNh2e7kw8+gYnaUWXcd0yXu g+P4meFsY4cQQdGDchSGiM/0d1VJbcll3KRaVYuZ4JOYNK4+BfHoTNxXRfVDgio48KeM awb0j2IeqeizCi8JrnS+9DPZRvn+1zP4/PAe7uV7rOK95mYm7R5Eb9Q0R5QifV56iZHB 9f3A==
X-Gm-Message-State: AMCzsaWoOT4C7n0PSMc5my85cjMFO+8txTIvLPT4ez75CSSxr60/T+yF yh5rZD++jUqgMCw0wBkhN5ZkvkGNx3D/Vs7TOUXkZg==
X-Google-Smtp-Source: ABhQp+QPw8HjmIdACazSwNZJy0EOi85+cZPKuWtyfKucIatMBdryJ3DAfAK3wvXf/2seTZFnTdEdRb4Lly+TI9+qPTg=
X-Received: by 10.200.55.101 with SMTP id p34mr24284605qtb.27.1509987618155; Mon, 06 Nov 2017 09:00:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Mon, 6 Nov 2017 09:00:17 -0800 (PST)
In-Reply-To: <37b32942-7d1a-dfd8-288d-ce1f937fc484@gont.com.ar>
References:  <6286.1509408085@obiwan.sandelman.ca>  <25055.1509413008@obiwan.sandelman.ca>  <19111.1509476559@obiwan.sandelman.ca> <37b32942-7d1a-dfd8-288d-ce1f937fc484@gont.com.ar>
From: Tom Herbert 
Date: Mon, 6 Nov 2017 09:00:17 -0800
Message-ID: 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Fernando Gont 
Cc: Michael Richardson , 6man WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 17:00:21 -0000

On Mon, Nov 6, 2017 at 8:15 AM, Fernando Gont  wrote:
> On 10/31/2017 04:02 PM, Michael Richardson wrote:
>>
>> Ole Troan  wrote:
>>     > Without having thought very much about it... I do think requiring a
>>     > host to accept tunnelled packets to itself by default or not, requires
>>     > further considerations.
>>
>> I agree: it requires further consideration.
>>
>>     > I am aware of no implementation that would support this. I would also
>>     > be worried about this opening the door for "alternate" paths into the
>>     > host stack.
>>
>> I agree. Nobody does it this way.
>> Yet 8200 (and 2460 before it) says that this is the way to insert headers.
>
> No. EHs are not inserted or removed. When you do IPinIP, you are
> creating a brad-new packet, *not* inserting EHs in the existing packet.
>
I agree.

I think the sticking point is going whether a node can blindly perform
IP-IP encapsulation on packets to arbitrary destinations (as opposed
to using IP-IP for explicitly tunneling across a network). This
requires the assumption that all nodes in the downstream path will
forward a packet with IP-IP and the added extension headers, and that
the destination will accept such packets. The problem is that if a
packet is dropped because of the encapsulation or EHs and no ICMP
error is returned to the encapsulator then there is no way to recover.
The original source host might see packets being dropped on a
connection but will have no idea why. The encapsulator sees no problem
and so it won't modify its behavior.

Tom


From nobody Mon Nov  6 09:07:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ACF13FBB1 for ; Mon,  6 Nov 2017 09:07:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqEnf6onyGoB for ; Mon,  6 Nov 2017 09:07:13 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1DE13FB6E for ; Mon,  6 Nov 2017 09:07:13 -0800 (PST)
Received: from [192.168.3.67] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id B11C8804E9; Mon,  6 Nov 2017 18:07:09 +0100 (CET)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Tom Herbert 
Cc: Michael Richardson , 6man WG 
References:  <6286.1509408085@obiwan.sandelman.ca>  <25055.1509413008@obiwan.sandelman.ca>  <19111.1509476559@obiwan.sandelman.ca> <37b32942-7d1a-dfd8-288d-ce1f937fc484@gont.com.ar> 
From: Fernando Gont 
Message-ID: <8843386f-94ba-8887-c35b-900770f49ea3@gont.com.ar>
Date: Mon, 6 Nov 2017 14:08:29 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 17:07:14 -0000

On 11/06/2017 02:00 PM, Tom Herbert wrote:
> On Mon, Nov 6, 2017 at 8:15 AM, Fernando Gont  wrote:
>> On 10/31/2017 04:02 PM, Michael Richardson wrote:
>>>
>>> Ole Troan  wrote:
>>>     > Without having thought very much about it... I do think requiring a
>>>     > host to accept tunnelled packets to itself by default or not, requires
>>>     > further considerations.
>>>
>>> I agree: it requires further consideration.
>>>
>>>     > I am aware of no implementation that would support this. I would also
>>>     > be worried about this opening the door for "alternate" paths into the
>>>     > host stack.
>>>
>>> I agree. Nobody does it this way.
>>> Yet 8200 (and 2460 before it) says that this is the way to insert headers.
>>
>> No. EHs are not inserted or removed. When you do IPinIP, you are
>> creating a brad-new packet, *not* inserting EHs in the existing packet.
>>
> I agree.
> 
> I think the sticking point is going whether a node can blindly perform
> IP-IP encapsulation on packets to arbitrary destinations (as opposed
> to using IP-IP for explicitly tunneling across a network). 

Answer: No. :-)


> This
> requires the assumption that all nodes in the downstream path will
> forward a packet with IP-IP and the added extension headers, and that
> the destination will accept such packets.

First condition: unlikely. Second condition: extremely unlikely.


> The problem is that if a
> packet is dropped because of the encapsulation or EHs and no ICMP
> error is returned to the encapsulator then there is no way to recover.
> The original source host might see packets being dropped on a
> connection but will have no idea why. The encapsulator sees no problem
> and so it won't modify its behavior.

And, as Ole mention, additional issues caused by the possible fragmentation.

Don't rely on layer-3 in layer-3 encapsulation. ENcapsulate in a
transport layer that can segment data as appropriate to avoid layer 3
fragmentation.

Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Mon Nov  6 10:02:00 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FD213FB75 for ; Mon,  6 Nov 2017 10:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW_rS58Aq_qU for ; Mon,  6 Nov 2017 10:01:56 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2AB13FB66 for ; Mon,  6 Nov 2017 10:01:55 -0800 (PST)
Received: from [192.168.3.67] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1EFA280764; Mon,  6 Nov 2017 19:01:52 +0100 (CET)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Michael Richardson , 6man WG 
References:  <6286.1509408085@obiwan.sandelman.ca>  <25055.1509413008@obiwan.sandelman.ca>  <19111.1509476559@obiwan.sandelman.ca>
From: Fernando Gont 
Message-ID: <37279216-12e5-f914-c2c0-63e165401b6c@gont.com.ar>
Date: Mon, 6 Nov 2017 14:52:37 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <19111.1509476559@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 18:01:59 -0000

On 10/31/2017 04:02 PM, Michael Richardson wrote:
> 
> Ole Troan  wrote:
>     > Without having thought very much about it... I do think requiring a
>     > host to accept tunnelled packets to itself by default or not, requires
>     > further considerations.
> 
> I agree: it requires further consideration.

If you feel like doing/proposing this, some thoughts of th top of my head:

* Beware of the Hop Limit, this thing may allow to circumvent GSTM --
think about remote ND attacks... even remote SLAAC.

* You might need to validate source/destination addresses as packets get
decapsulated (e.g., think about scopes)

* Strong end strong end system model and weak end system models might
(or not) apply here [rfc1112]

Cheers,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Mon Nov  6 10:02:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE58B13FC1A for ; Mon,  6 Nov 2017 10:02:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXSKq89kVbqV for ; Mon,  6 Nov 2017 10:02:05 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F6413FBBD for ; Mon,  6 Nov 2017 10:02:05 -0800 (PST)
Received: from [192.168.3.67] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id DCD9D80764; Mon,  6 Nov 2017 19:02:01 +0100 (CET)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Michael Richardson , Mikael Abrahamsson 
Cc: 6man WG 
References:  <6286.1509408085@obiwan.sandelman.ca>  <19087.1509567897@obiwan.sandelman.ca>
From: Fernando Gont 
Message-ID: 
Date: Mon, 6 Nov 2017 14:57:15 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <19087.1509567897@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 18:02:14 -0000

On 11/01/2017 05:24 PM, Michael Richardson wrote:
> 
> Mikael Abrahamsson  wrote:
>     > On Mon, 30 Oct 2017, Michael Richardson wrote:
> 
>     >> And I think that most host stacks discard such things unless configured to
>     >> expect a tunnel from D.
> 
>     > Agreed.
> 
>     >> What to do?
>     >>
>     >> I'd like to make it clear that the above construct is valid and that hosts
>     >> SHOULD process it to remove the first IPIP hader and then process the packet
>     >> as normal, even if "forwarding" is off. (If inner dst: is *NOT* B, then discard)
> 
>     > Ok. If it's configured to expect this kind of IPIP tunnel,
>     > agreed. Automatically, I don't think it should do this. It should not be
>     > default behaviour. Otoh I agree that ripping of a header isn't "forwarding"
>     > and shouldn't count as such. A 6to4 enabled host with forwarding disabled,
>     > receiving a 6to4 packet addressed to itself, should indeed take off the
>     > header and then process the inner packet.
> 
>     > If the OS comes by default with 6to4 enabled, then I expect it to be able to
>     > handle 6to4 packets coming to it. I wouldn't expect it to behave this way if
>     > 6to4 is turned off, then it should just drop the packet.
> 
> Fair enough for 6to4.  Having 6to4 on or off is a useful setting that the
> end-host should control, and for which the end-host gets some defined
> benefit.
> 
> Removing redundant IPIP headers at the end-host provides no benefit to the
> end-host.  The end-host does this in order to facilitate some unknown service
> in the middle that did something.  If we want to enable such things to work
> without prior permission (cf: "permissionless innovation") then we need to
> fix hosts to do this.

"Permissionless innovation" smells a bit like security issue. :-)


-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Mon Nov  6 10:02:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C65B13FC1A for ; Mon,  6 Nov 2017 10:02:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fASx3Fe59Z0E for ; Mon,  6 Nov 2017 10:02:13 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A5013F6BC for ; Mon,  6 Nov 2017 10:02:10 -0800 (PST)
Received: from [192.168.3.67] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2DDFD80EB1; Mon,  6 Nov 2017 19:02:06 +0100 (CET)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Brian E Carpenter , "C. M. Heard" , 6man WG 
Cc: Michael Richardson 
References:  <23308.1509623865@obiwan.sandelman.ca>  
From: Fernando Gont 
Message-ID: <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar>
Date: Mon, 6 Nov 2017 15:02:14 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 18:02:15 -0000

On 11/02/2017 04:33 PM, Brian E Carpenter wrote:
> On 03/11/2017 04:26, C. M. Heard wrote:
>> On Thu, Nov 2, 2017, Michael Richardson  wrote:
>>
>>>
>>> C. M. Heard  wrote:
>>>     > On Wed, 01 Nov 2017, Michael Richardson wrote:
>>>     >> Yet we skip other extension headers in order to find the ULP.
>>>
>>>     > Not so. An end node that encounters an unrecognized extension header
>>> is
>>>
>>> Both AH and IPIP are well known and recognized extension headers.
> 
> AH is an extension header. "IPIP" isn't. It's Protocol 41, and Protocol 41
> is otherwise known as IPv6. (That's why it's also called IPPROTO_IPV6).
> In RFC8200 terms that makes it an "upper-layer header". Strictly speaking,
> RFC8200 doesn't specify what to do with an unrecognized upper-layer header.

Based on the std, anything that is unknown is an EH. In the context of
RFC8200/FC2460, there's only:

* Known EHs
* Known ULP
* Unknown EHs


with the last one being the default branch :-)


-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Mon Nov  6 10:05:02 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6841013FBBD for ; Mon,  6 Nov 2017 10:05:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 379c7dd4eWUU for ; Mon,  6 Nov 2017 10:04:58 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DFC13FB81 for ; Mon,  6 Nov 2017 10:04:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vA6I4wHx025245; Mon, 6 Nov 2017 11:04:58 -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 vA6I4lNQ024801 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 6 Nov 2017 11:04:47 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 6 Nov 2017 10:04:46 -0800
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Mon, 6 Nov 2017 10:04:47 -0800
From: "Manfredi, Albert E" 
To: Tom Herbert 
CC: 6man WG 
Subject: RE: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Topic: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Index: AQHTVxp+zYH5bQ3/lEaBRWQjFVo6IKMIGViA//+H4wA=
Date: Mon, 6 Nov 2017 18:04:47 +0000
Message-ID: <639c67b05b334853a3fe8f51aa1b84a7@XCH15-06-11.nw.nos.boeing.com>
References:  <6286.1509408085@obiwan.sandelman.ca>  <25055.1509413008@obiwan.sandelman.ca>  <19111.1509476559@obiwan.sandelman.ca> <37b32942-7d1a-dfd8-288d-ce1f937fc484@gont.com.ar> 
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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 18:05:00 -0000

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert

> I think the sticking point is going whether a node can blindly
> perform IP-IP encapsulation on packets to arbitrary destinations
> (as opposed to using IP-IP for explicitly tunneling across a
> network).

Interesting thread. My question has been, during this exchange, why should =
we expect that *any* given payload should be assumed ahead of time, by a so=
urce, to be acceptable to a destination? Or if not acceptable, to return a =
particular ICMP message?

> This requires the assumption that all nodes in the downstream path
> will forward a packet with IP-IP and the added extension headers,
> and that the destination will accept such packets.

Yes. And if the source sends some obscure spreadsheet or word processor for=
mat, or streaming media compression algorithm, there's no assumption that t=
he obscure format will be acceptable either.

> The problem is that if a packet is dropped because of the
> encapsulation or EHs and no ICMP error is returned to the
> encapsulator then there is no way to recover. The original source
> host might see packets being dropped on a connection but will have
> no idea why.

As in many other examples of not-very-standard payloads? Is there an expect=
ation that any random host out there should know to be the egress of a tunn=
el? Or is this the sort of job one expects only or mainly from certain rout=
ers, very deliberately configured for such a task?

Bert



From nobody Mon Nov  6 10:17:46 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2DA13FC5A for ; Mon,  6 Nov 2017 10:17:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC44mWR1H7Qg for ; Mon,  6 Nov 2017 10:17:44 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69CF13FB8E for ; Mon,  6 Nov 2017 10:17:43 -0800 (PST)
Received: from [192.168.3.67] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id EE4AF8076E; Mon,  6 Nov 2017 19:17:40 +0100 (CET)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Michael Richardson , Brian E Carpenter 
Cc: "C. M. Heard" , 6man WG 
References:  <23308.1509623865@obiwan.sandelman.ca>     <7923.1509845822@obiwan.sandelman.ca>
From: Fernando Gont 
Message-ID: 
Date: Mon, 6 Nov 2017 15:19:16 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <7923.1509845822@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 18:17:45 -0000

On 11/04/2017 10:37 PM, Michael Richardson wrote:
> 
> Brian E Carpenter  wrote:
>     > Yes, that particular elephant stands politely and quietly in the corner
>     > of the room. However, I'd just read the text you cite when I wrote my
>     > message and I'll stick to what I said: we *specify* action for an
>     > unrecognized extension header, but we ignore the elephant and *don't*
>     > specify action for an unrecognized ULP. Consider it a drafting error,
>     > or a design error. I agree with you about the practical effect: an
>     > unexpected IPIP packet is likely to generate ICMP 1 today.
> 
> okay, so shouldn't 6463 fix this part at least?

You can't, unless you close the door to new EHs or to new ULPs. See:


Thanks,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Mon Nov  6 10:42:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C73B13FC62 for ; Mon,  6 Nov 2017 10:42:36 -0800 (PST)
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=herbertland-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 CoR73kdaGtB2 for ; Mon,  6 Nov 2017 10:42:35 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d: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 1074213FBB4 for ; Mon,  6 Nov 2017 10:42:35 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id n5so12166523qke.11 for ; Mon, 06 Nov 2017 10:42:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FuHmHS3gg8tnsFAbm6Sb+MgHRSfPPsRdkUrA5vLMJOk=; b=OdKvo0tnAMBt/R3NS/VAVBRgw3KLnqSXrJB2O08rR5ycrdqVX1YR9H4u22goWAt+JW Jjimka53SZYAJactKo2uQv6Kp4h1yTRp5ZJkbDtn+SPW04Nto4bhU7MtoaAJzVk/xVut A1u1CyGzyU6lg+SWazd5q5fT6rmLqa+ibJlnZPhZfG7u9GuBXyRxJYaO6bcjUCvEThZy ZKJrUbbTh77t5FwfIQtQXRGPeCTV6AnOdAn/FuH2Ne7SJh/xYwBwv6WxnH9Y2+yrq1Cw YK+RWKy6GmUTQ1DC1n0vKINQmLVaeXvuuEmkSFLCB57RrJqTMdnllJ+VsxbLe92wr/ML vX5Q==
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=FuHmHS3gg8tnsFAbm6Sb+MgHRSfPPsRdkUrA5vLMJOk=; b=rJDFdI8fyrU230DX87fwL1XXG6I1mOX4z+dxS38jxNsXBV9AW5j+PWkS+FCkL+jU74 rqsLtHmGJW4h95+MU45S4x8ErNwD7rBck2UBj2pT1lRQo3kFJZNSkWPUFOilwWWIreAj d06hJ7FN2HUj1cuWdgdiTZUSramgSCOnRXY2njZFl80YjiskqCtOWAAyj6Qa1q5MWBUx rSsktjh5IZMaz0+VySlgSxQqb7hHj6V5VNsYrr6Gm8zYWRSMR9V09S2vml/mcPe9Wkru ca5i/vUWjSxEgP+KbSiLz1P0/2RNEUT/iEuV92HKKNv5K659r8vCMf9HL4kpDXWb13xq H7Jg==
X-Gm-Message-State: AJaThX6RwzCGkZgcoeaWkG5/X82gSpGmrsjwbnrqhS08ukdirq1zbR+o 0FF2JdL0/KoFl03jW+CbH0F3eVuzJ754SJDnnA2Y+w==
X-Google-Smtp-Source: ABhQp+TMr8Bh4ZESrCzbxwBDMvSbyw6Wnf7tqMg5OUrPCeJIfQehKutABAgQbK0RyUmckRb/i+Zq4b0UOhb0yi6zeEg=
X-Received: by 10.55.148.70 with SMTP id w67mr23615263qkd.102.1509993303986; Mon, 06 Nov 2017 10:35:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Mon, 6 Nov 2017 10:35:03 -0800 (PST)
In-Reply-To: <639c67b05b334853a3fe8f51aa1b84a7@XCH15-06-11.nw.nos.boeing.com>
References:  <6286.1509408085@obiwan.sandelman.ca>  <25055.1509413008@obiwan.sandelman.ca>  <19111.1509476559@obiwan.sandelman.ca> <37b32942-7d1a-dfd8-288d-ce1f937fc484@gont.com.ar>  <639c67b05b334853a3fe8f51aa1b84a7@XCH15-06-11.nw.nos.boeing.com>
From: Tom Herbert 
Date: Mon, 6 Nov 2017 10:35:03 -0800
Message-ID: 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: "Manfredi, Albert E" 
Cc: 6man WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 18:42:36 -0000

On Mon, Nov 6, 2017 at 10:04 AM, Manfredi, Albert E
 wrote:
> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Tom Herbert
>
>> I think the sticking point is going whether a node can blindly
>> perform IP-IP encapsulation on packets to arbitrary destinations
>> (as opposed to using IP-IP for explicitly tunneling across a
>> network).
>
> Interesting thread. My question has been, during this exchange, why shoul=
d we expect that *any* given payload should be assumed ahead of time, by a =
source, to be acceptable to a destination? Or if not acceptable, to return =
a particular ICMP message?
>
Hi Bert,

The source doesn't need to make that assumption. If it puts something
in a packet that causes an intermediate node to drop it then the
source can detect the packet drop as a signal to back off using the
"advanced feature". This is essentially how happy eyeballs works for
IPv6; if IPv6 packets are being dropped then a host can revert to
using IPv4. A similar method could be used to introduce new EHs. The
key here is that it is only the source that is able detect the failure
and so that would be the one who could modify behavior to work around
the problem.

I agree that ICMP should be sent when packets are dropped due to
protocol, and in fact I wrote draft-herbert-6man-icmp-limits to cover
some common cases where routers drop because of EH limits. However,
ICMP is known to not be reliable and probably not robust enough for
this use case.

>> This requires the assumption that all nodes in the downstream path
>> will forward a packet with IP-IP and the added extension headers,
>> and that the destination will accept such packets.
>
> Yes. And if the source sends some obscure spreadsheet or word processor f=
ormat, or streaming media compression algorithm, there's no assumption that=
 the obscure format will be acceptable either.
>
In that case the destination host can send an error back to the source
host over an application layer protocol.

>> The problem is that if a packet is dropped because of the
>> encapsulation or EHs and no ICMP error is returned to the
>> encapsulator then there is no way to recover. The original source
>> host might see packets being dropped on a connection but will have
>> no idea why.
>
> As in many other examples of not-very-standard payloads? Is there an expe=
ctation that any random host out there should know to be the egress of a tu=
nnel? Or is this the sort of job one expects only or mainly from certain ro=
uters, very deliberately configured for such a task?

Hosts can certainly be configured as tunnel endpoints, but they don't
perform automatic decapsulation. It would be quite easy to implement,
but I think there are going to be many concerns over the ramifications
if we do that.

Tom


From nobody Mon Nov  6 11:35:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF6013FB5D for ; Mon,  6 Nov 2017 11:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzYDIQeUf1BJ for ; Mon,  6 Nov 2017 11:35:06 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A861E13FBCC for ; Mon,  6 Nov 2017 11:35:06 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id b85so8450620pfj.13 for ; Mon, 06 Nov 2017 11:35:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GiJCYkUUeifDgiay1XblL8MQKalB/ptBkfK5UacRPVU=; b=fqZhYsqIMGUvdsQz5Ocbe6YDnFDGxt81D3oibR6NzDvmwB0GvRE+Z3ukaInHvIeuvG tSqTI+vBqgZcS5zqTMNiQIad4blmQeb2LW8jem999mcLZqJguh2ov1s2LdAvAGWplVst VdEhMMHCZLG9yiSQDo+pp6I3pxd2cwYOm+KSvMWoFGw9y0Lnzs/aB1GDxGXOFOKdMgA0 Uz0cT/BIl7WXVyGsnUtx7ww0W6ZHhvZGYOhUoLp7Ww4SFqwE/B5aKcKdpuA19cPnTzIC 8JCmTEf76kKr/oRVwfvq8g9uAwYnDZnxNJzKtUb9SWL4tt2gWRo1rjupQmqfjKsaUg6a loUA==
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=GiJCYkUUeifDgiay1XblL8MQKalB/ptBkfK5UacRPVU=; b=HUpjND+6h/1NaoINZfrcslvR+hXIWAUj1ngAmumtwTdotGIkRxK4Y6pvN3Fr2Zu0yH 2IfcXZDWbqiY21tLflgl86lpTtk+8ewe1iW63X8Sqf1YKqSd7I4WqcswIgMBuopOJ1N5 Czqz4VCvIbIva8dqsGjrdOb7h9k+ynBDjMg252wzrJ6Fv9G7F/wXPxOeRFhApVLq6kHG vhTINaMoCl2BdRLSei56GRX8AX0oxVtaJb6yI3SPyDLApYGbbGCfEDj7DPaTeREFaHSe nLf+wjrI8VjGugPL6tYVLo4NOovwMQ8dIHuJsWPacuuDwnfPBku6Ge8flOh/jGFX6pvq OLWQ==
X-Gm-Message-State: AMCzsaXOkf6i2k94IRoxib8WoTJLUsMhayMlLF7Wkc6OiwZ8V77a643Q 98E/hLH9CVuglPBLGd2OZmU=
X-Google-Smtp-Source: ABhQp+QPmH43Uj8d+nDPJdECzdIXh8QPtlJ3dmc4clDiVBq0ICRhojBPjr5UUOLzEr3+hjVFpKh4iw==
X-Received: by 10.101.64.11 with SMTP id f11mr16279916pgp.217.1509996906083; Mon, 06 Nov 2017 11:35:06 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id g11sm25313645pfe.41.2017.11.06.11.35.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 11:35:05 -0800 (PST)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Fernando Gont , "C. M. Heard" , 6man WG 
Cc: Michael Richardson 
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com>
Date: Tue, 7 Nov 2017 08:35:03 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 19:35:10 -0000

Hi Fernando,

On 07/11/2017 07:02, Fernando Gont wrote:
> On 11/02/2017 04:33 PM, Brian E Carpenter wrote:
>> On 03/11/2017 04:26, C. M. Heard wrote:
>>> On Thu, Nov 2, 2017, Michael Richardson  wrote:
>>>
>>>>
>>>> C. M. Heard  wrote:
>>>>     > On Wed, 01 Nov 2017, Michael Richardson wrote:
>>>>     >> Yet we skip other extension headers in order to find the ULP.
>>>>
>>>>     > Not so. An end node that encounters an unrecognized extension header
>>>> is
>>>>
>>>> Both AH and IPIP are well known and recognized extension headers.
>>
>> AH is an extension header. "IPIP" isn't. It's Protocol 41, and Protocol 41
>> is otherwise known as IPv6. (That's why it's also called IPPROTO_IPV6).
>> In RFC8200 terms that makes it an "upper-layer header". Strictly speaking,
>> RFC8200 doesn't specify what to do with an unrecognized upper-layer header.
> 
> Based on the std, anything that is unknown is an EH. In the context of
> RFC8200/FC2460, there's only:
> 
> * Known EHs
> * Known ULP
> * Unknown EHs

Yes, that's what the text says but I wish we'd fixed it in 8200 to
acknowledge that there is a 4th case (Unknown ULP) and that it
cannot be distinguished from the 3rd case. Acknowledging that is
much better than ignoring it. I'm happy with Ole's suggestion that
this (and the resulting ICMP 1 behaviour) should be mentioned in
6434bis - as a clarification, not a new invention.

I also agree that there are enough potential issues in unexpected
IPv6-in-IPv6 that is deserves its own draft.

Regards
   Brian
 
> with the last one being the default branch :-)
> 
> 


From nobody Mon Nov  6 11:50:10 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0643913AF75 for ; Mon,  6 Nov 2017 11:50:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1wXldhz2rFP for ; Mon,  6 Nov 2017 11:50:07 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFFA13FB30 for ; Mon,  6 Nov 2017 11:50:06 -0800 (PST)
Received: from [192.168.3.67] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 21D9B80764; Mon,  6 Nov 2017 20:50:02 +0100 (CET)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Brian E Carpenter , Fernando Gont , "C. M. Heard" , 6man WG 
Cc: Michael Richardson 
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com>
From: Fernando Gont 
Message-ID: <0c41a05a-7684-e95e-30d6-b7a10673e23b@si6networks.com>
Date: Mon, 6 Nov 2017 16:46:38 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 19:50:09 -0000

On 11/06/2017 04:35 PM, Brian E Carpenter wrote:
> Hi Fernando,
> 
> On 07/11/2017 07:02, Fernando Gont wrote:
>> On 11/02/2017 04:33 PM, Brian E Carpenter wrote:
>>> On 03/11/2017 04:26, C. M. Heard wrote:
>>>> On Thu, Nov 2, 2017, Michael Richardson  wrote:
[....]
>>>>> Both AH and IPIP are well known and recognized extension headers.
>>>
>>> AH is an extension header. "IPIP" isn't. It's Protocol 41, and Protocol 41
>>> is otherwise known as IPv6. (That's why it's also called IPPROTO_IPV6).
>>> In RFC8200 terms that makes it an "upper-layer header". Strictly speaking,
>>> RFC8200 doesn't specify what to do with an unrecognized upper-layer header.
>>
>> Based on the std, anything that is unknown is an EH. In the context of
>> RFC8200/FC2460, there's only:
>>
>> * Known EHs
>> * Known ULP
>> * Unknown EHs
> 
> Yes, that's what the text says but I wish we'd fixed it in 8200 to
> acknowledge that there is a 4th case (Unknown ULP) and that it
> cannot be distinguished from the 3rd case. Acknowledging that is
> much better than ignoring it.

In that sense we probably did a bit worse: the merge of RFC6564 seems to
imply a "unified format" helps... but it doesn't.. because if the type
is unknown, you cannot infer the syntax of what's comming next.


> I'm happy with Ole's suggestion that
> this (and the resulting ICMP 1 behaviour) should be mentioned in
> 6434bis - as a clarification, not a new invention.

mmm.. would this RFC8200 (jut curious...)



> I also agree that there are enough potential issues in unexpected
> IPv6-in-IPv6 that is deserves its own draft.

Agreed. Just curious: why is this "behaviour" nw found to be of
interest? -- I missed this bit (if it was actually mentioned).

Thanks!

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





From nobody Mon Nov  6 13:12:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999FF13FC3F; Mon,  6 Nov 2017 13:12:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRpd5wsD8q_r; Mon,  6 Nov 2017 13:12:02 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8242613FBD5; Mon,  6 Nov 2017 13:12:02 -0800 (PST)
Received: from [192.168.3.67] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C30FA80EB1; Mon,  6 Nov 2017 22:11:55 +0100 (CET)
From: Fernando Gont 
Subject: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: IPv6 Operations , "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" 
Cc: "6man@ietf.org" <6man@ietf.org>, draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Message-ID: 
Date: Mon, 6 Nov 2017 18:13:50 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 21:12:05 -0000

Folks,

These past few days I ended up reviewing the aforementioned document, as
a result of a thread on this document on the v6ops mailing-list.

I had reviewed an early version of the document, in which the benefits
of not having and on-link prefix were discussed -- which was certainly
fine (and I supported).

While reviewing this document a few days ago, I found that Section 4
(page 5) contains what is a protocol spec, rather than an operational
BCP. It contains rules regarding how to set the link-layer address (to a
unicast address) for IPv6 multicasted RAs, and how a SLAAC router should
now remember which prefix has been "leased" to which node -- something
that seems to be way outside of the v6ops charter, and that should have
been done in 6man, instead.

Looking at diffs, it seems this additional text was incorporated very
recently, in version -09 of the I-D, published in mid September
().
It seems to be that this change is way beyond what the authors
originally proposed
(a bcp saying that it's great to give each host a unique prefix, without
providing details on specific mechanisms or doing protocol specs --
which was obviously within v6ops' charter), and what the wg shipped, and
also seems to be in conflict of the v6ops and 6man charters (v6ops
doesn't do protocol specs, but this document certainly contains one).

Besides what seems to be a conflict in the aforementioned charter, there
are a number of issues associated with the specified protocol:

1) The protocol spec specified in this document requires the SLAAC
router to keep state of the "leased" prefixes -- what seems a major
change to SLAAC, which now would be kind of as stateful as DHCPv6.

2) There are scenarios in which multiple nodes might receive the same
packet -- say a NIC let's the packet through because it is in
promiscuous mode -- wich could possibly lead to two nodes configuring
the same prefix.

3) What happens if the SLAAC router crashes and reboots, loosing state
of the "leased" prefixes?

4) How are prefixes selected? And, what's the minimum size of the pool
of prefixes for the selection algorithm not to break due two "prefix
collisions"? Does the selection algorithm have any specific properties?


In summary, revision -09 (most likely done to address some DISCUSS)
turned the original BCP document into a protocol spec, with a major
change to SLAAC, which should have happened in 6man, rather than in
v6ops (which is not allowed to do protocol specs). Looking at the
current document (to be published), Section 4 (page 5) looks more like a
Std Track document than a BCP.

It was suggested to me that I discuss this on the mailing-list... hence
this post.

Thoughts?

P.S.: I wished I had caught this earlier. I just didn't.

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





From nobody Tue Nov  7 03:20:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C66C13FDD5 for ; Tue,  7 Nov 2017 03:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Ci7tiXbt8efI for ; Tue,  7 Nov 2017 03:20:22 -0800 (PST)
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 296E813FDCC for ; Tue,  7 Nov 2017 03:20:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510053620; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=N0MYsdv6tcwGrdbGSG+FDT/IkmHrq1bDHPEfPLCTrlc=; b=Zq36sC1o3HXomEO0d5gVD7bL+QRyBfqN26Odwgvh4MbuyXQDe/tdZIWEpHvvlhOsZdAkrI8C3TdJVXUzKeU0GMjteNBNCU3yHuGOZN21LgN8pq+Osr0w7l3p7e22a3kZJjQREFmTmSm3QfZ83LtdMyzVkwE9/yKfVh2BX7Sp70Q=
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0209.outbound.protection.outlook.com [213.199.154.209]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-93-zSYEtncAOdmd3_MindqvVA-1; Tue, 07 Nov 2017 11:20:16 +0000
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.218.6; Tue, 7 Nov 2017 11:20:14 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 11:20:14 +0000
From: Tim Chown 
To: Brian E Carpenter 
CC: Fernando Gont , "C. M. Heard" , 6man WG , Michael Richardson 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Topic: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Index: AQHTU4K/vqPz1IcGUEyBNF2bHgm6GqMHrANIgAAZpoCAAQgTgA==
Date: Tue, 7 Nov 2017 11:20:14 +0000
Message-ID: <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk>
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com>
In-Reply-To: <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:edda:61ec:7313:b139]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 20:UjmahmNy1pGlx8CMvL85SLxJje1Kf81v571TjxP81d1CKuuC4rMtIToiO+1ES9BA5Hw1GYinHXlX8imnnZPawVeIemCubsfgJnTBWWYH/szsONige2YZFiCOvRfMla5aG6j3fShO3Hm1A3vpdBoMOaW+u8tBxqJW/UwyqV6zQoM=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 13965f50-593f-40ba-2d5a-08d525d18454
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1140; 
x-ms-traffictypediagnostic: AM3PR07MB1140:
x-exchange-antispam-report-test: UriScan:(100324003535756);
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)(3002001)(3231021)(100000703101)(100105400095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(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: 0484063412
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(24454002)(199003)(6246003)(53546010)(3280700002)(42882006)(966005)(86362001)(97736004)(81166006)(316002)(36756003)(54906003)(8676002)(8936002)(81156014)(39060400002)(5660300001)(83716003)(6916009)(2950100002)(5250100002)(14454004)(57306001)(3660700001)(82746002)(786003)(2906002)(6436002)(50226002)(305945005)(2900100001)(6306002)(6506006)(106356001)(68736007)(229853002)(99286004)(74482002)(6486002)(6512007)(101416001)(50986999)(93886005)(25786009)(72206003)(6116002)(102836003)(4326008)(8656006)(53936002)(189998001)(7736002)(76176999)(478600001)(33656002)(105586002); 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: <004DC191035313438F58C92A36FCA5B6@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 13965f50-593f-40ba-2d5a-08d525d18454
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 11:20:14.0669 (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: zSYEtncAOdmd3_MindqvVA-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 11:20:26 -0000

SGksDQoNCj4gT24gNiBOb3YgMjAxNywgYXQgMTk6MzUsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlh
bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgRmVybmFuZG8sDQo+IA0K
PiBPbiAwNy8xMS8yMDE3IDA3OjAyLCBGZXJuYW5kbyBHb250IHdyb3RlOg0KPj4gT24gMTEvMDIv
MjAxNyAwNDozMyBQTSwgQnJpYW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+Pj4gT24gMDMvMTEvMjAx
NyAwNDoyNiwgQy4gTS4gSGVhcmQgd3JvdGU6DQo+Pj4+IE9uIFRodSwgTm92IDIsIDIwMTcsIE1p
Y2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4+Pj4gDQo+
Pj4+PiANCj4+Pj4+IEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20+IHdyb3RlOg0KPj4+Pj4+
IE9uIFdlZCwgMDEgTm92IDIwMTcsIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZToNCj4+Pj4+Pj4g
WWV0IHdlIHNraXAgb3RoZXIgZXh0ZW5zaW9uIGhlYWRlcnMgaW4gb3JkZXIgdG8gZmluZCB0aGUg
VUxQLg0KPj4+Pj4gDQo+Pj4+Pj4gTm90IHNvLiBBbiBlbmQgbm9kZSB0aGF0IGVuY291bnRlcnMg
YW4gdW5yZWNvZ25pemVkIGV4dGVuc2lvbiBoZWFkZXINCj4+Pj4+IGlzDQo+Pj4+PiANCj4+Pj4+
IEJvdGggQUggYW5kIElQSVAgYXJlIHdlbGwga25vd24gYW5kIHJlY29nbml6ZWQgZXh0ZW5zaW9u
IGhlYWRlcnMuDQo+Pj4gDQo+Pj4gQUggaXMgYW4gZXh0ZW5zaW9uIGhlYWRlci4gIklQSVAiIGlz
bid0LiBJdCdzIFByb3RvY29sIDQxLCBhbmQgUHJvdG9jb2wgNDENCj4+PiBpcyBvdGhlcndpc2Ug
a25vd24gYXMgSVB2Ni4gKFRoYXQncyB3aHkgaXQncyBhbHNvIGNhbGxlZCBJUFBST1RPX0lQVjYp
Lg0KPj4+IEluIFJGQzgyMDAgdGVybXMgdGhhdCBtYWtlcyBpdCBhbiAidXBwZXItbGF5ZXIgaGVh
ZGVyIi4gU3RyaWN0bHkgc3BlYWtpbmcsDQo+Pj4gUkZDODIwMCBkb2Vzbid0IHNwZWNpZnkgd2hh
dCB0byBkbyB3aXRoIGFuIHVucmVjb2duaXplZCB1cHBlci1sYXllciBoZWFkZXIuDQo+PiANCj4+
IEJhc2VkIG9uIHRoZSBzdGQsIGFueXRoaW5nIHRoYXQgaXMgdW5rbm93biBpcyBhbiBFSC4gSW4g
dGhlIGNvbnRleHQgb2YNCj4+IFJGQzgyMDAvRkMyNDYwLCB0aGVyZSdzIG9ubHk6DQo+PiANCj4+
ICogS25vd24gRUhzDQo+PiAqIEtub3duIFVMUA0KPj4gKiBVbmtub3duIEVIcw0KPiANCj4gWWVz
LCB0aGF0J3Mgd2hhdCB0aGUgdGV4dCBzYXlzIGJ1dCBJIHdpc2ggd2UnZCBmaXhlZCBpdCBpbiA4
MjAwIHRvDQo+IGFja25vd2xlZGdlIHRoYXQgdGhlcmUgaXMgYSA0dGggY2FzZSAoVW5rbm93biBV
TFApIGFuZCB0aGF0IGl0DQo+IGNhbm5vdCBiZSBkaXN0aW5ndWlzaGVkIGZyb20gdGhlIDNyZCBj
YXNlLiBBY2tub3dsZWRnaW5nIHRoYXQgaXMNCj4gbXVjaCBiZXR0ZXIgdGhhbiBpZ25vcmluZyBp
dC4gSSdtIGhhcHB5IHdpdGggT2xlJ3Mgc3VnZ2VzdGlvbiB0aGF0DQo+IHRoaXMgKGFuZCB0aGUg
cmVzdWx0aW5nIElDTVAgMSBiZWhhdmlvdXIpIHNob3VsZCBiZSBtZW50aW9uZWQgaW4NCj4gNjQz
NGJpcyAtIGFzIGEgY2xhcmlmaWNhdGlvbiwgbm90IGEgbmV3IGludmVudGlvbi4NCg0KVGhpcyBz
ZWVtcyBhIHJlYXNvbmFibGUgYXBwcm9hY2ggdG8gbWUuICBXb3VsZCB5b3UgbGlrZSB0byBwcm9w
b3NlIHRleHQsIEJyaWFuPw0KDQo+IEkgYWxzbyBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBlbm91Z2gg
cG90ZW50aWFsIGlzc3VlcyBpbiB1bmV4cGVjdGVkDQo+IElQdjYtaW4tSVB2NiB0aGF0IGlzIGRl
c2VydmVzIGl0cyBvd24gZHJhZnQuDQoNCknigJlkIGFncmVlLiBUaGUgc2FtZSB3aXRoIGhlYWRl
ciBpbnNlcnRpb24gZm9yIHRoYXQgbWF0dGVyLiBGb2N1cyBvbiB0aGUgaXNzdWVzIGFuZCBob3cv
aWYgdGhleSBjYW4gYmUgbWl0aWdhdGVkIGFuZCBpbiB3aGljaCBjb250ZXh0cy4NCg0KVGltDQoN
Cj4gDQo+IFJlZ2FyZHMNCj4gICBCcmlhbg0KPiANCj4+IHdpdGggdGhlIGxhc3Qgb25lIGJlaW5n
IHRoZSBkZWZhdWx0IGJyYW5jaCA6LSkNCj4+IA0KPj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJ
RVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBB
ZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9pcHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KDQo=


From nobody Tue Nov  7 03:48:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E7113FE32 for ; Tue,  7 Nov 2017 03:48:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_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=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 k695gn8XYC1S for ; Tue,  7 Nov 2017 03:48:09 -0800 (PST)
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 2D9E613FE2F for ; Tue,  7 Nov 2017 03:48:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510055287; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding; bh=OqcofEcBi+GKqn/Ao4cLmQ1WfWh8xFqRtH0aRsFAQ9U=; b=aVylh7mEh4FLaezyVjRnVma9XCBgrTNkkE4X2PuxDFGCWnXL4KIJSEu+Hya+aIfD5LQ2v6KKluRvpQm/55z+JxWa47BjNUuAD4WIrVXgqRngF4GEc4apQabwC1rcX2loc3i5L9cz1AVCdhycO8aNQEA7wUhWsfCDa7wKHXZmoNE=
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0180.outbound.protection.outlook.com [213.199.180.180]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-3-3c5J_t6wOhy5h8zoTLc3rQ-1; Tue, 07 Nov 2017 11:48:05 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Tue, 7 Nov 2017 11:48:03 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 11:48:03 +0000
From: Tim Chown 
To: 6man WG 
Subject: RFC6434bis open issue - RFC4191 text
Thread-Topic: RFC6434bis open issue - RFC4191 text
Thread-Index: AQHTV75EP6wrXrpUPkaHBjupV+TptA==
Date: Tue, 7 Nov 2017 11:48:03 +0000
Message-ID: <4FF47B5B-247F-4361-838C-2E50BD642ED3@jisc.ac.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:edda:61ec:7313:b139]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 20:HHEwHxEpsBQ7mwQ1UnlPhc4AK60sUqYsGs6T8zJ/pCJrwkUnDfxdRQSTgzGPmx0pn3PlrkDYZtGSsTZSDHhvIRggDmH/gkH3NajuEOilFxCfupQSMfTczz/gdqoC/o7MQMIGs4ewtzvwweg9udDKNhuyC/7A+rEA95DOqqBR6hg=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ef140480-c563-47e2-f2a6-08d525d5674f
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249); SRVR:AM3PR07MB1138; 
x-ms-traffictypediagnostic: AM3PR07MB1138:
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)(100000703101)(100105400095)(3002001)(3231021)(93006095)(93001095)(10201501046)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1138; 
x-forefront-prvs: 0484063412
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(199003)(36756003)(57306001)(50226002)(6916009)(42882006)(5660300001)(189998001)(7736002)(8936002)(97736004)(305945005)(74482002)(6506006)(2906002)(99286004)(3280700002)(3660700001)(6436002)(5890100001)(14454004)(6486002)(5250100002)(72206003)(478600001)(6512007)(83716003)(86362001)(33656002)(25786009)(2900100001)(53936002)(101416001)(786003)(316002)(8676002)(81156014)(81166006)(105586002)(106356001)(6116002)(102836003)(68736007)(50986999)(82746002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <1A81CB38897FA24EBEE96098EE854440@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: ef140480-c563-47e2-f2a6-08d525d5674f
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 11:48:03.3878 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138
X-MC-Unique: 3c5J_t6wOhy5h8zoTLc3rQ-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 11:48:11 -0000

SGksDQoNClRpbVcgYW5kIEkgd291bGQgbGlrZSB0byBnZXQgc29tZSBsaXN0IGZlZWRiYWNrIG9u
IHNvbWUgb3BlbiBpc3N1ZXMgaW4gdGhlIGRyYWZ0IGluIGFkdmFuY2Ugb2YgdGhlIFNpbmdhcG9y
ZSBXRyBzZXNzaW9uLg0KDQpUaGUgZmlyc3QgdG9waWMgaXMgd2hldGhlciB0aGUgdGV4dCBvbiBS
RkM0MTkxIGlzIG5vdyBhY2NlcHRhYmxlLCBpLmUuOg0KDQrigJQgc25pcCDigJQNCg0KNS45LiAg
RGVmYXVsdCBSb3V0ZXIgUHJlZmVyZW5jZXMgYW5kIE1vcmUtU3BlY2lmaWMgUm91dGVzIC0gUkZD
IDQxOTENCg0KICAgIkRlZmF1bHQgUm91dGVyIFByZWZlcmVuY2VzIGFuZCBNb3JlLVNwZWNpZmlj
IFJvdXRlcyIgW1JGQzQxOTFdDQogICBwcm92aWRlcyBzdXBwb3J0IGZvciBub2RlcyBhdHRhY2hl
ZCB0byBtdWx0aXBsZSAoZGlmZmVyZW50KSBuZXR3b3JrcywNCiAgIGVhY2ggcHJvdmlkaW5nIHJv
dXRlcnMgdGhhdCBhZHZlcnRpc2UgdGhlbXNlbHZlcyBhcyBkZWZhdWx0IHJvdXRlcnMNCiAgIHZp
YSBSb3V0ZXIgQWR2ZXJ0aXNlbWVudHMuICBJbiBzb21lIHNjZW5hcmlvcywgb25lIHJvdXRlciBt
YXkgcHJvdmlkZQ0KICAgY29ubmVjdGl2aXR5IHRvIGRlc3RpbmF0aW9ucyB0aGUgb3RoZXIgcm91
dGVyIGRvZXMgbm90LCBhbmQgY2hvb3NpbmcNCiAgIHRoZSAid3JvbmciIGRlZmF1bHQgcm91dGVy
IGNhbiByZXN1bHQgaW4gcmVhY2hhYmlsaXR5IGZhaWx1cmVzLiAgSW4NCiAgIG9yZGVyIHRvIHJl
c29sdmUgdGhpcyBzY2VuYXJpbyBJUHY2IE5vZGVzIE1VU1QgaW1wbGVtZW50IFtSRkM0MTkxXQ0K
ICAgYW5kIFNIT1VMRCBpbXBsZW1lbnQgVHlwZSBDIGhvc3Qgcm9sZS4NCg0K4oCUIHNuaXAg4oCU
DQoNCkFueSBjb21tZW50cyB3ZWxjb21lZC4gIA0KDQooQXMgYSBuaXQsIEkgY2FuIHNlZSB3ZSBz
aG91bGQgYWRkICJ0aGUiIGJlZm9yZSAiVHlwZSBD4oCdLikNCg0KVGltIA0KDQoNCg0K


From nobody Tue Nov  7 03:59:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B0B13FE48 for ; Tue,  7 Nov 2017 03:59:30 -0800 (PST)
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 aRTxicZ0GCQp for ; Tue,  7 Nov 2017 03:59:27 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E7E13FE47 for ; Tue,  7 Nov 2017 03:59:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510055965; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding; bh=oQEqY/2v35gJk92bN9ypz8V+KMzUNiRYeffOn1TyF9w=; b=cqJ3a/ufbNambbz6EwghEraFnGtVidce+s4yCQkjskhpF+eUm7qSIbgLhVh6W/NLc6UHp3el3Ct6ILuGUWFIcb3regyShuL5GUxS6KvNIf6cUwQbbmh+0m9IPvtW//fX8kcr7OGMYeKmEn95lkDBcW14MjUOU1sDwEhqvNVd64s=
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0175.outbound.protection.outlook.com [213.199.180.175]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-92-OqhvgJ73PmeXZN-VhR48XA-1; Tue, 07 Nov 2017 11:59:13 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Tue, 7 Nov 2017 11:59:12 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 11:59:12 +0000
From: Tim Chown 
To: 6man WG 
Subject: RFC6434bis open issue - IPv6 EH protection
Thread-Topic: RFC6434bis open issue - IPv6 EH protection
Thread-Index: AQHTV7/TRDB8jV2rFUefxjYBgVVZEA==
Date: Tue, 7 Nov 2017 11:59:12 +0000
Message-ID: <4E35047B-BB4A-4ED2-BB1D-535EC54C6502@jisc.ac.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:edda:61ec:7313:b139]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 20:oN5xBU8iSg6/f3oGMJf3WJAqvsQdwfrOBv7CwxgasKKS0OSEpsyAVicLf2jRRtCXORcJlVqIqBbrZY1ESPkuzchnWtBs2uX26Kd2lfkcfQCfgE5oUr9uQfTD9WKYS5p2buwT59efBFTdztebP4yASYYXo+VKUROkWzMmVAks3+o=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 62bf0f57-bca4-4871-eebc-08d525d6f61a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1139; 
x-ms-traffictypediagnostic: AM3PR07MB1139:
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)(3231021)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1139; 
x-forefront-prvs: 0484063412
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(57306001)(478600001)(50986999)(6506006)(6486002)(42882006)(6916009)(6436002)(316002)(102836003)(99286004)(72206003)(966005)(14454004)(2900100001)(83716003)(86362001)(5250100002)(6116002)(786003)(25786009)(53936002)(68736007)(74482002)(305945005)(7736002)(101416001)(97736004)(50226002)(8676002)(105586002)(36756003)(81156014)(81166006)(2906002)(6306002)(6512007)(8936002)(5660300001)(189998001)(82746002)(3660700001)(33656002)(3280700002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <424EF48344D30544B40662CE802FFD45@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 62bf0f57-bca4-4871-eebc-08d525d6f61a
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 11:59:12.4201 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139
X-MC-Unique: OqhvgJ73PmeXZN-VhR48XA-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 11:59:31 -0000

SGksDQoNCkhlcmUgaXMgYSBzZWNvbmQgb3BlbiBpc3N1ZSBpbiB0aGUgZHJhZnQgZm9yIHdoaWNo
IHRoZSBhdXRob3JzIHdvdWxkIGxpa2UgY29tbWVudHMuDQoNCkluIHJlc3BvbnNlIHRvIHByZXZp
b3VzIGRpc2N1c3Npb25zLCBUb20gSGVyYmVydCBraW5kbHkgc3VwcGxpZWQgc29tZSB0ZXh0IG9u
IGhvdyBub2RlcyBtYXkgcHJvdGVjdCB0aGVtc2VsdmVzIGZyb20gZXhjZXNzaXZlIEVIIG9wdGlv
bnMuDQoNClRoZXJlIGFyZSB0d28gaXNzdWVzIGhlcmUuDQoxLiBEb2VzIHRoZSB0ZXh0IGxvb2sg
cmVhc29uYWJsZT8NCjIuIFRoZSB0ZXh0IGlzIHF1aXRlIGxvbmcsIGFuZCBpcyBub3QgcHVibGlz
aGVkIGVsc2V3aGVyZTsgaXMgYSBzZXBhcmF0ZSBkcmFmdCBtb3JlIGFwcHJvcHJpYXRlIHdpdGgg
anVzdCBicmllZmVyIHRleHQgaW4gNjQzNGJpcz8NCg0KSW4gZ2VuZXJhbCwgd2UgaGF2ZSBtaW5p
bWlzZWQgbmV3IHRleHQgaW4gNjQzNGJpcywgYW5kIHBvaW50ZWQgYXQgbWF0ZXJpYWwgcHVibGlz
aGVkIGluIFJGQ3MgZWxzZXdoZXJlLg0KDQrigJQgc25pcCDigJQNCg0KNS4zLiAgUHJvdGVjdGlu
ZyBhIG5vZGUgZnJvbSBleGNlc3NpdmUgRUggb3B0aW9ucw0KDQogICBQZXIgUkZDIDgyMDAsIGVu
ZCBob3N0cyBhcmUgZXhwZWN0ZWQgdG8gcHJvY2VzcyBhbGwgZXh0ZW5zaW9uDQogICBoZWFkZXJz
LCBkZXN0aW5hdGlvbiBvcHRpb25zLCBhbmQgaG9wLWJ5LWhvcCBvcHRpb25zIGluIGEgcGFja2V0
Lg0KICAgR2l2ZW4gdGhhdCB0aGUgb25seSBsaW1pdCBvbiB0aGUgbnVtYmVyIGFuZCBzaXplIG9m
IGV4dGVuc2lvbiBoZWFkZXJzDQogICBpcyB0aGUgTVRVLCB0aGUgcHJvY2Vzc2luZyBvZiByZWNl
aXZlZCBwYWNrZXRzIGNvdWxkIGJlIGNvbnNpZGVyYWJsZS4NCiAgIEl0IGlzIGFsc28gY29uY2Vp
dmFibGUgdGhhdCBhIGxvbmcgY2hhaW4gb2YgZXh0ZW5zaW9uIGhlYWRlcnMgbWlnaHQNCiAgIGJl
IHVzZWQgYXMgYSBmb3JtIG9mIGRlbmlhbC1vZi1zZXJ2aWNlIGF0dGFjay4gIEFjY29yZGluZ2x5
LCBhIGhvc3QNCiAgIG1heSBwbGFjZSBsaW1pdHMgb24gdGhlIG51bWJlciBhbmQgc2l6ZXMgb2Yg
ZXh0ZW5zaW9uIGhlYWRlcnMgYW5kDQogICBvcHRpb25zIGl0IGlzIHdpbGxpbmcgdG8gcHJvY2Vz
cy4NCg0KICAgQSBob3N0IE1BWSBsaW1pdCB0aGUgbnVtYmVyIG9mIGNvbnNlY3V0aXZlIFBBRDEg
b3B0aW9ucyBpbg0KICAgZGVzdGluYXRpb24gb3B0aW9ucyBvciBob3AtYnktaG9wIG9wdGlvbnMg
dG8gc2V2ZW4uICBJbiB0aGlzIGNhc2UsIGlmDQogICB0aGUgbW9yZSB0aGFuIHNldmVuIGNvbnNl
Y3V0aXZlIFBBRDEgb3B0aW9ucyBhcmUgcHJlc2VudCB0aGUgdGhlDQogICBwYWNrZXQgc2hvdWxk
IGJlIHNpbGVudGx5IGRpc2NhcmRlZC4gIFRoZSByYXRpb25hbGUgaXMgdGhhdCBpZg0KICAgcGFk
ZGluZyBvZiBlaWdodCBvciBtb3JlIGJ5dGVzIGlzIHJlcXVpcmVkIHRoYW4gdGhlIFBBRE4gb3B0
aW9uDQogICBzaG91bGQgYmUgdXNlZC4NCg0KICAgQSBob3N0IE1BWSBsaW1pdCBudW1iZXIgb2Yg
Ynl0ZXMgaW4gYSBQQUROIG9wdGlvbiB0byBiZSBsZXNzIHRoYW4NCiAgIGVpZ2h0LiAgSW4gc3Vj
aCBhIGNhc2UsIGlmIGEgUEFETiBvcHRpb24gaXMgcHJlc2VudCB0aGF0IGhhcyBhIGxlbmd0aA0K
ICAgZ3JlYXRlciB0aGFuIHNldmVuIHRoZW4gdGhlIHBhY2tldCBzaG91bGQgYmUgc2lsZW50bHkg
ZGlzY2FyZGVkLiAgVGhlDQogICByYXRpb25hbGUgZm9yIHRoaXMgZ3VpZGVsaW5lIGlzIHRoYXQg
dGhlIHB1cnBvc2Ugb2YgcGFkZGluZyBpcyBmb3INCiAgIGFsaWdubWVudCBhbmQgZWlnaHQgYnl0
ZXMgaXMgdGhlIG1heGltdW0gYWxpZ25tZW50IHVzZWQgaW4gSVB2Ni4NCg0KICAgQSBob3N0IE1B
WSBkaXNhbGxvdyB1bmtub3duIG9wdGlvbnMgaW4gZGVzdGluYXRpb24gb3B0aW9ucyBvciBob2It
YnktDQogICBob3Agb3B0aW9ucy4gIFRoaXMgc2hvdWxkIGJlIGNvbmZpZ3VyYWJsZSB3aGVyZSB0
aGUgZGVmYXVsdCBpcyB0bw0KICAgYWNjZXB0IHVua25vd24gb3B0aW9ucyBhbmQgcHJvY2VzcyB0
aGVtIHBlciBSRkMyNDYwLiAgSWYgYSBwYWNrZXQNCiAgIHdpdGggdW5rbm93biBvcHRpb25zIGlz
IHJlY2VpdmVkIGFuZCB0aGUgaG9zdCBpcyBjb25maWd1cmVkIHRvDQogICBkaXNhbGxvdyB0aGVt
LCB0aGVuIHRoZSBwYWNrZXQgc2hvdWxkIGJlIHNpbGVudGx5IGRpc2NhcmRlZC4NCg0KICAgQSBo
b3N0IE1BWSBpbXBvc2UgYSBsaW1pdCBvbiB0aGUgbWF4aW11bSBudW1iZXIgb2Ygbm9uLXBhZGRp
bmcNCiAgIG9wdGlvbnMgYWxsb3dlZCBpbiBhIGRlc3RpbmF0aW9uIG9wdGlvbnMgYW5kIGhvcC1i
eS1ob3AgZXh0ZW5zaW9uDQogICBoZWFkZXJzLiAgSWYgdGhpcyBmZWF0dXJlIGlzIHN1cHBvcnRl
ZCB0aGUgbWF4aW11bSBudW1iZXIgc2hvdWxkIGJlDQogICBjb25maWd1cmFibGUgYW5kIHRoZSBk
ZWZhdWx0IHZhbHVlIFNIT1VMRCBiZSBzZXQgdG8gZWlnaHQuICBUaGUNCiAgIGxpbWl0cyBmb3Ig
ZGVzdGluYXRpb24gb3B0aW9ucyBhbmQgaG9wLWJ5LWhvcCBvcHRpb25zIG1heSBiZQ0KICAgc2Vw
YXJhdGVseSBjb25maWd1cmFibGUuICBJZiBhIHBhY2tldCBpcyByZWNlaXZlZCBhbmQgdGhlIG51
bWJlciBvZg0KICAgZGVzdGluYXRpb24gb3IgaG9wLWJ5LWhvcCBvcHRpbmVzIGV4Y2VlZHMgdGhl
IGxpbWl0LCB0aGVuIHRoZSBwYWNrZXQNCiAgIHNob3VsZCBiZSBzaWxlbnRseSBkaXNjYXJkZWQu
DQoNCiAgIEEgaG9zdCBNQVkgaW1wb3NlIGEgbGltaXQgb24gdGhlIG1heGltdW0gbGVuZ3RoIG9m
IGRlc3RpbmF0aW9uDQogICBvcHRpb25zIG9yIGhvcC1ieS1ob3Agb3B0aW9ucyBleHRlbnNpb24g
aGVhZGVyLiAgVGhpcyB2YWx1ZSBzaG91bGQgYmUNCiAgIGNvbmZpZ3VyYWJsZSBhbmQgdGhlIGRl
ZmF1bHQgaXMgdG8gYWNjZXB0IG9wdGlvbnMgb2YgYW55IGxlbmd0aC4gIElmDQogICBhIHBhY2tl
dCBpcyByZWNlaXZlZCBhbmQgdGhlIGxlbmd0aCBvZiBkZXN0aW5hdGlvbiBvciBob3AtYnktaG9w
DQogICBvcHRpb25zIGV4dGVuc2lvbiBoZWFkZXIgZXhjZWVkcyB0aGUgbGVuZ3RoIGxpbWl0LCB0
aGVuIHRoZSBwYWNrZXQNCiAgIHNob3VsZCBiZSBzaWxlbnRseSBkaXNjYXJkZWQuDQoNCuKAlCBz
bmlwIOKAlA0KDQpGb3IgdGhlIGZ1bGwgZG9jdW1lbnQsIHNlZQ0KaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMiNzZWN0aW9uLTUuMw0KDQpU
aW0NCg0K


From nobody Tue Nov  7 04:09:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9E513FC44 for ; Tue,  7 Nov 2017 04:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 jsp1HTODezeb for ; Tue,  7 Nov 2017 04:09:29 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AF413FE31 for ; Tue,  7 Nov 2017 04:09:28 -0800 (PST)
Received: from [192.168.3.67] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0C8C88018F; Tue,  7 Nov 2017 13:09:24 +0100 (CET)
Subject: Re: RFC6434bis open issue - RFC4191 text
To: Tim Chown , 6man WG 
References: <4FF47B5B-247F-4361-838C-2E50BD642ED3@jisc.ac.uk>
From: Fernando Gont 
Message-ID: 
Date: Tue, 7 Nov 2017 09:11:11 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4FF47B5B-247F-4361-838C-2E50BD642ED3@jisc.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 12:09:30 -0000

On 11/07/2017 08:48 AM, Tim Chown wrote:
> Hi,
> 
> TimW and I would like to get some list feedback on some open issues in the draft in advance of the Singapore WG session.
> 
> The first topic is whether the text on RFC4191 is now acceptable, i.e.:
> 
> — snip —
> 
> 5.9.  Default Router Preferences and More-Specific Routes - RFC 4191
> 
>    "Default Router Preferences and More-Specific Routes" [RFC4191]
>    provides support for nodes attached to multiple (different) networks,
>    each providing routers that advertise themselves as default routers
>    via Router Advertisements.  In some scenarios, one router may provide
>    connectivity to destinations the other router does not, and choosing
>    the "wrong" default router can result in reachability failures.  In
>    order to resolve this scenario IPv6 Nodes MUST implement [RFC4191]
>    and SHOULD implement Type C host role.

Without looking at RFC4191... I assume this "Type C" thing is part of
FC4191, and hence s asubset of it?

Then I wonder if the text should read: MUST implement Type C host role,
and SHOULD implement RFC4191?  (You want the Type C functionality, and
implementing the rest of rfc4191 is desired, but not required?)


In any case: since RFC4191 has stuff for routers and for hosts, and
"Node" (as in "node requirements") encompasses both hosts and routers...
What kind of requirements we want for host and routers? The same level
of requirements for both? Or something else?

Cheers,

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





From nobody Tue Nov  7 04:15:25 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E1413FE4F for ; Tue,  7 Nov 2017 04:15:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jbHeYtSF9H7C for ; Tue,  7 Nov 2017 04:15:22 -0800 (PST)
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 4DB6213FE4E for ; Tue,  7 Nov 2017 04:15:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510056920; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=grNJyOrGrLJllptRnBPypidrEpjAZByNhjfCEBglevU=; b=OBvgdHZbfhNfAMzTIgdtetRZm+eN535c7wq7e9T4LfEAVURa0Ta9OWqEeQ8rWN0bXB0xvYZvmpzayRLWH+259wOtVINPSzu7Abb9pCpym+mZ5t/IRb/uAqp6Kkt/lbLPXcIUBIbpGOqne/Mc10TLKAb9SuEvRLhLg7y1c4xe3JQ=
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0244.outbound.protection.outlook.com [213.199.154.244]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-7-L-f-UwtnMwq2im2gTX_zBg-1; Tue, 07 Nov 2017 12:15:16 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Tue, 7 Nov 2017 12:15:15 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 12:15:15 +0000
From: Tim Chown 
To: Fernando Gont 
CC: 6man WG 
Subject: Re: RFC6434bis open issue - RFC4191 text
Thread-Topic: RFC6434bis open issue - RFC4191 text
Thread-Index: AQHTV75EJ9Vd3jxnpkmfKsh/gF+IgqMI04OAgAABIQA=
Date: Tue, 7 Nov 2017 12:15:14 +0000
Message-ID: <529F9BB3-B730-4B9C-BC4D-CFFC79B22FE5@jisc.ac.uk>
References: <4FF47B5B-247F-4361-838C-2E50BD642ED3@jisc.ac.uk> 
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.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:edda:61ec:7313:b139]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 20:z7x2IxZl4Z2nmoOIcd/jSajRPKkVvrtvAwt7buqSiOqq2s493fC4mtg3t4x7iOYHkqC5//DGrEutD+rhDmp7sjrCZElsraJVdeJ4kIqxR5VHV89Z4SNCCsA/qAhY+D2DGvaD2AGzfd907Fnazpioss7+4i8xn5ec6cUwuTCqyZY=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 14aee77f-4925-4d39-3c6a-08d525d933d6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1139; 
x-ms-traffictypediagnostic: AM3PR07MB1139:
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)(10201501046)(3002001)(93006095)(93001095)(3231021)(100000703101)(100105400095)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1139; 
x-forefront-prvs: 0484063412
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(24454002)(252514010)(199003)(54094003)(8676002)(229853002)(81156014)(81166006)(2906002)(105586002)(36756003)(305945005)(74482002)(68736007)(101416001)(50226002)(97736004)(7736002)(82746002)(3660700001)(33656002)(106356001)(3280700002)(8936002)(6512007)(6306002)(189998001)(5660300001)(6486002)(6506006)(6436002)(42882006)(6916009)(2950100002)(57306001)(50986999)(478600001)(53546010)(5250100002)(83716003)(86362001)(786003)(76176999)(25786009)(53936002)(6246003)(6116002)(5890100001)(316002)(99286004)(966005)(14454004)(2900100001)(72206003)(4326008)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <08A9FCA937B2C74D8B667BF7E34E5DE6@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 14aee77f-4925-4d39-3c6a-08d525d933d6
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 12:15:15.0133 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139
X-MC-Unique: L-f-UwtnMwq2im2gTX_zBg-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 12:15:24 -0000

SGksDQoNCj4gT24gNyBOb3YgMjAxNywgYXQgMTI6MTEsIEZlcm5hbmRvIEdvbnQgPGZnb250QHNp
Nm5ldHdvcmtzLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAxMS8wNy8yMDE3IDA4OjQ4IEFNLCBUaW0g
Q2hvd24gd3JvdGU6DQo+PiBIaSwNCj4+IA0KPj4gVGltVyBhbmQgSSB3b3VsZCBsaWtlIHRvIGdl
dCBzb21lIGxpc3QgZmVlZGJhY2sgb24gc29tZSBvcGVuIGlzc3VlcyBpbiB0aGUgZHJhZnQgaW4g
YWR2YW5jZSBvZiB0aGUgU2luZ2Fwb3JlIFdHIHNlc3Npb24uDQo+PiANCj4+IFRoZSBmaXJzdCB0
b3BpYyBpcyB3aGV0aGVyIHRoZSB0ZXh0IG9uIFJGQzQxOTEgaXMgbm93IGFjY2VwdGFibGUsIGku
ZS46DQo+PiANCj4+IOKAlCBzbmlwIOKAlA0KPj4gDQo+PiA1LjkuICBEZWZhdWx0IFJvdXRlciBQ
cmVmZXJlbmNlcyBhbmQgTW9yZS1TcGVjaWZpYyBSb3V0ZXMgLSBSRkMgNDE5MQ0KPj4gDQo+PiAg
ICJEZWZhdWx0IFJvdXRlciBQcmVmZXJlbmNlcyBhbmQgTW9yZS1TcGVjaWZpYyBSb3V0ZXMiIFtS
RkM0MTkxXQ0KPj4gICBwcm92aWRlcyBzdXBwb3J0IGZvciBub2RlcyBhdHRhY2hlZCB0byBtdWx0
aXBsZSAoZGlmZmVyZW50KSBuZXR3b3JrcywNCj4+ICAgZWFjaCBwcm92aWRpbmcgcm91dGVycyB0
aGF0IGFkdmVydGlzZSB0aGVtc2VsdmVzIGFzIGRlZmF1bHQgcm91dGVycw0KPj4gICB2aWEgUm91
dGVyIEFkdmVydGlzZW1lbnRzLiAgSW4gc29tZSBzY2VuYXJpb3MsIG9uZSByb3V0ZXIgbWF5IHBy
b3ZpZGUNCj4+ICAgY29ubmVjdGl2aXR5IHRvIGRlc3RpbmF0aW9ucyB0aGUgb3RoZXIgcm91dGVy
IGRvZXMgbm90LCBhbmQgY2hvb3NpbmcNCj4+ICAgdGhlICJ3cm9uZyIgZGVmYXVsdCByb3V0ZXIg
Y2FuIHJlc3VsdCBpbiByZWFjaGFiaWxpdHkgZmFpbHVyZXMuICBJbg0KPj4gICBvcmRlciB0byBy
ZXNvbHZlIHRoaXMgc2NlbmFyaW8gSVB2NiBOb2RlcyBNVVNUIGltcGxlbWVudCBbUkZDNDE5MV0N
Cj4+ICAgYW5kIFNIT1VMRCBpbXBsZW1lbnQgVHlwZSBDIGhvc3Qgcm9sZS4NCj4gDQo+IFdpdGhv
dXQgbG9va2luZyBhdCBSRkM0MTkxLi4uIEkgYXNzdW1lIHRoaXMgIlR5cGUgQyIgdGhpbmcgaXMg
cGFydCBvZg0KPiBGQzQxOTEsIGFuZCBoZW5jZSBzIGFzdWJzZXQgb2YgaXQ/DQo+IA0KPiBUaGVu
IEkgd29uZGVyIGlmIHRoZSB0ZXh0IHNob3VsZCByZWFkOiBNVVNUIGltcGxlbWVudCBUeXBlIEMg
aG9zdCByb2xlLA0KPiBhbmQgU0hPVUxEIGltcGxlbWVudCBSRkM0MTkxPyAgKFlvdSB3YW50IHRo
ZSBUeXBlIEMgZnVuY3Rpb25hbGl0eSwgYW5kDQo+IGltcGxlbWVudGluZyB0aGUgcmVzdCBvZiBy
ZmM0MTkxIGlzIGRlc2lyZWQsIGJ1dCBub3QgcmVxdWlyZWQ/KQ0KDQpJdOKAmXMgaW4gU2VjdGlv
biAzLjEgb2YgUkZDNDE5MTsgdGhlIGNydXggb2YgaXQgaXM6DQoNCiAgIlR5cGUgQSBob3N0cyBp
Z25vcmUgZGVmYXVsdCByb3V0ZXIgcHJlZmVyZW5jZXMgYW5kIG1vcmUtc3BlY2lmaWMNCiAgIHJv
dXRlcy4gIFRoZXkgdXNlIHRoZSBjb25jZXB0dWFsIGRhdGEgc3RydWN0dXJlcyBkZXNjcmliZWQg
aW4NCiAgIE5laWdoYm9yIERpc2NvdmVyeSBbUkZDMjQ2MV0uDQoNCiAgIFR5cGUgQiBob3N0cyB1
c2UgYSBEZWZhdWx0IFJvdXRlciBMaXN0IGF1Z21lbnRlZCB3aXRoIHByZWZlcmVuY2UNCiAgIHZh
bHVlcywgYnV0IGlnbm9yZSBhbGwgUm91dGUgSW5mb3JtYXRpb24gT3B0aW9ucy4gIFRoZXkgdXNl
IHRoZQ0KICAgRGVmYXVsdCBSb3V0ZXIgUHJlZmVyZW5jZSB2YWx1ZSBpbiB0aGUgUm91dGVyIEFk
dmVydGlzZW1lbnQgaGVhZGVyLg0KICAgVGhleSBpZ25vcmUgUm91dGUgSW5mb3JtYXRpb24gT3B0
aW9ucy4NCg0KICAgVHlwZSBDIGhvc3RzIHVzZSBhIFJvdXRpbmcgVGFibGUgaW5zdGVhZCBvZiBh
IERlZmF1bHQgUm91dGVyIExpc3QuDQogICAoVGhlIFJvdXRpbmcgVGFibGUgbWF5IGFsc28gc3Vi
c3VtZSB0aGUgUHJlZml4IExpc3QsIGJ1dCB0aGF0IGlzDQogICBiZXlvbmQgdGhlIHNjb3BlIG9m
IHRoaXMgZG9jdW1lbnQuKSAgRW50cmllcyBpbiB0aGUgUm91dGluZyBUYWJsZQ0KICAgaGF2ZSBh
IHByZWZpeCwgcHJlZml4IGxlbmd0aCwgcHJlZmVyZW5jZSB2YWx1ZSwgbGlmZXRpbWUsIGFuZCBu
ZXh0LQ0KICAgaG9wIHJvdXRlci4gIFR5cGUgQyBob3N0cyB1c2UgYm90aCB0aGUgRGVmYXVsdCBS
b3V0ZXIgUHJlZmVyZW5jZQ0KICAgdmFsdWUgaW4gdGhlIFJvdXRlciBBZHZlcnRpc2VtZW50IGhl
YWRlciBhbmQgUm91dGUgSW5mb3JtYXRpb24NCiAgIE9wdGlvbnMu4oCdDQoNCj4gSW4gYW55IGNh
c2U6IHNpbmNlIFJGQzQxOTEgaGFzIHN0dWZmIGZvciByb3V0ZXJzIGFuZCBmb3IgaG9zdHMsIGFu
ZA0KPiAiTm9kZSIgKGFzIGluICJub2RlIHJlcXVpcmVtZW50cyIpIGVuY29tcGFzc2VzIGJvdGgg
aG9zdHMgYW5kIHJvdXRlcnMuLi4NCj4gV2hhdCBraW5kIG9mIHJlcXVpcmVtZW50cyB3ZSB3YW50
IGZvciBob3N0IGFuZCByb3V0ZXJzPyBUaGUgc2FtZSBsZXZlbA0KPiBvZiByZXF1aXJlbWVudHMg
Zm9yIGJvdGg/IE9yIHNvbWV0aGluZyBlbHNlPw0KDQpOb2RlIFJlcXVpcmVtZW50cyBpcyBmb2N1
c2VkIG9uIGhvc3RzLCBidXQgbm90IGV4Y2x1c2l2ZWx5LiAgUm91dGVyLXNwZWNpZmljIGZ1bmN0
aW9uYWxpdHkgaXMgaW5jbHVkZWQgaW4gb25lIHNlY3Rpb24sIHNlZSBodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyI3NlY3Rpb24tMTQuDQoN
ClRoZXJlIGlzIGFsc28gZHJhZnQtaWV0Zi12Nm9wcy1pcHY2cnRyLXJlcXMtMDAgb3ZlciBpbiB2
Nm9wcywgYnV0IHRoYXTigJlzIG5vdCBiZWVuIHVwZGF0ZWQgc2luY2UgTWF5IGFzIGZhciBhcyBJ
IGNhbiB0ZWxsLiAgSXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8ga25vdyBpZiB0aGUgYXV0aG9y
cyBhcmUgc3RpbGwgcHJvZ3Jlc3NpbmcgdGhpcy4gIEnigJlsbCBwb3AgUnVzcyBhIG1haWwuDQoN
ClRpbQ0KDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiAtLSANCj4gRmVybmFuZG8gR29udA0KPiBTSTYg
TmV0d29ya3MNCj4gZS1tYWlsOiBmZ29udEBzaTZuZXR3b3Jrcy5jb20NCj4gUEdQIEZpbmdlcnBy
aW50OiA2NjY2IDMxQzYgRDQ4NCA2M0IyIDhGQjEgRTNDNCBBRTI1IDBENTUgMUQ0RSA3NDkyDQo+
IA0KPiANCj4gDQo+IA0KDQo=


From nobody Tue Nov  7 04:23:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2C913FE61 for ; Tue,  7 Nov 2017 04:23:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 pr20eaNvIT6h for ; Tue,  7 Nov 2017 04:23:09 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C240B13FE67 for ; Tue,  7 Nov 2017 04:23:08 -0800 (PST)
Received: from [192.168.3.67] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 679FB8028D; Tue,  7 Nov 2017 13:23:04 +0100 (CET)
Subject: Re: RFC6434bis open issue - IPv6 EH protection
To: Tim Chown , 6man WG 
References: <4E35047B-BB4A-4ED2-BB1D-535EC54C6502@jisc.ac.uk>
From: Fernando Gont 
Message-ID: 
Date: Tue, 7 Nov 2017 09:24:50 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4E35047B-BB4A-4ED2-BB1D-535EC54C6502@jisc.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 12:23:12 -0000

On 11/07/2017 08:59 AM, Tim Chown wrote:
> Hi,
> 
> Here is a second open issue in the draft for which the authors would like comments.
> 
> In response to previous discussions, Tom Herbert kindly supplied some text on how nodes may protect themselves from excessive EH options.

I support the idea/text (in general).


> 
> There are two issues here.
> 1. Does the text look reasonable?
> 2. The text is quite long, and is not published elsewhere; is a separate draft more appropriate with just briefer text in 6434bis?

If the text focuses solely on the number of EHs, I guess it could be
included to this document. But I would be fine with the other option, too.


> In general, we have minimised new text in 6434bis, and pointed at material published in RFCs elsewhere.
> 
> — snip —
> 
> 5.3.  Protecting a node from excessive EH options
> 
>    Per RFC 8200, end hosts are expected to process all extension
>    headers, destination options, and hop-by-hop options in a packet.
>    Given that the only limit on the number and size of extension headers
>    is the MTU, the processing of received packets could be considerable.
>    It is also conceivable that a long chain of extension headers might
>    be used as a form of denial-of-service attack.  Accordingly, a host
>    may place limits on the number and sizes of extension headers and
>    options it is willing to process.

"may place" or "MAY place"?



>    A host MAY limit the number of consecutive PAD1 options in
>    destination options or hop-by-hop options to seven.  In this case, if
>    the more than seven consecutive PAD1 options are present the the
>    packet should be silently discarded.  The rationale is that if
>    padding of eight or more bytes is required than the PADN option
>    should be used.
> 
>    A host MAY limit number of bytes in a PADN option to be less than
>    eight.  In such a case, if a PADN option is present that has a length
>    greater than seven then the packet should be silently discarded.  The
>    rationale for this guideline is that the purpose of padding is for
>    alignment and eight bytes is the maximum alignment used in IPv6.
> 
>    A host MAY disallow unknown options in destination options or hob-by-
>    hop options.  This should be configurable where the default is to
>    accept unknown options and process them per RFC2460.  If a packet
>    with unknown options is received and the host is configured to
>    disallow them, then the packet should be silently discarded.

While I'm not against this paragraph, this one is more tricky. If the
information in an option is early "optional", then you should be fine
ignoring the option. At the end of the they, the high order two bits of
the option type give guidance regarding what to do.



>    A host MAY impose a limit on the maximum number of non-padding
>    options allowed in a destination options and hop-by-hop extension
>    headers.  If this feature is supported the maximum number should be
>    configurable and the default value SHOULD be set to eight.  The
>    limits for destination options and hop-by-hop options may be
>    separately configurable.  If a packet is received and the number of
>    destination or hop-by-hop optines exceeds the limit, then the packet
>    should be silently discarded.

This seems fine. I assume you're tackling "unknown options". Otherwise
you could say something along the lines of "at most one instance of each
of the specified options for this EH type".




>    A host MAY impose a limit on the maximum length of destination
>    options or hop-by-hop options extension header.  This value should be
>    configurable and the default is to accept options of any length. 

s/options of any length/extension headers of any length/ might be clearrer.



>    If
>    a packet is received and the length of destination or hop-by-hop
>    options extension header exceeds the length limit, then the packet
>    should be silently discarded.
A meta question here is whether one should silently drop, or respond
with an ICMPv6 error. For the long EH chains in RFC7112, we do the later.

Thanks!

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





From nobody Tue Nov  7 04:47:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B051013FD47 for ; Tue,  7 Nov 2017 04:47:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wJ6LbSwBOMv3 for ; Tue,  7 Nov 2017 04:47:51 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CFC13F961 for ; Tue,  7 Nov 2017 04:47:50 -0800 (PST)
Received: from [192.168.3.67] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D30C68028D; Tue,  7 Nov 2017 13:47:38 +0100 (CET)
Subject: Re: RFC6434bis open issue - RFC4191 text
To: Tim Chown 
Cc: 6man WG 
References: <4FF47B5B-247F-4361-838C-2E50BD642ED3@jisc.ac.uk>  <529F9BB3-B730-4B9C-BC4D-CFFC79B22FE5@jisc.ac.uk>
From: Fernando Gont 
Message-ID: <862634b4-d6b8-d089-3ef5-a8c68506db3a@si6networks.com>
Date: Tue, 7 Nov 2017 09:49:12 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <529F9BB3-B730-4B9C-BC4D-CFFC79B22FE5@jisc.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 12:47:53 -0000

On 11/07/2017 09:15 AM, Tim Chown wrote:
> Hi,
> 
>> On 7 Nov 2017, at 12:11, Fernando Gont  wrote:
>>
>> On 11/07/2017 08:48 AM, Tim Chown wrote:
>>> Hi,
>>>
>>> TimW and I would like to get some list feedback on some open issues in the draft in advance of the Singapore WG session.
>>>
>>> The first topic is whether the text on RFC4191 is now acceptable, i.e.:
>>>
>>> — snip —
>>>
>>> 5.9.  Default Router Preferences and More-Specific Routes - RFC 4191
>>>
>>>   "Default Router Preferences and More-Specific Routes" [RFC4191]
>>>   provides support for nodes attached to multiple (different) networks,
>>>   each providing routers that advertise themselves as default routers
>>>   via Router Advertisements.  In some scenarios, one router may provide
>>>   connectivity to destinations the other router does not, and choosing
>>>   the "wrong" default router can result in reachability failures.  In
>>>   order to resolve this scenario IPv6 Nodes MUST implement [RFC4191]
>>>   and SHOULD implement Type C host role.
>>
>> Without looking at RFC4191... I assume this "Type C" thing is part of
>> FC4191, and hence s asubset of it?
>>
>> Then I wonder if the text should read: MUST implement Type C host role,
>> and SHOULD implement RFC4191?  (You want the Type C functionality, and
>> implementing the rest of rfc4191 is desired, but not required?)
> 
> It’s in Section 3.1 of RFC4191; the crux of it is:

May question would be: What you want is that all hosts iplement RFC4191,
and that by default they behave like Type C hosts?

If so, I'd say something like "MUST implement RFC4191 and SHOULD employ
the Type C host model"  ("*implement* Type C host model" was a bit
confusing to me). -- but ...well.. English as second language here, so...




>> In any case: since RFC4191 has stuff for routers and for hosts, and
>> "Node" (as in "node requirements") encompasses both hosts and routers...
>> What kind of requirements we want for host and routers? The same level
>> of requirements for both? Or something else?
> 
> Node Requirements is focused on hosts, but not exclusively.  Router-specific functionality is included in one section, see https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02#section-14.

Me, I'd use "hosts" if you refer only to functionality expected in only
hosts, "routers" when it is only meant for routers, and "nodes" when
referring to both.


> 
> There is also draft-ietf-v6ops-ipv6rtr-reqs-00 over in v6ops, but that’s not been updated since May as far as I can tell.  It would be interesting to know if the authors are still progressing this.  I’ll pop Russ a mail.

Good grief!

Thanks!

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





From nobody Tue Nov  7 11:18:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFA71201F8 for ; Tue,  7 Nov 2017 11:18:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh-9QoYJ_aeL for ; Tue,  7 Nov 2017 11:18:01 -0800 (PST)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90687132EC4 for ; Tue,  7 Nov 2017 11:18:00 -0800 (PST)
Received: by mail-pg0-x230.google.com with SMTP id 15so200047pgc.12 for ; Tue, 07 Nov 2017 11:18:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=z0JgW6QxGLFjbZ3h+lTSKWcFceohM+xisaPq4wkLwFM=; b=cQBau214tY9cApy7TP2KiYxiFwCgpA0RyGlTHtdU9GTzR/XJ/JH11YaZIHxU3IUAyh N+05kSZkgFRwD/5hMsIRJe/FuK10E1FoqQE9kjKehlY9zxT+hTVb2q+cSyFPfqus5B2H tzJexaShObTarBxm+WxO9uwoEGnA4kgYugcZgq9tsFNxZ/81jIgsYCTPVX6bTPcFL5gN 5uECVbqq5t1ZxqhMn6dwzFlS0H0PYQcl1lE/0d3bEX1XoXAeetahtyhtPLn2YUnS2ObZ FQzJjemjwWfBfes6L6j8pi6u3OJf9Qr55F84mB1CubfFl2uvk4r6863f50RYPjwf+3m4 u8dg==
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=z0JgW6QxGLFjbZ3h+lTSKWcFceohM+xisaPq4wkLwFM=; b=t0Ur6VRyt+6rDNrS4feuW+IgjD8XkK0xEsll6xE4+pvFVpXejMktw62IgI2fWeWE8G /76dLiCMlHdVcmQhSGDU8qZLH0sLIJNgAvnngB503j8lNDSz5+EfX+hOcsf29ffB9efY kOjW7q8/GI0tc5W2mCMvVCDjzG+xHvJIjtRH+z2NUvDm4Xi672FihftRlRB8nN6RdYLB 6G/97FdY+t2Ho6bh8JkhfDr4uM7jgTaPL1xqatsXw+CUq13mBUdR0SwuvcNTqKtgL85V boD98LoW5R2G5Agis3cCxpLQ/RZ3ZcYkWmpk4vLlGMFOqH3/mW9Q+jrR/TAprI/duEVr kX2g==
X-Gm-Message-State: AMCzsaUy4viGh5Vka5W/cAYZlhlfeorOe6xb/tU8YXxKHC/Qb+3vXrZQ kw3U582GBWK15zRHKvaZK2ZeQA==
X-Google-Smtp-Source: ABhQp+T52lGqECBJHeGwwSTSiYhimX4fNxOxxkLVIxbupwV/xOVAEFogwTmBPeRmXyRL6Xx2qzB29Q==
X-Received: by 10.84.133.165 with SMTP id f34mr18918065plf.268.1510082279863;  Tue, 07 Nov 2017 11:17:59 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id e84sm4718291pfd.1.2017.11.07.11.17.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 11:17:58 -0800 (PST)
Subject: Re: RFC6434bis open issue - RFC4191 text
To: Tim Chown , 6man WG 
References: <4FF47B5B-247F-4361-838C-2E50BD642ED3@jisc.ac.uk>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <27940d72-293a-0486-ab23-ae816566adb2@gmail.com>
Date: Wed, 8 Nov 2017 08:17:59 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4FF47B5B-247F-4361-838C-2E50BD642ED3@jisc.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 19:18:03 -0000

On 08/11/2017 00:48, Tim Chown wrote:
> Hi,
>=20
> TimW and I would like to get some list feedback on some open issues in =
the draft in advance of the Singapore WG session.
>=20
> The first topic is whether the text on RFC4191 is now acceptable, i.e.:=

>=20
> =E2=80=94 snip =E2=80=94
>=20
> 5.9.  Default Router Preferences and More-Specific Routes - RFC 4191
>=20
>    "Default Router Preferences and More-Specific Routes" [RFC4191]
>    provides support for nodes attached to multiple (different) networks=
,
>    each providing routers that advertise themselves as default routers
>    via Router Advertisements.  In some scenarios, one router may provid=
e
>    connectivity to destinations the other router does not, and choosing=

>    the "wrong" default router can result in reachability failures.  In
>    order to resolve this scenario IPv6 Nodes MUST implement [RFC4191]
>    and SHOULD implement Type C host role.
>=20
> =E2=80=94 snip =E2=80=94
>=20
> Any comments welcomed. =20
>=20
> (As a nit, I can see we should add "the" before "Type C=E2=80=9D.)

I already mentioned this in my comments a couple of weeks ago,
and Tim W replied:

>> I suggest that the last phrase should clarify that "Type C" is defined=

>> in RFC 4191, because as written that is not obvious.
>>
> We can clarify that in the next revision.

    Brian
=20



From nobody Tue Nov  7 11:20:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4CB13301D for ; Tue,  7 Nov 2017 11:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6OkiFODytNk for ; Tue,  7 Nov 2017 11:20:51 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD82132FB9 for ; Tue,  7 Nov 2017 11:20:50 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id 17so189236pfn.12 for ; Tue, 07 Nov 2017 11:20:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QxyDBZ0eWX0IjDm1JvkQlTUt93EQ1DL+x6MqxnT0wSE=; b=eMV9YwEI4VN51CRCF9/uHiZNquHrsgCG9P8UEyHXU1HhTNPWqGVPY6kruXMA6HGe+k R/pkO5KjSUDgguKo6Kpvsgipc3Z1rTDnmXR85RQZviqqcYKouvAfodbjJJJ8hLKssTi4 xFDLr8X2XLWvCfa3yHlx7BaZqgt/6iDseASmEcWMUz4SIwCJ5Jqb/WzEpYaGhnUyNcPg Uszz28A2F2T5pUEtI5K9zKbM6Uo2OjeC9qc4gAWJauQPR8d+HpGDbAD/PzDIeN48+7EQ L8R7gFVGBEm2IR8AoM4bN5xPWTrmuaOlmBekOwNNYVKjabn9blNhV6hHhCX9nRQZM86g CE2Q==
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=QxyDBZ0eWX0IjDm1JvkQlTUt93EQ1DL+x6MqxnT0wSE=; b=feIXr07AWMli0i5lFbAlKrRGXfJ0sdhXOeYwtmicY/2eYwGOsreZHMyxmn7BqQ/Lky v0LDUwcrIQjss0/uwcYK0hyJ9us9Fv1O872v3kk0tv23VAQ9W9SO0474XYEvKgb7cy/m jQivafIRrdEhIzA/HTXe3TbyCE6KjyBnfCRkbNuiM1/Exaqmd7sIbCXcA/Jv+0DF0ZpL 3ZfpltlbFdZesj7Hul47mnNrKI9MMf1O5cAGHxob2ezmq72WbyZEbDTVDmpJUH7KjOUr YYuUM4G0Nbe6uB1Os3G/pIMhJ515myyh+Gbf70ekPQY/ROaziMgqOcdr/8h2T9buub/s hJsA==
X-Gm-Message-State: AMCzsaW0MHQJ2Sg1XbzTj+L+ITpGVHC+zYV/+GPFOJ665epCUhKbwiFk 5G2fr7FCcMPb1BphehSJrIEROQ==
X-Google-Smtp-Source: ABhQp+QZGc+UaRwBYOh4a5CiJgCo8FH2CE5esGllgp51JxCnDMKuOpZhmjNOY4woFZOWke2Pg8F22Q==
X-Received: by 10.159.197.67 with SMTP id d3mr19260411plo.433.1510082449579; Tue, 07 Nov 2017 11:20:49 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q69sm4611668pfg.127.2017.11.07.11.20.47 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 11:20:48 -0800 (PST)
Subject: Re: RFC6434bis open issue - IPv6 EH protection
To: ipv6@ietf.org
References: <4E35047B-BB4A-4ED2-BB1D-535EC54C6502@jisc.ac.uk>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Wed, 8 Nov 2017 08:20:48 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4E35047B-BB4A-4ED2-BB1D-535EC54C6502@jisc.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 19:20:53 -0000

On 08/11/2017 00:59, Tim Chown wrote:
> Hi,
>=20
> Here is a second open issue in the draft for which the authors would li=
ke comments.
>=20
> In response to previous discussions, Tom Herbert kindly supplied some t=
ext on how nodes may protect themselves from excessive EH options.
>=20
> There are two issues here.
> 1. Does the text look reasonable?
> 2. The text is quite long, and is not published elsewhere; is a separat=
e draft more appropriate with just briefer text in 6434bis?
>=20
> In general, we have minimised new text in 6434bis, and pointed at mater=
ial published in RFCs elsewhere.

Right. And this text is getting close to BCP or even BIP (Best Implementa=
tion Practice).
But I think it's reasonable to include it.

    Brian

> =E2=80=94 snip =E2=80=94
>=20
> 5.3.  Protecting a node from excessive EH options
>=20
>    Per RFC 8200, end hosts are expected to process all extension
>    headers, destination options, and hop-by-hop options in a packet.
>    Given that the only limit on the number and size of extension header=
s
>    is the MTU, the processing of received packets could be considerable=
=2E
>    It is also conceivable that a long chain of extension headers might
>    be used as a form of denial-of-service attack.  Accordingly, a host
>    may place limits on the number and sizes of extension headers and
>    options it is willing to process.
>=20
>    A host MAY limit the number of consecutive PAD1 options in
>    destination options or hop-by-hop options to seven.  In this case, i=
f
>    the more than seven consecutive PAD1 options are present the the
>    packet should be silently discarded.  The rationale is that if
>    padding of eight or more bytes is required than the PADN option
>    should be used.
>=20
>    A host MAY limit number of bytes in a PADN option to be less than
>    eight.  In such a case, if a PADN option is present that has a lengt=
h
>    greater than seven then the packet should be silently discarded.  Th=
e
>    rationale for this guideline is that the purpose of padding is for
>    alignment and eight bytes is the maximum alignment used in IPv6.
>=20
>    A host MAY disallow unknown options in destination options or hob-by=
-
>    hop options.  This should be configurable where the default is to
>    accept unknown options and process them per RFC2460.  If a packet
>    with unknown options is received and the host is configured to
>    disallow them, then the packet should be silently discarded.
>=20
>    A host MAY impose a limit on the maximum number of non-padding
>    options allowed in a destination options and hop-by-hop extension
>    headers.  If this feature is supported the maximum number should be
>    configurable and the default value SHOULD be set to eight.  The
>    limits for destination options and hop-by-hop options may be
>    separately configurable.  If a packet is received and the number of
>    destination or hop-by-hop optines exceeds the limit, then the packet=

>    should be silently discarded.
>=20
>    A host MAY impose a limit on the maximum length of destination
>    options or hop-by-hop options extension header.  This value should b=
e
>    configurable and the default is to accept options of any length.  If=

>    a packet is received and the length of destination or hop-by-hop
>    options extension header exceeds the length limit, then the packet
>    should be silently discarded.
>=20
> =E2=80=94 snip =E2=80=94
>=20
> For the full document, see
> https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02#section-5.3
>=20
> Tim
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From nobody Tue Nov  7 11:25:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C0E126BF3 for ; Tue,  7 Nov 2017 11:25:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_QOzKp_hbrO for ; Tue,  7 Nov 2017 11:25:51 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDCD12421A for ; Tue,  7 Nov 2017 11:25:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510082749; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=oihLE3fzrBLfzo3KwLj2IQeY2q2O8vLpj7wjpT+2bDY=; b=LUbHayiN2x/wPaA5xtI9Ej1IDtwnthIUoEk6+MQv65h5u5AnQOQ/ZVTXfgBVlEJgETo/tTgPD8p4gjNkQheMU4ggErQyO0PeGTSH/blwAdWFUkcPgTC70xeZPsy82n7axeeVOa+bYHZkXBVhAugqjX9wKkxMMQR63lHFti54B6I=
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0184.outbound.protection.outlook.com [213.199.154.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-134-06uSDWwzPvGhJx6cBPNEBg-1; Tue, 07 Nov 2017 19:25:46 +0000
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.218.6; Tue, 7 Nov 2017 19:25:45 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::f008:dc81:4b84:fd23%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 19:25:45 +0000
From: Tim Chown 
To: Brian E Carpenter 
CC: 6man WG 
Subject: Re: RFC6434bis open issue - RFC4191 text
Thread-Topic: RFC6434bis open issue - RFC4191 text
Thread-Index: AQHTV75EJ9Vd3jxnpkmfKsh/gF+IgqMJSsKAgAACKgA=
Date: Tue, 7 Nov 2017 19:25:45 +0000
Message-ID: 
References: <4FF47B5B-247F-4361-838C-2E50BD642ED3@jisc.ac.uk> <27940d72-293a-0486-ab23-ae816566adb2@gmail.com>
In-Reply-To: <27940d72-293a-0486-ab23-ae816566adb2@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:edda:61ec:7313:b139]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 20:K1/5uPdtBl9m6PbBERgYz7DYPWT97io0IDKEtwjAcBLTc3DgoDPCFJO2P41fr0zMRccdeOCeTTkR0jr+fWUQjxiJxmaJ876q9j8w1STz2t5x4xT0HsZghJaCboX25uSAjgOcnichChNdHOlPlIvko/yb0WOz2a502vZMJ1g6QKQ=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 620a16f5-a7ba-4fac-e54b-08d5261557f5
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); 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)(3231021)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(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: 0484063412
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(24454002)(189002)(199003)(53546010)(6246003)(42882006)(3280700002)(316002)(97736004)(86362001)(81166006)(81156014)(36756003)(8936002)(8676002)(5660300001)(39060400002)(6916009)(83716003)(2950100002)(5250100002)(14454004)(57306001)(3660700001)(82746002)(786003)(2906002)(6436002)(2900100001)(50226002)(305945005)(106356001)(6506006)(68736007)(229853002)(99286004)(5890100001)(6486002)(74482002)(6512007)(101416001)(50986999)(4326008)(25786009)(72206003)(6116002)(102836003)(189998001)(53936002)(478600001)(33656002)(76176999)(105586002)(7736002); 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: 
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 620a16f5-a7ba-4fac-e54b-08d5261557f5
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 19:25:45.4225 (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: 06uSDWwzPvGhJx6cBPNEBg-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 19:25:53 -0000

PiBPbiA3IE5vdiAyMDE3LCBhdCAxOToxNywgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2Fy
cGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwOC8xMS8yMDE3IDAwOjQ4LCBUaW0g
Q2hvd24gd3JvdGU6DQo+PiBIaSwNCj4+IA0KPj4gVGltVyBhbmQgSSB3b3VsZCBsaWtlIHRvIGdl
dCBzb21lIGxpc3QgZmVlZGJhY2sgb24gc29tZSBvcGVuIGlzc3VlcyBpbiB0aGUgZHJhZnQgaW4g
YWR2YW5jZSBvZiB0aGUgU2luZ2Fwb3JlIFdHIHNlc3Npb24uDQo+PiANCj4+IFRoZSBmaXJzdCB0
b3BpYyBpcyB3aGV0aGVyIHRoZSB0ZXh0IG9uIFJGQzQxOTEgaXMgbm93IGFjY2VwdGFibGUsIGku
ZS46DQo+PiANCj4+IOKAlCBzbmlwIOKAlA0KPj4gDQo+PiA1LjkuICBEZWZhdWx0IFJvdXRlciBQ
cmVmZXJlbmNlcyBhbmQgTW9yZS1TcGVjaWZpYyBSb3V0ZXMgLSBSRkMgNDE5MQ0KPj4gDQo+PiAg
ICJEZWZhdWx0IFJvdXRlciBQcmVmZXJlbmNlcyBhbmQgTW9yZS1TcGVjaWZpYyBSb3V0ZXMiIFtS
RkM0MTkxXQ0KPj4gICBwcm92aWRlcyBzdXBwb3J0IGZvciBub2RlcyBhdHRhY2hlZCB0byBtdWx0
aXBsZSAoZGlmZmVyZW50KSBuZXR3b3JrcywNCj4+ICAgZWFjaCBwcm92aWRpbmcgcm91dGVycyB0
aGF0IGFkdmVydGlzZSB0aGVtc2VsdmVzIGFzIGRlZmF1bHQgcm91dGVycw0KPj4gICB2aWEgUm91
dGVyIEFkdmVydGlzZW1lbnRzLiAgSW4gc29tZSBzY2VuYXJpb3MsIG9uZSByb3V0ZXIgbWF5IHBy
b3ZpZGUNCj4+ICAgY29ubmVjdGl2aXR5IHRvIGRlc3RpbmF0aW9ucyB0aGUgb3RoZXIgcm91dGVy
IGRvZXMgbm90LCBhbmQgY2hvb3NpbmcNCj4+ICAgdGhlICJ3cm9uZyIgZGVmYXVsdCByb3V0ZXIg
Y2FuIHJlc3VsdCBpbiByZWFjaGFiaWxpdHkgZmFpbHVyZXMuICBJbg0KPj4gICBvcmRlciB0byBy
ZXNvbHZlIHRoaXMgc2NlbmFyaW8gSVB2NiBOb2RlcyBNVVNUIGltcGxlbWVudCBbUkZDNDE5MV0N
Cj4+ICAgYW5kIFNIT1VMRCBpbXBsZW1lbnQgVHlwZSBDIGhvc3Qgcm9sZS4NCj4+IA0KPj4g4oCU
IHNuaXAg4oCUDQo+PiANCj4+IEFueSBjb21tZW50cyB3ZWxjb21lZC4gIA0KPj4gDQo+PiAoQXMg
YSBuaXQsIEkgY2FuIHNlZSB3ZSBzaG91bGQgYWRkICJ0aGUiIGJlZm9yZSAiVHlwZSBD4oCdLikN
Cj4gDQo+IEkgYWxyZWFkeSBtZW50aW9uZWQgdGhpcyBpbiBteSBjb21tZW50cyBhIGNvdXBsZSBv
ZiB3ZWVrcyBhZ28sDQo+IGFuZCBUaW0gVyByZXBsaWVkOg0KPiANCj4+PiBJIHN1Z2dlc3QgdGhh
dCB0aGUgbGFzdCBwaHJhc2Ugc2hvdWxkIGNsYXJpZnkgdGhhdCAiVHlwZSBDIiBpcyBkZWZpbmVk
DQo+Pj4gaW4gUkZDIDQxOTEsIGJlY2F1c2UgYXMgd3JpdHRlbiB0aGF0IGlzIG5vdCBvYnZpb3Vz
Lg0KPj4+IA0KPj4gV2UgY2FuIGNsYXJpZnkgdGhhdCBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0K
QWdyZWVkIEJyaWFuLCBzb3JyeSB3ZSBtaXNzZWQgaXQgbGFzdCB0aW1lIHJvdW5kLg0KDQpUaW0N
Cg0K


From nobody Tue Nov  7 11:29:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A266126BF3 for ; Tue,  7 Nov 2017 11:29:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eYn97PCczEl for ; Tue,  7 Nov 2017 11:29:28 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F102E12421A for ; Tue,  7 Nov 2017 11:29:27 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id t188so208621pfd.10 for ; Tue, 07 Nov 2017 11:29:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=163KGNepeKjtsVyT+cJJt/KwOG1C6FFdiwYN5VkVvVY=; b=b73yebo2B6WMy+43Brswc8VFE7XupAOMAAeD5Oyo/godOGL9tL05tMisdqbW5rOQAI LsW1afFnI6xNbAMywERGSMQ99WG0UDko/ecr+vrMoslFQwt8QfTvK29iRl17Yg1k+w8/ eW9qGECFBITd69IksDWibMIcLTwSqG2G5i2S+VF0S5GpBtKTNuV4kazTzXAfauJ71wTB TUnUe7rRvU0ywQHWrvC6OVjhZZEtC58baaI+7QKrHLe2HrtolrjB2Ugm0vRZ8v4xkDtV 617SYmBsbW+ug9k7yDT9O7nl5tk8EzEXnZ3Ueid7TlVDjwGfpoL0TtrLUWSiNxYLYhuo 94Eg==
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=163KGNepeKjtsVyT+cJJt/KwOG1C6FFdiwYN5VkVvVY=; b=s85fCzH+zIFAdRpZx7b0Agd9g7rKAwg/UcNK1oyyixS5GN53m3jYs3KV6XCHDUu7Pc 1YafN+SCxD/sW1wsbJ1ulxhHRndIVizxEIpY34flCjp3OdUWlH+XPaykrLYnlSAb0AlS 2CT6UhpbjKxib0cLjsbGxARujIxDHCcz9FfdN5k74cNWsc++5C1LX05H81mijNLaWp4b H2rz7+c5zGFFf3QxB28Bm6aZH3U69vcVyMfYtrbZgvXLRBHtviFf1znZC9IBtb1WNpa4 oZ69OJ4SXFSEaMxbvC5YxUzMpTi5uxiHXI0u0ZqQVxLO+y5BtynCcsKYg2i7n4Dm4Vaw SFdQ==
X-Gm-Message-State: AMCzsaXKVzSKi320XCoSxPAbYvxp3CUgV8ELOSGTIiWyok6BWk1na4yx x/h73q5Q4lINiddRyZAJLnqpBA==
X-Google-Smtp-Source: ABhQp+ROTTJGkfgNZF27T/u1ekvo2gHcF0KScYAXVDAycQyAuo5kAJH1cbZUAA5UezJfnSV3yoIvww==
X-Received: by 10.84.245.145 with SMTP id j17mr18676781pll.163.1510082967497;  Tue, 07 Nov 2017 11:29:27 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s3sm4718582pfk.7.2017.11.07.11.29.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 11:29:26 -0800 (PST)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Tim Chown 
Cc: Fernando Gont , "C. M. Heard" , 6man WG , Michael Richardson 
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com> <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com>
Date: Wed, 8 Nov 2017 08:29:26 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 19:29:30 -0000

On 08/11/2017 00:20, Tim Chown wrote:
> Hi,
>=20
>> On 6 Nov 2017, at 19:35, Brian E Carpenter  wrote:
>>
>> Hi Fernando,
>>
>> On 07/11/2017 07:02, Fernando Gont wrote:
>>> On 11/02/2017 04:33 PM, Brian E Carpenter wrote:
>>>> On 03/11/2017 04:26, C. M. Heard wrote:
>>>>> On Thu, Nov 2, 2017, Michael Richardson  wro=
te:
>>>>>
>>>>>>
>>>>>> C. M. Heard  wrote:
>>>>>>> On Wed, 01 Nov 2017, Michael Richardson wrote:
>>>>>>>> Yet we skip other extension headers in order to find the ULP.
>>>>>>
>>>>>>> Not so. An end node that encounters an unrecognized extension hea=
der
>>>>>> is
>>>>>>
>>>>>> Both AH and IPIP are well known and recognized extension headers.
>>>>
>>>> AH is an extension header. "IPIP" isn't. It's Protocol 41, and Proto=
col 41
>>>> is otherwise known as IPv6. (That's why it's also called IPPROTO_IPV=
6).
>>>> In RFC8200 terms that makes it an "upper-layer header". Strictly spe=
aking,
>>>> RFC8200 doesn't specify what to do with an unrecognized upper-layer =
header.
>>>
>>> Based on the std, anything that is unknown is an EH. In the context o=
f
>>> RFC8200/FC2460, there's only:
>>>
>>> * Known EHs
>>> * Known ULP
>>> * Unknown EHs
>>
>> Yes, that's what the text says but I wish we'd fixed it in 8200 to
>> acknowledge that there is a 4th case (Unknown ULP) and that it
>> cannot be distinguished from the 3rd case. Acknowledging that is
>> much better than ignoring it. I'm happy with Ole's suggestion that
>> this (and the resulting ICMP 1 behaviour) should be mentioned in
>> 6434bis - as a clarification, not a new invention.
>=20
> This seems a reasonable approach to me.  Would you like to propose text=
, Brian?

After this:

5.1.  Internet Protocol Version 6 - RFC 8200

   The Internet Protocol Version 6 is specified in [RFC8200].  This
   specification MUST be supported.

   Any unrecognized extension headers or options MUST be processed as
   described in RFC 8200.

insert something like:

   Note that it is impossible for a node to distinguish between an
   unrecognized extension header and an unrecognized upper layer
   protocol. Therefore, a node will behave in the same way for
   either of these cases, in particular by returning an ICMP
   Parameter Problem message with code 1 ("unrecognized Next Header
   type encountered") even for an unrecognized upper layer protocol.

(Protocol 41 is not special in this regard.)

 - Brian

>=20
>> I also agree that there are enough potential issues in unexpected
>> IPv6-in-IPv6 that is deserves its own draft.
>=20
> I=E2=80=99d agree. The same with header insertion for that matter. Focu=
s on the issues and how/if they can be mitigated and in which contexts.
>=20
> Tim
>=20
>>
>> Regards
>>   Brian
>>
>>> with the last one being the default branch :-)
>>>
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>=20


From nobody Tue Nov  7 13:24:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FF5128B51 for ; Tue,  7 Nov 2017 13:24:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 bWz83AUPDzTJ for ; Tue,  7 Nov 2017 13:24:47 -0800 (PST)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C044B1279E5 for ; Tue,  7 Nov 2017 13:24:46 -0800 (PST)
Received: by mail-ua0-x22f.google.com with SMTP id s41so454801uab.10 for ; Tue, 07 Nov 2017 13:24:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ioeuljt/xr12ornRBJZh9RZ42pSJwmweJzzfn/9cyJo=; b=gflV8s45fvpbsFjD6EVkTMBWbqq9HCo5ux/ppRfKXvWj3iWZuujes9uCb7SAzR/vxN AdJncGC99kXfHx/0tLcGwGGSWUCcuOzzVtMQJo6uq9xWO0VNkBd/nd/xegMAK6Aq17hD M5snAjvLluuibHQtDnJR1H0NBiN/SmBBxdI4X6ukz6I6B9MQzoF21D8xiE7CWFUJ2KF1 HDUqHyv+5YH9a3cO+lkIVMzzEU4h0FaDdnknzXW3VsFU3t5916Pdvh7rmiD1ejzD8t4L 73u5jqpfguAPdHZaYkkmJHmEt8MQBJpwiu4pxmlxivjJE2MEA8FyyBN2OnEtqlabCEmk UDPA==
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=ioeuljt/xr12ornRBJZh9RZ42pSJwmweJzzfn/9cyJo=; b=gDji3lnujpnWq0NXAhRyfWbMxneK9cp0z+DMTMyFZVswZ5oCSw9F9D/8BAqTLGHzo6 Eo+F1wCMSD9vfkk26i7XQhEHQwzGlEl6MyqVgk3OXT8I/45cFhgzxTtrT4zRRk+ubBzA U0NVr72hUs2FHgDQE6gNiE+miYT33Kx4EG9ISOrNmxVqPtJOod5kERMIkvu2QS1rviJo dRvQfKQlyEdv/6Rw5MtW7XOyDL3Toen8mSjyyl49o8hY8jDqjjPN0raQKOEOglKGnpjY tSVA7Mh5yCzhTHm/JZj3/Ko4AGEHmP3N0FkIQQ0jNqOxcICVCyLpAdOovNu7mldqYZGt Fn+w==
X-Gm-Message-State: AJaThX6U7pkhLZK3zuLpdjt5KTAStK00VxTeVZSdt6Fr0FPyeiCkvS8k gWjO70PQUEeRC7gzoVmylc0ZAYSOgoxyiaheSjc=
X-Google-Smtp-Source: ABhQp+R7FIjpq+Fr4wHYFZWlaHGiC0BEPGsBdbfAGFFEp6StRWTkAulJvAHpA5QGLDa018mrAp8e0rsbdBC03ibxd4I=
X-Received: by 10.159.53.13 with SMTP id o13mr88125uao.183.1510089885718; Tue, 07 Nov 2017 13:24:45 -0800 (PST)
MIME-Version: 1.0
Sender: fgont.mobile@gmail.com
Received: by 10.103.19.129 with HTTP; Tue, 7 Nov 2017 13:24:45 -0800 (PST)
In-Reply-To: <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com>
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com> <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk> <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com>
From: Fernando Gont 
Date: Tue, 7 Nov 2017 18:24:45 -0300
X-Google-Sender-Auth: 2OxkI6x6--gjqNFQboKyrRiLbI4
Message-ID: 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Brian E Carpenter 
Cc: Tim Chown , "C. M. Heard" , 6man WG , Michael Richardson 
Content-Type: multipart/alternative; boundary="94eb2c03bb4e379d44055d6b33a4"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 21:24:49 -0000

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

FWIW, I support Brian's proposed text.

On Tuesday, November 7, 2017, Brian E Carpenter 
wrote:

> On 08/11/2017 00:20, Tim Chown wrote:
> > Hi,
> >
> >> On 6 Nov 2017, at 19:35, Brian E Carpenter  > wrote:
> >>
> >> Hi Fernando,
> >>
> >> On 07/11/2017 07:02, Fernando Gont wrote:
> >>> On 11/02/2017 04:33 PM, Brian E Carpenter wrote:
> >>>> On 03/11/2017 04:26, C. M. Heard wrote:
> >>>>> On Thu, Nov 2, 2017, Michael Richardson  > wrote:
> >>>>>
> >>>>>>
> >>>>>> C. M. Heard > wrote:
> >>>>>>> On Wed, 01 Nov 2017, Michael Richardson wrote:
> >>>>>>>> Yet we skip other extension headers in order to find the ULP.
> >>>>>>
> >>>>>>> Not so. An end node that encounters an unrecognized extension
> header
> >>>>>> is
> >>>>>>
> >>>>>> Both AH and IPIP are well known and recognized extension headers.
> >>>>
> >>>> AH is an extension header. "IPIP" isn't. It's Protocol 41, and
> Protocol 41
> >>>> is otherwise known as IPv6. (That's why it's also called
> IPPROTO_IPV6).
> >>>> In RFC8200 terms that makes it an "upper-layer header". Strictly
> speaking,
> >>>> RFC8200 doesn't specify what to do with an unrecognized upper-layer
> header.
> >>>
> >>> Based on the std, anything that is unknown is an EH. In the context o=
f
> >>> RFC8200/FC2460, there's only:
> >>>
> >>> * Known EHs
> >>> * Known ULP
> >>> * Unknown EHs
> >>
> >> Yes, that's what the text says but I wish we'd fixed it in 8200 to
> >> acknowledge that there is a 4th case (Unknown ULP) and that it
> >> cannot be distinguished from the 3rd case. Acknowledging that is
> >> much better than ignoring it. I'm happy with Ole's suggestion that
> >> this (and the resulting ICMP 1 behaviour) should be mentioned in
> >> 6434bis - as a clarification, not a new invention.
> >
> > This seems a reasonable approach to me.  Would you like to propose text=
,
> Brian?
>
> After this:
>
> 5.1.  Internet Protocol Version 6 - RFC 8200
>
>    The Internet Protocol Version 6 is specified in [RFC8200].  This
>    specification MUST be supported.
>
>    Any unrecognized extension headers or options MUST be processed as
>    described in RFC 8200.
>
> insert something like:
>
>    Note that it is impossible for a node to distinguish between an
>    unrecognized extension header and an unrecognized upper layer
>    protocol. Therefore, a node will behave in the same way for
>    either of these cases, in particular by returning an ICMP
>    Parameter Problem message with code 1 ("unrecognized Next Header
>    type encountered") even for an unrecognized upper layer protocol.
>
> (Protocol 41 is not special in this regard.)
>
>  - Brian
>
> >
> >> I also agree that there are enough potential issues in unexpected
> >> IPv6-in-IPv6 that is deserves its own draft.
> >
> > I=E2=80=99d agree. The same with header insertion for that matter. Focu=
s on the
> issues and how/if they can be mitigated and in which contexts.
> >
> > Tim
> >
> >>
> >> Regards
> >>   Brian
> >>
> >>> with the last one being the default branch :-)
> >>>
> >>>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org 
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >>
> >
>
>

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

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

FWIW, I support Brian's proposed text.

On Tuesday, November 7, 2=
017, Brian E Carpenter <b=
rian.e.carpenter@gmail.com> wrote:
On 08/11/2017 00:20, Tim Chown wrote:

> Hi,

>

>> On 6 Nov 2017, at 19:35, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

>>

>> Hi Fernando,

>>

>> On 07/11/2017 07:02, Fernando Gont wrote:

>>> On 11/02/2017 04:33 PM, Brian E Carpenter wrote:

>>>> On 03/11/2017 04:26, C. M. Heard wrote:

>>>>> On Thu, Nov 2, 2017, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

>>>>>

>>>>>>

>>>>>> C. M. Heard <heard@pobox.com> wrote:

>>>>>>> On Wed, 01 Nov 2017, Michael Richardson wrote:=


>>>>>>>> Yet we skip other extension headers in ord=
er to find the ULP.

>>>>>>

>>>>>>> Not so. An end node that encounters an unrecog=
nized extension header

>>>>>> is

>>>>>>

>>>>>> Both AH and IPIP are well known and recognized ext=
ension headers.

>>>>

>>>> AH is an extension header. "IPIP" isn't. It&=
#39;s Protocol 41, and Protocol 41

>>>> is otherwise known as IPv6. (That's why it's also =
called IPPROTO_IPV6).

>>>> In RFC8200 terms that makes it an "upper-layer header=
". Strictly speaking,

>>>> RFC8200 doesn't specify what to do with an unrecognize=
d upper-layer header.

>>>

>>> Based on the std, anything that is unknown is an EH. In the co=
ntext of

>>> RFC8200/FC2460, there's only:

>>>

>>> * Known EHs

>>> * Known ULP

>>> * Unknown EHs

>>

>> Yes, that's what the text says but I wish we'd fixed it in=
 8200 to

>> acknowledge that there is a 4th case (Unknown ULP) and that it

>> cannot be distinguished from the 3rd case. Acknowledging that is
>> much better than ignoring it. I'm happy with Ole's suggest=
ion that

>> this (and the resulting ICMP 1 behaviour) should be mentioned in
>> 6434bis - as a clarification, not a new invention.

>

> This seems a reasonable approach to me.=C2=A0 Would you like to propos=
e text, Brian?



After this:



5.1.=C2=A0 Internet Protocol Version 6 - RFC 8200



=C2=A0 =C2=A0The Internet Protocol Version 6 is specified in [RFC8200].=C2=
=A0 This

=C2=A0 =C2=A0specification MUST be supported.



=C2=A0 =C2=A0Any unrecognized extension headers or options MUST be processe=
d as

=C2=A0 =C2=A0described in RFC 8200.



insert something like:



=C2=A0 =C2=A0Note that it is impossible for a node to distinguish between a=
n

=C2=A0 =C2=A0unrecognized extension header and an unrecognized upper layer<=
br>
=C2=A0 =C2=A0protocol. Therefore, a node will behave in the same way for
=C2=A0 =C2=A0either of these cases, in particular by returning an ICMP

=C2=A0 =C2=A0Parameter Problem message with code 1 ("unrecognized Next=
 Header

=C2=A0 =C2=A0type encountered") even for an unrecognized upper layer p=
rotocol.



(Protocol 41 is not special in this regard.)



=C2=A0- Brian



>

>> I also agree that there are enough potential issues in unexpected<=
br>
>> IPv6-in-IPv6 that is deserves its own draft.

>

> I=E2=80=99d agree. The same with header insertion for that matter. Foc=
us on the issues and how/if they can be mitigated and in which contexts.
>

> Tim

>

>>

>> Regards

>>=C2=A0 =C2=A0Brian

>>

>>> with the last one being the default branch :-)

>>>

>>>

>>

>> ------------------------------------------------------------<=
wbr>--------

>> IETF IPv6 working group mailing list

>> ipv6@ietf.org

>> Administrative Requests: https://www.ietf.org/mailman/listinfo/=
ipv6

>> ------------------------------------------------------------<=
wbr>--------

>>

>






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







--94eb2c03bb4e379d44055d6b33a4--


From nobody Wed Nov  8 07:11:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE811275C5 for ; Wed,  8 Nov 2017 07:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsH6yq4wC9HK for ; Wed,  8 Nov 2017 07:11:03 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E925D12706D for ; Wed,  8 Nov 2017 07:11:00 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8EFF2206C8; Wed,  8 Nov 2017 10:12:17 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E6AE281F0B; Wed,  8 Nov 2017 10:10:59 -0500 (EST)
From: Michael Richardson 
To: Brian E Carpenter 
cc: Tim Chown , Fernando Gont , "C. M. Heard" , 6man WG 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
In-Reply-To: <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com>
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com> <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk> <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Nov 2017 15:11:06 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Brian E Carpenter  wrote:
    >    Note that it is impossible for a node to distinguish between an
    > unrecognized extension header and an unrecognized upper layer

Does "unrecognized" mean unknown to the writer of the code at the time of
writing, or does it mean a header which the node has no support for?

Or to put it in C, what goes into TBD?

retry:
  switch(proto) {
  case IPPROTO_UDP:
       udp_rcv();
       break;
  case IPPROTO_TCP:
       tcp_rcv();
       break;
  case IPPROTO_AH:
       if(ipsec_enabled) ipsec_rcv();
       else TBD;
  case IPPROTO_HOPOPT:
       process_hopopt();
       goto retry;
  case IPPROTO_MOBILITY_HEADER:
       skip_hopopt();
       goto retry;
  default:
       return_icmp(1);
  }

=2D-=20
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloDHoMACgkQgItw+93Q
3WVpMwf+J/AaovenE/t7iRLoOigWQGnYVVz/sjd20OHtA8QrvmsjbbDSacIhg+PN
TSaNIZznwwcSuVVr+SIhj3gqbmi6F+N8dn5SBxRf29c55sd4lThilBkUk9ldcJzc
kEtVJvEL5N7be/vZD13SDHNrISLxiycowsEJFT8RD79ESdL+Auct4u1SnRqdQzKZ
puVbERFCzvRW0M3TG/E/pMCoy124xLIMpRS/pJwU3ayXLrp2GdMA6p6UzA6c6EpA
EwwIHnr/8+ZYAutRTALb5ZZGWAJ/Az29S1fOa3UAqYuhFBnvZBC/OdQQgXLqnmVY
sUEEA9jKQkXZvc2lJU88jFJOhbAbGw==
=90V4
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Nov  8 11:15:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EA1128990 for ; Wed,  8 Nov 2017 11:15:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBPtiI66eWMB for ; Wed,  8 Nov 2017 11:15:49 -0800 (PST)
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 D571A12778D for ; Wed,  8 Nov 2017 11:15:49 -0800 (PST)
Received: by mail-pg0-x235.google.com with SMTP id l19so81037pgo.2 for ; Wed, 08 Nov 2017 11:15:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1yAGdZokqdHFu3EETdjvp5qoGLF9v7jX6TKcL2Qhg5I=; b=oE6bxX+OHBk3DxwwRb+f91YdXYffLgADv55naRyAf5djs0R5xi58e4CiigRMZfKyYB 0cGWpNVflcyVKAfy+R5ePe2j2IMJRNynSgy+rNt1siYCcfEPusTxQ6TFjxrB9TjFxvJm i1be10jhYhzZxWWHLMhelgL0YgMILWZH9TGm/CnM6UNW8s4x8/9mdSO33/8U7xb3fiLh MdI442adhH31ekMzUN03IiOmFcAwsVLsCLXka/1PbYHy447I4A3YgG74CGzvqG+H0WAn uYnqNIL4isBphcuBZSY0jm/tWMl5HKS9seEP4YPSeTU6pkGJYXfCRPNG2S1d+LwwGASx lJRw==
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=1yAGdZokqdHFu3EETdjvp5qoGLF9v7jX6TKcL2Qhg5I=; b=FZIhetACw7i2hdbJy6ZYXMbPrQZZI2AvCJLAkqIjBOHip45ByjkucnVkwOPfiuQkux OGxxwOOCrdEFs425aW9fhpkBhFew9dDxA8Kd5MTdPbLrpzySBCS16QACt3kUVC/p3K1F 2F2iQxdUQPRi5M/zPjXkdbfs8GPsAA7/IDapA4HB61NBbdSB4/T4gMil4H5BUlowuEP/ 2Z8XlxsBdGo/D+w+yGhF6ldlD6UTm3/StYny5XQwMwn0UQKUnyG1YTutrmPviMsLI9el oa8aV0MY7ki6XlxNWGdQER90625Y2xLPa+IZ3yJU5n/5s+Y7uJZ84/fetCFokxTcmQ+N iZaw==
X-Gm-Message-State: AJaThX7g8V4Y59MkIWlEeXSj4LaCji8rXk2SvwlfWLb5pCO+z3EWoTlL 8dyYgRM905Plw/I6DSCVGlqTlQ==
X-Google-Smtp-Source: ABhQp+Q9xFgh+ZGgJmECkFKcnoE4eNIADe/uIdB/MfOQRVe6JkZPNfc9H9vtQ+QxDg13WKvynPxTqg==
X-Received: by 10.159.211.65 with SMTP id g1mr1377972plp.312.1510168549144; Wed, 08 Nov 2017 11:15:49 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h6sm9526928pgn.63.2017.11.08.11.15.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 11:15:48 -0800 (PST)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Michael Richardson 
Cc: Tim Chown , Fernando Gont , "C. M. Heard" , 6man WG 
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com> <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk> <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com> <12447.1510153859@obiwan.sandelman.ca>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 9 Nov 2017 08:15:50 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <12447.1510153859@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Nov 2017 19:15:51 -0000

On 09/11/2017 04:10, Michael Richardson wrote:
> 
> Brian E Carpenter  wrote:
>     >    Note that it is impossible for a node to distinguish between an
>     > unrecognized extension header and an unrecognized upper layer
> 
> Does "unrecognized" mean unknown to the writer of the code at the time of
> writing, or does it mean a header which the node has no support for?

I think it means unrecognized at run time, regardless of whether it was
known or unknown when the code was written, or configured on or off when
the node was instantiated, or even configured off one microsecond before
the packet arrived. So TBD would be return_icmp(1) in your case.

IMHO.

     Brian

> 
> Or to put it in C, what goes into TBD?
> 
> retry:
>   switch(proto) {
>   case IPPROTO_UDP:
>        udp_rcv();
>        break;
>   case IPPROTO_TCP:
>        tcp_rcv();
>        break;
>   case IPPROTO_AH:
>        if(ipsec_enabled) ipsec_rcv();
>        else TBD;
>   case IPPROTO_HOPOPT:
>        process_hopopt();
>        goto retry;
>   case IPPROTO_MOBILITY_HEADER:
>        skip_hopopt();
>        goto retry;
>   default:
>        return_icmp(1);
>   }
> 


From nobody Wed Nov  8 16:16:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B371129420; Wed,  8 Nov 2017 16:16:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn9TBJRPL8nG; Wed,  8 Nov 2017 16:16:39 -0800 (PST)
Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8066912943A; Wed,  8 Nov 2017 16:16:19 -0800 (PST)
Received: by mail-pg0-x243.google.com with SMTP id a192so3245116pge.9; Wed, 08 Nov 2017 16:16:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=e6jPrhQNubWhREfu7WrT+PHb1wYlQkCijJb1k5HHIws=; b=EDIhBAJl6cyQUc+L41vPC/t6AjXnyigjpaxg25rfZL7653JHsDb8/Xgi+DxjR6Sc6y c0pbgCBiffSYysLRhkjcV8Vw9DNrwFl8zxm2E6bc1UNlkahl/dQqSLQgZQ5MSjNcswOG 2rV0A5ob7FpyLsGov44oe5pgUh7WfARRvH8JoAFIG/gSWm311wU5UJPknMdlMQRP6Kvc vyBV9E4LlUbraSuyrxWcWjrbOavHqIz27T7vZed3EbhsZJ2y+T6eI0Qb7mDORjO/ZFLE 1BBGZweL6pV1Pj/ZOw/R/waiBbLuGO/KXRPS4+kVOMVOTPSMTtGteewCe3aWgMLHVvbZ vlZg==
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=e6jPrhQNubWhREfu7WrT+PHb1wYlQkCijJb1k5HHIws=; b=SAqbU/y+n21eI3PdpWAQZzVGvkj3PTUVGQFmffvtCcpGXRZr6BDSH3funpR1q9aW9r xh1cltvZROFrG2TlDVjWBTYOAeL44RwL9k6kzsrlF9tDnS9IJtOLyxJeE5ol/NT11vFU yTBtZioTFrlc2C5tSon/0mSnOSEQlUZZeJi9Dt2GWilSZNMw10e1VQLJW0QTCZjjGy/s ap+PpyUUFtJWA13qsdtmxWlP9ugVMDU8kOeElaN7AZgsx3trgUluIq+bOpDDuQDEubKr 6gFrymI0H0GLf16wJja/z5zzPl7vjQ1pc2ZxSsuWX9bryQX8iM6HQgCBOa70hp7KIUYh aY0w==
X-Gm-Message-State: AJaThX6ap7RYSnzSjV/AoTf4wqw1jX/1CBmoVcbrqiCTtVSVaKt+A2V8 pPVUmU4R3uSYU39Yme9e16M=
X-Google-Smtp-Source: ABhQp+RtxLIgASwV9swNjG90ajJedlrk8y5wnMwNd/j0tZ7lLzjZ11wRWqBOHCcYdoZ3R0d3FKzP3w==
X-Received: by 10.98.60.211 with SMTP id b80mr2248532pfk.4.1510186578968; Wed, 08 Nov 2017 16:16:18 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id 125sm9541756pff.14.2017.11.08.16.16.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 16:16:17 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim 
In-Reply-To: 
Date: Thu, 9 Nov 2017 09:16:12 +0900
Cc: IPv6 Operations , "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , "6man@ietf.org" <6man@ietf.org>, draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Fernando Gont 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 00:16:41 -0000

Hi Fernando,

If I=E2=80=99m not wrong, SLAAC in this document is one supposed to run =
on hosts not on the router=E2=80=A6

---
DY

> On 7 Nov 2017, at 06:13, Fernando Gont  wrote:
>=20
> Folks,
>=20
> These past few days I ended up reviewing the aforementioned document, =
as
> a result of a thread on this document on the v6ops mailing-list.
>=20
> I had reviewed an early version of the document, in which the benefits
> of not having and on-link prefix were discussed -- which was certainly
> fine (and I supported).
>=20
> While reviewing this document a few days ago, I found that Section 4
> (page 5) contains what is a protocol spec, rather than an operational
> BCP. It contains rules regarding how to set the link-layer address (to =
a
> unicast address) for IPv6 multicasted RAs, and how a SLAAC router =
should
> now remember which prefix has been "leased" to which node -- something
> that seems to be way outside of the v6ops charter, and that should =
have
> been done in 6man, instead.
>=20
> Looking at diffs, it seems this additional text was incorporated very
> recently, in version -09 of the I-D, published in mid September
> =
().
> It seems to be that this change is way beyond what the authors
> originally proposed
> (a bcp saying that it's great to give each host a unique prefix, =
without
> providing details on specific mechanisms or doing protocol specs --
> which was obviously within v6ops' charter), and what the wg shipped, =
and
> also seems to be in conflict of the v6ops and 6man charters (v6ops
> doesn't do protocol specs, but this document certainly contains one).
>=20
> Besides what seems to be a conflict in the aforementioned charter, =
there
> are a number of issues associated with the specified protocol:
>=20
> 1) The protocol spec specified in this document requires the SLAAC
> router to keep state of the "leased" prefixes -- what seems a major
> change to SLAAC, which now would be kind of as stateful as DHCPv6.
>=20
> 2) There are scenarios in which multiple nodes might receive the same
> packet -- say a NIC let's the packet through because it is in
> promiscuous mode -- wich could possibly lead to two nodes configuring
> the same prefix.
>=20
> 3) What happens if the SLAAC router crashes and reboots, loosing state
> of the "leased" prefixes?
>=20
> 4) How are prefixes selected? And, what's the minimum size of the pool
> of prefixes for the selection algorithm not to break due two "prefix
> collisions"? Does the selection algorithm have any specific =
properties?
>=20
>=20
> In summary, revision -09 (most likely done to address some DISCUSS)
> turned the original BCP document into a protocol spec, with a major
> change to SLAAC, which should have happened in 6man, rather than in
> v6ops (which is not allowed to do protocol specs). Looking at the
> current document (to be published), Section 4 (page 5) looks more like =
a
> Std Track document than a BCP.
>=20
> It was suggested to me that I discuss this on the mailing-list... =
hence
> this post.
>=20
> Thoughts?
>=20
> P.S.: I wished I had caught this earlier. I just didn't.
>=20
> Thanks,
> --=20
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>=20
>=20
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Wed Nov  8 17:12:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9253128D6F for ; Wed,  8 Nov 2017 17:12:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLXwUapnoGj8 for ; Wed,  8 Nov 2017 17:12:52 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75616124B0A for ; Wed,  8 Nov 2017 17:12:52 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id b6so3061867pfh.7 for ; Wed, 08 Nov 2017 17:12:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=GyDZw8VbQs/SOIRloo24QUXiP/mGre/1iPDb/HqRyeA=; b=LBl7FGvnVzWTIgbDfioe5y93bIYtb590/mBlsUGm1evrKv11YW07TNJCV8GhuL9baC IvoiKFiJOFZKH+lahfZvGSPvNe1mwyObHvHYnURmDwmyO/X4lVI9DUbZ9rJzm8Z/V16U BaDukaRPiHwSbOa2+nRQiDqhJ7GqwzbiHQkF14YfXeAPCRWGQPmQseoee5ka7vj1lwoj qtw6Hzjd2iMbSPdsnqhCOPdBRHfJaboHeLSjNmHvrnAojdPTzHZ4SqxLdG8khXfVwqiE WRV7T38lLYJZp4gcQ0j9X/rbUcn11M5BF2f+7CUxwuo4rq3DHqT1UbL+O9YbS4WQ8ntQ yeEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=GyDZw8VbQs/SOIRloo24QUXiP/mGre/1iPDb/HqRyeA=; b=Jmq8ET7BeirWSRSfDf79IPi+LNdjb9EfDah9368tN+u2/5lZYAMczJWa9ezOEI8R03 UHEkgTtkAm1QJnyS6K8VSLaJdKau4pDahJbj49vpdzeT4yt8QIteulvQ7Z00pVw+xBk6 FJQx5byvRu4mv2IF6Gr0Ggd7NAEoNDFpRHR63FkfIoYYQQB70a1JjsUUC9+gPghxrNwz JX2iOWO275an2W0pLtXs//O8YJ1B2EHR2u1SmnBwvvVoQhVr3fi/JDloL3aot3qaV5+n 9PByE26/0NgEcIo4+iJBgE7AFz/8bLKJkW//kFk0W/TGFqvVdm1ZSuJYxaIwi/nMRqv2 3Htw==
X-Gm-Message-State: AJaThX4UpXjlB41KpWTq/5pVLPt0NrJM6QLe2tNI/uDea+9F5KxZTGDF 6CQVpKBOU+5VrT2M8XSooUIbBA==
X-Google-Smtp-Source: ABhQp+RA6VvlLXa0oCXCZD+PcwNCVvJpc+pLcDdqp0tOm30J8t0aRJP5/zBcnZJ6cqWxvSMkg54gOw==
X-Received: by 10.159.244.18 with SMTP id x18mr2120887plr.338.1510189971821; Wed, 08 Nov 2017 17:12:51 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b22sm10865165pfj.123.2017.11.08.17.12.49 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 17:12:51 -0800 (PST)
To: 6man 
From: Brian E Carpenter 
Subject: FYI: draft-ietf-spring-* coming to the IESG soon
Organization: University of Auckland
Message-ID: <49ccc406-8ea9-650c-e028-d9b42a7dd133@gmail.com>
Date: Thu, 9 Nov 2017 14:12:55 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 01:12:54 -0000

Just FYI for people interested in the Source Packet Routing
topic, a whole group of draft-ietf-spring-* drafts are on
the IESG agenda for 2017-12-14.

Last chance to comment on the IPv6 aspects...

    Brian


From nobody Wed Nov  8 18:58:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CAD129ADF for ; Wed,  8 Nov 2017 18:58:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mK3XRwgUwVCc for ; Wed,  8 Nov 2017 18:58:34 -0800 (PST)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8321D129467 for <6man@ietf.org>; Wed,  8 Nov 2017 18:58:34 -0800 (PST)
Received: by mail-it0-x231.google.com with SMTP id c3so9450075itc.3 for <6man@ietf.org>; Wed, 08 Nov 2017 18:58:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mLMKWIwUrHFcKTmKNKiwljf5/2STafD2ozRAOQZspvA=; b=F4LSPEHYkv0TuJEvPnhQhm1bonUNPr+2a0mAe9qlYjywaa7E+cF2YvzdS4b8FMNd7h DbIH7hprq6Lo+9HoHbqkGOKbwEBM7C7ilIBMJH4FoHv2XxBuiqtNxSOR4Qe4xDppj9h7 kcznn5se7cFbKrj3BoNz4s9e4Jyw15HH8Z+lzJd/MJmuQkwt3pF/HtAb2X2eccp21FRS lYyotesfsHqwNYZUxDBkOqVUUETOyUT2C3wkfdmIclgkPJvX5w3vFDF2DT7YWwqPss0O k6+qMuTv5MRDSAhsOiCBpKx5CgMXD25VvZR+KZtHVYvnXK1KqWhTRQVy/Y0kxg0XhhyI 87jQ==
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=mLMKWIwUrHFcKTmKNKiwljf5/2STafD2ozRAOQZspvA=; b=icScrHkdIeaWS4HkYmgHCSQttrbH3oOFA6QwIEtzpMznSCycFE7g9yQIEjcPRo51bh HSuXVywTAKCiJWjdl9zNqdMiXcQN6J/e+XUeiMo21E9iJstdAlHH5rcNK4dZTPCaSomK YvxWCpxUICxQkQufx2IGMoRtaqgeoClJIi5VLTm5GO+Fn3oElHSf19Xw/b/nOCtl3AyZ 2KahU8S+pmk940fJ4yWmCW64Mlsh7QWJurarDLj0BcdyMIOQkjXv/P6jx2eF1D8RG30L mY2hfrPKrneE9+48Gngw6Bm47aK9ltuFb+fun/Ws5dEjTFCRK0HcHtT/GIIk3daP+q4M Vamg==
X-Gm-Message-State: AJaThX6pIuWk4cMoAqkufatVOjA+xxvnbtOvkKxZaVpxrZbM0G2h3txW sBksL7jqQS2Kor0kthjDEarMr8qvZo0m3t12QRPuU9YpIcY=
X-Google-Smtp-Source: ABhQp+TOVJ1qA/lhlyCmwjwm8qAy3XOHEhbxP2QYZWG7LgzeGN8MEIcsGJ1xD3pSLzhMhtVf12GVT26EGCiWwm3dmIo=
X-Received: by 10.36.70.76 with SMTP id j73mr3563244itb.32.1510196313447; Wed, 08 Nov 2017 18:58:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Wed, 8 Nov 2017 18:58:12 -0800 (PST)
In-Reply-To: 
References: 
From: Lorenzo Colitti 
Date: Thu, 9 Nov 2017 11:58:12 +0900
Message-ID: 
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: IPv6 Operations , "6man-ads@tools.ietf.org" <6man-ads@ietf.org>,  "v6ops-ads@ietf.org" , "6man@ietf.org" <6man@ietf.org>,  draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Type: multipart/alternative; boundary="001a1144b0eccea886055d83fa1e"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 02:58:37 -0000

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

On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont  wrote:

> While reviewing this document a few days ago, I found that Section 4
> (page 5) contains what is a protocol spec, rather than an operational
> BCP. It contains rules regarding how to set the link-layer address (to a
> unicast address) for IPv6 multicasted RAs, and how a SLAAC router should
> now remember which prefix has been "leased" to which node -- something
> that seems to be way outside of the v6ops charter, and that should have
> been done in 6man, instead.
>

I don't see how this is a protocol change. Sending RAs unicast is already
allowed by RFC 4861, so this is just an operational practice.

Looking at diffs, it seems this additional text was incorporated very
> recently, in version -09 of the I-D, published in mid September
> ( unique-ipv6-prefix-per-host-09.txt>).
> It seems to be that this change is way beyond what the authors
> originally proposed
>

The additional text did not actually change this practice at all. It simply
clarified what has always been a fundamental premise of this operational
practice: if you want to give each host its own prefix, you need to ensure
that the RA with that prefix is only received by that host.

1) The protocol spec specified in this document requires the SLAAC
> router to keep state of the "leased" prefixes -- what seems a major
> change to SLAAC, which now would be kind of as stateful as DHCPv6.
>

This is a bizarre claim. The first-hop router must always have fully
up-to-date state on all the prefixes it is sending RAs for, otherwise it
cannot fulfill its fundamental purpose of forwarding traffic to those
prefixes. The word "stateless" in SLAAC applies to addresses configured to
the host, not how routers route traffic.

2) There are scenarios in which multiple nodes might receive the same
> packet -- say a NIC let's the packet through because it is in
> promiscuous mode -- wich could possibly lead to two nodes configuring
> the same prefix.
>

Why do you say promiscuous mode is a problem? Even in promiscuous mode,
network stacks already understand which packets are being send to the host
network stack and which are not. For example, in the linux networking
stack, well before the packet ever gets to the ICMPv6 protocol handlers
that would process incoming RAs, ipv6_rcv does:

if (skb->pkt_type == PACKET_OTHERHOST) {
kfree_skb(skb);
return NET_RX_DROP;
}

3) What happens if the SLAAC router crashes and reboots, loosing state
> of the "leased" prefixes?
>

You seem to be assuming that the router does not store the prefixes in
stable storage. It's certainly the case that if you want this scheme to
work across router crashes, then you need to ensure that the prefixes are
stored somewhere. That sort of seems self-evident, but we could add it to
the text.

4) How are prefixes selected? And, what's the minimum size of the pool
> of prefixes for the selection algorithm not to break due two "prefix
> collisions"? Does the selection algorithm have any specific properties?
>

I see no reason why this should be in scope for this document.

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


On T=
ue, Nov 7, 2017 at 6:13 AM, Fernando Gont <fgont@si6networks.com&g=
t; wrote:
While=
 reviewing this document a few days ago, I found that Section 4

(page 5) contains what is a protocol spec, rather than an operational

BCP. It contains rules regarding how to set the link-layer address (to a
unicast address) for IPv6 multicasted RAs, and how a SLAAC router should
now remember which prefix has been "leased" to which node -- some=
thing

that seems to be way outside of the v6ops charter, and that should have

been done in 6man, instead.

I don't=
 see how this is a protocol change. Sending RAs unicast is already allowed =
by RFC 4861, so this is just an operational practice.

<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
Looking at diffs, it seems this additional text was incorporated very

recently, in version -09 of the I-D, published in mid September

(<https:=
//tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-unique-ipv6-pref=
ix-per-host-09.txt>).

It seems to be that this change is way beyond what the authors

originally proposed

The additional text=
 did not actually change this practice at all. It simply clarified what has=
 always been a fundamental premise of this operational practice: if you wan=
t to give each host its own prefix, you need to ensure that the RA with tha=
t prefix is only received by that host.

1) The protocol spec specified in this d=
ocument requires the SLAAC

router to keep state of the "leased" prefixes -- what seems a maj=
or

change to SLAAC, which now would be kind of as stateful as DHCPv6.

This is a bizarre claim. The first-hop router m=
ust always have fully up-to-date state on all the prefixes it is sending RA=
s for, otherwise it cannot fulfill its fundamental purpose of forwarding tr=
affic to those prefixes. The word "stateless" in SLAAC applies to=
 addresses configured to the host, not how routers route traffic.


2) There are scenarios in which multiple nodes might receive the same

packet -- say a NIC let's the packet through because it is in

promiscuous mode -- wich could possibly lead to two nodes configuring

the same prefix.

Why do you say promisc=
uous mode is a problem? Even in promiscuous mode, network stacks already un=
derstand which packets are being send to the host network stack and which a=
re not. For example, in the linux networking stack, well before the packet =
ever gets to the ICMPv6 protocol handlers that would process incoming RAs, =
ipv6_rcv does:

	if (skb->pkt_type =3D=3D PACKET_OTHERHOST) {
		kfree_skb(skb);
		return NET_RX_DROP;
	}


3) What happens if the SLAAC router crashes and reboots, loosing state

of the "leased" prefixes?

You=
 seem to be assuming that the router does not store the prefixes in stable =
storage. It's certainly the case that if you want this scheme to work a=
cross router crashes, then you need to ensure that the prefixes are stored =
somewhere. That sort of seems self-evident, but we could add it to the text=
.

4) =
How are prefixes selected? And, what's the minimum size of the pool

of prefixes for the selection algorithm not to break due two "prefix
collisions"? Does the selection algorithm have any specific properties=
?

I see no reason why this should be in=
 scope for this document.


--001a1144b0eccea886055d83fa1e--


From nobody Wed Nov  8 19:03:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B54120713 for ; Wed,  8 Nov 2017 19:03:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Tn7rhkgInbmR for ; Wed,  8 Nov 2017 19:03:10 -0800 (PST)
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 2159E129ADF for <6man@ietf.org>; Wed,  8 Nov 2017 19:03:08 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id k11so4165506ywh.1 for <6man@ietf.org>; Wed, 08 Nov 2017 19:03:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=useyj2CvFFl8IGlZeA5IB7KegqoYokkv2mJT9H6CNJM=; b=JRsSkgeZeOaBytDGyWdzFx8r1ErVZ0/IsMzHvbcAzG/r3mPje8Ex1vSJmI4crk4An2 m6PgLhxyfk5c2IJZaXJ9bLem51ThXxnOGhlJeqMdG5U201lsQwYhVuMN8XAxDafVQc99 YvaIvHMzypuA6u4+RgdDtlYVmDiAgqc6daaVOpvlUl0BWyI4tiji9wxlFdiT7bJ4t/zs 6XByyuPzyi2c8XL0+IcAs2hjwjE4Trlm4rLTZsRDklQrqJz2vNPjV2K81jaHyepw9cPA 7vgupmV4q8ndhXz4G/iiIXBhqdJ9JCOWspIYIkYu4og38ohKhH+eg4y0W2kSYH+Z+vZc eUBQ==
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=useyj2CvFFl8IGlZeA5IB7KegqoYokkv2mJT9H6CNJM=; b=qK05pR+80mZ/7Czx7Rd66LsMASzqh12PR+rw1m4sLWFRidL/eqW/kXFrh2Kj5Vlq0W y1hRUxuYOA0nZouLuhM5JhO0gCZ6jyQpnXx+4Esm0t/dq3DFHGC8TKza1SUSQuhAckKe tLJfFwjGtC1leK1GXDIoOsNOXonBdmZNUZznfPFIZJBddhfrz96Yo1jWQRqMKMnL9dqC Hoindno3IX/5TqsKASoQIAM9aC75vkM+Rb8/KVEi2bKMPcCHrJInqIZp67+4g1b9sWKI X1RrSheGvFTi9hb6G83o2dacKyt4brWDxGGg/jvqWh3ha5MQft0Rce9eYqPL04NhK4KE Qz1w==
X-Gm-Message-State: AJaThX6StZ+Q36Ok6+/MSa7KvnX98SwiJj4lBpQN8XgaQmZayg+J7ldj 8Zm5/evgzUZU7BQUHWviwBdW+QOpMShBgT4PWWrD+g==
X-Google-Smtp-Source: ABhQp+RoWRRchLZY7WtN+hnjynx2Q0EtrSkXUp08zdCyu2HosNasrdSGEgzynq0YExnCJmKtJF7AIZMMM0oJU/jb+qg=
X-Received: by 10.129.89.133 with SMTP id n127mr1824307ywb.68.1510196587031; Wed, 08 Nov 2017 19:03:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.130.80 with HTTP; Wed, 8 Nov 2017 19:02:46 -0800 (PST)
In-Reply-To: 
References: 
From: Erik Kline 
Date: Thu, 9 Nov 2017 12:02:46 +0900
Message-ID: 
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: IPv6 Operations , "6man-ads@tools.ietf.org" <6man-ads@ietf.org>,  "v6ops-ads@ietf.org" , "6man@ietf.org" <6man@ietf.org>,  draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1149152c250c80055d840b41"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 03:03:12 -0000

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

I don't think we should be recommending unique RAs per device where
the devices are all on a shared link.

My understanding was that in the original motivating wifi deployment
every node is effectively isolated in its own (pseudo)VLAN, and
node-to-node traffic must be routed through the infrastructure (to the
extent such a thing can actually be enforced in a medium like wifi).

--001a1149152c250c80055d840b41
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgDi861mD0Aw9NVS3dC3SjSI4ePVi/rSXI
jf2tmBmaTDwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTA5
MDMwMzA3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAJuGc6lqT/1hdpSh9t52V4sXwMctIwcaOxGFn10BO4CD7ak15Rsz
HUh+W5z/Q7ZZ2vyGGV9erqkyR0Q8kyyMOsOIuvaWBTlGb1FFg5wSbYji9jjWvAped6x4yHgJy3CE
G/4b5wpV6JyOHmGDueiMwuBFV6QPVNMhfCUVePBJTPBsXWBD4g38PzxW4kewQB3aLm8pK9K+NxUp
s3XPHbz410GP3plARuj54qsZqm8DKntHYbTnO22WFxH/KPrqokdbYT3Sqod0Lu+0CL+MG993gRNy
/UzJDsq6Xkdpr100bXMfo3W5QIUsV1xE8IQyH6pYafGWVqmHA46OCXbLP2gbhH4=
--001a1149152c250c80055d840b41--


From nobody Wed Nov  8 19:53:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407B5129B41 for ; Wed,  8 Nov 2017 19:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGsxD2AqNtsD for ; Wed,  8 Nov 2017 19:53:21 -0800 (PST)
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 56942128B27 for ; Wed,  8 Nov 2017 19:53:21 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id e64so3350707pfk.9 for ; Wed, 08 Nov 2017 19:53:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6hFhrE7olvweU9EnHws/foLHbNIV+ENl3TuOYj7Nkx4=; b=XaUvfL6mre4NldNFTeQNWhI5CLbq8BpvXLmmpeki+wxH+sH7xP1npINyQN9PrzK/Gh KyN05iQd39Iov+gbpNJJA5CFdraarV6Yx5EjCCMrO49zVPGDXbgH0R1UeKNFVEmYXau4 4BNTMPWJWfMvXeY6+NeTFk0HF6EoMbEDl0UuEzxwwwxX2V34T+KDb4DYHTk4iV4zV11T cblnf+9bwq8/NXOC/sCejlxujAzhAv8Owo/OdAWPGCx4PaP7TA//RePOV0NeOXZT3Ax1 pqkSTbKK95g/cKuRZrpu3rfSWcjXWFY4W4skgrwEaF/PCFwsOUcvI0oiVI0xQ8U128wZ HpVA==
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=6hFhrE7olvweU9EnHws/foLHbNIV+ENl3TuOYj7Nkx4=; b=Ps007zSkvxhWAtT1tDwLxpdTa2x2ObxtYCbVlzzScIuBzRIgyYy/+56G5EjlTFVIDB 7fA9h1uTqJhMdr/7aztvLoztY4VB13GITQAYLso4ktTvp8OY9rvNBoTajW2xuvMAA6/q O8pirHV/WDkYg7yHOym+uHQwpOv3iix65hiiIEGgUTNmJpbIstRuRgtSgHGsuIT5bF63 LEoMS38RnPx/5v2r+y2DanUrFgv9mAPT12+ntexIZWfzpULqntV+88ljl5Nmm9uQHM09 THuPSjLfXT1yFhZ9wXdOppnflK7uNpzNK4soK3c5UGvxBvBJrPUSkwdWvRBg9UwdXxQ9 YwdQ==
X-Gm-Message-State: AJaThX4e3GMfR69cfZ4QClj7O6eKlZ1Sr7GWDNfGbHAb78szW6JlRX8C RkhI5bcBhljOMUa0tDFzDERlOg==
X-Google-Smtp-Source: ABhQp+RVZ2M/TfeMlLOaREbTj0FAUuJIVk9/B87G9fsKszuoN+oc43oFyiZH8NNHET4HQ7gCcWDgvQ==
X-Received: by 10.84.197.131 with SMTP id n3mr2506917pld.227.1510199600589; Wed, 08 Nov 2017 19:53:20 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 66sm8512066pgh.31.2017.11.08.19.53.18 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 19:53:19 -0800 (PST)
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: ipv6@ietf.org
References:  
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <9e1368ec-d2f0-f508-3928-522a43d8f6e0@gmail.com>
Date: Thu, 9 Nov 2017 16:53:23 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 03:53:23 -0000

On 09/11/2017 16:02, Erik Kline wrote:
> I don't think we should be recommending unique RAs per device where
> the devices are all on a shared link.

Why not? Where's the harm? As pointed out at
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13#page-5
it's permissible under RFC 4861. This is not an innovation.
 
> My understanding was that in the original motivating wifi deployment
> every node is effectively isolated in its own (pseudo)VLAN, and
> node-to-node traffic must be routed through the infrastructure (to the
> extent such a thing can actually be enforced in a medium like wifi).

It can also be enforced on a switched LAN if the switch does the requisite
peeking. We may not be happy at such layer violations, but it seems
to me that the days of true broadcast LANs are numbered and a lot of
these things will need to be rethought in the coming years.

Just a reminder, this draft was approved by the IESG a while ago
and is in state "RFC Ed Queue : AUTH48 for 23 days". This unique
unicast has been in there for a long time, although the phrasing
was clarified in the last couple of months, which is what WG
and IETF Last Calls are for.

   Brian


From nobody Wed Nov  8 21:14:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E53D120726 for ; Wed,  8 Nov 2017 21:14:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tfxlFC5NZMJM for ; Wed,  8 Nov 2017 21:14:44 -0800 (PST)
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 9017812711D for ; Wed,  8 Nov 2017 21:14:44 -0800 (PST)
Received: by mail-yw0-x232.google.com with SMTP id y75so4342005ywg.0 for ; Wed, 08 Nov 2017 21:14:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UIZHJfNl3l1JPjxB63yuvgyNNbgJidD1h4jtqauF2DQ=; b=XPR29A9hcIbm8QOUr8KWzyFUQlGVNOPjsvAxwkA02oEVpkwCceWH7nyGPZlPALyByw 1O2U0HizKqylA0/vTPsxTn6MMxX7tdn/VifpYG2R120ZuCac8M5nDNpbV+sb7xmvhN0R t5MgBpDyccZY4/RZ5NywCwgq5WEjakQ9lRYN9NV3x4rQUxT8pELfMgLRhfJP99Unyqfz wE1SmZnK6vuk5HKsDdIuipg4oh+PBWsd/zoIIa1nW0rxLjxWaBrfn1/0jTzMp+VnwlgT SUhG+DzXLb9yf2rmjqE+613PznjUzlCDbOswAbVOe3leUaYxU6TDIbgWTpSRAU2HDDWi j4IQ==
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=UIZHJfNl3l1JPjxB63yuvgyNNbgJidD1h4jtqauF2DQ=; b=MbJcWvX53Mn6zIdUFaCBhm4O9yXQlf6uux91k0A1RF6HXhmqIG6lF6wDWiBUdR9dF7 tgoUi6mkzhRsHnYPxS3JwfrIDAA+o2PwTMsjSVhRyi4fKV0gNxHrlnBP0aLvREiz56F0 gVbbYFhqkCVNyl/NmIXQTOr6Jnn3SoVJF5xlEp86YpLlkcGuMvvnT+2m6jS8W+JZWQmD 1tjFtx0fDyFvEtXhM5kUhd0yvwK8vNwIrKgDZbDl7dqrkR5JV2D/0/4tnS3j/OLtIxfg oFGxvU0Gvv17KHlhXSZkxWfGAfhsUHfTZGt294vH6SYmqOApzeTssZN7WIxAxz/DHtML m5dg==
X-Gm-Message-State: AJaThX5H8N8ZXCAQEV6PUhAzRjLBz6/JnkESD5Ew0bl3WBOtkyGsKlHc MKEie7psuILdeBUS5+q9PwWuMMF9WUdUxPwZH02FYA==
X-Google-Smtp-Source: ABhQp+Sp5TlzDkoyyoARr16DolBe5al5ZzlsTs/1iGOK3K2VNeC7yJzB4+se6q4Q1ejpiAzyiKjz2ITMTUspvAFeJig=
X-Received: by 10.37.186.203 with SMTP id a11mr1747991ybk.460.1510204483200; Wed, 08 Nov 2017 21:14:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.130.80 with HTTP; Wed, 8 Nov 2017 21:14:22 -0800 (PST)
In-Reply-To: <9e1368ec-d2f0-f508-3928-522a43d8f6e0@gmail.com>
References:   <9e1368ec-d2f0-f508-3928-522a43d8f6e0@gmail.com>
From: Erik Kline 
Date: Thu, 9 Nov 2017 14:14:22 +0900
Message-ID: 
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Brian E Carpenter 
Cc: IETF IPv6 Mailing List 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403043deec8cb73b8055d85e119"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 05:14:46 -0000

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

On 9 November 2017 at 12:53, Brian E Carpenter
 wrote:
> On 09/11/2017 16:02, Erik Kline wrote:
>> I don't think we should be recommending unique RAs per device where
>> the devices are all on a shared link.
>
> Why not? Where's the harm? As pointed out at
> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13#page-5
> it's permissible under RFC 4861. This is not an innovation.
>
>> My understanding was that in the original motivating wifi deployment
>> every node is effectively isolated in its own (pseudo)VLAN, and
>> node-to-node traffic must be routed through the infrastructure (to the
>> extent such a thing can actually be enforced in a medium like wifi).
>
> It can also be enforced on a switched LAN if the switch does the requisite
> peeking. We may not be happy at such layer violations, but it seems
> to me that the days of true broadcast LANs are numbered and a lot of
> these things will need to be rethought in the coming years.
>
> Just a reminder, this draft was approved by the IESG a while ago
> and is in state "RFC Ed Queue : AUTH48 for 23 days". This unique
> unicast has been in there for a long time, although the phrasing
> was clarified in the last couple of months, which is what WG
> and IETF Last Calls are for.
>
>    Brian

I understand.  If implemented correctly, it will of course work.

But I think the probably of configuration errors will in practice go
way up if the medium is shared, rather than isolated.  That's all I
really meant to say.

Thanks for helping me clarify.

--f403043deec8cb73b8055d85e119
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgP5V3jc+IE7eQtSpNpvp4228B09uiSQjG
3X7sN035yLowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTA5
MDUxNDQzWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAH/OFHiLlcLllKi4s741+QnoQf33bdc5shRKlH/pcBJTr9b2jWRO
fBHnsPW2eHJW9hOtdd0GXydQM9Zz/3/r5BV2DtY4TsHB6bqvYKQuDDo9V+5TC3QWnGWd7jZ9hiW2
Q7YQn/FSmwNorPTwF9gvU6pCiMMYc62TKupZfrH//03ACAjgqQ0kpfOoizPX2/InQa7e8ccqR+uM
wkTgihioa+6Gfo9i5X7UNruzA4HPFw46z6+kII0VU06i9Xyx2MQ4uPPVj1hnevb+7tf0iztF/w5W
Htg1JrC2Sjs0jXOiWCR8pSqPP19Kg5CV0gX4dISzE9eVWT0cmeKSLRCD3Et9Trs=
--f403043deec8cb73b8055d85e119--


From nobody Wed Nov  8 22:55:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F40412EC08 for ; Wed,  8 Nov 2017 22:55:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Xz2KeTItYoVq for ; Wed,  8 Nov 2017 22:55:41 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3402212EC07 for ; Wed,  8 Nov 2017 22:55:41 -0800 (PST)
Received: by mail-wm0-x234.google.com with SMTP id p75so14834818wmg.3 for ; Wed, 08 Nov 2017 22:55:41 -0800 (PST)
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=31xzCFodTtGdHYrIUaCOFzSzxaBncgpuYrk+xsGUNpU=; b=j2InxRbRB+9E6Pay0F3zsqI6A6FfDJJtooVH6NyWAqE0oSBm8d4kbrixmZmwx6I4Tg vhi5xq75jQv7QKjNMImeetIF1N1NwKbZ2pkQFk1b0+4WCGXWrzMazRuBbBasrsluD2GC NCbc3rp+r3mGwbzFbqlM/vb8/MTRqExA9lveCaXci7WRxReEKpfT5nMH6nQjmPyTGXik nFKAaK6MTye25vT4aZgJMkugLryoPkJX9eNaf7oqUYGupAb/ygxf9BVe5u3Umd+hEVpI hRe0sqHg5TdSYWghsbvDEMVk8MklniC13IdvfUbeSosP3H3Fnay2FmFYKA6d4yifO0Xi ALDw==
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=31xzCFodTtGdHYrIUaCOFzSzxaBncgpuYrk+xsGUNpU=; b=DiGSQrLgoyOEBYpoaTdhhOA1PyOFdwnMLpDYjUDs9To2Eca0pqG0KPGrP6hUrtUkE8 dL01jRAWwWv9EpKmcFnPoTzYIVOoeLH7hF+dnCGNH8VhSdQa/4hftYFvvGq3YSEMbeiX 19BVcdU3An4lx68Z63abNJcmfrzgvc8s2ABM28fdzMUL/8eK/viOf+e2/w5I7d5Rc1x9 NZcGcufWWsZXGrm9mJ0gh861HLpVuGenYsE1lTufSK7TN163UqnqroHr/Okihh3DEZxt Yo22OXWGfsr9kb3DmBcqzoI/ZcHWhn4LGDa1BuxLy021GHpovTGCQ7tpjD1MydEYSrXL yPzQ==
X-Gm-Message-State: AJaThX4vJk9JAbjrqwrSpeRcfzgr1R9HsVSjpyD3bKiDiYYVTVT9jArF L97Gps7ykTHuWvDCCQ8AqEsvIZazF953lWdoIDlnZg==
X-Google-Smtp-Source: ABhQp+SANt7TqXtKiZbwciZhxk7JQXWtarBTENXeZ2K3lWzrWL05EmeeMvM1MSmN/okQ5Jp8VQ4uZR3GRV5DuwMUj6M=
X-Received: by 10.28.26.138 with SMTP id a132mr2287107wma.124.1510210539357; Wed, 08 Nov 2017 22:55:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.160.149 with HTTP; Wed, 8 Nov 2017 22:54:58 -0800 (PST)
In-Reply-To: <9e1368ec-d2f0-f508-3928-522a43d8f6e0@gmail.com>
References:   <9e1368ec-d2f0-f508-3928-522a43d8f6e0@gmail.com>
From: Warren Kumari 
Date: Thu, 9 Nov 2017 14:54:58 +0800
Message-ID: 
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Brian E Carpenter 
Cc: ipv6@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 06:55:43 -0000

On Thu, Nov 9, 2017 at 11:53 AM, Brian E Carpenter
 wrote:
> On 09/11/2017 16:02, Erik Kline wrote:
>> I don't think we should be recommending unique RAs per device where
>> the devices are all on a shared link.
>
> Why not? Where's the harm? As pointed out at
> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13#page-5
> it's permissible under RFC 4861. This is not an innovation.
>
>> My understanding was that in the original motivating wifi deployment
>> every node is effectively isolated in its own (pseudo)VLAN, and
>> node-to-node traffic must be routed through the infrastructure (to the
>> extent such a thing can actually be enforced in a medium like wifi).
>
> It can also be enforced on a switched LAN if the switch does the requisite
> peeking. We may not be happy at such layer violations, but it seems
> to me that the days of true broadcast LANs are numbered and a lot of
> these things will need to be rethought in the coming years.
>
> Just a reminder, this draft was approved by the IESG a while ago
> and is in state "RFC Ed Queue : AUTH48 for 23 days". This unique
> unicast has been in there for a long time, although the phrasing
> was clarified in the last couple of months, which is what WG
> and IETF Last Calls are for.
>

... and in the interest of transparency -- the document was all
approved on Nov 6th; on Nov 7th Fernando sent the above mail (and also
separate mail to myself, saying that this was violating v6ops charter
and needed to have been done in 6MAN).

As soon as I saw this mail I asked the RFC Editor to hold publication
(if not too late) so I could talk to Suresh about this. The RFC Editor
has removed my approval (for now). I CCed Suresh, but as I'm already
in Singapore (and have been somewhat busy with NOC stuff) we haven't
had much time to chat (other than that we don't think it is a protocol
change, and was fine in V6OPS).

I'm planning on chatting with Suresh when he arrives (just to double
check), but I think that will be fine.
W

>    Brian
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



-- 
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 Thu Nov  9 06:37:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3A4128B51 for ; Thu,  9 Nov 2017 06:37:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBGSgHiYAjF7 for ; Thu,  9 Nov 2017 06:37:26 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32BB124319 for ; Thu,  9 Nov 2017 06:37:26 -0800 (PST)
Received: from h.hanazo.no (unknown [57.190.1.10]) (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 3C9E92D5003 for ; Thu,  9 Nov 2017 14:37:23 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 1542B200B2B748 for ; Thu,  9 Nov 2017 15:36:52 +0100 (CET)
From: Ole Troan 
Content-Type: multipart/signed; boundary="Apple-Mail=_DD055D82-BD61-438D-B57D-1F6FE9AD08E6"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Subject: Slides for 6MAN WG
Message-Id: <6854C55A-4B53-4725-A7EC-2C5C0F95031E@employees.org>
Date: Thu, 9 Nov 2017 15:36:51 +0100
To: 6man WG 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 14:37:28 -0000

--Apple-Mail=_DD055D82-BD61-438D-B57D-1F6FE9AD08E6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Presenters,

6man is meeting Tuesday at 1330. It would be greatly appreciated if you =
can get the slides to the chairs by Monday midnight.
We are also in need for a jabber scribe and minute takers. It's useful =
work to do, makes you pay attention instead of reading email.
(And with regards to that, we are in talks with the NOC to run an IPv6 =
only wireless (or IPv6 + NAT64) experiment in the room this time).

Best regards,
Ole


--Apple-Mail=_DD055D82-BD61-438D-B57D-1F6FE9AD08E6
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+/bDNdvtpYqJhC33YFAloEaAMACgkQvtpYqJhC
33ab7xAAhk7dpLwmTUygDeCTDeVTyHGRHklLLcn9uK/PZnlmGDxJLl0vfvCmiKJd
sHbxXEtNQNrwJOh+9M04CkLHViJY2xbY2ww0vIzFBQULtYRtj30gEWg1D4fjkbWf
lUNxBOKLZ1gokyxaQ+F2wVzqLTO0SZSVTXBIGJEQy8zra+IuTBV6ly6VU/t40jDj
fKrqxqZck3wMmqnFc0H//d1kbtmf6w+9bsqO+juDvoZg0DCAsMxG5nXCMWs1IKIy
2tpH34YZymsNteMFV3Q4CD7QdbRL38aiG5FodH9wAwMpFY10JsAv2ErgAOPRshiR
ikeGBr/Dwm9Jgx5ku6LLp/vYCux6w5oBLJLKHkesp8ACMG+p0uPUHoOBX63vu1+3
xo16ma04ZZ5PakS/7+Ewg/CTJ+qnow3IF5ZOLCvaSWt9SgK2qq5QyR58IkQ/Z8Ah
PD6FQT4PqfaEJUOcey4RJ/PMN0i9IbB+PnpVfCZ5RLgY2YBLvwJVi6j3tJBYps1Y
f6K2xV1fMXBEsibMdRsmnjARcEKwG14+nhOZdCFnYau04AlPJJddn+ddKTsck8Rg
6CBSIAAMa1QgSH2MhTtiDY0xGb1ia1guI1Mb/bNgzIdfAAnGevur97+GMv0B87W8
TS8rtUIGLqABCnvR/7UnCis266dXMkxEjZl1rJNASkF1ADymUOg=
=+bYS
-----END PGP SIGNATURE-----

--Apple-Mail=_DD055D82-BD61-438D-B57D-1F6FE9AD08E6--


From nobody Thu Nov  9 09:34:56 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D74C126DCA; Thu,  9 Nov 2017 09:34:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level: 
X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu8p35qpA8jP; Thu,  9 Nov 2017 09:34:52 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C7CE1243F6; Thu,  9 Nov 2017 09:34:52 -0800 (PST)
Received: from [192.168.3.83] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A59B6801CA; Thu,  9 Nov 2017 18:34:43 +0100 (CET)
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Erik Kline 
Cc: IPv6 Operations , "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , "6man@ietf.org" <6man@ietf.org>, draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References:  
From: Fernando Gont 
Message-ID: <65664ca5-b8fe-0ca0-82fc-99e120426aea@si6networks.com>
Date: Thu, 9 Nov 2017 05:05:23 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 17:34:54 -0000

On 11/09/2017 12:02 AM, Erik Kline wrote:
> I don't think we should be recommending unique RAs per device where
> the devices are all on a shared link.

Agreed.

And if we were to do it, we should be recommending this in a 6man
document, not v6ops.



> My understanding was that in the original motivating wifi deployment
> every node is effectively isolated in its own (pseudo)VLAN, and
> node-to-node traffic must be routed through the infrastructure (to the
> extent such a thing can actually be enforced in a medium like wifi).

Describing the virtues of one prefix per node, or how isolating nodes
(no "on link prefix") or the like are all fine for an informational
document, or even as a BCP (if that's how the wg feels).

Specifying hacks to SLAAC which require modification to the SLAAC router
code (you certainly need to hack e.g. radvd quite a lot to implement
this) or add additional requirements to SLAAC (like the requirement of a
data structure that contains mappings of Prefix_leased -> MAC_address)
is std track work that should be done in 6man, and with a document
flagged as "std track", not bcp.

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





From nobody Thu Nov  9 09:47:20 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA521276AF; Thu,  9 Nov 2017 09:47:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmhqdWy9pBzs; Thu,  9 Nov 2017 09:47:10 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D54D5124239; Thu,  9 Nov 2017 09:47:09 -0800 (PST)
Received: from [192.168.3.83] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id DC05F8062B; Thu,  9 Nov 2017 18:47:04 +0100 (CET)
From: Fernando Gont 
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Lorenzo Colitti 
Cc: IPv6 Operations , "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , "6man@ietf.org" <6man@ietf.org>, draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References:  
Message-ID: <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com>
Date: Thu, 9 Nov 2017 14:48:55 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 17:47:12 -0000

On 11/08/2017 11:58 PM, Lorenzo Colitti wrote:
> On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont  > wrote:
> 
>     While reviewing this document a few days ago, I found that Section 4
>     (page 5) contains what is a protocol spec, rather than an operational
>     BCP. It contains rules regarding how to set the link-layer address (to a
>     unicast address) for IPv6 multicasted RAs, and how a SLAAC router should
>     now remember which prefix has been "leased" to which node -- something
>     that seems to be way outside of the v6ops charter, and that should have
>     been done in 6man, instead.
> 
> 
> I don't see how this is a protocol change. Sending RAs unicast is
> already allowed by RFC 4861, so this is just an operational practice.

That's incorrect. We are talking about sending multicasted internetlayer
packets to a unicast link-layer address. There's nothing in RFC4861 that
suggests you should do that. RFC6085 says "you shouldn't drop packets if
they are internet-layer multicast but link-layer unicast". But
certainly, unless a protocol spec says otherwise, the normal mapping
applies.

There's nothing in RFC4862 that may suggest "leasing one prefix per
node". In fact, all nodes share all the prefixes being announced. And
when you don't want multiple nodes to share them, you just segment the
network one way or another. From the point of view of SLAAC, there's no
"one prefix per node". If it happens, it's because you segmented the
network, not because SLAAC is meant for that.



>     Looking at diffs, it seems this additional text was incorporated very
>     recently, in version -09 of the I-D, published in mid September
>     (     >).
>     It seems to be that this change is way beyond what the authors
>     originally proposed
> 
> The additional text did not actually change this practice at all.> It
> simply clarified what has always been a fundamental premise of this
> operational practice: if you want to give each host its own prefix, you
> need to ensure that the RA with that prefix is only received by that host.

If you want to give each host it's own prefix, you do prefix delegation.
So far, SLAAC doesn't do prefix delegation. If you want to do prefix
delegation in slaac, write a std track document in 6man, not a BCP in
v6ops.



>     1) The protocol spec specified in this document requires the SLAAC
>     router to keep state of the "leased" prefixes -- what seems a major
>     change to SLAAC, which now would be kind of as stateful as DHCPv6.
> 
> This is a bizarre claim. The first-hop router must always have fully
> up-to-date state on all the prefixes it is sending RAs for, otherwise it
> cannot fulfill its fundamental purpose of forwarding traffic to those
> prefixes. The word "stateless" in SLAAC applies to addresses configured
> to the host, not how routers route traffic.

A SLAAC router need not maintain any sort of dynamic mapping. It's
static configuration information of the sort "I'm announcing this prefix
on this interface".. If you think otherwise, please point me the section
in RFC4862 where this conceptual data structure is mentioned. (Note:
Neighbor Cache, Destination Cache, etc. are all mentioned in RFC4861).



>     2) There are scenarios in which multiple nodes might receive the same
>     packet -- say a NIC let's the packet through because it is in
>     promiscuous mode -- wich could possibly lead to two nodes configuring
>     the same prefix.
> 
> Why do you say promiscuous mode is a problem? Even in promiscuous mode,
> network stacks already understand which packets are being send to the
> host network stack and which are not. For example, in the linux
> networking stack, well before the packet ever gets to the ICMPv6
> protocol handlers that would process incoming RAs, ipv6_rcv does:
> 
> if (skb->pkt_type == PACKET_OTHERHOST) {
> kfree_skb(skb);
> return NET_RX_DROP;
> }

Great that Linux double-checks this. But it need not. Linux is just one
implementation. A very popular one. But one implementation.




>     3) What happens if the SLAAC router crashes and reboots, loosing state
>     of the "leased" prefixes?
> 
> You seem to be assuming that the router does not store the prefixes in
> stable storage.

Routers store configuration info, not dynamic mappings.

Simple scenario:

With slaac, the network is 100% resilient if a rotuer crashes and
reboots (because, as the name implies, it is stateless). With this
protocol you are specifying in this document, if the router crashes and
reboots, the network may just break -- same prefix may be reassigned to
different nodes, etc.



> It's certainly the case that if you want this scheme to
> work across router crashes, then you need to ensure that the prefixes
> are stored somewhere. That sort of seems self-evident, but we could add
> it to the text.

SLAAC stores *configuration information*. This protocol that you are
specifying requires SLAAC to store the *dynamic mappings* of which
prefix was "leased" to which host. And the fact that you need this for
this mechanism to work is an indication that you are specifying a
protocol. (Call it Stateful SLAAC, or AAC ;-) )

An operational practice is when you fiddle with the knobs that a
protocol gives you. Here you are introducing a state machine into SLAAC.
That's certainly not an operational practice, but rather a fundamental
change to SLAAC that makes it a stateful protocol



>     4) How are prefixes selected? And, what's the minimum size of the pool
>     of prefixes for the selection algorithm not to break due two "prefix
>     collisions"? Does the selection algorithm have any specific properties?
> 
> I see no reason why this should be in scope for this document.

Actually, what's not in the scope of this document, and not within v6ops
charter, is the protocol you are specifying to handle prefixes with SLAAC.

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





From nobody Thu Nov  9 10:19:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023F2129426; Thu,  9 Nov 2017 10:19:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e_AC39ctLfK; Thu,  9 Nov 2017 10:19:44 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE19F129404; Thu,  9 Nov 2017 10:19:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vA9IJhlx010208; Thu, 9 Nov 2017 11:19:43 -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 vA9IJYHv010120 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 9 Nov 2017 11:19:34 -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, 9 Nov 2017 10:19:33 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Thu, 9 Nov 2017 10:19:33 -0800
From: "Templin, Fred L" 
To: Fernando Gont , Lorenzo Colitti 
CC: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" 
Subject: RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Topic: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Index: AQHTWYLPF0lutU7PtESjw8Zn8vPUPqMMWk3Q
Date: Thu, 9 Nov 2017 18:19:33 +0000
Message-ID: <8efc982b0c784a6eac359d1ae9e50201@XCH15-06-08.nw.nos.boeing.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com>
In-Reply-To: <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 18:19:46 -0000

> > I don't see how this is a protocol change. Sending RAs unicast is
> > already allowed by RFC 4861, so this is just an operational practice.
>=20
> That's incorrect. We are talking about sending multicasted internetlayer
> packets to a unicast link-layer address. There's nothing in RFC4861 that
> suggests you should do that. RFC6085 says "you shouldn't drop packets if
> they are internet-layer multicast but link-layer unicast". But
> certainly, unless a protocol spec says otherwise, the normal mapping
> applies.

On this point, I agree with Fernando. RFC4861 says that RAs can be unicast =
but
that means unicast at both L2 and L3 (i.e., and not multicasted at L3). RFC=
5214
is an example of where both L2/L3 unicast are used in RAs in the spirit of =
RFC4861 .

Is there some reason why the requirements of this draft cannot be satisfied
by L3 unicast?

Thanks - Fred


From nobody Thu Nov  9 10:23:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE25F12949E for ; Thu,  9 Nov 2017 10:23:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 Lx-K-taiLa_4 for ; Thu,  9 Nov 2017 10:23:14 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B142129451 for ; Thu,  9 Nov 2017 10:22:49 -0800 (PST)
Received: from [192.168.3.83] (unknown [181.165.119.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 07B24826E6; Thu,  9 Nov 2017 19:22:45 +0100 (CET)
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Warren Kumari , Brian E Carpenter 
Cc: ipv6@ietf.org
References:   <9e1368ec-d2f0-f508-3928-522a43d8f6e0@gmail.com> 
From: Fernando Gont 
Message-ID: <51146afe-6756-35cf-c995-7217b9cabf3e@si6networks.com>
Date: Thu, 9 Nov 2017 15:24:31 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 18:23:16 -0000

On 11/09/2017 03:54 AM, Warren Kumari wrote:
>>
>> Just a reminder, this draft was approved by the IESG a while ago
>> and is in state "RFC Ed Queue : AUTH48 for 23 days". This unique
>> unicast has been in there for a long time, although the phrasing
>> was clarified in the last couple of months, which is what WG
>> and IETF Last Calls are for.
>>
> 
> ... and in the interest of transparency -- the document was all
> approved on Nov 6th; on Nov 7th Fernando sent the above mail (and also
> separate mail to myself, saying that this was violating v6ops charter
> and needed to have been done in 6MAN).

FWIW, and as noted in my original email, I got to re-read this document
as a result of the recent thread "Security: Unique IPv6 Prefix per Host"
on v6ops (the Subject caught my eyes).

Based on the discussion in v6ops, I decided to re-read the document in
question. And when I did, Oct 31, I asked the group if this wasn't a
protocol spec
().
There was no response on-list.


I tried to track when the text on Section 4 was added, and it seems to
have happened on Sept 14
(),
way after IETF Last Call, and apparently also after some IESG members
have balloted on this document.

Certainly I wished that my timing would have been better.. but it looks
like even if I had reviewed this document during the IETF LC, I wouldn't
have caught this, since the change was applied *after* IETF LC. It even
seems to have been applied after Suresh cleared his DISCUSS.

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





From nobody Thu Nov  9 12:36:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E738129B62; Thu,  9 Nov 2017 12:36:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htQDGSK1wuu8; Thu,  9 Nov 2017 12:36:31 -0800 (PST)
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 9D83E129B69; Thu,  9 Nov 2017 12:36:11 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id s11so176153pgc.5; Thu, 09 Nov 2017 12:36:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KrSe0ZkK2EpvcqtTfpyN4pCdGEcuTdMFLNjd2YWa5c8=; b=KTBBVp1N3UT2UpK2A46FLqpJJopXBhR0gJCHpJoOGdci1WLJ/nWCWoFucXmvrPZaqm kFf0kJ1298PYsBOk+OQbZs2IyaGt0tU1hc6A3SQ7Ia/KpDUxashrXLeTX+k0M9VwYmTL 3KF1eWUtPOr0FGUAtA6bgN6mFInKYUVcnLFBMSMIDe/oVj80ji79j/S52rvGUxWa7Hmj sKbrBM6hVYpMBtjTJO8+4Iqad7XRkhqeLCapVk+pGWPpJybh2hEYvVf12Ii2hfbAwX1f bJod9aH5lWCUiBfkFcMUgww1w05dcsOrr8io3rMti/aKMlIlUYp1L9CY1VGQ8dCPGOZ0 XkjA==
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=KrSe0ZkK2EpvcqtTfpyN4pCdGEcuTdMFLNjd2YWa5c8=; b=Ljf085xQntpwDbe3lexYRwKIrYJss7X7916/eg0meKrL371Iigr+raYc/EFgRkdcCL QL3xS7A8Ks1i+bgayn+2Ixm+TCKBP7PB8a9fNa+O+/FQr67mpUy6L0x+WzSGPRJ1jCTs vWnDScnqDtgtTLK5zKk2NpYsGZTvhYMu7qamRWMWRaIpFgpkOwJKReGC0f1RPOyFvenu 1XH4j6ysw05H8QpH8HIqZ23sVhV9XSizGNhAXhJqfkPZjDDVt9x9R+m5r1kXoPs/z0Pm Ausq5Q2Bdh8IZEmny9Xm/rmkr+TivWqz9uoCFnINTONNufzcAyIJKA8ixkJXcPlx71pz PXGQ==
X-Gm-Message-State: AJaThX7tNqChXMtPmHWWG3q+fYi73aJZFTEREfDvsYWiJu6KfcB/t2e3 LWW9ftrEXdc6+kchjrKZ1I9HsA==
X-Google-Smtp-Source: ABhQp+Q4OkehfNmD52LCkfQwBlOEtyXzqqY30qqNdLDX/EABEznVvPG7qrOOoWzgoWSncfoRuSnatg==
X-Received: by 10.84.236.70 with SMTP id h6mr1576271pln.166.1510259771207; Thu, 09 Nov 2017 12:36:11 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r18sm12420769pge.87.2017.11.09.12.36.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 12:36:10 -0800 (PST)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: "Templin, Fred L" , Fernando Gont , Lorenzo Colitti 
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <8efc982b0c784a6eac359d1ae9e50201@XCH15-06-08.nw.nos.boeing.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <10f7ae3d-1de0-d7fb-b5fb-fe7a609cbf05@gmail.com>
Date: Fri, 10 Nov 2017 09:36:13 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <8efc982b0c784a6eac359d1ae9e50201@XCH15-06-08.nw.nos.boeing.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 20:36:33 -0000

On 10/11/2017 07:19, Templin, Fred L wrote:
>>> I don't see how this is a protocol change. Sending RAs unicast is
>>> already allowed by RFC 4861, so this is just an operational practice.
>>
>> That's incorrect. We are talking about sending multicasted internetlayer
>> packets to a unicast link-layer address. There's nothing in RFC4861 that
>> suggests you should do that. RFC6085 says "you shouldn't drop packets if
>> they are internet-layer multicast but link-layer unicast". But
>> certainly, unless a protocol spec says otherwise, the normal mapping
>> applies.
> 
> On this point, I agree with Fernando. RFC4861 says that RAs can be unicast but
> that means unicast at both L2 and L3 (i.e., and not multicasted at L3). 

Who says that? As Fernando reminded us, RFC6085 says otherwise.

> RFC5214
> is an example of where both L2/L3 unicast are used in RAs in the spirit of RFC4861 .
> 
> Is there some reason why the requirements of this draft cannot be satisfied
> by L3 unicast?

Hosts listen for L3 multicast RAs.

   Brian


From nobody Thu Nov  9 13:14:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9B129B44; Thu,  9 Nov 2017 13:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level: 
X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx9LKSV737hD; Thu,  9 Nov 2017 13:14:00 -0800 (PST)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723911200B9; Thu,  9 Nov 2017 13:14:00 -0800 (PST)
Received: by mail-vk0-x22e.google.com with SMTP id t184so4883462vka.6; Thu, 09 Nov 2017 13:14:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2F2FmR+pR+KeZxk2to4eVZP534fr6PiDWCWtSMuEjOY=; b=QV+p80rm1sX0lrCZ/DVG1Fn5C4y23PLSHh+WPAtso2xeIgPcEQonwxhnXcjsGuepUh uygnVthDy/L33CTBKNr7WQ1NmuEZWlYuxdOloW/AY+alZkRTqxIkKTEdJjbdpEbr7OCs qKW3KPIH7PSgOuDe8k+0giy173vGUzyII6huzly9FFn8KgnXFdkAlTrBT9QGMAQr+SPD 93aPhzqi6Gd5f6N8iO9lrNz0gaxHiUKY+vUUQxyNf7/kaluQjJI6cBDLkl4PCflOXiL4 JmGSMWi/amT6XYqcPjbKbtHSRKRoamzbwx+IYYPiX53Cx4bj9uk39ughZedlKq4WfEFN E2dA==
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=2F2FmR+pR+KeZxk2to4eVZP534fr6PiDWCWtSMuEjOY=; b=Uia6hwdmuIZmdBiDHjwFSIsZcRhWivgYlt6UXsPsIv0P2x43Lysw1YorVojr5HrqRi qLyX8pk+1ejg8sx78dhbRXKOI2nMGHFEy2FDrJ+YEEexCj0zUgYTTt+qP6vxCEgEdMeU CO544POQsG9zrb+0UR0n8Gk/w7Hl8qD6PBbIZudODfXpcJbQNgormwRoQKiWlYO9ffhe FY32eeujJyrr6N/y1nX5YDoH0i00/JJPSS/G54LkW4/zruvIz8EcFwckqJuKmPtaqO3v 2nUJ76vF/5hZ8TxEdGQ7vvFKrtJSfpUoBJX7+tyrIVXNg+2E1FFZZkqVdw0VJ9R0gZ02 gFTg==
X-Gm-Message-State: AJaThX7v4WjMZWJipo1ecuBnD7sbGp8HHyFIB5fFr38MQncZySvhWwye NdXe6yWnfsqB8giLlkGXtjpGF19qpCjugQB3CYM=
X-Google-Smtp-Source: AGs4zMY3wGUM/70zoP+VLd4Dp4fdU0YN/gF00zNWy4B3MSgJu8fyfv3BhM9w6sZGSWfKmgOo6kHhn0socC+ip+cRgmo=
X-Received: by 10.31.165.214 with SMTP id o205mr1590471vke.147.1510262039339;  Thu, 09 Nov 2017 13:13:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.52.221 with HTTP; Thu, 9 Nov 2017 13:13:58 -0800 (PST)
Received: by 10.159.52.221 with HTTP; Thu, 9 Nov 2017 13:13:58 -0800 (PST)
In-Reply-To: <8efc982b0c784a6eac359d1ae9e50201@XCH15-06-08.nw.nos.boeing.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <8efc982b0c784a6eac359d1ae9e50201@XCH15-06-08.nw.nos.boeing.com>
From: Mark Smith 
Date: Fri, 10 Nov 2017 08:13:58 +1100
Message-ID: 
Subject: RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: "Templin, Fred L" 
Cc: Fernando Gont , Lorenzo Colitti , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>,  "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" ,  "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" 
Content-Type: multipart/alternative; boundary="001a11415eee5f67d7055d934862"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 21:14:02 -0000

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

On 10 Nov. 2017 5:19 am, "Templin, Fred L" 
wrote:

> > I don't see how this is a protocol change. Sending RAs unicast is
> > already allowed by RFC 4861, so this is just an operational practice.
>
> That's incorrect. We are talking about sending multicasted internetlayer
> packets to a unicast link-layer address. There's nothing in RFC4861 that
> suggests you should do that. RFC6085 says "you shouldn't drop packets if
> they are internet-layer multicast but link-layer unicast". But
> certainly, unless a protocol spec says otherwise, the normal mapping
> applies.

On this point, I agree with Fernando. RFC4861 says that RAs can be unicast
but
that means unicast at both L2 and L3 (i.e., and not multicasted at L3).
RFC5214
is an example of where both L2/L3 unicast are used in RAs in the spirit of
RFC4861 .

Is there some reason why the requirements of this draft cannot be satisfied
by L3 unicast?



I think it would be better to do it that way and suggested it because of
the principle of least suprise. Ole said that for an implementation he
works on, it is easier to do link layer unicast of multicast RAs rather
than RA unicast (perhaps because the implementation isn't performing NUD
and therefore isn't performing discovery of IPv6 neighbours, so knowledge
of their Link-Local addresses isn't available).

I'm comfortable with both options (as a contributor to RFC6085), although I
think unicast RAs should be the recommendation.

(I've thought there can also be security benefits of link-layer unicasting
for IPv6 multicasts when possible.


"MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6"


https://tools.ietf.org/id/draft-smith-mldv2-link-unicast-00.txt

)

Regards,
Mark.


Thanks - Fred

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

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




On 10 Nov. 2017 5:19 am, "Templin, Fred L" <Fred.L.Templin@boeing.com> wro=
te:
> > I don't see how this is a protocol change. Sending RAs u=
nicast is

> > already allowed by RFC 4861, so this is just an operational pract=
ice.

>

> That's incorrect. We are talking about sending multicasted interne=
tlayer

> packets to a unicast link-layer address. There's nothing in RFC486=
1 that

> suggests you should do that. RFC6085 says "you shouldn't drop=
 packets if

> they are internet-layer multicast but link-layer unicast". But
> certainly, unless a protocol spec says otherwise, the normal mapping
> applies.




On this point, I agree with Fernando. RFC4861 says that RAs can be un=
icast but

that means unicast at both L2 and L3 (i.e., and not multicasted at L3). RFC=
5214

is an example of where both L2/L3 unicast are used in RAs in the spirit of =
RFC4861 .



Is there some reason why the requirements of this draft cannot be satisfied=


by L3 unicast?


I think it would be better =
to do it that way and suggested it because of the principle of least supris=
e. Ole said that for an implementation he works on, it is easier to do link=
 layer unicast of multicast RAs rather than RA unicast (perhaps because the=
 implementation isn't performing NUD and therefore isn't performing=
 discovery of IPv6 neighbours, so knowledge of their Link-Local addresses i=
sn't available).=C2=A0

I'm comfortable with both options (as a contributor to RFC6085), alt=
hough I think unicast RAs should be the recommendation.

(I've thought there can also be securit=
y benefits of link-layer unicasting for IPv6 multicasts when possible.

&qu=
ot;MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6"=

<=
br>

)

Regards,
Mark.




Thanks - Fred




-----------------------------------------------------------------=
---

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

-----------------------------------------------------------------=
---





--001a11415eee5f67d7055d934862--


From nobody Thu Nov  9 15:01:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D593D1279EB for ; Thu,  9 Nov 2017 15:01:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 RXFnIby7O4xj for ; Thu,  9 Nov 2017 15:01:21 -0800 (PST)
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 628A9126C2F for <6man@ietf.org>; Thu,  9 Nov 2017 15:01:18 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id y75so6745073ywg.0 for <6man@ietf.org>; Thu, 09 Nov 2017 15:01:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=haqRjcUVjfn5CO4mMFdvjE/eXCgMds67v07xi8sfDM4=; b=hs9wN0BOahqRV7qLxHzzJPYm+Tl4+XZebzJsvlHvd4PI7fOOf66MGCC7vrOaQZ+A3O xg1/sZbMdHzemnPWjwTGEj5MOuivrRDe268/yO6UWmhapQKb/shee9I+PbCZhG9mgOvq NGteuWJaO8u1imr2mnMaMWhvh/ycFWhVJJskhCfQQprIj3ljgTiKsUhr58QY+n/t5HS1 w6QeYqRCxFvXn2ZN8x+nil+JmfPxZpu6IJcDyFJUXxD6xkshLcd7CC0aEXvZz/IiZK5R IAwks+g0lpFP42I8cQr6i7DOotJCl5Y+6tiligprAh2k0kDWoLLdikFdV2PW+VlowgCP ZVUQ==
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=haqRjcUVjfn5CO4mMFdvjE/eXCgMds67v07xi8sfDM4=; b=MyLMqQVM/MuqfhbAxGziDQFQN6LSeZF7hEsKUmmpitrU245DY2nkbFmzxtG5SXsXHp RxjgK+aiG6mPKnjfJbmo7/oWJsTOdESc+/yUS0sbYmAdfU/+tVrgmEo6UxuvwgLewYt6 8pTs7tK5UtZ/ArDiCajztmSZ73tLm29zftJcJ8mU6/Qr03Wc7BSgfMC9+vI5hjv/OBMA IJzpBZTNcUK1trM9O4s0uulPGyYF7gGWXqMyajJm2srDQKzRxL8dRVd5ddwxngGUGfY5 oyfL6oiFj7jC+5cBI5lG/gYh6NEUQIzdFZ5D3P8eeoFuW7qbRXONNuRQthRNK6yGJgjY c4WA==
X-Gm-Message-State: AJaThX4iOjKB71ykhQ7F/sjYc0+cNcLBFV/BQhSSTTpy8J8c2BHbIJmF V70WHJpFkfgj3LHvsJIaQZYeMw==
X-Google-Smtp-Source: ABhQp+TU9NsS1dl6OIdqA87GqCHvano/Goc52/XvPvMOnd1wFGpG+qW6g1z4xCrc8ZGTYN636Pmipg==
X-Received: by 10.129.76.194 with SMTP id z185mr1470157ywa.258.1510268477307;  Thu, 09 Nov 2017 15:01:17 -0800 (PST)
Received: from [172.29.163.110] ([172.29.163.110]) by smtp.gmail.com with ESMTPSA id i207sm796667ywe.38.2017.11.09.15.01.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 15:01:16 -0800 (PST)
From: james woodyatt 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_8079F2A4-00E6-4980-A58B-42DFE08E4429"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Thu, 9 Nov 2017 15:01:25 -0800
In-Reply-To: <10f7ae3d-1de0-d7fb-b5fb-fe7a609cbf05@gmail.com>
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" 
To: Brian E Carpenter , Fernando Gont , "Templin, Fred L" 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <8efc982b0c784a6eac359d1ae9e50201@XCH15-06-08.nw.nos.boeing.com> <10f7ae3d-1de0-d7fb-b5fb-fe7a609cbf05@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Nov 2017 23:01:23 -0000

--Apple-Mail=_8079F2A4-00E6-4980-A58B-42DFE08E4429
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 9, 2017, at 12:36, Brian E Carpenter =
 wrote:
> On 10/11/2017 07:19, Templin, Fred L wrote:
>>>> I don't see how this is a protocol change. Sending RAs unicast is
>>>> already allowed by RFC 4861, so this is just an operational =
practice.
>>>=20
>>> That's incorrect. We are talking about sending multicasted =
internetlayer
>>> packets to a unicast link-layer address. There's nothing in RFC4861 =
that
>>> suggests you should do that. RFC6085 says "you shouldn't drop =
packets if
>>> they are internet-layer multicast but link-layer unicast". But
>>> certainly, unless a protocol spec says otherwise, the normal mapping
>>> applies.
>>=20
>> On this point, I agree with Fernando. RFC4861 says that RAs can be =
unicast but
>> that means unicast at both L2 and L3 (i.e., and not multicasted at =
L3).=20
>=20
> Who says that? As Fernando reminded us, RFC6085 says otherwise.
>=20
>> RFC5214
>> is an example of where both L2/L3 unicast are used in RAs in the =
spirit of RFC4861 .
>>=20
>> Is there some reason why the requirements of this draft cannot be =
satisfied
>> by L3 unicast?
>=20
> Hosts listen for L3 multicast RAs.


My answer to Fernando=E2=80=99s concern about this late addition to =
section 4 possibly moving this draft into the ambit of 6MAN. I don=E2=80=99=
t think it does.

Here=E2=80=99s why. I don=E2=80=99t see the intent of RFC 6085 as to =
change the operational semantics of IPv6 multicast in the way that this =
draft sees it. When an IPv6 forwarding node sends a multicast packet =
with an Ethernet unicast address because the router knows that its group =
membership on the link comprises exactly one node=E2=80=A6 however, the =
RECEIVING node cannot be expected to share that knowledge. Therefore, =
when a host receives a multicast RA message in a unicast Ethernet frame, =
it cannot be expected to recognize that as a signal to indicate there =
are no other hosts on the link. Fortunately, this draft doesn=E2=80=99t =
violate that assumption of the protocol. The last paragraph of section 4 =
goes to this point:

   After the subscriber received the RA, and the associated flags, it
   will assign itself a 128 bit IPv6 address using SLAAC.  Since the
   address is composed by the subscriber device itself, it will need to
   verify that the address is unique on the shared network.  The
   subscriber will for that purpose, perform Duplicate Address Detection
   algorithm.  This will occur for each address the UE attempts to
   utilize on the shared provider managed network.

If the unicast address on the multicast RA message were to signal that =
the subscriber really is the only member of the all-hosts group on the =
link, then it would not be necessary for the host to perform Duplicate =
Address Detection (DAD), now would it? Of course, it has to perform =
DAD=E2=80=94 how could it not do that? Imagine all the things that could =
break if it didn=E2=80=99t.

Not mentioned in this draft (more is the pity) is that the provider =
router may send ND Redirect messages with a Target Address not in use by =
the subscriber host but still having the per-host unique prefix. Of =
course, in this scenario, the subscriber host cannot know that the =
prefix advertised in the RA message is a per-host unique prefix, so of =
course it=E2=80=99s then expected to process any ND Redirect messages it =
receives, and to update its Destination Cache according to RFC 4861 How =
could it not do that? Imagine all the things that could break if it =
didn=E2=80=99t. (I can imagine quite a lot, actually=E2=80=94 I=E2=80=99m =
thinking of applications for this even now.)

I was critical of this draft in V6OPS because I thought it didn=E2=80=99t =
make all of this sufficiently clear to the reader, but it was all =
pointed out to me on the list in subsequent discussions, and I seemed to =
be out of the rough consensus that it was necessary to clarify any of =
this stuff in the text, i.e. the fact that I initially misunderstood how =
this BCP is not actually a protocol specification should be no reason to =
believe that any ordinary reader might make the same mistake. =
Accordingly, because all of the protocol requirements about DAD and ND =
Redirect still hold despite all the diversionary text in the =
introduction about link-layer isolation, I=E2=80=99ve dropped my =
procedural objections to this draft.


--james woodyatt >




--Apple-Mail=_8079F2A4-00E6-4980-A58B-42DFE08E4429
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 9, 2017, at 12:36, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 10/11/2017 =
07:19, Templin, Fred L wrote:
I don't see how this is a protocol change. Sending RAs =
unicast is
already allowed by RFC 4861, so this is just an =
operational practice.

That's =
incorrect. We are talking about sending multicasted internetlayer
packets to a unicast link-layer address. There's nothing in =
RFC4861 that
suggests you should do that. RFC6085 says =
"you shouldn't drop packets if
they are internet-layer =
multicast but link-layer unicast". But
certainly, unless a =
protocol spec says otherwise, the normal mapping
applies.

On this point, I agree with =
Fernando. RFC4861 says that RAs can be unicast but
that =
means unicast at both L2 and L3 (i.e., and not multicasted at L3). 

Who says that? As Fernando =
reminded us, RFC6085 says otherwise.

RFC5214
is =
an example of where both L2/L3 unicast are used in RAs in the spirit of =
RFC4861 .

Is there some reason why the =
requirements of this draft cannot be satisfied
by L3 =
unicast?

Hosts listen for L3 =
multicast RAs.

My answer to =
Fernando=E2=80=99s concern about this late addition to section 4 =
possibly moving this draft into the ambit of 6MAN. I don=E2=80=99t think =
it does.

Here=E2=80=99s why. I don=E2=80=99t see the intent of RFC =
6085 as to change the operational semantics of IPv6 multicast in the way =
that this draft sees it. When an IPv6 forwarding node sends a multicast =
packet with an Ethernet unicast address because the router knows that =
its group membership on the link comprises exactly one node=E2=80=A6 =
however, the RECEIVING node cannot be expected to share that knowledge. =
Therefore, when a host receives a multicast RA message in a unicast =
Ethernet frame, it cannot be expected to recognize that as a signal to =
indicate there are no other hosts on the link. Fortunately, this draft =
doesn=E2=80=99t violate that assumption of the protocol. The last =
paragraph of section 4 goes to this point:

   After the subscriber received the RA, and the associated flags, =
it
   will assign itself a 128 bit IPv6 address using SLAAC.  Since the
   address is composed by the subscriber device itself, it will need to
   verify that the address is unique on the shared network.  The
   subscriber will for that purpose, perform Duplicate Address Detection
   algorithm.  This will occur for each address the UE attempts to
   utilize on the shared provider managed network.

If the unicast =
address on the multicast RA message were to signal that the subscriber =
really is the only member of the all-hosts group on the link, then it =
would not be necessary for the host to perform Duplicate Address =
Detection (DAD), now would it? Of course, it has to perform DAD=E2=80=94 =
how could it not do that? Imagine all the things that could break if it =
didn=E2=80=99t.

Not mentioned in this draft (more is the pity) is that the =
provider router may send ND Redirect messages with a Target Address not =
in use by the subscriber host but still having the per-host unique =
prefix. Of course, in this scenario, the subscriber host cannot know =
that the prefix advertised in the RA message is a per-host unique =
prefix, so of course it=E2=80=99s then expected to process any ND =
Redirect messages it receives, and to update its Destination Cache =
according to RFC 4861 How could it not do that? Imagine all the things =
that could break if it didn=E2=80=99t. (I can imagine quite a lot, =
actually=E2=80=94 I=E2=80=99m thinking of applications for this even =
now.)

I was =
critical of this draft in V6OPS because I thought it didn=E2=80=99t make =
all of this sufficiently clear to the reader, but it was all pointed out =
to me on the list in subsequent discussions, and I seemed to be out of =
the rough consensus that it was necessary to clarify any of this stuff =
in the text, i.e. the fact that I initially misunderstood how this BCP =
is not actually a protocol specification should be no reason to believe =
that any ordinary reader might make the same mistake. Accordingly, =
because all of the protocol requirements about DAD and ND Redirect still =
hold despite all the diversionary text in the introduction about =
link-layer isolation, I=E2=80=99ve dropped my procedural objections to =
this draft.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_8079F2A4-00E6-4980-A58B-42DFE08E4429--


From nobody Thu Nov  9 16:35:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DF11288B8 for ; Thu,  9 Nov 2017 16:35:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 j8eDRidLUhlE for ; Thu,  9 Nov 2017 16:35:33 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7612127444 for <6man@ietf.org>; Thu,  9 Nov 2017 16:35:32 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id j140so12928584itj.1 for <6man@ietf.org>; Thu, 09 Nov 2017 16:35:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EK73B3p7r2GeOtDd6Li5n2hzB+1NaAcfrnlNwSc8Qks=; b=YxsLV2NTVq16gqELfNOATxJ49Xftrbkm4H6DEnaByCRHbyw0+9vlB+bZ5k1EJMVxf+ yZVPx2y37A4f/qH5xEnWSV3Xmmy5iInKjFJ3MgJtthHUf7vTaQ8+tPXrz1xoTdILKoIH P3B81MK1oa20JbhN/pzyc+/Ip/9nWAGYRfpOVgpRWxX/wmablLt7o9CBwM1pkb3NEln/ UloOZR9nHFyjOGKf6oZDz3cx5azq75V/5xFqMAG3GFeKDeSKns+Fof61Pt+Gck1NfSSG KDhTNGLnnKWoheD9aTNUDCIkjudq/blQnqQ5sRlHAp6lnghkofMqYVE6cb8LnZSTS0TH NUCg==
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=EK73B3p7r2GeOtDd6Li5n2hzB+1NaAcfrnlNwSc8Qks=; b=RON765BlBD1o7ASVgozVfZbBNXXVBojKxQolw7Ph1Xvg1/EymFJP6FVFPI0oXjm3cH jrxlRRKflrznbIVobc01XmKwuzcDee3FHfKmfx2tXcUiO9k/Eb9ZjDrQhmdTQOQtDiRW qb0cGpTbCMGQIf1hZjspYuT0HbUES2kJgr6VuQbnlm7Rsg+aq7Zp+CT8PLv9oFjHcZPk yuf81SYaPOK9/LCdxNGTg1GlWtlafb4swXxV2JBtEImqnsD1jJ1D4qc+BBrVBITZj236 iFW+ahYQ2M/010Xmaqxj427g6Hg2XLYYM33Qkr/LiJDL07kh9Pg9+yHjh+kG6nbuU84d OBNw==
X-Gm-Message-State: AJaThX4NO5uXr3NH8vqkuxgrkxAqmRkHikVFTazyINsHa37kzGXf5v4R 1/zBYOgtSlpzkgNdHaSK0WPNJ4depsvuf2ESwV5s3w==
X-Google-Smtp-Source: AGs4zMayeSqIJf5pdYRV4QhRcQ95UXdnId0g0chmoKIh56pFVMgvPOQZ/RfyS4XggGvs+ezJBR6FpDv2UyoVHGh6PZo=
X-Received: by 10.36.252.68 with SMTP id b65mr2174144ith.151.1510274131601; Thu, 09 Nov 2017 16:35:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Thu, 9 Nov 2017 16:35:10 -0800 (PST)
In-Reply-To: <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com>
From: Lorenzo Colitti 
Date: Fri, 10 Nov 2017 09:35:10 +0900
Message-ID: 
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: IPv6 Operations , "6man-ads@tools.ietf.org" <6man-ads@ietf.org>,  "v6ops-ads@ietf.org" , "6man@ietf.org" <6man@ietf.org>,  draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0b285821282e055d961997"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 00:35:35 -0000

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

On Fri, Nov 10, 2017 at 2:48 AM, Fernando Gont 
wrote:

> > I don't see how this is a protocol change. Sending RAs unicast is
> > already allowed by RFC 4861, so this is just an operational practice.
>
> That's incorrect. We are talking about sending multicasted internetlayer
> packets to a unicast link-layer address. There's nothing in RFC4861 that
> suggests you should do that. RFC6085 says "you shouldn't drop packets if
> they are internet-layer multicast but link-layer unicast". But
> certainly, unless a protocol spec says otherwise, the normal mapping
> applies.
>

The intent of 6085 is clearly to allow this. The introduction says that the
purpose of the document is to allows mapping a multicast group to a
link-layer address "when it is clear that only one address is relevant".

> The additional text did not actually change this practice at all.> It
> > simply clarified what has always been a fundamental premise of this
> > operational practice: if you want to give each host its own prefix, you
> > need to ensure that the RA with that prefix is only received by that
> host.
>
> If you want to give each host it's own prefix, you do prefix delegation.
> So far, SLAAC doesn't do prefix delegation. If you want to do prefix
> delegation in slaac, write a std track document in 6man, not a BCP in
> v6ops.
>

That statement does not match reality. All IPv6-capable phones (well over
100 million at this point) have a /64 prefix that is dedicated to them by
the network, and the mechanisms used for that are RAs and SLAAC. See RFC
6459.


> > This is a bizarre claim. The first-hop router must always have fully
> > up-to-date state on all the prefixes it is sending RAs for, otherwise it
> > cannot fulfill its fundamental purpose of forwarding traffic to those
> > prefixes. The word "stateless" in SLAAC applies to addresses configured
> > to the host, not how routers route traffic.
>
> A SLAAC router need not maintain any sort of dynamic mapping. It's
> static configuration information of the sort "I'm announcing this prefix
> on this interface".. If you think otherwise, please point me the section
> in RFC4862 where this conceptual data structure is mentioned. (Note:
> Neighbor Cache, Destination Cache, etc. are all mentioned in RFC4861).
>
:
In many cases that's not correct. Consider DHCPv6 PD, which you cite as an
example above. IIRC there is nothing in any RFC that says that the
first-hop router of a requesting router needs to maintain a mapping between
delegating prefix and requesting router, but that mapping is 100% required
for DHCPv6 PD to work.

>     3) What happens if the SLAAC router crashes and reboots, loosing state
> >     of the "leased" prefixes?
> >
> > You seem to be assuming that the router does not store the prefixes in
> > stable storage.
>
> Routers store configuration info, not dynamic mappings.
>

Again, see the DHCPv6 PD example above.

>     4) How are prefixes selected? And, what's the minimum size of the pool
> >     of prefixes for the selection algorithm not to break due two "prefix
> >     collisions"? Does the selection algorithm have any specific
> properties?
> >
> > I see no reason why this should be in scope for this document.
>
> Actually, what's not in the scope of this document, and not within v6ops
> charter, is the protocol you are specifying to handle prefixes with SLAAC.


Protocols are out of the v6ops charter, and that's fine because there is no
protocol in this document. :-)

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


On F=
ri, Nov 10, 2017 at 2:48 AM, Fernando Gont <fgont@si6networks.com&=
gt; wrote:
> I don't see how this is a protocol change. Send=
ing RAs unicast is

> already allowed by RFC 4861, so this is just an operational practice.<=
br>


That's incorrect. We are talking about sending multicasted inter=
netlayer

packets to a unicast link-layer address. There's nothing in RFC4861 tha=
t

suggests you should do that. RFC6085 says "you shouldn't drop pack=
ets if

they are internet-layer multicast but link-layer unicast". But

certainly, unless a protocol spec says otherwise, the normal mapping

applies.

The intent of 6085 is clearly =
to allow this. The introduction says that the purpose of the document is to=
 allows mapping a multicast group to a link-layer address "when it is =
clear that only one address is relevant".

> The a=
dditional text did not actually change this practice at all.> It

> simply clarified what has always been a fundamental premise of this
> operational practice: if you want to give each host its own prefix, yo=
u

> need to ensure that the RA with that prefix is only received by that h=
ost.



If you want to give each host it's own prefix, you do prefix del=
egation.

So far, SLAAC doesn't do prefix delegation. If you want to do prefix
delegation in slaac, write a std track document in 6man, not a BCP in

v6ops.

That statement does not match re=
ality. All IPv6-capable phones (well over 100 million at this point) have a=
 /64 prefix that is dedicated to them by the network, and the mechanisms us=
ed for that are RAs and SLAAC. See RFC 6459.
=C2=A0
> This =
is a bizarre claim. The first-hop router must always have fully

> up-to-date state on all the prefixes it is sending RAs for, otherwise =
it

> cannot fulfill its fundamental purpose of forwarding traffic to those<=
br>
> prefixes. The word "stateless" in SLAAC applies to addresses=
 configured

> to the host, not how routers route traffic.



A SLAAC router need not maintain any sort of dynamic mapping. It'=
;s

static configuration information of the sort "I'm announcing this =
prefix

on this interface".. If you think otherwise, please point me the secti=
on

in RFC4862 where this conceptual data structure is mentioned. (Note:

Neighbor Cache, Destination Cache, etc. are all mentioned in RFC4861).
<=
/blockquote>
:
In many cases that's not correct. Consider=
 DHCPv6 PD, which you cite as an example above. IIRC there is nothing in an=
y RFC that says that the first-hop router of a requesting router needs to m=
aintain a mapping between delegating prefix and requesting router, but that=
 mapping is 100% required for DHCPv6 PD to work.


>=C2=A0 =C2=A0 =C2=A03) What happens if the SLAAC router crashes and reb=
oots, loosing state

>=C2=A0 =C2=A0 =C2=A0of the "leased" prefixes?

>

> You seem to be assuming that the router does not store the prefixes in=


> stable storage.



Routers store configuration info, not dynamic mappings.

Again, see the DHCPv6 PD example above.

>=C2=A0 =C2=A0 =C2=A04) How are prefixes selected? And, what=
's the minimum size of the pool

>=C2=A0 =C2=A0 =C2=A0of prefixes for the selection algorithm not to brea=
k due two "prefix

>=C2=A0 =C2=A0 =C2=A0collisions"? Does the selection algorithm have=
 any specific properties?

>

> I see no reason why this should be in scope for this document.



Actually, what's not in the scope of this document, and not with=
in v6ops

charter, is the protocol you are specifying to handle prefixes with SLAAC.<=
/blockquote>

Protocols are out of the v6ops charter, and=
 that's fine because there is no protocol in this document. :-)


--94eb2c0b285821282e055d961997--


From nobody Thu Nov  9 20:12:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8F4120713; Thu,  9 Nov 2017 20:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLhbl6QxyO0e; Thu,  9 Nov 2017 20:12:49 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C4B129434; Thu,  9 Nov 2017 20:12:49 -0800 (PST)
Received: by mail-wm0-x233.google.com with SMTP id b9so154127wmh.0; Thu, 09 Nov 2017 20:12:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7KhVdFPdTuHMq04G/wwycGWHHxDLD7v/myix8Vys2bM=; b=jf7K7Q9izN3kP/O9ShCebTbCCQ0VvWzid1hnu7SaAnSOlamHg/PWhwFjuW/7ZNguE5 U2vTf8bgYX9UYrLY49V8zt9x3j58pxGNoqE37muI/onUtUiIAAup5Tk3ALWtgt7JgfQs 7qv1qaulBi4dEreoD1RSgJMWmBO0vvpktRwzzMg7brUmbkyW6TZLYLfZVhYOekzfHRoD 8ZNPZaTjTKVzXd4aSD/wh9azVmjuijuNH+Ztv/0Zj3gLbaCeXMFqYMnojQ6PKEcrQMxr 3988r/ovaWAGH8zJKrDDG3Et87xzQLpBJZQcSHLpE94Kh/EDd1uQ4xpRZyc2/OjsY277 HOcQ==
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=7KhVdFPdTuHMq04G/wwycGWHHxDLD7v/myix8Vys2bM=; b=ldlhZfgEpWvzZ0JaPjRb44HRpEzXX6s/6IO3lHwOiQnbYlrmZnCqSHlUVGWw44Pa2O Y49k5acbQQcB14wkS3FEYFnJQqdLFzeiC2l7k9nNAqNVYDXkrq1Hafpa6eqD+pTEIN2O bkGlqlFd++4rLHnpjMeug/trTndj/1n3DrYMDBVCA/tZik+ouWSq9rgu5CsFJGQK1y4X J5lCuGndoB+tfmI4P8G4yVWrYZAiaK0AY1GlDvbP/nbV4rP/oYR7pdVfTJFmdQS/6PDC zUOnnRcci4Tzg1OTTs29nz/QR2w6p2OUGP+QXT9qrxo5nqHlADadQbO2gKx09MGm81Tc DJVA==
X-Gm-Message-State: AJaThX7U6TvAEsxEc2vzAAo1PrlYvuNpM5rmUAvsQvfUjB74Xq1oK/wQ IsUepcPgGLyCADW8Nyi5yOw=
X-Google-Smtp-Source: AGs4zMZwGL59e3RxGCtLE6VMLEntOj6+ieCLVtaNNAI2P0TzSZi1whO1ROGc9XeqE5PPTefmoH/Nbw==
X-Received: by 10.28.19.130 with SMTP id 124mr33560wmt.108.1510287167689; Thu, 09 Nov 2017 20:12:47 -0800 (PST)
Received: from 198.66.20.149.in-addr.arpa (198.66.20.149.in-addr.arpa. [149.20.66.198]) by smtp.gmail.com with ESMTPSA id b81sm250629wmh.16.2017.11.09.20.12.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 20:12:46 -0800 (PST)
From: Fred Baker 
Message-Id: <83BF7A33-9A52-43EE-996E-0B5F54D67AFF@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_4A1A49D9-8A4B-4F81-8D64-40B087EAE376"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.11\))
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Fri, 10 Nov 2017 06:48:25 +0530
In-Reply-To: 
Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
To: Lorenzo Colitti 
References:  
X-Mailer: Apple Mail (2.3445.5.11)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 04:12:50 -0000

--Apple-Mail=_4A1A49D9-8A4B-4F81-8D64-40B087EAE376
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Nov 9, 2017, at 8:28 AM, Lorenzo Colitti  =
wrote:
>=20
> On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont  =
wrote:
> While reviewing this document a few days ago, I found that Section 4
> (page 5) contains what is a protocol spec, rather than an operational
> BCP. It contains rules regarding how to set the link-layer address (to =
a
> unicast address) for IPv6 multicasted RAs, and how a SLAAC router =
should
> now remember which prefix has been "leased" to which node -- something
> that seems to be way outside of the v6ops charter, and that should =
have
> been done in 6man, instead.
>=20
> I don't see how this is a protocol change. Sending RAs unicast is =
already allowed by RFC 4861, so this is just an operational practice.

I understand the concern to be sending to a multicast address at the =
network layer and a unicast address at the link layer. If 4861 allows =
the RA to be sent unicast, it is probably unicast at both layers. I =
suspect that if we change to doing what 4861 describes we'll be fine.

--Apple-Mail=_4A1A49D9-8A4B-4F81-8D64-40B087EAE376
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+AFAloE/mEACgkQEhdRnd2G
P+ClVhAAooIsAFm2LRtza93tIaU1mA02N7bgGMRZAZLb7FOTxOrozAocb3pf9na0
IzA3CrmkC4o/3N/Sfj/K20h4Aqy0poDu+N1ANXYcuuxx9E3l2F8laixjyPkd/DOg
pQQf3KqFYl6VEjRbqha6kv8e3UWpn+0m3Ilb0Fk45cgXTECUz0z0VzzBW52ITQ85
oTuLULubTGO5CVUqdo3TEfCkP4wvt5vgf+Jgt4WOAuzusoHLPnc9Boz8galvxQZl
FRMuw564QSZMKlrfSu5YEpZ+Pm+lTLONaZQDrbIz4uHNeUKQZfsGBN/X7hJWiX68
GSWAiU8RvP0jhdwedjkvDHkeK3X7MTqyd7ZRYMMKGnqJltLGXsHxpfedV0wPLQgv
Irb3mRQ0vmA1Rb3AuJrJwxhF+gODANE2TWTgHiocKFKyLwigJDxJNmF3XO/Vmtzb
onM8Hy4SUh1s1SAuG7+X4rb5BL+ahfBcuDjyQgMTif4dvsOtuGSHlZRncki2WeHk
lSVWI9hTpVhEeFh62BwXFaC1B7LePLkgOI+qwnwWFIbGM5EEMmI0Kocnv9gonapn
A1LU/pUamWDl8bimwW5cbfVEbWiBW5DW96ga8+9DnmY+4F6d0aLydbLT7eNLNvjV
i5ILR8ROCsNnbA9nkZdgU7n08pRZRjTlNWaHbGQj3jCmQyDO/bU=
=hjqZ
-----END PGP SIGNATURE-----

--Apple-Mail=_4A1A49D9-8A4B-4F81-8D64-40B087EAE376--


From nobody Thu Nov  9 20:13:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E4B129484; Thu,  9 Nov 2017 20:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbaqCvmiCt4r; Thu,  9 Nov 2017 20:13:23 -0800 (PST)
Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0940129434; Thu,  9 Nov 2017 20:13:21 -0800 (PST)
Received: by mail-wr0-x243.google.com with SMTP id j23so7467661wra.9; Thu, 09 Nov 2017 20:13:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dfXVue50ov+ByiI9kYRUmGSWUlCBE01/sTFXW+aWf60=; b=XTN7FqQI46BZDjhtf9T7F7sGNJKe7JQ6oQvn2lu0v8kLM7jw0GpDM4NC5Hnbp0gFDb R+LJ1HQpJe/hW201lY1xTprzbHE1329NxvH80EPs8g1IZlEWype3ryVGbW6VDnu8lP4G 2YJpydEPcmz1Rhtt2CVG3Wp5aOb83tclqCRiIdmfFuxzRVEkj3DupsUt9o+LJAnLxDaP iQOwAm0w/g67zEQrcO9ShlnbUCvxlmOI/nbfkgijWfkEY2lCce92cepJ6uIv1Vm2fORo khG7c3Yq7hebYKo0ctAju3ZDntjs/AvY2Eb5WM2TNFuuKBATBrR6BbrS+I5s8a66vHz5 xAAg==
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=dfXVue50ov+ByiI9kYRUmGSWUlCBE01/sTFXW+aWf60=; b=gMjyiUPP2ubaXkpUuuotc5wwE/+wO3SrGTRSDzBnN39e6rU4sbg//2xTELEFcgnxui AWh7shqnmKUcQM4WpgrgSKxelFetBXjg6tOG8X/uZUvFyzO6Es9y80P+IRZGfGiSJT+J WyUn33xouOJyP7DezIb0L6n5JLiDEfZfqalOAn4VaFUSKQdHrVuaYuu5NSb5W9eLrvNl gBZy6mwxOhN1t50mHKm7t6N+oFEflVM1YYS+m6aQP679rhHC44/Rtt1B22p755AbhFb1 OJj1k4zb9vkdCRdiOWziUmfcRVWDgszKvPMDkvVTPBwVWQfwCKgX8XfhR4rdyM5gnGhq M7sA==
X-Gm-Message-State: AJaThX7jv1eNqoypHaH1n52CutJNWMIYLkldbLStMNg0RpqeVheNRD3F CuihIRs3f2+CfDlmeFXLXRg=
X-Google-Smtp-Source: ABhQp+QcuOUaNQtq4wIs5OCxO8tPRbl8bo0fey2cXTBnCNiBHFX9KgvTtGgVS7BbulhCAwuqqpbpvA==
X-Received: by 10.223.163.216 with SMTP id m24mr2066632wrb.107.1510287200539;  Thu, 09 Nov 2017 20:13:20 -0800 (PST)
Received: from 198.66.20.149.in-addr.arpa (198.66.20.149.in-addr.arpa. [149.20.66.198]) by smtp.gmail.com with ESMTPSA id b81sm250629wmh.16.2017.11.09.20.13.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 20:13:19 -0800 (PST)
From: Fred Baker 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_541A7649-77F5-444B-923D-C903D28468D7"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.11\))
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Fri, 10 Nov 2017 09:42:31 +0530
In-Reply-To: 
Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
To: Lorenzo Colitti 
References:  
X-Mailer: Apple Mail (2.3445.5.11)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 04:13:24 -0000

--Apple-Mail=_541A7649-77F5-444B-923D-C903D28468D7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Nov 9, 2017, at 8:28 AM, Lorenzo Colitti  =
wrote:
>=20
> On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont  =
wrote:
> While reviewing this document a few days ago, I found that Section 4
> (page 5) contains what is a protocol spec, rather than an operational
> BCP. It contains rules regarding how to set the link-layer address (to =
a
> unicast address) for IPv6 multicasted RAs, and how a SLAAC router =
should
> now remember which prefix has been "leased" to which node -- something
> that seems to be way outside of the v6ops charter, and that should =
have
> been done in 6man, instead.
>=20
> I don't see how this is a protocol change. Sending RAs unicast is =
already allowed by RFC 4861, so this is just an operational practice.

I understand the concern to be sending to a multicast address at the =
network layer and a unicast address at the link layer. If 4861 allows =
the RA to be sent unicast, it is probably unicast at both layers. I =
suspect that if we change to doing what 4861 describes we'll be fine.

--Apple-Mail=_541A7649-77F5-444B-923D-C903D28468D7
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+AFAloFJy8ACgkQEhdRnd2G
P+CBnxAAkgHr7a+frBisOHbKyKR6hQcZJ1AnYiO8eTU7AVVXcRMXBUPw90t4qAmf
pjhj3D+ntfh+iNA5XcrvkMwy7lgmcY7qWF5thVfPLx1sSyxBEXZ4EuUukBGsuZVR
OOlTHt2tYP1VGSKrOKgBVpWWACfybnvD0u6OpOgEz0ajbaocMn7B37Pppo5ZMFbu
kAX9ZWkDr0JHE13ZUvZFgaEUEyEg5qmZ9R6AhjaQoywdQ3jnrjW8IBToeCrbHPCJ
soMEBVhfnbORav8ba5ucZRR94ks4Nmhi1jlb6kGUGzyNZaiM4txzNIq0f2eLGwax
1417q1zm1uQvLh3UiuQV6fHCKYdBDxfaAmk+QmyMXc2Y7hxCddOQOGwkQsz8b22u
/zKh1CEiruuYrG6hC42Ajea/LwqDHQ1jIRVkqxozkzWtUytYG9sCLE1sawypEeTi
yYPj0gdjCuKT0VuLrHOI2BGNS7Szdot5+glZS/BMoPZYuf+tE/mndEAoeTbZtHG6
xuVR0ri+mxYg2YoZrCanVco9vop0uYmF9bIxBrOAt7HXNjGtcjVR8z8dXh4fLoJM
aHyU1bFRxW5sQ3id5/evfWTwjkgHZnIfCIJ4vMxGNSlFfLfjjgpgXXjaAnfnt29C
zkPKrhZqxrZwCkEzCT3bmjlxW8znurUcOtjoGC9ricFY0zsisco=
=qN/E
-----END PGP SIGNATURE-----

--Apple-Mail=_541A7649-77F5-444B-923D-C903D28468D7--


From nobody Thu Nov  9 20:35:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74053129512; Thu,  9 Nov 2017 20:35:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6OQ0RlX1FWj; Thu,  9 Nov 2017 20:35:31 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC835129508; Thu,  9 Nov 2017 20:35:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rQOaFxjkeRgw6DhtYlSQj3sT4UmGK1i3Ekjp4WICksA=; b=wyB3veUFbe7Kd96bgqnTtCxpd/ jrwCbHHBmXkoR0a2CwkDOLOh+e5CM5SWd7al/Zc5NnxPG9gvGF2+r8Tq9EC7FmzD14TAjch4XHjgZ cD8Z0DE2sKFHRib2SKXN3C70vPCpkkDmMg1olK63c50fbUwkj6QFu+T3/o3s1d6udVe46v1bW+SXl PePSE+lcs5yee9e2Ymp7knVSh4DNDK1PaESVp5wshrIyJ/nWzdGyzlpn67JwPM2Qf/QpXdBozaYBy Av7dDvr6YeNYSvXskAPSneL53FoDfJaUkB85FVMwFMxD8kvYgLcFnkLPV3NJQoKVAGgm2dGGXeM7R lu8IDDmg==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:61548 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eD12O-000AZJ-QF; Thu, 09 Nov 2017 23:35:29 -0500
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: james woodyatt , Brian E Carpenter , Fernando Gont , "Templin, Fred L" 
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , "draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org" 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <8efc982b0c784a6eac359d1ae9e50201@XCH15-06-08.nw.nos.boeing.com> <10f7ae3d-1de0-d7fb-b5fb-fe7a609cbf05@gmail.com> 
From: Joe Touch 
Message-ID: <8ecf1a4c-35bb-3cfa-5902-103732e98669@strayalpha.com>
Date: Thu, 9 Nov 2017 20:35:15 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 04:35:33 -0000

On 11/9/2017 3:01 PM, james woodyatt wrote:
> i.e. the fact that I initially misunderstood how this BCP is not
> actually a protocol specification should be no reason to believe that
> any ordinary reader might make the same mistake. 

Given the time it has taken the discussion to come around to this claim,
it seems prudent to add text to the document to explain this reasoning.

Joe


From nobody Thu Nov  9 20:45:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD45C129AD2 for ; Thu,  9 Nov 2017 20:45:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 LePl8IJ8vSjF for ; Thu,  9 Nov 2017 20:45:36 -0800 (PST)
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 46F1E129744 for <6man@ietf.org>; Thu,  9 Nov 2017 20:45:36 -0800 (PST)
Received: by mail-it0-x229.google.com with SMTP id 72so168698itk.3 for <6man@ietf.org>; Thu, 09 Nov 2017 20:45:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lL+upWXUqeBwQ1kX4T44txVPm+/2X++fQ7CJ/dwMcUM=; b=bgSWZoA3SnVuft/IwfBEUBOPY6zKzms5QGxmgFmd8eRkEbeGI2d8FKO46h8YR+GYz+ YYhojKMSO7IQyvLzH1DYpA6ecpudth1cEACy945WoIXIJqhkfl5fC56fqusUjk5EHYvx cpdN3y6P2zN2hWBLbAY5g3H9cDjr16PIZHRk9gr+rj6cKwx3yab4cCfYFLbyE0NEwNpN i1I52LIKHSmmLVGvCWDBdmfGNY/W2trRXkIfrIttpnKeqjWgKN09ZnAhNkh11lyrD2td SZ4exxbKhDB2HDjYOvRd4uYS0XmLi+zOlxDpMZrfCasMGD1Tj5/flcnAkTuON9i9Kj+l g/zg==
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=lL+upWXUqeBwQ1kX4T44txVPm+/2X++fQ7CJ/dwMcUM=; b=WC1jGYQ+VyBhJTpkYz6sBD1j+18XYiyzOWEUU04NpgXw8h2Wywe+QbtmDjO7SHNKHY O0JMhZB191S3B/oUvYcFdeorLmio7bgdWPOxlRfRiF5PCMO0oBaf1wulHGLcWo+CgHel f1+tMr6lfeISiAHCQjvtSqAjdSje4nGMPBnj1Qv+mrA4zUOs0KP98L7/BWHiIEctk13C ftN6MieZ/TYznIQXWaLXDw3T48yT+96WdZb9WrIow27yAYe7uxTcgEqwPlIukcLTA2mA 4VGaTZcoTeV9/uFi2uIMLANtU3MYSK0SN+Apim9R9vo8fFmTjwQ64WW73C1v7l3JRgaB ojrQ==
X-Gm-Message-State: AJaThX5nmTvPyL1SQ3BPFDyp2QB9sRUwlWo3MUFk+8AedNLNoX+RIR7T F+EZ1ol+qPxlB7cttyiOSgdNEU0DuKH1SOZFXxibo6LzPkw=
X-Google-Smtp-Source: AGs4zMZEpQhB4JCYw6GOl2Vq4RYbDUqvZsPGegWlqIMzCjZcG1PmoI637XZUDrnV0hXQWUu4NocVT6k+5F48x+rPJn0=
X-Received: by 10.36.26.206 with SMTP id 197mr135969iti.88.1510289135151; Thu, 09 Nov 2017 20:45:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Thu, 9 Nov 2017 20:45:14 -0800 (PST)
In-Reply-To: <83BF7A33-9A52-43EE-996E-0B5F54D67AFF@gmail.com>
References:   <83BF7A33-9A52-43EE-996E-0B5F54D67AFF@gmail.com>
From: Lorenzo Colitti 
Date: Fri, 10 Nov 2017 13:45:14 +0900
Message-ID: 
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fred Baker 
Cc: Fernando Gont , IPv6 Operations ,  "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>,  "v6ops-ads@ietf.org" ,  draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Type: multipart/alternative; boundary="001a114457ec6972e1055d9997f4"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 04:45:38 -0000

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

On Fri, Nov 10, 2017 at 10:18 AM, Fred Baker 
wrote:

> > I don't see how this is a protocol change. Sending RAs unicast is
> already allowed by RFC 4861, so this is just an operational practice.
>
> I understand the concern to be sending to a multicast address at the
> network layer and a unicast address at the link layer. If 4861 allows the
> RA to be sent unicast, it is probably unicast at both layers. I suspect
> that if we change to doing what 4861 describes we'll be fine.
>

That's already allowed by RFC 6085, which states:

   "Transmission of IPv6 Packets over Ethernet Networks" ([RFC2464],
   Section 7) specifies how an IPv6 packet with a multicast destination
   address is mapped into an Ethernet link-layer address.  This document
   extends this mapping to explicitly allow for a mapping of an IPv6
   packet with a multicast destination address into an Ethernet link-
   layer unicast address, when it is clear that only one address is
   relevant.

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


On F=
ri, Nov 10, 2017 at 10:18 AM, Fred Baker <fredbaker.ietf@gmail.com<=
/a>> wrote:
=
> I don't see how this is a protocol change. =
Sending RAs unicast is already allowed by RFC 4861, so this is just an oper=
ational practice.



I understand the concern to be sending to a multicast address at the=
 network layer and a unicast address at the link layer. If 4861 allows the =
RA to be sent unicast, it is probably unicast at both layers. I suspect tha=
t if we change to doing what 4861 describes we'll be fine.



That's already =
allowed by RFC 6085, which states:

=C2=A0 =C2=A0"=
Transmission of IPv6 Packets over Ethernet Networks" ([RFC2464],
=

=C2=A0 =C2=A0Section 7) specifies how an IPv6 pa=
cket with a multicast destination
=C2=A0 =
=C2=A0address is mapped into an Ethernet link-layer address.=C2=A0 This doc=
ument
=C2=A0 =C2=A0extends this mapping to =
explicitly allow for a mapping of an IPv6
=
=C2=A0 =C2=A0packet with a multicast destination address into an Ethernet l=
ink-
=C2=A0 =C2=A0layer unicast address, wh=
en it is clear that only one address is
=C2=
=A0 =C2=A0relevant.



--001a114457ec6972e1055d9997f4--


From nobody Thu Nov  9 21:57:42 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF6712EB04; Thu,  9 Nov 2017 21:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQVbwxuRB8ET; Thu,  9 Nov 2017 21:57:39 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B7A12EB02; Thu,  9 Nov 2017 21:57:38 -0800 (PST)
Received: from mb.local ([111.223.75.82]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id vAA5vZfl012463 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 10 Nov 2017 05:57:36 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [111.223.75.82] claimed to be mb.local
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont , Erik Kline 
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References:   <65664ca5-b8fe-0ca0-82fc-99e120426aea@si6networks.com>
From: joel jaeggli 
Message-ID: 
Date: Fri, 10 Nov 2017 13:57:28 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:56.0) Gecko/20100101 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <65664ca5-b8fe-0ca0-82fc-99e120426aea@si6networks.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 05:57:40 -0000

On 11/9/17 16:05, Fernando Gont wrote:
> On 11/09/2017 12:02 AM, Erik Kline wrote:
>> I don't think we should be recommending unique RAs per device where
>> the devices are all on a shared link.
> 
> Agreed.
> 
> And if we were to do it, we should be recommending this in a 6man
> document, not v6ops.
> 
> 
> 
>> My understanding was that in the original motivating wifi deployment
>> every node is effectively isolated in its own (pseudo)VLAN, and
>> node-to-node traffic must be routed through the infrastructure (to the
>> extent such a thing can actually be enforced in a medium like wifi).
> 
> Describing the virtues of one prefix per node, or how isolating nodes
> (no "on link prefix") or the like are all fine for an informational
> document, or even as a BCP (if that's how the wg feels).

there is an available recourse to an onlink prefix in form of the
link-local address for a deligated prefix.

   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

https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13#section-4


> Specifying hacks to SLAAC which require modification to the SLAAC router
> code (you certainly need to hack e.g. radvd quite a lot to implement
> this) or add additional requirements to SLAAC (like the requirement of a
> data structure that contains mappings of Prefix_leased -> MAC_address)
> is std track work that should be done in 6man, and with a document
> flagged as "std track", not bcp.
> 


From nobody Fri Nov 10 11:53:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E6F129453; Fri, 10 Nov 2017 11:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.852
X-Spam-Level: 
X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWs4mm97V7mB; Fri, 10 Nov 2017 11:53:38 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B361128D0D; Fri, 10 Nov 2017 11:53:38 -0800 (PST)
Received: from [10.234.32.137] (unknown [87.200.50.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id F203682983; Fri, 10 Nov 2017 20:53:32 +0100 (CET)
From: Fernando Gont 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Brian E Carpenter , v6ops@ietf.org
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>
Cc: "6man@ietf.org" <6man@ietf.org>
Message-ID: 
Date: Thu, 9 Nov 2017 23:35:21 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 19:53:41 -0000

Hi, Brian,

Please let me top-post to try to focus the discussion here:

1) My comment to the list was essentially arguing that this document
contains a protocol specification, and such part is not suitable. I
think it should be easy to converge on something regarding this one:

Can anyone (you, for instance), provide a definition of what is a
protocol, and the run this document through such definition and figure
out if it fits or it doesn't?

It would seem to me that many folks seems to be assuming that the only
thing that can be said to be a "protocol spec" is something that
specifies a new packet format -- a definition with which I disagree.


2) The rest of the conversation has been about details (or lack of) of
what I believe is the protocol being specified in this document. Such
discussion can be interesting. But I believe at this point the item to
be discussed is #1 above.

Thanks,
Fernando




On 11/09/2017 04:42 PM, Brian E Carpenter wrote:
> On 10/11/2017 06:48, Fernando Gont wrote:
>> On 11/08/2017 11:58 PM, Lorenzo Colitti wrote:
>>> On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont >> > wrote:
>>>
>>>     While reviewing this document a few days ago, I found that Section 4
>>>     (page 5) contains what is a protocol spec, rather than an operational
>>>     BCP. It contains rules regarding how to set the link-layer address (to a
>>>     unicast address) for IPv6 multicasted RAs, and how a SLAAC router should
>>>     now remember which prefix has been "leased" to which node -- something
>>>     that seems to be way outside of the v6ops charter, and that should have
>>>     been done in 6man, instead.
>>>
>>>
>>> I don't see how this is a protocol change. Sending RAs unicast is
>>> already allowed by RFC 4861, so this is just an operational practice.
>>
>> That's incorrect. We are talking about sending multicasted internetlayer
>> packets to a unicast link-layer address. 
> 
> No. It's more subtle than that. We are talking about sending packets with
> a LL multicast destination address to a unicast LL address. The packets
> are not in fact multicasted, although the recipient will in fact receive
> them on a multicast socket.
> 
> Again I ask, so what? It may be different from what we thought of in 1998,
> but I simply don't see why it's problematic.
> 
> 
>> There's nothing in RFC4861 that
>> suggests you should do that. RFC6085 says "you shouldn't drop packets if
>> they are internet-layer multicast but link-layer unicast". But
>> certainly, unless a protocol spec says otherwise, the normal mapping
>> applies.
> 
> Actually RFC6085 also says: " This document
>    extends this mapping to explicitly allow for a mapping of an IPv6
>    packet with a multicast destination address into an Ethernet link-
>    layer unicast address, when it is clear that only one address is
>    relevant."
> 
> That seems to apply perfectly here.
>  
>> There's nothing in RFC4862 that may suggest "leasing one prefix per
>> node". 
> 
> No. That is the operational innovation in the present draft.
> 
>> In fact, all nodes share all the prefixes being announced. 
> 
> All nodes that receive the announcement share it. In this operational
> mode, only one node receives it. Again, what's the problem?
> 
>> And
>> when you don't want multiple nodes to share them, you just segment the
>> network one way or another. From the point of view of SLAAC, there's no
>> "one prefix per node". If it happens, it's because you segmented the
>> network, not because SLAAC is meant for that.
> 
> Yes, effectively this draft does segment the LAN from a logical
> viewpoint. Why is that a problem?
> 
>>
>>
>>
>>>     Looking at diffs, it seems this additional text was incorporated very
>>>     recently, in version -09 of the I-D, published in mid September
>>>     (>>     >).
>>>     It seems to be that this change is way beyond what the authors
>>>     originally proposed
>>>
>>> The additional text did not actually change this practice at all.> It
>>> simply clarified what has always been a fundamental premise of this
>>> operational practice: if you want to give each host its own prefix, you
>>> need to ensure that the RA with that prefix is only received by that host.
>>
>> If you want to give each host it's own prefix, you do prefix delegation.
>> So far, SLAAC doesn't do prefix delegation. If you want to do prefix
>> delegation in slaac, write a std track document in 6man, not a BCP in
>> v6ops.
> 
> That would be a more complicated way of getting the same result.
>  
>>>     1) The protocol spec specified in this document requires the SLAAC
>>>     router to keep state of the "leased" prefixes -- what seems a major
>>>     change to SLAAC, which now would be kind of as stateful as DHCPv6.
>>>
>>> This is a bizarre claim. The first-hop router must always have fully
>>> up-to-date state on all the prefixes it is sending RAs for, otherwise it
>>> cannot fulfill its fundamental purpose of forwarding traffic to those
>>> prefixes. The word "stateless" in SLAAC applies to addresses configured
>>> to the host, not how routers route traffic.
>>
>> A SLAAC router need not maintain any sort of dynamic mapping. It's
>> static configuration information of the sort "I'm announcing this prefix
>> on this interface".. If you think otherwise, please point me the section
>> in RFC4862 where this conceptual data structure is mentioned. (Note:
>> Neighbor Cache, Destination Cache, etc. are all mentioned in RFC4861).
> 
> Sure. The implementation will need a data structure per host, not per
> interface. Any way of handing out prefixes needs that. Why should I care?
> 
>>
>>
>>
>>>     2) There are scenarios in which multiple nodes might receive the same
>>>     packet -- say a NIC let's the packet through because it is in
>>>     promiscuous mode -- wich could possibly lead to two nodes configuring
>>>     the same prefix.
>>>
>>> Why do you say promiscuous mode is a problem? Even in promiscuous mode,
>>> network stacks already understand which packets are being send to the
>>> host network stack and which are not. For example, in the linux
>>> networking stack, well before the packet ever gets to the ICMPv6
>>> protocol handlers that would process incoming RAs, ipv6_rcv does:
>>>
>>> if (skb->pkt_type == PACKET_OTHERHOST) {
>>> kfree_skb(skb);
>>> return NET_RX_DROP;
>>> }
>>
>> Great that Linux double-checks this. But it need not. Linux is just one
>> implementation. A very popular one. But one implementation.
>>
>>
>>
>>
>>>     3) What happens if the SLAAC router crashes and reboots, loosing state
>>>     of the "leased" prefixes?
>>>
>>> You seem to be assuming that the router does not store the prefixes in
>>> stable storage.
>>
>> Routers store configuration info, not dynamic mappings.
> 
> I think that depends on the router. Configs are not static in the general
> case anyway.
> 
>>
>> Simple scenario:
>>
>> With slaac, the network is 100% resilient if a rotuer crashes and
>> reboots (because, as the name implies, it is stateless). With this
>> protocol you are specifying in this document, if the router crashes and
>> reboots, the network may just break -- same prefix may be reassigned to
>> different nodes, etc.
>>
>>
>>
>>> It's certainly the case that if you want this scheme to
>>> work across router crashes, then you need to ensure that the prefixes
>>> are stored somewhere. That sort of seems self-evident, but we could add
>>> it to the text.
>>
>> SLAAC stores *configuration information*. This protocol that you are
>> specifying requires SLAAC to store the *dynamic mappings* of which
>> prefix was "leased" to which host. And the fact that you need this for
>> this mechanism to work is an indication that you are specifying a
>> protocol. (Call it Stateful SLAAC, or AAC ;-) )
>>
>> An operational practice is when you fiddle with the knobs that a
>> protocol gives you. Here you are introducing a state machine into SLAAC.
>> That's certainly not an operational practice, but rather a fundamental
>> change to SLAAC that makes it a stateful protocol
> 
> It's not in SLAAC. It's almost certainly a layer above SLAAC.
> 
>    Brian
>>
>>
>>
>>>     4) How are prefixes selected? And, what's the minimum size of the pool
>>>     of prefixes for the selection algorithm not to break due two "prefix
>>>     collisions"? Does the selection algorithm have any specific properties?
>>>
>>> I see no reason why this should be in scope for this document.
>>
>> Actually, what's not in the scope of this document, and not within v6ops
>> charter, is the protocol you are specifying to handle prefixes with SLAAC.
>>
>> Thanks,
>>
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


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





From nobody Fri Nov 10 12:21:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524E4128CD5; Fri, 10 Nov 2017 12:21:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEujzgAS5onT; Fri, 10 Nov 2017 12:21:47 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6167129476; Fri, 10 Nov 2017 12:21:46 -0800 (PST)
Received: from [10.234.32.137] (unknown [87.200.50.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5194082995; Fri, 10 Nov 2017 21:21:43 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fred Baker , Lorenzo Colitti 
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References:   
From: Fernando Gont 
Message-ID: <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com>
Date: Fri, 10 Nov 2017 17:23:29 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 20:21:48 -0000

Hi, Fred,

On 11/10/2017 01:12 AM, Fred Baker wrote:
> 
> 
>> On Nov 9, 2017, at 8:28 AM, Lorenzo Colitti  wrote:
>>
>> On Tue, Nov 7, 2017 at 6:13 AM, Fernando Gont  wrote:
>> While reviewing this document a few days ago, I found that Section 4
>> (page 5) contains what is a protocol spec, rather than an operational
>> BCP. It contains rules regarding how to set the link-layer address (to a
>> unicast address) for IPv6 multicasted RAs, and how a SLAAC router should
>> now remember which prefix has been "leased" to which node -- something
>> that seems to be way outside of the v6ops charter, and that should have
>> been done in 6man, instead.
>>
>> I don't see how this is a protocol change. Sending RAs unicast is already allowed by RFC 4861, so this is just an operational practice.
> 
> I understand the concern to be sending to a multicast address at the network layer and a unicast address at the link layer. If 4861 allows the RA to be sent unicast, it is probably unicast at both layers. I suspect that if we change to doing what 4861 describes we'll be fine.

At which point you realize that know you have to no implement the
graituous  all-nodes RAs, and it becomes evident that you are changing
the spec.

THe main issue is not this but, as the subject implies, this document
making SLAAC stateful.

But, anyway, it should be easy to have all of us converge on something:
the whole discussion boils down to whether this is or is not a protocol
spec.

So, my request would be. For folks arguing that this document is not a
protocol spec, could you please provide a definition of what a protocol
is, and subsequently explain why/how such definition does not encompass
this document?

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





From nobody Fri Nov 10 12:33:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C430129489; Fri, 10 Nov 2017 12:33:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrIJrFCBofW2; Fri, 10 Nov 2017 12:33:31 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D18F129481; Fri, 10 Nov 2017 12:33:31 -0800 (PST)
Received: from [10.234.32.137] (unknown [87.200.50.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6B23B8049D; Fri, 10 Nov 2017 21:33:26 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: joel jaeggli , Erik Kline 
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References:   <65664ca5-b8fe-0ca0-82fc-99e120426aea@si6networks.com> 
From: Fernando Gont 
Message-ID: <0abf5614-c5a0-2942-771b-29426bd4cba8@si6networks.com>
Date: Fri, 10 Nov 2017 17:34:59 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 20:33:33 -0000

On 11/10/2017 02:57 AM, joel jaeggli wrote:
> On 11/9/17 16:05, Fernando Gont wrote:
>> On 11/09/2017 12:02 AM, Erik Kline wrote:
[....]
>>
>>
>>
>>> My understanding was that in the original motivating wifi deployment
>>> every node is effectively isolated in its own (pseudo)VLAN, and
>>> node-to-node traffic must be routed through the infrastructure (to the
>>> extent such a thing can actually be enforced in a medium like wifi).
>>
>> Describing the virtues of one prefix per node, or how isolating nodes
>> (no "on link prefix") or the like are all fine for an informational
>> document, or even as a BCP (if that's how the wg feels).
> 
> there is an available recourse to an onlink prefix in form of the
> link-local address for a deligated prefix.
> 
>    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
> 
> https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13#section-4

Fine with that. Then one would need to specify that a different prefix
should be announced to each node (based on the source addr of the RS?).
And also specify when you stop doing that. Or when you consider that
such prefix is no longer in use. And what you do if you run out of
available/free prefixes.

Isn't that a protocol? I wonder how folks define what a protocol is...

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





From nobody Fri Nov 10 12:42:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B76124B17; Fri, 10 Nov 2017 12:42:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMtXcB9ciYbD; Fri, 10 Nov 2017 12:42:44 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650F7126B7E; Fri, 10 Nov 2017 12:42:44 -0800 (PST)
Received: from h.hanazo.no (dhcp-9788.meeting.ietf.org [31.133.151.136]) (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 6FE6F2D5038; Fri, 10 Nov 2017 20:42:43 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 05913200B94A31; Sat, 11 Nov 2017 04:42:32 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_616D6661-8BF3-4E15-8C22-5D96CE71EF16"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Sat, 11 Nov 2017 04:42:31 +0800
In-Reply-To: 
Cc: Brian E Carpenter , v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>
To: Fernando Gont 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> 
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 20:42:46 -0000

--Apple-Mail=_616D6661-8BF3-4E15-8C22-5D96CE71EF16
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> 1) My comment to the list was essentially arguing that this document
> contains a protocol specification, and such part is not suitable. I
> think it should be easy to converge on something regarding this one:
>=20
> Can anyone (you, for instance), provide a definition of what is a
> protocol, and the run this document through such definition and figure
> out if it fits or it doesn't?


A protocol is a system of rules that allow _two_ or more nodes to =
communicate.
The protocol specifies the syntax, semantics and so on (1).

A protocol specification does not specify only the wire format.

'unique-ipv6-prefix' does not specify changes in the wire-format, nor =
its semantics.
It only requires implementation change on one 'side' of the protocol, =
namely on the routers.
=46rom that perspective I think you can argue that this is not a =
protocol specification.

I think you also make a point that there are further considerations =
here, than just the wire-format. Especially around additional state in =
the routers. In the early days of IPv6 design a lot of time and effort =
was made in avoiding state in the network. If this mechanism made =
address allocation inherently less robust, I think a case could be made =
for why the IETF should specify this in more detail.
I am not convinced of that though. (In my implementation per host prefix =
adds configured state, but dramatically lessens dynamic state (ND)).

Interesting question.

Cheers,
Ole

PS: This draft also raises some interesting IETF process issues around =
change control, oversight and how involved the working group should be =
in changes happening after the document is handed over to the IESG.

1:Freely borrowed from wikipedia.

--Apple-Mail=_616D6661-8BF3-4E15-8C22-5D96CE71EF16
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+/bDNdvtpYqJhC33YFAloGDzcACgkQvtpYqJhC
33ZV7RAAy/gYnL0KStvJ0NMriRzrJjEymXKTU/MhlEgGCxQ+ahte5G9AMHTSlDYn
27gvs27I4MdQpL6rQtkNYXKhaRytIaaLSjaTK+kW8qlIPcZ43q0eQ4Jaf52S85D9
vyfLAiWWlp4fZDoVWGW+lwq0QcxJAsM6nqvqfs3x04Y5qgA8KPCWMFB1+9rr0gmX
JNsY7pG6Jx3CjmHXrXschGVnmmr8Imvhv4QP+U07XhuaHliDaroykug6qjBNGIy2
aJjM0fsbMrIoNfJ6n1/CQBaBTmSmHJGMjHdoEasQ06rm8adR6nWHVS0ZbF8j9ny7
5ZKHwYIhnDX7IQJGYQMpCitiN0fbO8LYBZCvHQzf/oiSz5WH9Z1Yld7FJ1KUeFZp
YOxAvhCv5taMX69Un6YtiWiKxLPM0SUPcARldRvmXJSTzYshWL9hLrj/fKyZRTB1
arRsMddcEJ80g41ittPy1I3ND0KbheWRkBsEeBq94a0ldtEA8YPyQ15mBT+f+NPn
+tyr2BV+OUXFGw2q4a2XQIveuQO6ryoi3TRZXcqoaRMvi4HafFlJTph00WEEL4IY
3yJCMuue/tiBypLGQ6bXl0HbXp9x6mLvuhJ2rj7tDMZJb4fNry/NXywXUHHJPFHw
AqdI3/NH0gugbxlb+kfhiHzH4IETM3wvzP5hVUcyhewbtoL/sN0=
=FUId
-----END PGP SIGNATURE-----

--Apple-Mail=_616D6661-8BF3-4E15-8C22-5D96CE71EF16--


From nobody Fri Nov 10 13:05:46 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CDF1200CF; Fri, 10 Nov 2017 13:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DE1XypflPC1l; Fri, 10 Nov 2017 13:05:42 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47FC129479; Fri, 10 Nov 2017 13:05:42 -0800 (PST)
Received: from [10.234.32.137] (unknown [87.200.50.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9EFB182983; Fri, 10 Nov 2017 22:05:38 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ole Troan 
Cc: Brian E Carpenter , v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>  
From: Fernando Gont 
Message-ID: 
Date: Fri, 10 Nov 2017 18:04:39 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 21:05:44 -0000

On 11/10/2017 05:42 PM, Ole Troan wrote:
>> 1) My comment to the list was essentially arguing that this
>> document contains a protocol specification, and such part is not
>> suitable. I think it should be easy to converge on something
>> regarding this one:
>> 
>> Can anyone (you, for instance), provide a definition of what is a 
>> protocol, and the run this document through such definition and
>> figure out if it fits or it doesn't?
> 
> 
> A protocol is a system of rules that allow _two_ or more nodes to
> communicate. The protocol specifies the syntax, semantics and so on
> (1).
> 
> A protocol specification does not specify only the wire format.
> 
> 'unique-ipv6-prefix' does not specify changes in the wire-format, nor
> its semantics. It only requires implementation change on one 'side'
> of the protocol, namely on the routers. From that perspective I think
> you can argue that this is not a protocol specification.

How do you get from this: "it only requires implementation change on one
'side' of the protocol" to this: "From that perspective I think you can
argue that this is not a protocol specification". (First sentence
acknowledges it *is* a protocol)



> I think you also make a point that there are further considerations
> here, than just the wire-format. Especially around additional state
> in the routers. In the early days of IPv6 design a lot of time and
> effort was made in avoiding state in the network. If this mechanism
> made address allocation inherently less robust, I think a case could
> be made for why the IETF should specify this in more detail.

Indeed it does:

Current SLAAC: Router crashed and reboots -> network doesn't break

This document: Router carshes and reboots -> who knows what happens.
(Not only this protocol requires state that wasn't required for SLAAC,
but now you also need the mappings to be maintained on stable storage.
Otherwise, if the router crashes and reboots, the netwoks will most
likely break).



> I am not convinced of that though. (In my implementation per host
> prefix adds configured state, but dramatically lessens dynamic state
> (ND)).

What do you mean by "configured state"?



> Interesting question.
> 
> Cheers, Ole
> 
> PS: This draft also raises some interesting IETF process issues
> around change control, oversight and how involved the working group
> should be in changes happening after the document is handed over to
> the IESG.

Indeed.

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





From nobody Fri Nov 10 13:25:43 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D771294B2 for ; Fri, 10 Nov 2017 13:25:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 cFPeo5sD4-a4 for ; Fri, 10 Nov 2017 13:25:31 -0800 (PST)
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 0E9511294C9 for <6man@ietf.org>; Fri, 10 Nov 2017 13:25:28 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 14054B37 for <6man@ietf.org>; Fri, 10 Nov 2017 21:25:28 +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 KFqzUQg_9-hR for <6man@ietf.org>; Fri, 10 Nov 2017 15:25:27 -0600 (CST)
Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id A76D269F for <6man@ietf.org>; Fri, 10 Nov 2017 15:25:27 -0600 (CST)
Received: by mail-lf0-f71.google.com with SMTP id t5so2802808lfe.1 for <6man@ietf.org>; Fri, 10 Nov 2017 13:25:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=enoORXUFwaNNGUg+DsBWUz/VrsjCI94lfD3MYFPF8iY=; b=IXUQ8qlO8J1KUmLiCIg30FIuwJGz8fWVOLUxvlgMTwYvrQa7wru1jBuJKLE48sknEI yXMQePxoSMP0ta284nxgE99W918YDUViRy5egIPmhCM9BmWXaHNFm9s6Sz/9/UcdvI6N UOisLh6KiHm1sgqzrsyo+dOkRVUQ45/iqdKUGpExDWSSLqx8fiArEw/U0UfNvpnjVeBO 9OV10mbDENKAUDGWnQ5DQXl3Wv/mfUdtWLIku7SR3fbJYSW3Uyo6F3aF9MelP9HqZNLc KyienVwu4gdZR89uTIrvGC1qVBH+l5SOyFdKCMFL3y9+ilHEVqo9yLnNOBUK5Oxyh9lg 1pcg==
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=enoORXUFwaNNGUg+DsBWUz/VrsjCI94lfD3MYFPF8iY=; b=p1Ss0B/Qe+si3hQ/TArGbUnSggoPfebhCZO5aXr0i/Vn8gGacdcaG2kvn5ldCNETgl TBraodbilj/lsSq055lWBeenvY9sjedt9e/V7E3NqwzU4w83+ewNSbTWBWsMZw7MkRsQ blEL3bHMdiSQ2cZWuv4F6WALJByxslMyxs9qGfqiIH21dEw4kh+flYmI7YjoWO3mqSiK gctukt4P+RmbMULed7CPtNjrPOCqVVa+LaoLkOMm73cYP+FlD17sGT6anOySdPsnxHlW 9Z19EEcjH4/+r9QatG0KHIXMn6/bl9FkKd9ci0dcEpa/SKkEeuPXOzQpulWi/LXvhKsu JWvw==
X-Gm-Message-State: AJaThX60CF0a8o7MezL1RdqcCPhodJvoyBs8TA63XME1O07fok6DrcWw gDCkWGh9Doil86WURD7sx2QiBbU3jnoZ2cIAb5UEnTliURTVz8kdNWjiYDMrMC+ptcNuLcP8W+F HAXWvWkO//uclYyfwNnD2UhDB
X-Received: by 10.25.37.201 with SMTP id l192mr562674lfl.35.1510349125783; Fri, 10 Nov 2017 13:25:25 -0800 (PST)
X-Google-Smtp-Source: AGs4zMZHcKJHHVjefr2i21T0jHFQSPC3/h4+VMF/DoGhWPqnd/0/M/BNzKcS8bZGTCbbXUvikIh5HayOoOO62+asUL0=
X-Received: by 10.25.37.201 with SMTP id l192mr562671lfl.35.1510349125507; Fri, 10 Nov 2017 13:25:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Fri, 10 Nov 2017 13:25:24 -0800 (PST)
In-Reply-To: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> 
From: David Farmer 
Date: Fri, 10 Nov 2017 15:25:24 -0600
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: Brian E Carpenter , V6 Ops List , "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="001a114106701d13d6055da78f01"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 21:25:33 -0000

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

On Thu, Nov 9, 2017 at 8:35 PM, Fernando Gont  wrote:

> Hi, Brian,
>
> Please let me top-post to try to focus the discussion here:
>
> 1) My comment to the list was essentially arguing that this document
> contains a protocol specification, and such part is not suitable. I
> think it should be easy to converge on something regarding this one:
>

I can see how you might have come to that conclusion.  However, I don't
believe the document defines a new protocol or actually changes the old
one. As I see it, the document merely points out an interaction between two
existing protocol specifications, that allows for a desired implementation
outcome of providing a unique prefixes per host using SLAAC. Those being
primarily RFC4861 section 6.2.4, "Sending Unsolicited Router
Advertisements" and RFC6085 "Address Mapping of IPv6 Multicast Packets on
Ethernet".  The desired result is consistent with the protocols as they are
currently defined, the document doesn't change anything, it only points out
facts of the current specifications that may not be entirely obvious to
everyone implementing the specifications and that are critical to the
desired outcome of the draft.  Or put another way, the document specifies
how to implement to the current protocols consistent the desired outcome of
providing a unique prefixes per host.

What track IETF document is needed to accomplish that, is a judgment call
for the IESG, as I see it there are valid arguments for this to be a
standards track, BCP, or an informational document.

However, I'm fine with the current status of BCP personally.

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
===============================================

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




On Thu, Nov 9, 2017 at 8:35 PM, Fernando Gont <fgont@si6networks.c=
om> wrote:
Hi, Brian,



Please let me top-post to try to focus the discussion here:



1) My comment to the list was essentially arguing that this document

contains a protocol specification, and such part is not suitable. I

think it should be easy to converge on something regarding this one:

I can see how you might have come to that con=
clusion.=C2=A0 However, I don't believe the document defines a new prot=
ocol or actually changes the old one. As I see it, the document merely poin=
ts out an interaction between two existing protocol specifications, that al=
lows for a desired implementation outcome of providing a unique prefixes pe=
r host using SLAAC. Those being primarily RFC4861 section 6.2.4, "Send=
ing Unsolicited Router Advertisements" and RFC6085 "Address Mappi=
ng of IPv6 Multicast Packets on Ethernet".=C2=A0 The desired result is=
 consistent with the protocols as they are currently defined, the document =
doesn't change anything, it only points out facts of the current specif=
ications that may not be entirely obvious to everyone implementing the spec=
ifications and that are critical to the desired outcome of the draft.=C2=A0=
 Or put another way, the document specifies how to implement to the current=
 protocols consistent the desired outcome of providing a unique prefixes pe=
r host.=C2=A0 =C2=A0

What track IETF document is n=
eeded to accomplish that, is a judgment call for the IESG, as I see it ther=
e are valid arguments for this to be a standards track, BCP, or an informat=
ional document.

However, I'm fine with the cur=
rent status of BCP personally.

Thanks.
<=
br>
-- 
=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 




--001a114106701d13d6055da78f01--


From nobody Fri Nov 10 13:46:00 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D765A1294B2; Fri, 10 Nov 2017 13:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qim6zaULi_jI; Fri, 10 Nov 2017 13:45:52 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDA0126BF3; Fri, 10 Nov 2017 13:45:52 -0800 (PST)
Received: from h.hanazo.no (dhcp-9788.meeting.ietf.org [31.133.151.136]) (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 476032D4F99; Fri, 10 Nov 2017 21:45:51 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8B1FA200BA6881; Sat, 11 Nov 2017 05:45:38 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_E7D7C374-6759-4DF2-A43F-885B6327E922"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Sat, 11 Nov 2017 05:45:37 +0800
In-Reply-To: 
Cc: Brian E Carpenter , v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>
To: Fernando Gont 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>   
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 21:45:54 -0000

--Apple-Mail=_E7D7C374-6759-4DF2-A43F-885B6327E922
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Fernando,

> On 11 Nov 2017, at 05:04, Fernando Gont  wrote:
>=20
> On 11/10/2017 05:42 PM, Ole Troan wrote:
>>> 1) My comment to the list was essentially arguing that this
>>> document contains a protocol specification, and such part is not
>>> suitable. I think it should be easy to converge on something
>>> regarding this one:
>>>=20
>>> Can anyone (you, for instance), provide a definition of what is a
>>> protocol, and the run this document through such definition and
>>> figure out if it fits or it doesn't?
>>=20
>>=20
>> A protocol is a system of rules that allow _two_ or more nodes to
>> communicate. The protocol specifies the syntax, semantics and so on
>> (1).
>>=20
>> A protocol specification does not specify only the wire format.
>>=20
>> 'unique-ipv6-prefix' does not specify changes in the wire-format, nor
>> its semantics. It only requires implementation change on one 'side'
>> of the protocol, namely on the routers. =46rom that perspective I =
think
>> you can argue that this is not a protocol specification.
>=20
> How do you get from this: "it only requires implementation change on =
one
> 'side' of the protocol" to this: "=46rom that perspective I think you =
can
> argue that this is not a protocol specification". (First sentence
> acknowledges it *is* a protocol)

For it to be a new protocol (or protocol change, it requires _two_ or =
more communicating entities to be updated.
(The reference above was to the ND/SLAAC protocol.)
Proven by the fact that the host does not change, it doesn't change the =
ND protocol.
(With the set of reservations outlines in previous email).

Cheers,
Ole


--Apple-Mail=_E7D7C374-6759-4DF2-A43F-885B6327E922
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+/bDNdvtpYqJhC33YFAloGHgEACgkQvtpYqJhC
33aw/g/+JxfRj9h9LToajUQoz27jBhLd2+FxwtCPLv1w9SH0fq+KJnWv87xiGymF
cZTEMNg1L+DBa4zefroaCDjqP9DUZ0ITEuVHf3GnbwFvCLgvQ/01TgTAMBuTW3Ax
zc9M1YjCnXRghnXSNOAlRhmcv0BO2zVZnCJph38HG+KhxtWA64dnvScyx+GXVKWp
QbHHqkSpwPLKDQkl6sXPTK7W/Qx9CpDpb1Obrlfe4TijRVwnyWZN6Cd7bm4Wp4BG
A7XaxSnYCEN+qefm9bYofggPor9jp2PwhXIbjgjiU/V6vfbQGOn/N9D+uAfUXLPa
16Km6Chv49hzedjdop4XC3gkP6XFwwZe0Ui+eDxz3aDpOMj3TgKmcMHpvHj9bZ1E
Y3jQVCKGDkPa/lWs5hxjil/jOlHKE8n7ckdoBvMNjuSHTYstp+9J5nnaM2cfnMdN
LU25AMHlwJq+OrgftZEF2e35Y6wFo1AEUmDz6qx9FYRP7Ld3EnbrsREQNvnVqUF9
XAxnBpc8wLPh+WunJebk4pm6E1sFMng4Hs9u8tAsW31T/P7SeefoLZy1Gko49KLP
si7vgQW9BUZkq9sxR2MlRJ0dSb0pfeEgEcYalxxlqHFgTDynQjxAPn2hXIkquVJC
THCMwKxBEtIeD7vqtTwRY13+PvNxxsiT/aHNGM4w0BJ2DII2kkk=
=FG1o
-----END PGP SIGNATURE-----

--Apple-Mail=_E7D7C374-6759-4DF2-A43F-885B6327E922--


From nobody Fri Nov 10 13:52:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0604F1271DF; Fri, 10 Nov 2017 13:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDCKRTHSgb84; Fri, 10 Nov 2017 13:52:48 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB0C126BF3; Fri, 10 Nov 2017 13:52:48 -0800 (PST)
Received: from h.hanazo.no (dhcp-9788.meeting.ietf.org [31.133.151.136]) (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 A2A542D50AE; Fri, 10 Nov 2017 21:52:47 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C0C8E200BA764B; Sat, 11 Nov 2017 05:52:38 +0800 (+08)
From: Ole Troan 
Message-Id: <6D004D8F-2ADD-49AE-BB87-575C74F12E9E@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_998732A2-48A5-494E-99BF-8E83DD1AF107"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Sat, 11 Nov 2017 05:52:37 +0800
In-Reply-To: 
Cc: Brian E Carpenter , v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>
To: Fernando Gont 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>   
X-Mailer: Apple Mail (2.3445.1.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 21:52:50 -0000

--Apple-Mail=_998732A2-48A5-494E-99BF-8E83DD1AF107
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

>> I think you also make a point that there are further considerations
>> here, than just the wire-format. Especially around additional state
>> in the routers. In the early days of IPv6 design a lot of time and
>> effort was made in avoiding state in the network. If this mechanism
>> made address allocation inherently less robust, I think a case could
>> be made for why the IETF should specify this in more detail.
>=20
> Indeed it does:
>=20
> Current SLAAC: Router crashed and reboots -> network doesn't break
>=20
> This document: Router carshes and reboots -> who knows what happens.
> (Not only this protocol requires state that wasn't required for SLAAC,
> but now you also need the mappings to be maintained on stable storage.
> Otherwise, if the router crashes and reboots, the netwoks will most
> likely break).

If you read this document as an operational document, describing one =
potential deployment scenario, then those considerations are left as an =
exercise to the operator. I.e. don't deploy this in cases where this can =
happen.

If this has been a protocol specification, I agree that would not be =
acceptable.

>> I am not convinced of that though. (In my implementation per host
>> prefix adds configured state, but dramatically lessens dynamic state
>> (ND)).
>=20
> What do you mean by "configured state"?
>=20

In SLAAC, routers require that the IPv6 prefix is configured on the =
interface.
You can also implement this mechanism in that way.
It is still state, but different dynamically discovered state like the =
ND cache, or dynamic and non-recoverable state like what you get with =
middleboxes.

Best regards,
Ole

--Apple-Mail=_998732A2-48A5-494E-99BF-8E83DD1AF107
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+/bDNdvtpYqJhC33YFAloGH6UACgkQvtpYqJhC
33bOIRAAiozQjBN2zo8QZ8cOu623/Kx5zLNRgPukOC8WbRj3Vwf0Gn3+KLdd/tkd
9pE7IZVqhAiea9LVof/Gxnz8PwN5v5ECwai6Z8yXap1Jrr8/0tPDKJUllxr8G7t8
RlB4NJ0rDwGsZ1HEEinwXzi6on4Wt+gbovqW6oMz5Qmo5a3notNGlt6zn4p5oYM5
1eBn1vepMYhT3b/a1gdmn4erlrvCKXw3JovFYw8QJjQWgIvq+VNeDSi+EbURjpai
XIyFBAsDWlXRgb9EXxZtw8lAi4JD+WfK7HJeeXlW4CBhLZ0ekaEU8nYhyTvWzheU
bYEm/OSlVjkIGEQDPPA5BX2mRCKQgrHYPtA/KdQv6+2ID1sE8TAiYNVw9ZgA5Oqa
RHEKASCcGuTOePeEyU7eJ0UIMGCJ5BA2n/19YXwqmP8+fKntpbIG/HCTvnauXOdy
geeQIioj7nEl7KKBCSVckau/+bmuRMDdKy97RDgaaGNTdTC4H/zlDOIu1KN7BFki
jvmITVBuC2gL0SiQn0wDsk6NQ9B3byaPKDT+nXiQTaTcancT8VWfZlgwIPbpqCm8
SGn7+S6OOQr+I3lGq6z6c5hVCgCu//XwZYsgIMDrx7FAufFTezPkY490lqh/0DDY
4JgKbotKQdCcRPl2LY9y3iqFyJFQsGCvdg+ia5jZ3ZIpDP4yon4=
=PKQ1
-----END PGP SIGNATURE-----

--Apple-Mail=_998732A2-48A5-494E-99BF-8E83DD1AF107--


From nobody Fri Nov 10 13:58:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AC61200C5 for ; Fri, 10 Nov 2017 13:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 n389AFbklevV for ; Fri, 10 Nov 2017 13:58:44 -0800 (PST)
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 A20731294B7 for <6man@ietf.org>; Fri, 10 Nov 2017 13:58:41 -0800 (PST)
Received: by mail-io0-x233.google.com with SMTP id d66so15047383ioe.5 for <6man@ietf.org>; Fri, 10 Nov 2017 13:58:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xcLr/IJVznYNWLS2NPY1l1i2Z/56Vat15itKtcoYSpc=; b=qiZofiSf5ehsH2wA9Z4yzElOFhIZIAgFzk2c8V6pXVT6mIX9fFA4jQzxhkwvp6pcDv HQsVBNzAHqSdEsq+426q0iRFFkUN+nqDOVSZR/yCnLY7QliNvuoIzSQZgREIaJZqXWzR vxQh4Zwfvb2o5qJ+G1msJkDOZA9WE6dmi3q619f2OOZW6ICZtRWdNX5cyPoohBRzFFxJ d3dNc1uJpi2oBlBcRn4Bm6H/hM9hcW/ybzg2BMdnJTtyBQs5m/jemWcKe0I1iDFPd6fC MR3fLb11ooZs7pXUmM0PbAGHL/n7Yt/WrgXzr79cG62+F5pSvhxHOo3kVCyBQ9IUT6nD G85Q==
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=xcLr/IJVznYNWLS2NPY1l1i2Z/56Vat15itKtcoYSpc=; b=CX32TQkmEbW89xljaDTqAVFtHO95Ulqhnu2S4SJn1AWR/g7ZNye+Zdl4JusAWyJV3t QL6cYLFQADLYGHHBXX3a9dDB7KCOyydIpJ/PQptWqd4jvdT6PnhWF8yxHWHCO92k5sOr EaXT46kvLJptMCEsuPYSX1QjHKMfqSTbtUrdovsRUcmdQSgLLASSYLTO8TiL8bpuXEtq HwZpJ7rzMq7gYUtwx6zdQ66YyOoLjkO6j4s0/GWNVfVGJfjRuZnywwSEFuqDlr87PxeR Tr3Cjm0M/u5AzGYzFIt4+Vu1hVcfUUx2LRgJuq6ioi60IagY/HDIT9LlqqPYjAvy7IO+ A+sw==
X-Gm-Message-State: AJaThX6xcfm9RWEsPI7ZvxgfzXmoBESXz4XkTn+sQ0Zf7Sd7JP0JCGOt QeA5MT4CsOu7sx/l3yBWmIdqsw==
X-Google-Smtp-Source: AGs4zMbl1YmtEO1uPK7kTXeVp1xk+4L5pA1koR23thBLVsXadYjKXCLvSynQ7QOffrCpA29I2XHrUw==
X-Received: by 10.107.55.198 with SMTP id e189mr2109781ioa.70.1510351120425; Fri, 10 Nov 2017 13:58:40 -0800 (PST)
Received: from dhcp-100-99-229-233.pao.corp.google.com ([100.99.229.233]) by smtp.gmail.com with ESMTPSA id a72sm1366874itb.34.2017.11.10.13.58.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 13:58:39 -0800 (PST)
From: james woodyatt 
Message-Id: <52C752BD-2347-4704-9103-89BD979D7C2D@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6F51B085-143B-4F1D-A798-4563E6031C6E"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Fri, 10 Nov 2017 13:58:37 -0800
In-Reply-To: <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com>
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
To: Fernando Gont 
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 21:58:45 -0000

--Apple-Mail=_6F51B085-143B-4F1D-A798-4563E6031C6E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 10, 2017, at 12:23, Fernando Gont  wrote:
>=20
> So, my request would be. For folks arguing that this document is not a
> protocol spec, could you please provide a definition of what a =
protocol
> is, and subsequently explain why/how such definition does not =
encompass
> this document?


I think the definition of =E2=80=9Cprotocol=E2=80=9D in the New Oxford =
Dictionary is adequate. Its entry includes a specialization for =
=E2=80=9CComputing=E2=80=9D that reads as follows:

	Computing a set of rules governing the exchange or transmission =
of data between devices.

This document does not introduce any new rules governing the exchange of =
data between a provider router and its subscriber hosts. It merely =
describes a strategy that providers may use under those rules for their =
routers to provide a set of unique prefixes to each subscriber host. The =
rules of the existing protocol specified by 6MAN remain unchanged, and =
one imagines that if 6MAN doesn=E2=80=99t approve of the strategy that =
V6OPS describes here, then it=E2=80=99s on 6MAN to revise the protocol =
accordingly.

One might think to counter that the strategy described here does include =
some explicit and implied requirements on provider routers to perform =
correctly the existing, already described, protocol for the indicated =
purpose, but those new requirements do not change the set of rules that =
govern the exchange, i.e. the protocol. In other words, this draft =
identifies only a set of further constraints on the behavior of one =
party in the protocol and describes those constraints as a Best Current =
Practice. Which is perfectly in line with the V6OPS charter.


--james woodyatt >




--Apple-Mail=_6F51B085-143B-4F1D-A798-4563E6031C6E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 10, 2017, at 12:23, Fernando Gont <fgont@si6networks.com> wrote:

So, my request =
would be. For folks arguing that this document is not a
protocol spec, could you please provide a =
definition of what a protocol
is, and =
subsequently explain why/how such definition does not =
encompass
this =
document?

I think the definition of =
=E2=80=9Cprotocol=E2=80=9D in the New Oxford Dictionary is adequate. Its =
entry includes a specialization for =E2=80=9CComputing=E2=80=9D that =
reads as follows:

	=
Computing a set of rules governing the exchange or =
transmission of data between devices.

This document does not introduce any new rules governing the =
exchange of data between a provider router and its subscriber hosts. It =
merely describes a strategy that providers may use under those rules for =
their routers to provide a set of unique prefixes to each subscriber =
host. The rules of the existing protocol specified by 6MAN remain =
unchanged, and one imagines that if 6MAN doesn=E2=80=99t approve of the =
strategy that V6OPS describes here, then it=E2=80=99s on 6MAN to revise =
the protocol accordingly.

One might think to counter that the strategy described here =
does include some explicit and implied requirements on provider routers =
to perform correctly the existing, already described, protocol for the =
indicated purpose, but those new requirements do not change the set of =
rules that govern the exchange, i.e. the protocol. In other words, this =
draft identifies only a set of further constraints on the behavior of =
one party in the protocol and describes those constraints as a Best =
Current Practice. Which is perfectly in line with the V6OPS =
charter.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_6F51B085-143B-4F1D-A798-4563E6031C6E--


From nobody Fri Nov 10 14:26:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD29A126D85; Fri, 10 Nov 2017 14:26:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzasXfAoHAU7; Fri, 10 Nov 2017 14:26:38 -0800 (PST)
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 A35CE1200E5; Fri, 10 Nov 2017 14:26:38 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id j28so5285159pfk.8; Fri, 10 Nov 2017 14:26:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eVFT0yzBXevPwbm9xUvZphg0YpNigtHwCSWrFqWLd40=; b=eYWEosD21iBegEEN+BQTh/ufhVipcFtfVeKgkub+r8+kDqb2VyFjoB2iufONlsm264 2xMzlnpz7xTZa1qsOBgqGCCaUWLZHlkK8kELG88XOSOUzBVYYPTiGiENcihArLxOLkhy p/maU+ypv3Gv0zfu25KWkPSfdiNXcsFZ+/6M4Ax/jWa0yj+GroySjsUGM4uFxirvVoPI 3cMJJruTqO0BKfb6aaTT0G/6Fiotknds6Ukm+kGlvDf+XMxZ6S+mJyBkYb6hn34vaohv A3MjW6vjTfrx/PsOyzyXwUvpJ801spv1QzeVu+W69tDLgA9duvDKXzGVhVDa9d3vQnpU 68jA==
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=eVFT0yzBXevPwbm9xUvZphg0YpNigtHwCSWrFqWLd40=; b=OOxofxZWOWUUYUsqTEyl2L7gfL9+kybeWka3CiNX/CDsDZWL0Todl01C6lPonncLYY tokZJ2JL7IqAyY5VyZokEuQDvcHrbxfdTuFEEhLtV7Rm25258ZSR9fNQgQC6pVJqRCHX kebHabfHR8dPJY4zABBUe+PQfzW2HxAdNNgzh26lgZu7AiIpm1+yXLRy70aKVKT8xqk+ Kbhm1zZLvAmle3H/pgTYxF8J0N+Arsktg7Pwr3xViDI6NocuF4k+6+YIS1WrE98p+2bB Q9+OSZjW39bBFJ+8aCdutxkvJpPRfR/fwZc4S+951VQf9AUcXuVDaOvlw6G04UCyl6S6 B2wg==
X-Gm-Message-State: AJaThX61SWqxTFfoUaLk92ks8Wr/yoTI+KUdtP6z3XUdmHGCE7a0a0et x0da48HEytja0R/j+FK7jaTDoA==
X-Google-Smtp-Source: AGs4zMZ0SwrLb1LD1rPjHkh/ziqMAk9er3Ys6s67yFWWUW1oujx8ccLTRt6z8fOqZX1tkgakW8wwDw==
X-Received: by 10.101.72.65 with SMTP id i1mr1720885pgs.436.1510352797834; Fri, 10 Nov 2017 14:26:37 -0800 (PST)
Received: from [192.168.41.64] (219-88-101-13.adsl.xtra.co.nz. [219.88.101.13]) by smtp.gmail.com with ESMTPSA id 19sm21640642pfj.154.2017.11.10.14.26.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 14:26:36 -0800 (PST)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ole Troan , Fernando Gont 
Cc: v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>  
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Sat, 11 Nov 2017 11:26:40 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 22:26:40 -0000

On 11/11/2017 09:42, Ole Troan wrote:
>> 1) My comment to the list was essentially arguing that this document
>> contains a protocol specification, and such part is not suitable. I
>> think it should be easy to converge on something regarding this one:
>>
>> Can anyone (you, for instance), provide a definition of what is a
>> protocol, and the run this document through such definition and figure
>> out if it fits or it doesn't?
> 
> 
> A protocol is a system of rules that allow _two_ or more nodes to communicate.
> The protocol specifies the syntax, semantics and so on (1).
> 
> A protocol specification does not specify only the wire format.
> 
> 'unique-ipv6-prefix' does not specify changes in the wire-format, nor its semantics.
> It only requires implementation change on one 'side' of the protocol, namely on the routers.
> From that perspective I think you can argue that this is not a protocol specification.

I agree with that, and other versions of the same argument. (That also
answers Fernando's message directed at me, so I won't waste more bits.)

More on the philosophy side of the argument, WG Charters are a tool to
allow the chairs and AD to control mission creep. They aren't sacred
texts. So IMHO the real question is not whether this is strictly speaking
a protocol extension, but whether it's a useful thing for the IETF to
publish.

    Brian


From nobody Fri Nov 10 16:36:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329AB126C83; Fri, 10 Nov 2017 16:36:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gmAVjSNJox3; Fri, 10 Nov 2017 16:36:45 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5F2124B09; Fri, 10 Nov 2017 16:36:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kfPniqMCgM93abaB0jw0BmrvITc2KY4y6b6A26o0txM=; b=48VPnHUnZXTU5svJZ6nI2k+dOk 63VPJ2x/E2rZARANAXaX6gi7PG+YUFtTsQD6+Ty+Q5ZWz8oALbPqDtJrSAzfvT0UaJj6/xro+mGRG Id4tYVm9ZDfDFxA6ARirBDHVg9GAYyHLc/aaRbT4CyrQHZ4cQsnSAov/r3Q04v7/HWexvuqOFjqVr CtqHyaRgnSvAk7pxuIN6Fh8aTenDW2ULzJmnCB7TOINqaMJUlzPSM+GODSPhPnNGy4+t+YGoLekBX ZKCicT8tTvDO7RfpDJH7SyTMpPAbOJwHzWfmWCmvDeQFwm1nK/Q8wqVrAmv28dgMygmOjqmbTbep4 IUWVfpdA==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:62884 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eDJmq-003Hpa-1h; Fri, 10 Nov 2017 19:36:42 -0500
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: james woodyatt , Fernando Gont 
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <52C752BD-2347-4704-9103-89BD979D7C2D@google.com>
From: Joe Touch 
Message-ID: <5fc6a1b1-7707-b5ab-7820-98f9f07b794c@strayalpha.com>
Date: Fri, 10 Nov 2017 16:36:34 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <52C752BD-2347-4704-9103-89BD979D7C2D@google.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 00:36:46 -0000

On 11/10/2017 1:58 PM, james woodyatt wrote:
>
> I think the definition of “protocol†in the New Oxford Dictionary is
> adequate.

The definition there is certainly true, but not adequate except for an
English paper. "rules" are too vague.

In networking, a protocol is:

    a set of rules
    a set of states
    a set of messages that are exchanged (often called the "on the wire"
part)
    a set of events/messages/actions that represent the behavior of each
endpoint (i.e., to upper layers)
    a set of time events
    a set of rules that relate incoming
messages/timer-events/user-actions and state to yield outgoing
messages/timer-sets/user-reports and new states

(the simplest way to express this is as a FSM, which is the most generic
form of computation where a machine cannot revoke its output - which is
why it accurately represents the ends of a protocol)

If you take away any of these (except state and, in limited cases,
time), you cease to have a useful protocol.

If you change any of these, you have a new protocol.

Joe


From nobody Fri Nov 10 16:38:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA643126C83; Fri, 10 Nov 2017 16:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 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, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdO-Oyb_EriI; Fri, 10 Nov 2017 16:38:38 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF522124B09; Fri, 10 Nov 2017 16:38:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GpZPwCrRnKnvK05UmgfCWwKzsOx2Lq0oK/8aFn74Efk=; b=D2lMnKAt1sqR5Y1yfDRx1bQgG 3Q2g916Lw6G5yChOuN5jFKntqt9JGeT37FL8ZcWfyRBY0YFftZjV9Fi0y/wR+ifkITVep0tf8jIok VQ9hLb8RF1/Jp4p8v67P1lZbyuvYMfmLJZQT+XTOf/Zp7DDmK43sQvfzR5dJs19TOwWrOV5ceipR5 3sy8yvp8+0V5PM+lj4s60oo4o93LSBpJdsQQRzpZjVG00g4+iQh9xSJaUYFv6yzZbvuy6lyqTP4+3 UbDJXmDSH4udenpohFv/BcQr0x+jk3TZKeIToF/9JduypIuApkjTFnkyEwK97qO/5ChdqhfqGpKwq zfp/trkWw==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:62904 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eDJoi-003MEM-Kd; Fri, 10 Nov 2017 19:38:37 -0500
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont , Ole Troan 
Cc: v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>   
From: Joe Touch 
Message-ID: <1cf8f6d6-8297-9f9f-7953-be6c775444c4@strayalpha.com>
Date: Fri, 10 Nov 2017 16:38:31 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------8AC8465487B759D72D309AC3"
Content-Language: en-US
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 00:38:40 -0000

This is a multi-part message in MIME format.
--------------8AC8465487B759D72D309AC3
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit



On 11/10/2017 1:04 PM, Fernando Gont wrote:
> How do you get from this: "it only requires implementation change on one
> 'side' of the protocol" to this: "From that perspective I think you can
> argue that this is not a protocol specification". (First sentence
> acknowledges it *is* a protocol)
FWIW, from my definition, if you change the rules of either side of a
communication system, you have changed the protocol. The protocol
describes the rules of ALL parties of the system as a set, not in isolation.

Joe

--------------8AC8465487B759D72D309AC3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    


    

    

    
On 11/10/2017 1:04 PM, Fernando Gont
      wrote:

    

    

      
How do you get from this: "it only requires implementation change on one
'side' of the protocol" to this: "From that perspective I think you can
argue that this is not a protocol specification". (First sentence
acknowledges it *is* a protocol)

    

    FWIW, from my definition, if you change the rules of either side of
    a communication system, you have changed the protocol. The protocol
    describes the rules of ALL parties of the system as a set, not in
    isolation.

    

    Joe

  


--------------8AC8465487B759D72D309AC3--


From nobody Fri Nov 10 16:41:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D75126C83; Fri, 10 Nov 2017 16:41:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level: 
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUdVupIr9XDe; Fri, 10 Nov 2017 16:41:27 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F11124B09; Fri, 10 Nov 2017 16:41:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Vt90UausM7pCdnIwsiPydA5D9Uq9+P95j49W/37jBac=; b=NHV1l14WdIHPOADyATCkXjnaMM Hi+kHAX3ZCsJzK5LDB6C9cjbqEbl62fwrihuKL0KB39LtEJuGbwr0h5dEUiIjjR9G5bZ852g7IiPW k7w02/yaYKiRx86o2jXEtaQ5x0EeS2tt7TyclADczuUot6nrIzyhUa7x00SwbYxIUbTe/bvbjfTV6 eNY5cIAw/nU3dJEHDQJqMOvGVVpXTNWmh45Y7RsHkC2M/5sYzOT2dS2rK+Xk93zMF+nvbkG6xgD5s /h6So36QEIeg7H2BQFVd0SGbvaZrVTxjMr1qJSDPhmt6pQJpqny2CdlYXhbbSZ1DuPzPZBtT9xhPV s6Uh323A==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:62940 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eDJrR-003O9z-8L; Fri, 10 Nov 2017 19:41:25 -0500
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Brian E Carpenter , Ole Troan , Fernando Gont 
Cc: v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>   
From: Joe Touch 
Message-ID: <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>
Date: Fri, 10 Nov 2017 16:41:19 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 00:41:28 -0000

On 11/10/2017 2:26 PM, Brian E Carpenter wrote:
> More on the philosophy side of the argument, WG Charters are a tool to
> allow the chairs and AD to control mission creep. They aren't sacred
> texts. So IMHO the real question is not whether this is strictly speaking
> a protocol extension, but whether it's a useful thing for the IETF to
> publish.
FWIW, I would agree with that if this were an issue of WG focus creep. 
AFAICT, the issue appears to go much deeper, which means it's an Area
boundary issue if it is indeed a protocol extension.

IMO, OPS stays in the lane of suggesting sets of *existing* protocol
parameters and features, or indicates where MAYs and SHOULDs can be
relaxed (or not) - all of this remains compliant with the protocol.
Changes to the protocol should not be considered operational decisions,
again IMO.

Joe


From nobody Fri Nov 10 18:29:35 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE26128D2E; Fri, 10 Nov 2017 18:29:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 t-9LwZPvGPVK; Fri, 10 Nov 2017 18:29:33 -0800 (PST)
Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21EB1200C1; Fri, 10 Nov 2017 18:29:33 -0800 (PST)
Received: by mail-pf0-x243.google.com with SMTP id d28so7940848pfe.2; Fri, 10 Nov 2017 18:29:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Leok4TIErQLKjfzoA5Oo91umP/ZT0UnvgKZSiBLikHY=; b=ID3qIHRmkrs9Wctt4tbMacc+xLAeqtYlWnK/j2KITFxF5qirO6+sT2zMVMbgffsOje 5F6GhqNuQrfv4sqp/6Mv4wH514yvrAEe13JqGBQ+nso5L8g38Ps/za9HFsfychNBS2hR wFdoKPC+82mGG0Y3OoW5mAEyqcWUJGCE5u6NfsTgRqTxrHZJcNgrTsJzlSPoJf8pw1l7 kf4VggL7Qzi3+iCZ9JSW5rbVfdwsdE7Yw0huuDeqE2qcX4vyX0+8D7VaZ6QTv7VjMwPB U58z3fZYtcR/GboH337EC20OPA/r/6YaB4HexSKVuzk6C2Vx4ZJkM3WYdTUt0IN36eN0 U5xQ==
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=Leok4TIErQLKjfzoA5Oo91umP/ZT0UnvgKZSiBLikHY=; b=bUgLY0BH+OFACK29X38sGNoIZGSXTxigg6j5gzADELxOGZwRympy9euEtJB2yB6gfs 7oz7GNrzv0vq7rXCJ+jgrqWgG5l+/5KDiZtIYiKu0TFKMc3sDy3H4vPst4MNIa9JqD/I j9jltymMr+kfEaK8b+w6CguVcExhgfdp00CLQ4BHd3LXqChiU3B3IKDimtH1jhWiH/3/ uCsKVrA1RLFDubGpLPcGHddVcQjqTKRFysPPsWvetPBjl4sByUBgQW489ZpUFRdcR8X6 BtthL1QRFaCdqb6fdJ7YruyMHA2rq2OjJ/jZYaf7Msh0Z/5xKyNW6oolBdizJH7eewab tbVA==
X-Gm-Message-State: AJaThX451Ct+J3vn5NmW0C3nCERTujQg/rKrAenQowyXmR+7HF1kOsVM VT6J8Px0p9Vi9fyZO4J6lrk=
X-Google-Smtp-Source: AGs4zMaDiYQTqzGW1mmamW7VkjVV1d9jiqo8iVTrOalLHN9kkJ7jfKWx7vj4HHotcH6x25nrEe+afQ==
X-Received: by 10.84.128.227 with SMTP id a90mr2375804pla.224.1510367373107; Fri, 10 Nov 2017 18:29:33 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id q73sm23918570pfl.146.2017.11.10.18.29.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 18:29:30 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim 
In-Reply-To: <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com>
Date: Sat, 11 Nov 2017 11:29:26 +0900
Cc: Fred Baker , Lorenzo Colitti , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com>
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com>
To: Fernando Gont 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 02:29:35 -0000

I don=E2=80=99t get it when you say this doc makes SLAAC stateful.

=E2=80=98Staleless=E2=80=99 in SLAAC applies to hosts, not necessarily =
to routers.

Your argument might be based on the text of the draft, 2nd last para of =
Sec. 5:

  "IPv6 SLAAC requires the router to maintain neighbor state, which =
implies costs in terms of memory, power, message exchanges, and message =
processing."

For routers to keep (address) information about the hosts does not make =
SLAAC stateful. In order to manage (keep track of) the hosts that use =
SLAAC, routers need to store some information about the host. This =
action of the router is natural and has nothing to to with the =
=E2=80=98stateless=E2=80=99 property of SLAAC, AFAIU.

See also, for example, the beginning of the 2nd para of Sec. 1, RFC =
4862:

  "The IPv6 stateless autoconfiguration mechanism requires no manual =
configuration of hosts, minimal (if any) configuration of routers, and =
no additional servers.=E2=80=9D

I don=E2=80=99t think the text in Sec. 5 of the doc, as repeated above, =
does not make SLAAC stateful.

---
DY


> On 11 Nov 2017, at 05:23, Fernando Gont  wrote:
>=20
> THe main issue is not this but, as the subject implies, this document
> making SLAAC stateful.


From nobody Fri Nov 10 18:36:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDBC12426E; Fri, 10 Nov 2017 18:36:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74vmEfhr1huh; Fri, 10 Nov 2017 18:35:59 -0800 (PST)
Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::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 926641201FA; Fri, 10 Nov 2017 18:35:59 -0800 (PST)
Received: by mail-pf0-x241.google.com with SMTP id b79so7953165pfk.5; Fri, 10 Nov 2017 18:35:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YY4oxTP4poZUkBkyssNLW5jeQ1mbbPQH07Vpl3Zh+G4=; b=ercSKZoCZshaDIn5Eyv9ikxs5eAeEf6ucdzMWtgXvlJcjPdRPzOu5dMRa1DGvYnEQw tFoL6VwHwZYpqVgpAaGK9RHAs3KeW1/ks8y+lsuMIhxcpRPIqtxefLdddRdVHyHZQTWQ BVHy/Z4f4695Mah9n7Y3xpbRIyWJB/4sPqAOR+hjPQjplvbcCsSe+QLW3n1wCVIQP22S jqWiOjGreJ6sDoDXsUBNSRwQSov3PTWqMItkh75MHfKFVNTI0qhtEE7gThCKPTPdTJvC r1M4xre3987bt8may6ikmOZHOjixh8wCQXRMFwxGfxFJN+22PxkjIHEcxq+I5ILJy2oO HQXA==
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=YY4oxTP4poZUkBkyssNLW5jeQ1mbbPQH07Vpl3Zh+G4=; b=A2xBskYJob77dcKE3ljBlZDcbIpLVHb8yCrDK/yAAtKoV068a2VkBwsDvSyfZGVTeH SamGZ0rgoOaL4zGNYHCyuCA5S9Hh6y6BaYa32QvCTYlFH+pjBVCGT7qDSJOdMMx+ca7C 0ODR6wZVDb7XQPB6IHLgX4sFYnibVNUv26YkAWH9UKzZ7VBKD72BRV9KZRjXtf+QvEti ePgj+xTJ9rQ1D+jqFQAFcuatPU8lnzVk+nynVCLkpkQXG1bOYtfYt+ssFq/Ss4bu1LI9 LwJaJciKHCBkRtYRXVjLtPyvcf9cI0+iiKkwD6vsVHkXIWRGi8JHS+KAkR1VGSK/EhIa evmQ==
X-Gm-Message-State: AJaThX7UZGRs1SD/lMBx0oqnNItTnVd78xk8apVMY7JDWFyeyf4AIGMx 4KpA9rtW/aNdNSrJbANkdsw=
X-Google-Smtp-Source: AGs4zMbthsL02kvbyNGo6cKnPDLuaN179Ly3haBkYoz4Ryp72C8p85E3I6PnoE8VBEo2IWWfulyuLA==
X-Received: by 10.99.42.210 with SMTP id q201mr2176183pgq.7.1510367759194; Fri, 10 Nov 2017 18:35:59 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id a19sm21707912pfh.30.2017.11.10.18.35.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 18:35:58 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim 
In-Reply-To: <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com>
Date: Sat, 11 Nov 2017 11:35:54 +0900
Cc: Fred Baker , Lorenzo Colitti , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5871390C-ADDE-42E0-BF6E-DA1938DD87FD@gmail.com>
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com>
To: Fernando Gont 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 02:36:01 -0000

typo. >>=20

   I DON'T THINK the text in Sec. 5 of the doc, as repeated above, MAKES =
SLAAC stateful.

---
DY

> On 11 Nov 2017, at 11:29, DY Kim  wrote:
>=20
> I don=E2=80=99t think the text in Sec. 5 of the doc, as repeated =
above, does not make SLAAC stateful.


From nobody Fri Nov 10 18:45:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E371012940F for ; Fri, 10 Nov 2017 18:45:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 PpPup7QQn7wS for ; Fri, 10 Nov 2017 18:45:14 -0800 (PST)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC2E128DF6 for <6man@ietf.org>; Fri, 10 Nov 2017 18:45:14 -0800 (PST)
Received: by mail-pg0-x22b.google.com with SMTP id p9so8719662pgc.8 for <6man@ietf.org>; Fri, 10 Nov 2017 18:45:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=U7ftpBKeiboz+HbPPecVOFX4W5W51eno9pNaq3uPD7k=; b=2NxShA7Y7iu2eHlfKGaA4dMjM8gqUMb3n0+3og7AShFJBiAkqwQBfwuHURLuKtk8CG yU8CwIZRwFp1Z2qlnqb1ztyqhQC9N3NHJB644EftByNCo42rib4mXfwwht/Vlk9Ukb60 0k678aWuSBOWrNu89uPqVkjKoUYGSgNjKXXhdmhMlyJPn06MiLQ17eM9SMvipMGNaCpr BnGKLwqjqEey7MeZ8TxIfMspe9XMalERAij1mTJ4s4sqBORZdDXETfuBHZus+ke/Hqru WUXbeHVQhGWu0MOqwEvXvniQZpQIziMg3TYeE0GiLXahvQYGNpv6mTWLmNFFfwpRWY98 sNdQ==
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=U7ftpBKeiboz+HbPPecVOFX4W5W51eno9pNaq3uPD7k=; b=loe+8K+mJEUVMEfiqZ1Dio9BrvaKhMzjPlG5klGQfPVthcO63zpWqf/LFUyvQjjlrQ M3R401Kti6qw9VSjvLAAFqOLzyFQnZhuG+lkyM/091IONOz7K2UXw1QVrrcvpp9rriT5 YImVqpLwKL2VnMiuvsxDssNCPSxOP0nAoO1bcPqAceGUqvz6vmXhDxby3xihK6P+uyNn 2ClZa3RQllrXpetG1E1dijqfS0r3JiDFLafb85bJgP3D1oHkzBZlWH/6NdkgD8e6O2sq SmIG33LPqg8Laon91g72R6DSPLk60nTPbep+MOBKS3uy8Owe5uG4kQ0bOgPc4o35gnka gXjg==
X-Gm-Message-State: AJaThX4pubOPN35/egRY6CEsjN84grgg5LWQioFc+p7mZTss/VOtN39k cEZlIJl41A249wrTCHgFZzjMZQ==
X-Google-Smtp-Source: AGs4zMZ/LSsTB5byP+bNLuKStNO3KVvn5gTvBd0DA0i+qt6ERssMIYYGrSbOCTtCApnjnN7gATN3Vw==
X-Received: by 10.101.80.132 with SMTP id r4mr2209076pgp.428.1510368313593; Fri, 10 Nov 2017 18:45:13 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:3d4c:3e85:23e4:df4c? ([2001:67c:370:1998:3d4c:3e85:23e4:df4c]) by smtp.gmail.com with ESMTPSA id s6sm17596943pgq.57.2017.11.10.18.45.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 18:45:12 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: Ted Lemon 
In-Reply-To: <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com>
Date: Sat, 11 Nov 2017 10:45:10 +0800
Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com>
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com>
To: DY Kim 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 02:45:16 -0000

The issue is that if you have allocated a prefix for a host and then you =
reboot the router, either you retain the allocation in stable storage, =
or you don't.   If you don't, how do you make sure that the host doesn't =
get renumbered?

That's the sense in which this is stateful, whereas SLAAC by itself is =
not.   It's not really SLAAC that's stateful=E2=80=94it's the mapping =
between the link-local SLAAC address and the prefix that's assigned to =
the host.


From nobody Fri Nov 10 18:53:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBCF1270A0; Fri, 10 Nov 2017 18:53:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Nxh0q1vEb1wY; Fri, 10 Nov 2017 18:53:40 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B90F124B0A; Fri, 10 Nov 2017 18:53:40 -0800 (PST)
Received: from [172.19.248.110] (unknown [57.190.1.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6830880E71; Sat, 11 Nov 2017 03:53:30 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ole Troan 
Cc: Brian E Carpenter , v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    
From: Fernando Gont 
Message-ID: 
Date: Fri, 10 Nov 2017 23:51:04 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 02:53:42 -0000

On 11/10/2017 06:45 PM, Ole Troan wrote:
> Fernando,
> 
>> On 11 Nov 2017, at 05:04, Fernando Gont  wrote:
>>
>> On 11/10/2017 05:42 PM, Ole Troan wrote:
>>>> 1) My comment to the list was essentially arguing that this
>>>> document contains a protocol specification, and such part is not
>>>> suitable. I think it should be easy to converge on something
>>>> regarding this one:
>>>>
>>>> Can anyone (you, for instance), provide a definition of what is a
>>>> protocol, and the run this document through such definition and
>>>> figure out if it fits or it doesn't?
>>>
>>>
>>> A protocol is a system of rules that allow _two_ or more nodes to
>>> communicate. The protocol specifies the syntax, semantics and so on
>>> (1).
>>>
>>> A protocol specification does not specify only the wire format.
>>>
>>> 'unique-ipv6-prefix' does not specify changes in the wire-format, nor
>>> its semantics. It only requires implementation change on one 'side'
>>> of the protocol, namely on the routers. From that perspective I think
>>> you can argue that this is not a protocol specification.
>>
>> How do you get from this: "it only requires implementation change on one
>> 'side' of the protocol" to this: "From that perspective I think you can
>> argue that this is not a protocol specification". (First sentence
>> acknowledges it *is* a protocol)
> 
> For it to be a new protocol (or protocol change, it requires _two_ or more communicating entities to be updated.
> (The reference above was to the ND/SLAAC protocol.)

Who said you need to change both sides for it to be a protocol update?

You have a sate machine for each endpoint. As soon as you change one,
you have changed the protocol.

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





From nobody Fri Nov 10 19:02:21 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201031270A0; Fri, 10 Nov 2017 19:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 188lfUsR0ylj; Fri, 10 Nov 2017 19:02:18 -0800 (PST)
Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9291200C1; Fri, 10 Nov 2017 19:02:18 -0800 (PST)
Received: by mail-pg0-x243.google.com with SMTP id t10so7728252pgo.3; Fri, 10 Nov 2017 19:02:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4FkiQG5q2XywWR3NTMput3+SmTP/2cb2WO5QivdX1DU=; b=p+sY+1EQ8KYlloSrL8A6pza8FcU/s4V+0B85jrvAcmdfRck/wFuRqkHXHbZO0mEus8 l79JGe0Ey4seJJL8BFl6myLoqIm05zbA6RMr5x8/y+6iQvbRRCWhFBjENkfDrMz4d/tm uSgMQFFZEg8YIttArnMfmjNWSNd4Bz8VPA27zwSgy2+qya9YqcGrU0QuorYw/X/GkYID +4I1wr1RrQd21cBkEvKk43wIqxnKJHZ2aaoxtXo3qkOWxNKbiPDkeZNB/8J+7kvWV0GI M2hXLwmmLN24pyrz5fKQTP4uOK4b6BRrFLbkassFhlPwrVO4WdeTryggC/e7/nVtuhr/ 7FWQ==
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=4FkiQG5q2XywWR3NTMput3+SmTP/2cb2WO5QivdX1DU=; b=Il19ZWJeYqTGALdmwmNLNkGL945d62GaeiTwwhFJpG1ASntrtxSczqwssSPfMuSO2W 5C3CmsR1/8doXaLjOviHRq+1wuUPOAtSSGqIQ0ENIkW1tcEkOhl1LghR/Ri2EQAye1U1 SIKDTxA/LEiRcofvqIo/yKQhFW9Ce0BYQn/T5PO50uIjeCsXrAdtIPiahPqNLwZ1Pk8K YJ3oORibrzEqwJb9oX9IlhkDEnbBV5tzP/3YdCUV7nEoNx06NFNLoTow2FebKTNE1JOz b7duo3NfaIphSV7aHEv+pfPqlH1a+sUCz3hpRexvtctRFzb5PNskNCK+vAdcXlhadrQZ Fq8w==
X-Gm-Message-State: AJaThX5zhV1E5rvWu0ZVSRdLNFLY6ND9EvnlmaAA14MG4cD9qBpXnbFT VhYrBXQNrGu+o/o3tLMSyhk=
X-Google-Smtp-Source: AGs4zMb+kuJe1ck/eLXKr7IVdIbVah27sDgEfsfoIBsMVwbDuvUkF4cf+kbref7fmaMfg3uApSDjUw==
X-Received: by 10.98.56.204 with SMTP id f195mr2531008pfa.188.1510369337738; Fri, 10 Nov 2017 19:02:17 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id y3sm1269329pff.122.2017.11.10.19.02.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 19:02:16 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim 
In-Reply-To: <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com>
Date: Sat, 11 Nov 2017 12:02:12 +0900
Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com>
To: Ted Lemon 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 03:02:19 -0000

The issue is about the router crash and recovery, not SLAAC itself; not =
particular about SLAAC.

Even with the legacy operation wherein the router is assigned a link =
prefix (from the site server by some means) to be advertised to the =
hosts on the shared link and the hosts run SLAAC for address assignment =
to their interfaces, what happens if the router crashes?

Either the router has kept that link prefix in a stable storage, or if =
not, the router might have to acquire a new link prefix from the site =
server, and not even knowing whether the refreshed prefix should be the =
same as or different from the previous one, the router and the hosts on =
the link might go through a painful renumbering anyhow.

Hence, the issue, if any, should be raised against the router spec, not =
against this draft or even SLAAC, I=E2=80=99d think.

---
DY

> On 11 Nov 2017, at 11:45, Ted Lemon  wrote:
>=20
> The issue is that if you have allocated a prefix for a host and then =
you reboot the router, either you retain the allocation in stable =
storage, or you don't.   If you don't, how do you make sure that the =
host doesn't get renumbered?
>=20
> That's the sense in which this is stateful, whereas SLAAC by itself is =
not.   It's not really SLAAC that's stateful=E2=80=94it's the mapping =
between the link-local SLAAC address and the prefix that's assigned to =
the host.


From nobody Fri Nov 10 19:06:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDBE128D2E; Fri, 10 Nov 2017 19:06:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 onFCsQ-JwJ8H; Fri, 10 Nov 2017 19:06:15 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C821200C1; Fri, 10 Nov 2017 19:06:15 -0800 (PST)
Received: from [172.19.248.110] (unknown [57.190.1.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8224582759; Sat, 11 Nov 2017 04:06:05 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ted Lemon , DY Kim 
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com>
From: Fernando Gont 
Message-ID: <7532e311-be94-1b9e-b9f1-8b12e9d6ee79@si6networks.com>
Date: Sat, 11 Nov 2017 00:05:13 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 03:06:16 -0000

On 11/10/2017 11:45 PM, Ted Lemon wrote:
> The issue is that if you have allocated a prefix for a host and then you reboot the router, either you retain the allocation in stable storage, or you don't.   If you don't, how do you make sure that the host doesn't get renumbered?
> 
> That's the sense in which this is stateful, whereas SLAAC by itself is not.   It's not really SLAAC that's stateful—it's the mapping between the link-local SLAAC address and the prefix that's assigned to the host.

If the SLAAC router needs to keep that state, why do you say that it is
not SLAAC that is stateful? Whose state is that, then?

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





From nobody Fri Nov 10 19:08:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06344128D2E; Fri, 10 Nov 2017 19:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 io1Eqbu0SPKS; Fri, 10 Nov 2017 19:08:38 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5AC1200C1; Fri, 10 Nov 2017 19:08:38 -0800 (PST)
Received: from [172.19.248.110] (unknown [57.190.1.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id CB70D82759; Sat, 11 Nov 2017 04:08:25 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Joe Touch , james woodyatt 
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <52C752BD-2347-4704-9103-89BD979D7C2D@google.com> <5fc6a1b1-7707-b5ab-7820-98f9f07b794c@strayalpha.com>
From: Fernando Gont 
Message-ID: 
Date: Sat, 11 Nov 2017 00:10:09 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <5fc6a1b1-7707-b5ab-7820-98f9f07b794c@strayalpha.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 03:08:39 -0000

FWIW, I agree with everything that Joe said below.

Now, consider the FSM of router side of SLAAC, and compare it with the
FSM of the mechanism being proposed. The difference should be evident.

Thanks,
Fernando




On 11/10/2017 09:36 PM, Joe Touch wrote:
> 
> 
> On 11/10/2017 1:58 PM, james woodyatt wrote:
>>
>> I think the definition of “protocol†in the New Oxford Dictionary is
>> adequate.
> 
> The definition there is certainly true, but not adequate except for an
> English paper. "rules" are too vague.
> 
> In networking, a protocol is:
> 
>     a set of rules
>     a set of states
>     a set of messages that are exchanged (often called the "on the wire"
> part)
>     a set of events/messages/actions that represent the behavior of each
> endpoint (i.e., to upper layers)
>     a set of time events
>     a set of rules that relate incoming
> messages/timer-events/user-actions and state to yield outgoing
> messages/timer-sets/user-reports and new states
> 
> (the simplest way to express this is as a FSM, which is the most generic
> form of computation where a machine cannot revoke its output - which is
> why it accurately represents the ends of a protocol)
> 
> If you take away any of these (except state and, in limited cases,
> time), you cease to have a useful protocol.
> 
> If you change any of these, you have a new protocol.
> 
> Joe
> 
> 


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





From nobody Fri Nov 10 19:13:10 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078BF128DF6; Fri, 10 Nov 2017 19:13:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 bh9RyCEeSNET; Fri, 10 Nov 2017 19:13:08 -0800 (PST)
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 F225D1293D9; Fri, 10 Nov 2017 19:13:04 -0800 (PST)
Received: by mail-pg0-x241.google.com with SMTP id s2so8747911pge.10; Fri, 10 Nov 2017 19:13:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nwffYgwfPJD9Rl5K4wsWxsMfO87ASKOQFKLwR/dZ5Ow=; b=tCzHsBohetDB3RtiNqXlkDgtBNL8xQMu3b7IExS18unoJzWhhA3HUV1YaNHeSIajfG y4j3/aRH6+0nh41prl0KD4+tBwHStASfk2p6XafbHoDNEHXRddS2QRXQgs9disBnS7Jt AKATD5uLGRektp2rs7Me8A6U/TrJ7+b7Fuu46anUzbeLKh/Dw3iqrDAvTwjeeq/t8zut pKYTxxnbA3A9NIDW0A3zbpL0tqKwHUS4ywMhlUc6s8Kv30seIXXVRIkU/IuyApNlJGpl GCTgsAGYDQrQbrO4P3/Y6wTsy9ezu/OQfkwPuD1ed4hDPmuGRqLAMdVbD4SxCe52wbD6 I2NQ==
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=nwffYgwfPJD9Rl5K4wsWxsMfO87ASKOQFKLwR/dZ5Ow=; b=TwifBmp2mX4G4bE+1RwGvlQEosk/qIMeWnM9HxljjaVk5A7jE1iTeHE9w6LmftaenO CSXM6vzq2MfsYWiim3lOZomnSAlKnqhpkswttupf/n/UYSwdGxdc24MpbQ3w2vLagbg6 FrritKcJK/PpgnkRNLG+L0VNrf0T+dN/f7Z/YKkHUOkl/vJO2r68LR832GXWeyIMyknQ NAOIGpKB+GMR02M10bL3Vz7j5knU8m+1Bg6lOhMJVxUeehRfJo9beNIAzNLx9+DKc6j/ vf84IgS1HSFmhyWKhX84kiFLfAnjY5Vz1T1cNn0+lq0aNMKSVXJ7g4rHRIx/RugqlFF3 kRYA==
X-Gm-Message-State: AJaThX5OqEKHGBzWVql/LCa7C4/gYMWp37K4DQbom6+yxy/4LwuchoqH YnoLnVbe7e4C/jZmR5C4oUFSZIVU
X-Google-Smtp-Source: AGs4zMYq70loM8o1JHag+cYx1yAKznsi62hJ0jqSQq83oeo39M6xUsHWPpy/GNWUTuLpD4+R+GgY+A==
X-Received: by 10.98.133.28 with SMTP id u28mr2454493pfd.241.1510369984498; Fri, 10 Nov 2017 19:13:04 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id a4sm21896008pfj.72.2017.11.10.19.13.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 19:13:03 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim 
In-Reply-To: <7532e311-be94-1b9e-b9f1-8b12e9d6ee79@si6networks.com>
Date: Sat, 11 Nov 2017 12:13:00 +0900
Cc: Ted Lemon , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com> <7532e311-be94-1b9e-b9f1-8b12e9d6ee79@si6networks.com>
To: Fernando Gont 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 03:13:09 -0000

The host=E2=80=99s state.

RFC 4862:

  "This document specifies the steps a host takes in deciding how to =
autoconfigure its interfaces in IP version 6 (IPv6).=E2=80=9D

  "The stateless mechanism allows a host to generate its own addresses =
using a combination of locally available information and information =
advertised by routers."

---
DY

> On 11 Nov 2017, at 12:05, Fernando Gont  wrote:
>=20
> If the SLAAC router needs to keep that state, why do you say that it =
is
> not SLAAC that is stateful? Whose state is that, then?


From nobody Fri Nov 10 19:15:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3B4129353; Fri, 10 Nov 2017 19:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 otV2bszuMIbk; Fri, 10 Nov 2017 19:15:08 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ABAE128DF6; Fri, 10 Nov 2017 19:15:08 -0800 (PST)
Received: from [172.19.248.110] (unknown [57.190.1.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id BAB7082759; Sat, 11 Nov 2017 04:14:56 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: DY Kim 
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , Ted Lemon , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com> <7532e311-be94-1b9e-b9f1-8b12e9d6ee79@si6networks.com> 
From: Fernando Gont 
Message-ID: <203d7ede-2169-4a04-e545-2eb48144eac3@si6networks.com>
Date: Sat, 11 Nov 2017 00:16:39 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 03:15:09 -0000

On 11/11/2017 12:13 AM, DY Kim wrote:
> The host’s state.
> 
> RFC 4862:
> 
>   "This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6).â€
> 
>   "The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers."

Host state, maintained at the router?


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





From nobody Fri Nov 10 19:18:09 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2C2129353 for ; Fri, 10 Nov 2017 19:18:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 L3HeFJ1VWlai for ; Fri, 10 Nov 2017 19:18:06 -0800 (PST)
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 02D4C128D6F for <6man@ietf.org>; Fri, 10 Nov 2017 19:18:05 -0800 (PST)
Received: by mail-pf0-x231.google.com with SMTP id z80so7941278pff.4 for <6man@ietf.org>; Fri, 10 Nov 2017 19:18:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OxE/OR9PQpM2bB1/s2vwl0si+AzmfJosfNnIzuhIczM=; b=lpcYVignNPmEINCxdqDaYHjqwpX9Om5z3yPl3fKMGVtChV7cv8iQQoNxzjyEesdtJj brFEFaodOQ731JwYLJHIPDcCrJEX0B7ovGLWMUw8NVncEfZeGvBYFPGM7nuq6mSjtrE3 x1cS15Ts9ko4693B7OAs34D9ryu21cDa274DSG3cI1VQOTs1retYlJElOLe6gb4SvPIe 12UvTchP27sDMtovVq8wJ9DfWnFh/+mwcdWW+2wd/SPvZ2YxVX8elbo+1GDWgDsXksIL SZtQ2ta1ldsqIKhGWL8lWldvNrwLwE8VLzNEptz8YcuhpJoHehWgjv9Rb+ZxyC30lyiZ qsUg==
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=OxE/OR9PQpM2bB1/s2vwl0si+AzmfJosfNnIzuhIczM=; b=aSEZir0lXxjLGMn18sz3XXHwxYVchxxnTThuSPtamw0IObrRSD4+v54s8Oq+91b3cL AJkMbqvkg6DIYqdwMh+CRrFVxAVGKS4RZKgi1OqYnGV/iHn5/7bq9mYIlKbooibAgMUl PY4iuq0/pmRnQSA52OqSAQo7ZcGbLLT1/5Rc71qW6Rhm+Np8/9JWasU5xyf2zyhkl3Ll MKVe1vqtb0WQcmk9TVyRy37cbJKAMTwyRGq+T4hYGOfHR7JjaJDBwbGjOejAUVaqrB7g w932Xn41clQO5oW2uw4TgGmlKSEy1aaotVHEiMy6Vgklxjnf9qEnQx+Y6xkj4Bq8CM3/ vmNA==
X-Gm-Message-State: AJaThX48Fmbe2TqO5C2aEkGMWmDEebLVx249dtoVkJr7e+zYs/BOIj6E nSjI9BWK64t1doiNoIWDR4B6uKYQVZY=
X-Google-Smtp-Source: AGs4zMY+VqmbuAq2w9R4hkv37xFtvoc42uOI0ktIn961DaYmrZvoGwW+hARfXVRD5euI6snNZgRZtQ==
X-Received: by 10.99.188.9 with SMTP id q9mr2357901pge.104.1510370285396; Fri, 10 Nov 2017 19:18:05 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:3d4c:3e85:23e4:df4c? ([2001:67c:370:1998:3d4c:3e85:23e4:df4c]) by smtp.gmail.com with ESMTPSA id f11sm16658821pgp.48.2017.11.10.19.18.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 19:18:04 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_138C547B-7533-4B55-B610-31F74E69056C"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Sat, 11 Nov 2017 11:18:01 +0800
In-Reply-To: 
Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
To: DY Kim 
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 03:18:07 -0000

--Apple-Mail=_138C547B-7533-4B55-B610-31F74E69056C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 11, 2017, at 11:02 AM, DY Kim  wrote:
> Hence, the issue, if any, should be raised against the router spec, =
not against this draft or even SLAAC, I=E2=80=99d think.

There's clearly an issue.   The router has to preserve the prefix =
assigned to the host across reboots, or else the host will have to flash =
renumber.   This would be quite a bit worse than current behavior with =
SLAAC, and I think is unacceptable.


--Apple-Mail=_138C547B-7533-4B55-B610-31F74E69056C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 11, 2017, at 11:02 AM, DY Kim <dykim6@gmail.com> =
wrote:
Hence, the issue, =
if any, should be raised against the router spec, not against this draft =
or even SLAAC, I=E2=80=99d think.

There's=
 clearly an issue.   The router has to preserve the prefix assigned =
to the host across reboots, or else the host will have to flash =
renumber.   This would be quite a bit worse than current behavior =
with SLAAC, and I think is unacceptable.

=

--Apple-Mail=_138C547B-7533-4B55-B610-31F74E69056C--


From nobody Fri Nov 10 19:19:19 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1331293F3 for ; Fri, 10 Nov 2017 19:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aNUj2SyZLQ0 for ; Fri, 10 Nov 2017 19:19:15 -0800 (PST)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74EAF1293D9 for <6man@ietf.org>; Fri, 10 Nov 2017 19:19:15 -0800 (PST)
Received: by mail-pg0-x233.google.com with SMTP id y5so8769571pgq.7 for <6man@ietf.org>; Fri, 10 Nov 2017 19:19:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=C4Kc1hqysuv78lwAiRrUdcqWhtFTkwaruHZg3pMEEF0=; b=ix3NoGjGp+cdd2uKRUpbtkUuCqnypsXVKYE01V8EruFuk6aGmtRCTgUjYweCEqnBz8 HMr1jkkOoJTw2Rz5GDCIde41xVwYe+ACLQFTHxQLzcFaj9uSU1JwQG8A6/m1devD65u0 yNf/3eSJMkESmpaKWUrUEpnu4ArWNFxOXklPqTRgbKykjj4S9PQqA/5ZcQ3cXpeyafJV h9N4O6pb328Xro8o1Gvif30GW3kMuFgsQsqzYj08leXwIRKJ7Tv89UMTX/J+eQEzvIHK OPOXenytqxSSNByWjzXbo78NTDeGKE2m2rojHc+CavoIAKUt2EmkqhB7Et4J5glmEx/d /MLw==
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=C4Kc1hqysuv78lwAiRrUdcqWhtFTkwaruHZg3pMEEF0=; b=MuTJxWd6s+yWc741zpHTbMw09VxetxW2YDHow8rOKxivvPvpVZNoLeWCKmO/4eU571 7YZPZ8hYiemU+35UWnX131ULwe72yg0J7RadugZeZPIlDOOvHS45ePUmC/YWjrt/JTWx GkXQf8wfK0N5jQ3lj3l589P8qQFqxoBCkshX7NeKLyXMo9HWy9V+PuVbQ1hol7zdD7Tu b4tQpguN1Ib79J5qSIw/0VvicE0931sdRTCnuurTAdlhV1poZmYdkITgqJg3H0Tkngr8 rHCVG05M9undE9BGc0NwkvtiQ1TQdeqgpvKB8C5naI09RcRmP6O3tZaNnRiAyN57VtMJ rxGg==
X-Gm-Message-State: AJaThX65X+rTR/Q5va+0Au789qv4sqo4Yacb1gnZPJ0yZWvZg1mqG2Ok h8qJlyrufvF2AntZPEex69MDag==
X-Google-Smtp-Source: AGs4zMbxdxxUtnpZ+KD1I6VnNLSM7fGJjGiof035c9m+jC4mqXhSdnjNI/7uuZyE2fhQ4LYUccdpAA==
X-Received: by 10.84.242.9 with SMTP id ba9mr2411319plb.305.1510370355029; Fri, 10 Nov 2017 19:19:15 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:3d4c:3e85:23e4:df4c? ([2001:67c:370:1998:3d4c:3e85:23e4:df4c]) by smtp.gmail.com with ESMTPSA id y27sm20799211pfi.107.2017.11.10.19.19.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 19:19:14 -0800 (PST)
From: Ted Lemon 
Message-Id: <93A2E6BA-49B7-43D8-A4B6-631FEF4C7420@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_922DFA0C-7F95-4EE2-8555-E6AAEC92C614"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Sat, 11 Nov 2017 11:19:11 +0800
In-Reply-To: <7532e311-be94-1b9e-b9f1-8b12e9d6ee79@si6networks.com>
Cc: DY Kim , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
To: Fernando Gont 
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com> <7532e311-be94-1b9e-b9f1-8b12e9d6ee79@si6networks.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 03:19:17 -0000

--Apple-Mail=_922DFA0C-7F95-4EE2-8555-E6AAEC92C614
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 11, 2017, at 11:05 AM, Fernando Gont  =
wrote:
> If the SLAAC router needs to keep that state, why do you say that it =
is
> not SLAAC that is stateful? Whose state is that, then?

SLAAC is stateless.   The host can freely change its SLAAC address at =
any time.   However, when it does so, it will get a new prefix.   It's =
the binding between the SLAAC address and the prefix that is stateful.   =
So the address itself isn't what's stateful.


--Apple-Mail=_922DFA0C-7F95-4EE2-8555-E6AAEC92C614
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 11, 2017, at 11:05 AM, Fernando Gont <fgont@si6networks.com> wrote:
If the SLAAC router needs to keep that =
state, why do you say that it is
not SLAAC that is =
stateful? Whose state is that, then?

SLAAC =
is stateless.   The host can freely change its SLAAC address at any =
time.   However, when it does so, it will get a new prefix.   =
It's the binding between the SLAAC address and the prefix that is =
stateful.   So the address itself isn't what's stateful.

=

--Apple-Mail=_922DFA0C-7F95-4EE2-8555-E6AAEC92C614--


From nobody Fri Nov 10 19:55:07 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B19124D68; Fri, 10 Nov 2017 19:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 KdA1QD47DiAh; Fri, 10 Nov 2017 19:55:05 -0800 (PST)
Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40740124B18; Fri, 10 Nov 2017 19:55:05 -0800 (PST)
Received: by mail-pf0-x242.google.com with SMTP id i5so8037443pfe.6; Fri, 10 Nov 2017 19:55:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zH7aik9eEQAR7BpdE62rAAqUN4BOMUUEx2/LFBCzod0=; b=mSGPS5l5FwYmdKv0vKPOeU12M3qHsGbdbPl0NMTRhUzp6ryXltQMSXI43GPBW8slGJ uTR8RJ6T3HH9DAQsLOy9Tol2d25befmMiQIJvaF+Xt1Aeze1oLsQRZhYNV5lQliG1RTD RQw5J/jNxV0D/VV1uQMczwZHutvuVFE7EXUrWtxO7V0m70COn3PRcGsj5tf4SYHPqXPf wBNRTUOFuCH1tl9hQ7WSs/8p+PTmzOjsADn8vVMfmqx0reTgpMl/NTzPNlRBrodRJ8i5 Y5iS4aI6fzKzTZeyg4YY7zn2yLrpbZhaSBdNtzqxvx9WPCF9bPI6Z/RrNxZlg0Ikljod JJ6w==
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=zH7aik9eEQAR7BpdE62rAAqUN4BOMUUEx2/LFBCzod0=; b=TuSHREOb9sZPtA9KgvOoYuaW1JJytu4SAs/ZtVsN8hix47A/rJ1hyYyKVidOU9DmOY PSjcyAfbPMWOT83tFWSioBT/5rMa5sRpr59ZVtge+aXoG4VfMGEOnPSZzu3PUeZeBk64 rdF9vhH4+ER8mmY88rV7QSpziSvCz2aldfg775qmBCj1vJkCch6siEJnYY/FiwDISPgF 6nJd7wjHGsHHbvviGqouor3ky75DlzQDJTKsqJBjyjhAXg56x0f2GZBKVr+9pKSScLg4 M3E2dp8BzpCZxN/XMB/hljNfrAtfFffTD3WgTGNL39ioWFaEPq3LibCYipH8JM6TOgrn XVeA==
X-Gm-Message-State: AJaThX54GsXQOmtoFMcKo93MsGmmmL3OVK3WfZ1OIthGVEtwnwv37CMN xCGi41g4yqiWqyFSrTN1jeGioCI9
X-Google-Smtp-Source: AGs4zMasjvM/hLP+Kz7/nWxAkVez0sr+KMestWAjxtBNqC6qBmpqw9a3hnGHJuxQSdljLZeOwvpIZg==
X-Received: by 10.99.109.75 with SMTP id i72mr2404637pgc.43.1510372504734; Fri, 10 Nov 2017 19:55:04 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id a7sm16379196pgt.39.2017.11.10.19.55.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 19:55:02 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim 
In-Reply-To: <203d7ede-2169-4a04-e545-2eb48144eac3@si6networks.com>
Date: Sat, 11 Nov 2017 12:54:57 +0900
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , Ted Lemon , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0045136C-91FA-4B31-91E0-D2D44E7433AB@gmail.com>
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com> <7532e311-be94-1b9e-b9f1-8b12e9d6ee79@si6networks.com>  <203d7ede-2169-4a04-e545-2eb48144eac3@si6networks.com>
To: Fernando Gont 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 03:55:06 -0000

The =E2=80=98state=E2=80=99 in the wording SLAAC means that of the host, =
I mean.

SLAAC don=E2=80=99t need to require the router to do anything special, =
other than the router=E2=80=99s usual prefix advertisement through an =
RA.

The same is true of the case wherein DHCP is used to assign addresses to =
hosts by the router.

How the router keeps the link prefix info in its system is an interest =
neither to DHCP or SLAAC, since the link prefix itself is not about =
address assignment in which DHCP and SLAAC are interested.

How the router keeps the link prefix(es), whether shared or unique to =
each hosts, is an issue of the router system implementation, not of the =
protocols DHCP or SLAAC.

Hence, the question about how the prefix(es) are stored or recovered =
should be addressed to the router spec, neither to DHCP, nor to SLAAC, =
nor to this draft, I=E2=80=99d think.

---
DY

> On 11 Nov 2017, at 12:16, Fernando Gont  wrote:
>=20
> On 11/11/2017 12:13 AM, DY Kim wrote:
>> The host=E2=80=99s state.
>>=20
>> RFC 4862:
>>=20
>>  "This document specifies the steps a host takes in deciding how to =
autoconfigure its interfaces in IP version 6 (IPv6).=E2=80=9D
>>=20
>>  "The stateless mechanism allows a host to generate its own addresses =
using a combination of locally available information and information =
advertised by routers."
>=20
> Host state, maintained at the router?
>=20
>=20
> --=20
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492


From nobody Fri Nov 10 19:57:58 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A3F1200F1; Fri, 10 Nov 2017 19:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 mq4fPJnp6PUL; Fri, 10 Nov 2017 19:57:50 -0800 (PST)
Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1441200C1; Fri, 10 Nov 2017 19:57:49 -0800 (PST)
Received: by mail-pg0-x242.google.com with SMTP id 207so6014072pgc.12; Fri, 10 Nov 2017 19:57:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7MwmlcTBFEG4nmj2oUGieCIAiQAAOLwPZ0eJEnFwkXQ=; b=CBYkkVtHBbQjS6RTty0Jr7bJyYFQV7QkYZJx1EVikEhGtCSVN8MpczjrRvTPwTf/Gn 4TH01PEWgcCA5Edby0Dv+/4Mqy9RSZFbx59LpjihSXvflhj/m8COJxe9tXG0i5JwngSu rnQwzrT4/EY8QYiAJk7jnHDlm/2LcMIM6275kCoOgEt3HujcMmmTB4qswSNUHqj/Qduq kqfHO0ql5fqSD9+YxyFimXUv5LVmiUV01w2AWmAFgCa8Km4R00MUz6/5LOOZmNvmc4T9 tk6+nUa6IPVewVYsukMuV9c3bKRfEvfxAab04u8FjO7zQ0oQM7+FpBo1zaUX3e4ggzM1 TX0Q==
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=7MwmlcTBFEG4nmj2oUGieCIAiQAAOLwPZ0eJEnFwkXQ=; b=tZEh8FR0rD4t3ZhLLMmwbTLFpSTTD21GaDtga4tdGn4GBfcp0A94RuzyemuP/56X2P RlK/d/XNrdsYH/CoISS1ywpG3riGZQ34IDprMs41Y9+tUO4LIE1Vmc96tdYossSSkvxs J6nfZWa8x8kGYJ27CAZHtyVe9/FaSBBOlpsxITNkhytaWzRWYQikmTgRwOMmxpWOrtfW +HyfjJHxPGHtteRs6+LtRooLYd8pqzpEC0UxXE0+tONOxLFMeh5NCLScdLDdFvNwLnQ/ 5i2phVRnr690EV89utX08X8PzftqUmN4j6O0Xu3Mh80FOxLI+07uWgChnh8XxUorqUvA nJWg==
X-Gm-Message-State: AJaThX5hb+9v7acrlgKucigYmh471bEhdOvlZl4p9czpxhqqRF6CWXg5 zv5kWIE5gHksradZc0Tpl2AT6IPu
X-Google-Smtp-Source: AGs4zMb02xuGSdpRWH4tJh5vt3pHGyhW8ci9IyXDqnAG9hbBmAKvgjgh1+8sQQ90Z+ljyXmxUv0lhA==
X-Received: by 10.99.65.131 with SMTP id o125mr2314579pga.83.1510372669533; Fri, 10 Nov 2017 19:57:49 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id e18sm19432531pfi.57.2017.11.10.19.57.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 19:57:48 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim 
In-Reply-To: 
Date: Sat, 11 Nov 2017 12:57:45 +0900
Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6BA4A174-FCE5-4A28-8E9A-B1CAF8685264@gmail.com>
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com>  
To: Ted Lemon 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 03:57:51 -0000

That the router has to preserve the prefix(es) applies the same to both =
SLAAC and DHCP. The draft has not brought anything new/strange to the =
usual behavior of the router in association with SLAAC.

---
DY


> On 11 Nov 2017, at 12:18, Ted Lemon  wrote:
>=20
> There's clearly an issue.   The router has to preserve the prefix =
assigned to the host across reboots, or else the host will have to flash =
renumber.   This would be quite a bit worse than current behavior with =
SLAAC, and I think is unacceptable.


From nobody Fri Nov 10 20:01:19 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FB91293F3 for ; Fri, 10 Nov 2017 20:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 PiLlhD-1kCwS for ; Fri, 10 Nov 2017 20:01:13 -0800 (PST)
Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e: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 28EEF129469 for <6man@ietf.org>; Fri, 10 Nov 2017 20:00:13 -0800 (PST)
Received: by mail-pg0-x22c.google.com with SMTP id g6so8816548pgn.6 for <6man@ietf.org>; Fri, 10 Nov 2017 20:00:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sAJfJsiR3AIKspioQ4hI2XAZMxrvaWa/MViVttSzQKw=; b=MBj0RBiftV4tZqdGAJL/KGz6qcmAOvF7k7J6/r+BJa42xXy0A29eukiCySs2XpraDZ KS6gOnCOvDPtPYN/3MURmOg3J/k9KaLVIRdIXzxlcodxCaYg+kgC8DgNmumm7pk0vl49 YlGigh798JIH1DFs0m8o8eN/fPq2EH7OdWg+Lt+8kmV6Meth/yrxPnRPh/XUqzqQhGe/ JtFPOs3tsVcWeh0Fl1djtcPKjnJgkyXiLROao/qYTg2lWRdki/tn+jCZzcgewI2q2qPi EYk/JJqDo20Obi4LzfFFloDG0su/L6x03N2VcuCtUMundr6hG0iclhoiMWMnVcKOjL2V g1YQ==
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=sAJfJsiR3AIKspioQ4hI2XAZMxrvaWa/MViVttSzQKw=; b=GQVuLTCeeJ81fFxrzxbwZpTOnGqm/I8o5WNOk+fnyHvKCJZviscxaZCGQnZ1pf/Lf3 eneVaGdJdfeRUsw7NpAEIsXmxlXSxB8z1KHEBkNMI1Z5PeBQNvJvoOGu/FwsTkNuqfU9 KXp9ecEZwNcLrgrZjm/XwmKX5MBwhzKkdm1Cni+ivv1VE4mPONmlVMH3S+QKVXLwTMdh /N46VxcWOalDp3kCy0BLgKcyvgXNCbDAJrgkFYQHVkEw3kclJceBACXmSYht+Pk7gJqq tSgI3V2MNGos0PhNiHSUhtjbiIRG3sEwhK4nNATCwPSSpDuztwIHoRu612R8JziGX9Qh E5RQ==
X-Gm-Message-State: AJaThX6cqtRYAclqTZCSa7hCVXIlt6uzhPNHUvOWDuxkWdScOtUKH5jB yL+5dUdsLmMLcdG4bvTHZDajsA==
X-Google-Smtp-Source: AGs4zMZaDCnfeYNTpzmw50o64BSUTTXnpTXiFd0qlpZ7QHg9UhsJ0Tj8uWBz1tAU6g0Kr/T2KUtkyA==
X-Received: by 10.101.68.69 with SMTP id e5mr2353990pgq.282.1510372812516; Fri, 10 Nov 2017 20:00:12 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:6145:1fbe:5a46:6c72? ([2001:67c:370:1998:6145:1fbe:5a46:6c72]) by smtp.gmail.com with ESMTPSA id 84sm20843165pfy.179.2017.11.10.20.00.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 20:00:11 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_6F4C01BD-1B0F-47C9-8A9F-96D182223DBF"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Sat, 11 Nov 2017 12:00:09 +0800
In-Reply-To: <6BA4A174-FCE5-4A28-8E9A-B1CAF8685264@gmail.com>
Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
To: DY Kim 
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com>   <6BA4A174-FCE5-4A28-8E9A-B1CAF8685264@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 04:01:14 -0000

--Apple-Mail=_6F4C01BD-1B0F-47C9-8A9F-96D182223DBF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 11, 2017, at 11:57 AM, DY Kim  wrote:
> That the router has to preserve the prefix(es) applies the same to =
both SLAAC and DHCP. The draft has not brought anything new/strange to =
the usual behavior of the router in association with SLAAC.

Not correct.   In the case where we are not doing unique prefix per =
host, the prefix is static.   In a sense it's stateful, in that it is =
configured on the router, but there is no binding between the host and =
the prefix.   With unique prefix per host, the router has to have a =
bunch of prefixes, each of which is allocated to a specific host.   =
These allocations are dynamic, have lifetimes, and need to be managed.   =
It is simply not the case that the default behavior and the new behavior =
are analogous.


--Apple-Mail=_6F4C01BD-1B0F-47C9-8A9F-96D182223DBF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 11, 2017, at 11:57 AM, DY Kim <dykim6@gmail.com> =
wrote:
That the router has =
to preserve the prefix(es) applies the same to both SLAAC and DHCP. The =
draft has not brought anything new/strange to the usual behavior of the =
router in association with SLAAC.

Not =
correct.   In the case where we are not doing unique prefix per =
host, the prefix is static.   In a sense it's stateful, in that it =
is configured on the router, but there is no binding between the host =
and the prefix.   With unique prefix per host, the router has to =
have a bunch of prefixes, each of which is allocated to a specific host. =
  These allocations are dynamic, have lifetimes, and need to be =
managed.   It is simply not the case that the default behavior and =
the new behavior are analogous.

=

--Apple-Mail=_6F4C01BD-1B0F-47C9-8A9F-96D182223DBF--


From nobody Fri Nov 10 20:15:02 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75B71200F1; Fri, 10 Nov 2017 20:14:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 PL-jYS1vfRVn; Fri, 10 Nov 2017 20:14:53 -0800 (PST)
Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::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 7B0CE1200C1; Fri, 10 Nov 2017 20:14:53 -0800 (PST)
Received: by mail-pf0-x241.google.com with SMTP id j28so5724694pfk.8; Fri, 10 Nov 2017 20:14:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3xeCK/LAThbgIHtxw20xfRztJvZd0RuYnDrbLDjGdNA=; b=lmfHKYBSVIzS/8fvzgflUGjSB2ti7LpLDjiN+TSx4STQ6ai4n8XBYtfhUVLNqlnKyE BMgmo7iJvsmA4NaaYeyfjVJ+qEKhJho8C6XPqUqUjQ3PbRb6Ael5Cf+WuqavSOxHBEwZ oIm8h8Ee0ShL8zPXTLkoKS0LY67ler98isMCN8wpcM5h1u9EmSk2cCjX4BoSttXSgVWK 7ev3i9wvf8hNvv76jtsVTVQuQ/rsORVP3viy9iTTzNF9UE4/bzBsig1iyld/YnU7vsOH p63VJUrS4FtzvO3LV1O6vva5/qclQQlZPhuVGuEQCepDAX3XNV4oXLteAyYm/NWV/7Cb Y+mA==
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=3xeCK/LAThbgIHtxw20xfRztJvZd0RuYnDrbLDjGdNA=; b=o1JkbukXPXOAEyUYSvTApGxt3a1QXMGss3bybDle1BSm4aR6Ox6ukYaQYd0pW0ccie EuFiGb11sw+w0Ipw2h6RUsQkJ4BCxqWvfR1YR7u2UdOyyJi5LkzTkGxbBn1KG40enlmA eSV3pfy3iRzVGYGPXkqhrozjBD4bqFwkQpFoxEzHXPTLXV6JTmJsZtUuF8Jg50stnIGo BjFEe/bIV6eiuNg/eKtUEfbmuoDwTyWFgmS52ZIjD96QqLCzjoLGfVM2QdPCrSkzfxFB Ev4jjNvbLQtD775X+5Kp/mA3IowB4eDI7oqwLclJ4NlsmiNfGhuagBcx0AAeFqYvE9qz 3cFw==
X-Gm-Message-State: AJaThX4ctW17TWZ8upOUmSRJfTxlv33cmosGNP8mP4i7M0X3nGRQNWXH itU6w4k1uQ48MUeAE9QFzkI=
X-Google-Smtp-Source: AGs4zMZ2ZWcjI0gjl11S7pCoODelgwFjBQa1GzPIH/AQs3LwVYXxlS1YK16rtZrIkMSV1K4G+yTa1g==
X-Received: by 10.101.98.9 with SMTP id d9mr2461235pgv.8.1510373693094; Fri, 10 Nov 2017 20:14:53 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id t2sm23068872pfk.90.2017.11.10.20.14.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 20:14:52 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim 
In-Reply-To: 
Date: Sat, 11 Nov 2017 13:14:48 +0900
Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com>   <6BA4A174-FCE5-4A28-8E9A-B1CAF8685264@gmail.com> 
To: Ted Lemon 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 04:14:55 -0000

Points taken.

---
DY

> On 11 Nov 2017, at 13:00, Ted Lemon  wrote:
>=20
> Not correct.   In the case where we are not doing unique prefix per =
host, the prefix is static.   In a sense it's stateful, in that it is =
configured on the router, but there is no binding between the host and =
the prefix.   With unique prefix per host, the router has to have a =
bunch of prefixes, each of which is allocated to a specific host.   =
These allocations are dynamic, have lifetimes, and need to be managed.   =
It is simply not the case that the default behavior and the new behavior =
are analogous.


From nobody Fri Nov 10 21:02:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDCE12895E; Fri, 10 Nov 2017 21:02:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 gOGBGkCjQfFJ; Fri, 10 Nov 2017 21:02:34 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC0E1200C1; Fri, 10 Nov 2017 21:02:34 -0800 (PST)
Received: from dhcp-9e6d.meeting.ietf.org (dhcp-9e6d.meeting.ietf.org [31.133.158.109]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vAB52LQA003925 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 10 Nov 2017 23:02:23 -0600 (CST) (envelope-from adam@nostrum.com)
Subject: Re: Adam Roach's Discuss on draft-ietf-6man-maxra-03: (with DISCUSS and COMMENT)
To: Suresh Krishnan , Spencer Dawkins at IETF 
Cc: IPv6 List , Bob Hinden , =?UTF-8?B?56We5piO6YGU5ZOJ?= , "draft-ietf-6man-maxra@ietf.org" , IESG , 6man Chairs <6man-chairs@ietf.org>
References: <150888618658.4890.17540557977964477269.idtracker@ietfa.amsl.com> <4F068A57-9F88-4951-A584-D103193744C4@gmail.com>  <494DB70A-D752-45A9-9D9F-B0062F2E2764@employees.org>    
From: Adam Roach 
Message-ID: 
Date: Sat, 11 Nov 2017 13:02:20 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 05:02:35 -0000

On 10/28/17 02:50, Suresh Krishnan wrote:
> I have no issues mentioning that this is an inclusive between


Thanks -- that's literally all I'm asking for. If you submit a new 
version of the document with this clarification, I'll clear my discuss.

/a


From nobody Sat Nov 11 01:35:02 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2814129480 for ; Sat, 11 Nov 2017 01:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 fMS_OhL8T_yu for ; Sat, 11 Nov 2017 01:34:59 -0800 (PST)
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 BBCD7129449 for <6man@ietf.org>; Sat, 11 Nov 2017 01:34:58 -0800 (PST)
Received: by mail-wr0-x230.google.com with SMTP id l8so10462112wre.12 for <6man@ietf.org>; Sat, 11 Nov 2017 01:34:58 -0800 (PST)
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=vDSVcKrVeTZj4Q0btSR3Qv2J/+IE5HjFTCfDx3WDwL4=; b=kz5odJ4glnS/sKVcHsGv7PAoI31KZuwsj1WObWyAUPkBT1in1eOBpa+0wZYR4I/snz t9WzMOrRa0xB0ycGvjXljsWEXuB1/Ellq3oM0JZeQPYVNiKUfiE9LLO12UMva42mXtzF /wysDoQrJ1DSNOGvXUYbt45Xb+uQXccVN2x1VpnDEpU/KprKoAp+pBTtSlA+v3KSweHa lehfPzPf5RW3myuXbLm2zlOTwHHaklQR8EGX5Uj58wRIWYRP2HlaN5rrxxHKopkhjZsJ JZmnanYYLYm+vMzehlgdKYpi3OEqX7PkRjjD//58rnWWZpy2AgJ3DqBFiEG+/oCAFtbe 42iQ==
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=vDSVcKrVeTZj4Q0btSR3Qv2J/+IE5HjFTCfDx3WDwL4=; b=EGiwZSdrF/z6gqIg5YIJuaVC6k3+ahL+KIKx++mYv2i7biszc7nG36teJK2wUaIZR8 k/yoL2ZIVps4GGfn4OoGzRcnaf/vt+8qmD4jbQaL6uiNEYK6j3C7F1DxTDY0NSi2pR2P YWagdh2De8CyVUGFa2n/rMUFxPU3WdUq/xwL2tHYK1kj7kZpamPNO2nomrNm1cpbJrjp KsvIWLSAKJ7afiEmm9YNI77DhNe1/L3RgkcoHAnTNQb4wQyvAey6jG6czhlOhzf6J+vL PfsibzmX1GgGokxIXNujJCRzjQsSlY2NLMw6tmhbOsF/K9ztycPLcd9u/9+0xMNStfiO UD5w==
X-Gm-Message-State: AJaThX5KJFL9zNq9jletTZvljtQfZ44TmIT+bHM0TOMjxLBeC5JDfNfQ 7jvzFYuGZVWokicUt8h7uALlVu+k4L3dDpoIA1dMZw==
X-Google-Smtp-Source: AGs4zMYjhXB4MosdHyBNiH0jJM8lDQR9FSuOEili1wJw0ZVgqGc9aVokTcMeJIxDLaduPhm2XhGYhHVc/juCnhIbXU0=
X-Received: by 10.223.151.212 with SMTP id t20mr2593184wrb.2.1510392896813; Sat, 11 Nov 2017 01:34:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.160.149 with HTTP; Sat, 11 Nov 2017 01:34:15 -0800 (PST)
In-Reply-To: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>  
From: Warren Kumari 
Date: Sat, 11 Nov 2017 17:34:15 +0800
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ole Troan 
Cc: Fernando Gont , IPv6 Operations ,  "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 09:35:01 -0000

On Sat, Nov 11, 2017 at 4:42 AM, Ole Troan  wrote:
>> 1) My comment to the list was essentially arguing that this document
>> contains a protocol specification, and such part is not suitable. I
>> think it should be easy to converge on something regarding this one:
>>
>> Can anyone (you, for instance), provide a definition of what is a
>> protocol, and the run this document through such definition and figure
>> out if it fits or it doesn't?
>
>
> A protocol is a system of rules that allow _two_ or more nodes to communi=
cate.
> The protocol specifies the syntax, semantics and so on (1).
>
> A protocol specification does not specify only the wire format.
>
> 'unique-ipv6-prefix' does not specify changes in the wire-format, nor its=
 semantics.
> It only requires implementation change on one 'side' of the protocol, nam=
ely on the routers.
> From that perspective I think you can argue that this is not a protocol s=
pecification.
>
> I think you also make a point that there are further considerations here,=
 than just the wire-format. Especially around additional state in the route=
rs. In the early days of IPv6 design a lot of time and effort was made in a=
voiding state in the network. If this mechanism made address allocation inh=
erently less robust, I think a case could be made for why the IETF should s=
pecify this in more detail.
> I am not convinced of that though. (In my implementation per host prefix =
adds configured state, but dramatically lessens dynamic state (ND)).
>
> Interesting question.
>
> Cheers,
> Ole
>
> PS: This draft also raises some interesting IETF process issues around ch=
ange control, oversight and how involved the working group should be in cha=
nges happening after the document is handed over to the IESG.

Yup, that is always a tension.

In this particular case, there was an IETF LC on May 23rd, completing
June 6. There were a number of comments addressed and it went through
IESG review / telechat on Aug 17 telechat (as version -07).

There were enough issues raised during the IESG eval (and continuing
discussion on the V6OPS list exposing lack of clarity) that I decided
to return it to the WG on Sept 9th
(https://www.ietf.org/mail-archive/web/v6ops/current/msg27681.html)

The text under discussion was added in version -09 (Sept 14th).
There was a second WGLC (on version -12) on Oct 1st
(https://www.ietf.org/mail-archive/web/v6ops/current/msg28048.html)
which completed Oct 9th
(https://www.ietf.org/mail-archive/web/v6ops/current/msg28062.html).

I decided that the changes were sufficently small that it did not need
a second IETF LC (this may have been a mistake), and it had a second
IESG review / was on the October 12th telechat (as version -12).

How involved the WG should be after handing it to the IESG is always
tricky, but in this particular case the document was with the WG when
this text was added (which I think is fine).


W
>
> 1:Freely borrowed from wikipedia.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



--=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 Sat Nov 11 06:46:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6579E129601 for ; Sat, 11 Nov 2017 06:46:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM-gbqVRP-bw for ; Sat, 11 Nov 2017 06:46:30 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F7512953B for ; Sat, 11 Nov 2017 06:46:30 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vABEkSYD003658 for ; Sat, 11 Nov 2017 15:46:28 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6505D20123C for ; Sat, 11 Nov 2017 15:46:28 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 522D1200C21 for ; Sat, 11 Nov 2017 15:46:28 +0100 (CET)
Received: from [132.166.84.50] ([132.166.84.50]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vABEkRtT005538 for ; Sat, 11 Nov 2017 15:46:28 +0100
Subject: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: ipv6@ietf.org
References:  
From: Alexandre Petrescu 
Message-ID: 
Date: Sat, 11 Nov 2017 15:46:27 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 14:46:32 -0000

Le 09/11/2017 à 04:02, Erik Kline a écrit :
> I don't think we should be recommending unique RAs per device where
> the devices are all on a shared link.

I agree, me too.

> My understanding was that in the original motivating wifi deployment
> every node is effectively isolated in its own (pseudo)VLAN, and
> node-to-node traffic must be routed through the infrastructure (to the
> extent such a thing can actually be enforced in a medium like wifi).

There is a means to enforce such separation on WiFi.  It is a TCLAS. 
(this is not prefix-per-host).

Alex

> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Sat Nov 11 17:54:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766AB124BFA; Sat, 11 Nov 2017 17:54:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN--dakUueuP; Sat, 11 Nov 2017 17:54:01 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF819129412; Sat, 11 Nov 2017 17:54:00 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4] (unknown [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5E795800DD; Sun, 12 Nov 2017 02:53:56 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Brian E Carpenter , Ole Troan 
Cc: v6ops@ietf.org, "6man@ietf.org" <6man@ietf.org>, Enno Rey 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>   
From: Fernando Gont 
Message-ID: 
Date: Sat, 11 Nov 2017 22:49:23 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 01:54:03 -0000

On 11/10/2017 07:26 PM, Brian E Carpenter wrote:
> On 11/11/2017 09:42, Ole Troan wrote:
>>> 1) My comment to the list was essentially arguing that this document
>>> contains a protocol specification, and such part is not suitable. I
>>> think it should be easy to converge on something regarding this one:
>>>
>>> Can anyone (you, for instance), provide a definition of what is a
>>> protocol, and the run this document through such definition and figure
>>> out if it fits or it doesn't?
>>
>>
>> A protocol is a system of rules that allow _two_ or more nodes to communicate.
>> The protocol specifies the syntax, semantics and so on (1).
>>
>> A protocol specification does not specify only the wire format.
>>
>> 'unique-ipv6-prefix' does not specify changes in the wire-format, nor its semantics.
>> It only requires implementation change on one 'side' of the protocol, namely on the routers.
>> From that perspective I think you can argue that this is not a protocol specification.
> 
> I agree with that, and other versions of the same argument.

That certainly does not agree with my conception of what a protocol is,
which falls well under what was expressed on-list by Joe Touch.

If any of the FSMs that you can employ to model the protocol has
changed, you have changed the protocol.



> (That also
> answers Fernando's message directed at me, so I won't waste more bits.)
> 
> More on the philosophy side of the argument, WG Charters are a tool to
> allow the chairs and AD to control mission creep. They aren't sacred
> texts. So IMHO the real question is not whether this is strictly speaking
> a protocol extension, but whether it's a useful thing for the IETF to
> publish.

The "philosophy" of my comment is as follows:

* What is the document changes the SLAAC protocol, and maes SLAAC more
brittle: SLAAC is generaly resilient to a router rebooting, whereas,
with this protocol, it likely won't.

* There are a bunch of other aspects, from interoperability to security,
that have been ignored. The document just mentions "oh, we send the
multicasted RAs to unicast link-layer addresses" and essentially omits
way more cucial stuff, including: how do you time-out prefixes? How do
you generate them? What do you do when you don't have any more prefixes
to give away? And many others. Even if this same document/text was being
done in 6man, the protocol spec part is a half-baked protocol
specification. Even more, claiming that this *mechanism* a bcp, is quite
a bold statement when, as noted, there's *lots* that has been omitted.

* I would expect that the "beef" in a document is in what the wg ships
-- the rest is improvements. So, given that the protocol spec part of
this document was added after IETF LC, in a group that is not meant to
do Std Track documents, and given the issues mentioned above, I think
the protocol spec part in Section 4 is out of place.

* As a *side* comment/note: IPv6 automatic configuration is quite a mess
in a number of aspects (including
,
and
).
Publishing mechanism that is not even fully-specified and, even more,
flagging it as "bcp" just adds on top to that. I'd really also like to
see what's the criteria for specifying features in SLAAC and DHCPv6. For
instance... is the plan to duplicate in both as much functionality as
possible?  Or... do we just love SLAAC and will incorporate into SLAAC
everything that would make us otherwise use DHCPv6?  If there's
something available in one protocol (slaac or dhcv6) but not in the
other, and the feature is deemed as needed... should we use such
protocol or just figure out what to do to somehow implement such feature
in our belove one?  e.g. in this case, if what you want is a prefix, why
don't you use prefix delegation? And if the goal is just to isolate
nodes, set L=0 in the RAs, and so be it.

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





From nobody Sat Nov 11 18:25:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F22D128C83; Sat, 11 Nov 2017 18:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXLcWrYeteO4; Sat, 11 Nov 2017 18:25:19 -0800 (PST)
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 F323F124BFA; Sat, 11 Nov 2017 18:25:18 -0800 (PST)
Received: by mail-pf0-x234.google.com with SMTP id i5so9415351pfe.6; Sat, 11 Nov 2017 18:25:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CfT0fSufUljpj4TbcM6qnQpUVKXl8/nIx/HDXk5iwdg=; b=YATiVGE1GTUAUlr3wnMYoCBYL6bz3hiLRa2A9kIUKlFn2788TM+STnxdHQHAd4KDko UMY9Nt3UHpLDKqcHXsOZrZzRQMkKqFOOY5aquFZRR5+P6zIwIztDzX/hjmpNI5HvQAxZ ytlszB7bVupuM5y6GA528Y3oNZ6Bu/uuIm7JKg3xbASgiOKCgAl6SVhecBDicDrG60kt jCba+DerZpEr0z1p7k11mWSe3GB2+LZT4ZudWuNVShP/ro3ZkvBp9H/dMkwiKe7m/V+/ GLYg+m8R2UnzsXgTntHmOnJMeqjmjMmRPd8LcvRUCFNU51NUL+c/h6K5Pvo5AQmuweky kxKg==
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=CfT0fSufUljpj4TbcM6qnQpUVKXl8/nIx/HDXk5iwdg=; b=FdQ8IXiXWYuF+x0GqOa51TtWAHQqrRAx/jbA92see+0feOIq1OnGSISV9KPgErM2gN uGKJ9DIX9FmOqZMoypSc4kxfNubzAQ5J4PBGDeQ2lSgP8HUSsx3EHS+0eVSXdDiXc8vd 8UruGz04UguJRDtgLw756bIIJiKeHIrRpoK8whqlROHGGrb2W1IuazDJj/zmd9669NXJ 7wNUu8jdM1BBHQIX5vUwenMfg+nf/qTvbdikh/bJ0ClHGfBy9LDZZl0Wymy+jBE1ymNq l+ntTXNjmi3Hjh1WPJ2AvYh5HPd5mf1i3Kd0mpZD0o/eXDJ7mkp0McTvJ4hRl2GXRoOe Khng==
X-Gm-Message-State: AJaThX4/FNBWbxjvIRSQZbWecbLTZS0LxDPsJITNLuxuAHR8ELt4DP5B wDFk8nDBcq8F8UfK38WGDXs=
X-Google-Smtp-Source: AGs4zMZX/48dzcOw3kVbJLzZl0j7SoD3YX0tZDCydCABGraJD2JLZ1WM4mmu+5M5UAnLUD4GlfwnYg==
X-Received: by 10.101.77.3 with SMTP id i3mr4782529pgt.311.1510453518543; Sat, 11 Nov 2017 18:25:18 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id b6sm20183526pgc.2.2017.11.11.18.25.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 18:25:15 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim 
In-Reply-To: 
Date: Sun, 12 Nov 2017 11:25:12 +0900
Cc: Brian E Carpenter , Ole Troan , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8F6B656B-BD9B-4F23-B534-88AD685EE7EB@gmail.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    
To: Fernando Gont 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 02:25:20 -0000

I=E2=80=99m not sure whether setting L=3D0 guarantees node isolation:

  https://tools.ietf.org/html/rfc4861#section-4.6.2

 =E2=80=9CL    =E2=80=A6 When not set the advertisement makes no =
statement about on-link or off-link properties of the prefix. In other =
words, if the L flag is not set a host MUST NOT conclude that an address =
derived from the prefix is off-link.  That is, it MUST NOT update a =
previous indication that the address is on-link.=E2=80=9D

That is, with refreshing L=3D0 for the same prefix, the previous on-link =
property of the prefix continues to be valid.

---
DY

> On 12 Nov 2017, at 10:49, Fernando Gont  wrote:
>=20
> And if the goal is just to isolate
> nodes, set L=3D0 in the RAs, and so be it.


From nobody Sat Nov 11 18:50:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97500127337 for ; Sat, 11 Nov 2017 18:50:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzEMer_QrkmI for ; Sat, 11 Nov 2017 18:50:11 -0800 (PST)
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 E9680124BFA for ; Sat, 11 Nov 2017 18:50:10 -0800 (PST)
Received: by mail-pf0-x231.google.com with SMTP id j28so7102779pfk.8 for ; Sat, 11 Nov 2017 18:50:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Lw9dzp+AfyDDNFESpve0fO6dxpyRoB7uAZI9gV0DLps=; b=pRXAsI5yFmcw2dgb1sCCswFChjvSjGjquHuVIa1uXKfkH2filnfbNv3Twt5n0IJd8q n6Miqn+wCp3VhaRwIi2urvVIm9X/HYiJ6VAOZt9ac++qi9ZymCTVGkmRA6x6jqpoDaia j8ydOIPQn/cpJmOeKOsQaBsTcQWqOjlqHXb9ED4URBUjCMIILW1bwOtVu3uhkzRPNoEf e8etNgmNer7ucZECiNBByX+bNM4UJoVzWpZAv2P49Au/AX+MU9f51ezJBhT2nA9vUE7d Ow2CHJIGLDuhdAjf3QK2ow3ev5Cr1KIaglunAWyqfUSQDdz3qxhoV5V/F5tV2XMvXTd0 0fYA==
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=Lw9dzp+AfyDDNFESpve0fO6dxpyRoB7uAZI9gV0DLps=; b=J8OaVnd5iSjQkWEbKPyfPIu+IdYe9bL+kiyp7rY197JmTL2YdobsUNEKU3Bf+PTUlH zStWyOu2gVHtfAPUZmrk92eMRqmfgmUWgKAKamEf+JSr4gZxXT4QXrvEimvqSwjK0+XM EqBvioWgWGXufe9JQ+Ry7l1/TtckqM3SWIJOcFh+m7SPTY6IwXLcYFE/vOTywnds7PDK g6wp1xJgdDERZWfJeT2DMGLIETC9/7KKfSIKDjXbL61bYXejvHS1wsZzSb58aqL+sLl2 bnlbHBYyT9xEeRlXzqkDW9YnFVQ1mNj21fa/kcJ6v9wQ8sP7mvXJ5LDDPqeDQdbyX8Z7 SBSQ==
X-Gm-Message-State: AJaThX7U0fCLRzvciYBA4/6WrE4fz67y8yHvoC5oxUSdzwhdUsDeksrr mw3dDG6rPWp5awd4uX7mvbcB7kMU
X-Google-Smtp-Source: AGs4zMYs2vIHyadL2v2y77Ra054aMpmWgVTd8aR10v0Jq5pUrctA41KiHVal+lCLIU9zNUQbTvM9GA==
X-Received: by 10.159.204.139 with SMTP id t11mr5145020plo.121.1510455010174;  Sat, 11 Nov 2017 18:50:10 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:ddbc:f5b0:f56b:1c6? ([2001:67c:370:128:ddbc:f5b0:f56b:1c6]) by smtp.gmail.com with ESMTPSA id s6sm21444988pgq.57.2017.11.11.18.50.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 18:50:09 -0800 (PST)
From: Bob Hinden 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_DB607A69-74B7-40BA-99FA-CCA7779EA72B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Date: Sun, 12 Nov 2017 10:50:07 +0800
In-Reply-To: 
Cc: Bob Hinden , Michael Richardson , "C. M. Heard" , Fernando Gont , Brian Carpenter 
To: IPv6 List 
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com> <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk> <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com> <12447.1510153859@obiwan.sandelman.ca> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 02:50:13 -0000

--Apple-Mail=_DB607A69-74B7-40BA-99FA-CCA7779EA72B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I went back and looked at the RFC8200 text that deals with header =
insertion.  It does not actually mention IPIP.  The published text in =
Section 4. "IPv6 Extension Headers" regarding header insertion is:

   Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header.

   The Hop-by-Hop Options header is not inserted or deleted, but may be
   examined or processed by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv6 header.  The Hop-by-Hop Options header, when present, must
   immediately follow the IPv6 header.  Its presence is indicated by the
   value zero in the Next Header field of the IPv6 header.

Some earlier drafts include IPIP as a way of inserting headers, but that =
wasn=E2=80=99t included in what became RFC8200.

Bob


> On Nov 9, 2017, at 3:15 AM, Brian E Carpenter =
 wrote:
>=20
> On 09/11/2017 04:10, Michael Richardson wrote:
>>=20
>> Brian E Carpenter  wrote:
>>>   Note that it is impossible for a node to distinguish between an
>>> unrecognized extension header and an unrecognized upper layer
>>=20
>> Does "unrecognized" mean unknown to the writer of the code at the =
time of
>> writing, or does it mean a header which the node has no support for?
>=20
> I think it means unrecognized at run time, regardless of whether it =
was
> known or unknown when the code was written, or configured on or off =
when
> the node was instantiated, or even configured off one microsecond =
before
> the packet arrived. So TBD would be return_icmp(1) in your case.
>=20
> IMHO.
>=20
>     Brian
>=20
>>=20
>> Or to put it in C, what goes into TBD?
>>=20
>> retry:
>>  switch(proto) {
>>  case IPPROTO_UDP:
>>       udp_rcv();
>>       break;
>>  case IPPROTO_TCP:
>>       tcp_rcv();
>>       break;
>>  case IPPROTO_AH:
>>       if(ipsec_enabled) ipsec_rcv();
>>       else TBD;
>>  case IPPROTO_HOPOPT:
>>       process_hopopt();
>>       goto retry;
>>  case IPPROTO_MOBILITY_HEADER:
>>       skip_hopopt();
>>       goto retry;
>>  default:
>>       return_icmp(1);
>>  }
>>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--Apple-Mail=_DB607A69-74B7-40BA-99FA-CCA7779EA72B
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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloHtt8ACgkQrut0EXfn
u6jciQf/WCuJN+dHGTP3MGwZHG5zsZfEPvdivhgA8ESct+tslnNjxqbEDhDaWZZD
QCh6NjzCLDGEcIQGaAArm6fPjAw8oyRtMa0UYkONX84mq5uDvVeMWVKsIVx+V06B
9xoQfD2lpoRQF/4+cSiLXZAzvBvzWvj4HNrJuMN1i1veljOyx6gvgStkTZeRrPeI
wbA0ARDFgCLmWz3g/k/gbvkrwLQauo9cNi+r8DpvalTeo0nnfBFdIVlRHVUa1bO2
FW/WUUKlzwoN6HlqdLuWqJMvlfJbOwWjm8z6k4nw0UZYrXYXCFeU6GFB94cU3PlY
jscZT2KQiM/rLUVR16cvmh5SSIYqsQ==
=6+GD
-----END PGP SIGNATURE-----

--Apple-Mail=_DB607A69-74B7-40BA-99FA-CCA7779EA72B--


From nobody Sat Nov 11 23:42:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0028F12751F; Sat, 11 Nov 2017 23:42:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KW2JfumY-zTa; Sat, 11 Nov 2017 23:42:20 -0800 (PST)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BD412711D; Sat, 11 Nov 2017 23:42:20 -0800 (PST)
Received: by mail-wm0-x232.google.com with SMTP id b189so2633696wmd.5; Sat, 11 Nov 2017 23:42:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7B02J9JxxHZLtS1PrU21R42OQoJnWymPB8VuxOUnt9o=; b=ZT/3AdCVfzVNdI6/lfSYzf7/oWa8ZiZ0tN//cKG5PewIRJdALCZnMwWXfQ+WlftPgs Dm3y1xrTtLXIS8ZFKV9dBGm9TSv+EXcSn17iJfQd4TGK3k50uahyg/Dkdk5i53MXzUZk veZ99iHhxnhDj5H5CthI8Rk9HvC1+XA7QUHaEaEqHW2m3AZ2D/UenUIxliHIrXLAexXQ bTPV5FCMHk8r4CSGj/DUV19y7woDdf5hpFbaN6TDwRUQqLP9MENVn9wgeIKOri9S4qEY Mypon1D9bOrqd+7VwD3oPh1/6OWAb/3YzGHvHrHdfoFEv1CU4Lu14wyHydzEgThuIMWf IqBw==
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=7B02J9JxxHZLtS1PrU21R42OQoJnWymPB8VuxOUnt9o=; b=oqfQfi/n+evpsM42HFsFlHUtn/IBGJbgBONYEETjGkK9GlX1i5uzg618eBeiCK3ljt ctJ6GYQrI8OqL7WfPWRDJouBvQ9U7LN5mtUD1BKmdO5BF3Ho/iHevgSEnSWPu/5xR3b8 00oOTRpBeaUC0CQH92sapH4vH6Q5IaVWQ3l8waB/h+3MyYv4DSrEXnuHu8wl5I/4DZfW HCTbfiB85OPRyTpKP9PRKvgdwSTNRB+n5c8NzDAim8omR5ToB+nznPaN0h57GNmA4fvn so4Wagbc31liSksXDIP5SxQe7mhpYTGzBsX2uC8JmRaGh1CM6iw01OEgaKhXVaRl40+H CD1A==
X-Gm-Message-State: AJaThX7m0/3cwoMLsL+e9jg3IWpSMPeDo2WKk7MEXt/HNQebRt6j8nU+ Z4s4XQaFDaLUYWj3YELEdQA=
X-Google-Smtp-Source: AGs4zMbd/q2G6JAOPR+4LXMQfwEurVdtg52mhbEcuGf7Dbw6wBdO53SvdQwpFnMuou12DGlFeHZgBQ==
X-Received: by 10.80.145.13 with SMTP id e13mr7625946eda.22.1510472539035; Sat, 11 Nov 2017 23:42:19 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:d143:9ee:c44f:9c93? ([2001:67c:1232:144:d143:9ee:c44f:9c93]) by smtp.gmail.com with ESMTPSA id 41sm10833702edz.66.2017.11.11.23.42.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 23:42:17 -0800 (PST)
From: Bob Hinden 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_6D5FF35D-1919-4D99-8B33-84DB836B943E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Sun, 12 Nov 2017 15:42:02 +0800
In-Reply-To: 
Cc: Bob Hinden , DY Kim , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org, Fernando Gont 
To: Ted Lemon 
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com>  
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 07:42:22 -0000

--Apple-Mail=_6D5FF35D-1919-4D99-8B33-84DB836B943E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Ted,

> On Nov 11, 2017, at 11:18 AM, Ted Lemon  wrote:
>=20
> On Nov 11, 2017, at 11:02 AM, DY Kim  wrote:
>> Hence, the issue, if any, should be raised against the router spec, =
not against this draft or even SLAAC, I=E2=80=99d think.
>=20
> There's clearly an issue.   The router has to preserve the prefix =
assigned to the host across reboots, or else the host will have to flash =
renumber.   This would be quite a bit worse than current behavior with =
SLAAC, and I think is unacceptable.

I agree.  I think this document needs to address this topic.

Bob



--Apple-Mail=_6D5FF35D-1919-4D99-8B33-84DB836B943E
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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloH+0oACgkQrut0EXfn
u6jaZAf/TpFyTcGCW4iY+qpVatu1ul2LA2WgOk4ACAkwJQwQYN7OBnxWIpACdLZD
KXB4m/fkfeMTHscelDbK2MsnAc37942hS/7s9NpRXugjlZ0OBuy206FLtL2vxxNd
emJbMWVPxqU34VsHXQcrDaPxVTQD38JMdDTddOc4Kbd/eOpipHmiQJt+tm9zJPgH
7kNpZDt51O0PEpemNSZ04+HALE9OL63lsF7cStSEoS12e6FA7mb5L5Wgzaazm/OA
Qiau696HDZtSrkdwfJis/qZSQxbu80606lUmtl+ufWWekTE15IHLfH0BVjY5cxl9
6aRmH43ov10PYOi/hyFsqJB1iCv0SQ==
=I00J
-----END PGP SIGNATURE-----

--Apple-Mail=_6D5FF35D-1919-4D99-8B33-84DB836B943E--


From nobody Sun Nov 12 04:56:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97844126557; Sun, 12 Nov 2017 04:56:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25yvXYKckIGK; Sun, 12 Nov 2017 04:56:53 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350D7124B0A; Sun, 12 Nov 2017 04:56:53 -0800 (PST)
X-Envelope-To: v6ops-ads@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vACBuSHS020495 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Nov 2017 11:56:29 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <5A084504.7080003@foobar.org>
Date: Sun, 12 Nov 2017 12:56:36 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Fernando Gont 
CC: Joe Touch , james woodyatt , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <52C752BD-2347-4704-9103-89BD979D7C2D@google.com> <5fc6a1b1-7707-b5ab-7820-98f9f07b794c@strayalpha.com> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 12:56:54 -0000

Fernando Gont wrote:
> FWIW, I agree with everything that Joe said below.
> 
> Now, consider the FSM of router side of SLAAC, and compare it with the
> FSM of the mechanism being proposed. The difference should be evident.

The ID also omits any discussion about how this state is managed in the
context of source address validation by edge devices.

This would be important from an operational point of view, as it
introduces a substantial degree of state management into the network
infrastructure, not just the next-hop router.

Nick


From foglar@innoroute.de  Sun Nov 12 13:05:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0533127011; Sun, 12 Nov 2017 13:05:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=innoroute.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3ncGlo3Aoml; Sun, 12 Nov 2017 13:05:43 -0800 (PST)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A6C1270AB; Sun, 12 Nov 2017 13:05:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1510520738; s=domk; d=innoroute.de; h=Content-Language:Content-Type:MIME-Version:Date:Subject:In-Reply-To: References:Cc:To:From; bh=4eivS0mUuBqemwArPQlJplDrHjPRX8o/jvwQEoooa/Y=; b=B9GXJ0C9XjB2B7B10CnL4U75j6W1y4epSWx6reWgJcC0nNrN7sPWBE/Y1AIxcFtmIZ zO/i7gi4Z3dg6wEtz/2tiENJuhnijjTmYgDASsFxgEoppwf8CR83hJ2CpWl5BPuISHlX UCTAKBNZ6Iqg3/CnXYJEyVw1xA0JfAwPmN54Y=
X-RZG-AUTH: :KmMDeUG6W/ZiEDs/O264G0e18fDodBReuN95R7/q763ViEa4qzv2lntT5bYA/P7nZn28zNF1uA==
X-RZG-CLASS-ID: mo00
Received: from x220philipp (p5083744A.dip0.t-ipconnect.de [80.131.116.74]) by smtp.strato.de (RZmta 42.9 DYNA|AUTH) with ESMTPSA id Q04276tACL3isBX (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client did not present a certificate); Sun, 12 Nov 2017 22:03:44 +0100 (CET)
From: 
To: "'Mark Smith'" , "'Ole Troan'" , "'Brian E Carpenter'" , "'Mikael Abrahamsson'" 
Cc: , "'6man WG'" , "Mike Parker" , "Theodoros Rokkas" 
References: <150523432567.17956.11322312258310497482@ietfa.amsl.com> <7e8fd49f-a777-fd9e-d410-be7e8d5958cc@gmail.com> <3F17FC48-D8CB-46A4-A8B3-0BC7F65E6D26@employees.org>  
In-Reply-To: 
Subject: AW: I-D Action: draft-foglar-ipv6-ull-routing-00.txt
Date: Sun, 12 Nov 2017 22:03:44 +0100
Message-ID: <02d801d35bf9$b9f96530$2dec2f90$@innoroute.de>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D9_01D35C02.1BC26110"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIMisSjuJ1HD67tWJN72AqiLPZOWQJNj0JhAbMNloACZGwcKQGb3N6/oks4HnA=
Content-Language: de
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 21:06:56 -0000

This is a multipart message in MIME format.

------=_NextPart_000_02D9_01D35C02.1BC26110
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Dears Mark, Brian, Ole, Mikael and Bob,

Thank you for your valuable comments to our draft.=20

First of all, I am sorry that the sentence =E2=80=9COne of the goals of =
IPv6 was to have a sufficiently long address to allow grouping in fields =
to simplify routing decisions.=E2=80=9D did cause so much irritation.
The background was: in the mid-nineties I have read a document called =
=E2=80=9CThe case for IPv6=E2=80=9D, where one of its goals was that the =
structure of the IPv6 address should simplify routing. I remember this =
requirement well, because at that time I was working for a chip =
manufacturer and we considered making a dedicated IPv6 routing chip. =
Unfortunately, I could not find this document for the original citation.

Answer: I will remove the first two of the chapter sentences and add =
this simple one:
"The following proposal uses the 64-bit IPv6 address prefix."=20

Next, I thank Ole Troan for citing Y. Rekhter: =E2=80=9CAddressing can =
follow topology or topology can follow addressing; choose one=E2=80=9D.
Answer: in this case addressing and topology already match perfectly. In =
short: where more people are living there are more telephone numbers =
assigned. In case there are not enough addresses there are spare ones: =
currently only the digits 0=E2=80=A69 are used; by extending to =
A=E2=80=A6F the address space can be almost doubled.=20

Finally, there was a comment the proposal means replacing a great deal =
of existing software and hardware.=20
Answer: hardware effort is low, as not all hierarchies must be populated =
by forwarding nodes. Also, existing infrastructure such as transmission =
links can be reused. Both are outlined in an example at the end of the =
draft.=20

A corrected draft is uploaded.

With best regards,
Andreas Foglar
InnoRoute CEO
Phone +49-89-4524199-01
Mail foglar@innoroute.de =20
www.innoroute.com =20
Marsstr. 14a, D80335 Munich, Germany





-----Urspr=C3=BCngliche Nachricht-----
Von: Mark Smith [mailto:markzzzsmith@gmail.com]=20
Gesendet: Samstag, 16. September 2017 03:07
An: Brian E Carpenter 
Cc: Ole Troan ; =
draft-foglar-ipv6-ull-routing@ietf.org; 6man WG 
Betreff: Re: I-D Action: draft-foglar-ipv6-ull-routing-00.txt

On 16 September 2017 at 09:31, Brian E Carpenter =
 > =
wrote:
> On 15/09/2017 20:10, Ole Troan wrote:
>>> Re https://tools.ietf.org/html/draft-foglar-ipv6-ull-routing-00
>>>
>>> "One of the goals of IPv6 was to have a sufficiently long address to =

>>> allow grouping in fields to simplify routing decisions."
>>>
>>> What makes you believe that? I don't recall such a goal in the IPng=20
>>> process, and I can't see any trace of it in RFC1752 or RFC1726.
>>
>>
>> =E2=80=9CAddressing can follow topology or topology can follow =
addressing;=20
>> choose one=E2=80=9D - Y Rekhter
>>
>> Goal or no goal, we know of no other way to make the routing system =
scale.
>
> Sure. I agree with that and with the RIPE policy that Mikael cited.=20
> Believe me, everybody in the IPng discussion was acutely aware of the=20
> tension between PA and PI addressing and the benefits of aggregation=20
> when possible. But that is very different from the quoted "goal",=20
> which simply wasn't there. Allowing topological aggregation was a=20
> goal, of course, but that's always been a matter of prefix assignment =
policy, not of the protocol design.
>
> Please note that I did not say that their idea will not work. It's the =

> "alternative fact" that I'm concerned about.

>From what I've read in Christian Huitema's IPv6 book, at one stage
there was a thought of swapping the source and destination address =
fields so that the DA field was first, to facilitate this sort of =
cut-through forwarding. From memory, the explanation was that it was =
decided against was because fields other than the just the DA address =
have to be processed during layer 3 forwarding.

Regards,
Mark.



>
>     Brian
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org =20
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

------=_NextPart_000_02D9_01D35C02.1BC26110
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable






AW: I-D Action: draft-foglar-ipv6-ull-routing-00.txt





Dears Mark, Brian, Ole, Mikael and =
Bob,



Thank you for =
your valuable comments to our draft. 



First of all, I am =
sorry that =
the sentence =
=E2=80=9COne =
of the goals of IPv6 was to have a sufficiently long address to allow =
grouping in fields to simplify routing decisions.=E2=80=9D did cause =
so much irritation.



The background =
was: in the mid-nineties =
I have read a document called =E2=80=9CThe case for IPv6=E2=80=9D, where =
one of its goals was that the structure of the IPv6 address should =
simplify routing. I remember this requirement well, because at that time =
I was working for a chip manufacturer and we considered =
making a dedicated IPv6 routing =
chip. Unfortunately, I could not find this document for the original =
citation.



Answer: I will remove the first two of =
the chapter sentences and add this simple one:



"The =
following proposal uses the 64-bit IPv6 address =
prefix." 



Next, I thank =
Ole Troan for citing Y. Rekhter: =
=E2=80=9CAddressing can follow topology or topology can follow =
addressing; choose one=E2=80=9D.



Answer: in this case addressing and =
topology already match perfectly. In =
short: where more people are living there are more telephone numbers =
assigned. In case there are not enough addresses there are spare ones: =
currently only the digits 0=E2=80=A69 are used; by extending to =
A=E2=80=A6F the address space can be almost doubled. 



Finally, there =
was a comment the proposal means =
replacing a great deal of existing software and =
hardware. 



Answer: =
hardware effort is low, as not all hierarchies must be populated by =
forwarding nodes. Also, existing infrastructure =
such as transmission links can be reused. Both are outlined =
in an example at the end of the draft. 



A corrected draft is uploaded.






With best =
regards,



Andreas =
Foglar



InnoRoute =
CEO



Phone =
+49-89-4524199-01



Mail foglar@innoroute.de



www.innoroute.com



Marsstr. 14a, =
D80335 Munich, Germany















-----Urspr=C3=BCngliche Nachricht-----

Von: Mark Smith [mailto:markzzzsmith@gmail.com]=


Gesendet: Samstag, 16. September 2017 03:07

An: Brian E Carpenter =
<brian.e.carpenter@gmail.com>

Cc: Ole Troan <otroan@employees.org>; =
draft-foglar-ipv6-ull-routing@ietf.org; 6man WG =
<ipv6@ietf.org>

Betreff: Re: I-D Action: =
draft-foglar-ipv6-ull-routing-00.txt



On 16 September =
2017 at 09:31, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:



> On =
15/09/2017 20:10, Ole Troan wrote:



>>> =
Re https://tools.ietf.org/html/draft-foglar-ipv6-ull-routin=
g-00



>>>



>>> =
"One of the goals of IPv6 was to have a sufficiently long address =
to 



>>> =
allow grouping in fields to simplify routing =
decisions."



>>>



>>> =
What makes you believe that? I don't recall such a goal in the IPng =




>>> =
process, and I can't see any trace of it in RFC1752 or =
RFC1726.



>>



>>



>> =
=E2=80=9CAddressing can follow topology or topology can follow =
addressing; 



>> choose =
one=E2=80=9D - Y Rekhter



>>



>> Goal =
or no goal, we know of no other way to make the routing system =
scale.



>



> Sure. I =
agree with that and with the RIPE policy that Mikael cited. =




> Believe =
me, everybody in the IPng discussion was acutely aware of the =




> tension =
between PA and PI addressing and the benefits of aggregation =




> when =
possible. But that is very different from the quoted "goal", =




> which =
simply wasn't there. Allowing topological aggregation was a =




> goal, of =
course, but that's always been a matter of prefix assignment policy, not =
of the protocol design.



>



> Please =
note that I did not say that their idea will not work. It's the =




> =
"alternative fact" that I'm concerned about.



>From what =
I've read in Christian Huitema's IPv6 book, at one =
stage



there was a =
thought of swapping the source and destination address fields so that =
the DA field was first, to facilitate this sort of cut-through =
forwarding. From memory, the explanation was that it was decided against =
was because fields other than the just the DA address have to be =
processed during layer 3 forwarding.



Regards,



Mark.







>



>     Brian



>



>



> =
--------------------------------------------------------------------



> IETF IPv6 =
working group mailing list



> ipv6@ietf.org



> =
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=




> =
--------------------------------------------------------------------




------=_NextPart_000_02D9_01D35C02.1BC26110--


From nobody Sun Nov 12 13:22:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0161273B1 for ; Sun, 12 Nov 2017 13:22:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.852
X-Spam-Level: 
X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qP5kWyRwFO58 for ; Sun, 12 Nov 2017 13:22:36 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F901124F57 for ; Sun, 12 Nov 2017 13:22:36 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4] (unknown [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 177D980548; Sun, 12 Nov 2017 22:22:28 +0100 (CET)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Bob Hinden , IPv6 List 
Cc: "C. M. Heard" , Michael Richardson , Fernando Gont 
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com> <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk> <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com> <12447.1510153859@obiwan.sandelman.ca>  
From: Fernando Gont 
Message-ID: <45f01790-0561-68b9-e245-0a126c7e110b@si6networks.com>
Date: Sun, 12 Nov 2017 14:52:35 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 21:22:38 -0000

Hi, Bob,

On 11/12/2017 10:50 AM, Bob Hinden wrote:
> I went back and looked at the RFC8200 text that deals with header insertion.  It does not actually mention IPIP.  The published text in Section 4. "IPv6 Extension Headers" regarding header insertion is:
> 
>    Extension headers (except for the Hop-by-Hop Options header) are not
>    processed, inserted, or deleted by any node along a packet's delivery
>    path, until the packet reaches the node (or each of the set of nodes,
>    in the case of multicast) identified in the Destination Address field
>    of the IPv6 header.
> 
>    The Hop-by-Hop Options header is not inserted or deleted, but may be
>    examined or processed by any node along a packet's delivery path,
>    until the packet reaches the node (or each of the set of nodes, in
>    the case of multicast) identified in the Destination Address field of
>    the IPv6 header.  The Hop-by-Hop Options header, when present, must
>    immediately follow the IPv6 header.  Its presence is indicated by the
>    value zero in the Next Header field of the IPv6 header.
> 
> Some earlier drafts include IPIP as a way of inserting headers, but that wasn’t included in what became RFC8200.

Does IPIP simply mean tunelling IP over IP?

If so, that'd be tunneling, rather than "header insertion".

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





From nobody Sun Nov 12 16:14:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87921241F5 for ; Sun, 12 Nov 2017 16:14:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2YehbLC6tcM for ; Sun, 12 Nov 2017 16:14:06 -0800 (PST)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A3071200C5 for ; Sun, 12 Nov 2017 16:14:06 -0800 (PST)
Received: by mail-pg0-x22b.google.com with SMTP id p9so11414094pgc.8 for ; Sun, 12 Nov 2017 16:14:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=pZJYr/mXOkWOGkH43M4LkeHNYFsoB/4wCzqNUe+1nZI=; b=BwZDieFVpuwQ8zqaslbEeaG4JS6kKdM0QMBVaDaPHH8g2DsxjCqgu6s0H2rEz171zg WJBvtoH2yEX7ygAR+6z97Oc7b5hUcNY29l3AW2WZPZJnfesSgH2C1DHHxVDREXwyMO0A /1qFhFNCDrnXsfAx/qooOUOb9ZCHzNjLLpsc1khf/4XffbzSVatiLoQ3IngmX7rdd1lo fjAu+RK3vIgELdVmUFN9tyJFVYB+jjjjsX7KCxi+BhwZcz832oywDAbKsxzxxMpduuYm l7KE3PxDi7f6j8YFM93YEcLoajZHH/AZh69aguNolQKuFcUF5L9iCD0H5nycrVNXydA6 WA2w==
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=pZJYr/mXOkWOGkH43M4LkeHNYFsoB/4wCzqNUe+1nZI=; b=TAoJcDFuyvvcN2VnbpMXTQ4AE24y4y6H1f4JQgPE8CiG1O51RA6lYzCDRqslJx97f7 u3mFgsjS101K+qH5Nxbfj4wF4FCD2oE91k9ace6s+tjYQ1IQuB13mGAGV16GfGQcIYCR QS47oWYnQm+KB9D4N/mbcwN83sbVSiwu7AxxN8fRL+7WPHO0Pb/Hd+ICmbO4w4AOoLS7 VilwdpAS5euB0lP0vsUcW8/lrBnE8a/UeaQAr9ukTOfte/L6F3D8n9P8c3F4tIrBcih6 +Cac/Y5TqmsHi56o3U88wggQ8X8mqrZWgDDZ4Rn0MuBpTjcB90/K4apSTSpR8iYWiF1+ oUiw==
X-Gm-Message-State: AJaThX41eT9e6tV+fmdtX42l3e6xIOm/KjZlwG3W5w9FF/3SLN1WCLVx dWbYt8B46TFLOwXzPE3S0UI/cwAt
X-Google-Smtp-Source: AGs4zMZe3HQzicnhmhZYYfiwKPuN9t+S0Frr5M6M8jtWBc6zNq6ZsYGzZ+TulKPYV4wpWP/Jc5WMtw==
X-Received: by 10.98.69.86 with SMTP id s83mr8048365pfa.32.1510532045839; Sun, 12 Nov 2017 16:14:05 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id x79sm30998678pfa.156.2017.11.12.16.14.03 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 16:14:04 -0800 (PST)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: ipv6@ietf.org
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com> <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk> <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com> <12447.1510153859@obiwan.sandelman.ca>   <45f01790-0561-68b9-e245-0a126c7e110b@si6networks.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <9c39822b-584b-557c-635a-a1529f94cbd5@gmail.com>
Date: Mon, 13 Nov 2017 12:55:46 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <45f01790-0561-68b9-e245-0a126c7e110b@si6networks.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 00:14:08 -0000

On 12/11/2017 19:52, Fernando Gont wrote:
> Hi, Bob,
>=20
> On 11/12/2017 10:50 AM, Bob Hinden wrote:
>> I went back and looked at the RFC8200 text that deals with header inse=
rtion.  It does not actually mention IPIP.  The published text in Section=
 4. "IPv6 Extension Headers" regarding header insertion is:
>>
>>    Extension headers (except for the Hop-by-Hop Options header) are no=
t
>>    processed, inserted, or deleted by any node along a packet's delive=
ry
>>    path, until the packet reaches the node (or each of the set of node=
s,
>>    in the case of multicast) identified in the Destination Address fie=
ld
>>    of the IPv6 header.
>>
>>    The Hop-by-Hop Options header is not inserted or deleted, but may b=
e
>>    examined or processed by any node along a packet's delivery path,
>>    until the packet reaches the node (or each of the set of nodes, in
>>    the case of multicast) identified in the Destination Address field =
of
>>    the IPv6 header.  The Hop-by-Hop Options header, when present, must=

>>    immediately follow the IPv6 header.  Its presence is indicated by t=
he
>>    value zero in the Next Header field of the IPv6 header.
>>
>> Some earlier drafts include IPIP as a way of inserting headers, but th=
at wasn=E2=80=99t included in what became RFC8200.
>=20
> Does IPIP simply mean tunelling IP over IP?
>=20
> If so, that'd be tunneling, rather than "header insertion".

Yes, but the point was to say that this is a valid way to attach extra
headers. And iirc we concluded that while true, it isn't necessary
to write it down.

(Also there's a proposed standard for this if you need it: RFC2473.)

   Brian


From nobody Sun Nov 12 16:15:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18BD126CD6; Sun, 12 Nov 2017 16:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXP1QznYlDAl; Sun, 12 Nov 2017 16:15:25 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61091241F5; Sun, 12 Nov 2017 16:15:24 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id j28so8295974pfk.8; Sun, 12 Nov 2017 16:15:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SBwLysaQgmNCbBQTTaTdqTJ2P9Lr6n8Ab1/gVcd/LaM=; b=a6bbrOiVu6BMuEQeQQ5qsrCKpn4zre4H0hYXJ/oAmg777n65Z+Lazz25bYbfRRWIAd uwx2EJbFNyfo5B0ZANom5wz1weZ65Uzm5Zl9daqOoUem5X7aHnhCmekQRuybEU+njtbY Fub9u9YahgLkzmQAw3HLPf5f6fwsTiCPl5KYMa6rBk6DUeMxJdmyVSLs6f7OUbCmhfcS ecPMWMQL+uFJFLkPBIxu0GAHWwTa6RhQatSlIs0kv9IM3/nR/u/JVo2f0jQp1cnYl9Di JGrMXG2FTF7gJpKTOiF79JBZFtU2KMELnmNwmoa6KNCg6ZkrevQwtATZbVyIVu43nTVz Du7A==
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=SBwLysaQgmNCbBQTTaTdqTJ2P9Lr6n8Ab1/gVcd/LaM=; b=exjgdUH7fvYtiOA8uAOEi03pVOTYOrhmr1/BsW94+Uq37VjcW0cZCwgYv0+50o1E+7 UDm5KyDhp34JTA6bj9uqENa3M2g0FIjS7B1/HjRHCUnSuZYrt1nrqfqvVitp+0KJNXPl 3GcnnHbqi7OGDEtKOXsU8oH66vSU877nyrm9nEUO/85pYsQ7roqKGLuR9NIr4gHwwUcv A5Bdnlo47itS5CsttXII1sZnJVLpKSuOYBRcZQqQiwMOCjwNtuZC2J7qGZEDjXzlM1hl qmJq04OshoirHCw8n+2RfLn7mfgioGeJLUrD7HxzLYPAKhXw4VIhj3DprhXdH+DzoiCu 4q1A==
X-Gm-Message-State: AJaThX5a7hVf/7SqdrCZgu66+TRAfNGJbKxLIZ7Ki7y6rY8YrFkUjmTO zco57r8vjXuMBlgP1MZFLlt51Lt9
X-Google-Smtp-Source: AGs4zMaKfoFmaNzHYManrOIOngA9GxfZr0AzH3s7hLZs2stBcdYSI3k0fGsb0HyBPlOcB+XcTuK64g==
X-Received: by 10.84.213.9 with SMTP id f9mr7006805pli.76.1510532124430; Sun, 12 Nov 2017 16:15:24 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id l21sm18990722pgc.76.2017.11.12.16.15.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 16:15:23 -0800 (PST)
Subject: Re: AW: I-D Action: draft-foglar-ipv6-ull-routing-00.txt
To: foglar@innoroute.de, 'Mark Smith' , 'Ole Troan' , 'Mikael Abrahamsson' 
Cc: draft-foglar-ipv6-ull-routing@ietf.org, '6man WG' , Mike Parker , Theodoros Rokkas 
References: <150523432567.17956.11322312258310497482@ietfa.amsl.com> <7e8fd49f-a777-fd9e-d410-be7e8d5958cc@gmail.com> <3F17FC48-D8CB-46A4-A8B3-0BC7F65E6D26@employees.org>   <02d801d35bf9$b9f96530$2dec2f90$@innoroute.de>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <1e83275e-1756-19e9-af43-2aafa08db0cc@gmail.com>
Date: Mon, 13 Nov 2017 13:15:22 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <02d801d35bf9$b9f96530$2dec2f90$@innoroute.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 00:15:27 -0000

On 13/11/2017 10:03, foglar@innoroute.de wrote:
> Dears Mark, Brian, Ole, Mikael and Bob,
>=20
> Thank you for your valuable comments to our draft.=20
>=20
> First of all, I am sorry that the sentence =E2=80=9COne of the goals of=
 IPv6 was to have a sufficiently long address to allow grouping in fields=
 to simplify routing decisions.=E2=80=9D did cause so much irritation.
> The background was: in the mid-nineties I have read a document called =E2=
=80=9CThe case for IPv6=E2=80=9D, where one of its goals was that the str=
ucture of the IPv6 address should simplify routing. I remember this requi=
rement well, because at that time I was working for a chip manufacturer a=
nd we considered making a dedicated IPv6 routing chip. Unfortunately, I c=
ould not find this document for the original citation.

That was a white paper from the ex-vendor Bay Networks that was
transformed into the controversial draft-ietf-iab-case-for-ipv6, which
was never published as an RFC and which even the IETF data tracker
has forgotten. I have a copy of draft-ietf-iab-case-for-ipv6-06
(December 1999).

It does indeed contain the following claim:
" An independent
  IPv6 architecture presents the opportunity to build a fresh,
  hierarchical network address plan that will facilitate connection to
  one or more ISPs.  This simplifies renumbering, route aggregation
  (summarization), and other goals of a routing hierarchy."

I suspect that is one of the main reasons the document was scrapped,
since that isn't how IP routing works in the real world.

Regards
   Brian

> Answer: I will remove the first two of the chapter sentences and add th=
is simple one:
> "The following proposal uses the 64-bit IPv6 address prefix."=20
>=20
> Next, I thank Ole Troan for citing Y. Rekhter: =E2=80=9CAddressing can =
follow topology or topology can follow addressing; choose one=E2=80=9D.
> Answer: in this case addressing and topology already match perfectly. I=
n short: where more people are living there are more telephone numbers as=
signed. In case there are not enough addresses there are spare ones: curr=
ently only the digits 0=E2=80=A69 are used; by extending to A=E2=80=A6F t=
he address space can be almost doubled.=20
>=20
> Finally, there was a comment the proposal means replacing a great deal =
of existing software and hardware.=20
> Answer: hardware effort is low, as not all hierarchies must be populate=
d by forwarding nodes. Also, existing infrastructure such as transmission=
 links can be reused. Both are outlined in an example at the end of the d=
raft.=20
>=20
> A corrected draft is uploaded.
>=20
> With best regards,
> Andreas Foglar
> InnoRoute CEO
> Phone +49-89-4524199-01
> Mail foglar@innoroute.de =20
> www.innoroute.com =20
> Marsstr. 14a, D80335 Munich, Germany
>=20
>=20
>=20
>=20
>=20
> -----Urspr=C3=BCngliche Nachricht-----
> Von: Mark Smith [mailto:markzzzsmith@gmail.com]=20
> Gesendet: Samstag, 16. September 2017 03:07
> An: Brian E Carpenter 
> Cc: Ole Troan ; draft-foglar-ipv6-ull-routing@iet=
f.org; 6man WG 
> Betreff: Re: I-D Action: draft-foglar-ipv6-ull-routing-00.txt
>=20
> On 16 September 2017 at 09:31, Brian E Carpenter  > wrote:
>> On 15/09/2017 20:10, Ole Troan wrote:
>>>> Re https://tools.ietf.org/html/draft-foglar-ipv6-ull-routing-00
>>>>
>>>> "One of the goals of IPv6 was to have a sufficiently long address to=
=20
>>>> allow grouping in fields to simplify routing decisions."
>>>>
>>>> What makes you believe that? I don't recall such a goal in the IPng =

>>>> process, and I can't see any trace of it in RFC1752 or RFC1726.
>>>
>>>
>>> =E2=80=9CAddressing can follow topology or topology can follow addres=
sing;=20
>>> choose one=E2=80=9D - Y Rekhter
>>>
>>> Goal or no goal, we know of no other way to make the routing system s=
cale.
>>
>> Sure. I agree with that and with the RIPE policy that Mikael cited.=20
>> Believe me, everybody in the IPng discussion was acutely aware of the =

>> tension between PA and PI addressing and the benefits of aggregation=20
>> when possible. But that is very different from the quoted "goal",=20
>> which simply wasn't there. Allowing topological aggregation was a=20
>> goal, of course, but that's always been a matter of prefix assignment =
policy, not of the protocol design.
>>
>> Please note that I did not say that their idea will not work. It's the=
=20
>> "alternative fact" that I'm concerned about.
>=20
>>From what I've read in Christian Huitema's IPv6 book, at one stage
> there was a thought of swapping the source and destination address fiel=
ds so that the DA field was first, to facilitate this sort of cut-through=
 forwarding. From memory, the explanation was that it was decided against=
 was because fields other than the just the DA address have to be process=
ed during layer 3 forwarding.
>=20
> Regards,
> Mark.
>=20
>=20
>=20
>>
>>     Brian
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org =20
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>=20


From nobody Sun Nov 12 16:27:26 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 544001241F5 for ; Sun, 12 Nov 2017 16:27:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xgMrLMoIAcs for ; Sun, 12 Nov 2017 16:27:22 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D37C126CB6 for <6man@ietf.org>; Sun, 12 Nov 2017 16:27:22 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 8D8292D5119 for <6man@ietf.org>; Mon, 13 Nov 2017 00:27:21 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id A75DF200BDA653 for <6man@ietf.org>; Mon, 13 Nov 2017 08:26:51 +0800 (+08)
From: Ole Troan 
Content-Type: multipart/signed; boundary="Apple-Mail=_3AFF305B-095A-4246-BF85-F3628CCF2A1B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Fwd: [v6ops] New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt
Message-Id: <19F24928-32F1-411C-A855-08DFF342EFAC@employees.org>
References: 
To: 6man@ietf.org
Date: Mon, 13 Nov 2017 08:26:49 +0800
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 00:27:24 -0000

--Apple-Mail=_3AFF305B-095A-4246-BF85-F3628CCF2A1B
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_96E5878E-2F0A-467C-8785-CD8462898377"


--Apple-Mail=_96E5878E-2F0A-467C-8785-CD8462898377
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

This seems to be within our field of interest...

Best regards,
Ole

> Begin forwarded message:
>=20
> From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" =

> Subject: [v6ops] FW: New Version Notification for =
draft-fioccola-spring-flow-label-alt-mark-01.txt
> Date: 6 November 2017 at 23:59:58 GMT+8
> To: "v6ops@ietf.org" 
>=20
> If any feedback or comments (preferably constructive), then please =
have the discussion including SPRING WG in cc
>=20
> G/
>=20
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Thursday, October 26, 2017 16:35
> To: Giuseppe Fioccola ; Van De =
Velde, Gunter (Nokia - BE/Antwerp) ; =
Muley, Praveen (Nokia - US/Mountain View) ; =
Mauro Cociglio 
> Subject: New Version Notification for =
draft-fioccola-spring-flow-label-alt-mark-01.txt
>=20
>=20
> A new version of I-D, draft-fioccola-spring-flow-label-alt-mark-01.txt
> has been successfully submitted by Giuseppe Fioccola and posted to the =
IETF repository.
>=20
> Name:		draft-fioccola-spring-flow-label-alt-mark
> Revision:	01
> Title:		Using the IPv6 Flow Label for Performance =
Measurement with Alternate Marking Method in Segment Routing
> Document date:	2017-10-26
> Group:		Individual Submission
> Pages:		8
> URL:            =
https://www.ietf.org/internet-drafts/draft-fioccola-spring-flow-label-alt-=
mark-01.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-fioccola-spring-flow-label-alt-mark=
/
> Htmlized:       =
https://tools.ietf.org/html/draft-fioccola-spring-flow-label-alt-mark-01
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-fioccola-spring-flow-label-alt=
-mark-01
> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-fioccola-spring-flow-label-alt-m=
ark-01
>=20
> Abstract:
>   [RFC6294] makes a survey of Proposed Use Cases for the IPv6 Flow
>   Label.  The IPv6 protocol includes a flow label in every packet
>   header, but this field is, according to [RFC6294], not used in
>   practice.  This document describes how the alternate marking method
>   can be used as the passive performance measurement method in a IPv6
>   domain.
>=20
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission until the htmlized version and diff are available at =
tools.ietf.org.
>=20
> The IETF Secretariat
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail=_96E5878E-2F0A-467C-8785-CD8462898377
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

This =
seems to be within our field of interest...

Best regards,
Ole

Begin forwarded message:

From: =
"Van De Velde, Gunter (Nokia - =
BE/Antwerp)" <gunter.van_de_velde@nokia.com>
Subject: =
[v6ops] FW: New =
Version Notification for =
draft-fioccola-spring-flow-label-alt-mark-01.txt
Date: =
6 November 2017 at 23:59:58 =
GMT+8
To: =
"v6ops@ietf.org" <v6ops@ietf.org>

If =
any feedback or comments (preferably constructive), then please have the =
discussion including SPRING WG in cc

G/

-----Original Message-----
From: =
internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: =
Thursday, October 26, 2017 16:35
To: Giuseppe Fioccola =
<giuseppe.fioccola@telecomitalia.it>; Van De Velde, =
Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>; Muley, Praveen (Nokia =
- US/Mountain View) <praveen.muley@nokia.com>; Mauro Cociglio <mauro.cociglio@telecomitalia.it>
Subject: =
New Version Notification for =
draft-fioccola-spring-flow-label-alt-mark-01.txt


A new version of I-D, =
draft-fioccola-spring-flow-label-alt-mark-01.txt
has been =
successfully submitted by Giuseppe Fioccola and posted to the IETF =
repository.

Name:		=
draft-fioccola-spring-flow-label-alt-mark
Revision:	01
Title:		Using the =
IPv6 Flow Label for Performance Measurement with Alternate Marking =
Method in Segment Routing
Document date:	=
2017-10-26
Group:		Individual Submission
Pages:=
		=
8
URL: =
           https://www.ietf.org/internet-drafts/draft-fioccola-spring-flow=
-label-alt-mark-01.txt
Status: =
        https://datatracker.ietf.org/doc/draft-fioccola-spring-flow-lab=
el-alt-mark/
Htmlized: =
      https://tools.ietf.org/html/draft-fioccola-spring-flow-label-al=
t-mark-01
Htmlized: =
      https://datatracker.ietf.org/doc/html/draft-fioccola-spring-flo=
w-label-alt-mark-01
Diff: =
          https://www.ietf.org/rfcdiff?url2=3Ddraft-fioccola-spring-flow-=
label-alt-mark-01

Abstract:
   [RFC6294] makes a survey of Proposed Use Cases =
for the IPv6 Flow
   Label.  The IPv6 =
protocol includes a flow label in every packet
 =
  header, but this field is, according to [RFC6294], not used =
in
   practice.  This document describes =
how the alternate marking method
   can be used =
as the passive performance measurement method in a IPv6
 =
  domain.





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

The IETF =
Secretariat

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

=

--Apple-Mail=_96E5878E-2F0A-467C-8785-CD8462898377--

--Apple-Mail=_3AFF305B-095A-4246-BF85-F3628CCF2A1B
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+/bDNdvtpYqJhC33YFAloI5skACgkQvtpYqJhC
33aZqRAAlqApJ7fqIpzfbcky0lQpsNmGW4uJR1avrvQ22Am/TFiagzHyYoyHBz8G
mJRml3H3wyAUs8BZqiYEbJ1J7k813mgYTQe0JmAGhcnCVW9KypEJ0HHsYdpmJ3PA
Io2QjWvuuKGGrZz97tKMX6gDGFcuQPeqM+BXWm5SwxR/7grbDXm/GZM2d7Ax2mz9
w29q0jOtvM/l1Rt2suTMQ7bCv+gf0cp9uZ5iaSERz2nqNyewf4WUHYkyA8MQVTYF
7snbjEAXqA8MB2kHYLP3oYz5Tr17kqLi9lN7p3n0Y8Ur4wdTpS3pMnI5dLd2idUf
TYuZ8vTgmK8s67Fe7IZOdxPRgVhgxDpFGe79DNvUIdisQPY7oUoFMuNc8jQtPapm
5lawzJmMUCWz3EX95xulxzvU6riDk6Pdl5I+f/B+0KH45J1SLjqCm039ATzaA+dz
+Np8oA92Xq+pnxyKKt1bbT0v4cOzjOFQIApGGNy0rmPd5Xs8gC+0Wfqm3gV0Vnap
obxcsb0foj2zwWj/cigEkiETdRhOBJ1Z1C3YmDB/WfVbyWii39gL+z8OQfasOUf1
a1mqZ1sSBg/VD797v/ccccZqDEmpiIOMcTOB9dwYvsX630K6PG5PEe99TPipBq8E
3paOmiB7PQjAM23IrOZrG6UXkxlpjyvhIW3HWDj92jcCLWF6uGA=
=XK2+
-----END PGP SIGNATURE-----

--Apple-Mail=_3AFF305B-095A-4246-BF85-F3628CCF2A1B--


From nobody Sun Nov 12 18:08:09 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C486912785F; Sun, 12 Nov 2017 18:08:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wwzq_MxPsZt; Sun, 12 Nov 2017 18:07:59 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A1C126CB6; Sun, 12 Nov 2017 18:07:56 -0800 (PST)
Received: from [31.133.137.43] (dhcp-892b.meeting.ietf.org [31.133.137.43]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vAD27cHn005676 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 12 Nov 2017 18:07:40 -0800
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: DY Kim , Fernando Gont 
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , Ted Lemon , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com> <7532e311-be94-1b9e-b9f1-8b12e9d6ee79@si6networks.com>  <203d7ede-2169-4a04-e545-2eb48144eac3@si6networks.com> <0045136C-91FA-4B31-91E0-D2D44E7433AB@gmail.com>
From: Erik Nordmark 
Message-ID: <17184d11-ece0-38c4-3d94-af2972deb7cd@acm.org>
Date: Mon, 13 Nov 2017 10:07:37 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <0045136C-91FA-4B31-91E0-D2D44E7433AB@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Sonic-CAuth: UmFuZG9tSVbzTx8m5OB22l3criAqsrHSwLIAU179eze9HPlHellPqITck2lZxYTU4oinLVKJ7h+3F13JM7V6oIPVykQrSKUN
X-Sonic-ID: C;6GlpbBfI5xGlQIlQ3iMJ6w== M;BHVabRfI5xGlQIlQ3iMJ6w==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:08:03 -0000

On 11/11/2017 11:54 AM, DY Kim wrote:
> The ‘state’ in the wording SLAAC means that of the host, I mean.

DY,

The history of why SLAAC has "stateless" in its name in its name doesn't 
match your statement.
When SLAAC was created there was BOOTP/DHCP for IPv4, but not work had 
started on what would later become DHCPv6, but such work was 
anticipated. The use of "stateless" was to distinguish SLAAC from the 
case where there is a network service (akin to DHCP) which retains state 
about the allocations made for hosts. At that time the use of DHCPv4 for 
IPv4 address allocation was quite new and not very robust and there was 
concerns about IPv6 having a hard dependency on such a service.

Also, further back in time, at the Big10 meeting of the IPng directorate 
was the first time I heard the 128 bit address format be discussed with 
the idea than an IPv6 address could be formed using (a) prefix(es) 
advertised by the router and a 48 byte mac address of the host following 
an approach which had been used in other protocols (IPX I believe).

The fact that as IPv6 then evolved that evolved from 48 byte MAC to 64 
bit IID and the IID's later became more friendly to privacy 
considerations doesn't change the fact that we have never added a 
requirement that routers speaking SLAAC maintain per-host allocation 
information; they do maintain per-link configuration information.


Whether the split in to stateless and stateful (aka DHCPv6) address 
allocation was a wise choice is something I leave as an exercise to the 
reader. I merely offer the observation that we keep on muddling any 
boundaries between stateless and stateful address allocation and also 
between address allocation and host configuration.
The resulting larger number of possible implementation and configuration 
choices on the host and network/router side doesn't seem helpful in 
facilitating interoperable protocols.

Regards,
    Erik


> 
> SLAAC don’t need to require the router to do anything special, other than the router’s usual prefix advertisement through an RA.
> 
> The same is true of the case wherein DHCP is used to assign addresses to hosts by the router.
> 
> How the router keeps the link prefix info in its system is an interest neither to DHCP or SLAAC, since the link prefix itself is not about address assignment in which DHCP and SLAAC are interested.
> 
> How the router keeps the link prefix(es), whether shared or unique to each hosts, is an issue of the router system implementation, not of the protocols DHCP or SLAAC.
> 
> Hence, the question about how the prefix(es) are stored or recovered should be addressed to the router spec, neither to DHCP, nor to SLAAC, nor to this draft, I’d think.
> 
> ---
> DY
> 
>> On 11 Nov 2017, at 12:16, Fernando Gont  wrote:
>>
>> On 11/11/2017 12:13 AM, DY Kim wrote:
>>> The host’s state.
>>>
>>> RFC 4862:
>>>
>>>   "This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6 (IPv6).â€
>>>
>>>   "The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers."
>>
>> Host state, maintained at the router?
>>
>>
>> -- 
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Sun Nov 12 18:14:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F4E12785F for ; Sun, 12 Nov 2017 18:14:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3XDxUr8pY76c for ; Sun, 12 Nov 2017 18:14:36 -0800 (PST)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EA3126DFF for <6man@ietf.org>; Sun, 12 Nov 2017 18:14:35 -0800 (PST)
Received: by mail-it0-x22a.google.com with SMTP id u132so7623396ita.0 for <6man@ietf.org>; Sun, 12 Nov 2017 18:14:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kV+IndwTvKWkoKeoPfXo6i+2NF71fr9Mrz4+l/qBWH8=; b=nekUES3Xm8VsIEpaOQENihXL6vL7UDcKHsnavA7onTVrUaBjbIzpB5n7aInWan+6ih U8HKxBRPT4yhveMDLiuwZ3QJhB+WOoLDeUxqo6b/A759rkLBS9IUVXTSZTb2KKuzbwVn H1yxvxuJgJPEG0MqMen0enRWfFCdHPGbVTTXiSQPayLchk3IBx9419nZ66FrIg6co7Mq EQabxsoKluC/OK7kL5loZWi7s8Z548plY5h2+n9kwgqHwP4PCONtmENuJu4uNt5f1p8P ZP2+n3UKSyYEwWG/CdEwJIuuuZ0cLhCBI0gugoDOe3PKAAvw6NSrjPxSDvkAUjOlsTI+ 7fZQ==
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=kV+IndwTvKWkoKeoPfXo6i+2NF71fr9Mrz4+l/qBWH8=; b=TBeJBQ3bvbKCnaJBYkvZFwVQ2G8VDx9GLi0HEUtqyuvMh0KKDdQyuEN0DnoP9w9Qpd /E6CgxvFtE8oZXZke7qqzO/3txWb0tc/2utTCHAE5XV8ao/3n/ieRWnBb0MGqKfgUEh2 bYTUqIV3s4UWkWgj0SdftXG7QHQFVykveQzZAPGr+IaqvhxvwvQbw24sTM6id51XJu6E pWAFRuKvBZ+xqR4lrDDOL06NRuaughHwkgjEZ8p6Mb5mPWQ7udP4jlV4vNMb3eK13cO9 bAgKW2m+BoNKQ46b28arFC3UQw5jgstjnXjmYjbPgWUWnz4UMfRyuYTcg5PX2wOMbq4F 0Ndg==
X-Gm-Message-State: AJaThX6gPUvm6rT0kzdSp1jC7XAtqxRsZ1J0POHCPPVsoDdMP2NOweEs YgDpqUSyaxYBLI2Dzm76mBZ4flTJT99DtCrn5yJByw==
X-Google-Smtp-Source: AGs4zMYzO+s+YJDOPpQsEuSBH6lVnIBDAR6WvcTB3mAP8hR/tCPfnwerPpcljuspKdcE/hoyY9R/AjlbjDx1ODzWZ50=
X-Received: by 10.36.252.68 with SMTP id b65mr9016097ith.151.1510539274865; Sun, 12 Nov 2017 18:14:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Sun, 12 Nov 2017 18:14:13 -0800 (PST)
In-Reply-To: <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>
From: Lorenzo Colitti 
Date: Mon, 13 Nov 2017 11:14:13 +0900
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Joe Touch 
Cc: Brian E Carpenter , Ole Troan ,  Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0b2858e64998055dd3d4af"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:14:41 -0000

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

On Sat, Nov 11, 2017 at 9:41 AM, Joe Touch  wrote:

> FWIW, I would agree with that if this were an issue of WG focus creep.
> AFAICT, the issue appears to go much deeper, which means it's an Area
> boundary issue if it is indeed a protocol extension.
>
> IMO, OPS stays in the lane of suggesting sets of *existing* protocol
> parameters and features, or indicates where MAYs and SHOULDs can be
> relaxed (or not) - all of this remains compliant with the protocol.
> Changes to the protocol should not be considered operational decisions,
> again IMO.
>

Excuse me, but I really cannot fathom why we are saying that this draft
defines a new protocol when it is an explicit goal for all existing
implementations to continue to work. How can this be a new protocol when
all implementations implement this already?

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


On S=
at, Nov 11, 2017 at 9:41 AM, Joe Touch <touch@strayalpha.com> wrote:
FWIW, I would agree with that=
 if this were an issue of WG focus creep.=C2=A0

AFAICT, the issue appears to go much deeper, which means it's an Area
boundary issue if it is indeed a protocol extension.



IMO, OPS stays in the lane of suggesting sets of *existing* protocol

parameters and features, or indicates where MAYs and SHOULDs can be

relaxed (or not) - all of this remains compliant with the protocol.

Changes to the protocol should not be considered operational decisions,

again IMO.

Excuse me, but I really cann=
ot fathom why we are saying that this draft defines a new protocol when it =
is an explicit goal for all existing implementations to continue to work. H=
ow can this be a new protocol when all implementations implement this alrea=
dy?


--94eb2c0b2858e64998055dd3d4af--


From nobody Sun Nov 12 18:16:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE03127775 for ; Sun, 12 Nov 2017 18:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 zOsAo2rv_vc9 for ; Sun, 12 Nov 2017 18:16:10 -0800 (PST)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE9A127517 for <6man@ietf.org>; Sun, 12 Nov 2017 18:16:10 -0800 (PST)
Received: by mail-it0-x22f.google.com with SMTP id b5so1306402itc.3 for <6man@ietf.org>; Sun, 12 Nov 2017 18:16:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5OJjPzq3zQsVPMgpd4AIUm9w6IdP1x+a1Q6zSfADavc=; b=Ytvpe/aClmrHNTgkWT0MVjaLvsQ9VfuMi7S609MNyZD9GQbsJhDuGPEGscW7MKpJYd u1ho67XMKqMDhknJo4adSIi2sxVZwXBwT74mDUO/W6mjmYO6PaWUBxSNINe16fgRDja4 WIGZSM8x+6PtNaKk5kFOqAXImQLYEPYTn7XiXs1n5JL5VxaMjYOtiG2Uof3jjpM6kPtA WQ0JD+pv2n8lv/gBTyIRFvg6qKYCi+ZblDRLJQcRjgO7cwx9PZSieCvLYTet5FhyDeZM 0GsAq57R5ijLaUts8hjmaqfwmjIWFSAfarHWHE7k4T8Vax7OEDgGN+7LsM0IEd99PBUv Tfxw==
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=5OJjPzq3zQsVPMgpd4AIUm9w6IdP1x+a1Q6zSfADavc=; b=oA2unzO9SrrA1walDhCwvTXA9fKrL1nKsL0hYT/ye4wMPwo0Z4rB4hJSqyeuvG1BWU eJ9kZgAdNED62rmzoAFKEJNTGsAYgw7XuWzm9RSIw/M8ExVSOOGBzUv3Q4+T0p4+Ugyw 8e+JBjrbgqYFpPnGgw99+z+sRs8b/Ck01BDvpFAU/Sh/vbneMxmnbRpsU+HLp+J21glu MD4SNLN314XYUFd492y8n25y308UOoX8YMU7BH47W5zJ6fltdKC4KVEJAboGAfyrzC10 PvGZhAlUTMDtFGBq+GPSCn+qm05Sq/A9e3Xy3zAhbLxzrrG6hEnUwz4ptQTw/84BeR/6 P+BA==
X-Gm-Message-State: AJaThX4zrKaOMEMFzytKFQRPdzkDBJ7AX+C/zG9dGPfX21B2M6xnzOHP tdbHgXK1xFnfBLXZG0Lcm0g0ohgzU6UA3EamW3DFZA==
X-Google-Smtp-Source: AGs4zMa35pRklhZqbHmY1ZLSLu1jSifMTtHrrW8ElUU2NRT0+cQ8fqGHRQE9nlEgOMQSjPXAdWF/Y+mpw7KX5DZXLXQ=
X-Received: by 10.36.26.206 with SMTP id 197mr8744132iti.88.1510539369722; Sun, 12 Nov 2017 18:16:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Sun, 12 Nov 2017 18:15:48 -0800 (PST)
In-Reply-To: <5A084504.7080003@foobar.org>
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <52C752BD-2347-4704-9103-89BD979D7C2D@google.com> <5fc6a1b1-7707-b5ab-7820-98f9f07b794c@strayalpha.com>  <5A084504.7080003@foobar.org>
From: Lorenzo Colitti 
Date: Mon, 13 Nov 2017 11:15:48 +0900
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Nick Hilliard 
Cc: Fernando Gont , james woodyatt ,  IPv6 Operations , Joe Touch ,  "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" ,  draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org,  "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="001a114457ec8e1b5e055dd3da4c"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:16:12 -0000

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

On Sun, Nov 12, 2017 at 9:56 PM, Nick Hilliard  wrote:

> > Now, consider the FSM of router side of SLAAC, and compare it with the
> > FSM of the mechanism being proposed. The difference should be evident.
>
> The ID also omits any discussion about how this state is managed in the
> context of source address validation by edge devices.
>
> This would be important from an operational point of view, as it
> introduces a substantial degree of state management into the network
> infrastructure, not just the next-hop router.
>

Sure, but I don't think that issue is in scope for this document. DHCPv6 PD
has exactly the same issue, and AFAIK the solution(s) to that issue are not
documented in any RFC.

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


On S=
un, Nov 12, 2017 at 9:56 PM, Nick Hilliard <nick@foobar.org> w=
rote:
> Now, consider=
 the FSM of router side of SLAAC, and compare it with the

> FSM of the mechanism being proposed. The difference should be evident.=




The ID also omits any discussion about how this state is managed in =
the

context of source address validation by edge devices.



This would be important from an operational point of view, as it

introduces a substantial degree of state management into the network

infrastructure, not just the next-hop router.

Sure, but I don't think that issue is in scope for this document=
. DHCPv6 PD has exactly the same issue, and AFAIK the solution(s) to that i=
ssue are not documented in any RFC.


--001a114457ec8e1b5e055dd3da4c--


From nobody Sun Nov 12 18:17:35 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9DE1286B2 for ; Sun, 12 Nov 2017 18:17:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 sjeVrIDKmwym for ; Sun, 12 Nov 2017 18:17:20 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34B91252BA for <6man@ietf.org>; Sun, 12 Nov 2017 18:17:18 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id n89so10792317pfk.11 for <6man@ietf.org>; Sun, 12 Nov 2017 18:17:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5JwFZpAgt6PTbqI1BH5en4hgZsYa1JIQtmpHJF+vee0=; b=FnIEkhv7TPY/fV9gtmGLvOLNeDGIsYQnw271jSQTGjeC5MjhnEuFgQ3NrikuIMdOBs c3mN9aejNGp/nbP2LMbFmxU7yfma5wH1n79YJD4hFrsumSsedI+F1YzPRWxJtL5Pk5vN 7NkpVLhSBn9U7jxtq6KjABCjbAKFg37x+My1bzwIoH0ZUCgz2hWUJ7HbrIy9GwiiOm6s XPi6RQ5zhrZsVHAxsYkhuUAf72rUoxEYjomOyJzHDyl/cihhmmDz2YfP5fwx8oaBxogC 0v/VxTJvmmSljCaFDmSr59W6YjDIwQScNRcwMTJs535BLBrK+I23omNhDn4Yb4ciBtTu 406g==
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=5JwFZpAgt6PTbqI1BH5en4hgZsYa1JIQtmpHJF+vee0=; b=NLD6k3MwdFYX3eYDwbVyiyWIxCfi6nWn1jLLrW6miTspmL6iHtgdoSBISCT46SnQCt OziJnlTPUgosYHIuNq9zy3pT9dGeIMfRjeAhneVSchpu80fpq0XXGRiy2JaIxX/uAHsT qfB3mFHCWzeBaJnkANraPuOuUlQg9xEyduEFlRMToUbNpLbzP0owYoAvM27Jk5pj7WOc XeG7659qILI6HI/PQ/xCfItZFvMKYaH/UguDEbVuzkTNAqV7H2uvP+aVBnpyZ5Fg8ptV grNmxOoJXj+DH9Mdl01E1q3SqxuGjzjRE5Tu2TVzuZEXZpKaP2iaEYj1Jp/pDoVbg2OQ kFLg==
X-Gm-Message-State: AJaThX49W0cMgLWfuMSsZQhsygUpptQwfGX9DgJ9Xuz8tEteq+jKI6CJ xjeg+9BMS89/rBzTB9viDEHJiQ==
X-Google-Smtp-Source: AGs4zMbCuubuu1QIIR8zX+qV3ELfRgkevMe10A6z1M4BkkTc2lf64/f4SRLC3SnXxqhr+sW+3a7Nsg==
X-Received: by 10.99.100.67 with SMTP id y64mr7191934pgb.19.1510539438471; Sun, 12 Nov 2017 18:17:18 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:344f:2622:bc20:2ef? ([2001:67c:370:1998:344f:2622:bc20:2ef]) by smtp.gmail.com with ESMTPSA id o123sm21039098pfb.102.2017.11.12.18.17.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 18:17:17 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_68C707D4-E0EB-4554-BF9F-263B078A189F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 10:17:15 +0800
In-Reply-To: 
Cc: Joe Touch , Fernando Gont , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
To: Lorenzo Colitti 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:17:23 -0000

--Apple-Mail=_68C707D4-E0EB-4554-BF9F-263B078A189F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 13, 2017, at 10:14 AM, Lorenzo Colitti  =
wrote:
> Excuse me, but I really cannot fathom why we are saying that this =
draft defines a new protocol when it is an explicit goal for all =
existing implementations to continue to work. How can this be a new =
protocol when all implementations implement this already?

All host implementations have to work.   In order for them to work, new =
router behavior has to be specified.   That sounds like a protocol spec =
to me.  My question would be, why is this a problem?   I think that the =
document could be clearer about required behavior, but it already =
basically says what needs to happen.   Discussing this with Suresh on =
Saturday morning convinced me that more clarity would be useful, but =
that seems like a pretty easy problem to solve.



--Apple-Mail=_68C707D4-E0EB-4554-BF9F-263B078A189F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 13, 2017, at 10:14 AM, Lorenzo Colitti <lorenzo@google.com> =
wrote:
Excuse =
me, but I really cannot fathom why we are saying that this draft defines =
a new protocol when it is an explicit goal for all existing =
implementations to continue to work. How can this be a new protocol when =
all implementations implement this =
already?

All host implementations have to work.   In =
order for them to work, new router behavior has to be specified.   =
That sounds like a protocol spec to me.  My question would be, why =
is this a problem?   I think that the document could be clearer =
about required behavior, but it already basically says what needs to =
happen.   Discussing this with Suresh on Saturday morning convinced =
me that more clarity would be useful, but that seems like a pretty easy =
problem to solve.


=

--Apple-Mail=_68C707D4-E0EB-4554-BF9F-263B078A189F--


From nobody Sun Nov 12 18:17:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354EF128990; Sun, 12 Nov 2017 18:17:43 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 4U_M18aW2mzu; Sun, 12 Nov 2017 18:17:41 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0092.outbound.protection.outlook.com [104.47.1.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 ED741127517; Sun, 12 Nov 2017 18:17:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M9kCKdYd8eL7kk/0w8yCr2DDLQYrbIAzGrly1vPqYoo=; b=CHihmOyv+7shXL2QaC3CvJE01EirWR5Y1MjyUwTBCMYK3mIKHzIQ7Vn+Ib7yL/LFpHo/Wl76cbSNcEACMm+kMOop+P4r0RgJWL1eAZ/bi7cKxTi1W3Do26kF6zz4e32qidoPaU/vnEVLJL8ccGGJ+rs4lNUqffQOO1xj9w2H+1E=
Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB2833.eurprd07.prod.outlook.com (10.168.155.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 02:17:34 +0000
Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::7007:b8e:3320:94c1]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::7007:b8e:3320:94c1%14]) with mapi id 15.20.0239.004; Mon, 13 Nov 2017 02:17:33 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: Lorenzo Colitti , Joe Touch 
CC: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
Subject: RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Topic: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Index: AQHTV0Ps944vy/6Q4EOhEJVwr1mwgaMLXqEAgAD43YCAAB+YAIAAc32AgAEvwICAAB0aAIAAJZ+AgAM+noCAAACnYA==
Date: Mon, 13 Nov 2017 02:17:33 +0000
Message-ID: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:67c:370:128:69f5:b177:9682:2059]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2833; 6:RDPNvw2ekpwpO+KvI5/CQm6FUEjrtpCE0VjeajJTNBK3kMb22Bsga9qJMP8QOQwRB0TgZDPyPdfS2IcmfSbI7x9VQi5VbViDEfUiys1HZEoJi6AVLdqvdBaBdUm1/vgbn62iWrCsBuApP4JYJFy/ds1ybL8oln27/5eHbFDxGjOfPX1xC7Jy/+DlXSQ7OiRTLS2MqKU20Ieu1oxPVIc9U9KIzfCm8hUGna5EhI3iFiyp18lljMaAIDuTzsrWIQkJkgS2F0ZcLntCATtNbqOfiRKRVtGNY0FS5+E4wpW7UwjddJCnmOq2z2jKOZSBtyPkKp7Qbv3OQBbtaw7RBvFTyumdlmyNRfSmzkdjWIcQsrA=; 5:hB2WeQ14lkU2DYL9tWKAccQNJ3bPKYE1+kJ3F7arzULqoWKUsSKoqHDZJcIOPRaNM9VK7sTTLtW5LEa1a/IukjNAuPsG9V68TkUlZn9eoBekB2+wUj/e1lu8svwWvxFPZ8nKv9nM+aA4POp/kHezvE/oOoYrWdwI0JktS6kkRM0=; 24:XhvxXqqZCLAaSenyYhfcjfkdu32UNOWHEGNiJ6WkTEAA8/OonPNeQWqDrt0hJF/iuLVOJSCcv9KtsmGSQuOzZzNf9EztVkNlpSHqLdzzPdU=; 7:BZW1+Iln//bbJ4RAnyp6xY2ypqDJwyDUmeuEidyYnq6xcqqqcKFGWJTKseOyBeh3WdhQVr6/VhNNNsbzQdzLUUXp+O6lmE4U6zB5BIb5CChyrcoOPDBBTQg9BzMNkfSxXD2PeWQxvs32MEIuAipmxuzT2j0jDeEsWxw+xns4uURYDBwt4x56twckP/IG3MnEM63p/hm5+8N8e7688pvsd2Kr2jiZAgcbrsn0Cyd12C7BCCLUHY9v1Jdr6hlTfZ9B
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 49b26bee-72ba-4a25-dab6-08d52a3cb373
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:AM5PR0701MB2833; 
x-ms-traffictypediagnostic: AM5PR0701MB2833:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2833; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2833; 
x-forefront-prvs: 0490BBA1F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(189002)(199003)(24454002)(110136005)(229853002)(6246003)(93886005)(230783001)(86362001)(19609705001)(68736007)(478600001)(5250100002)(7736002)(6506006)(54906003)(8936002)(2900100001)(33656002)(25786009)(316002)(2950100002)(53936002)(99286004)(6436002)(189998001)(3280700002)(54356999)(8676002)(76176999)(74316002)(7696004)(236005)(14454004)(6306002)(55016002)(9686003)(97736004)(106356001)(81166006)(4326008)(2906002)(54896002)(53546010)(5660300001)(101416001)(105586002)(102836003)(6116002)(790700001)(3660700001)(50986999)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2833; H:AM5PR0701MB2836.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB283601F146B8AAED0FF0D39CE02B0AM5PR0701MB2836_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 49b26bee-72ba-4a25-dab6-08d52a3cb373
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 02:17:33.8818 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2833
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:17:43 -0000

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

KzEgd2l0aCBMb3JlbnpvLi4gYW5kIHRoaXMg4oCcaXPigJ0gd29ya2luZyBhbmQg4oCcZGVwbG95
ZWTigJ0gcmlnaHQgbm934oCmDQoNCg0KT24gU2F0LCBOb3YgMTEsIDIwMTcgYXQgOTo0MSBBTSwg
Sm9lIFRvdWNoIDx0b3VjaEBzdHJheWFscGhhLmNvbTxtYWlsdG86dG91Y2hAc3RyYXlhbHBoYS5j
b20+PiB3cm90ZToNCkZXSVcsIEkgd291bGQgYWdyZWUgd2l0aCB0aGF0IGlmIHRoaXMgd2VyZSBh
biBpc3N1ZSBvZiBXRyBmb2N1cyBjcmVlcC4NCkFGQUlDVCwgdGhlIGlzc3VlIGFwcGVhcnMgdG8g
Z28gbXVjaCBkZWVwZXIsIHdoaWNoIG1lYW5zIGl0J3MgYW4gQXJlYQ0KYm91bmRhcnkgaXNzdWUg
aWYgaXQgaXMgaW5kZWVkIGEgcHJvdG9jb2wgZXh0ZW5zaW9uLg0KDQpJTU8sIE9QUyBzdGF5cyBp
biB0aGUgbGFuZSBvZiBzdWdnZXN0aW5nIHNldHMgb2YgKmV4aXN0aW5nKiBwcm90b2NvbA0KcGFy
YW1ldGVycyBhbmQgZmVhdHVyZXMsIG9yIGluZGljYXRlcyB3aGVyZSBNQVlzIGFuZCBTSE9VTERz
IGNhbiBiZQ0KcmVsYXhlZCAob3Igbm90KSAtIGFsbCBvZiB0aGlzIHJlbWFpbnMgY29tcGxpYW50
IHdpdGggdGhlIHByb3RvY29sLg0KQ2hhbmdlcyB0byB0aGUgcHJvdG9jb2wgc2hvdWxkIG5vdCBi
ZSBjb25zaWRlcmVkIG9wZXJhdGlvbmFsIGRlY2lzaW9ucywNCmFnYWluIElNTy4NCg0KRXhjdXNl
IG1lLCBidXQgSSByZWFsbHkgY2Fubm90IGZhdGhvbSB3aHkgd2UgYXJlIHNheWluZyB0aGF0IHRo
aXMgZHJhZnQgZGVmaW5lcyBhIG5ldyBwcm90b2NvbCB3aGVuIGl0IGlzIGFuIGV4cGxpY2l0IGdv
YWwgZm9yIGFsbCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgdG8gY29udGludWUgdG8gd29yay4g
SG93IGNhbiB0aGlzIGJlIGEgbmV3IHByb3RvY29sIHdoZW4gYWxsIGltcGxlbWVudGF0aW9ucyBp
bXBsZW1lbnQgdGhpcyBhbHJlYWR5Pw0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m
IzQzOzEgd2l0aCBMb3JlbnpvLi4gYW5kIHRoaXMg4oCcaXPigJ0gd29ya2luZyBhbmQg4oCcZGVw
bG95ZWTigJ0gcmlnaHQgbm934oCmDQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBOb3Yg
MTEsIDIwMTcgYXQgOTo0MSBBTSwgSm9lIFRvdWNoICZsdDs8YSBocmVmPSJtYWlsdG86dG91Y2hA
c3RyYXlhbHBoYS5jb20iIHRhcmdldD0iX2JsYW5rIj50b3VjaEBzdHJheWFscGhhLmNvbTwvYT4m
Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw
dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkZXSVcsIEkgd291bGQgYWdyZWUgd2l0aCB0aGF0IGlmIHRoaXMgd2VyZSBhbiBpc3N1ZSBv
ZiBXRyBmb2N1cyBjcmVlcC4mbmJzcDs8YnI+DQpBRkFJQ1QsIHRoZSBpc3N1ZSBhcHBlYXJzIHRv
IGdvIG11Y2ggZGVlcGVyLCB3aGljaCBtZWFucyBpdCdzIGFuIEFyZWE8YnI+DQpib3VuZGFyeSBp
c3N1ZSBpZiBpdCBpcyBpbmRlZWQgYSBwcm90b2NvbCBleHRlbnNpb24uPGJyPg0KPGJyPg0KSU1P
LCBPUFMgc3RheXMgaW4gdGhlIGxhbmUgb2Ygc3VnZ2VzdGluZyBzZXRzIG9mICpleGlzdGluZyog
cHJvdG9jb2w8YnI+DQpwYXJhbWV0ZXJzIGFuZCBmZWF0dXJlcywgb3IgaW5kaWNhdGVzIHdoZXJl
IE1BWXMgYW5kIFNIT1VMRHMgY2FuIGJlPGJyPg0KcmVsYXhlZCAob3Igbm90KSAtIGFsbCBvZiB0
aGlzIHJlbWFpbnMgY29tcGxpYW50IHdpdGggdGhlIHByb3RvY29sLjxicj4NCkNoYW5nZXMgdG8g
dGhlIHByb3RvY29sIHNob3VsZCBub3QgYmUgY29uc2lkZXJlZCBvcGVyYXRpb25hbCBkZWNpc2lv
bnMsPGJyPg0KYWdhaW4gSU1PLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXhjdXNlIG1lLCBidXQgSSByZWFsbHkgY2Fubm90IGZh
dGhvbSB3aHkgd2UgYXJlIHNheWluZyB0aGF0IHRoaXMgZHJhZnQgZGVmaW5lcyBhIG5ldyBwcm90
b2NvbCB3aGVuIGl0IGlzIGFuIGV4cGxpY2l0IGdvYWwgZm9yIGFsbCBleGlzdGluZyBpbXBsZW1l
bnRhdGlvbnMgdG8gY29udGludWUgdG8gd29yay4gSG93IGNhbiB0aGlzIGJlIGEgbmV3IHByb3Rv
Y29sIHdoZW4gYWxsIGltcGxlbWVudGF0aW9ucyBpbXBsZW1lbnQNCiB0aGlzIGFscmVhZHk/PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_AM5PR0701MB283601F146B8AAED0FF0D39CE02B0AM5PR0701MB2836_--


From nobody Sun Nov 12 18:33:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E11127077; Sun, 12 Nov 2017 18:33:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 tfpFeYOxH0zv; Sun, 12 Nov 2017 18:33:28 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2D1126D85; Sun, 12 Nov 2017 18:33:28 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4] (unknown [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 656FF80C0D; Mon, 13 Nov 2017 03:33:24 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Lorenzo Colitti , Joe Touch 
Cc: Brian E Carpenter , Ole Troan , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> 
From: Fernando Gont 
Message-ID: <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>
Date: Mon, 13 Nov 2017 10:27:59 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:33:30 -0000

On 11/13/2017 10:14 AM, Lorenzo Colitti wrote:
> On Sat, Nov 11, 2017 at 9:41 AM, Joe Touch  > wrote:
> 
>     FWIW, I would agree with that if this were an issue of WG focus creep. 
>     AFAICT, the issue appears to go much deeper, which means it's an Area
>     boundary issue if it is indeed a protocol extension.
> 
>     IMO, OPS stays in the lane of suggesting sets of *existing* protocol
>     parameters and features, or indicates where MAYs and SHOULDs can be
>     relaxed (or not) - all of this remains compliant with the protocol.
>     Changes to the protocol should not be considered operational decisions,
>     again IMO.
> 
> 
> Excuse me, but I really cannot fathom why we are saying that this draft
> defines a new protocol 

Model SLAAC with a FSM for the client, and a FSM for the server. Now
apply this document. And look at the SLAAC router FSM.

Did it change (and quite a lot, actually)?  If yes, then you ahve
changed the protocol. If not, you didn't do the FSM properly.

Hope this helps.

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





From nobody Sun Nov 12 18:33:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3DA1273E2 for ; Sun, 12 Nov 2017 18:33:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ofS120NU-qkg for ; Sun, 12 Nov 2017 18:33:30 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C45C127136 for ; Sun, 12 Nov 2017 18:33:30 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4] (unknown [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 04E40819F8; Mon, 13 Nov 2017 03:33:27 +0100 (CET)
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Brian E Carpenter , ipv6@ietf.org
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com> <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk> <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com> <12447.1510153859@obiwan.sandelman.ca>   <45f01790-0561-68b9-e245-0a126c7e110b@si6networks.com> <9c39822b-584b-557c-635a-a1529f94cbd5@gmail.com>
From: Fernando Gont 
Message-ID: 
Date: Mon, 13 Nov 2017 10:34:52 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <9c39822b-584b-557c-635a-a1529f94cbd5@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:33:32 -0000

On 11/13/2017 07:55 AM, Brian E Carpenter wrote:
> On 12/11/2017 19:52, Fernando Gont wrote:
>> Hi, Bob,
>>
>> On 11/12/2017 10:50 AM, Bob Hinden wrote:
>>> I went back and looked at the RFC8200 text that deals with header insertion.  It does not actually mention IPIP.  The published text in Section 4. "IPv6 Extension Headers" regarding header insertion is:
>>>
>>>    Extension headers (except for the Hop-by-Hop Options header) are not
>>>    processed, inserted, or deleted by any node along a packet's delivery
>>>    path, until the packet reaches the node (or each of the set of nodes,
>>>    in the case of multicast) identified in the Destination Address field
>>>    of the IPv6 header.
>>>
>>>    The Hop-by-Hop Options header is not inserted or deleted, but may be
>>>    examined or processed by any node along a packet's delivery path,
>>>    until the packet reaches the node (or each of the set of nodes, in
>>>    the case of multicast) identified in the Destination Address field of
>>>    the IPv6 header.  The Hop-by-Hop Options header, when present, must
>>>    immediately follow the IPv6 header.  Its presence is indicated by the
>>>    value zero in the Next Header field of the IPv6 header.
>>>
>>> Some earlier drafts include IPIP as a way of inserting headers, but that wasn’t included in what became RFC8200.
>>
>> Does IPIP simply mean tunelling IP over IP?
>>
>> If so, that'd be tunneling, rather than "header insertion".
> 
> Yes, but the point was to say that this is a valid way to attach extra
> headers. And iirc we concluded that while true, it isn't necessary
> to write it down.
> 
> (Also there's a proposed standard for this if you need it: RFC2473.)

Agreed. If you create a new packet... "your packet, your headers"..

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





From nobody Sun Nov 12 18:44:09 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2BA128C84; Sun, 12 Nov 2017 18:43:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAZel7X3j8NQ; Sun, 12 Nov 2017 18:43:41 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBD121287A3; Sun, 12 Nov 2017 18:43:23 -0800 (PST)
Received: from h.hanazo.no (nat64-ad.meeting.ietf.org [31.130.238.173]) (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 E23192D4F99; Mon, 13 Nov 2017 02:43:22 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 28D7E200BE74BD; Mon, 13 Nov 2017 10:42:55 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_7B5AE5A5-DD9C-4E8B-B371-F90B7BD64889"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 10:42:54 +0800
In-Reply-To: <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>
Cc: Lorenzo Colitti , Joe Touch , Brian E Carpenter , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
To: Fernando Gont 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:43:43 -0000

--Apple-Mail=_7B5AE5A5-DD9C-4E8B-B371-F90B7BD64889
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Fernando,

>> > wrote:
>>=20
>>    FWIW, I would agree with that if this were an issue of WG focus =
creep.
>>    AFAICT, the issue appears to go much deeper, which means it's an =
Area
>>    boundary issue if it is indeed a protocol extension.
>>=20
>>    IMO, OPS stays in the lane of suggesting sets of *existing* =
protocol
>>    parameters and features, or indicates where MAYs and SHOULDs can =
be
>>    relaxed (or not) - all of this remains compliant with the =
protocol.
>>    Changes to the protocol should not be considered operational =
decisions,
>>    again IMO.
>>=20
>>=20
>> Excuse me, but I really cannot fathom why we are saying that this =
draft
>> defines a new protocol
>=20
> Model SLAAC with a FSM for the client, and a FSM for the server. Now
> apply this document. And look at the SLAAC router FSM.
>=20
> Did it change (and quite a lot, actually)?  If yes, then you ahve
> changed the protocol. If not, you didn't do the FSM properly.

Or do as I do in my implementation.
Model each host as being on it's own point to point interface.
Configure the IPv6 prefix on that interface. That configured state is =
exactly like what we have in classic SLAAC.

Ole



--Apple-Mail=_7B5AE5A5-DD9C-4E8B-B371-F90B7BD64889
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+/bDNdvtpYqJhC33YFAloJBq4ACgkQvtpYqJhC
33Z5NQ//dlkSiWioQqPI356m74uOtX67q/jcyqsR27ZskoJm1WPxg49ghcwRbDVz
7JP4MZKJV5mRfqCl/sRj/ILNkffgWoojJoDy6GhXnATGOlRuc4aXcfVK18lk3K/B
HyqETqjLMZk/lZyo50Xy+S/Mtauf6IKRKEMhKI9jWn9CSjRcmrcy8melv6Rus2UX
p/AseNmiH2oWs5TjKAxEs+IMsemeC0bXlQan90TrV3yic9l1OQChnhAnGimqkLe2
QQlMpFQ1ZS9SfPuujCGoVgUsf0LwJwwWMLYFN7uz1iHB8wJtfm/Bz5DCRt5T5u5r
cvTIP5oYL2gflOMBWOPdhnw/aGTiBa4xsGRkSt9214I7wGRh5DMoX99JOCLF2/Ob
Mm8Mu+ZMTIZs58EGQc5FWw5DFvL4Coh0Kc4J2kG71Ls559F1cCJe2OWf0I0H+kFO
/MOJOJrEzpU6bCRwo518T1Wa4ydXfWaztz3RIZHStrUA/iXo1LGK38oOl5siWtT6
3fxEWzbez5fXC1FTkvzC/kOSppIEtqGvPyWzn89fXDb3cmcGhV7GhoTyEqlXhQ6D
z5QSew0cHeRF/yCJ7B7sFPQR7AEHqLxudfav4JqEdweh+IzhkBgLSeRk6oz7g8CT
yrciH88wZMLzcSG0P+VNUfL5SkcJmdj0qMgny7Zrs26SwADja5U=
=eIkX
-----END PGP SIGNATURE-----

--Apple-Mail=_7B5AE5A5-DD9C-4E8B-B371-F90B7BD64889--


From nobody Sun Nov 12 18:44:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7530F127B57 for ; Sun, 12 Nov 2017 18:44:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsF9RGhmLa7J for ; Sun, 12 Nov 2017 18:44:35 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74CB128B88 for <6man@ietf.org>; Sun, 12 Nov 2017 18:44:04 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id b79so10856731pfk.5 for <6man@ietf.org>; Sun, 12 Nov 2017 18:44:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=SP81hTTA/pKd3ftY99m+GR6hLOxi5h4oaztJ6g8O5qA=; b=P7ukuvK7lCbac+UwNq+RXEa8cL4YzchVTMP0ZuHjFUCUpVeEVrAXX7GxyMVPqCjdPl LrOgluEdLcTw1WrQd0o7UIoHY4/kV4g7NUvHESSE+2zkGni46q/GtNUY7FQMVaC0Phg7 6HRh2/QoNjFaVGXmf9YMGLn34PbYJvoUAT1GFJcM3jqk2CYO8Fx8uWlvn57E8daSmVyn Bq88ngoF2XtdBKIxeNe9H0R+rknAySClOSxG8IbLdsUlWnFfgXO8dr8B+RCJo+WFrdva OeWe44AjbV86KMDioD8Z7frA6WeFX9SE47IkhO7aPJ8oEKusBuLyyqMRc6hwC/hDXA4C nkew==
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=SP81hTTA/pKd3ftY99m+GR6hLOxi5h4oaztJ6g8O5qA=; b=Fei/27zjrpcck1xCjjMro/LWGPZOukHSbiMF5CBBNOkEkeh34D6njQrZ694r8FKI/1 NjHq/Gczep9AdEZ2YU6uwgARtmFVUdTAtJalMu3usPyfUNzs4g/irtyk4vGshk+liWJ6 hkicrgTslb0IF98ZFsTocF6IkvDD3xJtt9+9mzBnXaRF/gGyjnvfxzBaVLPT5ma5CG33 udbLWCIjCJEqnjU/nDpxgq2/LPyb4Hid8lDgJGyOiyRMujsQ0uQbwzGMnR+8qVSKVHvk Lv8pwZWaU3Uiu2Sa73IYpc1goQrBhYJ0gKptiHxkquVLztgFNezWIOg92U1czkyuxFaB V/oA==
X-Gm-Message-State: AJaThX6bnoMQFqafsvtmclND03lRSusarqmzNqbUFT1bclHQz9gSwAZM tddPfVfC7l8V1fliwfOIN70vXQ==
X-Google-Smtp-Source: AGs4zMbLAbVSl1ZO1tcRUjdLH/Einf2xGOcMvaUlDTW4ePJRv8/6XIVANSipB9Ukjg1+NpM71H1PFw==
X-Received: by 10.98.73.196 with SMTP id r65mr8166034pfi.169.1510541044477; Sun, 12 Nov 2017 18:44:04 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:344f:2622:bc20:2ef? ([2001:67c:370:1998:344f:2622:bc20:2ef]) by smtp.gmail.com with ESMTPSA id y3sm31081527pfe.68.2017.11.12.18.44.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 18:44:03 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_8A02224E-74ED-4E9C-9CB3-17BA66A0DAD9"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 10:44:01 +0800
In-Reply-To: 
Cc: Lorenzo Colitti , Joe Touch , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:44:36 -0000

--Apple-Mail=_8A02224E-74ED-4E9C-9CB3-17BA66A0DAD9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 13, 2017, at 10:17 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) =
 wrote:
> +1 with Lorenzo.. and this =E2=80=9Cis=E2=80=9D working and =
=E2=80=9Cdeployed=E2=80=9D right now=E2=80=A6

And that always means that no spec is needed, since we have running =
code.   :)


--Apple-Mail=_8A02224E-74ED-4E9C-9CB3-17BA66A0DAD9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 13, 2017, at 10:17 AM, Van De Velde, Gunter (Nokia - =
BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:
+1 with Lorenzo.. =
and this =E2=80=9Cis=E2=80=9D working and =E2=80=9Cdeployed=E2=80=9D =
right now=E2=80=A6

And that always means that no spec is needed, since we have =
running code.   :)

=

--Apple-Mail=_8A02224E-74ED-4E9C-9CB3-17BA66A0DAD9--


From nobody Sun Nov 12 18:48:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC47127077; Sun, 12 Nov 2017 18:48:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 zWo7OlW-t56j; Sun, 12 Nov 2017 18:48:28 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4831F1241F5; Sun, 12 Nov 2017 18:48:28 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4] (unknown [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8B95C80197; Mon, 13 Nov 2017 03:48:24 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ted Lemon , Lorenzo Colitti 
Cc: "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>, "dhcwg@ietf.org" 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  
From: Fernando Gont 
Message-ID: <1595d30b-b704-8102-977b-31baa384ceb0@si6networks.com>
Date: Mon, 13 Nov 2017 10:50:04 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:48:30 -0000

On 11/13/2017 10:17 AM, Ted Lemon wrote:
> On Nov 13, 2017, at 10:14 AM, Lorenzo Colitti  > wrote:
>> Excuse me, but I really cannot fathom why we are saying that this
>> draft defines a new protocol when it is an explicit goal for all
>> existing implementations to continue to work. How can this be a new
>> protocol when all implementations implement this already?
> 
> All host implementations have to work.   In order for them to work, new
> router behavior has to be specified.   That sounds like a protocol spec
> to me.  My question would be, why is this a problem?   I think that the
> document could be clearer about required behavior, but it already
> basically says what needs to happen. 

If it's a BCP, then it should state what it wants to achieve, and note
that there is a standardized way to do it (DHCPv6-PD), and there are
products width non-standard mechanisms based SLAAC. And that's fair enough.

If somebody is willing to specify PD for SLAAC, then they should write
an I-D targeting 6man -- one might also wonder if also name it SSLAAC,
or just AAC (if there's a lack of a better name :-) )


Putting state into SLAAC will likely trigger "WTH!?" moments,
particulaly in folks that are already having a hard figuring out how all
the IPv6 automatic configuration pieces fit together.

I also wonder what's the logic with which we'd be specifying PD for
SLAAC... and also wondering if we're also going to specify a route
option for DHCPv6, and the like. And, if we're essentially going to
disregard anything and everything that can already be done in a standard
way with DHCPv6 and hack it into slaac instead, why we don't we just
close dhc wg.

Doing a half-baked sateful SLAAC for PD, and telling the community that
that's our best current practice seems to be like sending the wrong
message...

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





From nobody Sun Nov 12 18:51:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAF7127517 for ; Sun, 12 Nov 2017 18:51:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lqsFvYU8fcP for ; Sun, 12 Nov 2017 18:51:09 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BCE1286B2 for ; Sun, 12 Nov 2017 18:51:09 -0800 (PST)
Received: from h.hanazo.no (nat64-ad.meeting.ietf.org [31.130.238.173]) (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 7A1782D5038 for ; Mon, 13 Nov 2017 02:51:09 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id AAF14200BE76BA for ; Mon, 13 Nov 2017 10:50:41 +0800 (+08)
From: Ole Troan 
Content-Type: multipart/signed; boundary="Apple-Mail=_B97EE42B-FA32-4DE2-9858-BFFF233271F3"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: IPv6 only host NAT64 requirements?
Message-Id: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>
Date: Mon, 13 Nov 2017 10:50:40 +0800
To: 6man WG 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:51:23 -0000

--Apple-Mail=_B97EE42B-FA32-4DE2-9858-BFFF233271F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

At the hackathon there was quite a bit of testing of IPv6 only hosts =
with access to the IPv4 network via a NAT64.

While many applications work well on a classic IPv6 only host, there are =
a few things required to make all applications work.

- Must be able to do NAT64 prefix discovery (RFC6052)
- Synthesise IPv6 address from an IPv4 literal (RFC7050)

This is to be able to deal with IPv4 address literals. Which are common =
in protocols like SIP/ICE/STUN.
These can be implemented directly in applications, or it can be =
implemented in the host stack (although application might still have to =
change).

- Should do local DNS64 to support DNSSEC (RFC6147)=E2=80=A8(if you do =
validation).

A DNS64 service in the network looks like a man in the middle attack, so =
to support DNSSEC, validation should happen before synthesizing, and =
must be done on the host itself.

If this is the direction we want to go. Encourage IPv6 only host =
deployments (as opposed to dual stack hosts), are these requirements =
we'd like to add to the IPv6 node requirements document? Somewhere else?

Best regards,
Ole



--Apple-Mail=_B97EE42B-FA32-4DE2-9858-BFFF233271F3
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+/bDNdvtpYqJhC33YFAloJCIAACgkQvtpYqJhC
33abyBAAzshqMoEf1mNL85hSrPOOOkvzBXysrufvmS7/MPqDfbWvKX6k2++gEoAm
HtCRLeHJJI6I0raAYKjlnJ1zs3pY1KyYApdaU9+aTqi0zk+FZYiQ3DP2nLNKUtTR
d0Z+7/bXkb74lLPKxdAGfkq3J8XU0LLtf6nvidd5ns6bRrS4jQqJwePIUWqzToNp
B32Gw+BM+yl5KNg5wJkGIXovigiba/EHtrdHTrj0Pa2a3hebdzUdQHAfWw9E7FdD
iMzkHqf8cumnDLomP4U9NuNXwrDSZMc8VMsACmn2s5zo1HP2ds6AgMYI0Vv3oX8u
DocW8kXnFJ3j5b3aneo/vNWs7oNes4+ai0h13TxGTrNwLxQBRjDPZL3diZ3d7EyH
EZmuF85G4Q+D2M+k2oyC41lzJ8smPgBG/jlcy0nNhUY7YK812plEtyzldMAfCV0B
NQ7uS47+qcKUpbQnBZBME4CYoHfwgI7IIGEuvTmvSReznoWRguYfT/6Bpy8lvQpC
2toV4XcyAEs4Qj9kkbwVc3CacVIctbpaeLDSLM2CMQUI7SeEePiKMnNBcfsE5s9q
fJ/yt2GI8hkU7YxNdrnJp9T/7vufZNkgrmEFeMKeGG+t5SepTRYHXTPm9RDYPHPn
Zuw/lujTWM9QjUGKHmi2NrkUnn89vQsaTLVNh/4uNfU9h4AMSfM=
=KPpH
-----END PGP SIGNATURE-----

--Apple-Mail=_B97EE42B-FA32-4DE2-9858-BFFF233271F3--


From nobody Sun Nov 12 18:53:53 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5BB128ACA; Sun, 12 Nov 2017 18:53:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 GYnMfgpMxCzf; Sun, 12 Nov 2017 18:53:50 -0800 (PST)
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 526A8127B52; Sun, 12 Nov 2017 18:53:50 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id l8so6550776wmg.4; Sun, 12 Nov 2017 18:53:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XGgSlWzVw+OpXakscqi21JLHL3JKz+XcmWeasVwALz4=; b=jBRy/mIkbMlJgitqBfY+isZlQQMTrRotQ7HpGd6zUKfIdqA/c3oF+OuKPjBBxwFdE2 tDGme3bRQROxiT9375WFT48XEm1ZNx8ACfUMNZKnFnr6fPkSN2lezB5KvEQ3Vi+t0+4E DxHK5s+H1KAXiWvk7NxCs1W2a29jw3zzPyDciu9LIsEujL+xnyADjQORLJwBqi2HOumS 37CTCuVxswWhcpkvi5tyU1QLjW+XZL9c9mKqV1O/TD5pRsqjFLMyPAXBiuUxmZgTMs3b OOdTsC/4syLdTyI+SgVDogGIU4sffaCBznCjM4FMZFti48BRT5D6cfj/8QtYWP5VTBZ+ wi0g==
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=XGgSlWzVw+OpXakscqi21JLHL3JKz+XcmWeasVwALz4=; b=pC/XC8eqW/tqmD7mvW1lQRHypd3TXB/2IhwLKqEv40t6Y4wwfqES69aC3sJoRXk/ar bf8eI5Np8fO8CpsEAm5nDsuf3c6ln+Lo/eZEVvYtEqKzzwXaCi4BASyDvilRb2ROQuOA adL6hwv5mmQQJyNeA4Fj9au18UNDfH0C4myO7fXXeKNO4t3p3dpsxMd6Jc1M7lejpCrf 0nb6UNlEWgUIV8KE/eTLg5vjdrH6aXiQSPRJ7/cwnPXdpx7WRrzikLjSrDjejy3skS3p PntAXft7R8C3xz2ZG9usC7d6kPG8LInj62Z/ji6hcsmSyoLZUIJIgk/dNLMly0dLBmNl Sp4w==
X-Gm-Message-State: AJaThX4vZquzCoTZU4gVHbz+cH+N/dgNS1s9u+BJGT9B7F03d/2d+U7k C1hS8MgpB7E8DMi7pOzaHSs=
X-Google-Smtp-Source: AGs4zMayxD/UByC8SfAAJqRdMl17H52KOwl4xROg0CuOdXg75YCYBBwdbvG0A7mTErV7S7WHyufDRw==
X-Received: by 10.28.29.21 with SMTP id d21mr2755140wmd.93.1510541628923; Sun, 12 Nov 2017 18:53:48 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:1d89:6327:9256:69ce? ([2001:67c:370:128:1d89:6327:9256:69ce]) by smtp.gmail.com with ESMTPSA id e131sm12582887wmg.1.2017.11.12.18.53.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 18:53:48 -0800 (PST)
From: Bob Hinden 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_DBBCB0C1-5B62-4E92-9522-EAE7D3C800EA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 10:53:43 +0800
In-Reply-To: 
Cc: Bob Hinden , Fernando Gont ,  "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
To: =?utf-8?Q?Ole_Tr=C3=B8an?= 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:53:52 -0000

--Apple-Mail=_DBBCB0C1-5B62-4E92-9522-EAE7D3C800EA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Ole,

> On Nov 13, 2017, at 10:42 AM, Ole Troan  wrote:
>=20
> Fernando,
>=20
>>> > wrote:
>>>=20
>>>   FWIW, I would agree with that if this were an issue of WG focus =
creep.
>>>   AFAICT, the issue appears to go much deeper, which means it's an =
Area
>>>   boundary issue if it is indeed a protocol extension.
>>>=20
>>>   IMO, OPS stays in the lane of suggesting sets of *existing* =
protocol
>>>   parameters and features, or indicates where MAYs and SHOULDs can =
be
>>>   relaxed (or not) - all of this remains compliant with the =
protocol.
>>>   Changes to the protocol should not be considered operational =
decisions,
>>>   again IMO.
>>>=20
>>>=20
>>> Excuse me, but I really cannot fathom why we are saying that this =
draft
>>> defines a new protocol
>>=20
>> Model SLAAC with a FSM for the client, and a FSM for the server. Now
>> apply this document. And look at the SLAAC router FSM.
>>=20
>> Did it change (and quite a lot, actually)?  If yes, then you ahve
>> changed the protocol. If not, you didn't do the FSM properly.
>=20
> Or do as I do in my implementation.
> Model each host as being on it's own point to point interface.
> Configure the IPv6 prefix on that interface. That configured state is =
exactly like what we have in classic SLAAC.
>=20

Good point.  If the document had described this as something like =
creating virtual interfaces, we might not be having this discussion.

Bob




--Apple-Mail=_DBBCB0C1-5B62-4E92-9522-EAE7D3C800EA
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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloJCTcACgkQrut0EXfn
u6g1+QgAlwtjc7XVGWyaYZci793992XNJYTtSL+luuNgnGmnzuj9+PQLouPdvHmx
xk659RBME/22lX1AQ88wz14/8MQ9XpJia/kHfWhjxv0p0Zuy4sN4CsJc3k0z7oHx
ajQjnm4ZBXBhmvbPuAn8DEvo9nYbqe4CV1NGRJSbqdbYOZR9fW02QYDI6R6T2+r3
lZUKfgLrrpCmKQKrufXqcAZAyBBNmoLjbcWfe+0sRFT9XAp+Mq3jCMTwbJrMQ8aR
x9R22ROPGlCBbY5/aDVAUpbHv2V4Slew2yBhNDaSoYpK9727EIx04TlKGIuCevJw
VHfGlgKEX6YQFAl19kQZsOGBAOKzzA==
=LDMO
-----END PGP SIGNATURE-----

--Apple-Mail=_DBBCB0C1-5B62-4E92-9522-EAE7D3C800EA--


From nobody Sun Nov 12 18:55:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2441128DE5; Sun, 12 Nov 2017 18:55:29 -0800 (PST)
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 cvbDf435i_sF; Sun, 12 Nov 2017 18:55:25 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0091.outbound.protection.outlook.com [104.47.0.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DC6128ACA; Sun, 12 Nov 2017 18:55:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IJH4qWDCytpCYor6KZlK3G/zvMfjT1JmJxFhScDjwjk=; b=fIARfP398bJmOtwHEwmDqXt/G5efdpFct8TFeBk8DqUiLpVqT3lowMlpATMnJG+MuB/YMTTV/MSMl+AukO1jF+TDAyVYSKQjFO9E8pfdwSJEHfB91t0dEDDgrfw1030ky5KQnMefcihyfDgiSteWzhqmv3ymtatIaVK2s5PVXbo=
Received: from HE1PR0701MB2843.eurprd07.prod.outlook.com (10.168.91.145) by HE1PR0701MB2844.eurprd07.prod.outlook.com (10.168.91.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 02:55:20 +0000
Received: from HE1PR0701MB2843.eurprd07.prod.outlook.com ([fe80::7910:5b35:5762:f7de]) by HE1PR0701MB2843.eurprd07.prod.outlook.com ([fe80::7910:5b35:5762:f7de%18]) with mapi id 15.20.0239.004; Mon, 13 Nov 2017 02:55:20 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: Ole Troan , Fernando Gont 
CC: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
Subject: RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Topic: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Index: AQHTV0Ps944vy/6Q4EOhEJVwr1mwgaMLXqEAgAD43YCAAB+YAIAAc32AgAEvwICAAB0aAIAAJZ+AgAM+noCAAAPZgIAABCsAgAAA6yA=
Date: Mon, 13 Nov 2017 02:55:20 +0000
Message-ID: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; 
x-originating-ip: [2001:67c:370:128:69f5:b177:9682:2059]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2844; 6:F0WAX2BmKwTrrLh8VO+ILEc+0SvkE9DnuDB/n4kGohx/Q+Ik1eCdSWfee3/Q6hV1GdvpmvAx/eZB/umSMyTpHjSGN+PkB6LXnF6qm8aQbaOXQ2iWFoWJv1lompov1c1djaYvvXdtxblcyeESRI+8Ith1q7qfwzro6tQ0MxDzb9s/kPBdIEstjIHL6KAyWNxa7579TpYfPAI97uMeDRLrT1A59+3RaZ1m8ogTv/KbZEVEtkoyiwgwVDTHupQ8c39GIlVuZWlkOj1fLld84AbK9ZRHaRCMHkd4VCqMoaN89/jxYqoxD6gXdE/U0qOdZCOI2pmf2Zx4y4xsiHDYmzWYyz//Dj7Cw+HskM0hFPmKOuw=; 5:zI3I6KRoeXqqQDIOWIDPVi7LxfB1WnLQfjUhH01hD5MjGL3EHmhSmYqTMKLoWm0Ti1WyglBdXJZv7G9sjtJtEADM5TkpuSDWLubXFzoBKdyzn3VIh8fI+WvZ40KxOXiobVsDKFrEFHltQ25ZImiBtgfbbo7c4MWAimJ3hQf5mgQ=; 24:xiFvYCYeYpQLKXLUd5Nq0p3y7HuUHyDVbudUhWrqYhALveczv8uX9rvrZBEplf7XMAXYxW81cN0UfejAtOmfGOnqipdnG+jB9bO6AMlpjTM=; 7:IDELLMxi5pcLsGzGX/Z7XjmHj1olBArXYavP7rUWbbBX7jao8gFjqBrLk/BMvQoNfA787DFSsNqbPOWL5vMZNG4snC7QzecYHAFazc9ghq6SRC33OqMIsaqy3ksC58nfiDfQ3xV5JQf+lkvt6go1w2lhu5D92tC1qBQGN4bXdEsRHJLSZs2jbxz/FiAfmFugiUy5bhYL9yRe4FpVV3kJDv+WZKu82qOSAHFXTUKk59QORJOXilBr8asQWv5rroxJ
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: dde718fa-11b5-419b-5bbb-08d52a41fa45
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:HE1PR0701MB2844; 
x-ms-traffictypediagnostic: HE1PR0701MB2844:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3231022)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB2844; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB2844; 
x-forefront-prvs: 0490BBA1F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(199003)(24454002)(13464003)(189002)(86362001)(33656002)(7696004)(5660300001)(25786009)(55016002)(4326008)(99286004)(2950100002)(53936002)(478600001)(230783001)(6116002)(97736004)(14454004)(102836003)(54356999)(53546010)(54906003)(110136005)(76176999)(6506006)(5250100002)(8676002)(81156014)(9686003)(8936002)(2906002)(50986999)(105586002)(229853002)(2900100001)(106356001)(3660700001)(6246003)(7736002)(3280700002)(93886005)(81166006)(74316002)(316002)(189998001)(305945005)(6436002)(68736007)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2844; H:HE1PR0701MB2843.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; 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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dde718fa-11b5-419b-5bbb-08d52a41fa45
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 02:55:20.1477 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2844
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:55:30 -0000

Same for the Nokia implementation. It is session based p-t-p model and the =
session state is build upon for example IPoE, EAP-SIM, etc....=20

WG decided to exclude how the session state is achieved on the first hop ro=
uter. We as WG decided that creation and maintaining of state on that acces=
s router over reboots is outside of scope for the /64 allocation per connec=
ted EU. Nothing new from standards perspective to give /64 to a EU is neede=
d, then beyond what is in the document. We are discussing scope creep.

G/

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ole Troan
Sent: Monday, November 13, 2017 10:43
To: Fernando Gont 
Cc: 6man@ietf.org; v6ops@ietf.org WG 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-pe=
r-host)

Fernando,

>> > wrote:
>>=20
>>    FWIW, I would agree with that if this were an issue of WG focus creep=
.
>>    AFAICT, the issue appears to go much deeper, which means it's an Area
>>    boundary issue if it is indeed a protocol extension.
>>=20
>>    IMO, OPS stays in the lane of suggesting sets of *existing* protocol
>>    parameters and features, or indicates where MAYs and SHOULDs can be
>>    relaxed (or not) - all of this remains compliant with the protocol.
>>    Changes to the protocol should not be considered operational decision=
s,
>>    again IMO.
>>=20
>>=20
>> Excuse me, but I really cannot fathom why we are saying that this=20
>> draft defines a new protocol
>=20
> Model SLAAC with a FSM for the client, and a FSM for the server. Now=20
> apply this document. And look at the SLAAC router FSM.
>=20
> Did it change (and quite a lot, actually)?  If yes, then you ahve=20
> changed the protocol. If not, you didn't do the FSM properly.

Or do as I do in my implementation.
Model each host as being on it's own point to point interface.
Configure the IPv6 prefix on that interface. That configured state is exact=
ly like what we have in classic SLAAC.

Ole



From nobody Sun Nov 12 18:56:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0391293EB for ; Sun, 12 Nov 2017 18:56:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zKAXags9GVSC for ; Sun, 12 Nov 2017 18:56:29 -0800 (PST)
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 3CFB5126DCA for <6man@ietf.org>; Sun, 12 Nov 2017 18:56:27 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id 207so8863865pgc.12 for <6man@ietf.org>; Sun, 12 Nov 2017 18:56:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=uzN8sNab+r/K9jZe9/xz0OrnV4AuL8R3ElF8ZlggTg4=; b=SX+RA5dCkKUkzkO5loDlfckKcGD3ZlJ4AE/a3ghyD0ZDBiPmgPsupLgif1m2xBOMnR eHQ2BCH+m5cqOLjtTIrsWrBoTEXxoQpncxZIe+N2qhyznHDA/2LJEYAESKgnwva8P+Rk hTHA87Avyu4PavTcVab0Ozi5Bx1wfMrH0pMWcPrIr2M8icBZ8Z4hkjkclk8WdBfcauPi G6WskGIE79VGJp4mAhPgeU00uxHIMbJMutjbIZ37uc1ar2hb/OkyqVRqkAdCvmphP+a+ BymOAIXNZcxfm1kp7c5yCq+eLFbSsOjytroq+ryJl55omiv61NxLhjJrneTDtASQjXg4 rqGw==
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=uzN8sNab+r/K9jZe9/xz0OrnV4AuL8R3ElF8ZlggTg4=; b=UuCsZD/qv89auHPGGT8HmQ4N7NsCH0hrTCMpYdncrVu5So6JCKhAv+Q3J4i8q34nrM zCip6zuE3N60/qByzL5pnsPyXcgdxLfIhcZPm2BuEWZG58rHkKtYaUG9cqvbF6K2tYah 18vN0xoiPdjHaEMWDUW8u2VyjYogHSH+boTs9DByFiPD1IuBAdiUOMS1udahnCt4/8uK G0J9Aizmg5cMASjzoRtVd0rLs3A+cydUqhuRcNwCFe++DU8V1ZBhctk+a9UNL3/XeHlS 1rJs+YKf+VDuojtmEDvnh+6x/PMn9oKshumjZSl3m/kr4inDZHj3di5jMt24dda7cx18 EeNQ==
X-Gm-Message-State: AJaThX7lYxFsuzE/WVvVFO/FMKPiw4ENv5QhEJG+EcexKdvxl5SUttx/ 5xHcE8OdIK+KJRrdCBu7DSm4aIyyfMM=
X-Google-Smtp-Source: AGs4zMYUjuIM+UKfywkzacXrNSP3ggq/EDiHlDBLCkcuh+vsis0r1Skh5PyRUfwjj8fvo1d93FKfWw==
X-Received: by 10.98.68.146 with SMTP id m18mr8457388pfi.10.1510541786843; Sun, 12 Nov 2017 18:56:26 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:344f:2622:bc20:2ef? ([2001:67c:370:1998:344f:2622:bc20:2ef]) by smtp.gmail.com with ESMTPSA id l22sm34025459pfk.45.2017.11.12.18.56.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 18:56:26 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_2201CF9F-00EF-463E-A49C-636A8F1D55A2"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 10:56:23 +0800
In-Reply-To: 
Cc: =?utf-8?Q?Ole_Tr=C3=B8an?= , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
To: Bob Hinden 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:56:31 -0000

--Apple-Mail=_2201CF9F-00EF-463E-A49C-636A8F1D55A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 13, 2017, at 10:53 AM, Bob Hinden  wrote:
> Good point.  If the document had described this as something like =
creating virtual interfaces, we might not be having this discussion.

The problem is that there is still required behavior around these =
"virtual interfaces" that needs to be documented.

E.g., Ole, what happens in your implementation if the router reboots?   =
What happens if a host chooses a new link-local address?   Etc.


--Apple-Mail=_2201CF9F-00EF-463E-A49C-636A8F1D55A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 13, 2017, at 10:53 AM, Bob Hinden <bob.hinden@gmail.com> wrote:
Good point.  If the document had =
described this as something like creating virtual interfaces, we might =
not be having this discussion.

The =
problem is that there is still required behavior around these "virtual =
interfaces" that needs to be documented.

E.g., Ole, what happens in your =
implementation if the router reboots?   What happens if a host =
chooses a new link-local address?   Etc.

=

--Apple-Mail=_2201CF9F-00EF-463E-A49C-636A8F1D55A2--


From nobody Sun Nov 12 19:00:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6371127B73; Sun, 12 Nov 2017 18:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cfQtUQRMtuid; Sun, 12 Nov 2017 18:59:37 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310981293EC; Sun, 12 Nov 2017 18:59:36 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4] (unknown [IPv6:2001:67c:1232:144:8016:582c:2bf0:48c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7C337803CA; Mon, 13 Nov 2017 03:59:32 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ole Troan 
Cc: Lorenzo Colitti , Joe Touch , Brian E Carpenter , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> 
From: Fernando Gont 
Message-ID: 
Date: Mon, 13 Nov 2017 11:00:56 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 02:59:39 -0000

On 11/13/2017 10:42 AM, Ole Troan wrote:
> Fernando,
> 
>>> > wrote:
>>>
>>>    FWIW, I would agree with that if this were an issue of WG focus creep.
>>>    AFAICT, the issue appears to go much deeper, which means it's an Area
>>>    boundary issue if it is indeed a protocol extension.
>>>
>>>    IMO, OPS stays in the lane of suggesting sets of *existing* protocol
>>>    parameters and features, or indicates where MAYs and SHOULDs can be
>>>    relaxed (or not) - all of this remains compliant with the protocol.
>>>    Changes to the protocol should not be considered operational decisions,
>>>    again IMO.
>>>
>>>
>>> Excuse me, but I really cannot fathom why we are saying that this draft
>>> defines a new protocol
>>
>> Model SLAAC with a FSM for the client, and a FSM for the server. Now
>> apply this document. And look at the SLAAC router FSM.
>>
>> Did it change (and quite a lot, actually)?  If yes, then you ahve
>> changed the protocol. If not, you didn't do the FSM properly.
> 
> Or do as I do in my implementation.
> Model each host as being on it's own point to point interface.
> Configure the IPv6 prefix on that interface. That configured state is exactly like what we have in classic SLAAC.

The I assume that, in that case, you don't need to do anything fancy
with how you send the multicasted RAs, and the SLAAC router
implementation need not keep a table of bindings?

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





From nobody Sun Nov 12 19:05:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19EA12700F; Sun, 12 Nov 2017 19:05:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 U6hNCQuWNoDJ; Sun, 12 Nov 2017 19:05:25 -0800 (PST)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A221241F5; Sun, 12 Nov 2017 19:05:25 -0800 (PST)
Received: from [31.133.137.43] (dhcp-892b.meeting.ietf.org [31.133.137.43]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vAD35J6D018941 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 12 Nov 2017 19:05:21 -0800
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ole Troan , Fernando Gont 
Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" , Joe Touch 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> 
From: Erik Nordmark 
Message-ID: <862687c9-c107-53a8-288a-29049097b0e1@acm.org>
Date: Mon, 13 Nov 2017 11:05:18 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVY5kD3Jv0d+sqTQYqA/Q1B2QgUFj2VcKQg+CYssxqw9uDD8bZxkUwzJiCmqo5CRX4udNyVZ+pqg8lraGXddGvq4
X-Sonic-ID: C;rikOex/I5xGPDYKfRUfeDw== M;FNQGfB/I5xGPDYKfRUfeDw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 03:05:26 -0000

On 11/13/2017 10:42 AM, Ole Troan wrote:

> Or do as I do in my implementation.
> Model each host as being on it's own point to point interface.
> Configure the IPv6 prefix on that interface. That configured state is exactly like what we have in classic SLAAC.

Ole,

did you figure out how to expire those allocated prefixes when the host 
is long gone from the network?

The draft seems to be silent on that issue and if the purpose is to 
document some current practice it would be good to capture that.

    Erik


From nobody Sun Nov 12 19:06:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEF5127876; Sun, 12 Nov 2017 19:06:34 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 Es885XfDVW1s; Sun, 12 Nov 2017 19:06:32 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10108.outbound.protection.outlook.com [40.107.1.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20D271272E1; Sun, 12 Nov 2017 19:06:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B0iYA6HH8SuimwvnFnT3jI2G105fpfaeH2Z1RsyOdYA=; b=oNkD03z+iVbX0I89Bd1tV2FqJ7SuuEYKiI2jRxU17Kj9r2/WoxzQOtwgwFaUIVA/DN1LQzZYU+ydsdbLUqpm8hMOUhgoQwX3xw+0F+LgTMyjrzn+Zz5sIntfPyQmUOdMoyeJ/vJCR0PUyNMNImN7QKHcK4qzEDjZqQEJ3E3vvNQ=
Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB2835.eurprd07.prod.outlook.com (10.168.155.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 03:06:29 +0000
Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::7007:b8e:3320:94c1]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::7007:b8e:3320:94c1%14]) with mapi id 15.20.0239.004; Mon, 13 Nov 2017 03:06:29 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: Ted Lemon , Bob Hinden 
CC: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
Subject: RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Topic: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Index: AQHTV0Ps944vy/6Q4EOhEJVwr1mwgaMLXqEAgAD43YCAAB+YAIAAc32AgAEvwICAAB0aAIAAJZ+AgAM+noCAAAPZgIAABCsAgAADBYCAAAC/gIAAAJCA
Date: Mon, 13 Nov 2017 03:06:29 +0000
Message-ID: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:67c:370:128:69f5:b177:9682:2059]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2835; 6:oSZYqrGONKrS1rqqG9EpQk3VvuygrNTrew7gnRDkskF/HRJKScagHa24UyPwx8LQEK7C5YXWWAPVSwmdyOg+9mOPhUabUoRyIpa9UC5UptbVffEM3clURzQE553I608aMAkbvQv89GvJpCO8bjA9RKaLEKeQaoHkOzV95kh8csXJaImJtCHM7UHHe2nIkj9lnr5jLFg6koqtWwMW3wDdj8MJq8Y12nqgGp6KapvKwOjNYzWBTMLqESlIfH/YpC3CTaDgRGyZR8z7Y8BJbxcu917rP+XV4r7SvI7cyvAdAZ540sqSpgl6l9H8Ul1MboRYAefeqz4V+dUO4Bn9USrkZyGfL37syGK0NDxbH4vHcsY=; 5:Iz8kAiRT3xIGAVhFhMET0ZDYBjG3fTWeWCZRLMjkiWVn1XXpxvAzBn92JgqzOk4nPVf+V4Itbpwx6QL3dalwTrQoU+3a6IEqx8vTKWh+Lz6ncM/Sky3zo/14BKhZvmA9RIBrpN5m12+o7JlSYixpIddl9m0bTn61CqYZyIP8KOk=; 24:i/EbTX2201XMBN8HH5tK5uUEuNOi3S6BS0q8k6P1LQXktNfzeUwUPeXl09kos6yupcVCnv9mrVtPvKfPLeTNoBaIfUFvlNh9Lfa1+U1hwjc=; 7:TZRvkOK3/Zmp5y84FvGiTQ1/Yo0WnvoebO5UAZafoZe61+6QrIVl/bFZaDnU9u67oYMCRufn8tKLZeAKYTeryc7aZyh0Q5zW8pQAuA2nHXH+xaPFVIAKEdxRcNTqqXRZ+dzA5msS+YnHbBznMs2H/fKRkW/LgkywXaQNrgpylPl5lKtFxaFxQ8v3GgGn29RfDg1IQeJo6Svpp7bE9ErmABjDa89YUzjdDeCfQK0iQst0tD7a8G8kHPAC2+YZlisn
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b4f1cd17-29d2-4740-acfd-08d52a43890b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:AM5PR0701MB2835; 
x-ms-traffictypediagnostic: AM5PR0701MB2835:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(3231022)(6055026)(6041248)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2835; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2835; 
x-forefront-prvs: 0490BBA1F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(199003)(189002)(24454002)(25786009)(2900100001)(101416001)(8936002)(4326008)(105586002)(5250100002)(76176999)(68736007)(93886005)(102836003)(790700001)(106356001)(54356999)(6116002)(7696004)(33656002)(50986999)(5660300001)(229853002)(8676002)(6436002)(6306002)(6506006)(97736004)(2906002)(54906003)(19609705001)(53936002)(9686003)(99286004)(55016002)(54896002)(7736002)(39060400002)(230783001)(86362001)(53546010)(81156014)(110136005)(3660700001)(74316002)(478600001)(6246003)(14454004)(81166006)(2950100002)(189998001)(3280700002)(316002)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2835; H:AM5PR0701MB2836.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2836292A85EB117A605492A4E02B0AM5PR0701MB2836_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b4f1cd17-29d2-4740-acfd-08d52a43890b
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 03:06:29.2274 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2835
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 03:06:34 -0000

--_000_AM5PR0701MB2836292A85EB117A605492A4E02B0AM5PR0701MB2836_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Ted, it depends upon how the router identifies what is a session to create =
the "virtual interface".
The session state mechanics is considered out of scope for this particular =
v6ops document. It can be done in many many ways... and the across reboots =
can be done in many ways also, depending on the capabilities of the router =
and the backend OSS system. Its out of scope.

G/

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Monday, November 13, 2017 10:56
To: Bob Hinden 
Cc: Fernando Gont ; 6man@ietf.org; v6ops@ietf.org WG=
 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-pe=
r-host)

On Nov 13, 2017, at 10:53 AM, Bob Hinden > wrote:
Good point.  If the document had described this as something like creating =
virtual interfaces, we might not be having this discussion.

The problem is that there is still required behavior around these "virtual =
interfaces" that needs to be documented.

E.g., Ole, what happens in your implementation if the router reboots?   Wha=
t happens if a host chooses a new link-local address?   Etc.


--_000_AM5PR0701MB2836292A85EB117A605492A4E02B0AM5PR0701MB2836_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Ted, it depends upon how the router identifies what =
is a session to create the “virtual interface”.


The session state mechanics is considered out of sco=
pe for this particular v6ops document. It can be done in many many waysR=
30; and the across reboots can be done in many ways also, depending on the =
capabilities of the router and the backend
 OSS system. Its out of scope.


 


G/


 






From: v6ops [mailto:v6ops-bounces@ietf.org] <=
b>On Behalf Of
Ted Lemon

Sent: Monday, November 13, 2017 10:56

To: Bob Hinden <bob.hinden@gmail.com>

Cc: Fernando Gont <fgont@si6networks.com>; 6man@ietf.org; v6op=
s@ietf.org WG <v6ops@ietf.org>

Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-pr=
efix-per-host)






 


On Nov 13, 2017, at 10:53 AM, Bob Hinden <bob.hinden@gmail.com> wrote:








Good point.  If the document had described th=
is as something like creating virtual interfaces, we might not be having th=
is discussion.








 




The problem is that there is still required behavior=
 around these "virtual interfaces" that needs to be documented.






 






E.g., Ole, what happens in your implementation if th=
e router reboots?   What happens if a host chooses a new link-local ad=
dress?   Etc.






 








--_000_AM5PR0701MB2836292A85EB117A605492A4E02B0AM5PR0701MB2836_--


From nobody Sun Nov 12 19:07:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E102127876; Sun, 12 Nov 2017 19:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOgnc0W6tZaj; Sun, 12 Nov 2017 19:07:30 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928BE1274D0; Sun, 12 Nov 2017 19:07:30 -0800 (PST)
Received: from h.hanazo.no (nat64-ad.meeting.ietf.org [31.130.238.173]) (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 E3CFE2D4F99; Mon, 13 Nov 2017 03:07:29 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 3987A200BE9B01; Mon, 13 Nov 2017 11:07:02 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_C6067886-6048-43A9-9270-02E99B3343BA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 11:07:01 +0800
In-Reply-To: 
Cc: Lorenzo Colitti , Joe Touch , Brian E Carpenter , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
To: Fernando Gont 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 03:07:32 -0000

--Apple-Mail=_C6067886-6048-43A9-9270-02E99B3343BA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Fernando,

>> Or do as I do in my implementation.
>> Model each host as being on it's own point to point interface.
>> Configure the IPv6 prefix on that interface. That configured state is =
exactly like what we have in classic SLAAC.
>=20
> The I assume that, in that case, you don't need to do anything fancy
> with how you send the multicasted RAs, and the SLAAC router
> implementation need not keep a table of bindings?

That's correct.
The interfaces look like:
interface P2P-Ethernet0 remote-mac aa:bb:cc:dd:ee:ff
 ipv6 address 2001:db8::1/64

Think of it as an interface with a fixed L2 address for the remote end.
L3 to L2 address mapping is then fixed, both for unicast and multicast.
Should that have it's own internet draft, very possibly?

In the vein of all problems in computer science can be solved with =
another layer of redirection.
How these interfaces are created and how they are maintained across =
reboots etc, can be considered out of scope for the SLAAC feature.
Although they have to be solved somewhere somehow of course.

Best regards,
Ole


--Apple-Mail=_C6067886-6048-43A9-9270-02E99B3343BA
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+/bDNdvtpYqJhC33YFAloJDFUACgkQvtpYqJhC
33ZDwg//Tc2Fp0XPjCPICuyH5NVfxhOLx0mhSFG7UtLf045AgLuYYOPz8qJ3QATh
wfgAaN1ub/SbqxYs8Cjz49UY65DNv1NtKzvU7sSO7fOcchapPc3PnfBmAt3m1TEP
6gOGsZdBXLXa/SbnX205RW/bFKP/J9Pbx8WiCY+1ySF/edtF1CavxExESw3eJaov
1H3E+C5XpAa6bpcyh4rREoKgkMyJxJ5WIi5J2gKaKNQvPGBVn89xcWmH/LZ+TwDq
VSlWx4vgNL330vYXMSQ0z13fl+mLejJe5YAjhMT/2hbO5JOhaoRDOFT20CJL7mJ8
vtVDxO9ObQ8jf0JbSdcSkzzHRGp1c+Qjcnts3xY3WOVpBI1OtXPc5HKHShdHFE1Z
v8sxvNFkmYfzTJfSV7t5HRDwUxmUgh0+f+h1oJoSRly/a6u5zYMp0LsL/9bpjOML
HV8zeyx5BCLdfrTURdhkTQY/SljcccXRlpfxTHjKWOZL8WriozfHi53z/5R+KyVa
4bNL/3IhrtM3wdeEGY9zoFsi0G9Z0oiYQSUlbwg5sZcvY8WzYw73cvNW4W/7X2sK
rVdyScZLweX4aaCd3kFtGA+TIA9M5bWpv+VuEQ4y9T6kaHJwwaSgRtnRTeM+2MMp
k65ayFOrsnYwYGHkgbiv1D6fI7onjbzXgLmbPViKqca7QaOIPio=
=VgGB
-----END PGP SIGNATURE-----

--Apple-Mail=_C6067886-6048-43A9-9270-02E99B3343BA--


From nobody Sun Nov 12 19:08:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96DB12700F; Sun, 12 Nov 2017 19:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 gJ03MBDIqXCr; Sun, 12 Nov 2017 19:08:18 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10113.outbound.protection.outlook.com [40.107.1.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13F71289C3; Sun, 12 Nov 2017 19:08:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P3F0pEslR45/7Y1wLqkrH1qHp5dn9E42YMe2SZhjkPE=; b=cMpBStkEzJVPa9/HqnYU4OdC3Jnj3q1D7Ja5FOL8zaLoGzn/h8MOVOUMwTbmjdQ1+WMqLD5XsY6KxFc0hMGMzsRGiIAw2LD2Kd/qyw9fyTr9gAEPHtdm1QbJK3IfJ1VYWMdRgqPRquvFzsZic8CAGK2qFAFO9Z8Wa4SuO2I7//0=
Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB2835.eurprd07.prod.outlook.com (10.168.155.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 03:08:10 +0000
Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::7007:b8e:3320:94c1]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::7007:b8e:3320:94c1%14]) with mapi id 15.20.0239.004; Mon, 13 Nov 2017 03:08:10 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: Erik Nordmark , Ole Troan , Fernando Gont 
CC: "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
Subject: RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Topic: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Index: AQHTV0Ps944vy/6Q4EOhEJVwr1mwgaMLXqEAgAD43YCAAB+YAIAAc32AgAEvwICAAB0aAIAAJZ+AgAM+noCAAAPZgIAABCsAgAAGQgCAAABiwA==
Date: Mon, 13 Nov 2017 03:08:10 +0000
Message-ID: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>
In-Reply-To: <862687c9-c107-53a8-288a-29049097b0e1@acm.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:67c:370:128:69f5:b177:9682:2059]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2835; 6:YdnfAHaLuJQnId88+AODQ9PK/PRDYqzxpjnNfxhEbq5dKhT8FkNL5zWaWg0klsZ4CiLeAKNiges6HuSoAAPq1vbfRSC+ZsW2VsrC9IuyKcfw6tBqxmVmbagMfrtOA5fY5F6AH/mmGopFgiRDFy2hKYf65FEHDOfRnkEH3yiMFAe5oEhZTAIDMCb4S1MoZn4MYAsNj13ospOmWhCmPbyX/CRxWq6RjBI+PBqa/aWPMONuBZaxP59HYHGeD5/2yE0qORF8BTXO2igkcR9IqbcuvDtY1YWjE0SH+NULGoiPoWltz7ZbT7VePTfHA2av8xgKu4Rwaay7hhUAFK486x5whh34hZnWNZgwBiaviHEzFsI=; 5:5dNhthIqXufyolvJvuFWEYEh395PR1t0RknvtRUjRNDpsCI/rrrzY3sj001b+Wvi6d2WRs3h/0l/SG5jqltWP1Iol2hXcZrQEkLQN+bxc/9skHbGzE3I4vXFMHMSewQpoHkPrYrfp6aOHGPoBjnh27sEy5iIWuhoRuv/x2/FrLo=; 24:OsfQh71QGwJFG9VfRgx3wY/wT2p8TWSpeh49NSs6BjfPfzLwr0XTcyeoZ+mleLQPZwAtmwZRfdMmZd9EI61mKI+SV/Tz1XB1o82id9tYTh8=; 7:N0pCS9bkQdSVDUAKEtsiHs88LZm9NPpu8hNClC98a2bVp2JIbomPTcZC6p6cyS087aBzCIG1s1uRK404cVTeKDq6JuvcZsht8wm1PMrTgHI1G4krhJAwEFSY3C9k2I5tIyqJK+ahrBc8vFK9H8Ief0KAbiGlR7XLdx2yWxKAM/GHzcSYWcDpCDN7p+JGGdrq8sU15itbLX7Ibff3uSNQ6gcE6BS8jepd2qrW3qEn8svCzQjtgVQ3gF3/xbk713FN
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b428c5cd-cf82-4e89-123e-08d52a43c52c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:AM5PR0701MB2835; 
x-ms-traffictypediagnostic: AM5PR0701MB2835:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(3231022)(6055026)(6041248)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2835; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2835; 
x-forefront-prvs: 0490BBA1F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(199003)(13464003)(189002)(24454002)(25786009)(2900100001)(101416001)(8936002)(4326008)(105586002)(5250100002)(76176999)(68736007)(93886005)(102836003)(106356001)(54356999)(6116002)(7696004)(33656002)(50986999)(5660300001)(966005)(229853002)(8676002)(6436002)(6306002)(6506006)(97736004)(2906002)(54906003)(53936002)(9686003)(99286004)(55016002)(7736002)(230783001)(86362001)(53546010)(81156014)(110136005)(3660700001)(74316002)(478600001)(6246003)(14454004)(81166006)(2950100002)(189998001)(305945005)(3280700002)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2835; H:AM5PR0701MB2836.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b428c5cd-cf82-4e89-123e-08d52a43c52c
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 03:08:10.0874 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2835
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 03:08:22 -0000

The session state management procedures out of scope of this document. This=
 is scope creep.

G/

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Erik Nordmark
Sent: Monday, November 13, 2017 11:05
To: Ole Troan ; Fernando Gont 
Cc: v6ops@ietf.org WG ; 6man@ietf.org
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-pe=
r-host)

On 11/13/2017 10:42 AM, Ole Troan wrote:

> Or do as I do in my implementation.
> Model each host as being on it's own point to point interface.
> Configure the IPv6 prefix on that interface. That configured state is exa=
ctly like what we have in classic SLAAC.

Ole,

did you figure out how to expire those allocated prefixes when the host is =
long gone from the network?

The draft seems to be silent on that issue and if the purpose is to documen=
t some current practice it would be good to capture that.

    Erik

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


From nobody Sun Nov 12 19:15:02 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A5C127077; Sun, 12 Nov 2017 19:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u02-sxvPWJti; Sun, 12 Nov 2017 19:14:58 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C351712700F; Sun, 12 Nov 2017 19:14:58 -0800 (PST)
Received: from h.hanazo.no (nat64-ad.meeting.ietf.org [31.130.238.173]) (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 3C85E2D5038; Mon, 13 Nov 2017 03:14:58 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D3EE6200BEA860; Mon, 13 Nov 2017 11:14:30 +0800 (+08)
From: Ole Troan 
Message-Id: <581AF3E8-00D9-4EBD-A98A-2D5867010980@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_4282AA4E-DEA8-472C-A8A4-925C0B0244D2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 11:14:29 +0800
In-Reply-To: <862687c9-c107-53a8-288a-29049097b0e1@acm.org>
Cc: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" , Joe Touch 
To: Erik Nordmark 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 03:15:00 -0000

--Apple-Mail=_4282AA4E-DEA8-472C-A8A4-925C0B0244D2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Erik,

>> Or do as I do in my implementation.
>> Model each host as being on it's own point to point interface.
>> Configure the IPv6 prefix on that interface. That configured state is =
exactly like what we have in classic SLAAC.
>=20
> Ole,
>=20
> did you figure out how to expire those allocated prefixes when the =
host is long gone from the network?
>=20
> The draft seems to be silent on that issue and if the purpose is to =
document some current practice it would be good to capture that.

Right, and it might be a case of "it depends".
Interesting question though, would be benefit from an L3 solution to =
this problem?

In my implementation, since I'm only doing a data-plane, it's not my =
problem. Let the control plane deal with that. ;-)

- in a wired network, where routing is done to the edge, with a physical =
interface to each host then data-link layer events would suffice.
- on 802.11 you could be tightly integrated with AP / WLC

If we were to do this at L3, we would need some sort of keepalive =
messages.
Thinking aloud here, any time where a host requires state to be =
maintained in the network, we are much better off if we put the burden =
of maintaining that state and ensuring the state is in the first-hop =
router on the host. E.g. like you did with the ARO option.

Cheers,
Ole

--Apple-Mail=_4282AA4E-DEA8-472C-A8A4-925C0B0244D2
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+/bDNdvtpYqJhC33YFAloJDhUACgkQvtpYqJhC
33ZdEBAAlT20T45elkx7C4Kcnz5CW/Jy4/KuamaCAZDJFSMATuGjtozvxdpfbBcr
pM0q9Iz1P1TAvsT+uPMSPCFVVPIv1OJ6vJ2hCVOzxIVih4LU3tpKkRsUVWKKqCLN
hQEJgIwjHm1ZpPJsWYX6R4RCV2JZZlG5XFoVN6L9w6xhRvtuMLeDVrv1AqAqCAEd
7p0WcHYc2w6364hIPu4DHn+QNGeAOnaPacGeEEvmLCd9KJ1zHC0gPusLGBweUCmr
k+vbGwxpCyqiPztEOdXUv3VKw5JJdnr1o3vTW59EeZ6Jh7UFPr41UPJofQG00MYN
MUOJ9i7k0eCs43dT28RMlUlrvHtkOomVRuCXKnSmUMvwwZU1XnvuPqE9pODN4ie5
+/5W05kX4mq3OKk4rwbqo0paMg3RLlwudFFCt9GLb7K3eWtpRxC+TAW/IwkZOdZu
0y1HpDTAB+bad0kr9XraiuF8Vm7o2wsfYj8LTSmK0KHh4eHFTVrJepXa96G9Nqc8
RlaRtgwxROtdAsKAdZRTGclQHCMXuB3gxvKj26DzveQ+P1Xdv1LBtWCuQbmorSaA
yve514yxvpcso3WJE7WTMYEd/Oyr3QEreNj2ZZZ83Tx+kp+lacafbURrl5PBi2OR
Vh5U4hQcjK0cCpo/ic3bsIV5cZ9nVmBaplSgZZ60pXxC0lpErJY=
=cVfa
-----END PGP SIGNATURE-----

--Apple-Mail=_4282AA4E-DEA8-472C-A8A4-925C0B0244D2--


From nobody Sun Nov 12 19:27:53 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04FFE129437 for ; Sun, 12 Nov 2017 19:27:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw1urf__7chf for ; Sun, 12 Nov 2017 19:27:36 -0800 (PST)
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 6286312941D for <6man@ietf.org>; Sun, 12 Nov 2017 19:27:26 -0800 (PST)
Received: by mail-pg0-x229.google.com with SMTP id t10so10694632pgo.3 for <6man@ietf.org>; Sun, 12 Nov 2017 19:27:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=o0/LnM3SvGU6MHZHKjRbDk6+U0g3/r/cPU4TSCqA4V8=; b=1pywWzaXEEWi98murM16plWpjQs/SRGTfQmuuUzVa7wUNZOCKS60nYTwJHBBlLoFee pLip2nD0wcNIctV5o9nhUI7xgxuxY3zY29S3xaUPI2zZafTV1o/msG7Lg6sUfjzFKu1X 3ZDJi3qzGL+3IxICF41NMUWsq2GCtwDMpKlKLxqDPTdVgbUEUJTJPDaqwawrIYLuVTeR GOEYGBGFgK/HLPK8NGqg7zfIK2PzMUX7M7CReFGF8H0SyQ7LYh0xcjZQOI5pnecI+v5b MyZtuTjuShhqx98rvaNXs7WizG0tQpf0jScEV/eMyLpNBbIx3wb+XD0QQX7L19+PzTmo Ef7Q==
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=o0/LnM3SvGU6MHZHKjRbDk6+U0g3/r/cPU4TSCqA4V8=; b=jKSWuXpxLGqhrbIPjg+djwyTZajCFB91anklPlgNdaQAEmeXfQoQ3ZC6n18joPBdrR FxcxeM7JfaCjmKiIYFkcH0ix98+GXXAr0rRFcY/ROONcpe2k8vR+wWcqwAJPliQynL0u VlKdSUQngslfATDfk+vVaX5+D6u/PzwEy/XxaJAj6UslygHU7CnEGi5O0eEH+O/8LbVP qqh/DeI8bKsqAs9NMErhBv4naSBazF1aMR2n9gNK9pp8enKYAMTX1XfGP6gWS1tg7loU hWRvXXZ50N+zGOZsD8w83X8iE3SHyOWlEe5TYUc5R4xHjFzMAXR9w/QPfcvYFW/D1uVU DUKQ==
X-Gm-Message-State: AJaThX7Y788Pb/JBASC094LQ1XFAUmY3GLkXVprA85U1oelvhdeSLZb/ ZaVjjCjn7EylH4CR48zO9sES/A==
X-Google-Smtp-Source: AGs4zMY+jhdClldqtESP085sf7etqxE9hXeVw/rMAQmiTYND4TC/dRSwdI+CjSC4Q8GWSrqFucoTFg==
X-Received: by 10.159.195.7 with SMTP id bd7mr7771912plb.43.1510543645942; Sun, 12 Nov 2017 19:27:25 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:344f:2622:bc20:2ef? ([2001:67c:370:1998:344f:2622:bc20:2ef]) by smtp.gmail.com with ESMTPSA id 81sm30151164pfh.145.2017.11.12.19.27.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 19:27:25 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_968C01F7-FDF5-4831-B723-638D97A8ADF5"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 11:27:22 +0800
In-Reply-To: 
Cc: Bob Hinden , Fernando Gont ,  "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 03:27:39 -0000

--Apple-Mail=_968C01F7-FDF5-4831-B723-638D97A8ADF5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 13, 2017, at 11:06 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) =
 wrote:
> The session state mechanics is considered out of scope for this =
particular v6ops document. It can be done in many many ways=E2=80=A6 and =
the across reboots can be done in many ways also, depending on the =
capabilities of the router and the backend OSS system. Its out of scope.

Sure, I get that, but the document doesn't say what the required =
behavior is.   I don't think that should be out of scope.   This is =
somewhat exacerbated by the proposed update to the privacy =
considerations section as a result of Alissa's DISCUSS.



--Apple-Mail=_968C01F7-FDF5-4831-B723-638D97A8ADF5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 13, 2017, at 11:06 AM, Van De Velde, Gunter (Nokia - =
BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:
The session state mechanics is considered out of scope for =
this particular v6ops document. It can be done in many many ways=E2=80=A6 =
and the across reboots can be done in many ways also, depending on the =
capabilities of the router and the backend OSS system. Its out of =
scope.

Sure, I get =
that, but the document doesn't say what the required behavior is.   =
I don't think that should be out of scope.   This is somewhat =
exacerbated by the proposed update to the privacy considerations section =
as a result of Alissa's DISCUSS.


=

--Apple-Mail=_968C01F7-FDF5-4831-B723-638D97A8ADF5--


From nobody Sun Nov 12 19:32:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873BE126DCA for ; Sun, 12 Nov 2017 19:32:35 -0800 (PST)
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 0YNaFjMa55SQ for ; Sun, 12 Nov 2017 19:32:33 -0800 (PST)
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 A933E126E64 for ; Sun, 12 Nov 2017 19:32:33 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id k191so3965036ywe.1 for ; Sun, 12 Nov 2017 19:32:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2JlD0LdPUFMoCpv97Kzyqd3bAaJRc/0kvJYTy2twZYg=; b=KrdyovwwD0oexH+4pGu/ELTyyYBdtlo1XddoKenp7NNx3TubpaD/miLSuuTiqvXVms wBVzqzg3wLMpVRMuUqIsqWggqTPgcvQxCg4IKF5e/aptWbV83PPlcGK/HOPnn173uctR S143VYSOLI7v81MFwPrOhUCwtPDG+jWM2mmt9WBkx2QQnvDEsCGqBT16Aqw+vV611K4u Wssh7RV4+TeEpfBEUjaKotjj601xdJ+nd0EDYzYM7IEtMx6R50lWTqX59unpTDt97uBN 28S+Yry3Cydz1s4mtBXooAyNDeY5CuGOi/B6Y/O1a0vvOCXEX5M2Bc5NQ1sw/KbE7e5/ exXA==
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=2JlD0LdPUFMoCpv97Kzyqd3bAaJRc/0kvJYTy2twZYg=; b=kKpm8kVagZtuKn8o0lkExg+aRBvvKAoVOGZ+qjc+4XLyP2R36hHNKgVAsJqn+lNgCC tyajK+Um6MDo84TwgxDUbAHJdIbNNQMTNbh1Cnsb4BBoLDbWPWQyPvnWcsgpN424bFfZ ZZQ4FXGZUXgzFsy38hpo/VCRPxuafBzBhVmiDrqEIamTo/tAg8R1vTR/pHAiRYPKfq1U otd1zshIZANAJf5FKJS1qo7M7XES6KsVKvqyAg05giGMOm2J0vDvXPyMIY+D0EXMsB8s oa+n+4muFUVcDxZIEFA180nW5M53gsXrwISHGrUgjw8AW2dQrwFlizXUAG+FZWloAES6 Mmnw==
X-Gm-Message-State: AJaThX43srbOSyIJyvurAZW4g8u5Tcw2YlprcJdZiVVYbaVusjOvuWty T+ZeuuCaUR4NPhppPPujg+nImFfRX2jN7l/y9VI=
X-Google-Smtp-Source: AGs4zMa5Qu4r0uuki/BqZkQ36WBXpB4P1tsuTLsHVBPpDDuZckrS2qw5L1TaYHDY6yS9wuTSHAx1iAJOnXNEN8k+Yw8=
X-Received: by 10.13.192.69 with SMTP id b66mr5112108ywd.336.1510543952910; Sun, 12 Nov 2017 19:32:32 -0800 (PST)
MIME-Version: 1.0
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>
In-Reply-To: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>
From: Ca By 
Date: Mon, 13 Nov 2017 03:32:22 +0000
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: 6man WG 
Content-Type: multipart/alternative; boundary="001a114edf34bb21ff055dd4eba7"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 03:32:35 -0000

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

On Sun, Nov 12, 2017 at 6:51 PM Ole Troan  wrote:

> At the hackathon there was quite a bit of testing of IPv6 only hosts with
> access to the IPv4 network via a NAT64.
>
> While many applications work well on a classic IPv6 only host, there are a
> few things required to make all applications work.
>
> - Must be able to do NAT64 prefix discovery (RFC6052)
> - Synthesise IPv6 address from an IPv4 literal (RFC7050)
>
> This is to be able to deal with IPv4 address literals. Which are common in
> protocols like SIP/ICE/STUN.
> These can be implemented directly in applications, or it can be
> implemented in the host stack (although application might still have to
> change).
>
> - Should do local DNS64 to support DNSSEC (RFC6147)(if you do validation).
>
> A DNS64 service in the network looks like a man in the middle attack, so
> to support DNSSEC, validation should happen before synthesizing, and must
> be done on the host itself.
>
> If this is the direction we want to go. Encourage IPv6 only host
> deployments (as opposed to dual stack hosts), are these requirements we'd
> like to add to the IPv6 node requirements document? Somewhere else?
>

I am not optimistic on the demand / need / value of dnssec in any scenario
....let alone an ipv6-only host validating an ipv4-only dns name. If the
folks operating this service cared, they could operate the server with
signed v6 names.  It is more reasonable in todays internet to asked the
server (lets assume most signed name scenarios are servers) to be setup
right (with v6). There is not a compelling reason why having v6 is
unattainable today for named nodes.

With 20 years of experience with ipsec as an ipv6 node requirement, i think
it is safe to say the IETF foisting requirents into the network layer has
caused more confusion (ipv6 is more secure because everything has ipsec!)
and hacks (ospfv3 ...) than actual true security benefit.



> Best regards,
> Ole
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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



On Sun, Nov 12, 2017 =
at 6:51 PM Ole Troan <otroan@emp=
loyees.org> wrote:
At the h=
ackathon there was quite a bit of testing of IPv6 only hosts with access to=
 the IPv4 network via a NAT64.



While many applications work well on a classic IPv6 only host, there are a =
few things required to make all applications work.



- Must be able to do NAT64 prefix discovery (RFC6052)

- Synthesise IPv6 address from an IPv4 literal (RFC7050)



This is to be able to deal with IPv4 address literals. Which are common in =
protocols like SIP/ICE/STUN.

These can be implemented directly in applications, or it can be implemented=
 in the host stack (although application might still have to change).



- Should do local DNS64 to support DNSSEC (RFC6147)(if you do validation).<=
br>


A DNS64 service in the network looks like a man in the middle attack, so to=
 support DNSSEC, validation should happen before synthesizing, and must be =
done on the host itself.



If this is the direction we want to go. Encourage IPv6 only host deployment=
s (as opposed to dual stack hosts), are these requirements we'd like to=
 add to the IPv6 node requirements document? Somewhere else?



I am not optimis=
tic on the demand / need / value of dnssec in any scenario ....let alone an=
 ipv6-only host validating an ipv4-only dns name. If the folks operating th=
is service cared, they could operate the server with signed v6 names.=C2=A0=
 It is more reasonable in todays internet to asked the server (lets assume =
most signed name scenarios are servers) to be setup right (with v6). There =
is not a compelling reason why having v6 is unattainable today for named no=
des. =C2=A0

With 20 year=
s of experience with ipsec as an ipv6 node requirement, i think it is safe =
to say the IETF foisting requirents into the network layer has caused more =
confusion (ipv6 is more secure because everything has ipsec!) and hacks (os=
pfv3 ...) than actual true security benefit.=C2=A0
<=
br>



Best regards,

Ole





--------------------------------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/list=
info/ipv6

--------------------------------------------------------------------




--001a114edf34bb21ff055dd4eba7--


From nobody Sun Nov 12 19:58:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F74A129445 for ; Sun, 12 Nov 2017 19:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 s9h5nFxn00vO for ; Sun, 12 Nov 2017 19:58:51 -0800 (PST)
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 0F712126DCA for ; Sun, 12 Nov 2017 19:58:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510545528; x=1511150328; 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=7i3v3uB9yT2pZ8zK08NhYs3u3 BURbU9ntfYl5W4E9wo=; b=orLxcXxFM9XBqZG5+Q+AQhywcYyDtrkbCBm+tnqsf WCcgWuYfkG6lhPwB8roT8uKeFNWH9n3Fr9QzNrmXMZgDTdjK6By40BKAVLhRUeln SR4i0kcOScFubpxYRn7ELwTqsdeKezey9LUBSYcWJPETsoFW/xYXYeHK/+v3koV4 Bg=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=C64aFtQJvx7IMU9LWRKx745LLQO8qXeu/uoTiRztrhtdyzP2Aw7lxdF6UXuD YVPof/b9/P5wXY8gNNg/jIQiNsoDxlHXJhUP1wEobA+nJpGEuezRuPxvu jgQmA4Uh6L5OCj3BQy7mLxcuWa4z9i1rYqX+7GwYi578iyz0eVVw0I=;
X-MDAV-Processed: mail.consulintel.es, Mon, 13 Nov 2017 04:58:48 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 13 Nov 2017 04:58:47 +0100
Received: from [172.20.60.10] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005622213.msg for ; Mon, 13 Nov 2017 04:58:47 +0100
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:171113:md50005622213::V9+qtilAkUZXl/fZ:00000VzP
X-Return-Path: prvs=149031125e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Mon, 13 Nov 2017 11:58:22 +0800
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 6man WG 
Message-ID: 
Thread-Topic: IPv6 only host NAT64 requirements?
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>
In-Reply-To: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 03:58:53 -0000

Hi Ole,

I was also thinking on this yesterday after the hackathon and I thing from =
that talk it is obvious that I will support that.

Also thought about this:

Could the =E2=80=9CIPv6 node requirements document=E2=80=9D include also a =
consideration for the same you mention here, in case there is IPv4-only in =
a dual-stack LAN with IPv6-only access?

I=E2=80=99m almost sure that this is out of the scope of the 6man charter, =
but I also feel that this is somehow our job =E2=80=A6 alternatively what i=
s the correct place to do that? May be a new sunset4 document? Or int-area?=
 The point here is an IPv4-only host being used in a network using IPv6-onl=
y for the access ...

Regards,
Jordi
=20

-----Mensaje original-----
De: ipv6  en nombre de Ole Troan 
Responder a: 
Fecha: lunes, 13 de noviembre de 2017, 11:46
Para: 6man WG 
Asunto: IPv6 only host NAT64 requirements?

    At the hackathon there was quite a bit of testing of IPv6 only hosts wi=
th access to the IPv4 network via a NAT64.
   =20
    While many applications work well on a classic IPv6 only host, there ar=
e a few things required to make all applications work.
   =20
    - Must be able to do NAT64 prefix discovery (RFC6052)
    - Synthesise IPv6 address from an IPv4 literal (RFC7050)
   =20
    This is to be able to deal with IPv4 address literals. Which are common=
 in protocols like SIP/ICE/STUN.
    These can be implemented directly in applications, or it can be impleme=
nted in the host stack (although application might still have to change).
   =20
    - Should do local DNS64 to support DNSSEC (RFC6147)=E2=80=A8(if you do =
validation).
   =20
    A DNS64 service in the network looks like a man in the middle attack, s=
o to support DNSSEC, validation should happen before synthesizing, and must=
 be done on the host itself.
   =20
    If this is the direction we want to go. Encourage IPv6 only host deploy=
ments (as opposed to dual stack hosts), are these requirements we'd like to=
 add to the IPv6 node requirements document? Somewhere else?
   =20
    Best regards,
    Ole
   =20
   =20
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
   =20



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

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




From nobody Sun Nov 12 20:38:20 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7996124B0A; Sun, 12 Nov 2017 20:38:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 c-xoroPaKi4h; Sun, 12 Nov 2017 20:38:10 -0800 (PST)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA941270A7; Sun, 12 Nov 2017 20:38:09 -0800 (PST)
Received: by mail-pf0-x244.google.com with SMTP id q4so2893519pfg.13; Sun, 12 Nov 2017 20:38:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vqWepG3+a1KmPnlEmvxLtazIHUJWLyfUcMsxaDAtsA4=; b=Ef7oCNQ5QxjTWuWS6GgOTf4o1XwjSJGN57IVzRgDfm6gowmke+Y5kXjQiDJA4kGSAT sOK3MDFlCnXaBFF4I+Aycr6TKuIWpdiVWcouBEhWX7wVmyfb0CBDmIEA5QefJtodALK4 xuErYwP4qIwg4YmigZfp946As9Auq23xrKdMvwckVyBhjeh7qHAzqwHv2xrofpAFAhxP j4WxUDky5WDgbZuycqTiK5lbiNYRLGTuX/uYuzcslDfLgaa+RZFxiW3JvPcyfmfTY1RC fJ803xaxUHFuczB5TzLoUEkBnZRmH32CNnqXJplky0u40Zm3hOTJJs37tGmdp5QECBkf GshQ==
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=vqWepG3+a1KmPnlEmvxLtazIHUJWLyfUcMsxaDAtsA4=; b=TmCqipiHItzAw4Nf9T879LPB8uA0MihPzbfQvHSTuBYAji2KEmnGEXLR8EFQwIQyWs /zSlTWpToNrJ993ebI32w0+nxm79VEOU5iG1vv0o/0Rd5Z174yrOYTnx9hmYPkATPqEr qQDNP9vimt3CoCi/q6NxagSSUDC0H9KmrNMlXbtutHgmNRQdXwcO58E0MtnyAKZCl5ak uthQVMyS8EX36VmNuk6Bhr8wStkjnm2jG/TuPM8xf1DnCBenvd3vxu+2IZqMTW3dTwD5 KYrWSxateQs45Wmg+Sc6EQRSlvAuxoPPj1khe6wVGi5emrKKYaKEqY2OsAqxnuVp6Gq0 fcSA==
X-Gm-Message-State: AJaThX6V9KkfZ7eNKeBo3kUHCxp2apYKNhkbwW1y23CwOlT8T6v5sgJH QiIcUP+RZKIeFqnI3mTB6/M=
X-Google-Smtp-Source: AGs4zMaT516fJT8WJn/gFjf5q3QFjVe8L37spxG6YsbNreMkileWWWDQp+dS2ZFheciH+fzOgwqQDw==
X-Received: by 10.98.242.66 with SMTP id y2mr8595904pfl.150.1510547889298; Sun, 12 Nov 2017 20:38:09 -0800 (PST)
Received: from [100.72.33.241] ([110.70.55.186]) by smtp.gmail.com with ESMTPSA id f70sm22324908pfc.84.2017.11.12.20.38.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 20:38:08 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DaeYoung KIM 
X-Mailer: iPhone Mail (15B150)
In-Reply-To: <17184d11-ece0-38c4-3d94-af2972deb7cd@acm.org>
Date: Mon, 13 Nov 2017 13:38:05 +0900
Cc: Fernando Gont , IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , Ted Lemon , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com> <7532e311-be94-1b9e-b9f1-8b12e9d6ee79@si6networks.com>  <203d7ede-2169-4a04-e545-2eb48144eac3@si6networks.com> <0045136C-91FA-4B31-91E0-D2D44E7433AB@gmail.com> <17184d11-ece0-38c4-3d94-af2972deb7cd@acm.org>
To: Erik Nordmark 
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 04:38:12 -0000

Thanks, Erik. Well taken.

Sent from my iPhone

> On 13 Nov 2017, at 11:07, Erik Nordmark  wrote:
>=20
>> On 11/11/2017 11:54 AM, DY Kim wrote:
>> The =E2=80=98state=E2=80=99 in the wording SLAAC means that of the host, I=
 mean.
>=20
> DY,
>=20
> The history of why SLAAC has "stateless" in its name in its name doesn't m=
atch your statement.
> When SLAAC was created there was BOOTP/DHCP for IPv4, but not work had sta=
rted on what would later become DHCPv6, but such work was anticipated. The u=
se of "stateless" was to distinguish SLAAC from the case where there is a ne=
twork service (akin to DHCP) which retains state about the allocations made f=
or hosts. At that time the use of DHCPv4 for IPv4 address allocation was qui=
te new and not very robust and there was concerns about IPv6 having a hard d=
ependency on such a service.
>=20
> Also, further back in time, at the Big10 meeting of the IPng directorate w=
as the first time I heard the 128 bit address format be discussed with the i=
dea than an IPv6 address could be formed using (a) prefix(es) advertised by t=
he router and a 48 byte mac address of the host following an approach which h=
ad been used in other protocols (IPX I believe).
>=20
> The fact that as IPv6 then evolved that evolved from 48 byte MAC to 64 bit=
 IID and the IID's later became more friendly to privacy considerations does=
n't change the fact that we have never added a requirement that routers spea=
king SLAAC maintain per-host allocation information; they do maintain per-li=
nk configuration information.
>=20
>=20
> Whether the split in to stateless and stateful (aka DHCPv6) address alloca=
tion was a wise choice is something I leave as an exercise to the reader. I m=
erely offer the observation that we keep on muddling any boundaries between s=
tateless and stateful address allocation and also between address allocation=
 and host configuration.
> The resulting larger number of possible implementation and configuration c=
hoices on the host and network/router side doesn't seem helpful in facilitat=
ing interoperable protocols.
>=20
> Regards,
>   Erik
>=20
>=20
>> SLAAC don=E2=80=99t need to require the router to do anything special, ot=
her than the router=E2=80=99s usual prefix advertisement through an RA.
>> The same is true of the case wherein DHCP is used to assign addresses to h=
osts by the router.
>> How the router keeps the link prefix info in its system is an interest ne=
ither to DHCP or SLAAC, since the link prefix itself is not about address as=
signment in which DHCP and SLAAC are interested.
>> How the router keeps the link prefix(es), whether shared or unique to eac=
h hosts, is an issue of the router system implementation, not of the protoco=
ls DHCP or SLAAC.
>> Hence, the question about how the prefix(es) are stored or recovered shou=
ld be addressed to the router spec, neither to DHCP, nor to SLAAC, nor to th=
is draft, I=E2=80=99d think.
>> ---
>> DY
>>> On 11 Nov 2017, at 12:16, Fernando Gont  wrote:
>>>=20
>>> On 11/11/2017 12:13 AM, DY Kim wrote:
>>>> The host=E2=80=99s state.
>>>>=20
>>>> RFC 4862:
>>>>=20
>>>>  "This document specifies the steps a host takes in deciding how to aut=
oconfigure its interfaces in IP version 6 (IPv6).=E2=80=9D
>>>>=20
>>>>  "The stateless mechanism allows a host to generate its own addresses u=
sing a combination of locally available information and information advertis=
ed by routers."
>>>=20
>>> Host state, maintained at the router?
>>>=20
>>>=20
>>> --=20
>>> Fernando Gont
>>> SI6 Networks
>>> e-mail: fgont@si6networks.com
>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>=20


From nobody Sun Nov 12 21:50:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF0B129478; Sun, 12 Nov 2017 21:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 oprL18inJqBJ; Sun, 12 Nov 2017 21:50:02 -0800 (PST)
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 006CC127599; Sun, 12 Nov 2017 21:50:01 -0800 (PST)
Received: by mail-it0-x234.google.com with SMTP id f187so8002023itb.1; Sun, 12 Nov 2017 21:50:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mGSHCHyc5YYpiPx2zpW/MBlwTG5vgyVWMkcQzbpYd40=; b=tFSH/i9hnuN9arhJgmrgzFuJsh7iuM+oOO0JBPlp84XrdvHpxMiVrgpNtSFfevevBr FJfydXOD7O4wbNo5S6fKBPSfnClenAKRsmtfzVldc6MFj7OLdkbYk8XEoa9B4VMTcf8Y XwQy3DFkAC+04Jxiufuv99B0GT8Ka1I9RbFvU6c0TjifK+ngGyC+zSAoySG28dTauCX1 E4feapYLLQrmgHkmAaxOJtctDz7v/fBC5SSaCeiLmq1ji6oyvG2/5fEFY9CD+3nZFFRR L+oM3zc+mPspioh6ccApBSysoAc8oWlkNshbekuTLjD3QNv2a3xn5s9V0wfDZaRDpbgr A60Q==
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=mGSHCHyc5YYpiPx2zpW/MBlwTG5vgyVWMkcQzbpYd40=; b=pZ8S4wh9RGwDYgozzF9oVxaS+dY9oPmOP4MAbaQyxleM62CiFjbdzw3eWRRFmROZ5t bvMCgNQ0E/0XLbA2OZy9E6H7K279JbZD0rJ7Zq9lv8pI5naZBLBXlnuGfplMAjXM3GYH OYMkmLEq1m51pgxmQaVpobh+nWPra/W+KgqcSDsG+nhjTLQ6Dnz2B559mvdCOj/x0yoI UQOg+pnlxcqkdvAW8iQ7UTuvaMpksUtS6wCBQBVEuv4GnRWg7/tSdLZwqkWCTXwQfw0M 6RqfrHypxTUYa6K1sdTehWBtToTjrxByTEPy5Z85pDH516k/0t25dhx9UExQWC3RWJCF vdOQ==
X-Gm-Message-State: AJaThX4lJ0e2SE4nYtuzAwfE8TKgHk8Fl1tHUV07GoOznzoiJkfp1aGP 3nHpqZlpPl/2qoG8wCC5AcDyviU4
X-Google-Smtp-Source: AGs4zMYAVAJkt8oNumRU/iL5aeadaaOda6VxLePQLyH0GnPjqSj53knAP4B/3MKZ9Cw2N/xTI1uowQ==
X-Received: by 10.36.79.22 with SMTP id c22mr9957122itb.102.1510552201304; Sun, 12 Nov 2017 21:50:01 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id u140sm3708052itc.41.2017.11.12.21.49.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 21:50:00 -0800 (PST)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Erik Nordmark , DY Kim , Fernando Gont 
Cc: IPv6 Operations , "6man@ietf.org" <6man@ietf.org>, "6man-ads@tools.ietf.org" <6man-ads@ietf.org>, "v6ops-ads@ietf.org" , draft-ietf-v6ops-unique-ipv6-prefix-per-host@tools.ietf.org
References:    <37b58331-ecfc-aaf8-bde4-91dd4d375834@si6networks.com> <029B5A33-0C3F-4021-BA86-50E6DF37F879@gmail.com> <59F47233-62ED-489D-9421-00128C8E7EB2@fugue.com> <7532e311-be94-1b9e-b9f1-8b12e9d6ee79@si6networks.com>  <203d7ede-2169-4a04-e545-2eb48144eac3@si6networks.com> <0045136C-91FA-4B31-91E0-D2D44E7433AB@gmail.com> <17184d11-ece0-38c4-3d94-af2972deb7cd@acm.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <9d74c4ed-1297-5743-5a3a-e549e9d04eb5@gmail.com>
Date: Mon, 13 Nov 2017 18:49:58 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <17184d11-ece0-38c4-3d94-af2972deb7cd@acm.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 05:50:04 -0000

On 13/11/2017 15:07, Erik Nordmark wrote:
> On 11/11/2017 11:54 AM, DY Kim wrote:
>> The =E2=80=98state=E2=80=99 in the wording SLAAC means that of the hos=
t, I mean.
>=20
> DY,
>=20
> The history of why SLAAC has "stateless" in its name in its name doesn'=
t=20
> match your statement.
> When SLAAC was created there was BOOTP/DHCP for IPv4,=20

To be 100% historically accurate, DHCP was defined but definitely
unproven; the vast majority of sites were still configuring host
IP addresses by hand. The commercial alternatives such as Netware
were all better than IP in that respect, and SLAAC looked like
a great leap forward.

   Brian

> but not work had=20
> started on what would later become DHCPv6, but such work was=20
> anticipated. The use of "stateless" was to distinguish SLAAC from the=20
> case where there is a network service (akin to DHCP) which retains stat=
e=20
> about the allocations made for hosts. At that time the use of DHCPv4 fo=
r=20
> IPv4 address allocation was quite new and not very robust and there was=
=20
> concerns about IPv6 having a hard dependency on such a service.
>=20
> Also, further back in time, at the Big10 meeting of the IPng directorat=
e=20
> was the first time I heard the 128 bit address format be discussed with=
=20
> the idea than an IPv6 address could be formed using (a) prefix(es)=20
> advertised by the router and a 48 byte mac address of the host followin=
g=20
> an approach which had been used in other protocols (IPX I believe).
>=20
> The fact that as IPv6 then evolved that evolved from 48 byte MAC to 64 =

> bit IID and the IID's later became more friendly to privacy=20
> considerations doesn't change the fact that we have never added a=20
> requirement that routers speaking SLAAC maintain per-host allocation=20
> information; they do maintain per-link configuration information.
>=20
>=20
> Whether the split in to stateless and stateful (aka DHCPv6) address=20
> allocation was a wise choice is something I leave as an exercise to the=
=20
> reader. I merely offer the observation that we keep on muddling any=20
> boundaries between stateless and stateful address allocation and also=20
> between address allocation and host configuration.
> The resulting larger number of possible implementation and configuratio=
n=20
> choices on the host and network/router side doesn't seem helpful in=20
> facilitating interoperable protocols.
>=20
> Regards,
>     Erik
>=20
>=20
>>
>> SLAAC don=E2=80=99t need to require the router to do anything special,=
 other than the router=E2=80=99s usual prefix advertisement through an RA=
=2E
>>
>> The same is true of the case wherein DHCP is used to assign addresses =
to hosts by the router.
>>
>> How the router keeps the link prefix info in its system is an interest=
 neither to DHCP or SLAAC, since the link prefix itself is not about addr=
ess assignment in which DHCP and SLAAC are interested.
>>
>> How the router keeps the link prefix(es), whether shared or unique to =
each hosts, is an issue of the router system implementation, not of the p=
rotocols DHCP or SLAAC.
>>
>> Hence, the question about how the prefix(es) are stored or recovered s=
hould be addressed to the router spec, neither to DHCP, nor to SLAAC, nor=
 to this draft, I=E2=80=99d think.
>>
>> ---
>> DY
>>
>>> On 11 Nov 2017, at 12:16, Fernando Gont  wrote=
:
>>>
>>> On 11/11/2017 12:13 AM, DY Kim wrote:
>>>> The host=E2=80=99s state.
>>>>
>>>> RFC 4862:
>>>>
>>>>   "This document specifies the steps a host takes in deciding how to=
 autoconfigure its interfaces in IP version 6 (IPv6).=E2=80=9D
>>>>
>>>>   "The stateless mechanism allows a host to generate its own address=
es using a combination of locally available information and information a=
dvertised by routers."
>>>
>>> Host state, maintained at the router?
>>>
>>>
>>> --=20
>>> Fernando Gont
>>> SI6 Networks
>>> e-mail: fgont@si6networks.com
>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>=20


From nobody Sun Nov 12 21:50:25 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C6712949D for ; Sun, 12 Nov 2017 21:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A0OgJRO9rGY for ; Sun, 12 Nov 2017 21:50:21 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5BB4128B4E for ; Sun, 12 Nov 2017 21:50:15 -0800 (PST)
Received: from h.hanazo.no (nat64-4f.meeting.ietf.org [31.130.238.79]) (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 46B862D50CE; Mon, 13 Nov 2017 05:50:15 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 7340D200BF03D0; Mon, 13 Nov 2017 13:49:48 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_8C7E207F-D256-40D8-8694-57F9F34FDFE1"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 13 Nov 2017 13:49:47 +0800
In-Reply-To: 
Cc: 6man WG 
To: Jordi Palet Martinez 
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 05:50:23 -0000

--Apple-Mail=_8C7E207F-D256-40D8-8694-57F9F34FDFE1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Jordi,

> I was also thinking on this yesterday after the hackathon and I thing =
from that talk it is obvious that I will support that.

Thanks.

>=20
> Also thought about this:
>=20
> Could the =E2=80=9CIPv6 node requirements document=E2=80=9D include =
also a consideration for the same you mention here, in case there is =
IPv4-only in a dual-stack LAN with IPv6-only access?

Not sure I understand what dual stack LAN with IPv6 only access means.
If it is dual-stack, I'd assume you also have IPV4 routing.

> I=E2=80=99m almost sure that this is out of the scope of the 6man =
charter, but I also feel that this is somehow our job =E2=80=A6 =
alternatively what is the correct place to do that? May be a new sunset4 =
document? Or int-area? The point here is an IPv4-only host being used in =
a network using IPv6-only for the access ...

If you are talking about the reverse problem, an IPv4 only host =
requiring access to the IPv6 Internet.
Or an isolated IPv4 only host in an IPv6 only network... I'd think that =
would be better suited for sunset4.

Cheers,
Ole

--Apple-Mail=_8C7E207F-D256-40D8-8694-57F9F34FDFE1
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+/bDNdvtpYqJhC33YFAloJMnsACgkQvtpYqJhC
33aIng//eE8KFUYzyUMFodKYvDRx4iGPoakYrN4Q+67iPxYv13oKHUuWPKhdGU57
1vMtOyjZlitOn2HbhAuchQxWAA57mMUNTyDpDLGMWCe39vH7V0fnKbIGc1zP7ZUR
ZYLxbTgH1ZjrUzJxFPHC017OJSRu19ZasJyuKxGy2zg0StNRf6hvAptRYBfQAOra
JlXVXEsp/KaG2rW/mWkpAAFnxo31XdiI+5R7ayK9UCO05W/Ls/Jwg6y4HE1b4GJT
8t9YGFFJt+VazIiLsLLR7wZhZVI8LBUMCwQtS0Q122gtLDkNvZ4xnIRLgNXHicfH
GbJbGeP62dPyk1275sHU3+EjxqNel087HBvncutFViuevveUbmRjHS1KSX8+XmNC
hXv+TV6REsgESlIZxugpsyNlPXiLpHPDtanaWfgmyRI176PxsPZR3LPaIOiJnLbE
4XpP2Dy5u+zAHJ7J5+/rQNuNlQyei8cTsVeqGEzlt4Fp25d2cHKDwfFYJfrh2Cqr
f+EMUsnSukv7DQMgRaMk1Fra85V7ic6C/+eU7/BaTFgcHEi2x/w0PFBCMVFbKBiK
D1bFSroNnyOT7vjYh6C3qeVeAEaqSy0eHkKxixTd/eHRWAfPqoSUgKAInXBpqR7t
OdcPCsE884xTIP0AVShQt5WqWVfq0v1l12jxqSBRujj9p3ixVoU=
=XKsh
-----END PGP SIGNATURE-----

--Apple-Mail=_8C7E207F-D256-40D8-8694-57F9F34FDFE1--


From nobody Sun Nov 12 22:25:00 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78A0129471; Sun, 12 Nov 2017 22:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 OQWX4IF6GZhI; Sun, 12 Nov 2017 22:24:58 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9033F12946F; Sun, 12 Nov 2017 22:24:58 -0800 (PST)
Received: from [31.133.137.43] (dhcp-892b.meeting.ietf.org [31.133.137.43]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vAD6OnX1001057 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 12 Nov 2017 22:24:50 -0800
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ole Troan , Erik Nordmark 
Cc: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" , Joe Touch 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org> <581AF3E8-00D9-4EBD-A98A-2D5867010980@employees.org>
From: Erik Nordmark 
Message-ID: <2a4d3627-77b8-f1b0-9d49-344ff2ea83fe@acm.org>
Date: Mon, 13 Nov 2017 14:24:47 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <581AF3E8-00D9-4EBD-A98A-2D5867010980@employees.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVYsYCMrugIgQGivyPfprIAON8OUXetjpfVAGEt6zN2FX+Gj8+LViwA/XR5pQi2OKYUvi+8t9YQuLhENYQ37aZxu
X-Sonic-ID: C;+GulWTvI5xG9d4lQ3iMJ6w== M;Og+mWjvI5xG9d4lQ3iMJ6w==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 06:25:00 -0000

Ole,

> Right, and it might be a case of "it depends".
> Interesting question though, would be benefit from an L3 solution to this problem?
> 
> In my implementation, since I'm only doing a data-plane, it's not my problem. Let the control plane deal with that. ;-)

Has this or is this being deployed?

Seems like some solution would be needed to avoid running out of prefixes.


> - in a wired network, where routing is done to the edge, with a physical interface to each host then data-link layer events would suffice.
> - on 802.11 you could be tightly integrated with AP / WLC

Yes, I can see how one can use loss of the link/association to trigger 
this in some cases. But even in those cases/topologies if the host 
looses the link and reconnects it isn't necessarily going to redo the RS 
hence you can't tell whether it is still there or not.

> 
> If we were to do this at L3, we would need some sort of keepalive messages.
> Thinking aloud here, any time where a host requires state to be maintained in the network, we are much better off if we put the burden of maintaining that state and ensuring the state is in the first-hop router on the host. E.g. like you did with the ARO option.

Yeah that soft state approach has been shown to be useful in other 
protocols. In this particular case it would require the hosts to send 
some form of "refresh" packet, which could be a unicast RS or anything 
else we'd like.


    Erik


From nobody Sun Nov 12 23:52:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E209127444; Sun, 12 Nov 2017 23:52:25 -0800 (PST)
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 ANFBEl_zd5YA; Sun, 12 Nov 2017 23:52:23 -0800 (PST)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 B793212008A; Sun, 12 Nov 2017 23:52:23 -0800 (PST)
Received: by mail-ua0-x229.google.com with SMTP id f14so653812uaa.5; Sun, 12 Nov 2017 23:52:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WomaFTl1YSLdlPLZ47ilUoNxZG6TBGX/tgHYKNB/l+M=; b=aRKG084SihH9PvUdx99/770I/albuFP8NUNXVD5iDdDif0JWKbcOh95Tp1sQEHQmGC czXYYERSE6Vz2N1+Sz0UxlRa4k2m+0efpNqrk2MAjAyP/9bugjmNG/IAg6Dy/QBtcPNf FdrJOy5uFkzs/FQ36u9VRw5Z8ieYxd5/Bw0RGVtjCQApu3I75Q7XTLgmcSiVlfAlUIJu 5JNHmN51/Fy9pkiZtSlsEJiFRCLH22iUHzCqJC8F3pRlKN8H4dEiq12HJO4h1+yDan/o 7OnQDScH1nP5GuMF79AdqTsC1Pd46EaOlHWhg+fGQPGeREGMj5RutGJYlzrBg+nXcOQy qcbQ==
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=WomaFTl1YSLdlPLZ47ilUoNxZG6TBGX/tgHYKNB/l+M=; b=RuaQYUV1DPiHGEMaTpu8mg7Ia0JF8ZUhSjB+ZR8dSTaofoD9ncPaSyOlF/6c6es0Sp +1xahIzJRWXv9pMriycICk9gMMnE3sbHmLbtQpGItrPApeuvytqZGhZYJ3yl6EeInPbh 91310aCSr7IKCI6H+jOebOzm5RWPmgh4bQo8kxqLXHfLqIhwzi5/wXxAlsPoR3sWuFix Gh89PxgERFGgWV4EUJfB68Du+AvLWTLx1GRPHLdgBWQtRHRz8kiECv7hbIXwKUEUnXwO /oG0Tpj9is6gxkvO3cnDWq9QvTVRWd/TGrpFLeoZpHovPyae+TBoiI0JnqudrcNX7r5A tcrg==
X-Gm-Message-State: AJaThX7WbIHc4zk/appRS4UimrFQeuSlVutZii7f+T+QtvEXERTgAY8G RV9Oni0DBAQeGn/FBm13kd69DMcXj8x14YDeq+k=
X-Google-Smtp-Source: AGs4zMYppDBrEAkwIBz1GuYs6y8uV+z4pIFyGH3DKQM+6U4EqfNQ1aL2j6UbRAVobn7MJz4QvyUoSSHNE0CYLgXo05g=
X-Received: by 10.176.71.226 with SMTP id w34mr7787686uac.33.1510559542695; Sun, 12 Nov 2017 23:52:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.52.221 with HTTP; Sun, 12 Nov 2017 23:52:21 -0800 (PST)
Received: by 10.159.52.221 with HTTP; Sun, 12 Nov 2017 23:52:21 -0800 (PST)
In-Reply-To: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org> 
From: Mark Smith 
Date: Mon, 13 Nov 2017 18:52:21 +1100
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
Cc: Erik Nordmark , Ole Troan ,  Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="f40304379198f45a5d055dd88c01"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 07:52:25 -0000

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

On 13 Nov. 2017 14:08, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <
gunter.van_de_velde@nokia.com> wrote:

The session state management procedures out of scope of this document. This
is scope creep.


I don't think it is.

It's a fantasy that routers don't fail, or that a single router on a link
is always enough.

Host connections are supposed to survive transient failures such router
reloads or switching to a different router that provides equivalent packet
forwarding service. If a host loses its prefix in this scenario because of
either of those events, then I don't think this method as currently
described is robust against a foreseeable failure.

I don't think it is a Best current practice if router redundancy hasn't
been considered or tested and deployed, and can therefore be documented. I
see value in the approach because of SLAAC compatibility with hosts however
I think it is currently half baked.

Regards,
Mark.


G/

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Erik Nordmark
Sent: Monday, November 13, 2017 11:05
To: Ole Troan ; Fernando Gont 
Cc: v6ops@ietf.org WG ; 6man@ietf.org
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-
prefix-per-host)

On 11/13/2017 10:42 AM, Ole Troan wrote:

> Or do as I do in my implementation.
> Model each host as being on it's own point to point interface.
> Configure the IPv6 prefix on that interface. That configured state is
exactly like what we have in classic SLAAC.

Ole,

did you figure out how to expire those allocated prefixes when the host is
long gone from the network?

The draft seems to be silent on that issue and if the purpose is to
document some current practice it would be good to capture that.

    Erik

_______________________________________________
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

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




On 13 Nov. 2017 14:08, "Van De Velde, Gunter (Nokia - BE/Ant=
werp)" <gunter.van_de_velde@nokia.com> wrote:
The session state man=
agement procedures out of scope of this document. This is scope creep.
<=
/blockquote>

I don't think it is.

It's a fantasy that routers don't fail, or that a single router o=
n a link is always enough.

Host connections are supposed to survive transient failures such router =
reloads or switching to a different router that provides equivalent packet =
forwarding service. If a host loses its prefix in this scenario because of =
either of those events, then I don't think this method as currently des=
cribed is robust against a foreseeable failure.

=

I don't think it is a Best current practice if =
router redundancy hasn't been considered or tested and deployed, and ca=
n therefore be documented. I see value in the approach because of SLAAC com=
patibility with hosts however I think it is currently half baked.

Regards,
M=
ark.




G/




-----Original Message-----

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Erik Nordmark

Sent: Monday, November 13, 2017 11:05

To: Ole Troan <otroan@employees.org>; Fernando Gont <fgont@si6networks.com>

Cc: v6ops@ietf.org =
WG <v6ops@ietf.org>; 6man@ietf.org

Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-pref=
ix-per-host)




On 11/13/2017 10:42 =
AM, Ole Troan wrote:



> Or do as I do in my implementation.

> Model each host as being on it's own point to point interface.

> Configure the IPv6 prefix on that interface. That configured state is =
exactly like what we have in classic SLAAC.



Ole,



did you figure out how to expire those allocated prefixes when the host is =
long gone from the network?



The draft seems to be silent on that issue and if the purpose is to documen=
t some current practice it would be good to capture that.



=C2=A0 =C2=A0 Erik



_______________________________________________

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





--f40304379198f45a5d055dd88c01--


From nobody Mon Nov 13 00:01:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9CC126B6E for ; Mon, 13 Nov 2017 00:01:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Ftva-KiWR3ib for ; Mon, 13 Nov 2017 00:01:17 -0800 (PST)
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 9F96A1294D8 for <6man@ietf.org>; Mon, 13 Nov 2017 00:00:58 -0800 (PST)
Received: by mail-it0-x232.google.com with SMTP id y15so8346414ita.4 for <6man@ietf.org>; Mon, 13 Nov 2017 00:00:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EO3jfBYbmc87G0vKD38O3ges7rSyJEsjGmBOov9lryQ=; b=CtcQP9nygnlj+JxePyNrN6T577of5tWQJJtlDywiZh8XuLc56b0PCbmlpDv0sBR9d9 9hw1IKz6OptNykpLfqzrweTWlnhlvUMPbpB2o7HRMjzF9arBHVtlsWBUcNmbA8FJoBHT Qm5Xyr4t9DRUheKjyEWdMV2eGjoGpMIBdnbMQEElgQWAEPuU36lZZpnlDIhcNB0HlbrB I6nXEkGiaWQv+DkR/bRjozTqzInlXCp682FNQynceU/oczVx16KSUcROkUqOTnFWhv8e Db0xqZ1e2gntli5yAfOcbU8ezOKI16FCzsI09l666J5fvP8AZID713wGG2UoH27dRU6A J2sw==
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=EO3jfBYbmc87G0vKD38O3ges7rSyJEsjGmBOov9lryQ=; b=IsMy3GhmGddrQP59fQ9pjyLxnEHyvmBoejiZSRR1ET6qrW9hHS9NvakvF5w8GG6uRI CidRs0Dln1ePnMSAfb9J24KmHTzUPFSonZtbu/3DET5LfuIFhOur0KanKEn5Fakr2oxS u9mz15+Q4qFVfD+S0nVP3wWNvdnyueKYpuatiCzGcRuNaA2/ap/kYXY0ei+91rqudD8V Iakto0s+v47as0MXs8e/+xfP3XtAZtvds0cTCbStG8D+GRR2boQ2PiFAERu4mOnHe0Or UDCFcrq4jL/p7MQ5ywe3n+wVM9uBFybAnp/OqnhhnIylrPmMZdnpvXlSRHH/3nUcYrRS shQQ==
X-Gm-Message-State: AJaThX5Z4CJORFvwyT2r+KJg+mhl43KhJWUoiZphg8xFVcf3FLROGeoB DAptANgAN3EKsA70rs2p0SMEWH87/RVd/4d4bGhw7Q==
X-Google-Smtp-Source: AGs4zMbBVLctqavITXSPghgqHB87/dnQ0mQCxna5cij7BTkH0gasvlp1oat8UsPvb++IU1eiinlFVdeon6YghFMn9Tk=
X-Received: by 10.36.70.76 with SMTP id j73mr9459449itb.32.1510560057493; Mon, 13 Nov 2017 00:00:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Mon, 13 Nov 2017 00:00:36 -0800 (PST)
In-Reply-To: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>  
From: Lorenzo Colitti 
Date: Mon, 13 Nov 2017 17:00:36 +0900
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Mark Smith 
Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "6man@ietf.org" <6man@ietf.org>,  "v6ops@ietf.org WG" , Fernando Gont 
Content-Type: multipart/alternative; boundary="001a1144b0eca419d9055dd8ab77"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 08:01:19 -0000

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

On Mon, Nov 13, 2017 at 4:52 PM, Mark Smith  wrote:

> It's a fantasy that routers don't fail, or that a single router on a link
> is always enough.
>
> Host connections are supposed to survive transient failures such router
> reloads or switching to a different router that provides equivalent packet
> forwarding service. If a host loses its prefix in this scenario because of
> either of those events, then I don't think this method as currently
> described is robust against a foreseeable failure.
>
> I don't think it is a Best current practice if router redundancy hasn't
> been considered or tested and deployed, and can therefore be documented. I
> see value in the approach because of SLAAC compatibility with hosts however
> I think it is currently half baked.
>

Let me state this again:

   - DHCPv6 PD has exactly the same problem.
   - As far as I am aware there is no RFC that documents the solutions that
   are in use for DHCPv6 PD.
   - This has not stopped the deployment of tens or hundreds of millions of
   networks that use DHCPv6 PD.

Why are we holding this document up on this?

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


On M=
on, Nov 13, 2017 at 4:52 PM, Mark Smith <markzzzsmith@gmail.com&g=
t; wrote:
It's a fantasy that routers don't fail, or that a s=
ingle router on a link is always enough.
=

Host connections are supposed to survive transi=
ent failures such router reloads or switching to a different router that pr=
ovides equivalent packet forwarding service. If a host loses its prefix in =
this scenario because of either of those events, then I don't think thi=
s method as currently described is robust against a foreseeable failure.

I don't think it is a =
Best current practice if router redundancy hasn't been considered or te=
sted and deployed, and can therefore be documented. I see value in the appr=
oach because of SLAAC compatibility with hosts however I think it is curren=
tly half baked.

Let me state th=
is again:
  • DHCPv6 PD has exactly the same problem.
    • As far as I am aware there is no RFC that documents the solutions that are=
 in use for DHCPv6 PD.
  • This has not stopped the deployment of tens =
or hundreds of millions of networks that use DHCPv6 PD.
Why a=
re we holding this document up on this?


--001a1144b0eca419d9055dd8ab77--


From nobody Mon Nov 13 00:04:23 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31265128891 for ; Mon, 13 Nov 2017 00:04:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Vrb-8fW9y9_Q for ; Mon, 13 Nov 2017 00:04:14 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C38126C0F for <6man@ietf.org>; Mon, 13 Nov 2017 00:04:14 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id b6so11054958pff.10 for <6man@ietf.org>; Mon, 13 Nov 2017 00:04:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0Mdqg3HF55+P5TRSQW2nmn0uHMlo8WOG6wNylbJrDMA=; b=SKBz4ZWWJz6rbrH+Sx/D4V+PCiVY5h57RpCuUsqm+2PZ0f3aqmWLLnSfzK/ATZwhzk g0zbv3yhMnRDoDFMlMtSV6a2112kUrXcaB3LUWkopBTG667e+l4b35mvSQ+SlBdQ/YWe G4eOmXx4Z8m+mtsoref6B5aHxfnY0AleI6xGXP7QSQbPAsdkZrUkelsLHOxLKKVzbSO6 gUGEtv52EiycpFoa/CRDlRUAnujjtEIJNhC3nG9pj+zDRPZLCl/zkDAYvJfwdoSzFtNA /f4/eSj/85s/Ld/wJI21ksU4H9mTAuPZfjW22h2zTtM2/9LrkJqADEZYr5Fq9/3iaKDG adHA==
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=0Mdqg3HF55+P5TRSQW2nmn0uHMlo8WOG6wNylbJrDMA=; b=fa8J8XYrBprSkkM7G2+x4rFx0maucjIFomucfzLDqQpFZj7Oxz+J0r94FnCVOxVWf9 IcJgtwaPhfn0Ohg5fAZ7VC0nJmmHz04QGtr3Z3KDvTK2o17ZQ3wvW57Iu1M7Zo+fckA2 nVGSmJ1OiVbJoIr26LnRREaNAf89niJxAvcRO6wi3/091Y+A3PSqRnBvXk4bdFgrYdWx UjERC7dgh68+OPrlHM7sziEK4fs+139Vj5VUIKDgDKbtd6Rth4AodW+TfwzmVwrl6CK3 K4WjFwiyZuDK1DZzpjO+lAAZheBYb44OKsLYO3Yd3N86FghK0uD0Mj+GTAy8C49Lhjmn /0aA==
X-Gm-Message-State: AJaThX5lKdfjV2Ao2g3wbYdAMhEzC8C83OEkIsgkfwcrO/6OntDkzz/+ v49hJ1zKZ4BIBJKmOF6ta7fRfQ==
X-Google-Smtp-Source: AGs4zMac0/AWZvxIlak4xhG6cWtv3rVmW3mRHLkeHTz7gKtWzJ2qXCLMc1ENpLqsGKPyiwaL9CCkpg==
X-Received: by 10.99.143.87 with SMTP id r23mr7258951pgn.224.1510560254134; Mon, 13 Nov 2017 00:04:14 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:c9f0:3e0a:fd05:e8c4? ([2001:67c:370:1998:c9f0:3e0a:fd05:e8c4]) by smtp.gmail.com with ESMTPSA id 125sm30390217pff.14.2017.11.13.00.04.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 00:04:13 -0800 (PST)
From: Ted Lemon 
Message-Id: <68CF4FB7-FC94-41A0-A97B-F783F6DB7825@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A2E62852-3C2A-4E9E-9663-9D849EDC1CE5"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 16:04:11 +0800
In-Reply-To: 
Cc: Mark Smith , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: Lorenzo Colitti 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>   
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 08:04:17 -0000

--Apple-Mail=_A2E62852-3C2A-4E9E-9663-9D849EDC1CE5
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

On Nov 13, 2017, at 4:00 PM, Lorenzo Colitti  wrote:
> DHCPv6 PD has exactly the same problem.

DHCPv6 PD specifies a stateful mechanism for managing prefixes.


--Apple-Mail=_A2E62852-3C2A-4E9E-9663-9D849EDC1CE5
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

On Nov 13, 2017, at 4:00 PM, Lorenzo Colitti <lorenzo@google.com> wrote:
  • DHCPv6 PD has exactly the same problem.
DHCPv6 PD specifies a stateful mechanism for managing prefixes.


--Apple-Mail=_A2E62852-3C2A-4E9E-9663-9D849EDC1CE5--


From nobody Mon Nov 13 00:14:56 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7C212947D; Mon, 13 Nov 2017 00:14:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDAFDDYtJY8y; Mon, 13 Nov 2017 00:14:52 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E54F129400; Mon, 13 Nov 2017 00:14:52 -0800 (PST)
Received: from h.hanazo.no (nat64-62.meeting.ietf.org [31.130.238.98]) (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 90C552D4F99; Mon, 13 Nov 2017 08:14:51 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 47E22200BF5491; Mon, 13 Nov 2017 16:14:25 +0800 (+08)
From: Ole Troan 
Message-Id: <1C0B81F3-A57E-4928-A32F-F8BDE50FA621@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_B4517A4D-0C54-4385-8F44-BDC288BF6E1B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 16:14:24 +0800
In-Reply-To: 
Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Erik Nordmark , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
To: Mark Smith 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>  
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 08:14:54 -0000

--Apple-Mail=_B4517A4D-0C54-4385-8F44-BDC288BF6E1B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Mark,

> I don't think it is a Best current practice if router redundancy =
hasn't been considered or tested and deployed, and can therefore be =
documented. I see value in the approach because of SLAAC compatibility =
with hosts however I think it is currently half baked.

I don't understand either why the IESG thinks this should be a BCP.
But for different reasons.

Cheers,
Ole

--Apple-Mail=_B4517A4D-0C54-4385-8F44-BDC288BF6E1B
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+/bDNdvtpYqJhC33YFAloJVGAACgkQvtpYqJhC
33YhHxAAorev6/WPCx9usFb+t6DP76kLav8leESaEXRw1MRqbw6JAXgx7TTu7uBQ
e2V+Lg8mCxm0ZIdoW5Q8VAmd+HYmvPcJiWei6UvKWZnVwCk5rC+gSMWfTq0Oodb9
4QH1wPSK/ptMRX8KvQS75PePj5x48A5YIFHTtI5lTRj8gPv3GOS9YzdSDinjxzXY
CAmMafVw6f1I18ov7CkvYH8kU9PFGo6At/VAl1nFuJeCraPvoWSr72EZgqlNToQK
gBoLslYcJ135OrmuWE5TXFioZgUsVUYlP0SCf0XpT0w9EOWY3FP4nZ949WU1U+7f
zWVH6Kf0TOLqyfcL6+tipgwLhxxQkak3Sw6fTysybFXb8nJ7zYQCET0lUUDwFPR2
1foEsfhBCdlcV9AVX3p9kTrJAPyyu02ZH94I9Z58WGrZGL4IpXYN1ysuKK4P6vwJ
058nYF7NW9u+slhEsOI3L6aCIcWFTBatdEq6/iUYJ1a7Vwc6BJcHKDHnSppgsBF/
t6ihCc3QbvrLatTw3LD4lvcy3Ts7PLBp3fm4MFq/r2224+4wjLR3h22DX92yXxOe
pWOWYyFxY5Hq8pvklDnj6cHcP49mX0SnPgNVMNgLllyV+Dz+CFXX8dEuzc7pq4q+
LgP3FAHHkwLpsrevHjaSIUqFlUr7LkRMEGcnnAXOpUv7Nz40jjQ=
=ef9r
-----END PGP SIGNATURE-----

--Apple-Mail=_B4517A4D-0C54-4385-8F44-BDC288BF6E1B--


From nobody Mon Nov 13 00:17:43 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5D0124B09 for ; Mon, 13 Nov 2017 00:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3VBlf2PBsbFl for ; Mon, 13 Nov 2017 00:17:35 -0800 (PST)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDAEA128BA2 for <6man@ietf.org>; Mon, 13 Nov 2017 00:17:34 -0800 (PST)
Received: by mail-it0-x231.google.com with SMTP id m191so8419567itg.2 for <6man@ietf.org>; Mon, 13 Nov 2017 00:17:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E+QXijtITEIAx2Br9mES+YK3FtUeQgkbcYnduO4b1fs=; b=MPONQSz9OiboLftIHDqCAJjPjHoqGyRasAX63Mrs+MypwvsbM+/4KYZEHGV00LKrh5 bLMqwH/aCVWfUFugg1xedQieD2KV6dXKkANid09gUFDAG7phzCIQO2+vz/CQAAljwhZo 6aw/5x1OcOEiWWswaEXJYXGJoZ7bkHaNPm2LTNCADDYbWcOODnOXcmH6gReInQhRugCf 3RlQybVCLqeOvrqUq1Z3XLvFLcIpSsqscHnljwJpykq5QU06R/uQkqyA4dAfj4/+2Mrd SCrTOZ6zMLq0AhGSnkizgXfMXy4+D3OE2qOBR68iQNFmWI8UI/0Lz70TqPmLZi5d+Kt0 yTYg==
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=E+QXijtITEIAx2Br9mES+YK3FtUeQgkbcYnduO4b1fs=; b=n25CTbM6XgVoo0jzELeFjUGU9J9Q05o/nsE1DCMrnNZiz1HFwbxAfEo/dwB4n0ViGd k1PMTe0ezoR4yGafXwviX1dTCS9z6lh3o2+eyJnkasmc0Q96JBnwSbTzjWORwk+zAlK4 AShJO0F8f6BSc3Waadnxt2b8/jioOY65vCX4lzSJ3icB7B/fUaF8JkVPGRpSDR1jlPUR VWOST8d2KMpJat7+HLFns1urb8hnZ91/oNTGCf+m5/UA2Xpzw7O4mQw2W4sy32dSky7m 4vjCc7+r8/mX/DNZcqHa4ae2TqUElav3nx8UAZVgkGhxvM/zIw/rrlbvBEXrHW4JrbNJ WJOA==
X-Gm-Message-State: AJaThX6lKduJYl3uCPKdiXill26q3d6fwh+dN9WGj/Jnp3TP1eHkWreo AqsUe6AKdq8VYOd18DrSyBKLKz0mvh2PW8Z9TPh/mA==
X-Google-Smtp-Source: AGs4zMYxEnKt5zPgWU9tGK8MMhzlBakAuPFtI2eOnmoYhw0Ol1BW9aOxKnk0LznUGRYVjABjFigcTDfkt/bXrhGM5E0=
X-Received: by 10.36.26.206 with SMTP id 197mr9512991iti.88.1510561053869; Mon, 13 Nov 2017 00:17:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Mon, 13 Nov 2017 00:17:12 -0800 (PST)
In-Reply-To: <68CF4FB7-FC94-41A0-A97B-F783F6DB7825@fugue.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>    <68CF4FB7-FC94-41A0-A97B-F783F6DB7825@fugue.com>
From: Lorenzo Colitti 
Date: Mon, 13 Nov 2017 17:17:12 +0900
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ted Lemon 
Cc: Mark Smith , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>,  "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
Content-Type: multipart/alternative; boundary="001a114457ec07b282055dd8e77f"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 08:17:37 -0000

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

On Mon, Nov 13, 2017 at 5:04 PM, Ted Lemon  wrote:

> On Nov 13, 2017, at 4:00 PM, Lorenzo Colitti  wrote:
>
>
>    - DHCPv6 PD has exactly the same problem.
>
> DHCPv6 PD specifies a stateful mechanism for managing prefixes.
>

And it does not specify how those prefixes are pushed to routers between
the requesting router and the DHCPv6 server. But in the real world, that is
a hard requirement for things to work, since in the real world, the DHCPv6
server is almost never in the client's first-hop router.

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


On M=
on, Nov 13, 2017 at 5:04 PM, Ted Lemon <mellon@fugue.com> wro=
te:
<=
span class=3D"">On Nov 13, 2017, at 4:00 PM, Lorenzo Colitti <lorenzo@google.com> wr=
ote:
  • DHCPv6 PD has exactly the same p=
roblem.
DHCPv6 PD specifies a=
 stateful mechanism for managing prefixes.
And it does not specify how those prefixes are pushed to router=
s between the requesting router and the DHCPv6 server. But in the real worl=
d, that is a hard requirement for things to work, since in the real world, =
the DHCPv6 server is almost never in the client's first-hop router.


--001a114457ec07b282055dd8e77f--


From nobody Mon Nov 13 00:20:58 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E381294EF; Mon, 13 Nov 2017 00:20:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JYattYCq_KWN; Mon, 13 Nov 2017 00:20:43 -0800 (PST)
Received: from mx1.ernw.net (mx1.ernw.net [IPv6:2003:60:4010:10a0::11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A09D1294E8; Mon, 13 Nov 2017 00:20:42 -0800 (PST)
Received: from mail1.ernw.net (unknown [IPv6:fd00:2001:0:d001::30]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail1.ernw.net", Issuer "ernw ca1" (verified OK)) by mx1.ernw.net (Postfix) with ESMTPS id A395C27365; Mon, 13 Nov 2017 09:20:40 +0100 (CET)
Received: from ws26.ernw.net (unknown [172.31.1.70]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ws26.ernw.net", Issuer "ernw ca1" (verified OK)) by mail1.ernw.net (Postfix) with ESMTPS id 8227F632DC0; Mon, 13 Nov 2017 09:20:40 +0100 (CET)
Received: by ws26.ernw.net (Postfix, from userid 1002) id 5F15D39993; Mon, 13 Nov 2017 09:20:40 +0100 (CET)
Date: Mon, 13 Nov 2017 09:20:40 +0100
From: Enno Rey 
To: Lorenzo Colitti 
Cc: Ted Lemon , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Message-ID: <20171113082040.GF35038@ernw.de>
References: <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>    <68CF4FB7-FC94-41A0-A97B-F783F6DB7825@fugue.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 08:20:46 -0000

Hi,

On Mon, Nov 13, 2017 at 05:17:12PM +0900, Lorenzo Colitti wrote:
> On Mon, Nov 13, 2017 at 5:04 PM, Ted Lemon  wrote:
> 
> > On Nov 13, 2017, at 4:00 PM, Lorenzo Colitti  wrote:
> >
> >
> >    - DHCPv6 PD has exactly the same problem.
> >
> > DHCPv6 PD specifies a stateful mechanism for managing prefixes.
> >
> 
> And it does not specify how those prefixes are pushed to routers between
> the requesting router and the DHCPv6 server. But in the real world, that is
> a hard requirement for things to work, since in the real world, the DHCPv6
> server is almost never in the client's first-hop router.

I didn't follow the full thread but wasn't it supposed to discuss SLAAC (somewhat becoming SFAAC) and not DHCPv6?

thanks

Enno





> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Matthias Luft, Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================


From nobody Mon Nov 13 00:25:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706181294B8 for ; Mon, 13 Nov 2017 00:25:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TR9JyqkfunRH for ; Mon, 13 Nov 2017 00:25:11 -0800 (PST)
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 6E27D12947D for <6man@ietf.org>; Mon, 13 Nov 2017 00:25:11 -0800 (PST)
Received: by mail-pg0-x229.google.com with SMTP id y5so12148895pgq.7 for <6man@ietf.org>; Mon, 13 Nov 2017 00:25:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bdQEonyen0uzL+Q5GuJiI31SEejAK311vxI/nlY+I6s=; b=R9jPBxzjcAt2iIuYUbx0B1oT9VHJk5TiFgtIMa8Z5ci1rU8b09wZvNUCgvfRRinlQI bv8wix47HYQIMOThC1l7jjX7qjrH+ZA/YLWm3xmI5rEv1mOfh4I/wfYsGZTsCG2doDGi 7otkcEdUuub+F+f68pftob0lA+VaYm6zKDiTr+rOlgCPLrZ/dNtZODpRyg9GofUnbIqy ujhChTyxRhaZVQGVAW23VstOvm6fZjSLrvQ7DBkzw2J314F5AVXfCdB2FDY1hTMEtKa/ PA8Q7JJ9pp/YplazsSclkBK1/rcyo7N/bP+01zRVv68YalbVJaxbb9IbKaCtBrFuWZJc pHow==
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=bdQEonyen0uzL+Q5GuJiI31SEejAK311vxI/nlY+I6s=; b=d331AqjKp4sDg79OMcpHqZGgQdbKLjcxHiTQOu/6WGFKYRogM6Nhazj2eTZpvL8/xb J9hRsP4yO8vS4OKNSmpcUP0PFB1kg+BfjeoWlTsoIdVI7VC2KvWO0PDc9YxYbAefzidk EGcgpZ0Jz+e4fmmMFzjyRA1AU6/MoU26SiQZ/aqAdUxYAXJRAZAd2ioyPM5HfAqYSx92 xX8Koyz9ku2+GUKb7rUuPc2U5RN6dq8lG6hUKmQC7RLuebaIOlUSBdvOEnzzctKZIPXc drZJuHQMOxsNEmPo9227IghS7UqO0bJSEe39GLEyLv4efRxgjOg3ymm9x8w+ENkiMpAq XxmQ==
X-Gm-Message-State: AJaThX6KCG8fPGhlw1Kod2K+rRhBjs/33Om6fGrEaTOjnnI4Pzfh+Q99 Tf8czY0LrOXMawuvVmF0lbqVSNm3SFE=
X-Google-Smtp-Source: AGs4zMbbSXDmbNWBqjybRgD+k+9WkquTes+446lb6kVzaGUFwFhBo46LV0UWUfIAEFO91I0z5vw5QA==
X-Received: by 10.99.105.71 with SMTP id e68mr7909608pgc.55.1510561510778; Mon, 13 Nov 2017 00:25:10 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:c9f0:3e0a:fd05:e8c4? ([2001:67c:370:1998:c9f0:3e0a:fd05:e8c4]) by smtp.gmail.com with ESMTPSA id e18sm30312332pfi.57.2017.11.13.00.25.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 00:25:10 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_1BF087C6-C219-4024-B368-649A5978D356"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 16:25:06 +0800
In-Reply-To: 
Cc: Mark Smith , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: Lorenzo Colitti 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>    <68CF4FB7-FC94-41A0-A97B-F783F6DB7825@fugue.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 08:25:12 -0000

--Apple-Mail=_1BF087C6-C219-4024-B368-649A5978D356
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 13, 2017, at 4:17 PM, Lorenzo Colitti  wrote:
> And it does not specify how those prefixes are pushed to routers =
between the requesting router and the DHCPv6 server. But in the real =
world, that is a hard requirement for things to work, since in the real =
world, the DHCPv6 server is almost never in the client's first-hop =
router.

That's the problem that leasequery solves.


--Apple-Mail=_1BF087C6-C219-4024-B368-649A5978D356
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 13, 2017, at 4:17 PM, Lorenzo Colitti <lorenzo@google.com> =
wrote:
And it does not specify how =
those prefixes are pushed to routers between the requesting router and =
the DHCPv6 server. But in the real world, that is a hard requirement for =
things to work, since in the real world, the DHCPv6 server is almost =
never in the client's first-hop =
router.

That's the problem that leasequery solves.

=

--Apple-Mail=_1BF087C6-C219-4024-B368-649A5978D356--


From nobody Mon Nov 13 00:30:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71F8126B6E; Mon, 13 Nov 2017 00:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2U1w8BoZxJxw; Mon, 13 Nov 2017 00:30:31 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94505129503; Mon, 13 Nov 2017 00:30:31 -0800 (PST)
Received: from h.hanazo.no (nat64-62.meeting.ietf.org [31.130.238.98]) (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 47DE32D4F99; Mon, 13 Nov 2017 08:30:31 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 22902200BF67AB; Mon, 13 Nov 2017 16:30:05 +0800 (+08)
From: Ole Troan 
Message-Id: <907BA572-3C7E-4395-A097-A73EE01D7A05@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_0292986B-30BC-4E21-8877-F27605DF1238"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 16:30:04 +0800
In-Reply-To: 
Cc: Lorenzo Colitti , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: Ted Lemon 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>    <68CF4FB7-FC94-41A0-A97B-F783F6DB7825@fugue.com>  
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 08:30:41 -0000

--Apple-Mail=_0292986B-30BC-4E21-8877-F27605DF1238
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Ted,

>> And it does not specify how those prefixes are pushed to routers =
between the requesting router and the DHCPv6 server. But in the real =
world, that is a hard requirement for things to work, since in the real =
world, the DHCPv6 server is almost never in the client's first-hop =
router.
>=20
> That's the problem that leasequery solves.

Well, we've really never specified how route injection should work on =
relays in PD.
RFC3633 does only specify the mechanism where the RR and DR are directly =
connected.

Cheers,
Ole

--Apple-Mail=_0292986B-30BC-4E21-8877-F27605DF1238
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+/bDNdvtpYqJhC33YFAloJWAwACgkQvtpYqJhC
33ZT2A//Wu3c9nY50Rhb0ExDq+sh/hBzq1Mc3zetgFiIbWsBLvTF0xPUOpX3SdTq
kXzfF2TEEPWmy9cVQXPiUd7M9rGSo42GGfeVq5m5kaBCTaXI/lEI66Clx9uUObVR
0S7/oPTTgxMLggsPAKB0UxpXxqZvqBKaUlojx5UkWdiI4oNI7vkjnf1qlUX9jzDS
JZxbLonSWCtdmvY24dUitHOPfrCdwHZM++5tkHvmkpZVHp+L5DB3w6kRQ7di60EX
4hDNBdxTz7WD1LVVqDWCwuaEOnI7JWSkPhjZl1FmGkOmQ04WwEEjBSaKUkh9jj2v
Az6axJRtWn6pqYiTWntaI+o5gziLcz2JaBEzzVHvm6MI2r2S7CFRvmfsuDVplhOU
iUG8WHacbFmfehuyWX0RkgCNGWCgn2GCqAJPeSSUd+uiIVbWlj2MPdySc6JWoJOM
cULcPCwhnTKxKbLGwPyRCf2OswnDfmB1QqK6fONhua2pe2kM6cFuHtsmdnXikrxm
rmcLidIaP90WY6BMof8FonfTiMISOPUZGLyEh4hEtYEHJejWQA1uTzN4s6YTfJFB
hzvV+KxEOrzYtGkFs4XT+qkY4tFGhimYUTI7j8vw8thdkGCFRvsIItu+cD120kf+
ARYlXWFCv8/HhqeHn91f3gNEohlV5Hgc7Xl82EnvzVXIIqOj8PY=
=WooY
-----END PGP SIGNATURE-----

--Apple-Mail=_0292986B-30BC-4E21-8877-F27605DF1238--


From nobody Mon Nov 13 02:00:02 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8831294FF; Mon, 13 Nov 2017 02:00:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OnfbBZEduT5c; Mon, 13 Nov 2017 01:59:59 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA0E31294E7; Mon, 13 Nov 2017 01:59:58 -0800 (PST)
Received: from [IPv6:2001:67c:370:128:c123:5f5f:9804:1669] (unknown [IPv6:2001:67c:370:128:c123:5f5f:9804:1669]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 9106280964; Mon, 13 Nov 2017 10:59:54 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ole Troan 
Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>   
From: Fernando Gont 
Message-ID: <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>
Date: Mon, 13 Nov 2017 17:21:26 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 10:00:01 -0000

On 11/13/2017 11:07 AM, Ole Troan wrote:
> Fernando,
> 
>>> Or do as I do in my implementation.
>>> Model each host as being on it's own point to point interface.
>>> Configure the IPv6 prefix on that interface. That configured state is exactly like what we have in classic SLAAC.
>>
>> The I assume that, in that case, you don't need to do anything fancy
>> with how you send the multicasted RAs, and the SLAAC router
>> implementation need not keep a table of bindings?
> 
> That's correct.

Then that's okay from the pov of slaac specification. The I-D in
question could focus on what it wants to achieve and, if anything, point
that this can be achieved with DHCPv6-PD, but there are also products
that achieve the same thing via "virtualization + slaac" (or something
along these lines). And the protocol-specific details from Section 4
(how you send the RAs, etc.) can and should be removed.

Question: is the motivation of this "mechanism" to stick to SLAAC,
because Android does not support DHCPv6?



> The interfaces look like:
> interface P2P-Ethernet0 remote-mac aa:bb:cc:dd:ee:ff
>  ipv6 address 2001:db8::1/64
> 
> Think of it as an interface with a fixed L2 address for the remote end.
> L3 to L2 address mapping is then fixed, both for unicast and multicast.
> Should that have it's own internet draft, very possibly?

If this is somethings that is deemed as useful (I guess it is, if you
implemented it), then: definitely. The document could also discuss
details such as how you time out prefixes, etc. e.g., if a node
vanishes, for how long do you keep the lease/virtual-interface? If you
run out of prefixes, do you just ignore new RSes? Do you base the
generation of the prefix on the MAC address?  How does this work, given
n prefix bits to play with, in the presence of nodes that vanish, nodes
that randomize MAC addresses, etc. Is this expected to work across
crash&reboot events? What's expected to happen in the presence of such
events?

I'm sure you made decisions on all of these things when you implemented
this...and that's stuff is certainly useful. Not only to understand how
this works, but also for folks that might want to implement this on
their own.



> In the vein of all problems in computer science can be solved with another layer of redirection.
> How these interfaces are created and how they are maintained across reboots etc, can be considered out of scope for the SLAAC feature.

If the implementation approach is as you've described, this is outside
of the SLAAC specification, indeed (nobody can prevent you from spawning
instances of SLAAC that behave according to the existing standards).
>From a operational point of view, one would wonder why pursue this path
as opposed to e.g. do DHCPv6 -- even if that means: we want to support
Android, and Android does not support DHCPv6. And also if this is a best
current practice, or just one possible deployment strategy ("you should
do this" vs "we have done this").

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





From nobody Mon Nov 13 02:01:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4801294E7 for ; Mon, 13 Nov 2017 02:01:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo76mEoT7rtg for ; Mon, 13 Nov 2017 02:01:26 -0800 (PST)
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 94DAF126CB6 for <6man@ietf.org>; Mon, 13 Nov 2017 02:01:26 -0800 (PST)
Received: by mail-pg0-x235.google.com with SMTP id z184so6908614pgd.13 for <6man@ietf.org>; Mon, 13 Nov 2017 02:01:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+1qm3Qhut41nQu43vwJUvQueKAjrH/PHLXepUjhjiZ0=; b=XhCBX3+YLchKmNnN4TVc+3kj1cSS6RXehbqa8txbxuUF5fgqdZecmUXAnsVqV9xDT5 lEdhLSDXVK1Dc7qIl3q7xoRs3zJpvryWZBQEnts/ZZ0Y5uV9Tj7SokrrrxzC91x/Snhr bzISSETIq+WFgSfqwVXHAsJ3w08zzKx8zUb3F+xOxltlEtLG+V87tuEpzkGdaLKoIsrh J6npKxSgBq2hR3Cw88XMfaMERJLTEMJXxwYEnoIMPVA2nGgRK78LyjvAVXZZPBe/ieNw X14eAQY/32msRT4kN5C3MmA5tEmqv/zga5A1LoVfIWY5eSfXRcOovP/T12aUfsTIyIiB JXew==
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=+1qm3Qhut41nQu43vwJUvQueKAjrH/PHLXepUjhjiZ0=; b=hCc5PXrg2iGEDKNz1b1dN8gIxPCAYXKPSMUiwyM9OkJUrECsuhTRHnR9wHeb/pAOMg nYH2QFZD1GZRZPOaO020xAVnXbVZZXP1zO9X2oBEkx6xRHF1b94A+3F4QUfej8kNEWqU hiKtZHGHXQ6TElvwAireWVvjWWlvpuEqWZkdourDLMVb0gUkLokkOEMRsKCrnGN1S7Ms yDoLt2fJC8e62x8IveamBsvl8mcM5QVPBENV2mDikgPB/LmWr+ZGt8EDS1a6yWmms/YP X0Noxi0De0S/CsJDjeu6rOcbp0TKx+webMB7SmuOIVqUIU4IzavSOm1+VHtv1kalQkMk rfgQ==
X-Gm-Message-State: AJaThX5H/dPnRoxIEUoAFInk2quX1GiWGsNLfa23MVBWpZOidjWcaHuJ mGKEfpcwhhn7JZPW+I1CPWbD1g==
X-Google-Smtp-Source: AGs4zMZx/saI88z7zOZgqXfZOjRbXMatUdqpQxMlfXK9ZQC7DujNVWeHMKun4Yl9jFDogO9hW7t1Yg==
X-Received: by 10.84.241.65 with SMTP id u1mr1861152plm.28.1510567286149; Mon, 13 Nov 2017 02:01:26 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:5915:f8e5:8fc6:2415? ([2001:67c:1232:144:5915:f8e5:8fc6:2415]) by smtp.gmail.com with ESMTPSA id q8sm35360258pfk.100.2017.11.13.02.01.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 02:01:25 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_A249E2A1-3DC1-4081-96A3-743E41678CB3"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 18:01:22 +0800
In-Reply-To: <907BA572-3C7E-4395-A097-A73EE01D7A05@employees.org>
Cc: Lorenzo Colitti , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: Ole Troan 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>    <68CF4FB7-FC94-41A0-A97B-F783F6DB7825@fugue.com>   <907BA572-3C7E-4395-A097-A73EE01D7A05@employees.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 10:01:28 -0000

--Apple-Mail=_A249E2A1-3DC1-4081-96A3-743E41678CB3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 13, 2017, at 4:30 PM, Ole Troan  wrote:
> Well, we've really never specified how route injection should work on =
relays in PD.
> RFC3633 does only specify the mechanism where the RR and DR are =
directly connected.

While true, this isn't the same sort of problem.   We have specified how =
state is retained, and the information is available both when the =
assignment occurs and thereafter, using leasequery.   It would be nice =
if it were explicitly said somewhere "snoop in the packet as it goes by, =
use leasequery to recover state," but routers do that anyway, and there =
isn't an interop problem because there aren't multiple ways to do it.


--Apple-Mail=_A249E2A1-3DC1-4081-96A3-743E41678CB3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 13, 2017, at 4:30 PM, Ole Troan <otroan@employees.org> wrote:
Well, we've really never specified how =
route injection should work on relays in PD.
RFC3633 does only specify the mechanism where =
the RR and DR are directly connected.

While =
true, this isn't the same sort of problem.   We have specified how =
state is retained, and the information is available both when the =
assignment occurs and thereafter, using leasequery.   It would be =
nice if it were explicitly said somewhere "snoop in the packet as it =
goes by, use leasequery to recover state," but routers do that anyway, =
and there isn't an interop problem because there aren't multiple ways to =
do it.

=

--Apple-Mail=_A249E2A1-3DC1-4081-96A3-743E41678CB3--


From nobody Mon Nov 13 03:14:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E041A1294B3 for ; Mon, 13 Nov 2017 03:14:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 jimFOvHYFnSG for ; Mon, 13 Nov 2017 03:14:31 -0800 (PST)
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 640C21293D8 for <6man@ietf.org>; Mon, 13 Nov 2017 03:14:31 -0800 (PST)
Received: by mail-it0-x22c.google.com with SMTP id 72so8952396itl.5 for <6man@ietf.org>; Mon, 13 Nov 2017 03:14:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h5aIEhngWM+Y5ZZ8Y07e6XfRMfLMlpFO0okx8jLBcNk=; b=vDJEGOlgHBYdn+hPzTFDitupaW0pWAefOaDa39CZpSD6ru2MhvDlQOphZde0NQwgs6 qj9w59LF3rN3h01mCJ65EF3WaDo2iV+7g0xNrdK48vN7BiCvXKW/RlYP+qWOosLrcubW yPuUPtdmPqDeTbWfrrymveWXM+Vi8Sn2w8R5+oIg9dpC13k2xHS8zagpj5z7//VrBvDZ V+VHb7g/+rjdYklhrAoOCWVaBNb2opxiKvlK52V1JW7ahFQkeohk8YkHDMhcC5g9NCjN 0jDrNhXVe4kzx1h+IYpuqNymHO6KNF0LSub8IRyYOjAGLsQmmps8AAVMrSBwcuTEgffS KUcA==
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=h5aIEhngWM+Y5ZZ8Y07e6XfRMfLMlpFO0okx8jLBcNk=; b=tzPrQRH2h3Pu3wAepqOFlBhT4m5X1puN0t1uz3/YkZ49X24v9b830zAEL4Cq20uG+g G21wHN9EZqW3PMxu0eae4wvoxl97mqaa/awI7oU/fARax5gnT/vTGzpFtQh3qjcF6PB6 CXDTNZxfIc3RYL98LsCmU1PDNmh2KP4+7+XVZEyjJIHdjfH9b2d50OLHTnNgV+xntLdZ Td8L2AnMCrs9sPFwjt1jc8N4NUXF91iLe07UACH5UUqXDkG0sA8nTlN1jUY1bS+b4JsN rxhivhcYOJHLNtCZOnaZJRAbYuR8ibibhxbjZJtcU00OAfmTQBcGciGWFMv8m0Om6HgR odEg==
X-Gm-Message-State: AJaThX4Er+bugwLj4xGaNAq6QWW8BZVraICZaMfc33HgeJQW6QcmqmKE jWV9+wUA+t10onRimxJ8XUzznCEsBuMV65RagZkbbAyl
X-Google-Smtp-Source: AGs4zMbdDYdMQiahQh8VzYs+jeH2G/uXWV0bnQGW8ANKLw2Ss2Dm5jyD3wAuTvM4KRNHiFPKtdV2tGHjoxWAf3eeLTw=
X-Received: by 10.36.74.83 with SMTP id k80mr9012811itb.133.1510571670368; Mon, 13 Nov 2017 03:14:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Mon, 13 Nov 2017 03:14:09 -0800 (PST)
In-Reply-To: <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>
From: Lorenzo Colitti 
Date: Mon, 13 Nov 2017 20:14:09 +0900
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: Ole Troan , "v6ops@ietf.org WG" ,  "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="001a1145e92ad273fe055ddb5f84"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 11:14:33 -0000

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

On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont 
wrote:

> >From a operational point of view, one would wonder why pursue this path
> as opposed to e.g. do DHCPv6
>

As for DHCPv6 specifically, one reason is that DHCPv6-only networks are not
recommended by the IETF. RFC 7934.

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


On M=
on, Nov 13, 2017 at 6:21 PM, Fernando Gont <fgont@si6networks.com&=
gt; wrote:
>From a operational =
point of view, one would wonder why pursue this path

as opposed to e.g. do DHCPv6

As for DHC=
Pv6 specifically, one reason is that DHCPv6-only networks are not recommend=
ed by the IETF. RFC 7934.


--001a1145e92ad273fe055ddb5f84--


From nobody Mon Nov 13 04:55:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CAC12954C; Mon, 13 Nov 2017 04:55:53 -0800 (PST)
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 ar_AR0sDIXF0; Mon, 13 Nov 2017 04:55:52 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A55B51292F4; Mon, 13 Nov 2017 04:55:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3547; q=dns/txt; s=iport; t=1510577751; x=1511787351; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=j1Tn0l1hFSYDAGb8a1hS78aC7y0QDKgHgzkSO+UsgBg=; b=BtkIDR8HctcBz8z6D4apeLijXxy203nHoTJS09c6oyNO2vKJd5rkTuuW 0m0VqJVMA5Qrftqs2qT/+nrmTtIJ2300N+9jJ87Er4Z58jYcL5my9zY0o ro+05oboEW/KB73t2So/dsURJgIaWhDkfU5w5XX2zpXCPHzLFjGV6xM9+ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CxAAC+lQla/5tdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM1ZG4ng36KH48pgX2RCIVIgTIDXAoYAQqFGAIahD4/GAEBAQE?= =?us-ascii?q?BAQEBAWsohR8BAQEDAQEhSwsQAgEIBBQnAwICAiULFBECBA4FiT5kEKtlgieLB?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgzSCB4NngwGILDGCMgWKLZd9ApUCk0K?= =?us-ascii?q?VdwIRGQGBOAEfOE+BI3oVSS0BgjaEX3eIYQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,389,1505779200";  d="scan'208,217";a="309552277"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2017 12:55:50 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vADCtobb030487 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2017 12:55:50 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 13 Nov 2017 06:55:49 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1320.000; Mon, 13 Nov 2017 06:55:49 -0600
From: "Bernie Volz (volz)" 
To: Lorenzo Colitti 
CC: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Topic: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Index: AQHTV0P9T2sJAG849Uu+HS5e9rBDPKMRm9v1gABoPYCAAAQrAIAABQoAgAABs4CAAGicAIAAH36A//+31Ns=
Date: Mon, 13 Nov 2017 12:55:49 +0000
Message-ID: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_D96CCF2BBDB3409CAC4D2EF23D92021Aciscocom_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 12:55:54 -0000

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

VGhhbmtzIHRvIHlvdSBhcyBvbmUgb2YgdGhlIGF1dGhvcnMuDQoNCi0gQmVybmllIChmcm9tIGlQ
aG9uZSkNCg0KT24gTm92IDEzLCAyMDE3LCBhdCA3OjE0IFBNLCBMb3JlbnpvIENvbGl0dGkgPGxv
cmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29nbGUuY29tPj4gd3JvdGU6DQoNCk9u
IE1vbiwgTm92IDEzLCAyMDE3IGF0IDY6MjEgUE0sIEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5l
dHdvcmtzLmNvbTxtYWlsdG86ZmdvbnRAc2k2bmV0d29ya3MuY29tPj4gd3JvdGU6DQo+RnJvbSBh
IG9wZXJhdGlvbmFsIHBvaW50IG9mIHZpZXcsIG9uZSB3b3VsZCB3b25kZXIgd2h5IHB1cnN1ZSB0
aGlzIHBhdGgNCmFzIG9wcG9zZWQgdG8gZS5nLiBkbyBESENQdjYNCg0KQXMgZm9yIERIQ1B2NiBz
cGVjaWZpY2FsbHksIG9uZSByZWFzb24gaXMgdGhhdCBESENQdjYtb25seSBuZXR3b3JrcyBhcmUg
bm90IHJlY29tbWVuZGVkIGJ5IHRoZSBJRVRGLiBSRkMgNzkzNC4NCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRG
IElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlw
djZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpU
aGFua3MgdG8geW91IGFzIG9uZSBvZiB0aGUgYXV0aG9ycy48YnI+DQo8YnI+DQo8ZGl2IGlkPSJB
cHBsZU1haWxTaWduYXR1cmUiPi0gQmVybmllIChmcm9tIGlQaG9uZSk8L2Rpdj4NCjxkaXY+PGJy
Pg0KT24gTm92IDEzLCAyMDE3LCBhdCA3OjE0IFBNLCBMb3JlbnpvIENvbGl0dGkgJmx0OzxhIGhy
ZWY9Im1haWx0bzpsb3JlbnpvQGdvb2dsZS5jb20iPmxvcmVuem9AZ29vZ2xlLmNvbTwvYT4mZ3Q7
IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2
Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNz
PSJnbWFpbF9xdW90ZSI+T24gTW9uLCBOb3YgMTMsIDIwMTcgYXQgNjoyMSBQTSwgRmVybmFuZG8g
R29udCA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmZnb250QHNpNm5ldHdv
cmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZnb250QHNpNm5ldHdvcmtzLmNvbTwvYT4mZ3Q7PC9z
cGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt
YXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6
MWV4Ij4NCiZndDtGcm9tIGEgb3BlcmF0aW9uYWwgcG9pbnQgb2Ygdmlldywgb25lIHdvdWxkIHdv
bmRlciB3aHkgcHVyc3VlIHRoaXMgcGF0aDxicj4NCmFzIG9wcG9zZWQgdG8gZS5nLiBkbyBESENQ
djY8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BcyBmb3IgREhD
UHY2IHNwZWNpZmljYWxseSwgb25lIHJlYXNvbiBpcyB0aGF0IERIQ1B2Ni1vbmx5IG5ldHdvcmtz
IGFyZSBub3QgcmVjb21tZW5kZWQgYnkgdGhlIElFVEYuIFJGQyA3OTM0LjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl
PSJjaXRlIj4NCjxkaXY+PHNwYW4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyPg0KPHNwYW4+SUVURiBJ
UHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9
Im1haWx0bzppcHY2QGlldGYub3JnIj5pcHY2QGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bh
bj5BZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9pcHY2Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vaXB2NjwvYT48L3NwYW4+PGJyPg0KPHNwYW4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyPg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D96CCF2BBDB3409CAC4D2EF23D92021Aciscocom_--


From nobody Mon Nov 13 05:08:26 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A104E129422 for ; Mon, 13 Nov 2017 05:08:24 -0800 (PST)
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 CVd2-nAffy3E for ; Mon, 13 Nov 2017 05:08:17 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB7D129418 for ; Mon, 13 Nov 2017 05:08:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510578495; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=4/wHorB2pGF+VbO9TR/U9bpCWfeNvjMzDoqOdQjzHcc=; b=bwxD40x1EJC5t4t8HNzJQstepkWiD22JViQlO38oe1AcVjdtw/GTMIDu8tEB/T9nHDejU6LQDfdXoJlTb7rmJimkdEopgcYcuBRXWkRYC0KxyL95KHgNnjZyUKXsQyCbmJ1uDBCtY9uKuY1skNIwt8YNQiFviQv18ovYGATZPOA=
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0215.outbound.protection.outlook.com [213.199.154.215]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-56-yEvg0xbAMoeB2Pelo6pHSQ-1; Mon, 13 Nov 2017 13:08:13 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 13:08:12 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0239.005; Mon, 13 Nov 2017 13:08:12 +0000
From: Tim Chown 
To: Ole Troan , Timothy Winters 
CC: 6man WG 
Subject: Re: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTXCpXJ0TGvGV100ygbRReFshDs6MSSJWA
Date: Mon, 13 Nov 2017 13:08:12 +0000
Message-ID: <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk>
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>
In-Reply-To: <6755862C-AA12-45B4-98B8-EF6D9F90898B@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.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:e565:a751:53f4:fd9a]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 20:rv5kydpUoikaXe5lMzEWRBg4/KCIEO7PEtuTlO0SwVoG9NzcTGK9QBDIuyWKnbH6LfxaFxuvUu9c+AUJ2zMQuXbYjVDEoKvslp8TUo/xXWlPVNJ6TwTA+rksoI3N5XSwGJKqzkOUuAenPbRPjCSW4o3doEdWiol5uk2Y5CbA9Is=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: c20e2412-6668-4847-d2e5-08d52a979836
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1137; 
x-ms-traffictypediagnostic: AM3PR07MB1137:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(278428928389397);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(3231022)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1137; 
x-forefront-prvs: 0490BBA1F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(24454002)(53546010)(966005)(81156014)(81166006)(72206003)(76176999)(36756003)(786003)(478600001)(6486002)(99286004)(7736002)(86362001)(4326008)(82746002)(106356001)(316002)(8936002)(5660300001)(83716003)(33656002)(101416001)(25786009)(105586002)(14454004)(189998001)(50986999)(8676002)(2171002)(6506006)(6246003)(3660700001)(3280700002)(6436002)(2906002)(5250100002)(110136005)(74482002)(2900100001)(229853002)(2950100002)(6116002)(68736007)(102836003)(97736004)(6512007)(6306002)(305945005)(42882006)(53936002)(50226002)(57306001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <250D07244AC2BE4191E6920EF0556412@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: c20e2412-6668-4847-d2e5-08d52a979836
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 13:08:12.4326 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137
X-MC-Unique: yEvg0xbAMoeB2Pelo6pHSQ-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:08:25 -0000

SGksDQoNCj4gT24gMTMgTm92IDIwMTcsIGF0IDAyOjUwLCBPbGUgVHJvYW4gPG90cm9hbkBlbXBs
b3llZXMub3JnPiB3cm90ZToNCj4gDQo+IEF0IHRoZSBoYWNrYXRob24gdGhlcmUgd2FzIHF1aXRl
IGEgYml0IG9mIHRlc3Rpbmcgb2YgSVB2NiBvbmx5IGhvc3RzIHdpdGggYWNjZXNzIHRvIHRoZSBJ
UHY0IG5ldHdvcmsgdmlhIGEgTkFUNjQuDQo+IA0KPiBXaGlsZSBtYW55IGFwcGxpY2F0aW9ucyB3
b3JrIHdlbGwgb24gYSBjbGFzc2ljIElQdjYgb25seSBob3N0LCB0aGVyZSBhcmUgYSBmZXcgdGhp
bmdzIHJlcXVpcmVkIHRvIG1ha2UgYWxsIGFwcGxpY2F0aW9ucyB3b3JrLg0KPiANCj4gLSBNdXN0
IGJlIGFibGUgdG8gZG8gTkFUNjQgcHJlZml4IGRpc2NvdmVyeSAoUkZDNjA1MikNCj4gLSBTeW50
aGVzaXNlIElQdjYgYWRkcmVzcyBmcm9tIGFuIElQdjQgbGl0ZXJhbCAoUkZDNzA1MCkNCj4gDQo+
IFRoaXMgaXMgdG8gYmUgYWJsZSB0byBkZWFsIHdpdGggSVB2NCBhZGRyZXNzIGxpdGVyYWxzLiBX
aGljaCBhcmUgY29tbW9uIGluIHByb3RvY29scyBsaWtlIFNJUC9JQ0UvU1RVTi4NCj4gVGhlc2Ug
Y2FuIGJlIGltcGxlbWVudGVkIGRpcmVjdGx5IGluIGFwcGxpY2F0aW9ucywgb3IgaXQgY2FuIGJl
IGltcGxlbWVudGVkIGluIHRoZSBob3N0IHN0YWNrIChhbHRob3VnaCBhcHBsaWNhdGlvbiBtaWdo
dCBzdGlsbCBoYXZlIHRvIGNoYW5nZSkuDQo+IA0KPiAtIFNob3VsZCBkbyBsb2NhbCBETlM2NCB0
byBzdXBwb3J0IEROU1NFQyAoUkZDNjE0NykNCj4gKGlmIHlvdSBkbyB2YWxpZGF0aW9uKS4NCj4g
DQo+IEEgRE5TNjQgc2VydmljZSBpbiB0aGUgbmV0d29yayBsb29rcyBsaWtlIGEgbWFuIGluIHRo
ZSBtaWRkbGUgYXR0YWNrLCBzbyB0byBzdXBwb3J0IEROU1NFQywgdmFsaWRhdGlvbiBzaG91bGQg
aGFwcGVuIGJlZm9yZSBzeW50aGVzaXppbmcsIGFuZCBtdXN0IGJlIGRvbmUgb24gdGhlIGhvc3Qg
aXRzZWxmLg0KPiANCj4gSWYgdGhpcyBpcyB0aGUgZGlyZWN0aW9uIHdlIHdhbnQgdG8gZ28uIEVu
Y291cmFnZSBJUHY2IG9ubHkgaG9zdCBkZXBsb3ltZW50cyAoYXMgb3Bwb3NlZCB0byBkdWFsIHN0
YWNrIGhvc3RzKSwgYXJlIHRoZXNlIHJlcXVpcmVtZW50cyB3ZSdkIGxpa2UgdG8gYWRkIHRvIHRo
ZSBJUHY2IG5vZGUgcmVxdWlyZW1lbnRzIGRvY3VtZW50PyBTb21ld2hlcmUgZWxzZT8NCg0KZHJh
ZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyIGluY2x1ZGVzIGEgKHZlcnkgc2hvcnQpIFNlY3Rp
b24gMTAgb24gdHJhbnNpdGlvbiwgc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIjc2VjdGlvbi0xMA0KDQpJZiBzb21lb25lIHdpc2hl
cyB0byBwcm9wb3NlIHRleHQgaW4gYSBuZXcgc2VjdGlvbiAxMC4yIG9uIOKAnElQdjYtb25seeKA
nSBvcGVyYXRpb24sIHdlIGNvdWxkIGluY2x1ZGUgdGhhdCBpZiB0aGUgV0cgYWdyZWVzLiAgVGhp
cyBjb3VsZCBiZSBzb21ldGhpbmcgZm9yIFRpbVcgdG8gYWRkIGFzIGEgcXVlc3Rpb24gd2hlbiB0
aGUgZHJhZnQgaXMgcHJlc2VudGVkIGluIDZtYW4uDQoNClRpbQ==


From nobody Mon Nov 13 05:10:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66A412941D; Mon, 13 Nov 2017 05:10:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 NMLjjaRNX6yj; Mon, 13 Nov 2017 05:10:02 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD55129418; Mon, 13 Nov 2017 05:10:01 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vADC9mxp004804 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2017 12:09:48 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <5A0999A4.3040807@foobar.org>
Date: Mon, 13 Nov 2017 13:09:56 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Lorenzo Colitti 
CC: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:10:04 -0000

Lorenzo Colitti wrote:
> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont  > wrote:
> 
>     >From a operational point of view, one would wonder why pursue this path
>     as opposed to e.g. do DHCPv6
> 
> As for DHCPv6 specifically, one reason is that DHCPv6-only networks are
> not recommended by the IETF. RFC 7934.

reminder: there is no WG consensus that this is what RFC 7934 means.

Nick


From nobody Mon Nov 13 05:20:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5E5128B91; Mon, 13 Nov 2017 05:20:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vOXq-U4UtQgz; Mon, 13 Nov 2017 05:20:35 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32CC12025C; Mon, 13 Nov 2017 05:20:35 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e] (unknown [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 5154580DF7; Mon, 13 Nov 2017 14:20:32 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Lorenzo Colitti 
Cc: Ole Troan , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com> 
From: Fernando Gont 
Message-ID: <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>
Date: Mon, 13 Nov 2017 21:20:19 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:20:38 -0000

On 11/13/2017 07:14 PM, Lorenzo Colitti wrote:
> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont  > wrote:
> 
>     >From a operational point of view, one would wonder why pursue this path
>     as opposed to e.g. do DHCPv6
> 
> 
> As for DHCPv6 specifically, one reason is that DHCPv6-only networks are
> not recommended by the IETF. RFC 7934.

Yes, sorry: I meant DHCPv6-PD.

RFC7934:

    Due to the drawbacks imposed by requiring explicit requests for
    address space (see Section 4), it is RECOMMENDED that the network
    give the host the ability to use new addresses without requiring
    explicit requests.  This can be achieved either by allowing the host
    to form new addresses autonomously (e.g., via SLAAC) or by providing
    the host with a dedicated /64 prefix.  The prefix MAY be provided
    using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.

Therefore, why re-invent PD in SLAAC?


That aside, same RFC says:
    Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide
    multiple addresses when the host connects (e.g., the approximately 30
    addresses that can fit into a single packet) would accommodate
    current clients, but it sets a limit on the number of addresses
    available to hosts when they attach and therefore limits the
    development of future applications.

I seem to recall many systems limit the number of addresses per
interface to 16. So the limit of "30 per request" aleady gives you more
than what you typically get, in practice, with SLAAC. Also... is issuing
multiple requests forbidden?

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





From nobody Mon Nov 13 05:22:25 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFC3129577 for ; Mon, 13 Nov 2017 05:22:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22qf_OZt4GNk for ; Mon, 13 Nov 2017 05:22:21 -0800 (PST)
Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E3F129584 for <6man@ietf.org>; Mon, 13 Nov 2017 05:22:12 -0800 (PST)
Received: by mail-oi0-x242.google.com with SMTP id r128so11204621oig.9 for <6man@ietf.org>; Mon, 13 Nov 2017 05:22:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jozUr/WTaOOW4h2uB0Oes2FFmDXnoth01Z934RBHJCU=; b=zYtD0nkcPq+mQZ6XhmpjoDS6f+gD3WlTy2dfAqV50vVjUE87fL9ErAWr3w8HjCItmf +TBbW3dM8BEO30v0rrynRW7lBgwC7sBDGfbRUB9Bm2X7n1hOCiUTPN9KKYyMF0oHNOou EScloqYRq9RvUUWi4wkn4Zk7b7kBmKMcfD8F70HLTrBTCFpImEmmsxUEckM457iLhBV4 2qCugt3v1WQRcBWUTHu6JpQtJJ8t5jBzhm6MeRWzoMw+hOUBhooUdVO8maisFyAQS8eT QdH9+9EYnvQkQRdDdKUP8MmsiwZLXF4B7mtxqhNFBN+VYMstdQlYw5+M9D3lxncxRg0b 0U2A==
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=jozUr/WTaOOW4h2uB0Oes2FFmDXnoth01Z934RBHJCU=; b=t/84Wtr5iTzwqZUgailrDHyU7dEZPE60vgV+ffffvCjcZyGSpihO/2iZBeFBHWy6YB 1v9RslczF55lVHUdhl4Lscy66bW6A4vBcTUn7Z/sZ6saPRuyYZJHywOoVKVjH2wr7JbX qLX1HjyTrLklpKEBCHlB23F5oM3459ugGMHvjkbQDKsoKxy2p1SG7i8+DT9bDQvGDKCu pJlZJz1Lggp6n3zyjiBsvgLWjWJRcvHV+K+Y8FgFt2wfMubG+8xcYMyTCnqJ/ydtc9s4 fCyILFlMnmrAtTduagtQM36YnhjLoOLXEArqwgt19CUOJdekfqc1aaKfIhX89bbUwXfU cB8A==
X-Gm-Message-State: AJaThX7Al+xd7bQrhnNswWPmm+xvYjs7q9dbumI35guEhySBFbfjHGjU 15Gwc1KgCsZaH5eTQFT4t1Okl0cfOuBVMgzEFj5AOQ==
X-Google-Smtp-Source: AGs4zMblNJZTrEXil29aU4BIprSxJUEsKjgtBMs4Tc7HLexymhkQlgq90UswPQvfqtdl7PDq1IlOJDAwFavG0lv60p0=
X-Received: by 10.202.75.139 with SMTP id y133mr5510793oia.117.1510579331476;  Mon, 13 Nov 2017 05:22:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.13.74 with HTTP; Mon, 13 Nov 2017 05:22:10 -0800 (PST)
In-Reply-To: <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>
From: Victor Kuarsingh 
Date: Mon, 13 Nov 2017 08:22:10 -0500
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: Ole Troan , "v6ops@ietf.org WG" ,  "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:22:23 -0000

On Mon, Nov 13, 2017 at 4:21 AM, Fernando Gont  wrote:
> On 11/13/2017 11:07 AM, Ole Troan wrote:

>
> If the implementation approach is as you've described, this is outside
> of the SLAAC specification, indeed (nobody can prevent you from spawning
> instances of SLAAC that behave according to the existing standards).
> >From a operational point of view, one would wonder why pursue this path
> as opposed to e.g. do DHCPv6 -- even if that means: we want to support
> Android, and Android does not support DHCPv6.

My understanding is one of the authors is an operator and the model
represents operational experience and input on this.

regards,

Victor K


From nobody Mon Nov 13 05:27:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D80129445 for ; Mon, 13 Nov 2017 05:27:14 -0800 (PST)
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_H4=-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 YdJz_MJRVl51 for ; Mon, 13 Nov 2017 05:27:12 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86ED1243F3 for ; Mon, 13 Nov 2017 05:27:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10023; q=dns/txt; s=iport; t=1510579632; x=1511789232; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pgzNiH8LwYoNdFYIjF8LpE6Fqpdl/uqW6BqsiAkjz0Q=; b=en7owTnSk8eWkUixAfbMj43fRGrSiLmJwrzDaIMKg/QhArXBYIhYzfB8 AuaJJ917lSOXhkf2C3Hm63u5D4bavbaAfcpTeWErvmJhfx5QqZqZG7acg rnO/ebFF/WLrKapH8M9bIRvg1O/Wz6jtFlSM2qkHyrxvYFpX7H2zdY11t 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAADInAla/4gNJK1bDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDNWRuJ4N+ih+PKZMFhUiCEQoYAQqFGAIahEA/GAEBAQEBAQE?= =?us-ascii?q?BAWsohR8CAQMBASFLCxACAQg/AwICAiULFBECBA4FiT5kEKtkgieLBgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFgzAEggeBVYISgwGILDGCMgWKLZd9AodpjRmTQox?= =?us-ascii?q?oiQ8CERkBgTgBHzhCgTB6FUktAYI2hCA/d4YiLIIWAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,389,1505779200";  d="scan'208,217";a="323597088"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2017 13:27:11 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vADDRBfK024364 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2017 13:27:11 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 13 Nov 2017 07:27:11 -0600
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; Mon, 13 Nov 2017 07:27:11 -0600
From: "Rajiv Asati (rajiva)" 
To: Tim Chown 
CC: Ole Troan , Timothy Winters ,  6man WG 
Subject: Re: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTXCpRAMcG+a5XKUyB+nmCuhf8DKMSrSsA//+guII=
Date: Mon, 13 Nov 2017 13:27:10 +0000
Message-ID: <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com>
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>, <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk>
In-Reply-To: <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk>
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_48E765433DD443E89B505CC4D9D76A2Fciscocom_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:27:15 -0000

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

QE9sZSwgSSBhZ3JlZS4gSnVzdCBzd2FwIHRoZSBSRkMjLg0KDQotIE11c3QgYmUgYWJsZSB0byBk
byBOQVQ2NCBwcmVmaXggZGlzY292ZXJ5IChSRkM2MDUyKQ0KLSBTeW50aGVzaXNlIElQdjYgYWRk
cmVzcyBmcm9tIGFuIElQdjQgbGl0ZXJhbCAoUkZDNzA1MCkNCg0KDQpAVGltLA0KDQpJZiBzb21l
b25lIHdpc2hlcyB0byBwcm9wb3NlIHRleHQgaW4gYSBuZXcgc2VjdGlvbiAxMC4yIG9uIOKAnElQ
djYtb25seeKAnSBvcGVyYXRpb24sIHdlIGNvdWxkIGluY2x1ZGUgdGhhdCBpZiB0aGUgV0cgYWdy
ZWVzLiAgVGhpcw0KDQpJdCBtaWdodCBiZSB1c2VmdWwgdG8gaGF2ZSBzb21lIHRleHQgaW4gc2Vj
dGlvbiAxNCAodjYgcm91dGVyKSB0byBhY2NvbW1vZGF0ZSB2NCBob3N0cy9hcHBzIGluIGNhc2Ug
b2YgdjYtb25seSB1cGxpbmsvIFdBTi4NCg0KQ2hlZXJzLA0KUmFqaXYNCg0KDQpPbiBOb3YgMTMs
IDIwMTcsIGF0IDg6MDggQU0sIFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWs8bWFpbHRv
OlRpbS5DaG93bkBqaXNjLmFjLnVrPj4gd3JvdGU6DQoNCkhpLA0KDQpPbiAxMyBOb3YgMjAxNywg
YXQgMDI6NTAsIE9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc8bWFpbHRvOm90cm9hbkBl
bXBsb3llZXMub3JnPj4gd3JvdGU6DQoNCkF0IHRoZSBoYWNrYXRob24gdGhlcmUgd2FzIHF1aXRl
IGEgYml0IG9mIHRlc3Rpbmcgb2YgSVB2NiBvbmx5IGhvc3RzIHdpdGggYWNjZXNzIHRvIHRoZSBJ
UHY0IG5ldHdvcmsgdmlhIGEgTkFUNjQuDQoNCldoaWxlIG1hbnkgYXBwbGljYXRpb25zIHdvcmsg
d2VsbCBvbiBhIGNsYXNzaWMgSVB2NiBvbmx5IGhvc3QsIHRoZXJlIGFyZSBhIGZldyB0aGluZ3Mg
cmVxdWlyZWQgdG8gbWFrZSBhbGwgYXBwbGljYXRpb25zIHdvcmsuDQoNCi0gTXVzdCBiZSBhYmxl
IHRvIGRvIE5BVDY0IHByZWZpeCBkaXNjb3ZlcnkgKFJGQzYwNTIpDQotIFN5bnRoZXNpc2UgSVB2
NiBhZGRyZXNzIGZyb20gYW4gSVB2NCBsaXRlcmFsIChSRkM3MDUwKQ0KDQpUaGlzIGlzIHRvIGJl
IGFibGUgdG8gZGVhbCB3aXRoIElQdjQgYWRkcmVzcyBsaXRlcmFscy4gV2hpY2ggYXJlIGNvbW1v
biBpbiBwcm90b2NvbHMgbGlrZSBTSVAvSUNFL1NUVU4uDQpUaGVzZSBjYW4gYmUgaW1wbGVtZW50
ZWQgZGlyZWN0bHkgaW4gYXBwbGljYXRpb25zLCBvciBpdCBjYW4gYmUgaW1wbGVtZW50ZWQgaW4g
dGhlIGhvc3Qgc3RhY2sgKGFsdGhvdWdoIGFwcGxpY2F0aW9uIG1pZ2h0IHN0aWxsIGhhdmUgdG8g
Y2hhbmdlKS4NCg0KLSBTaG91bGQgZG8gbG9jYWwgRE5TNjQgdG8gc3VwcG9ydCBETlNTRUMgKFJG
QzYxNDcpDQooaWYgeW91IGRvIHZhbGlkYXRpb24pLg0KDQpBIEROUzY0IHNlcnZpY2UgaW4gdGhl
IG5ldHdvcmsgbG9va3MgbGlrZSBhIG1hbiBpbiB0aGUgbWlkZGxlIGF0dGFjaywgc28gdG8gc3Vw
cG9ydCBETlNTRUMsIHZhbGlkYXRpb24gc2hvdWxkIGhhcHBlbiBiZWZvcmUgc3ludGhlc2l6aW5n
LCBhbmQgbXVzdCBiZSBkb25lIG9uIHRoZSBob3N0IGl0c2VsZi4NCg0KSWYgdGhpcyBpcyB0aGUg
ZGlyZWN0aW9uIHdlIHdhbnQgdG8gZ28uIEVuY291cmFnZSBJUHY2IG9ubHkgaG9zdCBkZXBsb3lt
ZW50cyAoYXMgb3Bwb3NlZCB0byBkdWFsIHN0YWNrIGhvc3RzKSwgYXJlIHRoZXNlIHJlcXVpcmVt
ZW50cyB3ZSdkIGxpa2UgdG8gYWRkIHRvIHRoZSBJUHY2IG5vZGUgcmVxdWlyZW1lbnRzIGRvY3Vt
ZW50PyBTb21ld2hlcmUgZWxzZT8NCg0KZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlzLTAyIGlu
Y2x1ZGVzIGEgKHZlcnkgc2hvcnQpIFNlY3Rpb24gMTAgb24gdHJhbnNpdGlvbiwgc2VlIGh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIjc2Vj
dGlvbi0xMA0KDQpJZiBzb21lb25lIHdpc2hlcyB0byBwcm9wb3NlIHRleHQgaW4gYSBuZXcgc2Vj
dGlvbiAxMC4yIG9uIOKAnElQdjYtb25seeKAnSBvcGVyYXRpb24sIHdlIGNvdWxkIGluY2x1ZGUg
dGhhdCBpZiB0aGUgV0cgYWdyZWVzLiAgVGhpcyBjb3VsZCBiZSBzb21ldGhpbmcgZm9yIFRpbVcg
dG8gYWRkIGFzIGEgcXVlc3Rpb24gd2hlbiB0aGUgZHJhZnQgaXMgcHJlc2VudGVkIGluIDZtYW4u
DQoNClRpbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz
dA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZlIFJl
cXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQo=

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpA
T2xlLCBJIGFncmVlLiBKdXN0IHN3YXAgdGhlIFJGQyMuICZuYnNwOyZuYnNwOw0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1j
b2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPi0gTXVzdCBiZSBhYmxlIHRvIGRvIE5BVDY0
IHByZWZpeCBkaXNjb3ZlcnkgKFJGQzYwNTIpPGJyPg0KPC9zcGFuPjwvZm9udD48L2Jsb2NrcXVv
dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4g
c3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4tIFN5bnRo
ZXNpc2UgSVB2NiBhZGRyZXNzIGZyb20gYW4gSVB2NCBsaXRlcmFsIChSRkM3MDUwKTwvc3Bhbj48
L2ZvbnQ+PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QFRpbSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGZvbnQgY29sb3I9IiMwMDAwMDAi
PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+
SWYgc29tZW9uZSB3aXNoZXMgdG8gcHJvcG9zZSB0ZXh0IGluIGEgbmV3IHNlY3Rpb24gMTAuMiBv
biDigJxJUHY2LW9ubHnigJ0gb3BlcmF0aW9uLCB3ZSBjb3VsZCBpbmNsdWRlIHRoYXQgaWYgdGhl
IFdHIGFncmVlcy4gJm5ic3A7VGhpcyZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9ibG9ja3F1b3RlPg0K
PGRpdj48YnI+DQo8L2Rpdj4NCkl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBoYXZlIHNvbWUgdGV4dCBp
biBzZWN0aW9uIDE0ICh2NiByb3V0ZXIpIHRvIGFjY29tbW9kYXRlIHY0IGhvc3RzL2FwcHMgaW4g
Y2FzZSBvZiB2Ni1vbmx5IHVwbGluay8gV0FOLiZuYnNwOzxicj4NCjxicj4NCjxkaXY+Q2hlZXJz
LA0KPGRpdj5SYWppdiAmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+PGJyPg0KT24gTm92IDEzLCAyMDE3LCBhdCA4OjA4IEFNLCBUaW0gQ2hvd24gJmx0OzxhIGhy
ZWY9Im1haWx0bzpUaW0uQ2hvd25AamlzYy5hYy51ayI+VGltLkNob3duQGppc2MuYWMudWs8L2E+
Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K
PGRpdj48c3Bhbj5IaSw8L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxzcGFuPk9uIDEzIE5vdiAyMDE3LCBhdCAwMjo1MCwgT2xlIFRyb2FuICZs
dDs8YSBocmVmPSJtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmciPm90cm9hbkBlbXBsb3llZXMu
b3JnPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj48c3Bhbj5BdCB0aGUgaGFja2F0aG9uIHRoZXJlIHdhcyBxdWl0ZSBhIGJp
dCBvZiB0ZXN0aW5nIG9mIElQdjYgb25seSBob3N0cyB3aXRoIGFjY2VzcyB0byB0aGUgSVB2NCBu
ZXR3b3JrIHZpYSBhIE5BVDY0Ljwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSI+PHNwYW4+V2hpbGUgbWFueSBhcHBsaWNhdGlvbnMgd29yayB3ZWxsIG9u
IGEgY2xhc3NpYyBJUHY2IG9ubHkgaG9zdCwgdGhlcmUgYXJlIGEgZmV3IHRoaW5ncyByZXF1aXJl
ZCB0byBtYWtlIGFsbCBhcHBsaWNhdGlvbnMgd29yay48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3Rl
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90
ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPi0gTXVzdCBiZSBhYmxlIHRvIGRvIE5B
VDY0IHByZWZpeCBkaXNjb3ZlcnkgKFJGQzYwNTIpPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPi0gU3ludGhlc2lzZSBJUHY2IGFkZHJlc3Mg
ZnJvbSBhbiBJUHY0IGxpdGVyYWwgKFJGQzcwNTApPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4N
CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+
DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5UaGlzIGlzIHRvIGJlIGFibGUgdG8gZGVh
bCB3aXRoIElQdjQgYWRkcmVzcyBsaXRlcmFscy4gV2hpY2ggYXJlIGNvbW1vbiBpbiBwcm90b2Nv
bHMgbGlrZSBTSVAvSUNFL1NUVU4uPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlRoZXNlIGNhbiBiZSBpbXBsZW1lbnRlZCBkaXJlY3RseSBp
biBhcHBsaWNhdGlvbnMsIG9yIGl0IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiB0aGUgaG9zdCBzdGFj
ayAoYWx0aG91Z2ggYXBwbGljYXRpb24gbWlnaHQgc3RpbGwgaGF2ZSB0byBjaGFuZ2UpLjwvc3Bh
bj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3Nw
YW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+LSBT
aG91bGQgZG8gbG9jYWwgRE5TNjQgdG8gc3VwcG9ydCBETlNTRUMgKFJGQzYxNDcpPC9zcGFuPjxi
cj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPihpZiB5b3Ug
ZG8gdmFsaWRhdGlvbikuPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0
eXBlPSJjaXRlIj48c3Bhbj5BIEROUzY0IHNlcnZpY2UgaW4gdGhlIG5ldHdvcmsgbG9va3MgbGlr
ZSBhIG1hbiBpbiB0aGUgbWlkZGxlIGF0dGFjaywgc28gdG8gc3VwcG9ydCBETlNTRUMsIHZhbGlk
YXRpb24gc2hvdWxkIGhhcHBlbiBiZWZvcmUgc3ludGhlc2l6aW5nLCBhbmQgbXVzdCBiZSBkb25l
IG9uIHRoZSBob3N0IGl0c2VsZi48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPjxzcGFuPklmIHRoaXMgaXMgdGhlIGRpcmVjdGlvbiB3ZSB3YW50IHRv
IGdvLiBFbmNvdXJhZ2UgSVB2NiBvbmx5IGhvc3QgZGVwbG95bWVudHMgKGFzIG9wcG9zZWQgdG8g
ZHVhbCBzdGFjayBob3N0cyksIGFyZSB0aGVzZSByZXF1aXJlbWVudHMgd2UnZCBsaWtlIHRvIGFk
ZCB0byB0aGUgSVB2NiBub2RlIHJlcXVpcmVtZW50cyBkb2N1bWVudD8gU29tZXdoZXJlIGVsc2U/
PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5kcmFm
dC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIgaW5jbHVkZXMgYSAodmVyeSBzaG9ydCkgU2VjdGlv
biAxMCBvbiB0cmFuc2l0aW9uLCBzZWUNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1pZXRmLTZtYW4tcmZjNjQzNC1iaXMtMDIjc2VjdGlvbi0xMCI+aHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJpcy0wMiNzZWN0aW9u
LTEwPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+SWYgc29tZW9uZSB3
aXNoZXMgdG8gcHJvcG9zZSB0ZXh0IGluIGEgbmV3IHNlY3Rpb24gMTAuMiBvbiDigJxJUHY2LW9u
bHnigJ0gb3BlcmF0aW9uLCB3ZSBjb3VsZCBpbmNsdWRlIHRoYXQgaWYgdGhlIFdHIGFncmVlcy4g
Jm5ic3A7VGhpcyBjb3VsZCBiZSBzb21ldGhpbmcgZm9yIFRpbVcgdG8gYWRkIGFzIGEgcXVlc3Rp
b24gd2hlbiB0aGUgZHJhZnQgaXMgcHJlc2VudGVkIGluIDZtYW4uPC9zcGFuPjxicj4NCjxzcGFu
Pjwvc3Bhbj48YnI+DQo8c3Bhbj5UaW08L3NwYW4+PGJyPg0KPHNwYW4+LS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3Nw
YW4+PGJyPg0KPHNwYW4+SUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0PC9zcGFu
Pjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIj5pcHY2QGlldGYub3Jn
PC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj5BZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2Ij4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NjwvYT48L3NwYW4+PGJyPg0KPHNwYW4+LS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS08L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9k
eT4NCjwvaHRtbD4NCg==

--_000_48E765433DD443E89B505CC4D9D76A2Fciscocom_--


From nobody Mon Nov 13 05:35:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554E0129400 for ; Mon, 13 Nov 2017 05:35:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PT9PEMqfogtz for ; Mon, 13 Nov 2017 05:35:17 -0800 (PST)
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 ABAAF12025C for <6man@ietf.org>; Mon, 13 Nov 2017 05:35:17 -0800 (PST)
Received: by mail-oi0-x233.google.com with SMTP id a132so11203668oih.11 for <6man@ietf.org>; Mon, 13 Nov 2017 05:35:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sj4QrcBcvpNSE9TAeJStJySyk/V4+osRjca/PrvYrB4=; b=A1WjurYaQIJNfsWSvaNUu9MuBnaReTtOUBgRZs7LK6PJgUqbbClTdoQQdFAK4BceMr ksXCxKiItKkK8QAt3h/trspjMdHwgRn+vvSmNwneDPDwYEgQW15UjMSkgxGPMv0BFT8m 8k067SGUY+W4zr6N3QDoktNGwuPf+WTrqx5wv7TMiPcnaCaInCt2wlmSDhE7UiXnh3wq ilx6kb+Q+/9MTreE4Uu5OskMLxijPR58mlbi9046RigGHesAkbzj/ZI0y/ao+klUXDwN 7OC8hM9xtfTXylb3tRQq+q5y/Xqu4hb+P+aM4Y9bLQvuRyBkmKZI3ig463P4KnO6i2M6 +S6g==
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=Sj4QrcBcvpNSE9TAeJStJySyk/V4+osRjca/PrvYrB4=; b=O5QZUATKwflKlRGUP0WY0Alb8kOsRWCvvhnsGBErJstMeuAWz4C2W+ZYsbcPfsGW1k sAw5zKRLfKpKsQVmLGcLyRShYjJnEJoClYbDYLnGIEDcMYGjPSjIFbxf7hgwFVJFz4Xt Er8qb/7zLfT0ZsLD6MAMjV2BlHdBGPqsEFPez33M80uJyG2hMPUvb2V5wiLfYX+Pj8hj B+5AOQ+CqZp17QXc7GCPPvlrjS+tsK0xO3T8sCX7xs8jV6PM0s5+qDFQjZ+IsyFFYKOS lCis4ENXLha7hW+HCR8SWYpr/pDqBluCBL/IS4K1lpoFk2HxJCGzYy5FbedcL7TFZCuj acbg==
X-Gm-Message-State: AJaThX6veLDKqX2j/AIIew2FKRKd2tkus6TFC9BPOC3LoL6zufwLd5HU 7Q2x0/3SDTLMilIUtR3xTSr57h628c0VUwfX5mBa2uxJ
X-Google-Smtp-Source: AGs4zMZ1mrzFnZuFd3HawOyyOX2hJknsZNe987JvaHnli5OMwwYmqMUKS802vHXQZBV6TjetW3PfRvACkIzkC0DBF0o=
X-Received: by 10.202.241.85 with SMTP id p82mr5605897oih.169.1510580116934; Mon, 13 Nov 2017 05:35:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.13.74 with HTTP; Mon, 13 Nov 2017 05:35:15 -0800 (PST)
In-Reply-To: <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>
From: Victor Kuarsingh 
Date: Mon, 13 Nov 2017 08:35:15 -0500
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: Lorenzo Colitti , "6man@ietf.org" <6man@ietf.org>,  "v6ops@ietf.org WG" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:35:19 -0000

On Mon, Nov 13, 2017 at 8:20 AM, Fernando Gont  wrote:
> On 11/13/2017 07:14 PM, Lorenzo Colitti wrote:
>> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont > > wrote:
>>
>>     >From a operational point of view, one would wonder why pursue this path
>>     as opposed to e.g. do DHCPv6
>>
>>
>> As for DHCPv6 specifically, one reason is that DHCPv6-only networks are
>> not recommended by the IETF. RFC 7934.
>
> Yes, sorry: I meant DHCPv6-PD.
>
> RFC7934:
>
>     Due to the drawbacks imposed by requiring explicit requests for
>     address space (see Section 4), it is RECOMMENDED that the network
>     give the host the ability to use new addresses without requiring
>     explicit requests.  This can be achieved either by allowing the host
>     to form new addresses autonomously (e.g., via SLAAC) or by providing
>     the host with a dedicated /64 prefix.  The prefix MAY be provided
>     using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
>
> Therefore, why re-invent PD in SLAAC?

PD is quite vast, and this draft describes a specific set of use
cases.  It does not seem like a re-invention of PD in SLACC to me.

>
>
> That aside, same RFC says:
>     Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide
>     multiple addresses when the host connects (e.g., the approximately 30
>     addresses that can fit into a single packet) would accommodate
>     current clients, but it sets a limit on the number of addresses
>     available to hosts when they attach and therefore limits the
>     development of future applications.
>
> I seem to recall many systems limit the number of addresses per
> interface to 16.

Current limitations are likely ephemeral and can change over time.

> So the limit of "30 per request" aleady gives you more
> than what you typically get, in practice, with SLAAC. Also... is issuing
> multiple requests forbidden?

I think we also have enough history in computing and the Internet to
know that today's concept of "that is way more then we need, so why do
we need more" is not a good argument to limit capabilities.

regards,

Victor K



>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Mon Nov 13 05:42:59 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD33129455 for ; Mon, 13 Nov 2017 05:42:57 -0800 (PST)
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 W7PpB0CDJ35d for ; Mon, 13 Nov 2017 05:42:51 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C54F127843 for ; Mon, 13 Nov 2017 05:42:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510580569; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=g2ZgtRqq2cloGTsUlMy1O/q3UmRRYy28cWZf/83j+Bc=; b=LPQf1D0ezge9oXbpPQkgVzM83oBFRkxu1GEYb6eDye3lYRJBGMJt0YwkksH/3brPAUbUyhnJU1MLYQVtCcSTcL/7B3U0kwIYf2imq+xUaRRaAWYZoJU7fHe5RVEbtR+FSsvVeU++ql+Bc84kqu7FJ7VNtOPDk87WmF59Fe1LCTk=
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0177.outbound.protection.outlook.com [213.199.154.177]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-60-nLfW6C7gNt2TWoNXDvQV0Q-1; Mon, 13 Nov 2017 13:42:45 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 13:42:44 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0239.005; Mon, 13 Nov 2017 13:42:44 +0000
From: Tim Chown 
To: "Rajiv Asati (rajiva)" 
CC: Ole Troan , Timothy Winters ,  6man WG 
Subject: Re: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTXCpXJ0TGvGV100ygbRReFshDs6MSSJWAgAAFTQCAAARZgA==
Date: Mon, 13 Nov 2017 13:42:44 +0000
Message-ID: <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk>
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com>
In-Reply-To: <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:e565:a751:53f4:fd9a]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 20:EbTs+2L9urINiSQiJckCyvxGkdSbSkwPNnlGQ2WBLJg09Mn1Gk0L3TD9zWNMLl3sBaX8fwR2YpPbwb0mrwpN7hi+zfdQV47ApUMCsny8dbVpTfAgs7qFMYQllORqe7vLKYNiug6ZVhOuaa5H0mqRIireA3xI4bLz/Z+ASoUmpfU=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 0e2ffcfb-d930-482a-6e7d-08d52a9c6b5a
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1137; 
x-ms-traffictypediagnostic: AM3PR07MB1137:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(274715658323672)(278428928389397)(95692535739014); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1137; 
x-forefront-prvs: 0490BBA1F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(24454002)(966005)(81156014)(53546010)(81166006)(72206003)(76176999)(36756003)(786003)(478600001)(6486002)(99286004)(7736002)(86362001)(106356001)(4326008)(82746002)(316002)(8936002)(5660300001)(83716003)(33656002)(101416001)(25786009)(105586002)(14454004)(189998001)(8676002)(50986999)(6506006)(6246003)(3660700001)(3280700002)(6436002)(2906002)(5250100002)(74482002)(2900100001)(229853002)(2950100002)(54906003)(6116002)(68736007)(102836003)(97736004)(6512007)(6306002)(305945005)(42882006)(6916009)(50226002)(53936002)(57306001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <7A014529E270D14D827FE324CAA0D852@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e2ffcfb-d930-482a-6e7d-08d52a9c6b5a
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 13:42:44.6365 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137
X-MC-Unique: nLfW6C7gNt2TWoNXDvQV0Q-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:42:58 -0000

PiBPbiAxMyBOb3YgMjAxNywgYXQgMTM6MjcsIFJhaml2IEFzYXRpIChyYWppdmEpIDxyYWppdmFA
Y2lzY28uY29tPiB3cm90ZToNCj4gDQo+IEBPbGUsIEkgYWdyZWUuIEp1c3Qgc3dhcCB0aGUgUkZD
Iy4gICANCj4gDQo+Pj4gLSBNdXN0IGJlIGFibGUgdG8gZG8gTkFUNjQgcHJlZml4IGRpc2NvdmVy
eSAoUkZDNjA1MikNCj4+PiAtIFN5bnRoZXNpc2UgSVB2NiBhZGRyZXNzIGZyb20gYW4gSVB2NCBs
aXRlcmFsIChSRkM3MDUwKQ0KPiANCj4gDQo+IEBUaW0sDQo+IA0KPj4gSWYgc29tZW9uZSB3aXNo
ZXMgdG8gcHJvcG9zZSB0ZXh0IGluIGEgbmV3IHNlY3Rpb24gMTAuMiBvbiDigJxJUHY2LW9ubHni
gJ0gb3BlcmF0aW9uLCB3ZSBjb3VsZCBpbmNsdWRlIHRoYXQgaWYgdGhlIFdHIGFncmVlcy4gIFRo
aXMgDQo+IA0KPiBJdCBtaWdodCBiZSB1c2VmdWwgdG8gaGF2ZSBzb21lIHRleHQgaW4gc2VjdGlv
biAxNCAodjYgcm91dGVyKSB0byBhY2NvbW1vZGF0ZSB2NCBob3N0cy9hcHBzIGluIGNhc2Ugb2Yg
djYtb25seSB1cGxpbmsvIFdBTi4gDQoNCkkgdGhpbmsgdGhlIHRyaWNrIGZvciA2NDM0YmlzIGlz
IGRlY2lkaW5nIHdoYXQgdGhlIHNjb3BlIG9mIHRoZSBkb2MgaXMuIFN1Y2ggc3VnZ2VzdGlvbnMs
IHdoaWxlIHRoZXkgY2VydGFpbmx5IGhhdmUgbWVyaXQsIGFyZSBhIHNsaXBwZXJ5IHNsb3BlIHRv
IGFkZGluZyBtYW55IHRoaW5ncywgYXMgd2XigJl2ZSBzZWVuIHdoZW4gSm9yZGkgc3RhcnRlZCBw
cm9wb3NpbmcgdHJhbnNpdGlvbiBtZWNoYW5pc21zIGZvciBSRkM3MDg0LWJpcy4gIA0KDQpTdGVl
ciBmcm9tIHRoZSBXRyBpcywgYXMgZXZlciwgdmVyeSB3ZWxjb21lLg0KDQpUaW0NCg0KPiBDaGVl
cnMsDQo+IFJhaml2ICANCj4gDQo+IA0KPiBPbiBOb3YgMTMsIDIwMTcsIGF0IDg6MDggQU0sIFRp
bSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWs+IHdyb3RlOg0KPiANCj4+IEhpLA0KPj4gDQo+
Pj4gT24gMTMgTm92IDIwMTcsIGF0IDAyOjUwLCBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMu
b3JnPiB3cm90ZToNCj4+PiANCj4+PiBBdCB0aGUgaGFja2F0aG9uIHRoZXJlIHdhcyBxdWl0ZSBh
IGJpdCBvZiB0ZXN0aW5nIG9mIElQdjYgb25seSBob3N0cyB3aXRoIGFjY2VzcyB0byB0aGUgSVB2
NCBuZXR3b3JrIHZpYSBhIE5BVDY0Lg0KPj4+IA0KPj4+IFdoaWxlIG1hbnkgYXBwbGljYXRpb25z
IHdvcmsgd2VsbCBvbiBhIGNsYXNzaWMgSVB2NiBvbmx5IGhvc3QsIHRoZXJlIGFyZSBhIGZldyB0
aGluZ3MgcmVxdWlyZWQgdG8gbWFrZSBhbGwgYXBwbGljYXRpb25zIHdvcmsuDQo+Pj4gDQo+Pj4g
LSBNdXN0IGJlIGFibGUgdG8gZG8gTkFUNjQgcHJlZml4IGRpc2NvdmVyeSAoUkZDNjA1MikNCj4+
PiAtIFN5bnRoZXNpc2UgSVB2NiBhZGRyZXNzIGZyb20gYW4gSVB2NCBsaXRlcmFsIChSRkM3MDUw
KQ0KPj4+IA0KPj4+IFRoaXMgaXMgdG8gYmUgYWJsZSB0byBkZWFsIHdpdGggSVB2NCBhZGRyZXNz
IGxpdGVyYWxzLiBXaGljaCBhcmUgY29tbW9uIGluIHByb3RvY29scyBsaWtlIFNJUC9JQ0UvU1RV
Ti4NCj4+PiBUaGVzZSBjYW4gYmUgaW1wbGVtZW50ZWQgZGlyZWN0bHkgaW4gYXBwbGljYXRpb25z
LCBvciBpdCBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gdGhlIGhvc3Qgc3RhY2sgKGFsdGhvdWdoIGFw
cGxpY2F0aW9uIG1pZ2h0IHN0aWxsIGhhdmUgdG8gY2hhbmdlKS4NCj4+PiANCj4+PiAtIFNob3Vs
ZCBkbyBsb2NhbCBETlM2NCB0byBzdXBwb3J0IEROU1NFQyAoUkZDNjE0NykNCj4+PiAoaWYgeW91
IGRvIHZhbGlkYXRpb24pLg0KPj4+IA0KPj4+IEEgRE5TNjQgc2VydmljZSBpbiB0aGUgbmV0d29y
ayBsb29rcyBsaWtlIGEgbWFuIGluIHRoZSBtaWRkbGUgYXR0YWNrLCBzbyB0byBzdXBwb3J0IERO
U1NFQywgdmFsaWRhdGlvbiBzaG91bGQgaGFwcGVuIGJlZm9yZSBzeW50aGVzaXppbmcsIGFuZCBt
dXN0IGJlIGRvbmUgb24gdGhlIGhvc3QgaXRzZWxmLg0KPj4+IA0KPj4+IElmIHRoaXMgaXMgdGhl
IGRpcmVjdGlvbiB3ZSB3YW50IHRvIGdvLiBFbmNvdXJhZ2UgSVB2NiBvbmx5IGhvc3QgZGVwbG95
bWVudHMgKGFzIG9wcG9zZWQgdG8gZHVhbCBzdGFjayBob3N0cyksIGFyZSB0aGVzZSByZXF1aXJl
bWVudHMgd2UnZCBsaWtlIHRvIGFkZCB0byB0aGUgSVB2NiBub2RlIHJlcXVpcmVtZW50cyBkb2N1
bWVudD8gU29tZXdoZXJlIGVsc2U/DQo+PiANCj4+IGRyYWZ0LWlldGYtNm1hbi1yZmM2NDM0LWJp
cy0wMiBpbmNsdWRlcyBhICh2ZXJ5IHNob3J0KSBTZWN0aW9uIDEwIG9uIHRyYW5zaXRpb24sIHNl
ZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi02bWFuLXJmYzY0MzQtYmlz
LTAyI3NlY3Rpb24tMTANCj4+IA0KPj4gSWYgc29tZW9uZSB3aXNoZXMgdG8gcHJvcG9zZSB0ZXh0
IGluIGEgbmV3IHNlY3Rpb24gMTAuMiBvbiDigJxJUHY2LW9ubHnigJ0gb3BlcmF0aW9uLCB3ZSBj
b3VsZCBpbmNsdWRlIHRoYXQgaWYgdGhlIFdHIGFncmVlcy4gIFRoaXMgY291bGQgYmUgc29tZXRo
aW5nIGZvciBUaW1XIHRvIGFkZCBhcyBhIHF1ZXN0aW9uIHdoZW4gdGhlIGRyYWZ0IGlzIHByZXNl
bnRlZCBpbiA2bWFuLg0KPj4gDQo+PiBUaW0NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBJRVRGIElQdjYg
d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4+IGlwdjZAaWV0Zi5vcmcNCj4+IEFkbWluaXN0
cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw
djYNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQoNCg==


From nobody Mon Nov 13 05:54:43 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46678129584 for ; Mon, 13 Nov 2017 05:54:42 -0800 (PST)
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 kXw-DoOKSnVR for ; Mon, 13 Nov 2017 05:54:38 -0800 (PST)
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 4362412957A for ; Mon, 13 Nov 2017 05:54:35 -0800 (PST)
Received: by mail-yw0-x22c.google.com with SMTP id q1so13453921ywh.5 for ; Mon, 13 Nov 2017 05:54:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qha5GPfKv4AYIqjnWDKoPiv7ZFjnCImJTHZKLMPylBM=; b=LWj/2nnPPIZnaLpbd/VQ8GGsTF96Iy99pILj+pC0A8MJdWFYXV1+2co2tA7xprB2iv 2CNZ33qxM5Fn20+aIiKLncXaVOOU3hXp9+vZvCWHUueISVTIMJ/tqnHBl+WrSuiGmODR +T7w9BaeliYkYAF1qfg+BRE6/Rj5h7FUUljY35v8dBNYe1yK3uhB+JSwTXVRsgY6ZcG4 LK5GfxwuftMrbS5xqvnBL93fG0YaTpEyQoUesnd1HF8m1HK609hNOmnWSdd3w12bSMit 9fbEpZUbgJwcQpRatKurOSrcGMlZKaynRlxSVMa7nSvxVTIDDZOwOkP3BSwGZVAt2ELM nKLA==
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=Qha5GPfKv4AYIqjnWDKoPiv7ZFjnCImJTHZKLMPylBM=; b=Qm6I+uFcs020CX9o5ZHKK4F0fTg6k3YibGIXua05SaR7y3TlABRk+SrB9eg3xPMvGv lxCPcTFGDamF8JIVqZt5E0S46s7fagAFY5wZSlyK5v8MZYcssVveboQgjUhuLW9/mNHw 1Ox8Jk9p0w5ckIArQQRHODYSDsM4YXZ/qfO8IgZgim62jjSmfqkVxrbXLUimqUfxJyZJ Ov0TNPaqws/aLsTtI6TtS+HvlWVh+5F7pXn4rSW800SQf2eeeyfLIq7/AP5EXqlopogL yMdu0/xChl2SNZ8ba7nIJ8BdgJJRogCbykOfJF6peZ6Ee5RJamZDZbbmwJkeEtH9+bVi wyyA==
X-Gm-Message-State: AJaThX57z1jAM6fziylbohNesN0N8KA0lVX3O2AZW6eEQUoWVgBNib4a MZhnxkU4Bh5BiL9Z6+n2OpnaCONaFEP2sVtNRnA=
X-Google-Smtp-Source: AGs4zMZE7bA4YBqDiarGTvSQPZUhcbrOf2191jS+CMZOMMqLcXqePtOWYiNDn5ZVeNhpomXNpfs+r98rlDWzFteQq0E=
X-Received: by 10.37.130.11 with SMTP id q11mr5438079ybk.50.1510581274315; Mon, 13 Nov 2017 05:54:34 -0800 (PST)
MIME-Version: 1.0
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk>
In-Reply-To: <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk>
From: Ca By 
Date: Mon, 13 Nov 2017 13:54:23 +0000
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Tim Chown 
Cc: 6man WG , "Rajiv Asati (rajiva)" 
Content-Type: multipart/alternative; boundary="089e0828c20c429dee055ddd9cbf"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:54:42 -0000

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

On Mon, Nov 13, 2017 at 5:43 AM Tim Chown  wrote:

> > On 13 Nov 2017, at 13:27, Rajiv Asati (rajiva)  wrote=
:
> >
> > @Ole, I agree. Just swap the RFC#.
> >
> >>> - Must be able to do NAT64 prefix discovery (RFC6052)
> >>> - Synthesise IPv6 address from an IPv4 literal (RFC7050)
> >
> >
> > @Tim,
> >
> >> If someone wishes to propose text in a new section 10.2 on =E2=80=9CIP=
v6-only=E2=80=9D
> operation, we could include that if the WG agrees.  This
> >
> > It might be useful to have some text in section 14 (v6 router) to
> accommodate v4 hosts/apps in case of v6-only uplink/ WAN.
>
> I think the trick for 6434bis is deciding what the scope of the doc is.
> Such suggestions, while they certainly have merit, are a slippery slope t=
o
> adding many things, as we=E2=80=99ve seen when Jordi started proposing tr=
ansition
> mechanisms for RFC7084-bis.
>

Yes , slippery slope indeed. And you would have to deal with me opposing
the case being included.

I have a network with 10s of millions of ipv6-only nodes, none of which can
so dnssec (neither android nor ios support it) and the implication that
these nodes are no longer ipv6 since they don't do dnssec is ludicrous.

i think this is just folks tryjng to raise the bar against nat64, again,
with nonesense usecass that users and operators don=E2=80=99t want or care =
about.

Sad


> Steer from the WG is, as ever, very welcome.
>
> Tim
>
> > Cheers,
> > Rajiv
> >
> >
> > On Nov 13, 2017, at 8:08 AM, Tim Chown  wrote:
> >
> >> Hi,
> >>
> >>> On 13 Nov 2017, at 02:50, Ole Troan  wrote:
> >>>
> >>> At the hackathon there was quite a bit of testing of IPv6 only hosts
> with access to the IPv4 network via a NAT64.
> >>>
> >>> While many applications work well on a classic IPv6 only host, there
> are a few things required to make all applications work.
> >>>
> >>> - Must be able to do NAT64 prefix discovery (RFC6052)
> >>> - Synthesise IPv6 address from an IPv4 literal (RFC7050)
> >>>
> >>> This is to be able to deal with IPv4 address literals. Which are
> common in protocols like SIP/ICE/STUN.
> >>> These can be implemented directly in applications, or it can be
> implemented in the host stack (although application might still have to
> change).
> >>>
> >>> - Should do local DNS64 to support DNSSEC (RFC6147)
> >>> (if you do validation).
> >>>
> >>> A DNS64 service in the network looks like a man in the middle attack,
> so to support DNSSEC, validation should happen before synthesizing, and
> must be done on the host itself.
> >>>
> >>> If this is the direction we want to go. Encourage IPv6 only host
> deployments (as opposed to dual stack hosts), are these requirements we'd
> like to add to the IPv6 node requirements document? Somewhere else?
> >>
> >> draft-ietf-6man-rfc6434-bis-02 includes a (very short) Section 10 on
> transition, see
> https://tools.ietf.org/html/draft-ietf-6man-rfc6434-bis-02#section-10
> >>
> >> If someone wishes to propose text in a new section 10.2 on =E2=80=9CIP=
v6-only=E2=80=9D
> operation, we could include that if the WG agrees.  This could be somethi=
ng
> for TimW to add as a question when the draft is presented in 6man.
> >>
> >> Tim
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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


On Mon, Nov 13, 2017=
 at 5:43 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
> On 13 Nov 2017, at 13:27, Rajiv Asati (rajiva) <rajiva@cisco.com> wro=
te:

>

> @Ole, I agree. Just swap the RFC#.

>

>>> - Must be able to do NAT64 prefix discovery (RFC6052)

>>> - Synthesise IPv6 address from an IPv4 literal (RFC7050)

>

>

> @Tim,

>

>> If someone wishes to propose text in a new section 10.2 on =E2=80=
=9CIPv6-only=E2=80=9D operation, we could include that if the WG agrees.=C2=
=A0 This

>

> It might be useful to have some text in section 14 (v6 router) to acco=
mmodate v4 hosts/apps in case of v6-only uplink/ WAN.



I think the trick for 6434bis is deciding what the scope of the doc is. Suc=
h suggestions, while they certainly have merit, are a slippery slope to add=
ing many things, as we=E2=80=99ve seen when Jordi started proposing transit=
ion mechanisms for RFC7084-bis.



Yes , slippery slope indeed. And you wou=
ld have to deal with me opposing the case being included.=C2=A0

I have a network with 10s of millio=
ns of ipv6-only nodes, none of which can so dnssec (neither android nor ios=
 support it) and the implication that these nodes are no longer ipv6 since =
they don't do dnssec is ludicrous.=C2=A0

i think this is just folks tryjng to raise the bar aga=
inst nat64, again, with nonesense usecass that users and operators don=E2=
=80=99t want or care about.=C2=A0

Sad=C2=A0

=



Steer from the WG is, as ever, very welcome.



Tim



> Cheers,

> Rajiv

>

>

> On Nov 13, 2017, at 8:08 AM, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

>

>> Hi,

>>

>>> On 13 Nov 2017, at 02:50, Ole Troan <otroan@employees.org> wrote:

>>>

>>> At the hackathon there was quite a bit of testing of IPv6 only=
 hosts with access to the IPv4 network via a NAT64.

>>>

>>> While many applications work well on a classic IPv6 only host,=
 there are a few things required to make all applications work.

>>>

>>> - Must be able to do NAT64 prefix discovery (RFC6052)

>>> - Synthesise IPv6 address from an IPv4 literal (RFC7050)

>>>

>>> This is to be able to deal with IPv4 address literals. Which a=
re common in protocols like SIP/ICE/STUN.

>>> These can be implemented directly in applications, or it can b=
e implemented in the host stack (although application might still have to c=
hange).

>>>

>>> - Should do local DNS64 to support DNSSEC (RFC6147)

>>> (if you do validation).

>>>

>>> A DNS64 service in the network looks like a man in the middle =
attack, so to support DNSSEC, validation should happen before synthesizing,=
 and must be done on the host itself.

>>>

>>> If this is the direction we want to go. Encourage IPv6 only ho=
st deployments (as opposed to dual stack hosts), are these requirements we&=
#39;d like to add to the IPv6 node requirements document? Somewhere else?
>>

>> draft-ietf-6man-rfc6434-bis-02 includes a (very short) Section 10 =
on transition, see https://tool=
s.ietf.org/html/draft-ietf-6man-rfc6434-bis-02#section-10

>>

>> If someone wishes to propose text in a new section 10.2 on =E2=80=
=9CIPv6-only=E2=80=9D operation, we could include that if the WG agrees.=C2=
=A0 This could be something for TimW to add as a question when the draft is=
 presented in 6man.

>>

>> Tim

>> ------------------------------------------------------------------=
--

>> IETF IPv6 working group mailing list

>> ipv6@ietf.org

>> Administrative Requests: https://www.ietf.org/mai=
lman/listinfo/ipv6

>> ------------------------------------------------------------------=
--



--------------------------------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/list=
info/ipv6

--------------------------------------------------------------------




--089e0828c20c429dee055ddd9cbf--


From nobody Mon Nov 13 05:56:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C7E1294D2; Mon, 13 Nov 2017 05:56:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 02SstgmTq8iA; Mon, 13 Nov 2017 05:56:22 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD34129584; Mon, 13 Nov 2017 05:56:22 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e] (unknown [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7BE228257B; Mon, 13 Nov 2017 14:56:19 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Victor Kuarsingh 
Cc: Lorenzo Colitti , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com> 
From: Fernando Gont 
Message-ID: 
Date: Mon, 13 Nov 2017 21:51:24 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:56:24 -0000

On 11/13/2017 09:35 PM, Victor Kuarsingh wrote:
> On Mon, Nov 13, 2017 at 8:20 AM, Fernando Gont  wrote:
>> On 11/13/2017 07:14 PM, Lorenzo Colitti wrote:
>>> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont >> > wrote:
>>>
>>>     >From a operational point of view, one would wonder why pursue this path
>>>     as opposed to e.g. do DHCPv6
>>>
>>>
>>> As for DHCPv6 specifically, one reason is that DHCPv6-only networks are
>>> not recommended by the IETF. RFC 7934.
>>
>> Yes, sorry: I meant DHCPv6-PD.
>>
>> RFC7934:
>>
>>     Due to the drawbacks imposed by requiring explicit requests for
>>     address space (see Section 4), it is RECOMMENDED that the network
>>     give the host the ability to use new addresses without requiring
>>     explicit requests.  This can be achieved either by allowing the host
>>     to form new addresses autonomously (e.g., via SLAAC) or by providing
>>     the host with a dedicated /64 prefix.  The prefix MAY be provided
>>     using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
>>
>> Therefore, why re-invent PD in SLAAC?
> 
> PD is quite vast, and this draft describes a specific set of use
> cases.  It does not seem like a re-invention of PD in SLACC to me.

Again: Why not use DHCPv6-PD?



>> That aside, same RFC says:
>>     Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide
>>     multiple addresses when the host connects (e.g., the approximately 30
>>     addresses that can fit into a single packet) would accommodate
>>     current clients, but it sets a limit on the number of addresses
>>     available to hosts when they attach and therefore limits the
>>     development of future applications.
>>
>> I seem to recall many systems limit the number of addresses per
>> interface to 16.
> 
> Current limitations are likely ephemeral and can change over time.

Same could possibly be said about packet sizes.

In any case, I don't see any limits on the number of DHCPv6-requests. If
one is not enough, do more than one.



>> So the limit of "30 per request" aleady gives you more
>> than what you typically get, in practice, with SLAAC. Also... is issuing
>> multiple requests forbidden?
> 
> I think we also have enough history in computing and the Internet to
> know that today's concept of "that is way more then we need, so why do
> we need more" is not a good argument to limit capabilities.

Apply this reasoning to your response above:

  PD is quite vast, and this draft describes a specific set of use
  cases.  It does not seem like a re-invention of PD in SLACC to me.

Rather than limit a node to request a /64, emply DHCPv6-PD, and allow
the node to get more than that. Otherwise, *this* mechanism is enforcing
an artificial limit.

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





From nobody Mon Nov 13 05:56:46 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92841296B3; Mon, 13 Nov 2017 05:56:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KtSzH5ivUgGq; Mon, 13 Nov 2017 05:56:25 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CDD12960D; Mon, 13 Nov 2017 05:56:25 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e] (unknown [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 391C582665; Mon, 13 Nov 2017 14:56:23 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Victor Kuarsingh 
Cc: Ole Troan , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com> 
From: Fernando Gont 
Message-ID: 
Date: Mon, 13 Nov 2017 21:53:31 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:56:27 -0000

On 11/13/2017 09:22 PM, Victor Kuarsingh wrote:
> On Mon, Nov 13, 2017 at 4:21 AM, Fernando Gont  wrote:
>> On 11/13/2017 11:07 AM, Ole Troan wrote:
> 
>>
>> If the implementation approach is as you've described, this is outside
>> of the SLAAC specification, indeed (nobody can prevent you from spawning
>> instances of SLAAC that behave according to the existing standards).
>> >From a operational point of view, one would wonder why pursue this path
>> as opposed to e.g. do DHCPv6 -- even if that means: we want to support
>> Android, and Android does not support DHCPv6.
> 
> My understanding is one of the authors is an operator and the model
> represents operational experience and input on this.

This doesn't answer the question I made above.


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





From nobody Mon Nov 13 06:17:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528DE1288B8 for ; Mon, 13 Nov 2017 06:17:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2BW7FljtUhm for ; Mon, 13 Nov 2017 06:17:11 -0800 (PST)
Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 A328C12943D for <6man@ietf.org>; Mon, 13 Nov 2017 06:17:10 -0800 (PST)
Received: by mail-ot0-x231.google.com with SMTP id b17so1623596oth.2 for <6man@ietf.org>; Mon, 13 Nov 2017 06:17:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3tGlPhTkX9B3rtPFC9t7fj8940R0sb3myt7LqtEkCx0=; b=w/SuZt2FhZKZDpBj8Z0JJnBX1Y/JLELZQi3p2/tkM7IZIvlq1MNbxY6lJrKTGg2c27 PSV234CCLKg52A2YOmltI2yGR1v/07CUB8/Gfo1G0oYaIeV8IE766fBLpxGkVcjwl9kP Hwxw/HJUNUaEbPudUXi810U1WafHTcYg3sbBdSDDE6Ud69I5uFaygBT9/ZXlXypa5qCR N9d9SrdATtqec/dto0RfptAco4nBfmKT7cilYjstaNEJ1ZpYdfhc0maJrsb8UdEwFlxB y8v6phNMbxvrMOKDTwF6IDAmF5eXjkeUfCE2KO8aUV1LU/AyKddPSfTrrorbQcskDgbc Tbxg==
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=3tGlPhTkX9B3rtPFC9t7fj8940R0sb3myt7LqtEkCx0=; b=ErrJTQo5XIGSNP2I4fzFbGNi51QlRxM1X8VJu8jmsfkcYf1z5cI3AJ6USerGzKTZkr 9MhUt1kS6SJX7YaOFrBY9KqOiJN4nz4GoKCzu6L2MF7gGLkTnRFa7AqlYMep0iTVXX5r GgleNgPlbYwMU3/rMGp75Z4/eqOwaCUAKWzAywwXbk/cT6VVVmmidSTawmSSYzRrxdzA aUymReyjslRmIrccLErAv2iOZdpyAQdRANqXTXWTK5SKWqoG/53uT6R4IE0ADRh9H6Jn yJEZUL9R847aWJfyOWfaS78AowLrHxB0QLeKh1LFlSZAuAAOIFn/ENBxnaQJStzo2h31 6nlw==
X-Gm-Message-State: AJaThX68czwZy80QJU+BZ0rJoMWjnl8gZk91I90lKg9IrlVSmJaR17q+ l8/qtSLbwXyB73mabkqRE8i1hDVf+fiCAiGadcg2lw==
X-Google-Smtp-Source: AGs4zMYB+YturM2+e8PGEuMMQvhXXzGcOYlmDrdKRNgT/hMWbELZ910zOmpHOpHMQioJLQ7qCTvrBBqQUOIdhuRL8TA=
X-Received: by 10.157.3.67 with SMTP id 61mr5704012otv.347.1510582630004; Mon, 13 Nov 2017 06:17:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.13.74 with HTTP; Mon, 13 Nov 2017 06:17:09 -0800 (PST)
In-Reply-To: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>  
From: Victor Kuarsingh 
Date: Mon, 13 Nov 2017 09:17:09 -0500
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: Lorenzo Colitti , "6man@ietf.org" <6man@ietf.org>,  "v6ops@ietf.org WG" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:17:12 -0000

On Mon, Nov 13, 2017 at 8:51 AM, Fernando Gont  wrote:
> On 11/13/2017 09:35 PM, Victor Kuarsingh wrote:
>> On Mon, Nov 13, 2017 at 8:20 AM, Fernando Gont  wrote:
>>> On 11/13/2017 07:14 PM, Lorenzo Colitti wrote:
>>>> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont >>> > wrote:
>>>>
>>>>     >From a operational point of view, one would wonder why pursue this path
>>>>     as opposed to e.g. do DHCPv6
>>>>
>>>>
>>>> As for DHCPv6 specifically, one reason is that DHCPv6-only networks are
>>>> not recommended by the IETF. RFC 7934.
>>>
>>> Yes, sorry: I meant DHCPv6-PD.
>>>
>>> RFC7934:
>>>
>>>     Due to the drawbacks imposed by requiring explicit requests for
>>>     address space (see Section 4), it is RECOMMENDED that the network
>>>     give the host the ability to use new addresses without requiring
>>>     explicit requests.  This can be achieved either by allowing the host
>>>     to form new addresses autonomously (e.g., via SLAAC) or by providing
>>>     the host with a dedicated /64 prefix.  The prefix MAY be provided
>>>     using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
>>>
>>> Therefore, why re-invent PD in SLAAC?
>>
>> PD is quite vast, and this draft describes a specific set of use
>> cases.  It does not seem like a re-invention of PD in SLACC to me.
>
> Again: Why not use DHCPv6-PD?
>

I would leave this up to the operators to decide. They are designing
their network and know their requirements best.  I don't want to be in
a position of ignoring what operators are saying they need by
suggesting we have it all figured out here at the IETF and are telling
them how to make design decisions.

There are many factors the weigh into why operators make certain
decisions.  There are circumstances were DHCPv6-PD would be quite
valid, and others, as described in the draft, where the methods
described are desirable.  I don't think there is any one way to build
a network (I am yet to have built two that look exactly the same given
different input requirements).

regards,

Victor K


From nobody Mon Nov 13 06:24:06 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890F61288B8 for ; Mon, 13 Nov 2017 06:24:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHipoCb5-t1H for ; Mon, 13 Nov 2017 06:23:58 -0800 (PST)
Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D94B127843 for <6man@ietf.org>; Mon, 13 Nov 2017 06:23:58 -0800 (PST)
Received: by mail-ot0-x236.google.com with SMTP id o23so2897787otd.1 for <6man@ietf.org>; Mon, 13 Nov 2017 06:23:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6dhxX1lRxNCKZCBseg+wamwP1Rlvx+IlxW8p41PIlTw=; b=VXP2xM/CAOXpeBz3tz83LcEbAWunFwFYRFSrqcTIpcoEr4RWymxH6t4Kqf7K3ZVY1t 4lZvXxrBJn+FGH7JZ7Gc63EQFUIDJh3SPknWwCg5ogQSkCv57jZ3ZYFYKOcFDzWWlPEZ 9S1s3DH0isOcRGjAyi/xnIemnvvPWUIx6A88RJd0ln4Nsw5VFGPg8v3qLYMAskyxMTqF evnRZWfGLebnm/5lvUP5IPcPUjwEw2sFKNZfelpr3wuiUkDZj6xTHIxMWveeFVSr0394 ObgfI/giUtJnNd3NZR4hpVKbZf1lDlAbzs77vAADZ6bf47sD1bUbpQFdk0IqtVpyxdA0 smpg==
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=6dhxX1lRxNCKZCBseg+wamwP1Rlvx+IlxW8p41PIlTw=; b=W1roZvE2LNcF2DMMMOvSKQQqnx0j3ErTLc1a3ggw0AYBcCATmu0+ykWdSrXiTdf7YX 9HGHNXD18ORuV63cHceKbFUXPVGgnxr1hQV4Oyb5c42hc9wBfojSYyJYtLNP4CoJK1V8 J/i0OVoRUy85lYUPZCtUXqnU/D+LZsPaDqOpeFlHZb7TJUwwHHoeiNpr/DTaeV3WFZJo 3s+tgmfNVnmTwGxaZzwP+xEZg0f6gdxfEd4zTMlH4hUgrcI7n6Zl5HRqWg7oWmmlCYpX dQe5+t2T5jNnbXitC1tmaEEIraVcsY0a7rSYah/3x1qojntt3jwvOUII7/y19j90GF1j rSfw==
X-Gm-Message-State: AJaThX64VlE02f6zrpuzw9uE2F6yFCwVjTI3TLLxMmo5Id/XMgSP/BS7 sBbmteEgvjgW5trfsWr+ypmJxqjgu/tcz3OEwpzLmhT2
X-Google-Smtp-Source: AGs4zMZ89wgM05V3G3g3qQDCEJDgsyUQdMyWBLqN9HO7WwwLu+6uuErLLzs08ntzrKKN0TNhj2tpvDfZAXxju3E5n5Y=
X-Received: by 10.157.3.67 with SMTP id 61mr5717796otv.347.1510583037675; Mon, 13 Nov 2017 06:23:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.13.74 with HTTP; Mon, 13 Nov 2017 06:23:56 -0800 (PST)
In-Reply-To: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  
From: Victor Kuarsingh 
Date: Mon, 13 Nov 2017 09:23:56 -0500
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: Ole Troan , "v6ops@ietf.org WG" ,  "6man@ietf.org" <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:24:00 -0000

On Mon, Nov 13, 2017 at 8:53 AM, Fernando Gont  wrote:
> On 11/13/2017 09:22 PM, Victor Kuarsingh wrote:
>> On Mon, Nov 13, 2017 at 4:21 AM, Fernando Gont  wrote:
>>> On 11/13/2017 11:07 AM, Ole Troan wrote:
>>
>>>
>>> If the implementation approach is as you've described, this is outside
>>> of the SLAAC specification, indeed (nobody can prevent you from spawning
>>> instances of SLAAC that behave according to the existing standards).
>>> >From a operational point of view, one would wonder why pursue this path
>>> as opposed to e.g. do DHCPv6 -- even if that means: we want to support
>>> Android, and Android does not support DHCPv6.
>>
>> My understanding is one of the authors is an operator and the model
>> represents operational experience and input on this.
>
> This doesn't answer the question I made above.

It was noted "From a operational point of view, one would wonder why
pursue this path as opposed to e.g. do DHCPv6".

What I am suggesting is the draft represents an actual operational
point of view from people in the field.

However, the methods described don't inhibit other choices to be made
in other networks, with perhaps other circumstances, to use DHCPv6.

regards,

Victor K

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


From nobody Mon Nov 13 06:27:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A16129A8D; Mon, 13 Nov 2017 06:27:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 h7EMv3MhAiXv; Mon, 13 Nov 2017 06:27:29 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F6B129A96; Mon, 13 Nov 2017 06:27:29 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e] (unknown [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 62B0580165; Mon, 13 Nov 2017 15:27:26 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Victor Kuarsingh 
Cc: Lorenzo Colitti , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
References:  <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>   
From: Fernando Gont 
Message-ID: 
Date: Mon, 13 Nov 2017 22:29:06 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:27:31 -0000

On 11/13/2017 10:17 PM, Victor Kuarsingh wrote:
> On Mon, Nov 13, 2017 at 8:51 AM, Fernando Gont  wrote:
>> On 11/13/2017 09:35 PM, Victor Kuarsingh wrote:
>>> On Mon, Nov 13, 2017 at 8:20 AM, Fernando Gont  wrote:
>>>> On 11/13/2017 07:14 PM, Lorenzo Colitti wrote:
>>>>> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont >>>> > wrote:
>>>>>
>>>>>     >From a operational point of view, one would wonder why pursue this path
>>>>>     as opposed to e.g. do DHCPv6
>>>>>
>>>>>
>>>>> As for DHCPv6 specifically, one reason is that DHCPv6-only networks are
>>>>> not recommended by the IETF. RFC 7934.
>>>>
>>>> Yes, sorry: I meant DHCPv6-PD.
>>>>
>>>> RFC7934:
>>>>
>>>>     Due to the drawbacks imposed by requiring explicit requests for
>>>>     address space (see Section 4), it is RECOMMENDED that the network
>>>>     give the host the ability to use new addresses without requiring
>>>>     explicit requests.  This can be achieved either by allowing the host
>>>>     to form new addresses autonomously (e.g., via SLAAC) or by providing
>>>>     the host with a dedicated /64 prefix.  The prefix MAY be provided
>>>>     using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
>>>>
>>>> Therefore, why re-invent PD in SLAAC?
>>>
>>> PD is quite vast, and this draft describes a specific set of use
>>> cases.  It does not seem like a re-invention of PD in SLACC to me.
>>
>> Again: Why not use DHCPv6-PD?
>>
> 
> I would leave this up to the operators to decide.

We are the ones trying to make SLAAC stateful, contributing to IPv6
automatic configuration complexity, and apparent lack of coherence with
respect to which protocol supports both, and why we e.g. disregard the
work of other WGs (e.g. dhc).

If you want to *partially* duplicate functionality in another protocol,
please provide a rationale, or don't.



> They are designing
> their network and know their requirements best.

Exactly: nobody specified the requirements, or said why DHCPv6-PD
doesn't fullfill them.



> There are many factors the weigh into why operators make certain
> decisions.  There are circumstances were DHCPv6-PD would be quite
> valid, and others, as described in the draft, where the methods
> described are desirable.  I don't think there is any one way to build
> a network (I am yet to have built two that look exactly the same given
> different input requirements).

You still have not answered my question.

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





From nobody Mon Nov 13 06:31:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7087129AB6 for ; Mon, 13 Nov 2017 06:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MXZRNnsXQ7O for ; Mon, 13 Nov 2017 06:31:40 -0800 (PST)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F80129744 for <6man@ietf.org>; Mon, 13 Nov 2017 06:31:19 -0800 (PST)
Received: by mail-it0-x235.google.com with SMTP id u132so9627069ita.0 for <6man@ietf.org>; Mon, 13 Nov 2017 06:31:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VkOyaR2ysMN4Bmt0qECIxldAWTTu2DhcKM8+3G8T5Nc=; b=YwafoHEq6KwWS10+MPIAkzB8NHRDmA5ep3usxrjLyIdZ/5LgffoIXOAU2kZUvPg4AD Y53Wm6w1xl9bJgFndmuUXFtaIDNLvFv8rv/tc3v3V/G+Os9tsaOD9OLoXXUK6Snfnwk4 ZN718x2U126dd5EwMo0j5EYqATdpqsqVc2iPfMBGwxpEqL90zLTaAiDZxyMbtFn1UGPk /umkYULVslq+NzHQkJrjVFmaU30iOm9iHDbZKng9wyuPeGwkOScPbxQdrLPH3nn/nm+C RHBLNiNwfVTaVdEx+VLDnP9w/ziVYz7qWCQL+N5mt4Ags2K5ZF1W/cdf5rdvXzzs4Rle +Jww==
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=VkOyaR2ysMN4Bmt0qECIxldAWTTu2DhcKM8+3G8T5Nc=; b=ICp/NxE4iizgjKdCCoiSRm7muQDv5JKKOznis95BUqoHPVdSYws+anJZ9wTsU7Iczt FIjaO15+8NY33VrIHMLSi2Xb3Vqw7onpFht5MvLsc9PvgBEGhNIngaCbhdfVxTW5dh0Y ZEZMmvZt5XnnWiHkOcURlLMSEyeEH7niafdlKWPDy/Num7R+JfeKNaxbyGO4sB5iR+bt lF8S6Zi9kbLG6DpqSKfZMRyCyXzcgftHUqxF7063cxpOjkemak3IWWGYPryUAGTtyTkQ ijJUU6o04IGQVtqj5j+VpAvHBYHVoF4DaWEQXcCTBdiVafx+oXddGQETRdK0w7+L7CwA 8gVg==
X-Gm-Message-State: AJaThX5McgBvq4UitlaXfEXywV7Nh3BkH76W5r9VSqskHJylNZTnmEeu 275KvAzlTrJgbQwyp3skimv3w8kPBCm1sqrOQsNWQQ==
X-Google-Smtp-Source: AGs4zMYEpqkRjl56wvvM3PXcPx8jp5MUd/4Fdj+u4RbIVBed6FdNIgb8/Vjg1rJYJIjOK+IytCnEZoFKbbNinyRB8XI=
X-Received: by 10.36.76.7 with SMTP id a7mr6062677itb.35.1510583478951; Mon, 13 Nov 2017 06:31:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.15.203 with HTTP; Mon, 13 Nov 2017 06:31:17 -0800 (PST)
Received: by 10.79.15.203 with HTTP; Mon, 13 Nov 2017 06:31:17 -0800 (PST)
In-Reply-To: 
References:  <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>    
From: Ted Lemon 
Date: Mon, 13 Nov 2017 22:31:17 +0800
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: Victor Kuarsingh , IPv6 Ops WG , "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="001a11448c12aac329055dde1fd8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:31:44 -0000

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

Fernando, the document is in AUTH48. If there is a technical problem with
it that is sufficient to pull it out of the publication queue at this
point, I haven't heard it yet. I think it would be nice to add a little
advice on how to manage the state, but it's up to the authors to do this or
not. This discussion is getting a bit old.

On Nov 13, 2017 22:27, "Fernando Gont"  wrote:

> On 11/13/2017 10:17 PM, Victor Kuarsingh wrote:
> > On Mon, Nov 13, 2017 at 8:51 AM, Fernando Gont 
> wrote:
> >> On 11/13/2017 09:35 PM, Victor Kuarsingh wrote:
> >>> On Mon, Nov 13, 2017 at 8:20 AM, Fernando Gont 
> wrote:
> >>>> On 11/13/2017 07:14 PM, Lorenzo Colitti wrote:
> >>>>> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont <
> fgont@si6networks.com
> >>>>> > wrote:
> >>>>>
> >>>>>     >From a operational point of view, one would wonder why pursue
> this path
> >>>>>     as opposed to e.g. do DHCPv6
> >>>>>
> >>>>>
> >>>>> As for DHCPv6 specifically, one reason is that DHCPv6-only networks
> are
> >>>>> not recommended by the IETF. RFC 7934.
> >>>>
> >>>> Yes, sorry: I meant DHCPv6-PD.
> >>>>
> >>>> RFC7934:
> >>>>
> >>>>     Due to the drawbacks imposed by requiring explicit requests for
> >>>>     address space (see Section 4), it is RECOMMENDED that the network
> >>>>     give the host the ability to use new addresses without requiring
> >>>>     explicit requests.  This can be achieved either by allowing the
> host
> >>>>     to form new addresses autonomously (e.g., via SLAAC) or by
> providing
> >>>>     the host with a dedicated /64 prefix.  The prefix MAY be provided
> >>>>     using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
> >>>>
> >>>> Therefore, why re-invent PD in SLAAC?
> >>>
> >>> PD is quite vast, and this draft describes a specific set of use
> >>> cases.  It does not seem like a re-invention of PD in SLACC to me.
> >>
> >> Again: Why not use DHCPv6-PD?
> >>
> >
> > I would leave this up to the operators to decide.
>
> We are the ones trying to make SLAAC stateful, contributing to IPv6
> automatic configuration complexity, and apparent lack of coherence with
> respect to which protocol supports both, and why we e.g. disregard the
> work of other WGs (e.g. dhc).
>
> If you want to *partially* duplicate functionality in another protocol,
> please provide a rationale, or don't.
>
>
>
> > They are designing
> > their network and know their requirements best.
>
> Exactly: nobody specified the requirements, or said why DHCPv6-PD
> doesn't fullfill them.
>
>
>
> > There are many factors the weigh into why operators make certain
> > decisions.  There are circumstances were DHCPv6-PD would be quite
> > valid, and others, as described in the draft, where the methods
> > described are desirable.  I don't think there is any one way to build
> > a network (I am yet to have built two that look exactly the same given
> > different input requirements).
>
> You still have not answered my question.
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


Fernando, the document is in AUTH48. If there is a techni=
cal problem with it that is sufficient to pull it out of the publication qu=
eue at this point, I haven't heard it yet. I think it would be nice to =
add a little advice on how to manage the state, but it's up to the auth=
ors to do this or not. This discussion is getting a bit old.=C2=A0

On Nov 13, 2017 22:2=
7, "Fernando Gont" <f=
gont@si6networks.com> wrote:
On 11/13/2017 10:17 PM, Victor Kuarsingh wrote:

> On Mon, Nov 13, 2017 at 8:51 AM, Fernando Gont <fgont@si6networks.com> wrote:

>> On 11/13/2017 09:35 PM, Victor Kuarsingh wrote:

>>> On Mon, Nov 13, 2017 at 8:20 AM, Fernando Gont <fgont@si6networks.com> wrote:

>>>> On 11/13/2017 07:14 PM, Lorenzo Colitti wrote:

>>>>> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont <fgont@si6networks.com

>>>>> <mailto:fg=
ont@si6networks.com>> wrote:

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0>From a operational point of vie=
w, one would wonder why pursue this path

>>>>>=C2=A0 =C2=A0 =C2=A0as opposed to e.g. do DHCPv6

>>>>>

>>>>>

>>>>> As for DHCPv6 specifically, one reason is that DHCPv6-=
only networks are

>>>>> not recommended by the IETF. RFC 7934.

>>>>

>>>> Yes, sorry: I meant DHCPv6-PD.

>>>>

>>>> RFC7934:

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0Due to the drawbacks imposed by requiri=
ng explicit requests for

>>>>=C2=A0 =C2=A0 =C2=A0address space (see Section 4), it is RE=
COMMENDED that the network

>>>>=C2=A0 =C2=A0 =C2=A0give the host the ability to use new ad=
dresses without requiring

>>>>=C2=A0 =C2=A0 =C2=A0explicit requests.=C2=A0 This can be ac=
hieved either by allowing the host

>>>>=C2=A0 =C2=A0 =C2=A0to form new addresses autonomously (e.g=
., via SLAAC) or by providing

>>>>=C2=A0 =C2=A0 =C2=A0the host with a dedicated /64 prefix.=
=C2=A0 The prefix MAY be provided

>>>>=C2=A0 =C2=A0 =C2=A0using DHCPv6 PD, SLAAC with per-device =
VLANs, or any other means.

>>>>

>>>> Therefore, why re-invent PD in SLAAC?

>>>

>>> PD is quite vast, and this draft describes a specific set of u=
se

>>> cases.=C2=A0 It does not seem like a re-invention of PD in SLA=
CC to me.

>>

>> Again: Why not use DHCPv6-PD?

>>

>

> I would leave this up to the operators to decide.



We are the ones trying to make SLAAC stateful, contributing to IPv6

automatic configuration complexity, and apparent lack of coherence with

respect to which protocol supports both, and why we e.g. disregard the

work of other WGs (e.g. dhc).



If you want to *partially* duplicate functionality in another protocol,

please provide a rationale, or don't.







> They are designing

> their network and know their requirements best.



Exactly: nobody specified the requirements, or said why DHCPv6-PD

doesn't fullfill them.







> There are many factors the weigh into why operators make certain

> decisions.=C2=A0 There are circumstances were DHCPv6-PD would be quite=


> valid, and others, as described in the draft, where the methods

> described are desirable.=C2=A0 I don't think there is any one way =
to build

> a network (I am yet to have built two that look exactly the same given=


> different input requirements).



You still have not answered my question.



--

Fernando Gont

SI6 Networks

e-mail: fgont@si6networks.com<=
br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492









_______________________________________________

v6ops mailing list

v6ops@ietf.org

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




--001a11448c12aac329055dde1fd8--


From nobody Mon Nov 13 06:32:58 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2D7129431; Mon, 13 Nov 2017 06:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 OZswdDl_PBCz; Mon, 13 Nov 2017 06:32:47 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7D0129576; Mon, 13 Nov 2017 06:32:32 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e] (unknown [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 474B68098C; Mon, 13 Nov 2017 15:32:30 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Victor Kuarsingh 
Cc: Ole Troan , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>   
From: Fernando Gont 
Message-ID: <38f6b6bf-8684-72f2-d191-52bb9cfb8c00@si6networks.com>
Date: Mon, 13 Nov 2017 22:33:48 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:32:51 -0000

On 11/13/2017 10:23 PM, Victor Kuarsingh wrote:
> On Mon, Nov 13, 2017 at 8:53 AM, Fernando Gont  wrote:
>> On 11/13/2017 09:22 PM, Victor Kuarsingh wrote:
>>> On Mon, Nov 13, 2017 at 4:21 AM, Fernando Gont  wrote:
>>>> On 11/13/2017 11:07 AM, Ole Troan wrote:
>>>
>>>>
>>>> If the implementation approach is as you've described, this is outside
>>>> of the SLAAC specification, indeed (nobody can prevent you from spawning
>>>> instances of SLAAC that behave according to the existing standards).
>>>> >From a operational point of view, one would wonder why pursue this path
>>>> as opposed to e.g. do DHCPv6 -- even if that means: we want to support
>>>> Android, and Android does not support DHCPv6.
>>>
>>> My understanding is one of the authors is an operator and the model
>>> represents operational experience and input on this.
>>
>> This doesn't answer the question I made above.
> 
> It was noted "From a operational point of view, one would wonder why
> pursue this path as opposed to e.g. do DHCPv6".
> 
> What I am suggesting is the draft represents an actual operational
> point of view from people in the field.
> 
> However, the methods described don't inhibit other choices to be made
> in other networks, with perhaps other circumstances, to use DHCPv6.

A point of view doesn't become, automagically, a BCP.

And I don't think that the IETF should increase complexity for no
reason. IPv6 automatic configuration is, aleady, enough of a mess to add
more on top of it.


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





From nobody Mon Nov 13 06:50:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B7F1289B5; Mon, 13 Nov 2017 06:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXLI99YiLOlN; Mon, 13 Nov 2017 06:50:36 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34D8127B52; Mon, 13 Nov 2017 06:50:35 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 F2C622D4F99; Mon, 13 Nov 2017 14:50:34 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 99450200BFBE5E; Mon, 13 Nov 2017 22:50:08 +0800 (+08)
From: Ole Troan 
Message-Id: <1CBBB814-CB4C-4A0F-92B7-9D2ECB98BC18@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_7E48012B-D9E0-4C07-90F6-C2A6BFD3292F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 22:50:07 +0800
In-Reply-To: 
Cc: Victor Kuarsingh , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
To: Fernando Gont 
References:  <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>    
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:50:38 -0000

--Apple-Mail=_7E48012B-D9E0-4C07-90F6-C2A6BFD3292F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Fernando,

>> I would leave this up to the operators to decide.
>=20
> We are the ones trying to make SLAAC stateful, contributing to IPv6
> automatic configuration complexity, and apparent lack of coherence =
with
> respect to which protocol supports both, and why we e.g. disregard the
> work of other WGs (e.g. dhc).
>=20
> If you want to *partially* duplicate functionality in another =
protocol,
> please provide a rationale, or don't.

repeating something enough times doesn't make it true.

>> They are designing
>> their network and know their requirements best.
>=20
> Exactly: nobody specified the requirements, or said why DHCPv6-PD
> doesn't fullfill them.

this is for public WIFI. hosts are unchanged. DHCPv6 PD is a non-starter =
deployment wise.

>> There are many factors the weigh into why operators make certain
>> decisions.  There are circumstances were DHCPv6-PD would be quite
>> valid, and others, as described in the draft, where the methods
>> described are desirable.  I don't think there is any one way to build
>> a network (I am yet to have built two that look exactly the same =
given
>> different input requirements).
>=20
> You still have not answered my question.

with regards to complexity. from a ND/SLAAC perspective this is a lot =
simpler. not more complex. don't make things up.
no address resolution, no ND cache, no need to rewrite L2 multicast to =
unicast and maintain state in WLCs/APs... I could go on.

I think it is time to shelf this discussion now.

Ole


--Apple-Mail=_7E48012B-D9E0-4C07-90F6-C2A6BFD3292F
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+/bDNdvtpYqJhC33YFAloJsR8ACgkQvtpYqJhC
33bNug//X8h07M/iGwvI/VmQYeKiuM7nMNxcREJw59Ud+mV7hsIbPNwV9zqUK4/I
6mPTNK7oa/EjMl3oDgN13stv8o0MCOnDSuf9u/+5XrvZf4TSZgFdxztG+OXPSdWm
gFTLUZB5KQxBgN+99G8e3PljktrJLr/BGD8xPHM1VEuiTClPT1RZkJuNcj8FQvhB
8Guq262BfduhsKeWaVb0zA+HA8CfEC/D9RGBI0LYZwYEG/GcAuZEOO718Tl6mLRg
fSLVnsM8XxLIQnY5Xsb28artt0bLblT5Uvdws0g3YpcCy7MA9aHToPNuSMbwUGt3
DtyaZ1SAfI0WwygsRsU6z1eJA5UXOxgpiA7tWy03j3vda+kdCfUpGTPHaceO+3j5
jmCVMjeAqcD6IDe0a/jPa4efxZgpkd7XX+dXGC/sdMb6+6bUKTVHNBm47nX9jXzv
M5i+uD4GHT1yfLzaKlBEwJMS1iHW/iAn1qVMkqJ2pnQvzPh5N22uIelKNfnNh+5T
xbh395Kr6Ff2an6kW9Vd7MpZLhQMN84qjfJM54FxHN56A1rbXS3TqNIs+tQTpRt1
xp11fhqeWmpVFSMEpaytEMAH+81G+vG/ghofhwMyx81R6qjDiVM7HcaMdRuMuATp
PX59E1adfg0XixyzxPId1fMHvcHvicDm8qbwF1PaxhrYeHjMcGg=
=2w+k
-----END PGP SIGNATURE-----

--Apple-Mail=_7E48012B-D9E0-4C07-90F6-C2A6BFD3292F--


From nobody Mon Nov 13 06:55:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EB0129AB7; Mon, 13 Nov 2017 06:55:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ODWeDq7lzULm; Mon, 13 Nov 2017 06:55:44 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1463F127B52; Mon, 13 Nov 2017 06:55:44 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e] (unknown [IPv6:2001:67c:1232:144:ed68:7911:ebe1:178e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 24AE780747; Mon, 13 Nov 2017 15:55:40 +0100 (CET)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ted Lemon 
Cc: Victor Kuarsingh , IPv6 Ops WG , "6man@ietf.org" <6man@ietf.org>
References:   <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>     
From: Fernando Gont 
Message-ID: 
Date: Mon, 13 Nov 2017 22:57:24 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:55:45 -0000

Ted,

On 11/13/2017 10:31 PM, Ted Lemon wrote:
> Fernando, the document is in AUTH48. If there is a technical problem
> with it that is sufficient to pull it out of the publication queue at
> this point, I haven't heard it yet. I think it would be nice to add a
> little advice on how to manage the state, but it's up to the authors to
> do this or not. This discussion is getting a bit old. 

The technical problem is that this is a v6ops document making SLAAC
stateful. As discussed, making SLAAC stateful brings breakage scenarios
not present in SLAAC, and that is certainly not a minor change.

And having folks noted that they have implemented this sort of behavior
without changing SLAAC, the low-level protocol details in Section 4 are
even less unwarranted.

It is not my call what's the proper action. But I do note that this is
yet another BCP that rather that essentially disregards work of other wg
(dhc), unnecessarily. Are you are pushing a BCP with a mechanism that is
so underspecified, that folks meaning to implement this are likely to
introduce breakage.

That said, it is not my call what's the proper action to follow. My
intent (noted to e.g. Suresh off-line) is not to obstruct the document,
but to avoid breakage -- particularly when it's unwarranted.

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





From nobody Mon Nov 13 06:56:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79D6128CD5 for ; Mon, 13 Nov 2017 06:56:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jvknet-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftq8h7sJuF1A for ; Mon, 13 Nov 2017 06:56:14 -0800 (PST)
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 60FDE129A84 for <6man@ietf.org>; Mon, 13 Nov 2017 06:56:14 -0800 (PST)
Received: by mail-oi0-x233.google.com with SMTP id h81so5840565oib.8 for <6man@ietf.org>; Mon, 13 Nov 2017 06:56:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9qAts52zhFFeQZI+a2GVVKRcgo4q598oXj7nLVQHL84=; b=D8sskFO7AYqmrgGJWltznRT+MzIIeffZ3KW3RPeAa5eO3c1frmx41ZB6x+cSbjV3Wj P0nbJvkOgCKC2yh0rC/h8/RCIxUe86ndqOsu2GEOZeELH5k7ZGVsC6HoMpicNltPJxJV uIpv1bvgj8GNDStvBiyBueT8uSyYUgjVUJ6wlIBEDn96uNixdP+Zx2k7y5IMV9EtaiqT /qEQBPV3FoxwkE63t8Xu7omCADTvVHKRWFDpoCZ43qkiWqheidq30uvhEjudqSd6uLp7 1PE8cbbDZx9oL/hXn7emmGUs//ZCJPBqSf3hNnHGVO/kNfzMpCIxX0PgDboIXFS0lFUL fAcQ==
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=9qAts52zhFFeQZI+a2GVVKRcgo4q598oXj7nLVQHL84=; b=OGRJ+iNHK1So22v2vnd6uG6fSBbIhT3kzPmUZEIiEO0z4k5idHQxQq6SXXpHHcW1Cq 6q+9dwB9lKRlM4xl9RtZfW4wzXshZm1z0OCLTtwpRy0ga5nLc2bWMfv0F/IZu9iD0COe IVo7J2hYpU/Hmq8aJkTE3A6NBWRbcGHDwBvRthgIuIiYkArYUv/kiekRfKtcNORYcVNG 9h7vIeU7XUxGRytnRv61iY7r6JT92SHSN9D2ciNhsmypt1Teexohfqtig5NricRKPB6p 1NOQlYWd3BzVbEu1uymP2wYCuK6KL1lpuOIgEW5fh/b9EhLcOwB+M24KNc+faTXjyUiT BOJQ==
X-Gm-Message-State: AJaThX6x/CzlIl1xUi7pfMaAlwD9zcMDKGAuX+y7wgyrS9FLRbykhWV2 I4xddga8dGGMa39PaJDzsAMVHfZMNTVsUz3Gg2vHqg==
X-Google-Smtp-Source: AGs4zMZw1x4NKKqQunVzbwtkQ5fVyqQ5ZzBlj49p0nUl6q23nXMxJKnKeqvkBsfqPe0MxBFulhoGnimx5MzWkLrfr00=
X-Received: by 10.202.77.200 with SMTP id a191mr51523oib.86.1510584973416; Mon, 13 Nov 2017 06:56:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.13.74 with HTTP; Mon, 13 Nov 2017 06:56:12 -0800 (PST)
In-Reply-To: 
References:  <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>    
From: Victor Kuarsingh 
Date: Mon, 13 Nov 2017 09:56:12 -0500
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: Lorenzo Colitti , "6man@ietf.org" <6man@ietf.org>,  "v6ops@ietf.org WG" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:56:17 -0000

On Mon, Nov 13, 2017 at 9:29 AM, Fernando Gont  wrote:
> On 11/13/2017 10:17 PM, Victor Kuarsingh wrote:
>> On Mon, Nov 13, 2017 at 8:51 AM, Fernando Gont  wrote:
>>> On 11/13/2017 09:35 PM, Victor Kuarsingh wrote:
>>>> On Mon, Nov 13, 2017 at 8:20 AM, Fernando Gont  wrote:
>>>>> On 11/13/2017 07:14 PM, Lorenzo Colitti wrote:
>>>>>> On Mon, Nov 13, 2017 at 6:21 PM, Fernando Gont >>>>> > wrote:
>>>>>>
>>>>>>     >From a operational point of view, one would wonder why pursue this path
>>>>>>     as opposed to e.g. do DHCPv6
>>>>>>
>>>>>>
>>>>>> As for DHCPv6 specifically, one reason is that DHCPv6-only networks are
>>>>>> not recommended by the IETF. RFC 7934.
>>>>>
>>>>> Yes, sorry: I meant DHCPv6-PD.
>>>>>
>>>>> RFC7934:
>>>>>
>>>>>     Due to the drawbacks imposed by requiring explicit requests for
>>>>>     address space (see Section 4), it is RECOMMENDED that the network
>>>>>     give the host the ability to use new addresses without requiring
>>>>>     explicit requests.  This can be achieved either by allowing the host
>>>>>     to form new addresses autonomously (e.g., via SLAAC) or by providing
>>>>>     the host with a dedicated /64 prefix.  The prefix MAY be provided
>>>>>     using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.
>>>>>
>>>>> Therefore, why re-invent PD in SLAAC?
>>>>
>>>> PD is quite vast, and this draft describes a specific set of use
>>>> cases.  It does not seem like a re-invention of PD in SLACC to me.
>>>
>>> Again: Why not use DHCPv6-PD?
>>>
>>
>> I would leave this up to the operators to decide.
>
> We are the ones trying to make SLAAC stateful, contributing to IPv6
> automatic configuration complexity, and apparent lack of coherence with
> respect to which protocol supports both, and why we e.g. disregard the
> work of other WGs (e.g. dhc).

I don't see how this work has any impact on what was done in DHC and
disregards it.  We potentially conflating things here?

Much in the same way RFC8106 (DNS info in RAs) does not disregard
DHCPv6 since it too can offer DNS information.

>
> If you want to *partially* duplicate functionality in another protocol,
> please provide a rationale, or don't.

Same point as above.  Some apparent duplication may exist, but these
are also two different deployment models. There are reasons why
operators choose one or the other model.  Telling them to use a
different model is not a valid rebuttal in my mind.

>
>
>
>> They are designing
>> their network and know their requirements best.
>
> Exactly: nobody specified the requirements, or said why DHCPv6-PD
> doesn't fullfill them.

What if operator does not have a DHCPv6 service for that access
network? (not saying this was driver for draft, but this is one
example).  Adding in a robust DHCPv6 service is not always trivial, so
if an operator is desiring to have this (/64 per host) capability,
while potentially keeping their service deployment framework SLACC,
why are we objecting to it?  SLAAC is a viable model to use, and the
draft describes the reasons for wanting a /64 per host.  So it seems
clear to me.

To exemplify, (maybe too far out of context),

If I asked for an extension to IS-IS for my deployment, and you told
me to use OSPF because that option was already there, my response
would be - "I am not using OSPF".

>
>
>
>> There are many factors the weigh into why operators make certain
>> decisions.  There are circumstances were DHCPv6-PD would be quite
>> valid, and others, as described in the draft, where the methods
>> described are desirable.  I don't think there is any one way to build
>> a network (I am yet to have built two that look exactly the same given
>> different input requirements).
>
> You still have not answered my question.

The operator has chosen to use a SLACC model, they need/want the
robustness/capability from a /64 per host.  So, if that's the case,
what DHCPv6 has to offer is not relevant   to what the operator would
need in this case.  A direct quote form the draft seems to also show
one of the reasons (others reasons can exist or may exist in future)

"To not exclude any known IPv6
   implementations, IPv6 SLAAC based subscriber and address management
   is the recommended technology to reach highest percentage of
   connected IPv6 devices on a provider managed shared network service."



regards,

Victor K



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


From nobody Mon Nov 13 06:56:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A667D129AD4 for ; Mon, 13 Nov 2017 06:56:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7zF0-SXvYyX for ; Mon, 13 Nov 2017 06:56:17 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FA3128CD5 for ; Mon, 13 Nov 2017 06:56:17 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 E06F82D4F99; Mon, 13 Nov 2017 14:56:16 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C8E88200BFC237; Mon, 13 Nov 2017 22:55:51 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_BA113047-D14C-46A8-9404-4204542A0231"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 13 Nov 2017 22:55:50 +0800
In-Reply-To: 
Cc: Tim Chown , 6man WG 
To: Ca By 
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk> 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:56:20 -0000

--Apple-Mail=_BA113047-D14C-46A8-9404-4204542A0231
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Cameron,

> > @Ole, I agree. Just swap the RFC#.
> >
> >>> - Must be able to do NAT64 prefix discovery (RFC6052)
> >>> - Synthesise IPv6 address from an IPv4 literal (RFC7050)
> >
> >
> > @Tim,
> >
> >> If someone wishes to propose text in a new section 10.2 on =
=E2=80=9CIPv6-only=E2=80=9D operation, we could include that if the WG =
agrees.  This
> >
> > It might be useful to have some text in section 14 (v6 router) to =
accommodate v4 hosts/apps in case of v6-only uplink/ WAN.
>=20
> I think the trick for 6434bis is deciding what the scope of the doc =
is. Such suggestions, while they certainly have merit, are a slippery =
slope to adding many things, as we=E2=80=99ve seen when Jordi started =
proposing transition mechanisms for RFC7084-bis.
>=20
> Yes , slippery slope indeed. And you would have to deal with me =
opposing the case being included.
>=20
> I have a network with 10s of millions of ipv6-only nodes, none of =
which can so dnssec (neither android nor ios support it) and the =
implication that these nodes are no longer ipv6 since they don't do =
dnssec is ludicrous.
>=20
> i think this is just folks tryjng to raise the bar against nat64, =
again, with nonesense usecass that users and operators don=E2=80=99t =
want or care about.

I wanted to put the DNSSEC requirement out there. After having talked =
with a few people here, it seems doing validation on a off-box resolver =
isn't any worse than what's typically done today. I wouldn't mind =
dropping that requirement.

You appear to have missed the two other requirements I suggested in the =
original email?
This wouldn't be the exact opposite of raising the bar against NAT64. It =
would be to try to ensure NAT64 worked for all IPv6 only nodes.

Cheers,
Ole

--Apple-Mail=_BA113047-D14C-46A8-9404-4204542A0231
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+/bDNdvtpYqJhC33YFAloJsnYACgkQvtpYqJhC
33amig/+PJamE6oOFxVzMyPNW1/EgH94XX8GLlfp5A9T0B+PLZB1iglYADzl/gGj
GMkCoXwkwAh+baZSJUxsCiyhiU6WPXUVS8NEdQsycLdrErba24EbZfwODzJf2RZi
Z9jS6kuGo7fO0NNexSoZ4VJ0zIeELVFGcjFIVP5Mlwx/lPSWuwZVAqZtvl0lt8A+
7e5UapFVzaLG641MCwH5smkQbHLdzmE+Mg8WPq48Ktt7djbdDq0tdFrNLqXQGxKK
bF/1oRtRoF/SDTylLAGHPHqFFnoiuzWDROSrS9YiKi9yUpPA6V7GHFSZC1KXCQDU
Tdn3ADPMS1NnzUK4V68RTN+jQngpeqWt3WyBwNzZesc/7m0WKndxTBRPzM4kqupc
oON8wcT3SsiIoTdu/fGlTz/JtS0GR+iooGjn8R28dUQd/4qA/VXicq1SfbJLbjQg
g1auJTa9IaVHPQZrQm3r/b8xa9ZzHnTkXXCZljk6VNTN/YCukVqhe6FtvuQQ0BRV
F7SnMB5Qospd8tlbc+OXQrwVwlDzX2RpkMFGjRklcLYiiV+3/fPrFlqN4ATT8lw5
arq4t2W8GQ+vzzEaCM+xXLvbv4hviUmXVvrW5M6wEWFHWf+dqLase2TfwxKMSFOE
OpB0ZzCnpz9TJoCv9jMqWglOlRytm6ErcLIOjuyh4+pvIcwoFDU=
=IbqX
-----END PGP SIGNATURE-----

--Apple-Mail=_BA113047-D14C-46A8-9404-4204542A0231--


From nobody Mon Nov 13 06:58:09 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5300B129A84 for ; Mon, 13 Nov 2017 06:57:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxyOeg333aAJ for ; Mon, 13 Nov 2017 06:57:58 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5056E129ABE for <6man@ietf.org>; Mon, 13 Nov 2017 06:57:52 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id r127so9621524itb.5 for <6man@ietf.org>; Mon, 13 Nov 2017 06:57:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hY/VbeZfB+A/COXAiLofQgw97/lbhtfwPWXLrTlmY7Y=; b=zapdb6b59Td2VcFc57kBBhS1367fs2eX0BIZR6bOHFpP2/kwAlH3536fMrgSNsLlWa PtOTNmjnioIR8dqMaexKNmo95IVfdKCECvrqkSkR1LurOrSnz7UTeTTw0juYDwMauF6b 54lrrMUFbsJqj1I/QnHgjaWtSh1OPmrzJqFyJFl63n2V9Qx4v+TSswNFUbrCyq7k1aff 6C2scu9G/OKxKdWB/Rbx/pW8smE5N87/Zw3MlTi5yszDRqEogEMkAOcaxgVcrQG+QH4u 3cTBY8hetaYzUDnzpF3LFPVYS7rxBbISSPBLGW7QZ/mdLuoMBl/V8R+OiOy3SkQXQpSS nWEw==
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=hY/VbeZfB+A/COXAiLofQgw97/lbhtfwPWXLrTlmY7Y=; b=g38rol+BSrdqOVaJ9b8vX81WVuzivwzZtyRFTv0/VLrbmzcUiamdGmdKhn7VWfyVQ4 wRm6RYmtW3PiCo/xMxsfGDRt6+qeyG3vKFk4oVhXHuYwWKOtcgJZRrJF1FjD9rhXaMwa Y97d5KhDGrag2rQB1bS9y3AB1EPv4B0/vkhkAUHsSKq25E4kvvA1Qua8znIALHUO5vw1 +/T3MPEsMZ8KE0JUeMNq1zxrSqtSuPVhNLYf2KNdfJ0RgrX7vjFf40wFM0NQYCE0vTGh w2GW8sbJ6TukfqPNqa8/Fxu755wUh5MgnjAVaJWQmylFIoyFhYa5pjf077tBM6XSBVfa lmNQ==
X-Gm-Message-State: AJaThX54Z2fn1G5swXv4CKadn93WiooLYaVD7GqOUoUGZQUmitlcesHP p7GCuM+fx4k16jaj8b41hIHoPkJKDFvb7/5kJTuTkw==
X-Google-Smtp-Source: AGs4zMbTbcRgVzkOvj4gmHYtg6RhH0gq0QIYnzlD7QQM4FdF/cTtTt/5eFesJzU5T0ps/QkcM2LWlTWj7WKoGtflJJg=
X-Received: by 10.36.76.7 with SMTP id a7mr6171776itb.35.1510585071562; Mon, 13 Nov 2017 06:57:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.15.203 with HTTP; Mon, 13 Nov 2017 06:57:50 -0800 (PST)
Received: by 10.79.15.203 with HTTP; Mon, 13 Nov 2017 06:57:50 -0800 (PST)
In-Reply-To: 
References:   <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>      
From: Ted Lemon 
Date: Mon, 13 Nov 2017 22:57:50 +0800
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: Victor Kuarsingh , IPv6 Ops WG , "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="001a11448c1297fd95055dde7e92"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:57:59 -0000

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

It doesn't make slaac stateful.

On Nov 13, 2017 22:55, "Fernando Gont"  wrote:

> Ted,
>
> On 11/13/2017 10:31 PM, Ted Lemon wrote:
> > Fernando, the document is in AUTH48. If there is a technical problem
> > with it that is sufficient to pull it out of the publication queue at
> > this point, I haven't heard it yet. I think it would be nice to add a
> > little advice on how to manage the state, but it's up to the authors to
> > do this or not. This discussion is getting a bit old.
>
> The technical problem is that this is a v6ops document making SLAAC
> stateful. As discussed, making SLAAC stateful brings breakage scenarios
> not present in SLAAC, and that is certainly not a minor change.
>
> And having folks noted that they have implemented this sort of behavior
> without changing SLAAC, the low-level protocol details in Section 4 are
> even less unwarranted.
>
> It is not my call what's the proper action. But I do note that this is
> yet another BCP that rather that essentially disregards work of other wg
> (dhc), unnecessarily. Are you are pushing a BCP with a mechanism that is
> so underspecified, that folks meaning to implement this are likely to
> introduce breakage.
>
> That said, it is not my call what's the proper action to follow. My
> intent (noted to e.g. Suresh off-line) is not to obstruct the document,
> but to avoid breakage -- particularly when it's unwarranted.
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>

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


It doesn't make slaac stateful.=C2=A0

On Nov 13, 2017 22:55, &quo=
t;Fernando Gont" <fgont@si=
6networks.com> wrote:
Ted,



On 11/13/2017 10:31 PM, Ted Lemon wrote:

> Fernando, the document is in AUTH48. If there is a technical problem
> with it that is sufficient to pull it out of the publication queue at<=
br>
> this point, I haven't heard it yet. I think it would be nice to ad=
d a

> little advice on how to manage the state, but it's up to the autho=
rs to

> do this or not. This discussion is getting a bit old.



The technical problem is that this is a v6ops document making SLAAC

stateful. As discussed, making SLAAC stateful brings breakage scenarios

not present in SLAAC, and that is certainly not a minor change.



And having folks noted that they have implemented this sort of behavior

without changing SLAAC, the low-level protocol details in Section 4 are

even less unwarranted.



It is not my call what's the proper action. But I do note that this is<=
br>
yet another BCP that rather that essentially disregards work of other wg
(dhc), unnecessarily. Are you are pushing a BCP with a mechanism that is
so underspecified, that folks meaning to implement this are likely to

introduce breakage.



That said, it is not my call what's the proper action to follow. My

intent (noted to e.g. Suresh off-line) is not to obstruct the document,

but to avoid breakage -- particularly when it's unwarranted.



--

Fernando Gont

SI6 Networks

e-mail: fgont@si6networks.com<=
br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492












--001a11448c1297fd95055dde7e92--


From nobody Mon Nov 13 07:04:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C096128CD5; Mon, 13 Nov 2017 07:04:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=psc.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 TUyv-eg_M3OG; Mon, 13 Nov 2017 07:04:06 -0800 (PST)
Received: from mailer2.psc.edu (mailer2.psc.edu [128.182.70.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A431289B5; Mon, 13 Nov 2017 07:04:06 -0800 (PST)
Received: from dengue.psc.edu (dengue.psc.edu [128.182.160.217]) (authenticated bits=0) by mailer2.psc.edu (8.14.7/8.14.7) with ESMTP id vADF45wC025272 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Nov 2017 10:04:05 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 mailer2.psc.edu vADF45wC025272
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=psc.edu; s=default; t=1510585445; bh=81UMmOoz9uzO5ebtltRtyUCO+S0Adn9TI89ME3Ia5hs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=RnWs4engaauMsuy9Wp6HzYvpSpO26jgWoFBYFiASCpl0Z5KnelppQpX0zSx/gPSRL tFbj+ozAB6TkB8u6RDytvkCIwLH7cRlhHiUQwtyGm5/tmgODYbchF+zJjKP9Kitmel viP5hxVqew/J8T9YuW+hcSFWvGvngp1D4AtJRX5o=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: Michael H Lambert 
In-Reply-To: 
Date: Mon, 13 Nov 2017 10:04:09 -0500
Cc: "6man@ietf.org" <6man@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <15D40EE6-1715-49F7-96DA-AF781995FAE4@psc.edu>
References:  <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>     
To: IPv6 Ops WG 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:04:08 -0000

> On 13 Nov 2017, at 09:31, Ted Lemon  wrote:
>=20
> Fernando, the document is in AUTH48. If there is a technical problem =
with it that is sufficient to pull it out of the publication queue at =
this point, I haven't heard it yet. I think it would be nice to add a =
little advice on how to manage the state, but it's up to the authors to =
do this or not. This discussion is getting a bit old.=20

I do have a question which I don't see addressed (no pun intended) in =
the draft.  The text only refers to THE first-hop router on the network. =
 If there are multiple routers on the network which can respond to =
router solicitations, do they act independently in providing prefixes to =
the requesting hosts?  If so, how do they (or do they) guarantee =
uniqueness?  If not, do they need to share any additional state?

Michael


From nobody Mon Nov 13 07:14:25 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86095129421 for ; Mon, 13 Nov 2017 07:14:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Xmh9SekqmS7s for ; Mon, 13 Nov 2017 07:14:15 -0800 (PST)
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 471EC12944A for <6man@ietf.org>; Mon, 13 Nov 2017 07:14:15 -0800 (PST)
Received: by mail-it0-x22d.google.com with SMTP id 72so9777700itl.5 for <6man@ietf.org>; Mon, 13 Nov 2017 07:14:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o0ViJReLWVl3ndBkIXA/LI/PdxoHbn/ZqZ5mWvhYVJg=; b=CTsnhzlZ0iT6LVKghEFoAbxHjp8zLFrLpGWlXBRIXOXL8Gkp7cBdBKgMhJiR3awXwP IoBuFtXaCWPUL6rRKuHymsUCe9eNx6UDDfjA6e0hRvjSL2EXQGNV4gAjGJlOFB9T6K1a QgxiG2rYuDRHc5epG//cSAf3atHvnym1QfJMAy2ym1SzDcdDSg/66tM6pnnD9eI4Zeb/ qRcDsGie29/ONaqVh5OcMzF9rK2EJj9S6zLj1lQ1+9XLSEWB5tAz4pLhovvsvPAlvArX WVePkCOShkwPu/86UTdPKNWYBtZZnrfmGf/XIvfIhA56iDI1WpEqFgIcCrmqzWSnAVou ZmoQ==
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=o0ViJReLWVl3ndBkIXA/LI/PdxoHbn/ZqZ5mWvhYVJg=; b=RrxPt0xvN/h6PLLn7GrQZTqVMKe0UR9gx8f2fPcYG0AbcDdInV4Utyuv/35fybqFdX hXQr4paSIb5uwPkYxZfq7QaqYN2CbnJko7lq/gCCimJoBiO2if1uYhC3tgspMuJ7I7e7 +EpX7jZ1V3GnOZtNMcQEEMVdMYLoc7gGYv0gN317GQWBVkETuT5KPBnuzFn3Wat1y/v/ ei1k1+oocm+9r+26huUa5Fwasn5uzTxqJ+XT72ITvKk0Ssc2KykvCCQGP5OetRg+9Q5R acOG/6E8KP3Fr95oPwMlnHe1gVuWpp+x9hxVum02w5y2ZACOmz1PjJeUmKhMl8uwLqQ1 mbnw==
X-Gm-Message-State: AJaThX6X9sNuxYyPctJL/hKdXTCAa/LGON1p3ikFH2JIHc3PFkthMQbW kDA8mdukVdt1xPUXfqEwl7B8T0mUM61jh28J7oJK6yQD
X-Google-Smtp-Source: AGs4zMbM5zApVNu1C8ejVikakVOVchNGVGtmv2vbKB6jH+EPHVoXWMAkt3pyFaG4O6aonSgusmlhGv1x9UAd/UdVCY8=
X-Received: by 10.36.88.72 with SMTP id f69mr10333706itb.129.1510586054158; Mon, 13 Nov 2017 07:14:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Mon, 13 Nov 2017 07:13:53 -0800 (PST)
In-Reply-To: <5A0999A4.3040807@foobar.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <5A0999A4.3040807@foobar.org>
From: Lorenzo Colitti 
Date: Tue, 14 Nov 2017 00:13:53 +0900
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Nick Hilliard 
Cc: Fernando Gont , "6man@ietf.org" <6man@ietf.org>,  "v6ops@ietf.org WG" 
Content-Type: multipart/alternative; boundary="001a1144d01e29d959055ddeb9f5"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:14:17 -0000

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

On Mon, Nov 13, 2017 at 10:09 PM, Nick Hilliard  wrote:

> >     >From a operational point of view, one would wonder why pursue this
> path
> >     as opposed to e.g. do DHCPv6
> >
> > As for DHCPv6 specifically, one reason is that DHCPv6-only networks are
> > not recommended by the IETF. RFC 7934.
>
> reminder: there is no WG consensus that this is what RFC 7934 means.
>

Actually, IIRC the thread you started a couple of months ago reaffirmed
that consensus. (The document does not state that DHCPv6 address assignment
is not recommended, it only states that networks that *only* use DHCPv6
address assignment are not recommended.)

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


On M=
on, Nov 13, 2017 at 10:09 PM, Nick Hilliard <nick@foobar.org> wrote:
>=C2=A0 =C2=
=A0 =C2=A0>From a operational point of view, one would wonder why pursue=
 this path

>=C2=A0 =C2=A0 =C2=A0as opposed to e.g. do DHCPv6

>

> As for DHCPv6 specifically, one reason is that DHCPv6-only networks ar=
e

> not recommended by the IETF. RFC 7934.



reminder: there is no WG consensus that this is what RFC 7934 means.=


Actually, IIRC the thread you started =
a couple of months ago reaffirmed that consensus. (The document does not st=
ate that DHCPv6 address assignment is not recommended, it only states that =
networks that *only* use DHCPv6 address assignment are not recommended.)


--001a1144d01e29d959055ddeb9f5--


From nobody Mon Nov 13 07:17:26 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050CF129454; Mon, 13 Nov 2017 07:17:19 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -1.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 Grf8iFspwgVe; Mon, 13 Nov 2017 07:17:17 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AE1129AC1; Mon, 13 Nov 2017 07:17:16 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEGU6-0000GEC; Mon, 13 Nov 2017 16:17:14 +0100
Message-Id: 
To: v6ops@ietf.org
Cc: Victor Kuarsingh 
Cc: Fernando Gont , "6man@ietf.org" <6man@ietf.org>
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
References:  <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>      
In-reply-to: Your message of "Mon, 13 Nov 2017 09:56:12 -0500 ."  
Date: Mon, 13 Nov 2017 16:17:13 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:17:19 -0000

>I don't see how this work has any impact on what was done in DHC and
>disregards it.  We potentially conflating things here?
>
>Much in the same way RFC8106 (DNS info in RAs) does not disregard
>DHCPv6 since it too can offer DNS information.

There is an interesting dynamics in that any new feature for RA that is a 
essentially a duplicate from what already exists in DHCPv6 gets accepted,
but a simple feature like a default router option in DHCPv6 gets rejected
time and time again because that feature is already provided by RA.


From nobody Mon Nov 13 07:24:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50532129454 for ; Mon, 13 Nov 2017 07:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TzdMnzND3yF for ; Mon, 13 Nov 2017 07:24:46 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD06129449 for ; Mon, 13 Nov 2017 07:24:45 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEGbJ-0000EhC; Mon, 13 Nov 2017 16:24:41 +0100
Message-Id: 
To: ipv6@ietf.org
Subject: Re: IPv6 only host NAT64 requirements? 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
In-reply-to: Your message of "Mon, 13 Nov 2017 10:50:40 +0800 ." <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> 
Date: Mon, 13 Nov 2017 16:24:30 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:24:47 -0000

In your letter dated Mon, 13 Nov 2017 10:50:40 +0800 you wrote:
>If this is the direction we want to go. Encourage IPv6 only host 
>deployments (as opposed to dual stack hosts), are these requirements 
>we'd like to add to the IPv6 node requirements document? Somewhere else

Personally I don't like how NAT64 requires an IPv6 stack to deal with all
kinds of IPv4 issues. So for IPv6 node requirements, it should not go
beyond the level of MAY.



From nobody Mon Nov 13 07:34:03 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF396129449 for ; Mon, 13 Nov 2017 07:34:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 miOAFcNLLkwi for ; Mon, 13 Nov 2017 07:34:00 -0800 (PST)
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 E9DCE129AC1 for <6man@ietf.org>; Mon, 13 Nov 2017 07:33:59 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id 4DBF15B0 for <6man@ietf.org>; Mon, 13 Nov 2017 15:33:59 +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 vBHNSbRxION2 for <6man@ietf.org>; Mon, 13 Nov 2017 09:33:59 -0600 (CST)
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 E896587A for <6man@ietf.org>; Mon, 13 Nov 2017 09:33:58 -0600 (CST)
Received: by mail-lf0-f69.google.com with SMTP id m74so2514373lfg.6 for <6man@ietf.org>; Mon, 13 Nov 2017 07:33:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7xK1BAZybyMnDCg9U/mLC+lSPtVq0YNJCYZWHwhqQEk=; b=NhkQV5Ob0UZl6qUsNQwBnoAdncjlgUbwm2mcicn2cKI7A1nnelKn1TnlYuXQT93fdG zqQPA54bgXpyv5a7j6FNeJlKeENgt8WY9UxotGKVqahDE3EBTD/Tn9hFwX9qU1l2P9kE qSzfMaOjxN7Gc0pH63Cy88HHKN/G9jM6IsoAJupUG39BRpPOhtiNlYv1QMgWHCWtA+Pl 7mxQywiMr6FhgciK0m+hkOsNtj88hsz0YNKnSNrXfPtrp2jCFx4SSbey3SJOljmIk154 DG3HYmpKIQDSv/cLpOIt191p5xauf7O+aN++7IiWIktsJKZ8KORrPHxwAn/DsEYGdES9 O2YA==
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=7xK1BAZybyMnDCg9U/mLC+lSPtVq0YNJCYZWHwhqQEk=; b=tg0UVrH0uihW3YpazuiSDITZJrMubUy+v25eE/DdXbuU7ACouagRUDyPWPqmq+fERI 6G1HllwCVWamIi+i4aGT8BilbzV2C1MZQzkd05JbqZ02tFXTqqNaXuXcg3HACN2gvHyH ZV5eAQcn4O99KSUsQgbe6eEcxarbKYl12qqa29wTXkuo13otrk4XuIkeqTmtasLWrCLx DjGBihPe7tEa2Sap/QQK5suXr/dD+Roy1pkIyKvC9L+16HGjUiz18boUD7nlqdhccbnO bPWbTUnUDJi1i90ZbZHAkUjm/X6wHxG34RGIgybKw5IK+AURQe8uN+VjvNlWJY17ZM6F 8yYg==
X-Gm-Message-State: AJaThX76djuHI5Ouwf4D6ohcgRftBZd3P7VoF2BTol//V2doptXoH2lS WF7DuERWl9dX57WBYDGm0siCS14sjy1nEe9UVlfyFTRVJe7cqPtQYXo79rXQ6QjPjGf+uYf0GtP N17OFHuFIMkCLbhZ40OyzSW7G
X-Received: by 10.46.20.79 with SMTP id 15mr3296374lju.125.1510587237098; Mon, 13 Nov 2017 07:33:57 -0800 (PST)
X-Google-Smtp-Source: AGs4zMbO1Ac9GRP+7ZemyoFa9klH7KsShMOJDRfGKeVsPlzOVTexNO87c3txvfvIWR4xOVi9M0FK+td578WQtPUdU50=
X-Received: by 10.46.20.79 with SMTP id 15mr3296364lju.125.1510587236854; Mon, 13 Nov 2017 07:33:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Mon, 13 Nov 2017 07:33:56 -0800 (PST)
In-Reply-To: 
References:   <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>      
From: David Farmer 
Date: Mon, 13 Nov 2017 09:33:56 -0600
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Fernando Gont 
Cc: Ted Lemon , IPv6 Ops WG , "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="f403045fbe34a7c4ae055ddefff9"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:34:02 -0000

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

On Mon, Nov 13, 2017 at 8:57 AM, Fernando Gont 
wrote:

> Ted,
>
> On 11/13/2017 10:31 PM, Ted Lemon wrote:
> > Fernando, the document is in AUTH48. If there is a technical problem
> > with it that is sufficient to pull it out of the publication queue at
> > this point, I haven't heard it yet. I think it would be nice to add a
> > little advice on how to manage the state, but it's up to the authors to
> > do this or not. This discussion is getting a bit old.
>
> The technical problem is that this is a v6ops document making SLAAC
> stateful. As discussed, making SLAAC stateful brings breakage scenarios
> not present in SLAAC, and that is certainly not a minor change.
>
> And having folks noted that they have implemented this sort of behavior
> without changing SLAAC, the low-level protocol details in Section 4 are
> even less unwarranted.
>
> It is not my call what's the proper action. But I do note that this is
> yet another BCP that rather that essentially disregards work of other wg
> (dhc), unnecessarily. Are you are pushing a BCP with a mechanism that is
> so underspecified, that folks meaning to implement this are likely to
> introduce breakage.
>
> That said, it is not my call what's the proper action to follow. My
> intent (noted to e.g. Suresh off-line) is not to obstruct the document,
> but to avoid breakage -- particularly when it's unwarranted.
>

You claim this is making SLAAC stateful by adding state to the router.
However, if anything this reduces the state the router needs to track.
Currently the router has to track address state of  O(NxM).  Where N =
Number Hosts, and M = Average Number Addresses used per Host.  With Unique
Prefix per host, the router only has to track prefix state of O(N).
Allowing a host to use as many addresses as it sees fit without impacting
the amount of state the router has to track.

Further, it seems to me that if anything it's Neighbor Discovery that is
changed, and not SLAAC, and Neighbor Discovery has always been stateful.
Now I don't believe the Neighbor Discovery protocol is actually being
changed, it is merely being implemented differently within the variations
allowed by the protocol.

Finally, this discussion has relieved that there this draft is incomplete
in several ways.  However this document is not any more incomplete than
many other documents already approved by the IESG and implemented on
thousands or even millions of hosts.  That is why we revise documents, we
never get it right the first time.

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
===============================================

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




On Mon, Nov 13, 2017 at 8:57 AM, Fernando Gont <fgont@si6networks.=
com> wrote:
Ted,



On 11/13/2017 10:31 PM, Ted Lemon wrote:

> Fernando, the document is in AUTH48. If there is a technical problem
> with it that is sufficient to pull it out of the publication queue at<=
br>
> this point, I haven't heard it yet. I think it would be nice to ad=
d a

> little advice on how to manage the state, but it's up to the autho=
rs to

> do this or not. This discussion is getting a bit old.



The technical problem is that this is a v6ops document making SLAAC

stateful. As discussed, making SLAAC stateful brings breakage scenarios

not present in SLAAC, and that is certainly not a minor change.



And having folks noted that they have implemented this sort of behavior

without changing SLAAC, the low-level protocol details in Section 4 are

even less unwarranted.



It is not my call what's the proper action. But I do note that this is<=
br>
yet another BCP that rather that essentially disregards work of other wg
(dhc), unnecessarily. Are you are pushing a BCP with a mechanism that is
so underspecified, that folks meaning to implement this are likely to

introduce breakage.



That said, it is not my call what's the proper action to follow. My

intent (noted to e.g. Suresh off-line) is not to obstruct the document,

but to avoid breakage -- particularly when it's unwarranted.

You claim this is making SLAAC stateful by adding=
 state to the router. However, if anything this reduces the state the route=
r needs to track.=C2=A0 Currently the router has to track address state of=
=C2=A0 O(NxM).=C2=A0 Where N =3D Number Hosts, and M =3D Average Number Add=
resses used per Host.=C2=A0 With Unique Prefix per host, the router only ha=
s to track prefix state of O(N). Allowing a host to use as many addresses a=
s it sees fit without impacting the amount of state the router has to track=
.

Further, it seems to me that if anything it'=
s Neighbor Discovery that is changed, and not SLAAC, and Neighbor Discovery=
 has always been stateful. Now I don't believe the Neighbor Discovery p=
rotocol is actually being changed, it is merely being implemented different=
ly within the variations allowed by the protocol.

=
Finally, this discussion has relieved that there this draft is incomplete i=
n several ways.=C2=A0 However this document is not any more incomplete than=
 many other documents already approved by the IESG and implemented on thous=
ands or even millions of hosts.=C2=A0 That is why we revise documents, we n=
ever get it right the first time.

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 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 




--f403045fbe34a7c4ae055ddefff9--


From nobody Mon Nov 13 07:35:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E0B129454 for ; Mon, 13 Nov 2017 07:35:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCCXaHuA8ZT7 for ; Mon, 13 Nov 2017 07:35:42 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257E4129449 for ; Mon, 13 Nov 2017 07:35:42 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEGlw-0000FsC; Mon, 13 Nov 2017 16:35:40 +0100
Message-Id: 
To: ipv6@ietf.org
Subject: Re: IPv6 only host NAT64 requirements? 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>  
In-reply-to: Your message of "Mon, 13 Nov 2017 03:32:22 +0000 ."  
Date: Mon, 13 Nov 2017 16:35:34 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:35:44 -0000

>I am not optimistic on the demand / need / value of dnssec in any scenario
>....let alone an ipv6-only host validating an ipv4-only dns name. If the
>folks operating this service cared, they could operate the server with
>signed v6 names.  It is more reasonable in todays internet to asked the
>server (lets assume most signed name scenarios are servers) to be setup
>right (with v6). There is not a compelling reason why having v6 is
>unattainable today for named nodes.

DNSSEC is something that works today. Opinions are divided on what security
it offers. Some people like it way more than the traditional CA system. 
Other people believe that we should continue making random changes to the CA
system in the hope that one day it will be secure.

The problem for people who do local DNSSEC validation is that if neither the
NAT64/DNS64 operator nor the operator of the target server cares about 
DNSSEC/IPv6 then it just breaks.

If all server operators cared, then there would be no need for NAT64/DNS64
so the problem would not exist in the first place.

If the NAT64/DNS64 operator cared, then they would offer be dual stack IPv4
or a tunneling based transition technology that doesn't break DNSSEC.

I guess the good news is that at least one group of people writing a local
DNSSEC validating resolver (getdns) are aware of this issue and are adding
code to handle this situation.



From nobody Mon Nov 13 07:36:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9301A128B8D for ; Mon, 13 Nov 2017 07:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veienttM6Ud8 for ; Mon, 13 Nov 2017 07:36:10 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB55127843 for ; Mon, 13 Nov 2017 07:36:09 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 D20192D5038; Mon, 13 Nov 2017 15:36:08 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 1BD9E200BFF204; Mon, 13 Nov 2017 23:35:44 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_1EDC8158-6581-4A82-BD32-C94846927E2D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 13 Nov 2017 23:35:43 +0800
In-Reply-To: 
Cc: 6man WG 
To: Philip Homburg 
References: 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:36:16 -0000

--Apple-Mail=_1EDC8158-6581-4A82-BD32-C94846927E2D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Philip,

> In your letter dated Mon, 13 Nov 2017 10:50:40 +0800 you wrote:
>> If this is the direction we want to go. Encourage IPv6 only host
>> deployments (as opposed to dual stack hosts), are these requirements
>> we'd like to add to the IPv6 node requirements document? Somewhere =
else
>=20
> Personally I don't like how NAT64 requires an IPv6 stack to deal with =
all
> kinds of IPv4 issues. So for IPv6 node requirements, it should not go
> beyond the level of MAY.

Yes, that's certainly the bind we are in. Are we going to require all =
IPv6 only nodes to be able to communicate with IPv4? And what does that =
entail? Do you have examples of "all kinds of IPv4 issues"?

Apart from the requirement of NAT64 prefix discovery and IPv4 =
synthesising, is there anything you don't need to do anyway?
I can't quite see ICE/STUN going away, just because the end to end path =
is IPv6.

While I'm also concerned about the consequences of carrying IPv4 debt in =
all IPv6 implementations, the alternative seems to be that we are stuck =
with Dual stack forever (for some definition of forever). This would at =
least allow us to move to single stack IPv6. Which appears to me to be a =
step forward. And we're very close to that already, and there are =
millions of devices already implementing it.

Cheers,
Ole

--Apple-Mail=_1EDC8158-6581-4A82-BD32-C94846927E2D
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+/bDNdvtpYqJhC33YFAloJu88ACgkQvtpYqJhC
33boGQ//Rtv/rq8p8/kmTxZWbgAMhn6jZDaVJlbB4pPoUZcdmv4t5Z3/9dHwGmmo
/SJ0uIP9+8DL1Qvq9RTHP3H8VBMvGIGqdy34yC3MOZJnx6k4Jl8DYFF9RTF88slc
WjwsMxyxmFQ/p8w6iqQSFUh17wzy7DDc6MmWeOIXlcMkQv46FTirGMrYdZkC+lUH
8plNn/aGwxRfNqSaxhsAAnU7q1+gCuaCvuMe++I4nK8g5+LYBb2Zn2X8UztVNmOL
LIGeCYKMYtR4xLODkN0B7jTTZQDv2xSIjjqWkytbOkvxxXCMP8J8X3g5f+nmKs5I
5FtU5ewjj5Sm261tbyWuQCHflpM1FKPdhVNxOT1rcWiL7cy4uC2vn6ft/ceWZbwY
4DIh5ENM+Lnfm3pGFIdPYfys0lF1jt97ii2juvWHCpsIDNviKnCJ+vNXRoUh3k0K
zyimSEc1Hn+dfoO3rRxmy6o3O1D+9IpL3MQCH7425JKE5gFE5gcACG8nWv6Qwjvp
ygovyS/7/kCVXPzp7xMM2fkS/ey+ccHjLD+BkGsu9kJ2Tax3ArL+hknWDq1ERpDT
pQ9/ir4avcShNaisARUt4MoZDYBcnxjlPwENn8tTKIDCrPmNXZsO/lY+oxRC2jIn
SDrq2b/NgFGFbm+eANRKo1T2GDjcbEYbRKOFZ88uUSPifXHV1Ig=
=G/GJ
-----END PGP SIGNATURE-----

--Apple-Mail=_1EDC8158-6581-4A82-BD32-C94846927E2D--


From nobody Mon Nov 13 07:36:42 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B51127843; Mon, 13 Nov 2017 07:36:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLR-x1TNTanA; Mon, 13 Nov 2017 07:36:38 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166E81294EF; Mon, 13 Nov 2017 07:36:34 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vADEaLep022965 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2017 14:36:23 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <5A09BBFE.5050407@foobar.org>
Date: Mon, 13 Nov 2017 15:36:30 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Victor Kuarsingh 
CC: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>   
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:36:41 -0000

Victor Kuarsingh wrote:
> It was noted "From a operational point of view, one would wonder why
> pursue this path as opposed to e.g. do DHCPv6".
> 
> What I am suggesting is the draft represents an actual operational
> point of view from people in the field.
> 
> However, the methods described don't inhibit other choices to be made
> in other networks, with perhaps other circumstances, to use DHCPv6.

I'm in favour of publication of this document, but not as-is. The change
in the SLAAC protocol to being stateful needs to be explicitly
acknowledged in the document, because it has substantive operational
implications for the router issuing the RAs, for other edge devices
which are involved in the host device SAVI process and for the host
device itself.

Nick


From nobody Mon Nov 13 07:37:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD17128B8D for ; Mon, 13 Nov 2017 07:37:10 -0800 (PST)
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 dnsw5-hsQOpa for ; Mon, 13 Nov 2017 07:37:08 -0800 (PST)
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 43E201286B2 for ; Mon, 13 Nov 2017 07:37:08 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id g204so2075752ywa.6 for ; Mon, 13 Nov 2017 07:37:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w3CFepmWv3YPVefVoDlRFN6If5Fn1noqwiltgzVIo+w=; b=aM2AJQ2mWtg433YerGxxOmdmWOerKfpIgtcCRmLP4DwNO/IauQBpzsQa5VgasRR0FT I/BnA/soPIor2gUX6bk6MxkWiQI3pmtXoJgd9m3l/V8uiRgs20ZtweKA+S/osD6Df8wF QTNOOKlPuqcHAJ7YLkYtIYChItWqIMOhPhcM30Iuqhfo+gY8NzOsmt3684jgYHdqN6DU wX7V1EkxkAc/PChaWVTiv3zDI0GKZ8cU6O3XmgPJC0MCQRjE7nGYc+WXvJmV0ouOfTh5 6GXYg6Zyvehhor7OZ5EUpoS7JU400oBLaavv1cdk2d9ZFzSzvxR9gojEtdMwOratlAzd oDTQ==
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=w3CFepmWv3YPVefVoDlRFN6If5Fn1noqwiltgzVIo+w=; b=ktA7AzA3T3ySoLwysczJQ2zJ8uKdSSzO5R7eIJvF4l6v3/qIWyR804lzkBiU06iOD2 fwgLw9i9k61gZ2VZjDElOdLJc6cXgNLd6G7MsVKuynFyLjZIcdRPmfaECREylYUCXO1d 6Pg4LFsyU7z7w3LUNG14ugONPjJfr/J+0o2frTnE36WWOwHfXA3+fqda/KTlw61nxkVJ RqjBz7rWWM7V9oX4OKHzo15tXDy0SlldsfF7BBl2TbzHlKHwF2lh2/PkDUFkFNS3NGXr Wp90U9CGcXjgbAybt+rCTToKaPpTxJSxb3/7CJuDw4AvLiKdSjVlw7mtAnbJ5W89rTvW 0t7g==
X-Gm-Message-State: AJaThX7JNto1kKHNcn3ezQ2WPVXHtvBT+hkw5eiAXCIPBQThrBiE3ZN/ C6j/1yggbKZb+qNab2nivBsY60PgJ726TAuHCP8=
X-Google-Smtp-Source: AGs4zMYM0EbTyQ5z6WZ8whRGlqar6+B/n/EQ1b2WKsTmF5kKfg1vTxTmODE6TuUhrf3fUgUJW0wj15kU4MLOSUWtcXg=
X-Received: by 10.13.214.130 with SMTP id y124mr2355562ywd.234.1510587427536;  Mon, 13 Nov 2017 07:37:07 -0800 (PST)
MIME-Version: 1.0
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk>  
In-Reply-To: 
From: Ca By 
Date: Mon, 13 Nov 2017 15:36:56 +0000
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: 6man WG , Tim Chown 
Content-Type: multipart/alternative; boundary="94eb2c0761ce0541f4055ddf0b84"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:37:10 -0000

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

On Mon, Nov 13, 2017 at 6:56 AM Ole Troan  wrote:

> Cameron,
>
> > > @Ole, I agree. Just swap the RFC#.
> > >
> > >>> - Must be able to do NAT64 prefix discovery (RFC6052)
> > >>> - Synthesise IPv6 address from an IPv4 literal (RFC7050)
> > >
> > >
> > > @Tim,
> > >
> > >> If someone wishes to propose text in a new section 10.2 on
> =E2=80=9CIPv6-only=E2=80=9D operation, we could include that if the WG ag=
rees.  This
> > >
> > > It might be useful to have some text in section 14 (v6 router) to
> accommodate v4 hosts/apps in case of v6-only uplink/ WAN.
> >
> > I think the trick for 6434bis is deciding what the scope of the doc is.
> Such suggestions, while they certainly have merit, are a slippery slope t=
o
> adding many things, as we=E2=80=99ve seen when Jordi started proposing tr=
ansition
> mechanisms for RFC7084-bis.
> >
> > Yes , slippery slope indeed. And you would have to deal with me opposin=
g
> the case being included.
> >
> > I have a network with 10s of millions of ipv6-only nodes, none of which
> can so dnssec (neither android nor ios support it) and the implication th=
at
> these nodes are no longer ipv6 since they don't do dnssec is ludicrous.
> >
> > i think this is just folks tryjng to raise the bar against nat64, again=
,
> with nonesense usecass that users and operators don=E2=80=99t want or car=
e about.
>
> I wanted to put the DNSSEC requirement out there. After having talked wit=
h
> a few people here, it seems doing validation on a off-box resolver isn't
> any worse than what's typically done today. I wouldn't mind dropping that
> requirement.
>
> You appear to have missed the two other requirements I suggested in the
> original email?
> This wouldn't be the exact opposite of raising the bar against NAT64. It
> would be to try to ensure NAT64 worked for all IPv6 only nodes.
>
> Cheers,
> Ole


Ole,

Yes, the first 2 are not objectionable and are already well know,
documented and deployed as part of various transition solutions.

My feeling is the plane is already in flight and operators do not need any
additional guidance / confusion from the ietf.

In short, this is a solved problem and the industry needs more stability
and less tweaking .... especially in something fundamental like the node
definition

http://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-Mo=
bileUSA.png




>

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



On Mon, Nov 13, 2017 =
at 6:56 AM Ole Troan <otroan@emp=
loyees.org> wrote:
Cameron,=




> > @Ole, I agree. Just swap the RFC#.

> >

> >>> - Must be able to do NAT64 prefix discovery (RFC6052)

> >>> - Synthesise IPv6 address from an IPv4 literal (RFC7050)<=
br>
> >

> >

> > @Tim,

> >

> >> If someone wishes to propose text in a new section 10.2 on =
=E2=80=9CIPv6-only=E2=80=9D operation, we could include that if the WG agre=
es.=C2=A0 This

> >

> > It might be useful to have some text in section 14 (v6 router) to=
 accommodate v4 hosts/apps in case of v6-only uplink/ WAN.

>

> I think the trick for 6434bis is deciding what the scope of the doc is=
. Such suggestions, while they certainly have merit, are a slippery slope t=
o adding many things, as we=E2=80=99ve seen when Jordi started proposing tr=
ansition mechanisms for RFC7084-bis.

>

> Yes , slippery slope indeed. And you would have to deal with me opposi=
ng the case being included.

>

> I have a network with 10s of millions of ipv6-only nodes, none of whic=
h can so dnssec (neither android nor ios support it) and the implication th=
at these nodes are no longer ipv6 since they don't do dnssec is ludicro=
us.

>

> i think this is just folks tryjng to raise the bar against nat64, agai=
n, with nonesense usecass that users and operators don=E2=80=99t want or ca=
re about.



I wanted to put the DNSSEC requirement out there. After having talked with =
a few people here, it seems doing validation on a off-box resolver isn'=
t any worse than what's typically done today. I wouldn't mind dropp=
ing that requirement.



You appear to have missed the two other requirements I suggested in the ori=
ginal email?

This wouldn't be the exact opposite of raising the bar against NAT64. I=
t would be to try to ensure NAT64 worked for all IPv6 only nodes.



Cheers,

Ole

Ole,

Yes, the first 2 are not objecti=
onable and are already well know, documented and deployed as part of variou=
s transition solutions.=C2=A0

My feeling is the plane is already in flight and operators do not nee=
d any additional guidance / confusion from the ietf.=C2=A0

In short, this is a solved problem and t=
he industry needs more stability and less tweaking .... especially in somet=
hing fundamental like the node definition

=









--94eb2c0761ce0541f4055ddf0b84--


From nobody Mon Nov 13 07:45:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED53C127843 for ; Mon, 13 Nov 2017 07:45:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Yzw87XRYVxUq for ; Mon, 13 Nov 2017 07:45:31 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7611200FC for ; Mon, 13 Nov 2017 07:45:31 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 D5AC42D4F99; Mon, 13 Nov 2017 15:45:30 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6ADFB200BFFAC1; Mon, 13 Nov 2017 23:45:06 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_211A7385-46B6-4F4C-B1A8-5615346BA5FF"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 13 Nov 2017 23:45:05 +0800
In-Reply-To: 
Cc: 6man WG , Tim Chown 
To: Ca By 
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk>   
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:45:33 -0000

--Apple-Mail=_211A7385-46B6-4F4C-B1A8-5615346BA5FF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Cameron,

>=20
> Yes, the first 2 are not objectionable and are already well know, =
documented and deployed as part of various transition solutions.
>=20
> My feeling is the plane is already in flight and operators do not need =
any additional guidance / confusion from the ietf.
>=20
> In short, this is a solved problem and the industry needs more =
stability and less tweaking .... especially in something fundamental =
like the node definition

This isn't guidance to operators, this is guidance to implementors.
As we found during the hackathon, multiple stacks do lack the first two. =
And as a consequence applications break.
Now you can argue if we want to put the burden of this on applications =
or on the host stack. If the former the node requirements document might =
not be the right place.

>=20
> =
http://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-M=
obileUSA.png

I thought this deployment provided dual stack service? 464XLAT, no?
That's a different problem than what we are trying to solve here.

Cheers,
Ole

--Apple-Mail=_211A7385-46B6-4F4C-B1A8-5615346BA5FF
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+/bDNdvtpYqJhC33YFAloJvgEACgkQvtpYqJhC
33bEiw//et1P9qTHMtY9dFa6SWWGmzTgANmmO0Bj7apGm28CeYmsTTmLv0wk6n7V
GxIslSgKYyOZ1bD/uVk1rjxHygxvJmKdzcTb/iACV5Ee37k2iiw1kHgmSkoMqKJY
Ny7UO12LUz+EZRTWajidSut/jdbv1ESVvHRj/nDZcA52nNwyc7k0gk7yzSNDCjkz
RnIHCTgtiILWBDPXbvEHDOYk9gZWywwQdXj1PRHIpuoU65mWE7jyZvsffuRNdFiP
43DYoATDRDIgnyJ711C9ZdZ/7kmOu/AMq/ITxPXw1rxrk0e9RY2iXvWuQQF/hdnX
8kvNHs1smieFnXH5jkdCWQrIZhrNWiXSeKp1NpnR88XXqbTrHqCfMpXiQ1ExbDv+
a7c+Un8tiYmNKCBkrXGVsY3KNNElTKA7EEl9F6+5Apj6F9nTsev01dhSSFfqFpC9
Fhw1sfbplMKshj35Zv7FsMbtzRBwNTIc6wBxPd3MXmmPfOTtd84CvkcRV3G181yd
dXtuzYtfCZ2QCZXYwBA4et6B4PEP0yqbeSkmo1T2zrF5j9yUxpygTUUyrYBeffLi
Z+ncJfQOT32xUMrdwj47NKgIswjDeE5WbsxzX9Aq8zg0B2CEVSlbp2TGYiMfGUXs
OkUdSFxxawUSEYNB9l3ZzVLVw1bHm/aqHQChRrNGAzl3uV7gIG4=
=Fd/M
-----END PGP SIGNATURE-----

--Apple-Mail=_211A7385-46B6-4F4C-B1A8-5615346BA5FF--


From nobody Mon Nov 13 07:46:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF591200FC for ; Mon, 13 Nov 2017 07:46:26 -0800 (PST)
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 rlayiJmXFbOW for ; Mon, 13 Nov 2017 07:46:24 -0800 (PST)
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 264261200F1 for ; Mon, 13 Nov 2017 07:46:24 -0800 (PST)
Received: by mail-yw0-x232.google.com with SMTP id r186so5270146ywe.13 for ; Mon, 13 Nov 2017 07:46:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/VX7BMnAv0k9pHjOv1/mqA/j7u1TWbW2hn2iQQUif88=; b=b4edcIgJZ1lGqZR6QwWV0s3mqTwRhAJswMHN06Zxx05OLINI0wXSmZmYvCqB+ViYiS WSm0kpVdUz0iNbZANEIjoXcpH2MmcNAvhBzmNl74sAFlMun2v3exf0Vi2PxpuFn4xB72 LddAv1fl8GMWNLKa09AfGSoIPCOQ6xE6S0t0de2rYzA5OTENuP1UgTIOZNAgCS5dA972 gvpBeWftDa3+4xsBLVQTTLYL2bN3AhvxuMcuN5W3taD2UbVO/IpGADvXlqnpplOIXYE5 5z9070rwX8jiyFuPv5x9XWpRN06G9jVrJtuFzUj1Fbqn/BCAen2rcHq7VT5DJ58f/C2C tolg==
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=/VX7BMnAv0k9pHjOv1/mqA/j7u1TWbW2hn2iQQUif88=; b=REDbLsxzHKoNx6VzQo/UkhWA/Xr1mDEkeGHam/dtRyOwtHtUKkgfaEk60BXJM9Enrc GXkOBpCmaxihG3ff2b7TE3mAInvLlzVhwjhXNvy7dJ5PWfQN2WSKjmL5AuHyiUtmxEay 6mhoMDAYqDXDRsklYcwo+tMFijVp+PBOW/AeX1TM8cdJ1ZL3TZGyoaUIOfGU+6htV2p+ huWlQdBmavRb6db+AeIzYHrc6ZkQnHN84cfsU5RzHhn4x2Li8csK/hcN+Nt9Rek7d2bL fFjrlwKG68uKszsfSS7YTYg8ulTy0FuDD/bsqE6UkvLrwIMnZMXTpPYD3p/CyzRJ/PCQ 6aUA==
X-Gm-Message-State: AJaThX4pFD387v/ElDS87pWTXJnWKWRbeab/iHGHl7Hb/MYo3SRPMmqi NlHMwL/2HeIDKwrKbE2EFaCr2Zj8jRRZH2wx1apkcQ==
X-Google-Smtp-Source: AGs4zMbyD960tnQTjaVbyykublFIEPsJ32pJZAs+Vv5qIgvhnDg6746lShE7bOXadc5GaQnUyt8sGDy4m/hUBwjxw00=
X-Received: by 10.129.50.66 with SMTP id y63mr6286830ywy.490.1510587983320; Mon, 13 Nov 2017 07:46:23 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Ca By 
Date: Mon, 13 Nov 2017 15:46:12 +0000
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: 6man WG , Philip Homburg 
Content-Type: multipart/alternative; boundary="001a11413a2c25dbf0055ddf2c27"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:46:26 -0000

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

On Mon, Nov 13, 2017 at 7:36 AM Ole Troan  wrote:

> Philip,
>
> > In your letter dated Mon, 13 Nov 2017 10:50:40 +0800 you wrote:
> >> If this is the direction we want to go. Encourage IPv6 only host
> >> deployments (as opposed to dual stack hosts), are these requirements
> >> we'd like to add to the IPv6 node requirements document? Somewhere else
> >
> > Personally I don't like how NAT64 requires an IPv6 stack to deal with all
> > kinds of IPv4 issues. So for IPv6 node requirements, it should not go
> > beyond the level of MAY.
>
> Yes, that's certainly the bind we are in. Are we going to require all IPv6
> only nodes to be able to communicate with IPv4? And what does that entail?
> Do you have examples of "all kinds of IPv4 issues"?
>
> Apart from the requirement of NAT64 prefix discovery and IPv4
> synthesising, is there anything you don't need to do anyway?
> I can't quite see ICE/STUN going away, just because the end to end path is
> IPv6.
>

1. ICE and STUN are apps, and they should be fixed in the app layer not
network.

2.  ICE and STUN work great today with v4 and v6 peer candidates,
especially when combined with their close cousin TURN, in TRAM WG and
specifically https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/






> While I'm also concerned about the consequences of carrying IPv4 debt in
> all IPv6 implementations, the alternative seems to be that we are stuck
> with Dual stack forever (for some definition of forever). This would at
> least allow us to move to single stack IPv6. Which appears to me to be a
> step forward. And we're very close to that already, and there are millions
> of devices already implementing it.
>
> Cheers,
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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



On Mon, Nov 13, 2017 =
at 7:36 AM Ole Troan <otroan@emp=
loyees.org> wrote:
Philip,<=
br>


> In your letter dated Mon, 13 Nov 2017 10:50:40 +0800 you wrote:

>> If this is the direction we want to go. Encourage IPv6 only host
>> deployments (as opposed to dual stack hosts), are these requiremen=
ts

>> we'd like to add to the IPv6 node requirements document? Somew=
here else

>

> Personally I don't like how NAT64 requires an IPv6 stack to deal w=
ith all

> kinds of IPv4 issues. So for IPv6 node requirements, it should not go<=
br>
> beyond the level of MAY.



Yes, that's certainly the bind we are in. Are we going to require all I=
Pv6 only nodes to be able to communicate with IPv4? And what does that enta=
il? Do you have examples of "all kinds of IPv4 issues"?



Apart from the requirement of NAT64 prefix discovery and IPv4 synthesising,=
 is there anything you don't need to do anyway?

I can't quite see ICE/STUN going away, just because the end to end path=
 is IPv6.



1. ICE and STUN =
are apps, and they should be fixed in the app layer not network.=C2=A0

2.=C2=A0 ICE and STUN work g=
reat today with v4 and v6 peer candidates, especially when combined with th=
eir close cousin TURN, in TRAM WG and specifically=C2=A0https://datatracker.ietf=
.org/doc/draft-ietf-tram-turnbis/




<=
/div>



While I'm also concerned about the consequences of carrying IPv4 debt i=
n all IPv6 implementations, the alternative seems to be that we are stuck w=
ith Dual stack forever (for some definition of forever). This would at leas=
t allow us to move to single stack IPv6. Which appears to me to be a step f=
orward. And we're very close to that already, and there are millions of=
 devices already implementing it.



Cheers,

Ole

--------------------------------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/list=
info/ipv6

--------------------------------------------------------------------




--001a11413a2c25dbf0055ddf2c27--


From nobody Mon Nov 13 07:46:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951031294EF for ; Mon, 13 Nov 2017 07:46:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3R6iQ-QXkvzh for ; Mon, 13 Nov 2017 07:46:54 -0800 (PST)
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 DB48B129449 for <6man@ietf.org>; Mon, 13 Nov 2017 07:46:53 -0800 (PST)
Received: by mail-io0-x236.google.com with SMTP id q101so3692188ioi.1 for <6man@ietf.org>; Mon, 13 Nov 2017 07:46:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xNgm99w63w6OqBIKCmTiljIJG83lUijRTQmkr7vQCKM=; b=oQ53IL4m9WbkC2QeB4FCQZG/GMm/fnVrZt+lB3Xdi4/KnilUDVOhk2/FamQtB+N+bD jTvLI9Sw2j7nPERHmCK77r7X5teIJOR56tkgw2YWMFBjopNIj7xfdL7u3q2Hy8OYKl9F lnrrJZA6Nqs0WL+7p0WfqEPhRnkfE0i7R+BcV1lJm4NEtqNXTrRo58V35CG+luH2x/Cy 2bmkiyg2wMl5yFFR9AXeZhoRSxjiufXoxCfQzHFtoRs8h5ropZhPBLus09NASz07rMjF PHhO9bpIt+CQAYTCHdFCIRa7SSS9sToB1Oc2Y8h+nnxPHT2Zp4UZeGPFQjc9rjAj4Hrt xzcA==
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=xNgm99w63w6OqBIKCmTiljIJG83lUijRTQmkr7vQCKM=; b=tTy41YI7vjr1I1eNSujzOY0r/tEelqHXvM3CG/KTi2KGu73Zc64r0xutJyjh81FZol AsxteUV7dXOS37/hpZVvQj7IJzqrpTDwPgD2oYmLb1Y7eqBqKikojIbIinxDgqdR0PxO pn8UWKv8HdgmEuF6+ijVqKLepTsC6hF7idpDJ+CGDullmEyKMlX0gw4LP7zv/0LBLfHB LLR1MwFxyRCSnbAG3dAFO23ckoc0GoDjAgvsHBlkrdc73iYXAleX/TnB0pr8OD34zO84 0SVoYWIFRnWHpfmAtPIx7Nt5JqKeDrWLEdsC2RXWbMgGtjijdUi3QVdS2AVMR1WLoEAL cedg==
X-Gm-Message-State: AJaThX5giPaESwVKQ4zSKZzHyLUMnytwqS9A226321ofmxL4N+YlWntx WLOGetUeRX46EuWrEPzUPR6XsFH6VANdEVOtqEkyNg==
X-Google-Smtp-Source: AGs4zMYs2odI1bdTasAPe2NUKHQYw1akMKBfGDtvKlVkWD6MVKnLYcK2t7m3PfCMolb22omAttbj/4dQFwTLk2a3X20=
X-Received: by 10.107.84.3 with SMTP id i3mr10426130iob.148.1510588012900; Mon, 13 Nov 2017 07:46:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Mon, 13 Nov 2017 07:46:32 -0800 (PST)
In-Reply-To: 
References:   <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>       
From: Lorenzo Colitti 
Date: Tue, 14 Nov 2017 00:46:32 +0900
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: David Farmer 
Cc: Fernando Gont , IPv6 Ops WG ,  "6man@ietf.org" <6man@ietf.org>, Ted Lemon 
Content-Type: multipart/alternative; boundary="94eb2c1b7600e9e4d2055ddf2d36"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:46:55 -0000

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

On Tue, Nov 14, 2017 at 12:33 AM, David Farmer  wrote:

> You claim this is making SLAAC stateful by adding state to the router.
> However, if anything this reduces the state the router needs to track.
> Currently the router has to track address state of  O(NxM).  Where N =
> Number Hosts, and M = Average Number Addresses used per Host.  With Unique
> Prefix per host, the router only has to track prefix state of O(N).
> Allowing a host to use as many addresses as it sees fit without impacting
> the amount of state the router has to track.
>

+1. Couldn't agree more.


> Finally, this discussion has relieved that there this draft is incomplete
> in several ways.  However this document is not any more incomplete than
> many other documents already approved by the IESG and implemented on
> thousands or even millions of hosts.  That is why we revise documents, we
> never get it right the first time.
>

+1.

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


On T=
ue, Nov 14, 2017 at 12:33 AM, David Farmer <farmer@umn.edu> wro=
te:
You claim this is making SLAAC state=
ful by adding state to the router. However, if anything this reduces the st=
ate the router needs to track.=C2=A0 Currently the router has to track addr=
ess state of=C2=A0 O(NxM).=C2=A0 Where N =3D Number Hosts, and M =3D Averag=
e Number Addresses used per Host.=C2=A0 With Unique Prefix per host, the ro=
uter only has to track prefix state of O(N). Allowing a host to use as many=
 addresses as it sees fit without impacting the amount of state the router =
has to track.

+1. C=
ouldn't agree more.
=C2=A0
Finally, this discussion has relieved that there this draft is incomplet=
e in several ways.=C2=A0 However this document is not any more incomplete t=
han many other documents already approved by the IESG and implemented on th=
ousands or even millions of hosts.=C2=A0 That is why we revise documents, w=
e never get it right the first time.
=C2=A0
+1.


--94eb2c1b7600e9e4d2055ddf2d36--


From nobody Mon Nov 13 07:48:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A83127843; Mon, 13 Nov 2017 07:48:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6CMLrlJ6oMT; Mon, 13 Nov 2017 07:48:20 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F1D1205F1; Mon, 13 Nov 2017 07:48:19 -0800 (PST)
X-Envelope-To: v6ops@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vADEm6ec024500 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Nov 2017 14:48:07 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <5A09BEBF.9020102@foobar.org>
Date: Mon, 13 Nov 2017 15:48:15 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Lorenzo Colitti 
CC: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <5A0999A4.3040807@foobar.org> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:48:22 -0000

Lorenzo Colitti wrote:
> Actually, IIRC the thread you started a couple of months ago reaffirmed
> that consensus. (The document does not state that DHCPv6 address
> assignment is not recommended, it only states that networks that *only*
> use DHCPv6 address assignment are not recommended.)

1. draft-ietf-v6ops-unique-ipv6-prefix-per-host says nothing one way or
another about networks that *only* use DHCPv6 address assignment, so RFC
7934 is not relevant in this case, even by your own arguments.

2. 7934 does not state that networks that *only* use DHCPv6 address
assignment are not recommended.  There was no WG consensus for your
interpretation, and your interpretation is in direct conflict with the
reality that DHCPv6 can be used to provide multiple IP addresses to a
host, as 7934 recommends, and as was proven with working examples during
that thread and others.  Either way, this is outside the scope of
draft-ietf-v6ops-unique-ipv6-prefix-per-host and it's not helpful to
have another rehash of this argument here.

3. you are now arguing that an option to implement
draft-ietf-v6ops-unique-ipv6-prefix-per-host with DHCPv6 shouldn't be
considered because of rfc7934.  In other words, you're arguing that we
shouldn't introduce the option for hosts to be able to get multiple ipv6
addresses via dhcpv6, because according to you, rfc7934 recommends
against using dhcpv6-only because it lacks the ability to provide
multiple ipv6 addresses for hosts.  I.e. circular reasoning.

These arguments are untenable.  In fact, they're completely ridiculous.

Nick


From nobody Mon Nov 13 07:52:43 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E70129454 for ; Mon, 13 Nov 2017 07:52:42 -0800 (PST)
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 hSsmwuZzV9FI for ; Mon, 13 Nov 2017 07:52:40 -0800 (PST)
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 6B921127843 for ; Mon, 13 Nov 2017 07:52:40 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id q1so13790432ywh.5 for ; Mon, 13 Nov 2017 07:52:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0zOUq39kqdyfklfc5gFMo11i1TUeNty1TijzvrzzHM4=; b=hKM9VtxuStUzRer/FWK6x0a6A7iPKA/VcilSAPU5OVImRQxz2V3IkBsxQrsOBRmjCl kvC03TmVndsEpdiyjhTx9T4AVv2fpXGfs7ypjY1ujTS5K9+kxZvYzluYep632+X+N6V0 IavvT3TD8oPGRidcaZrGQg2LboO4ecBNQOI55ECblezDzjQebhm49IT+lKQZ1mfGKH0N eZq1XQyxmN1TPOzT14KPV45q3CxnCslMh68rHZJMiUGlMxbVswqZRtp4crLkhZL+ogK0 OSOYTzPkBIpPf1zxDC2joCD89p+Sv4PtwH7q5d4dxuxbLfzDTEDb+xmou3z9YEOS00m+ BGDQ==
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=0zOUq39kqdyfklfc5gFMo11i1TUeNty1TijzvrzzHM4=; b=n5FY6zgpELHxcW4TfWQ908q82QL3cqwhkWmU3LeCQZIE1WSZmx1HiDZQ246AzDNOkK thdj/Q9ejwNIZCOPPtcQPIKaRcINi7E+XLTlTh0z6WZQXKvL5FYup+x1vv0y75LAF7SB y1lzpZCDKfjLNADkHvv7gskxKrlH5Q6/IUGzEsG4jjNlH3CRu7ZJ8H7PIp25GH5cxFTh GV4gCTlhKirqKzevS/dOKWndYPuAA69xamWB8OXflJrExlcqHYjTn1YRh6EzDtCjDR3z RmgvCV3XERWeWQk7UYzxNmY7W2Tc+LXpLnDR5xZc3AWmYxuerjgea3RbopTQA1O3ueNe pfsg==
X-Gm-Message-State: AJaThX4rFQTKpknFKDfQlfynrh2qLLFmhLi6+KC98VqL5DORwg+JqHkA J/RDSIvpp6gnODJzCes4nPfKtqRTEqiCfw8XnOwFjg==
X-Google-Smtp-Source: AGs4zMaRthMBkjXftzmYHMgDJlPN83Sc1OrdmCaSYwo1N64AO9p8UquLeL5zwTPW+WoRMoRu+14kqTrta6S1y/dhynM=
X-Received: by 10.129.123.9 with SMTP id w9mr6174905ywc.471.1510588359659; Mon, 13 Nov 2017 07:52:39 -0800 (PST)
MIME-Version: 1.0
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk>    
In-Reply-To: 
From: Ca By 
Date: Mon, 13 Nov 2017 15:52:28 +0000
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: 6man WG , Tim Chown 
Content-Type: multipart/alternative; boundary="001a114948489454cb055ddf426e"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 15:52:42 -0000

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

On Mon, Nov 13, 2017 at 7:45 AM Ole Troan  wrote:

> Cameron,
>
> >
> > Yes, the first 2 are not objectionable and are already well know,
> documented and deployed as part of various transition solutions.
> >
> > My feeling is the plane is already in flight and operators do not need
> any additional guidance / confusion from the ietf.
> >
> > In short, this is a solved problem and the industry needs more stability
> and less tweaking .... especially in something fundamental like the node
> definition
>
> This isn't guidance to operators, this is guidance to implementors.


Ok, then i would proceed with caution and weigh heavily the feedback from
implementors



> As we found during the hackathon, multiple stacks do lack the first two.
> And as a consequence applications break.
> Now you can argue if we want to put the burden of this on applications or
> on the host stack. If the former the node requirements document might not
> be the right place.
>
> >
> >
> http://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png
>
> I thought this deployment provided dual stack service? 464XLAT, no?


My definition of ipv6-only includes 464xlat

To your point, a large percentage of the tmobile case is 6555bis with
nat64/dns64.

Based on the picture, you can probably guess when 6555bis was implemented
ands its relative impact



> That's a different problem than what we are trying to solve here.
>
> Cheers,
> Ole
>

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



On Mon, Nov 13, 2017 =
at 7:45 AM Ole Troan <otroan@emp=
loyees.org> wrote:
Cameron,=




>

> Yes, the first 2 are not objectionable and are already well know, docu=
mented and deployed as part of various transition solutions.

>

> My feeling is the plane is already in flight and operators do not need=
 any additional guidance / confusion from the ietf.

>

> In short, this is a solved problem and the industry needs more stabili=
ty and less tweaking .... especially in something fundamental like the node=
 definition



This isn't guidance to operators, this is guidance to implementors.

Ok, then i would pro=
ceed with caution and weigh heavily the feedback from implementors=C2=A0




As we found during the hackathon, multiple stacks do lack the first two. An=
d as a consequence applications break.

Now you can argue if we want to put the burden of this on applications or o=
n the host stack. If the former the node requirements document might not be=
 the right place.



>

> http://ww=
w.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.p=
ng



I thought this deployment provided dual stack service? 464XLAT, no?

My definition of ipv6-on=
ly includes 464xlat

To y=
our point, a large percentage of the tmobile case is 6555bis with nat64/dns=
64.=C2=A0

Based on the p=
icture, you can probably guess when 6555bis was implemented ands its relati=
ve impact=C2=A0




That's a different problem than what we are trying to solve here.



Cheers,

Ole




--001a114948489454cb055ddf426e--


From nobody Mon Nov 13 08:09:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5522129AFC for ; Mon, 13 Nov 2017 08:09:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CabxJsx0xr46 for ; Mon, 13 Nov 2017 08:09:46 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2A3129AF9 for ; Mon, 13 Nov 2017 08:09:40 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 B7D342D4F99; Mon, 13 Nov 2017 16:09:39 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E96D2200C021DD; Tue, 14 Nov 2017 00:09:12 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_5965D9AD-AC02-4B44-AB08-790CAB8CADE0"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Tue, 14 Nov 2017 00:09:11 +0800
In-Reply-To: 
Cc: 6man WG , Philip Homburg 
To: Ca By 
References:   
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 16:09:49 -0000

--Apple-Mail=_5965D9AD-AC02-4B44-AB08-790CAB8CADE0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> > In your letter dated Mon, 13 Nov 2017 10:50:40 +0800 you wrote:
> >> If this is the direction we want to go. Encourage IPv6 only host
> >> deployments (as opposed to dual stack hosts), are these =
requirements
> >> we'd like to add to the IPv6 node requirements document? Somewhere =
else
> >
> > Personally I don't like how NAT64 requires an IPv6 stack to deal =
with all
> > kinds of IPv4 issues. So for IPv6 node requirements, it should not =
go
> > beyond the level of MAY.
>=20
> Yes, that's certainly the bind we are in. Are we going to require all =
IPv6 only nodes to be able to communicate with IPv4? And what does that =
entail? Do you have examples of "all kinds of IPv4 issues"?
>=20
> Apart from the requirement of NAT64 prefix discovery and IPv4 =
synthesising, is there anything you don't need to do anyway?
> I can't quite see ICE/STUN going away, just because the end to end =
path is IPv6.
>=20
> 1. ICE and STUN are apps, and they should be fixed in the app layer =
not network.

Right, AFAIK IOS solves it at the stack level (with some application =
requirements). So this can go both ways.

>=20
> 2.  ICE and STUN work great today with v4 and v6 peer candidates, =
especially when combined with their close cousin TURN, in TRAM WG and =
specifically https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/

But we did find ICE/STUN applications not working in an IPv6 only + =
NAt64 network at the hackathon.

> While I'm also concerned about the consequences of carrying IPv4 debt =
in all IPv6 implementations, the alternative seems to be that we are =
stuck with Dual stack forever (for some definition of forever). This =
would at least allow us to move to single stack IPv6. Which appears to =
me to be a step forward. And we're very close to that already, and there =
are millions of devices already implementing it.

Cheers,
Ole



--Apple-Mail=_5965D9AD-AC02-4B44-AB08-790CAB8CADE0
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+/bDNdvtpYqJhC33YFAloJw6cACgkQvtpYqJhC
33aWYw//QLJlf+49yG1UCzZ628pWQRvdfHcP/j0Rcu8FgNeireNIUyaZUxtUmFsW
fWw1NWOW73b5v9WKKshGgwyVn48pL/KRhM5Z5PuJ0hanejAYl7QPtKiwOhSPhtcA
39LsQk/pAlE9j+iRLkqL1BC0OdOK9P1E4+25o0xqG+wFqBEq9vtlrEi938dWmxn6
OZTNhbh0L6gIX5nAgvoCMG/7gY84dZY4W31k2MJ99CXKqZY60RoXWqwCyxFsQHwc
4UzEes2u6lERqw6CUHWrZQIpSFSI5eubxOCK42sUlS0a0OymgQvefR2SN/3P4QsO
OyExyoVc5AgFfdOY2EpTd0+yIaAOKyuOU3scg0fr9W9YVGpFWn2jC5rfri+tw0C7
VBUOwglDTU2D201NRLKNikGKCMmgFHeWznuzn1LdMpydrGSMmp4P+7VjFLHoV65E
55HOK/9O0vZFZnMdD5L8/3HAt1YNSHgUoc2PTR2+oCE2x7Tkaa+fUGPEsof/FfLn
poqMT+KXXlwr5oUqL0P0taVL8fw85wXLJB2mJK0pXadO7bOPspM8L7UtquFWuY7l
eVNdhWYIFuhvM8U2OlznAUWBvrfRANJLNdbkftDbOQBxOLq1Ex8zmthfK6oQpRWV
EvNFVd7bpZnYKQevpZlcVMBpZoeqtanGXyLJQi4/msn+A0aymrc=
=Uai5
-----END PGP SIGNATURE-----

--Apple-Mail=_5965D9AD-AC02-4B44-AB08-790CAB8CADE0--


From nobody Mon Nov 13 08:15:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D290120454 for ; Mon, 13 Nov 2017 08:15:53 -0800 (PST)
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 0rZzT0z2ibTC for ; Mon, 13 Nov 2017 08:15:50 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD9E129AF9 for ; Mon, 13 Nov 2017 08:15:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510589748; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=9zkowOVAW8CSFaZLzFclgFF1Gr2eTfjUJAut0Pbx6Ng=; b=C0q+qVcd5nRFvXAhvcXQ0zlInVy1iLH7i3T6B2lTnX6c0rnBBQJeOmRxrbN1wOi/sa6sVkgn+diiPo7vg9xvPT14pOgxp4UDCyn/7kuwmORrCgoU1WUtVbP1/+cLi1NEzrY6eJb/iS08XQ7w1G3GCxBlePW8eWpt3XkgP54rw/I=
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0209.outbound.protection.outlook.com [213.199.154.209]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-130-1zgIpZIbO5ObHHSrarCE5Q-1; Mon, 13 Nov 2017 16:15:45 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 16:15:43 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0239.005; Mon, 13 Nov 2017 16:15:43 +0000
From: Tim Chown 
To: Brian E Carpenter 
CC: Fernando Gont , "C. M. Heard" , 6man WG , Michael Richardson 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Topic: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
Thread-Index: AQHTU4K/vqPz1IcGUEyBNF2bHgm6GqMHrANIgAAZpoCAAQgTgIAAiLAAgAk33AA=
Date: Mon, 13 Nov 2017 16:15:43 +0000
Message-ID: <7F4258AC-1951-46E5-B0DD-BA5541A2797D@jisc.ac.uk>
References:  <23308.1509623865@obiwan.sandelman.ca>   <1e62fab6-c434-a474-e53b-e4c7f2d83de0@gont.com.ar> <5cb2b9fd-8546-31fd-d984-d161aef16349@gmail.com> <49F3820E-A9A8-41C4-B6D0-EAEAE0941769@jisc.ac.uk> <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com>
In-Reply-To: <52370287-9bd2-1e56-3aa2-f9d1c51455b4@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:e565:a751:53f4:fd9a]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 20:iJsQrnvrvAJAOAyn/gRvznwqjI4O3cDxNN0BfB0/0Ae/BkK0+PWkF06UvzxGTMWI9wTACmaFNvVcnOIxyS+aNA74dBk3UO+EiNgVZcPE8HJ7XNj1pWQbWLq2/ADOKGBcnMVdlu9714yk0/K7XXL79lICCYS0jlqrwvM+XqqRjv4=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: bb6e49ab-a646-44a7-7db6-08d52ab1ca5b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1139; 
x-ms-traffictypediagnostic: AM3PR07MB1139:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100324003535756);
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)(3231022)(100000703101)(100105400095)(6041248)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1139; 
x-forefront-prvs: 0490BBA1F0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(24454002)(25786009)(3660700001)(33656002)(6246003)(6512007)(8676002)(5660300001)(54906003)(93886005)(229853002)(6916009)(42882006)(189998001)(53936002)(305945005)(50986999)(39060400002)(7736002)(6306002)(2950100002)(966005)(2900100001)(72206003)(4326008)(14454004)(101416001)(83716003)(102836003)(68736007)(478600001)(5250100002)(76176999)(81156014)(106356001)(82746002)(105586002)(97736004)(53546010)(81166006)(316002)(3280700002)(86362001)(36756003)(6116002)(786003)(2906002)(57306001)(74482002)(6436002)(6486002)(8936002)(6506006)(50226002)(8656006)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <42A67C320F002B4AA54AAB973062E12D@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: bb6e49ab-a646-44a7-7db6-08d52ab1ca5b
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 16:15:43.4739 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139
X-MC-Unique: 1zgIpZIbO5ObHHSrarCE5Q-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 16:15:53 -0000

PiBPbiA3IE5vdiAyMDE3LCBhdCAxOToyOSwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2Fy
cGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAwOC8xMS8yMDE3IDAwOjIwLCBUaW0g
Q2hvd24gd3JvdGU6DQo+PiBIaSwNCj4+IA0KPj4+IE9uIDYgTm92IDIwMTcsIGF0IDE5OjM1LCBC
cmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToNCj4+
PiANCj4+PiBIaSBGZXJuYW5kbywNCj4+PiANCj4+PiBPbiAwNy8xMS8yMDE3IDA3OjAyLCBGZXJu
YW5kbyBHb250IHdyb3RlOg0KPj4+PiBPbiAxMS8wMi8yMDE3IDA0OjMzIFBNLCBCcmlhbiBFIENh
cnBlbnRlciB3cm90ZToNCj4+Pj4+IE9uIDAzLzExLzIwMTcgMDQ6MjYsIEMuIE0uIEhlYXJkIHdy
b3RlOg0KPj4+Pj4+IE9uIFRodSwgTm92IDIsIDIwMTcsIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNy
K2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEMu
IE0uIEhlYXJkIDxoZWFyZEBwb2JveC5jb20+IHdyb3RlOg0KPj4+Pj4+Pj4gT24gV2VkLCAwMSBO
b3YgMjAxNywgTWljaGFlbCBSaWNoYXJkc29uIHdyb3RlOg0KPj4+Pj4+Pj4+IFlldCB3ZSBza2lw
IG90aGVyIGV4dGVuc2lvbiBoZWFkZXJzIGluIG9yZGVyIHRvIGZpbmQgdGhlIFVMUC4NCj4+Pj4+
Pj4gDQo+Pj4+Pj4+PiBOb3Qgc28uIEFuIGVuZCBub2RlIHRoYXQgZW5jb3VudGVycyBhbiB1bnJl
Y29nbml6ZWQgZXh0ZW5zaW9uIGhlYWRlcg0KPj4+Pj4+PiBpcw0KPj4+Pj4+PiANCj4+Pj4+Pj4g
Qm90aCBBSCBhbmQgSVBJUCBhcmUgd2VsbCBrbm93biBhbmQgcmVjb2duaXplZCBleHRlbnNpb24g
aGVhZGVycy4NCj4+Pj4+IA0KPj4+Pj4gQUggaXMgYW4gZXh0ZW5zaW9uIGhlYWRlci4gIklQSVAi
IGlzbid0LiBJdCdzIFByb3RvY29sIDQxLCBhbmQgUHJvdG9jb2wgNDENCj4+Pj4+IGlzIG90aGVy
d2lzZSBrbm93biBhcyBJUHY2LiAoVGhhdCdzIHdoeSBpdCdzIGFsc28gY2FsbGVkIElQUFJPVE9f
SVBWNikuDQo+Pj4+PiBJbiBSRkM4MjAwIHRlcm1zIHRoYXQgbWFrZXMgaXQgYW4gInVwcGVyLWxh
eWVyIGhlYWRlciIuIFN0cmljdGx5IHNwZWFraW5nLA0KPj4+Pj4gUkZDODIwMCBkb2Vzbid0IHNw
ZWNpZnkgd2hhdCB0byBkbyB3aXRoIGFuIHVucmVjb2duaXplZCB1cHBlci1sYXllciBoZWFkZXIu
DQo+Pj4+IA0KPj4+PiBCYXNlZCBvbiB0aGUgc3RkLCBhbnl0aGluZyB0aGF0IGlzIHVua25vd24g
aXMgYW4gRUguIEluIHRoZSBjb250ZXh0IG9mDQo+Pj4+IFJGQzgyMDAvRkMyNDYwLCB0aGVyZSdz
IG9ubHk6DQo+Pj4+IA0KPj4+PiAqIEtub3duIEVIcw0KPj4+PiAqIEtub3duIFVMUA0KPj4+PiAq
IFVua25vd24gRUhzDQo+Pj4gDQo+Pj4gWWVzLCB0aGF0J3Mgd2hhdCB0aGUgdGV4dCBzYXlzIGJ1
dCBJIHdpc2ggd2UnZCBmaXhlZCBpdCBpbiA4MjAwIHRvDQo+Pj4gYWNrbm93bGVkZ2UgdGhhdCB0
aGVyZSBpcyBhIDR0aCBjYXNlIChVbmtub3duIFVMUCkgYW5kIHRoYXQgaXQNCj4+PiBjYW5ub3Qg
YmUgZGlzdGluZ3Vpc2hlZCBmcm9tIHRoZSAzcmQgY2FzZS4gQWNrbm93bGVkZ2luZyB0aGF0IGlz
DQo+Pj4gbXVjaCBiZXR0ZXIgdGhhbiBpZ25vcmluZyBpdC4gSSdtIGhhcHB5IHdpdGggT2xlJ3Mg
c3VnZ2VzdGlvbiB0aGF0DQo+Pj4gdGhpcyAoYW5kIHRoZSByZXN1bHRpbmcgSUNNUCAxIGJlaGF2
aW91cikgc2hvdWxkIGJlIG1lbnRpb25lZCBpbg0KPj4+IDY0MzRiaXMgLSBhcyBhIGNsYXJpZmlj
YXRpb24sIG5vdCBhIG5ldyBpbnZlbnRpb24uDQo+PiANCj4+IFRoaXMgc2VlbXMgYSByZWFzb25h
YmxlIGFwcHJvYWNoIHRvIG1lLiAgV291bGQgeW91IGxpa2UgdG8gcHJvcG9zZSB0ZXh0LCBCcmlh
bj8NCj4gDQo+IEFmdGVyIHRoaXM6DQo+IA0KPiA1LjEuICBJbnRlcm5ldCBQcm90b2NvbCBWZXJz
aW9uIDYgLSBSRkMgODIwMA0KPiANCj4gICBUaGUgSW50ZXJuZXQgUHJvdG9jb2wgVmVyc2lvbiA2
IGlzIHNwZWNpZmllZCBpbiBbUkZDODIwMF0uICBUaGlzDQo+ICAgc3BlY2lmaWNhdGlvbiBNVVNU
IGJlIHN1cHBvcnRlZC4NCj4gDQo+ICAgQW55IHVucmVjb2duaXplZCBleHRlbnNpb24gaGVhZGVy
cyBvciBvcHRpb25zIE1VU1QgYmUgcHJvY2Vzc2VkIGFzDQo+ICAgZGVzY3JpYmVkIGluIFJGQyA4
MjAwLg0KPiANCj4gaW5zZXJ0IHNvbWV0aGluZyBsaWtlOg0KPiANCj4gICBOb3RlIHRoYXQgaXQg
aXMgaW1wb3NzaWJsZSBmb3IgYSBub2RlIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gYW4NCj4gICB1
bnJlY29nbml6ZWQgZXh0ZW5zaW9uIGhlYWRlciBhbmQgYW4gdW5yZWNvZ25pemVkIHVwcGVyIGxh
eWVyDQo+ICAgcHJvdG9jb2wuIFRoZXJlZm9yZSwgYSBub2RlIHdpbGwgYmVoYXZlIGluIHRoZSBz
YW1lIHdheSBmb3INCj4gICBlaXRoZXIgb2YgdGhlc2UgY2FzZXMsIGluIHBhcnRpY3VsYXIgYnkg
cmV0dXJuaW5nIGFuIElDTVANCj4gICBQYXJhbWV0ZXIgUHJvYmxlbSBtZXNzYWdlIHdpdGggY29k
ZSAxICgidW5yZWNvZ25pemVkIE5leHQgSGVhZGVyDQo+ICAgdHlwZSBlbmNvdW50ZXJlZCIpIGV2
ZW4gZm9yIGFuIHVucmVjb2duaXplZCB1cHBlciBsYXllciBwcm90b2NvbC4NCg0KVGhpcyBpcyB0
aGUgdGV4dCBUaW1XIHdpbGwgcHJlc2VudCBpbiA2bWFuOyBpdCBzZWVtcyBmaW5lIHRvIG1lLCBh
bmQgaG9wZWZ1bGx5IHdl4oCZbGwgaGF2ZSBjb25zZW5zdXMuDQoNClRpbQ0KDQo+IChQcm90b2Nv
bCA0MSBpcyBub3Qgc3BlY2lhbCBpbiB0aGlzIHJlZ2FyZC4pDQo+IA0KPiAtIEJyaWFuDQo+IA0K
Pj4gDQo+Pj4gSSBhbHNvIGFncmVlIHRoYXQgdGhlcmUgYXJlIGVub3VnaCBwb3RlbnRpYWwgaXNz
dWVzIGluIHVuZXhwZWN0ZWQNCj4+PiBJUHY2LWluLUlQdjYgdGhhdCBpcyBkZXNlcnZlcyBpdHMg
b3duIGRyYWZ0Lg0KPj4gDQo+PiBJ4oCZZCBhZ3JlZS4gVGhlIHNhbWUgd2l0aCBoZWFkZXIgaW5z
ZXJ0aW9uIGZvciB0aGF0IG1hdHRlci4gRm9jdXMgb24gdGhlIGlzc3VlcyBhbmQgaG93L2lmIHRo
ZXkgY2FuIGJlIG1pdGlnYXRlZCBhbmQgaW4gd2hpY2ggY29udGV4dHMuDQo+PiANCj4+IFRpbQ0K
Pj4gDQo+Pj4gDQo+Pj4gUmVnYXJkcw0KPj4+ICBCcmlhbg0KPj4+IA0KPj4+PiB3aXRoIHRoZSBs
YXN0IG9uZSBiZWluZyB0aGUgZGVmYXVsdCBicmFuY2ggOi0pDQo+Pj4+IA0KPj4+PiANCj4+PiAN
Cj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KPj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz
dA0KPj4+IGlwdjZAaWV0Zi5vcmcNCj4+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+Pj4gLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K


From nobody Mon Nov 13 08:16:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31189129AF9 for ; Mon, 13 Nov 2017 08:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEiN7NMj9yx4 for ; Mon, 13 Nov 2017 08:16:34 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980FC1200F1 for ; Mon, 13 Nov 2017 08:16:33 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEHPS-0000FyC; Mon, 13 Nov 2017 17:16:30 +0100
Message-Id: 
To: ipv6@ietf.org
Subject: Re: IPv6 only host NAT64 requirements? 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
References:   
In-reply-to: Your message of "Mon, 13 Nov 2017 23:35:43 +0800 ."  
Date: Mon, 13 Nov 2017 17:16:29 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 16:16:35 -0000

>Yes, that's certainly the bind we are in. Are we going to require all 
>IPv6 only nodes to be able to communicate with IPv4? And what does that 
>entail? Do you have examples of "all kinds of IPv4 issues"?
>
>Apart from the requirement of NAT64 prefix discovery and IPv4 
>synthesising, is there anything you don't need to do anyway?

One that really breaks my code, and is relevant to 6man is the guarantee in
IPv6 error ICMPs:

(c) Every ICMPv6 error message (type < 128) MUST include as much of
    the IPv6 offending (invoking) packet (the packet that caused the
    error) as possible without making the error message packet exceed
    the minimum IPv6 MTU


>While I'm also concerned about the consequences of carrying IPv4 debt in 
>all IPv6 implementations, the alternative seems to be that we are stuck 
>with Dual stack forever (for some definition of forever). This would at 
>least allow us to move to single stack IPv6. Which appears to me to be a 
>step forward. And we're very close to that already, and there are 
>millions of devices already implementing it.

In new applications that are simple from a networking point of view, it should
be possible to come up with a design that works well for both dual stack and
NAT64.

Operators who have lots of legacy devices are likely to run a dual stack
network. So hosts that are expected to work in such an environment have to
implement dual stack.

I'm not sure how (outside 3GPP) anyone can transition to NAT64. You have to
make sure that all devices that need to connect support NAT64. To do that,
you probably want to run dual stack for a while to make sure everything 
supports IPv6 properly. 

But for host software there is a lot more incentive to support dual stack then
to do the extra step for NAT64.

The big problem I see for NAT64 is that for old IPv4-only applications you 
have to make two fundamental changes to the application. The first to 
make sure that the application handles IPv6 in every possible way. And a
second pass that makes sure that every place where an IPv4 address literal 
is handled, works with NAT64. 

For an application writer it is better to try to avoid doing the second pass.


From nobody Mon Nov 13 08:16:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3887A129B13 for ; Mon, 13 Nov 2017 08:16:38 -0800 (PST)
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 XxA3UCWo0Rdo for ; Mon, 13 Nov 2017 08:16:36 -0800 (PST)
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 E1DB41200F1 for ; Mon, 13 Nov 2017 08:16:35 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id i198so13844818ywe.7 for ; Mon, 13 Nov 2017 08:16:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eg/YaS2s8HZtRymfXBSehoxeap87Ue3WadDisO5Kp5o=; b=Zz68GqESaQpp4Tg4ilKl7Lh/ydJ8AnK3DyEy5u2eWsul66ZnLh/XYHuj/UPZgZAGMi 4ne2NDiB4l18P2JsW6QFDFDJFeqDhmboZplzKBvNNUwTx5VlEUMT+pFa0bjMt0gcgBuT 99ycUT7LcoycEIV5pAJxrQGl/RGkllPme9xr7v0xTwP0RECE8Un2j2KbelbU3j17Kyme qKoeygRJADLKVPGaumn9+kbtff2tosZ67CMlVfsmlp8s+zwpZU2+deMlMykkClXGlxIC 9X/y6+HjLx6eAQcKRm24NHfItAcxgs285I2rgFe9bJAjaIGL2Q5CaCumqB9FBVgcCE2+ 9jPA==
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=eg/YaS2s8HZtRymfXBSehoxeap87Ue3WadDisO5Kp5o=; b=kWh4MVxssUiLdp0CeRYU0RPvi8vyqtwwgRbRqYedR93ptArNVEdMLvfF5ypixdRBVK PkBbAbKoisZoCsqpc2ysiYnWKe7W4vYKketq/OcALVwDYcJdILwAEjtaGbuBFTo4cwE8 9jHPZBm1nSgRE9Qogh3X4RqmA5Ip5QyWy2d8VMA5ydydLAQkHFU9M1oGnxCWcVa6NJP7 wm7DNxjrqrpMJVCDsaVohYQ2mUm6gpo1s3ddnlLWq8K1ZH3C77hBtA5FtMDSeF3hj16B TYiJ8ZuwqtHMxGty9KWAOXlv0J53aPkAEPP0zVob8IQ2wyw8JU4nlgy0MfUD0DSBt4po /vpA==
X-Gm-Message-State: AJaThX5mMuquxtrvuaM+gQVbBJEMtOaCrtK8mnH7j4TCfcQxG+JS4Npm tsxp7jJZZMEDb0uqAGPgFxnTb1+xtjOnsBCQ4JE=
X-Google-Smtp-Source: AGs4zMYZAeJO4x31xWyM7VryLMLg5oXPdYH8aO1AmbNM+JJ5ofMB2oKeSBtlBQY80cHKnntY8maDjzdOLhJ5R7KeVOc=
X-Received: by 10.37.130.11 with SMTP id q11mr5722395ybk.50.1510589795122; Mon, 13 Nov 2017 08:16:35 -0800 (PST)
MIME-Version: 1.0
References:    
In-Reply-To: 
From: Ca By 
Date: Mon, 13 Nov 2017 16:16:24 +0000
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: 6man WG , Philip Homburg 
Content-Type: multipart/alternative; boundary="089e0828c20c23c88e055ddf9877"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 16:16:38 -0000

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

On Mon, Nov 13, 2017 at 8:09 AM Ole Troan  wrote:

> > > In your letter dated Mon, 13 Nov 2017 10:50:40 +0800 you wrote:
> > >> If this is the direction we want to go. Encourage IPv6 only host
> > >> deployments (as opposed to dual stack hosts), are these requirements
> > >> we'd like to add to the IPv6 node requirements document? Somewhere
> else
> > >
> > > Personally I don't like how NAT64 requires an IPv6 stack to deal with
> all
> > > kinds of IPv4 issues. So for IPv6 node requirements, it should not go
> > > beyond the level of MAY.
> >
> > Yes, that's certainly the bind we are in. Are we going to require all
> IPv6 only nodes to be able to communicate with IPv4? And what does that
> entail? Do you have examples of "all kinds of IPv4 issues"?
> >
> > Apart from the requirement of NAT64 prefix discovery and IPv4
> synthesising, is there anything you don't need to do anyway?
> > I can't quite see ICE/STUN going away, just because the end to end path
> is IPv6.
> >
> > 1. ICE and STUN are apps, and they should be fixed in the app layer not
> network.
>
> Right, AFAIK IOS solves it at the stack level (with some application
> requirements). So this can go both ways.
>
> >
> > 2.  ICE and STUN work great today with v4 and v6 peer candidates,
> especially when combined with their close cousin TURN, in TRAM WG and
> specifically https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
>
> But we did find ICE/STUN applications not working in an IPv6 only + NAt64
> network at the hackathon.
>

The ICE needs to be paired with a dual stack TURN server, i believe that is
the correct way to handle this scenario

That way, the peers always see v4 and v6 candidates

The issue you saw was that the v6 host was only presented with v4 peers
from ICE?



> > While I'm also concerned about the consequences of carrying IPv4 debt in
> all IPv6 implementations, the alternative seems to be that we are stuck
> with Dual stack forever (for some definition of forever). This would at
> least allow us to move to single stack IPv6. Which appears to me to be a
> step forward. And we're very close to that already, and there are millions
> of devices already implementing it.
>
> Cheers,
> Ole
>
>
>

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



On Mon, Nov 13, 2017 =
at 8:09 AM Ole Troan <otroan@emp=
loyees.org> wrote:
> >=
; In your letter dated Mon, 13 Nov 2017 10:50:40 +0800 you wrote:

> >> If this is the direction we want to go. Encourage IPv6 only h=
ost

> >> deployments (as opposed to dual stack hosts), are these requi=
rements

> >> we'd like to add to the IPv6 node requirements document? =
Somewhere else

> >

> > Personally I don't like how NAT64 requires an IPv6 stack to d=
eal with all

> > kinds of IPv4 issues. So for IPv6 node requirements, it should no=
t go

> > beyond the level of MAY.

>

> Yes, that's certainly the bind we are in. Are we going to require =
all IPv6 only nodes to be able to communicate with IPv4? And what does that=
 entail? Do you have examples of "all kinds of IPv4 issues"?

>

> Apart from the requirement of NAT64 prefix discovery and IPv4 synthesi=
sing, is there anything you don't need to do anyway?

> I can't quite see ICE/STUN going away, just because the end to end=
 path is IPv6.

>

> 1. ICE and STUN are apps, and they should be fixed in the app layer no=
t network.



Right, AFAIK IOS solves it at the stack level (with some application requir=
ements). So this can go both ways.



>

> 2.=C2=A0 ICE and STUN work great today with v4 and v6 peer candidates,=
 especially when combined with their close cousin TURN, in TRAM WG and spec=
ifically https://datatracker.ietf.org/doc/d=
raft-ietf-tram-turnbis/



But we did find ICE/STUN applications not working in an IPv6 only + NAt64 n=
etwork at the hackathon.



The ICE needs to=
 be paired with a dual stack TURN server, i believe that is the correct way=
 to handle this scenario

That way, the peers always see v4 and v6 candidates=C2=A0

The issue you saw was that the v6 host w=
as only presented with v4 peers from ICE?

=




> While I'm also concerned about the consequences of carrying IPv4 d=
ebt in all IPv6 implementations, the alternative seems to be that we are st=
uck with Dual stack forever (for some definition of forever). This would at=
 least allow us to move to single stack IPv6. Which appears to me to be a s=
tep forward. And we're very close to that already, and there are millio=
ns of devices already implementing it.



Cheers,

Ole








--089e0828c20c23c88e055ddf9877--


From nobody Mon Nov 13 08:17:42 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E763F129B14 for ; Mon, 13 Nov 2017 08:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amJzQ0euE8ir for ; Mon, 13 Nov 2017 08:17:39 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D35F129B0E for ; Mon, 13 Nov 2017 08:17:35 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 EE0072D4F99; Mon, 13 Nov 2017 16:17:34 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 1EDF3200C0308E; Tue, 14 Nov 2017 00:17:10 +0800 (+08)
From: Ole Troan 
Message-Id: <991C27F8-26BE-4588-B8FA-D83531F8742D@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_9F523B89-A781-4CA7-BACD-CBB4AC26207A"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Tue, 14 Nov 2017 00:17:09 +0800
In-Reply-To: 
Cc: 6man WG , Tim Chown 
To: Ca By 
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk>     
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 16:17:41 -0000

--Apple-Mail=_9F523B89-A781-4CA7-BACD-CBB4AC26207A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Cameron,

> I thought this deployment provided dual stack service? 464XLAT, no?
>=20
> My definition of ipv6-only includes 464xlat

Terminology is tricky. As proven by Jordi's presentation in v6ops today.

The difference as I see it between IPv6 only + NAT64 and 464XLAT is that =
in the former an IPv4 application cannot work.
While in the latter the host has an IPv4 address and the IPv4 only =
application works just as if it is provisioned with IPv4 using any other =
means. That being native, LW46, MAP-E, MAP-T, L2TP, Public4over6, DSTM, =
2473, DS-lite...

Different use cases. While 464XLAT is a way to tunnel IPv4 across an =
IPv6 only access network (albeit with a null encap. :-)), IPv6 only + =
NAT64 is about delivering IPv6 only to hosts and applications. =
Applications would only have an IPv6 address to bind to. This use case =
would be much more akin to an enterprise network or home network.

> To your point, a large percentage of the tmobile case is 6555bis with =
nat64/dns64.
>=20
> Based on the picture, you can probably guess when 6555bis was =
implemented ands its relative impact

:-)

Cheers,
Ole

--Apple-Mail=_9F523B89-A781-4CA7-BACD-CBB4AC26207A
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+/bDNdvtpYqJhC33YFAloJxYUACgkQvtpYqJhC
33aAfg//ZKvjXlnP8IZ59LGrNy17XkLhAPNJaOLjLszZ4vj+5UHW6I9CIef8b1p2
shKRnlt+/jz3yO+OJSoAkqFUuQ+GZaKlW4/+ftv4vbUkyXvtTbmjrVVN2zIZMWRT
qRgQWkqL2xCAZUfP+aMbnwn4O7Ewk4DGMM8QOYwhNCzTKvYWUF5EtEyyvZGUDh5Y
ehNf/e8GNDzmDY5zrcI2H0iuA03O0iIRd6kU1bLk+hXM4ZeErkltaKwb16EjaKK/
kuUUu4+RNjNHZJm0a5nIma7Sr2LydTdEwihdYI7WZ6kapQlRoyZh+5l8py0rAe5p
Ip8dvCOmdA5UpOuguL9B2hZFm8ej7UE37FJpQ9h2wPFkk5hlqyWURvFlbPdS7nn8
ikkJ5TsaqpBn/Wz8g+VuuXLXnhWtkjlzbmsxu+JhfreNnp6DdqUyCugIMekFtGFc
sHBqcl+l3ONXrrLPz0Hw9/KkpY7M8G4p8m9B8rWlvUt3hMCzNkh5BUxegQIZkvbd
oudTYNSmzl8Ayb3PkiS0fNgeK0IHkW1N2Ri34bDEmtyCiJChsHbRGBTYWxTRwjKi
xomanxN4ixiIBZVzuOar1Pm/boG5il/MUuHVQXpC+3MXlgVIMzbAROgenmFM3M+n
89TPqgOKG8qv1OCvUqdIHyGFX/DJsf7iUzs5ymLniaJYDW5aCHI=
=mDbl
-----END PGP SIGNATURE-----

--Apple-Mail=_9F523B89-A781-4CA7-BACD-CBB4AC26207A--


From nobody Mon Nov 13 08:31:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BF5129B08 for ; Mon, 13 Nov 2017 08:31:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XltFl_VoVIRG for ; Mon, 13 Nov 2017 08:31:09 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDE8120454 for ; Mon, 13 Nov 2017 08:31:09 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 C4C6B2D5119; Mon, 13 Nov 2017 16:31:08 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 29B17200C03E2A; Tue, 14 Nov 2017 00:30:39 +0800 (+08)
From: Ole Troan 
Message-Id: <44AC4D4A-1525-49B4-BB6B-E083399BE42D@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_BBEE4AF8-D31B-416A-BE36-04A35D8BBCE2"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Tue, 14 Nov 2017 00:30:38 +0800
In-Reply-To: 
Cc: 6man WG , Philip Homburg 
To: Ca By 
References:     
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 16:31:11 -0000

--Apple-Mail=_BBEE4AF8-D31B-416A-BE36-04A35D8BBCE2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Cameron,

> > 1. ICE and STUN are apps, and they should be fixed in the app layer =
not network.
>=20
> Right, AFAIK IOS solves it at the stack level (with some application =
requirements). So this can go both ways.
>=20
> >
> > 2.  ICE and STUN work great today with v4 and v6 peer candidates, =
especially when combined with their close cousin TURN, in TRAM WG and =
specifically https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
>=20
> But we did find ICE/STUN applications not working in an IPv6 only + =
NAt64 network at the hackathon.
>=20
> The ICE needs to be paired with a dual stack TURN server, i believe =
that is the correct way to handle this scenario
>=20
> That way, the peers always see v4 and v6 candidates
>=20
> The issue you saw was that the v6 host was only presented with v4 =
peers from ICE?

Yep. Agree with the solution.
Unless If you synthesized the IPv4 address and went through a NAT64 =
instead of the TURN you could have a more direct path. Or not.

Cheers,
Ole


--Apple-Mail=_BBEE4AF8-D31B-416A-BE36-04A35D8BBCE2
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+/bDNdvtpYqJhC33YFAloJyK4ACgkQvtpYqJhC
33aDaA/+PslrDAAbIOUYB2Bn7t/34pARycFqxaRSpRha+kcj05AKbRMaMttpQum4
Osk4p8bkPrj3kB6iGyH8mzKvr7sCxsu4+7iUM8r/E3GMccmeX+S1DzT5ARwMhyYZ
Ot0XlHFsqfxD5KOWHmGx/WXNg96swmVBUwc/HF2xJxoJ/om2v1OULplo2OEYbtMk
3V5gNetpxOqc0rNR+llp57uFO3rspcwHXHnvImDTZugON8meSknsZWZcK3+uW+GG
cCeVtk1YEKCWlEkZXmP19q90621vlhsUFEBhAJidIVExcHyhO2c35euX0khpjd6N
3gpP47LZ1szEAdRXNtosW/I9X+g3gsDAD49eL9hABdJWNAE1Ie5H5FgkCnaSHzwC
Ha8M1jC8aiQETRnuEJLoqxMY8aDOeqzj6pxWcyQ263TwVcsrSx9vBJlwuaTxJrkj
DGJcISZ03EK9/6g3dOp0rvW8Ch0e6CFkQn6Ok7vxspxkEWr7e7v7Q+Oca3F9O2Je
8peq354fUaOjGfZ1aBJeIyYn6qnnL/AL34wr9+MoW/M8hwopN4Fyq6dReStElElf
6XjtmILaz3uni+VGSy+vWxepx7HZwtFEpMkaQyelzynUidBz9KMF1iSIXZTvnxff
rlPMsK3HBNNfurlNvezSnkBIGyX1GrydWe3e/nUW4c8yQ3YX5r0=
=ivcZ
-----END PGP SIGNATURE-----

--Apple-Mail=_BBEE4AF8-D31B-416A-BE36-04A35D8BBCE2--


From nobody Mon Nov 13 08:35:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F824129B04 for ; Mon, 13 Nov 2017 08:35:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZktG0EdUnr5a for ; Mon, 13 Nov 2017 08:35:26 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8934120454 for ; Mon, 13 Nov 2017 08:35:26 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 183852D4F99; Mon, 13 Nov 2017 16:35:26 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8194F200C045C3; Tue, 14 Nov 2017 00:35:00 +0800 (+08)
From: Ole Troan 
Message-Id: <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_74B9495F-C87E-42C2-9108-FEBC74B02368"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Tue, 14 Nov 2017 00:34:59 +0800
In-Reply-To: 
Cc: 6man WG 
To: Philip Homburg 
References:   
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 16:35:28 -0000

--Apple-Mail=_74B9495F-C87E-42C2-9108-FEBC74B02368
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Philip,

>> Yes, that's certainly the bind we are in. Are we going to require all
>> IPv6 only nodes to be able to communicate with IPv4? And what does =
that
>> entail? Do you have examples of "all kinds of IPv4 issues"?
>>=20
>> Apart from the requirement of NAT64 prefix discovery and IPv4
>> synthesising, is there anything you don't need to do anyway?
>=20
> One that really breaks my code, and is relevant to 6man is the =
guarantee in
> IPv6 error ICMPs:
>=20
> (c) Every ICMPv6 error message (type < 128) MUST include as much of
>    the IPv6 offending (invoking) packet (the packet that caused the
>    error) as possible without making the error message packet exceed
>    the minimum IPv6 MTU

Right. But when is that an actual issue for applications?
(Where I'm not going to reply with, well ICMPv6 errors a) either don't =
make it there b) are ignored by the host stack / application c) are =
heavily throttled d) suffered that faith anyway because of some MPLS =
link or whatnot...) :-)

>> While I'm also concerned about the consequences of carrying IPv4 debt =
in
>> all IPv6 implementations, the alternative seems to be that we are =
stuck
>> with Dual stack forever (for some definition of forever). This would =
at
>> least allow us to move to single stack IPv6. Which appears to me to =
be a
>> step forward. And we're very close to that already, and there are
>> millions of devices already implementing it.
>=20
> In new applications that are simple from a networking point of view, =
it should
> be possible to come up with a design that works well for both dual =
stack and
> NAT64.
>=20
> Operators who have lots of legacy devices are likely to run a dual =
stack
> network. So hosts that are expected to work in such an environment =
have to
> implement dual stack.
>=20
> I'm not sure how (outside 3GPP) anyone can transition to NAT64. You =
have to
> make sure that all devices that need to connect support NAT64. To do =
that,
> you probably want to run dual stack for a while to make sure =
everything
> supports IPv6 properly.
>=20
> But for host software there is a lot more incentive to support dual =
stack then
> to do the extra step for NAT64.
>=20
> The big problem I see for NAT64 is that for old IPv4-only applications =
you
> have to make two fundamental changes to the application. The first to
> make sure that the application handles IPv6 in every possible way. And =
a
> second pass that makes sure that every place where an IPv4 address =
literal
> is handled, works with NAT64.
>=20
> For an application writer it is better to try to avoid doing the =
second pass.

Then we are stuck with dual stack.
What Randy and Jen set out to try in the IETF experiment was to figure =
out if it would be possible to do IPv6 only + NAT64. Identify what was =
broken and then get that fixed. If we're stuck with dual stack (or IPv4 =
only), then we're not moving towards the end-goal, are we?

Ole

--Apple-Mail=_74B9495F-C87E-42C2-9108-FEBC74B02368
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+/bDNdvtpYqJhC33YFAloJybMACgkQvtpYqJhC
33ZYUA//YrZE0qXSBdZReO17GbeOXvfq0UH6iLzh0zg1AunkgVVlOsp5nptS87Cm
asXCKAeUmyK9JSTP0Rcq2R8xjkzj8vfHFyb51/4jhMGw3dZnunD8mTdkmzCe00P1
pxzC7RcYZUDHImXYjGjfbWeK7/2HkM8L+8Xo17i3SAjSZHIAEfAwp/sl5XtgoVv1
aSnYFBqW+JA/8P0ZtsPHh5n59SiCQm5ikdZ0MVyqRxAnD4MUk8ZFPt2aJyHPfgzy
Dth3vlKfhXgjx+ZSgF+SoM5QwfZBHHv5ycJAM9RJOZNi6YzGK7BvOE5/LRK2gRr8
/J3eXwRFTdytIn1m2KsNRfi+67YIfFHCKi982G11BCvYD84cRZspOaXbxagAKL5X
1BV/4Uuj9iDlmw7THp2I3jgUrn1lYHUBzqe5SCxDGtv9JQkyCPtU/D8bnvjYQWyA
I/EQi1Qhx7Sc/S5WmmJDsGLN6QT77DzT4EPMnMDJ6chLqwsyRaP41WJcQMHvQJ0l
4ZQhB7Pa9lzNdVQov9pmIUDpdXZhLrEZ05DF3la8qvhO6bic5eaapSUZx2B+rl5F
I5Z/eAR8CA3CGUSVPq3pzZ+CTdy9Qukkcg2PrUiUxBcWEMsz9uwD6gYa44LAae2j
DzukMPhPCEd8CRjmrmlCsRA+kZ5A9FIDUlnJhd4Zge0CGH/UxjM=
=7jUA
-----END PGP SIGNATURE-----

--Apple-Mail=_74B9495F-C87E-42C2-9108-FEBC74B02368--


From nobody Mon Nov 13 08:44:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BED129B08; Mon, 13 Nov 2017 08:44:02 -0800 (PST)
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 HghYiaF-uVqm; Mon, 13 Nov 2017 08:43:59 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9AD7129B04; Mon, 13 Nov 2017 08:43:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vADGhxbl047312; Mon, 13 Nov 2017 09:43: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-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vADGhpB4047246 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 13 Nov 2017 09:43:51 -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, 13 Nov 2017 08:43:50 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 13 Nov 2017 08:43:50 -0800
From: "Templin, Fred L" 
To: Lorenzo Colitti , Ted Lemon 
CC: Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
Subject: RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Topic: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Index: AQHTXFfOF0lutU7PtESjw8Zn8vPUPqMSgHbw
Date: Mon, 13 Nov 2017 16:43:50 +0000
Message-ID: <6d7cbb0725b14a7bbe3755054c8a0971@XCH15-06-08.nw.nos.boeing.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>    <68CF4FB7-FC94-41A0-A97B-F783F6DB7825@fugue.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_6d7cbb0725b14a7bbe3755054c8a0971XCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 16:44:02 -0000

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

VGhpcyBvbmUgbmVlZHMgYSBiaXQgbW9yZSBkaXNjdXNzaW9uOg0KDQo+QnV0IGluIHRoZSByZWFs
IHdvcmxkLCB0aGF0IGlzIGEgaGFyZCByZXF1aXJlbWVudCBmb3IgdGhpbmdzIHRvIHdvcmssIHNp
bmNlIGluIHRoZSByZWFsIHdvcmxkLCB0aGUgREhDUHY2IHNlcnZlciBpcyBhbG1vc3QgbmV2ZXIg
aW4gdGhlIGNsaWVudCdzIGZpcnN0LWhvcCByb3V0ZXIuDQoNCkluIG15IHVzZSBjYXNlLCB0aGUg
REhDUHY2IHNlcnZlciBtb3N0IGRlZmluaXRlbHkgaXMgb24gdGhlIENsaWVudOKAmXMgZmlyc3Qt
aG9wIHJvdXRlci4NCkkgZG8gREhDUHY2IFBELCBhbmQgZXZlcnl0aGluZyBnZXRzIHNldCB1cCBj
b3JyZWN0bHksIGluY2x1ZGluZyByb3V0aW5nIG9uIHRoZSBmaXJzdA0KaG9wIHJvdXRlci4NCg0K
QnV0LCB3aGF0IEkgd291bGQgcmVhbGx5IGxpa2UgdG8gZ2V0IHRvIGlzIHRoZSBhYmlsaXR5IHRv
IGRvIGV2ZXJ5dGhpbmcgaW4gYSBzaW5nbGUgbWVzc2FnZQ0KZXhjaGFuZ2UuIEkgZG9u4oCZdCB3
YW50IHRvIGhhdmUgdG8gZG8gdHdvIHNlcGFyYXRlIG1lc3NhZ2UgZXhjaGFuZ2VzIChSUy9SQSBm
b2xsb3dlZA0KYnkgREhDUHY2IFNvbGljaXQvUmVwbHkgb3IgdmljZS12ZXJzYSkuIFNvLCB3aGF0
IEkgd291bGQgcmVhbGx5IGxpa2Ugd291bGQgYmUgZm9yIHRoZQ0KREhDUHY2IFJlcGx5IHRvIGNv
bnRhaW4gaW5mb3JtYXRpb24gbm9ybWFsbHkgZm91bmQgaW4gYW4gUkEsIGUuZy4sIGRlZmF1bHQg
cm91dGVyDQpsaWZldGltZSwgZGVmYXVsdCByb3V0ZXIgcHJlZmVyZW5jZXMsIGxpbmsgTVRVLCBl
dGMuDQoNClNvLCBtYXliZSB3aGF0IHdvdWxkIHNhdGlzZnkgaXQgd291bGQgYmUgYSBuZXcgREhD
UHY2IG9wdGlvbiB0aGF0IGVtYmVkcyBhbiBJUHY2DQpSQSB3aXRoIGFsbCBvZiBpdHMgbWFueSBm
ZWF0dXJlcy4gVGhlbiwgREhDUHY2IHNlcnZlcnMgdGhhdCBhcmUga25vd24gdG8gYmUgb24gdGhl
DQpzYW1lIGxpbmsgYXMgdGhlIGNsaWVudCBjYW4gaW5jbHVkZSBhbiBSQSBpbiB0aGUgREhDUHY2
IFJlcGx5IGFuZCB0aGUgY2xpZW50IGNhbiBkbw0KYWxsIG9mIGl0cyBSQS1zdHlsZSBjb25maWd1
cmF0aW9ucyB3aXRob3V0IGhhdmluZyB0byBpc3N1ZSBhbiBSUy9SQS4NCg0KRmFpbGluZyB0aGF0
LCB0aGVyZSB3b3VsZCBuZWVkIHRvIGJlIGEgd2F5IHRvIGVtYmVkIGluZm9ybWF0aW9uIG5vcm1h
bGx5IGdvdHRlbg0KZnJvbSBESENQdjYgaW4gYW4gUkEgYW5kIHRoZW4gbWFrZSBSUy9SQSB0aGUg
b25seSBleGNoYW5nZS4NCg0KVGhpcyBpcyB2ZXJ5IGltcG9ydGFudCBmb3IgZGV2aWNlcyBvbiB3
aGljaCBldmVuIGEgc2luZ2xlIG1lc3NhZ2UgZXhjaGFuZ2UgaXMNCmV4cGVuc2l2ZSAoZS5nLiwg
YWlycGxhbmVzIHdpdGggbG93LWVuZCBkYXRhIGxpbmtzKSBzbyBJIHJlYWxseSBuZWVkIGFuIGFs
bC1pbi1vbmUNCmV4Y2hhbmdlLg0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IHY2b3BzIFttYWls
dG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvcmVuem8gQ29saXR0aQ0K
U2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMywgMjAxNyAxMjoxNyBBTQ0KVG86IFRlZCBMZW1vbiA8
bWVsbG9uQGZ1Z3VlLmNvbT4NCkNjOiBGZXJuYW5kbyBHb250IDxmZ29udEBzaTZuZXR3b3Jrcy5j
b20+OyB2Nm9wc0BpZXRmLm9yZyBXRyA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuQGlldGYub3JnOyBW
YW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8Z3VudGVyLnZhbl9kZV92
ZWxkZUBub2tpYS5jb20+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBTdGF0ZWZ1bCBTTEFBQyAoZHJh
ZnQtaWV0Zi12Nm9wcy11bmlxdWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QpDQoNCk9uIE1vbiwgTm92
IDEzLCAyMDE3IGF0IDU6MDQgUE0sIFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbTxtYWlsdG86
bWVsbG9uQGZ1Z3VlLmNvbT4+IHdyb3RlOg0KT24gTm92IDEzLCAyMDE3LCBhdCA0OjAwIFBNLCBM
b3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNvbTxtYWlsdG86bG9yZW56b0Bnb29nbGUu
Y29tPj4gd3JvdGU6DQoNCiAgKiAgIERIQ1B2NiBQRCBoYXMgZXhhY3RseSB0aGUgc2FtZSBwcm9i
bGVtLg0KREhDUHY2IFBEIHNwZWNpZmllcyBhIHN0YXRlZnVsIG1lY2hhbmlzbSBmb3IgbWFuYWdp
bmcgcHJlZml4ZXMuDQoNCkFuZCBpdCBkb2VzIG5vdCBzcGVjaWZ5IGhvdyB0aG9zZSBwcmVmaXhl
cyBhcmUgcHVzaGVkIHRvIHJvdXRlcnMgYmV0d2VlbiB0aGUgcmVxdWVzdGluZyByb3V0ZXIgYW5k
IHRoZSBESENQdjYgc2VydmVyLiBCdXQgaW4gdGhlIHJlYWwgd29ybGQsIHRoYXQgaXMgYSBoYXJk
IHJlcXVpcmVtZW50IGZvciB0aGluZ3MgdG8gd29yaywgc2luY2UgaW4gdGhlIHJlYWwgd29ybGQs
IHRoZSBESENQdjYgc2VydmVyIGlzIGFsbW9zdCBuZXZlciBpbiB0aGUgY2xpZW50J3MgZmlyc3Qt
aG9wIHJvdXRlci4NCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy
IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z
b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu
Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6
LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw
YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w
aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9
DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjg0MzA5
MDU1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjgz
NjU5MTc2IDY5NTkwNDgwNCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5
ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv
LWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5
OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRp
LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2
ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4
dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6
bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7
fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt
c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs
LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls
eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u
dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51
bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi
LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7
bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps
ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0
Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci
O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p
bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE2ODQ5MzU3ODI7DQoJbXNv
LWxpc3QtdGVtcGxhdGUtaWRzOjIwNDQxMDgwODI7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K
CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVs
Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn
Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7
DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10
YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p
bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6
V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi
dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K
CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs
aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVt
YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K
CW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt
c3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu
Z2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJ
e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5
bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0
IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp
dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh
ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg
Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBvbmUgbmVlZHMgYSBiaXQgbW9yZSBkaXNjdXNzaW9uOjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mZ3Q7QnV0IGluIHRoZSByZWFsIHdvcmxkLCB0aGF0IGlzIGEgaGFyZCByZXF1
aXJlbWVudCBmb3IgdGhpbmdzIHRvIHdvcmssIHNpbmNlIGluIHRoZSByZWFsIHdvcmxkLCB0aGUg
REhDUHY2IHNlcnZlciBpcyBhbG1vc3QgbmV2ZXIgaW4gdGhlIGNsaWVudCdzIGZpcnN0LWhvcCBy
b3V0ZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYw
Ij5JbiBteSB1c2UgY2FzZSwgdGhlIERIQ1B2NiBzZXJ2ZXIgbW9zdCBkZWZpbml0ZWx5IGlzIG9u
IHRoZSBDbGllbnTigJlzIGZpcnN0LWhvcCByb3V0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPkkgZG8gREhD
UHY2IFBELCBhbmQgZXZlcnl0aGluZyBnZXRzIHNldCB1cCBjb3JyZWN0bHksIGluY2x1ZGluZyBy
b3V0aW5nIG9uIHRoZSBmaXJzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5ob3Agcm91dGVyLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAy
MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+QnV0LCB3aGF0IEkgd291bGQgcmVhbGx5IGxpa2Ug
dG8gZ2V0IHRvIGlzIHRoZSBhYmlsaXR5IHRvIGRvIGV2ZXJ5dGhpbmcgaW4gYSBzaW5nbGUgbWVz
c2FnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjojMDAyMDYwIj5leGNoYW5nZS4gSSBkb27igJl0IHdhbnQgdG8gaGF2ZSB0byBk
byB0d28gc2VwYXJhdGUgbWVzc2FnZSBleGNoYW5nZXMgKFJTL1JBIGZvbGxvd2VkPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw
MDIwNjAiPmJ5IERIQ1B2NiBTb2xpY2l0L1JlcGx5IG9yIHZpY2UtdmVyc2EpLiBTbywgd2hhdCBJ
IHdvdWxkIHJlYWxseSBsaWtlIHdvdWxkIGJlIGZvciB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+REhDUHY2
IFJlcGx5IHRvIGNvbnRhaW4gaW5mb3JtYXRpb24gbm9ybWFsbHkgZm91bmQgaW4gYW4gUkEsIGUu
Zy4sIGRlZmF1bHQgcm91dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPmxpZmV0aW1lLCBkZWZhdWx0IHJvdXRl
ciBwcmVmZXJlbmNlcywgbGluayBNVFUsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMwMDIwNjAiPlNvLCBtYXliZSB3aGF0IHdvdWxkIHNhdGlzZnkgaXQgd291bGQgYmUgYSBuZXcg
REhDUHY2IG9wdGlvbiB0aGF0IGVtYmVkcyBhbiBJUHY2PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlJBIHdpdGgg
YWxsIG9mIGl0cyBtYW55IGZlYXR1cmVzLiBUaGVuLCBESENQdjYgc2VydmVycyB0aGF0IGFyZSBr
bm93biB0byBiZSBvbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+c2FtZSBsaW5rIGFzIHRoZSBjbGllbnQg
Y2FuIGluY2x1ZGUgYW4gUkEgaW4gdGhlIERIQ1B2NiBSZXBseSBhbmQgdGhlIGNsaWVudCBjYW4g
ZG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iY29sb3I6IzAwMjA2MCI+YWxsIG9mIGl0cyBSQS1zdHlsZSBjb25maWd1cmF0aW9ucyB3aXRo
b3V0IGhhdmluZyB0byBpc3N1ZSBhbiBSUy9SQS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMwMDIwNjAiPkZhaWxpbmcgdGhhdCwgdGhlcmUgd291bGQgbmVlZCB0byBiZSBhIHdheSB0byBl
bWJlZCBpbmZvcm1hdGlvbiBub3JtYWxseSBnb3R0ZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ZnJvbSBESENQ
djYgaW4gYW4gUkEgYW5kIHRoZW4gbWFrZSBSUy9SQSB0aGUgb25seSBleGNoYW5nZS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6
IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPlRoaXMgaXMgdmVyeSBpbXBvcnRhbnQgZm9y
IGRldmljZXMgb24gd2hpY2ggZXZlbiBhIHNpbmdsZSBtZXNzYWdlIGV4Y2hhbmdlIGlzPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OiMwMDIwNjAiPmV4cGVuc2l2ZSAoZS5nLiwgYWlycGxhbmVzIHdpdGggbG93LWVuZCBkYXRhIGxp
bmtzKSBzbyBJIHJlYWxseSBuZWVkIGFuIGFsbC1pbi1vbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+ZXhjaGFu
Z2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5UaGFua3MgLSBGcmVkPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz
b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo
YWxmIE9mIDwvYj5Mb3JlbnpvIENvbGl0dGk8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3Zl
bWJlciAxMywgMjAxNyAxMjoxNyBBTTxicj4NCjxiPlRvOjwvYj4gVGVkIExlbW9uICZsdDttZWxs
b25AZnVndWUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRmVybmFuZG8gR29udCAmbHQ7ZmdvbnRA
c2k2bmV0d29ya3MuY29tJmd0OzsgdjZvcHNAaWV0Zi5vcmcgV0cgJmx0O3Y2b3BzQGlldGYub3Jn
Jmd0OzsgNm1hbkBpZXRmLm9yZzsgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50
d2VycCkgJmx0O2d1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tJmd0Ozxicj4NCjxiPlN1Ympl
Y3Q6PC9iPiBSZTogW3Y2b3BzXSBTdGF0ZWZ1bCBTTEFBQyAoZHJhZnQtaWV0Zi12Nm9wcy11bmlx
dWUtaXB2Ni1wcmVmaXgtcGVyLWhvc3QpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBOb3YgMTMsIDIwMTcg
YXQgNTowNCBQTSwgVGVkIExlbW9uICZsdDs8YSBocmVmPSJtYWlsdG86bWVsbG9uQGZ1Z3VlLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPm1lbGxvbkBmdWd1ZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44
cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTm92
IDEzLCAyMDE3LCBhdCA0OjAwIFBNLCBMb3JlbnpvIENvbGl0dGkgJmx0OzxhIGhyZWY9Im1haWx0
bzpsb3JlbnpvQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5sb3JlbnpvQGdvb2dsZS5jb208
L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8dWwgdHlwZT0i
ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4N
CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmIj5ESENQdjYgUEQgaGFzIGV4YWN0bHkgdGhlIHNhbWUgcHJvYmxl
bS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRIQ1B2NiBQRCBzcGVjaWZpZXMgYSBz
dGF0ZWZ1bCBtZWNoYW5pc20gZm9yIG1hbmFnaW5nIHByZWZpeGVzLjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkFuZCBpdCBkb2VzIG5vdCBzcGVjaWZ5IGhvdyB0aG9zZSBwcmVmaXhlcyBhcmUgcHVzaGVk
IHRvIHJvdXRlcnMgYmV0d2VlbiB0aGUgcmVxdWVzdGluZyByb3V0ZXIgYW5kIHRoZSBESENQdjYg
c2VydmVyLiBCdXQgaW4gdGhlIHJlYWwgd29ybGQsIHRoYXQgaXMgYSBoYXJkIHJlcXVpcmVtZW50
IGZvciB0aGluZ3MgdG8gd29yaywgc2luY2UgaW4gdGhlIHJlYWwgd29ybGQsIHRoZSBESENQdjYg
c2VydmVyIGlzIGFsbW9zdA0KIG5ldmVyIGluIHRoZSBjbGllbnQncyBmaXJzdC1ob3Agcm91dGVy
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_6d7cbb0725b14a7bbe3755054c8a0971XCH150608nwnosboeingcom_--


From nobody Mon Nov 13 09:09:21 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3FF129B14 for ; Mon, 13 Nov 2017 09:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 NLLU2gUxfgZR for ; Mon, 13 Nov 2017 09:09:13 -0800 (PST)
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 42068126BFD for <6man@ietf.org>; Mon, 13 Nov 2017 09:09:13 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id 134so21388269ioo.0 for <6man@ietf.org>; Mon, 13 Nov 2017 09:09:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tLpgKLpiDdNoXm6HNltwUYjXAKfssFOEDjOTz6nssqs=; b=YRueMl+2v3w5zGAR0ZDfAAzbzsnEpeP1IlNFEuFQtPBh3d2tyk19HzFWN9CfxXTldc e9mtKwr8e6J57yzCzHpHeek5PXqsHs5as8Snvl1Y8bJsQdAnkL1DYRIxiH87DOJ/KBTX ca9z1lvGVlaQnq8HWKl4EnY1nZgtkOX6kETqCl2BId6t1cHy7frBAVO/Tl2ATSrLSd1T /HBY4vbh0VApGrCfJ882CBu/oE6slIt7+KqAr6uWapKsmfN40QPGDlgmgeUH6LsRx2em bOytA4dn18VarBdo4khiVejuulWD/vuroP+R/ZBqpUPIR5Fc2u/W6wtDohKsVmr9AvpA Jziw==
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=tLpgKLpiDdNoXm6HNltwUYjXAKfssFOEDjOTz6nssqs=; b=fERXr8htGoV69AraFZERyWdPCos5yFnA+avBX6VdGhzc19x4sqagLKR3QCTRjSZrpZ lc5w2mPqpgkJLLZb79aUrXW6oc4LENNIO/k7dYe2lnUSt7s4l1es7ELMly0mYINgOwR3 Ujl7LCcGsssBqvH/vtZV0b9a9r7lSNN+7goW1PhM/r1xKV9ETkR8Ahe4XZeiXxv4ZmWe Ab65gWENjjl9f8cX29kChhPxXTKAX9otiqZ/lh1YFe+ylq59MaFi/YQpg5cJ1EjJcIM5 m7p8t4qjODeJH/39jzE9Rif+YMSuz5/V3iy6jZMSb4nZ9py//bCoJCuczmLrlM6vOvKI VhZg==
X-Gm-Message-State: AJaThX6t4lM4/NVlCO2PzcSYjgoISi6bIg7B86Ne8NtToxIlznU/zh55 eE0tNaOUuQ7xMa2fS0sIMnqnI6TTZhQgEvXAx0jUMvSo
X-Google-Smtp-Source: AGs4zMYJaC04jqTSwmNSt42JXnsPSU/aer4sdH3aW/7hDIz3Y6Eo4l/KS11Tg86R+2iDeO9TGlt0LeUEFOhvavlZoPA=
X-Received: by 10.107.174.206 with SMTP id n75mr10315238ioo.43.1510592952149;  Mon, 13 Nov 2017 09:09:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Mon, 13 Nov 2017 09:08:51 -0800 (PST)
In-Reply-To: <5A09BEBF.9020102@foobar.org>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <5A0999A4.3040807@foobar.org>  <5A09BEBF.9020102@foobar.org>
From: Lorenzo Colitti 
Date: Tue, 14 Nov 2017 02:08:51 +0900
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Nick Hilliard 
Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
Content-Type: multipart/alternative; boundary="001a11445e9e50e808055de05403"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 17:09:15 -0000

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

On Tue, Nov 14, 2017 at 12:48 AM, Nick Hilliard  wrote:

> 1. draft-ietf-v6ops-unique-ipv6-prefix-per-host says nothing one way or
> another about networks that *only* use DHCPv6 address assignment, so RFC
> 7934 is not relevant in this case, even by your own arguments.
>

Agreed. It is relevant only in that there were comments on this thread that
roughly said "why not use DHCPv6 instead".


> 2. 7934 does not state that networks that *only* use DHCPv6 address
> assignment are not recommended.  There was no WG consensus for your
> interpretation, and your interpretation is in direct conflict with the
> reality that DHCPv6 can be used to provide multiple IP addresses to a
> host, as 7934 recommends, and as was proven with working examples during
> that thread and others.  Either way, this is outside the scope of
> draft-ietf-v6ops-unique-ipv6-prefix-per-host and it's not helpful to
> have another rehash of this argument here.
>

The 7934 recommendation that can't be met by networks that only use DHCPv6
address assignment is not "provide hosts with multiple addresses" - it's
"allow hosts to form new addresses without explicit requests to the
network". But I agree it's not useful to repeat that argument here.


> 3. you are now arguing that an option to implement
> draft-ietf-v6ops-unique-ipv6-prefix-per-host with DHCPv6 shouldn't be
> considered because of rfc7934.  In other words, you're arguing that we
> shouldn't introduce the option for hosts to be able to get multiple ipv6
> addresses via dhcpv6, because according to you, rfc7934 recommends
> against using dhcpv6-only because it lacks the ability to provide
> multiple ipv6 addresses for hosts.  I.e. circular reasoning.
>

I don't think you understood me. If you're saying that a unique prefix per
host can be assigned using DHCPv6 PD, then of course that's true. Given
that DHCPv6 PD is not widely supported by hosts, it's not a fit for the
goals of this document, which are to support as many hosts as possible. But
it would work.

RFC 7934 only recommends against a network that exclusively uses DHCPv6
*address* assignment. Using DHCPv6 PD to assign a /64 *prefix* to each host
is fine (and in fact, cited as an example).

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


On T=
ue, Nov 14, 2017 at 12:48 AM, Nick Hilliard <nick@foobar.org> wrote:
1. draft-ietf-v6ops-unique-ipv6-=
prefix-per-host says nothing one way or

another about networks that *only* use DHCPv6 address assignment, so RFC
7934 is not relevant in this case, even by your own arguments.

Agreed. It is relevant only in that there were comm=
ents on this thread that roughly said "why not use DHCPv6 instead"=
;.
=C2=A0
2. 7934 does not st=
ate that networks that *only* use DHCPv6 address

assignment are not recommended.=C2=A0 There was no WG consensus for your
interpretation, and your interpretation is in direct conflict with the

reality that DHCPv6 can be used to provide multiple IP addresses to a

host, as 7934 recommends, and as was proven with working examples during
that thread and others.=C2=A0 Either way, this is outside the scope of

draft-ietf-v6ops-unique-ipv6-prefix-per-host and it's not helpful =
to

have another rehash of this argument here.

<=
div>The 7934 recommendation that can't be met by networks that only use=
 DHCPv6 address assignment is not "provide hosts with multiple address=
es" - it's "allow hosts to form new addresses without explici=
t requests to the network". But=C2=A0I agree it's not useful to re=
peat that argument here.
=C2=A0

3. you are now arguing that an option to implement

draft-ietf-v6ops-unique-ipv6-prefix-per-host with DHCPv6 shouldn't=
 be

considered because of rfc7934.=C2=A0 In other words, you're arguing tha=
t we

shouldn't introduce the option for hosts to be able to get multiple ipv=
6

addresses via dhcpv6, because according to you, rfc7934 recommends

against using dhcpv6-only because it lacks the ability to provide

multiple ipv6 addresses for hosts.=C2=A0 I.e. circular reasoning.

I don't think you understood me. If you'=
re saying that a unique prefix per host can be assigned using DHCPv6 PD, th=
en of course that's true. Given that DHCPv6 PD is not widely supported =
by hosts, it's not a fit for the goals of this document, which are to s=
upport as many hosts as possible. But it would work.

RFC 7934 only recommends against a network that exclusively uses DHCPv6 =
*address* assignment. Using DHCPv6 PD to assign a /64 *prefix* to each host=
 is fine (and in fact, cited as an example).


--001a11445e9e50e808055de05403--


From nobody Mon Nov 13 09:11:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8831205D3 for ; Mon, 13 Nov 2017 09:11:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-aowBCXETdS for ; Mon, 13 Nov 2017 09:11:27 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C6F129B20 for ; Mon, 13 Nov 2017 09:11:26 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEIGX-0000FjC; Mon, 13 Nov 2017 18:11:21 +0100
Message-Id: 
To: ipv6@ietf.org
Subject: Re: IPv6 only host NAT64 requirements? 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> 
In-reply-to: Your message of "Tue, 14 Nov 2017 00:34:59 +0800 ." <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> 
Date: Mon, 13 Nov 2017 18:11:15 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 17:11:29 -0000

>> (c) Every ICMPv6 error message (type < 128) MUST include as much of
>>    the IPv6 offending (invoking) packet (the packet that caused the
>>    error) as possible without making the error message packet exceed
>>    the minimum IPv6 MTU
>
>Right. But when is that an actual issue for applications?

First, I naively put this in my TCP implementation. Technically that's
not an application, though user land TCP does occur.

It also breaks my traceroute implementation.

>Then we are stuck with dual stack.
>What Randy and Jen set out to try in the IETF experiment was to figure 
>out if it would be possible to do IPv6 only + NAT64. Identify what was 
>broken and then get that fixed. If we're stuck with dual stack (or IPv4 
>only), then we're not moving towards the end-goal, are we?

>From a host point of view, I very much want to be dual stack. No magic.
What goes over the wire is what the application sees. IPv6 is complex enough
on its own. Adding DNS64/NAT64 make it less likely that people can actually
understand what is going on. 

Hosts being dual stack doesn't say anything about backbone networks. You
can do 464xlat on access routers or any other kind of IPv4 tunneling
technology. By tunneling on access routers you can even preserve a 1500 octet
MTU for IPv4.

In my view, the way we move to the end goal is when some networks really don't
have any IPv4 anymore. 

When IPv6-only eyeball networks appear that don't offer any kind of IPv4
connectivity, content providers either add support for IPv6 or they lose that
group of potential customers.

After a while, cheap consumer networks just drop IPv4 because it too expensive
to maintain. 

That's when IPv4 becomes truly legacy: you may have IPv4 connectivity at work,
but possible not at home. Not at a random place that offers wifi, not in
your hotel.

In corporate environments, assuming that all legacy applications can get
rewritten to support IPv6, the next step is to install proxies that offer
access to the few essential external services that are still IPv4 only.
Though possibly, those services start installing reverse proxies to offer
IPv6.

The only thing offering NAT64 to hosts does is making access networks IPv6-only
while introducing a lot of complexity without increasing end-to-end IPv6
connectivity.



From nobody Mon Nov 13 09:17:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955A512944E for ; Mon, 13 Nov 2017 09:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ImHFG421Z6nm for ; Mon, 13 Nov 2017 09:17:06 -0800 (PST)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556C2127137 for ; Mon, 13 Nov 2017 09:17:06 -0800 (PST)
Received: by mail-it0-x235.google.com with SMTP id f187so10319500itb.1 for ; Mon, 13 Nov 2017 09:17:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NZyytEGQdh69YRcl83AUxxmm+JKQFkhoggkchysLhFc=; b=fkrI2o0y5qX8eit8yJypFfzapgSgMQ0YRaDcYFkUh6urAsZHVDJlHqBPnpx0Pbxl4X vY0d0meRFXrmFpzpiAqBV8gn0ipxZLKS0+Bukj61PhT+msErv49oaIbFpwjOSO/4Y+F3 IYhAFNdILVAjMQptVs9IkHwf8Kr8jJWkpZok6FlOKgN4d2jEoSHUQzyxzaJjeBDQNMn2 rWSd/s+OqC/MGGrhaB/gqnIN8sTkkV0QFGWxFSU66Lehlluj7M4A5sE/MbHI7fZ6Ezla cxcWt4Z8GVoOaBydI5lesA45is2WpnC/f8hsXs8hKf6gtMLBK4jxgI9/2SRu6AgmtvBC omug==
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=NZyytEGQdh69YRcl83AUxxmm+JKQFkhoggkchysLhFc=; b=OSKZnzil/IBlAREjKLW2lufmJmxustteDHc8WOfUQ7puL4kqcXhKtT37X5JeSuVniI +2lW8CiXF2EohCeTbLlGiR4Gta1ycKOkTgo4bXpl5N6gEcU3tmwxqjnWtm3iCEMgF4W6 Av+h8nJKG3i/55j11mO7gODpOr8s6ryjeMqSEwe12+10wRjncXV+pfh0plrhDaeNvODX GgNYGO9GcWrne7IUvh4DfI3EAe38tNeFkuCVxV33swt0sP/hH3Gj9a76Ix3wxZbmwpQq zFEIEkhsTslxyi8lu3Ucad2oaTLvwcCb30jytl6sLXiv7MUQA8vzJTAAl1uNHBeHlb0k tr5g==
X-Gm-Message-State: AJaThX6wn2uqUxZrbMsS1oRz7kQFosU/yYXQa7p4NSAmE87v2bXm4nTF DB3ZzXMnhxKRVGabnBuBE2/GCQoZxQGjJ8W4soZE5xuq
X-Google-Smtp-Source: AGs4zMZXDb0YFAwXGrHBedTMCDr/IFiYK+PhJOJ7oT+JKoPHaSP3GS/GpLiRxljYqgmhj3qee+jXI/lutzBLfOofXvo=
X-Received: by 10.36.26.206 with SMTP id 197mr11281534iti.88.1510593425222; Mon, 13 Nov 2017 09:17:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Mon, 13 Nov 2017 09:16:44 -0800 (PST)
In-Reply-To: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> 
From: Lorenzo Colitti 
Date: Tue, 14 Nov 2017 02:16:44 +0900
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Philip Homburg 
Cc: IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary="001a114457ec8394c5055de07055"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 17:17:07 -0000

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

On Tue, Nov 14, 2017 at 2:11 AM, Philip Homburg <
pch-ipv6-ietf-4@u-1.phicoh.com> wrote:
>
> When IPv6-only eyeball networks appear that don't offer any kind of IPv4
> connectivity, content providers either add support for IPv6 or they lose
> that
> group of potential customers.
>

And how are those eyeball networks going to enter the market, given that
they don't provide access to IPv4 content but their competitors do? Seems
that they can only do that if pretty much all content is available over
IPv6. That leaves us stuck at the chicken and egg problem again.

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


On T=
ue, Nov 14, 2017 at 2:11 AM, Philip Homburg <pch-ipv6-ietf-=
4@u-1.phicoh.com> wrote:

When IPv6-only eyeball networks appear that don't offer any kind of IPv=
4

connectivity, content providers either add support for IPv6 or they lose th=
at

group of potential customers.

And how a=
re those eyeball networks going to enter the market, given that they don=
9;t provide access to IPv4 content but their competitors do? Seems that the=
y can only do that if pretty much all content is available over IPv6. That =
leaves us stuck at the chicken and egg problem again.


--001a114457ec8394c5055de07055--


From nobody Mon Nov 13 11:03:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5706B129B50 for ; Mon, 13 Nov 2017 11:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 zS4gN_ExQBq2 for ; Mon, 13 Nov 2017 11:03:21 -0800 (PST)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B29129B56 for <6man@ietf.org>; Mon, 13 Nov 2017 11:03:21 -0800 (PST)
Received: by mail-it0-x233.google.com with SMTP id m191so10618955itg.2 for <6man@ietf.org>; Mon, 13 Nov 2017 11:03:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2tDDsVAF4K/+9Y59oKitInH2fevXWL/9eb9GODUOTmI=; b=EZcSLd7JoADSsMFI+4ebVpuQNvTiYaIrYCskj4q26f2Qh8WpQjlZtMe5GGtBUqX6LY PT3Pxg8E75goLPy70/b2wVjBnKgmwgzYH/gyIem1VwS2VJG1Xb1vbi70THBHKA4UEML6 n1v1xO8+9GBJTh7OXueteKE6Wwc5M9bcWqmGxsYESN3fEEBZbEDaaDboNhJAydhLOgu/ s7ml6779ZXBJgBgEihPirpVeHjXBN/yTszoN8CdiVwkHRz3ru80pbz8TYdbiKqOFx2jV CQ/kpRYdg3HW+bO319OKy+EM2BW46P2EPbT7zetCUg6M5BIXdHs5eOE2QiIU6Q6Wq3vX 5T6A==
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=2tDDsVAF4K/+9Y59oKitInH2fevXWL/9eb9GODUOTmI=; b=HEkMl9ZgjdsYQKy0EVqHrmk5kRu9/uuB17dNKDQdlPNQ2EEO1KuFX1tH2VVY5zDbE0 f28E9kdHaucMUVOG0CyyhCpm0cuLGvltgyS4G2jHwZx0KL5ZRQ46x0C+ESKctzUBl5/p lqzIN1dHoyipD2KlWaev1qMbvRJa6s1eziedYggKmyHwnVqjwj2IJVJFu7uaHT8tlc26 TWhLQyARvnEefKeUgdwoVuOyrXw8KbhR0yzhjaqUkoEcC9uH/13YQpDCdRCkFTYR4JCg gRxRUZ3ipscL1XElaM0U6B0OwRns50OXg+rO/rOdwECsvWo1S5DljM4FoEeC/U6HTBe5 Lwfw==
X-Gm-Message-State: AJaThX6dW9ts6m9N7g4DafMoUb3dn0bzoj2NIv0tP51UnGQ1cm4Qw6AB Rw5UpeGz7PntgpVpjN9RS9U1WQ==
X-Google-Smtp-Source: AGs4zMZjzmKkJ8VxzIX5xyCWbEbF+saSrEXIkxrlbe6JzQbU6XTGMsLjFV/k8cUUiYICKC4r/Pz6mQ==
X-Received: by 10.36.67.149 with SMTP id s143mr10939982itb.64.1510599800444; Mon, 13 Nov 2017 11:03:20 -0800 (PST)
Received: from dhcp-100-99-229-233.pao.corp.google.com ([100.99.229.233]) by smtp.gmail.com with ESMTPSA id g79sm4568312itb.43.2017.11.13.11.03.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 11:03:19 -0800 (PST)
From: james woodyatt 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D9B99862-968F-4B5A-B099-3FC47336626F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 11:03:18 -0800
In-Reply-To: 
Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
To: Lorenzo Colitti 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 19:03:24 -0000

--Apple-Mail=_D9B99862-968F-4B5A-B099-3FC47336626F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 12, 2017, at 18:14, Lorenzo Colitti  wrote:
> On Sat, Nov 11, 2017 at 9:41 AM, Joe Touch > wrote:
> FWIW, I would agree with that if this were an issue of WG focus creep.=20=

> AFAICT, the issue appears to go much deeper, which means it's an Area
> boundary issue if it is indeed a protocol extension.
>=20
> IMO, OPS stays in the lane of suggesting sets of *existing* protocol
> parameters and features, or indicates where MAYs and SHOULDs can be
> relaxed (or not) - all of this remains compliant with the protocol.
> Changes to the protocol should not be considered operational =
decisions,
> again IMO.
>=20
> Excuse me, but I really cannot fathom why we are saying that this =
draft defines a new protocol when it is an explicit goal for all =
existing implementations to continue to work. How can this be a new =
protocol when all implementations implement this already?

I agree with Lorenzo here, and I have to push back against Mr. Touch=E2=80=
=99s earlier message insisting that a protocol specification cannot be =
useful unless it defines the finite state machines for each =
participating member. This is not even true in theory, much less in =
actual practice. In theory, and here I am referring to the literature of =
bisimulation and the calculi for communicating processes, it=E2=80=99s =
generally sufficient when formally specifying a protocol to require =
implementations to exhibit "barbed equivalence" with one another. =
Indeed, what is the point of insisting on interoperability between =
disparate implementations if we only accept strict bisimilarity as =
conformance?

Moreover, we don=E2=80=99t even require formal protocol specifications =
here, preferring instead=E2=80=94 as a matter of explicit policy=E2=80=94 =
to publish informal specifications rather than formal ones. Therefore, =
it seems to me that a more broadly expansive understanding of the term =
=E2=80=9Cprotocol=E2=80=9D is warranted than the very narrow, much more =
formalized one that Mr. Touch outlined.

Here=E2=80=99s how I see it: when we publish a protocol specification =
here, what we are defining the rules to a multiplayer game where each =
player is free to adopt whatever strategy within the rules is optimal =
for achieving their aims. Our job as Internet engineers is to insure =
that the rules of the new and revised games we publish are balanced and =
do not contribute any damage to the Internet as a communications =
ecosystem. This draft does not modify any of the rules for provider =
routers that subscriber hosts legitimately expect them to follow. It =
makes no recommendations to change any host behaviors. It is therefore =
not a new protocol. It is merely a new strategy for performing an =
existing protocol.

It=E2=80=99s also my view that this draft is mainly an attempt by =
service provider operators to establish a new convention for keeping =
state in the network on behalf of hosts, and its authors have taken =
great pains=E2=80=94 cut many corners and shaved off a lot of risk =
mitigation=E2=80=94 in order to avoid requiring, or even inviting, hosts =
to modify their behavior. Maybe, if 6MAN were more responsive to the =
needs of both provider router operators and subscriber host users, a =
more elegant solution to the problems this draft is meant to address =
could have been developed. I don=E2=80=99t blame V6OPS for devising new =
strategies for dealing with perceived deficiencies in the protocols that =
6MAN maintains. Not at all. It=E2=80=99s their job. I=E2=80=99m also far =
from sure there is even a deficiency here for 6MAN to consider. I can =
easily see how this draft essentially amounts to exactly the sort of =
refinement that 6MAN intended to permit when it specified IPv6 Neighbor =
Discovery the way it did.


--james woodyatt >




--Apple-Mail=_D9B99862-968F-4B5A-B099-3FC47336626F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 12, 2017, at 18:14, Lorenzo Colitti <lorenzo@google.com> =
wrote:
On Sat, Nov 11, 2017 at 9:41 AM, Joe Touch <touch@strayalpha.com> =
wrote:
FWIW, I would =
agree with that if this were an issue of WG focus creep. 

AFAICT, the issue appears to go much deeper, which means it's an Area

boundary issue if it is indeed a protocol extension.



IMO, OPS stays in the lane of suggesting sets of *existing* protocol

parameters and features, or indicates where MAYs and SHOULDs can be

relaxed (or not) - all of this remains compliant with the protocol.

Changes to the protocol should not be considered operational =
decisions,

again IMO.

Excuse me, but I really cannot fathom =
why we are saying that this draft defines a new protocol when it is an =
explicit goal for all existing implementations to continue to work. How =
can this be a new protocol when all implementations implement this =
already?

I agree with Lorenzo here, and I have to push back =
against Mr. Touch=E2=80=99s earlier message insisting that a protocol =
specification cannot be useful unless it defines the finite state =
machines for each participating member. This is not even true in theory, =
much less in actual practice. In theory, and here I am referring to the =
literature of bisimulation and the calculi for communicating processes, =
it=E2=80=99s generally sufficient when formally specifying a protocol to =
require implementations to exhibit "barbed equivalence" with one =
another. Indeed, what is the point of insisting on interoperability =
between disparate implementations if we only accept strict bisimilarity =
as conformance?

Moreover, we don=E2=80=
=99t even require formal protocol specifications here, preferring =
instead=E2=80=94 as a matter of explicit policy=E2=80=94 to publish =
informal specifications rather than formal ones. Therefore, it seems to =
me that a more broadly expansive understanding of the term =
=E2=80=9Cprotocol=E2=80=9D is warranted than the very narrow, much more =
formalized one that Mr. Touch outlined.

Here=E2=80=99s how I see it: when we publish a =
protocol specification here, what we are defining the rules to a =
multiplayer game where each player is free to adopt whatever strategy =
within the rules is optimal for achieving their aims. Our job as =
Internet engineers is to insure that the rules of the new and revised =
games we publish are balanced and do not contribute any damage to the =
Internet as a communications ecosystem. This draft does not modify any =
of the rules for provider routers that subscriber hosts legitimately =
expect them to follow. It makes no recommendations to change any host =
behaviors. It is therefore not a new protocol. It is merely a new =
strategy for performing an existing protocol.

It=E2=80=99s also my view that this draft is =
mainly an attempt by service provider operators to establish a new =
convention for keeping state in the network on behalf of hosts, and its =
authors have taken great pains=E2=80=94 cut many corners and shaved off =
a lot of risk mitigation=E2=80=94 in order to avoid requiring, or even =
inviting, hosts to modify their behavior. Maybe, if 6MAN were more =
responsive to the needs of both provider router operators and subscriber =
host users, a more elegant solution to the problems this draft is meant =
to address could have been developed. I don=E2=80=99t blame V6OPS for =
devising new strategies for dealing with perceived deficiencies in the =
protocols that 6MAN maintains. Not at all. It=E2=80=99s their job. I=E2=80=
=99m also far from sure there is even a deficiency here for 6MAN to =
consider. I can easily see how this draft essentially amounts to exactly =
the sort of refinement that 6MAN intended to permit when it specified =
IPv6 Neighbor Discovery the way it did.



--james woodyatt <jhw@google.com>







=

--Apple-Mail=_D9B99862-968F-4B5A-B099-3FC47336626F--


From nobody Mon Nov 13 11:09:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0844A129B50 for ; Mon, 13 Nov 2017 11:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjGxt2xt54yy for ; Mon, 13 Nov 2017 11:09:13 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0C49124C27 for ; Mon, 13 Nov 2017 11:09:12 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEK6W-0000FzC; Mon, 13 Nov 2017 20:09:08 +0100
Message-Id: 
To: ipv6@ietf.org
Subject: Re: IPv6 only host NAT64 requirements? 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>   
In-reply-to: Your message of "Tue, 14 Nov 2017 02:16:44 +0900 ."  
Date: Mon, 13 Nov 2017 20:09:08 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 19:09:15 -0000

>And how are those eyeball networks going to enter the market, given that
>they don't provide access to IPv4 content but their competitors do? Seems
>that they can only do that if pretty much all content is available over
>IPv6. That leaves us stuck at the chicken and egg problem again.

If your core business is IPv4, then in my opinion it doesn't make much 
sense to transition to a network setup where you tunnel your IPv4 traffic
over IPv6. 

As long as an eyeball network has plenty of IPv4 address and there is no
pressure from content providers, there is no point in transitioning to IPv6.

Moving bulk traffic (and bulk connections) to IPv6 make sense if all IPv4
traffic goes through a CGN. 

If an ISP has a full IPv6 setup to handle large volume traffic, and only has
to maintain an IPv4 CGN for content that doesn't want to move to IPv4, then
it is possible that slowly IPv4 performance will get worse. And then content
providers may see an incentive to move to IPv6. For some content providers,
accidentally kiling geolocation in order to improve CGN efficiency may
give them the nudge they need.

In the end, the only argument that seems to make economic sense is that
an IPv4 address is more expensive than an IPv6 address. And that traffic
through a CGN is more expensive than through a router.



From nobody Mon Nov 13 11:43:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31E1129B5B; Mon, 13 Nov 2017 11:43:39 -0800 (PST)
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, 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 NuU2Qxjh3Cxu; Mon, 13 Nov 2017 11:43:38 -0800 (PST)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D57E129B50; Mon, 13 Nov 2017 11:43:38 -0800 (PST)
Received: by mail-ua0-x234.google.com with SMTP id q18so11211558uaa.0; Mon, 13 Nov 2017 11:43:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GJiugp6wudEdMC81Q/wcLO5vkbqgRHJcKAfAOKIe8tg=; b=A+jxmtcMAXjvlrN9COSXI0dq4mv614FHR9f73He+Ie0fm6PqWSrwWhqGoMp3XxZr3D mApGjZQJySLXXLsULyIK1Ua9w23GdJDrvUF2PSmZGCV4NGNlj0z5FiYoxGvCgxDhA5EH 4lX3E0ALpGtp0ZKloiunr8FDD7Cx83qErS4bgQan5IgFkoOaY5k9EHx1QJn1qVANSt/s RVvuDWV/naXOMKct0BddsA+I4URyb25wHjwdiKU+VcLMEpElLYcpgFFxjP2FqX38DxD0 74kOAG19tnFRA0zbMLBpShbLlnXA/gjTGeQLIozxnjxt7477b+P39XnireQCTG3I4m7c hpzA==
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=GJiugp6wudEdMC81Q/wcLO5vkbqgRHJcKAfAOKIe8tg=; b=nwNkaWNW7Z1PTLPuJ1k8qy2mb52htBaiEoNmwuodISBfQflFlwHNERtn6h1gPJETUm eCrcULVJgJq5vOAZ2nOQjcjD3pLb4LxTtlqIYeFsJ64m1GtmS3EZ0t9m4H2++nz77lMB phkSn5/Drmd/dw2Op+RzQoyKeAbOrma3vjPTfQ2FtA0S+LJkG2fvKrp1YrHnZmzDP7ZW Qr17yIMSRhmDID05cmKWjeNDO/xK/sjLK+/UAngsMBj07bb41WB7IYv80XD1MZF2aZkt 1t2DRE8cy6q8MrDbwg0NmJ9sRI3du3YjIo40rEyczHflI1T3jQHVGDwGz2S0O0C+3Rol BGpg==
X-Gm-Message-State: AJaThX6FnpCJRCYlE0e/j2ECbhV7WrmLYFZSXPQFnhfGgruaYoaMJz5l b+9TdCzIDJ3FkkpwZQ0by/gSZnlVw5D+UYIzqvE=
X-Google-Smtp-Source: AGs4zMbRsllNPn9QOW2RqxtSm6lucVBGJv3qx0aZsIt+YREl5tPVu1wM1CL3qWIqW7ux9MdtQJ+g9buPQSBldcMX4Y8=
X-Received: by 10.176.80.226 with SMTP id d31mr8295191uaa.53.1510602217317; Mon, 13 Nov 2017 11:43:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.52.221 with HTTP; Mon, 13 Nov 2017 11:43:06 -0800 (PST)
In-Reply-To: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>   
From: Mark Smith 
Date: Tue, 14 Nov 2017 06:43:06 +1100
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Lorenzo Colitti 
Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "6man@ietf.org" <6man@ietf.org>,  "v6ops@ietf.org WG" , Fernando Gont 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 19:43:40 -0000

On 13 November 2017 at 19:00, Lorenzo Colitti  wrote:
> On Mon, Nov 13, 2017 at 4:52 PM, Mark Smith  wrote:
>>
>> It's a fantasy that routers don't fail, or that a single router on a link
>> is always enough.
>>
>> Host connections are supposed to survive transient failures such router
>> reloads or switching to a different router that provides equivalent packet
>> forwarding service. If a host loses its prefix in this scenario because of
>> either of those events, then I don't think this method as currently
>> described is robust against a foreseeable failure.
>>
>> I don't think it is a Best current practice if router redundancy hasn't
>> been considered or tested and deployed, and can therefore be documented. I
>> see value in the approach because of SLAAC compatibility with hosts however
>> I think it is currently half baked.
>
>
> Let me state this again:
>
> DHCPv6 PD has exactly the same problem.

No it doesn't.

> As far as I am aware there is no RFC that documents the solutions that are
> in use for DHCPv6 PD.

DHCPv6 has been designed to avoid having state in intermediary devices
by incorporating a relay agent into the architecture, specified in
RFC3315.

Clients use DUIDs to identify themselves, and the DHCPv6 server
associates client attributes with the client's DUID. That is what
allows DHCPv6-PD to survive a router/DHCPv6 relay reboot.

This draft hasn't been published as an RFC, however it is also
considering this issue.

"DHCPv6 Relay Agent Assignment Notification (RAAN) Option"
https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-03

A number of vendors seem to have implemented the functional equivalent
by looking directly at the ID_PD option when the DHCPv6 reply is sent
to the client - search for "DHCPv6 Relay Agent Notification for Prefix
Delegation"

The alternative is to have a RADIUS server provide the delegated
prefix information to a DHCPv6 server running on the router. "RADIUS
Delegated-IPv6-Prefix Attribute", RFC4818.

Possibly the RADIUS method could be used in this draft's scenario if a
layer 2 attribute such as the MAC address or per-client VLAN tags, or
802.1X authentication information, is used to identify the client.

If this draft can't document that method because it doesn't exist,
then, assuming Comcast is the only deployment of this, it seems
Comcast aren't trying to have a prefix assignment survive a router
reboot. That's a "flash renumbering" approach, which I don't think is
right for IPv6.


> This has not stopped the deployment of tens or hundreds of millions of
> networks that use DHCPv6 PD.
>

What was the alternative that didn't have this limitation?

There is a big difference between something working and something working well.

I worked on the first production deployment of residential broadband
IPv6 in Australia in 2010. Going by the beta software we were working
with from one of the major BRAS vendors, that was likely one of the
earliest in the world. Making it work was the goal. If the goal was to
make it work well, we wouldn't have deployed it. (I haven't worked on
an IPv6 residential deployment since because of Australia's position
of being early in the IPv4 game, and ISP consolidation making IPv4
pools bigger.)

Six years later, with much more production IPv6 deployment, new
methods and solutions shouldn't be functionally equivalent, they
should be functionally superior, because the consequences of failure
matter more.

> Why are we holding this document up on this?

Half baked cakes aren't cakes, even though they may look like them.


From nobody Mon Nov 13 14:46:21 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480F5124239 for ; Mon, 13 Nov 2017 14:46:19 -0800 (PST)
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 zxu1IGD2Y2Qo for ; Mon, 13 Nov 2017 14:46:17 -0800 (PST)
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 8C63A120724 for ; Mon, 13 Nov 2017 14:46:17 -0800 (PST)
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 0E8FD3B6B87; Mon, 13 Nov 2017 22:46:14 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D9DF3160086; Mon, 13 Nov 2017 22:46:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BDA9F160087; Mon, 13 Nov 2017 22:46:13 +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 082STSCnrzUV; Mon, 13 Nov 2017 22:46:13 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id E0AC9160086; Mon, 13 Nov 2017 22:46:12 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements? 
From: Mark Andrews 
In-Reply-To: 
Date: Tue, 14 Nov 2017 09:46:10 +1100
Cc: ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> 
To: Philip Homburg 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 22:46:19 -0000

Is there any reason to run DNS64 at all these days?  ipv4only.arpa can =
be a preconfigured
zone which allows CLAT to get its mapping.  All the phones have CLAT =
support.  Can we just
make DNS64 historic and let the phones run all IPv4 connections through =
CLAT rather than
having to stuff up DNSSEC and have IPv6 connections terminate in IPv4 =
servers without
the application knowing?

Mark

> On 14 Nov 2017, at 4:11 am, Philip Homburg =
 wrote:
>=20
>>> (c) Every ICMPv6 error message (type < 128) MUST include as much of
>>>   the IPv6 offending (invoking) packet (the packet that caused the
>>>   error) as possible without making the error message packet exceed
>>>   the minimum IPv6 MTU
>>=20
>> Right. But when is that an actual issue for applications?
>=20
> First, I naively put this in my TCP implementation. Technically that's
> not an application, though user land TCP does occur.
>=20
> It also breaks my traceroute implementation.
>=20
>> Then we are stuck with dual stack.
>> What Randy and Jen set out to try in the IETF experiment was to =
figure=20
>> out if it would be possible to do IPv6 only + NAT64. Identify what =
was=20
>> broken and then get that fixed. If we're stuck with dual stack (or =
IPv4=20
>> only), then we're not moving towards the end-goal, are we?
>=20
>> =46rom a host point of view, I very much want to be dual stack. No =
magic.
> What goes over the wire is what the application sees. IPv6 is complex =
enough
> on its own. Adding DNS64/NAT64 make it less likely that people can =
actually
> understand what is going on.=20
>=20
> Hosts being dual stack doesn't say anything about backbone networks. =
You
> can do 464xlat on access routers or any other kind of IPv4 tunneling
> technology. By tunneling on access routers you can even preserve a =
1500 octet
> MTU for IPv4.
>=20
> In my view, the way we move to the end goal is when some networks =
really don't
> have any IPv4 anymore.=20
>=20
> When IPv6-only eyeball networks appear that don't offer any kind of =
IPv4
> connectivity, content providers either add support for IPv6 or they =
lose that
> group of potential customers.
>=20
> After a while, cheap consumer networks just drop IPv4 because it too =
expensive
> to maintain.=20
>=20
> That's when IPv4 becomes truly legacy: you may have IPv4 connectivity =
at work,
> but possible not at home. Not at a random place that offers wifi, not =
in
> your hotel.
>=20
> In corporate environments, assuming that all legacy applications can =
get
> rewritten to support IPv6, the next step is to install proxies that =
offer
> access to the few essential external services that are still IPv4 =
only.
> Though possibly, those services start installing reverse proxies to =
offer
> IPv6.
>=20
> The only thing offering NAT64 to hosts does is making access networks =
IPv6-only
> while introducing a lot of complexity without increasing end-to-end =
IPv6
> connectivity.
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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


From nobody Mon Nov 13 15:08:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BB312717E for ; Mon, 13 Nov 2017 15:08:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 l8kYZOo3bKrU for ; Mon, 13 Nov 2017 15:08:31 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDF6120227 for ; Mon, 13 Nov 2017 15:08:30 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eENq7-0000FkC; Tue, 14 Nov 2017 00:08:27 +0100
Message-Id: 
To: ipv6@ietf.org
Cc: Mark Andrews 
Subject: Re: IPv6 only host NAT64 requirements? 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> 
In-reply-to: Your message of "Tue, 14 Nov 2017 09:46:10 +1100 ." <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> 
Date: Tue, 14 Nov 2017 00:08:26 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 23:08:33 -0000

> Is there any reason to
> run DNS64 at all these days?  ipv4only.arpa can be a preconfigured
> zone which allows CLAT to get its mapping.  All the phones have
> CLAT support.  Can we just make DNS64 historic and let the phones
> run all IPv4 connections through CLAT rather than having to stuff
> up DNSSEC and have IPv6 connections terminate in IPv4 servers
> without the application knowing?

If NAT64 was limited to 3GPP interfaces then not a lot of people would care.

The problem started when a vocal group tried to push NAT64 as a general
purpose mechanism for providing IPv4 access.

In that context, there are lots of devices that do implement IPv6, but
do not implement CLAT.

So without DNS64 those devices would lose access to the IPv4 internet.

If you are willing have a stateful NAT box in your network, and requiring
host changes is acceptable, then ds lite is in interesting alternative. 
One that avoids having a NAT function on the host.




From nobody Mon Nov 13 15:22:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F181124E15 for ; Mon, 13 Nov 2017 15:22:52 -0800 (PST)
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 vwQ2DVKhcbtw for ; Mon, 13 Nov 2017 15:22:51 -0800 (PST)
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 0C1B5124207 for ; Mon, 13 Nov 2017 15:22:50 -0800 (PST)
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 299C73B6C4B; Mon, 13 Nov 2017 23:22:48 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 18C6016008A; Mon, 13 Nov 2017 23:22:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 09D1F160087; Mon, 13 Nov 2017 23:22:48 +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 4MOCvw9a5yHD; Mon, 13 Nov 2017 23:22:47 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 69229160086; Mon, 13 Nov 2017 23:22:47 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements? 
From: Mark Andrews 
In-Reply-To: 
Date: Tue, 14 Nov 2017 10:22:45 +1100
Cc: ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DEA250E-0F49-4ACD-B31B-3F7E71181AFC@isc.org>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> 
To: Philip Homburg 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 23:22:52 -0000

> On 14 Nov 2017, at 10:08 am, Philip Homburg =
 wrote:
>=20
>> Is there any reason to
>> run DNS64 at all these days?  ipv4only.arpa can be a preconfigured
>> zone which allows CLAT to get its mapping.  All the phones have
>> CLAT support.  Can we just make DNS64 historic and let the phones
>> run all IPv4 connections through CLAT rather than having to stuff
>> up DNSSEC and have IPv6 connections terminate in IPv4 servers
>> without the application knowing?
>=20
> If NAT64 was limited to 3GPP interfaces then not a lot of people would =
care.
>=20
> The problem started when a vocal group tried to push NAT64 as a =
general
> purpose mechanism for providing IPv4 access.
>=20
> In that context, there are lots of devices that do implement IPv6, but
> do not implement CLAT.
>=20
> So without DNS64 those devices would lose access to the IPv4 internet.
>=20
> If you are willing have a stateful NAT box in your network, and =
requiring
> host changes is acceptable, then ds lite is in interesting =
alternative.=20
> One that avoids having a NAT function on the host.

I=E2=80=99m aware of the above.  I=E2=80=99m trying to workout if DN64 =
was turned off
today and replace with a preconfigured ipv4only.arpa zone on the =
recursive
servers would everything fail or would the devices just use the CLAT =
that
already exists?  Phones have CLAT for tethered devices.  Will they make =
the
A lookup with a IPv6-only ASN if the AAAA returns NOERROR/NODATA?

For wireline the routers are going to have to have CLAT support so there =
is
no needed to configure those routers with DNS64 servers.

While I think there are much better solutions than 464XLAT that is =
infinitely
better than DNS64/NAT64.

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


From nobody Mon Nov 13 16:11:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0274E12421A for ; Mon, 13 Nov 2017 16:11:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KWzg9ztSf4a for ; Mon, 13 Nov 2017 16:11:27 -0800 (PST)
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 BCC551200CF for ; Mon, 13 Nov 2017 16:11:27 -0800 (PST)
Received: by mail-pf0-x22a.google.com with SMTP id a84so8142385pfl.0 for ; Mon, 13 Nov 2017 16:11:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=e4xNxR6BPyGUhaNQTxzGx0C3nCFPCWR0Syvjk/+Uj7o=; b=AqSkmTCOBwcKpdnpvcbx6/Mvz8PIczxkrpsLxm+KNQscexxTfd3xmHVorXXF0O5ZAv VKrC3xu2Z5C/j1A+B2c01imrfGYrJtv+sSneJHBorvLDDmThDtpHvgnX/9ybcgLAAsHt JlB6S2yP2AcpZo1tzqUNpi5h1yNWdmqM7n0fxydokIbAZuVfS06lEF7hcARkSPkxvnPs x7R2GkfNxKKx9tGyYWLCh9v1F+e3ERCFfPArXyOZUXeVEJlFos52bGAagPRB+49++HMJ aIVAVM600ohspyaOxp3WnxnS2rxzPxL24oGYktXZmRp2SofxpGW7vwtkkhyKBwhCClQZ QC7A==
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=e4xNxR6BPyGUhaNQTxzGx0C3nCFPCWR0Syvjk/+Uj7o=; b=ChnNGTLoLfJweQBmuhGbp1hkMHSc5ZZX1Y8vB/rAtZFozG96s/Tz6yxjJaBaWFXf1a GoEQwacA/DpMkKo8MLIxnXqUJbWbOHo6qrxbTAuiaHJ+S2zy9uBUU71r5uVZCiyNozDm QVldJEkqlThnopxI9HIV3KfZ3u1t1D98TEmbiRw9EA9+vRKq6uU+4Fz8wC3a/XnHQkFH Ki0MaQ3k7f7D0+NFpaKFHID+pHyRbnN69BD7UnScpC/xEOL1QHpMyK1ZEQJS071WNvTU h/ne08AhvnzuyU/vdf4nsnZUYCk14q58xa1pMfVFxTxe5L2yQ2TSqbBX+UhPCTJ5z3dz P9ow==
X-Gm-Message-State: AJaThX58mUlao85ITKRj5VCvVGWfnXnVBb/EXOj+sm8l5xPlDfmjc1YL YkkS/ZF2t0G/1uoeC/JWqbH5JQ==
X-Google-Smtp-Source: AGs4zMaYml5QOs/qHV6iV4Bydpo2yaPvYzNKFqylJcPFRgqMnRG1/EygBG1WnKSlhtQSWGg5KbiupA==
X-Received: by 10.84.130.104 with SMTP id 95mr6166660plc.151.1510618286714; Mon, 13 Nov 2017 16:11:26 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id y20sm9736403pgc.52.2017.11.13.16.11.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 16:11:25 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Philip Homburg , ipv6@ietf.org
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>  
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Tue, 14 Nov 2017 13:11:24 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 00:11:29 -0000

On 14/11/2017 04:35, Philip Homburg wrote:
>> I am not optimistic on the demand / need / value of dnssec in any scenario
>> ....let alone an ipv6-only host validating an ipv4-only dns name. If the
>> folks operating this service cared, they could operate the server with
>> signed v6 names.  It is more reasonable in todays internet to asked the
>> server (lets assume most signed name scenarios are servers) to be setup
>> right (with v6). There is not a compelling reason why having v6 is
>> unattainable today for named nodes.
> 
> DNSSEC is something that works today. 

This is not the impression I get from attending IEPG meetings
and chatting in the corridors at the IETF. Also, we knew throughout
the development of NAT64/DNS64 that DNSSEC was a major stumbling block.
I don't think it is a good idea to entangle RFC6434bis with that issue.

    Brian


From nobody Mon Nov 13 16:11:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ADA1288A9 for ; Mon, 13 Nov 2017 16:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL6htUWGFEMl for ; Mon, 13 Nov 2017 16:11:49 -0800 (PST)
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 625791200CF for ; Mon, 13 Nov 2017 16:11:49 -0800 (PST)
Received: by mail-pg0-x229.google.com with SMTP id 207so11150774pgc.12 for ; Mon, 13 Nov 2017 16:11:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fXy04IJNCjnId6U3LGCUzBg2aPnpO9v+8PRBqGUS/6k=; b=ZW5/qwMTyOr/YAmy3gCXjI1VGl18KAaYtpoyjht7UWkblu+nn+r6f4Kkfd3krqnlLl nris06NDgUzqAKlRKUU2cou3n3uI/GRPLURA+t/4xq2HDGa1byYLoXV04hrAnrAFYG+L BN5uRldfpzGS7OEq5XFMrVtPsP3RKltQqzFOx1WX5rqZPYMR/vnRoZuYlGcuZ+jsKwi/ aPvu1joF8bu+HbVhaxToJwq27O/Eq+07dqffsg9gropkNEok+mUsTnx3LexpgVfcE+23 z1rOEXTINZNse9yzfT9DhoY100gGREIDq6tHwL6/j182sYaWSk3es4wa4CcbtVWl7LDg dSwQ==
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=fXy04IJNCjnId6U3LGCUzBg2aPnpO9v+8PRBqGUS/6k=; b=hvpIsFX7SEgj1YYMTZ60vbzgrAVuqCoV07/p/cpsfDbXesksfb0e6wcXIerN56qkeE lqbTsxMM5W+9ZOQvkZCrXZgztwBY3vbiRvILk3I/MgF6AYRAaWySVgPeFHLuZwBE3WXZ vFzVd0dHxnZD+Ybvj36crWNOgOI1HvrBTedKb/DBTwGg18FAoYChNawywwM3WF+F2W4b Ar6joPNHHn86nL9EKTP1PwVUp/LAUxSEuB/pT9HKKHByvx0rbWan9wdLdNcc0ywirVHA 6FWzJ0c1IPxoBrveS9CRXq+ZO7VXOLdRIzMYxn+zvRC2TKPvc0ODn1nkCdkqkUg4W7kl Ma2w==
X-Gm-Message-State: AJaThX635MERi6ff5fn2E32dEeP44ft/E+koeKfprusH1YhNdO4cKjJx 2kaDtjv5volBs5EkoRkJK/Oz5g==
X-Google-Smtp-Source: AGs4zMYtO8quRYTyKVa2g9QgVtgD5PglG65yCcVNv/By9Cb+Aoadwld0g/WNvlytK/eKR7zqrTSQfQ==
X-Received: by 10.84.194.3 with SMTP id g3mr10779554pld.400.1510618308709; Mon, 13 Nov 2017 16:11:48 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id t2sm38242691pfk.90.2017.11.13.16.11.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 16:11:47 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Philip Homburg , ipv6@ietf.org
References:   
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <909eb642-b2a0-2fb5-8f41-297e013ae307@gmail.com>
Date: Tue, 14 Nov 2017 13:11:46 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 00:11:50 -0000

On 14/11/2017 05:16, Philip Homburg wrote:
...
> But for host software there is a lot more incentive to support dual stack then
> to do the extra step for NAT64.
> 
> The big problem I see for NAT64 is that for old IPv4-only applications you 
> have to make two fundamental changes to the application. The first to 
> make sure that the application handles IPv6 in every possible way. And a
> second pass that makes sure that every place where an IPv4 address literal 
> is handled, works with NAT64. 
> 
> For an application writer it is better to try to avoid doing the second pass.

I think there is a missing document, and it may well belong in v6ops not
6man: "IPv4 Applications on an IPv6-only Host". 

Your text above is probably a good summary of what the document needs
to cover. (I also suspect that if this document existed, we wouldn't need
Jordi's draft attempting to define "IPv6-only".)

   Brian



From nobody Mon Nov 13 16:32:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE411243F6 for ; Mon, 13 Nov 2017 16:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1yKDlhuD2QB for ; Mon, 13 Nov 2017 16:32:47 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1496F128954 for ; Mon, 13 Nov 2017 16:32:47 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 68DAB2D4F99; Tue, 14 Nov 2017 00:32:46 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BF1D7200C08C5A; Tue, 14 Nov 2017 08:32:21 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_9989E0A9-117E-44C8-9F8A-D2C9992BA70C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements? 
Date: Tue, 14 Nov 2017 08:32:20 +0800
In-Reply-To: <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>
Cc: Philip Homburg , 6man WG 
To: Mark Andrews 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 00:32:49 -0000

--Apple-Mail=_9989E0A9-117E-44C8-9F8A-D2C9992BA70C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Mark,

> Is there any reason to run DNS64 at all these days?  ipv4only.arpa can =
be a preconfigured
> zone which allows CLAT to get its mapping.  All the phones have CLAT =
support.  Can we just
> make DNS64 historic and let the phones run all IPv4 connections =
through CLAT rather than
> having to stuff up DNSSEC and have IPv6 connections terminate in IPv4 =
servers without
> the application knowing?

For the last point, that's no different than today's IP4 network where =
addresses change underneath you.

The scenario this thread is about, albeit the efforts in derailing it, =
is about an IPv6 only host (and application), connecting to something =
like the Internet. The premise of the experiment was "single stack".

There is therefore no CLAT in this scenario.

If you go back and look at my proposed host requirements, you'll see I =
added a requirement that hosts must be able to do the DNS64 function =
themselves, exactly for the reason of solving the DNSSEC problem with =
NAT64.
Now people here tell me that local validation of DNSSEC isn't done for =
IP4 either and in practice it's not deployable. I'd hope that's untrue, =
but regardless you don't appear to be in a worse position with DNS64 =
than you are without. Either you trust a distance recursive resolver to =
do the validation for you, or you do validation yourself (and also the =
synthesizing of IP6 addresses).

Cheers,
Ole


--Apple-Mail=_9989E0A9-117E-44C8-9F8A-D2C9992BA70C
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+/bDNdvtpYqJhC33YFAloKOZQACgkQvtpYqJhC
33bFxQ//ViLMjrgwnbsloeb/sZg7KZDLAGAcUehOTDxY4yBL9ez76OUlcPRK7L4v
0fizDylYzsAq2BEoQK+VyM38aCpoxRG3/889+MPxjNPVShi/cc3LMJnGUalEAU3p
aTLGeqNvIJw8hQC5m6CKxTuarnK3YWpA/tv/BxtIRvBcIVPxOJug6HAokBQsitbJ
nY7NT0QwLTCtcRQ5NyNbi06iJjvEOPqs3hKnS8OSDnR7zk9uW/zaPKimxE3X0t4q
ckKcoQ/ugj8rbKUERxEr04Wqyaiha9ziNNUoqm+gyPicFmPN5NkbXpHnCkaoVPsl
91yBHbSDfZrdtu0eIgPTSrQAZ5DHp5Vi5VIYDrA7q7w3iSmzhDXwHEUBRHKk1lyc
PTrn91QymzpkXGhNZuTj9HbJQu/KcAjtEGhAewX35cgYjkUlUvlkC+ncy6iZk5iE
AxsoptPY+wkE8Xt05mSmBXzqwC4MgrofjjsetVeI0VjPMzK/lCaWYtSYFb8dkV9N
fWqT0VXJslbFA/5Lh38Vi8s/ke9eWmiL2QBLm6JL9dvc6tYPpl1KhIqXUNvND5yL
79LBqJ/4mvymc7xoGpgps2rnZFdd5fVVIZm1QPFf7azZqtzvk8W7LruCOVpPXZiq
b7BKTGmrNSSzZ7Lm6yc5Bgf2cAHQ/xNLDG5DQ+QK52RbQPOTYO8=
=91dc
-----END PGP SIGNATURE-----

--Apple-Mail=_9989E0A9-117E-44C8-9F8A-D2C9992BA70C--


From nobody Mon Nov 13 16:34:43 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D3B128954 for ; Mon, 13 Nov 2017 16:34:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z8KhMGqTPf7 for ; Mon, 13 Nov 2017 16:34:40 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99CB21200CF for ; Mon, 13 Nov 2017 16:34:40 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 1C2692D50CE; Tue, 14 Nov 2017 00:34:40 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 815F6200C08CDD; Tue, 14 Nov 2017 08:34:16 +0800 (+08)
From: Ole Troan 
Message-Id: <9620CE6D-6364-41E9-A43D-AF0690D2A5F4@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_B263468C-9C2E-4785-89C2-2D6F0CF95384"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Tue, 14 Nov 2017 08:34:15 +0800
In-Reply-To: 
Cc: Philip Homburg , 6man WG 
To: Brian E Carpenter 
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>   
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 00:34:42 -0000

--Apple-Mail=_B263468C-9C2E-4785-89C2-2D6F0CF95384
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Brian,

>>> I am not optimistic on the demand / need / value of dnssec in any =
scenario
>>> ....let alone an ipv6-only host validating an ipv4-only dns name. If =
the
>>> folks operating this service cared, they could operate the server =
with
>>> signed v6 names.  It is more reasonable in todays internet to asked =
the
>>> server (lets assume most signed name scenarios are servers) to be =
setup
>>> right (with v6). There is not a compelling reason why having v6 is
>>> unattainable today for named nodes.
>>=20
>> DNSSEC is something that works today.
>=20
> This is not the impression I get from attending IEPG meetings
> and chatting in the corridors at the IETF. Also, we knew throughout
> the development of NAT64/DNS64 that DNSSEC was a major stumbling =
block.
> I don't think it is a good idea to entangle RFC6434bis with that =
issue.

What's the DNSSEC major stumbling block?

Ole

--Apple-Mail=_B263468C-9C2E-4785-89C2-2D6F0CF95384
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+/bDNdvtpYqJhC33YFAloKOgcACgkQvtpYqJhC
33aMaRAAoQ+VbxyNzkat6lW5YaFvUR9a+wkGJFmytYAPsDM4sfZ3bUN2K1d1sgZp
BjqCLQLUM68p4Du+UpDqH/XYD4LC9ZHqJPhg9bjBR0IpX7cqE3rmlCy6uBJRWf0e
OmW8HetdfmNG8B2QzEkfA8AP93CnKs5VlBtrBOLq76LqpTlf/AJ3k47e4YGJ2zKA
wBD2qusP4sZNRXlZgCi/9UsoNsaDI/6Dpw456PRa2EBEsQw1bg82UU1DFJO24MBQ
LSYiIVeQ49kNi9kZxn5OEcC4I76lwyQvKRTuWspehVAt7Ii+gqs17VFQcQAMxb2E
rg50wA4ij6fRVb5+3bZM/Aqb87SHX0Mh6YmjS7Fezb9NWH0yo+iAFdNHco2R+h8c
kuT5kpXqfq3s3t5CvVuUgAouxOn9mFGhkFg1mbZGKrejEW56K6l9Gb46rVlJNVdA
QfCeJ46y+l7BeXDMsrZ/PTjt29SEf8d8IgBj7FQPdW8jbgjnho2LzcXKn0mZSVOQ
F1mDq0zULlds/NNbZBa5+72UUuQpaalNsE86gZVUHmA6hq4CDnRplPoulFzAP3d5
bneRV0YAXe064JbSd3LsJUml9oP8xIQ8TkPphE7jhxSXnfXLO0lOEAdJEbLs5O6E
/AumiLcLeJ3l7hVWIvsGqN0ydJVhP71ZPvCypvblE0jSN6NuSfo=
=Ly52
-----END PGP SIGNATURE-----

--Apple-Mail=_B263468C-9C2E-4785-89C2-2D6F0CF95384--


From nobody Mon Nov 13 16:38:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E31126CD6 for ; Mon, 13 Nov 2017 16:38:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2Cht-oZMF_M for ; Mon, 13 Nov 2017 16:38:05 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E6D1200CF for ; Mon, 13 Nov 2017 16:38:05 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 2BC572D5122; Tue, 14 Nov 2017 00:38:05 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 3099C200C08E7C; Tue, 14 Nov 2017 08:37:41 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_F1AE219E-F75A-4B7E-B41D-8335A79ADCA4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Tue, 14 Nov 2017 08:37:40 +0800
In-Reply-To: <909eb642-b2a0-2fb5-8f41-297e013ae307@gmail.com>
Cc: Philip Homburg , 6man WG 
To: Brian E Carpenter 
References:    <909eb642-b2a0-2fb5-8f41-297e013ae307@gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 00:38:07 -0000

--Apple-Mail=_F1AE219E-F75A-4B7E-B41D-8335A79ADCA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Brian,

> ...
>> But for host software there is a lot more incentive to support dual =
stack then
>> to do the extra step for NAT64.
>>=20
>> The big problem I see for NAT64 is that for old IPv4-only =
applications you
>> have to make two fundamental changes to the application. The first to
>> make sure that the application handles IPv6 in every possible way. =
And a
>> second pass that makes sure that every place where an IPv4 address =
literal
>> is handled, works with NAT64.
>>=20
>> For an application writer it is better to try to avoid doing the =
second pass.
>=20
> I think there is a missing document, and it may well belong in v6ops =
not
> 6man: "IPv4 Applications on an IPv6-only Host".

IPv4 applications do not run on an IPv6 only host, so that's a short =
document.

> Your text above is probably a good summary of what the document needs
> to cover. (I also suspect that if this document existed, we wouldn't =
need
> Jordi's draft attempting to define "IPv6-only".)

Please take that to a different thread. This thread is about a IPv6 =
only, single stack host connecting to an IPv6 only network.
With a backdoor to the IPv4 Internet for legacy destinations.


Ole

--Apple-Mail=_F1AE219E-F75A-4B7E-B41D-8335A79ADCA4
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+/bDNdvtpYqJhC33YFAloKOtQACgkQvtpYqJhC
33YQlg//ZQfeBQezlgdbSZiYxP8TXTBEtBNgdCH9326a4rT/9PgB7GSRQBYJ1iI4
fYUtWoEqEz/E+Nk2xfSWKy1G/T1D2rgKD4Buu8V96l6Men+86NYpURJpW/QMfXU1
gt0Kv0P8al5i9eeB2L3zQqcKw8s4eR3QqusyPgZJ4DNUuwmF5Ne2ofKbwL1hIGWe
CmUq5V72lqbzTYa9yNvdgcStiROdk28YesOefHTpXMyCUn/NXJ5g9PQWsZCJHGHD
o8mKZX1XN8eVDUeUK9DLsQlmQG+Jx7gaegs8X2AACGiolPY4IIJ/yP7kttCjhWVE
sIO92+ystMkOXdo8jqAaiva2ALBS72xfZjdYBs3HVbeOtPZTLMyHpolJi4hWlrl1
hA9vrtqF95tFvUn3SU+KpRMPWjyXwrHTux0neYjtOHu4HelBjNzKm8LqCjWe6k+m
rHw86j3/x2tU84+Uq+8WTFivixwwEOt3iGspAMCFJcHiStYlLYwz9EpGn+WZejyL
PKMuvMDuHdXt1K18bKPumV8wtsQlT5Wy2Fa/hMGBPuNe2rusohkv1Sb2nwbBOhJf
oNb5NO6VGmg+crrnCy15+bvri7zdGAmMwYMfTGcIwcNwOxBmnee+f3aL/JdvCYzw
7gktWgohdkbLilOheXNXGrqnNmzmYIj2J3a9xlJYZNE1lTY5Oqg=
=Z2Zt
-----END PGP SIGNATURE-----

--Apple-Mail=_F1AE219E-F75A-4B7E-B41D-8335A79ADCA4--


From nobody Mon Nov 13 16:38:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F29129431 for ; Mon, 13 Nov 2017 16:38:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1lBZJCLBN9w for ; Mon, 13 Nov 2017 16:38:44 -0800 (PST)
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 D95F5129438 for ; Mon, 13 Nov 2017 16:38:44 -0800 (PST)
Received: by mail-pg0-x22a.google.com with SMTP id 4so5106274pge.1 for ; Mon, 13 Nov 2017 16:38:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SuhZy0ujp0nJiFyjK4QiHxeAaryKlYYBAC5yiuxXt68=; b=dBeOotdtCyKli6EguwRxNf0F4dqK1SsXgrV+RPIBJ2l8lS/W3xM6Is7wz0Exc59lSm k0vfKyEKH46JEClFAXI7lunJvJayIDLo0fpVBMqb+DSi9zjcFeWXaVV4y3ctccmU2qRe sHnBkisgZqzSYJzSaNvcDxNkdVPRdkVHcGgkhSHqbO2PBhZvZeWwRkV6UaWWvBnX147Y SXC3ujZgIi5PKo4bY52tZLRa58QM0oVYGDhqMCzE0IzEb2BMJ29jJZvlANGCDXIG8F0Z ennOKKDQw23vPqnioBnSQRpsBbrcKygwF26x4Fa3BSbEfCphwqAH4Zkpzgu2evNdKbGT JnUw==
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=SuhZy0ujp0nJiFyjK4QiHxeAaryKlYYBAC5yiuxXt68=; b=NfAyTkFZB3nLKfATU8J88SGqDx59U6ASnRFawU5XLkjYvcoqhHE4vaPhbBl6XN03Bd ZS3ymc5EuW6ooPxiNe1LPZYb4Dr7zim+0QFahMhbNwcUJOvAGiLyiCF78Qf8dTiBdOPD GxzWwcJ7EeymEamdmv0xlrcENjxQ01fI/cSfZLqjirMUfi9ZIbExB1xQ07C4wUcf5ziD dbgG7NvFDOD9RFGQ9rZ94LSsnBhDC1i/xRLVs2GF1gqwyG1XlbYzEGvlY6zUTagsXqfF OD3nm6cTq31k/4XEbv0EzeYRWDrlyKo0rS5PIhOGYsX4cxyVTyMI0F/mBLBZyTvhQ+yP XzoQ==
X-Gm-Message-State: AJaThX7uoDho3AAIVzlUF7d2wh0GUuMFDZuMRnAWllDtD3HPizxQKsaz 0hUgWnliZAfVmdHa1ijEPJ5CCA==
X-Google-Smtp-Source: AGs4zMaKq+g+VqjwxgyMWgyCpVqqh4YdP3r3V6O6FFXzQunofxscpi83F9iWAEW6wzozPvIo1gIDCw==
X-Received: by 10.159.241.129 with SMTP id s1mr10476378plr.378.1510619924042;  Mon, 13 Nov 2017 16:38:44 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id u9sm39717692pfa.40.2017.11.13.16.38.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 16:38:43 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: Philip Homburg , 6man WG 
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>    <9620CE6D-6364-41E9-A43D-AF0690D2A5F4@employees.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <1bcc9417-6f00-48ac-b9ef-0317f6f43a56@gmail.com>
Date: Tue, 14 Nov 2017 13:38:41 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <9620CE6D-6364-41E9-A43D-AF0690D2A5F4@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 00:38:46 -0000

On 14/11/2017 13:34, Ole Troan wrote:
> Brian,
> 
>>>> I am not optimistic on the demand / need / value of dnssec in any scenario
>>>> ....let alone an ipv6-only host validating an ipv4-only dns name. If the
>>>> folks operating this service cared, they could operate the server with
>>>> signed v6 names.  It is more reasonable in todays internet to asked the
>>>> server (lets assume most signed name scenarios are servers) to be setup
>>>> right (with v6). There is not a compelling reason why having v6 is
>>>> unattainable today for named nodes.
>>>
>>> DNSSEC is something that works today.
>>
>> This is not the impression I get from attending IEPG meetings
>> and chatting in the corridors at the IETF. Also, we knew throughout
>> the development of NAT64/DNS64 that DNSSEC was a major stumbling block.
>> I don't think it is a good idea to entangle RFC6434bis with that issue.
> 
> What's the DNSSEC major stumbling block?

I pass. Try asking Geogg Huston, for example.

    Brian


From nobody Mon Nov 13 16:43:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D00B126CD8; Mon, 13 Nov 2017 16:43:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hhNReDQ46yv; Mon, 13 Nov 2017 16:43:02 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D192126CD6; Mon, 13 Nov 2017 16:43:02 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id m88so5852509pfi.9; Mon, 13 Nov 2017 16:43:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EOHHCOUcx4xOJzYAc5sPkJh10EUC8BEwyZ7ohidb9r8=; b=dAE4Kyg8oP6qhWLvrm0JShoJfctvvOE1S2SFmP7UmRmy7Ppfs5YmhJfjxBltoV1YNj qjKwwDTD7Qo+2kLgyjMr7jjJyMO4MmsAOGT4WrvyI/jHalRbBF3aKMq9t13V1mFHfoHM k1jo2KU2/Fs+52/YJ1GC00OZPEJk2kXXkCpYIH5DaKy/PbGU94BToNGEpl9S3MjuObSW ie2G9VBYOKJPsa8CFmnmfCgVlYY7uKU0yGheAMhC68JXVQ3mwtszQ2JaMcYHcKvpIvUX yhQVOKaNSuk8TPhopCCsuWIpqxfuWkeriauQgtoPM0VCkGoHHzO5yACAXDYIjeAiSIn/ TdFQ==
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=EOHHCOUcx4xOJzYAc5sPkJh10EUC8BEwyZ7ohidb9r8=; b=aunHylVQ+m+XM7PVmEIO8Bw1JpmZ51elQV3J3yB7Cb2XAEfo0d+dsHWCvCafXLgpkH BH4Voot7ri5ak1AJhqToapb6F04TbZinqXzAbzie5xYNHC1cbEeOuMawfYKpVXlCHFDv p7z91E6aRTUuSx1W7htVM+mH/WLsXlrMJYf7pxAf3Pdf5b/X4Eziwht020eti7x94dmO mzS/IL7Zs8qIn7JZaCtgUR/tEgvbgJmee0xBf1KSRo0DOxGBts1cUSgGenDIIfVl9eHL QnQ+XpIeEQ6JSD5bnXXzZxPruEkC4hSaA49MsjeMtIGtWSyzVui9WPu3wbOhc522Uadw +Gdw==
X-Gm-Message-State: AJaThX7HMdNi+NJJcFntzYpvMPmJvaLgRObVsjH5tLGRWjrCfIK5mZjT UQjcK+PEtLd4eN2eOTrOgrI=
X-Google-Smtp-Source: AGs4zMbC3YEiai81coMg5Vd/FFj8d6dC2fR1wEo02Q1hHYf0NjpeOlDkT2+/i9pIx71sTtiYtawEZA==
X-Received: by 10.84.133.15 with SMTP id 15mr9127548plf.367.1510620182157; Mon, 13 Nov 2017 16:43:02 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:b445:d6af:36e2:368f? ([2001:67c:370:1998:b445:d6af:36e2:368f]) by smtp.gmail.com with ESMTPSA id 70sm33034457pfv.97.2017.11.13.16.42.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 16:43:00 -0800 (PST)
From: Fred Baker 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_2902D3CE-E479-4FEE-B231-1977C971672B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.11\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Tue, 14 Nov 2017 08:43:03 +0800
In-Reply-To: <5A0999A4.3040807@foobar.org>
Cc: Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
To: Nick Hilliard , Lorenzo Colitti 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <5A0999A4.3040807@foobar.org>
X-Mailer: Apple Mail (2.3445.5.11)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 00:43:09 -0000

--Apple-Mail=_2902D3CE-E479-4FEE-B231-1977C971672B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Chair hat off.

> On Nov 13, 2017, at 9:09 PM, Nick Hilliard  wrote:
>=20
>>> =46rom a operational point of view, one would wonder why pursue this =
path
>>    as opposed to e.g. do DHCPv6
>>=20
>> As for DHCPv6 specifically, one reason is that DHCPv6-only networks =
are
>> not recommended by the IETF. RFC 7934.
>=20
> reminder: there is no WG consensus that this is what RFC 7934 means.

I just went back to read it. Having an argument with the author of a =
document about what it means is an interesting tactic.

There are 26 references to DHCP(v6) in the document. The vast majority =
of them are factual - "it does this, and there are networks that use =
it".

The two references I found that are negative statements about DHCP are =
about IA_NA. Section 8, second and third paragraphs, reads

   Due to the drawbacks imposed by requiring explicit requests for
   address space (see Section 4), it is RECOMMENDED that the network
   give the host the ability to use new addresses without requiring
   explicit requests.  This can be achieved either by allowing the host
   to form new addresses autonomously (e.g., via SLAAC) or by providing
   the host with a dedicated /64 prefix.  The prefix MAY be provided
   using DHCPv6 PD, SLAAC with per-device VLANs, or any other means.

   Using stateful address assignment (DHCPv6 IA_NA or IA_TA) to provide
   multiple addresses when the host connects (e.g., the approximately 30
   addresses that can fit into a single packet) would accommodate
   current clients, but it sets a limit on the number of addresses
   available to hosts when they attach and therefore limits the
   development of future applications.

I think it is absolutely fair to say that the RFC doesn't recommend =
(recommends against) the mechanism that IA_NA uses. That said, the =
laptop I'm typing on (a Mac) generally keeps 2-3 addresses per interface =
and has several interfaces. 30 is a viable number for it. I can also =
report that I have worked in an environment that only uses DHCPv6, and =
it worked just fine for any purpose I put it to.

--Apple-Mail=_2902D3CE-E479-4FEE-B231-1977C971672B
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+AFAloKPBcACgkQEhdRnd2G
P+BZ0BAAnwhap9oQhTVPlVDE3ShWpbioV5UVgBmsObzeEfHWlX8qDrYHO+qUe0AS
q32A0rps8l3y2Ah3huzrD/OdT+sV3S9rklDSDgFU6wq/n6A/1rjiYvL0uULXeZF0
1AMLIAQD8lq6Z5aVFi+nQ0xGG4I2JG2QqJVyRXtMhg1/J1vnVU4t/smG9rkbZ7fA
bUYzS0n+I1auYWFDsTIzfYLlE9n3V5RQX/Cyw+YyFo01D2lEam106ZMDY0fE/TT8
JPKjbNXDOIeW6/nzHSaMKEaFoYnuR9fhnWhIcmaHGN4VtVUlqxJ1hht370SPhr/r
K0l2bd9b6s0HkDZDz6TvbDhuTRErscQp5Bzg7EAvD4p3FzIn2RDA2AMofg093mPz
FYE7opXltnaly8yBJv8IAUBuKQDkpnm94Uz7Jq265+W3NXQS4R6Rtk3XoqJaNuuz
ooCV8tuumlnqiNZi2tf2xYH9hTzTh7+NYLnmMB3uhVJJsJyjoDXAimx9NEkcd+wV
qY6On1pM8r5ZnmFt3WcMgNleWSNM7kqdoeG5jwCMEwX1O5uxOLcShg1rNRmU3SGa
cAd8sftYYP0pzsFnVk+5YUVDaWG3O6dG6GaSyhxESICX/0GPq7weOOdZmV/XQDVg
tDO0bDswTxLyAxEd7/E6VvauLHkelMVEcnAhy4l1kcS99+x8N+I=
=R8c1
-----END PGP SIGNATURE-----

--Apple-Mail=_2902D3CE-E479-4FEE-B231-1977C971672B--


From nobody Mon Nov 13 16:58:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FB0124F57; Mon, 13 Nov 2017 16:58:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbHu7YKsgURX; Mon, 13 Nov 2017 16:57:59 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2E41200CF; Mon, 13 Nov 2017 16:57:59 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 94E852D5124; Tue, 14 Nov 2017 00:57:58 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E1B27200C0969C; Tue, 14 Nov 2017 08:57:34 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_7AB1DA3E-4D11-4C9C-BB81-5BCD9E1B8C11"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: DHCPv6 PD route injection (was: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
Date: Tue, 14 Nov 2017 08:57:33 +0800
In-Reply-To: 
Cc: Lorenzo Colitti , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: Mark Smith 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>    
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 00:58:01 -0000

--Apple-Mail=_7AB1DA3E-4D11-4C9C-BB81-5BCD9E1B8C11
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On 14 Nov 2017, at 03:43, Mark Smith  wrote:
>=20
>=20
> DHCPv6 has been designed to avoid having state in intermediary devices
> by incorporating a relay agent into the architecture, specified in
> RFC3315.
>=20
> Clients use DUIDs to identify themselves, and the DHCPv6 server
> associates client attributes with the client's DUID. That is what
> allows DHCPv6-PD to survive a router/DHCPv6 relay reboot.
>=20
> This draft hasn't been published as an RFC, however it is also
> considering this issue.
>=20
> "DHCPv6 Relay Agent Assignment Notification (RAAN) Option"
> https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-03
>=20
> A number of vendors seem to have implemented the functional equivalent
> by looking directly at the ID_PD option when the DHCPv6 reply is sent
> to the client - search for "DHCPv6 Relay Agent Notification for Prefix
> Delegation"
>=20
> The alternative is to have a RADIUS server provide the delegated
> prefix information to a DHCPv6 server running on the router. "RADIUS
> Delegated-IPv6-Prefix Attribute", RFC4818.
>=20
> Possibly the RADIUS method could be used in this draft's scenario if a
> layer 2 attribute such as the MAC address or per-client VLAN tags, or
> 802.1X authentication information, is used to identify the client.
>=20
> If this draft can't document that method because it doesn't exist,
> then, assuming Comcast is the only deployment of this, it seems
> Comcast aren't trying to have a prefix assignment survive a router
> reboot. That's a "flash renumbering" approach, which I don't think is
> right for IPv6.
>=20
>=20
>> This has not stopped the deployment of tens or hundreds of millions =
of
>> networks that use DHCPv6 PD.
>>=20
>=20
> What was the alternative that didn't have this limitation?
>=20
> There is a big difference between something working and something =
working well.

Yes, it's quite unfortunate that we haven't solved the problem of robust =
route injection in PD yet.

Ralph and I when writing 3633, concluded while there were many options, =
few of them were attractive, and instead resorted to specify that PD =
must operate without relays.

Markus enumerated the options here:
=
https://www.ietf.org/archive/id/draft-stenberg-pd-route-maintenance-00.txt=


Let me know if you are interested in working on the problem.

Best regards,
Ole


--Apple-Mail=_7AB1DA3E-4D11-4C9C-BB81-5BCD9E1B8C11
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+/bDNdvtpYqJhC33YFAloKP30ACgkQvtpYqJhC
33bAzhAAnpRbqiFW4L7g7LpB2P/GbgkoRYnxYBuzlNrbcearHLMfJ3PsnMXS3Ui9
OqaQA087MNNpGY+qCrVLQZKFeRV3qWVklQPfQvVyp+FdQw/zeB6gDwozMs08zl+T
LiecG6oQutgBl1tHhE406fgy2+ICLkiPYtrW9QZpisMtMkTF1gGm6cqtzJDXO3bg
X0YZzo/HbcnnjE3HptQUFX0RrMfrfBlPbtKf3LHT7dTl6wRbG9X5A0N+sh2HeQ2g
XwzglqeuvwPK7qRykyGoaPam5p1Llm6BcVMf84+67bQMnvufvFMz7S7t8EtMQgr8
ArXe7qwFewYvudyzX5CfxrAYU/yS6OOvPVQrlDRp4zpwsu6ayXRH0wOYDaL3VpdA
yvyozWhZM5ghHRf709wFfLID6hbfk3ctq7RSarO0RVnoO9UBtIwbDcgeZSmJ87pO
+K9vWr8qwN5AxH/dJ1Tefc+1eNIA+BDORTgDtT4VDbe1Yaan8sWUkxjAbu+6UBot
oSwGhatGKBE/4r8QmfInQ9qtY7LzEjOnWqYJNS1beOgpno9awAzkNXYV2RNM1xPd
om0hiIyt9Ae+aLr69HsidZ1iwNaCp+kWVTDpf30/zznC0siBUZVEBVGS6LR3IXOo
JELoT2wPmoOxP8odaUc8nOaqXt8xzM654YKFrS9xJdAxNiXmYkk=
=SiD0
-----END PGP SIGNATURE-----

--Apple-Mail=_7AB1DA3E-4D11-4C9C-BB81-5BCD9E1B8C11--


From nobody Mon Nov 13 17:04:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47B01205F0 for ; Mon, 13 Nov 2017 17:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJihNpGwtzSn for ; Mon, 13 Nov 2017 17:04:12 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E68F126579 for ; Mon, 13 Nov 2017 17:04:12 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 AF56F2D5038; Tue, 14 Nov 2017 01:04:11 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0170A200C09DA0; Tue, 14 Nov 2017 09:03:47 +0800 (+08)
From: Ole Troan 
Message-Id: <39CD5C15-5A9E-4CD5-BE89-890EAF516E22@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_9BE49051-8665-4F5C-B0E0-F7F0A4C72995"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Tue, 14 Nov 2017 09:03:46 +0800
In-Reply-To: <1bcc9417-6f00-48ac-b9ef-0317f6f43a56@gmail.com>
Cc: Philip Homburg , 6man WG 
To: Brian E Carpenter 
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>    <9620CE6D-6364-41E9-A43D-AF0690D2A5F4@employees.org> <1bcc9417-6f00-48ac-b9ef-0317f6f43a56@gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 01:04:14 -0000

--Apple-Mail=_9BE49051-8665-4F5C-B0E0-F7F0A4C72995
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Brian,

>>>>> I am not optimistic on the demand / need / value of dnssec in any =
scenario
>>>>> ....let alone an ipv6-only host validating an ipv4-only dns name. =
If the
>>>>> folks operating this service cared, they could operate the server =
with
>>>>> signed v6 names.  It is more reasonable in todays internet to =
asked the
>>>>> server (lets assume most signed name scenarios are servers) to be =
setup
>>>>> right (with v6). There is not a compelling reason why having v6 is
>>>>> unattainable today for named nodes.
>>>>=20
>>>> DNSSEC is something that works today.
>>>=20
>>> This is not the impression I get from attending IEPG meetings
>>> and chatting in the corridors at the IETF. Also, we knew throughout
>>> the development of NAT64/DNS64 that DNSSEC was a major stumbling =
block.
>>> I don't think it is a good idea to entangle RFC6434bis with that =
issue.
>>=20
>> What's the DNSSEC major stumbling block?
>=20
> I pass. Try asking Geogg Huston, for example.

As far as I understand it, DNSSEC has deployment issues, which are =
comparable for the DNS64 and non-DNS64 case.

https://tools.ietf.org/html/rfc6147#section-3
https://tools.ietf.org/html/rfc7050#section-3

But I will leave someone who knows DNS to give a definite answer to =
that.

If I understand what people are telling me correctly, your statement =
"major stumbling block" is not correct.

Best regards,
Ole

--Apple-Mail=_9BE49051-8665-4F5C-B0E0-F7F0A4C72995
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+/bDNdvtpYqJhC33YFAloKQPIACgkQvtpYqJhC
33aKUhAAyPlCd644Firg3OjPOQl4EuVDDl9LWneN0s7Eqgt8ogl+F/sjjdZWHjac
Wl6s2R2O17R7S7msaAslWRf1r51858kORIG99M8mh6P+tX/mNF1pWpwE/CT+evZ+
CgDI4DT4YGWByy2qF+QQ8umViuImG1HhdQpwvunhWzOR1uk5hZANMV05niGEWkcI
VV+06FpV1sqJiHjMKKwTSJLY6FMmULD0Lobw+RIYJ30CcTJyRpOqUKqRUXOfQqGc
bK06dWm59jBFb/GUhq2Ws0h3ZppE61Z/+X9FWmbbSL3zVTNO+ccuedXP4Zjt1OOb
8K2NYwjyD6iEVvwsptFp4f5D3xxPW5D+KQmqanQm71aKLhrco7QzmY5G4UCNvWGx
7KWTnwoVpHAhrMEVad8G3st/0I4FRqkgENLXPkCn2Y33DLXsuIBop+ntyY17vy4z
yoRITaWfr8FeSBJ0Hk6xndr4wY5yUtAOdRBf0OQbmJI8tYF/3KpFEoa9zlTeId43
TkYtrUbuuHy0Sd9ZbIFIRSqHXJZlYP7wJYN42KPVm9pVpiMsXe1bL/hwrroTLxfG
WvrduENQGLFoqf7LuAJdCkAuls/xJaSk7HmOyTlVMtTW7vN4MOessBDw+7bWKpCB
cuTynRL46hTI3er01DEuxgkmeu/lCdK7r3ff8879ShIPh/UDJSA=
=aqk1
-----END PGP SIGNATURE-----

--Apple-Mail=_9BE49051-8665-4F5C-B0E0-F7F0A4C72995--


From nobody Mon Nov 13 17:33:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589AD1270FC for ; Mon, 13 Nov 2017 17:33:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lE-e2Oyxgq5v for ; Mon, 13 Nov 2017 17:33:09 -0800 (PST)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9D11205F0 for ; Mon, 13 Nov 2017 17:33:09 -0800 (PST)
Received: by mail-pg0-x22e.google.com with SMTP id s2so14085823pge.10 for ; Mon, 13 Nov 2017 17:33:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=d8Z7Uvq9d88JzwVvPVknHUB1Roir4zpJ6Chm+a1phTg=; b=TBEM+wXg95D4V3zyYvjSLQkbimlJ3GBch2dguESGpA4qaN2OwcdbIHWxu6dn2+faqY J8dI/k/2RiMLJjp8o3C/xESrwONp4DJV/095tDGUbviQLHgvHtERABVrrhMaj5OPfYRb BDQ3PDwyfDYcNo5kwSeBVMD9C94/iolzFOg+vS5+KFwJtUXeKWOyLXowq0VlRpI6AdiD ZtmBcaFmqv5FcbQR65/CIKvMIsSbBkNaSnyaDzhNjsYDRcY9ViRTpHU+XGk285UYCCeX yhCdzpQtZ2L4/lPGOFHgetZ8yqauqRK/p+mGQaZ0yuEtx3JNWt6Da61ammCo/wkivWvH nrKw==
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=d8Z7Uvq9d88JzwVvPVknHUB1Roir4zpJ6Chm+a1phTg=; b=ptbGFuF9+wmQ996BGGoHMvJL589/+4AOv7CVzLjTGkx+D7lNgjQZL3USRTE6QRASuv qfzjfp8BFpbNqXx5CdigVRPrBLI3qaL64OJJGO9cfMoVXuW4nem1dppJ23S3/Y7LSTxV cZH10+pn3qB+lCFt5ArALB8ePwx1NvVdxdza4aPpm31Ags/xxsKqRlDnXmJiXx74vpsg 9gZFcopyIzpZ3J1Rc6aKbYAmxXn23JPe12ohetd0eeNgE0/roK3OhsODWt2E5vaHzsdb zOoPAG5WjGe+5UByGptXuXRfyljTSXCnXvBIDehUPYGN7MCceqggoYKLnwg9EHSwETYs dwVg==
X-Gm-Message-State: AJaThX6LXu5aVrpZjxYxun5OuvvqQGEmaxAv66/Ma6KHvgwpQPW2xiyn kEpxT9EaeiQlkk6Xd0X5k9ZeaGBk
X-Google-Smtp-Source: AGs4zMbPi0p131bIFWvoJ0tjBzxneeTXXLFJSxSjy5ziY3VuxOBWn2loZcpu7AJWFQDrLi2vsOv08g==
X-Received: by 10.159.204.146 with SMTP id t18mr10484654plo.83.1510623188362;  Mon, 13 Nov 2017 17:33:08 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r80sm36395808pfa.169.2017.11.13.17.33.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 17:33:07 -0800 (PST)
Subject: IPv4 only apps [was: IPv6 only host NAT64 requirements?]
To: Ole Troan 
Cc: Philip Homburg , 6man WG 
References:    <909eb642-b2a0-2fb5-8f41-297e013ae307@gmail.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Tue, 14 Nov 2017 14:33:06 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 01:33:10 -0000

On 14/11/2017 13:37, Ole Troan wrote:
> Brian,
> 
>> ...
>>> But for host software there is a lot more incentive to support dual stack then
>>> to do the extra step for NAT64.
>>>
>>> The big problem I see for NAT64 is that for old IPv4-only applications you
>>> have to make two fundamental changes to the application. The first to
>>> make sure that the application handles IPv6 in every possible way. And a
>>> second pass that makes sure that every place where an IPv4 address literal
>>> is handled, works with NAT64.
>>>
>>> For an application writer it is better to try to avoid doing the second pass.
>>
>> I think there is a missing document, and it may well belong in v6ops not
>> 6man: "IPv4 Applications on an IPv6-only Host".
> 
> IPv4 applications do not run on an IPv6 only host, so that's a short document.

No, I don't think so. We haven't done a good job of advising implementers
in this area, and those apps will not go away spontaneously. Tweaking them
for the new world may be much easier than getting them rewritten, in terms
of the incentives in play.
> 
>> Your text above is probably a good summary of what the document needs
>> to cover. (I also suspect that if this document existed, we wouldn't need
>> Jordi's draft attempting to define "IPv6-only".)
> 
> Please take that to a different thread.

Done ;-)

> This thread is about a IPv6 only, single stack host connecting to an IPv6 only network.
> With a backdoor to the IPv4 Internet for legacy destinations.

And that neglects the legacy that most such hosts have inside them.
I have a bunch in the host I'm typing on right now, which is connected
via NAT64 for the week.

    Brian


From nobody Mon Nov 13 17:40:21 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E803F127275 for ; Mon, 13 Nov 2017 17:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 FQ718jekoQtv for ; Mon, 13 Nov 2017 17:40:13 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5F71205F0 for <6man@ietf.org>; Mon, 13 Nov 2017 17:40:12 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id l24so773384pfj.6 for <6man@ietf.org>; Mon, 13 Nov 2017 17:40:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZDGEFmgMwXKGk5dUgjN0Qxdo2L571Upmt44l5MsuBvc=; b=oLOmnoooykiroPuIYqckYyqvqweNDs9C/9Ljl1+7BmNdq+LYZsGVQB1qod5EEpkvnb 79gSiK3mV0qlGWjSmMYRyAcwsdPHQgRKgEyKxYK2ju+5+CYgyYt6andvpBtKFxMlDMqr XVvHvmczw/kYZnWF7GKAW1EunrXDr5jZ4f5gx7ZFB3iyRZO9Lm4T6D1ulan6rD2vIvFG ZSNdRj+2EcoHrTKaSQ9jooFpz+KOCYl6KrfQWLy+Zey7pUcFxGAbNT3eeI91pfrAN/wN DvjxenXH7580wKJK0U+Vi800Q2guO3lRZvdJimF+CyNf+/FxcGJhBoak5B9q2/chQECf BYbw==
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=ZDGEFmgMwXKGk5dUgjN0Qxdo2L571Upmt44l5MsuBvc=; b=e2VLBLwUAnn2M5RLOe584puwIqFUpnUaefgMTSPchEf0qrdVWRXWDymne5zcOohl6Z p4JGLlOG0dqsf/XKZ1Puuw5VYs+EU3noGcDNhA9bSRH44J4c3fKijBXGpqxWQksKwkqH 1p4Ympe73L62hFS2XeQ/PIGWXWJFPc7tuJvt7WeFCDOEYKZImg4oDUyAd81K8kI2saV2 rulBHoF/K20dcuo18b7s0Tkg3VmS0iQ+ztaSpRob+ZN2k7rCJdWRxG8AhBCMw+24viau 1FpvFNgR0csrFpyDoJIikmH8mdt9dzHkxEPD46Dyw9LiH36ZibHWTIqVR4gmc4QdSCoA 7uMQ==
X-Gm-Message-State: AJaThX6SN2O3BDq/yMdM4RYvtEjfL59HDannVJVC2WQivCzAbN2Gw/YV kJ1TQ1XP9jMOyPvYNQtCZ4tzCA==
X-Google-Smtp-Source: AGs4zMZFz87hGT45XlEbtu9UvbU3jj0SfigY6WvlgDoJwxkUSd5fE3pgiEcPrqqLFaYQDWpPzjIimw==
X-Received: by 10.84.254.13 with SMTP id b13mr10577422plm.363.1510623612520; Mon, 13 Nov 2017 17:40:12 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:2552:171a:b18:8a8c? ([2001:67c:1232:144:2552:171a:b18:8a8c]) by smtp.gmail.com with ESMTPSA id f11sm34814520pfd.82.2017.11.13.17.40.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 17:40:11 -0800 (PST)
From: Ted Lemon 
Message-Id: <72ECE18B-5247-4D00-AF4C-763881929DD3@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D3F1257E-F6C2-48D4-BB38-5373889095CE"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Tue, 14 Nov 2017 09:40:09 +0800
In-Reply-To: 
Cc: "v6ops@ietf.org WG" , Fernando Gont , "6man@ietf.org" <6man@ietf.org>
To: Philip Homburg 
References:  <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>      
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 01:40:16 -0000

--Apple-Mail=_D3F1257E-F6C2-48D4-BB38-5373889095CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 13, 2017, at 11:17 PM, Philip Homburg =
 wrote:
> There is an interesting dynamics in that any new feature for RA that =
is a=20
> essentially a duplicate from what already exists in DHCPv6 gets =
accepted,
> but a simple feature like a default router option in DHCPv6 gets =
rejected
> time and time again because that feature is already provided by RA.

This is actually a reflection of the consensus that Lorenzo mentioned =
earlier: that we do not recommend DHCPv6-only networks.   Also, it is =
not true that there is no pushback when new options are proposed for RA.


--Apple-Mail=_D3F1257E-F6C2-48D4-BB38-5373889095CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 13, 2017, at 11:17 PM, Philip Homburg <pch-v6ops-8@u-1.phicoh.com> wrote:
There is an interesting dynamics in that =
any new feature for RA that is a 
essentially a duplicate from what already exists =
in DHCPv6 gets accepted,
but a simple =
feature like a default router option in DHCPv6 gets rejected
time and time again because that feature is =
already provided by RA.

This is actually a reflection of the consensus that Lorenzo =
mentioned earlier: that we do not recommend DHCPv6-only networks.   =
Also, it is not true that there is no pushback when new options are =
proposed for RA.

=

--Apple-Mail=_D3F1257E-F6C2-48D4-BB38-5373889095CE--


From nobody Mon Nov 13 17:42:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2290E1205F0 for ; Mon, 13 Nov 2017 17:42:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tY8vNsI25ECG for ; Mon, 13 Nov 2017 17:42:28 -0800 (PST)
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 45C01126E3A for <6man@ietf.org>; Mon, 13 Nov 2017 17:42:28 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id r62so625762pfd.5 for <6man@ietf.org>; Mon, 13 Nov 2017 17:42:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=B7Ov732J96X0FeAYx8tyvQAk9pCyTxLt4OTz8ZAzerk=; b=0x9g3J9t7iJtRFQbpsFHIN81JMO4X3wzNF3LjkjVno36ED1A3NhMeHAHJUwoDNYops me4gYrddptwLgJebOsjXIctN9ezA4KAGPfBylr4+Sbp/wwoBqh5AbACS8ClY/EO66xjo AJ685SgclekolIPovyCtLXvuJQ3oBkoOOdSK77u8Ea2bk0VzZ7LIskToaDM4ERA1keMT SGC9rTPj901aehVjhReAm/H2sHX0BPmygwGmrHJtW69o44VBhG3gx1dr0DOrHCJ/QhAV R8l9psJAjNbae+BFefv3sQFiKfzhF2aQriW/y9w6z6QxVWN6IXljFhTgqbZ0oHnb1Sx+ Ue/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=B7Ov732J96X0FeAYx8tyvQAk9pCyTxLt4OTz8ZAzerk=; b=uJgfe5nZq9KOrTlLX7kYeD7oOVJEG6nFE9zal5kK175Dq82R8TVRe6gAkbwWIkwrx1 YjKaRdRuc4eQ629ch6Q++1nYZ1GcZMQ/OkEEzGLfpOfGRYO/D7mzKICnrvk7AJSHQACE 1wp1P8Oifqm95ESfK0i8oYsE4RJnSU/F4idgnnG9Law8mIRdfdQfFvgzupyYRb5sAmuD IE8U439dui08HjEoVCc1/aLsjZn/lw8B0qz2EmT7J8wwMMUK9kWKJcvU4lruDK8kt5EL +eVFcSbrgHA+QiwONHgm4q9MHQdRI6VJB55e+RppVh0f5vzxUq8F5kZfjUowdm2uQ0YD 6ZTg==
X-Gm-Message-State: AJaThX7KXFW7b5HyZAapRA7+Y6InipO2o88oyQmmugcgiiGtpiokDRt/ vxYeyeCSWJl+KyQ8zx+nWrp2xfUu7u0=
X-Google-Smtp-Source: AGs4zMbyIF3V+Q5aiBpQhlxcD4rZAzaQwN9P7jrcJXNT6pJ9HrA8zgfuVvU4hruxCYI92xRSYGBJfw==
X-Received: by 10.98.59.139 with SMTP id w11mr8225604pfj.188.1510623747853; Mon, 13 Nov 2017 17:42:27 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:2552:171a:b18:8a8c? ([2001:67c:1232:144:2552:171a:b18:8a8c]) by smtp.gmail.com with ESMTPSA id n129sm4619280pfn.1.2017.11.13.17.42.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 17:42:27 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_73AABDDC-AFC8-4F62-B9BF-AA90392CF5DB"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Tue, 14 Nov 2017 09:42:24 +0800
In-Reply-To: <5A09BBFE.5050407@foobar.org>
Cc: Victor Kuarsingh , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
To: Nick Hilliard 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>    <5A09BBFE.5050407@foobar.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 01:42:30 -0000

--Apple-Mail=_73AABDDC-AFC8-4F62-B9BF-AA90392CF5DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 13, 2017, at 11:36 PM, Nick Hilliard  wrote:
> The change
> in the SLAAC protocol to being stateful

Can you explicitly detail what the new state is that needs to be tracked =
for SLAAC?   I was rather short in my answer to Fernando, but as an =
implementor I do not see what additional state I now need to track in my =
SLAAC implementation, and would appreciate it if you could say what =
state that is.


--Apple-Mail=_73AABDDC-AFC8-4F62-B9BF-AA90392CF5DB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 13, 2017, at 11:36 PM, Nick Hilliard <nick@foobar.org> =
wrote:
The =
change
in the SLAAC protocol to being =
stateful

Can=
 you explicitly detail what the new state is that needs to be tracked =
for SLAAC?   I was rather short in my answer to Fernando, but as an =
implementor I do not see what additional state I now need to track in my =
SLAAC implementation, and would appreciate it if you could say what =
state that is.

=

--Apple-Mail=_73AABDDC-AFC8-4F62-B9BF-AA90392CF5DB--


From nobody Mon Nov 13 17:45:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C5D127275 for ; Mon, 13 Nov 2017 17:45:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 D_FeoEl72aOM for ; Mon, 13 Nov 2017 17:45:41 -0800 (PST)
Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e: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 504011205F0 for <6man@ietf.org>; Mon, 13 Nov 2017 17:45:41 -0800 (PST)
Received: by mail-pg0-x22c.google.com with SMTP id c123so6102075pga.11 for <6man@ietf.org>; Mon, 13 Nov 2017 17:45:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZD+VhUDOHVY4FWGAFSn3qWtZJwhPt4sihpAeefPiSag=; b=HTEm6Zjmy/QrUcApktuDgtl1NvgW0RKa2QCQxlMFgYzdZvhMIyrAmBMla/CVgq/Tob KmmAKk8T2qvPmqOswyR2w3q3a1Mb34W3XOUWMzTLR9a6N6LbdTJXrnnKbwpKR/HLPy/m 639yKEOfCIfhCuVZCUMhfSSSjU5VBXHkHKJtfBFDmH6F0RjjvaRFDYUet0Xt3It8Xb/x 5f5NVsoIyIFI+xd9pU2Rn57cw5b8LYTiCCKCDVG56zPm5EP08abBOiZu7PI3wKn+vVle GmRyD98mURTiL1NVC2MV47X2SXgNtv8CdYZkkq0wmU5sYJ7bOY6LcqQAvq0kOayi/Cee vGhg==
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=ZD+VhUDOHVY4FWGAFSn3qWtZJwhPt4sihpAeefPiSag=; b=UCtoGbfuTSu6qrHZXrftmQ0PUwh1cUo+/pMMA250tPywv2Wu9HDMDsiIas5JPJjByd /6Eh3eC3QbTfLfdChTa+oAVBotSF2QV9CoXujxymz0TaRX1bgQ+K6V8JszUy2P95oHEk LhWdSN/8sJO55vcpnfRiGxJ+RkP+zzWosv7BqDOXqvdXr3RW3reaAWzHKUCitJgjLhsD tJLg1DNkUG55Pap3tfCHw2yr8AXWGsrS11Dv/LYOmX2w0/lMMw/ZDn+MxsY3jnxX6viw pCc7qpMU5U5k6ttXYj7GoPiBDy3wpYq1vK5kDeTCS1chEnSihr/P8hqnEpdkVGjDPsSO yNqQ==
X-Gm-Message-State: AJaThX7/LA9SLsuxeSKa23IjvvZksZAg3EDiIysXfkxI5bJJIA3jwohY VKd7fJPLNM9YCDgk0xJMaABx8Q==
X-Google-Smtp-Source: AGs4zMaMG39vI83umZ62kTLlX/AvMgoHOSzgnUfGgY7eT64oCXxVUrwz/HUiWIzunJU5r1GmjLuskQ==
X-Received: by 10.84.165.171 with SMTP id y40mr11068696pla.362.1510623940926;  Mon, 13 Nov 2017 17:45:40 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:2552:171a:b18:8a8c? ([2001:67c:1232:144:2552:171a:b18:8a8c]) by smtp.gmail.com with ESMTPSA id z16sm1867969pge.62.2017.11.13.17.45.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 17:45:40 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_7CFF9108-9028-492F-9880-75FC2F557CF7"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Tue, 14 Nov 2017 09:45:37 +0800
In-Reply-To: 
Cc: Lorenzo Colitti , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: Mark Smith 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>    
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 01:45:43 -0000

--Apple-Mail=_7CFF9108-9028-492F-9880-75FC2F557CF7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 14, 2017, at 3:43 AM, Mark Smith  wrote:
>> Why are we holding this document up on this?
> Half baked cakes aren't cakes, even though they may look like them.

FWIW, "we" aren't holding up this document.   It's in AUTH48.   The =
working group already has consensus on the document, the IESG has =
approved it, and at this point the only changes allowed are editorial =
changes that do not substantively change what the document says.   The =
working group has no agency here: this is entirely up to the authors and =
the AD.

If the authors or the AD were to make substantive changes to the =
document, that would be grounds for an appeal by the working group.


--Apple-Mail=_7CFF9108-9028-492F-9880-75FC2F557CF7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 14, 2017, at 3:43 AM, Mark Smith <markzzzsmith@gmail.com> wrote:
Why are we holding this =
document up on this?
Half baked cakes aren't cakes, even =
though they may look like them.

FWIW, "we" aren't holding up this document.   It's in =
AUTH48.   The working group already has consensus on the document, =
the IESG has approved it, and at this point the only changes allowed are =
editorial changes that do not substantively change what the document =
says.   The working group has no agency here: this is entirely up =
to the authors and the AD.

If the authors or the AD were to make substantive changes to =
the document, that would be grounds for an appeal by the working =
group.

=

--Apple-Mail=_7CFF9108-9028-492F-9880-75FC2F557CF7--


From nobody Mon Nov 13 17:48:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CF7129463 for ; Mon, 13 Nov 2017 17:48:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xBOoZ37YG49Y for ; Mon, 13 Nov 2017 17:48:03 -0800 (PST)
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 1D8E5129584 for <6man@ietf.org>; Mon, 13 Nov 2017 17:47:33 -0800 (PST)
Received: by mail-pf0-x236.google.com with SMTP id l24so786371pfj.6 for <6man@ietf.org>; Mon, 13 Nov 2017 17:47:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BbFoWG86AATX13d2OnnbmqxFJJZBgETPsrR/FyqFSHM=; b=TNtcImUF2FJcu9ZoW4KxQngutoqLsxxu6HwDuGNR0nkj4aSN1HPDb2p+tC73sueS2l nVHOB0OPtvEp5TsQhxUFiEVYiVe9ummcIb1Xouqa0BwXoSTyVra+fbsDJEnsB/6Akdsw uTVxRiHUvTOmXMvdTcMgOD+8Xs7Up8tEHcYtQjss/or/aL502msxXhl2l8vsMuFA2Xza v7S3UZ0+jMMcJrBw62s0f1cIVQ6SpZbAWdVElbwWsp+0jIvC7njt2FZJEXmWj0+8z2R/ 1iiNvOBzCQ+y3sTH579jaWLw23WPMZn6ZVXvLLrH62XIA8PI7tqAXCOfYWfMffAyavoc fa3Q==
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=BbFoWG86AATX13d2OnnbmqxFJJZBgETPsrR/FyqFSHM=; b=KfbnR8pgwhq4KtNCpliDWgHVFaGd3eUP/C5xwyKcL+B0WbZ8FIprwIkb2gFE6+Nz6d p0yAWY0wvXQKc8S9l7WHtBRblLtf5ccS5L4CP+zNnVcbf9LpIdHNP5syPDO2K9C9Xzte 39ZvkETBZpzhskwAJMfEWtV0c50EBGDKaWxrSLFylOBvAkiauxPCuk8j0Y9h2O04owWd x3UNN9Apmnph1JaagxEV8zg3WobxnQCkCVF9lqWfVavoXe4oqJF2PT+GUkz0XS4CV5oD WcOSTUo7s5Njns3v8zDN2RTE7zfomQPEDctp72S128TH9e0hF2N6peuTLFwWxl3Oa0rn OI8A==
X-Gm-Message-State: AJaThX4llrnff3VZAbBB0n+wdpuzpdRDqu3p7B++8YtKxh4uNgxYPGpo DrBg1eMx1lsEbFT2m+qVJqTsbg==
X-Google-Smtp-Source: AGs4zMa/dr4VLS9nv4s3MwSq9gFRO4Ci7OomNlRPXOvxudRH67Si3ss5enKWjsQhNs64wWA0sNXO3g==
X-Received: by 10.101.86.76 with SMTP id m12mr3518353pgs.143.1510624052708; Mon, 13 Nov 2017 17:47:32 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:2552:171a:b18:8a8c? ([2001:67c:1232:144:2552:171a:b18:8a8c]) by smtp.gmail.com with ESMTPSA id j1sm35622691pfj.108.2017.11.13.17.47.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 17:47:32 -0800 (PST)
From: Ted Lemon 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_46EC187B-C1F8-4F4D-986C-73D89F76FED9"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Tue, 14 Nov 2017 09:47:29 +0800
In-Reply-To: 
Cc: Nick Hilliard , Lorenzo Colitti , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
To: Fred Baker 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <5A0999A4.3040807@foobar.org> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 01:48:04 -0000

--Apple-Mail=_46EC187B-C1F8-4F4D-986C-73D89F76FED9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 14, 2017, at 8:43 AM, Fred Baker  =
wrote:
> I can also report that I have worked in an environment that only uses =
DHCPv6, and it worked just fine for any purpose I put it to.

How do you get your route?


--Apple-Mail=_46EC187B-C1F8-4F4D-986C-73D89F76FED9
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

On Nov 14, 2017, at 8:43 AM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
I can also report that I have worked in an environment that only uses DHCPv6, and it worked just fine for any purpose I put it to.

How do you get your route?


--Apple-Mail=_46EC187B-C1F8-4F4D-986C-73D89F76FED9--


From nobody Mon Nov 13 17:49:37 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5604129576 for ; Mon, 13 Nov 2017 17:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vepk5S__RWgr for ; Mon, 13 Nov 2017 17:49:28 -0800 (PST)
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 2E1CF127275 for <6man@ietf.org>; Mon, 13 Nov 2017 17:49:28 -0800 (PST)
Received: by mail-io0-x22e.google.com with SMTP id 134so22775743ioo.0 for <6man@ietf.org>; Mon, 13 Nov 2017 17:49:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=b0KMplj64MK/WNYFc9gkezl5Xoj3h9sQzYxRNnbzhYw=; b=OrVpz+zMr49vP37JBYljx4fg2im5pFBTyrtetBIXwpJgCZOmk0905G1lJic5VgnNlb 72BxSgyGViEaSxN7eh8jsimfNnXvfR4y0cQZ4RSwyAppxTJX16lV0bKnbg9V6+r7GzRQ +hefxz8dr8GZugUvFAWSUhApnz7tfpMHg2yGOfyEormDJHK6POUlSyTHa6J/VN89I5vJ A7VlOE/hvCyTHdpNYIdh5ZHl78V0+gehSl9Tat1OljLEjICRMAwFTQjg+X05xFKBT2Ra xhNtCrq+dJmo9X0sc1AlmfZfdu8hV0mCdwrKLNow+wqiBepflMr8m9wvFDvo5d18xwqT XJVw==
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=b0KMplj64MK/WNYFc9gkezl5Xoj3h9sQzYxRNnbzhYw=; b=IyjWkPOv0tTVRwiyCKLnIH3UfbkUH13lzL492+QuyNZeuKt/dQsT/hz3Yxm6ayYG0W XV/Dc7y4muxO/6DGIoPQrMyB6bFjjFQT3S+yDJhI9iYi9IoowujCJye/7eVM2IoBzO7G IiKxFUHfdtkolhl9P+HnYFt6wFYEVCtd3Ls0TuHXpxduG90japERG46QdsCO2oxahqlG uK5TK+eqodWmWnwU20Ng3W+Gripo3M9T54Vw5Q9hVtE9+2DIWWuywmhlla0gXH7GaUSM Rpps8ysz/zMX8DxNwXhlxZ4tVjZzuZIp8+qxNorWSIgspiQa9QNjTh2nuTl4kBZB3ipL kqAQ==
X-Gm-Message-State: AJaThX5SCC1hj+lDNeMbMkAeeJ/okdqZB8yFhUn+hLtQ6YlgBKeh3crC OQRVmnswi8+5BWkntukijw3p3g==
X-Google-Smtp-Source: AGs4zMY2xyL/6YLWVuGVohI1fCBWtzjHFtH+gEHwRhlhfCb3vNPCBkwEOusZ2y668kiPrL4kkCnJVw==
X-Received: by 10.107.200.207 with SMTP id y198mr13259073iof.157.1510624166922;  Mon, 13 Nov 2017 17:49:26 -0800 (PST)
Received: from dhcp-100-99-229-233.pao.corp.google.com ([100.99.229.233]) by smtp.gmail.com with ESMTPSA id d1sm3255050ioc.61.2017.11.13.17.49.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 17:49:26 -0800 (PST)
From: james woodyatt 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_9D111570-4A7A-4A7C-A60F-63B668F712DD"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Date: Mon, 13 Nov 2017 17:49:24 -0800
In-Reply-To: <72ECE18B-5247-4D00-AF4C-763881929DD3@fugue.com>
Cc: Philip Homburg , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
To: Ted Lemon 
References:  <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>       <72ECE18B-5247-4D00-AF4C-763881929DD3@fugue.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 01:49:31 -0000

--Apple-Mail=_9D111570-4A7A-4A7C-A60F-63B668F712DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 13, 2017, at 17:40, Ted Lemon  wrote:
>=20
> Also, it is not true that there is no pushback when new options are =
proposed for RA.


I have a pile of rejections, none of which were duplicates of DHCPv6. =
One of them was eventually obsoleted by PCP. Another probably gets =
replaced by a mess of security vulnerabilities (but at least ND6 will =
remain pure!).


--james woodyatt >




--Apple-Mail=_9D111570-4A7A-4A7C-A60F-63B668F712DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 13, 2017, at 17:40, Ted Lemon <mellon@fugue.com> =
wrote:

Also, it is not true that there =
is no pushback when new options are proposed for =
RA.

I have a pile of rejections, none of =
which were duplicates of DHCPv6. One of them was eventually obsoleted by =
PCP. Another probably gets replaced by a mess of security =
vulnerabilities (but at least ND6 will remain pure!).




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_9D111570-4A7A-4A7C-A60F-63B668F712DD--


From nobody Mon Nov 13 17:57:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23A71294FA for ; Mon, 13 Nov 2017 17:57:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBnPpGdREKbN for ; Mon, 13 Nov 2017 17:57:33 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F78D12954B for ; Mon, 13 Nov 2017 17:57:33 -0800 (PST)
Received: from h.hanazo.no (nat64-7b.meeting.ietf.org [31.130.238.123]) (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 B82982D4F99; Tue, 14 Nov 2017 01:57:32 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 20EDB200C0BE6F; Tue, 14 Nov 2017 09:57:09 +0800 (+08)
From: Ole Troan 
Message-Id: <50F8194E-E887-4940-8ED0-CA4FD9600093@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_96C52B77-BDEC-4C0F-9477-2F46569C39EB"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv4 only apps [was: IPv6 only host NAT64 requirements?]
Date: Tue, 14 Nov 2017 09:57:08 +0800
In-Reply-To: 
Cc: Philip Homburg , 6man WG 
To: Brian E Carpenter 
References:    <909eb642-b2a0-2fb5-8f41-297e013ae307@gmail.com>  
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 01:57:35 -0000

--Apple-Mail=_96C52B77-BDEC-4C0F-9477-2F46569C39EB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Brian,

[...]

>> This thread is about a IPv6 only, single stack host connecting to an =
IPv6 only network.
>> With a backdoor to the IPv4 Internet for legacy destinations.
>=20
> And that neglects the legacy that most such hosts have inside them.
> I have a bunch in the host I'm typing on right now, which is connected
> via NAT64 for the week.

I don't understand what you mean with the above.
I guess this is where we have to be extremely careful with terminology =
use.

If you are using the IPv6 only + NAT64 network you can't possibly use =
the legacy IPv4 only stuff in your laptop...?

Cheers,
Ole


--Apple-Mail=_96C52B77-BDEC-4C0F-9477-2F46569C39EB
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+/bDNdvtpYqJhC33YFAloKTXQACgkQvtpYqJhC
33Z6vBAAi5gcdq8TKoXmt3TYakkjhXWWt7SUiEbV9DslUx4uoiBXkihd76usVckV
VPIj8scZjw76QUaYXLdYeOzOCKZ8rWblr2HgMOcaRfLr1i6WNUwCQ6J4DhjMKhhB
P6OB8tQItXWZGqrybbjaU1UDX7FnsC+zNPU7nQ5a96vqhn3ZVf1Yllk/nqlIiY4Y
j/53443Olj2xua5S+9k6Ruh6Asxm0KuXUK6CuBOfR2ems8RkLurSLrBiWe2qjXWc
NmxVDgqyEslouYOn0N07DucEuvqAOnH5Sit3iDsodP8y/L3E68SmbszhHxdbTdSf
nzVoHv5PqKDk8eNtJ1UOGZ5wk7DWgixkWUgs7+RSgT0M0jG88Hygvs7JjW9SHP9g
8cfR1smLB/HVo3qIigF1BkTnQfhUvlZ9FVdgM9Ijg1LuHBYbZcg9AiLCuO3YksUU
PoY2A1V12qEARlmvH99bxkFXNuR0rZH6j9JvzYm4W4nj+Bzw06f+1XkGiRCHWeT/
Xjgq/toBlG0/QOXvh9QsfJ3FRLHvTZIaoWAvFAf1Llq1PqgP8f0moH4cNhiSi+K0
eesoId4Vvcf3pjvZoJ6JJx+88XUcvDfyxT62+p6w2dUPtYI/pECZfcUNUaMRYdnC
+zGJ4dAnz4Gjvl/Y480CcOoLoPp0RZqPscPCTVJAQrQYu0NYKFw=
=MleN
-----END PGP SIGNATURE-----

--Apple-Mail=_96C52B77-BDEC-4C0F-9477-2F46569C39EB--


From nobody Mon Nov 13 17:57:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3731200C5; Mon, 13 Nov 2017 17:57:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJdEvGkmNqGw; Mon, 13 Nov 2017 17:57:47 -0800 (PST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50110.outbound.protection.outlook.com [40.107.5.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09588129AD0; Mon, 13 Nov 2017 17:57:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Cr6OttgCRzmZGwfD3aL/H2Lzt89Ewg09zw3catmE1W0=; b=jmsBEjFlqrMhI6EjLDnb0BCgQeuansOYa39YjscWD2GVgWLbKRIDrmIBhdDpsO49KJ3dyTHnJglI9v5pf2bL2RvsfhAKMVU9ma1ZhGq3TZMdJdQR9jvrpdHU4C6e0jBF2SERtsmU7ape4EqLgVqgvxRV8lXZMyZb7qorGKsKBPo=
Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB2835.eurprd07.prod.outlook.com (10.168.155.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Tue, 14 Nov 2017 01:57:43 +0000
Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::7007:b8e:3320:94c1]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::7007:b8e:3320:94c1%14]) with mapi id 15.20.0239.005; Tue, 14 Nov 2017 01:57:43 +0000
From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: Ted Lemon , Mark Smith 
CC: Lorenzo Colitti , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
Subject: RE: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Topic: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
Thread-Index: AQHTV0Ps944vy/6Q4EOhEJVwr1mwgaMLXqEAgAD43YCAAB+YAIAAc32AgAEvwICAAB0aAIAAJZ+AgAM+noCAAAPZgIAABCsAgAAGQgCAAABiwIAAT9GAgAACTgCAAMRHAIAAZUmAgAABsTA=
Date: Tue, 14 Nov 2017 01:57:43 +0000
Message-ID: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:67c:370:128:a8ea:45e6:3e08:1dbe]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2835; 6:XY/SZb69eXQ2slpiOGlGElgvHnhBA9u/acaBNBttJ+bRgpeMJq9el37azZxCSQdphHPcjMbbznRVG4mEPClP77ZiS6We690fb0kFabeAWilHqXp7j8FhLLv+kwvI1OwQGdKvpF0W2KF6OvjA7TM1rHr/cLLO5qEnv1x8ihlx4FVTVcgnw9jQ42zO0nCuT/utuJlev1NNMwqgM/9cCSSOmnN6LgkAIpnyi8GJG2/ZJ+tYOIaUhdXJN0Uw+E894aCKvJ/WF9JmxSW2QtYtqeHelU5kCrliU43tBJrOgL9u387I/karvpMbIKzitYDCPStn6D3expjGqLilb5KBcSUYMMS1R+F/bB8/skzNlQTeRDA=; 5:6y1KRZCzxdZZlWPo5DaYF3b8XfIX80XzKlJt9z+EZror2HUGPZg8cVYhunv9DWkcsSj48afbH2e0FecUnIudLNoBXY8OHSd2cCyemK3sJUCKx1gXRc7wYoZuqzll+XTRgYLdu/+T9sPJCqw4nWQBAffqmJdHuaY9GRy8RStuzns=; 24:vXRXdEEQwQqIli48sq+JdpnhHM+SRkTDv8/Tz0xgB1+Nna1H+3usRyTOKHtIaGPJAlrjRB+dkZixzQ9ToVTBpjjKcDYzP6r4BN5+S3caMok=; 7:KbsKCpBmlfycJ6ZYasis72toqcfk0IWMgcWx4YPxfGXtmXt35ZYzc2PgsYXvkvGP5W1DalK2cIuk9Wt8UnJTYlAjd6liWuEiEWyD0od+WQv6F9xjKkXG4dT5vCPwe8pl5V94KZtKbSVtezS2dwS62N5p6aTs1x1+E14Ndm/53AIUi1rC9feFYARRLNzi9p7tSMLEmCLv03yE6n511iHTc5+p+YaXDxN2d/xL+Yk66kja89LWr/KrUsrgcPfMK7I2
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 294a5a6f-096a-4eef-8113-08d52b031882
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:AM5PR0701MB2835; 
x-ms-traffictypediagnostic: AM5PR0701MB2835:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(82608151540597)(211936372134217)(100405760836317)(153496737603132)(21748063052155)(227612066756510);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(3231022)(920507027)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2835; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2835; 
x-forefront-prvs: 04916EA04C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(189002)(199003)(24454002)(102836003)(5660300001)(19609705001)(6116002)(790700001)(81156014)(81166006)(3660700001)(3280700002)(2906002)(8676002)(105586002)(106356001)(86362001)(230783001)(6506006)(6436002)(478600001)(2950100002)(4326008)(7696004)(2900100001)(229853002)(25786009)(5250100002)(7736002)(76176999)(99286004)(50986999)(316002)(53546010)(34040400001)(110136005)(74316002)(93886005)(101416001)(189998001)(8936002)(14454004)(68736007)(33656002)(54906003)(6306002)(6246003)(97736004)(54896002)(54356999)(53936002)(236005)(55016002)(39060400002)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2835; H:AM5PR0701MB2836.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2836DB6E4A3E3F8FC6CA5FE0E0280AM5PR0701MB2836_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 294a5a6f-096a-4eef-8113-08d52b031882
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 01:57:43.7957 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2835
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 01:57:49 -0000

--_000_AM5PR0701MB2836DB6E4A3E3F8FC6CA5FE0E0280AM5PR0701MB2836_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This may be a good moment to halt this discussion.
The original reported finding that this draft makes protocol changes "makin=
g SLAAC statefull" has been found invalid.
This means that there is no procedural issue caused by this draft.

AUTH48 process can now go forward as planned.

G/


From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Tuesday, November 14, 2017 09:46
To: Mark Smith 
Cc: Lorenzo Colitti ; Fernando Gont ; v6ops@ietf.org WG ; 6man@ietf.org; Van De Velde, Gunt=
er (Nokia - BE/Antwerp) 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-pe=
r-host)

On Nov 14, 2017, at 3:43 AM, Mark Smith > wrote:
Why are we holding this document up on this?
Half baked cakes aren't cakes, even though they may look like them.

FWIW, "we" aren't holding up this document.   It's in AUTH48.   The working=
 group already has consensus on the document, the IESG has approved it, and=
 at this point the only changes allowed are editorial changes that do not s=
ubstantively change what the document says.   The working group has no agen=
cy here: this is entirely up to the authors and the AD.

If the authors or the AD were to make substantive changes to the document, =
that would be grounds for an appeal by the working group.


--_000_AM5PR0701MB2836DB6E4A3E3F8FC6CA5FE0E0280AM5PR0701MB2836_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











This may be a good moment to halt this discussion.


The original reported finding that this draft makes =
protocol changes “making SLAAC statefull” has been found invali=
d.



This means that there is no procedural issue caused =
by this draft.


 


AUTH48 process can now go forward as planned.


 


G/


 


 






From: Ted Lemon [mailto:mellon@fugue.com] 
Sent: Tuesday, November 14, 2017 09:46

To: Mark Smith <markzzzsmith@gmail.com>

Cc: Lorenzo Colitti <lorenzo@google.com>; Fernando Gont <fg=
ont@si6networks.com>; v6ops@ietf.org WG <v6ops@ietf.org>; 6man@iet=
f.org; Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@no=
kia.com>

Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-pr=
efix-per-host)






 


On Nov 14, 2017, at 3:43 AM, Mark Smith <markzzzsmith@gmail.com> wrote:












Why are we holding this document up on this?<=
/o:p>




Half baked cakes aren't cakes, even though they ma=
y look like them.










 




FWIW, "we" aren't holding up this document=
.   It's in AUTH48.   The working group already has consensus on =
the document, the IESG has approved it, and at this point the only changes =
allowed are editorial changes that do not substantively
 change what the document says.   The working group has no agency here=
: this is entirely up to the authors and the AD.






 






If the authors or the AD were to make substantive ch=
anges to the document, that would be grounds for an appeal by the working g=
roup.






 








--_000_AM5PR0701MB2836DB6E4A3E3F8FC6CA5FE0E0280AM5PR0701MB2836_--


From nobody Mon Nov 13 18:01:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D3B1270A3 for ; Mon, 13 Nov 2017 18:01:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NRsQDOWLZqr for ; Mon, 13 Nov 2017 18:01:06 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDA81200C5 for ; Mon, 13 Nov 2017 18:01:05 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id l24so810570pfj.6 for ; Mon, 13 Nov 2017 18:01:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9jpJrbOPdmMT8+cwALiptzfjx+ClnX/nfvEClZEG7Dk=; b=ZIxYHBrcG93s0Ep/bPoNidXv71abSK11GiM9RXiSWpGYDvT8B8FwH1clv+h/vvhkV4 Tx9NXbyLUffgQqXEJsBDDBcr1GCe2CUwRM8Tji0LsnLKpqraUckLWbpOI2HFL56N37+n 5lB/uQW/+8Xle5TsXFSXm78qZ8u1ZB6YzJAKrO9fMJLNkKq1XALaSZDZIlj8MD7ZUnCy Zj3F4lNZ29EW9l2szazU3EMs2tBYWjOprCz0O/cw3Rrsx+uV/5mxlt8/9pal7TAV8/00 2XtfX+pAv7grjqEfk153/dbbvuczcEuTa90KQYQpw3RvQQu6CcfhpZAjZK0qxK60Awiv gvmg==
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=9jpJrbOPdmMT8+cwALiptzfjx+ClnX/nfvEClZEG7Dk=; b=bQaEWq9NqzZaGBwTh0dZ8eAnCiZzp6iltekWt0vSKapBwcxPz3jpBHlKf6wneytuEh 909MZsOIVJ4kf9A0S7Hw2U3NTx9674KQNvdQB0iPlrA8xib6hauOaePgq8qSQEn/5tsy X8qHRjABSPF1HSNb20/XrrS26kD6oYSYUO/lhQfGbAfkAxgUNt9Ms+b/P4ddFFh+9vbj GK8oXaeLk3UOCuD/tfADOPrY6wD/tpN8oZsNXJaaDJ7pd5ERus1pINwNph22ZkP7I8zs cd5tWXWIQqmVA+is6KNAAHZv55IZb5GJ0E4R9+qdg1CAWhiU6c9czOQI7/8O8gRHLBKC VCGw==
X-Gm-Message-State: AJaThX7sbx6xXcU+WMRHPlB8G6M9wS2vxF2YBCOQfJ6Vaf+giIit36An WFq5gcB6NeIhr3PriIX+TuG24BbE
X-Google-Smtp-Source: AGs4zMZhCDHkYTNnqaBz8Ue8u/j2wYRNdN0NE/r5h6/eUbcqauzuxQNnRGfeZeM+AhSaaPrcSQgBew==
X-Received: by 10.84.254.78 with SMTP id a14mr10600509pln.353.1510624864947; Mon, 13 Nov 2017 18:01:04 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v9sm24254386pfg.85.2017.11.13.18.01.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 18:01:04 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: Philip Homburg , 6man WG 
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>    <9620CE6D-6364-41E9-A43D-AF0690D2A5F4@employees.org> <1bcc9417-6f00-48ac-b9ef-0317f6f43a56@gmail.com> <39CD5C15-5A9E-4CD5-BE89-890EAF516E22@employees.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Tue, 14 Nov 2017 15:01:02 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <39CD5C15-5A9E-4CD5-BE89-890EAF516E22@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 02:01:11 -0000

On 14/11/2017 14:03, Ole Troan wrote:
> Brian,
> 
>>>>>> I am not optimistic on the demand / need / value of dnssec in any scenario
>>>>>> ....let alone an ipv6-only host validating an ipv4-only dns name. If the
>>>>>> folks operating this service cared, they could operate the server with
>>>>>> signed v6 names.  It is more reasonable in todays internet to asked the
>>>>>> server (lets assume most signed name scenarios are servers) to be setup
>>>>>> right (with v6). There is not a compelling reason why having v6 is
>>>>>> unattainable today for named nodes.
>>>>>
>>>>> DNSSEC is something that works today.
>>>>
>>>> This is not the impression I get from attending IEPG meetings
>>>> and chatting in the corridors at the IETF. Also, we knew throughout
>>>> the development of NAT64/DNS64 that DNSSEC was a major stumbling block.
>>>> I don't think it is a good idea to entangle RFC6434bis with that issue.
>>>
>>> What's the DNSSEC major stumbling block?
>>
>> I pass. Try asking Geogg Huston, for example.
> 
> As far as I understand it, DNSSEC has deployment issues, which are comparable for the DNS64 and non-DNS64 case.
> 
> https://tools.ietf.org/html/rfc6147#section-3
> https://tools.ietf.org/html/rfc7050#section-3

My understanding during the BEHAVE discussions was that
the gymnastics required in the resolver code in a host
were considerably more complex in the NAT64/DNS64 case than
in any other.
 
> But I will leave someone who knows DNS to give a definite answer to that.

Yes, that would be very helpful.

> If I understand what people are telling me correctly, your statement "major stumbling block" is not correct.

It would be nice if you are correct.

    Brian


From nobody Mon Nov 13 18:08:56 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C347129B02; Mon, 13 Nov 2017 18:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p96cA0QhSKb; Mon, 13 Nov 2017 18:08:46 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667B31200C5; Mon, 13 Nov 2017 18:08:46 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id j28so10928575pfk.8; Mon, 13 Nov 2017 18:08:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zIQCHJe1VtWPVIEIO36LPiHXdos9Xi+CBfQDyveLcio=; b=j/nIcsb0l+wcNe/xlQhpWdWfObPqFG2UUnEEWCOrh5HSkHpJcIcHhC6+Jwo6+VWyy6 AHvoxD/f8V2/zTbIcJ8aOnzMkpBAdLJDpeLAneu8ruUm7x4EkW1JWoDe2A04/a0Ek+gY CKihaMFK/S67A6O2LTcIcZK8z2cOmfLgXi9Mp6NWji6F1YlLh+WU2PddvZ6aACWJzuir jDZLSMddN9rBTUFjgI5iLaJ3DTph8qD1kZYGj1PBWh2Yj9ucLuiv0/MeKZ2kNioK4rVs VSRUKmEOMcWd+9PCwpcSPd9WsR1uf+2hnY3lLQNFbT768C4e1YSFygtkwK+2WQdM7sMW wTNg==
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=zIQCHJe1VtWPVIEIO36LPiHXdos9Xi+CBfQDyveLcio=; b=onA9oENec62jHBfGVm18m95gFHZO9VRAzov3iI7o+6SgboDe/w8/GKmyuarHmHkCaR T7tW48q2Wf7cakcDL8k7/6x0uSKyfwp0RTLk9coiAMJp4IjRJXVj07w4sP3NhRbIlY25 WcYjFqgNfwAhofWOzgiD/l67geF2/ls6mU+gHpSXxxFDAW+tNhgK+AV0lW2kjvmmsDaq gv0FHmDGflfeDvceFLuxGTywFwx3ltn5p/78nK5U4qPmDHnn56RE8s6sgyiKOCQo0J/G 1icjDMNH9Vogphh7ET16Nc7YzDfB5EEX2K+MrP3FRLwF30+776by7qvY5eewy8wjPENR 8CSQ==
X-Gm-Message-State: AJaThX5rhcmYSwgRsNjyb6UrPGRCecjIWj263aeVV+k2Jqflzk0YfIcI vPF/fiwHccz/iUTsIBRcwV2vPihEuIU=
X-Google-Smtp-Source: AGs4zMaZI25TLc8ifRj7yg5l6xpnBeBm9sytfWsyVzLO9v9Y8AUJPqe5AO3vhsuecBwRdopRhpUDNQ==
X-Received: by 10.101.82.130 with SMTP id y2mr10491442pgp.65.1510625325774; Mon, 13 Nov 2017 18:08:45 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:e88d:8fb9:5eb5:14b0? ([2001:67c:370:1998:e88d:8fb9:5eb5:14b0]) by smtp.gmail.com with ESMTPSA id q13sm28559304pgt.73.2017.11.13.18.08.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 18:08:45 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: Suresh Krishnan 
In-Reply-To: 
Date: Tue, 14 Nov 2017 10:08:46 +0800
Cc: v6ops@ietf.org, Fernando Gont , "6man@ietf.org" <6man@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AD0314B-4E8B-489E-880A-3E9C7210F6AF@gmail.com>
References:  <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>      
To: Philip Homburg 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 02:08:47 -0000

Hi Philip,

> On Nov 13, 2017, at 11:17 PM, Philip Homburg =
 wrote:
>=20
>> I don't see how this work has any impact on what was done in DHC and
>> disregards it.  We potentially conflating things here?
>>=20
>> Much in the same way RFC8106 (DNS info in RAs) does not disregard
>> DHCPv6 since it too can offer DNS information.
>=20
> There is an interesting dynamics in that any new feature for RA that =
is a=20
> essentially a duplicate from what already exists in DHCPv6 gets =
accepted,
> but a simple feature like a default router option in DHCPv6 gets =
rejected
> time and time again because that feature is already provided by RA.

This is certainly not the case. Other than the DNS option in RA (which =
enables hosts to get minimal internet connectivity) there has been a =
conscious effort to avoid overlap between DHCPv6 and RA based =
configuration. Lot of the thinking as to why this has been done is =
documented in RFC5505 (Section 2.3).

Thanks
Suresh


From nobody Mon Nov 13 18:11:59 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B85A129ADF for ; Mon, 13 Nov 2017 18:11:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ie2wyB9vHKLy for ; Mon, 13 Nov 2017 18:11:55 -0800 (PST)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A70E0129AEA for ; Mon, 13 Nov 2017 18:11:55 -0800 (PST)
Received: by mail-pg0-x22e.google.com with SMTP id z184so8775835pgd.13 for ; Mon, 13 Nov 2017 18:11:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=GHJMR1hVKXnqFXrO05eYXVIBkdKJYyNKOPwXg59DLlM=; b=CSgOTi98ywShpcUWY5a1wtvUrXldpBSwJjRKEhpRefmsRMbM5ILhkm4zDwLat+Ue3d x5J8ru2CoIX0L53xKUFoEckxXBOzzP3BIXULzeYbQycGZ47ISJUDClh9MtFHltWFponA LlERFqjjjhgl5y6j6TMn8qZJGkFBloi2yZt32LklsCVAsJWZAHb8XOo3qG9/4SGbeFSW +jvdEdNgr/EbjICUGX9CyNny6FqraTF4fix6QbMCYfQL0DUH4kkYSA134RN/MX2TxOJU KI1DTVAj7phu6Fp2xDcr9C6ZMtcH4TBZZvvwLiuKV1185Uihpi5r2awrn420FWSC4QNS 5Dww==
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=GHJMR1hVKXnqFXrO05eYXVIBkdKJYyNKOPwXg59DLlM=; b=axqL5SdLMtt/tso7uQE9ODWDxyjRw9rz3GGWgoRnuWY56TsUz/PY/4luPk30gac4Zc 6d6aoOO6+UHZrC/CeBI1VKVv3PYXhZWNRpgPMZ1k/WMHWfe9U0IWhCN0EOPzlOXtWQYP vGIrPwOZ7DNp4r+Nm/TR7xS4NKuKdLrcCFU91DKFb3HnDJwv9+jxVveKMfLyGZjX0gIW 2rCDKhzpPort0bsBe/7tfJ+cn8Dhh4aul6sYJiqrhy9R2Fbl/DXl5xIjMLA0BFrbnIYH z8eYaVgo6XKTBDlTI0hE9PUV3PkyJ7sf1gyNI7tBK3m7Wstf0Dj+dy/51I7kCCuAIAA5 OQEg==
X-Gm-Message-State: AJaThX7RTNgyyn3T8bMEac6T2zm/ETThRz56o+4eCWwXPhqYYPwWMY+T AYiJAGIOMnKQtzqn9yncnA+8RMav
X-Google-Smtp-Source: AGs4zMbnTW4qEtRT5AtSGXzQU4cb/Mrkk1bpJejTBuwL636cMoprIwQuWNhr07pdspsJT44kO3fANw==
X-Received: by 10.99.186.70 with SMTP id l6mr10385007pgu.253.1510625514865; Mon, 13 Nov 2017 18:11:54 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id i186sm37292971pfg.75.2017.11.13.18.11.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 18:11:54 -0800 (PST)
Subject: Re: IPv4 only apps [was: IPv6 only host NAT64 requirements?]
To: Ole Troan 
Cc: Philip Homburg , 6man WG 
References:    <909eb642-b2a0-2fb5-8f41-297e013ae307@gmail.com>   <50F8194E-E887-4940-8ED0-CA4FD9600093@employees.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <79fa6f37-efdf-4ba1-49bc-a8da1d33fd43@gmail.com>
Date: Tue, 14 Nov 2017 15:11:52 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <50F8194E-E887-4940-8ED0-CA4FD9600093@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 02:11:57 -0000

On 14/11/2017 14:57, Ole Troan wrote:
> Brian,
> 
> [...]
> 
>>> This thread is about a IPv6 only, single stack host connecting to an IPv6 only network.
>>> With a backdoor to the IPv4 Internet for legacy destinations.
>>
>> And that neglects the legacy that most such hosts have inside them.
>> I have a bunch in the host I'm typing on right now, which is connected
>> via NAT64 for the week.
> 
> I don't understand what you mean with the above.
> I guess this is where we have to be extremely careful with terminology use.
> 
> If you are using the IPv6 only + NAT64 network you can't possibly use the legacy IPv4 only stuff in your laptop...?

Indeed. Because my laptop isn't providing a NAT46 bump in the stack, for example.

I haven't analysed this at all. What I'm saying is that we haven't done this;
we've simply sneered at application developers who haven't added IPPROTO_IPV6
to all their network code. Sneering doesn't solve much.

    Brian
> 
> Cheers,
> Ole
> 


From nobody Mon Nov 13 18:17:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13B4129B02 for ; Mon, 13 Nov 2017 18:17:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZaHCg7ofyaQ for ; Mon, 13 Nov 2017 18:17:42 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690D612954B for ; Mon, 13 Nov 2017 18:17:42 -0800 (PST)
Received: from h.hanazo.no (nat64-7b.meeting.ietf.org [31.130.238.123]) (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 1BB642D511A; Tue, 14 Nov 2017 02:17:42 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id E35CC200C0C93F; Tue, 14 Nov 2017 10:17:18 +0800 (+08)
From: Ole Troan 
Message-Id: <98FB26AA-E5E2-43D1-97F1-62A3A59804FB@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_C630384C-6A12-49CC-93BD-089F27CCD012"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv4 only apps [was: IPv6 only host NAT64 requirements?]
Date: Tue, 14 Nov 2017 10:17:17 +0800
In-Reply-To: <79fa6f37-efdf-4ba1-49bc-a8da1d33fd43@gmail.com>
Cc: Philip Homburg , 6man WG 
To: Brian E Carpenter 
References:    <909eb642-b2a0-2fb5-8f41-297e013ae307@gmail.com>   <50F8194E-E887-4940-8ED0-CA4FD9600093@employees.org> <79fa6f37-efdf-4ba1-49bc-a8da1d33fd43@gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 02:17:44 -0000

--Apple-Mail=_C630384C-6A12-49CC-93BD-089F27CCD012
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Brian,

>>=20
>> If you are using the IPv6 only + NAT64 network you can't possibly use =
the legacy IPv4 only stuff in your laptop...?
>=20
> Indeed. Because my laptop isn't providing a NAT46 bump in the stack, =
for example.
>=20
> I haven't analysed this at all. What I'm saying is that we haven't =
done this;
> we've simply sneered at application developers who haven't added =
IPPROTO_IPV6
> to all their network code. Sneering doesn't solve much.

Gentle nudge?
I think Randy and Jen's experiment shows that we are nearly there.
On my iphone, where Apple enforced IPv6 support to be allowed to play, I =
only found _one_ single application that didn't work.
Even on my laptop, I had to look quite hard before finding something =
that broke.
We're nearly there!

Cheers,
Ole

--Apple-Mail=_C630384C-6A12-49CC-93BD-089F27CCD012
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+/bDNdvtpYqJhC33YFAloKUi0ACgkQvtpYqJhC
33akdhAAivegPD03EfXvLa1GZN59KVAdpyj20Qf73d9HoUOYWuDY+xw0XNeUMmu6
HK9A3dp0ifbu+urWi073+0ERC7U7gS7n3ocu3Kw3KQ4YkDHkfkPaOZt2hadYTkUL
/nDnsCQN1MkcrhaYHty83/osb+/nk+C7uf97kGlCGbMuhmC/p1Q3UHsmKHTw3N5L
0XBAiukCQAjwX+XLtgg8NbgNmMAQw2HbbXBdarZG0A70o/wGKS0YsT9UO5dzd7eg
nXIBWILbFMnZBSbP22ygRYpHZt1g16TDQATdEaAq/z1MdsWnyHTfdi2ZjGdGvHsX
C4xuYHkCPXSirO6gUNn8EhXSZvjMCwghGVR7JgNGHUP2Q4iWveyoFYMr9H7Qkkg2
kGgSgLmroPBTjqRk9FoWTJQTQs9E6eWrDo9dEohqm4pmwFnLM71xq5fJl42D8GuP
pOHjtnx3dCW7J4sv15YsP3Nz1OiNuxGcIrmJ/o3OP5d70TIFgmPdEs3d67pauIci
+lEDF8FU6t06FHmFbY0uRT+myFs8/i2obBdiZKyblFrW05mPX9lzbUT72O/Nb6sM
LDWGIngqQPpjuEZWh5WE2e1n7ivbA9YVP3ersZBNeRuRFdUO59mMp4fkXw2MBDGN
6gQUc/ejq9rZfQ2+O8JmA4p9i+m5SJQ4x7Hz8RChV9+T18nIz5E=
=D+Pq
-----END PGP SIGNATURE-----

--Apple-Mail=_C630384C-6A12-49CC-93BD-089F27CCD012--


From nobody Mon Nov 13 18:41:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4775B127863 for ; Mon, 13 Nov 2017 18:41:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 ekxgtVjyl1fd for ; Mon, 13 Nov 2017 18:41:43 -0800 (PST)
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 568B0127735 for <6man@ietf.org>; Mon, 13 Nov 2017 18:41:43 -0800 (PST)
Received: by mail-wr0-x22c.google.com with SMTP id u40so16169530wrf.10 for <6man@ietf.org>; Mon, 13 Nov 2017 18:41:43 -0800 (PST)
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=I+3e9bjEKdduncQH29V/vOasDKp5dyjvR+wn5upYBmQ=; b=aGz0oiwg6aLf/hWvFyd5akTblhazTebY1XrrXFWTJJxZ7XViGbZIcMe6ATC4p+qBPg cBdi+kfZCafW+I7AFxMtec+miMzNleMY9N7okRi1t5zkJIe9Nrzu686SCFeApiy70rHk SHFfia6uFI/QYbo+zwD2vEiQd9hSW8RMJEbep3OVNFsCeL7+fmJtu2Om3akFjLcgVY2V rb6CrbVgyGyLuzEtNefIXaeQsOu8tG3a20V0G/mZ5fVxa+IHffCGjlyYOE2sWyIiyrSu y0CJhAH7p/hN5ESBy5nOm0t7wphV6OmIQY6xMw+/yrnuSwZh4yMeFPvbc3VOixEZlWtF fsFA==
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=I+3e9bjEKdduncQH29V/vOasDKp5dyjvR+wn5upYBmQ=; b=qEG7ZesqXEeLffocGVGvPgfvTp1yXJG52etQ4JoYpL7+GLghUA1S6X5Kklo+lX05B3 HhnNmfqQSIfjwMbF5MA0Fzsps+b0pwSxTmWGCNNYQ2dXl0SDLh9SFcJKNn1N+YwFFkTU 401kWHyRtrQ8XV8SQsDSINm4Y5iYQv+5Xp6HrmtEgyEIu/OJar/E43ZTaB4wI8lxbMhy 4LfGu9UAMjZix1hKScSbKLrLF962fI0WWVhD5KBtxsbo9KIvN7gnUzQzOIruq/OqRpuG lb7JLp/pK84vXSe0LmymDcxljcsrhJxK9H8QzGZvuKfPP++7jywQoLtR5imxCwZwulIk 286g==
X-Gm-Message-State: AJaThX5+P4EI2Y+2sAHdBOJkltBhZMrjUfmKonCsHpp0AKYBN/bqzlcW B3hj6m/Uzk4XtTZ8uxFXwzqpeiI+lOtc6r48CRyuXQ==
X-Google-Smtp-Source: AGs4zMZCki/FzQrFLHVh1x8I53Hj3QNnDNt+a6/KcEnOPnBrh75WAamR2J1EiOx0r1NDktdGJYrYQl/pODoCa8V6tJ0=
X-Received: by 10.223.149.6 with SMTP id 6mr8670226wrs.112.1510627301707; Mon, 13 Nov 2017 18:41:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.160.149 with HTTP; Mon, 13 Nov 2017 18:41:01 -0800 (PST)
In-Reply-To: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>     
From: Warren Kumari 
Date: Tue, 14 Nov 2017 10:41:01 +0800
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Ted Lemon 
Cc: Mark Smith , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>,  "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 02:41:45 -0000

On Tue, Nov 14, 2017 at 9:45 AM, Ted Lemon  wrote:
> On Nov 14, 2017, at 3:43 AM, Mark Smith  wrote:
>
> Why are we holding this document up on this?
>
> Half baked cakes aren't cakes, even though they may look like them.
>
>
> FWIW, "we" aren't holding up this document.   It's in AUTH48.   The working
> group already has consensus on the document, the IESG has approved it, and
> at this point the only changes allowed are editorial changes that do not
> substantively change what the document says.   The working group has no
> agency here: this is entirely up to the authors and the AD.

Yup, but the AD is closely watching the discussion, because what the
WG wants is critical.

I held up publication because Fernando claimed that this was a
protocol change, and so doing this in V6OPS was a process violation --
as this was right before the meeting I decided it made sense to hold
publication so that A: I could get feedback from the WGs and B: I
could talk to Suresh (in his capacity as 6MAN AD).

Neither Suresh nor I think that this is a protocol change (and these
isn't really even a very fast V6OPS cannot touch protocol) - at the
moment I'm very strongly leaning towards just publishing it, although
(based on discussions with Suresh) I'm *considering* that this should
be Informational instead

Note that versions -04, -05, -06 of the document were Informational;
the GenArt (and other feedback) questioned the BCP status, and it was
(IMO) right on the hairy edge of Informational / BCP (enough that I
asked the IESG to comment on the status during eval). It was right on
the edge before, the new text, WG discussion (and my discussions with
Suresh) may have tipped it over to Informational.

I would feel out the WG about this - would you be OK with this being
Info (and getting it out the door)?

I feel I also owe the WG (and authors) an apology - this has been a
painful process and taken up way more of your time than it should
have.


W
>
> If the authors or the AD were to make substantive changes to the document,
> that would be grounds for an appeal by the working group.
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
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 Nov 13 18:47:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112D1127978 for ; Mon, 13 Nov 2017 18:47:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xspYzPjB8jzV for ; Mon, 13 Nov 2017 18:47:27 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D608F127136 for ; Mon, 13 Nov 2017 18:47:27 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4D65A20008; Mon, 13 Nov 2017 21:49:03 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B2E4980CFA; Mon, 13 Nov 2017 21:47:26 -0500 (EST)
From: Michael Richardson 
To: Ca By 
cc: Tim Chown , 6man WG 
Subject: Re: IPv6 only host NAT64 requirements?
In-Reply-To: 
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk> 
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 02:47:29 -0000

--=-=-=
Content-Type: text/plain


Ca By  wrote:
    > I have a network with 10s of millions of ipv6-only nodes, none of
    > which can so dnssec (neither android nor ios support it) and the
    > implication that these nodes are no longer ipv6 since they don't do
    > dnssec is ludicrous.

If you want to do DNSSEC validation, and there is a possibility of NAT64,
then you need to do the DNS64 locally.

If you aren't doing DNSSEC now, then it won't matter.
When you add DNSSEC, then you have to do NAT64 prefix discovery, and DNS64.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloKWT4ACgkQgItw+93Q
3WXjRwf8DFHiXRdzkUm7LK+59Rg4QixaE4Jj3b7qNVJ8I8l72ZMYRjZlUyrQk0d4
kG/fSYXE3ySbrMTCFJfuxKJYeRnz2pj+olAzwfJy8WhCl1R/t+fka+E91Fo0y6FM
2w+HmdEcav+J6F04nOmuE6x9VccFspehl1Z3vgNRVXejr0NMTI81MvSriJ0a8fix
o3dnrebDERAtU7TG6IaEFH32Ben3pplN0tJ3/59YLSISM5H8zqgCnjvb+LnFsWkE
/+DTl0NcwneGA0ba2KW6Uk0hWj1PzeJiVcQMRxXj2FhWB+2HbwV52ijpCgx6gt9p
mkW5eecYogVljBwsI99JauRfM+WjUA==
=YF2r
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Nov 13 18:50:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC4C129A96 for ; Mon, 13 Nov 2017 18:50:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQSddzC_GcKv for ; Mon, 13 Nov 2017 18:50:44 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBD6127909 for ; Mon, 13 Nov 2017 18:50:44 -0800 (PST)
Received: from h.hanazo.no (nat64-7b.meeting.ietf.org [31.130.238.123]) (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 01EF62D4F99; Tue, 14 Nov 2017 02:50:44 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D0B2D200C0F3C6; Tue, 14 Nov 2017 10:50:20 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_03CD319F-FE84-419C-AB00-765EA46F7484"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Tue, 14 Nov 2017 10:50:19 +0800
In-Reply-To: <24403.1510627646@obiwan.sandelman.ca>
Cc: Ca By , 6man WG 
To: Michael Richardson 
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk>  <24403.1510627646@obiwan.sandelman.ca>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 02:50:45 -0000

--Apple-Mail=_03CD319F-FE84-419C-AB00-765EA46F7484
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Michael,

>> I have a network with 10s of millions of ipv6-only nodes, none of
>> which can so dnssec (neither android nor ios support it) and the
>> implication that these nodes are no longer ipv6 since they don't do
>> dnssec is ludicrous.
>=20
> If you want to do DNSSEC validation, and there is a possibility of =
NAT64,
> then you need to do the DNS64 locally.
>=20
> If you aren't doing DNSSEC now, then it won't matter.
> When you add DNSSEC, then you have to do NAT64 prefix discovery, and =
DNS64.

Could you speculate on how much of this should go in the host and =
thereby are candidates for host requirements and how much belongs in the =
application?

Best regards,
Ole

Btw: Your key has expired. ;-)

--Apple-Mail=_03CD319F-FE84-419C-AB00-765EA46F7484
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+/bDNdvtpYqJhC33YFAloKWesACgkQvtpYqJhC
33Z5aw/+KSPfXNsJRk0d5xqw1N1zimUoXq/rW5hmGWAbjQ/7kuWGucnaF/a6TK1R
jk2aL9UaJSXiV0sh5mgDRPSTJf0+ErpDcDGt+IYFmyOtkchpICpMjPebVXf6ei48
d5FY0jcSQU2/7t8yYMbABx+Lp3Rt+7ziMZO8cjRpvhqyZ42+pDGB5tTxzj5zMDnE
2wxjfioSQ2+q9gko1xxhvgUdTIWKoR5IfmMQTmvgQ8q7Pjd1CWqPsmzDtIl7BGL7
VwAegyWndOjEhIMY9TM0H+qLU4+6OQQhmbTEueP28ohtzWIBtVBj2t1o90WO2PJT
Xt9DUY4PjphYvuYdHp+piOnqqFGJaJHn8MbysOoA0Tz39CJshFh7awM1Uzmig3ao
bCwXMdPn+XN98FVcdyUha1I/juNBmpAvRT6b5Am4AxlpzqWpkWv8XW11bZRLO9q+
3L8GqXjbTJ17xccJh8zniYfY7X50bLtM9Aw786lFH+yIL48I2Lo5KAvvmMuLrLnN
f4NScwBID0fWV40cHZ8t2ReYT5rcVqwTtyMUc7Sg45nbZQgjppZ8WrajFhuWKHg7
BznqS53pCUw6t8VvZeX9bOt0pTx4nJYypCt6wEJUtNoFVjJ6b2weYQrika2noKbP
/J0krulIJYWWlHnW71Nl9kOWyzg/xC/ZSRi5QG2Ku/WhuTNx5X8=
=pi+h
-----END PGP SIGNATURE-----

--Apple-Mail=_03CD319F-FE84-419C-AB00-765EA46F7484--


From nobody Mon Nov 13 18:59:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8331292FD; Mon, 13 Nov 2017 18:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02QqxG4Mp7wg; Mon, 13 Nov 2017 18:59:37 -0800 (PST)
Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::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 E16B91286B1; Mon, 13 Nov 2017 18:59:36 -0800 (PST)
Received: by mail-pf0-x241.google.com with SMTP id l24so914180pfj.6; Mon, 13 Nov 2017 18:59:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EiiNgQRKMpSo0wB4UTz2sbBiUpiBAynBDeAed2gjjdA=; b=KQuUecQ3wGh9ALxZ0rLEbUKc6E1YnMCvC4MMIuhyo825+EgdhN2kijk4p3yCIZJIC7 U2QyczR9ga+jSBWijBif8y1F7aTUktVK75xZvPFSsqh64CdEuiK1E9RXqg82lNj7xJAR bpeoeFKqDJej3hQXuiPenaUn5J67YPzqpOgvWdSgzndhdn8Zd6qc5OjEWRcVbPZ6pmsy drCCp1Jw6IEo2rBKWSX5tl4x33v5FHnjFPHL3Uh4+KWsJLndlfqeJbUvORmS+T3b8Bft ieQfnMDWjiKVtGFxV2khD4cpr7n5naNPBVRQ81sIGasEYk1/hbZ2oFdNwcabZ2Z0YKa8 aoAg==
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=EiiNgQRKMpSo0wB4UTz2sbBiUpiBAynBDeAed2gjjdA=; b=hiYolI6kjkzptMR/agpNRgLpWicd0Tlm9TmBzI3x+7F3BbYIicd9FNMxb84hOqP1oJ oDqRPi5laeqmWFYF2aFS+3TeX2KI5G+IfUKb2+klM2rCmCyudBvjgqCWdpHp258Ozjth dtV/I6i7Hh4a9S/s4rM23iAHS52px56eprIUX1uowv78/L+EQ4nmgznTFsydEgD9D0uI df2Q8qqsPtf/tOgg9C3zqlx3HlbMKi0MNsjU0lcrYJKSTUkS3pFadFG7yUByRKehbyuc uui5Gb7GxghSHaxHv+QWBmEISQnGRbJMS88FKSujJGdYXB3GURsVYMYsaU2BQoOyPJAM fTSg==
X-Gm-Message-State: AJaThX5PrOqS2/6Oa+IWbmbLTUxi9AM8+/SDKAaimz0R3N5VLht+5bEm DSHdUpP1XaIunR0p1nliJEF1aXii
X-Google-Smtp-Source: AGs4zMaXNyXPViAh46P6FFbEwU2Y/PvrOegnhVvGBMuDLYSRYmrefHGa+YPmIv5/11uU8TZ77j2Mcg==
X-Received: by 10.101.64.70 with SMTP id h6mr10739695pgp.144.1510628375909; Mon, 13 Nov 2017 18:59:35 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id r1sm12041903pfe.99.2017.11.13.18.59.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 18:59:34 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim 
In-Reply-To: 
Date: Tue, 14 Nov 2017 11:59:32 +0900
Cc: "6man@ietf.org" <6man@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>       <72ECE18B-5247-4D00-AF4C-763881929DD3@fugue.com> 
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 02:59:38 -0000

With my self torn between two schools of thought, I might retry the =
following argument:

  =E2=80=98The draft doesn=E2=80=99t make SLAAC stateful=E2=80=99

The essence of my argument is that what the draft brings new to the =
router side is not any change of states of any protocols but rather =
implementation details that need not be reflected on existing protocols =
like SLAAC or NDv6.

The rationale for my argument goes like the followings:

1.	As far as the hosts are concerned, nothing changes. A host =
receives RAs as usual, not even knowing that the prefix provided is =
unique per host, hence running DAD as usual.

2.1.	As for the router, take the case of usual SLAAC. There are no =
code lines specific about SLAAC. They just issue RAs, either in response =
to RSs or unsolicited. All it does is either set L=3D1 or L=3D0, in =
accordance with the operators policy.

2.2.	Let us see what changes are taking place to the router as a =
consequence of this draft.
	First of all, the router intended to implement the ideas of this =
draft should already know that it=E2=80=99s going to deal with different =
prefixes for different hosts, uniquely per host. Any routers of the =
intention then surely have to write in codes to manage the table of =
prefix-to-host mapping.=20
	Should there be any changes to the specs of NDv6 (rfc4861) that =
the router is running? No. (can be confirmed by re-reading NDv6). NDv6 =
is silent about how to store/manage the prefix it has handed out, =
anyhow. That part is implementation details that a protocol need not / =
should not bother itself with.
	Should any part of the specs of SLAAC (rfc4862) be changed? No. =
(can be confirmed by re-reading SLAAC). The router hasn=E2=80=99t been =
involved with any SLAAC specific behaviors anyhow in the fist place, all =
it does in connection with prefix assignment are NDv6-related actions, =
which puts us back to the statements made in the just preceding =
paragraph.

3.	Anything new this draft has brought are not spec changes (of =
either SLAAC or NDv6) but operational recommendations for any routers =
intending to adopt the ideas described in the draft. Certainly, you =
might have to rewrite part of your router software, but the necessary =
rewriting is such that you put more care about database management in =
regard to prefix-to-host mappings, but is not of such consequential =
quality that you might have to ask 6man to revise either SLAAC or NDv6.

4.	The conclusion is that the draft has not made any changes to =
SLAAC. The management of the prefix-to-host mapping table is not part of =
the SLAAC specs itself, but is simply part of your implementation =
details up to your best choice in your system environment.

P.S.: A protocol, by definition, is an interaction between two remote =
entities by exchange of messages of specific syntax and semantics. If =
there are no changes to such incurred, it=E2=80=99s not a protocol =
changes, and so is not subject to be sent to 6man.

---
DY








> On 14 Nov 2017, at 10:49, james woodyatt  wrote:
>=20
> On Nov 13, 2017, at 17:40, Ted Lemon  wrote:
>>=20
>> Also, it is not true that there is no pushback when new options are =
proposed for RA.
>=20
> I have a pile of rejections, none of which were duplicates of DHCPv6. =
One of them was eventually obsoleted by PCP. Another probably gets =
replaced by a mess of security vulnerabilities (but at least ND6 will =
remain pure!).
>=20
>=20
> --james woodyatt 
>=20
>=20
>=20
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops


From nobody Mon Nov 13 19:01:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33ADB1243FE; Mon, 13 Nov 2017 19:01:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 zysSo5vzrGEa; Mon, 13 Nov 2017 19:01:08 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037391242F7; Mon, 13 Nov 2017 19:01:08 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id l24so917273pfj.6; Mon, 13 Nov 2017 19:01:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TeKyljdb9IumNO9F9Nwk7WCyIIBSQ/+0RT9T0aVi8yU=; b=Wf5NXqS1fp7Z79WDBLdVh0LJsZlryzE8Jd2dJlBSotNHpUAg9lLjezmphlMFZ3nYoW riDxBAGWvUWOqBOuFdqOkSk//u/qpomzRDvC3sZemNO5kGy2ZJYOERobYZfDZDYpHgM5 7mCG5fLHxYoBkCQ1UIS8b3nqrL0rc4tZOJDmMS8jhXV4J7JbWwWxuHRVAifM5wrf8sGg rBThXeZfyOfRPYdCZvBERb1H6sJvWW5MEZ2LAjh2M9rvP8jCqMIEocAaEk/XX0Xajjr4 h9Frnkzcxw9QDn0/3muQ0fIbP6Y1HdR8kvpCTBWs7tVZvE/vmzctW93OupOoiDZr3ikC H43w==
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=TeKyljdb9IumNO9F9Nwk7WCyIIBSQ/+0RT9T0aVi8yU=; b=SOneiaPv7mTqkXurIPuVLHsgpbfwZycRl0P4424JVr4mbQ/YxDrCcECRDscLYOtApZ O5gGXFKNizJea5ezw2Fo8ca9UKhUcWAbtUfx1mD05mbiSJDh3vQA8TyHKgXhny1wmNdN AZ7w9PZPevrWeWk+YuFjsSvK5VxBS4EtH3wPWiFyUr2Ct2bTOsPU3oc7dYaHPe6nnywS ruFh3YwXihk1/odxjN41HXbAdA414/KYMztfhpGOg1UEP/lSR5Sv85r8NyZKwUnbbw7W ohgyPIwORd/hOOYLNCGfQh0rgi9eglAtvVs0Y0gnycpUINbGbRlbJJMWTQ9GSMROJqnh CEdw==
X-Gm-Message-State: AJaThX5650+N3FMnJQXTESECK+HZXpHrJLLHzM8DaRKPg+RUkqQ4exz3 kjPCuPN9BNh71N2TW+k8AoSdhJcu
X-Google-Smtp-Source: AGs4zMZ4BcPfyz+NhZzei/ulOrTYLYHksuvz98TlKMJDeXlFiggRNrdgjgl7ERDhikZ5x9w6HLfbhw==
X-Received: by 10.98.87.13 with SMTP id l13mr6469761pfb.193.1510628467667; Mon, 13 Nov 2017 19:01:07 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:9da5:83a8:c36:9ad5? ([2001:67c:370:1998:9da5:83a8:c36:9ad5]) by smtp.gmail.com with ESMTPSA id t4sm10305097pfd.110.2017.11.13.19.01.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 19:01:06 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-EC0116AD-AA01-4449-9EF7-2F3E29BB74C9
Mime-Version: 1.0 (1.0)
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: Fred Baker 
X-Mailer: iPhone Mail (15B150)
In-Reply-To: 
Date: Tue, 14 Nov 2017 11:01:05 +0800
Cc: Nick Hilliard , Lorenzo Colitti , Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <4450EF39-E404-4A53-948F-9F916415E6A1@gmail.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <5A0999A4.3040807@foobar.org>  
To: Ted Lemon 
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 03:01:09 -0000

--Apple-Mail-EC0116AD-AA01-4449-9EF7-2F3E29BB74C9
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

As specified in 3315, I imagine...

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

> On Nov 14, 2017, at 9:47 AM, Ted Lemon  wrote:
>=20
>> On Nov 14, 2017, at 8:43 AM, Fred Baker  wrote:=

>> I can also report that I have worked in an environment that only uses DHC=
Pv6, and it worked just fine for any purpose I put it to.
>=20
> How do you get your route?
>=20

--Apple-Mail-EC0116AD-AA01-4449-9EF7-2F3E29BB74C9
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

As specified in 3315, I imagine...

<=
div id=3D"AppleMailSignature">Sent using a machine that autocorrects in inte=
resting ways...

On Nov 14, 2017, at 9:47 AM, Ted Lemon <mellon@fugue.com> wrote:

On Nov 14, 2017, at 8:43 AM, Fred Baker <<=
a href=3D"mailto:fredbaker.ietf@gmail.com" class=3D"">fredbaker.ietf@gmail.c=
om> wrote:
<=
span style=3D"font-family: Menlo-Regular; font-size: 18px; font-style: norma=
l; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norma=
l; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: i=
nline !important;" class=3D"">I can also report that I have worked in an env=
ironment that only uses DHCPv6, and it worked just fine for any purpose I pu=
t it to.

How d=
o you get your route?

=

--Apple-Mail-EC0116AD-AA01-4449-9EF7-2F3E29BB74C9--


From nobody Mon Nov 13 19:17:53 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE2C126CC7; Mon, 13 Nov 2017 19:17:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBuzl8W-bs39; Mon, 13 Nov 2017 19:17:49 -0800 (PST)
Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5B112714F; Mon, 13 Nov 2017 19:17:49 -0800 (PST)
X-AuditID: 60721c4c-cc26d7000000a9fa-6a-5a0a605c88fc
Received: from VAADCEX09.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 64.96.43514.C506A0A5; Mon, 13 Nov 2017 22:17:48 -0500 (EST)
Received: from VAADCEX15.cable.comcast.com (147.191.102.82) by VAADCEX09.cable.comcast.com (147.191.102.76) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 22:17:47 -0500
Received: from VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0]) by VAADCEX15.cable.comcast.com ([fe80::3aea:a7ff:fe12:39c0%19]) with mapi id 15.00.1347.000; Mon, 13 Nov 2017 22:17:47 -0500
From: "Brzozowski, John" 
To: Ole Troan , Mark Smith 
CC: Fernando Gont , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
Subject: Re: [v6ops] DHCPv6 PD route injection (was: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
Thread-Topic: [v6ops] DHCPv6 PD route injection (was: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
Thread-Index: AQHTXOOlZwr2K8IU9U+8sAzJ4tkB6aMTNIKA
Date: Tue, 14 Nov 2017 03:17:47 +0000
Message-ID: <12D6415A-562A-4844-B56F-6A2EFA0B2267@cable.comcast.com>
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>     
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.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6AEB78F83EDD114DBAD3163E0A055A59@comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsWSUOxpoRuTwBVlsO+qkMXKFXeZLJ6sesNm 8XbxD0aLnUeOsltMblvBZnH62F5mBzaPg8c+MnrsnHWX3WPJkp9MHndvXWLy+HCohz2ANYrL JiU1J7MstUjfLoEr49znDywFF7QrHhw9w9TAeECri5GTQ0LAROLK1BlMXYxcHEIC25kk3q6f ywjhHGCU2Lv/A1TmJKPE6xvTmEBa2ATMJLYcvM0OYosIeEocfT+VBaSIWeAgo8Tj74/AEsIC lRKPJqxnhiiqkvh25DYjhG0kMX/6JyCbg4NFQFXiyV8TkDCvgIvE6a2roTbP5pCYt6wHbA6n gKPEhVl/wGxGATGJ76fWgB3BLCAucevJfCaIHwQkluw5zwxhi0q8fPyPFcQWFdCTuPZhJQtE XEfi7PUnjBC2gcTWpfug4goS2/dvYwG5h1lAU2L9Ln0I00pi9WxPiE2KElO6H7JDnCkocXLm E6hOcYnDR3awTmCUnoXkoFkIg2YhDJqFZNAsJIMWMLKuYuSxNNMzNDTRM7LQMzfbxAhKAEUy PjsYP03zOMQowMGoxMM7JZ4rSog1say4MvcQowQHs5IIb0gwUIg3JbGyKrUoP76oNCe1+BCj NAeLkjjv/JOsUUIC6YklqdmpqQWpRTBZJg5OqQbG0DyB2VM3drm/N/v103B50ZNYv3MOs07t jr7LGvpbUN4r7kK9r9ytyCnapUarDh2zFM2qtZW1yfx+bfG5E9fPtvUv8fDUFV4ZVdp1otKJ 02mPRpbRrfyQsyLxPwxvJFz/If7EkeHC5ex4uyiWZWdLFrP3azJ/N3yxUSnz5p0Xc41XSTw/ wqSuxFKckWioxVxUnAgAOYmKcfwCAAA=
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 03:17:51 -0000

T2xlIEkgdGhpbmsgdGhpcyBpcyBwZXJoYXBzIDUtNyB5ZWFycyB0b28gbGF0ZSBwb3NzaWJseSBs
b25nZXIuICBUbyBiZSBjbGVhciB0aGlzIGhhcyBpbiBmYWN0IGJlZW4gc29sdmVkLCBQRFJJIHdh
cyBzb21ldGhpbmcgd2UgbmVlZGVkIHRvIGFkZHJlc3MgdG8gbGF1bmNoIElQdjYgZm9yIERPQ1NJ
UyBiYXNlZCBIU0QgbWFueSB5ZWFycyBhZ28uICBSYWxwaCAoc2luY2UgeW91IG1lbnRpb24gaGlt
KSB3YXMgdGhlcmUsIGhlIGtub3dzLg0KDQpUaGlzIGlzIHdpZGVseSBzdXBwb3J0ZWQgdG9kYXkg
YWNyb3NzIGNhYmxlIG5ldHdvcmtzIHNwZWNpZmljYWxseSBmb3IgRE9DU0lTIGFuZCBldmVuIG90
aGVyIGZpYmVyIGJhc2VkIChQT04pIGFjY2VzcyBuZXR3b3JrIGltcGxlbWVudGF0aW9ucyB3aGVy
ZSB3ZSAoQ29tY2FzdCkgd2VyZSBpbnZvbHZlZCBpbiB0aGUgZGV2ZWxvcG1lbnQgb2YgSVB2NiBz
dXBwb3J0LiAgTm90ZSB3ZSB1c2UgdGhlIHNhbWUgaW1wbGVtZW50YXRpb24gZm9yIG91ciB2aWRl
byBzZXJ2aWNlcywgd2hpY2ggYXJlIElQdjYgb25seS4NCg0KV2h5IGluIGhlYXZlbnMgbmFtZSB3
b3VsZCB5b3Ugbm93IGdvIGJhY2sgYW5kIGRvY3VtZW50IHNvbWV0aGluZyB0aGF0IGhhcyBiZWVu
IGRvbmUgZm9yIHNvIGxvbmc/IChyaGV0b3JpY2FsKQ0KDQpQbGVhc2Ugbm90ZSBhIGRvY3VtZW50
YXRpb24gZXhlcmNpc2Ugd2lsbCBub3QgY2hhbmdlIGFueSBleGlzdGluZyBkZXBsb3ltZW50cywg
dGhpcyBzaGlwIGhhcyBzYWlsZWQuICBUaGlzIGlzIG5vdCBhIHdpc2UgdXNlIG9mIElFVEYgdGlt
ZSBhbmQgZW5lcmd5LiAgSWYgdGhpcyBpcyB0aGUgdHlwZSBvZiB3b3JrIHRoZSBJRVRGIGJlbGll
dmVzIHJlcXVpcmVzIGF0dGVudGlvbiBwZXJoYXBzIGl0IGlzIHRpbWUgdG8gc3RhcnQgc2h1dHRp
bmcgZG93biBzb21lIG9mIHRoZSBJUHY2ICg2bWFuL3Y2b3BzKSBXR3MuDQoNCkpvaG4NCisxLTQ4
NC05NjItMDA2MA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgPHY2
b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBPbGUgVHLDuGFuIDxvdHJvYW5AZW1w
bG95ZWVzLm9yZz4NCkRhdGU6IE1vbmRheSwgTm92ZW1iZXIgMTMsIDIwMTcgYXQgMTg6NTcNClRv
OiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPg0KQ2M6IEZlcm5hbmRvIEdvbnQg
PGZnb250QHNpNm5ldHdvcmtzLmNvbT4sIHY2b3BzIDx2Nm9wc0BpZXRmLm9yZz4sICI2bWFuQGll
dGYub3JnIiA8Nm1hbkBpZXRmLm9yZz4sIEd1bnRlciBWYW4gZGUgVmVsZGUgPGd1bnRlci52YW5f
ZGVfdmVsZGVAbm9raWEuY29tPg0KU3ViamVjdDogW3Y2b3BzXSBESENQdjYgUEQgcm91dGUgaW5q
ZWN0aW9uICh3YXM6IFJlOiBTdGF0ZWZ1bCBTTEFBQyAoZHJhZnQtaWV0Zi12Nm9wcy11bmlxdWUt
aXB2Ni1wcmVmaXgtcGVyLWhvc3QpKQ0KDQogICAgDQogICAgDQogICAgPiBPbiAxNCBOb3YgMjAx
NywgYXQgMDM6NDMsIE1hcmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb20+IHdyb3RlOg0K
ICAgID4gDQogICAgPiANCiAgICA+IERIQ1B2NiBoYXMgYmVlbiBkZXNpZ25lZCB0byBhdm9pZCBo
YXZpbmcgc3RhdGUgaW4gaW50ZXJtZWRpYXJ5IGRldmljZXMNCiAgICA+IGJ5IGluY29ycG9yYXRp
bmcgYSByZWxheSBhZ2VudCBpbnRvIHRoZSBhcmNoaXRlY3R1cmUsIHNwZWNpZmllZCBpbg0KICAg
ID4gUkZDMzMxNS4NCiAgICA+IA0KICAgID4gQ2xpZW50cyB1c2UgRFVJRHMgdG8gaWRlbnRpZnkg
dGhlbXNlbHZlcywgYW5kIHRoZSBESENQdjYgc2VydmVyDQogICAgPiBhc3NvY2lhdGVzIGNsaWVu
dCBhdHRyaWJ1dGVzIHdpdGggdGhlIGNsaWVudCdzIERVSUQuIFRoYXQgaXMgd2hhdA0KICAgID4g
YWxsb3dzIERIQ1B2Ni1QRCB0byBzdXJ2aXZlIGEgcm91dGVyL0RIQ1B2NiByZWxheSByZWJvb3Qu
DQogICAgPiANCiAgICA+IFRoaXMgZHJhZnQgaGFzbid0IGJlZW4gcHVibGlzaGVkIGFzIGFuIFJG
QywgaG93ZXZlciBpdCBpcyBhbHNvDQogICAgPiBjb25zaWRlcmluZyB0aGlzIGlzc3VlLg0KICAg
ID4gDQogICAgPiAiREhDUHY2IFJlbGF5IEFnZW50IEFzc2lnbm1lbnQgTm90aWZpY2F0aW9uIChS
QUFOKSBPcHRpb24iDQogICAgPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0
Zi1kaGMtZGhjcHY2LWFnZW50b3B0LWRlbGVnYXRlLTAzDQogICAgPiANCiAgICA+IEEgbnVtYmVy
IG9mIHZlbmRvcnMgc2VlbSB0byBoYXZlIGltcGxlbWVudGVkIHRoZSBmdW5jdGlvbmFsIGVxdWl2
YWxlbnQNCiAgICA+IGJ5IGxvb2tpbmcgZGlyZWN0bHkgYXQgdGhlIElEX1BEIG9wdGlvbiB3aGVu
IHRoZSBESENQdjYgcmVwbHkgaXMgc2VudA0KICAgID4gdG8gdGhlIGNsaWVudCAtIHNlYXJjaCBm
b3IgIkRIQ1B2NiBSZWxheSBBZ2VudCBOb3RpZmljYXRpb24gZm9yIFByZWZpeA0KICAgID4gRGVs
ZWdhdGlvbiINCiAgICA+IA0KICAgID4gVGhlIGFsdGVybmF0aXZlIGlzIHRvIGhhdmUgYSBSQURJ
VVMgc2VydmVyIHByb3ZpZGUgdGhlIGRlbGVnYXRlZA0KICAgID4gcHJlZml4IGluZm9ybWF0aW9u
IHRvIGEgREhDUHY2IHNlcnZlciBydW5uaW5nIG9uIHRoZSByb3V0ZXIuICJSQURJVVMNCiAgICA+
IERlbGVnYXRlZC1JUHY2LVByZWZpeCBBdHRyaWJ1dGUiLCBSRkM0ODE4Lg0KICAgID4gDQogICAg
PiBQb3NzaWJseSB0aGUgUkFESVVTIG1ldGhvZCBjb3VsZCBiZSB1c2VkIGluIHRoaXMgZHJhZnQn
cyBzY2VuYXJpbyBpZiBhDQogICAgPiBsYXllciAyIGF0dHJpYnV0ZSBzdWNoIGFzIHRoZSBNQUMg
YWRkcmVzcyBvciBwZXItY2xpZW50IFZMQU4gdGFncywgb3INCiAgICA+IDgwMi4xWCBhdXRoZW50
aWNhdGlvbiBpbmZvcm1hdGlvbiwgaXMgdXNlZCB0byBpZGVudGlmeSB0aGUgY2xpZW50Lg0KICAg
ID4gDQogICAgPiBJZiB0aGlzIGRyYWZ0IGNhbid0IGRvY3VtZW50IHRoYXQgbWV0aG9kIGJlY2F1
c2UgaXQgZG9lc24ndCBleGlzdCwNCiAgICA+IHRoZW4sIGFzc3VtaW5nIENvbWNhc3QgaXMgdGhl
IG9ubHkgZGVwbG95bWVudCBvZiB0aGlzLCBpdCBzZWVtcw0KICAgID4gQ29tY2FzdCBhcmVuJ3Qg
dHJ5aW5nIHRvIGhhdmUgYSBwcmVmaXggYXNzaWdubWVudCBzdXJ2aXZlIGEgcm91dGVyDQogICAg
PiByZWJvb3QuIFRoYXQncyBhICJmbGFzaCByZW51bWJlcmluZyIgYXBwcm9hY2gsIHdoaWNoIEkg
ZG9uJ3QgdGhpbmsgaXMNCiAgICA+IHJpZ2h0IGZvciBJUHY2Lg0KICAgID4gDQogICAgPiANCiAg
ICA+PiBUaGlzIGhhcyBub3Qgc3RvcHBlZCB0aGUgZGVwbG95bWVudCBvZiB0ZW5zIG9yIGh1bmRy
ZWRzIG9mIG1pbGxpb25zIG9mDQogICAgPj4gbmV0d29ya3MgdGhhdCB1c2UgREhDUHY2IFBELg0K
ICAgID4+IA0KICAgID4gDQogICAgPiBXaGF0IHdhcyB0aGUgYWx0ZXJuYXRpdmUgdGhhdCBkaWRu
J3QgaGF2ZSB0aGlzIGxpbWl0YXRpb24/DQogICAgPiANCiAgICA+IFRoZXJlIGlzIGEgYmlnIGRp
ZmZlcmVuY2UgYmV0d2VlbiBzb21ldGhpbmcgd29ya2luZyBhbmQgc29tZXRoaW5nIHdvcmtpbmcg
d2VsbC4NCiAgICANCiAgICBZZXMsIGl0J3MgcXVpdGUgdW5mb3J0dW5hdGUgdGhhdCB3ZSBoYXZl
bid0IHNvbHZlZCB0aGUgcHJvYmxlbSBvZiByb2J1c3Qgcm91dGUgaW5qZWN0aW9uIGluIFBEIHll
dC4NCiAgICANCiAgICBSYWxwaCBhbmQgSSB3aGVuIHdyaXRpbmcgMzYzMywgY29uY2x1ZGVkIHdo
aWxlIHRoZXJlIHdlcmUgbWFueSBvcHRpb25zLCBmZXcgb2YgdGhlbSB3ZXJlIGF0dHJhY3RpdmUs
IGFuZCBpbnN0ZWFkIHJlc29ydGVkIHRvIHNwZWNpZnkgdGhhdCBQRCBtdXN0IG9wZXJhdGUgd2l0
aG91dCByZWxheXMuDQogICAgDQogICAgTWFya3VzIGVudW1lcmF0ZWQgdGhlIG9wdGlvbnMgaGVy
ZToNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LXN0ZW5iZXJnLXBk
LXJvdXRlLW1haW50ZW5hbmNlLTAwLnR4dA0KICAgIA0KICAgIExldCBtZSBrbm93IGlmIHlvdSBh
cmUgaW50ZXJlc3RlZCBpbiB3b3JraW5nIG9uIHRoZSBwcm9ibGVtLg0KICAgIA0KICAgIEJlc3Qg
cmVnYXJkcywNCiAgICBPbGUNCiAgICANCiAgICANCg0K


From nobody Mon Nov 13 19:23:07 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C09F128990; Mon, 13 Nov 2017 19:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViZ_0ZaGI2xc; Mon, 13 Nov 2017 19:22:50 -0800 (PST)
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 0B02F1242F7; Mon, 13 Nov 2017 19:22:50 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id s2so14282268pge.10; Mon, 13 Nov 2017 19:22:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tNFKHABHncooQ3XRsgLFTOKPFteln/kgHfYPT4+xHdk=; b=GUt6QUnGZu4uq/hIlSXLjkGhcXHp95XLG4kqS+rsILxfNwns3MnIo6iD12yMIWJxBo UU61AbyNKQxnIkccIsc/fVkKb1xeZLJT0pOIwHjXNBfyTSebDIJksqNx4olNLrcNodZa Np0ULdRWsYWKpU820vg7rEjxihE/UUODuYD7+Xv9t15khVQyiztrNSbrGyiBkN8Dog5Y 0jPbjNyVLLmTuzyCBWay0rH1DTiaiA3bnqDDhK98VBHH+NXHYa7Zj0PTT9mRPzgwQMWs GEyg7MYPu+A2pMN9bJE2L7kmQyxzLtfKmG9hJiJPOvuI2coJMmwV6MXAXynZiWWx82/G siHw==
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=tNFKHABHncooQ3XRsgLFTOKPFteln/kgHfYPT4+xHdk=; b=H41RWCC6ezFcl3UjtiQBGCuFwByMI9KoZEkVmS0D5YVK0IH2jIQ+zbCGS/PiZp/Bxn EzqWnkREjV7NYqWKyz5o0+gUNvMNLxA9Xz1T80tAd4MJ0M+fQYW2N/dtwShXNx7RiiDm S0OCrP2WOP+++LT2UNSq+S4MgAdLw2nbSODfy2gE3Y+1G7eeTETH27apIKtGrnKW1t14 eHFHTCjb8oV38+3xFS6oJJPi5IiC2FM538dj7mZklun+buWdkYe4bzmtqX5Mr2nzfq4K 2Tki0hQXtnJBZpFgY6JrbF8o28L1C7+VSploGwOHKUbY3b/Rs18yqrTpvAdXDN/ORhqX j4Zw==
X-Gm-Message-State: AJaThX6fXQw+jLsyGur07Z1WB0jBJPdhqBuDHIgUiKeXJuj0TdPrOKJI gbYHC5KQKLh/4X8qMSvG0IrUeuTf5xs=
X-Google-Smtp-Source: AGs4zMYOr5Bl4E5HcfVEKXW98+YV+L93pJ9UMav+T7A4EaGdru9c83J9DATqxnFvWPIU+uvVpcojOg==
X-Received: by 10.99.170.66 with SMTP id x2mr10854917pgo.117.1510629769138; Mon, 13 Nov 2017 19:22:49 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:e88d:8fb9:5eb5:14b0? ([2001:67c:370:1998:e88d:8fb9:5eb5:14b0]) by smtp.gmail.com with ESMTPSA id a9sm21633499pff.31.2017.11.13.19.22.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 19:22:48 -0800 (PST)
From: Suresh Krishnan 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C560EE03-2FC3-4C6F-9BB3-A32150979E70"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Upleveling discussion (was Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
Date: Tue, 14 Nov 2017 11:22:49 +0800
In-Reply-To: 
Cc: Ted Lemon , Mark Smith , Fernando Gont , "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
To: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>      
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 03:22:52 -0000

--Apple-Mail=_C560EE03-2FC3-4C6F-9BB3-A32150979E70
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,
  I would like to summarize the issues that have been brought up, along =
with my views (I apologize for the long mail but I think it is warranted =
in this case)

a) Changes were made to the draft after most of the IESG balloted on an =
older version of the document

Yes .This is an issue but hardly limited to this draft. I keep reading =
newer versions of the draft if I balloted DISCUSS and/or have some open =
issues that need to get resolved. After the issues are resolved, I do =
not usually read newer versions unless I am the shepherding AD for the =
document in which case I do. I spoke to some of the other ADs and their =
workflows are similar. This is something we need to discuss on the IESG =
in order to see how we can improve.

b) Mechanism does not work

Given that the mechanism has been implemented and deployed by the =
authors, I have a hard time taking this claim at face value. Providing =
an unique prefix per host has been standard practice in 3GPP mobile =
networks for the past *15 years*. based on recommendations from the IETF =
back at that time. When a mobile attaches, there is state created on the =
first hop router that does exactly what this draft wants to do. The only =
issue I see is a lack of mechanism to clean up stale prefixes if the =
hosts go away, but depending on the deployment this may or may not be an =
issue.

c) The document should be Informational and not BCP

Regardless of people claiming on this thread that the IESG chose this to =
be a BCP, it is the *v6ops WG* that decided to send this in as BCP. The =
document was IETF Last Called as BCP way before it even hit the IESG. =
Given that there is no objective guidance in RFC2026 on what constitutes =
a BCP (=E2=80=9Cbest=E2=80=9D and "what is believed to be the best =
way=E2=80=9D are not exactly objective) we could go either way. I am =
inclined to go along with the wishes of the WG (v6ops), the shepherding =
AD (Warren) in the absence of a more definitive measure of suitability. =
That said, as I conveyed to Warren, I would not object if this was made =
Informational either.

d) Draft should have been done in 6man

Let me start off by stating that (AFAIK) there is no written agreement =
between 6man and v6ops as to the split of work. We have mostly used =
common sense to decide where things go. Specifically, if there have been =
bits-on-the-wire changes we have insisted that the work be done in 6man =
and this is certainly not the case for the document in question. I think =
this work is certainly pertinent to v6ops based on the following text in =
their charter

Solicit input from network operators and users to identify
operational issues with IPv6 networks, and determine solutions or
workarounds to those issues.

In closing, looking at where the document is in the publication cycle =
(It is in AUTH48 and it was probably an hour or so away from being =
published as an RFC), I think making major changes to the draft without =
a clear justification and WG consensus is not appropriate .

Thanks
Suresh

> On Nov 14, 2017, at 9:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) =
 wrote:
>=20
> This may be a good moment to halt this discussion.
> The original reported finding that this draft makes protocol changes =
=E2=80=9Cmaking SLAAC statefull=E2=80=9D has been found invalid.
> This means that there is no procedural issue caused by this draft.
> =20
> AUTH48 process can now go forward as planned.
> =20
> G/
> =20
> =C2=A0 <>
> From: Ted Lemon [mailto:mellon@fugue.com]=20
> Sent: Tuesday, November 14, 2017 09:46
> To: Mark Smith 
> Cc: Lorenzo Colitti ; Fernando Gont =
; v6ops@ietf.org WG ; =
6man@ietf.org; Van De Velde, Gunter (Nokia - BE/Antwerp) =

> Subject: Re: [v6ops] Stateful SLAAC =
(draft-ietf-v6ops-unique-ipv6-prefix-per-host)
> =20
> On Nov 14, 2017, at 3:43 AM, Mark Smith > wrote:
> Why are we holding this document up on this?
> Half baked cakes aren't cakes, even though they may look like them.
> =20
> FWIW, "we" aren't holding up this document.   It's in AUTH48.   The =
working group already has consensus on the document, the IESG has =
approved it, and at this point the only changes allowed are editorial =
changes that do not substantively change what the document says.   The =
working group has no agency here: this is entirely up to the authors and =
the AD.
> =20
> If the authors or the AD were to make substantive changes to the =
document, that would be grounds for an appeal by the working group.
> =20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--Apple-Mail=_C560EE03-2FC3-4C6F-9BB3-A32150979E70
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi all,
  I would like to summarize the =
issues that have been brought up, along with my views (I apologize for =
the long mail but I think it is warranted in this case)

a) Changes were made to =
the draft after most of the IESG balloted on an older version of the =
document

Yes =
.This is an issue but hardly limited to this draft. I keep reading newer =
versions of the draft if I balloted DISCUSS and/or have some open issues =
that need to get resolved. After the issues are resolved, I do not =
usually read newer versions unless I am the shepherding AD for the =
document in which case I do. I spoke to some of the other ADs and their =
workflows are similar. This is something we need to discuss on the IESG =
in order to see how we can improve.

b) Mechanism does not work

Given that the mechanism =
has been implemented and deployed by the authors, I have a hard time =
taking this claim at face value. Providing an unique prefix per host has =
been standard practice in 3GPP mobile networks for the past *15 years*. =
based on recommendations from the IETF back at that time. When a mobile =
attaches, there is state created on the first hop router that does =
exactly what this draft wants to do. The only issue I see is a lack of =
mechanism to clean up stale prefixes if the hosts go away, but depending =
on the deployment this may or may not be an issue.

c) The document should =
be Informational and not BCP

Regardless of people claiming on this =
thread that the IESG chose this to be a BCP, it is the *v6ops WG* that =
decided to send this in as BCP. The document was IETF Last Called as BCP =
way before it even hit the IESG. Given that there is no objective =
guidance in RFC2026 on what constitutes a BCP (=E2=80=9Cbest=E2=80=9D =
and "what is believed to be the best way=E2=80=9D are not exactly =
objective) we could go either way. I am inclined to go along with the =
wishes of the WG (v6ops), the shepherding AD (Warren) in the absence of =
a more definitive measure of suitability. That said, as I conveyed to =
Warren, I would not object if this was made Informational =
either.

d) =
Draft should have been done in 6man

Let me start off by stating that =
(AFAIK) there is no written agreement between 6man and v6ops as to the =
split of work. We have mostly used common sense to decide where things =
go. Specifically, if there have been bits-on-the-wire changes we have =
insisted that the work be done in 6man and this is certainly not the =
case for the document in question. I think this work is certainly =
pertinent to v6ops based on the following text in their =
charter

Solicit =
input from network operators and users to identify
operational issues with IPv6 networks, and determine =
solutions or
workarounds to those issues.

In closing, looking at =
where the document is in the publication cycle (It is in AUTH48 and it =
was probably an hour or so away from being published as an RFC), I think =
making major changes to the draft without a clear justification and WG =
consensus is not appropriate .

Thanks
Suresh

On Nov 14, 2017, at 9:57 AM, =
Van De Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com> wrote:

This may be a good moment to halt this discussion.
The =
original reported finding that this draft makes protocol changes =
=E2=80=9Cmaking SLAAC statefull=E2=80=9D has been found invalid.
This =
means that there is no procedural issue caused by this draft.
 
AUTH48 =
process can now go forward as planned.
 
G/
 
 
From: Ted Lemon [mailto:mellon@fugue.com] 
Sent: Tuesday, November 14, 2017 =
09:46
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Lorenzo Colitti <lorenzo@google.com>; =
Fernando Gont <fgont@si6networks.com>; v6ops@ietf.org WG <v6ops@ietf.org>; 6man@ietf.org; Van De =
Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>
Subject: Re: [v6ops] Stateful SLAAC =
(draft-ietf-v6ops-unique-ipv6-prefix-per-host)
 
On Nov 14, 2017, at 3:43 AM, Mark Smith <markzzzsmith@gmail.com> =
wrote:
Why are we holding this =
document up on this?
Half baked cakes aren't =
cakes, even though they may look like them.
 
FWIW, "we" aren't holding =
up this document.   It's in AUTH48.   The working group =
already has consensus on the document, the IESG has approved it, and at =
this point the only changes allowed are editorial changes that do not =
substantively change what the document says.   The working group =
has no agency here: this is entirely up to the authors and the AD.
 
If the authors or the AD were to make =
substantive changes to the document, that would be grounds for an appeal =
by the working group.
 
---------------------------------------------------------------=
-----
IETF IPv6 working group mailing =
list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
---------------------------------------------------------------=
-----

=

--Apple-Mail=_C560EE03-2FC3-4C6F-9BB3-A32150979E70--


From nobody Mon Nov 13 20:24:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB248127B52 for ; Mon, 13 Nov 2017 20:24:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vCx4xAliejD2 for ; Mon, 13 Nov 2017 20:24:06 -0800 (PST)
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 0A35C126E64 for <6man@ietf.org>; Mon, 13 Nov 2017 20:24:06 -0800 (PST)
Received: by mail-io0-x22e.google.com with SMTP id 134so23048607ioo.0 for <6man@ietf.org>; Mon, 13 Nov 2017 20:24:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X5LJI8G40ncaKE2TJjeY1IICQSCv+/t2Zv/p9rWxJyU=; b=Mr3F051iqEODYps3sVl43ixN3tMqQEd0oXXkNrSwvp5HBzSZnN92jlot0fVP9ryOzI i8wNHQCiwFamfroRgFNbdahOPjs2XFkbKMEBZATmK/YTWWFYgDQoF4f1imtFimmbGnEi ihDwApK0hZs5w0l8DoAI0ap6kIDBzECk8MSUN9+l5L9vt3lcPFxk8ljnnWDzRT+WfjC6 c0VXpUarbzf0GUGMm73zADnT8FHuxoTaeVlSKDybJyg2wOtrK+juleGOLSI7yxC7QA+G RVZNGn4ebiI8h25NjyKXX1mtJ+D5kzs8DcLLx/LuBI0dt5XnqAld4fq0ef5q7Ed1rYvb 3yGw==
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=X5LJI8G40ncaKE2TJjeY1IICQSCv+/t2Zv/p9rWxJyU=; b=M+RrRHfb9iiPf4JGiR5Lh5LFvh46ipAyt/PY8aBMp5ga/gbpWXG9I1sig3ZH0YAiQa sn/2v1wStlgqdKpaT4kH5g51FBj8jEeckO5xJtvv1BeyMhIB5coKy2prfH2N280FlhuX YVAE2y7a71mQl1Os9Y5efGDGOf/buQRSIuwgGj/xJozg/aMbMzCPZY6cp8MTBRuzeAZB xlH0+vteJyH+eEtxbdr/vpXjcZ4BGIRSp2LI439x7dTI+ByHqMxeG3snd6wBGm3BwZJL E/hrr4qgIVRz41hQpL2GpIKUr6+qbUJzc4sW5/eax5f6TIBo+zWAB38xCrDKvnGG+5zW sE9g==
X-Gm-Message-State: AJaThX6ltBqQmyl8WPzXUe9OfAkRY8MiRPOzFAWiVy9vn3+i8wGJQnAc i0wmvyqclVkesvDP9UQxJ8QGd9/GpqWhhHPZq6Jf/Q==
X-Google-Smtp-Source: AGs4zMYP+NQ8ILD1ePh6mXyXq9tZNMyC2KGjHJnxecL3V1/RLYbYWV0HykXtOP0JcjcGarg4zUwUq2o00RFomWhoOjk=
X-Received: by 10.107.174.94 with SMTP id x91mr12308786ioe.224.1510633444969;  Mon, 13 Nov 2017 20:24:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Mon, 13 Nov 2017 20:23:44 -0800 (PST)
In-Reply-To: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>      
From: Lorenzo Colitti 
Date: Tue, 14 Nov 2017 12:23:44 +0800
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Warren Kumari 
Cc: Ted Lemon , Fernando Gont ,  "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>,  "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
Content-Type: multipart/alternative; boundary="001a1144a242e05321055de9c1f6"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 04:24:08 -0000

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

On Tue, Nov 14, 2017 at 10:41 AM, Warren Kumari  wrote:

> I would feel out the WG about this - would you be OK with this being
> Info (and getting it out the door)?
>

Warren,

is it worth asking that question on a new thread that is narrowly scoped to
that question? There's a lot of discussion still on this thread that might
cloud the response.

Cheers,
Lorenzo

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


On T=
ue, Nov 14, 2017 at 10:41 AM, Warren Kumari <warren@kumari.net> wrote:
I would feel out the WG abou=
t this - would you be OK with this being

Info (and getting it out the door)?

War=
ren,

is it worth asking that question on a new thr=
ead that is narrowly scoped to that question? There's a lot of discussi=
on still on this thread that might cloud the response.

=

Cheers,
Lorenzo


--001a1144a242e05321055de9c1f6--


From nobody Mon Nov 13 22:03:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE7C1293E1 for ; Mon, 13 Nov 2017 22:03:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.013
X-Spam-Level: 
X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_24=1.618, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, 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 13_UU_J8KEiG for ; Mon, 13 Nov 2017 22:03:17 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22051128AB0 for ; Mon, 13 Nov 2017 22:03:16 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAE63FhN032980 for ; Tue, 14 Nov 2017 07:03:15 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4BDD3200C33 for ; Tue, 14 Nov 2017 07:03:15 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3DC55200B5C for ; Tue, 14 Nov 2017 07:03:15 +0100 (CET)
Received: from [132.166.84.15] ([132.166.84.15]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAE63Djm003656 for ; Tue, 14 Nov 2017 07:03:14 +0100
To: IPv6 
From: Alexandre Petrescu 
Subject: ESSID ietf-v6only at IETF 100
Message-ID: 
Date: Tue, 14 Nov 2017 07:03:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------29B710425B42C144932B6D1E"
Content-Language: fr
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 06:03:19 -0000

This is a multi-part message in MIME format.
--------------29B710425B42C144932B6D1E
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

I have problems connecting to the IPv6-only ESSID "ietf-v6only".

It is a problem of certificates.

I have this problem on Windows since several IETF meetings; it may not=20
be related in particular to IPv6.

The message in the window below says: "The server=20
services.meeting.ietf.org presented a certifcate valid emitted by=20
Starfield CA, but that is not configured as a valid anchor to approve=20
this profile".

I dont thave this kind of certification refusal problem on=20
ietf-legacy100 ESSID (and all earlier ietf-legacy), neither on=20
ietf-nat64-unencrypted.

This ietf-nat64-unencrypted is now appearing first time at IETF.=C2=A0 I =

suppose people realized there was a problem with certs and created an=20
'unencrypted' version.=C2=A0 That's not a best practice to fix security :=
-)

And yes, my VPN FortiClient works ok on ietf-nat64-unencrypted.




Alex



--------------29B710425B42C144932B6D1E
Content-Type: multipart/related;
 boundary="------------ACFCB6E3C948482F77DF51DF"


--------------ACFCB6E3C948482F77DF51DF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
Hi,

    
I have problems
          connecting to the IPv6-only ESSID "ietf-v6only".

    
It is a problem of
          certificates.

    
I have this problem on
          Windows since several IETF meetings; it may not be related in
          particular to IPv6.

    
The message in the
          window below says: "The server services.meeting.ietf.org
          presented a certifcate valid emitted by Starfield CA, but that
          is not configured as a valid anchor to approve this profile".

    
I dont thave this kind
          of certification refusal problem on ietf-legacy100 ESSID (and
          all earlier ietf-legacy), neither on ietf-nat64-unencrypted.

    
This
          ietf-nat64-unencrypted is now appearing first time at IETF.  I
          suppose people realized there was a problem with certs and
          created an 'unencrypted' version.  That's not a best practice
          to fix security :-)

    
And yes, my VPN
          FortiClient works ok on ietf-nat64-unencrypted.

        

    


        

    


        

    


        

    
Alex

        

    


      

  


--------------ACFCB6E3C948482F77DF51DF
Content-Type: image/png;
 name="nmjmnhnofdiighgk.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="nmjmnhnofdiighgk.png"

iVBORw0KGgoAAAANSUhEUgAAAccAAAFjCAIAAADHE1cdAAAgAElEQVR4nO2dd1gU1/rH99qw
o8abdnOTcDe5MdUeojGWrIjR9MREsSCKEUmxRJPYsaBRgg3sNZZgYUGsKCBWWLBkTVZNookC
BgugUmyT3N/+/pjZnTltZnZ3FnaX9zyfh2fZnTnvOe85850zZ868o/tFdfr1119//fXX8+fP
X7x4saCg4Nq1ayUlJWVlZbdv37579+59p9Ldu3dv375dVlZWUlJy7dq1goKCixcvnj9/nrel
vmyQIEFyxxEKyYmks5hNAAAAgIt07dpVUFUrJEiQIEFyLUVFRYmqWuUCDwAA4O0gqhpFS9No
aTotzSDSTFqKpqVZtDSbSN/S0hxamkukGFr6jpZiaWkekebT0gJaWkikRbQUR0vxtLSYSEto
aSktLSPSclpaQUsraWkVkVbT0hpaWktL64j0PS2tp6UNRNpIS5to6QdaSiDSZlraQktbibSN
lhJpyUhLSURKpqXttJRCpB20tJOWdtHSbiLtoaW9tJRKpH20tJ+W0mgpnUgZtHSAljKJdNCF
BKoKqgqqCqoKqgqqCqoKqgqqCqrqflV1aC61a9euoKqgqqCqoKqgqgqq6tBEKqgqqCqoKqgq
qGqVq+rK7RazybJnuVtVdd1ek8Vs2r/WFVVdk2Y2WY5uWeJGVf0+w2yyHEtc6R5V3ZJusphN
BxJAVUFVQVWrXlV1Op1OhyyRwr5Rraq8hppNqSudU9UV+8wmizllbaWr6vpUiqQ6pKrLkw9Y
zCZT8tLY2O/TzSaLedcmVFU37TdZjm3DJPWH/SaL2ZSxacGCBQtWbs+0mE2WtA0LFixYsDIx
x2yypG1YlZJpMZtyUlaAqoKqgqp6naraZRT71wFVXbXbJsxHNs33KlXVdAaArqrUGYCV2w9Y
zKac7csXLFiQkGay8INZm8LyYgpjVVBVUFWvU1WpkpKSqlpVYzdmmU2WI9tTj5gs5vRt8whV
XZUiZnpk04Lp06fP35RlNlmO/LBwdYrFnLJvj3TeIWXtzJkzV0t3SViEqiovpnYEVV27Q/zy
6OZ4VFW/TxW3zzbGz5kzZ873OyXb24aryJdbl67fZTGbLPvWxsTEbNhnsphN6Ru++27pVpPZ
ZDm2ddmGXRbzrk0bdlnMJsv+7zftl5Zq96Z58+Zt3C1+g80ArEg0CePTDRlmU86xTIt5d4Kg
sJk7Vy1c+MMefgArfMjKzOHzyTKuXrRo0aJFvJja4VV17Y5M+zc5O1bHx6/elWWymPduXbx4
8Za9FrMpZ+eaxYvX7M4yWbKS1y1Zsi1DzCF311pQVVBVUFVN5lVZkqpWVedtTreYTVmbvxM+
bIlFVHXepiyzKWvLvOnTp/PymrVlnk1V07PMJos5ZQ02Vl34Q7bZlL11/syZM6PX7LCYTdnb
FoiaumaHxWyy7F2FjFUXJWSbTdmJi2bPns3La3biIrukLk7MsJhN2Ylx4lh18ZZsVF5NxnhB
Uo9uWTJ3bkzM4u375FX1gIkfmdpUFR+rLt9mMptMycvm2eTVtH25RFbXC5OtKxNzzJk7NiXm
mDN3rFy+45jJYt6TsJBUVePqRYs2p/ECumhRwh6L2WRJ34SMVW1fxsfH819mbo5fuyPTYs7c
vXbxup2ZFrPJkv7D4rXJuWZT7s4163YetJhNuTvXwFgVVBVU1aNU9butR0wWc/rWWPugddN8
iarO35KOZWrZs1xQVXPKGtoMwMKtGfgue1faRXWt5Krfrqpx24hdUldjqiodqC4xEtvvW8vr
Ztr3khkAGVU179rIzwAwVHVF8gHcxP71xNTq7oRNuy3m3QkLNmSYTRmbNmTwSkqqatrGRRJV
tX1AZgDsShofHx+/ea+gsJv3WsymzC1rdmeZMtP3WrKS123hv1nCq6owUN25BlQVVBVU1TNm
AGz3qaSkrsRVVRir2pN9BoCtqsJYlUgyqiqMVanzquskl/apa3hVFcaqtnlVx1T12NZlKlRV
GKsS86q2qdXMjLRMy7HElQuW7zhmyknbnWOfVNVKVeM3ZZpNOTuTM82Zu9f+kGnOzEzPtJj3
buMHqFv2im7JSABVBVUFVa36u1X8faqszd/x/woj0z3LxRkAQXZTVqtWVdukaspamqou4gV0
20JkBkCYVN3xvfzdqvjN2WaTJXWNbVJ153rp3SrWDMDRrUsdV1XbpOruTaz1qisShanStA3i
PSt+UlVJVVfzKwR2rFKcAYiPj9/Kz8BmJa/jZ1TNwqSqmNYl54KqgqqCqmqnqtJRpqOquizV
bLv859erzuMv7bevlt6tEq73BSTzqnZVnbFwq32iIGWtbWpVvGyXzqtGLzAeRYbGwt2quM3I
LsS8qsDRLUskU6v2703GeMrdqpjF21Fbsqoau1y86t+9yTa1KppA5lVtU6u29VULNgkqnLBQ
WVUXLVq5KwspGONuVXx8fLw4o7p4Ma+w/FyqdAbAkpX8PcwAgKqCqmo0ryqDC08BwLNV8GwV
qCqoKqgqqCqoKqgqqCqoqnOqSpVEagJVBVUFVQVVBVVVUNWuDiZQVVBVUFVQVVBVOVV1LoGq
gqqCqoKqgqq6U1VVTs0CAAAALBBV/UervgKtRWq07lejjYS2dkJI3hwxdcfu1LSMYz/mbv8j
d+qFI5+dODB7f1ragYOmyd8taf760BovD6jJEyjhlYE8tXg62BlUq8OgWh0lvMoTKtAJ5bXB
UmpL6RwmpU4XO0PqdEXw68YzVOB1CYahfoZwke4oQcNEegjU7TGsbo9P6gaj9Pykbs9P6vUc
Xq/n8HpvoPQaXq9XRH07vSW8OaL+myMa2HlLSmSDtyW8Y+fTBu982uBdlPc+bfDeZzwN30f5
4As7jT74otGHEvqMtNO4z8jGH9kZ1fijUY0/FvD/eJR/X57RAv1QQsaI9EcZ8CXCwC+bCIxt
MggldGzT0LFNQ8cJDJYQNq5Z2FciQ0QeGPq19N9mQ8bZaTpkXNMhY1G+5GkiMEYgjGd0k7DR
/iKjUEZK+ALlM/+wz/wH2/lUSuPBkSgjeBoJRIiERjQKHd4odHhDgU9QhjUMHdZAJBxlqMAg
niEoYSiD7dQfFIoyqP5AgXoDB9UbOBBlQL2BA+qK9EcJ8bMzIMRvQD+UvhI+RvkIpY/fgD5+
/fv49e9Tp3+fOv0/RPmAp7bA+yjv1e7/Xi2Bd2uFSHkH5W2Ut1DeFOj3Zs1+b2qpqv6vhY2O
js84cNhkMl3+cebdnMA7GQ9W7G5Uvtv/Qkqbw3vnHzx6avm6H1r3GQmqCqoKqgqqCqqqoKod
Bn6zbP2WjANHTp44dOvcpL9Odak40r4s/dlbOx+6sdW/bGvDa9ua5e4cdfDoydR9B0JGT2vY
KRRUFVQVVBVUFVSVoqr/Do74eu6KrGzT4cPZv/ycce/SbO5c+B3zoApTz7K0lrdSHi3Z3LB4
Q4OSdY2K1zf4cUvvjLSUg8dOLVy+NrDvSFBVUFVQVVBVUFVRVZ9849PIafFHTcdPnjp98mTu
1bwD1uINf+UvvH9h9l3LF7dzPyzP7Fi6U1+yuWnxunrXV9e/vrzRjZX1Lqx7KmvXtINHc9Iy
jnwVPb/Nh5/XegVUFVQVVBVUtRqr6oOvh7/zeXTsmkTL2d9+O3/p9OnTF89n37uZZS0//HfJ
gb+uJt2/uPjuuQl3ToWWH+5euuf5G9seKl7f6PrK+leX1LsS1/D6woZXlzY6vf71Q3tXHMr+
cV/64RnzlvYe9vXjPYfV6gCqCqoKqgqqWj1UtV7gwNAJC2av2Lpt7+HzFy8XlVSc//3yubOn
L/6yu7xwu7Xi0P/dPve/O3n/Kzv91/W99/NX3/t1+h3zsIqjvcpSW900PlayoUnR6sbXFje4
sqBeYWyDP+c2uh5bPy+++emNb2ftXZh55OihrFPJO/d9G7dq2Dez3ho+vmGnAaCqoKqgqqCq
vqyq74+cff/+/StXS3797feLF07k/7L50qmZdy7O+L8/5/59fdvft078786l/90t+Lvsp7+u
p/5dsPp/F6L+/mnIX9nBXNoL91Mevr25UfHaJteX+V9Z0PDPmPqXZ9e7HN3g8sxGV7+tf3l+
M8uyl88kR+akLsjYn5RtMmWbTO3eGgSqCqoKqgqq6suq+uWclTdulp3JmlT8Y+87liDuzOt/
/fLR/fNjufzFf11L+ftm9t9llr/Lfv77xrG/ryUX/rz6VEZs1vaxGesG7lwYvDX65e3Tnipc
0aR4edOrcf6FsY0vf9uwYEaDgmn186c0yJ/c8M+ohldmNiic17xglT5n2+fmn3/tETIcVBVU
FVQVVNWXVXXmkk1FxSU3f3qLMz9+1/zynZ963z075N75Cffz4v4q3Pp30b6/SzL/Kkr760ry
X/krD6ZtXb1uy7yFyyZHffv5qPEDhnwWOmTE0Vn/urG80dW4JlfmNymc2+TPWf4F0xrlT2yQ
93XdS+PqXhxb/9JXja/PbJoTH3w059Q7YZ+BqoKqgqqCqvqyqsau2vpn4eWSU93v/fjU7VPt
7/zY8+7PYfd+nXD/4nzu8vdc4Rbuz4T7Bd/fv7iEOz8rdfvKRXFLo6Ojx44dO3To0A8/7DNo
UGja1EeLl9S/utD/SmyTwrlN/5zVtGBG0/zJjS993eDiqDoXRtS8MNzvz3H+R2Z3TT+UFRIx
BlQVVBVUFVTVl1V13qotf/z+S3Fu4N1TT93OfenOiaC7P4Xd/eWbexdm3/9j4f0/Ftw7P/fe
r9Pvnplw7/Sn2zfNnTlr7jfffBMREdG3b9/eb77Vr+/H6ZP+WRJX7+q8RoVzG/852//P6KYF
M5oVTG2WN97/4qgGF4bV/i2s9uUvGh+c1ik141D/EaCqoKqgqqCqPq2q361I+OWcuTi3/b2T
T1VkPXfb1OXOj/3vWL64e3b83bMT7lq+vHM68s7JobdzB9w9+vbWlePHjJs4fPjwvn379u7d
29A96P333smc6F+y0O9qTP3C2Q3/jG50ebp/QVSz/MkP5H3T7OIo/wvD6v0W6lfwmf+hqFf3
pmXCWBVUFVQVVNXHVXXu8k1nLCeKc9vfPf5UxZEWFUc73D7+3u1Tg++Yh985NeR2Tp+Ko70q
DgaVp3e5k9p6w/xPwsIjP/roo969e3fv3r3Ta1169Qw6OK5+8ezaf071K5hQP/+rhnlf+l8a
0+zSqAcufvHAHyOaXQhreH5Q3YLP/A9N7bg37UDo51+DqoKqgqqCqvqyqs5ZutHy8/Hi3PZ3
c/UVh5+tOPxKRVavitwPeT0tz+hQlvpS6e5nS3c8VW58eMWMDz/4aOAbb7wRGBj4zDPP/POh
h59v8XTm8LrXvqld8GWd/DF180Y1yBvZ6NLIJpdGPnDxiwf++PSB34f5XwhrcPmLpkemvZqa
nhn6+VegqqCqoKqgqr6sqtFx6346nVtyPPCuSV9xsEX5oQ4VR9+oyHq74nBweXr7sl0Bt5If
upX4wM0tTcoT/OZ92fXF1h0eeeQRPz+/mjVr6nQ1ng749+ERftcm1r48rnbBmDr5o+rmjWp4
aZT/pVEP2IerfwzzLxz9wJEZndMyjwyIHAeqCqoKqgqq6suqOiFmhfnH3OLjr97N/k95Zovy
g69UHOlZcfTNiszXy/Y+dyv5nze3NriR4FeypnZZXI2vPnhKp6tbs2bN2rVr+/n51alb/8Vn
Ao5G1rk2sdblr2oXjPXL/7Je/phGeWOa5H35QN6Y5pdGN7/0+QMXI5tdGds861vDwWOmkBFf
gqqCqoKqgqr6sqp+Mmlebm7u5WPd7mUHlB94pvxAYMXh4IrDvSsyupbtfubW9gdKNta/vqjO
lWm1bkb9Y/y7Af/wa8xLaqNGjfybNe/Y6uncz2pfm1T78ni/y+PrXf66YcFXjQu+apo/rnnB
Vw/mj3sof8w/L41sfmX8Q0fnvX0s99S7YZ+DqoKqgqqCqvqyqn7w+YyjWcfPH+x1P/uJ8oyn
yw+0rzjco+JQr4oDnUt3P12ytumV6HqFk2sXTql1a/o/prz/RM16TerUqdOoUaPmzZs//K/H
gwJbmEfVvj61XuGUBoWTGxVO8r88senlCc0vT3joz4mPXJ74aMHXj+SPe/jqtH8dW9o/5+TP
3fsOA1UFVQVVBVX1ZVXtEDLu0JHj5rR+nOmJ8vSny9PbVBzqXn7kjfK014pXP3VlZtPCqHqF
U2sXTq5VOu0f0z54vFaDZvXr12/evPljjz2m/+9zb3d58exYv6LpDa9M978yo+mV6Q9cmf7P
K9MfKZz+WOH0x/+c9vifUx67POnf1759/GTCyBOnz7V/sz9DVRdt4zgrl9XX+1R1qZHjrFxO
iFtUdXkSx1m53AE+oqrrkjnOyp0Mdbuqfr+d46zcqTBfUdX2xjwrx1kvbW8Pqur5qvpUrxGH
j57M2jv6nuk/5fufKtvfsvzQ62XpPUvWv3Zt3lNXopsWRtUrnFK7cHKt0qh/fPvho/X8H2zS
pMmjjz769NNPt2wT2Deo5a/f1Cua1fTa7AeuzXnw+txHrsU8dm3uE1fnBlydo7/y7X8KZz5Z
OOPJokVP/bhrRu6pM//t9qH7VLVvGpc42VVVDcngEqOUVTXkAGecDqoKqlopqhqXY+XyZo1f
msRx1qylUlUdkMUlxYGqepiqPtglbP+BrKP748qyninfry/b90Lpns4lG3sWr+x8fcF/r0Y3
u8Kr6qRapVH/iO/3oP8/H2vevHlAQEDLli07dn79kzdb/TGlUXHMP4tiHyla+O/iuICiOH3R
oqevL/rvtYUtrs3/79UY/dXYp6+vfvHIroUHj5iav/y2e1R14vTznJVzUVUnz+AzUVDVKTMu
cFbOrqpunQHwMVWtxBmAiann8lI7+oaq0mcApkRf4qwcqKrnqWq9wAGbtu04Ydpdcqh9RerT
N5NbFK99tXhtUPGqztcXtLga3fzK1PqFk+sUTqp1a+o/Vg9s3vzRJx9++OEWLVoEBga+3qP3
yPdb589sUrLgX8XxTxYve6pkxTMlK54rXvF80YoXipa/eH3x89cWtShe+vyl9a/s37PZmLzT
r827zqjqxCwrx9m4NH0gpqqCpAqcT2rVJaxOl7BWq/PsXyZOsavq4kSOs3KmkMHJZ4Vf82aE
DfUzTJohzeRCcqvu4X7TTBK7eTOGDvMLEiTVttn21pKxasgBzspx1syldlXtn8l/s4xX1Tbr
8+37GqNZqjot+ndhm6TZuKq22yTmkPQtS1VnRv9hL2T+rC9EVW2fUGDf/VxCtE1VVydxnJU7
MWj07nPCrwWzR/OquiaZ/2mM5KcvRVUN3CpmmDzfJqnzT1o5znpxT2D/Mf7958y+yFk5Lnkh
Zaz6SuJlsTyJc22qKow0B49PtRm9/O0EUlXXCwPSiam/2DabM9E+Vr08Z6JtXnXxSUk7Xv52
Iqmqa/mCDY63b3ki1K6q8SckuxfMnmhT1fjjku+Ph1JUdWUyx1m53NC4XNtmuYMEVV2eLPzL
qyrf0DmDaKoqXP7zjR7Hq6ogqQKXktuFLkniOCuXl5TFb5wX/c3QBoOGtEuU7LsIVLWy3gXw
5fQFx49nXzn4dsWO54pXPlu0vH3x2teLV3W5vuj5q7MevBLVoHByncKJtW5NrbE5rNkjj+sf
e+zfL730UufOnd9464NvPm5VOPfBG0sCSlY+U7L2hRvrW97Y0OrGhjYl37cpWdu6aFXL6yte
LF3f8uSGd3KO//jNtDm1Avs5rKoDjGc4SQfiOCuX3VdJVfulY7twZ1ZPlKgqyvnkVqSqDrHL
rh1TiKyq1p2Rw3/ZRlDVZUaOs3J5M4dLFFbC2Q1RhKqKkipBUNUBh4gcNs0gVFUqqcIBP/D9
zxp+8MXAw0TOR1ZLVBXl4u6XRVXFftoT2He0f9/RoUfxn85tncMLa+gxzspxyQvG+C84aeU4
67F15AzA4Cwi56zvJaqKcim1A11VUfJSO2J3qybapdnOycF0VcUs7gkMG+0/cTex+4nQsJGU
7y/tDKSrKrbZjpcdUdWBhJfOGqewVVXsqwMGDR1A7ps4EVS1MlT1lY9HZx425SR/VpHUpmjZ
s0VLWxaveq14VZfri166OvvhK1ENCyfVKZxY+1ZUzcShTf/15NNPPvlkmzZtDAbD2x/0m9Sv
5fWFj91c1eLm+pdu/tDm1tb2N7cF3twaeHNz4I1N7Yu/b128rnW5se2Peyf+cj6/W5+h7Des
qJwBiNvGcfhwlZwBGJR0hpdX4dqfV9LsEImqnl0zye/1oX5TTYJcKswALE3kOGG4is8ASOdV
p868wFm5vJmfDK/Xc3i9mbzIprR5Y3i94SlnOc76e0pbYQZgOb/XAExVR+w4y3FWLj86ckSD
t0Y0mJ0rquqnO85ynPX3He2EGYCVwjAWU9XPd561K+n7n/FKevaHmQ1H7jrLcVauYNbILxp9
8EWjUbt4UUiKEVX13OZZjfuMbBzLD81ODJKo6rkts/0/HuU/T/gptO9o/y/3nOMVVpgBEIZ7
ocIMwNpkjrNePJl8kbNyJ0PJedWv957jOCt3+dtvxjYZNLbJN/y/XHKcqKrnjDFNB49rGnfK
ynFW7tRghqqeS/rugaFfN1ssbBYmtwaAz7mAH66SqnouaU6TsNFNwoR/k+OxGQDeGwWzJ44U
BrCXdgXKzQAIqnrOOKPx4MjGg1cI2capVtXxKWc5/iYVf/m/NIlXTMoMgKCqZ42ThBmAb5LP
cpz1UlI74fJ/cRLHWbnsAaCqlaCqDV7uu2df5sHUDcWJHUpWPVe05Lni5YHFKzsXxbe+9u1j
V6IaF06qWzipzs2o2tvDmzz476f+/cR/WrdtbwgKfqfPoK8/frFk2X9ubWh5a3O7W8YOpdtf
LU3pdCu5001jxxtbXi7Z1O5mQvvrO147uG9d7onTD778lguqyuspj5KqTs4mhnuclcubMdiu
qnkzBvMzqrYJAaaqLkmU5qCgqp+0/j7PynFnv4+q11MYnBpnDq/3hk1hcfKjI1BVnZVr5Tjr
weWUedXZufQcPkNUtd0P+VaOsx5eic+rxhy3cpz18Gr7vOqgI5yVnwcQVLVg1mh+XnV1Mq6q
BbPH8POqwoRAaN/RNoXFKJg9TphXDdwmTA4kL6DdrVp4Uhic2mZU+aHrOeNcm6pe/nY8P6Nq
mxCgq+rlORP5eVXbhABdVaXjX5aqnhxsm1cNzeZF9ltUT211nEiOVQtmT2TPANjmVQfx2Rqn
q1XVOGq3yYsez1LVvOjxtnnVRSbavpeivwFVrZS3AY6eGnP8xPGL298rXf9C0ZIWRUtaFS/v
WBTf7tqcJ69Ma1I4uV7hJL/iKX4/jqrXo13Aq22f69m53fu9unz8Xq9F4f+9seb50s3tSpM6
lu7sXLa7a9merqW7utza/urNba/c2BJ4Z0eHU4kfZ+eeilm4tFa7Ps6oqvIMgEpV5RKnSuZV
uympKn0GQEFV6/ZcauQ464WUNj35y/+c/m/IqKptdtV5VeWS5milqicG9WGp6olBH6tUVdvs
an9hEsDKcdZja51S1VODQ9Wo6qmwIbKq6sAMAE1VWTMAYSP9J+5Cf8qfPbFyVJVLinNaVaWz
q6Cq7lTVR14LOZJ96uj26eVbWxcve7Yo/rmiJe2K4ttd/+7pq9ObX5lUv3Ci35VJda9Pqf/r
Vw2Pj/E/9VXTkxP+aZr82O8Ln7m5sW1pYoeynZ3LUruVpxnK9htK93a9ldLpZuIrN40dylI7
Ze+LPf/75Vfeln/HKlNVX1p5ycpxZ1ZNqPXa4FoDeYUlVTWsb5pEVfkZAC67H2UNgIyqhodk
iKraam2elePOrp3s1z3cb+j2s6KqDuPvSrFWVoVkclYub+b3OVaOO7s+SlgAwM8AcDkD5NcA
oDMA7Tby96YkMwBc7gD5NQDoDEB7u8jSZwAKZo36wklV5WcAuBOh1DUAwnTqWmGCdaHKGYDL
344fq62qdki6bOW4c0lzmw4Z23Qib4U5r0rOAAQmFVg57lzSbP+wUTaFtamqZAEAr8LJ8Y7O
AHBJcSMaDR7R3sg3NGMGgMsZSHsKgJ82ZaoqPwPAZQ+ANQBVoqo1W3/83eI1pmPp+Yndb619
sWhxi6K4F4sWt70+79mrMx+5MqVR4aT6VybVuzq5YemMxifGP74uosWOr1+6HNfi9saWtzYH
liZ3Kt/brTy9e/mBHuXp3UtTu97a0elmUsfbezr9vvvtw4cP7klNq9f6bRWqinNm5XheVbGr
GGIGQFBVK8e8W2U9n9RKnapaOc56ITlkbR5hl58BEFTVyhF3q/iVVZ9st68u4O9T8ZB3q6y/
p7R17W6V9Y+d7ZTvVuXP+kLN3SoHVZV2t8p6cU9gyBj/EP6+f8Hsr8b4f8WLLz+16tDdKi1V
FYU5r4pwaU9gmKCq2O7ivCrqZ8ZYFcuWv1s1bfYl4id1d6usl7a3k6iqlUPWAIiqSrtbZb2U
1A5UtXJUtUabfk90CTmWYz6WNLViS+viZc8VxbUoWvTS9fkvXJv9+JWoZlcmNbw6sUHptIYr
Bz3x/Ett/vtC206G3sP6vfHbkla3kzqW7exSvr97+YEe5Zk9yjO6l+7tejPl1VvbX63I6Hxk
5+T8P4t7D4ys9YqasSpFVWt1CrUr5plVE15adcnKcYmTiKcAxKv+7H5dwupgwno+qZWKsapf
lP2iyRTSXRTZs+umtFqXZ+W4xGnD/HoM85tu3ywnhPYUALKgSrJeFRFWu6Q6srIKEdbfUUl1
fWWVg6rq3w8VVkFSxwjLrY6t5RerClMBx9Y5vLJKkxmAIeMGZ9tMJM3lRXb7YgdWVoWKu8/m
RTY5nlxZJTuvSllZNaLxhB32CYSkOLmVVYiwXtre3v4UQJzYXQfQVLXBoCGIsCKSCqrqflWt
0brvrAXLc0yH/0jsXbrupaL4Z4sWPFs0/4Vrc5+6Ou2hq5OaFE9p+MvXzVo/p3/goUdbt27d
o0ePd/oMnDeyc0XSKxV7u5WnB5UfDC7P7JgpWAYAACAASURBVFGWbijd/dqtlI5397/22573
jh7LOnDoaL3WbympKsQBgDgAVRgHAJ9X1egpAHxeFeIAVDNVbdPvsdc+zs49fXhXXKmxQ8nq
lkXxz19f8Pz12GevzXr8WlTz0mn+qZH/euzJ/z7xxBMdO3Z89913Q4d88vng3oU/vHx7n6E8
g1fVoLJ9XUt3vFq2s9OtA93SUuZeuXazW5+hNXlJBVUFVQVVBVWtVqpao23fiK9nZOecOp08
/Lbx1ZJV7YrjXiqe/8L1mP9em/FoybQHznzVvPVz+qeeeT6oe/eBAweO+Hxs9GevX9/yyu19
3cszepQf6FGebijd89rNHa/ey+x6Ysfgn85cSN65p3brd0FVQVVBVUFVq6eq9mvQ7oPUtIPZ
R1Kv7ulTvtVwY9UrxXGtiua/UPSt/tqMR0pn/jOu/5Nt2nfo0fu9ocM/H/vp4PRZrcpSOpfv
616eHlSW3r0steutna/d2d+lIK3X/lTjteslz77+Yc1XBoKqgqp6tqp6YxwAUFUvUdUabfu1
6j0498RPh/csq0j/qCyx9821XUuWtC9e8GLRHH1R9L+vRz+WOvo/0/q1WDC81YEZL17b1LF8
R7eyvYay/d3LUruV7u5cvqdL2SFDRsqsm2X3x0XNrtnuY1BVUFVQVVDVaq2qNdr0HTpmqun4
6VN7Z/x1NKws5eNbm3rdWPFaSVzbonnPFc975taiFiXxz11f1urWxo6lxm6lOwxlu4PK9rxe
urNL6e6u9w53y9n1eeHVm5mHj/m1fJOXVFBVUFVQVVDVaqyqbfvVafPhsrWbDh0+ci5j6v+O
jyxPDS/d1ufm+p43V3UpWdbhxvLAm6s73trQuXRL99LknqU7e5Xu6lm6q3vpbsP9Q91/3t33
199+vXHj1qOvvFUzcACoKqgqqCqoKqhqvxptQ5q9/EH6gcMZGWl/HJ31f5bJtw+NKd8zrNQY
Urr5/VsJb93a/OatbW+VJr9btvOD0t3vl+55tyz17ftHev+W2ud47tH79//u8PbAmoH93amq
cXzAlL5uUFX+qSprxhJQVVBVUFVQVc1UtUbbkGe6h2SbTqTvT/3dFPt/5+fcOxF1+/BXFWlf
lO+LqNg7rHzvkPK9g8v3hZanDSzP6M9lf/zLvoFHD+//n9X6wdCRNdv1rRk4wDtVdUmi/UFV
UFVQVVBVUFUNVbVG25CWvUJzj59KT0//+Wj8/+Ut+uuX2Ls/zrqTG3U7e+Lto19VHB5TcWTk
3exP/zoZ/lPq54cPHygrvzt01ISabT4UJNUrVRVmAEBVQVVBVd2mqjXahrwYPPBYlunI0SxT
5prbF5dZ85f89dvC+2e/u/fTrPuno/62TCg79eWRnTOPn/jxz8KrH4WPrNn6A1FSHVJVLOD/
ALukjp/+m+T7gZiqxiWKP4mq2mq1GD2AfxFAna5DQvhnWNMX21VVeCY1YzGvqq0kz/4nTkNU
lX9iVfhpOqgqqCqoKqiqs6pao23Iox0/3Jq080ezJW1fypmcVaXnl945v/D2LzG3fp5tOTQn
PXXLuV//+PnnM23f6Fuz7Uc1Xx7gjKqGJBLh/rL64pIqPObfV1RVlPNJLTsTEQD4AAKrJ9bp
OsRvaraV46znk1sJqmqLtRo21M8wVAytYsM+DyCGU7H/tG4KqCqoKqgqqKqTqlqjbUjd1u99
On7GqVPmk6dOm7IPHz2460hmSk72wR9PW3797ff5i1f4t36jRvv+NV8e4KSqIjMAtoD/A+zB
VbP6vja41muD+TArZ1ZNsKvqmVUTancOqz1QCP3Xt7PkRQBdkBcB9Os6xK/bxBnnOSFkdTfb
iwDOJ7d6fagQTfV8cithBmBJoi3GivDThe2thBmApcJPoKqgqqCqoKpOq2qNtiE12vZr/vJ7
kV9Hbd+191hWTk7uyYzMw9HfLdR3eqdGy3drvDygBi+pLqnqIiTg/wAhuKo1LU5pXjU+0a6q
rBcBhA7x6zak1Zo8K/96lW7C4DRx6lC/14dKolWhew3B3gko/jQzHFQVVBVUFVTVFVVtF1Kj
Xf8abfvVavluvZa967/Uq86LvWu0+qBG+/68pLqkqowZAO1UlUucIokEeD65lT0k4Osyqsol
TmOpauW8uRpUFVQVVNXnVZWnPYrLqvrSiktWjjuz8ptar4bW6m+76u+EzwDwwVWtaXFyqmp/
EQBjDUBIOmfl8masMVnt7wS0zwBwphByDYD9J1gDAKoKqgqq6l2qisIvAyDvVvEvAmCrKutF
APaVVYPtL6TKmxEmrqwi71ZZLyS3Ytytsl7Y3rrHsLo90JDVoKqgqqCqoKoeoqq1Og7qu992
v972VpVtE9WsrKKoKvVFANL1qsISq4zF2HpVRFhtksqvrEKE9cL2VsJYFVQVVBVUtbqqqhUS
JEiQILmQcFW1mE0AAACAK4CqAgAAaAmoKgAAgJaAqgIAAGgJqCoAAICWgKoCAABoCagqAACA
loCqAgAAaAmoKgAAgJaAqgIAAGgJqCoAAICWgKoCAABoCagqAACAloCqAgAAaAmoKgAAgJaA
qgIAAGgJqCoAAICWgKoCAABoCagqAACAloCqAgAAaAmoKgAAgJaAqgIAAGgJqCoAAICWgKoC
AABoCagqAACAloCqAgAAaAmoKgAAgJaAqgIAAGhJVahqjEGn0+l0uuCYqq+/HMZwvT48xWyy
mKODdQGRRtav3uMHb/G8hk6uVGj9xDOJMeh0On1EghtNsNoO/z462Is6pDoUVNXJPi13MLih
59nNaXsQ2nOLMej0AXjODtmilNDmB/X5uFpN7TxfaWLnXaoaY9AFRXtDvaKDdYZYsyk2yCZn
7igPnyeZM/qNWAYfwj2qKu9rnSFW8zzd0Udt2aZEGChi5JyquuIHF6vpDs+7G69SVXo/8Yp6
uU9VPb/ubsBBVTWG6/lrSNuoJyUiQPhCuqXkNBUZpJNcdUYH63Ti9mJuhljbXpFBOp3OEGsM
1+sNwXp+x4RIvXjdKloUyiD8qtPp9EEGcTRHz5mWD7OOkp+k40TsV8wnFFtkCSV+EK2IXwbH
aFZNG8qeT6G3Hd8WaLYUbyj2B6E1me0otUgegYQhO7hFZnMYYpHzijBeo27PdAVaMLqrlRtF
0pT2a3A1LlLvXrIWckcx3rXEyrLcTvMktUFTKC3IaCn13cnjcUhVbR1R2uFs38QGEQeDMVxv
73AxBtGVEhERe09QtEW6vTFcz3s2xqCzf8A8a7/gwi+NZXPm82GVXDrLQ+ma5K9Un7BrzfyQ
EKlnXAq5Uk3sWJLxPCklSFsQ3mPWndEf7EdOjEGHDZn5Ckqt4GUmDCE5Sy3KNof0elPwKm17
GVcgdqmuVtcodKVT4yJ17pVTVZozUe2zVZbtdoonaaVFuorSgaO+O3k8jqiq9GwjnIr5ERBR
YVYHpX4w244NldtTT3rSD6pyli056zPjkEN8or4WrDKT3na+mrSqqdlRjR8c7Q9m+7FqG8tI
K0gWWMbJ4jaoRfnmMIsSEBtElIHVfDIFU/ys2B8ccpF698awewLVmcy+wXI74Umyx2JdRc2B
o7I7eTwOqip9HE5U3n2qKj0tq1EoBblhlJz1Wc0hp4mqalxN9iHtoqo61B/EXwMiY4gKyqsq
3RBhUUGtTBZzQqTeEGuODlajblWrqqSLHHKvjKrKVEe+CyEQnqQ2qHMHjnx38ngcnQHAp5CC
hYmhhEi9ZOZFjaqquQ4lP0i2SYkIkEzQSE+5qq5w6SWX3CgX80dyxn6l+IReC9agQPiAzgBo
VU16r6VepQq9VjCn6uziYH/gPyNzCAyLeJnZi29wi7LNYTMXHGSwTWjStpdxhXwrO9SrMZlQ
5yIH3IvVQuYopvZP1pYsT7IaVP2Bo6Y7kX7zSJRUlbxSoFyS6HTY2jdVqirNjXHPhPYh1jbx
L960sX0pfxuH0Edayc3iok5p/mIO5K9G2oUP0d0pJSQ/2LIJjtGqmmwhQC/r7LcFhMxVqaoj
/QHrSGQ7Ko6hEEPIoYhYlGkOsTDYpCSSs5wrWM7EBoMqGkVoSundKkUXOeJevBa4B3Bn4l2L
vSXLk/QGVX/gqOlOvqGqAKABCteSgGsuAvd6GKCqgPuBw96tLgL3ehigqgAAAFoCqgoAAKAl
HqaqjoT/iA3SUR67hquhagU0tzv84HVReDwMFWsAJMoVG8R+dMyBlW4sHA04gi2KcsW0G9Cq
JFWSj/vcqG3O8rmxfnX0+8r0T+V4VW5774l/5Kkorlc1BOuli3uJ0E3UdnLOd5osm/C9ZgNV
9cDcPK2baVged6xe8jR3uRnlpwBiIwL4xWKxQbrgCHL9IBGgISIaCR7B3hK9xCACjhjD9cxY
IZTAE1j7MTdAbQmhKKRr/Ui71JLg9YoORlbVSZ5vUcwf639MxyY4XwU0H5pzpBkmONOCyNFI
xi7hf3I8kAe1KSmLUmmxeCRLJqnRYdDgHcyyyUW6If3DWN6Lx2ehhiNRDP5CNj3a7cntfTD+
kcej5tmq6GD7g3fiEnp2gAbkMztAg0z4D7stmVgh0nyks6vkWRGP/oDFMVEZigUrCcMDOkOs
9DkQ20pm1TFQlBzrdBXo+didQ8R2caoFabFL0ILh7lIVyIMoLRGqw8iIxcPqSOL3aPAOetlo
fUnGP1RVlZ+jFJ+pVwr+worCwzowyTqyCuY18Y+8AFVPrPJPTSAnf500yT4ZRW4pbRJKz2D3
Tmxj6UmVmon8BuS/RtUPxTPqxZ9dkWf41ORPrRTVsU5XgbIZOiSROcOpb0EydglWMDXlkVpR
LC3mZGoXYm7PfqBepl1IQ1jJ5fuPfB92KPgL2V4UN/pc/CNvQF0cAOyQoDat4pEsIn++VaGq
0kOaKjGKG7CKrV5VqZ1b+uIK51RV3rFOVwH7oBjZxLkWlIldoqiqrPGpfGldUlXehOToZQqK
UqQb+QOB1ayULupI8Bfye6YbfSj+kTfgeNRq22mEGaAB+UzZUrwYpPYM+SYn/sWDRxD7EtEl
VFw+K6oqPfAEf/2FrWRwKAaKkmOdroI0H4pzaDMATrQgO3YJMgPgUCAPSmmJUB3OqapM8A5G
G1Ei3WgRn0XaRRWCvyjPAPh8/CMvwDlVpQ3y0YAR4md8S+ldKUbYHkVVZcRYkW7J3AAtPOtW
j5Kqkh6QdGgscrBi/oyyUR3rZBXQfCjOwTJ0rgWlxw9eTjwMh/pAHpTSYqE6nByrUoKVUMsm
F+mG4h918VlYXZTpQEoIEtm7Vb4b/8jj8bCnAAAAALwcUFUAAAAtAVUFAADQElBVAAAALXFZ
VZmLORRReH+D2+xqkYOae/fuKzngAvSgPID7qH4d3sE1ACyXOe448TGSqmoq7VQVqYtMto76
CtnS+9aXuNou7joafciTlSNYLloBVfUal3mSqjqWrQN2Jcd/9ema1aem1cRXXlFITVExVjWG
6+Vii2APERLRGeRWepLBMmRDQpB2qSEqVIZpYJdHvXViX9kgJuhYVU3wiBRbaBtLjIF42x1z
CSG7vkI4DFo7stfqKof8YEXMMeGhQGjmmFFgJIs9qbFR5BpR3Es2oAnSskqhYdS72omKKxxl
jgfBYXgAqbLK8CjOV5axu+aRBj0MdapKiS1ChLfQo4/oMJcZkwEjVIeEIO1KS8s/Q02WlpWb
BtZVBkORlE26NF1N8Ag87oa6J8FY9bX3Zv45BXUPz6gI+SEpLVJ316LAiNWhxUZRbkRVAU3s
KIeGUe9qd0XwcSQIjqIH7P1BMTyKw5Vlh5thON/HUDtWVXjWSKZzUzqiNBliyW/kQ0Jgn5mj
ZuwhDXaACaetU/ZlPZoiKZt8qXB4l/KPh5OZOxKWAunc0cHSWIVyuakI+SHmQI/KSHeg+ufK
1XQ/slNRrwCwFpH+pBgaxklXq8vKuUpRjwJ5D1D3JT9QjinVlWWVRMb5vkVVqCqrZ+CwQwoh
PU8p9IZ8bi5aJ/dF+hCtbPKlIogNCoiMCdfjAehkhUmx/A6pqmLID2EbWgSDSlNVNZ2KbBG8
CrKhYZx0tQuqqlgp0mnyHpDfV80x5VBlserIOd+ncEpVmeEtaDMAWKQJyiIk1SEhZMJqUCNZ
2MogF2DCFevywVBYZWOVSuIrhBiDDolDSl5L4rE8ZOtryxMtPzM322fZkB+seCtaRIGhn0qV
OpX8CY8Sc0eumg672l0RfBwJgoN7ICFSTwsFQH5g91tHK2thVJDqfF/COVWVDW+BDvLxSBO0
bYhv2IEVMLtkKAdG76TkxiyzA9apFzXMICb4uB61wlJV6RUAYhEJ6iopFbu+9qIil+3yuZko
ZWN7TCY0qsNRYJgNqqJTMUZDcjF35KrpoKudqDjzBIP2LixbmSAvuAeIt1GxVJV5TDlRWaQk
Cs73Idz2bJWvD/K9D2iR6oyv3yDyKEBVqw3QItWYlIgAlx66ARwB4gAAAABoCagqAACAloCq
AgAAaAmoKgAAgJaAqgIAAGiJ76uql8XTdP5OvWvxatVkSC8b3a4Hud2J544AZTTvb76D76uq
xvE03X1AOpu/k/Fq2Y88UjKkPUnJtusBYUzVP/pZrVBZfdnNXI2P7NNUB1X1KqrqgFdj10vF
CFRV0SGApig9sapt0ElxX34UEx2MPK/Jx/tQigFK5o9nKyIXT5P2yCAe4FKygRCqkllHpwLL
UjzjSKWYW0riXUbI1NReHdlInZjTVFRHO7c73BmQf0UT9nzQeFROOxnzoWIIWrmK45FK2FFW
WUFp2Z6n9ENWW2OZs7u6TDcGzCaLoqpqGnSSEY1UiHRnjzCiIgYokj873KcU7Ik9erGJWJ/2
Dch4skgZnAssK/WMisitYmHkq49Gu5CvKWUGQNY08lR4Jbjdwc5A/qtHoiWhIXhccLK02GpC
0MpXnNrT5CLgMDxGep51dpcMBZiZ07u6unav3ijNAGgbdFInTchYQxyxiu3EiFaH5c/IlmKU
FAjpZ2r/Y22M19GpwLLyhWFWSqn6ioWXP9IUy6lcQje4XWVnIJ1DmtBJ1VYjJyuGoJWvuHr/
yAUkpHlesa0dPZzl2x0wmywq5lXdFnTSToxB55iqovnLnDClgx3ntIa1MV5HpwLLqiwMHXb1
XVdV+XKqqY7mblfZGajOkVFVrZysGIK2clSV9LwGqqr6cANsKN+t0i7oJHUpBq9HtjBl0jZj
XwGh+bNXeEhyw0M60ortgKriZXAusKzUCSoit9oKoFR9YgZATU3FzZT8KRnCVJ7bVXaGGPxf
TFnQaSsXnEyIi0IIWvmKy/Q0lUFpWZ6n9EN6W8tM6CkfbsgZDlCzBgBzmXgJ4FLQSVw7+Ikz
5PqCFQOUGpmUdr0pG9IRL7ZjY1XlMqgKLGtHXeRWi8rqS74JjlFbU2akTswPiBC72e0Odwb0
X/EMR/jHRSdTR6NyIWhlKy7X04gqy3iM5nlqwFxaW7MyV9nfQFVFPGxllQ9cX/hAFTwE8CTg
nYCqQhU8FfAk4J14mKoCAAB4OaCqAAAAWgKqCgAAoCWgqgAAAFoCqgoAAKAloKoAAABaAqoK
AACgJaCqAAAAWgKqCgAAoCWgqgAAAFoCqgoAAKAloKoAAABaAqoKAACgJaCqAAAAWgKqCgAA
oCWgqgAAAFoCqgoAAKAloKoAAABaAqoKAACgJR6uqjJveyaA1xwBAOABVLWqIm8nxgU0Ngh9
rz1LNLE3KgMAAFQdHqCq0vePy4xMFUUTVBUAAA+gklQ1ipYsZkIK7f+KY9iASKPJYk6ItP2v
j0hIiQjQSX9Fx6rir5KcqQWABAmSbyer1erLqmolEkVVzdHBOkOs8JfQWXIoGmPQBUUjqmoM
19v2jQ2yZWI2kdYhQYLk26laqCrlJ6qqopOtOl4libkCcUCKjFWjg+27AABQjQFVlfxLHZYi
kwP8tIAJH6WKe4G2AkB1B1TVJFlHRVtQZb+0l+ySEhGAj1WN4cERCRazyWJOiNTbxBcAgOpH
NVZV8UpfIoLYNb7ZZDGbYoOEu1X8B51Opw8yEGNVfpQqbFnl7QoAQFVRXVUVAADAPYCqAgAA
aAmoKgAAgJaAqgIAAGgJqCoAAICWgKoCAABoRteuXUFVAQAAFFD/rCqoqpcAYbF8iRgDNf4k
4MmolJFqr6qSBf+Vum6f9QCC/C4+H8i1ymsnH0/HlfLjD/LBo3feB6gqYoZRPWnnjg4Oiq68
yuPhWlQEDahyxakOuM/JTrQ44GGAqiJm2KpKdG4suKoxXK8PjwzS6YRwVvbtbfvSthcPHtvo
UshBagUZuQg/4cFbzfIhspCsqKFdbTlU3sgIL4ZD/hTrJT77GxxDRryVrazeEKzndxQC4wpX
2UQmcoF0JY8jR9qeUSbyoVpXDNEbHiyzu/CDGHRC7DkydoFKAVQVMcOqnvBQvzhKJYKrou8I
EF+7wgdXpW5Pqio1XIt9sxgD5SAR85cczDKqygjtKmxQaaqKF8NBfwr1SojUSz1GzUSpsjEG
nf2DEKIBC5srG0iXLK2YD9oilGZVCtFLHxGLOadEBAjeEH0laxeoFEgZieLj3xNfVmtVFeBv
Hdj6sSRJR0+2LYOiLWZTbJBt5CWzvXxoQeq4gzoyJXOjHKIeEn4QLYYT/iQ9Rol4y66srD7i
JcGzpe0l05osVVUTolcm2qTZdnJi7QKqWkVgMmKP+Y9tBqpqB7sCtYF/kxCpN8Sao4NZ9zTU
q6p4qSjVIFrwVjI35jHmYdrqnD9JVaWLCK2yMqqqUBLa7qSfpRcWMqqqKJqOqqq8XaBSkMoI
9jIV6WbVW1WN4Xr7tb9kxIdcrRM9OCUiIDjIYFswQNteOkmq5hiLMZDDGWFfyf00PJwrYYUZ
2rVyZwDQYjjoT+YMAJ4JXlm7Q1iqSgmbqyKQLv2aAD3zkXvJ52ymCShaHnEGADlfEnaBysUu
I9S3VNk3q96qKrmHoHB3SLqX9PAgt5fcSEECsGKm0S9TIgL4AuDBW83iwkYsN9yKTGjXylRV
shgO+RPRKSGhd6t0OmpllVWVNutCm4cRAumSbWf/bGsRNB/COivniASGqtLvViGzJUSeQGUi
lRHq+n/+p2quqgDgArZJ4epit9oDawAQM6CqgFbYrycqef66quwCdkBVETOgqgAAuAioKmIG
VBUAABeh3qSiJlDVyoF2X9hO5dzVhYgevoR8a6pcSaa4lwdSRd24q4OpmqtqQqRe6aaqyt5G
3ne2IT5E5Er+6qGUxLY0R70tdnU0xisOZnfUmlzJoNYPSq2pUlWl6wrwtVwaVUrGnJrcPKYb
8xqi/m/1VlVjuF5vCNbLrj1ytD3cvb0TGWILwqqkVIAILbKPQ0oh35oqVDUlIkB64ys2iPbU
hqPEGCSP2CLHFMWcmmp6Ujd2SFirtaqmRAToIxJig2jjBcmidPH0S1tUKIYLkdueEG65FZSk
yssGHJEWg4wSItlXstoRyZAI7EJmQl9QiQcfkbjOHhmEEjVGaj1CXHLPDmVC9Z73xtMjI/sg
3Qb3GOJPWmvS+gNr5azNHM2l6GpoVjgbZnQbZv40c4xie1A3lgBjVdwMu3q2xrY/EUhd+I1c
gLBDYNC3pz1Rg2YleSaHtbGagCOSDeQXw1OeX5JgXw7JfjyJUncsRgxWHjxz1DpZBWZIFOyA
9F5VJSP7sC/S8Ugr1KahRvlhx2ShDvrIAojWJeFssH+pFVRjzvO7MQqMVREzclGrZeZrZBrV
3lEUt5eeXVnBACVdSnljarbkBvLdkS5SxPCHtYtM3RULTFqn5i/vEJ/BHtmH0ruUPCbjKJZL
WQ1EZot0BizkgmK4CSIsN8uch3djCTBWxc2wqie5XtDpqE8Tuq6qrFMfVUTUbEzN1sXuKB33
qdnFIVUlM1evquyBgw8hidUripoKj8k4SlFVqe8jEDWaGnNApbZS33TANifzTZV3YxQYqyJm
ZOIAiJcP/ODfSAQusXvf1pOYITCQowLfnoCInCK3sXLAEfoFF7Nf0q7BWbU2si+dVKoqnjlj
BgDfRWk5mvfOABjJyD60VmPF6MFbk9UfyD4mbsO8W0WzjoSziXEmlA/tbpXHd2MJMFbFzTBj
VtHO3kTgEr4TSAaz0gtSRpPQtiem9rHIKWba9QvSw4RECThC9AYkSgirX0oypAR2oWaiou7k
v5TMpdYjWKqq6BCvVVVqZB9Jt8E9pmYQR+0PZB+TgFyrSfSFaC8snA0zlA/l4k/GnEyxPaQb
o8BYFTHjAU8BAADgxcBYFTcDqgoAgIvAWBUxA6oKAIArwFgVNwOqCgCAi8BYFTGjWfWqy1of
AAAQYKyKm5GtniPRVRxVVad3BADAw4CxKmJGrnrGcAeiqzgtjqCqAODNwFgVNyNTPceiqwQZ
9HIRQNTEW4mWrFumPoUCAIAnAmNVxAy7eg5GVzFSI4A4FG9FEvcBXusGAF4CjFVxM8zqiWLn
VHQV9Y8V489TG2IVQ1kDAOBJwFgVMcOqnqvRVZxUVV5PyQibAAB4KDBWxc0wqud4dBXZCCDq
4q3Yvqe+ggIAAE8FxqqIGXr1nIiuIg1RQYnvoC7eitnEDI0OAIBHAmNV3IzHPVslG3IcAAAP
BMaqiBlPU1W4TwUA3gWMVXEznqaqAAB4HTBWRcyAqgIA4AowVsXNgKoCAOAiMFZFzICqAgDg
CjBWxc2AqgIA4CIwVkXMgKoCAOAKMFbFzYCqAgDgIjBWRcyAqgIA4AowVsXNgKoCAOAiMFZF
zICqAgDgCjBWxc2AqgIA4CIwVkXMgKoCAOAKMFbFzYCqAgDgIjBWRcyAqgIA4AowVsXNgKoC
AOAiMFZFzICqVl9iDMhrxj0X8VU9npqhpzoff6mH0vdOAWNV3Ay9epo63cuo8roz3pOoQfnx
19l6x5tsXA1kTjiksiOjUxqU9t5iB2vhgGlyX607OYxVETOgqh6H+5xPvvW2yivr1f50ugBO
OF/bUyyMVd1qRq2qiu/1wwc44juuMhoc+AAAEJBJREFU8TcAimfjyCCdjn9ztdiZbK+npm1P
vgFbyIEsaowhOMZkMUcHB0VrUyRkQKETL9MID+BWEO8ZgvX8jgmResmFHulG/Bthe/EFi2Jp
qflQrdNqLc05IjxYZnfiBY6i82Xs0hoCbw6s80gcJTqZbo7hc2bL2n0lrXUCsxvL9TqJ20Vk
+wZSC6JBJftK3IhkSHgMrYXYUvjRhO+IjVXJ5mMf1w4BY1XEjDpVtSkg+ZOkaWODDLHklsZw
vaRTihdfMQZdUDQlZ2r/Zkw/iS/Ext997UKRhAKg7+6mZyK1gnqP76MxBp39g3A4YW6kORb7
IC2tmI9EXumqKpszdUehmsTLxkVfydo1J0TqdfqIBLn3OQqNTjiK/0k4yUnNyftctmXtxUBO
k+xuLNPr8Bqp6RuSDVgtK37AMqR5jNZexNFE7IgcU2TzsR3iCDBWxc2oUlXpKc4+ihG7lOQb
ckssK1vzxwbZzqUy27Nmhcwmi9mUEhGgj0hA+rRWRSKNUjyAWqF6j6aPeElIx5J7yTiEpary
OVN3JDegNofM7vbjXMZ7LC3jpxpjsALI+lxN58E+sLqxQ05W7Bus7WU6BvOKQUecGyRgXZfc
UZo/48xBd4iDwFgVMaNWVRXOY7buzhw62b9JiNQbYs3Rway+olpVLayxqiZFUusBmrY6dPDI
SBvrYJAOnWRUVVE0HVVVebussap0QCrnVZqqyvtcTeehfiBxUVXlm9VRVaV6jF54outiOyqq
qrPjUykwVsXNqJ4BYFyhGMODhYmehEh9QKSR2JJouZSIgOAgg216iLa9TaRSIgJ0im1PTue5
WCQj9aKMkglqRVJy5lFEupHmWCwfyuEtuX2PDMSk1mVzxpwgfk+bAcCEj6qP1IYgDAkNSm0I
Xotxc/I+l21Z0jOy3Viu11FOwwp9g1BJ+Y6BZkj1GH3oQO26RC2IbmPLVrMVZjBWRcwwVZW8
eKRexElm2cWmJa9B8MyxaVAkZ/uMu/R2jSNnVNeKhByNQkLvSOjsPZKwIn/wMK7sCMfGBjGq
b/9sW+2I5kNYZ+XM37ehqKp0L2LSgGpXBbG2ez622zWy3Yy1AdPnjJaVfEZqzSi/XK+jdxh2
3yC2RxpUqWMEx9A9JtaCfTThO2InZlvzISVxvEExYKyKm4GnALwb8jaFF9nV6AoUqHJgrIqY
AVX1RuxDElfuMFS9XVBVnwDGqrgZUFUAAFwExqqIGVBVAABcAcaquBml6nlAHArNkQ9sobhQ
hopXXMx6eDgVr/ChJ+CODuwaMFZFzMhXTzkORZUcCZIbl+SaEiWUAluo7JTSu+H4CiSNKiVj
Tk1u+DpHFyJ6OF+7hEi90s1lp61oUDzX2stpo57QgbUDxqq4GS+cAZAGW7KtjnRIKeTvtKjo
lCkRATpkOQttRbqjCOs9sQoyzKmppvyCNpW+cv1UoTcE62WfMXddHL1skFv1HVhzYKyKmGFW
Tzyd2k+MtIghtgajhxqR7KWTLi/Hc3YoeAr5iCoSe0I2f1pgC0pN5Zfy2Zb90zouGUkE8wwz
Jgszf5o5RrHdFdGDsrwRi70itq8U/qni2CDaiEyyAF5qhR1Hhoj2QuYQES1ZTk+EOmTHf0Hb
kR4Zhx64RLFBPbEDawyMVXEzjOpRA0bQIoaIv9JCjdj3MtvCZ6AdjojfgcB6IFVY34PF6aBe
pJP54yMjVngXdiQR6mCBLIBoXeIZlqNksqKPTSo3ogfhE0rsFUpQFdv5gBLohLkSnhVHhmKR
Osi1F56yolZF/BdWP6e2rEzP9+QO7AZgrIqYUfFslQ555hr7IGlCymATaU7JfJD0FMpocnbw
FEmfs3dN7HCVyZ8sP7Wm1OOf+i+ZLTJAwDzDjsmCeUnRHKuBqNVkNhwjT8VdjLKxV/BvaFOB
MiV01CLezQyx7FsC9PgvKv1G6VfMBvXcDqw1MFbFzaiLA6Dy4CR6GKmqMYwAELTiyQZPsedJ
PqYpm78acVHolLQo+tiInlJ3NdpKjc/PNifzjaOqSi25a6oquZLV6aiPybpFVXndpGqZurEq
q+5y/YreoJ7agbUHxqqIGfYMACNgBLVRyVAjZHMS4TOcDp6il34W+yL+IDk9f7wirJqSoSjE
bZh3q2jWEc/EMBxlRg8nFNrdqsqN6EH4ihJ7BW9HNH9762NBTBht55hFTLaM4XrGOgpiitOm
syr7OdmvWD3fszuwtsBYFTej4m4VehlC721E2AsyE3H6ybalk8FTxKl9aQBze+wJhfypFaHW
lAxFIQEZiEmOdiIuBuYZhqOoIzsZczLFNqMO0SSih+zdKnXzJMJBjgcxoVqhF1LOIhp5hCFw
FNjzLcQHRr9iNqiHd2BtgbEqYsa91XP/pQcA4Mhc4JNbVklsGt8Cxqq4GVBVwMdQ/wrVlIgA
D33MzNuAsSpixgufAgAAwIOAsSpuBlQVAAAXgbEqYsaB6nnF5TwEEHEA6kIuT0WblvXFaEFV
DYxVcTNy1YMAIqrw2gAiKu/VeMSZwPGWpaF+yhVwCBirImZY1YMAIo7k4JUBRFIiDKoGqp6g
qk60LFBZwFgVN8OoHgQQ0flUABGZWmBOxpsPCfwhyU0paI5cN0AaRYXD5UOKMN4DiPQWSjUd
KQ8rrhA9DouMLXbkFGm7SMoTob4WVQmMVREz7DgAEEDEhwKIMGtBdTLafPRrAjVBc6jdgPna
ZzmHyzxQhDyNwuotRDUdKw8jrhA9DouMLaqXsMoSz7ypqkVVAmNV3IzaOABmXBokAwcIIGKi
T/zJlNBRi4hpxwOIyHzGnKwQzIH8hhE0R1XAHbIwStWX0VAFx2LVdLw8rDKQ37NskT1QvtjK
jeUuZXAUGKsiZthxACCAiA8FEFGjsHiL6CgPiVL2YgTNYXUDTVRVWjv1Oks9CtyhqjK2ZCKn
qFFVjxmfSoGxKm7G4btVkqaFACLeEECEKDmhepiT8ebDTGM5sIPmMLqBiitu5dOS5DQsnuxR
t8tXk9WIMuVRqaoytmheIirL7LSevCwMxqqIGZnqQQARnwggQhSVcnKSOJnWfKhp7FKUETRH
JuwI2iiqqk9+kK7D04enmAm3K1TT8fKoVVU5W3KRU6idNkJ1LaoOGKviZuDZKq9EfQARd+BR
l6IQIcUDgLEqYgZU1Rup4tXsHqCq9kGfR920ARTp2rUrqCoAAIACVnWJ1zVQVQAAAAVUygio
qg3xcs89wTg84HJSrhgeUjxNkAYo8aV6AVUNqCpixgFVddNtAZWHN2PlpsbFUFib6dWgzyn4
Tr2AqgdUFTGjXlXVBuNwFEdV1U34/FiVXPHqG/UCPABQVcQMs3qMlXG08BBooA36N9QIEXj0
CkpgDk3CoCCCIjySRI1zgSxCxKovfkM+bouHGlFeg4n5RIQV6UPJqLyTyQAloKqAdthlJIqW
7JtVc1UloleQ24jhIdBAG/RvkHg89OgV1FfsahQGRVyKRM5j2Csiag1ZfXZgC7K+ap4XQnxi
h3zOR7VReSeTDgRVBbRDKiOYpPJ3/+0/VWNVVf8oDv5EXUBkjOw3WM7kc9/4UEujMCg2MY0N
kjzpSFaEmrlNBCWJdSlNqy+1bFRRk3G1o0apLgVVBdwDJiNUSbWAqrIPUXZ4CK1UlbRCfnBU
Vc0JkXpDrDk6WLycp1VERlVZGuRWVXXaKKgqUImQMkJKqqW6q6pkERVyVS45FCnhIYhAG5Rv
ZK+O6d+IOuh0GBRhs+AgAxlbGqmImDlWfVUhM2RDpsrE/rDDjPShbFTeyWa2qkrKBgDOQZUR
qtRWZ1UV1zYiAUGo4SGwS1TqN/QLW8bFPiVUh/ilM2FQRLvSsFhERaRaQ1afVk4Ltb5k2RRj
f9ByQ+9WKRmVd7IZVBVwI7AGADHjavVIdahul5ZVUt/q5mTAswFVRcyAqroKqCpQ7QFVRcxA
HAAAAFyEukyVmkBVAQAAFOjqYAJVBQAA0BJQVQAAAC0BVQUAANASUFUAAAAtAVUFAADQEt9X
VUiQIEGq5OTLqqryHV6QIEGCpG3yWVUFAACoJoCqAgAAaAmoKgAAgJaAqgIAAGgJqCoAAICW
gKoCAABoCagqAACAloCqAgAAaAmoKgAAgJaAqgIAAGgJqCoAAICWgKoCAABoCagqAACAloCq
AgAAaAmoKgAAgJaAqgIAAGgJqCoAAICWgKoCAABoCagq4E1U9ds6PCh17doVXOdcctR1jgKq
CngTVnhTr9lksR234LrKcZ1zJjz6bYDudgHgRYA08ICqVqbrnDNRGarqsS4AvAiQBh5Q1cp0
nXMmQFUB7wCkgQdUtTJd55wJUFXAOwBp4AFVrUzXOWcCVBXwDkAaeEBVK9N1zpnwMVWNDtbp
gmPUbWwM1+vDU9zpYkBDtJCGhEi9Dkv6iARnsqq6zlMFqhpjEP0VFO3G2rnZq9VFVTdu3Oio
C6THBSagsUGSb2RaiP8JVNWr0HLA5c1NX8mqmhIRoNMZYm3/xgaJn7UHVFUlMi26cePGWrVq
sYSVqap2vxvD9TIjU8UW8uZDqxriRlU1httO1QGRRuHXyCCdTmeINYbr9YZgPX8KF4a6wTHI
iTkyCD3Hy+SmReErV1UTIvUBkUaaA4U6GmLN0joi/lHwjNnEX1zathGvJPQRCe5wo++rKi+p
fKIKq7KqmiWHB95gSAulRAToiBayj1XFX0FkPRi3qWp0sP1AtXcMRAgCIo38VbDtg73zSLfk
v5fPTQsqVVWN4XqKionzbCkRAbqgaAvpBzWeMSdE6lHPiO3iFjf6uKpKJZUlrKpUVfA+2WCM
oWiMQegEyIEh7OveqxvANdylquL52Db4wn7FuhPWebAt5XPTgspWVbLwuPdoHnPOM5RBkpZu
9GVVJSWVKqwOqCrZBpS2tyX8kOCvQUBPPR03qirr2DY7paoyuWlB5c4ARAfriBkAp1VV0TMy
QyJQVfkW3chOalxAmQGQP6PaL+LM7EMCtNXjcecMAOs61HFVlc9NCzzgbhVtBkBRVSnrc2gz
AIItt7jRl1XVRRfQjgfagip7C0naIyUiAB+rGsODhbU1jIl5wDOolLtVkksZbEu1qiqbmxZU
/soqyW0J28oq2t0qJVUlPIN+wx+/sUHCvRB3uBFUVc3KKokIkg0maaFY271IfZCBOCTEu5BO
Ll0EKgVYys4DTwFUpuucM+F9qgpUT0AaeEBVK9N1zpkAVQW8A5AGHlDVynSdcyZAVQHvAKSB
B1S1Ml3nnAlQVcA7AGngAVWtTNc5Z6IyVDXK2QSqCtgBaeABVa1M1zlnwu2q2tW1VOUtAXgI
rpyefSw5oapVXWRPST6iqgCgCS6enn0sgeucTm7tpaCqAAAAWgKqCgAAoCWgqgAAAFoCqgoA
AKAloKoAAABaAqoKAACgJaCqAAAAWgKqCgAAoCWgqgAAAFoCqgoAAKAloKoAAABagqhqVQQ6
gAQJEiRfS6KqVlJgA0iQIEHy9SSoaqfh02xEdfok6lWBqa8OszOl47ApHcN5JncMn9xx6OQO
Qyd3GDqpw9BJHYZM6jBkUn5+fklJSUVFxb179+6rSPfu3auoqCgpKcnPz2/RuRfggQR9PGTh
yvWbknb6HhsTd3wybkq7Nz5s0bnXiG+iVm3aVuVF0r6Oxh1L1yW8NSiiRedez3d7y9EjFJIr
6f8Bsr6jdD+9yJkAAAAASUVORK5CYII=
--------------ACFCB6E3C948482F77DF51DF--

--------------29B710425B42C144932B6D1E--


From nobody Mon Nov 13 22:08:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B929E1270AE for ; Mon, 13 Nov 2017 22:08:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd88lYKZ9LMl for ; Mon, 13 Nov 2017 22:08:41 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41CA126DD9 for ; Mon, 13 Nov 2017 22:08:40 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id q4so5537393pfg.13 for ; Mon, 13 Nov 2017 22:08:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8t1LwZD9M5n+GmiHX/2nByRJgG0v3u6UgClXl7WH2tU=; b=GVDNqQylHrLzsRAwbBcceQacMHpp5XzkyQafLjbunMi3FOqS6TLPJA+EQzQqNhXuYv pWVz5TBFVgLkgVR0HbqEVD7zIRXJsn+ORTqYOt36gy2a6/3ZPD1Hx20PcV2pvXFdbPWu 0NrohN9l3fuP/gI5VuFViRwsDhOPAZ6hS/m54pDLeUNEoaN8jo4Lf4URutqngb4F8aEy FjgOg/OX/Z7KiP2P0KB+QamOZm2dFqRRMRmkes7yX6ld7XYiouLfAQDc0Kwkg/5c7tZX 5W8k6AFQYoMhM4Mb5Q8k2vemt35Nx4hjfPsI/2ogrpmzSWwEOlhtiRZjL7QnTEeNmS8O CFlA==
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=8t1LwZD9M5n+GmiHX/2nByRJgG0v3u6UgClXl7WH2tU=; b=WMpNZiykUjWwtsAhLZELpkJWXA4ADi96BKvVZy43l80LV15inO3EKfdOWcesZ24sXg YJPrwOtZLC1nHg8hDpCfVVIwn8wRlWNMt+/S3MV1OwOUA3mmgLZpeGbaPPDJweRIWZmx EszHgjAcOfhQZvXCDWIM5PP3cDmMsXxDFXby2IW8iyyXCjmfxljP3dCeESdLugikTZlR KuLKF9pakMjarp9FbbYT2KcSuCICrEbaBX8wfv2/CXexDPQ2RrOhqwywPiuG7+dsfW27 AgR76vOFy6mObRL1hpuX/j/YptnW+HzfY/R3aBYA9rwMLKYO9FSCC2s/OXi2S5ND4iRe 9f6A==
X-Gm-Message-State: AJaThX5lhRdz90Xmgj5xOQIkwaRl5nh0Sc24pIvf2nfi+PmAlbAw3GZp RwkHjx5NJJlThBbGwTov6WDPPePo7ko=
X-Google-Smtp-Source: AGs4zMZ9j/DgX4tvUi8KshU70AddPK6TUSTLgd+gZ8vJEjJ5s56gHLPPQppgp8w4V4+2ljEWuW5Wug==
X-Received: by 10.98.32.21 with SMTP id g21mr6056546pfg.52.1510639720320; Mon, 13 Nov 2017 22:08:40 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:1997:afe:9fe5:8736? ([2001:67c:370:1998:1997:afe:9fe5:8736]) by smtp.gmail.com with ESMTPSA id t4sm11106828pfd.110.2017.11.13.22.08.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 22:08:39 -0800 (PST)
From: Suresh Krishnan 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_6EF8360A-7DF3-42A5-9991-2A5A68D1F2CE"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: ESSID ietf-v6only at IETF 100
Date: Tue, 14 Nov 2017 14:08:41 +0800
In-Reply-To: 
Cc: IPv6 
To: Alexandre Petrescu 
References: 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 06:08:43 -0000

--Apple-Mail=_6EF8360A-7DF3-42A5-9991-2A5A68D1F2CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Alex,
  This has nothing to do with IPv6. You will have the same certificate =
issue with the ietf SSID.=20

Thanks
Suresh

> On Nov 14, 2017, at 2:03 PM, Alexandre Petrescu =
 wrote:
>=20
> Hi,
>=20
> I have problems connecting to the IPv6-only ESSID "ietf-v6only".
>=20
> It is a problem of certificates.
>=20
> I have this problem on Windows since several IETF meetings; it may not =
be related in particular to IPv6.
>=20
> The message in the window below says: "The server =
services.meeting.ietf.org presented a certifcate valid emitted by =
Starfield CA, but that is not configured as a valid anchor to approve =
this profile".
>=20
> I dont thave this kind of certification refusal problem on =
ietf-legacy100 ESSID (and all earlier ietf-legacy), neither on =
ietf-nat64-unencrypted.
>=20
> This ietf-nat64-unencrypted is now appearing first time at IETF.  I =
suppose people realized there was a problem with certs and created an =
'unencrypted' version.  That's not a best practice to fix security :-)
>=20
> And yes, my VPN FortiClient works ok on ietf-nat64-unencrypted.
>=20
>=20
>=20
> 
>=20
>=20
>=20
> Alex
>=20
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--Apple-Mail=_6EF8360A-7DF3-42A5-9991-2A5A68D1F2CE
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Hi Alex,
  This has nothing to do with IPv6. You will have the same certificate issue with the ietf SSID. 

Thanks
Suresh

On Nov 14, 2017, at 2:03 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:


  

    
  
  
Hi,
I have problems
          connecting to the IPv6-only ESSID "ietf-v6only".
It is a problem of
          certificates.
I have this problem on
          Windows since several IETF meetings; it may not be related in
          particular to IPv6.
The message in the
          window below says: "The server services.meeting.ietf.org
          presented a certifcate valid emitted by Starfield CA, but that
          is not configured as a valid anchor to approve this profile".
I dont thave this kind
          of certification refusal problem on ietf-legacy100 ESSID (and
          all earlier ietf-legacy), neither on ietf-nat64-unencrypted.
This
          ietf-nat64-unencrypted is now appearing first time at IETF.  I
          suppose people realized there was a problem with certs and
          created an 'unencrypted' version.  That's not a best practice
          to fix security :-)
And yes, my VPN
          FortiClient works ok on ietf-nat64-unencrypted.

        


        
<nmjmnhnofdiighgk.png>

        


        
Alex

        


      

  


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


--Apple-Mail=_6EF8360A-7DF3-42A5-9991-2A5A68D1F2CE--


From nobody Mon Nov 13 22:25:01 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0701129439 for ; Mon, 13 Nov 2017 22:24:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 c8WVqrZVWbvd for ; Mon, 13 Nov 2017 22:24:56 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 273E2129438 for ; Mon, 13 Nov 2017 22:24:53 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id z3so19577423wme.5 for ; Mon, 13 Nov 2017 22:24:53 -0800 (PST)
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=H9ifG+7+k8AhLPLAJxpZr6lumCKKCoTHpN/mnvI0R58=; b=fusbsIr/SyjDcd8Kn8fpbidcdARFT8m8DQ4HVveaeJ9H3N2Usx/UtM22/FZo63AtjM HDz7TFUKSnojoei1ui4h5X+OProopjdhPLybStSjAZQQuBTOhzWbv2pXYYqjtAno1MFj Cg5xtwFsUbwG060wQaH3LShTp5KM5BCpGkACaTpyRp9zB+QG0wMSqxckWPvkcA51crlA YlI5OxFpZYNjXmuGI8tl3R137DVAezzIP/YqUUY2/XJ/jHvpIunUkeJnhzhg3gkzr7bV IWL5TT9kSe3FgdrS45F1qYHq7FrnnMV5rFtvQMIqIe4bXp875540zSn6NJnYAi0rvnAp T17Q==
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=H9ifG+7+k8AhLPLAJxpZr6lumCKKCoTHpN/mnvI0R58=; b=AgglUjRFpDWXl5Yyepxn+YqGmBvR8d8Xq+0WQlRkTeqyR3Ua3MbU1GkVLKgHM3TcbJ hCZIOU6fvMAPcwE+MNbzJQd6MWGxR9EUEdoDJa3TRjj+72RDlKOB+mTUdovGJoYUYrrn k4+4bk6+gPi84bDJVCukZDpmxmJL1Zl8LZjSIVhfu9m9isSQ6eDStLeyKqvMbdmBHwVU jYVh9W0By/4yPpWFiKuBXpRMFBc0dkAgnCX571BoU9tKKehFktkIpaUFhaixX8lukpwq vAJS1OGBoxK8s9Y/az/sWGVyV/6igYFyW7AngQNqbynte+mKJzet1s7X5qhh2qKwczG+ M01A==
X-Gm-Message-State: AJaThX60lBW/1ZE1zMLl6IGrlD1v4z0SpJ2fwtnYoGK92EaCaeDPpFpS uNjlFkPV7it8PjOsZGP5K4KbhenSO0jWnihr4GnTKg==
X-Google-Smtp-Source: AGs4zMZheGW7wW6Tp6IhQu6KeoNMYt9MrrJZDMYCrBqz2Mg2gpbshPAyZmFzgoAi5GVJ/98Wz2kaGtgjV4dzyni+Nxc=
X-Received: by 10.28.191.80 with SMTP id p77mr8868526wmf.85.1510640691448; Mon, 13 Nov 2017 22:24:51 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.160.149 with HTTP; Mon, 13 Nov 2017 22:24:10 -0800 (PST)
In-Reply-To: 
References: 
From: Warren Kumari 
Date: Tue, 14 Nov 2017 14:24:10 +0800
Message-ID: 
Subject: Re: ESSID ietf-v6only at IETF 100
To: Alexandre Petrescu 
Cc: IPv6 
Content-Type: multipart/related; boundary="94eb2c074232cc50b7055deb7109"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 06:24:59 -0000

--94eb2c074232cc50b7055deb7109
Content-Type: multipart/alternative; boundary="94eb2c074232cc50b5055deb7108"

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

On Tue, Nov 14, 2017 at 2:03 PM, Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

> Hi,
>
> I have problems connecting to the IPv6-only ESSID "ietf-v6only".
>
> It is a problem of certificates.
>
> I have this problem on Windows since several IETF meetings; it may not be
> related in particular to IPv6.
>
> The message in the window below says: "The server
> services.meeting.ietf.org presented a certifcate valid emitted by
> Starfield CA, but that is not configured as a valid anchor to approve thi=
s
> profile".
>
> I dont thave this kind of certification refusal problem on ietf-legacy100
> ESSID (and all earlier ietf-legacy), neither on ietf-nat64-unencrypted.
>

=E2=80=8BThat's because the legacy (and unencrypted) SSIDs are unencrypted =
and you
don't need to talk to a RADIUS server (which presents the certificate)



> This ietf-nat64-unencrypted is now appearing first time at IETF.  I
> suppose people realized there was a problem with certs and created an
> 'unencrypted' version.  That's not a best practice to fix security :-)
>


=E2=80=8BNope. We have the legacy SSIDs because some people apparently had =
issues
connecting to encrypted SSIDs (because of old OS / broken wpa_supplicant,
etc) - this wasn't issue with certs, but rather providing a solution for
those who are unable to do WPA enterprise / have old cards, etc.
 There was an assertion made that some people were not using nat64 and were
using ietf-legacy were easier, and so there should be parity, and so the
ietf-nat64-unencrypted was created.
We are changing the name of the ietf-legacyXXX network at each meeting
because we don't people who connected to it at a previous meeting to become
sticky to it and keep joining -- it requires a specific action at each
meeting for the user to choose the unencrypted network -- we'd all prefer
that people use the encrypted network...





> And yes, my VPN FortiClient works ok on ietf-nat64-unencrypted.
>
>
>
>
> Alex
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>


--=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

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




On Tue, Nov 14, 2017 at 2:03 PM, Alexandre Petrescu =
<alexa=
ndre.petrescu@gmail.com> wrote:

 =20

   =20
 =20
  

    
Hi,

    
I have problems
          connecting to the IPv6-only ESSID "ietf-v6only".=


    
It is a problem of
          certificates.

    
I have this problem on
          Windows since several IETF meetings; it may not be related in
          particular to IPv6.

    
The message in the
          window below says: "The server services.meeting.ietf.org
          presented a certifcate valid emitted by Starfield CA, but that
          is not configured as a valid anchor to approve this profile"=
.

    
I dont thave this kind
          of certification refusal problem on ietf-legacy100 ESSID (and
          all earlier ietf-legacy), neither on ietf-nat64-unencrypted.

=E2=80=8BThat's because =
the legacy (and unencrypted) SSIDs are unencrypted and you don't need t=
o talk to a RADIUS server (which presents the certificate)

<=
div>=C2=A0

    
This
          ietf-nat64-unencrypted is now appearing first time at IETF.=C2=A0=
 I
          suppose people realized there was a problem with certs and
          created an 'unencrypted' version.=C2=A0 That's not a =
best practice
          to fix security :-)

=


=E2=80=8BNope. We have the legacy SSIDs because some people=
 apparently had issues connecting to encrypted SSIDs (because of old OS / b=
roken wpa_supplicant, etc) - this wasn't issue with certs, but rather p=
roviding a solution for those who are unable to do WPA enterprise / have ol=
d cards, etc.
=C2=A0There was an assertion made that some people were not u=
sing nat64 and were using ietf-legacy were easier, and so there should be p=
arity, and so the ietf-nat64-unencrypted was created.
We are changing the n=
ame of the ietf-legacyXXX network at each meeting because we don't peop=
le who connected to it at a previous meeting to become sticky to it and kee=
p joining -- it requires a specific action at each meeting for the user to =
choose the unencrypted network -- we'd all prefer that people use the e=
ncrypted network...=C2=A0



=C2=A0

    
And yes, my VPN
          FortiClient works ok on ietf-nat64-unencrypted.

        

    


        

    
3D""

        

    


        

    
Alex

        

    


      

  



-------------------------------------------------------------=
-------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

-----------------------------------------------------------------=
---





-- 
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 p=
articular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf



--94eb2c074232cc50b5055deb7108--

--94eb2c074232cc50b7055deb7109
Content-Type: image/png; name="nmjmnhnofdiighgk.png"
Content-Disposition: inline; filename="nmjmnhnofdiighgk.png"
Content-Transfer-Encoding: base64
Content-ID: 
X-Attachment-Id: 6743a879b0ab9760_0.0.1.1

iVBORw0KGgoAAAANSUhEUgAAAccAAAFjCAIAAADHE1cdAAAgAElEQVR4nO2dd1gU1/rH99qwo8ab
dnOTcDe5MdUeojGWrIjR9MREsSCKEUmxRJPYsaBRgg3sNZZgYUGsKCBWWLBkTVZNookCBgugUmyT
3N/+/pjZnTltZnZ3FnaX9zyfh2fZnTnvOe85850zZ868o/tFdfr1119//fXX8+fPX7x4saCg4Nq1
ayUlJWVlZbdv37579+59p9Ldu3dv375dVlZWUlJy7dq1goKCixcvnj9/nrelvmyQIEFyxxEKyYmk
s5hNAAAAgIt07dpVUFUrJEiQIEFyLUVFRYmqWuUCDwAA4O0gqhpFS9NoaTotzSDSTFqKpqVZtDSb
SN/S0hxamkukGFr6jpZiaWkekebT0gJaWkikRbQUR0vxtLSYSEtoaSktLSPSclpaQUsraWkVkVbT
0hpaWktL64j0PS2tp6UNRNpIS5to6QdaSiDSZlraQktbibSNlhJpyUhLSURKpqXttJRCpB20tJOW
dtHSbiLtoaW9tJRKpH20tJ+W0mgpnUgZtHSAljKJdNCFBKoKqgqqCqoKqgqqCqoKqgqqCqrqflV1
aC61a9euoKqgqqCqoKqgqgqq6tBEKqgqqCqoKqgqqGqVq+rK7RazybJnuVtVdd1ek8Vs2r/WFVVd
k2Y2WY5uWeJGVf0+w2yyHEtc6R5V3ZJusphNBxJAVUFVQVWrXlV1Op1OhyyRwr5Rraq8hppNqSud
U9UV+8wmizllbaWr6vpUiqQ6pKrLkw9YzCZT8tLY2O/TzSaLedcmVFU37TdZjm3DJPWH/SaL2ZSx
acGCBQtWbs+0mE2WtA0LFixYsDIxx2yypG1YlZJpMZtyUlaAqoKqgqp6naraZRT71wFVXbXbJsxH
Ns33KlXVdAaArqrUGYCV2w9YzKac7csXLFiQkGay8INZm8LyYgpjVVBVUFWvU1WpkpKSqlpVYzdm
mU2WI9tTj5gs5vRt8whVXZUiZnpk04Lp06fP35RlNlmO/LBwdYrFnLJvj3TeIWXtzJkzV0t3SViE
qiovpnYEVV27Q/zy6OZ4VFW/TxW3zzbGz5kzZ873OyXb24aryJdbl67fZTGbLPvWxsTEbNhnsphN
6Ru++27pVpPZZDm2ddmGXRbzrk0bdlnMJsv+7zftl5Zq96Z58+Zt3C1+g80ArEg0CePTDRlmU86x
TIt5d4KgsJk7Vy1c+MMefgArfMjKzOHzyTKuXrRo0aJFvJja4VV17Y5M+zc5O1bHx6/elWWymPdu
Xbx48Za9FrMpZ+eaxYvX7M4yWbKS1y1Zsi1DzCF311pQVVBVUFVN5lVZkqpWVedtTreYTVmbvxM+
bIlFVHXepiyzKWvLvOnTp/PymrVlnk1V07PMJos5ZQ02Vl34Q7bZlL11/syZM6PX7LCYTdnbFoia
umaHxWyy7F2FjFUXJWSbTdmJi2bPns3La3biIrukLk7MsJhN2Ylx4lh18ZZsVF5NxnhBUo9uWTJ3
bkzM4u375FX1gIkfmdpUFR+rLt9mMptMycvm2eTVtH25RFbXC5OtKxNzzJk7NiXmmDN3rFy+45jJ
Yt6TsJBUVePqRYs2p/ECumhRwh6L2WRJ34SMVW1fxsfH819mbo5fuyPTYs7cvXbxup2ZFrPJkv7D
4rXJuWZT7s4163YetJhNuTvXwFgVVBVU1aNU9butR0wWc/rWWPugddN8iarO35KOZWrZs1xQVXPK
GtoMwMKtGfgue1faRXWt5Krfrqpx24hdUldjqiodqC4xEtvvW8vrZtr3khkAGVU179rIzwAwVHVF
8gHcxP71xNTq7oRNuy3m3QkLNmSYTRmbNmTwSkqqatrGRRJVtX1AZgDsShofHx+/ea+gsJv3Wsym
zC1rdmeZMtP3WrKS123hv1nCq6owUN25BlQVVBVU1TNmAGz3qaSkrsRVVRir2pN9BoCtqsJYlUgy
qiqMVanzquskl/apa3hVFcaqtnlVx1T12NZlKlRVGKsS86q2qdXMjLRMy7HElQuW7zhmyknbnWOf
VNVKVeM3ZZpNOTuTM82Zu9f+kGnOzEzPtJj3buMHqFv2im7JSABVBVUFVa36u1X8faqszd/x/woj
0z3LxRkAQXZTVqtWVdukaspamqou4gV020JkBkCYVN3xvfzdqvjN2WaTJXWNbVJ153rp3SrWDMDR
rUsdV1XbpOruTaz1qisShanStA3iPSt+UlVJVVfzKwR2rFKcAYiPj9/Kz8BmJa/jZ1TNwqSqmNYl
54KqgqqCqmqnqtJRpqOquizVbLv859erzuMv7bevlt6tEq73BSTzqnZVnbFwq32iIGWtbWpVvGyX
zqtGLzAeRYbGwt2quM3ILsS8qsDRLUskU6v2703GeMrdqpjF21Fbsqoau1y86t+9yTa1KppA5lVt
U6u29VULNgkqnLBQWVUXLVq5KwspGONuVXx8fLw4o7p4Ma+w/FyqdAbAkpX8PcwAgKqCqmo0ryqD
C08BwLNV8GwVqCqoKqgqqCqoKqgqqCqoqnOqSpVEagJVBVUFVQVVBVVVUNWuDiZQVVBVUFVQVVBV
OVV1LoGqgqqCqoKqgqq6U1VVTs0CAAAALBBV/UervgKtRWq07lejjYS2dkJI3hwxdcfu1LSMYz/m
bv8jd+qFI5+dODB7f1ragYOmyd8taf760BovD6jJEyjhlYE8tXg62BlUq8OgWh0lvMoTKtAJ5bXB
UmpL6RwmpU4XO0PqdEXw68YzVOB1CYahfoZwke4oQcNEegjU7TGsbo9P6gaj9Pykbs9P6vUcXq/n
8HpvoPQaXq9XRH07vSW8OaL+myMa2HlLSmSDtyW8Y+fTBu982uBdlPc+bfDeZzwN30f54As7jT74
otGHEvqMtNO4z8jGH9kZ1fijUY0/FvD/eJR/X57RAv1QQsaI9EcZ8CXCwC+bCIxtMggldGzT0LFN
Q8cJDJYQNq5Z2FciQ0QeGPq19N9mQ8bZaTpkXNMhY1G+5GkiMEYgjGd0k7DR/iKjUEZK+ALlM/+w
z/wH2/lUSuPBkSgjeBoJRIiERjQKHd4odHhDgU9QhjUMHdZAJBxlqMAgniEoYSiD7dQfFIoyqP5A
gXoDB9UbOBBlQL2BA+qK9EcJ8bMzIMRvQD+UvhI+RvkIpY/fgD5+/fv49e9Tp3+fOv0/RPmAp7bA
+yjv1e7/Xi2Bd2uFSHkH5W2Ut1DeFOj3Zs1+b2qpqv6vhY2Ojs84cNhkMl3+cebdnMA7GQ9W7G5U
vtv/Qkqbw3vnHzx6avm6H1r3GQmqCqoKqgqqCqqqoKodBn6zbP2WjANHTp44dOvcpL9Odak40r4s
/dlbOx+6sdW/bGvDa9ua5e4cdfDoydR9B0JGT2vYKRRUFVQVVBVUFVSVoqr/Do74eu6KrGzT4cPZ
v/ycce/SbO5c+B3zoApTz7K0lrdSHi3Z3LB4Q4OSdY2K1zf4cUvvjLSUg8dOLVy+NrDvSFBVUFVQ
VVBVUFVRVZ9849PIafFHTcdPnjp98mTu1bwD1uINf+UvvH9h9l3LF7dzPyzP7Fi6U1+yuWnxunrX
V9e/vrzRjZX1Lqx7KmvXtINHc9IyjnwVPb/Nh5/XegVUFVQVVBVUtRqr6oOvh7/zeXTsmkTL2d9+
O3/p9OnTF89n37uZZS0//HfJgb+uJt2/uPjuuQl3ToWWH+5euuf5G9seKl7f6PrK+leX1LsS1/D6
woZXlzY6vf71Q3tXHMr+cV/64RnzlvYe9vXjPYfV6gCqCqoKqgqqWj1UtV7gwNAJC2av2Lpt7+Hz
Fy8XlVSc//3yubOnL/6yu7xwu7Xi0P/dPve/O3n/Kzv91/W99/NX3/t1+h3zsIqjvcpSW900Play
oUnR6sbXFje4sqBeYWyDP+c2uh5bPy+++emNb2ftXZh55OihrFPJO/d9G7dq2Dez3ho+vmGnAaCq
oKqgqqCqvqyq74+cff/+/StXS3797feLF07k/7L50qmZdy7O+L8/5/59fdvft078786l/90t+Lvs
p7+up/5dsPp/F6L+/mnIX9nBXNoL91Mevr25UfHaJteX+V9Z0PDPmPqXZ9e7HN3g8sxGV7+tf3l+
M8uyl88kR+akLsjYn5RtMmWbTO3eGgSqCqoKqgqq6suq+uWclTdulp3JmlT8Y+87liDuzOt//fLR
/fNjufzFf11L+ftm9t9llr/Lfv77xrG/ryUX/rz6VEZs1vaxGesG7lwYvDX65e3Tnipc0aR4edOr
cf6FsY0vf9uwYEaDgmn186c0yJ/c8M+ohldmNiic17xglT5n2+fmn3/tETIcVBVUFVQVVNWXVXXm
kk1FxSU3f3qLMz9+1/zynZ963z075N75Cffz4v4q3Pp30b6/SzL/Kkr760ryX/krD6ZtXb1uy7yF
yyZHffv5qPEDhnwWOmTE0Vn/urG80dW4JlfmNymc2+TPWf4F0xrlT2yQ93XdS+PqXhxb/9JXja/P
bJoTH3w059Q7YZ+BqoKqgqqCqvqyqsau2vpn4eWSU93v/fjU7VPt7/zY8+7PYfd+nXD/4nzu8vdc
4Rbuz4T7Bd/fv7iEOz8rdfvKRXFLo6Ojx44dO3To0A8/7DNoUGja1EeLl9S/utD/SmyTwrlN/5zV
tGBG0/zJjS993eDiqDoXRtS8MNzvz3H+R2Z3TT+UFRIxBlQVVBVUFVTVl1V13qotf/z+S3Fu4N1T
T93OfenOiaC7P4Xd/eWbexdm3/9j4f0/Ftw7P/fer9Pvnplw7/Sn2zfNnTlr7jfffBMREdG3b9/e
b77Vr+/H6ZP+WRJX7+q8RoVzG/852//P6KYFM5oVTG2WN97/4qgGF4bV/i2s9uUvGh+c1ik141D/
EaCqoKqgqqCqPq2q361I+OWcuTi3/b2TT1VkPXfb1OXOj/3vWL64e3b83bMT7lq+vHM68s7Jobdz
B9w9+vbWlePHjJs4fPjwvn379u7d29A96P333smc6F+y0O9qTP3C2Q3/jG50ebp/QVSz/MkP5H3T
7OIo/wvD6v0W6lfwmf+hqFf3pmXCWBVUFVQVVNXHVXXu8k1nLCeKc9vfPf5UxZEWFUc73D7+3u1T
g++Yh985NeR2Tp+Ko70qDgaVp3e5k9p6w/xPwsIjP/roo969e3fv3r3Ta1169Qw6OK5+8ezaf071
K5hQP/+rhnlf+l8a0+zSqAcufvHAHyOaXQhreH5Q3YLP/A9N7bg37UDo51+DqoKqgqqCqvqyqs5Z
utHy8/Hi3PZ3c/UVh5+tOPxKRVavitwPeT0tz+hQlvpS6e5nS3c8VW58eMWMDz/4aOAbb7wRGBj4
zDPP/POhh59v8XTm8LrXvqld8GWd/DF180Y1yBvZ6NLIJpdGPnDxiwf++PSB34f5XwhrcPmLpkem
vZqanhn6+VegqqCqoKqgqr6sqtFx6346nVtyPPCuSV9xsEX5oQ4VR9+oyHq74nBweXr7sl0Bt5If
upX4wM0tTcoT/OZ92fXF1h0eeeQRPz+/mjVr6nQ1ng749+ERftcm1r48rnbBmDr5o+rmjWp4aZT/
pVEP2IerfwzzLxz9wJEZndMyjwyIHAeqCqoKqgqq6suqOiFmhfnH3OLjr97N/k95Zovyg69UHOlZ
cfTNiszXy/Y+dyv5nze3NriR4FeypnZZXI2vPnhKp6tbs2bN2rVr+/n51alb/8VnAo5G1rk2sdbl
r2oXjPXL/7Je/phGeWOa5H35QN6Y5pdGN7/0+QMXI5tdGds861vDwWOmkBFfgqqCqoKqgqr6sqp+
Mmlebm7u5WPd7mUHlB94pvxAYMXh4IrDvSsyupbtfubW9gdKNta/vqjOlWm1bkb9Y/y7Af/wa8xL
aqNGjfybNe/Y6uncz2pfm1T78ni/y+PrXf66YcFXjQu+apo/rnnBVw/mj3sof8w/L41sfmX8Q0fn
vX0s99S7YZ+DqoKqgqqCqvqyqn7w+YyjWcfPH+x1P/uJ8oynyw+0rzjco+JQr4oDnUt3P12ytumV
6HqFk2sXTql1a/o/prz/RM16TerUqdOoUaPmzZs//K/HgwJbmEfVvj61XuGUBoWTGxVO8r88senl
Cc0vT3joz4mPXJ74aMHXj+SPe/jqtH8dW9o/5+TP3fsOA1UFVQVVBVX1ZVXtEDLu0JHj5rR+nOmJ
8vSny9PbVBzqXn7kjfK014pXP3VlZtPCqHqFU2sXTq5VOu0f0z54vFaDZvXr12/evPljjz2m/+9z
b3d58exYv6LpDa9M978yo+mV6Q9cmf7PK9MfKZz+WOH0x/+c9vifUx67POnf1759/GTCyBOnz7V/
sz9DVRdt4zgrl9XX+1R1qZHjrFxOiFtUdXkSx1m53AE+oqrrkjnOyp0Mdbuqfr+d46zcqTBfUdX2
xjwrx1kvbW8Pqur5qvpUrxGHj57M2jv6nuk/5fufKtvfsvzQ62XpPUvWv3Zt3lNXopsWRtUrnFK7
cHKt0qh/fPvho/X8H2zSpMmjjz769NNPt2wT2Deo5a/f1Cua1fTa7AeuzXnw+txHrsU8dm3uE1fn
Blydo7/y7X8KZz5ZOOPJokVP/bhrRu6pM//t9qH7VLVvGpc42VVVDcngEqOUVTXkAGecDqoKqlop
qhqXY+XyZo1fmsRx1qylUlUdkMUlxYGqepiqPtglbP+BrKP748qyninfry/b90Lpns4lG3sWr+x8
fcF/r0Y3u8Kr6qRapVH/iO/3oP8/H2vevHlAQEDLli07dn79kzdb/TGlUXHMP4tiHyla+O/iuICi
OH3RoqevL/rvtYUtrs3/79UY/dXYp6+vfvHIroUHj5iav/y2e1R14vTznJVzUVUnz+AzUVDVKTMu
cFbOrqpunQHwMVWtxBmAiann8lI7+oaq0mcApkRf4qwcqKrnqWq9wAGbtu04Ydpdcqh9RerTN5Nb
FK99tXhtUPGqztcXtLga3fzK1PqFk+sUTqp1a+o/Vg9s3vzRJx9++OEWLVoEBga+3qP3yPdb589s
UrLgX8XxTxYve6pkxTMlK54rXvF80YoXipa/eH3x89cWtShe+vyl9a/s37PZmLzTr827zqjqxCwr
x9m4NH0gpqqCpAqcT2rVJaxOl7BWq/PsXyZOsavq4kSOs3KmkMHJZ4Vf82aEDfUzTJohzeRCcqvu
4X7TTBK7eTOGDvMLEiTVttn21pKxasgBzspx1syldlXtn8l/s4xX1Tbr8+37GqNZqjot+ndhm6TZ
uKq22yTmkPQtS1VnRv9hL2T+rC9EVW2fUGDf/VxCtE1VVydxnJU7MWj07nPCrwWzR/OquiaZ/2mM
5KcvRVUN3CpmmDzfJqnzT1o5znpxT2D/Mf7958y+yFk5LnkhZaz6SuJlsTyJc22qKow0B49PtRm9
/O0EUlXXCwPSiam/2DabM9E+Vr08Z6JtXnXxSUk7Xv52Iqmqa/mCDY63b3ki1K6q8SckuxfMnmhT
1fjjku+Ph1JUdWUyx1m53NC4XNtmuYMEVV2eLPzLqyrf0DmDaKoqXP7zjR7Hq6ogqQKXktuFLkni
OCuXl5TFb5wX/c3QBoOGtEuU7LsIVLWy3gXw5fQFx49nXzn4dsWO54pXPlu0vH3x2teLV3W5vuj5
q7MevBLVoHByncKJtW5NrbE5rNkjj+sfe+zfL730UufOnd9464NvPm5VOPfBG0sCSlY+U7L2hRvr
W97Y0OrGhjYl37cpWdu6aFXL6yteLF3f8uSGd3KO//jNtDm1Avs5rKoDjGc4SQfiOCuX3VdJVful
Y7twZ1ZPlKgqyvnkVqSqDrHLrh1TiKyq1p2Rw3/ZRlDVZUaOs3J5M4dLFFbC2Q1RhKqKkipBUNUB
h4gcNs0gVFUqqcIBP/D9zxp+8MXAw0TOR1ZLVBXl4u6XRVXFftoT2He0f9/RoUfxn85tncMLa+gx
zspxyQvG+C84aeU467F15AzA4Cwi56zvJaqKcim1A11VUfJSO2J3qybapdnOycF0VcUs7gkMG+0/
cTex+4nQsJGU7y/tDKSrKrbZjpcdUdWBhJfOGqewVVXsqwMGDR1A7ps4EVS1MlT1lY9HZx425SR/
VpHUpmjZs0VLWxaveq14VZfri166OvvhK1ENCyfVKZxY+1ZUzcShTf/15NNPPvlkmzZtDAbD2x/0
m9Sv5fWFj91c1eLm+pdu/tDm1tb2N7cF3twaeHNz4I1N7Yu/b128rnW5se2Peyf+cj6/W5+h7Des
qJwBiNvGcfhwlZwBGJR0hpdX4dqfV9LsEImqnl0zye/1oX5TTYJcKswALE3kOGG4is8ASOdVp868
wFm5vJmfDK/Xc3i9mbzIprR5Y3i94SlnOc76e0pbYQZgOb/XAExVR+w4y3FWLj86ckSDt0Y0mJ0r
quqnO85ynPX3He2EGYCVwjAWU9XPd561K+n7n/FKevaHmQ1H7jrLcVauYNbILxp98EWjUbt4UUiK
EVX13OZZjfuMbBzLD81ODJKo6rkts/0/HuU/T/gptO9o/y/3nOMVVpgBEIZ7ocIMwNpkjrNePJl8
kbNyJ0PJedWv957jOCt3+dtvxjYZNLbJN/y/XHKcqKrnjDFNB49rGnfKynFW7tRghqqeS/rugaFf
N1ssbBYmtwaAz7mAH66SqnouaU6TsNFNwoR/k+OxGQDeGwWzJ44UBrCXdgXKzQAIqnrOOKPx4MjG
g1cI2capVtXxKWc5/iYVf/m/NIlXTMoMgKCqZ42ThBmAb5LPcpz1UlI74fJ/cRLHWbnsAaCqlaCq
DV7uu2df5sHUDcWJHUpWPVe05Lni5YHFKzsXxbe+9u1jV6IaF06qWzipzs2o2tvDmzz476f+/cR/
WrdtbwgKfqfPoK8/frFk2X9ubWh5a3O7W8YOpdtfLU3pdCu5001jxxtbXi7Z1O5mQvvrO147uG9d
7onTD778lguqyuspj5KqTs4mhnuclcubMdiuqnkzBvMzqrYJAaaqLkmU5qCgqp+0/j7PynFnv4+q
11MYnBpnDq/3hk1hcfKjI1BVnZVr5TjrweWUedXZufQcPkNUtd0P+VaOsx5eic+rxhy3cpz18Gr7
vOqgI5yVnwcQVLVg1mh+XnV1Mq6qBbPH8POqwoRAaN/RNoXFKJg9TphXDdwmTA4kL6DdrVp4Uhic
2mZU+aHrOeNcm6pe/nY8P6NqmxCgq+rlORP5eVXbhABdVaXjX5aqnhxsm1cNzeZF9ltUT211nEiO
VQtmT2TPANjmVQfx2Rqnq1XVOGq3yYsez1LVvOjxtnnVRSbavpeivwFVrZS3AY6eGnP8xPGL298r
Xf9C0ZIWRUtaFS/vWBTf7tqcJ69Ma1I4uV7hJL/iKX4/jqrXo13Aq22f69m53fu9unz8Xq9F4f+9
seb50s3tSpM6lu7sXLa7a9merqW7utza/urNba/c2BJ4Z0eHU4kfZ+eeilm4tFa7Ps6oqvIMgEpV
5RKnSuZVuympKn0GQEFV6/ZcauQ464WUNj35y/+c/m/IqKptdtV5VeWS5milqicG9WGp6olBH6tU
Vdvsan9hEsDKcdZja51S1VODQ9Wo6qmwIbKq6sAMAE1VWTMAYSP9J+5Cf8qfPbFyVJVLinNaVaWz
q6Cq7lTVR14LOZJ96uj26eVbWxcve7Yo/rmiJe2K4ttd/+7pq9ObX5lUv3Ci35VJda9Pqf/rVw2P
j/E/9VXTkxP+aZr82O8Ln7m5sW1pYoeynZ3LUruVpxnK9htK93a9ldLpZuIrN40dylI7Ze+LPf/7
5Vfeln/HKlNVX1p5ycpxZ1ZNqPXa4FoDeYUlVTWsb5pEVfkZAC67H2UNgIyqhodkiKraam2elePO
rp3s1z3cb+j2s6KqDuPvSrFWVoVkclYub+b3OVaOO7s+SlgAwM8AcDkD5NcAoDMA7Tby96YkMwBc
7gD5NQDoDEB7u8jSZwAKZo36wklV5WcAuBOh1DUAwnTqWmGCdaHKGYDL344fq62qdki6bOW4c0lz
mw4Z23Qib4U5r0rOAAQmFVg57lzSbP+wUTaFtamqZAEAr8LJ8Y7OAHBJcSMaDR7R3sg3NGMGgMsZ
SHsKgJ82ZaoqPwPAZQ+ANQBVoqo1W3/83eI1pmPp+Yndb619sWhxi6K4F4sWt70+79mrMx+5MqVR
4aT6VybVuzq5YemMxifGP74uosWOr1+6HNfi9saWtzYHliZ3Kt/brTy9e/mBHuXp3UtTu97a0elm
Usfbezr9vvvtw4cP7klNq9f6bRWqinNm5XheVbGrGGIGQFBVK8e8W2U9n9RKnapaOc56ITlkbR5h
l58BEFTVyhF3q/iVVZ9st68u4O9T8ZB3q6y/p7R17W6V9Y+d7ZTvVuXP+kLN3SoHVZV2t8p6cU9g
yBj/EP6+f8Hsr8b4f8WLLz+16tDdKi1VFYU5r4pwaU9gmKCq2O7ivCrqZ8ZYFcuWv1s1bfYl4id1
d6usl7a3k6iqlUPWAIiqSrtbZb2U1A5UtXJUtUabfk90CTmWYz6WNLViS+viZc8VxbUoWvTS9fkv
XJv9+JWoZlcmNbw6sUHptIYrBz3x/Ett/vtC206G3sP6vfHbkla3kzqW7exSvr97+YEe5Zk9yjO6
l+7tejPl1VvbX63I6Hxk5+T8P4t7D4ys9YqasSpFVWt1CrUr5plVE15adcnKcYmTiKcAxKv+7H5d
wupgwno+qZWKsapflP2iyRTSXRTZs+umtFqXZ+W4xGnD/HoM85tu3ywnhPYUALKgSrJeFRFWu6Q6
srIKEdbfUUl1fWWVg6rq3w8VVkFSxwjLrY6t5RerClMBx9Y5vLJKkxmAIeMGZ9tMJM3lRXb7YgdW
VoWKu8/mRTY5nlxZJTuvSllZNaLxhB32CYSkOLmVVYiwXtre3v4UQJzYXQfQVLXBoCGIsCKSCqrq
flWt0brvrAXLc0yH/0jsXbrupaL4Z4sWPFs0/4Vrc5+6Ou2hq5OaFE9p+MvXzVo/p3/goUdbt27d
o0ePd/oMnDeyc0XSKxV7u5WnB5UfDC7P7JgpWAYAACAASURBVFGWbijd/dqtlI5397/22573jh7L
OnDoaL3WbympKsQBgDgAVRgHAJ9X1egpAHxeFeIAVDNVbdPvsdc+zs49fXhXXKmxQ8nqlkXxz19f
8Pz12GevzXr8WlTz0mn+qZH/euzJ/z7xxBMdO3Z89913Q4d88vng3oU/vHx7n6E8g1fVoLJ9XUt3
vFq2s9OtA93SUuZeuXazW5+hNXlJBVUFVQVVBVWtVqpao23fiK9nZOecOp08/Lbx1ZJV7YrjXiqe
/8L1mP9em/FoybQHznzVvPVz+qeeeT6oe/eBAweO+Hxs9GevX9/yyu193cszepQf6FGebijd89rN
Ha/ey+x6Ysfgn85cSN65p3brd0FVQVVBVUFVq6eq9mvQ7oPUtIPZR1Kv7ulTvtVwY9UrxXGtiua/
UPSt/tqMR0pn/jOu/5Nt2nfo0fu9ocM/H/vp4PRZrcpSOpfv616eHlSW3r0steutna/d2d+lIK3X
/lTjteslz77+Yc1XBoKqgqp6tqp6YxwAUFUvUdUabfu16j0498RPh/csq0j/qCyx9821XUuWtC9e
8GLRHH1R9L+vRz+WOvo/0/q1WDC81YEZL17b1LF8R7eyvYay/d3LUruV7u5cvqdL2SFDRsqsm2X3
x0XNrtnuY1BVUFVQVVDVaq2qNdr0HTpmqun46VN7Z/x1NKws5eNbm3rdWPFaSVzbonnPFc975tai
FiXxz11f1urWxo6lxm6lOwxlu4PK9rxeurNL6e6u9w53y9n1eeHVm5mHj/m1fJOXVFBVUFVQVVDV
aqyqbfvVafPhsrWbDh0+ci5j6v+OjyxPDS/d1ufm+p43V3UpWdbhxvLAm6s73trQuXRL99LknqU7
e5Xu6lm6q3vpbsP9Q91/3t33199+vXHj1qOvvFUzcACoKqgqqCqoKqhqvxptQ5q9/EH6gcMZGWl/
HJ31f5bJtw+NKd8zrNQYUrr5/VsJb93a/OatbW+VJr9btvOD0t3vl+55tyz17ftHev+W2ud47tH7
9//u8PbAmoH93amqcXzAlL5uUFX+qSprxhJQVVBVUFVQVc1UtUbbkGe6h2SbTqTvT/3dFPt/5+fc
OxF1+/BXFWlflO+LqNg7rHzvkPK9g8v3hZanDSzP6M9lf/zLvoFHD+//n9X6wdCRNdv1rRk4wDtV
dUmi/UFVUFVQVVBVUFUNVbVG25CWvUJzj59KT0//+Wj8/+Ut+uuX2Ls/zrqTG3U7e+Lto19VHB5T
cWTk3exP/zoZ/lPq54cPHygrvzt01ISabT4UJNUrVRVmAEBVQVVBVd2mqjXahrwYPPBYlunI0SxT
5prbF5dZ85f89dvC+2e/u/fTrPuno/62TCg79eWRnTOPn/jxz8KrH4WPrNn6A1FSHVJVLOD/ALuk
jp/+m+T7gZiqxiWKP4mq2mq1GD2AfxFAna5DQvhnWNMX21VVeCY1YzGvqq0kz/4nTkNUlX9iVfhp
OqgqqCqoKqiqs6pao23Iox0/3Jq080ezJW1fypmcVaXnl945v/D2LzG3fp5tOTQnPXXLuV//+Pnn
M23f6Fuz7Uc1Xx7gjKqGJBLh/rL64pIqPObfV1RVlPNJLTsTEQD4AAKrJ9bpOsRvaraV46znk1sJ
qmqLtRo21M8wVAytYsM+DyCGU7H/tG4KqCqoKqgqqKqTqlqjbUjd1u99On7GqVPmk6dOm7IPHz24
60hmSk72wR9PW3797ff5i1f4t36jRvv+NV8e4KSqIjMAtoD/A+zBVbP6vja41muD+TArZ1ZNsKvq
mVUTancOqz1QCP3Xt7PkRQBdkBcB9Os6xK/bxBnnOSFkdTfbiwDOJ7d6fagQTfV8cithBmBJoi3G
ivDThe2thBmApcJPoKqgqqCqoKpOq2qNtiE12vZr/vJ7kV9Hbd+191hWTk7uyYzMw9HfLdR3eqdG
y3drvDygBi+pLqnqIiTg/wAhuKo1LU5pXjU+0a6qrBcBhA7x6zak1Zo8K/96lW7C4DRx6lC/14dK
olWhew3B3gko/jQzHFQVVBVUFVTVFVVtF1KjXf8abfvVavluvZa967/Uq86LvWu0+qBG+/68pLqk
qowZAO1UlUucIokEeD65lT0k4OsyqsolTmOpauW8uRpUFVQVVNXnVZWnPYrLqvrSiktWjjuz8pta
r4bW6m+76u+EzwDwwVWtaXFyqmp/EQBjDUBIOmfl8masMVnt7wS0zwBwphByDYD9J1gDAKoKqgqq
6l2qisIvAyDvVvEvAmCrKutFAPaVVYPtL6TKmxEmrqwi71ZZLyS3Ytytsl7Y3rrHsLo90JDVoKqg
qqCqoKoeoqq1Og7qu992v972VpVtE9WsrKKoKvVFANL1qsISq4zF2HpVRFhtksqvrEKE9cL2VsJY
FVQVVBVUtbqqqhUSJEiQILmQcFW1mE0AAACAK4CqAgAAaAmoKgAAgJaAqgIAAGgJqCoAAICWgKoC
AABoCagqAACAloCqAgAAaAmoKgAAgJaAqgIAAGgJqCoAAICWgKoCAABoCagqAACAloCqAgAAaAmo
KgAAgJaAqgIAAGgJqCoAAICWgKoCAABoCagqAACAloCqAgAAaAmoKgAAgJaAqgIAAGgJqCoAAICW
gKoCAABoCagqAACAloCqAgAAaAmoKgAAgJaAqgIAAGhJVahqjEGn0+l0uuCYqq+/HMZwvT48xWyy
mKODdQGRRtav3uMHb/G8hk6uVGj9xDOJMeh0On1EghtNsNoO/z462Is6pDoUVNXJPi13MLih59nN
aXsQ2nOLMej0AXjODtmilNDmB/X5uFpN7TxfaWLnXaoaY9AFRXtDvaKDdYZYsyk2yCZn7igPnyeZ
M/qNWAYfwj2qKu9rnSFW8zzd0Udt2aZEGChi5JyquuIHF6vpDs+7G69SVXo/8Yp6uU9VPb/ubsBB
VTWG6/lrSNuoJyUiQPhCuqXkNBUZpJNcdUYH63Ti9mJuhljbXpFBOp3OEGsM1+sNwXp+x4RIvXjd
KloUyiD8qtPp9EEGcTRHz5mWD7OOkp+k40TsV8wnFFtkCSV+EK2IXwbHaFZNG8qeT6G3Hd8WaLYU
byj2B6E1me0otUgegYQhO7hFZnMYYpHzijBeo27PdAVaMLqrlRtF0pT2a3A1LlLvXrIWckcx3rXE
yrLcTvMktUFTKC3IaCn13cnjcUhVbR1R2uFs38QGEQeDMVxv73AxBtGVEhERe09QtEW6vTFcz3s2
xqCzf8A8a7/gwi+NZXPm82GVXDrLQ+ma5K9Un7BrzfyQEKlnXAq5Uk3sWJLxPCklSFsQ3mPWndEf
7EdOjEGHDZn5Ckqt4GUmDCE5Sy3KNof0elPwKm17GVcgdqmuVtcodKVT4yJ17pVTVZozUe2zVZbt
doonaaVFuorSgaO+O3k8jqiq9GwjnIr5ERBRYVYHpX4w244NldtTT3rSD6pyli056zPjkEN8or4W
rDKT3na+mrSqqdlRjR8c7Q9m+7FqG8tIK0gWWMbJ4jaoRfnmMIsSEBtElIHVfDIFU/ys2B8ccpF6
98awewLVmcy+wXI74Umyx2JdRc2Bo7I7eTwOqip9HE5U3n2qKj0tq1EoBblhlJz1Wc0hp4mqalxN
9iHtoqo61B/EXwMiY4gKyqsq3RBhUUGtTBZzQqTeEGuODlajblWrqqSLHHKvjKrKVEe+CyEQnqQ2
qHMHjnx38ngcnQHAp5CChYmhhEi9ZOZFjaqquQ4lP0i2SYkIkEzQSE+5qq5w6SWX3CgX80dyxn6l
+IReC9agQPiAzgBoVU16r6VepQq9VjCn6uziYH/gPyNzCAyLeJnZi29wi7LNYTMXHGSwTWjStpdx
hXwrO9SrMZlQ5yIH3IvVQuYopvZP1pYsT7IaVP2Bo6Y7kX7zSJRUlbxSoFyS6HTY2jdVqirNjXHP
hPYh1jbxL960sX0pfxuH0Edayc3iok5p/mIO5K9G2oUP0d0pJSQ/2LIJjtGqmmwhQC/r7LcFhMxV
qaoj/QHrSGQ7Ko6hEEPIoYhYlGkOsTDYpCSSs5wrWM7EBoMqGkVoSundKkUXOeJevBa4B3Bn4l2L
vSXLk/QGVX/gqOlOvqGqAKABCteSgGsuAvd6GKCqgPuBw96tLgL3ehigqgAAAFoCqgoAAKAlHqaq
joT/iA3SUR67hquhagU0tzv84HVReDwMFWsAJMoVG8R+dMyBlW4sHA04gi2KcsW0G9CqJFWSj/vc
qG3O8rmxfnX0+8r0T+V4VW5774l/5Kkorlc1BOuli3uJ0E3UdnLOd5osm/C9ZgNV9cDcPK2baVge
d6xe8jR3uRnlpwBiIwL4xWKxQbrgCHL9IBGgISIaCR7B3hK9xCACjhjD9cxYIZTAE1j7MTdAbQmh
KKRr/Ui71JLg9YoORlbVSZ5vUcwf639MxyY4XwU0H5pzpBkmONOCyNFIxi7hf3I8kAe1KSmLUmmx
eCRLJqnRYdDgHcyyyUW6If3DWN6Lx2ehhiNRDP5CNj3a7cntfTD+kcej5tmq6GD7g3fiEnp2gAbk
MztAg0z4D7stmVgh0nyks6vkWRGP/oDFMVEZigUrCcMDOkOs9DkQ20pm1TFQlBzrdBXo+didQ8R2
caoFabFL0ILh7lIVyIMoLRGqw8iIxcPqSOL3aPAOetlofUnGP1RVlZ+jFJ+pVwr+worCwzowyTqy
CuY18Y+8AFVPrPJPTSAnf500yT4ZRW4pbRJKz2D3Tmxj6UmVmon8BuS/RtUPxTPqxZ9dkWf41ORP
rRTVsU5XgbIZOiSROcOpb0EydglWMDXlkVpRLC3mZGoXYm7PfqBepl1IQ1jJ5fuPfB92KPgL2V4U
N/pc/CNvQF0cAOyQoDat4pEsIn++VaGq0kOaKjGKG7CKrV5VqZ1b+uIK51RV3rFOVwH7oBjZxLkW
lIldoqiqrPGpfGldUlXehOToZQqKUqQb+QOB1ayULupI8Bfye6YbfSj+kTfgeNRq22mEGaAB+UzZ
UrwYpPYM+SYn/sWDRxD7EtElVFw+K6oqPfAEf/2FrWRwKAaKkmOdroI0H4pzaDMATrQgO3YJMgPg
UCAPSmmJUB3OqapM8A5GG1Ei3WgRn0XaRRWCvyjPAPh8/CMvwDlVpQ3y0YAR4md8S+ldKUbYHkVV
ZcRYkW7J3AAtPOtWj5Kqkh6QdGgscrBi/oyyUR3rZBXQfCjOwTJ0rgWlxw9eTjwMh/pAHpTSYqE6
nByrUoKVUMsmF+mG4h918VlYXZTpQEoIEtm7Vb4b/8jj8bCnAAAAALwcUFUAAAAtAVUFAADQElBV
AAAALXFZVZmLORRReH+D2+xqkYOae/fuKzngAvSgPID7qH4d3sE1ACyXOe448TGSqmoq7VQVqYtM
to76CtnS+9aXuNou7joafciTlSNYLloBVfUal3mSqjqWrQN2Jcd/9ema1aem1cRXXlFITVExVjWG
6+Vii2APERLRGeRWepLBMmRDQpB2qSEqVIZpYJdHvXViX9kgJuhYVU3wiBRbaBtLjIF42x1zCSG7
vkI4DFo7stfqKof8YEXMMeGhQGjmmFFgJIs9qbFR5BpR3Es2oAnSskqhYdS72omKKxxljgfBYXgA
qbLK8CjOV5axu+aRBj0MdapKiS1ChLfQo4/oMJcZkwEjVIeEIO1KS8s/Q02WlpWbBtZVBkORlE26
NF1N8Ag87oa6J8FY9bX3Zv45BXUPz6gI+SEpLVJ316LAiNWhxUZRbkRVAU3sKIeGUe9qd0XwcSQI
jqIH7P1BMTyKw5Vlh5thON/HUDtWVXjWSKZzUzqiNBliyW/kQ0Jgn5mjZuwhDXaACaetU/ZlPZoi
KZt8qXB4l/KPh5OZOxKWAunc0cHSWIVyuakI+SHmQI/KSHeg+ufK1XQ/slNRrwCwFpH+pBgaxklX
q8vKuUpRjwJ5D1D3JT9QjinVlWWVRMb5vkVVqCqrZ+CwQwohPU8p9IZ8bi5aJ/dF+hCtbPKlIogN
CoiMCdfjAehkhUmx/A6pqmLID2EbWgSDSlNVNZ2KbBG8CrKhYZx0tQuqqlgp0mnyHpDfV80x5VBl
serIOd+ncEpVmeEtaDMAWKQJyiIk1SEhZMJqUCNZ2MogF2DCFevywVBYZWOVSuIrhBiDDolDSl5L
4rE8ZOtryxMtPzM322fZkB+seCtaRIGhn0qVOpX8CY8Sc0eumg672l0RfBwJgoN7ICFSTwsFQH5g
91tHK2thVJDqfF/COVWVDW+BDvLxSBO0bYhv2IEVMLtkKAdG76TkxiyzA9apFzXMICb4uB61wlJV
6RUAYhEJ6iopFbu+9qIil+3yuZkoZWN7TCY0qsNRYJgNqqJTMUZDcjF35KrpoKudqDjzBIP2Lixb
mSAvuAeIt1GxVJV5TDlRWaQkCs73Idz2bJWvD/K9D2iR6oyv3yDyKEBVqw3QItWYlIgAlx66ARwB
4gAAAABoCagqAACAloCqAgAAaAmoKgAAgJaAqgIAAGiJ76uql8XTdP5OvWvxatVkSC8b3a4Hud2J
544AZTTvb76D76uqxvE03X1AOpu/k/Fq2Y88UjKkPUnJtusBYUzVP/pZrVBZfdnNXI2P7NNUB1X1
KqrqgFdj10vFCFRV0SGApig9sapt0ElxX34UEx2MPK/Jx/tQigFK5o9nKyIXT5P2yCAe4FKygRCq
kllHpwLLUjzjSKWYW0riXUbI1NReHdlInZjTVFRHO7c73BmQf0UT9nzQeFROOxnzoWIIWrmK45FK
2FFWWUFp2Z6n9ENWW2OZs7u6TDcGzCaLoqpqGnSSEY1UiHRnjzCiIgYokj873KcU7Ik9erGJWJ/2
Dch4skgZnAssK/WMisitYmHkq49Gu5CvKWUGQNY08lR4Jbjdwc5A/qtHoiWhIXhccLK02GpC0MpX
nNrT5CLgMDxGep51dpcMBZiZ07u6unav3ijNAGgbdFInTchYQxyxiu3EiFaH5c/IlmKUFAjpZ2r/
Y22M19GpwLLyhWFWSqn6ioWXP9IUy6lcQje4XWVnIJ1DmtBJ1VYjJyuGoJWvuHr/yAUkpHlesa0d
PZzl2x0wmywq5lXdFnTSToxB55iqovnLnDClgx3ntIa1MV5HpwLLqiwMHXb1XVdV+XKqqY7mblfZ
GajOkVFVrZysGIK2clSV9LwGqqr6cANsKN+t0i7oJHUpBq9HtjBl0jZjXwGh+bNXeEhyw0M60ort
gKriZXAusKzUCSoit9oKoFR9YgZATU3FzZT8KRnCVJ7bVXaGGPxfTFnQaSsXnEyIi0IIWvmKy/Q0
lUFpWZ6n9EN6W8tM6CkfbsgZDlCzBgBzmXgJ4FLQSVw7+Ikz5PqCFQOUGpmUdr0pG9IRL7ZjY1Xl
MqgKLGtHXeRWi8rqS74JjlFbU2akTswPiBC72e0Odwb0X/EMR/jHRSdTR6NyIWhlKy7X04gqy3iM
5nlqwFxaW7MyV9nfQFVFPGxllQ9cX/hAFTwE8CTgnYCqQhU8FfAk4J14mKoCAAB4OaCqAAAAWgKq
CgAAoCWgqgAAAFoCqgoAAKAloKoAAABaAqoKAACgJaCqAAAAWgKqCgAAoCWgqgAAAFoCqgoAAKAl
oKoAAABaAqoKAACgJaCqAAAAWgKqCgAAoCWgqgAAAFoCqgoAAKAloKoAAABaAqoKAACgJR6uqjJv
eyaA1xwBAOABVLWqIm8nxgU0Ngh9rz1LNLE3KgMAAFQdHqCq0vePy4xMFUUTVBUAAA+gklQ1ipYs
ZkIK7f+KY9iASKPJYk6ItP2vj0hIiQjQSX9Fx6rir5KcqQWABAmSbyer1erLqmolEkVVzdHBOkOs
8JfQWXIoGmPQBUUjqmoM19v2jQ2yZWI2kdYhQYLk26laqCrlJ6qqopOtOl4libkCcUCKjFWjg+27
AABQjQFVlfxLHZYikwP8tIAJH6WKe4G2AkB1B1TVJFlHRVtQZb+0l+ySEhGAj1WN4cERCRazyWJO
iNTbxBcAgOpHNVZV8UpfIoLYNb7ZZDGbYoOEu1X8B51Opw8yEGNVfpQqbFnl7QoAQFVRXVUVAADA
PYCqAgAAaAmoKgAAgJaAqgIAAGgJqCoAAICWgKoCAABoRteuXUFVAQAAFFD/rCqoqpcAYbF8iRgD
Nf4k4MmolJFqr6qSBf+Vum6f9QCC/C4+H8i1ymsnH0/HlfLjD/LBo3feB6gqYoZRPWnnjg4Oiq68
yuPhWlQEDahyxakOuM/JTrQ44GGAqiJm2KpKdG4suKoxXK8PjwzS6YRwVvbtbfvSthcPHtvoUshB
agUZuQg/4cFbzfIhspCsqKFdbTlU3sgIL4ZD/hTrJT77GxxDRryVrazeEKzndxQC4wpX2UQmcoF0
JY8jR9qeUSbyoVpXDNEbHiyzu/CDGHRC7DkydoFKAVQVMcOqnvBQvzhKJYKrou8IEF+7wgdXpW5P
qio1XIt9sxgD5SAR85cczDKqygjtKmxQaaqKF8NBfwr1SojUSz1GzUSpsjEGnf2DEKIBC5srG0iX
LK2YD9oilGZVCtFLHxGLOadEBAjeEH0laxeoFEgZieLj3xNfVmtVFeBvHdj6sSRJR0+2LYOiLWZT
bJBt5CWzvXxoQeq4gzoyJXOjHKIeEn4QLYYT/iQ9Rol4y66srD7iJcGzpe0l05osVVUTolcm2qTZ
dnJi7QKqWkVgMmKP+Y9tBqpqB7sCtYF/kxCpN8Sao4NZ9zTUq6p4qSjVIFrwVjI35jHmYdrqnD9J
VaWLCK2yMqqqUBLa7qSfpRcWMqqqKJqOqqq8XaBSkMoI9jIV6WbVW1WN4Xr7tb9kxIdcrRM9OCUi
IDjIYFswQNteOkmq5hiLMZDDGWFfyf00PJwrYYUZ2rVyZwDQYjjoT+YMAJ4JXlm7Q1iqSgmbqyKQ
Lv2aAD3zkXvJ52ymCShaHnEGADlfEnaBysUuI9S3VNk3q96qKrmHoHB3SLqX9PAgt5fcSEECsGKm
0S9TIgL4AuDBW83iwkYsN9yKTGjXylRVshgO+RPRKSGhd6t0OmpllVWVNutCm4cRAumSbWf/bGsR
NB/COivniASGqtLvViGzJUSeQGUilRHq+n/+p2quqgDgArZJ4epit9oDawAQM6CqgFbYrycqef66
quwCdkBVETOgqgAAuAioKmIGVBUAABeh3qSiJlDVyoF2X9hO5dzVhYgevoR8a6pcSaa4lwdSRd24
q4OpmqtqQqRe6aaqyt5G3ne2IT5E5Er+6qGUxLY0R70tdnU0xisOZnfUmlzJoNYPSq2pUlWl6wrw
tVwaVUrGnJrcPKYb8xqi/m/1VlVjuF5vCNbLrj1ytD3cvb0TGWILwqqkVIAILbKPQ0oh35oqVDUl
IkB64ys2iPbUhqPEGCSP2CLHFMWcmmp6Ujd2SFirtaqmRAToIxJig2jjBcmidPH0S1tUKIYLkdue
EG65FZSkyssGHJEWg4wSItlXstoRyZAI7EJmQl9QiQcfkbjOHhmEEjVGaj1CXHLPDmVC9Z73xtMj
I/sg3Qb3GOJPWmvS+gNr5azNHM2l6GpoVjgbZnQbZv40c4xie1A3lgBjVdwMu3q2xrY/EUhd+I1c
gLBDYNC3pz1Rg2YleSaHtbGagCOSDeQXw1OeX5JgXw7JfjyJUncsRgxWHjxz1DpZBWZIFOyA9F5V
JSP7sC/S8Ugr1KahRvlhx2ShDvrIAojWJeFssH+pFVRjzvO7MQqMVREzclGrZeZrZBrV3lEUt5ee
XVnBACVdSnljarbkBvLdkS5SxPCHtYtM3RULTFqn5i/vEJ/BHtmH0ruUPCbjKJZLWQ1EZot0Bizk
gmK4CSIsN8uch3djCTBWxc2wqie5XtDpqE8Tuq6qrFMfVUTUbEzN1sXuKB33qdnFIVUlM1evquyB
gw8hidUripoKj8k4SlFVqe8jEDWaGnNApbZS33TANifzTZV3YxQYqyJmZOIAiJcP/ODfSAQusXvf
1pOYITCQowLfnoCInCK3sXLAEfoFF7Nf0q7BWbU2si+dVKoqnjljBgDfRWk5mvfOABjJyD60VmPF
6MFbk9UfyD4mbsO8W0WzjoSziXEmlA/tbpXHd2MJMFbFzTBjVtHO3kTgEr4TSAaz0gtSRpPQtiem
9rHIKWba9QvSw4RECThC9AYkSgirX0oypAR2oWaiou7kv5TMpdYjWKqq6BCvVVVqZB9Jt8E9pmYQ
R+0PZB+TgFyrSfSFaC8snA0zlA/l4k/GnEyxPaQbo8BYFTHjAU8BAADgxcBYFTcDqgoAgIvAWBUx
A6oKAIArwFgVNwOqCgCAi8BYFTGjWfWqy1ofAAAQYKyKm5GtniPRVRxVVad3BADAw4CxKmJGrnrG
cAeiqzgtjqCqAODNwFgVNyNTPceiqwQZ9HIRQNTEW4mWrFumPoUCAIAnAmNVxAy7eg5GVzFSI4A4
FG9FEvcBXusGAF4CjFVxM8zqiWLnVHQV9Y8V489TG2IVQ1kDAOBJwFgVMcOqnqvRVZxUVV5PyQib
AAB4KDBWxc0wqud4dBXZCCDq4q3Yvqe+ggIAAE8FxqqIGXr1nIiuIg1RQYnvoC7eitnEDI0OAIBH
AmNV3IzHPVslG3IcAAAPBMaqiBlPU1W4TwUA3gWMVXEznqaqAAB4HTBWRcyAqgIA4AowVsXNgKoC
AOAiMFZFzICqAgDgCjBWxc2AqgIA4CIwVkXMgKoCAOAKMFbFzYCqAgDgIjBWRcyAqgIA4AowVsXN
gKoCAOAiMFZFzICqAgDgCjBWxc2AqgIA4CIwVkXMgKoCAOAKMFbFzYCqAgDgIjBWRcyAqgIA4Aow
VsXNgKoCAOAiMFZFzICqVl9iDMhrxj0X8VU9npqhpzoff6mH0vdOAWNV3Ay9epo63cuo8roz3pOo
Qfnx19l6x5tsXA1kTjiksiOjUxqU9t5iB2vhgGlyX607OYxVETOgqh6H+5xPvvW2yivr1f50ugBO
OF/bUyyMVd1qRq2qiu/1wwc44juuMhoc+AAAEJBJREFU8TcAimfjyCCdjn9ztdiZbK+npm1PvgFb
yIEsaowhOMZkMUcHB0VrUyRkQKETL9MID+BWEO8ZgvX8jgmResmFHulG/Bthe/EFi2JpqflQrdNq
Lc05IjxYZnfiBY6i82Xs0hoCbw6s80gcJTqZbo7hc2bL2n0lrXUCsxvL9TqJ20Vk+wZSC6JBJftK
3IhkSHgMrYXYUvjRhO+IjVXJ5mMf1w4BY1XEjDpVtSkg+ZOkaWODDLHklsZwvaRTihdfMQZdUDQl
Z2r/Zkw/iS/Ext997UKRhAKg7+6mZyK1gnqP76MxBp39g3A4YW6kORb7IC2tmI9EXumqKpszdUeh
msTLxkVfydo1J0TqdfqIBLn3OQqNTjiK/0k4yUnNyftctmXtxUBOk+xuLNPr8Bqp6RuSDVgtK37A
MqR5jNZexNFE7IgcU2TzsR3iCDBWxc2oUlXpKc4+ihG7lOQbckssK1vzxwbZzqUy27Nmhcwmi9mU
EhGgj0hA+rRWRSKNUjyAWqF6j6aPeElIx5J7yTiEparyOVN3JDegNofM7vbjXMZ7LC3jpxpjsALI
+lxN58E+sLqxQ05W7Bus7WU6BvOKQUecGyRgXZfcUZo/48xBd4iDwFgVMaNWVRXOY7buzhw62b9J
iNQbYs3Rway+olpVLayxqiZFUusBmrY6dPDISBvrYJAOnWRUVVE0HVVVebussap0QCrnVZqqyvtc
TeehfiBxUVXlm9VRVaV6jF54outiOyqqqrPjUykwVsXNqJ4BYFyhGMODhYmehEh9QKSR2JJouZSI
gOAgg216iLa9TaRSIgJ0im1PTue5WCQj9aKMkglqRVJy5lFEupHmWCwfyuEtuX2PDMSk1mVzxpwg
fk+bAcCEj6qP1IYgDAkNSm0IXotxc/I+l21Z0jOy3Viu11FOwwp9g1BJ+Y6BZkj1GH3oQO26RC2I
bmPLVrMVZjBWRcwwVZW8eKRexElm2cWmJa9B8MyxaVAkZ/uMu/R2jSNnVNeKhByNQkLvSOjsPZKw
In/wMK7sCMfGBjGqb/9sW+2I5kNYZ+XM37ehqKp0L2LSgGpXBbG2ez622zWy3Yy1AdPnjJaVfEZq
zSi/XK+jdxh23yC2RxpUqWMEx9A9JtaCfTThO2InZlvzISVxvEExYKyKm4GnALwb8jaFF9nV6AoU
qHJgrIqYAVX1RuxDElfuMFS9XVBVnwDGqrgZUFUAAFwExqqIGVBVAABcAcaquBml6nlAHArNkQ9s
obhQhopXXMx6eDgVr/ChJ+CODuwaMFZFzMhXTzkORZUcCZIbl+SaEiWUAluo7JTSu+H4CiSNKiVj
Tk1u+DpHFyJ6OF+7hEi90s1lp61oUDzX2stpo57QgbUDxqq4GS+cAZAGW7KtjnRIKeTvtKjolCkR
ATpkOQttRbqjCOs9sQoyzKmppvyCNpW+cv1UoTcE62WfMXddHL1skFv1HVhzYKyKmGFWTzyd2k+M
tIghtgajhxqR7KWTLi/Hc3YoeAr5iCoSe0I2f1pgC0pN5Zfy2Zb90zouGUkE8wwzJgszf5o5RrHd
FdGDsrwRi70itq8U/qni2CDaiEyyAF5qhR1Hhoj2QuYQES1ZTk+EOmTHf0HbkR4Zhx64RLFBPbED
awyMVXEzjOpRA0bQIoaIv9JCjdj3MtvCZ6AdjojfgcB6IFVY34PF6aBepJP54yMjVngXdiQR6mCB
LIBoXeIZlqNksqKPTSo3ogfhE0rsFUpQFdv5gBLohLkSnhVHhmKROsi1F56yolZF/BdWP6e2rEzP
9+QO7AZgrIqYUfFslQ555hr7IGlCymATaU7JfJD0FMpocnbwFEmfs3dN7HCVyZ8sP7Wm1OOf+i+Z
LTJAwDzDjsmCeUnRHKuBqNVkNhwjT8VdjLKxV/BvaFOBMiV01CLezQyx7FsC9PgvKv1G6VfMBvXc
Dqw1MFbFzaiLA6Dy4CR6GKmqMYwAELTiyQZPsedJPqYpm78acVHolLQo+tiInlJ3NdpKjc/PNifz
jaOqSi25a6oquZLV6aiPybpFVXndpGqZurEqq+5y/YreoJ7agbUHxqqIGfYMACNgBLVRyVAjZHMS
4TOcDp6il34W+yL+IDk9f7wirJqSoSjEbZh3q2jWEc/EMBxlRg8nFNrdqsqN6EH4ihJ7BW9HNH97
62NBTBht55hFTLaM4XrGOgpiitOmsyr7OdmvWD3fszuwtsBYFTej4m4VehlC721E2AsyE3H6ybal
k8FTxKl9aQBze+wJhfypFaHWlAxFIQEZiEmOdiIuBuYZhqOoIzsZczLFNqMO0SSih+zdKnXzJMJB
jgcxoVqhF1LOIhp5hCFwFNjzLcQHRr9iNqiHd2BtgbEqYsa91XP/pQcA4Mhc4JNbVklsGt8Cxqq4
GVBVwMdQ/wrVlIgAD33MzNuAsSpixgufAgAAwIOAsSpuBlQVAAAXgbEqYsaB6nnF5TwEEHEA6kIu
T0WblvXFaEFVDYxVcTNy1YMAIqrw2gAiKu/VeMSZwPGWpaF+yhVwCBirImZY1YMAIo7k4JUBRFIi
DKoGqp6gqk60LFBZwFgVN8OoHgQQ0flUABGZWmBOxpsPCfwhyU0paI5cN0AaRYXD5UOKMN4DiPQW
SjUdKQ8rrhA9DouMLXbkFGm7SMoTob4WVQmMVREz7DgAEEDEhwKIMGtBdTLafPRrAjVBc6jdgPna
ZzmHyzxQhDyNwuotRDUdKw8jrhA9DouMLaqXsMoSz7ypqkVVAmNV3IzaOABmXBokAwcIIGKiT/zJ
lNBRi4hpxwOIyHzGnKwQzIH8hhE0R1XAHbIwStWX0VAFx2LVdLw8rDKQ37NskT1QvtjKjeUuZXAU
GKsiZthxACCAiA8FEFGjsHiL6CgPiVL2YgTNYXUDTVRVWjv1Oks9CtyhqjK2ZCKnqFFVjxmfSoGx
Km7G4btVkqaFACLeEECEKDmhepiT8ebDTGM5sIPmMLqBiitu5dOS5DQsnuxRt8tXk9WIMuVRqaoy
tmheIirL7LSevCwMxqqIGZnqQQARnwggQhSVcnKSOJnWfKhp7FKUETRHJuwI2iiqqk9+kK7D04en
mAm3K1TT8fKoVVU5W3KRU6idNkJ1LaoOGKviZuDZKq9EfQARd+BRl6IQIcUDgLEqYgZU1Rup4tXs
HqCq9kGfR920ARTp2rUrqCoAAIACVnWJ1zVQVQAAAAVUygioqg3xcs89wTg84HJSrhgeUjxNkAYo
8aV6AVUNqCpixgFVddNtAZWHN2PlpsbFUFib6dWgzyn4Tr2AqgdUFTGjXlXVBuNwFEdV1U34/FiV
XPHqG/UCPABQVcQMs3qMlXG08BBooA36N9QIEXj0CkpgDk3CoCCCIjySRI1zgSxCxKovfkM+bouH
GlFeg4n5RIQV6UPJqLyTyQAloKqAdthlJIqW7JtVc1UloleQ24jhIdBAG/RvkHg89OgV1FfsahQG
RVyKRM5j2Csiag1ZfXZgC7K+ap4XQnxih3zOR7VReSeTDgRVBbRDKiOYpPJ3/+0/VWNVVf8oDv5E
XUBkjOw3WM7kc9/4UEujMCg2MY0NkjzpSFaEmrlNBCWJdSlNqy+1bFRRk3G1o0apLgVVBdwDJiNU
SbWAqrIPUXZ4CK1UlbRCfnBUVc0JkXpDrDk6WLycp1VERlVZGuRWVXXaKKgqUImQMkJKqqW6q6pk
ERVyVS45FCnhIYhAG5RvZK+O6d+IOuh0GBRhs+AgAxlbGqmImDlWfVUhM2RDpsrE/rDDjPShbFTe
yWa2qkrKBgDOQZURqtRWZ1UV1zYiAUGo4SGwS1TqN/QLW8bFPiVUh/ilM2FQRLvSsFhERaRaQ1af
Vk4Ltb5k2RRjf9ByQ+9WKRmVd7IZVBVwI7AGADHjavVIdahul5ZVUt/q5mTAswFVRcyAqroKqCpQ
7QFVRcxAHAAAAFyEukyVmkBVAQAAFOjqYAJVBQAA0BJQVQAAAC0BVQUAANASUFUAAAAtAVUFAADQ
Et9XVUiQIEGq5OTLqqryHV6QIEGCpG3yWVUFAACoJoCqAgAAaAmoKgAAgJaAqgIAAGgJqCoAAICW
gKoCAABoCagqAACAloCqAgAAaAmoKgAAgJaAqgIAAGgJqCoAAICWgKoCAABoCagqAACAloCqAgAA
aAmoKgAAgJaAqgIAAGgJqCoAAICWgKoCAABoCagq4E1U9ds6PCh17doVXOdcctR1jgKqCngTVnhT
r9lksR234LrKcZ1zJjz6bYDudgHgRYA08ICqVqbrnDNRGarqsS4AvAiQBh5Q1cp0nXMmQFUB7wCk
gQdUtTJd55wJUFXAOwBp4AFVrUzXOWcCVBXwDkAaeEBVK9N1zpnwMVWNDtbpgmPUbWwM1+vDU9zp
YkBDtJCGhEi9Dkv6iARnsqq6zlMFqhpjEP0VFO3G2rnZq9VFVTdu3OioC6THBSagsUGSb2RaiP8J
VNWr0HLA5c1NX8mqmhIRoNMZYm3/xgaJn7UHVFUlMi26cePGWrVqsYSVqap2vxvD9TIjU8UW8uZD
qxriRlU1httO1QGRRuHXyCCdTmeINYbr9YZgPX8KF4a6wTHIiTkyCD3Hy+SmReErV1UTIvUBkUaa
A4U6GmLN0joi/lHwjNnEX1zathGvJPQRCe5wo++rKi+pfKIKq7KqmiWHB95gSAulRAToiBayj1XF
X0FkPRi3qWp0sP1AtXcMRAgCIo38VbDtg73zSLfkv5fPTQsqVVWN4XqKionzbCkRAbqgaAvpBzWe
MSdE6lHPiO3iFjf6uKpKJZUlrKpUVfA+2WCMoWiMQegEyIEh7OveqxvANdylquL52Db4wn7FuhPW
ebAt5XPTgspWVbLwuPdoHnPOM5RBkpZu9GVVJSWVKqwOqCrZBpS2tyX8kOCvQUBPPR03qirr2DY7
paoyuWlB5c4ARAfriBkAp1VV0TMyQyJQVfkW3chOalxAmQGQP6PaL+LM7EMCtNXjcecMAOs61HFV
lc9NCzzgbhVtBkBRVSnrc2gzAIItt7jRl1XVRRfQjgfagip7C0naIyUiAB+rGsODhbU1jIl5wDOo
lLtVkksZbEu1qiqbmxZU/soqyW0J28oq2t0qJVUlPIN+wx+/sUHCvRB3uBFUVc3KKokIkg0maaFY
271IfZCBOCTEu5BOLl0EKgVYys4DTwFUpuucM+F9qgpUT0AaeEBVK9N1zpkAVQW8A5AGHlDVynSd
cyZAVQHvAKSBB1S1Ml3nnAlQVcA7AGngAVWtTNc5Z6IyVDXK2QSqCtgBaeABVa1M1zlnwu2q2tW1
VOUtAXgIrpyefSw5oapVXWRPST6iqgCgCS6enn0sgeucTm7tpaCqAAAAWgKqCgAAoCWgqgAAAFoC
qgoAAKAloKoAAABaAqoKAACgJaCqAAAAWgKqCgAAoCWgqgAAAFoCqgoAAKAloKoAAABagqhqVQQ6
gAQJEiRfS6KqVlJgA0iQIEHy9SSoaqfh02xEdfok6lWBqa8OszOl47ApHcN5JncMn9xx6OQOQyd3
GDqpw9BJHYZM6jBkUn5+fklJSUVFxb179+6rSPfu3auoqCgpKcnPz2/RuRfggQR9PGThyvWbknb6
HhsTd3wybkq7Nz5s0bnXiG+iVm3aVuVF0r6Oxh1L1yW8NSiiRedez3d7y9EjFJIr6f8Bsr6jdD+9
yJkAAAAASUVORK5CYII=
--94eb2c074232cc50b7055deb7109--


From nobody Mon Nov 13 22:59:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026FF129470 for ; Mon, 13 Nov 2017 22:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4vl-vkADxbC for ; Mon, 13 Nov 2017 22:59:13 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9337127977 for ; Mon, 13 Nov 2017 22:59:12 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAE6xAU1189730; Tue, 14 Nov 2017 07:59:10 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 38C3720118E; Tue, 14 Nov 2017 07:59:10 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2B8FF200B5D; Tue, 14 Nov 2017 07:59:10 +0100 (CET)
Received: from [132.166.84.60] ([132.166.84.60]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAE6x7GM017704; Tue, 14 Nov 2017 07:59:09 +0100
Subject: Re: ESSID ietf-v6only at IETF 100 - security
To: Warren Kumari 
Cc: IPv6 
References:  
From: Alexandre Petrescu 
Message-ID: <88d14301-f417-da89-a526-954f44149af8@gmail.com>
Date: Tue, 14 Nov 2017 07:59:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 06:59:15 -0000

Le 14/11/2017 à 07:24, Warren Kumari a écrit :
[...]

> ​Nope. We have the legacy SSIDs because some people apparently had 
> issues connecting to encrypted SSIDs (because of old OS / broken 
> wpa_supplicant, etc) - this wasn't issue with certs, but rather 
> providing a solution for those who are unable to do WPA enterprise / 
> have old cards, etc.

Well - sorry, but all these reasons seem light for me.

I have Windows 7 which is not old.  Updated regularly from Microsoft and 
from employer IT.

The WPA_supplicant comes from original.  It is widely accepted at many 
other hotspots.

My laptop is very well able to do WPA enterprise, and WPA2 Enterprise.

The laptop is a Dell E7440, 2 or 3 years old.  I dont accept to call 
that old.  What makes laptops old is when they break; they often break 
because of mechanically moving parts like hd, but this one is SSD.

Rather, I suspect there is a preference at the Access Point to favorise 
Macintosh variations of WiFi Clients, rather than Windows.

I also wonder why my Windows complains that the cert emmitted by IETF is 
"not configured as a valid anchor".  Should I manually install that 
cert?  If so, that is little reasonable to ask.

Alex

>   There was an assertion made that some people were not using nat64 and 
> were using ietf-legacy were easier, and so there should be parity, and 
> so the ietf-nat64-unencrypted was created.
> We are changing the name of the ietf-legacyXXX network at each meeting 
> because we don't people who connected to it at a previous meeting to 
> become sticky to it and keep joining -- it requires a specific action at 
> each meeting for the user to choose the unencrypted network -- we'd all 
> prefer that people use the encrypted network...
> 
> 
> 
>     And yes, my VPN FortiClient works ok on ietf-nat64-unencrypted.
> 
> 
> 
> 
>     Alex
> 
> 
> 
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org 
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     
>     --------------------------------------------------------------------
> 
> 
> 
> 
> -- 
> 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 Nov 13 23:26:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B13126DFE for ; Mon, 13 Nov 2017 23:26:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koaT0hvZXSXT for ; Mon, 13 Nov 2017 23:26:48 -0800 (PST)
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 3B2AB124B18 for ; Mon, 13 Nov 2017 23:26:48 -0800 (PST)
Received: by mail-io0-x22b.google.com with SMTP id 71so7781126ior.7 for ; Mon, 13 Nov 2017 23:26:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CqOPE2nomva525wsvWjE7vkIJ5Ig5O9ey1+yZAgMUOI=; b=eb0GmZYsKDhBtVgIznrt6k8Wu9WjbIUOW0Z+7iZmsbpq10jhlCN68reIWy7MbdlIJX XDJ9OO8EU14ahDoM/8/p24kCxa99EqOp+T41MXgmeFWXKkHg02d2+TJgVTHbo6+ey1b6 MXCXLo69XCg2Q1qeEbzuGL12joSUrurm5a5x8JwvvjcWHD13RgqxRu7wWbjZjU1CWGX5 D7pmBBtJjH7ZmL9qF2kF3zJZKMn3UMqv7o7omPNiwK2Sbd6UUGfWKyYGjwGCAJ6Fz1hw xWmxsHchWZ8uHeBy/qPz1q5tVaPOOfbPYbglbb9h7IhkdWqNxwyL9VQzqCBT/ZW0DJEk mIRg==
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=CqOPE2nomva525wsvWjE7vkIJ5Ig5O9ey1+yZAgMUOI=; b=ki4rRPQShuhjZ/ftVpMAWnCblZNumuZjsJsUSUKv/W7kyPR+fuqAjzQTrR84Lz1PO4 y64sU/raPoloAgKTvE2eobMjWtrCpXL+9rZ7qbIxp7Ea/EkI0ONraztRV0oR9szi9bLX r3wODP4LX0dAbjojO+FZ7a+XYDpKavm2SEARXMqemPFafLRtv9lJ+qTlCPQJ4hI1hnn5 h3vZeerytQpgvBtCYixnLjXiLUKRu3APfJp5Sb31Yc2dDNWJlbo13NDu+RYm5z826GxR wNDndz2MT1LS3Yz5Aqm+Qf7UJPTMyqYMaPra40//XkAUgLE9vAy9TExCd9L+fycClB1h +gUQ==
X-Gm-Message-State: AJaThX4dI5WByzstW0RrU9s6JHg1+vqZiFbp6eLhsFYCGGBzDCg1WZic uY89qB5FkfRl4ftcW1OoKJOp1g==
X-Google-Smtp-Source: AGs4zMZ3JaOdFdIvuirTCQIjyJ3tcrYdtIgsxqveEm5G8toPmmQiiGf62Ueq8/S1Py8foVR/LZ7OKg==
X-Received: by 10.107.205.8 with SMTP id d8mr12694007iog.119.1510644406364; Mon, 13 Nov 2017 23:26:46 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v198sm6594623ita.4.2017.11.13.23.26.44 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 23:26:45 -0800 (PST)
Subject: Re: ESSID ietf-v6only at IETF 100 - security
To: ipv6@ietf.org
References:   <88d14301-f417-da89-a526-954f44149af8@gmail.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <30891ba2-01e7-70ec-4fc3-1a32038dde12@gmail.com>
Date: Tue, 14 Nov 2017 20:26:43 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <88d14301-f417-da89-a526-954f44149af8@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 07:26:50 -0000

On 14/11/2017 19:59, Alexandre Petrescu wrote:
>=20
>=20
> Le 14/11/2017 =C3=A0 07:24, Warren Kumari a =C3=A9crit=C2=A0:
> [...]
>=20
>> =E2=80=8BNope. We have the legacy SSIDs because some people apparently=
 had=20
>> issues connecting to encrypted SSIDs (because of old OS / broken=20
>> wpa_supplicant, etc) - this wasn't issue with certs, but rather=20
>> providing a solution for those who are unable to do WPA enterprise /=20
>> have old cards, etc.
>=20
> Well - sorry, but all these reasons seem light for me.
>=20
> I have Windows 7 which is not old.  Updated regularly from Microsoft an=
d=20
> from employer IT.

My Windows 7 box is a ~5 years old Samsung and has no problem such as you=
 report.
It is patched up to date as far as I know. I seem to think I had to authe=
nticate
the first time I joined ietf-nat64, but that was no surprise.
=2E..> Rather, I suspect there is a preference at the Access Point to fav=
orise=20
> Macintosh variations of WiFi Clients, rather than Windows.

I have seen no evidence of that. I expect it is a problem with the
particular WiFi device and driver built into your Windows box.
Go and see the friendly NOC staff.
https://tickets.meeting.ietf.org/wiki/IETF100network#HelpDesk

    Brian

    Brian


From nobody Mon Nov 13 23:30:58 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FDB12948D for ; Mon, 13 Nov 2017 23:30:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQlaJ-vHQYPF for ; Mon, 13 Nov 2017 23:30:55 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3B312945F for ; Mon, 13 Nov 2017 23:30:54 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAE7UqRK004496 for ; Tue, 14 Nov 2017 08:30:52 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9B40E201241 for ; Tue, 14 Nov 2017 08:30:52 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 925D4200808 for ; Tue, 14 Nov 2017 08:30:52 +0100 (CET)
Received: from [132.166.84.93] ([132.166.84.93]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAE7Upfg004654 for ; Tue, 14 Nov 2017 08:30:52 +0100
Subject: Re: ESSID ietf-v6only at IETF 100 - security
To: ipv6@ietf.org
References:   <88d14301-f417-da89-a526-954f44149af8@gmail.com> <30891ba2-01e7-70ec-4fc3-1a32038dde12@gmail.com>
From: Alexandre Petrescu 
Message-ID: <6d39ece3-2a00-bd8d-cc97-25eeaf4ebeaf@gmail.com>
Date: Tue, 14 Nov 2017 08:30:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <30891ba2-01e7-70ec-4fc3-1a32038dde12@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 07:30:57 -0000

Le 14/11/2017 à 08:26, Brian E Carpenter a écrit :
> On 14/11/2017 19:59, Alexandre Petrescu wrote:
>>
>>
>> Le 14/11/2017 à 07:24, Warren Kumari a écrit :
>> [...]
>>
>>> ​Nope. We have the legacy SSIDs because some people apparently had
>>> issues connecting to encrypted SSIDs (because of old OS / broken
>>> wpa_supplicant, etc) - this wasn't issue with certs, but rather
>>> providing a solution for those who are unable to do WPA enterprise /
>>> have old cards, etc.
>>
>> Well - sorry, but all these reasons seem light for me.
>>
>> I have Windows 7 which is not old.  Updated regularly from Microsoft and
>> from employer IT.
> 
> My Windows 7 box is a ~5 years old Samsung and has no problem such as you report.
> It is patched up to date as far as I know. I seem to think I had to authenticate
> the first time I joined ietf-nat64, but that was no surprise.
> ...> Rather, I suspect there is a preference at the Access Point to favorise
>> Macintosh variations of WiFi Clients, rather than Windows.
> 
> I have seen no evidence of that. I expect it is a problem with the
> particular WiFi device and driver built into your Windows box.
> Go and see the friendly NOC staff.
> https://tickets.meeting.ietf.org/wiki/IETF100network#HelpDesk

I went and they updated by WiFi driver.  It worked during that IETF.

No it no longer works.  Maybe it's because my IT rolled me back into the 
earlier driver.  If so, they must have their reasons for doing so.

I go many hotspots and currently only IETF rejects my card.

I may need to check that again.

Alex

> 
>      Brian
> 
>      Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Mon Nov 13 23:32:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812D0124B18 for ; Mon, 13 Nov 2017 23:32:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV3cFr6DvC2O for ; Mon, 13 Nov 2017 23:32:09 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDE21294A1 for ; Mon, 13 Nov 2017 23:32:06 -0800 (PST)
Received: from dhcp-88cf.meeting.ietf.org (dhcp-88cf.meeting.ietf.org [31.133.136.207]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id vAE7W223030901 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 14 Nov 2017 07:32:04 GMT (envelope-from joelja@bogus.com)
Subject: Re: ESSID ietf-v6only at IETF 100 - security
To: Alexandre Petrescu , Warren Kumari 
Cc: IPv6 
References:   <88d14301-f417-da89-a526-954f44149af8@gmail.com>
From: joel jaeggli 
Message-ID: <15e70479-ea25-6031-dec6-01189a233a37@bogus.com>
Date: Tue, 14 Nov 2017 15:31:28 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:56.0) Gecko/20100101 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: <88d14301-f417-da89-a526-954f44149af8@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 07:32:10 -0000

On 11/14/17 14:59, Alexandre Petrescu wrote:
> 
> 
> Le 14/11/2017 à 07:24, Warren Kumari a écrit :
> [...]
> 
>> ​Nope. We have the legacy SSIDs because some people apparently had
>> issues connecting to encrypted SSIDs (because of old OS / broken
>> wpa_supplicant, etc) - this wasn't issue with certs, but rather
>> providing a solution for those who are unable to do WPA enterprise /
>> have old cards, etc.
> 
> Well - sorry, but all these reasons seem light for me.
> 
> I have Windows 7 which is not old.  Updated regularly from Microsoft and
> from employer IT.

Mainstream support ended January 13, 2015. It works, if you were looking
for a more streamlined experience, the user experience has improved a
bit since then, it has not been backported.

> The WPA_supplicant comes from original.  It is widely accepted at many
> other hotspots.
> 
> My laptop is very well able to do WPA enterprise, and WPA2 Enterprise.
> 
> The laptop is a Dell E7440, 2 or 3 years old.  I dont accept to call
> that old.  What makes laptops old is when they break; they often break
> because of mechanically moving parts like hd, but this one is SSD.
> 
> Rather, I suspect there is a preference at the Access Point to favorise
> Macintosh variations of WiFi Clients, rather than Windows.

There's no obvious basis for that assertion.

> I also wonder why my Windows complains that the cert emmitted by IETF is
> "not configured as a valid anchor".  Should I manually install that
> cert?  If so, that is little reasonable to ask.
https://tickets.meeting.ietf.org/wiki/IETF100network
https://802.1x-config.org/?idp=137&profile=101

> Alex
> 
>>   There was an assertion made that some people were not using nat64
>> and were using ietf-legacy were easier, and so there should be parity,
>> and so the ietf-nat64-unencrypted was created.
>> We are changing the name of the ietf-legacyXXX network at each meeting
>> because we don't people who connected to it at a previous meeting to
>> become sticky to it and keep joining -- it requires a specific action
>> at each meeting for the user to choose the unencrypted network -- we'd
>> all prefer that people use the encrypted network...
>>
>>
>>
>>     And yes, my VPN FortiClient works ok on ietf-nat64-unencrypted.
>>
>>
>>
>>
>>     Alex
>>
>>
>>
>>     --------------------------------------------------------------------
>>     IETF IPv6 working group mailing list
>>     ipv6@ietf.org 
>>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>     
>>     --------------------------------------------------------------------
>>
>>
>>
>>
>> -- 
>> 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
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Mon Nov 13 23:32:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3850129481 for ; Mon, 13 Nov 2017 23:32:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvrGcu4wyxcS for ; Mon, 13 Nov 2017 23:32:48 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C52F1294A8 for ; Mon, 13 Nov 2017 23:32:48 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAE7Wks3005254 for ; Tue, 14 Nov 2017 08:32:46 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 636E4200CEC for ; Tue, 14 Nov 2017 08:32:46 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 50CA4200808 for ; Tue, 14 Nov 2017 08:32:46 +0100 (CET)
Received: from [132.166.84.93] ([132.166.84.93]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAE7WjuK005773 for ; Tue, 14 Nov 2017 08:32:45 +0100
Subject: Re: ESSID ietf-nat64-unencrypted at IETF 100
To: ipv6@ietf.org
References: 
From: Alexandre Petrescu 
Message-ID: <553998cf-e802-23ec-c1b5-2b57b5c297e1@gmail.com>
Date: Tue, 14 Nov 2017 08:32:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 07:32:50 -0000

I Can connect ok to ietf-nat64-unencrypted.

Here is my feedback:

I use VPN to check emails, and the email checking and sending is much 
slower than when I do it on ietf-legacy100, or on Terminal Room Ethernet.

It has intermittency and 'hiccups'.  Sometimes the VPN gets disconnected.

Alex

Le 14/11/2017 à 07:03, Alexandre Petrescu a écrit :
> Hi,
> 
> I have problems connecting to the IPv6-only ESSID "ietf-v6only".
> 
> It is a problem of certificates.
> 
> I have this problem on Windows since several IETF meetings; it may not 
> be related in particular to IPv6.
> 
> The message in the window below says: "The server 
> services.meeting.ietf.org presented a certifcate valid emitted by 
> Starfield CA, but that is not configured as a valid anchor to approve 
> this profile".
> 
> I dont thave this kind of certification refusal problem on 
> ietf-legacy100 ESSID (and all earlier ietf-legacy), neither on 
> ietf-nat64-unencrypted.
> 
> This ietf-nat64-unencrypted is now appearing first time at IETF.  I 
> suppose people realized there was a problem with certs and created an 
> 'unencrypted' version.  That's not a best practice to fix security :-)
> 
> And yes, my VPN FortiClient works ok on ietf-nat64-unencrypted.
> 
> 
> 
> 
> Alex
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Tue Nov 14 00:34:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DA31292FD; Tue, 14 Nov 2017 00:34:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwkfRoV6Xtpl; Tue, 14 Nov 2017 00:34:34 -0800 (PST)
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 A6D3A1292C5; Tue, 14 Nov 2017 00:34:34 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id y5so14816508pgq.7; Tue, 14 Nov 2017 00:34:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9uzRtcuqIv3lEn5NTCdkXU1F+lBtWz4zEGKufCU5Q3U=; b=MZek7yKcaE2Y9xGMR6SmWQeSmSIyMHITBz1+a8ZS7NmG5iXpWovqjZb1Iq0DYIV2WB c+PeCq2M+UY7X9PZHfgOY4heGva+PpUfCDjKqTGEQ0a+1cuwmTxC5et0XiGUEoIkiwmv svCwIjTzkhSWijW9umuwriFFAPOOoVJYVkVQzYmdjoJjWK3Wg8Suq3eQgtXDEb8LpQHL rEGQM4w81JA3wnpZj0hDFpbo6GpwtcyqPVDBLnE9ULuK2RBGe7AQKgvauDOlFGDCdyLS IplW6Egd5+o4uBe7FOPVliQh2E7R/EeZSLJLEGbcBgQMVa2DpHhMBRoNxH/2YtvosIpc ky5Q==
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=9uzRtcuqIv3lEn5NTCdkXU1F+lBtWz4zEGKufCU5Q3U=; b=BFRk9neMgUcmdKE9HbMhPgf0dpfircxxaeLQ6nMtXHWkzLXn5viJZQMJjfFL/p77WT +BqKOXI4IMJvGR12qAc9G7DcMwg0CJRVMzxT9gVkzxbwUPPfUpvL14xVjCbXubmXQuvr uRJ5pWY7Anc3/rUuqVX30y7LmCgWmzHok67G4Nhyma6fhHxe7Z3fEejhx+78ZcM0goTr 21VdxoTH787QTQqoBiHHfETr00jqPJw5ySi8YnVjnGNGiMEx8ev3ZPBnuITU3DxEsdP3 ObZqE0tW3/JinN1RYQ2K2G3KAb486ownMPtxO67Y/dNUd7c8tuIu4RTSPFCekRAEtUVW a4Xg==
X-Gm-Message-State: AJaThX7rjsHFStXO5OVlqITVoxBtvnAcrqCSAdiYqqk4BnNZU+2/gRJy xLJlniO0pLK36gLWYhn3TGkN4vYZ
X-Google-Smtp-Source: AGs4zMaw0/H9rHIFNbiZ4Y6yr25JZ7ijkWmX6F81mywL18a1vKmH7H2ndC4nhgC0r0y0iJfX6UgFWg==
X-Received: by 10.84.176.163 with SMTP id v32mr11838069plb.175.1510648473685;  Tue, 14 Nov 2017 00:34:33 -0800 (PST)
Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id u8sm28221689pgp.17.2017.11.14.00.34.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 00:34:32 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
From: DY Kim 
In-Reply-To: 
Date: Tue, 14 Nov 2017 17:34:29 +0900
Cc: "6man@ietf.org" <6man@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>    <4b7e8e53-ea7a-f84d-92cf-a9a113c200ce@si6networks.com>  <14d489ec-0b28-8fe5-e28c-35a1f4fc15de@si6networks.com>       <72ECE18B-5247-4D00-AF4C-763881929DD3@fugue.com>  
To: "v6ops@ietf.org WG" 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 08:34:36 -0000

Apology to James. My message is not meant to be directed against James =
message.

---
DY

> On 14 Nov 2017, at 11:59, DY Kim  wrote:
>=20
> With my self torn between two schools of thought, I might retry the =
following argument:
>=20
>  =E2=80=98The draft doesn=E2=80=99t make SLAAC stateful=E2=80=99
>=20
> The essence of my argument is that what the draft brings new to the =
router side is not any change of states of any protocols but rather =
implementation details that need not be reflected on existing protocols =
like SLAAC or NDv6.
>=20
> The rationale for my argument goes like the followings:
>=20
> 1.	As far as the hosts are concerned, nothing changes. A host =
receives RAs as usual, not even knowing that the prefix provided is =
unique per host, hence running DAD as usual.
>=20
> 2.1.	As for the router, take the case of usual SLAAC. There are no =
code lines specific about SLAAC. They just issue RAs, either in response =
to RSs or unsolicited. All it does is either set L=3D1 or L=3D0, in =
accordance with the operators policy.
>=20
> 2.2.	Let us see what changes are taking place to the router as a =
consequence of this draft.
> 	First of all, the router intended to implement the ideas of this =
draft should already know that it=E2=80=99s going to deal with different =
prefixes for different hosts, uniquely per host. Any routers of the =
intention then surely have to write in codes to manage the table of =
prefix-to-host mapping.=20
> 	Should there be any changes to the specs of NDv6 (rfc4861) that =
the router is running? No. (can be confirmed by re-reading NDv6). NDv6 =
is silent about how to store/manage the prefix it has handed out, =
anyhow. That part is implementation details that a protocol need not / =
should not bother itself with.
> 	Should any part of the specs of SLAAC (rfc4862) be changed? No. =
(can be confirmed by re-reading SLAAC). The router hasn=E2=80=99t been =
involved with any SLAAC specific behaviors anyhow in the fist place, all =
it does in connection with prefix assignment are NDv6-related actions, =
which puts us back to the statements made in the just preceding =
paragraph.
>=20
> 3.	Anything new this draft has brought are not spec changes (of =
either SLAAC or NDv6) but operational recommendations for any routers =
intending to adopt the ideas described in the draft. Certainly, you =
might have to rewrite part of your router software, but the necessary =
rewriting is such that you put more care about database management in =
regard to prefix-to-host mappings, but is not of such consequential =
quality that you might have to ask 6man to revise either SLAAC or NDv6.
>=20
> 4.	The conclusion is that the draft has not made any changes to =
SLAAC. The management of the prefix-to-host mapping table is not part of =
the SLAAC specs itself, but is simply part of your implementation =
details up to your best choice in your system environment.
>=20
> P.S.: A protocol, by definition, is an interaction between two remote =
entities by exchange of messages of specific syntax and semantics. If =
there are no changes to such incurred, it=E2=80=99s not a protocol =
changes, and so is not subject to be sent to 6man.
>=20
> ---
> DY
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>> On 14 Nov 2017, at 10:49, james woodyatt  wrote:
>>=20
>> On Nov 13, 2017, at 17:40, Ted Lemon  wrote:
>>>=20
>>> Also, it is not true that there is no pushback when new options are =
proposed for RA.
>>=20
>> I have a pile of rejections, none of which were duplicates of DHCPv6. =
One of them was eventually obsoleted by PCP. Another probably gets =
replaced by a mess of security vulnerabilities (but at least ND6 will =
remain pure!).
>>=20
>>=20
>> --james woodyatt 
>>=20
>>=20
>>=20
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>=20


From nobody Tue Nov 14 00:47:21 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F280126DCA; Tue, 14 Nov 2017 00:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level: 
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 jRjLvhGBOs8o; Tue, 14 Nov 2017 00:47:12 -0800 (PST)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF830124D6C; Tue, 14 Nov 2017 00:47:12 -0800 (PST)
Received: from [IPv6:2001:67c:370:1998:b4a8:fb1b:f5d:8e18] (nat64-52.meeting.ietf.org [31.130.238.82]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id vAE8l6uc017802 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Nov 2017 00:47:08 -0800
Subject: Re: Upleveling discussion (was Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
To: Suresh Krishnan , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
Cc: Fernando Gont , "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
References:     <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>       
From: Erik Nordmark 
Message-ID: <03e0242b-140b-4da1-89aa-86987358a99d@acm.org>
Date: Tue, 14 Nov 2017 16:47:05 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVYYb+1VvEUdzG+3j7Xsw7IjqVfAzn/H4ihuZjvGw/LSx1JVUqgnHVevPjWvaEcfb6IS8/2EwTDxZ7dWdespJs90
X-Sonic-ID: C;UMfCZBjJ5xGo5YlQ3iMJ6w== M;hCTWZRjJ5xGo5YlQ3iMJ6w==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 08:47:14 -0000

Suresh,

Thanks for summarizing.

On 11/14/2017 11:22 AM, Suresh Krishnan wrote:
> b) Mechanism does not work
> 
> Given that the mechanism has been implemented and deployed by the 
> authors, I have a hard time taking this claim at face value. Providing 
> an unique prefix per host has been standard practice in 3GPP mobile 
> networks for the past *15 years*. based on recommendations from the IETF 
> back at that time. When a mobile attaches, there is state created on the 
> first hop router that does exactly what this draft wants to do. The only 
> issue I see is a lack of mechanism to clean up stale prefixes if the 
> hosts go away, but depending on the deployment this may or may not be an 
> issue.

The draft is claiming more general applicability that what I understand 
has been implemented and/or specified in the draft, in particular when 
it comes to  being able to reclaim the allocated prefixes when the host 
goes away. The fact that this has been solved in particular contexts 
(such as the 3GPP one) when there is some other mechanisms to detect 
when the host goes away doesn't provide any useful information to the 
Internet community how to make this work in the general case, nor any 
indication that it can be made to work in an interoperable way in the 
general case.

My attempt to find out what has actually been implemented to handle 
hasn't indicated that there is any agreement or any common way to 
implement the reclaim in the general case.

Hence I think the current general applicability is misplaced and if this 
draft is implemented it would be a nice excuse to consume all of the 
IPv6 address space since there is no robust way to reclaim the allocated 
prefixes.

Does the IETF really want to make such a statement?


Note that I would have no issue with publishing what has been 
implemented (in 3GPP and/or Cablelabs specifications) but scoped to 
those environments with their specific reclaim mechanisms.

Regards,
    Erik


From nobody Tue Nov 14 01:40:56 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11627129400 for ; Tue, 14 Nov 2017 01:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gltFDv2DXsie for ; Tue, 14 Nov 2017 01:40:52 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797EF1293EC for ; Tue, 14 Nov 2017 01:40:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAE9epc7056778; Tue, 14 Nov 2017 02:40:51 -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 vAE9elZl056766 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 14 Nov 2017 02:40:47 -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, 14 Nov 2017 01:40:47 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 14 Nov 2017 01:40:47 -0800
From: "Templin, Fred L" 
To: "ipv6@ietf.org" , Lorenzo Colitti 
Subject: Prefix deprecation for 'draft-templin-6man-rio-redirect'
Thread-Topic: Prefix deprecation for 'draft-templin-6man-rio-redirect'
Thread-Index: AdNdKIjKGXdvOekgSZqgQSONCPvpkw==
Date: Tue, 14 Nov 2017 09:40:46 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 09:40:55 -0000

SGkgTG9yZW56bywNCg0KSSdtIG5vdCBzdXJlIGlmIEkgZnVsbHkgYW5zd2VyZWQgeW91ciBxdWVz
dGlvbiwgYnV0IGxldCBtZSBzZWUgaWYgSSBjYW4gdGFsaw0KdGhyb3VnaCBpdCBoZXJlLiBJIGFt
IGFzc3VtaW5nIGEgbGFyZ2UgbGluayB3aXRoIG1hbnkgbm9kZXMgLSBhcyBtYW55IGFzDQp5b3Ug
bGlrZS4gVGhlIFNvdXJjZSBub2RlIHNlbmRzIGEgcGFja2V0IHZpYSBhIFJvdXRlciB3aGljaCBm
b3J3YXJkcyB0aGUNCnBhY2tldCB0byBhIFRhcmdldCBub2RlIG9uIHRoZSBsaW5rLiBBdCB0aGUg
c2FtZSB0aW1lLCB0aGUgUm91dGVyIHJldHVybnMNCmEgUmVkaXJlY3QgbWVzc2FnZSB0byB0aGUg
c291cmNlIHdpdGggYW4gUklPIG9wdGlvbiB0aGF0IGNvbnRhaW5zIHRoZQ0KcHJlZml4IHRoYXQg
bWF0Y2hlcyB0aGUgZGVzdGluYXRpb24gYWRkcmVzcyBvZiB0aGUgcGFja2V0IGFuZCB0aGF0IGhh
cw0KYmVlbiBkZWxlZ2F0ZWQgdG8gdGhlIFRhcmdldC4NCg0KV2hlbiB0aGUgU291cmNlIGdldHMg
dGhlIFJlZGlyZWN0LCBpdCBzZW5kcyBhbiBOUyB0byB0aGUgVGFyZ2V0IHdpdGggYW4NClJJTyB0
aGF0IGluY2x1ZGVzIHRoZSBwcmVmaXggbGVhcm5lZCBmcm9tIHRoZSBSb3V0ZXIgYW5kIHdpdGgg
dGhlICJTIiBiaXQNCnNldCB0byAxIHRvIFNPTElDSVQgdGhlIHByZWZpeC4gV2hlbiB0aGUgVGFy
Z2V0IHJlY2VpdmVzIHRoZSBOUyBtZXNzYWdlLA0KaXQgcmV0dXJucyBhbiBOQSBtZXNzYWdlIHdp
dGggdGhlIFJJTyB3aXRoIGEgY29ycmVjdCByb3V0ZSBsaWZldGltZSB2YWx1ZQ0KYW5kIHdpdGgg
dGhlICJTIiBiaXQgc2V0IHRvIDAgdG8gQVNTRVJUIHRoZSBwcmVmaXguIFRoZSBTb3VyY2Ugbm93
IGhhcw0KdGhlIHByZWZpeCBhbmQgcHJlZml4IGxpZmV0aW1lIGZvciB0aGUgVGFyZ2V0Lg0KDQpZ
b3VyIHF1ZXN0aW9uIGlzIHdoYXQgaGFwcGVucyB3aGVuIHRoZSBUYXJnZXQncyBwcmVmaXggaXMg
aW52YWxpZGF0ZWQ7DQpwZXJoYXBzIGFzIHBhcnQgb2YgYSBzaXRlIHJlbnVtYmVyaW5nIGV2ZW50
LiBJbiB0aGF0IGNhc2UsIHRoZSBUYXJnZXQNCnJlbWVtYmVycyBhbGwgb2YgdGhlIFNvdXJjZXMg
dGhhdCBpdCBoYXMgcHJldmlvdXNseSBzZW50IHNvbGljaXRlZCBOQQ0KbWVzc2FnZXMgdG8sIGFu
ZCBzZW5kcyB0aGVtIGFuIHVuc29saWNpdGVkIE5BIHdpdGggdGhlIHByZWZpeCBhbmQNCndpdGgg
aXRzIGxpZmV0aW1lIHNldCB0byAwLg0KDQpJbiB0aGUgdXNlIGNhc2VzIEkgYW0gY29uc2lkZXJp
bmcsIEkgYW0gZXhwZWN0aW5nIHRoYXQgZXZlbiB0aG91Z2ggdGhlcmUNCm1heSBiZSBhcmJpdHJh
cmlseSBtYW55IG5vZGVzIG9uIHRoZSBsaW5rIGVhY2ggbm9kZSBpcyBsaWtlbHkgdG8gaGF2ZSBv
bmx5DQphIGZldyBhY3RpdmUgY29ycmVzcG9uZGVudHMuIFNvLCBpdCB3b3VsZCBub3QgYmUgdGhl
IGNhc2UgdGhhdCB0aGUgbm9kZQ0Kd291bGQgaGF2ZSB0byBzZW5kIGh1Z2UgbnVtYmVycyBvZiB1
bnNvbGljaXRlZCBOQXMuIEl0IGNvdWxkIGFsc28gc2VuZA0KdGhlIHVuc29saWNpdGVkIE5BcyBh
cyBtdWx0aWNhc3Qgc28gdGhhdCBhIHNpbmdsZSBOQSBpcyByZWNlaXZlZCBieSBtYW55DQpjb3Jy
ZXNwb25kZW50cywgYnV0IHRoYXQgbWlnaHQgbm90IGJlIHNjYWxhYmxlIGZvciByZWFsbHkgbGFy
Z2UgbGlua3MuDQoNCkFub3RoZXIgZmFjdG9yIHdvdWxkIGJlIGZvciB0aGUgVGFyZ2V0IHRvIHNl
dCBzaG9ydCByb3V0ZSBsaWZldGltZXM7IG1heWJlDQpzb21ldGhpbmcgbGlrZSAxMDBzZWMgYXMg
b3Bwb3NlZCB0byBob3Vycy9kYXlzL3dlZWtzLiBJbiB0aGF0IHdheSwgcm91dGVzDQp3aWxsIHRp
bWUgb3V0IGlmIGEgbmVpZ2hib3Igc29tZWhvdyBtaXNzZXMgZ2V0dGluZyB0aGUgdW5zb2xpY2l0
ZWQgTkEuIEFsc28sDQp0aGUgVGFyZ2V0IGNhbiBzZW5kIERlc3RpbmF0aW9uIFVucmVhY2hhYmxl
IGlmIGl0cyBmb3JtZXIgcHJlZml4IGJlY29tZXMNCmludmFsaWRhdGVkLiBTbywgdGhlcmUgYXJl
IHNldmVyYWwgZmFjdG9ycyB0aGF0IHdvdWxkIG1pdGlnYXRlIHRoZSBzaXR1YXRpb24NCnlvdSB3
ZXJlIGNvbmNlcm5lZCB3aXRoLg0KDQpUaGVyZSBpcyBhbHJlYWR5IHNvbWUgdGV4dCBhbG9uZyB0
aGVzZSBsaW5lcyBpbiBTZWN0aW9ucyA0LjQuMyBhbmQgNC43IGluDQp0aGUgZHJhZnQuIERvIHlv
dSB0aGluayB0aGVyZSBzaG91bGQgYmUgYW55IGNoYW5nZXMgdGhlcmU/DQoNClRoYW5rcyAtIEZy
ZWQNCg0KDQo=


From nobody Tue Nov 14 02:08:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADAE126FB3; Tue, 14 Nov 2017 02:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNRqrQswXExe; Tue, 14 Nov 2017 02:08:19 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44C9126DED; Tue, 14 Nov 2017 02:08:19 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id t69so5084536pfg.4; Tue, 14 Nov 2017 02:08:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=j8ad30FNgbRPlGzEv/o4LIPnCp2ahL1IJabvvn9BaI4=; b=LhN7bkepOxRNdYCG9ofVHxysrGO72H4M3xwg7ZeVH/UrCWrTFK7X0gHnMtApS68kTn dituFEnu9e/A0FF+GQJJQD+iILowxuDu3dir6yLFD3Tguvy2gtIt9tAn4kRL7XoRRFv8 wJ0uhHwNByc5Yt4rUIBAy3CgvS4abQioP53KhuR+7X5w7kJDfL1o6TQg26JKgtJWbkJF 97qfGDUmce4Yqf6Z4jtx1fVBqIcdSWR9+K8l7NXWVzXSPVkUDONc6qVg3/Ho88Y4VaLr Pvq0zmW3to2Ycg64jmK90MKwNBV0X/IiqzKKnZcA15WBnaFjQa1qRk8PqwT7/Hc5vgVe ofsg==
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=j8ad30FNgbRPlGzEv/o4LIPnCp2ahL1IJabvvn9BaI4=; b=Sq2ss2PGw8Zt0G7KRJQ4OtY2AQu8UD0ljCKdxj1njeeTiExJS1dFYNLAQBj75xTUOU OHq8Scg1YOTAwAAN8rNralApIcC0ll/S2PKLk1o7EYdNcW4tr8CJMEAXSNEQ8BC9Exik aSMzbHq5tCpIP+L/Qz22sw/xINpDPOBLNxRSuKfHgm81XJPlNMe5AX/u3XzwpyqdThKt iC6oA7SvsCEY4BitxGODPWI+DwAUsszmdsoFg/oH184NN4utE8f9AJgwK7mWcmfLqYLk Rfqc1xZjApQ8Q0cv2xnsl4nPpRWBl7LYRrBatz8fFUxoaTS94o+Ay/dcsjxi3j5k1LXo bCjg==
X-Gm-Message-State: AJaThX5UK7MQCHN2EaQb7/gk+H9wsD8ER+Uj3V3Z4alVc1M4CtOCxQKe OF5JcZX2pCzwC5TD46WbNXE=
X-Google-Smtp-Source: AGs4zMaQ1JsV92E4lNqigNpml4I/2Hyqr2Ek8eAYtooSbvINbuPJtaC4Y9bZIrX3WN0+KhjIHUfnqg==
X-Received: by 10.99.110.197 with SMTP id j188mr11454932pgc.34.1510654098920;  Tue, 14 Nov 2017 02:08:18 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id b19sm39887338pfd.182.2017.11.14.02.08.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 02:08:17 -0800 (PST)
Subject: Re: [v6ops] Upleveling discussion (was Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
To: Erik Nordmark , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
Cc: Suresh Krishnan , Fernando Gont , "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
References:    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>        <03e0242b-140b-4da1-89aa-86987358a99d@acm.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <1ee73094-6ae6-fbe1-c9f4-adc4afc2e0c6@gmail.com>
Date: Tue, 14 Nov 2017 23:08:16 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <03e0242b-140b-4da1-89aa-86987358a99d@acm.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 10:08:21 -0000

On 14/11/2017 21:47, Erik Nordmark wrote:
> 
> Suresh,
> 
> Thanks for summarizing.
> 
> On 11/14/2017 11:22 AM, Suresh Krishnan wrote:
>> b) Mechanism does not work
>>
>> Given that the mechanism has been implemented and deployed by the 
>> authors, I have a hard time taking this claim at face value. Providing 
>> an unique prefix per host has been standard practice in 3GPP mobile 
>> networks for the past *15 years*. based on recommendations from the IETF 
>> back at that time. When a mobile attaches, there is state created on the 
>> first hop router that does exactly what this draft wants to do. The only 
>> issue I see is a lack of mechanism to clean up stale prefixes if the 
>> hosts go away, but depending on the deployment this may or may not be an 
>> issue.
> 
> The draft is claiming more general applicability that what I understand 
> has been implemented and/or specified in the draft, in particular when 
> it comes to  being able to reclaim the allocated prefixes when the host 
> goes away. The fact that this has been solved in particular contexts 
> (such as the 3GPP one) when there is some other mechanisms to detect 
> when the host goes away doesn't provide any useful information to the 
> Internet community how to make this work in the general case, nor any 
> indication that it can be made to work in an interoperable way in the 
> general case.
> 
> My attempt to find out what has actually been implemented to handle 
> hasn't indicated that there is any agreement or any common way to 
> implement the reclaim in the general case.
> 
> Hence I think the current general applicability is misplaced and if this 
> draft is implemented it would be a nice excuse to consume all of the 
> IPv6 address space since there is no robust way to reclaim the allocated 
> prefixes.

That seems a bit alarmist. I don't think the RIRs will be handing out
IPv6 /16 prefixes because operators have lost millions of prefixes
and don't know where they are. Clearly an implementation of this
is going to have a mechanism for recycling these prefixes when
the host has been inactive for X amount of time, or has gone
physically off line, or whatever criterion they prefer to use.
Do we need to specify that? It isn't a wire protocol. 
(Another way to look at it is that the lifetime of the implied
prefix delegation is identical to the advertised router lifetime.
The host doesn't know it's getting a prefix, it just hears about
a router with a certain lifetime. If that isn't refreshed, it
can no longer send packets and the address will also vanish.)

   Brian
 
> Does the IETF really want to make such a statement?
> 
> 
> Note that I would have no issue with publishing what has been 
> implemented (in 3GPP and/or Cablelabs specifications) but scoped to 
> those environments with their specific reclaim mechanisms.
> 
> Regards,
>     Erik
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


From nobody Tue Nov 14 02:44:43 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A3A128BB6 for ; Tue, 14 Nov 2017 02:44:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3SbBpvHwKZv for ; Tue, 14 Nov 2017 02:44:39 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9704127775 for ; Tue, 14 Nov 2017 02:44:38 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEYhl-0000FyC; Tue, 14 Nov 2017 11:44:33 +0100
Message-Id: 
To: ipv6@ietf.org
Subject: Re: IPv6 only host NAT64 requirements? 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  
In-reply-to: Your message of "Tue, 14 Nov 2017 08:32:20 +0800 ."  
Date: Tue, 14 Nov 2017 11:44:32 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 10:44:42 -0000

> Now people here tell me that local validation
> of DNSSEC isn't done for IP4 either and in practice it's not
> deployable. I'd hope that's untrue, but regardless you don't appear
> to be in a worse position with DNS64 than you are without. Either
> you trust a distance recursive resolver to do the validation for
> you, or you do validation yourself (and also the synthesizing of
> IP6 addresses).

For quite a while now, I'm running two applications with local DNSSEC
validation on my laptop.

One is the cz.nic dnssec validator plugin for web browsers. The other is my
own code that uses getdns in ssh to validate SSHFP records.

In both cases, it just works. My conclusion is that wherever I take my laptop,
getdns can do local DNSSEC validation. DNSSEC works. Of course there are issues.
The fragmentation problems Geoff is seeing are real. But in practice it works.

One of the problems with DNSSEC and NAT64 is one way or another you have
to deal with a AAAA response that is not signed.

Without local synthesizing, local DNSSEC validation will fail. With local
synthesizing the local validator has to tell the application 'trust me, I
know what I'm doing'. Even if that's not actually true.



From nobody Tue Nov 14 04:03:23 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8BB126DCA for ; Tue, 14 Nov 2017 04:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, 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 dB3kqwExJzkR for ; Tue, 14 Nov 2017 04:03:20 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC0E120726 for ; Tue, 14 Nov 2017 04:03:18 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAEC3HBC034698 for ; Tue, 14 Nov 2017 13:03:17 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 53DF2205469 for ; Tue, 14 Nov 2017 13:03:17 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 495BD2052F7 for ; Tue, 14 Nov 2017 13:03:17 +0100 (CET)
Received: from [132.166.84.62] ([132.166.84.62]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAEC3FZB000421 for ; Tue, 14 Nov 2017 13:03:16 +0100
To: IPv6 
From: Alexandre Petrescu 
Subject: Windows - how to connect on the ietf-v6ONLY
Message-ID: <4fb12f9b-3039-d5c1-75db-324a28fcdbc1@gmail.com>
Date: Tue, 14 Nov 2017 13:03:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------28BCCA9D234FD62081C128FE"
Content-Language: fr
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 12:03:23 -0000

This is a multi-part message in MIME format.
--------------28BCCA9D234FD62081C128FE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

During today's 6MAN meeting there was suggestion to use IPv6 ESSIDs.  In 
that room the other more normal ESSIDs seemed more silenced.

For Windows 7 users, in order to connect to "ietf-v6ONLY", one should be 
ready to give up some security worries. (there are other IPv6 related 
ESSIDs like "ietf-nat64" and its visibly "unencrypted" version. They're 
all unsecure.)

How to connect to ESSID "ietf-v6ONLY":

Right button on the five-bar scale bottom right of the screen.
Open Network Center
In the left column click "Manage WiFi Networks"
Search existing "ietf-v6ONLY" or "ietf-v6only" and delete
In the left collumn click "Add"
Click Create a Network Profile manually
In the Network Name field type "ietf-v6ONLY" without quotes, but respect 
capitals (note 'v' but 'ONLY')
In the Security Type unfold menu select "WPA2 - Enterprise"
In the Encryption Type unfold menu select "AES"
In the lower right zone click Next
Click "Modify Connexion Parameters"
Select the Security titled Tab
Click the "Parameters" button (not the "Advanced Parameters")
Up in the window uncheck the "Validate the Server Certificate" <-- give 
up security worries
Down in the window click the Configure button
In the new small window uncheck "Use automatically the Windows 
username/password" <-- give up security worries
Click Ok many times to return many levels
Right button on the five-bar scale bottom right of the screen
In the Network Authentication window type "ietf" and "ietf" <-- give up 
security worries, final.

At this point one is connected to ietf-v6ONLY.

Alex


--------------28BCCA9D234FD62081C128FE
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
Hi,

    
During today's 6MAN
          meeting there was suggestion to use IPv6 ESSIDs.  In that room
          the other more normal ESSIDs seemed more silenced.

    
For Windows 7 users, in
          order to connect to "ietf-v6ONLY", one should be ready to give
          up some security worries. (there are other IPv6 related ESSIDs
          like "ietf-nat64" and its visibly "unencrypted" version. 
          They're all unsecure.)

        

    
How to connect to ESSID
          "ietf-v6ONLY":

    Right button on the
        five-bar scale bottom right of the screen.

        Open Network Center

        In the left column click "Manage WiFi Networks"

        Search existing "ietf-v6ONLY" or "ietf-v6only" and delete

        In the left collumn click "Add"

        Click Create a Network Profile manually

        In the Network Name field type "ietf-v6ONLY" without quotes, but
        respect capitals (note 'v' but 'ONLY')

        In the Security Type unfold menu select "WPA2 - Enterprise"

        In the Encryption Type unfold menu select "AES"

        In the lower right zone click Next 

        Click "Modify Connexion Parameters"

        Select the Security titled Tab

        Click the "Parameters" button (not the "Advanced Parameters")

        Up in the window uncheck the "Validate the Server Certificate"
        <-- give up security worries

        Down in the window click the Configure button

        In the new small window uncheck "Use automatically the Windows
        username/password" <-- give up security worries

        Click Ok many times to return many levels

      Right button on the
            five-bar scale bottom right of the screen

            In the Network Authentication window type "ietf" and "ietf"
            <-- give up security worries, final.

            

            At this point one is connected to ietf-v6ONLY.

            

            Alex 

          

      
  


--------------28BCCA9D234FD62081C128FE--


From nobody Tue Nov 14 04:26:42 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915BF1272E1 for ; Tue, 14 Nov 2017 04:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxqjp3ivyiuI for ; Tue, 14 Nov 2017 04:26:39 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C8212420B for ; Tue, 14 Nov 2017 04:26:38 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id t69so5332638pfg.4 for ; Tue, 14 Nov 2017 04:26:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YRzR0LORPCDZYkpclGVs76vwt11X2FQF8v4MKx+tteA=; b=MLFJecLEMvm+aF4CJElbbTqzvOPJ+AhyDY6xRicxArflpkLvJECPVCgu8NCqkWXeDy kkzNySb+a/C48zoWu/nhrZqhINlpDVFKuEI1Z3iuBJigLBTgDt2iv9GV1ivKFYneasjw 6wZLJEVu2IZ93S+bjyb1RPIDRINTlGxxiN3cZjf54BA/K8XXbY5FuERwT+fcxHdmwWyZ 1mU+OXIiO42RkY4Kyc7Pv4TTL7HuoIDQKnTKoW3AdfRVgi3vGC1roS+PfcgRGaDmes1z ofEnlTs1U+R2vsGRP82YcAAaLAbUZgtN3HxG/8lxzkqEptuxmAOKyGf+QIWJVcmnSbSy XiiQ==
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=YRzR0LORPCDZYkpclGVs76vwt11X2FQF8v4MKx+tteA=; b=mXJ3zIHBhXEccneUk0MZyN70N+W9B9AJOx9baTWCQpazD8FIVinpCVciZSJpjAM9MP ZcBMuGzgEa/JK6OMqBR9g1kx88g9c7AWmX2CCmCRNFCkNnVhEBGbWwbFk4LAVW/nQ2LF WOFFRQrta9lZYTFh9J7InB1/lRmTFKoDi4r6c3zIzrQv7TrAEQZuF+8XCIltg+CN2Y73 f8+YeQLakYFrv8zKGp6WSK8y8rlgfklKGUo1ktqJ+t5jb7wDkq8fpvy/pOkai8OceTEW XYl545l9TDJc184wqEvKBk24Rps5iau7uDT9UUQPeDINrkmPabzME4bnGo4GbXSgzlOy noNg==
X-Gm-Message-State: AJaThX72OVLG7n2G54aVSnvq56MgX2xjiqwddBsnj77ewaVpPtkz17LM dY2k37ctCWniLGCGHp9q/O3PMw==
X-Google-Smtp-Source: AGs4zMYa6EX/YCHCdauQkkkPGgSRuuM063fa/B12BHTJwvGDgNl4u6xxjZbFyslZwI6YRe5mUNPiSw==
X-Received: by 10.99.124.85 with SMTP id l21mr11949346pgn.372.1510662398063; Tue, 14 Nov 2017 04:26:38 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id e9sm22423402pfl.138.2017.11.14.04.26.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 04:26:36 -0800 (PST)
Subject: Re: Windows - how to connect on the ietf-v6ONLY
To: Alexandre Petrescu , IPv6 
References: <4fb12f9b-3039-d5c1-75db-324a28fcdbc1@gmail.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Wed, 15 Nov 2017 01:26:35 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4fb12f9b-3039-d5c1-75db-324a28fcdbc1@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 12:26:40 -0000

> Up in the window uncheck the "Validate the Server Certificate" <-- give 
> up security worries

This is not necessary with an up to date WiFi driver. For whatever reason,
you are trying to run with an obsolete driver, judging by your mail
earlier today. I just verified that my Windows 7, at least, has that
option enabled, as it clearly should be.

> In the Network Authentication window type "ietf" and "ietf" <-- give up 
> security worries, final.

Sure. The login is not kept secret, since that would be pointless with
such a large group of users. There's no news there.
https://tickets.meeting.ietf.org/wiki/IETF100network#MeetingRoomWireless

Does any of this involve IETF protocols?

Regards
   Brian


From nobody Tue Nov 14 04:53:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49EB1204DA for ; Tue, 14 Nov 2017 04:53:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3xI1rDXm8Xm for ; Tue, 14 Nov 2017 04:53:51 -0800 (PST)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDF1126B7E for ; Tue, 14 Nov 2017 04:53:51 -0800 (PST)
Received: by mail-pg0-x22e.google.com with SMTP id t10so14267287pgo.3 for ; Tue, 14 Nov 2017 04:53:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:message-id:date:user-agent:mime-version :content-language; bh=TQynhNsJa7B0fFPQw8hAofOX8F+taRULz2uZT63wll0=; b=NwIajWhSKGije0ZBYwUdz7ZdnkOso8EmiaxO72poP/hcldrsSzn2jOCDNb/zKY0PXC w6q4Kt+zQIxpSpItegB0QCrYkguBZ0EaZoNLwZhIbPHhhbNEl07PkImmHsaG4TPyYeOF y7p8ZR2imk5bynTedAtCOWITMaz2UkIg7Ir5Jfkci8IovZKZkFi6/OxuNWgd0rOL2Lix obgcuiOlTvtfzAzqRenjUX5SA17nktUwNIMmugh+eIVesIhLgYHPphMKhcXyFrW+Vl// I/FoSKzmFWfXkl7ZHFr1bsXYj/WgNxoXp7R0pJPeRbKyHqH9gOVOcs2sep+0Mkjfn8Qk FlPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language; bh=TQynhNsJa7B0fFPQw8hAofOX8F+taRULz2uZT63wll0=; b=j3F9s2FBd48WOtnYrMQpQA82cNyRCRRvzbiYX8UojzFiveqAx32OyXOJEyczrgUNyS tDPFJT3AQaxN5fep9I9HdBLmG4x0YIPAT7Qzzp+rCYOMj7NkaALa3LJGLb0M74mKyRfM tBhaUWvrCjAPKyZ/+DXfa+sqBE6yQ+oQIIAjM7mbDsqeedxD4qfaBcauxnJpVwqOSm7r +0ygmn+HR/u5/ymxlx3gvPvJCcncq0Po8WXDXMnEvDVJluOfHZwofaSXefPjR1Gbk+2L QudviMhpIMq4mKI4EXk+bLZqvltzNjFTyf0cr4TohbemGdtmeE0AkgPMMqx83jWSp/BB 00+w==
X-Gm-Message-State: AJaThX513E0DZ9nHBCIzpMtnKaMWRg8IMgCXppa0YOimRLgZF7Zo0p9E +QBzHsEYRSRJ6iAUyadJQa/3mw==
X-Google-Smtp-Source: AGs4zMbOJ44JJCw8JS1Nc+c6zkCTCLglU5zz+MZoR8Ftp1KLSNh8smJCcPt4Mf0zG+q6XOho1EWIBA==
X-Received: by 10.101.66.135 with SMTP id j7mr11930130pgp.39.1510664030681; Tue, 14 Nov 2017 04:53:50 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1999:fc88:62e4:1270:9cc? ([2001:67c:370:1999:fc88:62e4:1270:9cc]) by smtp.gmail.com with ESMTPSA id 3sm37776843pfo.17.2017.11.14.04.53.49 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 04:53:49 -0800 (PST)
From: Alexandre Petrescu 
X-Google-Original-From: Alexandre Petrescu 
To: IPv6 
Subject: Reporting on some applications on ietf-v6ONLY
Message-ID: 
Date: Tue, 14 Nov 2017 13:53:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------FC97255ED5A70DB95560F840"
Content-Language: fr
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 12:53:53 -0000

This is a multi-part message in MIME format.
--------------FC97255ED5A70DB95560F840
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

I am not sure whether the group wants these reported here or on tickets 
@ meeting.ietf.org.  It's not their fault if these dont work.  I am not 
sure whether v6ops WG wants to see these either.

While connected on the 'ietf-v6ONLY' at IETF 100:

Windows Update no, Red error "8024402C".

FortiClient VPN no.  It seemingly can't reach the server.   I can do a 
packet dump if needed.

VPN SSL to my employer's web page does not work.

Skype latest, and Skype Enterprise can't connect.

webex yes, arkadin no.

Thunderbird to free.fr and to gmail.com yes.

Firefox to many ietf.org pages seems ok.   Paypal no, youtube yes, 
amazon no, ebay no, impots.gouv.fr no.

Google Earth yes.

KeePass update check no.

BT747 no.

iTunes starts, but cant connect to Store.

Wireshark updates yes.

Picasa yes.

TomTom no.

Fitbit no.

VLC updates no.

The Berkeley's netalyzr is not reachable :-( (it was in the past, on 
other 'v6-only' networks).

Alex
(sent from Windows laptop on 'ietf-v6ONLY' at IETF 100)
(there is no IPv4 address on computer's interface, other than the IPv4 
link-local address)

--------------FC97255ED5A70DB95560F840
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
Hi,

    
I am not sure whether
          the group wants these reported here or on tickets @
          meeting.ietf.org.  It's not their fault if these dont work.  I
          am not sure whether v6ops WG wants to see these either.

        

    
While connected on the
          'ietf-v6ONLY' at IETF 100:

    
Windows Update no, Red
          error "8024402C".

        

    
FortiClient VPN no.  It
          seemingly can't reach the server.   I can do a packet dump if
          needed.

    
VPN SSL to my employer's web page does
              not work.

    
Skype latest, and Skype
          Enterprise can't connect.

            

    
webex yes, arkadin no.

    
Thunderbird to free.fr
          and to gmail.com yes.

    
Firefox to many ietf.org
          pages seems ok.   Paypal no, youtube yes, amazon no, ebay no,
          impots.gouv.fr no.

    
Google Earth yes.

        

    
KeePass update check no.

    
BT747 no.

    
iTunes starts, but cant
          connect to Store.

        

    
Wireshark updates yes.

        

    
Picasa yes.

    
TomTom no.

    
Fitbit no.

    
VLC updates no.

        

    
The Berkeley's netalyzr
          is not reachable :-( (it was in the past, on other 'v6-only'
          networks).

    Alex

        (sent from Windows laptop on 'ietf-v6ONLY' at IETF 100)

        (there is no IPv4 address on computer's interface, other than
        the IPv4 link-local address)

      
  


--------------FC97255ED5A70DB95560F840--


From nobody Tue Nov 14 05:00:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14F6127078 for ; Tue, 14 Nov 2017 05:00:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYJ9dqbIMdUF for ; Tue, 14 Nov 2017 05:00:11 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8721C12420B for ; Tue, 14 Nov 2017 05:00:11 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAED08ZM145652; Tue, 14 Nov 2017 14:00:08 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AAC52205526; Tue, 14 Nov 2017 14:00:08 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9405720544B; Tue, 14 Nov 2017 14:00:08 +0100 (CET)
Received: from [132.166.84.62] ([132.166.84.62]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAED061I013690; Tue, 14 Nov 2017 14:00:07 +0100
Subject: Re: Windows - how to connect on the ietf-v6ONLY
To: Brian E Carpenter , IPv6 
References: <4fb12f9b-3039-d5c1-75db-324a28fcdbc1@gmail.com> 
From: Alexandre Petrescu 
Message-ID: <75eeb91a-ab1c-d7fc-bb00-55e45d197fc4@gmail.com>
Date: Tue, 14 Nov 2017 14:00:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 13:00:14 -0000

Le 14/11/2017 à 13:26, Brian E Carpenter a écrit :
>> Up in the window uncheck the "Validate the Server Certificate" <-- give
>> up security worries
> 
> This is not necessary with an up to date WiFi driver. For whatever reason,
> you are trying to run with an obsolete driver, judging by your mail
> earlier today. I just verified that my Windows 7, at least, has that
> option enabled, as it clearly should be.
> 
>> In the Network Authentication window type "ietf" and "ietf" <-- give up
>> security worries, final.
> 
> Sure. The login is not kept secret, since that would be pointless with
> such a large group of users.

Yes, I have seen larger groups of users using such.  During latest 
Olympic games the TV of a wifi password at bobsleigh area was broadcast 
to a very wide audience.

> There's no news there.
> https://tickets.meeting.ietf.org/wiki/IETF100network#MeetingRoomWireless
> 
> Does any of this involve IETF protocols?

It's hard to say just like that.  But putting IPv6 on it without some 
friendly security is a non-starter.

Maybe we want an IETF CA to sign our certificates, or something like 
that.  I am saying that just to answer you but I really dont know what's 
better.

Alex

> 
> Regards
>     Brian
> 
> 


From nobody Tue Nov 14 07:38:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8091D128B93 for ; Tue, 14 Nov 2017 07:38:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3dmNY-OaTGVy for ; Tue, 14 Nov 2017 07:38:01 -0800 (PST)
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 4DBA8128B44 for <6man@ietf.org>; Tue, 14 Nov 2017 07:38:01 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id C4C119D0 for <6man@ietf.org>; Tue, 14 Nov 2017 15:38:00 +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 blxCV7lrOJhe for <6man@ietf.org>; Tue, 14 Nov 2017 09:38:00 -0600 (CST)
Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id 8D0ABD9E for <6man@ietf.org>; Tue, 14 Nov 2017 09:36:21 -0600 (CST)
Received: by mail-lf0-f70.google.com with SMTP id a132so5152130lfa.17 for <6man@ietf.org>; Tue, 14 Nov 2017 07:36:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0qVFkdhizx0FZwUP0TDpsQ7GJZLH02kVhMIw6YTk/sw=; b=aoWDX0N7OOC1wGTFr9WjmWh4YvdheYnuYeTckKVcQ0J6paLQyK7li+ZRi3V5sPjktj GdCbX5RIU/3dFvi6uPBXkHsc41lmo43yLocrhWaAgEJHW98rk/qZfxUuA5/kF5UViQpI j594rPSd+THdmUl5ILRuVmv8DDY2LnPeSkqX0sCdOojo5334KqK0QoYsxNYIXoKt/Kcz WU2uNTPwHhv803kY5ABK1Y754qSthTwuNwP2mIKw5PtUQb/SYcrIFhq3to2Q8NoErf3f 4I3Q4u1Bel73BFIDuCLtDkviKoL/5CiroeWt/E7nhq6yJ92B60LnRb+NASsMUo0CB+m7 AUuw==
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=0qVFkdhizx0FZwUP0TDpsQ7GJZLH02kVhMIw6YTk/sw=; b=aTMhVcoyf9Ob9cKqVdwU8Zkyt90wD2OtaTNg7PBskh16Un/Miqcy+umgzlaMRt7qcP h72itjTa3neX2EXwPF03EZEbdy7kcW42xVJduOAati5ZZonm4jogEW9vPJj5GNYv/U2H ZBedEmOZJ7e2GEbDWOdFacB2ixd7ukDbrpuRVsref3RUhSaWzerHF7nzxtmdQ6dPvb/z 6rxC+YXrlsrAgREWTUX1zeN+MYQ8BVbMWvxLcjYGf3lgT/EoELCetgz/itwYrB8+ETQ0 1+alm602CpcShXIrpFqHPsavZI/apYZXrWdxIJS+PiPWU9NLsv3jVLc6XERNHG5YKiIl Dw/g==
X-Gm-Message-State: AJaThX4OKYVsLqaJdj2lnLpsvtWhMG6AaePzNzrWSBgnrfrZVSYz/GJb yRCEF9V582zvMMXyRch7BQU22nWEZalu9K8q9OvI5afOd8DL+gAFRhTVPY8SKHFbhZfz8rzEHp/ 21jK0yR3c3HwLGl2PhWgRM4V6
X-Received: by 10.25.104.19 with SMTP id d19mr3568160lfc.155.1510673779395; Tue, 14 Nov 2017 07:36:19 -0800 (PST)
X-Google-Smtp-Source: AGs4zMYSFoOX/4zCgNxVEySgAZp4FVRVL/DntLMXnp+e8kR6wfxr2gkdkvgw3DT+4LKewAx6SwOH7ceXYfQNUOoOmQc=
X-Received: by 10.25.104.19 with SMTP id d19mr3568148lfc.155.1510673779090; Tue, 14 Nov 2017 07:36:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Tue, 14 Nov 2017 07:36:18 -0800 (PST)
In-Reply-To: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>      
From: David Farmer 
Date: Tue, 14 Nov 2017 09:36:18 -0600
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Warren Kumari 
Cc: Ted Lemon , Fernando Gont ,  "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>,  "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
Content-Type: multipart/alternative; boundary="f403045e58a0f97eed055df32550"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 15:38:02 -0000

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

On Mon, Nov 13, 2017 at 8:41 PM, Warren Kumari  wrote:

>
> I would feel out the WG about this - would you be OK with this being
> Info (and getting it out the door)?
>

I'd be fine with Informational.


> I feel I also owe the WG (and authors) an apology - this has been a
> painful process and taken up way more of your time than it should
> have.
>

Don't worry about it, you have simply occupied us so we didn't have start
another round of the RFC4291bis discussion. :)

-- 
===============================================
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>
===============================================

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



=
On Mon, Nov 13, 2017 at 8:41 PM, Warren Kumari <warren@kumari.net><=
/span> wrote:


I would feel out the WG about this - would you be OK with this being

Info (and getting it out the door)?

I&#=
39;d be fine with Informational.
=C2=A0

I feel I also owe the WG (and authors) an apology - this has been a

painful process and taken up way more of your time than it should

have.

Don't worry about it, you hav=
e simply occupied us so we didn't have start another round of the RFC42=
91bis discussion. :)

-- 
=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Far=
mer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Netw=
orking & Telecommunication 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 




--f403045e58a0f97eed055df32550--


From nobody Tue Nov 14 07:38:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A101128D69 for ; Tue, 14 Nov 2017 07:38:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 auM5q-ViPHsS for ; Tue, 14 Nov 2017 07:38:23 -0800 (PST)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D7B128961 for <6man@ietf.org>; Tue, 14 Nov 2017 07:38:23 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 4587CB4F for <6man@ietf.org>; Tue, 14 Nov 2017 15:38: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 rlJSDcIaAQWd for <6man@ietf.org>; Tue, 14 Nov 2017 09:38:23 -0600 (CST)
Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 44692EFC for <6man@ietf.org>; Tue, 14 Nov 2017 09:37:15 -0600 (CST)
Received: by mail-lf0-f71.google.com with SMTP id a132so5152678lfa.17 for <6man@ietf.org>; Tue, 14 Nov 2017 07:37:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XzyBOYKjhMqqoEx6ji6wPtPmSZJlnyTM5BchWDP70eY=; b=JE/zB+EeNzeFwOQRju0aAhaencVt3qW81/z0vCX6su5v4u7A3EQgUps6Mw2WpjYwZo Rjk+BcnjG5y1aWGNjtDgaClq3ebfIW2THG8WLVlZb5a+NZGyZYnpNf9x772csfwsLc2R bGXz8UuqCPBPAoKIntILRqSlmfPmaMD3Kb4GnNiYnoqRmp1KDIqS/ZgKn0YBSvKrBa9d UUzvpIXyaFIIjJ2ygt8UNdiUOtdEa38q5MfRQ/JbL/BM1fV1eT11r8yQDmjxgCA1NiMn 97E3ZT/d46YJHikDi9gP9mmvQOggZMbIkHcMpx7PjtlRAeS9Fjfk+iDPeNU4iMgnHzcc 5TLg==
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=XzyBOYKjhMqqoEx6ji6wPtPmSZJlnyTM5BchWDP70eY=; b=LhMpPOKypp0ArKiZuRQMIbNlqz7ov6WkkdAZreneC1A4O9AfoF+Kczntnv85G3PSyT PpjcIKEJ5aPxcB3lay1sPEDFwREEve6MYMXlAL7tuPXCCZY17UkWqFi88XI9GqtHUPSn QSRQLzvAqjzLTwjyaTF8qos9avvSv9Gx+GohX3o1bDDQ4ddBE4GB90ZDE9vjNGjm8nTq 3Y5mIvQv9ZWE4guHVvQl4JzsXXAI+Ks3hkV3MpAXNBiuyju3rwIJ6vk6kT6D7J8n4er+ Jdw09sUoIhkVaf4gFOro0ztFB/bIdpi56UlJURMNvm6fQou10coc3rKm3ctOE31jenmY mkSQ==
X-Gm-Message-State: AJaThX4jAp6WB2y/0W5nY+3cIkKTERr0E6CUOvPLVxGO5NTo+kO26Bww 0VgUxu5p3Zr6yRKVikA13XiX9kyDLtlp5hrowYMCPL+69fAP2MPw5I7Hcn+vajzRHpfAuAkJz22 0ajxuz9ZP9+FxjJd+rynIBNPc
X-Received: by 10.25.15.161 with SMTP id 33mr5056638lfp.57.1510673833505; Tue, 14 Nov 2017 07:37:13 -0800 (PST)
X-Google-Smtp-Source: AGs4zMaOPZhU1Z9X1GBpSbxVHZUxDqvsCu4q6FBTVDpAak4u44bVhwv/XNGXGr/WqGKz+hQ6pxa0HO4sErD4C0wqdzc=
X-Received: by 10.25.15.161 with SMTP id 33mr5056630lfp.57.1510673833259; Tue, 14 Nov 2017 07:37:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Tue, 14 Nov 2017 07:37:12 -0800 (PST)
In-Reply-To: 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>       
From: David Farmer 
Date: Tue, 14 Nov 2017 09:37:12 -0600
Message-ID: 
Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)
To: Lorenzo Colitti 
Cc: Warren Kumari , Fernando Gont ,  "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>, Ted Lemon ,  "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
Content-Type: multipart/alternative; boundary="001a113f220034b07d055df32981"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 15:38:30 -0000

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

On Mon, Nov 13, 2017 at 10:23 PM, Lorenzo Colitti 
wrote:

> On Tue, Nov 14, 2017 at 10:41 AM, Warren Kumari  wrote:
>
>> I would feel out the WG about this - would you be OK with this being
>> Info (and getting it out the door)?
>>
>
> Warren,
>
> is it worth asking that question on a new thread that is narrowly scoped
> to that question? There's a lot of discussion still on this thread that
> might cloud the response.
>

+1

-- 
===============================================
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
===============================================

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




On Mon, Nov 13, 2017 at 10:23 PM, Lorenzo Colitti <=
;lorenzo@google.com=
> wrote:
<=
div class=3D"gmail_extra">
On Tue, Nov 14, 2017 a=
t 10:41 AM, Warren Kumari <warren@kumari.net> wrote:
I would feel out the WG about this - would you b=
e OK with this being

Info (and getting it out the door)?

War=
ren,

is it worth asking that question on a new thr=
ead that is narrowly scoped to that question? There's a lot of discussi=
on still on this thread that might cloud the response.

+1

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=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:fa=
rmer@umn.edu
Networking & Telecommunication Services
Office o=
f Information Technology
University of Minnesota=C2=A0=C2=A0 
2218 Un=
iversity Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815
Minneapol=
is, 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 




--001a113f220034b07d055df32981--


From nobody Tue Nov 14 08:29:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64DF1271FD for ; Tue, 14 Nov 2017 08:29:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMbaPEvrebwS for ; Tue, 14 Nov 2017 08:29:05 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864821200F1 for ; Tue, 14 Nov 2017 08:29:05 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AE7FF20008; Tue, 14 Nov 2017 11:30:42 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 242D982B23; Tue, 14 Nov 2017 11:29:04 -0500 (EST)
From: Michael Richardson 
To: Ole Troan 
cc: Ca By , 6man WG 
Subject: Re: IPv6 only host NAT64 requirements?
In-Reply-To: 
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk>  <24403.1510627646@obiwan.sandelman.ca> 
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 16:29:12 -0000

--=-=-=
Content-Type: text/plain


Ole Troan  wrote:
    > Michael,

    >>> I have a network with 10s of millions of ipv6-only nodes, none of
    >>> which can so dnssec (neither android nor ios support it) and the
    >>> implication that these nodes are no longer ipv6 since they don't do
    >>> dnssec is ludicrous.
    >>
    >> If you want to do DNSSEC validation, and there is a possibility of NAT64,
    >> then you need to do the DNS64 locally.
    >>
    >> If you aren't doing DNSSEC now, then it won't matter.
    >> When you add DNSSEC, then you have to do NAT64 prefix discovery, and DNS64.

    > Could you speculate on how much of this should go in the host and
    > thereby are candidates for host requirements and how much belongs in
    > the application?

You have to do this wherever you do DNSSEC.

That is seldom in the application.  There are libraries (e.g: libunbound)
so that clueful applications can do DNSSEC before the system is ready, but
this is rather akin to that some applications (ping/traceroute,etc) open
raw sockets and construct IP headers themselves.

So I'd say that it all goes into the host requirements.


    > Btw: Your key has expired. ;-)

finger mcr@sandelman.ca | gpg --import

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloLGc8ACgkQgItw+93Q
3WXX4AgArULuMR11dPDSmpQvF4ZVHItitdVzDfHEH5tNUevB1ZsyffNkY2MhXxSe
3P5kyXbyHwm24+29HKJJhuTxCqz0nFyosi9pcExtbIeF4v3CFHKpITA1zxSz6lnN
VwpkfruY9NG0Q8MFRTWt2R5rLKHttleTNsoXYdKrjM9j3RXH3l9d6AASGat/deJn
zvF6O1Z/JhmYNEr9pFUoy5MMIwJK3MC7C0d0RLZlN1I7RfyixkOlPAzv1BbXMsYR
aoaYJY34Xp4FvDLFqcf44jGwQ+G95byHi/COzrpRk2VQjFRsQnMvp6AcjZRfola/
0dXw7V+vUF+bINBEgQv0ZSZMokIkkw==
=VMyO
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Nov 14 08:40:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2F31293D8 for ; Tue, 14 Nov 2017 08:40:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 NvyuoLdym9ZY for ; Tue, 14 Nov 2017 08:40:47 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608FE128D44 for ; Tue, 14 Nov 2017 08:40:47 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id m191so14272697itg.2 for ; Tue, 14 Nov 2017 08:40:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jdyqPb+uWm/3RQIAD7/z6SYZIsEJMd/f8BF9Zju5OJo=; b=kREr/x4lcI1pVLyyFe7msPCkr0NkXzkyX9B4LJVannV9064vmR6vKv4BXlTkAshWQS dc5Zd+0+0V+JMMEN+ZwVfDs0erZaoP9JMaPaaYbRl6mJaL22aBPRA6NL6DQFRz1cQua9 sI/+2YRKdMx79JGkr1mDvF6XhJvutP1GvMjjFR+ehp2o+KfENRFcWdvZyB6MfLZZg8u3 tK35uJnMEU3dtRZ/dW0gW4sKsbUu0cIkWX4fJFrdTa8EnkTMD1sB/ABNFdXfm09YtZhQ 1IIzJogDPk1tf+Gbn9ggQujl2w+ZJWmuX1/e8uHm91thxOqTThGOIuATqHHP99tST5/d oCJQ==
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=jdyqPb+uWm/3RQIAD7/z6SYZIsEJMd/f8BF9Zju5OJo=; b=SfBDACOkLymFvfF1E4xcq9f+ZpG2gSSjrZ2L4al1qnyqZVnZhrelNnvCemEkR97i+q DVGF2NxX6nQZ18MzeDfy6NR02mnDKPOV3bOBC1BRvK8mAiL/JfcPL6kZJtmXUVk+hRii eIKuwXO0l+em37GkweA3ZFLyE4BBi+sqUDZwppECikHSXW0H43uU/4vlk1vJiSxGlBfJ oaU1Yoll6uHQ1nGRE89U7xIt1+QCDk8ktcj+f+K4/FWEMpIz5Ihwtz0KSrAwZs1lI12j 5b5M+fLPN2OyX4dHA0tY5dMurpp/I5lUiKmzSP2SjNO/zCfmC/XYl71fx6rDfVARib7U b5WA==
X-Gm-Message-State: AJaThX4b71Y+lA9qmtb+uM5lkq/IGx3qmmSPSdFzxI7qSC+8tx2ima/l AfnDxKFuKZwO/Dlw20CVjjLFOzylIVq3GYYdgGeO8HVe
X-Google-Smtp-Source: AGs4zMazz/k/8dGGPMjcFTuO6xijGtXIkA/1jszVK4NRzV1P/TIZLMkhqOuRQomqJMy1a+to2SO0E7CV7xBcVQEyX0U=
X-Received: by 10.36.252.68 with SMTP id b65mr15760232ith.151.1510677646233; Tue, 14 Nov 2017 08:40:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.82.19 with HTTP; Tue, 14 Nov 2017 08:40:25 -0800 (PST)
In-Reply-To: <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>
From: Lorenzo Colitti 
Date: Wed, 15 Nov 2017 00:40:25 +0800
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Mark Andrews 
Cc: Philip Homburg , IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary="94eb2c0b285879f050055df40cbb"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 16:40:49 -0000

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

On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews  wrote:

> Is there any reason to run DNS64 at all these days?  ipv4only.arpa can be
> a preconfigured
> zone which allows CLAT to get its mapping.  All the phones have CLAT
> support.


That's an interesting idea. It would work in theory, but such a network
would completely break devices that don't support 464xlat. That gives up
one of the major advantages of NAT64/DNS64, which is that it's a 90%
solution even just by itself - yes, IPv4-only applications and address
literals exist, but most simple client/server applications Just Work behind
it.

It's not true that all phones have clat support. Notably, Apple not only
does not support it but appears ideologically opposed to it on the grounds
that it does not have a good exit strategy (because it makes it possible to
run IPv4-only apps forever).

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


On T=
ue, Nov 14, 2017 at 6:46 AM, Mark Andrews <marka@isc.org> wrote:=

Is there any reason to run DNS64 at all =
these days?=C2=A0 ipv4only.arpa can be a preconfigured

zone which allows CLAT to get its mapping.=C2=A0 All the phones have CLAT s=
upport.

That's an interesting idea. It =
would work in theory, but such a network would completely break=C2=A0device=
s that don't support 464xlat. That gives up one of the major advantages=
 of NAT64/DNS64, which is that it's a 90% solution even just by itself =
- yes, IPv4-only applications and address literals exist, but most simple c=
lient/server applications Just Work behind it.

It&=
#39;s not true that all phones have clat support. Notably, Apple not only d=
oes not support it but appears ideologically opposed to it on the grounds t=
hat it does not have a good exit strategy (because it makes it possible to =
run IPv4-only apps forever).


--94eb2c0b285879f050055df40cbb--


From nobody Tue Nov 14 10:28:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BF61286D6 for ; Tue, 14 Nov 2017 10:28:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 GiR9gNO4jFA1 for ; Tue, 14 Nov 2017 10:28:46 -0800 (PST)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E292212704A for <6man@ietf.org>; Tue, 14 Nov 2017 10:28:45 -0800 (PST)
Received: by mail-io0-x232.google.com with SMTP id d66so25412474ioe.5 for <6man@ietf.org>; Tue, 14 Nov 2017 10:28:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qanqcKINRZWECWxmdTRTyB3XNJWHa832En8ZtWo76K0=; b=kWfuXq6t9EK9XNQxTMvKznjcDSbzw+2BQxFCA4NwXEnDJN5pNWi8j69wcikYvPB/u8 DOheE78ofao5xbfq54veFMr5M4JlnnoAMIWLLEZ4Jdt+VQscB93TwgfJyii8Jo61agIu MYw9MlnTDb0GncEXIo6TCsOvMsadZty8PF9nVMn5MpOpqD4r56vnsvxNVI8gM9ODZKR/ XLOxogQj8FLBFy5cAvc2LJ2Y+36ai/+If6Ugvr76zMutUZ7DnLwGkzDM1S1X+j/moNEM tl8RB4RURe5k8B8e6KRBrQfR5+/4fujc7/ISSuCvZ4PjQMqYg5nbxFKCk36hPskNyYud oxWQ==
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=qanqcKINRZWECWxmdTRTyB3XNJWHa832En8ZtWo76K0=; b=oKaA8wbhwJtQsLyRt9/BzkxFH9OGhmueJ5BRJjjOYAhnfVpHIxZyl9YoZiUd4YRNwl 4QszVg8/Hh6toH0AidxPQKUrNm/aTi/5Zz6lGNqwuPGD2kGf3qdiTUxqXtW8FjxMdpOq vQV89WRTgMyXiF7C8k5g/XWPc/Qx6xyYQxKgsKr7zn362ItdwEBKkHFQjnvNh+X7wYTg j7f+JJuh3I2LdPGiALgsqGmULqNWjvsfsdZviNSEuWMGVmAtr+wPsva3m/SlT5e6AIgU D7eRsdmJ66QPzWpra73egI7EwhcGWsuh2KBdca4qKuOQ2us2lpAZ1lwsawCpkYmQhBdS ymEA==
X-Gm-Message-State: AJaThX5/0wC2t7cVywdKR4LNLFp2cb+rRwAEMw5wAhQDhjwG8PH7AbPw bmS5O0p2zAa6mU9MWQwwbTHrpw==
X-Google-Smtp-Source: AGs4zMZ/J8wZJqPp9e/tFrH8L4yvIxwoGMHnF9Hch6cbRZzNTnpAyM9n/pJIg2l+EvomW0FTOEXE3g==
X-Received: by 10.107.30.81 with SMTP id e78mr15196346ioe.65.1510684125027; Tue, 14 Nov 2017 10:28:45 -0800 (PST)
Received: from dhcp-100-99-229-233.pao.corp.google.com ([100.99.229.233]) by smtp.gmail.com with ESMTPSA id w139sm5714819itb.5.2017.11.14.10.28.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 10:28:44 -0800 (PST)
From: james woodyatt 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_FBA5FFEC-9C5F-458C-A69C-BBE275B82F90"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Upleveling discussion (was Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
Date: Tue, 14 Nov 2017 10:28:43 -0800
In-Reply-To: 
Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
To: Suresh Krishnan 
References:   <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com>    <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>       
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 18:28:47 -0000

--Apple-Mail=_FBA5FFEC-9C5F-458C-A69C-BBE275B82F90
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 13, 2017, at 19:22, Suresh Krishnan  =
wrote:
>=20
> c) The document should be Informational and not BCP
>=20
> Regardless of people claiming on this thread that the IESG chose this =
to be a BCP, it is the *v6ops WG* that decided to send this in as BCP. =
The document was IETF Last Called as BCP way before it even hit the =
IESG. Given that there is no objective guidance in RFC2026 on what =
constitutes a BCP (=E2=80=9Cbest=E2=80=9D and "what is believed to be =
the best way=E2=80=9D are not exactly objective) we could go either way. =
I am inclined to go along with the wishes of the WG (v6ops), the =
shepherding AD (Warren) in the absence of a more definitive measure of =
suitability. That said, as I conveyed to Warren, I would not object if =
this was made Informational either.

In light of its other deficiencies that I=E2=80=99ve previously =
complained about (lack of clarity about some significant contingencies, =
e.g., reclaiming prefixes, ND redirects, et cetera), I=E2=80=99d be =
marginally happier with Informational rather than Best Current Practice.


--james woodyatt >




--Apple-Mail=_FBA5FFEC-9C5F-458C-A69C-BBE275B82F90
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 13, 2017, at 19:22, Suresh Krishnan <suresh.krishnan@gmail.com> wrote:

c) The =
document should be Informational and not BCP

Regardless of people =
claiming on this thread that the IESG chose this to be a BCP, it is the =
*v6ops WG* that decided to send this in as BCP. The document was IETF =
Last Called as BCP way before it even hit the IESG. Given that there is =
no objective guidance in RFC2026 on what constitutes a BCP (=E2=80=9Cbest=E2=
=80=9D and "what is believed to be the best way=E2=80=9D are not exactly =
objective) we could go either way. I am inclined to go along with the =
wishes of the WG (v6ops), the shepherding AD (Warren) in the absence of =
a more definitive measure of suitability. That said, as I conveyed to =
Warren, I would not object if this was made Informational =
either.

In light of =
its other deficiencies that I=E2=80=99ve previously complained about =
(lack of clarity about some significant contingencies, e.g., reclaiming =
prefixes, ND redirects, et cetera), I=E2=80=99d be marginally happier =
with Informational rather than Best Current Practice.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_FBA5FFEC-9C5F-458C-A69C-BBE275B82F90--


From nobody Tue Nov 14 12:16:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF626128792 for ; Tue, 14 Nov 2017 12:16:42 -0800 (PST)
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 9mgjpnsRjJ0Q for ; Tue, 14 Nov 2017 12:16:41 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC92127599 for <6man@ietf.org>; Tue, 14 Nov 2017 12:16:40 -0800 (PST)
X-Original-To: 6man@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6352240ED6 for <6man@ietf.org>; Tue, 14 Nov 2017 21:16:37 +0100 (CET)
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 52A2C40BA5; Tue, 14 Nov 2017 21:16:37 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 43E2734D89; Tue, 14 Nov 2017 21:16:37 +0100 (CET)
Date: Tue, 14 Nov 2017 21:16:37 +0100
From: Gert Doering 
To: james woodyatt 
Cc: Suresh Krishnan , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org>
Subject: Re: [v6ops] Upleveling discussion (was Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
Message-ID: <20171114201637.GP45648@Space.Net>
References:  <862687c9-c107-53a8-288a-29049097b0e1@acm.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 20:16:43 -0000

Hi,

On Tue, Nov 14, 2017 at 10:28:43AM -0800, james woodyatt wrote:
> In light of its other deficiencies that I???ve previously complained
> about (lack of clarity about some significant contingencies, e.g.,
> reclaiming prefixes, ND redirects, et cetera), I???d be marginally
> happier with Informational rather than Best Current Practice.

+1

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

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


From nobody Tue Nov 14 16:06:42 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0512940E for ; Tue, 14 Nov 2017 16:06:40 -0800 (PST)
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 DoBVOp8wdMlw for ; Tue, 14 Nov 2017 16:06:39 -0800 (PST)
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 386F912940C for ; Tue, 14 Nov 2017 16:06:39 -0800 (PST)
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 3C08A3B8D93; Wed, 15 Nov 2017 00:06:37 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 290AC160087; Wed, 15 Nov 2017 00:06:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0EC9016008B; Wed, 15 Nov 2017 00:06:37 +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 dbAEEmjklFgn; Wed, 15 Nov 2017 00:06:36 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 15749160087; Wed, 15 Nov 2017 00:06:35 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
From: Mark Andrews 
In-Reply-To: 
Date: Wed, 15 Nov 2017 11:06:33 +1100
Cc: Philip Homburg , IETF IPv6 Mailing List 
Content-Transfer-Encoding: quoted-printable
Message-Id: <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> 
To: Lorenzo Colitti 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 00:06:40 -0000

> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti  =
wrote:
>=20
> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews  wrote:
> Is there any reason to run DNS64 at all these days?  ipv4only.arpa can =
be a preconfigured
> zone which allows CLAT to get its mapping.  All the phones have CLAT =
support.
>=20
> That's an interesting idea. It would work in theory, but such a =
network would completely break devices that don't support 464xlat. That =
gives up one of the major advantages of NAT64/DNS64, which is that it's =
a 90% solution even just by itself - yes, IPv4-only applications and =
address literals exist, but most simple client/server applications Just =
Work behind it.

And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.  It =
basically requires EVERY DNS VALIDATOR ON
THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64 =
SERVER.

DNS64/NAT64 was presented as NOT REQUIRING node changes when first =
mooted.  It keeps on
requiring more and more highly invasive node changes to support.  It was =
from the very beginning
bad engineering.   To get IPv4 as a service some node changes are =
required.  Lets make sure they
are MINIMAL ones.

Just for the record DNSSEC validators need to send BOTH CD=3D0 and CD=3D1 =
queries to get answers
though a upstream VALIDATING server which includes a VALIDATING DNS64 =
server as CD=3D0 and
CD=3D1 address different DNSSEC threats.  I tried very hard to point =
that out when RFC 6147 was
being written but the working group decide that CD indicated whether the =
client was validating or
not.  There is NO SUCH INDICATION in a DNS message.

  If a query arrives at a vDNS64 device with the "Checking Disabled"
   (CD) bit set, it is an indication that the querying agent wants all
   the validation data so it can do checking itself.  By local policy,
   vDNS64 could still validate, but it must return all data to the
   querying agent anyway.

CD=3D0 queries causes the upstream validating servers to reject incoming =
spoofed answers
or stale answers (this is a common operational problem).

CD=3D1 queries allow the validation to succeed when the upstream =
validator has a bad trust
anchor or a bad clock which is rejecting legitimate answers.

A validating client can=E2=80=99t just send CD=3D1 queries as the =
upstream validator doesn=E2=80=99t kick in.
The upstream validator can lock onto a stale answer source.  It needs to =
send CD=3D0 queries
on validation failure to force the upstream validator to try multiple =
sources.

A validating client can=E2=80=99t just send CD=3D0.  It needs to send =
CD=3D1 on SERVFAIL in case the
upstream validator has a bad trust anchor (likely with the upcoming root =
KSK roll) or has
a bad clock (these usually get fixed fast).

Now to get a answer from a signed zone with servers with stale answers a =
validatiing DNS64 client
needs to send:

a) send CD=3D1 and validation failure send CD=3D0 then on AAAA =
validation failure send CD=3D1 and
    hope the TTL was not 0 and that is not cachable and there is no =
assurance that you won=E2=80=99t get
    a answer from a stale source.

	or

b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 and =
hope the TTL was not 0 as
    that is not cachable and there is no assurance that you won=E2=80=99t =
get a answer from a stale source.

TTL=3D0 answers exist.

Note none of this is documented in a RFC.  You have to understand how =
both DNSSEC and DNS64 work to
realise this.

IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix =
discover for DNS VALIDATORS.
Note =E2=80=9Cad=E2=80=9D is set in the flags.  Yes, I=E2=80=99ve =
submitted a errata.  Yes, I=E2=80=99ve opened a ticket to get it fixed =
but
based on past experience that could take months if it happens at all.  =
You will note that the recursive
server is running on the loopback interface so all DNS answers are being =
validated here.

[rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
;; QUESTION SECTION:
;IPV4ONLY.ARPA.			IN	A

;; ANSWER SECTION:
ipv4only.arpa.		26574	IN	A	192.0.0.171
ipv4only.arpa.		26574	IN	A	192.0.0.170

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
;; MSG SIZE  rcvd: 115

[rock:bind9/bin/named] marka%=20

> It's not true that all phones have clat support. Notably, Apple not =
only does not support it but appears ideologically opposed to it on the =
grounds that it does not have a good exit strategy (because it makes it =
possible to run IPv4-only apps forever).


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


From nobody Tue Nov 14 18:08:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89786126BF7 for ; Tue, 14 Nov 2017 18:08:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CWhO1QB_C6Rp for ; Tue, 14 Nov 2017 18:08:18 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873051200CF for ; Tue, 14 Nov 2017 18:08:18 -0800 (PST)
Received: from h.hanazo.no (dhcp-809d.meeting.ietf.org [31.133.128.157]) (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 341112D5126; Wed, 15 Nov 2017 02:08:17 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id EAFCC200C1CAFF; Wed, 15 Nov 2017 10:07:53 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_32A4927A-AD60-407D-BECC-AB0448774C78"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Wed, 15 Nov 2017 10:07:52 +0800
In-Reply-To: <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>
Cc: Lorenzo Colitti , 6man WG 
To: Mark Andrews 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 02:08:20 -0000

--Apple-Mail=_32A4927A-AD60-407D-BECC-AB0448774C78
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Mark,

Thanks for doing the analysis of this. It will take me some time to =
digest.

If I may try to suggest a solution based on what you are saying:

- Remove (external) DNS64 from the solution
- Replace NAT64 prefix discovery with some sort of local configuration. =
e.g. put it in DHCP or RA

Which has the implications that:
 - host learns NAT64 prefix via RA/DHCP
 - host is free to use whatever DNS recursive resolvers (instead of the =
must be local (and on correct interface where the NAT64 is) resolver
 - host synthesises addresses itself. And does validation before =
synthesising (if that's required).

Is this the solution you would be looking for?

And yes, you need host changes. But we need that anyway.

Cheers,
Ole




> On 15 Nov 2017, at 08:06, Mark Andrews  wrote:
>=20
>=20
>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti  =
wrote:
>>=20
>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews  wrote:
>> Is there any reason to run DNS64 at all these days?  ipv4only.arpa =
can be a preconfigured
>> zone which allows CLAT to get its mapping.  All the phones have CLAT =
support.
>>=20
>> That's an interesting idea. It would work in theory, but such a =
network would completely break devices that don't support 464xlat. That =
gives up one of the major advantages of NAT64/DNS64, which is that it's =
a 90% solution even just by itself - yes, IPv4-only applications and =
address literals exist, but most simple client/server applications Just =
Work behind it.
>=20
> And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.  It =
basically requires EVERY DNS VALIDATOR ON
> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64 =
SERVER.
>=20
> DNS64/NAT64 was presented as NOT REQUIRING node changes when first =
mooted.  It keeps on
> requiring more and more highly invasive node changes to support.  It =
was from the very beginning
> bad engineering.   To get IPv4 as a service some node changes are =
required.  Lets make sure they
> are MINIMAL ones.
>=20
> Just for the record DNSSEC validators need to send BOTH CD=3D0 and =
CD=3D1 queries to get answers
> though a upstream VALIDATING server which includes a VALIDATING DNS64 =
server as CD=3D0 and
> CD=3D1 address different DNSSEC threats.  I tried very hard to point =
that out when RFC 6147 was
> being written but the working group decide that CD indicated whether =
the client was validating or
> not.  There is NO SUCH INDICATION in a DNS message.
>=20
>  If a query arrives at a vDNS64 device with the "Checking Disabled"
>   (CD) bit set, it is an indication that the querying agent wants all
>   the validation data so it can do checking itself.  By local policy,
>   vDNS64 could still validate, but it must return all data to the
>   querying agent anyway.
>=20
> CD=3D0 queries causes the upstream validating servers to reject =
incoming spoofed answers
> or stale answers (this is a common operational problem).
>=20
> CD=3D1 queries allow the validation to succeed when the upstream =
validator has a bad trust
> anchor or a bad clock which is rejecting legitimate answers.
>=20
> A validating client can=E2=80=99t just send CD=3D1 queries as the =
upstream validator doesn=E2=80=99t kick in.
> The upstream validator can lock onto a stale answer source.  It needs =
to send CD=3D0 queries
> on validation failure to force the upstream validator to try multiple =
sources.
>=20
> A validating client can=E2=80=99t just send CD=3D0.  It needs to send =
CD=3D1 on SERVFAIL in case the
> upstream validator has a bad trust anchor (likely with the upcoming =
root KSK roll) or has
> a bad clock (these usually get fixed fast).
>=20
> Now to get a answer from a signed zone with servers with stale answers =
a validatiing DNS64 client
> needs to send:
>=20
> a) send CD=3D1 and validation failure send CD=3D0 then on AAAA =
validation failure send CD=3D1 and
>    hope the TTL was not 0 and that is not cachable and there is no =
assurance that you won=E2=80=99t get
>    a answer from a stale source.
>=20
> 	or
>=20
> b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 and =
hope the TTL was not 0 as
>    that is not cachable and there is no assurance that you won=E2=80=99t=
 get a answer from a stale source.
>=20
> TTL=3D0 answers exist.
>=20
> Note none of this is documented in a RFC.  You have to understand how =
both DNSSEC and DNS64 work to
> realise this.
>=20
> IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix =
discover for DNS VALIDATORS.
> Note =E2=80=9Cad=E2=80=9D is set in the flags.  Yes, I=E2=80=99ve =
submitted a errata.  Yes, I=E2=80=99ve opened a ticket to get it fixed =
but
> based on past experience that could take months if it happens at all.  =
You will note that the recursive
> server is running on the loopback interface so all DNS answers are =
being validated here.
>=20
> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
> ;; BADCOOKIE, retrying.
>=20
> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: =
1
>=20
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
> ;; QUESTION SECTION:
> ;IPV4ONLY.ARPA.			IN	A
>=20
> ;; ANSWER SECTION:
> ipv4only.arpa.		26574	IN	A	192.0.0.171
> ipv4only.arpa.		26574	IN	A	192.0.0.170
>=20
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
> ;; MSG SIZE  rcvd: 115
>=20
> [rock:bind9/bin/named] marka%
>=20
>> It's not true that all phones have clat support. Notably, Apple not =
only does not support it but appears ideologically opposed to it on the =
grounds that it does not have a good exit strategy (because it makes it =
possible to run IPv4-only apps forever).
>=20
>=20
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--Apple-Mail=_32A4927A-AD60-407D-BECC-AB0448774C78
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+/bDNdvtpYqJhC33YFAloLoXgACgkQvtpYqJhC
33YFOA//QeeH2W44QhJlBdRYdIwiRcZ+8ZOnbR2p3LqmwQu5CTw3HUuAnla7KNJw
dEaJUo03rmf09p687sDamhXa+MHE/3kxySY0ZZe2piI74pddWFzQ82gBb2sIPwWd
k7wq5Zfq7H7fG2Qnp6zbx89hW0RS+Go6+lQHKY/F952UmP/Ram9rHaXmnB2Dv0uM
IluuL73PccMOjSLwMll8JDEA5t8Ny6BEPoaopd9c9Dx/T6fWr+okJqr+D3+oblEd
cB0gcSxBt5Envu0LJ6/IuyqrN5uyYZknl16kZF8af2fDkBj+eoD1phgdUJ6mjpv4
bHgKu1IRaHnB7gUcgG1435CxagRrjVzW/ffAI1GUaPxgaimbioWMYPv+onYfeTCg
KdRF4v7rEPKtm5qieG1/CJJfL+4HbgrFoGlSjZg2C6xkdgr+1WEGXIXygbWzqjMQ
izLDem9PGOlnfI3ehpN05UJkfxlRPBMKakYymD+JAz+ji2kAzP+Xzjz3c11GkTag
BiZQbd168s9hLiik9B+X4uJuRfO6wwxHrXD/omZrydxyHUwAwmJfWNrSiNg0JoE2
HajTn5ZsVqqHl+57epjWzGd8sw/N4eO6nl/EvHVa7CiGLMiHw8RFaEC58rRLoC5S
Zi7qQLlR6W7QguZHt0GKvooj6IChDTyr/MX0gdGvMfJXZvo7wqI=
=tICC
-----END PGP SIGNATURE-----

--Apple-Mail=_32A4927A-AD60-407D-BECC-AB0448774C78--


From nobody Tue Nov 14 18:12:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2A126D73 for ; Tue, 14 Nov 2017 18:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.018
X-Spam-Level: 
X-Spam-Status: No, score=-1.018 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_FONT_FACE_BAD=0.981, 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 KEcmDTfVZ95y for ; Tue, 14 Nov 2017 18:12:01 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D2B126BF7 for ; Tue, 14 Nov 2017 18:12:01 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id u70so11072915pfa.7 for ; Tue, 14 Nov 2017 18:12:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:message-id:date:user-agent:mime-version :content-language; bh=xkTrmInbSTPlitCuw0lbFDMMr0/36x4fEQfNDw7cXN0=; b=O28Q73ZyrAZa0KTsYy9evjaiAfCx+rdyEVlmjDOW+IY5E0uXhg+haAqHi90AJmK3xA sjO/CpxON1ecwZuB8jdys1cifjKY6zVGkKtnQgPBi3OHHl2V51IIcfkI1tzsB3cJJBYP 5+7vZw35VZvSGJj9PQakeI2pmg9pXh9NQu1xaeGxO4vgya3xWrCwxhnz16qXmBxd4GaQ aTCzYM+xQBvnUClNNerpgcz1WCZjO7Il5DNb++bMA60wjspQNuzWW+mZvVywqfeyVfiM LtEhVViPmsi8t9EYkYrUY5t9mkTHkxN6ZDsr/ZKbPDoIPQ/YZyPftOk+ll+1Okd/1uXC FBpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language; bh=xkTrmInbSTPlitCuw0lbFDMMr0/36x4fEQfNDw7cXN0=; b=e3JeP78PNynUjvCbd/IepkP5mecny1pT8C1hx1LHdvXJqripVIn3gxzwFYorsxlJVS vKQ0bcSh0AY5C69wAzN7qcH1rgupRXX5pe/oQrDsU0P7QAKRTxXmKtmw3RhZgiiHWucx Ro3nwM81FvOwpvYnQY6PohJHhJTn7KHCPdy54ES/6e7hX/ptgqMgNcyt3mJjuf3DUu2y O8YTrsgD/6uzOZX7bOxNmcuH5K1tuKH38/L2B2QpJLZRCm9dutAPM2J06cdhkP9EOIQk 8U3pQa1L5/nrlQ/8c80qJuzaGXZnp8qrxCVjpRdwn0u8xjyNVuFl2RaAk0bCWSlR2ph5 t43Q==
X-Gm-Message-State: AJaThX6HZlsKVOMeAuzma0Kph+6qCYVNHE2yPdIycc4wu55a/zYJ0sE9 4ZOTRt408U5UBGtrvwGK81Jd+w==
X-Google-Smtp-Source: AGs4zMaZ40QVzhK90CToOpD189W3wmM2zwCIwDfVkwUYrSkxv65PN4VdVNmtpCxUBHRXVPJbjbz/eg==
X-Received: by 10.98.61.80 with SMTP id k77mr15482631pfa.226.1510711921054; Tue, 14 Nov 2017 18:12:01 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1999:39cf:9f16:b725:a56a? ([2001:67c:370:1999:39cf:9f16:b725:a56a]) by smtp.gmail.com with ESMTPSA id t81sm40198555pfg.187.2017.11.14.18.11.59 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 18:12:00 -0800 (PST)
From: Alexandre Petrescu 
X-Google-Original-From: Alexandre Petrescu 
To: IPv6 
Subject: skype and ping, Windows, on IPv6-related SSIDs at IETF 100
Message-ID: 
Date: Wed, 15 Nov 2017 03:11:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------5C9C019C00F0FE363E7A631C"
Content-Language: fr
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 02:12:03 -0000

This is a multi-part message in MIME format.
--------------5C9C019C00F0FE363E7A631C
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

These are the tests for skype and ping, Windows, on IPv6-related SSIDs 
at IETF 100.

Table says that skype can not connect if on ietf-v6ONLY but can connect 
if on the ietf-nat64, even though no test call can be made on either:

            ietf-v6ONLY, IPv6-only Host|    ietf-nat64, IPv6-only Host
---------------------------+------------------------------
connect         no                  |         yes
test call no                  |          no


Bonus test: ping.
                   ietf-v6ONLY, IPv6-only Host|    ietf-nat64, IPv6-only 
Host
---------------------------+------------------------------
ping 8.8.8.8             no                  |         no
ping google.com     yes                 |         yes


The IPv6-only Host is a Host that connects to a network that does not 
give it an IPv4 address nor an IPv4 default route.  The IPv6-only Host 
still has an IPv4 stack and many IPv4 literals on it.  A "not-IPv4 Host" 
is a Host that removed its IPv4 stack, or has no IPv4 stack at 
manufacture time[*].

Alex
[*] On Windows uncheck the IPv4 box on the network interface 
Properties.  On Windows this does not remove entirely the IPv4 from the 
Host (there is still e.g. IPv4 routing table entries for the loopback) 
but it does has some effect of IPv4 removal, like disappearance of the 
IPv4 link-local address.  On linux it's impossible to remove the IPv4 
stack.  On contiki IIRC there is no IPv4 stack whatsoever (but its IPv6 
is not that IPv6 either). Ideally, a not-IPv4 Host has nothing about 
IPv4 on it: no stack, no rt table entries, no literals in /etc/hosts, 
and probably more.

On Windows, one could try to Uninstall the "IPv4", instead of just 
unchecking IPv4; but I suspect this removal to be risky.  I wont try it 
at IETF on my work computer.

--------------5C9C019C00F0FE363E7A631C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    These are the tests for
        skype and ping, Windows, on IPv6-related SSIDs at IETF 100.

        

        Table says that skype can not connect if on ietf-v6ONLY but can
        connect if on the ietf-nat64, even though no test call can be
        made on either:

        

                   ietf-v6ONLY, IPv6-only Host|    ietf-nat64, IPv6-only
        Host 

                  
        ---------------------------+------------------------------

      connect  
                no                  |         yes                   

    test call        
        no                  |          no                   

        

        

        Bonus test: ping.

                      ietf-v6ONLY, IPv6-only
            Host|    ietf-nat64, IPv6-only Host

                             
            ---------------------------+------------------------------

          ping
            8.8.8.8             no                  |         no 
                             

        ping google.com     
                yes                 |         yes                  

            

          

        The IPv6-only Host is a Host that connects to a network that
        does not give it an IPv4 address nor an IPv4 default route.  The
        IPv6-only Host still has an IPv4 stack and many IPv4 literals on
        it.  A "not-IPv4
        Host" is a Host that removed its IPv4 stack, or has no IPv4
        stack at manufacture time[*].

        

      Alex

          [*] On Windows uncheck
                the IPv4 box on the network interface Properties.  On
                Windows this does not remove entirely the IPv4 from the
                Host (there is still e.g. IPv4 routing table entries for
                the loopback) but it does has some effect of IPv4
                removal, like disappearance of the IPv4 link-local
                address.  On linux it's impossible to remove the IPv4
                stack.  On contiki IIRC there is no IPv4 stack
                whatsoever (but its IPv6 is not that IPv6 either). 
                Ideally, a not-IPv4 Host has nothing about IPv4 on it:
                no stack, no rt table entries, no literals in
                /etc/hosts, and probably more.

                

                On Windows, one could try to Uninstall the "IPv4",
                instead of just unchecking IPv4; but I suspect this
                removal to be risky.  I wont try it at IETF on my work
                computer.

               
  


--------------5C9C019C00F0FE363E7A631C--


From nobody Tue Nov 14 18:13:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8188129478 for ; Tue, 14 Nov 2017 18:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEiPtW1ZD7Gr for ; Tue, 14 Nov 2017 18:13:10 -0800 (PST)
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 681E9129477 for ; Tue, 14 Nov 2017 18:13:10 -0800 (PST)
Received: by mail-pf0-x231.google.com with SMTP id d28so15885936pfe.2 for ; Tue, 14 Nov 2017 18:13:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:message-id:date:user-agent:mime-version :content-language; bh=LkyU9v5gdelr4U9/GpKUDFSSShnvZls4UyPcpT55YPk=; b=rCUrhoFZ1H8pgjlhSYhWC6uyOOOTyFHmDVqTcBfAGW3CV1HCWVxD5aPwntJX6w2kys NVcTbrr7Nip/j4cTvzmeQApn6fBQ6rANMV2K9FOZobJ1uz1ePSOKbPZ7poNLDt6LtO7p 1Vf8gkvIDvuZ+8NMdwBMrAzZQIoUM5b3l5HPSx5jyfij1lyLz728MzLkimdpIIddwr2R 7DpzNEo3HxiwviX0Q8jYOaW1RtyvtkeqYznd2bAyeQoxhWwdRyvu1xiVTb+GUBmXZGPw d3elcIqnnHIj7dZGHUvVUI+Amsol9BElyvIHYvmpczVTKGD17ADQOadPd90/KRNwOkR9 zBkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language; bh=LkyU9v5gdelr4U9/GpKUDFSSShnvZls4UyPcpT55YPk=; b=nY79RVInLKictre04wmoomnSO+ioYZMcER/0659SPZZBIfDk9Y7s99SN9nM1ZzCcNc M2Ol1Z+AiZOLiUEs70v2u62Tmufl5Gl8K8CJ4GOR+lvzQcuc7abu7KXwxgLlO0gHMjql el4tnLWBPTfRLzSCn7rVJvvaA7XOyyEWZMIk2snobwePEAqI0rtpRW77ubc9xmorg5lH 2U44q9apVleHtUKU5Tb6XEvDZMW9MM180IkVdNbuZFRwj7PEt/MDe0Des5oKlu1+FItJ ntqRc8QN/DljXfgM7zHSRu5MOrjDuH+TM3K/geFF8tiKGmW5BW3kZ7jJFyrv6lvLfJ1j dIGw==
X-Gm-Message-State: AJaThX4tr69m21pJoYylImWZBwnvvCmEueJoZ79sL8PGmdYVcU/O1QMa tzTsVNyNI1fpp3NH6fVXCM8dUg==
X-Google-Smtp-Source: AGs4zMaOdnbrVyYz094Po3yyYVXSAzQc8y1dMz3X7L2b4dMmpQ6EAt+LlqCw8HQLUxQGKTl95bTfpQ==
X-Received: by 10.84.175.129 with SMTP id t1mr14088890plb.193.1510711989898; Tue, 14 Nov 2017 18:13:09 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1999:39cf:9f16:b725:a56a? ([2001:67c:370:1999:39cf:9f16:b725:a56a]) by smtp.gmail.com with ESMTPSA id 186sm22538604pfe.176.2017.11.14.18.13.08 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 18:13:09 -0800 (PST)
From: Alexandre Petrescu 
X-Google-Original-From: Alexandre Petrescu 
To: IPv6 
Subject: IPv4 traffic on "ietf-v6ONLY"
Message-ID: 
Date: Wed, 15 Nov 2017 03:13:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------EAF73777BC92F79EFA519199"
Content-Language: fr
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 02:13:12 -0000

This is a multi-part message in MIME format.
--------------EAF73777BC92F79EFA519199
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.

Alex


--------------EAF73777BC92F79EFA519199
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
There is much IPv4
          traffic on the "ietf-v6ONLY" ESSID.

    
Alex

        

  


--------------EAF73777BC92F79EFA519199--


From nobody Tue Nov 14 18:34:56 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAA4129477 for ; Tue, 14 Nov 2017 18:34:55 -0800 (PST)
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 jcQdPkYLDhjW for ; Tue, 14 Nov 2017 18:34:52 -0800 (PST)
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 6D9E9120724 for ; Tue, 14 Nov 2017 18:34:52 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id j198so1479676ywg.9 for ; Tue, 14 Nov 2017 18:34:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NihYYYo1DwtFxVAm/FJNQ+nPdtEBmbE19WT8cgYB2wg=; b=GQQgAI//+u6bAVHqFalohIOTax45u1x18+sAjwPW91BPGXtsyEVerHRnt2oR2CbAvp 1JclL+PTfp6rJ2MIFQRZXIWj/RUkHMAqgN3V5ChDNsVfq0xG5AncwrTb7I6Qm7cphacF YB4gAJGkXnhzRSIRm1+HiRpBxFkdMDZj5p1kO2K0APImYqx2iKc2H2Rw6qV9WCJ8w1JX GPBpPVxKhyq3TxcqJx5yp+igUC3s/FQR3CPZjFOfMZaCj1219uy735P8wfQbc8FO1vhn 52PLbZ1xcHqYDjxbaI5Km4JXZCT1I3vyEVcwT8hLGUMG0ZBBrwIKu6zcUl+Dadjy7vip h7jA==
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=NihYYYo1DwtFxVAm/FJNQ+nPdtEBmbE19WT8cgYB2wg=; b=TmdnlLtgYBh2N+gp49662IAYPbA+WRvkkZvAo+OtxLsaZsblngfSrMpLO2szy1ZXv8 Tw5myT+wgRfsVApty4Ytb+eRRx1GtE6KNOM1cuQp6FiR1LeDI3jxqrsoXEbrEa5nVRx0 RVent4eMynO7N8KI8+YsSoj+moPIFf8yfpxx3FN+3uwP6i+ERIL0oxcdb5evwjy5GZ2k GwUNKYYK44GwhURCl/nQvDMu/px1QccCbe+Jt5NM1dRTcm4fksmrFNOMXG+rIFJ6MKiG lYNFdxxglABIOqTJFdWXW/OcSBGnHAGG51jtg37O8a0XUXMNnkyUT0lkBjyWPU2jsbnt QYfA==
X-Gm-Message-State: AJaThX6r5eVNrCGWn+ZV9SgyCews36KFvrFKyjIGXamgfjc3AiohD0bK zXLz/CZpEYbF+6+FxyYJR+tOEpwCxWZY4IKp4sM=
X-Google-Smtp-Source: AGs4zMat60dPMMOXyCwFk513WXaRgU90wzK6LGSfIGz7ow8ptM7xxySTHvsFNFy+NxQoFI8HDATzca6SPrHDrsWKp3k=
X-Received: by 10.37.20.193 with SMTP id 184mr8436636ybu.400.1510713291616; Tue, 14 Nov 2017 18:34:51 -0800 (PST)
MIME-Version: 1.0
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> 
In-Reply-To: 
From: Ca By 
Date: Wed, 15 Nov 2017 02:34:40 +0000
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: 6man WG , Mark Andrews 
Content-Type: multipart/alternative; boundary="001a113e72b61ab88a055dfc5969"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 02:34:55 -0000

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

On Tue, Nov 14, 2017 at 6:08 PM Ole Troan  wrote:

> Mark,
>
> Thanks for doing the analysis of this. It will take me some time to diges=
t.
>
> If I may try to suggest a solution based on what you are saying:
>
> - Remove (external) DNS64 from the solution
> - Replace NAT64 prefix discovery with some sort of local configuration.
> e.g. put it in DHCP or RA
>
> Which has the implications that:
>  - host learns NAT64 prefix via RA/DHCP
>  - host is free to use whatever DNS recursive resolvers (instead of the
> must be local (and on correct interface where the NAT64 is) resolver
>  - host synthesises addresses itself. And does validation before
> synthesising (if that's required).
>
> Is this the solution you would be looking for?
>
> And yes, you need host changes. But we need that anyway.
>

Or your peer node could deploy ipv6 and be done with all these transition
nonsense.

As has been reported in elsewhere, docsis and 3gpp networks see 50+ and
70+% of their bits moved to ipv6.   The problem size is waning quickly,
especially on modern OS


> Cheers,
> Ole
>
>
>
>
> > On 15 Nov 2017, at 08:06, Mark Andrews  wrote:
> >
> >
> >> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti  wrote=
:
> >>
> >> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews  wrote:
> >> Is there any reason to run DNS64 at all these days?  ipv4only.arpa can
> be a preconfigured
> >> zone which allows CLAT to get its mapping.  All the phones have CLAT
> support.
> >>
> >> That's an interesting idea. It would work in theory, but such a networ=
k
> would completely break devices that don't support 464xlat. That gives up
> one of the major advantages of NAT64/DNS64, which is that it's a 90%
> solution even just by itself - yes, IPv4-only applications and address
> literals exist, but most simple client/server applications Just Work behi=
nd
> it.
> >
> > And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.  It bas=
ically requires
> EVERY DNS VALIDATOR ON
> > THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64
> SERVER.
> >
> > DNS64/NAT64 was presented as NOT REQUIRING node changes when first
> mooted.  It keeps on
> > requiring more and more highly invasive node changes to support.  It wa=
s
> from the very beginning
> > bad engineering.   To get IPv4 as a service some node changes are
> required.  Lets make sure they
> > are MINIMAL ones.
> >
> > Just for the record DNSSEC validators need to send BOTH CD=3D0 and CD=
=3D1
> queries to get answers
> > though a upstream VALIDATING server which includes a VALIDATING DNS64
> server as CD=3D0 and
> > CD=3D1 address different DNSSEC threats.  I tried very hard to point th=
at
> out when RFC 6147 was
> > being written but the working group decide that CD indicated whether th=
e
> client was validating or
> > not.  There is NO SUCH INDICATION in a DNS message.
> >
> >  If a query arrives at a vDNS64 device with the "Checking Disabled"
> >   (CD) bit set, it is an indication that the querying agent wants all
> >   the validation data so it can do checking itself.  By local policy,
> >   vDNS64 could still validate, but it must return all data to the
> >   querying agent anyway.
> >
> > CD=3D0 queries causes the upstream validating servers to reject incomin=
g
> spoofed answers
> > or stale answers (this is a common operational problem).
> >
> > CD=3D1 queries allow the validation to succeed when the upstream valida=
tor
> has a bad trust
> > anchor or a bad clock which is rejecting legitimate answers.
> >
> > A validating client can=E2=80=99t just send CD=3D1 queries as the upstr=
eam
> validator doesn=E2=80=99t kick in.
> > The upstream validator can lock onto a stale answer source.  It needs t=
o
> send CD=3D0 queries
> > on validation failure to force the upstream validator to try multiple
> sources.
> >
> > A validating client can=E2=80=99t just send CD=3D0.  It needs to send C=
D=3D1 on
> SERVFAIL in case the
> > upstream validator has a bad trust anchor (likely with the upcoming roo=
t
> KSK roll) or has
> > a bad clock (these usually get fixed fast).
> >
> > Now to get a answer from a signed zone with servers with stale answers =
a
> validatiing DNS64 client
> > needs to send:
> >
> > a) send CD=3D1 and validation failure send CD=3D0 then on AAAA validati=
on
> failure send CD=3D1 and
> >    hope the TTL was not 0 and that is not cachable and there is no
> assurance that you won=E2=80=99t get
> >    a answer from a stale source.
> >
> >       or
> >
> > b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 and ho=
pe
> the TTL was not 0 as
> >    that is not cachable and there is no assurance that you won=E2=80=99=
t get a
> answer from a stale source.
> >
> > TTL=3D0 answers exist.
> >
> > Note none of this is documented in a RFC.  You have to understand how
> both DNSSEC and DNS64 work to
> > realise this.
> >
> > IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix
> discover for DNS VALIDATORS.
> > Note =E2=80=9Cad=E2=80=9D is set in the flags.  Yes, I=E2=80=99ve submi=
tted a errata.  Yes, I=E2=80=99ve
> opened a ticket to get it fixed but
> > based on past experience that could take months if it happens at all.
> You will note that the recursive
> > server is running on the loopback interface so all DNS answers are bein=
g
> validated here.
> >
> > [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
> > ;; BADCOOKIE, retrying.
> >
> > ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
> > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 4096
> > ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
> > ;; QUESTION SECTION:
> > ;IPV4ONLY.ARPA.                       IN      A
> >
> > ;; ANSWER SECTION:
> > ipv4only.arpa.                26574   IN      A       192.0.0.171
> > ipv4only.arpa.                26574   IN      A       192.0.0.170
> >
> > ;; Query time: 0 msec
> > ;; SERVER: 127.0.0.1#53(127.0.0.1)
> > ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
> > ;; MSG SIZE  rcvd: 115
> >
> > [rock:bind9/bin/named] marka%
> >
> >> It's not true that all phones have clat support. Notably, Apple not
> only does not support it but appears ideologically opposed to it on the
> grounds that it does not have a good exit strategy (because it makes it
> possible to run IPv4-only apps forever).
> >
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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



On Tue, Nov 14, 2017 =
at 6:08 PM Ole Troan <otroan@emp=
loyees.org> wrote:
Mark,


Thanks for doing the analysis of this. It will take me some time to digest.=




If I may try to suggest a solution based on what you are saying:



- Remove (external) DNS64 from the solution

- Replace NAT64 prefix discovery with some sort of local configuration. e.g=
. put it in DHCP or RA



Which has the implications that:

=C2=A0- host learns NAT64 prefix via RA/DHCP

=C2=A0- host is free to use whatever DNS recursive resolvers (instead of th=
e must be local (and on correct interface where the NAT64 is) resolver

=C2=A0- host synthesises addresses itself. And does validation before synth=
esising (if that's required).



Is this the solution you would be looking for?



And yes, you need host changes. But we need that anyway.



Or your peer nod=
e could deploy ipv6 and be done with all these transition nonsense.=C2=A0

As has been reported in e=
lsewhere, docsis and 3gpp networks see 50+ and 70+% of their bits moved to =
ipv6. =C2=A0 The problem size is waning quickly, especially on modern OS



Cheers,

Ole









> On 15 Nov 2017, at 08:06, Mark Andrews <marka@isc.org> wrote:

>

>

>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti <lorenzo@google.com> wrote:

>>

>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews <marka@isc.org> wrote:

>> Is there any reason to run DNS64 at all these days?=C2=A0 ipv4only=
.arpa can be a preconfigured

>> zone which allows CLAT to get its mapping.=C2=A0 All the phones ha=
ve CLAT support.

>>

>> That's an interesting idea. It would work in theory, but such =
a network would completely break devices that don't support 464xlat. Th=
at gives up one of the major advantages of NAT64/DNS64, which is that it=
9;s a 90% solution even just by itself - yes, IPv4-only applications and ad=
dress literals exist, but most simple client/server applications Just Work =
behind it.

>

> And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.=C2=A0 =
It basically requires EVERY DNS VALIDATOR ON

> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64 SER=
VER.

>

> DNS64/NAT64 was presented as NOT REQUIRING node changes when first moo=
ted.=C2=A0 It keeps on

> requiring more and more highly invasive node changes to support.=C2=A0=
 It was from the very beginning

> bad engineering.=C2=A0 =C2=A0To get IPv4 as a service some node change=
s are required.=C2=A0 Lets make sure they

> are MINIMAL ones.

>

> Just for the record DNSSEC validators need to send BOTH CD=3D0 and CD=
=3D1 queries to get answers

> though a upstream VALIDATING server which includes a VALIDATING DNS64 =
server as CD=3D0 and

> CD=3D1 address different DNSSEC threats.=C2=A0 I tried very hard to po=
int that out when RFC 6147 was

> being written but the working group decide that CD indicated whether t=
he client was validating or

> not.=C2=A0 There is NO SUCH INDICATION in a DNS message.

>

>=C2=A0 If a query arrives at a vDNS64 device with the "Checking Di=
sabled"

>=C2=A0 =C2=A0(CD) bit set, it is an indication that the querying agent =
wants all

>=C2=A0 =C2=A0the validation data so it can do checking itself.=C2=A0 By=
 local policy,

>=C2=A0 =C2=A0vDNS64 could still validate, but it must return all data t=
o the

>=C2=A0 =C2=A0querying agent anyway.

>

> CD=3D0 queries causes the upstream validating servers to reject incomi=
ng spoofed answers

> or stale answers (this is a common operational problem).

>

> CD=3D1 queries allow the validation to succeed when the upstream valid=
ator has a bad trust

> anchor or a bad clock which is rejecting legitimate answers.

>

> A validating client can=E2=80=99t just send CD=3D1 queries as the upst=
ream validator doesn=E2=80=99t kick in.

> The upstream validator can lock onto a stale answer source.=C2=A0 It n=
eeds to send CD=3D0 queries

> on validation failure to force the upstream validator to try multiple =
sources.

>

> A validating client can=E2=80=99t just send CD=3D0.=C2=A0 It needs to =
send CD=3D1 on SERVFAIL in case the

> upstream validator has a bad trust anchor (likely with the upcoming ro=
ot KSK roll) or has

> a bad clock (these usually get fixed fast).

>

> Now to get a answer from a signed zone with servers with stale answers=
 a validatiing DNS64 client

> needs to send:

>

> a) send CD=3D1 and validation failure send CD=3D0 then on AAAA validat=
ion failure send CD=3D1 and

>=C2=A0 =C2=A0 hope the TTL was not 0 and that is not cachable and there=
 is no assurance that you won=E2=80=99t get

>=C2=A0 =C2=A0 a answer from a stale source.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0or

>

> b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 and h=
ope the TTL was not 0 as

>=C2=A0 =C2=A0 that is not cachable and there is no assurance that you w=
on=E2=80=99t get a answer from a stale source.

>

> TTL=3D0 answers exist.

>

> Note none of this is documented in a RFC.=C2=A0 You have to understand=
 how both DNSSEC and DNS64 work to

> realise this.

>

> IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix=
 discover for DNS VALIDATORS.

> Note =E2=80=9Cad=E2=80=9D is set in the flags.=C2=A0 Yes, I=E2=80=99ve=
 submitted a errata.=C2=A0 Yes, I=E2=80=99ve opened a ticket to get it fixe=
d but

> based on past experience that could take months if it happens at all.=
=C2=A0 You will note that the recursive

> server is running on the loopback interface so all DNS answers are bei=
ng validated here.

>

> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA

> ;; BADCOOKIE, retrying.

>

> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>=
;> IPV4ONLY.ARPA

> ;; global options: +cmd

> ;; Got answer:

> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: =
1

>

> ;; OPT PSEUDOSECTION:

> ; EDNS: version: 0, flags:; udp: 4096

> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)

> ;; QUESTION SECTION:

> ;IPV4ONLY.ARPA.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0IN=C2=A0 =C2=A0 =C2=A0 A

>

> ;; ANSWER SECTION:

> ipv4only.arpa.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
26574=C2=A0 =C2=A0IN=C2=A0 =C2=A0 =C2=A0 A=C2=A0 =C2=A0 =C2=A0 =C2=A0192.0.=
0.171

> ipv4only.arpa.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
26574=C2=A0 =C2=A0IN=C2=A0 =C2=A0 =C2=A0 A=C2=A0 =C2=A0 =C2=A0 =C2=A0192.0.=
0.170

>

> ;; Query time: 0 msec

> ;; SERVER: 127.0.0.1#53(127.0.0.1)

> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017

> ;; MSG SIZE=C2=A0 rcvd: 115

>

> [rock:bind9/bin/named] marka%

>

>> It's not true that all phones have clat support. Notably, Appl=
e not only does not support it but appears ideologically opposed to it on t=
he grounds that it does not have a good exit strategy (because it makes it =
possible to run IPv4-only apps forever).

>

>

> --

> Mark Andrews, ISC

> 1 Seymour St., Dundas Valley, NSW 2117, Australia

> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 INTERNET: marka@isc.org=


>

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list

> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman=
/listinfo/ipv6

> --------------------------------------------------------------------


--------------------------------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/list=
info/ipv6

--------------------------------------------------------------------




--001a113e72b61ab88a055dfc5969--


From nobody Tue Nov 14 18:44:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340E81205F0 for ; Tue, 14 Nov 2017 18:44:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5d6hfY58eZQ for ; Tue, 14 Nov 2017 18:44:29 -0800 (PST)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0DE1201F2 for ; Tue, 14 Nov 2017 18:44:29 -0800 (PST)
Received: by mail-pg0-x232.google.com with SMTP id 4so8020712pge.1 for ; Tue, 14 Nov 2017 18:44:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2uMp/SVLEIgJJ23IuF9846mboO36oJjS474QUHFxNkM=; b=TqHoLNiz3cUDjE7EAcejLhR8dw4y1mretVofYMyFKq16G2P7OfHSPohbJ+75y4dLdV It++g9KUQi/j9EMkj3sbrYFceEGjC4zzDQKgIZ1fG/Ic5Asxrb9yXVirNM1QO/NorJ7b 7yp97/0NhkjQXbZ7bPKmOuhVrEy3PizO/Wk4I15UzcGSPFWI1zcXHJiEWR9tEBu3phHH lr6BUZJqwKHmHsXJxm0GJ15/5yKscd0/hgd7MrWNcEjOkg9Yl04OrTnludBpkN5eJT+X R5tcevv9aWNZAuZ8rpOPmFm4debWaxRyZcZIy12OYhFuGPpn7U/mkbiEsVbL8HwZGrC2 eVyQ==
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=2uMp/SVLEIgJJ23IuF9846mboO36oJjS474QUHFxNkM=; b=ZgS9hcXG/KuCHGgV4i29DcGRANRKMsJePoeacanKpY2QpVjujxXJEAOhArj9MHaPeE MFp/sW6q6JjEVRSe3+90rUllF14bMUrRCVQfUCkxbz8TYpPzbK/Lh77z1Yg1JZdutNc0 uhUxT8vfh39SayduDSUzmmg9hqIAWF+zklTXXdIVjkliqEqfkg0ArOdfq7skH2QkwjJ1 GAhht9uVHclBaGU27LauH7xpXgqJE/c5HIN9aim6VNkoYv9Mut6P8vLlCqaleGmS/1a6 8HsnNeX5JfNlgaFgdUDQhzIp4s0MrrUTYyDjQ7KWo8r0Hzvvz5EVDwg9gGR493IlruVD Clng==
X-Gm-Message-State: AJaThX4oq4enUt6RJl6D4EG5LNADpxaX1YaN3Wn0TJQHB1byMO3IniBN YqFV7IISpmBWZjt0LoSe+ZQYjA==
X-Google-Smtp-Source: AGs4zMaQ1rEFa3k70a4H4u/UwuIqqaDZhBtFx1Ui6KWwZLmko9GV/ltARtLlEuxK+YMe2xvWlezpvQ==
X-Received: by 10.99.117.83 with SMTP id f19mr13760350pgn.255.1510713868293; Tue, 14 Nov 2017 18:44:28 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b9sm38100797pff.48.2017.11.14.18.44.26 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 18:44:27 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References: 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Wed, 15 Nov 2017 15:44:28 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 02:44:30 -0000

On 15/11/2017 15:13, Alexandre Petrescu wrote:
> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.

Also on the DNS64 network. But it is all one-way, you
will notice. No replies as far as I can see. Most of them
are sourced from 169.254.*.*, but there are some oddities such as
31.130.227.98	224.0.0.1	IGMPv2	42	Membership Query, general

I have a couple of Wireshark capture files if anyone cares.

   Brian


From nobody Tue Nov 14 18:57:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639631294A1 for ; Tue, 14 Nov 2017 18:57:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do0LnxHXlfNn for ; Tue, 14 Nov 2017 18:57:24 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 28C3812941D for ; Tue, 14 Nov 2017 18:57:24 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id x68so567065lff.0 for ; Tue, 14 Nov 2017 18:57:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cA3M6hMtHy6DeGFcULV52+/EbOHplokWXoc+iToe2fs=; b=tdzSPetf2rqcAeNVvn5ZWJDSl18I2ravLhQSm2sLSPC2vOuuUZ8JJV+QqlFT0jS8gu sxVMhs26SgFkx/RNlsh9FZ3pQQinedIox/Ald8nF9YkrWWtcrYc3bIGXUU335U8/98VA j8BdtVbdu1qITTN9uJ9R117sNJGjLioMb6CaiLI6cJxaxBI29OVp2P4ok9O7PJObe9FQ JdU7JsTfw0qOLUXAtNhUAmExL2mS1xdYZd2ydQG+7K3mwmWMsHfv7V2fhjzeiF4BrX9g pTY+7KS0t7SdGBKd2+gSrTsZ4YDBavs6kyHHzOHXWXCxb4Yamd42gTlQaSVHCP0g0R3S I3Ng==
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=cA3M6hMtHy6DeGFcULV52+/EbOHplokWXoc+iToe2fs=; b=CaCpSJqgNe57azmO1sWYncmj5hGosxc+VO+m5WLDSKnl3Bs7rEtHAc/EEGM0/mnsMo s+EPvRC29Zju+JP86khM97al9ib/l0I8zdXwZ924fKRwXNppdAZRlulGE5VWFaF5maqF PFxfxd2ROCDdMr2CHZnojKuPBghsG3JjtAXwhaWC2VKAIiFsFpHXv6W95gjIyaWNgXhF NbOP3G1gl7s59hk3VyAiqUFLOaZiJh7g/z1FpPmfi8aWHPGdhLdin7PM6i3tuL9TXS4V T8+uFHhfnu9NyyYqgZaPNHBYQZ8zd7BEtnYLqr/8fFHYNUa/PqWtA/D3oSwyyJ2KgEyU DC1w==
X-Gm-Message-State: AJaThX4yGMkfU0bEDLDSTG64xDvK33RZrZ262c7jdactSRlYPhViOACo 5Wc5Prkl++vxpqKP8hFR8rGtgp1P/CbKL1FGu+g=
X-Google-Smtp-Source: AGs4zMYPyq5mNNF4XPaWNWYCOol9whs6ZzDbeju3DXz5cViuoD41ZJg8QYhEdWHSVTwipr8Mxao0tI92uIilPAoO3H4=
X-Received: by 10.25.219.6 with SMTP id s6mr5303365lfg.229.1510714642327; Tue, 14 Nov 2017 18:57:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.205.2 with HTTP; Tue, 14 Nov 2017 18:57:01 -0800 (PST)
In-Reply-To: 
References: 
From: Jen Linkova 
Date: Wed, 15 Nov 2017 13:57:01 +1100
Message-ID: 
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Alexandre Petrescu 
Cc: IPv6 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 02:57:26 -0000

On Wed, Nov 15, 2017 at 1:13 PM, Alexandre Petrescu
 wrote:
> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.

Nothing prevents a host form configuring 'link-local' IPv4 address and
trying to reach other hosts over Ipv4 even if the network itself does
not provide IPv4 as a service.
However those v4 connectivity attempts will be unsuccessful indeed
(well, communication in the same broadcast domain might be OK as long
as L2 environment supports switching Ethernet frames with IPv4
inside).

>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
SY, Jen Linkova aka Furry


From nobody Tue Nov 14 18:59:20 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFCC129438 for ; Tue, 14 Nov 2017 18:59:18 -0800 (PST)
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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAyxxsucnKk3 for ; Tue, 14 Nov 2017 18:59:16 -0800 (PST)
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 A076B127137 for ; Tue, 14 Nov 2017 18:59:16 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob23.registeredsite.com (8.14.4/8.14.4) with ESMTP id vAF2xCQn128136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 14 Nov 2017 21:59:14 -0500
Received: (qmail 31339 invoked by uid 0); 15 Nov 2017 02:59:12 -0000
X-TCPREMOTEIP: 31.133.153.67
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?31.133.153.67?) (lee@asgard.org@31.133.153.67) by 0 with ESMTPA; 15 Nov 2017 02:59:11 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Wed, 15 Nov 2017 10:59:06 +0800
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
From: Lee Howard 
To: Brian E Carpenter , 
Message-ID: 
Thread-Topic: IPv4 traffic on "ietf-v6ONLY"
References:  
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 02:59:18 -0000

On 11/15/17, 10:44 AM, "ipv6 on behalf of Brian E Carpenter"
 wrote:

>On 15/11/2017 15:13, Alexandre Petrescu wrote:
>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
>
>Also on the DNS64 network. But it is all one-way, you
>will notice. No replies as far as I can see. Most of them
>are sourced from 169.254.*.*, but there are some oddities such as
>31.130.227.98	224.0.0.1	IGMPv2	42	Membership Query, general


Does that return us to the question of how to tell hosts that IPv4 doesn=E2=80=99=
t
live here, and to stop trying?

Lee

>
>I have a couple of Wireshark capture files if anyone cares.
>
>   Brian
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>



From nobody Tue Nov 14 19:05:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A81E126C22 for ; Tue, 14 Nov 2017 19:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w92YoAWJ_5_V for ; Tue, 14 Nov 2017 19:05:42 -0800 (PST)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 76B80126B72 for ; Tue, 14 Nov 2017 19:05:41 -0800 (PST)
Received: by mail-lf0-x22f.google.com with SMTP id x68so581333lff.0 for ; Tue, 14 Nov 2017 19:05:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qp8xSLcqMnHPEZbW2XD8HgMYeBtLPdfU2KL2wYvDVoY=; b=V+SE83bSAZ+9Pg7tqSzxK+cmKSWF5+mnS6WIDRVjfabimb6fR8cQAoxyIZwnpfEfDM UHmP7g1qjfKzi+5pJzBr7oxMC8RlGOcH5RW8FjbmWaTe7C2LPuo7n76zy8FSzm8kiIxr U3AZTsTKKDNSkknHQZEvAZ9mUO/rkU2YODbfHaTQKZDYLyydUiA4vTJ7qfeIgSd6D/Uy vz/IK0zpMwQCEuKQPXH5urwG2eOt9N/B6Wz3DmGtVmInkVK6yYxzCHErupMJt3vAVTBK LQJZZcnNDvfEMGbfY+bCD01TBM4esvsqIeBBLBOfDplb5bRWWab9EF1TZZonKHn/r4OD 6WOg==
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=qp8xSLcqMnHPEZbW2XD8HgMYeBtLPdfU2KL2wYvDVoY=; b=bN0XsnDOWabAjMm+kXwn9GAfNJ9SDKfUi+MzawXH8NNiI0/0gQ7oS1YQZK79jy6j9S 9LIlzhCyHnggjLlf7S2Ht5pDRBefWAcMbwQ4Ue2EhEBjLxO72xPk0r57kY67grmbJqxx 3kv1YEeQ9LFkk1pP7JhkJ0ovGv7XU0z35UHsIDX+XM/AmZ5Rjwk3a8Z1IBoMWL4dj2YW HVttNVuCqWdCXJ984Ur52AanqrDEQLO5IDkXC5a6O2dTv/J0XlQUi0vvM+bRRF7rDnRo 4xGfGO2Uezw0T3Fuybj7GD2nvmrlBhnYEo4a8luqC/j3lPidhB3pCyTNqw4Nbk8LakmB tWrg==
X-Gm-Message-State: AJaThX4jvpqxq4PrlglIxBU2ZgWxKAZay1ICO6VmzDfJlEGnLAECJyGC /Vs2MKFCVNw2GEYw3q03IeZk8jybdaQZHCnbbEA=
X-Google-Smtp-Source: AGs4zMbjj4SUzB+izlBykZiGUKmaI5TWVBpKZHXF5aqFQmIlxKuKFt4cKm0OnN0gd/t7OpvXfaKtdGm4P8xqFUm5oCU=
X-Received: by 10.25.59.77 with SMTP id i74mr4551283lfa.46.1510715139607; Tue, 14 Nov 2017 19:05:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.205.2 with HTTP; Tue, 14 Nov 2017 19:05:18 -0800 (PST)
In-Reply-To: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> 
From: Jen Linkova 
Date: Wed, 15 Nov 2017 14:05:18 +1100
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: Mark Andrews , 6man WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:05:44 -0000

On Wed, Nov 15, 2017 at 1:07 PM, Ole Troan  wrote:
> If I may try to suggest a solution based on what you are saying:
>
> - Remove (external) DNS64 from the solution
> - Replace NAT64 prefix discovery with some sort of local configuration. e=
.g. put it in DHCP or RA
>
> Which has the implications that:
>  - host learns NAT64 prefix via RA/DHCP
>  - host is free to use whatever DNS recursive resolvers (instead of the m=
ust be local (and on correct interface where the NAT64 is) resolver
>  - host synthesises addresses itself. And does validation before synthesi=
sing (if that's required).
>
> Is this the solution you would be looking for?
>
> And yes, you need host changes. But we need that anyway.

NAT64 is a band aid, a tactical solution to deal with IPv4-only hosst
while we are waiting for them to die. Requiring *mandatory* changes on
majority of devices which are working on NAT64 networks just fine
currently to solve problems for those who either a) sign their zones
but do not enable Ipv6 b)doing some smart things in their host
resolvers looks like an overkill to me..

IMHO the optimal solution is:
- the network SHOULD provide a host with NAT64 prefix information in
RA (I do not believe that information needs to be duplicated in DHCP
at all);
- an application MAY use that information to do AAAA synthetics
(validating resolvers SHOULD do that).
- network still provides DNS64 servers to hosts so all unsophisticated
hosts (majority of devices falls into that category) continue to use
network-provided resolvers.


>
>> On 15 Nov 2017, at 08:06, Mark Andrews  wrote:
>>
>>
>>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti  wrote:
>>>
>>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews  wrote:
>>> Is there any reason to run DNS64 at all these days?  ipv4only.arpa can =
be a preconfigured
>>> zone which allows CLAT to get its mapping.  All the phones have CLAT su=
pport.
>>>
>>> That's an interesting idea. It would work in theory, but such a network=
 would completely break devices that don't support 464xlat. That gives up o=
ne of the major advantages of NAT64/DNS64, which is that it's a 90% solutio=
n even just by itself - yes, IPv4-only applications and address literals ex=
ist, but most simple client/server applications Just Work behind it.
>>
>> And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.  It basi=
cally requires EVERY DNS VALIDATOR ON
>> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64 SERVE=
R.
>>
>> DNS64/NAT64 was presented as NOT REQUIRING node changes when first moote=
d.  It keeps on
>> requiring more and more highly invasive node changes to support.  It was=
 from the very beginning
>> bad engineering.   To get IPv4 as a service some node changes are requir=
ed.  Lets make sure they
>> are MINIMAL ones.
>>
>> Just for the record DNSSEC validators need to send BOTH CD=3D0 and CD=3D=
1 queries to get answers
>> though a upstream VALIDATING server which includes a VALIDATING DNS64 se=
rver as CD=3D0 and
>> CD=3D1 address different DNSSEC threats.  I tried very hard to point tha=
t out when RFC 6147 was
>> being written but the working group decide that CD indicated whether the=
 client was validating or
>> not.  There is NO SUCH INDICATION in a DNS message.
>>
>>  If a query arrives at a vDNS64 device with the "Checking Disabled"
>>   (CD) bit set, it is an indication that the querying agent wants all
>>   the validation data so it can do checking itself.  By local policy,
>>   vDNS64 could still validate, but it must return all data to the
>>   querying agent anyway.
>>
>> CD=3D0 queries causes the upstream validating servers to reject incoming=
 spoofed answers
>> or stale answers (this is a common operational problem).
>>
>> CD=3D1 queries allow the validation to succeed when the upstream validat=
or has a bad trust
>> anchor or a bad clock which is rejecting legitimate answers.
>>
>> A validating client can=E2=80=99t just send CD=3D1 queries as the upstre=
am validator doesn=E2=80=99t kick in.
>> The upstream validator can lock onto a stale answer source.  It needs to=
 send CD=3D0 queries
>> on validation failure to force the upstream validator to try multiple so=
urces.
>>
>> A validating client can=E2=80=99t just send CD=3D0.  It needs to send CD=
=3D1 on SERVFAIL in case the
>> upstream validator has a bad trust anchor (likely with the upcoming root=
 KSK roll) or has
>> a bad clock (these usually get fixed fast).
>>
>> Now to get a answer from a signed zone with servers with stale answers a=
 validatiing DNS64 client
>> needs to send:
>>
>> a) send CD=3D1 and validation failure send CD=3D0 then on AAAA validatio=
n failure send CD=3D1 and
>>    hope the TTL was not 0 and that is not cachable and there is no assur=
ance that you won=E2=80=99t get
>>    a answer from a stale source.
>>
>>       or
>>
>> b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 and hop=
e the TTL was not 0 as
>>    that is not cachable and there is no assurance that you won=E2=80=99t=
 get a answer from a stale source.
>>
>> TTL=3D0 answers exist.
>>
>> Note none of this is documented in a RFC.  You have to understand how bo=
th DNSSEC and DNS64 work to
>> realise this.
>>
>> IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix d=
iscover for DNS VALIDATORS.
>> Note =E2=80=9Cad=E2=80=9D is set in the flags.  Yes, I=E2=80=99ve submit=
ted a errata.  Yes, I=E2=80=99ve opened a ticket to get it fixed but
>> based on past experience that could take months if it happens at all.  Y=
ou will note that the recursive
>> server is running on the loopback interface so all DNS answers are being=
 validated here.
>>
>> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
>> ;; BADCOOKIE, retrying.
>>
>> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
>> ;; QUESTION SECTION:
>> ;IPV4ONLY.ARPA.                       IN      A
>>
>> ;; ANSWER SECTION:
>> ipv4only.arpa.                26574   IN      A       192.0.0.171
>> ipv4only.arpa.                26574   IN      A       192.0.0.170
>>
>> ;; Query time: 0 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
>> ;; MSG SIZE  rcvd: 115
>>
>> [rock:bind9/bin/named] marka%
>>
>>> It's not true that all phones have clat support. Notably, Apple not onl=
y does not support it but appears ideologically opposed to it on the ground=
s that it does not have a good exit strategy (because it makes it possible =
to run IPv4-only apps forever).
>>
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



--=20
SY, Jen Linkova aka Furry


From nobody Tue Nov 14 19:07:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B435126B72 for ; Tue, 14 Nov 2017 19:07:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so7mW5_LEDL6 for ; Tue, 14 Nov 2017 19:07:25 -0800 (PST)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C351252BA for ; Tue, 14 Nov 2017 19:07:25 -0800 (PST)
Received: by mail-pg0-x232.google.com with SMTP id o7so16951962pgc.4 for ; Tue, 14 Nov 2017 19:07:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OPzAHQEAwo1f1OKq7kEUcl3dfA74pfkAUI6VcK+4RgY=; b=qetyVGe5pkUg0yWKedB1dhOPP2xA51Z6ZrRJhal3+bjHvVf0CTPBiEO6is6y02u+PK Vvel3185+tXJdrVrXC9PF4zRtpI3u/lGuJqk0WVYJ6uiY5Kd7APAtKS+QNxc2OMGSU9W 6QuIyTPC3AUZfyPA9ZDYuHUopUaXcsXiKkhyin+8WfSASGrfEg9swB865xu1vxVPFEii hrudYs14jt3bExNilu46grWJhu9+YGrw7gUVeF98RHHqzhx+qlpsHRBoCrD90cR0ouFh UeE127w9AjPcRJXKpEkRitiq6Vb/VwuXygcXdRk3Eu+mZZFCVQYWxZMM0hvxheZgJLt1 IsEQ==
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=OPzAHQEAwo1f1OKq7kEUcl3dfA74pfkAUI6VcK+4RgY=; b=Dtmt7+KwS6vhvgPucN+N7cotxriwg9ZnWQIQfLlGfyodgEm32T+iCQEht6UsGJ0dSF XnwncBK4LD80E0SlyLkDg8croqI5TQN66uKxw5iFwKTqgkVIpAc/JdFuxPXdZ+GYnXpl r6FN6+zN2uX7hox709n5h1IVo0dEecMFNVCJ+ryHjFt6hJMnUn7OvoD2CzwhagIMfXCN DlK65NrljQP8TR6u6YrDQIRMHNKrDfyZ5VSZ3dvZM0MwEcHspTHLd8q4WcllKLSVXfNf /am6e2+zCgjjtAwLo06OeUQzsZdxDGDYPklI/OaTB+85ZLfj/2OVdRh6S7KDc4zLQsvQ qJKA==
X-Gm-Message-State: AJaThX5GtYjasC2lmttxALzwkxYvcaTmRt0+ySeABZfEy+V4Utskz3Mh O7o9mRrh/BzGzYpBToxAJWdMSQ==
X-Google-Smtp-Source: AGs4zMYkDiq+6wWyHY2OvADI9vcAOlIb24aaBdPRvoS2bDv4nS/4PxSTM8vyUbf6AMK0Vo8JYdZnGA==
X-Received: by 10.84.132.65 with SMTP id 59mr12549618ple.146.1510715244787; Tue, 14 Nov 2017 19:07:24 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b9sm38149605pff.48.2017.11.14.19.07.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 19:07:24 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Lee Howard , ipv6@ietf.org
References:   
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Wed, 15 Nov 2017 16:07:24 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:07:27 -0000

On 15/11/2017 15:59, Lee Howard wrote:
>=20
>=20
> On 11/15/17, 10:44 AM, "ipv6 on behalf of Brian E Carpenter"
>  wrote:=

>=20
>> On 15/11/2017 15:13, Alexandre Petrescu wrote:
>>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
>>
>> Also on the DNS64 network. But it is all one-way, you
>> will notice. No replies as far as I can see. Most of them
>> are sourced from 169.254.*.*, but there are some oddities such as
>> 31.130.227.98	224.0.0.1	IGMPv2	42	Membership Query, general
>=20
>=20
> Does that return us to the question of how to tell hosts that IPv4 does=
n=E2=80=99t
> live here, and to stop trying?

Maybe. But on the other hand there is no reason in principle
that peer2peer traffic between 169.254.*.* addresses won't work.
(There are reasons in practice, e.g. it doesn't work on Windows 7.)

   Brian

>=20
> Lee
>=20
>>
>> I have a couple of Wireshark capture files if anyone cares.
>>
>>   Brian
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>=20
>=20
>=20


From nobody Tue Nov 14 19:08:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C4D127137 for ; Tue, 14 Nov 2017 19:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD4m4Ajby4Q7 for ; Tue, 14 Nov 2017 19:08:27 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 4EE6B1201F2 for ; Tue, 14 Nov 2017 19:08:27 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id w23so945144lfd.11 for ; Tue, 14 Nov 2017 19:08:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PffdUFAh6vH6WaBFZx+Y4oF/no/cVCB7dTwm79uCvdk=; b=RuAYc0kIIt9NR7DikyRCz0LbhKzQVj3fHMi3shbx5QZusjQa66ymUfQ12/KTsC//1G fI07RkowhWBgcZcy6Cv7SDPGutd4yhNnzMottt1dfzHmE1ODkWfRx9YzD2vnC9mfwEuj I4+IyO35zNPBALGgw8GOuE06jSYySPWxym3LzVqt5K1Dy7FL5Y7x/KYmZXDWHsyic7YP 16kb6J2awBId6IT8gCfdf5iYmMyEW06Zk8IYvgtSKdRqTa1kE8qrjnWzxBeegAyQiihC P+RqOmIinIBV7WJuY9FIQsFSTxm2no9SFwgBr8rPpsWQOPdx/6/VnWvRH6Q6XhIEBgJO EPmw==
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=PffdUFAh6vH6WaBFZx+Y4oF/no/cVCB7dTwm79uCvdk=; b=Muvl0BJF1dWkgX19rPG4M1Sm1uHARxzDTdQel0dR6UTpSiXiiL7EPw+DBebl9fghkj gqVVpT9fuHAk6Xl6r2tfXP+tvu2DJOZI0TaSygM7po7vjdse9MLJ7dQaH9toMfljCPvS BUVh4MOLOeJenhkuOgRHCvokPtdr9yn8qC1b4igvd78rPfvKl9lS6LNnT40Un6Bsklaj bjXdMG6RfVYb2/Gl5VMkX3NQpAwiPVINkJKLjTZ35/PByS+HdqGUylS3UeRoFbSFxY3D OHsqoeZrCJjOP4YYjK1hBDErirDwV43x69F0WPrdl8nPGfBrubZwURSIxjD1ac21sFmB lEzQ==
X-Gm-Message-State: AJaThX44GFwcN0ZUA8UlEjhmP09TNhmz21fwmP5Br8NcZDAGAqOtEe5j sJ+RRUzeBT4LImVS0SHLQZapW19Uw4lxqo2fsWDUzw==
X-Google-Smtp-Source: AGs4zMaCNgbcYxXVQI74jvewxl2/xWmw18zEizwXhxv9Y68t1P+o1o1g3jTkUimEk7X//NB1YHv4bEkNHFVk0aTl52A=
X-Received: by 10.25.67.79 with SMTP id m15mr1404516lfj.216.1510715305547; Tue, 14 Nov 2017 19:08:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.205.2 with HTTP; Tue, 14 Nov 2017 19:08:04 -0800 (PST)
In-Reply-To: 
References:   
From: Jen Linkova 
Date: Wed, 15 Nov 2017 14:08:04 +1100
Message-ID: 
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Lee Howard 
Cc: Brian E Carpenter , 6man 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:08:29 -0000

On Wed, Nov 15, 2017 at 1:59 PM, Lee Howard  wrote:
>>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
>>
>>Also on the DNS64 network. But it is all one-way, you
>>will notice. No replies as far as I can see. Most of them
>>are sourced from 169.254.*.*, but there are some oddities such as
>>31.130.227.98  224.0.0.1       IGMPv2  42      Membership Query, general
>
>
> Does that return us to the question of how to tell hosts that IPv4 doesn=
=E2=80=99t
> live here, and to stop trying?

I do not believe we should be doing this. How do you tell the hosts
'Ipv6 does not live here, stop trying' and why would you
be doing this when I can just get hosts talk to each other on link
using IPv6 LLAs?
Or that...I don't know, DECNET, Appletalk or MPLS does not live here?


>
>>
>>I have a couple of Wireshark capture files if anyone cares.
>>
>>   Brian
>>
>>--------------------------------------------------------------------
>>IETF IPv6 working group mailing list
>>ipv6@ietf.org
>>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>--------------------------------------------------------------------
>>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



--=20
SY, Jen Linkova aka Furry


From nobody Tue Nov 14 19:09:26 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC551129496 for ; Tue, 14 Nov 2017 19:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 heUMkCoEfqN0 for ; Tue, 14 Nov 2017 19:09:24 -0800 (PST)
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 D5C96128959 for ; Tue, 14 Nov 2017 19:09:24 -0800 (PST)
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 9D94B3ACCF1; Wed, 15 Nov 2017 03:08:24 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6969C160067; Wed, 15 Nov 2017 03:08:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 576FC16007A; Wed, 15 Nov 2017 03:08:23 +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 vqul8q594j81; Wed, 15 Nov 2017 03:08:23 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 89F8B160067; Wed, 15 Nov 2017 03:08:22 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
From: Mark Andrews 
In-Reply-To: 
Date: Wed, 15 Nov 2017 14:08:20 +1100
Cc: Brian E Carpenter , ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   
To: Lee Howard 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:09:26 -0000

> On 15 Nov 2017, at 1:59 pm, Lee Howard  wrote:
>=20
> On 11/15/17, 10:44 AM, "ipv6 on behalf of Brian E Carpenter"
>  =
wrote:
>=20
>> On 15/11/2017 15:13, Alexandre Petrescu wrote:
>>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
>>=20
>> Also on the DNS64 network. But it is all one-way, you
>> will notice. No replies as far as I can see. Most of them
>> are sourced from 169.254.*.*, but there are some oddities such as
>> 31.130.227.98	224.0.0.1	IGMPv2	42	Membership =
Query, general
>=20
>=20
> Does that return us to the question of how to tell hosts that IPv4 =
doesn=E2=80=99t
> live here, and to stop trying?
>=20
> Lee

I don=E2=80=99t think so.  Enterprises that want to get rid of local =
IPv4 traffic can filter it.
In the home it really doesn=E2=80=99t matter if there is still local =
IPv4 the same way as
on most hotel nets there is a lot of IPv6 local traffic but no external =
IPv6 traffic.

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


From nobody Tue Nov 14 19:11:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA7D12711E for ; Tue, 14 Nov 2017 19:11:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNMADa9NH-Gg for ; Tue, 14 Nov 2017 19:11:31 -0800 (PST)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 8B568126B72 for ; Tue, 14 Nov 2017 19:11:31 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id u42so8449341qte.7 for ; Tue, 14 Nov 2017 19:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oKrMpYRA3TGsiRXR6XyKWILta0vXrO4IGuzsFPl8leI=; b=d1s4KXVifEVCMv7EZBVUW8vUD0jsMD0lVAm34m7eiokif/25SR3hFJdTA5CtRk98WU 0wA3h2kp5yWxO5cadRuKOFd7hLjT3/53JXLVZ02js7MSSfQzQV3K3kKhBZWQrIqPy3NT VSUuYEzwMKnkmJZP5qn//Uir2lFtbHyHtNVwSbZYXCY6d7t9HWEb8QkYycR4Sfu3m+40 dUZN00nl9O6DsfmHS7NbWecAiG2zRkIHmryj3cTcgvBCxUsaPZfeTidsC5OTGBJD133i 3IU0LfkpAv2/ReeOWDuD5OaT/6k9SNnm0NHNSePq+2kEOb77H+RX/8g+mwUJIizTAeY3 +yng==
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=oKrMpYRA3TGsiRXR6XyKWILta0vXrO4IGuzsFPl8leI=; b=ZskHdtdN35ArXgJCwO1yre8fYFk7pf3ElfoHAxSqwjtUUUsdTV3Jb9Zmz2jkRw/Y/Y eP/1ZZN7bkuxoTWvII3K6S3YYnuHQKFmdwGkmrfhxhu8T9086RFovhw/cMoakej/Bcjd K8nB30CR9KLEH+SWkgbjIXFitYXTuTOmyYk1knSem1E5pA0zTGaGLTJuDaZU8n0Fcnib Bxbog6TdsOAsbUgWlfX99Fdl7QWdkKBsX8rt8lw4Z/w/gIiauh79pCyHpvyCcqmdH3Zk TMW11M2NVnc7xQPeewdkQWBbwlA5IA6EgUZk17W2cxtIrT3pY7NGkyyieCWpkVTCSNxQ 3qTA==
X-Gm-Message-State: AJaThX5GkmI9+tP9xXprhiqVCyfOiM1fMJzdJzjWDGqshCAZYZtWXpF4 1Bpa3YeH+/IbGyogttsHUBU=
X-Google-Smtp-Source: AGs4zMb0/UrtpzqS/vedksKaukWttaO/+TmcBc1KUYurFw3fSTUDf1rlvyaXVQ6uKoBBdG5ya65EhA==
X-Received: by 10.55.77.67 with SMTP id a64mr21228277qkb.172.1510715490633; Tue, 14 Nov 2017 19:11:30 -0800 (PST)
Received: from ?IPv6:2601:18f:801:600:9d80:2e76:d937:64c? ([2601:18f:801:600:9d80:2e76:d937:64c]) by smtp.gmail.com with ESMTPSA id b65sm14681560qkb.45.2017.11.14.19.11.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 19:11:30 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
From: Ralph Droms 
In-Reply-To: 
Date: Tue, 14 Nov 2017 22:11:28 -0500
Cc: Lee Howard , ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C1A44D3-A53B-4E2A-9FF1-79A715518E9A@gmail.com>
References:    
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:11:33 -0000

> On Nov 14, 2017, at 10:07 PM, Brian E Carpenter =
 wrote:
>=20
> On 15/11/2017 15:59, Lee Howard wrote:
>>=20
>>=20
>> On 11/15/17, 10:44 AM, "ipv6 on behalf of Brian E Carpenter"
>>  =
wrote:
>>=20
>>> On 15/11/2017 15:13, Alexandre Petrescu wrote:
>>>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
>>>=20
>>> Also on the DNS64 network. But it is all one-way, you
>>> will notice. No replies as far as I can see. Most of them
>>> are sourced from 169.254.*.*, but there are some oddities such as
>>> 31.130.227.98	224.0.0.1	IGMPv2	42	Membership =
Query, general
>>=20
>>=20
>> Does that return us to the question of how to tell hosts that IPv4 =
doesn=E2=80=99t
>> live here, and to stop trying?
>=20
> Maybe. But on the other hand there is no reason in principle
> that peer2peer traffic between 169.254.*.* addresses won't work.
> (There are reasons in practice, e.g. it doesn't work on Windows 7.)

Can you get any sense of how much of the IPv4 traffic is useless?  Would =
it be useful to try to quench that useless traffic to improve network =
performance, behavior, operations? =20

- Ralph

>=20
>   Brian
>=20
>>=20
>> Lee
>>=20
>>>=20
>>> I have a couple of Wireshark capture files if anyone cares.
>>>=20
>>>  Brian
>>>=20
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>=20
>>=20
>>=20
>>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Tue Nov 14 19:11:58 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F92126C22 for ; Tue, 14 Nov 2017 19:11:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7skWEwo34Rj for ; Tue, 14 Nov 2017 19:11:55 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6F01292D3 for ; Tue, 14 Nov 2017 19:11:54 -0800 (PST)
Received: from mb.local ([IPv6:2001:67c:370:1998:78fa:30c8:8d1d:2a52]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id vAF3BlJ7039629 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 15 Nov 2017 03:11:49 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2001:67c:370:1998:78fa:30c8:8d1d:2a52] claimed to be mb.local
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Lee Howard , Brian E Carpenter , ipv6@ietf.org
References:   
From: joel jaeggli 
Message-ID: <81557db0-2335-f2f8-530c-4648ca5c85fd@bogus.com>
Date: Wed, 15 Nov 2017 11:11:01 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:56.0) Gecko/20100101 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:11:57 -0000

On 11/15/17 10:59, Lee Howard wrote:
> 
> 
> On 11/15/17, 10:44 AM, "ipv6 on behalf of Brian E Carpenter"
>  wrote:
> 
>> On 15/11/2017 15:13, Alexandre Petrescu wrote:
>>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
>>
>> Also on the DNS64 network. But it is all one-way, you
>> will notice. No replies as far as I can see. Most of them
>> are sourced from 169.254.*.*, but there are some oddities such as
>> 31.130.227.98	224.0.0.1	IGMPv2	42	Membership Query, general
> 
> 
> Does that return us to the question of how to tell hosts that IPv4 doesn’t
> live here, and to stop trying?

Ah but it does, because in the absence of ipv4 network instruction you
still build an adhoc network, just as you do for ipv6.

J@mb:nobackup$dns-sd  -G v4 "mb.local"
DATE: ---Wed 15 Nov 2017---
11:04:02.802  ...STARTING...
Timestamp     A/R Flags if Hostname
Address                                      TTL
11:04:02.804  Add     2  5 mb.local.
169.254.36.108                               120

J@mb:nobackup$dns-sd  -G v4 "Zamboni.local"
DATE: ---Wed 15 Nov 2017---
11:06:42.643  ...STARTING...
Timestamp     A/R Flags if Hostname
Address                                      TTL
11:06:42.644  Add     2  5 zamboni.local.
169.254.150.104                              120

if you turn off your ipv4 stack you'll no longer do that.

There is some (possibly misguided) assumption that if you have only
adhoc networking available for a given address faily that your network
is broken. In fact it is not, it is working.


joel

> Lee
> 
>>
>> I have a couple of Wireshark capture files if anyone cares.
>>
>>   Brian
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Tue Nov 14 19:31:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A00F126CBF for ; Tue, 14 Nov 2017 19:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsiYqt5JeD5j for ; Tue, 14 Nov 2017 19:31:33 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A06126B72 for ; Tue, 14 Nov 2017 19:31:33 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id 17so16004922pfn.12 for ; Tue, 14 Nov 2017 19:31:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xXmshC4RxzhzC7PhFXMDcBwhrIoF2LSyVN3LNvvs4hQ=; b=IFyGKxnM2nElN/W9K2v3is2CSys4Zg2/sqndK8cOlEJa8NQmFgQDFak8krithmtDra 03keuqFclGRmmxuwIdcfWa3L2Xd1qaWCq6j7qxxBcur0C+bs3buJCRT33VdPED9cNGv0 aFMj/v40iy69fVSt56Gql1RymcgsXDaxnjzr36+atbrZnhFQ6MCBhgN8fZuA0VBzJoK8 vZvuC9mOttpG/b+wkkyvzX4PHoaPHW8K0Ng14I1ZQxbAk3DG3U/vKDjxOrwiQYw0hmR/ QFN8norCo+HkKKIkPmKnxQQDGJjipDU4p+OqS72vp0vymI3KyXEZ2R4yw0Wgu148x+Vp 0wYA==
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=xXmshC4RxzhzC7PhFXMDcBwhrIoF2LSyVN3LNvvs4hQ=; b=TEYlXvqvictuA0Gm8eQwkxQMz7sMYoLxrzgWVV8k668ksA4/uNDw5/f5xSJeIZPQzP pJHs4oyVbDw5FkZez0rxG48np1QkCRH881rPEI0fn304xA2ENL6T4l+sDMScr5Iyy/Xh iYtxHljtRW6zYKUqJrX+o+m5f/71TliOfdBbblM/nWrmctbHCT4DueKhkEaGI+JxrvMu nOP+Wj3KhEqtKIceCqqemrPXH3q0MqXi0GMWTLLPajbPH1DBXzbVUjRZhGwCsR2YyZ/t RGyUDV5gapJdmUQDKSzIl1R5N7t6Cpq63EOxqh4CvN461jy75A0THloXG/HWre7blhMY buOw==
X-Gm-Message-State: AJaThX5xG2wfDYn34Cz7M5cXw8H1djxL77P1fvsP6z31IxDHGLG81kvT Vq0ZB4EYZJvDoYmQOmE1jrKerg==
X-Google-Smtp-Source: AGs4zMaIThhqclskWBjv9H44o85YdAI7wwzsL+niNCJ9EiLrDJ2KLrN3vmHjjVHSmSH0w+YYTGZPpw==
X-Received: by 10.84.224.75 with SMTP id a11mr12243389plt.421.1510716692690; Tue, 14 Nov 2017 19:31:32 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c73sm45910195pfd.139.2017.11.14.19.31.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 19:31:31 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Ralph Droms 
Cc: Lee Howard , ipv6@ietf.org
References:     <2C1A44D3-A53B-4E2A-9FF1-79A715518E9A@gmail.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <2a97bed4-c224-5728-bb78-978279c41e66@gmail.com>
Date: Wed, 15 Nov 2017 16:31:32 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <2C1A44D3-A53B-4E2A-9FF1-79A715518E9A@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:31:35 -0000

On 15/11/2017 16:11, Ralph Droms wrote:
>=20
>=20
>> On Nov 14, 2017, at 10:07 PM, Brian E Carpenter  wrote:
>>
>> On 15/11/2017 15:59, Lee Howard wrote:
>>>
>>>
>>> On 11/15/17, 10:44 AM, "ipv6 on behalf of Brian E Carpenter"
>>>  wrot=
e:
>>>
>>>> On 15/11/2017 15:13, Alexandre Petrescu wrote:
>>>>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
>>>>
>>>> Also on the DNS64 network. But it is all one-way, you
>>>> will notice. No replies as far as I can see. Most of them
>>>> are sourced from 169.254.*.*, but there are some oddities such as
>>>> 31.130.227.98	224.0.0.1	IGMPv2	42	Membership Query, general
>>>
>>>
>>> Does that return us to the question of how to tell hosts that IPv4 do=
esn=E2=80=99t
>>> live here, and to stop trying?
>>
>> Maybe. But on the other hand there is no reason in principle
>> that peer2peer traffic between 169.254.*.* addresses won't work.
>> (There are reasons in practice, e.g. it doesn't work on Windows 7.)
>=20
> Can you get any sense of how much of the IPv4 traffic is useless?  Woul=
d it be useful to try to quench that useless traffic to improve network p=
erformance, behavior, operations? =20
>=20

At the moment I think it's 100% useless traffic - in the two captures,
I see messages from many 169.254.*.* addresses and, I think, none that
are sent to such an address (except 169.254.255.255). Haven't quite
figured out the Wireshark display filter to be 100% certain

    Brian


From nobody Tue Nov 14 20:15:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A8A1293E4 for ; Tue, 14 Nov 2017 20:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 e_Q2rL9nzQhN for ; Tue, 14 Nov 2017 20:15:11 -0800 (PST)
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 6DE7112949F for ; Tue, 14 Nov 2017 20:15:11 -0800 (PST)
Received: by mail-yw0-x232.google.com with SMTP id d2so10933267ywb.11 for ; Tue, 14 Nov 2017 20:15:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qdGRDL41HUtxhrBd73vzo/E89Kyf3ePw1gpgJpQSims=; b=XUYfGAaMDutbor2kIVBxlRVl7kXnGxr/73PNXJwN43i4vi3Zd6k1usBFc3QUEMz17L jLsJPtiIXwDlyPMdwMDPzB5CsPcRMZdgaT9U+9LRyTZ8//9mME0VoYi4SREpzzy+Um38 AZs3ykAy6FOaqAN2c/sUQ2825Z9yVUPyr9CQ7kH+4mwKZCKCIFiIzz+fYZSbK6oTNr9o jB3FzfFKC8D0VTIMWxXDNx9844QZ7RPvPNh+nPNH7db13asXR5mjvhB62pNw9mknwivO QYI/7F1xfsdMCdS4e9tEicqujIG6tqHXbgRBB3vJfRs+ugxLz16ZLJef2onzN1R8oy+Z ARxA==
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=qdGRDL41HUtxhrBd73vzo/E89Kyf3ePw1gpgJpQSims=; b=SUbN62Lpcts0AhtmY9shdcSvSDxk6WPNir5bI6uLve7QXiJlN6vY99HW77sTFsb7kY QXmA+xtg5UY9nccDhmNFiFxjJ2h1o2LAJKiz3fT5xhFfjO/VVVmsZpFADO/RXVvRMno1 BW5z++QoN5Eo3ZTf0+utgq6C1gYdsoJRwjr9kedmDm39SLz2ZyNGp1zLwfvJsbVh+H7v t0/LqGqE9KuXiK2pPnZUIGlu2aWqKku5q8lB3LPTBk4MYF5TPeoafwwNcsJXF8UqB/lJ 66a2iR9AmNbcRFTBUjiQyx5n5Z5tzSDbRbmSu56oxFjqZWOF+h3Sj/rJ7aROWMeRGtAi 5Bew==
X-Gm-Message-State: AJaThX5WUcDv+s5kYRRVE9FHqRkWhVlabhWYKdvQAoDS6Cqx4WSTFKmY S8n5ocKuPLkCghHvBNzRNuyzFY9wNRPXDKVPJAe2BA==
X-Google-Smtp-Source: AGs4zMb94v4W0EsDNMmM3EWByUPtFyg3F1K75GGtF0c6uk/DgS4FxBMQpaTbICWHFRERA7AkfrtL8Chk1ncaQAXeRQA=
X-Received: by 10.129.155.23 with SMTP id s23mr9403686ywg.77.1510719310124; Tue, 14 Nov 2017 20:15:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.5.146 with HTTP; Tue, 14 Nov 2017 20:14:49 -0800 (PST)
In-Reply-To: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>  
From: Erik Kline 
Date: Wed, 15 Nov 2017 04:14:49 +0000
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Jen Linkova 
Cc: Ole Troan , 6man WG , Mark Andrews 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0b9166e0f413055dfdbff8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 04:15:14 -0000

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

Actually, I think the think we should is add the following to the PvD info:

    [1] NAT64 prefix
    [2] set of separate DNS64 servers, for clients who don't yet do
client-side DNS64 synthesis.

Unfortunately, it's too early to create a SHOULD/MUST that IPv6 hosts
support PvDs, but I think we'll just need to revisit that in the
future.

On 15 November 2017 at 03:05, Jen Linkova  wrote:
> On Wed, Nov 15, 2017 at 1:07 PM, Ole Troan  wrote:
>> If I may try to suggest a solution based on what you are saying:
>>
>> - Remove (external) DNS64 from the solution
>> - Replace NAT64 prefix discovery with some sort of local configuration. =
e.g. put it in DHCP or RA
>>
>> Which has the implications that:
>>  - host learns NAT64 prefix via RA/DHCP
>>  - host is free to use whatever DNS recursive resolvers (instead of the =
must be local (and on correct interface where the NAT64 is) resolver
>>  - host synthesises addresses itself. And does validation before synthes=
ising (if that's required).
>>
>> Is this the solution you would be looking for?
>>
>> And yes, you need host changes. But we need that anyway.
>
> NAT64 is a band aid, a tactical solution to deal with IPv4-only hosst
> while we are waiting for them to die. Requiring *mandatory* changes on
> majority of devices which are working on NAT64 networks just fine
> currently to solve problems for those who either a) sign their zones
> but do not enable Ipv6 b)doing some smart things in their host
> resolvers looks like an overkill to me..
>
> IMHO the optimal solution is:
> - the network SHOULD provide a host with NAT64 prefix information in
> RA (I do not believe that information needs to be duplicated in DHCP
> at all);
> - an application MAY use that information to do AAAA synthetics
> (validating resolvers SHOULD do that).
> - network still provides DNS64 servers to hosts so all unsophisticated
> hosts (majority of devices falls into that category) continue to use
> network-provided resolvers.
>
>
>>
>>> On 15 Nov 2017, at 08:06, Mark Andrews  wrote:
>>>
>>>
>>>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti  wrote=
:
>>>>
>>>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews  wrote:
>>>> Is there any reason to run DNS64 at all these days?  ipv4only.arpa can=
 be a preconfigured
>>>> zone which allows CLAT to get its mapping.  All the phones have CLAT s=
upport.
>>>>
>>>> That's an interesting idea. It would work in theory, but such a networ=
k would completely break devices that don't support 464xlat. That gives up =
one of the major advantages of NAT64/DNS64, which is that it's a 90% soluti=
on even just by itself - yes, IPv4-only applications and address literals e=
xist, but most simple client/server applications Just Work behind it.
>>>
>>> And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.  It bas=
ically requires EVERY DNS VALIDATOR ON
>>> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64 SERV=
ER.
>>>
>>> DNS64/NAT64 was presented as NOT REQUIRING node changes when first moot=
ed.  It keeps on
>>> requiring more and more highly invasive node changes to support.  It wa=
s from the very beginning
>>> bad engineering.   To get IPv4 as a service some node changes are requi=
red.  Lets make sure they
>>> are MINIMAL ones.
>>>
>>> Just for the record DNSSEC validators need to send BOTH CD=3D0 and CD=
=3D1 queries to get answers
>>> though a upstream VALIDATING server which includes a VALIDATING DNS64 s=
erver as CD=3D0 and
>>> CD=3D1 address different DNSSEC threats.  I tried very hard to point th=
at out when RFC 6147 was
>>> being written but the working group decide that CD indicated whether th=
e client was validating or
>>> not.  There is NO SUCH INDICATION in a DNS message.
>>>
>>>  If a query arrives at a vDNS64 device with the "Checking Disabled"
>>>   (CD) bit set, it is an indication that the querying agent wants all
>>>   the validation data so it can do checking itself.  By local policy,
>>>   vDNS64 could still validate, but it must return all data to the
>>>   querying agent anyway.
>>>
>>> CD=3D0 queries causes the upstream validating servers to reject incomin=
g spoofed answers
>>> or stale answers (this is a common operational problem).
>>>
>>> CD=3D1 queries allow the validation to succeed when the upstream valida=
tor has a bad trust
>>> anchor or a bad clock which is rejecting legitimate answers.
>>>
>>> A validating client can=E2=80=99t just send CD=3D1 queries as the upstr=
eam validator doesn=E2=80=99t kick in.
>>> The upstream validator can lock onto a stale answer source.  It needs t=
o send CD=3D0 queries
>>> on validation failure to force the upstream validator to try multiple s=
ources.
>>>
>>> A validating client can=E2=80=99t just send CD=3D0.  It needs to send C=
D=3D1 on SERVFAIL in case the
>>> upstream validator has a bad trust anchor (likely with the upcoming roo=
t KSK roll) or has
>>> a bad clock (these usually get fixed fast).
>>>
>>> Now to get a answer from a signed zone with servers with stale answers =
a validatiing DNS64 client
>>> needs to send:
>>>
>>> a) send CD=3D1 and validation failure send CD=3D0 then on AAAA validati=
on failure send CD=3D1 and
>>>    hope the TTL was not 0 and that is not cachable and there is no assu=
rance that you won=E2=80=99t get
>>>    a answer from a stale source.
>>>
>>>       or
>>>
>>> b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 and ho=
pe the TTL was not 0 as
>>>    that is not cachable and there is no assurance that you won=E2=80=99=
t get a answer from a stale source.
>>>
>>> TTL=3D0 answers exist.
>>>
>>> Note none of this is documented in a RFC.  You have to understand how b=
oth DNSSEC and DNS64 work to
>>> realise this.
>>>
>>> IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix =
discover for DNS VALIDATORS.
>>> Note =E2=80=9Cad=E2=80=9D is set in the flags.  Yes, I=E2=80=99ve submi=
tted a errata.  Yes, I=E2=80=99ve opened a ticket to get it fixed but
>>> based on past experience that could take months if it happens at all.  =
You will note that the recursive
>>> server is running on the loopback interface so all DNS answers are bein=
g validated here.
>>>
>>> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
>>> ;; BADCOOKIE, retrying.
>>>
>>> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
>>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
>>> ;; QUESTION SECTION:
>>> ;IPV4ONLY.ARPA.                       IN      A
>>>
>>> ;; ANSWER SECTION:
>>> ipv4only.arpa.                26574   IN      A       192.0.0.171
>>> ipv4only.arpa.                26574   IN      A       192.0.0.170
>>>
>>> ;; Query time: 0 msec
>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
>>> ;; MSG SIZE  rcvd: 115
>>>
>>> [rock:bind9/bin/named] marka%
>>>
>>>> It's not true that all phones have clat support. Notably, Apple not on=
ly does not support it but appears ideologically opposed to it on the groun=
ds that it does not have a good exit strategy (because it makes it possible=
 to run IPv4-only apps forever).
>>>
>>>
>>> --
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
>
>
> --
> SY, Jen Linkova aka Furry
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--94eb2c0b9166e0f413055dfdbff8
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgBODe+nKD/bC4VNncW3qTwjtBq9xbRHg3
COYEELqFgJ4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTE1
MDQxNTEwWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBADo0Bk2DrNaM82HOcdkPDCG8rWZSFfQTBx1yAPjWtMbuMuIWJSNB
eBJLgy/ZPOoOE8fB/WJG9VwuHQUsxR176cZCu2ai830r11zdEnxFfTe/L4yIs/f8GV6Sg5+hni4B
HIPik+K/8HinC3PPlp51lRV4QgtLvoMz3IX3NMJtH9e1DQtNMgKgSbzK3/5Hf+DW1swqXMK2QJaC
RGnZQiKez78+gz72U32Vkh5l17ORNz5JWiTef+qb4mxPc0hvYyuBZRyZAhOs87vToNKiMU1e4fC+
hdxm1AkbqDRUUpval1z5iPyYRSU19DzYQxKaKNuF1jsGu3CT4Qrn1NDOez6vMTo=
--94eb2c0b9166e0f413055dfdbff8--


From nobody Tue Nov 14 20:24:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4A71294C9 for ; Tue, 14 Nov 2017 20:24:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuIZm59VCwbb for ; Tue, 14 Nov 2017 20:24:40 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F21B1201F2 for ; Tue, 14 Nov 2017 20:24:39 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id s16so24483727lfs.1 for ; Tue, 14 Nov 2017 20:24:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TFfkoCZEfsR9dL44xDVk7QrRujw5GNkVZO0j68EGeZI=; b=MaUMETTDyVwP1MH8RmnyQxO5t0ZV9xe1JKnm0zEFSQPiPeNHtaNlAENnipXZ0K03Y1 hBVTqZdmClb7o2qKObeZoYmXtxLmE5er1Pxcq1gH/AQnEPsQcIJos8xG6qRl+ygQuG0S TCtWB1LWR5JMnpH2d2S2TKnUIIuUDZiAVwv/3utPHga018KrSwE20dkP9X98ED5y5xr8 11LKrhmXFGbtnubBGjfYtFnDHGsZQWytEsTeHZycO3r2rsONgq69NFKourfdwRDCpjnO Cpwf651A/EvbZOzmFR9S8HQFIxGXJSN8N0KKm9ppN5bprE6qXLX+MF+b1i8MRoJXJSGN fRVw==
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=TFfkoCZEfsR9dL44xDVk7QrRujw5GNkVZO0j68EGeZI=; b=Lf6xQ7TkmJL0g1sjZkTcaRig21GSfbQi1P1DmssM8opkvwBsjBmcF8er7sEjel+L/o LKiCf1QAsYbkB/ZpvA9MSzTRT37iSJFeCyQgbjbjKGwGFAwlBFR5Si5oT+GQRq6ViAf1 2BjFOjKaFFKcjbZ3AmdrC9/9+nhZE7O7g0E+O+gpSAE7YdHqoJpeqkpt4lj4lztDiC3z u4RIVMYv6hRST9aICdKBDW85s5PYFimrpJRUS0AEEDAyWh+qiB6Mocv0h6cgMyWcpXi7 h08VyS1LiJhmtNfbGhcXVE8Biz96FNwBm5vvSMGLSG6pvP1Qoo9bIdBXrxGSHihFKS9l sgWA==
X-Gm-Message-State: AJaThX6s9sSMKoDowJDoGrhDsqXenwZs5XnBD37WMXWy0WVGTPi4QKbQ MCynRLYEoZ8cW5dUIcQ2Zt27N6UMEDA583kKH3Y=
X-Google-Smtp-Source: AGs4zMaH7DINomyVjbDD6/Xjr691rA7e+gazDaT8D9CgzxmvhpqNkHhiiIKJ+r0ySZ0MyYjF8us1pGNqotvYVHHa+8s=
X-Received: by 10.25.87.12 with SMTP id l12mr4982038lfb.111.1510719877528; Tue, 14 Nov 2017 20:24:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.205.2 with HTTP; Tue, 14 Nov 2017 20:24:16 -0800 (PST)
In-Reply-To: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   
From: Jen Linkova 
Date: Wed, 15 Nov 2017 15:24:16 +1100
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Erik Kline 
Cc: Ole Troan , 6man WG , Mark Andrews 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 04:24:43 -0000

On Wed, Nov 15, 2017 at 3:14 PM, Erik Kline  wrote:
> Actually, I think the think we should is add the following to the PvD inf=
o:
>
>     [1] NAT64 prefix
>     [2] set of separate DNS64 servers, for clients who don't yet do
> client-side DNS64 synthesis.

I love that idea.
Even better than RA/DHCP ;)

> Unfortunately, it's too early to create a SHOULD/MUST that IPv6 hosts
> support PvDs, but I think we'll just need to revisit that in the
> future.

Well, we are talking about hosts/applications which do not  exist anyway.
So basically if an application wants to know about NAT64 prefix and
the presence of DNS64,
we need to define a mechanism to provide that information. PvD sounds
like a right place to do it.

>
> On 15 November 2017 at 03:05, Jen Linkova  wrote:
>> On Wed, Nov 15, 2017 at 1:07 PM, Ole Troan  wrote:
>>> If I may try to suggest a solution based on what you are saying:
>>>
>>> - Remove (external) DNS64 from the solution
>>> - Replace NAT64 prefix discovery with some sort of local configuration.=
 e.g. put it in DHCP or RA
>>>
>>> Which has the implications that:
>>>  - host learns NAT64 prefix via RA/DHCP
>>>  - host is free to use whatever DNS recursive resolvers (instead of the=
 must be local (and on correct interface where the NAT64 is) resolver
>>>  - host synthesises addresses itself. And does validation before synthe=
sising (if that's required).
>>>
>>> Is this the solution you would be looking for?
>>>
>>> And yes, you need host changes. But we need that anyway.
>>
>> NAT64 is a band aid, a tactical solution to deal with IPv4-only hosst
>> while we are waiting for them to die. Requiring *mandatory* changes on
>> majority of devices which are working on NAT64 networks just fine
>> currently to solve problems for those who either a) sign their zones
>> but do not enable Ipv6 b)doing some smart things in their host
>> resolvers looks like an overkill to me..
>>
>> IMHO the optimal solution is:
>> - the network SHOULD provide a host with NAT64 prefix information in
>> RA (I do not believe that information needs to be duplicated in DHCP
>> at all);
>> - an application MAY use that information to do AAAA synthetics
>> (validating resolvers SHOULD do that).
>> - network still provides DNS64 servers to hosts so all unsophisticated
>> hosts (majority of devices falls into that category) continue to use
>> network-provided resolvers.
>>
>>
>>>
>>>> On 15 Nov 2017, at 08:06, Mark Andrews  wrote:
>>>>
>>>>
>>>>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti  wrot=
e:
>>>>>
>>>>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews  wrote:
>>>>> Is there any reason to run DNS64 at all these days?  ipv4only.arpa ca=
n be a preconfigured
>>>>> zone which allows CLAT to get its mapping.  All the phones have CLAT =
support.
>>>>>
>>>>> That's an interesting idea. It would work in theory, but such a netwo=
rk would completely break devices that don't support 464xlat. That gives up=
 one of the major advantages of NAT64/DNS64, which is that it's a 90% solut=
ion even just by itself - yes, IPv4-only applications and address literals =
exist, but most simple client/server applications Just Work behind it.
>>>>
>>>> And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.  It ba=
sically requires EVERY DNS VALIDATOR ON
>>>> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64 SER=
VER.
>>>>
>>>> DNS64/NAT64 was presented as NOT REQUIRING node changes when first moo=
ted.  It keeps on
>>>> requiring more and more highly invasive node changes to support.  It w=
as from the very beginning
>>>> bad engineering.   To get IPv4 as a service some node changes are requ=
ired.  Lets make sure they
>>>> are MINIMAL ones.
>>>>
>>>> Just for the record DNSSEC validators need to send BOTH CD=3D0 and CD=
=3D1 queries to get answers
>>>> though a upstream VALIDATING server which includes a VALIDATING DNS64 =
server as CD=3D0 and
>>>> CD=3D1 address different DNSSEC threats.  I tried very hard to point t=
hat out when RFC 6147 was
>>>> being written but the working group decide that CD indicated whether t=
he client was validating or
>>>> not.  There is NO SUCH INDICATION in a DNS message.
>>>>
>>>>  If a query arrives at a vDNS64 device with the "Checking Disabled"
>>>>   (CD) bit set, it is an indication that the querying agent wants all
>>>>   the validation data so it can do checking itself.  By local policy,
>>>>   vDNS64 could still validate, but it must return all data to the
>>>>   querying agent anyway.
>>>>
>>>> CD=3D0 queries causes the upstream validating servers to reject incomi=
ng spoofed answers
>>>> or stale answers (this is a common operational problem).
>>>>
>>>> CD=3D1 queries allow the validation to succeed when the upstream valid=
ator has a bad trust
>>>> anchor or a bad clock which is rejecting legitimate answers.
>>>>
>>>> A validating client can=E2=80=99t just send CD=3D1 queries as the upst=
ream validator doesn=E2=80=99t kick in.
>>>> The upstream validator can lock onto a stale answer source.  It needs =
to send CD=3D0 queries
>>>> on validation failure to force the upstream validator to try multiple =
sources.
>>>>
>>>> A validating client can=E2=80=99t just send CD=3D0.  It needs to send =
CD=3D1 on SERVFAIL in case the
>>>> upstream validator has a bad trust anchor (likely with the upcoming ro=
ot KSK roll) or has
>>>> a bad clock (these usually get fixed fast).
>>>>
>>>> Now to get a answer from a signed zone with servers with stale answers=
 a validatiing DNS64 client
>>>> needs to send:
>>>>
>>>> a) send CD=3D1 and validation failure send CD=3D0 then on AAAA validat=
ion failure send CD=3D1 and
>>>>    hope the TTL was not 0 and that is not cachable and there is no ass=
urance that you won=E2=80=99t get
>>>>    a answer from a stale source.
>>>>
>>>>       or
>>>>
>>>> b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 and h=
ope the TTL was not 0 as
>>>>    that is not cachable and there is no assurance that you won=E2=80=
=99t get a answer from a stale source.
>>>>
>>>> TTL=3D0 answers exist.
>>>>
>>>> Note none of this is documented in a RFC.  You have to understand how =
both DNSSEC and DNS64 work to
>>>> realise this.
>>>>
>>>> IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix=
 discover for DNS VALIDATORS.
>>>> Note =E2=80=9Cad=E2=80=9D is set in the flags.  Yes, I=E2=80=99ve subm=
itted a errata.  Yes, I=E2=80=99ve opened a ticket to get it fixed but
>>>> based on past experience that could take months if it happens at all. =
 You will note that the recursive
>>>> server is running on the loopback interface so all DNS answers are bei=
ng validated here.
>>>>
>>>> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
>>>> ;; BADCOOKIE, retrying.
>>>>
>>>> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
>>>> ;; global options: +cmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
>>>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: =
1
>>>>
>>>> ;; OPT PSEUDOSECTION:
>>>> ; EDNS: version: 0, flags:; udp: 4096
>>>> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
>>>> ;; QUESTION SECTION:
>>>> ;IPV4ONLY.ARPA.                       IN      A
>>>>
>>>> ;; ANSWER SECTION:
>>>> ipv4only.arpa.                26574   IN      A       192.0.0.171
>>>> ipv4only.arpa.                26574   IN      A       192.0.0.170
>>>>
>>>> ;; Query time: 0 msec
>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
>>>> ;; MSG SIZE  rcvd: 115
>>>>
>>>> [rock:bind9/bin/named] marka%
>>>>
>>>>> It's not true that all phones have clat support. Notably, Apple not o=
nly does not support it but appears ideologically opposed to it on the grou=
nds that it does not have a good exit strategy (because it makes it possibl=
e to run IPv4-only apps forever).
>>>>
>>>>
>>>> --
>>>> Mark Andrews, ISC
>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>>>>
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>>
>>
>> --
>> SY, Jen Linkova aka Furry
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------



--=20
SY, Jen Linkova aka Furry


From nobody Tue Nov 14 21:13:58 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5869B128C9C for ; Tue, 14 Nov 2017 21:13:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 BXby2BJ2iL3K for ; Tue, 14 Nov 2017 21:13:54 -0800 (PST)
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 9D59F127B73 for ; Tue, 14 Nov 2017 21:13:54 -0800 (PST)
Received: by mail-io0-x22e.google.com with SMTP id 71so335979ior.7 for ; Tue, 14 Nov 2017 21:13:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hIotUHRfy9YcUwdIjIcy9/mJaD1NfRNeTn7jm2kztd4=; b=G0721FbZHTdvUG/ZobILqVw0fktbMQthtmhi7wAENqMZQJZ/9hEgZDO8ftSilQcgWQ RvhAIblGfetCkfR8g4adh11FpfAqBa5veSmaYAtjFRgVd6t+8EE+gsTQuI87JlDTV+tC khKGEFqnL7kDsdFN7+Kt4bMUpmSLRxcZEPNKRpgD1i3ohNTfZ2i0AZdJxU6ctOsHojSG 4kAsxwjjOlut699nyouWXMgPagJy+czu741CdTQqYq8Q2mxzL//4cSGaUgYbHD+9xf/h IoMSq97RSOAvIb/V5w30pRouz/XPpxWHF14+hqa0jnnRkWN1f4CnLxItTAlyKJg0Y/pX 0b5w==
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=hIotUHRfy9YcUwdIjIcy9/mJaD1NfRNeTn7jm2kztd4=; b=KFpVNpycBEBEnKwK544K8TekKTOQy+E2etoevsSv1SKllm4WtNiyeiaosEfsraPUQq Or0wReMOHFZ8HNX/DMILzdcKcS/l2dVTj3tLxaRP8TQTcf2pb30Lv+Lxwuoze6yDZbex uOGpkVEJ8Qd98w334Cc35szmfQi6TJItlrXULxJtnoCZ3UsQa77E8HjXOzxNZR6JgT/3 nhPC18NV+Wvk95bLQaVxCZOo744P1NdQ48AgPCyRrwQLfrGWfEmfisCCZMcQFVq8UNUe oLliJiqy8HZjoU7TcjpkBfIedEAQGTT7lzHi7q1EruiBLJPwQmXAwZvHCvryGLUFa1z9 BYbw==
X-Gm-Message-State: AJaThX6D4Qf9gv5cqG2z0O3CKcKb8xpIw9n90E7qieWHirqC4nsHrcue 1qvyutBiJ9g/OEgCAdKtyfUs7g==
X-Google-Smtp-Source: AGs4zMalgqRiM4Yuqz6wUErLXUr95+GEdUAVhILBRiuRsyP+B/PUR+5fUKil0JOtv5Zh/dpvZ04ijQ==
X-Received: by 10.107.97.1 with SMTP id v1mr4101946iob.263.1510722833761; Tue, 14 Nov 2017 21:13:53 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id p17sm9066831iod.40.2017.11.14.21.13.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 21:13:53 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Ralph Droms 
Cc: Lee Howard , ipv6@ietf.org
References:     <2C1A44D3-A53B-4E2A-9FF1-79A715518E9A@gmail.com> <2a97bed4-c224-5728-bb78-978279c41e66@gmail.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <4472589f-4b6a-2687-d729-9eb866174902@gmail.com>
Date: Wed, 15 Nov 2017 18:13:53 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <2a97bed4-c224-5728-bb78-978279c41e66@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 05:13:56 -0000

Update at the end...

On 15/11/2017 16:31, Brian E Carpenter wrote:
> On 15/11/2017 16:11, Ralph Droms wrote:
>>
>>
>>> On Nov 14, 2017, at 10:07 PM, Brian E Carpenter  wrote:
>>>
>>> On 15/11/2017 15:59, Lee Howard wrote:
>>>>
>>>>
>>>> On 11/15/17, 10:44 AM, "ipv6 on behalf of Brian E Carpenter"
>>>>  wro=
te:
>>>>
>>>>> On 15/11/2017 15:13, Alexandre Petrescu wrote:
>>>>>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
>>>>>
>>>>> Also on the DNS64 network. But it is all one-way, you
>>>>> will notice. No replies as far as I can see. Most of them
>>>>> are sourced from 169.254.*.*, but there are some oddities such as
>>>>> 31.130.227.98	224.0.0.1	IGMPv2	42	Membership Query, general
>>>>
>>>>
>>>> Does that return us to the question of how to tell hosts that IPv4 d=
oesn=E2=80=99t
>>>> live here, and to stop trying?
>>>
>>> Maybe. But on the other hand there is no reason in principle
>>> that peer2peer traffic between 169.254.*.* addresses won't work.
>>> (There are reasons in practice, e.g. it doesn't work on Windows 7.)
>>
>> Can you get any sense of how much of the IPv4 traffic is useless?  Wou=
ld it be useful to try to quench that useless traffic to improve network =
performance, behavior, operations? =20
>>
>=20
> At the moment I think it's 100% useless traffic - in the two captures,
> I see messages from many 169.254.*.* addresses and, I think, none that
> are sent to such an address (except 169.254.255.255). Haven't quite
> figured out the Wireshark display filter to be 100% certain

The correct display filter is ip.dst=3D=3D169.254.0.0/16 and ip.dst!=3D16=
9.254.255.255
and the result is exactly zero messages with a unicast destination
in 169.254.0.0/16. So I can assert that there is no peer to peer
IPv4 link local traffic, just futile attempts to reach multicast
destinations.

There's quite a lot to 255.255.255.255, with a large majority being=20
"Dropbox LAN sync Discovery Protocol".

   Brian


From nobody Tue Nov 14 23:36:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BD6129447 for ; Tue, 14 Nov 2017 23:36:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vLzOTjTb5Cgo for ; Tue, 14 Nov 2017 23:36:52 -0800 (PST)
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 C245A1270A0 for ; Tue, 14 Nov 2017 23:36:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510731409; x=1511336209; 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=XOFT0rtpxJfDpWaRrX0rNeuCB tn+wVmXALgVGb0mUtM=; b=p2flrawcVlj2FFxyEEOk9scEV0d9awyV8+pg/5+6/ VBPW/oS/nWB1/peVUBZ/IpqhE2tc+dYzmKj2aw1Bl0A0Vt6UU9ObL5CVcgVJrNG9 YIHu75IpZXHoLE/w/su7qciD9wnzcSDZXUxiAIpEuC4i5QTXvVtAB3/OzqKASa1e 7I=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=UEliniMWRdRRyAt+T/AqzPCri7WoXGgsd4cpe/UysnBPzSZzoKy2/oLWrtRQ XFSN9yunUMwNlGlpKHbxuw50nfogcqJhREKvs2yoxP/W6D9BSDDWWJ58L 8uw3JfJN4LCtRMcV55PaPIKClHXqQ3XWZWCxWk0+GYX8N4emU8yJmk=;
X-MDAV-Processed: mail.consulintel.es, Wed, 15 Nov 2017 08:36:49 +0100
X-Spam-Processed: mail.consulintel.es, Wed, 15 Nov 2017 08:36:48 +0100
Received: from [31.133.140.255] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005624238.msg for ; Wed, 15 Nov 2017 08:36:47 +0100
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:171115:md50005624238::OL4fsNBNOvkJZmwh:00004f03
X-Return-Path: prvs=1492ded23e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Wed, 15 Nov 2017 15:36:28 +0800
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 6man WG 
Message-ID: 
Thread-Topic: IPv6 only host NAT64 requirements?
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 07:36:54 -0000

> I was also thinking on this yesterday after the hackathon and I thing fro=
m that talk it is obvious that I will support that.
   =20
    Thanks.
   =20
    >=20
    > Also thought about this:
    >=20
    > Could the =E2=80=9CIPv6 node requirements document=E2=80=9D include a=
lso a consideration for the same you mention here, in case there is IPv4-on=
ly in a dual-stack LAN with IPv6-only access?
   =20
    Not sure I understand what dual stack LAN with IPv6 only access means.
    If it is dual-stack, I'd assume you also have IPV4 routing.

[Jordi] What I mean is a LAN (which is dual-stack) but with *hosts* that ar=
e IPv4-only (old devices, IP cameras, printers, many other very frequently =
found in home networks, even corporate ones). The problem I see is that tho=
se hosts not always will get updated, unless maybe very severe security iss=
ues =E2=80=A6
   =20
    > I=E2=80=99m almost sure that this is out of the scope of the 6man cha=
rter, but I also feel that this is somehow our job =E2=80=A6 alternatively =
what is the correct place to do that? May be a new sunset4 document? Or int=
-area? The point here is an IPv4-only host being used in a network using IP=
v6-only for the access ...
   =20
    If you are talking about the reverse problem, an IPv4 only host requiri=
ng access to the IPv6 Internet.
    Or an isolated IPv4 only host in an IPv6 only network... I'd think that=
 would be better suited for sunset4.

[Jordi] yeah, I guess we agree =E2=80=A6
   =20
    Cheers,
    Ole
   =20



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

This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the 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 Nov 14 23:53:01 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746891294D3 for ; Tue, 14 Nov 2017 23:52:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 bVGM9Lf85iKt for ; Tue, 14 Nov 2017 23:52:56 -0800 (PST)
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 EF9741270A0 for ; Tue, 14 Nov 2017 23:52:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510732374; x=1511337174; 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=8U9kf6zNXv+YY7mB293KXN+Ml hlisldwjT0QEr9UlMU=; b=UOc0RyYHGsNUEF/f9ShGq2Wq5D4xuf44duTqIAgSt Mt8OK9Z/lbxCJo8ItWKjuKpR82vjcnXiqVX2jD880tKhQHfyWUXAhn26bm3nGd/0 hwkEddon9mqcQGld8DGzSH21qYa4iIocHWiIWw7wBOCK5GV5UX4+QNBo+umvtQBH jo=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=EAuFoUBl03XdrIFWEtWnau9j2FCO+HbCgubbKu0+nL5UpLA3VKgsayWj257U AR73bo6qetOwcFSZdyG9738V9zSjU/6W5uYs+RVGAKAPZD166pAnl7yDV B/SehpoCDRLPcJuMHe0Qc+LVZz1Y0kTC+NJIqE6OkezF+lGl5GsZKY=;
X-MDAV-Processed: mail.consulintel.es, Wed, 15 Nov 2017 08:52:54 +0100
X-Spam-Processed: mail.consulintel.es, Wed, 15 Nov 2017 08:52:53 +0100
Received: from [31.133.140.255] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005624246.msg for ; Wed, 15 Nov 2017 08:52:51 +0100
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:171115:md50005624246::cLF62cDlZCWYvqt4:00004x3q
X-Return-Path: prvs=1492ded23e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Wed, 15 Nov 2017 15:52:32 +0800
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 6man WG 
Message-ID: 
Thread-Topic: IPv6 only host NAT64 requirements?
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org> <6445323B-FFE4-4A3E-9EFB-9F4D05BED0D5@jisc.ac.uk> <48E76543-3DD4-43E8-9B50-5CC4D9D76A2F@cisco.com> <7C928B66-8D07-42A0-9168-617E2978227F@jisc.ac.uk>      <991C27F8-26BE-4588-B8FA-D83531F8742D@employees.org>
In-Reply-To: <991C27F8-26BE-4588-B8FA-D83531F8742D@employees.org>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Reply-To: jordi.palet@consulintel.es
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 07:52:57 -0000

> I thought this deployment provided dual stack service? 464XLAT, no?
    > 
    > My definition of ipv6-only includes 464xlat
    
    Terminology is tricky. As proven by Jordi's presentation in v6ops today.
    
    The difference as I see it between IPv6 only + NAT64 and 464XLAT is that in the former an IPv4 application cannot work.
    While in the latter the host has an IPv4 address and the IPv4 only application works just as if it is provisioned with IPv4 using any other means. That being native, LW46, MAP-E, MAP-T, L2TP, Public4over6, DSTM, 2473, DS-lite...
    
    Different use cases. While 464XLAT is a way to tunnel IPv4 across an IPv6 only access network (albeit with a null encap. :-)), IPv6 only + NAT64 is about delivering IPv6 only to hosts and applications. Applications would only have an IPv6 address to bind to. This use case would be much more akin to an enterprise network or home network.
  
[Jordi] The problem I see here is that in both home and enterprise networks, for at least 3-4 years, we will have to support IPv4 only devices (as just mention in a previous email). So NAT64 is not sufficient.
  
    > To your point, a large percentage of the tmobile case is 6555bis with nat64/dns64.
    > 
    > Based on the picture, you can probably guess when 6555bis was implemented ands its relative impact
    
    :-)
    
    Cheers,
    Ole
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



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

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




From nobody Tue Nov 14 23:57:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE45129549 for ; Tue, 14 Nov 2017 23:57:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 pc8FFE4_6ZHF for ; Tue, 14 Nov 2017 23:57:44 -0800 (PST)
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 67628124BE8 for ; Tue, 14 Nov 2017 23:57:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510732658; x=1511337458; 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=2cVCyh2n1rHBmqxWC2yo9qZ6F pnBlv/XqwKHx0ot//E=; b=OXvrW0gAVr3VC3qXdNiagejZPa/cP5YkbaUkSG5CW hjdN8exGDe84Fx0juJ1kzQ6NaTQDq7OvHJmN2VjfGpCPsp6G+rGaIBfEsinnvmxC /S5CB8HCByocjpvzyQfJhjsXKIxMyfS6vn2x5UPYWF864p16SGQdSu4cDJ10PZbV io=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=Lub6NvMw8+fohVnWbcQeNo7ctk2Il5XNNr2fvGO0M2Fv8tyqDqNeiqSrR0na Nt+SOmq6fbrhs9wCE/pay5zXA6sj0dXVLinYkVIsuRhEQCHGHMTh9UYU9 q+oZkY8eECo8fjTPqbrZETb6jleybmY2NHtI1s9G0TljfLHnrZRtco=;
X-MDAV-Processed: mail.consulintel.es, Wed, 15 Nov 2017 08:57:38 +0100
X-Spam-Processed: mail.consulintel.es, Wed, 15 Nov 2017 08:57:37 +0100
Received: from [31.133.140.255] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005624248.msg for ; Wed, 15 Nov 2017 08:57:37 +0100
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:171115:md50005624248::auo8iYYvSpkaLDMP:00003cia
X-Return-Path: prvs=1492ded23e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Wed, 15 Nov 2017 15:57:27 +0800
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 
Message-ID: <8567DB0A-31E9-4D88-AA90-FE15F52639C5@consulintel.es>
Thread-Topic: IPv6 only host NAT64 requirements?
References: <6755862C-AA12-45B4-98B8-EF6D9F90898B@employees.org>  
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Reply-To: jordi.palet@consulintel.es
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 07:57:46 -0000

That tunneling technology is 464XLAT, depending on how you deploy it:

https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-deployment/

Regards,
Jordi
 

-----Mensaje original-----
De: ipv6  en nombre de Philip Homburg 
Responder a: 
Fecha: martes, 14 de noviembre de 2017, 6:11
Para: 
Asunto: Re: IPv6 only host NAT64 requirements?

    >I am not optimistic on the demand / need / value of dnssec in any scenario
    >....let alone an ipv6-only host validating an ipv4-only dns name. If the
    >folks operating this service cared, they could operate the server with
    >signed v6 names.  It is more reasonable in todays internet to asked the
    >server (lets assume most signed name scenarios are servers) to be setup
    >right (with v6). There is not a compelling reason why having v6 is
    >unattainable today for named nodes.
    
    DNSSEC is something that works today. Opinions are divided on what security
    it offers. Some people like it way more than the traditional CA system. 
    Other people believe that we should continue making random changes to the CA
    system in the hope that one day it will be secure.
    
    The problem for people who do local DNSSEC validation is that if neither the
    NAT64/DNS64 operator nor the operator of the target server cares about 
    DNSSEC/IPv6 then it just breaks.
    
    If all server operators cared, then there would be no need for NAT64/DNS64
    so the problem would not exist in the first place.
    
    If the NAT64/DNS64 operator cared, then they would offer be dual stack IPv4
    or a tunneling based transition technology that doesn't break DNSSEC.
    
    I guess the good news is that at least one group of people writing a local
    DNSSEC validating resolver (getdns) are aware of this issue and are adding
    code to handle this situation.
    
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



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

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




From nobody Wed Nov 15 00:06:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD24C1270A0 for ; Wed, 15 Nov 2017 00:06:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vTf3i2jrCmvH for ; Wed, 15 Nov 2017 00:06:27 -0800 (PST)
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 2F078124BE8 for ; Wed, 15 Nov 2017 00:06:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510733184; x=1511337984; 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=/okV2CCz8mSYo9v97boKPVQf3 KpKoswzwKAb4T5DVFA=; b=N/Ba0SsQ/knmAxNkqz4b4A1t6B9dHlB8uSdJpNHhI ajs1RojL4FYfAQCtXI1hgUc/h9QVxa0nywxP6rKSUPEFtJRbToH8low9PEflrcVP Aev6XzND+ExxsLKcynHG1yICnyf8N+PdLXuNb2VSYGGR4Tu1VsdF2z8LJyPzJwjl cI=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=bq3PXjGMW21SLmGmP10XUQKu3Wi9VI9E9CToU5VepKuuCdrbHHS8aeuhjUu4 120xGRDIdM8awiOl6v7MUG+qxRIUM1eZVy9t8vhvc47kSc51DSMkLM0Z8 s57e6DkhPVqlkBdxeinK67ZDcYbgpHE8+BgNdKF0tuJb8BDYbjydyg=;
X-MDAV-Processed: mail.consulintel.es, Wed, 15 Nov 2017 09:06:24 +0100
X-Spam-Processed: mail.consulintel.es, Wed, 15 Nov 2017 09:06:23 +0100
Received: from [31.133.140.255] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005624254.msg for ; Wed, 15 Nov 2017 09:06:22 +0100
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:171115:md50005624254::P9XojiyqWCh7IaTm:00003DNz
X-Return-Path: prvs=1492ded23e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Wed, 15 Nov 2017 16:06:06 +0800
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 
Message-ID: <71004332-84A3-4175-93C0-AE69D777F04D@consulintel.es>
Thread-Topic: IPv6 only host NAT64 requirements?
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>
In-Reply-To: <73231F8D-498E-4C77-8DA8-044365368FC9@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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 08:06:29 -0000

Is there any reason to run DNS64 at all these days?  ipv4only.arpa can be a=
 preconfigured
    zone which allows CLAT to get its mapping.  All the phones have CLAT su=
pport.  Can we just
    make DNS64 historic and let the phones run all IPv4 connections through=
 CLAT rather than
    having to stuff up DNSSEC and have IPv6 connections terminate in IPv4 s=
ervers without
    the application knowing?

[Jordi] Mark, this will not work: You need to consider that even if the pho=
ne is dual stack, there may be IPv4-only devices behind the phone (tetherin=
g), that NEED a DNS64. If the IPv4 device is validating, then is broken. If=
 the IPv4 devices is not validating, then because the phone act as DHCP ser=
ver for it, and provides the DNS, the phone acts as the DNS64 and even vali=
dator, then we are set =E2=80=A6 but phones today don=E2=80=99t do DNSSEC.


   =20
    Mark
   =20
    > On 14 Nov 2017, at 4:11 am, Philip Homburg  wrote:
    >=20
    >>> (c) Every ICMPv6 error message (type < 128) MUST include as much of
    >>>   the IPv6 offending (invoking) packet (the packet that caused the
    >>>   error) as possible without making the error message packet exceed
    >>>   the minimum IPv6 MTU
    >>=20
    >> Right. But when is that an actual issue for applications?
    >=20
    > First, I naively put this in my TCP implementation. Technically that'=
s
    > not an application, though user land TCP does occur.
    >=20
    > It also breaks my traceroute implementation.
    >=20
    >> Then we are stuck with dual stack.
    >> What Randy and Jen set out to try in the IETF experiment was to figu=
re=20
    >> out if it would be possible to do IPv6 only + NAT64. Identify what w=
as=20
    >> broken and then get that fixed. If we're stuck with dual stack (or I=
Pv4=20
    >> only), then we're not moving towards the end-goal, are we?
    >=20
    >> From a host point of view, I very much want to be dual stack. No mag=
ic.
    > What goes over the wire is what the application sees. IPv6 is complex=
 enough
    > on its own. Adding DNS64/NAT64 make it less likely that people can ac=
tually
    > understand what is going on.=20
    >=20
    > Hosts being dual stack doesn't say anything about backbone networks. =
You
    > can do 464xlat on access routers or any other kind of IPv4 tunneling
    > technology. By tunneling on access routers you can even preserve a 15=
00 octet
    > MTU for IPv4.
    >=20
    > In my view, the way we move to the end goal is when some networks rea=
lly don't
    > have any IPv4 anymore.=20
    >=20
    > When IPv6-only eyeball networks appear that don't offer any kind of I=
Pv4
    > connectivity, content providers either add support for IPv6 or they l=
ose that
    > group of potential customers.
    >=20
    > After a while, cheap consumer networks just drop IPv4 because it too =
expensive
    > to maintain.=20
    >=20
    > That's when IPv4 becomes truly legacy: you may have IPv4 connectivity=
 at work,
    > but possible not at home. Not at a random place that offers wifi, not=
 in
    > your hotel.
    >=20
    > In corporate environments, assuming that all legacy applications can =
get
    > rewritten to support IPv6, the next step is to install proxies that o=
ffer
    > access to the few essential external services that are still IPv4 onl=
y.
    > Though possibly, those services start installing reverse proxies to o=
ffer
    > IPv6.
    >=20
    > The only thing offering NAT64 to hosts does is making access networks=
 IPv6-only
    > while introducing a lot of complexity without increasing end-to-end I=
Pv6
    > connectivity.
    >=20
    >=20
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > ipv6@ietf.org
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------
   =20
    --=20
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
   =20
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
   =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 Nov 15 02:17:43 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099FE129459 for ; Wed, 15 Nov 2017 02:17:42 -0800 (PST)
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 3xq9RjsC9yCU for ; Wed, 15 Nov 2017 02:17:40 -0800 (PST)
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 0D7F9126CE8 for ; Wed, 15 Nov 2017 02:17:40 -0800 (PST)
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 AED503B33A7; Wed, 15 Nov 2017 10:17:36 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7339A16003F; Wed, 15 Nov 2017 10:17:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 61535160087; Wed, 15 Nov 2017 10:17:36 +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 ZtV7EdIyMdyQ; Wed, 15 Nov 2017 10:17:36 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 859C916003F; Wed, 15 Nov 2017 10:17:35 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
From: Mark Andrews 
In-Reply-To: <71004332-84A3-4175-93C0-AE69D777F04D@consulintel.es>
Date: Wed, 15 Nov 2017 21:17:32 +1100
Cc: ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9160BE92-BA4B-4442-B8FB-46B86A5E8858@isc.org>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> <71004332-84A3-4175-93C0-AE69D777F04D@consulintel.es>
To: jordi.palet@consulintel.es
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:17:42 -0000

> On 15 Nov 2017, at 7:06 pm, JORDI PALET MARTINEZ =
 wrote:
>=20
> Is there any reason to run DNS64 at all these days?  ipv4only.arpa can =
be a preconfigured
>    zone which allows CLAT to get its mapping.  All the phones have =
CLAT support.  Can we just
>    make DNS64 historic and let the phones run all IPv4 connections =
through CLAT rather than
>    having to stuff up DNSSEC and have IPv6 connections terminate in =
IPv4 servers without
>    the application knowing?
>=20
> [Jordi] Mark, this will not work: You need to consider that even if =
the phone is dual stack, there may be IPv4-only devices behind the phone =
(tethering), that NEED a DNS64. If the IPv4 device is validating, then =
is broken. If the IPv4 devices is not validating, then because the phone =
act as DHCP server for it, and provides the DNS, the phone acts as the =
DNS64 and even validator, then we are set =E2=80=A6 but phones today =
don=E2=80=99t do DNSSEC.

and the IPv4 device sends a IPv4 packet to the phone which then runs it =
through the CLAT to
translate it into a IPv6 packet which is sent to the NAT64 which turns =
it back into a IPv4 packet.
None if this requires a DNS64 server.   All DNS64 does is reduce the =
number of IPv4 packets
that are translated by the CLAT.  It does not reduce the work of the =
NAT64.


>    Mark
>=20
>> On 14 Nov 2017, at 4:11 am, Philip Homburg =
 wrote:
>>=20
>>>> (c) Every ICMPv6 error message (type < 128) MUST include as much of
>>>>  the IPv6 offending (invoking) packet (the packet that caused the
>>>>  error) as possible without making the error message packet exceed
>>>>  the minimum IPv6 MTU
>>>=20
>>> Right. But when is that an actual issue for applications?
>>=20
>> First, I naively put this in my TCP implementation. Technically =
that's
>> not an application, though user land TCP does occur.
>>=20
>> It also breaks my traceroute implementation.
>>=20
>>> Then we are stuck with dual stack.
>>> What Randy and Jen set out to try in the IETF experiment was to =
figure=20
>>> out if it would be possible to do IPv6 only + NAT64. Identify what =
was=20
>>> broken and then get that fixed. If we're stuck with dual stack (or =
IPv4=20
>>> only), then we're not moving towards the end-goal, are we?
>>=20
>>> =46rom a host point of view, I very much want to be dual stack. No =
magic.
>> What goes over the wire is what the application sees. IPv6 is complex =
enough
>> on its own. Adding DNS64/NAT64 make it less likely that people can =
actually
>> understand what is going on.=20
>>=20
>> Hosts being dual stack doesn't say anything about backbone networks. =
You
>> can do 464xlat on access routers or any other kind of IPv4 tunneling
>> technology. By tunneling on access routers you can even preserve a =
1500 octet
>> MTU for IPv4.
>>=20
>> In my view, the way we move to the end goal is when some networks =
really don't
>> have any IPv4 anymore.=20
>>=20
>> When IPv6-only eyeball networks appear that don't offer any kind of =
IPv4
>> connectivity, content providers either add support for IPv6 or they =
lose that
>> group of potential customers.
>>=20
>> After a while, cheap consumer networks just drop IPv4 because it too =
expensive
>> to maintain.=20
>>=20
>> That's when IPv4 becomes truly legacy: you may have IPv4 connectivity =
at work,
>> but possible not at home. Not at a random place that offers wifi, not =
in
>> your hotel.
>>=20
>> In corporate environments, assuming that all legacy applications can =
get
>> rewritten to support IPv6, the next step is to install proxies that =
offer
>> access to the few essential external services that are still IPv4 =
only.
>> Though possibly, those services start installing reverse proxies to =
offer
>> IPv6.
>>=20
>> The only thing offering NAT64 to hosts does is making access networks =
IPv6-only
>> while introducing a lot of complexity without increasing end-to-end =
IPv6
>> connectivity.
>>=20
>>=20
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>=20
>    --=20
>    Mark Andrews, ISC
>    1 Seymour St., Dundas Valley, NSW 2117, Australia
>    PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>=20
>    =
--------------------------------------------------------------------
>    IETF IPv6 working group mailing list
>    ipv6@ietf.org
>    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>    =
--------------------------------------------------------------------
>=20
>=20
>=20
>=20
>=20
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>=20
> This electronic message contains information which may be privileged =
or confidential. The information is intended to be for the exclusive use =
of the individual(s) named above and further non-explicilty authorized =
disclosure, copying, distribution or use of the contents of this =
information, even if partially, including attached files, is strictly =
prohibited and will be considered a criminal offense. If you are not the =
intended recipient be aware that any disclosure, copying, distribution =
or use of the contents of this information, even if partially, including =
attached files, is strictly prohibited, will be considered a criminal =
offense, so you must reply to the original sender to inform about this =
communication and delete it.
>=20
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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


From nobody Wed Nov 15 02:24:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0D512706D for ; Wed, 15 Nov 2017 02:24:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpCQLhmF0FH0 for ; Wed, 15 Nov 2017 02:24:31 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E454A128B88 for ; Wed, 15 Nov 2017 02:24:30 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id b6so16463523pff.10 for ; Wed, 15 Nov 2017 02:24:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YD0f3zO/O2aEmYliACWB7f6CggSaV2yMv9k1B7IIpV4=; b=VxlDxHxkruEGoEghONdBwN2Hd1ckOj/bt+fxbYAvO6Kgfqw/FlkpKz7jxrD/TkT/2i ZSyWcpSOVVCy3xiDEAWAuDDUwLdyl7lQK/94dm3duyrgvM3sqOPNn/rP2Fd5ManBjjEl L4rks0OrUNhsfCykOAfmL/BSh4sI5jnoXW8390TASp6WOvVELcnb36hkYxOK6UmRCSvI Uo6NSUVdvpfMNgRF/E/pJJ4uA+ViX4gc4Y7YGbYjCBxIJBYb3COeI5yxZ63WTU++3hoH hYmEfJcpMuunKxH+wdZhvOeA+kifUsxtUTHlJPrqfR1rsywSr6ABHNEQq+fsFzbU5xzb CZJQ==
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=YD0f3zO/O2aEmYliACWB7f6CggSaV2yMv9k1B7IIpV4=; b=TnWkpZElMkWinO5PIYLNBxNu39pLPUxFM2JWEi10HyyxPStsXJiRcDYZ+j67zqzeXF MBGl7Hh4vqJHhwFcQqRJtJ40pjYywEZhuxpv+HPF+Cu6XPfiFIkW3dVV98hvwUIqhGow NMkgqWMv3VAU7Gv1ioA5vd7P+LbpENKDbkBckznSfVyUVYWbnlF/hnfFp2O+mVyLJV3W e4HMUtqmVn1FCEWNRSW8yi5FbSbX1z+HmgcEyQ3g/BvJZqTk0wkTvyUaFb89mV8nC/qk vQiiI2wMB0AZplLIkfhumv/FMpP+RdrZqQTli1ed/1XIaY0oZoKSIGYoCvlPKf6adS6Z Zsww==
X-Gm-Message-State: AJaThX40vZElcyeCtWejxNqHY2sZO1TdiLaoit7FoVIF4He7lqVLbNaN elolfE8A+r6BVrxWOGL6IibRuA==
X-Google-Smtp-Source: AGs4zMZ+FfWifVkgTJiRqLUIqEOvxcqibT6am5Bm6bTdkNXqjOL8nyCvKlHJ5sSJ+TRD2ziUJ1iKdw==
X-Received: by 10.84.131.6 with SMTP id 6mr15697751pld.100.1510741470360; Wed, 15 Nov 2017 02:24:30 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s65sm43811852pfj.81.2017.11.15.02.24.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 02:24:29 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Jen Linkova , Ole Troan 
Cc: 6man WG , Mark Andrews 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>  
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <449b423b-9d60-82e9-19ea-a9e8fc197086@gmail.com>
Date: Wed, 15 Nov 2017 23:24:29 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:24:33 -0000

Excuse front posting but +1, this is IMHO just about the
last thing worth saying on this thread.

Regards
   Brian

On 15/11/2017 16:05, Jen Linkova wrote:
> On Wed, Nov 15, 2017 at 1:07 PM, Ole Troan  wrote=
:
>> If I may try to suggest a solution based on what you are saying:
>>
>> - Remove (external) DNS64 from the solution
>> - Replace NAT64 prefix discovery with some sort of local configuration=
=2E e.g. put it in DHCP or RA
>>
>> Which has the implications that:
>>  - host learns NAT64 prefix via RA/DHCP
>>  - host is free to use whatever DNS recursive resolvers (instead of th=
e must be local (and on correct interface where the NAT64 is) resolver
>>  - host synthesises addresses itself. And does validation before synth=
esising (if that's required).
>>
>> Is this the solution you would be looking for?
>>
>> And yes, you need host changes. But we need that anyway.
>=20
> NAT64 is a band aid, a tactical solution to deal with IPv4-only hosst
> while we are waiting for them to die. Requiring *mandatory* changes on
> majority of devices which are working on NAT64 networks just fine
> currently to solve problems for those who either a) sign their zones
> but do not enable Ipv6 b)doing some smart things in their host
> resolvers looks like an overkill to me..
>=20
> IMHO the optimal solution is:
> - the network SHOULD provide a host with NAT64 prefix information in
> RA (I do not believe that information needs to be duplicated in DHCP
> at all);
> - an application MAY use that information to do AAAA synthetics
> (validating resolvers SHOULD do that).
> - network still provides DNS64 servers to hosts so all unsophisticated
> hosts (majority of devices falls into that category) continue to use
> network-provided resolvers.
>=20
>=20
>>
>>> On 15 Nov 2017, at 08:06, Mark Andrews  wrote:
>>>
>>>
>>>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti  wro=
te:
>>>>
>>>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews  wrote:=

>>>> Is there any reason to run DNS64 at all these days?  ipv4only.arpa c=
an be a preconfigured
>>>> zone which allows CLAT to get its mapping.  All the phones have CLAT=
 support.
>>>>
>>>> That's an interesting idea. It would work in theory, but such a netw=
ork would completely break devices that don't support 464xlat. That gives=
 up one of the major advantages of NAT64/DNS64, which is that it's a 90% =
solution even just by itself - yes, IPv4-only applications and address li=
terals exist, but most simple client/server applications Just Work behind=
 it.
>>>
>>> And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.  It b=
asically requires EVERY DNS VALIDATOR ON
>>> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64 SE=
RVER.
>>>
>>> DNS64/NAT64 was presented as NOT REQUIRING node changes when first mo=
oted.  It keeps on
>>> requiring more and more highly invasive node changes to support.  It =
was from the very beginning
>>> bad engineering.   To get IPv4 as a service some node changes are req=
uired.  Lets make sure they
>>> are MINIMAL ones.
>>>
>>> Just for the record DNSSEC validators need to send BOTH CD=3D0 and CD=
=3D1 queries to get answers
>>> though a upstream VALIDATING server which includes a VALIDATING DNS64=
 server as CD=3D0 and
>>> CD=3D1 address different DNSSEC threats.  I tried very hard to point =
that out when RFC 6147 was
>>> being written but the working group decide that CD indicated whether =
the client was validating or
>>> not.  There is NO SUCH INDICATION in a DNS message.
>>>
>>>  If a query arrives at a vDNS64 device with the "Checking Disabled"
>>>   (CD) bit set, it is an indication that the querying agent wants all=

>>>   the validation data so it can do checking itself.  By local policy,=

>>>   vDNS64 could still validate, but it must return all data to the
>>>   querying agent anyway.
>>>
>>> CD=3D0 queries causes the upstream validating servers to reject incom=
ing spoofed answers
>>> or stale answers (this is a common operational problem).
>>>
>>> CD=3D1 queries allow the validation to succeed when the upstream vali=
dator has a bad trust
>>> anchor or a bad clock which is rejecting legitimate answers.
>>>
>>> A validating client can=E2=80=99t just send CD=3D1 queries as the ups=
tream validator doesn=E2=80=99t kick in.
>>> The upstream validator can lock onto a stale answer source.  It needs=
 to send CD=3D0 queries
>>> on validation failure to force the upstream validator to try multiple=
 sources.
>>>
>>> A validating client can=E2=80=99t just send CD=3D0.  It needs to send=
 CD=3D1 on SERVFAIL in case the
>>> upstream validator has a bad trust anchor (likely with the upcoming r=
oot KSK roll) or has
>>> a bad clock (these usually get fixed fast).
>>>
>>> Now to get a answer from a signed zone with servers with stale answer=
s a validatiing DNS64 client
>>> needs to send:
>>>
>>> a) send CD=3D1 and validation failure send CD=3D0 then on AAAA valida=
tion failure send CD=3D1 and
>>>    hope the TTL was not 0 and that is not cachable and there is no as=
surance that you won=E2=80=99t get
>>>    a answer from a stale source.
>>>
>>>       or
>>>
>>> b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 and =
hope the TTL was not 0 as
>>>    that is not cachable and there is no assurance that you won=E2=80=99=
t get a answer from a stale source.
>>>
>>> TTL=3D0 answers exist.
>>>
>>> Note none of this is documented in a RFC.  You have to understand how=
 both DNSSEC and DNS64 work to
>>> realise this.
>>>
>>> IPV4ONLY.ARPA is currently has a secure delegation which breaks prefi=
x discover for DNS VALIDATORS.
>>> Note =E2=80=9Cad=E2=80=9D is set in the flags.  Yes, I=E2=80=99ve sub=
mitted a errata.  Yes, I=E2=80=99ve opened a ticket to get it fixed but
>>> based on past experience that could take months if it happens at all.=
  You will note that the recursive
>>> server is running on the loopback interface so all DNS answers are be=
ing validated here.
>>>
>>> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
>>> ;; BADCOOKIE, retrying.
>>>
>>> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
>>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL:=
 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 4096
>>> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
>>> ;; QUESTION SECTION:
>>> ;IPV4ONLY.ARPA.                       IN      A
>>>
>>> ;; ANSWER SECTION:
>>> ipv4only.arpa.                26574   IN      A       192.0.0.171
>>> ipv4only.arpa.                26574   IN      A       192.0.0.170
>>>
>>> ;; Query time: 0 msec
>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
>>> ;; MSG SIZE  rcvd: 115
>>>
>>> [rock:bind9/bin/named] marka%
>>>
>>>> It's not true that all phones have clat support. Notably, Apple not =
only does not support it but appears ideologically opposed to it on the g=
rounds that it does not have a good exit strategy (because it makes it po=
ssible to run IPv4-only apps forever).
>>>
>>>
>>> --
>>> Mark Andrews, ISC
>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>=20
>=20
>=20


From nobody Wed Nov 15 02:47:56 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10CF12711E for ; Wed, 15 Nov 2017 02:47:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i348hZIKm68 for ; Wed, 15 Nov 2017 02:47:53 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2362126CE8 for ; Wed, 15 Nov 2017 02:47:52 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEvEP-0000G3C; Wed, 15 Nov 2017 11:47:45 +0100
Message-Id: 
To: ipv6@ietf.org
Subject: Re: IPv4 traffic on "ietf-v6ONLY" 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
References:    
In-reply-to: Your message of "Wed, 15 Nov 2017 10:59:06 +0800 ."  
Date: Wed, 15 Nov 2017 11:47:39 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:47:54 -0000

> Does that return us to the question of how to tell hosts that IPv4
> doesnt live here, and to stop trying?

The safest option to do that is a DHCPv4 option that says 'no IPv4 service
here, go away'.

Any network that has IPv4 production traffic already has to protect against
rogue DHCPv4 servers. 

Of course, a DHCPv4 option conflicts with the goal of some people to have
no IPv4 related infrastructure at all.


From nobody Wed Nov 15 02:50:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDD21270AC for ; Wed, 15 Nov 2017 02:50:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 xKpj6oozwkd1 for ; Wed, 15 Nov 2017 02:50:46 -0800 (PST)
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 E1C63128B44 for ; Wed, 15 Nov 2017 02:50:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510743043; x=1511347843; 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=lrZpFv3EeRsBNOEBJ/MHpHu3X TZRDOGD9cQ+UBcJzC8=; b=cw2f2gRBuwUfuDA3CNmDSkmuPL6Z5Cvm+oNqWpdcV MsWfSvdC3w2dDm01oNcZD2yP4iu/f2JHzyOkjC3t/Opwb2gdXSpKQffF0n3Ew1gC rzhBGta6CXe4G/f5Pr6rgqg5uIPOegl7hY/N46qwBz4fDS0jqgYbgBWw36CwbbWk 1U=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=uMp+9yXeKqWoiZLzlaVOb7nHR83YP/KrRtXSd4m1WEdzlgqBMGcQh19wSHGv D2RTBYLrqEO31wWVpCbmnp6Jo2Q2s5bRP83TMLfxpq2qQYGLxDABq2+Fc TQmr+qw3iMcQDcEdM2GywQIbomQTui6/umAQVMD4cSfzok+OCJTAyQ=;
X-MDAV-Processed: mail.consulintel.es, Wed, 15 Nov 2017 11:50:43 +0100
X-Spam-Processed: mail.consulintel.es, Wed, 15 Nov 2017 11:50:41 +0100
Received: from [31.133.140.255] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005624380.msg for ; Wed, 15 Nov 2017 11:50:39 +0100
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:171115:md50005624380::2eKxNk49KSfiVnbb:00002AGE
X-Return-Path: prvs=1492ded23e=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Wed, 15 Nov 2017 18:50:22 +0800
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 
Message-ID: 
Thread-Topic: IPv6 only host NAT64 requirements?
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> <71004332-84A3-4175-93C0-AE69D777F04D@consulintel.es> <9160BE92-BA4B-4442-B8FB-46B86A5E8858@isc.org>
In-Reply-To: <9160BE92-BA4B-4442-B8FB-46B86A5E8858@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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 10:50:48 -0000

> On 15 Nov 2017, at 7:06 pm, JORDI PALET MARTINEZ  wrote:
    >=20
    > Is there any reason to run DNS64 at all these days?  ipv4only.arpa ca=
n be a preconfigured
    >    zone which allows CLAT to get its mapping.  All the phones have CL=
AT support.  Can we just
    >    make DNS64 historic and let the phones run all IPv4 connections th=
rough CLAT rather than
    >    having to stuff up DNSSEC and have IPv6 connections terminate in I=
Pv4 servers without
    >    the application knowing?
    >=20
    > [Jordi] Mark, this will not work: You need to consider that even if t=
he phone is dual stack, there may be IPv4-only devices behind the phone (te=
thering), that NEED a DNS64. If the IPv4 device is validating, then is brok=
en. If the IPv4 devices is not validating, then because the phone act as DH=
CP server for it, and provides the DNS, the phone acts as the DNS64 and eve=
n validator, then we are set =E2=80=A6 but phones today don=E2=80=99t do DN=
SSEC.
   =20
    and the IPv4 device sends a IPv4 packet to the phone which then runs it=
 through the CLAT to
    translate it into a IPv6 packet which is sent to the NAT64 which turns =
it back into a IPv4 packet.
    None if this requires a DNS64 server.   All DNS64 does is reduce the nu=
mber of IPv4 packets
    that are translated by the CLAT.  It does not reduce the work of the NA=
T64.

[Jordi] Yeah, sorry, I guess I=E2=80=99m too sleepy today and I=E2=80=99ve =
interpreted something else. In fact, I=E2=80=99ve a specific section about =
that in my document (3.  Using 464XLAT with/without DNS64):

https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-deployment
   =20
   =20
    >    Mark
    >=20
    >> On 14 Nov 2017, at 4:11 am, Philip Homburg  wrote:
    >>=20
    >>>> (c) Every ICMPv6 error message (type < 128) MUST include as much o=
f
    >>>>  the IPv6 offending (invoking) packet (the packet that caused the
    >>>>  error) as possible without making the error message packet exceed
    >>>>  the minimum IPv6 MTU
    >>>=20
    >>> Right. But when is that an actual issue for applications?
    >>=20
    >> First, I naively put this in my TCP implementation. Technically that=
's
    >> not an application, though user land TCP does occur.
    >>=20
    >> It also breaks my traceroute implementation.
    >>=20
    >>> Then we are stuck with dual stack.
    >>> What Randy and Jen set out to try in the IETF experiment was to fig=
ure=20
    >>> out if it would be possible to do IPv6 only + NAT64. Identify what =
was=20
    >>> broken and then get that fixed. If we're stuck with dual stack (or =
IPv4=20
    >>> only), then we're not moving towards the end-goal, are we?
    >>=20
    >>> From a host point of view, I very much want to be dual stack. No ma=
gic.
    >> What goes over the wire is what the application sees. IPv6 is comple=
x enough
    >> on its own. Adding DNS64/NAT64 make it less likely that people can a=
ctually
    >> understand what is going on.=20
    >>=20
    >> Hosts being dual stack doesn't say anything about backbone networks.=
 You
    >> can do 464xlat on access routers or any other kind of IPv4 tunneling
    >> technology. By tunneling on access routers you can even preserve a 1=
500 octet
    >> MTU for IPv4.
    >>=20
    >> In my view, the way we move to the end goal is when some networks re=
ally don't
    >> have any IPv4 anymore.=20
    >>=20
    >> When IPv6-only eyeball networks appear that don't offer any kind of =
IPv4
    >> connectivity, content providers either add support for IPv6 or they =
lose that
    >> group of potential customers.
    >>=20
    >> After a while, cheap consumer networks just drop IPv4 because it too=
 expensive
    >> to maintain.=20
    >>=20
    >> That's when IPv4 becomes truly legacy: you may have IPv4 connectivit=
y at work,
    >> but possible not at home. Not at a random place that offers wifi, no=
t in
    >> your hotel.
    >>=20
    >> In corporate environments, assuming that all legacy applications can=
 get
    >> rewritten to support IPv6, the next step is to install proxies that =
offer
    >> access to the few essential external services that are still IPv4 on=
ly.
    >> Though possibly, those services start installing reverse proxies to =
offer
    >> IPv6.
    >>=20
    >> The only thing offering NAT64 to hosts does is making access network=
s IPv6-only
    >> while introducing a lot of complexity without increasing end-to-end =
IPv6
    >> connectivity.
    >>=20
    >>=20
    >> --------------------------------------------------------------------
    >> IETF IPv6 working group mailing list
    >> ipv6@ietf.org
    >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    >> --------------------------------------------------------------------
    >=20
    >    --=20
    >    Mark Andrews, ISC
    >    1 Seymour St., Dundas Valley, NSW 2117, Australia
    >    PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
    >=20
    >    ------------------------------------------------------------------=
--
    >    IETF IPv6 working group mailing list
    >    ipv6@ietf.org
    >    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv=
6
    >    ------------------------------------------------------------------=
--
    >=20
    >=20
    >=20
    >=20
    >=20
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.consulintel.es
    > The IPv6 Company
    >=20
    > This electronic message contains information which may be privileged =
or confidential. The information is intended to be for the exclusive use of=
 the individual(s) named above and further non-explicilty authorized disclo=
sure, copying, distribution or use of the contents of this information, eve=
n if partially, including attached files, is strictly prohibited and will b=
e considered a criminal offense. If you are not the intended recipient be a=
ware that any disclosure, copying, distribution or use of the contents of t=
his information, even if partially, including attached files, is strictly p=
rohibited, will be considered a criminal offense, so you must reply to the =
original sender to inform about this communication and delete it.
    >=20
    >=20
    >=20
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > ipv6@ietf.org
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------
   =20
    --=20
    Mark Andrews, ISC
    1 Seymour St., Dundas Valley, NSW 2117, Australia
    PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
   =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 Nov 15 03:02:06 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECA6127B52 for ; Wed, 15 Nov 2017 03:02:04 -0800 (PST)
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_H4=-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 51cj40DkCpUX for ; Wed, 15 Nov 2017 03:02:03 -0800 (PST)
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 3E6FF12711E for ; Wed, 15 Nov 2017 03:02:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5945; q=dns/txt; s=iport; t=1510743723; x=1511953323; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5YWnnlhtwgmiPVK9JtOtZpYoEvJPAO3ICzqCg5aZkbI=; b=AsJcb/LI8RFY/gfgK2lMR9NFUj8PyJj6ykKEVhbxH/CzIdQB2CDKqBgj XM7tlTdRDKiI2+LVdT9ALXafXv2Vtg64HAZiEKa8Dpnfgsa2o8i7KGxMH BKDxv1+tvHXYfPK7sqhO2dpSADNIzdgUscsLILo72UMiKO9Dn2wyjLoov I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAACdHQxa/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4ng3+KH48fgVeRN4VJghEKGAEKhRgCGoRuPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUfAgEDAQEhRQYLEAIBCAQKMQMCAgIlCxQRAgQOBYlAZBCnYIInixcBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYM0ggeBVYISC4J2iC0xgjIFijSYAwKVBJN?= =?us-ascii?q?ElgACERkBgTgBHziBdHoVSS0BgjaEX3eIYQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.44,398,1505779200";  d="scan'208,217";a="319033130"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 11:02:02 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id vAFB21qT022088 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2017 11:02:02 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 05:02:01 -0600
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; Wed, 15 Nov 2017 05:02:01 -0600
From: "Rajiv Asati (rajiva)" 
To: Philip Homburg 
CC: "ipv6@ietf.org" , "Andrew Yourtchenko (ayourtch)" 
Subject: Re: IPv4 traffic on "ietf-v6ONLY" 
Thread-Topic: IPv4 traffic on "ietf-v6ONLY" 
Thread-Index: AQHTXf83bm4aWWuTskuMVFltkxTomaMVRlRF
Date: Wed, 15 Nov 2017 11:02:01 +0000
Message-ID: <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com>
References:    ,
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_5655992F737A4223A91763CAD6DF7A1Dciscocom_"
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 11:02:05 -0000

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

DQpPZiBjb3Vyc2UsIGEgREhDUHY0IG9wdGlvbiBjb25mbGljdHMgd2l0aCB0aGUgZ29hbCBvZiBz
b21lIHBlb3BsZSB0byBoYXZlDQpubyBJUHY0IHJlbGF0ZWQgaW5mcmFzdHJ1Y3R1cmUgYXQgYWxs
Lg0KDQogUGVyaGFwcywgZGVmaW5lIGEgREhDUHY2IG9wdGlvbiB0byBjb252ZXkgdjYtb25seSwg
Zm9yIHdoaWNoIHRoZSBjbGllbnQgaW50ZXJwcmV0YXRpb24gc2hvdWxkIGJlIHRvIHN1cHByZXNz
IHY0Lg0KDQpBbHRob3VnaCB0aGlzIHdpbGwgYmUgYXQgdGhlIGNyb3NzIHJvYWQgd2l0aCBhbGxv
d2luZyBjbGllbnTigJlzIHdpc2hlcyB0byB1c2UgdjQgTEwgZm9yIHdoYXRldmVyIHVzZWxlc3Mv
dXNlZnVsIHRyYWZmaWMsIGl0IHdvdWxkIGJlIGEgcmVhc29uYWJsZSBkZXBsb3ltZW50IHBvbGlj
eSB0byBlbmZvcmNlLg0KDQpXZSBoYXZlIHRvIHJlbWVtYmVyIHRoYXQgYWxsb3dpbmcgdGhpcyB3
b3VsZCBjb250aW51ZSB0byBodXJ0IFdMQU4gKG5vdCB3aXJlZCBMQU4pIGZvciBvYnZpb3VzIHJl
YXNvbnMgLSByYWRpbyBiYW5kd2lkdGguDQoNCkR1cmluZyBvbmUgb2YgY2lzY29saXZlIGNvbmZl
cmVuY2VzLCBpIHJlY2FsbCBoYXZpbmcgb2JzZXJ2ZWQgbG90cyBvZiB1c2VsZXNzIHY0IHRyYWZm
aWMgKGUuZy4gZGlzY292ZXJ5KSBvbiBXTEFOLiAgQW5kcmV3IChjY2VkKSBtYXkgcmVtZW1iZXIg
bW9yZSBkZXRhaWxzLg0KDQpDaGVlcnMsDQpSYWppdg0KDQpPbiBOb3YgMTUsIDIwMTcsIGF0IDU6
NDggQU0sIFBoaWxpcCBIb21idXJnIDxwY2gtaXB2Ni1pZXRmLTRAdS0xLnBoaWNvaC5jb208bWFp
bHRvOnBjaC1pcHY2LWlldGYtNEB1LTEucGhpY29oLmNvbT4+IHdyb3RlOg0KDQpEb2VzIHRoYXQg
cmV0dXJuIHVzIHRvIHRoZSBxdWVzdGlvbiBvZiBob3cgdG8gdGVsbCBob3N0cyB0aGF0IElQdjQN
CmRvZXNudCBsaXZlIGhlcmUsIGFuZCB0byBzdG9wIHRyeWluZz8NCg0KVGhlIHNhZmVzdCBvcHRp
b24gdG8gZG8gdGhhdCBpcyBhIERIQ1B2NCBvcHRpb24gdGhhdCBzYXlzICdubyBJUHY0IHNlcnZp
Y2UNCmhlcmUsIGdvIGF3YXknLg0KDQpBbnkgbmV0d29yayB0aGF0IGhhcyBJUHY0IHByb2R1Y3Rp
b24gdHJhZmZpYyBhbHJlYWR5IGhhcyB0byBwcm90ZWN0IGFnYWluc3QNCnJvZ3VlIERIQ1B2NCBz
ZXJ2ZXJzLg0KDQpPZiBjb3Vyc2UsIGEgREhDUHY0IG9wdGlvbiBjb25mbGljdHMgd2l0aCB0aGUg
Z29hbCBvZiBzb21lIHBlb3BsZSB0byBoYXZlDQpubyBJUHY0IHJlbGF0ZWQgaW5mcmFzdHJ1Y3R1
cmUgYXQgYWxsLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGlu
ZyBsaXN0DQppcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KQWRtaW5pc3RyYXRp
dmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0K
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxmb250IGNv
bG9yPSIjMDAwMDAwIj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1
NSwgMjU1LCAwKTsiPk9mIGNvdXJzZSwgYSBESENQdjQgb3B0aW9uIGNvbmZsaWN0cyB3aXRoIHRo
ZSBnb2FsIG9mIHNvbWUgcGVvcGxlIHRvIGhhdmU8YnI+DQpubyBJUHY0IHJlbGF0ZWQgaW5mcmFz
dHJ1Y3R1cmUgYXQgYWxsLjwvc3Bhbj48L2ZvbnQ+PC9ibG9ja3F1b3RlPg0KPGJyPg0KPC9kaXY+
DQombmJzcDtQZXJoYXBzLCBkZWZpbmUgYSBESENQdjYgb3B0aW9uIHRvIGNvbnZleSB2Ni1vbmx5
LCBmb3Igd2hpY2ggdGhlIGNsaWVudCBpbnRlcnByZXRhdGlvbiBzaG91bGQgYmUgdG8gc3VwcHJl
c3MgdjQuJm5ic3A7PGJyPg0KPGJyPg0KQWx0aG91Z2ggdGhpcyB3aWxsIGJlIGF0IHRoZSBjcm9z
cyByb2FkIHdpdGggYWxsb3dpbmcgY2xpZW504oCZcyB3aXNoZXMgdG8gdXNlIHY0IExMIGZvciB3
aGF0ZXZlciB1c2VsZXNzL3VzZWZ1bCB0cmFmZmljLCBpdCB3b3VsZCBiZSBhIHJlYXNvbmFibGUg
ZGVwbG95bWVudCBwb2xpY3kgdG8gZW5mb3JjZS4mbmJzcDsNCjxkaXY+PGJyPg0KPC9kaXY+DQo8
ZGl2PldlIGhhdmUgdG8gcmVtZW1iZXIgdGhhdCBhbGxvd2luZyB0aGlzIHdvdWxkIGNvbnRpbnVl
IHRvIGh1cnQgV0xBTiAobm90IHdpcmVkIExBTikgZm9yIG9idmlvdXMgcmVhc29ucyAtIHJhZGlv
IGJhbmR3aWR0aC4mbmJzcDs8YnI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5EdXJpbmcgb25l
IG9mIGNpc2NvbGl2ZSBjb25mZXJlbmNlcywgaSByZWNhbGwgaGF2aW5nIG9ic2VydmVkIGxvdHMg
b2YgdXNlbGVzcyB2NCB0cmFmZmljIChlLmcuIGRpc2NvdmVyeSkgb24gV0xBTi4gJm5ic3A7QW5k
cmV3IChjY2VkKSBtYXkgcmVtZW1iZXIgbW9yZSBkZXRhaWxzLiZuYnNwOzwvZGl2Pg0KPGRpdj4N
CjxkaXY+PGJyPg0KPGRpdj5DaGVlcnMsDQo8ZGl2PlJhaml2ICZuYnNwOzwvZGl2Pg0KPC9kaXY+
DQo8ZGl2Pjxicj4NCk9uIE5vdiAxNSwgMjAxNywgYXQgNTo0OCBBTSwgUGhpbGlwIEhvbWJ1cmcg
Jmx0OzxhIGhyZWY9Im1haWx0bzpwY2gtaXB2Ni1pZXRmLTRAdS0xLnBoaWNvaC5jb20iPnBjaC1p
cHY2LWlldGYtNEB1LTEucGhpY29oLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0
ZSI+PHNwYW4+RG9lcyB0aGF0IHJldHVybiB1cyB0byB0aGUgcXVlc3Rpb24gb2YgaG93IHRvIHRl
bGwgaG9zdHMgdGhhdCBJUHY0PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxzcGFuPmRvZXNudCBsaXZlIGhlcmUsIGFuZCB0byBzdG9wIHRyeWluZz88
L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPlRoZSBz
YWZlc3Qgb3B0aW9uIHRvIGRvIHRoYXQgaXMgYSBESENQdjQgb3B0aW9uIHRoYXQgc2F5cyAnbm8g
SVB2NCBzZXJ2aWNlPC9zcGFuPjxicj4NCjxzcGFuPmhlcmUsIGdvIGF3YXknLjwvc3Bhbj48YnI+
DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+QW55IG5ldHdvcmsgdGhhdCBoYXMgSVB2NCBwcm9k
dWN0aW9uIHRyYWZmaWMgYWxyZWFkeSBoYXMgdG8gcHJvdGVjdCBhZ2FpbnN0PC9zcGFuPjxicj4N
CjxzcGFuPnJvZ3VlIERIQ1B2NCBzZXJ2ZXJzLiA8L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxi
cj4NCjxzcGFuPk9mIGNvdXJzZSwgYSBESENQdjQgb3B0aW9uIGNvbmZsaWN0cyB3aXRoIHRoZSBn
b2FsIG9mIHNvbWUgcGVvcGxlIHRvIGhhdmU8L3NwYW4+PGJyPg0KPHNwYW4+bm8gSVB2NCByZWxh
dGVkIGluZnJhc3RydWN0dXJlIGF0IGFsbC48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4N
CjxzcGFuPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxicj4NCjxzcGFuPklFVEYgSVB2NiB3b3JraW5nIGdy
b3VwIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJtYWlsdG86aXB2NkBp
ZXRmLm9yZyI+aXB2NkBpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+QWRtaW5pc3RyYXRp
dmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vaXB2NiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+
PC9zcGFuPjxicj4NCjxzcGFuPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_5655992F737A4223A91763CAD6DF7A1Dciscocom_--


From nobody Wed Nov 15 03:16:20 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA02124BE8 for ; Wed, 15 Nov 2017 03:16:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj2pNDDuSbq6 for ; Wed, 15 Nov 2017 03:16:17 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D512E1200FC for ; Wed, 15 Nov 2017 03:16:16 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAFBGEwS092184 for ; Wed, 15 Nov 2017 12:16:14 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B9F6B2037F6 for ; Wed, 15 Nov 2017 12:16:14 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A7179203769 for ; Wed, 15 Nov 2017 12:16:14 +0100 (CET)
Received: from [132.166.84.214] ([132.166.84.214]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAFBGDiv030130 for ; Wed, 15 Nov 2017 12:16:14 +0100
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:  
From: Alexandre Petrescu 
Message-ID: 
Date: Wed, 15 Nov 2017 12:16:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 11:16:19 -0000

Le 15/11/2017 à 03:44, Brian E Carpenter a écrit :
> On 15/11/2017 15:13, Alexandre Petrescu wrote:
>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
> 
> Also on the DNS64 network. But it is all one-way, you
> will notice. No replies as far as I can see.

Brian,

I looked at it for longer time.  I did spot some successful exchanges, 
i.e. replies too.

> Most of them
> are sourced from 169.254.*.*,

YEs, most of them.

> but there are some oddities such as
> 31.130.227.98	224.0.0.1	IGMPv2	42	Membership Query, general

YEs, but there is more.  There are also TCPs and https and 
re-transmissions.  I dont recollect precisely but there is surely more 
than LL.

> I have a couple of Wireshark capture files if anyone cares.

I think it's good to produce many now at IETF and analyze later, because 
no access to "ietf-v6ONLY" later.

Alex

> 
>     Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Wed Nov 15 03:20:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922C2124BE8 for ; Wed, 15 Nov 2017 03:20:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZwnsnY3aUq6 for ; Wed, 15 Nov 2017 03:20:12 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 771A612711E for ; Wed, 15 Nov 2017 03:20:12 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAFBKAxZ025500 for ; Wed, 15 Nov 2017 12:20:10 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CFD622037F6 for ; Wed, 15 Nov 2017 12:20:10 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C67682035EA for ; Wed, 15 Nov 2017 12:20:10 +0100 (CET)
Received: from [132.166.84.214] ([132.166.84.214]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAFBK9wN002079 for ; Wed, 15 Nov 2017 12:20:10 +0100
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:   
From: Alexandre Petrescu 
Message-ID: <2454c0ee-3c2b-a63a-8095-019e8bb589f3@gmail.com>
Date: Wed, 15 Nov 2017 12:20:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 11:20:14 -0000

Le 15/11/2017 à 03:59, Lee Howard a écrit :
> 
> 
> On 11/15/17, 10:44 AM, "ipv6 on behalf of Brian E Carpenter" 
> 
> wrote:
> 
>> On 15/11/2017 15:13, Alexandre Petrescu wrote:
>>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
>> 
>> Also on the DNS64 network. But it is all one-way, you will notice.
>> No replies as far as I can see. Most of them are sourced from
>> 169.254.*.*, but there are some oddities such as 31.130.227.98
>> 224.0.0.1	IGMPv2	42	Membership Query, general
> 
> 
> Does that return us to the question of how to tell hosts that IPv4
> doesn’t live here, and to stop trying?

I think the question is relevant.

On one hand, it's counterproductive to tell some computer to stop
sending, "protocol police" is making laugh.

On another hand, recent documents do have these kinds of semantics:
PIO-X, prefix-exclude option in DHCP, and others.

On the same vein, even for IPv6 there is need of such semantics: the
IPv6 DNS address in the RA gets installed on a Client forever.  And it's
that IPv6 Host that makes IPv6 noise on IPv4-only networks.

Alex

> 
> Lee
> 
>> 
>> I have a couple of Wireshark capture files if anyone cares.
>> 
>> Brian
>> 
>> --------------------------------------------------------------------
>>
>> 
IETF IPv6 working group mailing list
>> ipv6@ietf.org Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>>
>
>> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 


From nobody Wed Nov 15 03:21:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D771124205 for ; Wed, 15 Nov 2017 03:21:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAx0Q0cgxDuS for ; Wed, 15 Nov 2017 03:21:26 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA831200FC for ; Wed, 15 Nov 2017 03:21:26 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEvku-0000F7C; Wed, 15 Nov 2017 12:21:20 +0100
Message-Id: 
To: ipv6@ietf.org
Subject: Re: IPv4 traffic on "ietf-v6ONLY" 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
References:    ,  <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com> 
In-reply-to: Your message of "Wed, 15 Nov 2017 11:02:01 +0000 ." <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com> 
Date: Wed, 15 Nov 2017 12:21:19 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 11:21:27 -0000

>     Perhaps, define a DHCPv6 option to convey v6-only, for which
>     the client interpretation should be to suppress v4.  Although
>    this will be at the cross road with allowing client's wishes to
>    use v4 LL for whatever useless/useful traffic, it would be a
>    reasonable deployment policy to enforce.

The problem with a DHCPv6 option is that an IPv4-only network may not be
prepared to defend against rogue DHCPv6 servers.

So anyone who starts such a server can kick everybody else of the IPv4 network.

Great option for an overcrowded hotel or conference network.


From nobody Wed Nov 15 03:23:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F037A124BE8 for ; Wed, 15 Nov 2017 03:23:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ybs7MmDehFGh for ; Wed, 15 Nov 2017 03:23:23 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2B51200FC for ; Wed, 15 Nov 2017 03:23:23 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAFBNLvv025987 for ; Wed, 15 Nov 2017 12:23:21 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AA6B420374C for ; Wed, 15 Nov 2017 12:23:21 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A10F320370B for ; Wed, 15 Nov 2017 12:23:21 +0100 (CET)
Received: from [132.166.84.214] ([132.166.84.214]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAFBNKxu005368 for ; Wed, 15 Nov 2017 12:23:21 +0100
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:    
From: Alexandre Petrescu 
Message-ID: 
Date: Wed, 15 Nov 2017 12:23:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 11:23:26 -0000

Le 15/11/2017 à 04:08, Jen Linkova a écrit :
> On Wed, Nov 15, 2017 at 1:59 PM, Lee Howard  wrote:
>>>> There is much IPv4 traffic on the "ietf-v6ONLY" ESSID.
>>>
>>> Also on the DNS64 network. But it is all one-way, you
>>> will notice. No replies as far as I can see. Most of them
>>> are sourced from 169.254.*.*, but there are some oddities such as
>>> 31.130.227.98  224.0.0.1       IGMPv2  42      Membership Query, general
>>
>>
>> Does that return us to the question of how to tell hosts that IPv4 doesn’t
>> live here, and to stop trying?
> 
> I do not believe we should be doing this. How do you tell the hosts
> 'Ipv4[] does not live here, stop trying' and why would you
> be doing this when I can just get hosts talk to each other on link
> using IPv6 LLAs?

You could do that with DHCPv4: it has some mechanism to not respod to 
DHCPv4 Request, or to reduce the lifetime, or reply negatively altogether.

You could also invent an ICMPv4 message send by the Router to the 
IPv6-only Host that says: I only do IPv6.

But to avoid the IPv4 LL-addressed traffic I dont know.

Alex

> Or that...I don't know, DECNET, Appletalk or MPLS does not live here?
> 
> 
>>
>>>
>>> I have a couple of Wireshark capture files if anyone cares.
>>>
>>>    Brian
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> 
> 


From nobody Wed Nov 15 03:29:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E168124BE8 for ; Wed, 15 Nov 2017 03:29:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qmq6hYEEvhi for ; Wed, 15 Nov 2017 03:29:30 -0800 (PST)
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 637B11200FC for ; Wed, 15 Nov 2017 03:29:30 -0800 (PST)
Received: by mail-pf0-x22c.google.com with SMTP id a84so11916915pfl.0 for ; Wed, 15 Nov 2017 03:29:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=iqXI9HuoyAHptypKuCHBwDuZjBYkJ1xNsXdiKU+WXoY=; b=dEpdsO1lmsWs+N0C436GcmJLumxvYainf58KdBbYhII05pyfYuvdel04QzaHCgHGaj kZiqH+Pu0HElIaFIvkG1EvRyv0MhsiQ8fIwUUfDbz23gcjt6GHEZFAsbbpgFioukyZME UvRaOgbxlu8VKoNh6GwzRcIijqr+umWa6gLKJ/dXiBO49WrHRw7+urjdhYY458ghlA4N gBRLJnS9Z6CLSeaQsHSvGOFVwm+llVoIlNTQtTZEkhGAOju4ZRw9X83vYURVHPjIWsKB YqDgDnJLDeo1y4ju3LbZnzmotC4LRWROv3jp8qjB38Gll9COXxBI0EKmN1bS0D8qG0Ia Z9Iw==
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=iqXI9HuoyAHptypKuCHBwDuZjBYkJ1xNsXdiKU+WXoY=; b=i7SYdWc1BXRjDw0KSPcs1DaNeH3ZcwRFdmvMarYeoO6ZS9XWb3H6okZLjrUgeyaEiD YyWtMKvxxyDn1el1RDtOo+3X/6tnwRBQIGy4SgvrBswzs1EczLLH2vdj7ZXbE7/2c+EE TtAy6aAbRH93M/KyoJVqiQIgVeA13noeyt2c5J/pb7sxKH/76G9ta7O8A+PplGHvZ1Y2 rz4yxhTz+fN9w78mPHmweBP6JFzFQpEmRBr7K2VEfgMpc/Xf02t+XfFMi6suijpHw4nl ZrJdsb+e/gB8zAbhjo4CHg80eiws6fXGFgjQrzVTFDVadvsf0UPXZfG3Oj/9+pAQj3Yf buSQ==
X-Gm-Message-State: AJaThX52fLmfMMSsj3xo1Z1r6YAB0BdDjLFOadEwr1yyZBA9H8xRSDKv RVoYFl2pGaPlL+hW96yeK9+oww==
X-Google-Smtp-Source: AGs4zMasZXqEX/yXmFJ6LCdizol15tTtPseAu9QdFn/8/UU3le64fPwyXWAL6P59F2SR3yOvWSng1g==
X-Received: by 10.84.218.10 with SMTP id q10mr9094507pli.111.1510745369562; Wed, 15 Nov 2017 03:29:29 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x79sm45763004pfa.156.2017.11.15.03.29.27 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 03:29:28 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:    
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <0b565be0-e228-0879-ead5-3ba03e6d1c28@gmail.com>
Date: Thu, 16 Nov 2017 00:29:30 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 11:29:32 -0000

There's an L flag in draft-ietf-intarea-provisioning-domains
that says "DHCP(v4) on this network". So L=0 says "No DHCP(v4) on
this network".

    Brian
On 15/11/2017 23:47, Philip Homburg wrote:
>> Does that return us to the question of how to tell hosts that IPv4
>> doesnt live here, and to stop trying?
> 
> The safest option to do that is a DHCPv4 option that says 'no IPv4 service
> here, go away'.
> 
> Any network that has IPv4 production traffic already has to protect against
> rogue DHCPv4 servers. 
> 
> Of course, a DHCPv4 option conflicts with the goal of some people to have
> no IPv4 related infrastructure at all.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Wed Nov 15 03:31:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFBA126B6E for ; Wed, 15 Nov 2017 03:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 XZ7_BNmjXpiv for ; Wed, 15 Nov 2017 03:31:15 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE50D1200FC for ; Wed, 15 Nov 2017 03:31:14 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id g141so2307949wmg.2 for ; Wed, 15 Nov 2017 03:31:14 -0800 (PST)
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=z2FhKLR9uscdiReKL2nj0INiWTy4llaSqjYRhAGOuOE=; b=rqUAn1BN27xxiDsz3Sb3dqpw3zQUkXZWM+AcIFMfKlxJ0c9i3JMZFrYAGjsD73nOx+ k3N+cU2bS4uOvYYMko4DlIra0IOYhOMEDdxDlh74E4XdQT9uRvK7JXjWMyiupcWNwK9J vLBYZlsL1COG/rJi41DqJ/vLS/QfIwpzpZmq5Uu6y1NXeilGzP6xL/73RyxCdvJu0qSo XVgvG5vTnwuqPZ6qne8ryaOet4mF/jYs9FYEeKoofcag5PxMJ1iCInZ7ZkiyfYERWYYC 0A84A+mfIGs3rfmN35OQ3umAcn7R7Ie0vfv7yoZqkTJtsgGb/owaMMx/ypoBND+YdPwX 3Wfw==
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=z2FhKLR9uscdiReKL2nj0INiWTy4llaSqjYRhAGOuOE=; b=mPWD+YpA1IFbkd+c4lBX/01BrdveKIKZYFge+XyU7h+IIYTZyxVuCDsVMVJudtaaKm XVPbU+tgDyiqgsFWztoEcHJEBHxRwfVTD0DLvFbM952gElH8dKazIgb33BSIQzZ9SUyP 4OFbB5m4JaRrGxnalZuHMql9OzgiG7djo7p68wYVb5ne5gCnBeKcERAAsUqjWZdhAA0C 8Hz4JeJkDVGBRjGE6xI7oKqFt9UFsNGH+bK2UjlcNzEBwqjvS9KaYfMoRWW9JNNzW2Oy sItFPfQUie4TxNn671NNp2ol6rHsvZrZ522qkBUR84s3lSnhgDo30i7jIcRdjsp29yXV hKQw==
X-Gm-Message-State: AJaThX446fEE/2jfXhYLuMg8q1MI44zHr+mCNrsbvLe+mZ7X1akmW0Ib XplJjSyUqUuzPrsZrWH/XQrpfkot45p9gfw8yPQAQg==
X-Google-Smtp-Source: AGs4zMabU4X3WP1xmA8f8CfbQnlgmx9ebuYpnIQKa72WNgFbYemwjdBPj4gPOyQEtOkIyA0fxDxXp46WT9E2DknRLD4=
X-Received: by 10.28.191.80 with SMTP id p77mr12561392wmf.85.1510745472914; Wed, 15 Nov 2017 03:31:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.160.149 with HTTP; Wed, 15 Nov 2017 03:30:32 -0800 (PST)
In-Reply-To: <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com>
References:     <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com>
From: Warren Kumari 
Date: Wed, 15 Nov 2017 19:30:32 +0800
Message-ID: 
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: "Rajiv Asati (rajiva)" 
Cc: Philip Homburg ,  "Andrew Yourtchenko (ayourtch)" , "ipv6@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 11:31:16 -0000

On Wed, Nov 15, 2017 at 7:02 PM, Rajiv Asati (rajiva)  wr=
ote:
>
> Of course, a DHCPv4 option conflicts with the goal of some people to have
> no IPv4 related infrastructure at all.
>
>
>  Perhaps, define a DHCPv6 option to convey v6-only, for which the client
> interpretation should be to suppress v4.


Can someone remind me what problem we are trying to solve?
W

>
> Although this will be at the cross road with allowing client=E2=80=99s wi=
shes to use
> v4 LL for whatever useless/useful traffic, it would be a reasonable
> deployment policy to enforce.
>
> We have to remember that allowing this would continue to hurt WLAN (not
> wired LAN) for obvious reasons - radio bandwidth.
>
> During one of ciscolive conferences, i recall having observed lots of
> useless v4 traffic (e.g. discovery) on WLAN.  Andrew (cced) may remember
> more details.
>
> Cheers,
> Rajiv
>
> On Nov 15, 2017, at 5:48 AM, Philip Homburg 
> wrote:
>
> Does that return us to the question of how to tell hosts that IPv4
>
> doesnt live here, and to stop trying?
>
>
> The safest option to do that is a DHCPv4 option that says 'no IPv4 servic=
e
> here, go away'.
>
> Any network that has IPv4 production traffic already has to protect again=
st
> rogue DHCPv4 servers.
>
> Of course, a DHCPv4 option conflicts with the goal of some people to have
> no IPv4 related infrastructure at all.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



--=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 Wed Nov 15 03:33:03 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADEF124BE8 for ; Wed, 15 Nov 2017 03:33:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3jsJDsBbTVM for ; Wed, 15 Nov 2017 03:33:00 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC231200FC for ; Wed, 15 Nov 2017 03:32:59 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id x7so16838114pfa.1 for ; Wed, 15 Nov 2017 03:32:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JP2GG1Ma22sT2jyQDtGgOkfyiesB9p8uAEFrHW9olow=; b=XFXSgL/Mm35qxRl3TVGd+cWO/MfIohfGpHTGD2oUPwzHNsXQ7lhvT+uHfRdCV9l3nq ALNhdJI4TyMVy2+Dft65zJCk3FlE+NcxS9+P4sQdT4JxFHSDXfLv/4w/YPSouu50Xvxt iAt580KaO7PI6L6BkEa/qRc/1srx1lcbiVnHVFuFVOIb2sLqA3vpPBEYrescEit//KMZ 0P/GgAIliECiBfw3go/BiZAJJAaC8wxmFuEcUlWWOf3wQhZJ7T7kMDEKVdpi2kfhiQBq /XsVVwXSKDb9C1hncsMEiJhYRNizvvyqLIbMMPh4GN86FpRWmZLgBJvA5mn28OlAjOVR q0ug==
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=JP2GG1Ma22sT2jyQDtGgOkfyiesB9p8uAEFrHW9olow=; b=aW00IWkBIqLNfKkamIOvBo3VgZ5L8loejXdqVDM4l63H99KOH2KsCs+h/IfbLb3p7w hbpiQy8M8tUhp8CtodODY+rlK/ewiVSXuyNP7twQG1s5mUubizKTeoZm7u3PNGxd+pz7 0YNLUaW2oFQkr4EUnYAmQh2rEwXR4AxEOJ5MpDZTvEAxzTm4EWHYgrbZXMEszcAVpfce uBIn6FnFM0foNiYvG0k5bGf/wsfd7kiO1s3jIMWoOXlZAE/U2ZD9Ud0FVEM9GmojG2UO X2A/fcpZsGQhlxCKC/SvI5pdqKssRP+1h9aAMAwEBRP1K3NQnlcAsQcxL5LZ/MSEAqNb bCSw==
X-Gm-Message-State: AJaThX7sfgQl4R7zXcECgiDb6Sxi5yjUeKzX1JABrQ+oijfgVLag6VPn QF1jRhBZdEPZTV7J++xotB0fuw==
X-Google-Smtp-Source: AGs4zMbKeQAmuJrITmI9XFWuGnW6jflWOqMi+7KZmZAksdZAsVUYH1j3IV+fEUYu4xPtanwQjI6TxA==
X-Received: by 10.159.207.143 with SMTP id z15mr15204168plo.159.1510745579317;  Wed, 15 Nov 2017 03:32:59 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id s6sm34197715pgq.57.2017.11.15.03.32.56 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 03:32:58 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:     <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <232a0572-a804-fccf-7278-e70671a50df9@gmail.com>
Date: Thu, 16 Nov 2017 00:32:58 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 11:33:01 -0000

On 16/11/2017 00:21, Philip Homburg wrote:
>>     Perhaps, define a DHCPv6 option to convey v6-only, for which
>>     the client interpretation should be to suppress v4.  Although
>>    this will be at the cross road with allowing client's wishes to
>>    use v4 LL for whatever useless/useful traffic, it would be a
>>    reasonable deployment policy to enforce.
> 
> The problem with a DHCPv6 option is that an IPv4-only network may not be
> prepared to defend against rogue DHCPv6 servers.

A bigger problem is that not all networks/hosts support DHCPv6. It needs
to be an RA option if you want everybody to see it.

    Brian


From nobody Wed Nov 15 04:39:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77F5126D74 for ; Wed, 15 Nov 2017 04:39:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snSxmhFYBJia for ; Wed, 15 Nov 2017 04:39:48 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33EE120726 for ; Wed, 15 Nov 2017 04:39:47 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eEwyn-0000GWC; Wed, 15 Nov 2017 13:39:45 +0100
Message-Id: 
To: ipv6@ietf.org
Subject: Re: IPv4 traffic on "ietf-v6ONLY" 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
References:     <0b565be0-e228-0879-ead5-3ba03e6d1c28@gmail.com> 
In-reply-to: Your message of "Thu, 16 Nov 2017 00:29:30 +1300 ." <0b565be0-e228-0879-ead5-3ba03e6d1c28@gmail.com> 
Date: Wed, 15 Nov 2017 13:39:44 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 12:39:50 -0000

>There's an L flag in draft-ietf-intarea-provisioning-domains
>that says "DHCP(v4) on this network". So L=0 says "No DHCP(v4) on
>this network".

Maybe I'm reading the draft too strictly, but it seems that the L flag is used
to tell which provisioning domain DHCPv4 information belongs to. Not to tell
a host to avoid using DHCPv4 in the first place.

If it does have the intention to make hosts avoid DHCPv4 requests then it
has the same drawback as in sending a 'no IPv4' option in RA or DHCPv6:
in an IPv4-only network that can be used to prevent hosts from connecting to
the network.


From nobody Wed Nov 15 05:29:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516EC126DCA for ; Wed, 15 Nov 2017 05:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plGtLD53KX-i for ; Wed, 15 Nov 2017 05:29:46 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DF6124B17 for ; Wed, 15 Nov 2017 05:29:46 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAFDTi6q018535 for ; Wed, 15 Nov 2017 14:29:44 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7BF10203A89 for ; Wed, 15 Nov 2017 14:29:44 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 72037201D7B for ; Wed, 15 Nov 2017 14:29:44 +0100 (CET)
Received: from [132.166.84.19] ([132.166.84.19]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAFDTfwP026763 for ; Wed, 15 Nov 2017 14:29:43 +0100
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:     <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com> 
From: Alexandre Petrescu 
Message-ID: 
Date: Wed, 15 Nov 2017 14:29:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 13:29:48 -0000

Le 15/11/2017 à 12:30, Warren Kumari a écrit :
> On Wed, Nov 15, 2017 at 7:02 PM, Rajiv Asati (rajiva)  wrote:
>>
>> Of course, a DHCPv4 option conflicts with the goal of some people to have
>> no IPv4 related infrastructure at all.
>>
>>
>>   Perhaps, define a DHCPv6 option to convey v6-only, for which the client
>> interpretation should be to suppress v4.
> 
> 
> Can someone remind me what problem we are trying to solve?

To me, the problem comes mainly from the impossibility to say "IPv6-only".

It's not just a terminology problem.  There are bad side-effects of 
abusing the term "IPv6-only".  Some people claim that IPv6 is there 
already, because there are "IPv6-only" networks.  But there are no 
"IPv6-only" networks at all.  (except in some very rare cases that are 
not visible at IETF nor at mobile network operators.)

Another problem can be related to that wireless network efficiency (too 
many useless IPv4 packets on the air of "ietf-v6ONLY").

The 'noise' problem is symmetric - valid in IPv4 too.  The person at the 
IETF ticketing system tells me I have to go meet them to manually remove 
the DNS Server IPv6 address that the "ietf" SSID has put on my Windows 
and that stays there forever.  That DNS IPv6 address makes noise on my 
corporate IPv4-only network.  I suppose the person does not want me to 
go there at each IETF for that manual operation.  That's a speculation 
of a problem too.  Maybe he has some magic means (a protocol?) that 
makes that the DNS IPv6 address has a lifetime, or so.

Alex

> W
> 
>>
>> Although this will be at the cross road with allowing client’s wishes to use
>> v4 LL for whatever useless/useful traffic, it would be a reasonable
>> deployment policy to enforce.
>>
>> We have to remember that allowing this would continue to hurt WLAN (not
>> wired LAN) for obvious reasons - radio bandwidth.
>>
>> During one of ciscolive conferences, i recall having observed lots of
>> useless v4 traffic (e.g. discovery) on WLAN.  Andrew (cced) may remember
>> more details.
>>
>> Cheers,
>> Rajiv
>>
>> On Nov 15, 2017, at 5:48 AM, Philip Homburg 
>> wrote:
>>
>> Does that return us to the question of how to tell hosts that IPv4
>>
>> doesnt live here, and to stop trying?
>>
>>
>> The safest option to do that is a DHCPv4 option that says 'no IPv4 service
>> here, go away'.
>>
>> Any network that has IPv4 production traffic already has to protect against
>> rogue DHCPv4 servers.
>>
>> Of course, a DHCPv4 option conflicts with the goal of some people to have
>> no IPv4 related infrastructure at all.
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> 
> 


From nobody Wed Nov 15 05:35:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014F7127137 for ; Wed, 15 Nov 2017 05:35:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level: 
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inAmEgjUcPqJ for ; Wed, 15 Nov 2017 05:35:33 -0800 (PST)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5A2124B17 for ; Wed, 15 Nov 2017 05:35:33 -0800 (PST)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id B5C74A0E6A; Wed, 15 Nov 2017 14:35:31 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 8BD461C0075; Wed, 15 Nov 2017 14:35:31 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 14:35:31 +0100
From: 
To: Jen Linkova , Ole Troan 
CC: 6man WG , Mark Andrews 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTXWdFi4OqdfTJ20KXt2XmNGUMBaMUf56AgAAh5QCAABAMAIAAvzQQ
Date: Wed, 15 Nov 2017 13:35:30 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>  
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.2]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 13:35:36 -0000

SGkgSmVuLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1N
ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNA
aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmVuIExpbmtvdmENCj4gRW52b3nDqcKgOiBtZXJjcmVk
aSAxNSBub3ZlbWJyZSAyMDE3IDA0OjA1DQo+IMOAwqA6IE9sZSBUcm9hbg0KPiBDY8KgOiA2bWFu
IFdHOyBNYXJrIEFuZHJld3MNCj4gT2JqZXTCoDogUmU6IElQdjYgb25seSBob3N0IE5BVDY0IHJl
cXVpcmVtZW50cz8NCj4gDQo+IE9uIFdlZCwgTm92IDE1LCAyMDE3IGF0IDE6MDcgUE0sIE9sZSBU
cm9hbiA8b3Ryb2FuQGVtcGxveWVlcy5vcmc+IHdyb3RlOg0KPiA+IElmIEkgbWF5IHRyeSB0byBz
dWdnZXN0IGEgc29sdXRpb24gYmFzZWQgb24gd2hhdCB5b3UgYXJlIHNheWluZzoNCj4gPg0KPiA+
IC0gUmVtb3ZlIChleHRlcm5hbCkgRE5TNjQgZnJvbSB0aGUgc29sdXRpb24NCj4gPiAtIFJlcGxh
Y2UgTkFUNjQgcHJlZml4IGRpc2NvdmVyeSB3aXRoIHNvbWUgc29ydCBvZiBsb2NhbCBjb25maWd1
cmF0aW9uLg0KPiBlLmcuIHB1dCBpdCBpbiBESENQIG9yIFJBDQo+ID4NCj4gPiBXaGljaCBoYXMg
dGhlIGltcGxpY2F0aW9ucyB0aGF0Og0KPiA+ICAtIGhvc3QgbGVhcm5zIE5BVDY0IHByZWZpeCB2
aWEgUkEvREhDUA0KPiA+ICAtIGhvc3QgaXMgZnJlZSB0byB1c2Ugd2hhdGV2ZXIgRE5TIHJlY3Vy
c2l2ZSByZXNvbHZlcnMgKGluc3RlYWQgb2YgdGhlDQo+IG11c3QgYmUgbG9jYWwgKGFuZCBvbiBj
b3JyZWN0IGludGVyZmFjZSB3aGVyZSB0aGUgTkFUNjQgaXMpIHJlc29sdmVyDQo+ID4gIC0gaG9z
dCBzeW50aGVzaXNlcyBhZGRyZXNzZXMgaXRzZWxmLiBBbmQgZG9lcyB2YWxpZGF0aW9uIGJlZm9y
ZQ0KPiBzeW50aGVzaXNpbmcgKGlmIHRoYXQncyByZXF1aXJlZCkuDQo+ID4NCj4gPiBJcyB0aGlz
IHRoZSBzb2x1dGlvbiB5b3Ugd291bGQgYmUgbG9va2luZyBmb3I/DQo+ID4NCj4gPiBBbmQgeWVz
LCB5b3UgbmVlZCBob3N0IGNoYW5nZXMuIEJ1dCB3ZSBuZWVkIHRoYXQgYW55d2F5Lg0KPiANCj4g
TkFUNjQgaXMgYSBiYW5kIGFpZCwgYSB0YWN0aWNhbCBzb2x1dGlvbiB0byBkZWFsIHdpdGggSVB2
NC1vbmx5IGhvc3N0DQo+IHdoaWxlIHdlIGFyZSB3YWl0aW5nIGZvciB0aGVtIHRvIGRpZS4gUmVx
dWlyaW5nICptYW5kYXRvcnkqIGNoYW5nZXMgb24NCj4gbWFqb3JpdHkgb2YgZGV2aWNlcyB3aGlj
aCBhcmUgd29ya2luZyBvbiBOQVQ2NCBuZXR3b3JrcyBqdXN0IGZpbmUNCj4gY3VycmVudGx5IHRv
IHNvbHZlIHByb2JsZW1zIGZvciB0aG9zZSB3aG8gZWl0aGVyIGEpIHNpZ24gdGhlaXIgem9uZXMN
Cj4gYnV0IGRvIG5vdCBlbmFibGUgSXB2NiBiKWRvaW5nIHNvbWUgc21hcnQgdGhpbmdzIGluIHRo
ZWlyIGhvc3QNCj4gcmVzb2x2ZXJzIGxvb2tzIGxpa2UgYW4gb3ZlcmtpbGwgdG8gbWUuLg0KPiAN
Cj4gSU1ITyB0aGUgb3B0aW1hbCBzb2x1dGlvbiBpczoNCj4gLSB0aGUgbmV0d29yayBTSE9VTEQg
cHJvdmlkZSBhIGhvc3Qgd2l0aCBOQVQ2NCBwcmVmaXggaW5mb3JtYXRpb24gaW4NCj4gUkEgKEkg
ZG8gbm90IGJlbGlldmUgdGhhdCBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSBkdXBsaWNhdGVkIGlu
IERIQ1ANCj4gYXQgYWxsKTsNCg0KW01lZF0gUGxlYXNlIGNoZWNrOiBodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvcmZjNzA1MSNzZWN0aW9uLTUuNy4zIA0KDQpUaGluZ3MgbWF5IGdldCBjb21w
bGV4IGlmIG11bHRpcGxlIE5TUHMgYXJlIHVzZWQgZm9yIGxvYWQtYmFsYW5jaW5nIG9yIGlmIGRl
c3RpbmF0aW9uIGJhc2VkIE5BVDY0cyBhcmUgZGVwbG95ZWQuIEEgbGlzdCBvZiBpc3N1ZXMgaXMg
ZWxhYm9yYXRlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIyNSNzZWN0aW9u
LTMuMSANCg0KPiAtIGFuIGFwcGxpY2F0aW9uIE1BWSB1c2UgdGhhdCBpbmZvcm1hdGlvbiB0byBk
byBBQUFBIHN5bnRoZXRpY3MNCj4gKHZhbGlkYXRpbmcgcmVzb2x2ZXJzIFNIT1VMRCBkbyB0aGF0
KS4NCj4gLSBuZXR3b3JrIHN0aWxsIHByb3ZpZGVzIEROUzY0IHNlcnZlcnMgdG8gaG9zdHMgc28g
YWxsIHVuc29waGlzdGljYXRlZA0KPiBob3N0cyAobWFqb3JpdHkgb2YgZGV2aWNlcyBmYWxscyBp
bnRvIHRoYXQgY2F0ZWdvcnkpIGNvbnRpbnVlIHRvIHVzZQ0KPiBuZXR3b3JrLXByb3ZpZGVkIHJl
c29sdmVycy4NCj4gDQo+IA0KPiA+DQo+ID4+IE9uIDE1IE5vdiAyMDE3LCBhdCAwODowNiwgTWFy
ayBBbmRyZXdzIDxtYXJrYUBpc2Mub3JnPiB3cm90ZToNCj4gPj4NCj4gPj4NCj4gPj4+IE9uIDE1
IE5vdiAyMDE3LCBhdCAzOjQwIGFtLCBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem9AZ29vZ2xlLmNv
bT4NCj4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gT24gVHVlLCBOb3YgMTQsIDIwMTcgYXQgNjo0NiBB
TSwgTWFyayBBbmRyZXdzIDxtYXJrYUBpc2Mub3JnPiB3cm90ZToNCj4gPj4+IElzIHRoZXJlIGFu
eSByZWFzb24gdG8gcnVuIEROUzY0IGF0IGFsbCB0aGVzZSBkYXlzPyAgaXB2NG9ubHkuYXJwYSBj
YW4NCj4gYmUgYSBwcmVjb25maWd1cmVkDQo+ID4+PiB6b25lIHdoaWNoIGFsbG93cyBDTEFUIHRv
IGdldCBpdHMgbWFwcGluZy4gIEFsbCB0aGUgcGhvbmVzIGhhdmUgQ0xBVA0KPiBzdXBwb3J0Lg0K
PiA+Pj4NCj4gPj4+IFRoYXQncyBhbiBpbnRlcmVzdGluZyBpZGVhLiBJdCB3b3VsZCB3b3JrIGlu
IHRoZW9yeSwgYnV0IHN1Y2ggYQ0KPiBuZXR3b3JrIHdvdWxkIGNvbXBsZXRlbHkgYnJlYWsgZGV2
aWNlcyB0aGF0IGRvbid0IHN1cHBvcnQgNDY0eGxhdC4gVGhhdA0KPiBnaXZlcyB1cCBvbmUgb2Yg
dGhlIG1ham9yIGFkdmFudGFnZXMgb2YgTkFUNjQvRE5TNjQsIHdoaWNoIGlzIHRoYXQgaXQncyBh
DQo+IDkwJSBzb2x1dGlvbiBldmVuIGp1c3QgYnkgaXRzZWxmIC0geWVzLCBJUHY0LW9ubHkgYXBw
bGljYXRpb25zIGFuZCBhZGRyZXNzDQo+IGxpdGVyYWxzIGV4aXN0LCBidXQgbW9zdCBzaW1wbGUg
Y2xpZW50L3NlcnZlciBhcHBsaWNhdGlvbnMgSnVzdCBXb3JrDQo+IGJlaGluZCBpdC4NCj4gPj4N
Cj4gPj4gQW5kIHRoYXQgOTAlIOKAnHNvbHV0aW9u4oCdIGhhcyBsb3RzIG9mIGRvd24gc2lkZXMu
ICBJdCBiYXNpY2FsbHkgcmVxdWlyZXMNCj4gRVZFUlkgRE5TIFZBTElEQVRPUiBPTg0KPiA+PiBU
SEUgUExBTkVUIFRPIFNVUFBPUlQgRE5TNjQgSlVTVCBJTiBDQVNFIElUIElTIFVTRUQgQkVISU5E
IEEgRE5TNjQNCj4gU0VSVkVSLg0KPiA+Pg0KPiA+PiBETlM2NC9OQVQ2NCB3YXMgcHJlc2VudGVk
IGFzIE5PVCBSRVFVSVJJTkcgbm9kZSBjaGFuZ2VzIHdoZW4gZmlyc3QNCj4gbW9vdGVkLiAgSXQg
a2VlcHMgb24NCj4gPj4gcmVxdWlyaW5nIG1vcmUgYW5kIG1vcmUgaGlnaGx5IGludmFzaXZlIG5v
ZGUgY2hhbmdlcyB0byBzdXBwb3J0LiAgSXQNCj4gd2FzIGZyb20gdGhlIHZlcnkgYmVnaW5uaW5n
DQo+ID4+IGJhZCBlbmdpbmVlcmluZy4gICBUbyBnZXQgSVB2NCBhcyBhIHNlcnZpY2Ugc29tZSBu
b2RlIGNoYW5nZXMgYXJlDQo+IHJlcXVpcmVkLiAgTGV0cyBtYWtlIHN1cmUgdGhleQ0KPiA+PiBh
cmUgTUlOSU1BTCBvbmVzLg0KPiA+Pg0KPiA+PiBKdXN0IGZvciB0aGUgcmVjb3JkIEROU1NFQyB2
YWxpZGF0b3JzIG5lZWQgdG8gc2VuZCBCT1RIIENEPTAgYW5kIENEPTENCj4gcXVlcmllcyB0byBn
ZXQgYW5zd2Vycw0KPiA+PiB0aG91Z2ggYSB1cHN0cmVhbSBWQUxJREFUSU5HIHNlcnZlciB3aGlj
aCBpbmNsdWRlcyBhIFZBTElEQVRJTkcgRE5TNjQNCj4gc2VydmVyIGFzIENEPTAgYW5kDQo+ID4+
IENEPTEgYWRkcmVzcyBkaWZmZXJlbnQgRE5TU0VDIHRocmVhdHMuICBJIHRyaWVkIHZlcnkgaGFy
ZCB0byBwb2ludCB0aGF0DQo+IG91dCB3aGVuIFJGQyA2MTQ3IHdhcw0KPiA+PiBiZWluZyB3cml0
dGVuIGJ1dCB0aGUgd29ya2luZyBncm91cCBkZWNpZGUgdGhhdCBDRCBpbmRpY2F0ZWQgd2hldGhl
cg0KPiB0aGUgY2xpZW50IHdhcyB2YWxpZGF0aW5nIG9yDQo+ID4+IG5vdC4gIFRoZXJlIGlzIE5P
IFNVQ0ggSU5ESUNBVElPTiBpbiBhIEROUyBtZXNzYWdlLg0KPiA+Pg0KPiA+PiAgSWYgYSBxdWVy
eSBhcnJpdmVzIGF0IGEgdkROUzY0IGRldmljZSB3aXRoIHRoZSAiQ2hlY2tpbmcgRGlzYWJsZWQi
DQo+ID4+ICAgKENEKSBiaXQgc2V0LCBpdCBpcyBhbiBpbmRpY2F0aW9uIHRoYXQgdGhlIHF1ZXJ5
aW5nIGFnZW50IHdhbnRzIGFsbA0KPiA+PiAgIHRoZSB2YWxpZGF0aW9uIGRhdGEgc28gaXQgY2Fu
IGRvIGNoZWNraW5nIGl0c2VsZi4gIEJ5IGxvY2FsIHBvbGljeSwNCj4gPj4gICB2RE5TNjQgY291
bGQgc3RpbGwgdmFsaWRhdGUsIGJ1dCBpdCBtdXN0IHJldHVybiBhbGwgZGF0YSB0byB0aGUNCj4g
Pj4gICBxdWVyeWluZyBhZ2VudCBhbnl3YXkuDQo+ID4+DQo+ID4+IENEPTAgcXVlcmllcyBjYXVz
ZXMgdGhlIHVwc3RyZWFtIHZhbGlkYXRpbmcgc2VydmVycyB0byByZWplY3QgaW5jb21pbmcNCj4g
c3Bvb2ZlZCBhbnN3ZXJzDQo+ID4+IG9yIHN0YWxlIGFuc3dlcnMgKHRoaXMgaXMgYSBjb21tb24g
b3BlcmF0aW9uYWwgcHJvYmxlbSkuDQo+ID4+DQo+ID4+IENEPTEgcXVlcmllcyBhbGxvdyB0aGUg
dmFsaWRhdGlvbiB0byBzdWNjZWVkIHdoZW4gdGhlIHVwc3RyZWFtDQo+IHZhbGlkYXRvciBoYXMg
YSBiYWQgdHJ1c3QNCj4gPj4gYW5jaG9yIG9yIGEgYmFkIGNsb2NrIHdoaWNoIGlzIHJlamVjdGlu
ZyBsZWdpdGltYXRlIGFuc3dlcnMuDQo+ID4+DQo+ID4+IEEgdmFsaWRhdGluZyBjbGllbnQgY2Fu
4oCZdCBqdXN0IHNlbmQgQ0Q9MSBxdWVyaWVzIGFzIHRoZSB1cHN0cmVhbQ0KPiB2YWxpZGF0b3Ig
ZG9lc27igJl0IGtpY2sgaW4uDQo+ID4+IFRoZSB1cHN0cmVhbSB2YWxpZGF0b3IgY2FuIGxvY2sg
b250byBhIHN0YWxlIGFuc3dlciBzb3VyY2UuICBJdCBuZWVkcw0KPiB0byBzZW5kIENEPTAgcXVl
cmllcw0KPiA+PiBvbiB2YWxpZGF0aW9uIGZhaWx1cmUgdG8gZm9yY2UgdGhlIHVwc3RyZWFtIHZh
bGlkYXRvciB0byB0cnkgbXVsdGlwbGUNCj4gc291cmNlcy4NCj4gPj4NCj4gPj4gQSB2YWxpZGF0
aW5nIGNsaWVudCBjYW7igJl0IGp1c3Qgc2VuZCBDRD0wLiAgSXQgbmVlZHMgdG8gc2VuZCBDRD0x
IG9uDQo+IFNFUlZGQUlMIGluIGNhc2UgdGhlDQo+ID4+IHVwc3RyZWFtIHZhbGlkYXRvciBoYXMg
YSBiYWQgdHJ1c3QgYW5jaG9yIChsaWtlbHkgd2l0aCB0aGUgdXBjb21pbmcNCj4gcm9vdCBLU0sg
cm9sbCkgb3IgaGFzDQo+ID4+IGEgYmFkIGNsb2NrICh0aGVzZSB1c3VhbGx5IGdldCBmaXhlZCBm
YXN0KS4NCj4gPj4NCj4gPj4gTm93IHRvIGdldCBhIGFuc3dlciBmcm9tIGEgc2lnbmVkIHpvbmUg
d2l0aCBzZXJ2ZXJzIHdpdGggc3RhbGUgYW5zd2Vycw0KPiBhIHZhbGlkYXRpaW5nIEROUzY0IGNs
aWVudA0KPiA+PiBuZWVkcyB0byBzZW5kOg0KPiA+Pg0KPiA+PiBhKSBzZW5kIENEPTEgYW5kIHZh
bGlkYXRpb24gZmFpbHVyZSBzZW5kIENEPTAgdGhlbiBvbiBBQUFBIHZhbGlkYXRpb24NCj4gZmFp
bHVyZSBzZW5kIENEPTEgYW5kDQo+ID4+ICAgIGhvcGUgdGhlIFRUTCB3YXMgbm90IDAgYW5kIHRo
YXQgaXMgbm90IGNhY2hhYmxlIGFuZCB0aGVyZSBpcyBubw0KPiBhc3N1cmFuY2UgdGhhdCB5b3Ug
d29u4oCZdCBnZXQNCj4gPj4gICAgYSBhbnN3ZXIgZnJvbSBhIHN0YWxlIHNvdXJjZS4NCj4gPj4N
Cj4gPj4gICAgICAgb3INCj4gPj4NCj4gPj4gYikgc2VuZCBDRD0wIGFuZCBvbiB2YWxpZGF0aW9u
IGZhaWx1cmUgb2YgdGhlIEFBQUEgc2VuZCBDRD0xIGFuZCBob3BlDQo+IHRoZSBUVEwgd2FzIG5v
dCAwIGFzDQo+ID4+ICAgIHRoYXQgaXMgbm90IGNhY2hhYmxlIGFuZCB0aGVyZSBpcyBubyBhc3N1
cmFuY2UgdGhhdCB5b3Ugd29u4oCZdCBnZXQgYQ0KPiBhbnN3ZXIgZnJvbSBhIHN0YWxlIHNvdXJj
ZS4NCj4gPj4NCj4gPj4gVFRMPTAgYW5zd2VycyBleGlzdC4NCj4gPj4NCj4gPj4gTm90ZSBub25l
IG9mIHRoaXMgaXMgZG9jdW1lbnRlZCBpbiBhIFJGQy4gIFlvdSBoYXZlIHRvIHVuZGVyc3RhbmQg
aG93DQo+IGJvdGggRE5TU0VDIGFuZCBETlM2NCB3b3JrIHRvDQo+ID4+IHJlYWxpc2UgdGhpcy4N
Cj4gPj4NCj4gPj4gSVBWNE9OTFkuQVJQQSBpcyBjdXJyZW50bHkgaGFzIGEgc2VjdXJlIGRlbGVn
YXRpb24gd2hpY2ggYnJlYWtzIHByZWZpeA0KPiBkaXNjb3ZlciBmb3IgRE5TIFZBTElEQVRPUlMu
DQo+ID4+IE5vdGUg4oCcYWTigJ0gaXMgc2V0IGluIHRoZSBmbGFncy4gIFllcywgSeKAmXZlIHN1
Ym1pdHRlZCBhIGVycmF0YS4gIFllcywNCj4gSeKAmXZlIG9wZW5lZCBhIHRpY2tldCB0byBnZXQg
aXQgZml4ZWQgYnV0DQo+ID4+IGJhc2VkIG9uIHBhc3QgZXhwZXJpZW5jZSB0aGF0IGNvdWxkIHRh
a2UgbW9udGhzIGlmIGl0IGhhcHBlbnMgYXQgYWxsLg0KPiBZb3Ugd2lsbCBub3RlIHRoYXQgdGhl
IHJlY3Vyc2l2ZQ0KPiA+PiBzZXJ2ZXIgaXMgcnVubmluZyBvbiB0aGUgbG9vcGJhY2sgaW50ZXJm
YWNlIHNvIGFsbCBETlMgYW5zd2VycyBhcmUNCj4gYmVpbmcgdmFsaWRhdGVkIGhlcmUuDQo+ID4+
DQo+ID4+IFtyb2NrOmJpbmQ5L2Jpbi9uYW1lZF0gbWFya2ElIGRpZyBJUFY0T05MWS5BUlBBDQo+
ID4+IDs7IEJBRENPT0tJRSwgcmV0cnlpbmcuDQo+ID4+DQo+ID4+IDsgPDw+PiBEaUcgOS4xMi4w
YjIraG90c3BvdCthZGQtcHJlZmV0Y2grbWFya2EgPDw+PiBJUFY0T05MWS5BUlBBDQo+ID4+IDs7
IGdsb2JhbCBvcHRpb25zOiArY21kDQo+ID4+IDs7IEdvdCBhbnN3ZXI6DQo+ID4+IDs7IC0+PkhF
QURFUjw8LSBvcGNvZGU6IFFVRVJZLCBzdGF0dXM6IE5PRVJST1IsIGlkOiA4NTA0DQo+ID4+IDs7
IGZsYWdzOiBxciByZCByYSBhZDsgUVVFUlk6IDEsIEFOU1dFUjogMiwgQVVUSE9SSVRZOiAwLCBB
RERJVElPTkFMOiAxDQo+ID4+DQo+ID4+IDs7IE9QVCBQU0VVRE9TRUNUSU9OOg0KPiA+PiA7IEVE
TlM6IHZlcnNpb246IDAsIGZsYWdzOjsgdWRwOiA0MDk2DQo+ID4+IDsgQ09PS0lFOiA3ZGJmOGJl
Yjc5YmU0N2EwOWViNTMxM2Q1YTBiNzc2ZjRmYWUzYWE2OTMxZDk1ODMgKGdvb2QpDQo+ID4+IDs7
IFFVRVNUSU9OIFNFQ1RJT046DQo+ID4+IDtJUFY0T05MWS5BUlBBLiAgICAgICAgICAgICAgICAg
ICAgICAgSU4gICAgICBBDQo+ID4+DQo+ID4+IDs7IEFOU1dFUiBTRUNUSU9OOg0KPiA+PiBpcHY0
b25seS5hcnBhLiAgICAgICAgICAgICAgICAyNjU3NCAgIElOICAgICAgQSAgICAgICAxOTIuMC4w
LjE3MQ0KPiA+PiBpcHY0b25seS5hcnBhLiAgICAgICAgICAgICAgICAyNjU3NCAgIElOICAgICAg
QSAgICAgICAxOTIuMC4wLjE3MA0KPiA+Pg0KPiA+PiA7OyBRdWVyeSB0aW1lOiAwIG1zZWMNCj4g
Pj4gOzsgU0VSVkVSOiAxMjcuMC4wLjEjNTMoMTI3LjAuMC4xKQ0KPiA+PiA7OyBXSEVOOiBXZWQg
Tm92IDE1IDEwOjA4OjMxIEFFRFQgMjAxNw0KPiA+PiA7OyBNU0cgU0laRSAgcmN2ZDogMTE1DQo+
ID4+DQo+ID4+IFtyb2NrOmJpbmQ5L2Jpbi9uYW1lZF0gbWFya2ElDQo+ID4+DQo+ID4+PiBJdCdz
IG5vdCB0cnVlIHRoYXQgYWxsIHBob25lcyBoYXZlIGNsYXQgc3VwcG9ydC4gTm90YWJseSwgQXBw
bGUgbm90DQo+IG9ubHkgZG9lcyBub3Qgc3VwcG9ydCBpdCBidXQgYXBwZWFycyBpZGVvbG9naWNh
bGx5IG9wcG9zZWQgdG8gaXQgb24gdGhlDQo+IGdyb3VuZHMgdGhhdCBpdCBkb2VzIG5vdCBoYXZl
IGEgZ29vZCBleGl0IHN0cmF0ZWd5IChiZWNhdXNlIGl0IG1ha2VzIGl0DQo+IHBvc3NpYmxlIHRv
IHJ1biBJUHY0LW9ubHkgYXBwcyBmb3JldmVyKS4NCj4gPj4NCj4gPj4NCj4gPj4gLS0NCj4gPj4g
TWFyayBBbmRyZXdzLCBJU0MNCj4gPj4gMSBTZXltb3VyIFN0LiwgRHVuZGFzIFZhbGxleSwgTlNX
IDIxMTcsIEF1c3RyYWxpYQ0KPiA+PiBQSE9ORTogKzYxIDIgOTg3MSA0NzQyICAgICAgICAgICAg
ICBJTlRFUk5FVDogbWFya2FAaXNjLm9yZw0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiBJ
RVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gPj4gaXB2NkBpZXRmLm9yZw0K
PiA+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9pcHY2DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPg0KPiA+IC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ID4gaXB2NkBp
ZXRmLm9yZw0KPiA+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+IA0KPiANCj4g
DQo+IC0tDQo+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCj4gDQo+IC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+
IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+
IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg==


From nobody Wed Nov 15 10:33:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2625D126C22 for ; Wed, 15 Nov 2017 10:33:26 -0800 (PST)
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 FgM1Q22xP9Un for ; Wed, 15 Nov 2017 10:33:24 -0800 (PST)
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 3E3D1124B17 for ; Wed, 15 Nov 2017 10:33:24 -0800 (PST)
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 EC1003AD28D; Wed, 15 Nov 2017 18:33:08 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id ABA0616008D; Wed, 15 Nov 2017 18:33:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 94604160087; Wed, 15 Nov 2017 18: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 17jmDsxPvHyi; Wed, 15 Nov 2017 18:33:08 +0000 (UTC)
Received: from [172.30.42.88] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 1C2AA16003F; Wed, 15 Nov 2017 18:33:08 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
From: Mark Andrews 
X-Mailer: iPhone Mail (15B150)
In-Reply-To: 
Date: Thu, 16 Nov 2017 05:33:05 +1100
Cc: ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E59E93D-03F0-4146-AD81-DA8AEE5255F6@isc.org>
References:     <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com>  
To: Alexandre Petrescu 
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 18:33:26 -0000

Do we provide a DHCPv6 server and set the O bit in the RA to provide the DNS=
 server addresses?  Manual config shouldn=E2=80=99t be required if we do tha=
t unless your OS is broken. I=E2=80=99m not on site to check.=20

--=20
Mark Andrews

> On 16 Nov 2017, at 00:29, Alexandre Petrescu  wrote:
>=20
>=20
>=20
>> Le 15/11/2017 =C3=A0 12:30, Warren Kumari a =C3=A9crit :
>>> On Wed, Nov 15, 2017 at 7:02 PM, Rajiv Asati (rajiva) =
 wrote:
>>>=20
>>> Of course, a DHCPv4 option conflicts with the goal of some people to hav=
e
>>> no IPv4 related infrastructure at all.
>>>=20
>>>=20
>>>  Perhaps, define a DHCPv6 option to convey v6-only, for which the client=

>>> interpretation should be to suppress v4.
>> Can someone remind me what problem we are trying to solve?
>=20
> To me, the problem comes mainly from the impossibility to say "IPv6-only".=

>=20
> It's not just a terminology problem.  There are bad side-effects of abusin=
g the term "IPv6-only".  Some people claim that IPv6 is there already, becau=
se there are "IPv6-only" networks.  But there are no "IPv6-only" networks at=
 all.  (except in some very rare cases that are not visible at IETF nor at m=
obile network operators.)
>=20
> Another problem can be related to that wireless network efficiency (too ma=
ny useless IPv4 packets on the air of "ietf-v6ONLY").
>=20
> The 'noise' problem is symmetric - valid in IPv4 too.  The person at the I=
ETF ticketing system tells me I have to go meet them to manually remove the D=
NS Server IPv6 address that the "ietf" SSID has put on my Windows and that s=
tays there forever.  That DNS IPv6 address makes noise on my corporate IPv4-=
only network.  I suppose the person does not want me to go there at each IET=
F for that manual operation.  That's a speculation of a problem too.  Maybe h=
e has some magic means (a protocol?) that makes that the DNS IPv6 address ha=
s a lifetime, or so.
>=20
> Alex
>=20
>> W
>>>=20
>>> Although this will be at the cross road with allowing client=E2=80=99s w=
ishes to use
>>> v4 LL for whatever useless/useful traffic, it would be a reasonable
>>> deployment policy to enforce.
>>>=20
>>> We have to remember that allowing this would continue to hurt WLAN (not
>>> wired LAN) for obvious reasons - radio bandwidth.
>>>=20
>>> During one of ciscolive conferences, i recall having observed lots of
>>> useless v4 traffic (e.g. discovery) on WLAN.  Andrew (cced) may remember=

>>> more details.
>>>=20
>>> Cheers,
>>> Rajiv
>>>=20
>>> On Nov 15, 2017, at 5:48 AM, Philip Homburg 
>>> wrote:
>>>=20
>>> Does that return us to the question of how to tell hosts that IPv4
>>>=20
>>> doesnt live here, and to stop trying?
>>>=20
>>>=20
>>> The safest option to do that is a DHCPv4 option that says 'no IPv4 servi=
ce
>>> here, go away'.
>>>=20
>>> Any network that has IPv4 production traffic already has to protect agai=
nst
>>> rogue DHCPv4 servers.
>>>=20
>>> Of course, a DHCPv4 option conflicts with the goal of some people to hav=
e
>>> no IPv4 related infrastructure at all.
>>>=20
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>=20
>>>=20
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Wed Nov 15 11:07:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E67B127005 for ; Wed, 15 Nov 2017 11:07:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 CGV-Mh9XYjkf for ; Wed, 15 Nov 2017 11:07:51 -0800 (PST)
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 1B26C126CBF for ; Wed, 15 Nov 2017 11:07:51 -0800 (PST)
Received: by mail-pg0-x234.google.com with SMTP id s11so13218918pgc.5 for ; Wed, 15 Nov 2017 11:07:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7E/lsS1RJ+qGLU3QegEeqNkjKTov+h8odEx3KXAzgwg=; b=ifddOkDTfZU14pKq5le7gRDkV3LHBMcfesAzdB/yt//iFpYNE1jmUew2Y5m2iy1Pub zsGtYUsuH8f1wHy/1ZamhS8kEt8SiCYf+T+tJAxbQAr5v1hlt8LpclhYdA6Bwob3qSMc zGGh8hsFRTdGOUWZnPefppQzzKDnUFfuuvCiH4yWouCaZcWwh/whWAmtJTDeIjcSiSg7 u7l6EGcH31oDEwrizFPLjZ1x3qyIgnBlEUvIizwnY5w6m+9rjuNk+qgRZ27xNxqV6rXe WQhH7uPB+JedYJy1agAZZ8npZNXO7Jh/oY+JYYrl34JtekTceR75T4N34r6MxIyqaxGa dedw==
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=7E/lsS1RJ+qGLU3QegEeqNkjKTov+h8odEx3KXAzgwg=; b=knEZUK8AyHohY75n6JwRr1J1tNroWLk/nNJ5OwHZDb98q4opW7Ke6WOh7MVFSG5umo TgrZ+c+Bh8aW4xld7BfBMtbSVaF2scODAI6dxG95x+ugIGJKWvXydcM/PGg3qmNFbCyW Sm91XbmJgqf2bHzsiZbJDK0iMmCFpSmDZsQ/XLu+6jfSJnvPthUpfiqF3vmI/J8ZdXo1 x4Gsa686KXN5xkrPGu27oyCXhib0dqW8VnbOM2P5+kT3iDfDYo5lNpixR6uCQtLNhCt9 l2VIbBhjp9iLknPkVljD0ZM6SiEU/BUYWHtf4zLJ8aE/RsP954Qf/jpT6mK/Yq7TXLbY fTBw==
X-Gm-Message-State: AJaThX6rGxzYpLEXuEdun4dMSOKWAaE5+xh3SPonypzVwqnUDs6Eno8Y L2Q1OB7yvAZQM+zFah0tp+6aTg==
X-Google-Smtp-Source: AGs4zMZ5py6Sg0BFXsj1D8cXafMyUVta0e6tAlz5dR7ij5RG+QFhyHzy+iV++kH53F9y9gWnC1jOfA==
X-Received: by 10.98.94.194 with SMTP id s185mr18838789pfb.56.1510772870453; Wed, 15 Nov 2017 11:07:50 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:788d:282:9de1:e7b9? ([2620:0:10e7:10:788d:282:9de1:e7b9]) by smtp.gmail.com with ESMTPSA id d15sm43402932pfj.163.2017.11.15.11.07.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 11:07:49 -0800 (PST)
From: james woodyatt 
Message-Id: <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0637C46E-B471-4114-B141-FFAA4C250913"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Wed, 15 Nov 2017 11:07:53 -0800
In-Reply-To: 
Cc: Ole Troan , 6man WG , Mark Andrews 
To: Jen Linkova 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>  
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 19:07:52 -0000

--Apple-Mail=_0637C46E-B471-4114-B141-FFAA4C250913
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 14, 2017, at 19:05, Jen Linkova  wrote:
>=20
> IMHO the optimal solution is:
> - the network SHOULD provide a host with NAT64 prefix information in =
RA;


Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye =
gods, this is the very last thing that should be jammed into RA =
messages.

>  (I do not believe that information needs to be duplicated in DHCP at =
all)

Totally agree about that.

--james woodyatt >




--Apple-Mail=_0637C46E-B471-4114-B141-FFAA4C250913
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 14, 2017, at 19:05, Jen Linkova <furry13@gmail.com> =
wrote:

IMHO the optimal =
solution is:
- the network SHOULD provide a host with =
NAT64 prefix information in RA;

Disagree. If the network =
has NAT64, then it should deploy RFC 7225. Ye gods, this is the very =
last thing that should be jammed into RA messages.

 (I do not believe that =
information needs to be duplicated in DHCP at all)

Totally agree about =
that.



--james woodyatt <jhw@google.com>







=

--Apple-Mail=_0637C46E-B471-4114-B141-FFAA4C250913--


From nobody Wed Nov 15 11:15:20 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDDA126D74 for ; Wed, 15 Nov 2017 11:15:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 RRdq_woHU_zh for ; Wed, 15 Nov 2017 11:15:16 -0800 (PST)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 470F712426E for ; Wed, 15 Nov 2017 11:15:16 -0800 (PST)
Received: by mail-pg0-x22b.google.com with SMTP id 70so6189123pgf.6 for ; Wed, 15 Nov 2017 11:15:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CA2UsfkaxA3S30+BcjCZBpf7rZzgjTynKvkpAn/GngI=; b=qb7fhepb2wp17iogmMWGX78SZ2WsBAUBzvoXMkmPNLaqW5EyInQYLjl1ZVe/6+ECuj 0dw3W6EHdZEnYWLQbqzXvm+a5LoGMnNzfhT0oLProYgGj0y/+aDckJ8dnPMQk1gKJ4m6 H1AYXAuwoJAeT2Hy7VjEELPUQT4XGJDbEw1lzALh1lPvCmZ8LKDQNXHXnVjlv1UJGluV UyMOI02n6pB6AkCKslRxjs16WT4PHnx56NuwmGpj/+OALT0Nsq2wZDhyCAysvo/Uh5vM W9LKzWjnTNo39H4wuxBRlds5XK7SHAruHy2QCr8WsdGA4HOu2k1+w8dXTIf0/Iaa5fV5 tosg==
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=CA2UsfkaxA3S30+BcjCZBpf7rZzgjTynKvkpAn/GngI=; b=uNPkYA1OeQCrqaixSEaHg7YNBLVVj/iQhSXGJ0kVmHz6CSXOUIqkpcEkmdlq1q3H9G UyCbXvDZ3oxxpfKnIuSioBPFR1S5Y8G5pY0pxhebagkvzsMZn7sUmzw3GJwBDpTgk27x dLTU4lTdZO5RyOxXOKBduBi72pEymt6a6PJ+Nj2jMGev9D5z8fqDtvybOFRqrHUU31u6 /Q8/Xq1rm7qN2tIrmgWt3OnMFl24ULhkGElrXCizA3mMomdP3F++i8uQfzNUWpmUfWRl d58Bl3cfXV81gJFt9eHYXkXDSQyukOPYdg8tr1WGwog31+OZpKMkDw0wy49AMYpkaqy4 FGVA==
X-Gm-Message-State: AJaThX76TFc5QGIw+Uin6uK7J8JDlXSztoN/ef/ZQAYmvOJdKTd3y6zt lTum2ZQ/OWYvbdrcSmmDlkd6We85WTc=
X-Google-Smtp-Source: AGs4zMaT+Xi7ned80seHmNtBhYtX3uyHxlgUuB6M+7PZCtj4lc75/phKBs354w/YjaDhSHdGhkYb/A==
X-Received: by 10.84.240.73 with SMTP id h9mr10457873plt.388.1510773315770; Wed, 15 Nov 2017 11:15:15 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:788d:282:9de1:e7b9? ([2620:0:10e7:10:788d:282:9de1:e7b9]) by smtp.gmail.com with ESMTPSA id c185sm44391937pfb.112.2017.11.15.11.15.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 11:15:14 -0800 (PST)
From: james woodyatt 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C0734A14-AB91-4CFC-851E-211F25558DFD"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
Date: Wed, 15 Nov 2017 11:15:18 -0800
In-Reply-To: 
Cc: ipv6@ietf.org
To: Philip Homburg 
References:    
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 19:15:18 -0000

--Apple-Mail=_C0734A14-AB91-4CFC-851E-211F25558DFD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 15, 2017, at 02:47, Philip Homburg =
 wrote:
>=20
> The safest option to do that is a DHCPv4 option that says 'no IPv4 =
service here, go away'.


Better: extend ARP with a signal that says, =E2=80=9CARP is not welcome =
here."

--james woodyatt >




--Apple-Mail=_C0734A14-AB91-4CFC-851E-211F25558DFD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 15, 2017, at 02:47, Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> wrote:

The safest option =
to do that is a DHCPv4 option that says 'no IPv4 =
service here, go away'.

Better: extend ARP with a signal that =
says, =E2=80=9CARP is not welcome here."



--james woodyatt <jhw@google.com>







=

--Apple-Mail=_C0734A14-AB91-4CFC-851E-211F25558DFD--


From nobody Wed Nov 15 13:47:19 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCF61250B8 for ; Wed, 15 Nov 2017 13:47:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgReOdD89rpZ for ; Wed, 15 Nov 2017 13:47:16 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536F01279E5 for ; Wed, 15 Nov 2017 13:47:16 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 A2FE62D4F99; Wed, 15 Nov 2017 21:47:15 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 19441200C2614F; Thu, 16 Nov 2017 05:47:15 +0800 (+08)
From: Ole Troan 
Message-Id: <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_CBFD9CD7-EF32-468A-BD54-12897E98A1A4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Thu, 16 Nov 2017 05:47:13 +0800
In-Reply-To: <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>
Cc: Jen Linkova , 6man WG , Mark Andrews 
To: james woodyatt 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 21:47:18 -0000

--Apple-Mail=_CBFD9CD7-EF32-468A-BD54-12897E98A1A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

James,

>> IMHO the optimal solution is:
>> - the network SHOULD provide a host with NAT64 prefix information in =
RA;
>=20
> Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye =
gods, this is the very last thing that should be jammed into RA =
messages.

Do we really want PCP in IPv6?
Is PCP successful in IPv4? Or does it even work well with A+P based =
solutions?

>=20
>>  (I do not believe that information needs to be duplicated in DHCP at =
all)
>=20
> Totally agree about that.

Appears this isn't as simple a problem as I thought. Let me read 7051 in =
it's excruciating detail.

Guess we're stuck.

Best regards,
Ole

--Apple-Mail=_CBFD9CD7-EF32-468A-BD54-12897E98A1A4
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+/bDNdvtpYqJhC33YFAloMteEACgkQvtpYqJhC
33ZwjRAAoVJOGX9cPGWw6aoUX4uU7S33WsROCQ4sc1kLdye6qB/X3/uXKkivV+X7
vRKo6rOOYzH0WGzPBcKrTpnTfbilC2rcKcoJMstB/B3QbdnW+luhEWXsCVXTuHhn
JZqmdibeC/cyFx6tkTg0QNn7UCWNmtX1Anbj28AavvWgdXDmv1v0G7rzuS2Dv45A
AuKIiTdUPHzn0dLYw7VTFsc6wgSSpwlzYBXcfY6fAUXM/Uo80gF+lkcg3xCqNMgB
WjPou4H0Yme2SYm+He9Tx3+H73fz3r1X0TnL/3QnsoySiYVD82q2/yiJiUUfMjWg
fKNzebGF5MEpd78TJZuk2y2udWyYjkAYibU2ecVWjHgZrZHUfGqOrXFIjxjVaAzm
04x6jyX20RCPRNsmoqbg6JfuRNVoREYz1D5fL8wsfWeW1Ruic+rZaDgVoNOXtVZ7
wz3mRsseE2v/VPubgY/vEFzxJVp1V4wrhobOtwe7DFV3sAZXLZwclDq0hlmPs8vE
E0Y4h+0T0nKsr1jN8JBECfbWxoennlx+2De9qpfwUMLGGNLjQTSCDT47QqDlaek5
fXqzLUR+zklaK+q5VqdRIKC43XC5dSjIUK8IepfZjvaUBzxELc+jf4ITqs2xUQeD
ya1PmFEmZi9zXT2RtEBS4Qr6UjRXOqLd6wvdBAa55bjOK/NnCNk=
=PK6N
-----END PGP SIGNATURE-----

--Apple-Mail=_CBFD9CD7-EF32-468A-BD54-12897E98A1A4--


From nobody Wed Nov 15 15:04:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A06128BC8 for ; Wed, 15 Nov 2017 15:04:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3AZEHWpwM061 for ; Wed, 15 Nov 2017 15:04:23 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B471F126E01 for ; Wed, 15 Nov 2017 15:04:23 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id d28so18119145pfe.2 for ; Wed, 15 Nov 2017 15:04:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=95eISPdPWciD4DLsANlV1gTONCxYOadbJi9kd9uWqqA=; b=JJMLlW9L+BfjG/C6uiTZlcb3DBRbWWylrDAbaVzGDOyAmtXw6Ft2GyQdoLaFnix9uu CSt6Vlqi6J8SdhhUWUk9sL3AzVKSiwVz4nopvMsVwF0PcANatG52iTEvEMWZftcHPtsn 4NxXqxTo1YrDkseJt8DOdNLd2nc+bvRdrdA/bMMSpqOtK7J8+JvWrMXQ4AqYGLwYP7+L b3PcJwhah7F+56f4UMJ4VyBdGolQxi/nMcJ7hwDdiCCe2xusEwy+v4lZVUfCZ+JL2Wth NTXsw9WPB+xqbRnykhArdqs41/+LIiQOR5nrV3wL75gxg/krxXl9bUX1zIudOT2FEt0k gY8w==
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=95eISPdPWciD4DLsANlV1gTONCxYOadbJi9kd9uWqqA=; b=S8XEkU4gCnqoSEoavaz1vqKpJAHeNVb0BXwfX1ipRn1artL6TqXjJ2oUjU81Zw4/X9 QSi88fbkz+s04Z8UCLplaCiW9+zKxf3P8NtXIqzNwZeSzQzp1+O181axbtrJ3OAyUIt6 dIIivWcDz1iwUFY8U2/EOtdFzIbIUtziE5c5ASAyuHjZygeSYCiswY0/szx9gKs+UpjA J5eJujHj2UJvaajwsyLjCin99+YKnFZh5F87nEw8Wg7KPCYGgl8hOE3zS8xbumShLfvK qYbysxNmJlsa3BMqRkweIXI5yTUE9kVp2L5bHs5Xe+133mWbm693YbVYzY/JeIFnom8E g7gw==
X-Gm-Message-State: AJaThX4VeynBtKD2ccgiK4YrL0NzgDSy+ejK4qMeGweRllAPH8afyP05 6u1z+DObd5/kmPgmth82FwF5kQ==
X-Google-Smtp-Source: AGs4zMYcO6uuyTTTOxnJlSBOa8gtpIGb0B3kBB6G3Zv8rhYfNTJGN8AHs2QQp3qTXZI1VwS3NdIEHg==
X-Received: by 10.99.67.195 with SMTP id q186mr16602301pga.186.1510787063056;  Wed, 15 Nov 2017 15:04:23 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:788d:282:9de1:e7b9? ([2620:0:10e7:10:788d:282:9de1:e7b9]) by smtp.gmail.com with ESMTPSA id n22sm41961962pfa.161.2017.11.15.15.04.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 15:04:22 -0800 (PST)
From: james woodyatt 
Message-Id: <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_086B4970-4283-4220-AD7C-9B41CFAEE1C3"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Wed, 15 Nov 2017 15:04:21 -0800
In-Reply-To: <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org>
Cc: Jen Linkova , 6man WG , Mark Andrews 
To: Ole Troan 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 23:04:26 -0000

--Apple-Mail=_086B4970-4283-4220-AD7C-9B41CFAEE1C3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 15, 2017, at 13:47, Ole Troan  wrote:
>=20
>>> IMHO the optimal solution is:
>>> - the network SHOULD provide a host with NAT64 prefix information in =
RA;
>>=20
>> Disagree. If the network has NAT64, then it should deploy RFC 7225. =
Ye gods, this is the very last thing that should be jammed into RA =
messages.
>=20
> Do we really want PCP in IPv6?

If we have any kind of NAT, then we need PCP. Using NAT without PCP =
considered harmful. That goes for NAT64 and NAT66.

> Is PCP successful in IPv4?

Well, there was this: =
>

> Or does it even work well with A+P based solutions?


Designed expressly for it.


--james woodyatt >




--Apple-Mail=_086B4970-4283-4220-AD7C-9B41CFAEE1C3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 15, 2017, at 13:47, Ole Troan <otroan@employees.org> wrote:

IMHO the optimal =
solution is:
- the network SHOULD provide a host with =
NAT64 prefix information in RA;

Disagree. If the network has NAT64, then it should deploy RFC =
7225. Ye gods, this is the very last thing that should be jammed into RA =
messages.

Do we really want =
PCP in IPv6?

If we have any kind of NAT, then we need PCP. =
Using NAT without PCP considered harmful. That goes for NAT64 and =
NAT66.

Is PCP successful in =
IPv4?



Designed expressly for it.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_086B4970-4283-4220-AD7C-9B41CFAEE1C3--


From nobody Wed Nov 15 15:24:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A12126D0C for ; Wed, 15 Nov 2017 15:24:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oeOe6m72WktY for ; Wed, 15 Nov 2017 15:24:53 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1F9120727 for ; Wed, 15 Nov 2017 15:24:53 -0800 (PST)
Received: from h.hanazo.no (dhcp-9240.meeting.ietf.org [31.133.146.64]) (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 269242D512B; Wed, 15 Nov 2017 23:24:52 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id AF0B4200C29B9B; Thu, 16 Nov 2017 07:24:52 +0800 (+08)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_DBAAB5F7-48F1-4D24-BA7F-A33BE1C17E3C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Thu, 16 Nov 2017 07:24:51 +0800
In-Reply-To: <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>
Cc: Jen Linkova , 6man WG , Mark Andrews 
To: james woodyatt 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 23:24:55 -0000

--Apple-Mail=_DBAAB5F7-48F1-4D24-BA7F-A33BE1C17E3C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

James,

>>=20
>>>> IMHO the optimal solution is:
>>>> - the network SHOULD provide a host with NAT64 prefix information =
in RA;
>>>=20
>>> Disagree. If the network has NAT64, then it should deploy RFC 7225. =
Ye gods, this is the very last thing that should be jammed into RA =
messages.
>>=20
>> Do we really want PCP in IPv6?
>=20
> If we have any kind of NAT, then we need PCP. Using NAT without PCP =
considered harmful. That goes for NAT64 and NAT66.

It's not for the lack of trying that IPv6 isn't adopted everywhere.
As IPv4 address sharing ratio's increase, say good bye to endpoint =
independent NATs, IP fragmentation...

But now I have to first implement a PCP client, discover the PCP server =
address, and then finally get the NAT64 prefix. ;-)

>> Is PCP successful in IPv4?
>=20
> Well, there was this: =

>=20
>> Or does it even work well with A+P based solutions?
>=20
> Designed expressly for it.

Ah, yes so it does.
Doesn't work well with address and port dependent filtering though.

Cheers,
Ole

--Apple-Mail=_DBAAB5F7-48F1-4D24-BA7F-A33BE1C17E3C
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+/bDNdvtpYqJhC33YFAloMzMMACgkQvtpYqJhC
33Yo2w/+N29wVL5pJlvozNvVIci8WqwoiplgnPdlmhXGhxfa6s2d32238eb8UEpF
3UfJEdkc6UE9FLQaiACejMYuxzlNcNKVWdTHs7Xvs6sGNeSbzor6OpGxzn/0h/7N
mC/mjikZ2LF7js0Y/l7HVJRpjJ+JYF9oJftduW4bo7OL5kRCctJGxymfqbKkOVVp
N9+AKwTkkbuVl3WlYZF86uuHoGk06jmhjJS4NNnKhk3LwUox2PJ/uJcV7xsXuBZm
VR3QZmp1XU85lgP1eAC8Ds+ldnB2O7RI0JgCbNWwiHYePP+WV1YgiDqKkmdemOCq
q6otiOxeeu7ljxIacLmTjZWVAlsYUfhIjujDWWkHiOexusxAc7LBJeiAfXaUth7M
F5tJyN4dFaFrK1u7vmSvuv2R5/ee2HEfiCzXdEVWe2kvEtgz57RgU/fazyOjtefe
GYA48LByUcS9UoOs4x52/fmRubem8U6+AXNLNBX2LFDPgseH3r1WCseMlMoQ0aOu
EpCbqxgy3e4BwWdU+KE9heBUv9t6rhGZE1b6g34ZcKbr7QayFvDX7uhzktkowfVZ
cGBGuoUpQbC7lyUAsrNPN/Eqj9gp7HqdQBHMObRFkSq0WhIN9hTYq4/pWUOVYNiu
8nlMFFRi/Fzez6QYIdlL4QLrc3WZeJHNsF6BC+O2eQNAQzZxyD8=
=oCyC
-----END PGP SIGNATURE-----

--Apple-Mail=_DBAAB5F7-48F1-4D24-BA7F-A33BE1C17E3C--


From nobody Wed Nov 15 15:36:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5E4127011 for ; Wed, 15 Nov 2017 15:36:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLqZMZMKXTml for ; Wed, 15 Nov 2017 15:36:37 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BF0124319 for ; Wed, 15 Nov 2017 15:36:37 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id n89so18164492pfk.11 for ; Wed, 15 Nov 2017 15:36:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2igBElYXDlvYEbjDzYtlo21EA319tulbZv6ke6heL4s=; b=vIJP+wGLBN8Pit+OifNZzIDDTJb5ZY8mxb14wE6+t+95vmpKzIW19gwi0ojJPUPVOK 91q0FvppcNG9XVEgOVKyZFJk5CgeV1X9R3exZqmsr605hBe6vfhyUcOMDT4PBTB87GUP ipSZmGPk+6QfErLW/5kvuYBkNZ1sixc6Mb8WejsnlMH2ITxMj8dc9RAjma0U1nr6kjXD AHKw5pJB9N4aYWMitKHbM1uTOjd9EkNk3vRL+5++K3AapcZ9gVlaPAlaXdDS+enYuWj9 jVWBnlgCG7NwUZEzEC0cJsClss1nqZQiwzGK9SNmjRP5/Fal3KJy24V+M6D5ALTUySR4 AxSw==
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=2igBElYXDlvYEbjDzYtlo21EA319tulbZv6ke6heL4s=; b=GCXosRuK26YOwt9DNBEoZZCc1tQegUdcnnSwnr7C7kdZ/8sIuuDz8Wyi+ben5zZ+Ml PGweGzyDtWvDWqZf85kk9GhljB03fkqNFnwM1feUi6aZ3QXnQsXhyCTqWHLRkU+kXnPB 43MnPr+40n+8W1dlk4P9/VO9C72xx1QMGlWvhFkj8jn1/sYbpyMEBlfB1JnMBO9BLhu0 oLe2KJqFBE0YvMIrGJ4HRpqRtXBQceZCLycUkPMkrHlC6qRwz/RLkAktASty1sJWG5rV VNzg8i8hjuzsVISlJXksmUb9/9DgpCWMo9dXYbx6hOJOMh6pp0KxswC5LP+xvHhGNMCG wk5A==
X-Gm-Message-State: AJaThX5nTo8CZUZTTjt/U1D/vINdUT6ZUL2mcTdWtZXjCrqRGNrEczY/ 1+gZ7kSXfadjTLamNQrpa4Y=
X-Google-Smtp-Source: AGs4zMapVC1U9tnMj/Tnk4t7edkGdkb311nNXG/MhkIPESUnTDDfInjZsB2VK+ju7WOogR3FSW0Y9Q==
X-Received: by 10.84.235.75 with SMTP id g11mr17595906plt.155.1510788996861; Wed, 15 Nov 2017 15:36:36 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id 69sm10450267pfj.28.2017.11.15.15.36.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 15:36:35 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: james woodyatt , Ole Troan 
Cc: 6man WG , Mark Andrews 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <6cb115a1-dec8-f31c-2865-7aca032bc771@gmail.com>
Date: Thu, 16 Nov 2017 12:36:37 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 23:36:39 -0000

On 16/11/2017 12:04, james woodyatt wrote:
> On Nov 15, 2017, at 13:47, Ole Troan  wrote:
>>
>>>> IMHO the optimal solution is:
>>>> - the network SHOULD provide a host with NAT64 prefix information in RA;
>>>
>>> Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye gods, this is the very last thing that should be jammed into RA messages.
>>
>> Do we really want PCP in IPv6?
> 
> If we have any kind of NAT, then we need PCP. Using NAT without PCP considered harmful. That goes for NAT64 and NAT66.

I have a more practical view. We can't assume that IPv6 hosts
grok DHCPv6, and we can't assume they grok PCP. We know that they
grok RAs, although of course they need an update to grok a new
option. So it seems to me that there isn't much doubt about the
need for an RA based solution.

    Brian

> 
>> Is PCP successful in IPv4?
> 
> Well, there was this: >
> 
>> Or does it even work well with A+P based solutions?
> 
> 
> Designed expressly for it.
> 
> 
> --james woodyatt >
> 
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Wed Nov 15 15:50:00 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11871127011 for ; Wed, 15 Nov 2017 15:49:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRzCZvb6ejik for ; Wed, 15 Nov 2017 15:49:56 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62840127078 for ; Wed, 15 Nov 2017 15:49:56 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id j28so15863569pfk.8 for ; Wed, 15 Nov 2017 15:49:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=va1oVQ2nVLk5cG1sBSrQExlNy432bj3EkOBpQCQwuh4=; b=eEH/+U/f1Z2w8UdyS34fB6z+Sl3lA9kmEMJT0XvbgLAwvivrGexhdrIKDzsQ9NAJJ3 MQObFXlJTc6CNZqYwFVG94dIAm3PdffV77LR4wwbMphFM5AJW4sIDO1Sepjh4vsIITia lwPFczOrMtZiwKsT+LEtBe8y2J5HXrXymBxH8/rpyIaelHtn+Ocu95VnlT8sYbmuOm3j BcPLO6cBR1v5F9MrZG4zHFKyw2pHzOF1EbwaHa1uhRtIhpvrgYA65DwVktwIukNtQQwb 44k2Bou59Bi6T2gP3FYdJS4mvOvaORWjuQt/sxVZ1DMyHXnvYNkfGg0r5pI3LxDzC8Z1 Z/Tg==
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=va1oVQ2nVLk5cG1sBSrQExlNy432bj3EkOBpQCQwuh4=; b=eQGsRpDGLRoZFZodFerXyktgFLXOAQAvbMRsGkOsjsc90ahX/HwF6yALbT89bqe/rn wz9w8S8KvuqC4NM4wwz0rmyonxOs0MZCTXXV9C9QQfd34F0wdeaycxEahTsEoX54xNse nbke2asK+jFQdCSo7lSZDpY/HDpwyazZrjDM/6jvBFZFyW34F8NCdqSj1emoV7/iafQj 0VjRAzHVz6cC2cnszQk3ZjNLh4sHdofWN1NirV1IYAZtoS64WtvOiSFxuofmHswoy6r/ 5RAp1FLJmJoQuRV1OHrlaGczFE6EYHSNKFDdxqm/nOuVybF7V/zGyKSVtlKWbfDunLMA TYdg==
X-Gm-Message-State: AJaThX77xojlaN+JNsQPYi/M+NVX2rgMeSX2QWuUxNyA0P2jjw20Yo5x HpY9UWcb7hx+ikOWyWqeGtsMfA==
X-Google-Smtp-Source: AGs4zMaTopHcFFGvaS0qVqcdChgxe+9/wxYjBwjXHV1KBgrymjQLEomFF1Na5eFn2MUNHhUakWJYlw==
X-Received: by 10.84.217.203 with SMTP id d11mr17799163plj.437.1510789795609;  Wed, 15 Nov 2017 15:49:55 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id 62sm42247381pfw.129.2017.11.15.15.49.54 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 15:49:54 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:     <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com>   <4E59E93D-03F0-4146-AD81-DA8AEE5255F6@isc.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 16 Nov 2017 12:49:57 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4E59E93D-03F0-4146-AD81-DA8AEE5255F6@isc.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 23:49:58 -0000

On 16/11/2017 07:33, Mark Andrews wrote:
> Do we provide a DHCPv6 server and set the O bit in the RA to provide th=
e DNS server addresses?  Manual config shouldn=E2=80=99t be required if w=
e do that unless your OS is broken. I=E2=80=99m not on site to check.=20

I believe that Windows 7 may be broken in this regard, although
I have never seen the issue Alexandre mentioned. Windows seems to
sometimes put things into the permanent config when they clearly
should be non-persistent; or it fails to clear stuff out when
switching from one SSID to another. I don't know if this has been=20
fixed in Windows >7, but it surely isn't a protocol issue.

    Brian
=20


From nobody Wed Nov 15 15:54:58 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28743127011 for ; Wed, 15 Nov 2017 15:54:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxJgsOHBXLGb for ; Wed, 15 Nov 2017 15:54:55 -0800 (PST)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD541270AB for ; Wed, 15 Nov 2017 15:54:55 -0800 (PST)
Received: by mail-pg0-x232.google.com with SMTP id s75so19202845pgs.0 for ; Wed, 15 Nov 2017 15:54:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NtVmwepmnGB7f6CwKT1WlvlFg6HMISoe9UnuqCwRP+w=; b=bf0A9Pl7yGpc++QnS35AdMg+kqSwUTmIH+9BO+C4pNKBrbHc4+DK+nWL7ojCAKfZ22 +WIM7k+iRIR8nhf8yOyPSfG2WaYiIQCyl3EQKPAjuoaaTXoH3D8ys4EtUMIkcy9SC7zx VKNu3BCg0r/LgM1Z83ODub47xts7G88pFE9qN1gy43zz3HiUg3FI1/W5Re3MkYpflE+7 Y2YERUnSWbLRRkRwHK2BG+rLLq/iFB3leeCnCMdxtAyxcO9yV9bViGWSqJYmV8Q+4Khw ep9Ri63Uk1EuVMNLoSjwjzvaoCXUmJgWAtbLRtWrUbQEb12Tn4faPSdQ7kGteJS3NOdr d5sg==
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=NtVmwepmnGB7f6CwKT1WlvlFg6HMISoe9UnuqCwRP+w=; b=p1e8F1TsTTg79Vx2nGlYiU/EvGpr3xev2SPJ742UHR9pacxahp6JLZSSQC57HwoQVa OUiB9qWPCMelriIrviqkwMEQORiNZyKewryg7t6e+u1cK+rEvsnMIk04+rt0wzCBb+BY fLmWnUVhTVUnMc0jO1yAQKT/o2p7rAetarvsgVsrWJ2Dx4SA9NZZxaf2gbGEFIhDzrIl aNZRE2ljEi3GCIB07MWMkedLeV0dLK+sYuahCFEelE5TZJ31pSMq1F6rm8b5AGAWN0CI yGdHLobZ/9cYVq1X0lGcM5xMzDTiCcSJGtGZOh5zMVA5Aq1QbY+O6DKGhsMD+N4nkVSj LO1g==
X-Gm-Message-State: AJaThX4MQPi3kA62gJukwggtKh3DYaYp04LzKSvTyeRp/z25/RwVDehr eYomws/UWb51ZscMJvICuNr42A==
X-Google-Smtp-Source: AGs4zMakfgb/z48NbcTAPW6RDLw22MxnU16bmo3BsuclMyVc7Z5YRSCalwccrc1mBoOGCCKWkjzjow==
X-Received: by 10.159.229.10 with SMTP id s10mr15246144plq.386.1510790094756;  Wed, 15 Nov 2017 15:54:54 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id p189sm35656448pfp.127.2017.11.15.15.54.53 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 15:54:53 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:     
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <72f42d56-2466-dfaa-59e9-ebb2264e8ca4@gmail.com>
Date: Thu, 16 Nov 2017 12:54:56 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 23:54:57 -0000

On 16/11/2017 08:15, james woodyatt wrote:
> On Nov 15, 2017, at 02:47, Philip Homburg  wrote:
>>
>> The safest option to do that is a DHCPv4 option that says 'no IPv4 ser=
vice here, go away'.
>=20
>=20
> Better: extend ARP with a signal that says, =E2=80=9CARP is not welcome=
 here."
=20
However, the IPv4 traffic seen on ietf-dns64 is negligible and harmless.
That is a practical indication that this problem probably isn't worth
solving.=20

I submit for example that sending a new "not welcome" response to
ARP requests would do more harm than good, since the legacy hosts
would probably react badly.

   Brian=20


From nobody Wed Nov 15 16:13:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508851293D8 for ; Wed, 15 Nov 2017 16:13:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ZtfDNiQuycUf for ; Wed, 15 Nov 2017 16:13:11 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354F8128E19 for ; Wed, 15 Nov 2017 16:13:11 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id t69so9246599pfg.4 for ; Wed, 15 Nov 2017 16:13:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8kX3BuEXm5OZvINTPKBCUDmHuz0vAPJlMe0ysFcTe/k=; b=P1DD4HecgsIzCwmd6c4qzy8F/xWeKVnkXlnhpY/WxydpgXqR/Zs72PfaXMbNYjTu6n nQaMz0/4grUV6zHBTziRA1dmWBKtT/yuNQoWV5shMl5oxYALPnaLMhyooH4krHBzOGVv 38cbxh1dvSyGoa8wblgsUOcISTo8VySfYjmfXf2bl1NHOE77H6vvaB+z+TyNRWk0RyMd bBGV7FbbjxfKWVNy4JuiXaJ9Dp6PkHx5FMJg+tGXFvFsYzzXdpmEzmmfmzPR+oG4DOsj pBfCdwqnIG4ZSctwPPKC2cEYP94/iDxx0ooaFoFMJIsJ0T1fly6yVZmDsEtjsvVRLImu Qgbw==
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=8kX3BuEXm5OZvINTPKBCUDmHuz0vAPJlMe0ysFcTe/k=; b=mukOfxuLigsec+zJn1hUfGu1pnD8jYiOQbCUQ2rvKUaz25KdoDqRqF08L1juCeqTdu nG2Ch1dNy43vwxVlxG+A+top7ZEqFXPIJotITQj/LV9YVgFI0IHUiVMnYIHUoQQ3K+hT vwL+aPpGyvg/8jneYPhYCgdnsBLAI0xmIigKN1msRxYCOJcryZyc3V6APdyM3X5gPQ7n 6gKgO3yUVI92/fkdOXMrC+he3eisQL3bvYnh9i+h+P5ErQXSDQ25X9kZ8MaKiAZPa4JT qeWs5+RGeHfvUSrHXPdsWnEu/Rs4t4VDWaqHrq5VsPG13AkDOC6quLEQlr0kipcbWSWh viMw==
X-Gm-Message-State: AJaThX4TOOvBZYu8iTrCO0Ar7EZGhaZLzFSlu85cA35CFWPNFCyT0EAh kyMJh4f1xsLkEA7oZ80FvZIZvqE0JVs=
X-Google-Smtp-Source: AGs4zMYSak7b2oDCgFRZq7HZOZNQQcO7LHEZDWPSnxWBEU983c0sv396HLbGuu6cGdPxUkWP4curzw==
X-Received: by 10.101.92.202 with SMTP id b10mr17678517pgt.164.1510791190401;  Wed, 15 Nov 2017 16:13:10 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:788d:282:9de1:e7b9? ([2620:0:10e7:10:788d:282:9de1:e7b9]) by smtp.gmail.com with ESMTPSA id i125sm1067057pfe.151.2017.11.15.16.13.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 16:13:09 -0800 (PST)
From: james woodyatt 
Message-Id: <022434F4-43DD-4455-90C2-C7774EF19B23@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_35D2485E-25A5-4BF2-97DC-FAE8D5BAD83A"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Wed, 15 Nov 2017 16:13:08 -0800
In-Reply-To: <6cb115a1-dec8-f31c-2865-7aca032bc771@gmail.com>
Cc: Ole Troan , 6man WG , Mark Andrews 
To: Brian E Carpenter 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com> <6cb115a1-dec8-f31c-2865-7aca032bc771@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 00:13:13 -0000

--Apple-Mail=_35D2485E-25A5-4BF2-97DC-FAE8D5BAD83A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Nov 15, 2017, at 15:36, Brian E Carpenter =
 wrote:
> On 16/11/2017 12:04, james woodyatt wrote:
>> On Nov 15, 2017, at 13:47, Ole Troan  wrote:
>>>=20
>>>>> IMHO the optimal solution is:
>>>>> - the network SHOULD provide a host with NAT64 prefix information =
in RA;
>>>>=20
>>>> Disagree. If the network has NAT64, then it should deploy RFC 7225. =
Ye gods, this is the very last thing that should be jammed into RA =
messages.
>>>=20
>>> Do we really want PCP in IPv6?
>>=20
>> If we have any kind of NAT, then we need PCP. Using NAT without PCP =
considered harmful. That goes for NAT64 and NAT66.
>=20
> I have a more practical view. We can't assume that IPv6 hosts
> grok DHCPv6, and we can't assume they grok PCP. We know that they
> grok RAs, although of course they need an update to grok a new
> option.

Simplifying... hosts need an update, and the question we have had on the =
table for four years now is what update to push. What if answers were =
something people wanted to read?

> So it seems to me that there isn't much doubt about the
> need for an RA based solution.

It seems to me that, of the various solutions analyzed by RFC 7051, that =
particular one comes with a raft of problems, which were the reasons we =
have RFC 7225 now.

	>


--james woodyatt >




--Apple-Mail=_35D2485E-25A5-4BF2-97DC-FAE8D5BAD83A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

On Nov 15, 2017, at 15:36, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 16/11/2017 =
12:04, james woodyatt wrote:
On Nov 15, 2017, at 13:47, Ole Troan <otroan@employees.org> wrote:

IMHO the optimal =
solution is:
- the network SHOULD provide a host with =
NAT64 prefix information in RA;

Disagree. If the network has NAT64, then it should deploy RFC =
7225. Ye gods, this is the very last thing that should be jammed into RA =
messages.

Do we really want =
PCP in IPv6?

If we have any =
kind of NAT, then we need PCP. Using NAT without PCP considered harmful. =
That goes for NAT64 and NAT66.

I=
 have a more practical view. We can't assume that IPv6 hosts
grok DHCPv6, and we can't assume they grok PCP. We know that =
they
grok RAs, although of course they need an update to =
grok a new
option.

Simplifying... hosts need an update, and the =
question we have had on the table for four years now is what update to =
push. What if answers were something people wanted to read?

So it seems to me that there isn't much doubt about the
need for an RA based solution.

It seems to me that, of the various solutions =
analyzed by RFC 7051, that particular one comes with a raft of problems, =
which were the reasons we have RFC 7225 now.





--james woodyatt <jhw@google.com>







=

--Apple-Mail=_35D2485E-25A5-4BF2-97DC-FAE8D5BAD83A--


From nobody Wed Nov 15 16:16:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1F8126557 for ; Wed, 15 Nov 2017 16:16:32 -0800 (PST)
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 8OMsmD6jGNTS for ; Wed, 15 Nov 2017 16:16:30 -0800 (PST)
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 A208B120721 for ; Wed, 15 Nov 2017 16:16:30 -0800 (PST)
Received: by mail-yw0-x22c.google.com with SMTP id a4so2925210ywh.3 for ; Wed, 15 Nov 2017 16:16:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c79r/aUOmSW2ilN8M9XYO4Ci1/SCbH/378Rq8PN+10Y=; b=D6VbunShdADzZSz8hLBBoD0Obf2J8mO4Tdyhagzo+DLG2dGuA1z+52n3Llsww6O8DZ L8ezjnExJqkWkjn7apm27+AUlkn19g6vGssoFAJnTVVv1PHfIQrWtkcl/SQt/59frdb4 Ddattthk5DqQiLMgbE/2bpDQT5337aRDwpgVIeRY7e2lTor9VPx2M4S9UWFdjoKhklmd 1g7GDfkKUfvBsbnDxxckt2/7GyzvmGxlUkBDNhn5FBQIscdcX1MDFLatjpkf/dAjshVK YE4EwV9dt830rJOiHtVAT8euQGdrP9fVMo1HhnU4XLTIEJ2BeZv5UND5dTTYF3SoIQly /6pQ==
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=c79r/aUOmSW2ilN8M9XYO4Ci1/SCbH/378Rq8PN+10Y=; b=rQ8GmyyeJXI88M+HMRo3k7IkLk2JWdwtwCaXq8B28jlBzYaQuzHQf+RXx4rL5uJBed 6X+lISD5vGLRdwBpQ5JSVFx+ny6JIUp4mGiKfdEPlEiFBrU/kwYohn07x0Tvlu0ta9qX Mgw7CEzpndCwdJAHsTaifTnzegrO4qCcRkl0FwPGWP7KXYHB65qV52vCAURAaCTl4uQG K5SMJ4aAfS7kFAcIHHcDVubuVlehlggfx2y04sCt53XD968TDo7QGdGyO6CRqlJrBiZe DopkEAIQj2wduCyXKm8P2rTau3QGrZMKavlWjgWCuz0Klkpm+G9hvaQ0NZ7l7b4w4gGS 08Kg==
X-Gm-Message-State: AJaThX4DxQr1Le2uQ9JFWNHS1BtprNByUwU/r2sqyQrIszh0B256TcpK m7t019dyNZvqF8M4TgOrcxT4n0WLEux6AuTc5GDEUw==
X-Google-Smtp-Source: AGs4zMYiptRg7D/NabMo4J7xwFt+nNIaVI4SbTG909nk/t8dd+LtoaCmVAWa5g1H6qrdolGf10rR3Sv64ut4Zwyzm9k=
X-Received: by 10.37.20.193 with SMTP id 184mr10593763ybu.400.1510791389862; Wed, 15 Nov 2017 16:16:29 -0800 (PST)
MIME-Version: 1.0
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com> <6cb115a1-dec8-f31c-2865-7aca032bc771@gmail.com> <022434F4-43DD-4455-90C2-C7774EF19B23@google.com>
In-Reply-To: <022434F4-43DD-4455-90C2-C7774EF19B23@google.com>
From: Ca By 
Date: Thu, 16 Nov 2017 00:16:18 +0000
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: james woodyatt 
Cc: 6man WG , Brian E Carpenter ,  Mark Andrews 
Content-Type: multipart/alternative; boundary="001a113e72b61f617f055e0e88e3"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 00:16:33 -0000

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

On Wed, Nov 15, 2017 at 4:13 PM james woodyatt  wrote:

> On Nov 15, 2017, at 15:36, Brian E Carpenter 
> wrote:
>
> On 16/11/2017 12:04, james woodyatt wrote:
>
> On Nov 15, 2017, at 13:47, Ole Troan  wrote:
>
>
> IMHO the optimal solution is:
> - the network SHOULD provide a host with NAT64 prefix information in RA;
>
>
> Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye
> gods, this is the very last thing that should be jammed into RA messages.
>
>
> Do we really want PCP in IPv6?
>
>
> If we have any kind of NAT, then we need PCP. Using NAT without PCP
> considered harmful. That goes for NAT64 and NAT66.
>
>
> I have a more practical view. We can't assume that IPv6 hosts
> grok DHCPv6, and we can't assume they grok PCP. We know that they
> grok RAs, although of course they need an update to grok a new
> option.
>
>
> Simplifying... hosts need an update, and the question we have had on the
> table for four years now is what update to push. What if answers were
> something people wanted to read?
>
> So it seems to me that there isn't much doubt about the
> need for an RA based solution.
>
>
> It seems to me that, of the various solutions analyzed by RFC 7051, that
> particular one comes with a raft of problems, which were the reasons we
> have RFC 7225 now.
>
> 
>
>
> --james woodyatt 
>
>
I may be missing the point, but we talking about updating host (5 year time
horizon) to solve the corresponding node not supporting ipv6?

Maybe we just need to cite this more and do nothing more

https://tools.ietf.org/html/bcp177

In short, to be on the internet you need to support ipv6.

What problem does this not solve ?



>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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



On Wed, Nov 15, 2017 =
at 4:13 PM james woodyatt <jhw@google.=
com> wrote:
On Nov 15, 2017, at 15:36, Brian E Carpenter <brian.e.carpente=
r@gmail.com> wrote:
On 16/11/2017 12:04, james woodyatt wrote=
:
On Nov 15, 2017, at 13:47, Ole Troan <otroan@employees.org=
> wrote:

=

IMHO the optimal solution is:
- the network SH=
OULD provide a host with NAT64 prefix information in RA;
Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye go=
ds, this is the very last thing that should be jammed into RA messages.
=


Do we really want PCP in IPv6?

If we h=
ave any kind of NAT, then we need PCP. Using NAT without PCP considered har=
mful. That goes for NAT64 and NAT66.

I have a more prac=
tical view. We can't assume that IPv6 hosts
grok DHCPv6, and we can&=
#39;t assume they grok PCP. We know that they
grok RAs, although of cour=
se they need an update to grok a new
option.

Simpl=
ifying... hosts need an update, and the question we have had on the table f=
or four years now is what update to push. What if answers were something pe=
ople wanted to read?
<=
div>
So it seems to me that there is=
n't much doubt about the
need for an RA based solution.
<=
/blockquote>
=

It seems to me that, of the various solutions analyzed by RFC 7051, th=
at particular one comes with a raft of problems, which were the reasons we =
have RFC 7225 now.





--james woodyatt <jhw@google.com>


I may be missing the point, but w=
e talking about updating host (5 year time horizon) to solve the correspond=
ing node not supporting ipv6?

Maybe we just need to cite this more and do nothing more


In short,=
 to be on the internet you need to support ipv6.=C2=A0

What problem does this not solve ?








-----------------------------------------------------------------=
---

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/list=
info/ipv6

--------------------------------------------------------------------




--001a113e72b61f617f055e0e88e3--


From nobody Wed Nov 15 16:28:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C63E124319 for ; Wed, 15 Nov 2017 16:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 YoRuUe4ZytF6 for ; Wed, 15 Nov 2017 16:28:24 -0800 (PST)
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 D1F59120227 for ; Wed, 15 Nov 2017 16:28:24 -0800 (PST)
Received: by mail-pg0-x22d.google.com with SMTP id p9so19233971pgc.8 for ; Wed, 15 Nov 2017 16:28:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Pi77uB+WpIthVFtdwpr4k+OTmwMZK6gAbBrpBx5lrqE=; b=iwKxEF7/diO7dmh0SBtYiLPThmgpKsXoIl2neOCQV+sfOtOZycbjgxffZMH268mJWm JBZHotI2BBIebpUg/eK0jgOKE6zESb54D2igNksphrjGdTsdzXUZaa86RC3CahYqbd1A JOg32lsjvcOV6zW7i+ZIPcOpqgRUGKRgBJfh/VZA2qtlj2aZFwBVpEaablAcI8HwqTyy Vj09E5sSrI1eL2trD5gVbvWGvN10c/ij8dXc6v7jphb+4eRU5hQ/+N5Iy/iF8dg6dZKN PD7YgQj8FYauzPuV0IttNwaIjG7yGPh406afnf35noX4M/EAuiYpsrOLCH5F8LkqcKs4 DDLA==
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=Pi77uB+WpIthVFtdwpr4k+OTmwMZK6gAbBrpBx5lrqE=; b=P2eMrbkD1iiln/ApC/XQJDgqDXW5PDf/4xteVofdaQvTm/iKWp2PkBL26r1hkT5e2K 18b7xIXTRuTgTkhncojm9GNzU0KEL007JvnfkmxZzwrFgMjNe+2QG3vutYfAzpc5TLZL uAHBlu0xdFGon3JF0R0ZqDm6C74fDHgP0+KH8DZCuPPuxwALVi2Zkdvf/vxqxvanoGJx o9bIC2YUeI+WDrA5YInb9FYG6CIdAGUMTpuidJAJxj4JljHglCEjwcDyDM8gcfye3c1i UmkqxF7HNg49aftPvKB1cS3i2SdCRctoSUG9HJkDKQYhaKdn9NGDEC4EPzbPOxmOXiu2 buFw==
X-Gm-Message-State: AJaThX4DkpsHKWczwuIpcnbcc8yvmuRAAqghKJ+edjOzeVKSmeuBUHRY BXA8oqaomXsFjMJQ+ig5l2B2oQ==
X-Google-Smtp-Source: AGs4zMZHsPC/QZliJTZUx0kGteaxA0aEpAyjqN0v8rL9aDnDt0yNeS0c4XBQH8GznN4ay0JbWhV+bQ==
X-Received: by 10.98.153.139 with SMTP id t11mr19560781pfk.210.1510792104217;  Wed, 15 Nov 2017 16:28:24 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:788d:282:9de1:e7b9? ([2620:0:10e7:10:788d:282:9de1:e7b9]) by smtp.gmail.com with ESMTPSA id c1sm41240095pfa.12.2017.11.15.16.28.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 16:28:23 -0800 (PST)
From: james woodyatt 
Message-Id: <24F322DA-F193-430C-8F97-CCDDFEF46931@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_99EB5C14-0D26-49BC-AAAB-80D480E1AFC2"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Wed, 15 Nov 2017 16:28:22 -0800
In-Reply-To: 
Cc: Jen Linkova , 6man WG , Mark Andrews 
To: Ole Troan 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com> 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 00:28:27 -0000

--Apple-Mail=_99EB5C14-0D26-49BC-AAAB-80D480E1AFC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 15, 2017, at 15:24, Ole Troan  wrote:
>>>=20
>>>>> IMHO the optimal solution is:
>>>>> - the network SHOULD provide a host with NAT64 prefix information =
in RA;
>>>>=20
>>>> Disagree. If the network has NAT64, then it should deploy RFC 7225. =
Ye gods, this is the very last thing that should be jammed into RA =
messages.
>>>=20
>>> Do we really want PCP in IPv6?
>>=20
>> If we have any kind of NAT, then we need PCP. Using NAT without PCP =
considered harmful. That goes for NAT64 and NAT66.
>=20
> It's not for the lack of trying that IPv6 isn't adopted everywhere.
> As IPv4 address sharing ratio's increase, say good bye to endpoint =
independent NATs, IP fragmentation...
>=20
> But now I have to first implement a PCP client, discover the PCP =
server address, and then finally get the NAT64 prefix. ;-)

Having implemented a PCP client, I can say from experience that it is a =
lot easier than implementing a DHCPv6 client.

Oh, and you have to discover all the PCP server addresses (in addition =
to the PCP server anycast address by RFC 7723) before you can use RFC =
7225 to discover the NAT64 network-specific prefix (NSP) for each one. =
If you=E2=80=99re really married to DHCPv6, then I suppose you could use =
RFC 7291 for that. But if you want to add those data to RA messages too, =
why not? (Oh right, I remember why not: because it=E2=80=99s a bad idea. =
Just use the anycast address.)

>>> Is PCP successful in IPv4?
>>=20
>> Well, there was this: =

>>=20
>>> Or does it even work well with A+P based solutions?
>>=20
>> Designed expressly for it.
>=20
> Ah, yes so it does.
> Doesn't work well with address and port dependent filtering though.

Is there a reason you think =
> doesn=E2=80=99t work =
well? Seemed to work well when I implemented it.


--james woodyatt >




--Apple-Mail=_99EB5C14-0D26-49BC-AAAB-80D480E1AFC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 15, 2017, at 15:24, Ole Troan <otroan@employees.org> wrote:

IMHO the optimal solution is:
- =
the network SHOULD provide a host with NAT64 prefix information in =
RA;

Disagree. If the network =
has NAT64, then it should deploy RFC 7225. Ye gods, this is the very =
last thing that should be jammed into RA messages.

Do we really want PCP in IPv6?

If we have any kind of NAT, then =
we need PCP. Using NAT without PCP considered harmful. That goes for =
NAT64 and NAT66.

It's not for =
the lack of trying that IPv6 isn't adopted everywhere.
As =
IPv4 address sharing ratio's increase, say good bye to endpoint =
independent NATs, IP fragmentation...

But =
now I have to first implement a PCP client, discover the PCP server =
address, and then finally get the NAT64 prefix. ;-)

Having =
implemented a PCP client, I can say from experience that it is a lot =
easier than implementing a DHCPv6 client.

Oh, and you have to discover all the PCP server =
addresses (in addition to the PCP server anycast address by RFC 7723) =
before you can use RFC 7225 to discover the NAT64 network-specific =
prefix (NSP) for each one. If you=E2=80=99re really married to DHCPv6, =
then I suppose you could use RFC 7291 for that. But if you want to add =
those data to RA messages too, why not? (Oh right, I remember why not: =
because it=E2=80=99s a bad idea. Just use the anycast address.)

Is PCP successful in IPv4?

Well, there was this: <https://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf<=
/a>>

Or does it even work well with A+P based solutions?

Designed expressly for it.

Ah, yes so it does.
Doesn't work well with address and port dependent filtering =
though.

Is there a reason you think <https://tools.ietf.org/html/rfc6887#section-13.3> =
doesn=E2=80=99t work well? Seemed to work well when I implemented =
it.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_99EB5C14-0D26-49BC-AAAB-80D480E1AFC2--


From nobody Wed Nov 15 16:39:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06E3120721 for ; Wed, 15 Nov 2017 16:39:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 jxWi-rIPQVnE for ; Wed, 15 Nov 2017 16:39:44 -0800 (PST)
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 6C1B0120227 for ; Wed, 15 Nov 2017 16:39:44 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id E732957A for ; Thu, 16 Nov 2017 00:39:43 +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 rUR8u5i_ZLSR for ; Wed, 15 Nov 2017 18:39:43 -0600 (CST)
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 79FDB86A for ; Wed, 15 Nov 2017 18:39:43 -0600 (CST)
Received: by mail-lf0-f69.google.com with SMTP id y85so3664122lfk.15 for ; Wed, 15 Nov 2017 16:39:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v02luK29UbZnvF7CIOEKdETb5ZIpiEF09roD6kYGqQI=; b=TN5rWxvy7piwdmA6duJdGlTgtNZac8Kc2u6zw2ygstsdDL/J6qANa1AwQQh/Mz6Q1S D2ZVK0iaTuc1UKwciyk4dxbOShVFPvOoxJeCA6FRw7S8QaHgdGgX/+R6fMegu65/fKFS bBaXb+hdhCa+EA59HK8rYmoy3YqcpD+5zxru4NGi4/gv59SsJCR721bXLlEtJMjzD/uT rC6E8oed/K0o+BuIauFIvrgaxh3jSKhfndvyUeMz/3iktigrpt+p0Rg5vMW7q215CTr3 Xq8cjES69cvMy4jTaaqm6wTYtx00drNiHG0PZSYOwqImKQrjiW6k6QvKeHLfptSZTzcm MZEA==
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=v02luK29UbZnvF7CIOEKdETb5ZIpiEF09roD6kYGqQI=; b=ftGutYVK2Wqym9UZjxYGdsWfK/qBdO1bWEmcob2C4+DIYpX9fCqUv/+QYdRfBmQK/k w6Z+kyM5EC9imPrL0jGfF+BpZEZDR1jsDGxNOTyB7PuLEU3sVipAiIQ8f0pdbpqE4ayo bPtPF679Uvj8rniGseFVL9FChD6djC4wtn7QgTQIWC9yrV2vlqBo2pjsy8Agj6QcqsKg usbdgfAT4YzQeGDkpePS2ce08lKTujYJVmWhNqPkwojooSFKeP04YvJF2YdKeFqp2rmx LUHaqDJXGvtW1HNzZ7oqaI3mrwncBU8owu7Pmx5raszNgR2Cmzp3J0LbwmHdRmW4alCs LYUg==
X-Gm-Message-State: AJaThX5V7BMrK3A1VCzbiM8gN0UCt8glFxwZ7TLH74iml5Y/qZkSilux DiNs9JCOiNFxLItitgL8txkuQQQX+4f6v7dgidEuk6qfkwu6u+SaUvoSFhUWDYyGiTTUicNLixu /OMUDz7oryd3a5jONuYzTW+qT
X-Received: by 10.25.31.198 with SMTP id f189mr4157577lff.1.1510792782007; Wed, 15 Nov 2017 16:39:42 -0800 (PST)
X-Google-Smtp-Source: AGs4zMZ/kRUv7iuefF8FMibD2NGqNeJKaTlf9yzS1sCl9+vivSClV5aydB4uOn55WIiNwZnoPU6RZQCXTGUwY6kmbNU=
X-Received: by 10.25.31.198 with SMTP id f189mr4157573lff.1.1510792781742; Wed, 15 Nov 2017 16:39:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Wed, 15 Nov 2017 16:39:41 -0800 (PST)
In-Reply-To: <72f42d56-2466-dfaa-59e9-ebb2264e8ca4@gmail.com>
References:      <72f42d56-2466-dfaa-59e9-ebb2264e8ca4@gmail.com>
From: David Farmer 
Date: Wed, 15 Nov 2017 18:39:41 -0600
Message-ID: 
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Brian E Carpenter 
Cc: 6man WG 
Content-Type: multipart/alternative; boundary="001a11403c0815da98055e0edb81"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 00:39:47 -0000

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

On Wed, Nov 15, 2017 at 5:54 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 16/11/2017 08:15, james woodyatt wrote:
> > On Nov 15, 2017, at 02:47, Philip Homburg  com> wrote:
> >>
> >> The safest option to do that is a DHCPv4 option that says 'no IPv4
> service here, go away'.
> >
> >
> > Better: extend ARP with a signal that says, =E2=80=9CARP is not welcome=
 here."
>
> However, the IPv4 traffic seen on ietf-dns64 is negligible and harmless.
> That is a practical indication that this problem probably isn't worth
> solving.
>
> I submit for example that sending a new "not welcome" response to
> ARP requests would do more harm than good, since the legacy hosts
> would probably react badly.
>
>    Brian
>

I'd love to see some data to back up the conjecture, that is the "traffic
... is negligible and harmless"

I completely agree that "a new "not welcome" response to ARP requests would
do more harm than good."

The problem I see is that WiFi airtime is precious, and worse yet broadcast
packets (DHCPv4 discover and ARP) can use excessive airtime in some
situations, more than the fraction of the bits they represent would
indicate.  On a wired network I'm not all that worried, but on WiFi, I'd
like some data on the matter.

On enterprise WiFi, you could filter ethertypes 0x0800 and 0x0806 at the
AP, or they usually have DHCP and ARP proxies, either of which would
prevent sleeping devices from being pestered by the traffic.  However, the
traffic still consumes airtime and that's my concern, especially on large
congested WiFi networks, like at IETF.

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

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




On Wed, Nov 15, 2017 at 5:54 PM, Brian E Carpenter &l=
t;brian.e.=
carpenter@gmail.com> wrote:
On 16/11/2017 08:15, james woodyatt wrote:

> On Nov 15, 2017, at 02:47, Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com> wrote=
:

>>

>> The safest option to do that is a DHCPv4 option that says 'no =
IPv4 service here, go away'.

>

>

> Better: extend ARP with a signal that says, =E2=80=9CARP is not welcom=
e here."



However, the IPv4 traffic seen on ietf-dns64 is negligible and harmless.
That is a practical indication that this problem probably isn't worth
solving.



I submit for example that sending a new "not welcome" response to=


ARP requests would do more harm than good, since the legacy hosts

would probably react badly.



=C2=A0 =C2=A0Brian

I'd love to see =
some data to back up the conjecture, that is the "traffic ... is negli=
gible and harmless"

I completely agree that &=
quot;a new "not welcome" response to ARP requests would do more h=
arm than good."

The problem I see is=
 that WiFi airtime is precious, and worse yet broadcast packets (DHCPv4 dis=
cover and ARP) can use excessive airtime in some situations, more than the =
fraction of the bits they represent would indicate.=C2=A0 On a wired networ=
k I'm not all that worried, but on WiFi, I'd like some data on the =
matter.

On enterprise WiFi, you could filter ether=
types 0x0800 and 0x0806 at the AP, or they usually have DHCP and ARP proxie=
s, either of which would prevent sleeping devices from being pestered by th=
e traffic.=C2=A0 However, the traffic still consumes airtime and that's=
 my concern, especially on large congested WiFi networks, like at IETF.

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:farme=
r@umn.edu
Networking & Telecommunication Services
Office of I=
nformation Technology
University of Minnesota=C2=A0=C2=A0 
2218 Unive=
rsity 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 




--001a11403c0815da98055e0edb81--


From nobody Wed Nov 15 16:56:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E348C128896 for ; Wed, 15 Nov 2017 16:56:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHytexTj523R for ; Wed, 15 Nov 2017 16:56:36 -0800 (PST)
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 F165B120227 for ; Wed, 15 Nov 2017 16:56:35 -0800 (PST)
Received: by mail-pg0-x235.google.com with SMTP id s75so19315503pgs.0 for ; Wed, 15 Nov 2017 16:56:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y7qnFaIs3lVyKNCiInhHSjzvjlT3T/nF2eeR+ku2Lto=; b=u4tJ2sSszMxNfnP/Z7rIpkSOSYTxN75jAvrlXrgNZGUAdUhBwTRzg44miN697dxMf+ xYUe9TZ9TXOkenELsm4e+POw0OXvlT4Ov3cCF7wdOZxqH28DQ5/yzAxQuHbj2Zn2bCzO ycvC6Var9qje27ES8FgqnTLamcS5G5MUCVBgP8J9tvhYKe8b3efZzB79hpyeMT/ChO7X z3xo3ogirHAMzlemTFbOdOsx3z6BQG4T9f20uO0l9PYML5PLp7+/b92yONtnVp2Z0+fV G4R0Yp/yAnK4fm9heg5QjWuwQhCJz3UP6mxUy88y3A4Zd+5HXypTjMRARXPXiQTfkNk6 4TVA==
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=Y7qnFaIs3lVyKNCiInhHSjzvjlT3T/nF2eeR+ku2Lto=; b=UoCCdEMBq7IAQ6qbo1dpg8XQZPsgk0UwidQcGcruN8CU/+r/l2+wDaBk8nTfEXWIzH CXpt2pqEZJ6WyXIy7WINynRxu0Y1PFApxKxvKviKr+GmFZwvgopujLfmRd0yxQ9yPBNO Z50kCQZgQNH/qSvfzQTGwlkkHBD3/igOMD5eP73LI8Ksb53bs6BBjbDygqTEstO3AoHM GqEKQKZMALNoSEtajt46FCM+Qdd8/IyoSxbhd53BWURmUz/uHxI7cnd8v63fkQ8WvUG8 TIQIq2b1qDaaKHhqBEnFnJrXzdTvOud1yoZWXbdpwDTTG9e5/1rjIG/tAdkn/7Sh7XJP T7IQ==
X-Gm-Message-State: AJaThX4uykHR29U6PPKKSBmVOnZv8U2H+Ez3V/1CTjLm2W0eVx54DLcB N52u9a0V4kZ+WahYeQ6xefeQaw==
X-Google-Smtp-Source: AGs4zMa8GMrme6S5kG6RP9uTDudc1moejrMdXDvP44a3mfUKdJ8QDThAALRGciWVwSc2BF/LRa8EnA==
X-Received: by 10.99.191.69 with SMTP id i5mr1940521pgo.13.1510793795157; Wed, 15 Nov 2017 16:56:35 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id i11sm16452945pfk.25.2017.11.15.16.56.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 16:56:34 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: David Farmer 
Cc: 6man WG 
References:      <72f42d56-2466-dfaa-59e9-ebb2264e8ca4@gmail.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 16 Nov 2017 13:56:36 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 00:56:38 -0000

On 16/11/2017 13:39, David Farmer wrote:
> On Wed, Nov 15, 2017 at 5:54 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
>=20
>> On 16/11/2017 08:15, james woodyatt wrote:
>>> On Nov 15, 2017, at 02:47, Philip Homburg > com> wrote:
>>>>
>>>> The safest option to do that is a DHCPv4 option that says 'no IPv4
>> service here, go away'.
>>>
>>>
>>> Better: extend ARP with a signal that says, =E2=80=9CARP is not welco=
me here."
>>
>> However, the IPv4 traffic seen on ietf-dns64 is negligible and harmles=
s.
>> That is a practical indication that this problem probably isn't worth
>> solving.
>>
>> I submit for example that sending a new "not welcome" response to
>> ARP requests would do more harm than good, since the legacy hosts
>> would probably react badly.
>>
>>    Brian
>>
>=20
> I'd love to see some data to back up the conjecture, that is the "traff=
ic
> ... is negligible and harmless"

That it's negligible was shown in Bob Hinden's statistics from Wireshark.=

That it's harmless seems obvious - it's virtually all multicast discovery=

traffic that goes nowhere. As I said, I have a couple of capture files
if anybody is interested.

   Brian

>=20
> I completely agree that "a new "not welcome" response to ARP requests w=
ould
> do more harm than good."
>=20
> The problem I see is that WiFi airtime is precious, and worse yet broad=
cast
> packets (DHCPv4 discover and ARP) can use excessive airtime in some
> situations, more than the fraction of the bits they represent would
> indicate.  On a wired network I'm not all that worried, but on WiFi, I'=
d
> like some data on the matter.
>=20
> On enterprise WiFi, you could filter ethertypes 0x0800 and 0x0806 at th=
e
> AP, or they usually have DHCP and ARP proxies, either of which would
> prevent sleeping devices from being pestered by the traffic.  However, =
the
> traffic still consumes airtime and that's my concern, especially on lar=
ge
> congested WiFi networks, like at IETF.
>=20
> Thanks.
>=20


From nobody Wed Nov 15 17:10:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7D2127978 for ; Wed, 15 Nov 2017 17:10:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.06
X-Spam-Level: 
X-Spam-Status: No, score=0.06 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_IMAGE_ONLY_12=2.059, 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 0MTRufKxmcWI for ; Wed, 15 Nov 2017 17:10:50 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7698D120227 for ; Wed, 15 Nov 2017 17:10:50 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id b6so18093507pff.10 for ; Wed, 15 Nov 2017 17:10:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:message-id:date:user-agent:mime-version :content-language; bh=I/zVuZTtZPBLledW/U0cPR1f1Qo4WHq6xtC8BCOTxW8=; b=GKYFpesRoNBsSsDMX8AiYaDb46Dpv8V5h7DhzRR9jTDkqQIIthctNi26mVhWEPBtVY dNawBXvD9tXoKoasP7mIf1yKY1sXA9KGkQ/JDPCU6RE7CSCRWQzRgPaMrFhSy7SQxRZR TGRWtheERrgzfdSK0WnQ6lHRG9UfoZcDlrAV0Wnzn2DVgpYj8qzWNsjUjm6aHMlDXSOT ocLkCPB94h9D73twpeycJ3bFWjrc2fHez+1luzwWKrZ14KYoefopEUs//8N2SMLRrX6P Yf1QmfPFjAS2TC+xyeHz09RywLbvMVIlrjB0ChcS9iL2hh9iKB4tX+56UQzhgprN308Y F9Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language; bh=I/zVuZTtZPBLledW/U0cPR1f1Qo4WHq6xtC8BCOTxW8=; b=N+m+WgadsHmXiuwUZNQeD3RfpLmMyrW/eXZhRxxqaU+hL7JBfqIvRz91u52oYWZP16 PD5auAfMM2nWH2IkZO+shc9SZ3+p8mHfLORY7btc82iIzO5EjyZFEinfLdGguBSaIWwo MuW6cCNOgxSUyH08tHD6y3ip55MQWABQNmCKIDOZnptH4bH83j5skbeMh7Jccg7VaBCU LW45/1LMRBofI07YLKmqNu+lIbDxpWx4sBowU6aMvQ3oihyj3bFsuqMFeJ+vtSjHtzlu DgL5JJe8+Pb0Qps5Ml+PBSCuK/NCbQCOBx9VK2oYZxYB2FvYmv/go9xVjLcRwQ0VCcsx 4voA==
X-Gm-Message-State: AJaThX6m6VUudQ5uiZu0td5P6SvLiw37xtE++Iq+r5OHxy3s0jdiomr/ dTDbUAkYMWTD+dXNjUwgemOolQ==
X-Google-Smtp-Source: AGs4zMZLzYSeApyvaRvixpjkD1IamVaJFnwduxEvoob4EIVEuVRl/w1RO2gfSF82jrp2L3my9VmFYw==
X-Received: by 10.99.125.81 with SMTP id m17mr14860243pgn.279.1510794649794; Wed, 15 Nov 2017 17:10:49 -0800 (PST)
Received: from ?IPv6:2001:67c:370:230:e84f:a10e:1937:4d7b? ([2001:67c:370:230:e84f:a10e:1937:4d7b]) by smtp.gmail.com with ESMTPSA id m25sm45810830pfg.49.2017.11.15.17.10.48 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 17:10:48 -0800 (PST)
From: Alexandre Petrescu 
X-Google-Original-From: Alexandre Petrescu 
To: IPv6 
Subject: IPv4 traffic on Ethernet in Terminal Room
Message-ID: 
Date: Thu, 16 Nov 2017 02:10:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------056C16DE74090916C51F09B2"
Content-Language: fr
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 01:10:52 -0000

This is a multi-part message in MIME format.
--------------056C16DE74090916C51F09B2
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

I dont know whether it is known or announced, but it seems to me the=20
Ethernet link on the Terminal Room can be qualified as "IPv6 only" (in=20
the sense that skype does not work on it, and most requests carried in=20
IPv4 packets are unanswered).

There is much IPv4 traffic on Ethernet in the Terminal Room.

Among the many IPv4 packets, maybe this MDNS sequence could be=20
considered as a successsful exchange:

Alex

--------------056C16DE74090916C51F09B2
Content-Type: multipart/related;
 boundary="------------32F0543211DB94CBE23A8725"


--------------32F0543211DB94CBE23A8725
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
I dont know whether it
          is known or announced, but it seems to me the Ethernet link on
          the Terminal Room can be qualified as "IPv6 only" (in the
          sense that skype does not work on it, and most requests
          carried in IPv4 packets are unanswered).

    
There is much IPv4
          traffic on Ethernet in the Terminal Room.

    
Among the many IPv4
          packets, maybe this MDNS sequence could be considered as a
          successsful exchange:

    

    Alex

  


--------------32F0543211DB94CBE23A8725
Content-Type: image/png;
 name="demnomgfgppnmbbb.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="demnomgfgppnmbbb.png"

iVBORw0KGgoAAAANSUhEUgAABB0AAAAiCAIAAACcBDaiAAATtklEQVR4nO1dX6hcxRlPWmhq
/H+VtNUqtVVXCF6FLCgS5L60sEiLKyzY4EOgL66tkuKysS/mQakPSylC5VAJ+NAHH7K2NIjZ
fQqFPFRcUYrVcl2JkjSpltw0SRuttd0+nH/z5/fNfHPm7Obe5As/Ljdz58z3f2a+mTlnNq2u
zQQCgUAgEAgEAoEgBpsuOAcCgUAgEAgEAoFgo0PyCoFAcOlhkjQbveRCPS5YPCZJs7HcGV5o
NhaNab+1MaROustLjeWlWm0U2eZo0F5q9JK1caex3BxMF/z4vHCJBoJgcQB5RRGKS412f5KX
T5KmXbg27bdq6QhAO5iNQIqjQbusPOzlDap9TdZghu6YJIQfpzTDRbSYbNXx+UQ1Y9uEEsHH
Sz2z522wHZo3zSuC2qy/Jtv9HBj2ygaLMUNz11yTw95SOcIpE46SMZWHOqCyobZclLeSkV9d
pmZqGBQv7rwi0nsjCylo7ldTISHRLbdt//5N337y/idO7d13fufK+Z0r53fcPtl6xTvbV053
9/z96eeOHTy8ujY7+vbRYwcPFzi1dx+FtEIVW8DwDGhh3LEHnQDw4yWSULQrhnE7Dw1A2/WS
tWm/pTie0i+VU4uyH1PIwccXB0JwySsEc4Zrv2I0aOfRMu5o0+h0QB13Gu3+JL4j8LSjsxFC
cdhbavU6uHLa1IyIPS8h9fFseqHwWQWVxAxSnW1BCI9EldqEfCJCajtaZ+0AZJiWwuUVKsN8
0WIUW839TIs0W+103BoNep1uuzmYqtrLl81S2dtNg/QkaVZKiRkYd0qFFCHDixSSK8krOGqP
8d7IQhJJt90fJk3d9JGFKt4/+enJn/9ofOU312741mzTpjnhf1u+en7nytqep07uf/nYwcNH
3z7qNgcOzzBrqusCoV4XlFfkjdfWJ4SOj+svr2glI60Fw+fb/YkzrzAfXyQ2zFaV4CKDL69I
lwnNOYoxO6zFd52TY20NlUnRNTlT2nS0xmdplmkpYqpRVUweny4L0kASRbRJS1QQGvYUJZQz
US6gCbRC3pSdL1qsYqu4n23l5mDc7yajtWl/MB4NzLxitVgwG/aWWkkyaBc7dXPOK5SFupIf
nlkRV6mGFWQVlM00dfjv9fP6cK2x8Ar0+CzpLncGRWV1vmXtApH8GzWNeRto00Fdn5Y5V0Ch
Tw57unKWUfKZ14wpJHUy7mRzLNWskYUZjh849Gnz3vnlEg58tnnzL5e2vfjdJ44fOAQ3NHB4
El6nl1tuowY1chtUWHYjPhupqwDlU95A4I7+rPHR6vQIQpaWSH3WO702sqOka8ZRRXJx3YVa
mGewnq7Sp2Si/xQIGIB5Rb4fqo4Z3fFq6pStpN9V/Wx+eYXJRhDFLOBd68Fla+gkkoMQnhjh
ZMOPKDGZqnNakIQuUXybvPynoaxvBc53oQnUQqdXgEe8okUrtoL7gdY6w9lo0OsPep3hDOUV
+vg3SZrdsT3hiNltcyAbyQq7TJJmK0kYIxbBlVMt+lK65VS+9XWlMDXoKP+9M2Q8XoJa3bcn
CnhLh6CuHqchqZM+meshjwJcM7KQ9IRhryBaVossXJutrs0+fP09Zg7wny9tfmf7Snos6p/b
rqyQRXxxzeVHtt70150rZ3bt/vP26z7ZZm6MrO15ihWeDq8zezD1eJLqANbvsDCPF9WjaKdV
N0ZoV8SEPOCNj3p0E4SQlrA+QZtxMEhnQsXmFTV0F4gixQlHybD/FAhYcL63nftTGjxFRCUL
yitMNgIolsveoDLVwZXHRZyE5rFZUVFMtuqcFmTyE98mwadOaFTOOJOw/QrvZoXTK2wTc0Sr
UbFM97OhDPaZXTx5RXqkxNq0mUN2Me23ltWpZ37UrdCSf+/C4gqpBbxMgkZlc7lXe+3EXv4E
VODj0MSgJmJJW6fUlhVt06v5gCcfI3wyU2befcGakYUOTyhnTvYhwCqFJc4+9LCdA/xpy2Uf
b7mKky18dOe9Z2+4mswltl371uW3/PHp5z76w1uq3VNl3vPD/eceePDzm7ME4x/fu6uwZrEv
AcKTdFo7HMDxJGMMSknAwnLlwhizFOpKMII1DtsVCUKwTZUcZ3zUopsgRHQa8I0yqseoirnk
FdHdhRHXPsGZSka7JQIBA+7vQeUBTL3uCf5bGZyXGZgU9Xdhjd0Ax/qK+SdEiDyeER94oWKG
qM5lQQCnRBXbJHM8ilBIdwbb0QudXmGAL1qNiuW4H4I58KfpExzqisJhb6mbEFt59R3J1SyY
t6zPC4mVNgdXcHfOXsjn5xV4H2BBeQXxEhFWS6Y6dc0yzCfTs/7lNALWjCwkPcGaD0UW6iSO
vn30zK7d7vzhk8u3HL/xjuw17mu3Gn89e9lVp75z/ZP3P/HBX06e3P/ymV27v/jy5vRPq5d9
4429+44fOHTs1z9tNnq/P3j41N59Zx96+LM771Zb+O/V13z4+nus8CSd1plX5MfAQvOKzpAT
19ivAvIKAiHjY+W8wrGbt+7PQUV3F2U7Dc4nLiSvEMwXvv0K+0i0c1k9i7pshhT0GQTnorsW
S+SCJWcr0LGFau0UA0L24zUlFTFiclRHW9Bq0yNRpTYhn05CAc7DSCp8GjMZ5otWm2I57kc9
6M4rkm6+gFcWTvutdpOXNleH82BGADm9mrkubhyQ8Kz2lTwsmYXq42i2BB/3MKzW1L4VAY5m
OWxalrf7gx7Vg3l8UnmLFOwXaafFYgoBjLlLumYfWUiJf3L/y+ceePCLbV+v/MrEaz95LjXi
fbf/4Lc/Sz6/+WuOyv++7Y5zK3e9eN19o9/8bnr0NDc8sdeV+3u6NR2ezD0HxfgKEDevCDoH
RXZ6nDGClsjUEhHFoE0XdQZUNRanxUw+A+cD0d2F3lRJndhCZJ6DkrxCUBF2XqFshqqznHLF
qOhEtM/SpVFaKa8A7RBswJqzVdcbaXQIKRW4hOzHzYW0KgcrI8Tkqw5aELWJJYprE/KJCZXm
4GoStuOxCz4CpNXhihap2BD3w0A5UppX2CZTc9diZNXOD9S3WaEowWyZ89KngytL4Un+MmJz
kHQceYXCT2dYVkCP45k9fNwtuFpTP+MHXsS03qnAavHbyPZJ5cS8dhQNem9kIcdFG4+a32QL
KySUr7jNPbc0XvjxS2d27T6/854Plq44sjWDN69Y/cqWI1uvOLL1evd3pd648VpG1BDhSXid
vq2qvClkK7mU1F2oMKDtL9lg5xUUdZcfescycz9Z5dkiZGsJ6pNos2Cs2je1EUtKR1dlXSau
u9DEdHaVfCVLXiGoDrkXTyAQCOaGekdl90EIAQ8fvv7ex79I7INMHHx2593nd66ce+BB+8iT
YOMg8sBn+LcKmZBJvGDjQ/IKgUAgmBvqnCjU+vaLIMf06Gn1drxjBw8fP3AovQ4vexlj58rp
7p6//eolySUuAqT7ALHfTi3X+GtNAySvEGx8SF4hEAgEc0NNE4X0mId8SF4guJgheYVg40Py
CoFAIBAIBAKBQBALySsEAoFAIBAIBAJBLCSvEAgEAoFAIBAIBLGQvEIgEFx6iDzHLMegBRsD
vlsUWSi/T1pcIh7xWepQlkzqlzygQvhaEn2uE1wEsYkB8oqCLcZ3yjORoj9RAtrBbPApqt+/
12+g9H4OX39c0TL9sXb6Ag0PYsXkq471pXmyZmybkZp3I/DL+ixjxamLXVP/oLjbUSlYVxNY
t1IoN6PBC5LVb6JX+6Y75Fm/g6L8E1NjmKuabs+VvGLdIjL0ar58Iwe8/CGycBGoY6KAv25c
ORIDWWJ+WxmO+EEmtkCMziGcM8cyPF1RylUNQIXwv0DNqxkr+yIhsWmWLyQ26U7VtV+hXFmv
fN9Qu2c+u/wubpj3tKOzwaSoaqf41DR8fNpvKdfQpITUSYN2vbSthKJOz7y8KRBVxeSrjmDe
BFJIbJuRmncDMkxLwTJWkGgxioW2C4us0aDdbGU3EI8GvU633RxMVe2VV94Oe0utdtMgXc8d
216e1etjXQ6WgeRK8oqLG5GhF1lIIum2+8OkqbtrZOGi9BnrqMZ95zkWlFcQ1B1tqiN+gIk9
PITaLmAsg8yTRKFCeFoKq1ld9sVCYtMqX0BswnE8izhfXpFybM5RzGsy6/ikunNyrCmOQ1G5
6tsMafrx4hrX/ErUXNHt/sShhHryq0pislXnsiANdK9tRJtVNc9XI7yIVyvkGYsvWqxiHZyE
5BWDcb+bjNam/cF4NDDzijIchr2lVpIM2p3hrO68wsMz7v4cFycjrtTbu9VlEmVpTY3KXr+8
sHaqNGtu46DHZ0l3uTMoKqPLbt39L6hJXGGLbh+3qeuju9K/IXiZNy8e1rTkVx1fyc7H2QGl
3TI+7jSWUeac14wpJA067rSS0dq031J9MrIwAIqLupwW1Rx3Gr0kX/YONYcVcarPG8Hud2/V
wQBLfOqAeTTiO0wM762nL7NXuy+u5h1jmUkITlfA8AcV4rKRTihEn1h2sqatOqJbgz0ts1Bi
c/3EphU4xcJlMiLerxh39K23wrGS7vJSK+l3zVN988krTDZCKWZWNGczvFl4Q0nFGu3+hFRC
kv0SkyBGiclRndOCJPS5YHybFTXPV6Z3IYdpLL5o0YpVz0EZwgbkFZ3hbDTo9Qe9znCG8opc
8LRwkjS7Y7X9rIeqYcGG4hmniO6VM4Irp1r01WjLqXzrl0phatBR/ntnyHhckxcukNudO16q
JKirp91cWQ3xOCaEtsty1RXZnZrmlb9DJVNtAuqO0DADKm8/D2FcM7KQdOxhryBaVossZCPp
Ok8nGk5r1qQCgWUOwyg6WHMXj4M5VhZI6iTzxojvMjE3r6BGZ4bmHWMZom5OVyZJs5UkdtIe
tF+BCLH1actOu41JyOdgvu7XU6jLKLFplS8oNg0eil+c723n7aa1C70kC8orTDZCKE77rWW1
T/HvV+hURmU8Jx0lrzCVUK5JROuhiphc1TktyOQnvs2Kmq+qQKuQbSy+aDUqtjytFOgAWe+Q
9xf+vCLd+bU2berILjDPwZsVplpUrhAJ8DIJ6klVnRinFKxVH9DnUo9DE4OaiCVtW2N5yTXd
16bUbjcDjxOEMvWS84xM24YFQa6iKAS0SVDH5iYCymgW1ows9Hv1JDGPEVYs5IOYW2Cft2sG
eJ0rBqvOXTwOxjieZFLHzIMRv0rnTMEYR1ia549laLoySZraKnL5eM3noLzOUMjOdxuqJv3W
H6uQUJ3EpkstFKE6YtMIjSLi3N+DUo4Awdc9wX8rg3Mym01R04iydkg8bk3pUFNACfpLt46F
DRbCxeSrzmVBAJdCqrZZXfMMwHb0whBj8UWrUbHmyZ/AvEJlqTu2z0F1hvoJgW6C2jeCJRSI
Z/JEE/9oqcoV3J2zF/L5eQXeB1hQXkEcvIZ5RT7y+Y/AepiHDJcDTGxeAdoMeqmUCKj0PaKS
DVgzshCyBEf6yEKu58/oGQn0ed7chW+OXPOV5y4eB6uQV0Dm4YgfPEJxrMDXPMWe+6858/o0
V43omvMKvzOAo+Ae4Jo+1fn6ZEJ1EpsXNDbVOnnE+fYr7KN+zmX17BBwNpPwHAJ2KsLho+SC
ZVmId+3x484pjiqCQwlO/pmoIGaA6mjmrTY9c75KbcZp3gNGUuHTGNjGZYpWm2K5G2voQXde
kXTzVZOycNpvtZu8HCAEgGd7/zcwqTC5Mtcdlb+WkpJLQcrqplmoPk4t+VuPexhWaxauYhTi
rQlo+qTb7g963gkEtcHtcieY/2hLlfAclHMQ0o+l8bpHIqAy1/V2yJGFAMbInW4WRRauluoN
2Hv3+TyqSZ6+Cxit2HMXZ3R4DgTyqSPmSf8MGaEc5ih6zgDNa4rSuizWdEVfSq+2X8E9B+V0
Bm3Ed5yMMJzBZaNSdfxChm9IbKqMzTs20TieEbLzivxQnbGaWyZ21vG7HNmyVnBeAdoh2IA1
CwnRoQ6tGnrcTFjTyuXatmZgoATKkExEislXHcm82SZWSFyb8Zp3ALaDGyeNZfsPW7RIxSq7
KAwHQEA5UppX2CZTc9ei39Q2bSvnxgTPdqLiMY0iBVXHUniSvw/XHCQdZ/9YdAudYVkBPY5n
9vBxCFhTPxehsmdaisoreKMdvd1hEtI28VA/aR6h1guhkmGbWExfRKuTQnXilQ8rMPQiCznx
1XjU/KBcWKFuev8ys6pSl9OimsREgW8OMHcx935TAZF7Uw4Wk1dg5tGIT5uYlVfgUY+teXos
w0tOrpAxK9eZV0B9ekd869O39Hvb+goX6GmZhRKb6yg2qXF8kni+MysQCASCKIQc5/MjcJe8
EvznrAT1qTpul1sgEMwFEpvVIXmFQCAQzA115hWLGeokr1gE0hVEufBYIFhvkNiMhOQVAoFA
MDfUlFeke+sLGeokrxAIBAJBRWzaeutjAoFAsE7wr/dfkJ/yU37KT/kpP+XnRvwpeYVAIFgv
SDsmgUAgEAgEGxGSVwgEAoFAIBAIBIJYSF4hEAjWC2S/QiAQCASCjQuQVzzy2iz/d+LZVl7e
evVdu/DWZ55dnc1ms1cej+QDtIPZ4FN8/M3i+dlr+63CNx8parJFwyxBQmzEisnnE4uJgGrG
tgklgo9DG4kOfa7+7vPPFLK88vhjW2/d/0rpl7louKbKQxUf9vJmWpMjMsXqRQa+7UK0pHha
8Vej/MSzLb3vyg204/kTM/1f2sKO50+oTblMaRciQpSYKEyyCIUumjKsaakgt/rqDofymcwL
BAKBgI3/A1GsrCBCtS22AAAAAElFTkSuQmCC
--------------32F0543211DB94CBE23A8725--

--------------056C16DE74090916C51F09B2--


From nobody Wed Nov 15 18:27:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9A412894A for ; Wed, 15 Nov 2017 18:27:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td_Htcw8Kn6i for ; Wed, 15 Nov 2017 18:26:57 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F29F129415 for ; Wed, 15 Nov 2017 18:26:51 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id i15so8164983pfa.3 for ; Wed, 15 Nov 2017 18:26:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JKrBuJ9fGHxHRj7hFjxy2gKAiVEq2lHpfk1NgJdYOzM=; b=WflQ3z/zg/UPTkOjb22GaPE77RPxO1xsE/mMa2umITydlypesq6xLawbQsUBstVmHc X1ISSPXkRw6j6G+olymuwAS3e53/e0mTeF7rNS1N9+WQ82DJDwX+bP8Mjygy2NpJ1HVF oF12136YMxXRtSkuHG3lum2SgbT+/4EnKDQ5qOcK0DxA15IwZrk4H1LMjaStiXq4Dw7D 3pdJPCK0r19MsW9jsPXrBOaeiEcF9E2j4Nf+mO8Cu4Cg7Et5gnNd1fbTzHFQYPYLB8ac oaaPABKtfd5V421VjEM2L9CFIGkpe37apmFEOzIyKzfFEI5HV+niY0xPwCpp2ydzHxJb rU1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JKrBuJ9fGHxHRj7hFjxy2gKAiVEq2lHpfk1NgJdYOzM=; b=kGw0Mu4fPZyG8qd+xj+W489hsHAoUyGqjg+JBDPeeiTG+oMHuqr9mTpI/F2as45tjc Z45ycHYFgj+fpFHz2qanUT3KLFXFtkPITXnjKLgrdYkFGJPfmrhcr3DCklUOvsOcIk1C wIMeJZGACEZkSjZBZ6pjMgF/HP1BCuhMCZ+l6XrCC81nkxN26aybFZUrLkWnp7UWi2dH oTVW+1mt3gzKcDhti4wXsh/W57naBVAAWR/TYXru2BDdGjmF+IYBSXoMTkxRpzCsZRO0 bfj6Ed7FNb5DnPVjyjEJzm++NOhxNf5aW2bgNqApXKKQW+Mvkhg+/fvMOwztEB2zPBsv Rwng==
X-Gm-Message-State: AJaThX5MMhUfeqbWfwimbyylS6XEnrD+B0hGV1CjgjdYIcbjntf+w4q3 PILAAkX8btk67rRMeFxk9UizuQ==
X-Google-Smtp-Source: AGs4zMasWGLq1BOU1Y1s721p4MtHbmmY5KxFuRDF26tjBJRECQP1LHqKjOq5tI93m24xHqXMpEnEjQ==
X-Received: by 10.99.127.88 with SMTP id p24mr116553pgn.377.1510799210945; Wed, 15 Nov 2017 18:26:50 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1999:b5e0:a490:c25c:d8f2? ([2001:67c:370:1999:b5e0:a490:c25c:d8f2]) by smtp.gmail.com with ESMTPSA id r18sm39872pge.87.2017.11.15.18.26.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 18:26:50 -0800 (PST)
From: Alexandre Petrescu 
X-Google-Original-From: Alexandre Petrescu 
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Mark Andrews 
Cc: ipv6@ietf.org
References:     <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com>   <4E59E93D-03F0-4146-AD81-DA8AEE5255F6@isc.org>
Message-ID: <3b9dc40f-56a4-dcaa-1b29-0e7f8c7fa8f9@gmail.com>
Date: Thu, 16 Nov 2017 03:26:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4E59E93D-03F0-4146-AD81-DA8AEE5255F6@isc.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 02:27:09 -0000

Le 15/11/2017 à 19:33, Mark Andrews a écrit :
> Do we provide a DHCPv6 server and set the O bit in the RA

The RA has the M reset and the O set.

It contains a "Recursive DNS Server Address" Option, and with lifetime 
9000 seconds.

> to provide
> the DNS server addresses?  Manual config shouldn’t be required if we
> do that unless your OS is broken. I’m not on site to check.

I suppose then Windows is wrong to keep this address forever.

Or maybe it received just once from IETF an 'infinity' value in that 
field so it stays there forever.  It's a stretch though.

Alex

> 


From nobody Wed Nov 15 19:42:53 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E0E1270B4 for ; Wed, 15 Nov 2017 19:42:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 BRtKiN7L0cuz for ; Wed, 15 Nov 2017 19:42:49 -0800 (PST)
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 77B14124BE8 for ; Wed, 15 Nov 2017 19:42:49 -0800 (PST)
Received: by mail-pf0-x231.google.com with SMTP id j28so16300176pfk.8 for ; Wed, 15 Nov 2017 19:42:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:subject:message-id:date:user-agent:mime-version :content-language; bh=Ye88cAlWVtMWRvGvsz0aqma6xi2KPWyPp/rHFsVjxtY=; b=CuvuvV/pT8xQ1t3DICMX+r6uRulaIAXFPMIGi0GAJRBPvw10n/Zx2AIuqjYUhrfDzv ChddjDNcAWWI+V2b9W/Jeqx1Yp1Uo/wGY/9BLpd/yLuLqrVtf0JqcCicuolAs71sglmk AVd0FsoDu1y1/mSDhs+1c4/org5ZsPz4xKYsrTyB5I7k+yYuDK6dMW4+G6rLA8IaOxQB VfB7jc+RgevFc/oFQZfOkEsjimPxEPMXQP+Jtm1aCnai01+rktJw4Xzmdc1WoRdhWnd9 1sYOV91TaF0oR5q2Kp0gUe0QBclYLY09cCmbSqrpPvvFoDPFwbmCpin0dR/soCy5apkN B1Ww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:message-id:date:user-agent :mime-version:content-language; bh=Ye88cAlWVtMWRvGvsz0aqma6xi2KPWyPp/rHFsVjxtY=; b=qX4R07NKYooMsnzO+ybnFpVYFc8kGWIQxbs69fUtC/kXdbqOkFbYCfjzi2qVGR7RPh UQVTSO7JnYC4P9tckQJNRK4Io5L+gTfAXDI0VwXRSSL5v6/E1zIeAWnNIlTQj/6chonQ wK/xB1lEHP6dqXawEq5Yv7PXEVNx7wzsBN9+rJPGPckGxpK9iBoSOZzctquDBf3Q93oi vI/0Bqy6wj3aZ+849fQJK8vF333Oau8+kmLIf59XqjWxmpShQC/kdw0a3wmHoUiOAkhy sA83sH5mq3ebJ9+ncAJXbGUYeRjWSxOJJgV4XZYIVVEyajRIs5mpdwy8v8Fi4pJbqyPI jM7g==
X-Gm-Message-State: AJaThX7IYK6j13hX7rS5EWBsYmdvnCr107nUxiBucHsnEJxCDdpwMH72 9CzeSLsARB1Vi/cu0BE8HtBQfg==
X-Google-Smtp-Source: AGs4zMY9itI+X5BlvCtpO8rFIo6F1f0IDA7YY/QExN5989wHKdfqnmToDym6/HWH7v2/rKBxvHIWMA==
X-Received: by 10.84.251.152 with SMTP id w24mr330176pll.88.1510803768878; Wed, 15 Nov 2017 19:42:48 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:99f9:2764:be45:afa0? ([2001:67c:370:128:99f9:2764:be45:afa0]) by smtp.gmail.com with ESMTPSA id m6sm222391pfm.121.2017.11.15.19.42.47 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 19:42:48 -0800 (PST)
From: Alexandre Petrescu 
X-Google-Original-From: Alexandre Petrescu 
To: IPv6 
Subject: report on jabber use on ESSID "ietf-v6ONLY" and "ietf-nat64"
Message-ID: 
Date: Thu, 16 Nov 2017 04:42:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------E582E0C9EFD9E9BDAD8BA8DC"
Content-Language: fr
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 03:42:51 -0000

This is a multi-part message in MIME format.
--------------E582E0C9EFD9E9BDAD8BA8DC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

I am happy the ESSIDs "ietf-v6ONLY" and "ietf-nat64" are available=20
during the v6ops WG meeting at IETF 100.=C2=A0 The other ietf SSIDs are=20
almost silenced (one or two bars out of five.)

Most apps work ok on my laptop.

One note, about the jabber participation.

My installed old client "exodus" can not connect.

"eyeCU" is hard to configure for IETF jabber.

The https://collyer.conf.meetecho.com/ has chat, works, but has a=20
relatively reduced chat text interface, short lines, not full screen, etc=
=2E

(or maybe I dont know how to use it very well).

Alex



--------------E582E0C9EFD9E9BDAD8BA8DC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    
Hi,

    
I am happy the ESSIDs
          "ietf-v6ONLY" and "ietf-nat64" are available during the v6ops
          WG meeting at IETF 100.  The other ietf SSIDs are almost
          silenced (one or two bars out of five.)

    
Most apps work ok on my
          laptop.

    
One note, about the
          jabber participation.  

        

    
My installed old client
          "exodus" can not connect.  

        

    
"eyeCU" is hard to
          configure for IETF jabber.

        

    
The
          https://collyer.conf.meetecho.com/ has chat, works, but has a
          relatively reduced chat text interface, short lines, not full
          screen, etc.

    
(or maybe I dont know
          how to use it very well).

        

    
Alex

    

  


--------------E582E0C9EFD9E9BDAD8BA8DC--


From nobody Wed Nov 15 19:53:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7057E127010 for ; Wed, 15 Nov 2017 19:53:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCjzKFvndrFm for ; Wed, 15 Nov 2017 19:53:30 -0800 (PST)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F49F124BE8 for ; Wed, 15 Nov 2017 19:53:30 -0800 (PST)
Received: by mail-pg0-x230.google.com with SMTP id c123so11601998pga.11 for ; Wed, 15 Nov 2017 19:53:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dPEvmUTqaLp6yR+dfmaIfntyTIyFvyIfFeIh6CeF8aI=; b=Opp6OkuOKNrEBaKsVelUDB/BQa6OuU24f2X6U947q+0sqIgVNf+TpibRu6NMkocAkN gWUbjGLmrXEpYQqUl+Vz7lPCEV/s+Xkzt/h/aM18CiTs+eM8G85EwSyUpS/q40EyzTD9 aIXwFHO+YpHuq5NfLw+KVljGxmhb0uNUXN4Cm3OBsc3ASP4H/7ngl0csAmODKcwMQwGm D9ke8sa4CdvOeQGCvsJMs8TceJ7udCux64WRRa1ejYdIn0F2scqCJjBY9gbEEirgknMF jFqPp7Go5QJDZnj4ysNy8T6cIf++nOyfYE0niVcTjtWB3Fg6mHohlKLLVlqBZJvGCy6k Lmmg==
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=dPEvmUTqaLp6yR+dfmaIfntyTIyFvyIfFeIh6CeF8aI=; b=fFoa1R6yIQ35ijyDAr68i2z6f+1816G/7/UjtRBTOlX+zdH8xdrZEnNAGSrLJDhV2m X6C8p8RZEGWmEVfgZxn7GSWNx9hS6Xo1A0Fl1fOuVwcil87vSLVVUXsBzSnAc+xIO082 Z4jjS0LEeSnRtg+aHn3Arx9pLXh4BxdFwj+PcQuDKMPoidSyUxlezbDe4f/o1RKQ/J9I +0kP3UnUlBgS4fzBmF5r+0gGN4QVUlGLZ3J2pDlE+KqZNuahiUIcaYbbtL3kZoj+OdN/ LSfYNNl3Bq+UDMit2WjfeGe8KCYR1RNSEbuNigUFZWgLCLf9Y+3xVKQsYTRc8KLhML/0 mpkA==
X-Gm-Message-State: AJaThX6TjnJpyp7UF6tXjl052aZsxEV/tT4b/sJttxrTqLIg+M7TfG8K pczlUG5ijraI/U+BVBWloTTBoQ==
X-Google-Smtp-Source: AGs4zMYR4RLk9JIVK5HAoOViRglWkOpq5wAkrsH6qyjrVBRbpb1tPcID0oQ5pXsZJmQKjY1OK0bVJg==
X-Received: by 10.98.82.3 with SMTP id g3mr348153pfb.189.1510804409837; Wed, 15 Nov 2017 19:53:29 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:28cc:dc4c:9703:6781? ([2001:67c:370:128:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t4sm276736pfj.56.2017.11.15.19.53.28 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 19:53:29 -0800 (PST)
Subject: Re: report on jabber use on ESSID "ietf-v6ONLY" and "ietf-nat64"
To: ipv6@ietf.org
References: 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 16 Nov 2017 16:53:32 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 03:53:32 -0000

> My installed old client "exodus" can not connect.

Did you report this to the NOC?
https://tickets.meeting.ietf.org/newticket

Exodus has been unusable for years, in my experience. Gajim works quite well,
but maybe it's IPv6-enabled anyway.

   Brian


From nobody Wed Nov 15 20:05:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF4C124BE8 for ; Wed, 15 Nov 2017 20:05:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF6qe83CWQPt for ; Wed, 15 Nov 2017 20:05:49 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A705B12025C for ; Wed, 15 Nov 2017 20:05:48 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAG45lEL007625 for ; Thu, 16 Nov 2017 05:05:47 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 09930201A89 for ; Thu, 16 Nov 2017 05:05:47 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EAEC22014F2 for ; Thu, 16 Nov 2017 05:05:46 +0100 (CET)
Received: from [132.166.84.17] ([132.166.84.17]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAG45jxJ028995 for ; Thu, 16 Nov 2017 05:05:46 +0100
Subject: Re: report on jabber use on ESSID "ietf-v6ONLY" and "ietf-nat64"
To: ipv6@ietf.org
References:  
From: Alexandre Petrescu 
Message-ID: <8ec969b7-dd8d-dc01-294e-e442c15aba3a@gmail.com>
Date: Thu, 16 Nov 2017 05:05:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 04:05:51 -0000

Le 16/11/2017 à 04:53, Brian E Carpenter a écrit :
>> My installed old client "exodus" can not connect.
> 
> Did you report this to the NOC?
> https://tickets.meeting.ietf.org/newticket

Should I?

> Exodus has been unusable for years, in my experience. Gajim works quite well,
> but maybe it's IPv6-enabled anyway.

I will try Gajim next time.

I have been using Exodus ok since IETF does jabber.  I suppose I got 
hooked to its interface more or less.  It works fine for me on the 
non-IPv6 ESSIDs.

Alex

> 
>     Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Wed Nov 15 23:28:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9606120724 for ; Wed, 15 Nov 2017 23:28:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level: 
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBYBM-G54Kux for ; Wed, 15 Nov 2017 23:28:41 -0800 (PST)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF99124319 for ; Wed, 15 Nov 2017 23:28:41 -0800 (PST)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 03B3E60F21; Thu, 16 Nov 2017 08:28:40 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id DA024C0062; Thu, 16 Nov 2017 08:28:39 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 08:28:39 +0100
From: 
To: Ole Troan , james woodyatt 
CC: 6man WG , Mark Andrews 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTXkUPM5Da2AC8eUW6xsTjimyrvqMV6UmAgACh+9A=
Date: Thu, 16 Nov 2017 07:28:38 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07B59C@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org>
In-Reply-To: <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 07:28:43 -0000

Hi Ole,=20

Please see inline.=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Ole Troan
> Envoy=E9=A0: mercredi 15 novembre 2017 22:47
> =C0=A0: james woodyatt
> Cc=A0: 6man WG; Mark Andrews
> Objet=A0: Re: IPv6 only host NAT64 requirements?
>=20
> James,
>=20
> >> IMHO the optimal solution is:
> >> - the network SHOULD provide a host with NAT64 prefix information in
> RA;
> >
> > Disagree. If the network has NAT64, then it should deploy RFC 7225. Ye
> gods, this is the very last thing that should be jammed into RA messages.
>=20
> Do we really want PCP in IPv6?

[Med] IPv6 Firewalls, NAT64, and NPTv6 are target use cases for PCP. All th=
ose were taken into account when designing PCP.=20

> Is PCP successful in IPv4?

[Med] PCP is a deployment reality. Most of CGN vendors are implementing PCP=
.=20

 Or does it even work well with A+P based
> solutions?

[Med] Why do you want PCP for A+P?=20

Please remember that we have indicated the following in draft-ietf-softwire=
-stateless-4v6-motivation:=20

=3D=3D=3D=3D
3.1.4.  No Additional Protocol for Port Control is Required

   Stateless solutions do not require activating a new dynamic signaling
   protocol in the end-user CPE in addition to those already used.  In
   particular, existing protocols (e.g., UPnP IGD:2 [UPnP-IGD]) can be
   used to control the NAT mappings in the CPE.

      Note: To overcome some security concerns, IGD:2 authorization
      framework [UPnP-IGD] should be used and security considerations
      elaborated in [Sec_DCP] should be taken into account.
=3D=3D=3D=3D

>=20
> >
> >>  (I do not believe that information needs to be duplicated in DHCP at
> all)
> >
> > Totally agree about that.
>=20
> Appears this isn't as simple a problem as I thought. Let me read 7051 in
> it's excruciating detail.
>=20
> Guess we're stuck.
>=20
> Best regards,
> Ole


From nobody Wed Nov 15 23:29:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635CB126D73 for ; Wed, 15 Nov 2017 23:29:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level: 
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDFbvOO7xL2z for ; Wed, 15 Nov 2017 23:29:47 -0800 (PST)
Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59045120724 for ; Wed, 15 Nov 2017 23:29:47 -0800 (PST)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id EF03820FA8; Thu, 16 Nov 2017 08:29:45 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id D00F71A0059; Thu, 16 Nov 2017 08:29:45 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 08:29:45 +0100
From: 
To: Ole Troan , james woodyatt 
CC: 6man WG , Mark Andrews 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTXkUPM5Da2AC8eUW6xsTjimyrvqMV6UmAgAAVjYCAAAW7gIAAic2g
Date: Thu, 16 Nov 2017 07:29:44 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07B5B0@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 07:29:49 -0000

Ole,=20

Please see inline.=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Ole Troan
> Envoy=E9=A0: jeudi 16 novembre 2017 00:25
> =C0=A0: james woodyatt
> Cc=A0: 6man WG; Mark Andrews
> Objet=A0: Re: IPv6 only host NAT64 requirements?
>=20
> James,
>=20
> >>
> >>>> IMHO the optimal solution is:
> >>>> - the network SHOULD provide a host with NAT64 prefix information in
> RA;
> >>>
> >>> Disagree. If the network has NAT64, then it should deploy RFC 7225. Y=
e
> gods, this is the very last thing that should be jammed into RA messages.
> >>
> >> Do we really want PCP in IPv6?
> >
> > If we have any kind of NAT, then we need PCP. Using NAT without PCP
> considered harmful. That goes for NAT64 and NAT66.
>=20
> It's not for the lack of trying that IPv6 isn't adopted everywhere.
> As IPv4 address sharing ratio's increase, say good bye to endpoint
> independent NATs, IP fragmentation...
>=20
> But now I have to first implement a PCP client, discover the PCP server
> address, and then finally get the NAT64 prefix. ;-)

[Med] This is more subtle. You don't need to implement PCP to discover NAT6=
4 prefixes, but because of other NAT64 problems (e.g., allow for incoming c=
onnection, referrals, reduce keepalive messages, etc.) PCP is your friend. =
In such case, prefix discovery using PCP is more determinist compared to th=
e heuristic (there are also many other issues unsolved when using the heuri=
stic).=20

My take on this is this wording from RFC7849:

=3D=3D
   C_REC#7:  In order to ensure IPv4 service continuity in an IPv6-only
             deployment context, the cellular host should support a
             method to learn PREFIX64(s).

                ...

                In environments based on the Port Control Protocol
                (PCP), cellular hosts should follow [RFC7225] to learn
                the IPv6 Prefix used by an upstream PCP-controlled NAT64
                device.  If PCP is not enabled, the cellular host should
                implement the method specified in [RFC7050] to retrieve
                the PREFIX64.
=3D=3D
=20

>=20
> >> Is PCP successful in IPv4?
> >
> > Well, there was this:
> 
> >
> >> Or does it even work well with A+P based solutions?
> >
> > Designed expressly for it.
>=20
> Ah, yes so it does.
> Doesn't work well with address and port dependent filtering though.
>=20
> Cheers,
> Ole


From nobody Thu Nov 16 00:07:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFEB126BFD for ; Thu, 16 Nov 2017 00:07:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ece9NaUqVyR for ; Thu, 16 Nov 2017 00:07:19 -0800 (PST)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 E9FD8120724 for ; Thu, 16 Nov 2017 00:07:18 -0800 (PST)
Received: by mail-io0-x234.google.com with SMTP id h205so3610951iof.5 for ; Thu, 16 Nov 2017 00:07:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:message-id:date:cc:to; bh=9tTGP5hCmk924d0P1h/l+m5yE3bHt/6afwbDL9d70WU=; b=uZjSqHS2ICQ6cViot+MoRE4CVPwvCpALfgxhBllyxpKaLjXpbkgUatgZyQdvQJT8Uu p1EETp3tepC2zuydMG8T8mBX0uSvOXh5duR51opETbaLyWLz4yTHARP//HKRgP0L2LGr j89lk5Vasys78Ayfr0QPFmbP9n6HNpfjLqD7oTBM6lQhuZi5x406NjalEjYYxAO0VYGW SwSrnandwH/eRNly/WhgQKFX6YiZVWLUiFhaUPnIb9JXXWaEv5ABtSVEwlGFrOMCV+wM Qie49SsVLXn2Yb4lXPMnysWbg34tS+Y1XkaxO20CEYa4dzphJMKyJ4bZOeuoLs5R3DSY X0MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=9tTGP5hCmk924d0P1h/l+m5yE3bHt/6afwbDL9d70WU=; b=PtS8PKQ6GbUc/8ed7H7VT5gip2rURu7Xuy9njoGQZ2rg+ZtCdNMaYmCAj+l8dNHX0Q 6Ys80qS8GTrHV3AxScDo3hupBK3zShq3WqUFMmTKlyk7zQwYNSEsEv2LF2sZ1TvHlRNW 2iDRAG0oOAD7jGc9bQU+rtQ8IASqII5Ivp4GCF/AsEFgtufhejuZrxW4qx9eQyCBHDya n5He5xw0E49ORtXodr7g1uy0B3UlU2QmIJ/2NQYQNKHmn8U39Zm6fhmt/PLBrICppdF/ jn3YlW9ua7gfPj/nPu1DHWvKRzkKTenhqXTwEDJZkIx4EMIEQbsheqdxP3ztNfzqxGuW INCQ==
X-Gm-Message-State: AJaThX6eVuFHKMtv3CL1Qlrc7cViUfBCA3yonesD2JoiDK0P986bFrgX L5xlhU7oxpZ15TvtNzzuWhPEoPt1
X-Google-Smtp-Source: AGs4zMbu7xIJ63fWnKA0Q7YALEGBOpd1XZFmNunE8+9JMFM6VnrPV33am4ZBf4O6i7dEMlJDZD3aGA==
X-Received: by 10.107.17.98 with SMTP id z95mr801185ioi.26.1510819638006; Thu, 16 Nov 2017 00:07:18 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:48d2:b159:ea47:82ea? ([2001:67c:370:1998:48d2:b159:ea47:82ea]) by smtp.gmail.com with ESMTPSA id b72sm496679iti.44.2017.11.16.00.07.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 00:07:15 -0800 (PST)
From: Bob Hinden 
Content-Type: multipart/signed; boundary="Apple-Mail=_A262450B-CBD3-44EF-B66C-7A466A7433A6"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Confirm consensus to adopt 
Message-Id: <2F87B4AC-E56C-4A33-82BD-E92DFEEAF331@gmail.com>
Date: Thu, 16 Nov 2017 16:07:12 +0800
Cc: Bob Hinden 
To: IPv6 List 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 08:07:20 -0000

--Apple-Mail=_A262450B-CBD3-44EF-B66C-7A466A7433A6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


At the 6MAN session at the Singapore IETF there was a positive hum to =
adopt  as a 6MAN working group document:

        Title           : IPv6 ND PIO Flags IANA considerations
        Author          : Ole Tr=C3=B8an
	Filename        : draft-troan-6man-ndpioiana-01.txt
	Pages           : 4
	Date            : 2017-09-19

        https://tools.ietf.org/html/draft-troan-6man-ndpioiana-01

The is a call to confirm this consensus.  If you object to adopting this =
document, please
respond to the mailing list.  Editorial suggestions can be sent to the =
author.

This confirmation call will end on 30 November 2017.

Regards,
Bob Hinden






--Apple-Mail=_A262450B-CBD3-44EF-B66C-7A466A7433A6
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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloNRzAACgkQrut0EXfn
u6ioDwgAqjOVhHPRVGtgZ/44h360CgvESr6Hpc1w6RI6qZVKxIsVYs5G+anExT8L
Ddze8fukzrhPiVYONawvElwfzV3lFy7HxnnKQe6oKwcWRU6Wpw68+nir41l9qCcL
VES+6hG3UdJOsSwi1BRhlMs3JfjgQhvkv0T/uPlY9Y5qjDZ0P5EqcLqaOccAjn/h
ckGLPkebtKgqp7b04S7J1enkhLHru0dC8gSpluwD7jTg+VyMjYmZF+CafWWMqDaF
tys9Ro4Lxb7fP1q0D60iAJ7zFdKD0ace3+GW3Ggg7mQMud2E3e3qFULoGkiVoG3K
k5p5q3K8lBzNGKf34pKPH+IEZ4FPKA==
=h3iQ
-----END PGP SIGNATURE-----

--Apple-Mail=_A262450B-CBD3-44EF-B66C-7A466A7433A6--


From nobody Thu Nov 16 01:44:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3C5129406 for ; Thu, 16 Nov 2017 01:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_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=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 LnDUdbAOgmVK for ; Thu, 16 Nov 2017 01:44:08 -0800 (PST)
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 14CE6126C2F for ; Thu, 16 Nov 2017 01:44:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510825446; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=h40g5CuQJKTGGiydiSpDh7RzKHxfsbwuhx+SVGTDmKs=; b=RvA0gYxnG+qhjBo8hTCiFt7nUCeYmRB6s5t5/xphP+t/EAQheV823LXUpJCtatwBYRLKa6FddmVjQuwpyw06UdrNdh4FrhL8z0+HMW5uU83KL8wxuz806AEgKN5T6c0j6Esytk6LuysHXmcnNnuGbhHePgl/SFVj/fvOZJo7Qt0=
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0183.outbound.protection.outlook.com [213.199.154.183]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-133-4kG-Xv7BMFGT3yNlOvmkNA-1; Thu, 16 Nov 2017 09:44:03 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Thu, 16 Nov 2017 09:44:02 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 09:44:02 +0000
From: Tim Chown 
To: Brian E Carpenter 
CC: David Farmer , 6man WG 
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
Thread-Topic: IPv4 traffic on "ietf-v6ONLY"
Thread-Index: AQHTXf8+9vC4sHTDhU2mItXTxkERoKMV0CcAgABOIQCAAAyAgIAABLoAgACTXIA=
Date: Thu, 16 Nov 2017 09:44:02 +0000
Message-ID: 
References:      <72f42d56-2466-dfaa-59e9-ebb2264e8ca4@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.3445.4.7)
x-originating-ip: [194.82.140.195]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 20:fAd+tyLXoI3e4nXE7DjioSv8iNmv4mBarX+i9dSo5PotAl2plX1mUfH4erEbQapmhgrMUJ/0JHLOIFrP6tZN9eoFw0wFhRCLV1KLXyrLhUdUzc3QFESYa9NMlpWvC/v9hrLFIcERrxxIiBJIXUzXRSgNRwcPBHLe9GgV9fX7faQ=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 76289d9b-9f0c-45bd-46c0-08d52cd691fe
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1139; 
x-ms-traffictypediagnostic: AM3PR07MB1139:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1139; 
x-forefront-prvs: 0493852DA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(24454002)(199003)(5660300001)(6246003)(83716003)(93886005)(53546010)(25786009)(53936002)(54906003)(5250100002)(101416001)(106356001)(102836003)(6512007)(105586002)(6916009)(786003)(316002)(33656002)(82746002)(66066001)(3846002)(42882006)(6116002)(229853002)(39060400002)(6486002)(189998001)(76176999)(50986999)(57306001)(6506006)(81156014)(2906002)(72206003)(74482002)(305945005)(2900100001)(3660700001)(14454004)(478600001)(68736007)(86362001)(8936002)(97736004)(2950100002)(36756003)(8676002)(3280700002)(7736002)(81166006)(6436002)(4326008)(99286004)(50226002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; 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-Network-Message-Id: 76289d9b-9f0c-45bd-46c0-08d52cd691fe
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 09:44:02.6308 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139
X-MC-Unique: 4kG-Xv7BMFGT3yNlOvmkNA-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 09:44:11 -0000

PiBPbiAxNiBOb3YgMjAxNywgYXQgMDA6NTYsIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNh
cnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gT24gMTYvMTEvMjAxNyAxMzozOSwgRGF2
aWQgRmFybWVyIHdyb3RlOg0KPj4gT24gV2VkLCBOb3YgMTUsIDIwMTcgYXQgNTo1NCBQTSwgQnJp
YW4gRSBDYXJwZW50ZXIgPA0KPj4gYnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPiB3cm90ZToN
Cj4+IA0KPj4+IE9uIDE2LzExLzIwMTcgMDg6MTUsIGphbWVzIHdvb2R5YXR0IHdyb3RlOg0KPj4+
PiBPbiBOb3YgMTUsIDIwMTcsIGF0IDAyOjQ3LCBQaGlsaXAgSG9tYnVyZyA8cGNoLWlwdjYtaWV0
Zi00QHUtMS5waGljb2guDQo+Pj4gY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gVGhlIHNhZmVz
dCBvcHRpb24gdG8gZG8gdGhhdCBpcyBhIERIQ1B2NCBvcHRpb24gdGhhdCBzYXlzICdubyBJUHY0
DQo+Pj4gc2VydmljZSBoZXJlLCBnbyBhd2F5Jy4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBCZXR0ZXI6
IGV4dGVuZCBBUlAgd2l0aCBhIHNpZ25hbCB0aGF0IHNheXMsIOKAnEFSUCBpcyBub3Qgd2VsY29t
ZSBoZXJlLiINCj4+PiANCj4+PiBIb3dldmVyLCB0aGUgSVB2NCB0cmFmZmljIHNlZW4gb24gaWV0
Zi1kbnM2NCBpcyBuZWdsaWdpYmxlIGFuZCBoYXJtbGVzcy4NCj4+PiBUaGF0IGlzIGEgcHJhY3Rp
Y2FsIGluZGljYXRpb24gdGhhdCB0aGlzIHByb2JsZW0gcHJvYmFibHkgaXNuJ3Qgd29ydGgNCj4+
PiBzb2x2aW5nLg0KPj4+IA0KPj4+IEkgc3VibWl0IGZvciBleGFtcGxlIHRoYXQgc2VuZGluZyBh
IG5ldyAibm90IHdlbGNvbWUiIHJlc3BvbnNlIHRvDQo+Pj4gQVJQIHJlcXVlc3RzIHdvdWxkIGRv
IG1vcmUgaGFybSB0aGFuIGdvb2QsIHNpbmNlIHRoZSBsZWdhY3kgaG9zdHMNCj4+PiB3b3VsZCBw
cm9iYWJseSByZWFjdCBiYWRseS4NCj4+PiANCj4+PiAgIEJyaWFuDQo+Pj4gDQo+PiANCj4+IEkn
ZCBsb3ZlIHRvIHNlZSBzb21lIGRhdGEgdG8gYmFjayB1cCB0aGUgY29uamVjdHVyZSwgdGhhdCBp
cyB0aGUgInRyYWZmaWMNCj4+IC4uLiBpcyBuZWdsaWdpYmxlIGFuZCBoYXJtbGVzcyINCj4gDQo+
IFRoYXQgaXQncyBuZWdsaWdpYmxlIHdhcyBzaG93biBpbiBCb2IgSGluZGVuJ3Mgc3RhdGlzdGlj
cyBmcm9tIFdpcmVzaGFyay4NCj4gVGhhdCBpdCdzIGhhcm1sZXNzIHNlZW1zIG9idmlvdXMgLSBp
dCdzIHZpcnR1YWxseSBhbGwgbXVsdGljYXN0IGRpc2NvdmVyeQ0KPiB0cmFmZmljIHRoYXQgZ29l
cyBub3doZXJlLiBBcyBJIHNhaWQsIEkgaGF2ZSBhIGNvdXBsZSBvZiBjYXB0dXJlIGZpbGVzDQo+
IGlmIGFueWJvZHkgaXMgaW50ZXJlc3RlZC4NCg0KQ2FyZWZ1bCB3aXRoIHRoYXQgZXRoaWNzIGNh
biBvZiB3b3JtcyB5b3XigJlyZSBob2xkaW5nIHRoZXJlIDspDQoNCknigJl2ZSBzZWVuIHNvbWUg
dW5pdmVyc2l0eSBuZXR3b3JrcyB3aGVyZSB0aGUgd2lyZWxlc3MgaXMgc3VycHJpc2luZ2x5IGZs
YXQsIGFuZCB0aGUgbXVsdGljYXN0L2Jyb2FkY2FzdCB0cmFmZmljIGlzIG5vdCBpbnNpZ25pZmlj
YW50LiBUaGUgbW9yZSByZWNlbnQgdHJlbmQgaXMgdG8gVkxBTiBwb29sIG9yIHNpbWlsYXIgdG8g
YXZvaWQgdGhhdCwgYnV0IHRoYXQgdGhlbiBhZmZlY3RzIHNlcnZpY2UgZGlzY292ZXJ5ICh0d28g
V2lGaSBkZXZpY2VzIGluIHNhbWUgcm9vbSwgYnV0IHBvdGVudGlhbGx5IG9uIGRpZmZlcmVudCBz
dWJuZXRzKS4NCg0KVGhlIHNlcnZpY2UgZGlzY292ZXJ5IHRyYWZmaWMgaXMgZ2VuZXJhbGx5IHJl
cGxpY2F0ZWQgb3ZlciBJUHY0IGFuZCBJUHY2OyB5b3XigJlsbCBzZWUgdGhlIHNhbWUgYWR2ZXJ0
aXNlbWVudHMgYW5kIGRpc2NvdmVyeSB0cmFmZmljIGVzc2VudGlhbGx5IGR1cGxpY2F0ZWQuICBC
dXQgdGhpcyBpcyBwb3RlbnRpYWxseSB1c2VmdWwgaW4gc2F5IGEgaG9tZSBuZXR3b3JrIHdoZXJl
IHlvdSBoYXZlIGxlZ2FjeSBkZXZpY2VzIGxpa2UgVFZzIGZvciB3aGljaCB5b3UgY2FuIG9ubHkg
ZGlzY292ZXIgdGhlIGRpc3BsYXkgb3ZlciBJUHY0LCBhbmQgdGhyb3cgZGF0YSB0byBpdCBvdmVy
IElQdjQuIA0KDQpUaGUgbW9kZWwgaW4gdGhlIEROU1NEIFdHIGZvciB3aWRlciBhcmVhIGRpc2Nv
dmVyeSBpcyB0byBrZWVwIHJlc29sdXRpb24gbG9jYWwsIGFuZCByZWxheSB0aGUgcmVzcG9uc2Vz
IGZyb20gdGhlIGRpc2NvdmVyeSBwcm94aWVzIHVzaW5nIHVuaWNhc3QuIA0KDQpUaW0NCg0K


From nobody Thu Nov 16 01:53:10 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFF2129408 for ; Thu, 16 Nov 2017 01:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMgx7GkOJOET for ; Thu, 16 Nov 2017 01:53:06 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A28129458 for ; Thu, 16 Nov 2017 01:51:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510825913; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=kuOyGff1bifmM0vIc2TUpWxOQfKD/BGKl8WOD2tK/u0=; b=S62K+SDSvmxwyBoDm9HmCyzrVHLQ8IAKXPHQCRbzg2a7EuEyP+BIMMHm7YvFHhn5cDSncwazwdB8DhLz3WDiO5GoRVzhz2PcfXsm8pVv6ohT3+4M6XaM15eDZTCe+ApVX0Or3sra/laGvmQZQ/QNLJNi0Fbs65qVeRk05+Q14bI=
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0176.outbound.protection.outlook.com [213.199.180.176]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-112-xj13jgSOMeG4AWXb_5Tsxg-1; Thu, 16 Nov 2017 09:51:49 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Thu, 16 Nov 2017 09:51:47 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 09:51:47 +0000
From: Tim Chown 
To: james woodyatt , Ole Troan , 6man WG , Mark Andrews 
Subject: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
Thread-Topic: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
Thread-Index: AQHTXsCEAUw9kQRqrUWNJp5g3qO1sg==
Date: Thu, 16 Nov 2017 09:51:47 +0000
Message-ID: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>
In-Reply-To: <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.4.7)
x-originating-ip: [194.82.140.195]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 20:6xYg9IrQFAfcCOMoqvnXFgmPsJc14gQXQJnTArzHbHB6yGDMwF2d1VCO1dyBzU4H2xTGmPWc5oQ+epZ8NizFsUrZQqV9LjtYMqXTysZLqR2nL6UQboWQSEe58zPmwlPS36+18ayC4N5U4lJAaF2P7dGb+LiTwl1EvcUbALOTfUc=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 9795c137-0b32-48e7-c1a6-08d52cd7a755
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1139; 
x-ms-traffictypediagnostic: AM3PR07MB1139:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(920507027)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1139; 
x-forefront-prvs: 0493852DA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(24454002)(199003)(5660300001)(83716003)(93886005)(53546010)(25786009)(53936002)(5250100002)(101416001)(106356001)(102836003)(6512007)(105586002)(786003)(316002)(33656002)(82746002)(66066001)(3846002)(42882006)(6116002)(110136005)(6486002)(189998001)(76176999)(50986999)(57306001)(6506006)(81156014)(2906002)(72206003)(74482002)(305945005)(2900100001)(3660700001)(14454004)(478600001)(68736007)(86362001)(8936002)(97736004)(2950100002)(36756003)(8676002)(34040400001)(3280700002)(7736002)(81166006)(6436002)(99286004)(50226002)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <2CCB2863D4F6024FBCA492E8345EC9B0@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 9795c137-0b32-48e7-c1a6-08d52cd7a755
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 09:51:47.9017 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139
X-MC-Unique: xj13jgSOMeG4AWXb_5Tsxg-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 09:53:09 -0000

SGksDQoNCj4gT24gMTUgTm92IDIwMTcsIGF0IDIzOjA0LCBqYW1lcyB3b29keWF0dCA8amh3QGdv
b2dsZS5jb20+IHdyb3RlOg0KPiANCj4gT24gTm92IDE1LCAyMDE3LCBhdCAxMzo0NywgT2xlIFRy
b2FuIDxvdHJvYW5AZW1wbG95ZWVzLm9yZz4gd3JvdGU6DQo+PiANCj4+Pj4gSU1ITyB0aGUgb3B0
aW1hbCBzb2x1dGlvbiBpczoNCj4+Pj4gLSB0aGUgbmV0d29yayBTSE9VTEQgcHJvdmlkZSBhIGhv
c3Qgd2l0aCBOQVQ2NCBwcmVmaXggaW5mb3JtYXRpb24gaW4gUkE7DQo+Pj4gDQo+Pj4gRGlzYWdy
ZWUuIElmIHRoZSBuZXR3b3JrIGhhcyBOQVQ2NCwgdGhlbiBpdCBzaG91bGQgZGVwbG95IFJGQyA3
MjI1LiBZZSBnb2RzLCB0aGlzIGlzIHRoZSB2ZXJ5IGxhc3QgdGhpbmcgdGhhdCBzaG91bGQgYmUg
amFtbWVkIGludG8gUkEgbWVzc2FnZXMuDQo+PiANCj4+IERvIHdlIHJlYWxseSB3YW50IFBDUCBp
biBJUHY2Pw0KPiANCj4gSWYgd2UgaGF2ZSBhbnkga2luZCBvZiBOQVQsIHRoZW4gd2UgbmVlZCBQ
Q1AuIFVzaW5nIE5BVCB3aXRob3V0IFBDUCBjb25zaWRlcmVkIGhhcm1mdWwuIFRoYXQgZ29lcyBm
b3IgTkFUNjQgYW5kIE5BVDY2Lg0KDQpBbmQgUENQIGlzIHN0aWxsIG5lZWRlZCB0byBuZWdvdGlh
dGUgZmlyZXdhbGwgaG9sZXMgaW4gYSBwdXJlIElQdjYgc2NlbmFyaW8sIGlzbuKAmXQgaXQ/ICBB
c3N1bWluZyB0aGUgaG9zdCB3aXRoIFBDUCBpcyBiZWhpbmQgU2ltcGxlIFNlY3VyaXR5Lg0KDQpB
IHF1ZXN0aW9uOiBpcyB0aGlzIHNvbWV0aGluZyB3ZSBzaG91bGQgY29uZHVjZXIgZm9yIFJGQzY0
MzQtYmlzLCBvciBzaG91bGQgd2UgYmUgc2lsZW50IG9uIFBDUD8NCg0KPj4gSXMgUENQIHN1Y2Nl
c3NmdWwgaW4gSVB2ND8NCj4gDQo+IFdlbGwsIHRoZXJlIHdhcyB0aGlzOiA8aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvcHJvY2VlZGluZ3MvODgvc2xpZGVzL3NsaWRlcy04OC1wY3AtNS5wZGY+DQo+IA0K
Pj4gT3IgZG9lcyBpdCBldmVuIHdvcmsgd2VsbCB3aXRoIEErUCBiYXNlZCBzb2x1dGlvbnM/DQo+
IA0KPiBEZXNpZ25lZCBleHByZXNzbHkgZm9yIGl0Lg0KDQpJIGFzc3VtZWQgUENQIHdhcyBkZXNp
Z25lZCB3aXRoIGFuIGV5ZSBmaXJtbHkgb24gZnV0dXJlIHJvdXRlZCBob21lIG5ldHdvcmtzIHdo
ZXJlIGZpcmV3YWxsIGhvbGVzIG5lZWQgdG8gYmUgb3BlbmVkLiBXaGF0IGlzIHRoZSBhbHRlcm5h
dGl2ZT8NCg0KVGlt


From nobody Thu Nov 16 01:53:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9176D126CD6 for ; Thu, 16 Nov 2017 01:53:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7LX1f3jokNk for ; Thu, 16 Nov 2017 01:53:36 -0800 (PST)
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 62DA2129437 for ; Thu, 16 Nov 2017 01:52:48 -0800 (PST)
Received: by mail-pg0-x234.google.com with SMTP id p9so20193106pgc.8 for ; Thu, 16 Nov 2017 01:52:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DewBn3gRztDtyNnrmfaNYw/KmzEQfW0FRaxh41IInz8=; b=tT8Iov249/dWdxibFMpBgGGA6/bOuS9aoD0/FrhaDuRiWv0HBY1CxbskauFPdeMj+S X+RHS4Zuxt5quxfJf24+pQhHvyhFihyp2UXFppRoBlsBcHTQyQD1rJbu/t63DnPaI3bi ywg0gcyL+esaDZM+kCOwIEMiCKDBa0HtAubNV/XzJac6f3lVziejPIJmZgge7FrQEb1G oaV0tqRCCUV5zfS9Umh4RZozSa4PXMVaV8xff5TddWRrgASmkKR39e/gtRZOMWealSEU IgPdu1w/BrLMIShPpQ7u7Kk2v7gS/cki0c+TiV2IB/H2NnBOLqomwtk2DWC4ncDmA69T KdKQ==
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=DewBn3gRztDtyNnrmfaNYw/KmzEQfW0FRaxh41IInz8=; b=Ccw2lqi3RQls/UE5biv/kXtFh99FVF0rzlAd/ZcHqSExJtlQHzhKHoW7vrshb52HT5 kE+F4RGTASKZ8pipLmTS0kdLXKIKVWhKQrpEC5jPcdh1x+8oBP4TyyU9Q3HtY59ZGleY 5U7PSXs8DkMYccbFoqc1/vfEDNebceLJZzXxzWTgMp+fCB0coEE7E60va3T+NNaUtShV 2NY+cPS2RP2T45qvGxPzw3A1pzJmwNYAdbhwhC0Wcbh4Yaqh+yRAkbHYAxeuUYNC33XG r/sZnWhsvLZGDCUEuNr3yIJvA48nOG7YakwKBxoPuGnf4B3/2sCPyJHjZVtEMM80/frO 6Wlw==
X-Gm-Message-State: AJaThX7d7pKI3HcQx1fB8gKE/LsHsh/8QFKUkZ0RpxfhlCFZ5GiRg6o8 RZKrIua4OBEradIdk40k1wXm2w==
X-Google-Smtp-Source: AGs4zMYZkT80M1AhFdXhrfRagCQGIRxltco9P9Melkm6ihxJDdL2QURO4kumtykWq73Hr1AI4VDeew==
X-Received: by 10.101.100.65 with SMTP id s1mr1109967pgv.185.1510825967667; Thu, 16 Nov 2017 01:52:47 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1998:28cc:dc4c:9703:6781? ([2001:67c:370:1998:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id x6sm1867120pgq.57.2017.11.16.01.52.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 01:52:46 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Tim Chown 
Cc: David Farmer , 6man WG 
References:      <72f42d56-2466-dfaa-59e9-ebb2264e8ca4@gmail.com>   
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 16 Nov 2017 22:52:49 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 09:53:38 -0000

On 16/11/2017 22:44, Tim Chown wrote:
>> On 16 Nov 2017, at 00:56, Brian E Carpenter  wrote:
>>
>> On 16/11/2017 13:39, David Farmer wrote:
>>> On Wed, Nov 15, 2017 at 5:54 PM, Brian E Carpenter <
>>> brian.e.carpenter@gmail.com> wrote:
>>>
>>>> On 16/11/2017 08:15, james woodyatt wrote:
>>>>> On Nov 15, 2017, at 02:47, Philip Homburg >>> com> wrote:
>>>>>>
>>>>>> The safest option to do that is a DHCPv4 option that says 'no IPv4=

>>>> service here, go away'.
>>>>>
>>>>>
>>>>> Better: extend ARP with a signal that says, =E2=80=9CARP is not wel=
come here."
>>>>
>>>> However, the IPv4 traffic seen on ietf-dns64 is negligible and harml=
ess.
>>>> That is a practical indication that this problem probably isn't wort=
h
>>>> solving.
>>>>
>>>> I submit for example that sending a new "not welcome" response to
>>>> ARP requests would do more harm than good, since the legacy hosts
>>>> would probably react badly.
>>>>
>>>>   Brian
>>>>
>>>
>>> I'd love to see some data to back up the conjecture, that is the "tra=
ffic
>>> ... is negligible and harmless"
>>
>> That it's negligible was shown in Bob Hinden's statistics from Wiresha=
rk.
>> That it's harmless seems obvious - it's virtually all multicast discov=
ery
>> traffic that goes nowhere. As I said, I have a couple of capture files=

>> if anybody is interested.
>=20
> Careful with that ethics can of worms you=E2=80=99re holding there ;)

Yes, maybe we need to add "IP packets" to the last sentence of the Note W=
ell ;-)

   Brian
=20
> I=E2=80=99ve seen some university networks where the wireless is surpri=
singly flat, and the multicast/broadcast traffic is not insignificant. Th=
e more recent trend is to VLAN pool or similar to avoid that, but that th=
en affects service discovery (two WiFi devices in same room, but potentia=
lly on different subnets).>=20
> The service discovery traffic is generally replicated over IPv4 and IPv=
6;=20
> you=E2=80=99ll see the same advertisements and discovery traffic essent=
ially duplicated.  But this is potentially useful in say a home network w=
here you have legacy devices like TVs for which you can only discover the=
 display over IPv4, and throw data to it over IPv4.=20
>=20
> The model in the DNSSD WG for wider area discovery is to keep resolutio=
n local, and relay the responses from the discovery proxies using unicast=
=2E=20
>=20
> Tim
>=20


From nobody Thu Nov 16 02:32:43 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92ED6127909 for ; Thu, 16 Nov 2017 02:32:41 -0800 (PST)
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 fBFIFCJuJaYj for ; Thu, 16 Nov 2017 02:32:38 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740551200CF for ; Thu, 16 Nov 2017 02:32:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2098; q=dns/txt; s=iport; t=1510828358; x=1512037958; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=HltDUmPQwRjVMWjkjC2bovg13MurvwOpfWmA4SQlJqs=; b=h9fWOfLKoeg1XyGooDPC53wK+1tQNjuRkv5aMLtwOi/+Aa7P9O3DMTQw jlTwFrvIs0ZCJKjj/NQIRwS/gXQ0iHuxk/P5zvBXUTpBazggF/Xr980h9 SZXt9oEcEKLmkm2JfUYnU2dndf08HP90iDGxTz8t6sF+9x0jE2h5jF9TF I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DvAAACaQ1a/5ldJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM2ZG4nB4N4ih+PIIF9ll+CEQoYC4UYAhqEez8YAQEBAQEBAQE?= =?us-ascii?q?BayiFHgEBAQEDAQEhEToXBAIBCA4DAwECAwImAgICJQsVCAgCBAESiiQQqWaCJ?= =?us-ascii?q?4sTAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4IlggeBVYISgwKEZDSDFTGCMgW?= =?us-ascii?q?KNJgHApUIk0iWAwIRGQGBOAEfOIF0ehVJLQGCNoRfd4ocgREBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,402,1505779200"; d="scan'208";a="32223848"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2017 10:32:21 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAGAWLUc012278 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 16 Nov 2017 10:32:21 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 16 Nov 2017 04:32:20 -0600
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, 16 Nov 2017 04:32:20 -0600
From: "Rajiv Asati (rajiva)" 
To: Philip Homburg , "ipv6@ietf.org" 
Subject: Re: IPv4 traffic on "ietf-v6ONLY" 
Thread-Topic: IPv4 traffic on "ietf-v6ONLY" 
Thread-Index: AQHTXg7aCDuXpAYsgk2hw+GoRJ/sAKMXNNOA
Date: Thu, 16 Nov 2017 10:32:20 +0000
Message-ID: 
References:     <0b565be0-e228-0879-ead5-3ba03e6d1c28@gmail.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.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.237.217]
Content-Type: text/plain; charset="utf-8"
Content-ID: <10A1F10E331A6E479E8985EE77844C34@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 10:32:41 -0000

V2hpbGUgSSBkbyBhZ3JlZSB0byBSQSBiZWluZyBiZXR0ZXIgdGhhbiBESENQKHY2KSBmb3IgdGhl
IHB1cnBvc2UgZGlzY3Vzc2VkIGhlcmUsIEkgYWxzbyBhZ3JlZSB3aXRoIFBoaWxpcCB3cnQgTC1m
bGFnIHVzYWdlLiBQdkQgTC1mbGFnID0gMCB3b3VsZCBub3QgcHJvaGliaXQgYSBob3N0IGZyb20g
dXNpbmcgSVB2NCBvbiB0aGUgYWNjZXNzLg0KDQpXZSBtaWdodCBiZSBiZXR0ZXIgb2ZmIGRlZmlu
aW5nIGEgbmV3IGZsYWcgdGhhdCBleHBsaWNpdGx5IGluZGljYXRlcyBmb3IgaG9zdCB0byDigJhT
dXBwcmVzcyBJUHY04oCZLiANCg0KLS0gDQpDaGVlcnMsDQpSYWppdiAgDQoNCi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHY2IDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl
aGFsZiBvZiBQaGlsaXAgSG9tYnVyZyA8cGNoLWlwdjYtaWV0Zi00QHUtMS5waGljb2guY29tPg0K
RGF0ZTogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyBhdCA3OjQwIEFNDQpUbzogImlwdjZA
aWV0Zi5vcmciIDxpcHY2QGlldGYub3JnPg0KU3ViamVjdDogUmU6IElQdjQgdHJhZmZpYyBvbiAi
aWV0Zi12Nk9OTFkiIA0KDQogICAgPlRoZXJlJ3MgYW4gTCBmbGFnIGluIGRyYWZ0LWlldGYtaW50
YXJlYS1wcm92aXNpb25pbmctZG9tYWlucw0KICAgID50aGF0IHNheXMgIkRIQ1AodjQpIG9uIHRo
aXMgbmV0d29yayIuIFNvIEw9MCBzYXlzICJObyBESENQKHY0KSBvbg0KICAgID50aGlzIG5ldHdv
cmsiLg0KICAgIA0KICAgIE1heWJlIEknbSByZWFkaW5nIHRoZSBkcmFmdCB0b28gc3RyaWN0bHks
IGJ1dCBpdCBzZWVtcyB0aGF0IHRoZSBMIGZsYWcgaXMgdXNlZA0KICAgIHRvIHRlbGwgd2hpY2gg
cHJvdmlzaW9uaW5nIGRvbWFpbiBESENQdjQgaW5mb3JtYXRpb24gYmVsb25ncyB0by4gTm90IHRv
IHRlbGwNCiAgICBhIGhvc3QgdG8gYXZvaWQgdXNpbmcgREhDUHY0IGluIHRoZSBmaXJzdCBwbGFj
ZS4NCiAgICANCiAgICBJZiBpdCBkb2VzIGhhdmUgdGhlIGludGVudGlvbiB0byBtYWtlIGhvc3Rz
IGF2b2lkIERIQ1B2NCByZXF1ZXN0cyB0aGVuIGl0DQogICAgaGFzIHRoZSBzYW1lIGRyYXdiYWNr
IGFzIGluIHNlbmRpbmcgYSAnbm8gSVB2NCcgb3B0aW9uIGluIFJBIG9yIERIQ1B2NjoNCiAgICBp
biBhbiBJUHY0LW9ubHkgbmV0d29yayB0aGF0IGNhbiBiZSB1c2VkIHRvIHByZXZlbnQgaG9zdHMg
ZnJvbSBjb25uZWN0aW5nIHRvDQogICAgdGhlIG5ldHdvcmsuDQogICAgDQogICAgLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCiAgICBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCiAgICBpcHY2QGll
dGYub3JnDQogICAgQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vaXB2Ng0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgDQoNCg==


From nobody Thu Nov 16 02:40:01 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888E2127909 for ; Thu, 16 Nov 2017 02:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cFc-qcrUk_g for ; Thu, 16 Nov 2017 02:39:58 -0800 (PST)
Received: from moth.iki.fi (moth.iki.fi [212.16.111.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20B0128B27 for ; Thu, 16 Nov 2017 02:39:58 -0800 (PST)
Received: from [130.188.13.201] (201.13.vtt.fi [130.188.13.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: msa) by moth.iki.fi (Postfix) with ESMTPSA id 823BD2A00B4 for ; Thu, 16 Nov 2017 12:38:30 +0200 (EET)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:     <0b565be0-e228-0879-ead5-3ba03e6d1c28@gmail.com>  
From: Markku Savela 
Message-ID: <85f11a44-6fb1-2a31-193c-bc2d6b42f52b@moth.iki.fi>
Date: Thu, 16 Nov 2017 12:39:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 10:40:00 -0000

On 16/11/17 12:32, Rajiv Asati (rajiva) wrote:
> While I do agree to RA being better than DHCP(v6) for the purpose discussed here, I also agree with Philip wrt L-flag usage. PvD L-flag = 0 would not prohibit a host from using IPv4 on the access.
> 
> We might be better off defining a new flag that explicitly indicates for host to ‘Suppress IPv4’.
> 

And, if the local network has multiple independent routers, this flag 
would be confusing, if one router says "Suppress IPv4", and the other 
provides IPv4 routing? A flag could just be "advisory"...


From nobody Thu Nov 16 02:41:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D081128B27 for ; Thu, 16 Nov 2017 02:41:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHC9GeRe_F-l for ; Thu, 16 Nov 2017 02:41:41 -0800 (PST)
Received: from moth.iki.fi (moth.iki.fi [IPv6:2a00:1c30:3:2::111:74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B03127873 for ; Thu, 16 Nov 2017 02:41:41 -0800 (PST)
Received: from [130.188.13.201] (201.13.vtt.fi [130.188.13.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: msa) by moth.iki.fi (Postfix) with ESMTPSA id 4FB612A00B4 for ; Thu, 16 Nov 2017 12:40:13 +0200 (EET)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:     <0b565be0-e228-0879-ead5-3ba03e6d1c28@gmail.com>   <85f11a44-6fb1-2a31-193c-bc2d6b42f52b@moth.iki.fi>
From: Markku Savela 
Message-ID: 
Date: Thu, 16 Nov 2017 12:41:39 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <85f11a44-6fb1-2a31-193c-bc2d6b42f52b@moth.iki.fi>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 10:41:42 -0000

On 16/11/17 12:39, Markku Savela wrote:
> On 16/11/17 12:32, Rajiv Asati (rajiva) wrote:
>> While I do agree to RA being better than DHCP(v6) for the purpose 
>> discussed here, I also agree with Philip wrt L-flag usage. PvD L-flag 
>> = 0 would not prohibit a host from using IPv4 on the access.
>>
>> We might be better off defining a new flag that explicitly indicates 
>> for host to ‘Suppress IPv4’.
>>
> 
> And, if the local network has multiple independent routers, this flag 
> would be confusing, if one router says "Suppress IPv4", and the other 
> provides IPv4 routing? A flag could just be "advisory"...

...or, sorry.. is this discussion about WiFi only?


From nobody Thu Nov 16 02:42:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9897128D6F for ; Thu, 16 Nov 2017 02:42:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 kjuAjRRNvaUO for ; Thu, 16 Nov 2017 02:42:48 -0800 (PST)
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 0D93A127873 for ; Thu, 16 Nov 2017 02:42:48 -0800 (PST)
Received: by mail-yw0-x22c.google.com with SMTP id q1so19002544ywh.5 for ; Thu, 16 Nov 2017 02:42:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ijAAsE0nCQENW/tss+EaqTD99AkJYKQ6b1mxTzbE5B8=; b=Ok31KApcV/JTku8TwHmTOmLvf/Jysj6nbwsY1dYXDLpYQaVMqPqSbx5AF8vnUwJ+YI hq5SbIUtimNJN9z3MB1moG5TePtTtOfvHv8cwepu2jAWJvW7BayedM3OzXNltjWvz0Bu lMetz2LA5FCkMQAMOy+JWTXaV4KjkpBEL0+4bgmeoT6Nfvuq5p1KcL0tyotCuMiKtHen JKbLeyR12U+7675wXk5w8uqux5pNHNGfCB61MwxH90MTeSOMELye3SiIrUdrYsaLBrna /m2xgHP527Ho9kb4kgGhlsP3oVyjwdI0o8sqPU03DshbPih16mUMhe3USHj3A+YClmw1 T8oA==
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=ijAAsE0nCQENW/tss+EaqTD99AkJYKQ6b1mxTzbE5B8=; b=qQPf7Llbi+9ybEmiHTazOr2a/3vmtvOlxvksD6ev1U5ajjbVthCKwfEd41M77irSPb B82F0Z8K5rc8nN5r4FSmUqETk7KQBjbLokMUNuqFIH1FeflIL3Biwstta+a6VYJ/ZQ8k 2v+yOcr4HVG5t56esd9dbG4xAoZKmqPeQoLHYmU0hjWeA4LC6HL8c8+VlpQCsvA0lSJ6 ei1l5Tdx8apduHU69jXedVB2LtjxKIYUHZrtpqFt6limQjBv4NJYvBUFZll9rEg9E+4h ObpfRaEpAAHk6FWIPg+MWQmi0RCaE8JWo7SbkPBBl4WKffPilKMOpp4ioTV9+lbHDXDd z+Hg==
X-Gm-Message-State: AJaThX6brrYP73rgnaKC93ZH6v5Rxtioekx5NdxXdBnGck597y9floMW 8KjxLJWh2i6A0EbPOeK/VB9qa0cMnYZX3cUtQvaD/YEK
X-Google-Smtp-Source: AGs4zMYuBxskMhAQ0RSn/Yug44evnYqUCm0wvCIfnlnWYd0m3MTqt5TYv27iDe0zwsdD/yUP2qed7TeeDU63pphrsPw=
X-Received: by 10.37.129.129 with SMTP id p1mr603104ybk.273.1510828966911; Thu, 16 Nov 2017 02:42:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.5.146 with HTTP; Thu, 16 Nov 2017 02:42:26 -0800 (PST)
In-Reply-To: <85f11a44-6fb1-2a31-193c-bc2d6b42f52b@moth.iki.fi>
References:     <0b565be0-e228-0879-ead5-3ba03e6d1c28@gmail.com>   <85f11a44-6fb1-2a31-193c-bc2d6b42f52b@moth.iki.fi>
From: Erik Kline 
Date: Thu, 16 Nov 2017 10:42:26 +0000
Message-ID: 
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Markku Savela 
Cc: IETF IPv6 Mailing List 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="089e08267ee0ed2b3b055e174710"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 10:42:50 -0000

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

On 16 November 2017 at 10:39, Markku Savela  wrote:
> On 16/11/17 12:32, Rajiv Asati (rajiva) wrote:
>>
>> While I do agree to RA being better than DHCP(v6) for the purpose
>> discussed here, I also agree with Philip wrt L-flag usage. PvD L-flag =
=3D 0
>> would not prohibit a host from using IPv4 on the access.
>>
>> We might be better off defining a new flag that explicitly indicates for
>> host to =E2=80=98Suppress IPv4=E2=80=99.
>>
>
> And, if the local network has multiple independent routers, this flag wou=
ld
> be confusing, if one router says "Suppress IPv4", and the other provides
> IPv4 routing? A flag could just be "advisory"...

Since it would be new, it would almost inherently be advisory.

It could be the first flag in the EFO!  (if I'm not mistaken...)

--089e08267ee0ed2b3b055e174710
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgkyqyjysfGUXqhOC6SjtEhgGf8EIZqaEN
DDE5evB7pjcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTE2
MTA0MjQ3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAIye1zHklV4I1iEFK9MCvXhtjppd6Pv9iGaJ8DxN5UKpA2svGPll
CvsM497o5hkw2Xc1b47mFMrlK8DwhqjXK4nlS73gqv1jXr3RByV1/BaFNDdN3PudFdHmseVF4//N
YzTKr9IJ3pWWHj016/me/2rkSxQ2H9WizyX2UebHBummbQvM0dZ6g6b6M26kYDm4WmaEoh/Dz3V2
MhabVll3j4w0rVNO3Ob0Q1tUl1q36tE+IeUf1T4uXRrrKWYqW7nhJw3SbicepNAdFX52ozlBCp/i
oArNeFD6rJB/+PHUdiMD0xvvOjqfqpUX9n7+cxWh63/2yjMaKmy8UtVkOewnE6Y=
--089e08267ee0ed2b3b055e174710--


From nobody Thu Nov 16 04:42:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439F71294E2 for ; Thu, 16 Nov 2017 04:42:16 -0800 (PST)
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 IJpQxX3amJJt for ; Thu, 16 Nov 2017 04:42:14 -0800 (PST)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13BA51294E1 for ; Thu, 16 Nov 2017 04:42:13 -0800 (PST)
Received: by mail-yw0-x234.google.com with SMTP id g204so7586402ywa.6 for ; Thu, 16 Nov 2017 04:42:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Bhr6HANefIL2t8mz/eckFt+PiySaibeQiHvL1BBdY0o=; b=fN8B4FYT+6E1AXOQwHa2fvUmLxxh4z8eEsI6YYnA1oLGWOmPX4DObz82Wv9zO6ZqNx U6+VnyN5R+dOa0zvQyGag0xuReGLaYg7Lw8J6h7fJD4froP8511gwqTteXdUjM88/PkI VEWx51yGNI/dAuV4dulql8fEDz1WQhOtSJWfV4UKtSZk4NOab6q3cHkkC9Hc60N/A3L3 2+4Tmzr9Czb0ChFp90XXsthnamBzts+FP7NHXs7O30tPilra2YAJt2ZlDV/g7V56tgKh fYMTleQkoGfW+lKI/lXI4J5DboQPE3vzDJ8VzjJ+lt0Eys+a9WkIf8HrJA35EMAE2uq3 l9SQ==
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=Bhr6HANefIL2t8mz/eckFt+PiySaibeQiHvL1BBdY0o=; b=bM51orvM/Vpeje21qVNVLkDsP5PShaUNpFQFuOYgsl5ktK/8qzsSFla5spQaXfATbs SNu3eMJjc+vH26EiVwIc4cd4QVdAq8uqIfrPXaHj2/C3t2SlEF9o9ekduB4hYz959IZh 3ET67hdLu94wPImlZrPCJuvWJpjIQ0FI88SCe7kmVLPYOGctJXc9RmxTNjBlFs6UeVIT bN4KzlOsiI3yNiKArEhNOGyQ3N019Bxlq88e+4xm+7wmrUiy6KYYVBm2yun7bxj1U3Km YdZtfWTix9IIcCgDSOe2LIkY/4CzF5vVBtRZDrSDILqO9SimRLr5SFe0qtH83e1O5Z3o o4mA==
X-Gm-Message-State: AJaThX6CvBk/cdXuFoFquntyy3AP6ZygcQS2FnLhvCna+/oeGjQOP3vN Ri4vuyaBRqfUIMao5Oz2hiKqjITJWaTteCwiS8M=
X-Google-Smtp-Source: AGs4zMacnOnBz3WEA6a1kqh0g2izfxGwT9qPSUO4oJdUnwUXJ0QDPbjS8pVcXpuiKERtDzL6p167dEFb2CMabtyDIPE=
X-Received: by 10.37.130.11 with SMTP id q11mr757321ybk.50.1510836132335; Thu, 16 Nov 2017 04:42:12 -0800 (PST)
MIME-Version: 1.0
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com> 
In-Reply-To: 
From: Ca By 
Date: Thu, 16 Nov 2017 12:42:01 +0000
Message-ID: 
Subject: Re: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
To: Tim Chown 
Cc: 6man WG , Mark Andrews , Ole Troan , james woodyatt 
Content-Type: multipart/alternative; boundary="089e0828c20cfb58de055e18f28e"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 12:42:16 -0000

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

On Thu, Nov 16, 2017 at 1:53 AM Tim Chown  wrote:

> Hi,
>
> > On 15 Nov 2017, at 23:04, james woodyatt  wrote:
> >
> > On Nov 15, 2017, at 13:47, Ole Troan  wrote:
> >>
> >>>> IMHO the optimal solution is:
> >>>> - the network SHOULD provide a host with NAT64 prefix information in
> RA;
> >>>
> >>> Disagree. If the network has NAT64, then it should deploy RFC 7225. Y=
e
> gods, this is the very last thing that should be jammed into RA messages.
> >>
> >> Do we really want PCP in IPv6?
> >
> > If we have any kind of NAT, then we need PCP. Using NAT without PCP
> considered harmful. That goes for NAT64 and NAT66.
>
> And PCP is still needed to negotiate firewall holes in a pure IPv6
> scenario, isn=E2=80=99t it?  Assuming the host with PCP is behind Simple =
Security.
>
> A question: is this something we should conducer for RFC6434-bis, or
> should we be silent on PCP?
>

No


> >> Is PCP successful in IPv4?
> >
> > Well, there was this: <
> https://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf>
> >
> >> Or does it even work well with A+P based solutions?
> >
> > Designed expressly for it.
>
> I assumed PCP was designed with an eye firmly on future routed home
> networks where firewall holes need to be opened. What is the alternative?
>

The alternative is secure host and no firewall. There is no firewall at the
ietf conference right now, right?  Are you secure ? Is there a malware
outbreak?

The fatal flaw in PCP (aside from the name) is that it assumes the host
needs protection yet it gives the host the power to control the firewall.
Next gen malware will come via email (just like today), it will encrypt
your hard drive, and then setup and c2 network on your pc via pcp
controls.  Sad!

CB


> Tim
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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



On Thu, Nov 16, 2017 =
at 1:53 AM Tim Chown <Tim.Chown@=
jisc.ac.uk> wrote:
Hi,



> On 15 Nov 2017, at 23:04, james woodyatt <jhw@google.com> wrote:

>

> On Nov 15, 2017, at 13:47, Ole Troan <otroan@employees.org> wrote:

>>

>>>> IMHO the optimal solution is:

>>>> - the network SHOULD provide a host with NAT64 prefix info=
rmation in RA;

>>>

>>> Disagree. If the network has NAT64, then it should deploy RFC =
7225. Ye gods, this is the very last thing that should be jammed into RA me=
ssages.

>>

>> Do we really want PCP in IPv6?

>

> If we have any kind of NAT, then we need PCP. Using NAT without PCP co=
nsidered harmful. That goes for NAT64 and NAT66.



And PCP is still needed to negotiate firewall holes in a pure IPv6 scenario=
, isn=E2=80=99t it?=C2=A0 Assuming the host with PCP is behind Simple Secur=
ity.



A question: is this something we should conducer for RFC6434-bis, or should=
 we be silent on PCP?



No=C2=A0



>> Is PCP successful in IPv4?

>

> Well, there was this: <https:/=
/www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf>

>

>> Or does it even work well with A+P based solutions?

>

> Designed expressly for it.



I assumed PCP was designed with an eye firmly on future routed home network=
s where firewall holes need to be opened. What is the alternative?



The alternative =
is secure host and no firewall. There is no firewall at the ietf conference=
 right now, right?=C2=A0 Are you secure ? Is there a malware outbreak?

The fatal flaw in PCP (aside=
 from the name) is that it assumes the host needs protection yet it gives t=
he host the power to control the firewall.=C2=A0 Next gen malware will come=
 via email (just like today), it will encrypt your hard drive, and then set=
up and c2 network on your pc via pcp controls.=C2=A0 Sad!

CB



Tim

--------------------------------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/list=
info/ipv6

--------------------------------------------------------------------




--089e0828c20cfb58de055e18f28e--


From nobody Thu Nov 16 05:42:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC8D1294CF for ; Thu, 16 Nov 2017 05:42:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 TwF9tN6K4zc0 for ; Thu, 16 Nov 2017 05:42:28 -0800 (PST)
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 7E9F1124B18 for ; Thu, 16 Nov 2017 05:42:28 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 01930C04 for ; Thu, 16 Nov 2017 13:42:28 +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 hN1IezL1v54O for ; Thu, 16 Nov 2017 07:42:27 -0600 (CST)
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 6D329C0F for ; Thu, 16 Nov 2017 07:42:27 -0600 (CST)
Received: by mail-lf0-f72.google.com with SMTP id o41so1329032lfi.18 for ; Thu, 16 Nov 2017 05:42:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9C23F8LiPNT8LjPUTkbagSJcUdwtZoYAFGgatNOK9GM=; b=HgSW1hpwEzBfHol7dt14CiISiSdzzheKiIWDD+8bNB2K5XDs5BG5EGViRTDriFcHTb KP/rJfHoWR7SDA1EHw28j8LHQ/fMA81ymf7M+fE0cb9E/7w55B2PQvjgUaU3oVaSOOIQ xNARaOq7l7PHe7pPhcYNidJQWwAjmX3QTksobWk58jX12UU2PrUGv9ocjSb759ljTvBR Pk6PPa/BtW5Av3bMuxeehcZhZXNZtDGlJ89zeFVHoCVYjr8dj4+I1J2LdpBK8VOCE2kA NmYxUIBPHQJuXPh59VXS1IejiOh+ZCczCi67oRdMKZVxcSGAkXo628AUBgr2gQrKGzFj wdmA==
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=9C23F8LiPNT8LjPUTkbagSJcUdwtZoYAFGgatNOK9GM=; b=LLco8nZO6QBrUsPtKm4X+QzzxH4EilcJsK6eBa+LRR86b482H8ybykgDvhGDnhGp5M s4yZ7Arz2fIhtwZkc1aCm4KxN2ptnhJttvfjmLQC20rfrqcs6pdhBppnC332I8Ga3ERI CkP7VjFRx29DvXkFLWJlX9q0vp36Wd3waMVh7lD3Rx7idfEoGWQBVH5fGC4wWlcwsIo3 870MdQzS/8Kw3u80sGdYml1DD35vFA8xLc1GAOFSKVHXSV+wfacW40FR2iPQ7zXmRtbE Wn4ePpbF162xoosG7j2JoIow9ajJ/wDdwkFkZWBzn5yWYczP+z19TRxm2i9Lu1LeMBmT Qemw==
X-Gm-Message-State: AJaThX5ITJZQ9UzqyrNG7lPCK6YpywaWii9W535k2fJUX3TJCaw5rUP+ y0uxK0hkuR3v94aa89krFi84EInqixyE5SDO4QuUjP/TgN536q/Tl6o1SwTuiclPjidvE9lvN+S yiV579vmo9Ep6Ia0xNsOc50YW
X-Received: by 10.25.158.210 with SMTP id h201mr665421lfe.177.1510839745662; Thu, 16 Nov 2017 05:42:25 -0800 (PST)
X-Google-Smtp-Source: AGs4zMbkf+bCOvNZ2rnQDkBjktrn6h/ZTgZ8ljpezulj4tDhdZKgK/PfzxfjSBtA19FMc/kdBAK8/CgpBfBQWbH+2Cs=
X-Received: by 10.25.158.210 with SMTP id h201mr665416lfe.177.1510839745284; Thu, 16 Nov 2017 05:42:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Thu, 16 Nov 2017 05:42:24 -0800 (PST)
In-Reply-To: 
References:     <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com> 
From: David Farmer 
Date: Thu, 16 Nov 2017 07:42:24 -0600
Message-ID: 
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Philip Homburg 
Cc: 6man WG 
Content-Type: multipart/alternative; boundary="001a114030cc54acb5055e19ca2a"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 13:42:30 -0000

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

On Wed, Nov 15, 2017 at 5:21 AM, Philip Homburg  wrote:

> >     Perhaps, define a DHCPv6 option to convey v6-only, for which
> >     the client interpretation should be to suppress v4.  Although
> >    this will be at the cross road with allowing client's wishes to
> >    use v4 LL for whatever useless/useful traffic, it would be a
> >    reasonable deployment policy to enforce.
>
> The problem with a DHCPv6 option is that an IPv4-only network may not be
> prepared to defend against rogue DHCPv6 servers.
>
> So anyone who starts such a server can kick everybody else of the IPv4
> network.
>
> Great option for an overcrowded hotel or conference network.
>

Sorry, but that ship has sailed. If you are purposefully IPv4-only, you
have to deal with rogue IPv6 RAs at least, and probably rogue DHCPv6
servers too, or you need to filter ethertype 0x86DD altogether. Otherwise,
a rogue signal to turn off IPv4 is the least of your worries.  Malicious or
even accidental deployment of IPv6 is a bigger security worry on these
networks than a rogue signal to turn off IPv4.

I'm not saying that a rogue signal to turn off IPv4 isn't a problem. Just
if your willing to ignore rogue IPv6 deployment, then worrying about a
rogue signal to turn off IPv4 seems kind of selective.

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>
===============================================

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



=
On Wed, Nov 15, 2017 at 5:21 AM, Philip Homburg <pch-ipv6-iet=
f-4@u-1.phicoh.com> wrote:
>=C2=A0 =C2=A0 =C2=A0Perhaps, define a DHCPv6 op=
tion to convey v6-only, for which

>=C2=A0 =C2=A0 =C2=A0the client interpretation should be to suppress v4.=
=C2=A0 Although

>=C2=A0 =C2=A0 this will be at the cross road with allowing client's=
 wishes to

>=C2=A0 =C2=A0 use v4 LL for whatever useless/useful traffic, it would b=
e a

>=C2=A0 =C2=A0 reasonable deployment policy to enforce.



The problem with a DHCPv6 option is that an IPv4-only network may not be
prepared to defend against rogue DHCPv6 servers.



So anyone who starts such a server can kick everybody else of the IPv4 netw=
ork.



Great option for an overcrowded hotel or conference network.

Sorry, but that ship has sailed. If you are purposefu=
lly IPv4-only, you have to deal with rogue IPv6 RAs at least, and probably =
rogue=C2=A0DHCPv6 servers too, or you need to filter ethertype 0x86DD altog=
ether. Otherwise, a rogue signal to turn off IPv4 is the least of your worr=
ies.=C2=A0 Malicious or even accidental deployment of IPv6 is a bigger secu=
rity worry on these networks than a rogue signal to turn off IPv4.=C2=A0

I'm not saying that a rogue signal to turn off I=
Pv4 isn't a problem. Just if your willing to ignore rogue IPv6 deployme=
nt, then worrying about a rogue signal to turn off IPv4 seems kind of selec=
tive.

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 & 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 




--001a114030cc54acb5055e19ca2a--


From nobody Thu Nov 16 05:59:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C886E129434 for ; Thu, 16 Nov 2017 05:59:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WddbTr5HHXAi for ; Thu, 16 Nov 2017 05:59:42 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC84F1293F3 for ; Thu, 16 Nov 2017 05:59:42 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAGDxfnn015514 for ; Thu, 16 Nov 2017 14:59:41 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 238C8207E18 for ; Thu, 16 Nov 2017 14:59:41 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 194C6207E0A for ; Thu, 16 Nov 2017 14:59:41 +0100 (CET)
Received: from [132.166.85.78] ([132.166.85.78]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAGDxdUp019785 for ; Thu, 16 Nov 2017 14:59:40 +0100
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:     <0b565be0-e228-0879-ead5-3ba03e6d1c28@gmail.com>   <85f11a44-6fb1-2a31-193c-bc2d6b42f52b@moth.iki.fi> 
From: Alexandre Petrescu 
Message-ID: <6a515876-c9ae-ffc0-b180-27931a2442a7@gmail.com>
Date: Thu, 16 Nov 2017 14:59:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 13:59:45 -0000

Le 16/11/2017 à 11:41, Markku Savela a écrit :
> On 16/11/17 12:39, Markku Savela wrote:
>> On 16/11/17 12:32, Rajiv Asati (rajiva) wrote:
>>> While I do agree to RA being better than DHCP(v6) for the purpose 
>>> discussed here, I also agree with Philip wrt L-flag usage. PvD L-flag 
>>> = 0 would not prohibit a host from using IPv4 on the access.
>>>
>>> We might be better off defining a new flag that explicitly indicates 
>>> for host to ‘Suppress IPv4’.
>>>
>>
>> And, if the local network has multiple independent routers, this flag 
>> would be confusing, if one router says "Suppress IPv4", and the other 
>> provides IPv4 routing? A flag could just be "advisory"...
> 
> ...or, sorry.. is this discussion about WiFi only?

There is same IPv4 traffic on the Ethernet in Terminal Room too.  The 
Ethernet Terminal Room was not announced as "IPv6 only" or as "NAT64" 
but that's the way it acts: ping 8.8.8.8 blocked.

The question is whether Ethernet Terminal Room is configured as "IPv6 
only" or as NAT64.

(and yes, I did file tickets about this at the URL provided by Brian; 
and not only me filed such tickets).

Alex

> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Thu Nov 16 06:07:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3AC1294F0 for ; Thu, 16 Nov 2017 06:07:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0XMfPyipzy3 for ; Thu, 16 Nov 2017 06:07:01 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1937C12954B for ; Thu, 16 Nov 2017 06:06:58 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAGE6vwx120260 for ; Thu, 16 Nov 2017 15:06:57 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0CE83204647 for ; Thu, 16 Nov 2017 15:06:57 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id F19B7202775 for ; Thu, 16 Nov 2017 15:06:56 +0100 (CET)
Received: from [132.166.85.78] ([132.166.85.78]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAGE6tIF031520 for ; Thu, 16 Nov 2017 15:06:56 +0100
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:     <0b565be0-e228-0879-ead5-3ba03e6d1c28@gmail.com>   <85f11a44-6fb1-2a31-193c-bc2d6b42f52b@moth.iki.fi>
From: Alexandre Petrescu 
Message-ID: 
Date: Thu, 16 Nov 2017 15:06:54 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <85f11a44-6fb1-2a31-193c-bc2d6b42f52b@moth.iki.fi>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 14:07:04 -0000

Le 16/11/2017 à 11:39, Markku Savela a écrit :
> On 16/11/17 12:32, Rajiv Asati (rajiva) wrote:
>> While I do agree to RA being better than DHCP(v6) for the purpose 
>> discussed here, I also agree with Philip wrt L-flag usage. PvD L-flag 
>> = 0 would not prohibit a host from using IPv4 on the access.
>>
>> We might be better off defining a new flag that explicitly indicates 
>> for host to ‘Suppress IPv4’.
>>
> 
> And, if the local network has multiple independent routers, this flag 
> would be confusing, if one router says "Suppress IPv4", and the other 
> provides IPv4 routing? A flag could just be "advisory"...

Advisory sounds good.

We could also consider our Terminology before calling Host or Network 
"IPv6 Only".

And, I am not opposing full IPv6 together with full IPv4 on ietf SSID, 
which is what happens now.

I do disagree when a critical access plug, such as Ethernet in Terminal 
Room, refuses ping 8.8.8.8.

Alex

> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Thu Nov 16 07:10:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAFA129423 for ; Thu, 16 Nov 2017 07:10:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_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=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 GDElGCq74yhY for ; Thu, 16 Nov 2017 07:10:42 -0800 (PST)
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 992B0129562 for ; Thu, 16 Nov 2017 07:10:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510845040; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=cI9qPdIde5GEyoH9VPaohNEYYtem6wtvAPKTW5eHKIE=; b=SxUUhI6hUN4bVdCp3vH/Su/2GWDJMIPknoyetv2xxhadMNrQgNnjQU0mGVvs7+Cz0ojQho5T3k+JKD4B3ncNh70o0YsvTG1iBgQ5I6jMA6RyDrCEmGTDUNxVnS1oq9L44u3B+2wHHHFplhSFC9ShKQr1MTJUIqd1elgP78+2Brk=
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0209.outbound.protection.outlook.com [213.199.154.209]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-111-MLAyu4guMPWxp5DlWE9IGA-1; Thu, 16 Nov 2017 15:10:36 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.2; Thu, 16 Nov 2017 15:10:35 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 15:10:35 +0000
From: Tim Chown 
To: David Farmer 
CC: Philip Homburg , 6man WG 
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
Thread-Topic: IPv4 traffic on "ietf-v6ONLY"
Thread-Index: AQHTXuC79vC4sHTDhU2mItXTxkERoKMXHFgA
Date: Thu, 16 Nov 2017 15:10:35 +0000
Message-ID: <7BDA3AE4-E7DE-4859-8ADC-758D6C49215F@jisc.ac.uk>
References:     <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.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.3445.4.7)
x-originating-ip: [194.82.140.195]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 20:pPa85q5AxriQ8qR/1D6qVmx9P4kJ5FxRyPN5td6Hy80sAunX8eChicABDih2PYG0tJYL5WBuIun2FqT04LmFX7B9V+cg96UpFObO3IAffZXU4ZeC6o7vaVvn7QY0/miHKwuTWTHNo9gPw+jkUj657FtddACJx/8yhtICUq/yN2g=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 529f4ea9-06f8-44de-b81b-08d52d043024
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1137; 
x-ms-traffictypediagnostic: AM3PR07MB1137:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(8104003914727); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231022)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1137; 
x-forefront-prvs: 0493852DA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(24454002)(189002)(199003)(229853002)(82746002)(7736002)(25786009)(54906003)(305945005)(74482002)(786003)(4326008)(57306001)(316002)(189998001)(53936002)(50986999)(99286004)(2900100001)(102836003)(6116002)(2171002)(6916009)(53546010)(42882006)(76176999)(83716003)(106356001)(2950100002)(3846002)(33656002)(6246003)(97736004)(6512007)(5660300001)(50226002)(6486002)(86362001)(66066001)(478600001)(101416001)(3660700001)(8676002)(36756003)(6436002)(68736007)(72206003)(2906002)(5250100002)(105586002)(81156014)(6506006)(8936002)(14454004)(3280700002)(81166006)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <9CFF18A5DA00DE4A9AB725ED1732286C@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 529f4ea9-06f8-44de-b81b-08d52d043024
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 15:10:35.2687 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137
X-MC-Unique: MLAyu4guMPWxp5DlWE9IGA-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 15:10:45 -0000

PiBPbiAxNiBOb3YgMjAxNywgYXQgMTM6NDIsIERhdmlkIEZhcm1lciA8ZmFybWVyQHVtbi5lZHU+
IHdyb3RlOg0KPiANCj4gT24gV2VkLCBOb3YgMTUsIDIwMTcgYXQgNToyMSBBTSwgUGhpbGlwIEhv
bWJ1cmcgPHBjaC1pcHY2LWlldGYtNEB1LTEucGhpY29oLmNvbT4gd3JvdGU6DQo+ID4gICAgIFBl
cmhhcHMsIGRlZmluZSBhIERIQ1B2NiBvcHRpb24gdG8gY29udmV5IHY2LW9ubHksIGZvciB3aGlj
aA0KPiA+ICAgICB0aGUgY2xpZW50IGludGVycHJldGF0aW9uIHNob3VsZCBiZSB0byBzdXBwcmVz
cyB2NC4gIEFsdGhvdWdoDQo+ID4gICAgdGhpcyB3aWxsIGJlIGF0IHRoZSBjcm9zcyByb2FkIHdp
dGggYWxsb3dpbmcgY2xpZW50J3Mgd2lzaGVzIHRvDQo+ID4gICAgdXNlIHY0IExMIGZvciB3aGF0
ZXZlciB1c2VsZXNzL3VzZWZ1bCB0cmFmZmljLCBpdCB3b3VsZCBiZSBhDQo+ID4gICAgcmVhc29u
YWJsZSBkZXBsb3ltZW50IHBvbGljeSB0byBlbmZvcmNlLg0KPiANCj4gVGhlIHByb2JsZW0gd2l0
aCBhIERIQ1B2NiBvcHRpb24gaXMgdGhhdCBhbiBJUHY0LW9ubHkgbmV0d29yayBtYXkgbm90IGJl
DQo+IHByZXBhcmVkIHRvIGRlZmVuZCBhZ2FpbnN0IHJvZ3VlIERIQ1B2NiBzZXJ2ZXJzLg0KPiAN
Cj4gU28gYW55b25lIHdobyBzdGFydHMgc3VjaCBhIHNlcnZlciBjYW4ga2ljayBldmVyeWJvZHkg
ZWxzZSBvZiB0aGUgSVB2NCBuZXR3b3JrLg0KPiANCj4gR3JlYXQgb3B0aW9uIGZvciBhbiBvdmVy
Y3Jvd2RlZCBob3RlbCBvciBjb25mZXJlbmNlIG5ldHdvcmsuDQo+IA0KPiBTb3JyeSwgYnV0IHRo
YXQgc2hpcCBoYXMgc2FpbGVkLiBJZiB5b3UgYXJlIHB1cnBvc2VmdWxseSBJUHY0LW9ubHksIHlv
dSBoYXZlIHRvIGRlYWwgd2l0aCByb2d1ZSBJUHY2IFJBcyBhdCBsZWFzdCwgYW5kIHByb2JhYmx5
IHJvZ3VlIERIQ1B2NiBzZXJ2ZXJzIHRvbywgb3IgeW91IG5lZWQgdG8gZmlsdGVyIGV0aGVydHlw
ZSAweDg2REQgYWx0b2dldGhlci4gT3RoZXJ3aXNlLCBhIHJvZ3VlIHNpZ25hbCB0byB0dXJuIG9m
ZiBJUHY0IGlzIHRoZSBsZWFzdCBvZiB5b3VyIHdvcnJpZXMuICBNYWxpY2lvdXMgb3IgZXZlbiBh
Y2NpZGVudGFsIGRlcGxveW1lbnQgb2YgSVB2NiBpcyBhIGJpZ2dlciBzZWN1cml0eSB3b3JyeSBv
biB0aGVzZSBuZXR3b3JrcyB0aGFuIGEgcm9ndWUgc2lnbmFsIHRvIHR1cm4gb2ZmIElQdjQuIA0K
PiANCj4gSSdtIG5vdCBzYXlpbmcgdGhhdCBhIHJvZ3VlIHNpZ25hbCB0byB0dXJuIG9mZiBJUHY0
IGlzbid0IGEgcHJvYmxlbS4gSnVzdCBpZiB5b3VyIHdpbGxpbmcgdG8gaWdub3JlIHJvZ3VlIElQ
djYgZGVwbG95bWVudCwgdGhlbiB3b3JyeWluZyBhYm91dCBhIHJvZ3VlIHNpZ25hbCB0byB0dXJu
IG9mZiBJUHY0IHNlZW1zIGtpbmQgb2Ygc2VsZWN0aXZlLg0KDQpJbmRlZWQuIA0KDQpQZXJoYXBz
IHRoZXJl4oCZcyBhIGNhc2UgZm9yIGEg4oCYZmxpcOKAmSBJbmZvcm1hdGlvbmFsIGRvY3VtZW50
IHRvIFJGQyA3MTIzLCBhcyBhbiBhZHZpc29yeSBkb2N1bWVudCwgYnV0IGV2ZW4gdGhhdOKAmXMg
YSBiaXQgdGVudW91cy4NCg0KVGlt


From nobody Thu Nov 16 07:27:01 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8BD1296B3 for ; Thu, 16 Nov 2017 07:26:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_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=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 DuLCr4qf_hil for ; Thu, 16 Nov 2017 07:26:51 -0800 (PST)
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 DA82312944C for ; Thu, 16 Nov 2017 07:26:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510846009; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=iIHoeEE3nwiQBdCfSEa2v/6r9JxlpvWSdafVkaqHJBQ=; b=I7RTX2ndRYNA3VcCdStgJVq699qjfq3+XKDj1K5u5o/oMUyF3WbLT4prc9pE4y14K8471mgXPBBb0qd6jJeIQRTVbobsmzuMZIWAZDPlkBhA1TrDQg9d/9YV2DPBPlGqi8FcNHpxxXrvy9S/cZBCex0vdM7i/Lwb7Q5HSHY6GM0=
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0116.outbound.protection.outlook.com [213.199.154.116]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-29-Ihi5BlXaOQ6ngLviMYW_HA-1; Thu, 16 Nov 2017 15:26:45 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1137.eurprd07.prod.outlook.com (10.163.188.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.2; Thu, 16 Nov 2017 15:26:44 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 15:26:44 +0000
From: Tim Chown 
To: Ca By 
CC: 6man WG , Mark Andrews , Ole Troan , james woodyatt 
Subject: Re: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
Thread-Topic: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
Thread-Index: AQHTXsCEK1gNvYa+mkyDyUX+Qr6diqMW8xeAgAAuBIA=
Date: Thu, 16 Nov 2017 15:26:44 +0000
Message-ID: <75C8CD33-AF67-4669-8548-EF318FC69BDE@jisc.ac.uk>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.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.3445.4.7)
x-originating-ip: [194.82.140.195]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 20:+t8KoFhdhZcXof5M66+NIQzyuc99pp1Y8kvbd+sMZYHTM5lOQdhGKqX9C+ZUn7YvAXubT1VcH0HSfPTQYQnCjGL/62dBgtJuttSuo2+IX9FSNGNMv/XDffgtzTu8+onx0Q5uMO+bPQ5RAZ0J5CuuD6tGw0fs2R1V42f+eGNe3+g=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 16f3c94e-628a-4848-d02d-08d52d0671a2
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1137; 
x-ms-traffictypediagnostic: AM3PR07MB1137:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(274715658323672)(211936372134217)(153496737603132); 
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)(3231022)(920507027)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1137; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1137; 
x-forefront-prvs: 0493852DA9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(24454002)(189002)(86362001)(6486002)(478600001)(101416001)(66066001)(6512007)(97736004)(6306002)(50226002)(5660300001)(105586002)(81156014)(2906002)(5250100002)(93886005)(6506006)(8936002)(14454004)(81166006)(3280700002)(3660700001)(6436002)(36756003)(72206003)(68736007)(8676002)(57306001)(316002)(74482002)(786003)(4326008)(7736002)(229853002)(82746002)(305945005)(25786009)(54906003)(76176999)(106356001)(83716003)(42882006)(53546010)(6916009)(2950100002)(3846002)(33656002)(6246003)(53936002)(50986999)(99286004)(189998001)(34040400001)(6116002)(102836003)(2900100001)(39060400002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1137; 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-Network-Message-Id: 16f3c94e-628a-4848-d02d-08d52d0671a2
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 15:26:44.1717 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1137
X-MC-Unique: Ihi5BlXaOQ6ngLviMYW_HA-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 15:26:59 -0000

PiBPbiAxNiBOb3YgMjAxNywgYXQgMTI6NDIsIENhIEJ5IDxjYi5saXN0NkBnbWFpbC5jb20+IHdy
b3RlOg0KPiANCj4gT24gVGh1LCBOb3YgMTYsIDIwMTcgYXQgMTo1MyBBTSBUaW0gQ2hvd24gPFRp
bS5DaG93bkBqaXNjLmFjLnVrPiB3cm90ZToNCj4gSGksDQo+IA0KPiA+IE9uIDE1IE5vdiAyMDE3
LCBhdCAyMzowNCwgamFtZXMgd29vZHlhdHQgPGpod0Bnb29nbGUuY29tPiB3cm90ZToNCj4gPg0K
PiA+IE9uIE5vdiAxNSwgMjAxNywgYXQgMTM6NDcsIE9sZSBUcm9hbiA8b3Ryb2FuQGVtcGxveWVl
cy5vcmc+IHdyb3RlOg0KPiA+Pg0KPiA+Pj4+IElNSE8gdGhlIG9wdGltYWwgc29sdXRpb24gaXM6
DQo+ID4+Pj4gLSB0aGUgbmV0d29yayBTSE9VTEQgcHJvdmlkZSBhIGhvc3Qgd2l0aCBOQVQ2NCBw
cmVmaXggaW5mb3JtYXRpb24gaW4gUkE7DQo+ID4+Pg0KPiA+Pj4gRGlzYWdyZWUuIElmIHRoZSBu
ZXR3b3JrIGhhcyBOQVQ2NCwgdGhlbiBpdCBzaG91bGQgZGVwbG95IFJGQyA3MjI1LiBZZSBnb2Rz
LCB0aGlzIGlzIHRoZSB2ZXJ5IGxhc3QgdGhpbmcgdGhhdCBzaG91bGQgYmUgamFtbWVkIGludG8g
UkEgbWVzc2FnZXMuDQo+ID4+DQo+ID4+IERvIHdlIHJlYWxseSB3YW50IFBDUCBpbiBJUHY2Pw0K
PiA+DQo+ID4gSWYgd2UgaGF2ZSBhbnkga2luZCBvZiBOQVQsIHRoZW4gd2UgbmVlZCBQQ1AuIFVz
aW5nIE5BVCB3aXRob3V0IFBDUCBjb25zaWRlcmVkIGhhcm1mdWwuIFRoYXQgZ29lcyBmb3IgTkFU
NjQgYW5kIE5BVDY2Lg0KPiANCj4gQW5kIFBDUCBpcyBzdGlsbCBuZWVkZWQgdG8gbmVnb3RpYXRl
IGZpcmV3YWxsIGhvbGVzIGluIGEgcHVyZSBJUHY2IHNjZW5hcmlvLCBpc27igJl0IGl0PyAgQXNz
dW1pbmcgdGhlIGhvc3Qgd2l0aCBQQ1AgaXMgYmVoaW5kIFNpbXBsZSBTZWN1cml0eS4NCj4gDQo+
IEEgcXVlc3Rpb246IGlzIHRoaXMgc29tZXRoaW5nIHdlIHNob3VsZCBjb25kdWNlciBmb3IgUkZD
NjQzNC1iaXMsIG9yIHNob3VsZCB3ZSBiZSBzaWxlbnQgb24gUENQPw0KPiANCj4gTm8gDQo+IA0K
PiA+PiBJcyBQQ1Agc3VjY2Vzc2Z1bCBpbiBJUHY0Pw0KPiA+DQo+ID4gV2VsbCwgdGhlcmUgd2Fz
IHRoaXM6IDxodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84OC9zbGlkZXMvc2xpZGVz
LTg4LXBjcC01LnBkZj4NCj4gPg0KPiA+PiBPciBkb2VzIGl0IGV2ZW4gd29yayB3ZWxsIHdpdGgg
QStQIGJhc2VkIHNvbHV0aW9ucz8NCj4gPg0KPiA+IERlc2lnbmVkIGV4cHJlc3NseSBmb3IgaXQu
DQo+IA0KPiBJIGFzc3VtZWQgUENQIHdhcyBkZXNpZ25lZCB3aXRoIGFuIGV5ZSBmaXJtbHkgb24g
ZnV0dXJlIHJvdXRlZCBob21lIG5ldHdvcmtzIHdoZXJlIGZpcmV3YWxsIGhvbGVzIG5lZWQgdG8g
YmUgb3BlbmVkLiBXaGF0IGlzIHRoZSBhbHRlcm5hdGl2ZT8NCj4gDQo+IFRoZSBhbHRlcm5hdGl2
ZSBpcyBzZWN1cmUgaG9zdCBhbmQgbm8gZmlyZXdhbGwuIFRoZXJlIGlzIG5vIGZpcmV3YWxsIGF0
IHRoZSBpZXRmIGNvbmZlcmVuY2UgcmlnaHQgbm93LCByaWdodD8gIEFyZSB5b3Ugc2VjdXJlID8g
SXMgdGhlcmUgYSBtYWx3YXJlIG91dGJyZWFrPw0KDQpZZXQgaW4gcHJhY3RpY2UgcHJldHR5IG11
Y2ggZXZlcnkgSVNQIGRlcGxveWluZyBJUHY2IHRvIHJlc2lkZW50aWFsIGlzIGRvaW5nIHNvIHdp
dGggUkZDIDYwOTIsIG9yIHN0cmljdGVyLiBQZXJoYXBzIHdpdGggYSB0b2dnbGUgdG8gdHVybiBv
ZmYgZmlyZXdhbGxpbmcsIGJ1dCB0aGF04oCZcyB0aGUgcmVhbGl0eS4NCg0KT1RPSCBpdCBzZWVt
cyB0aGF0IFBDUCBzdXBwb3J0IGluIGhvc3RzIC8gQ1BFcyBpc24ndCBleGFjdGx5IHdpZGVzcHJl
YWQuDQoNCj4gVGhlIGZhdGFsIGZsYXcgaW4gUENQIChhc2lkZSBmcm9tIHRoZSBuYW1lKSBpcyB0
aGF0IGl0IGFzc3VtZXMgdGhlIGhvc3QgbmVlZHMgcHJvdGVjdGlvbiB5ZXQgaXQgZ2l2ZXMgdGhl
IGhvc3QgdGhlIHBvd2VyIHRvIGNvbnRyb2wgdGhlIGZpcmV3YWxsLiAgTmV4dCBnZW4gbWFsd2Fy
ZSB3aWxsIGNvbWUgdmlhIGVtYWlsIChqdXN0IGxpa2UgdG9kYXkpLCBpdCB3aWxsIGVuY3J5cHQg
eW91ciBoYXJkIGRyaXZlLCBhbmQgdGhlbiBzZXR1cCBhbmQgYzIgbmV0d29yayBvbiB5b3VyIHBj
IHZpYSBwY3AgY29udHJvbHMuICBTYWQhDQoNClRydWUsIGFuZCB0aGF0IGhhcHBlbnMgd2l0aCBV
UG5QIHRvZGF5Li4uDQoNClRpbQ==


From nobody Thu Nov 16 07:34:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71517129687 for ; Thu, 16 Nov 2017 07:34:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8K_9Q5dRhpJ for ; Thu, 16 Nov 2017 07:34:10 -0800 (PST)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB6012956C for ; Thu, 16 Nov 2017 07:34:10 -0800 (PST)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1eFMB5-0000FzC; Thu, 16 Nov 2017 16:34:07 +0100
Message-Id: 
To: ipv6@ietf.org
Subject: Re: IPv4 traffic on "ietf-v6ONLY" 
From: Philip Homburg 
Sender: pch-bCE2691D2@u-1.phicoh.com
References:     <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com>   
In-reply-to: Your message of "Thu, 16 Nov 2017 07:42:24 -0600 ."  
Date: Thu, 16 Nov 2017 16:34:04 +0100
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 15:34:12 -0000

>I'm not saying that a rogue signal to turn off IPv4 isn't a problem. Just
if your willing to ignore rogue IPv6 deployment, then worrying about a
>rogue signal to turn off IPv4 seems kind of selective.

If you want your 'no IPv4' signal to be ignored, then by all means make it
part of some IPv6 signalling protocol.

Nobody needs yet another attack vector.

Of course, eventually, there will be so little IPv4, that not getting a 
DHCPv4 lease quickly is a good signal to stop trying. But that's quite a few
years down the road.


From nobody Thu Nov 16 10:26:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC87126C83 for ; Thu, 16 Nov 2017 10:26:50 -0800 (PST)
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 I-UJ4Np3M80E for ; Thu, 16 Nov 2017 10:26:47 -0800 (PST)
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 B7B531205F1 for ; Thu, 16 Nov 2017 10:26:47 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id r186so11706360ywe.13 for ; Thu, 16 Nov 2017 10:26:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z+tNBFm2h6ldBjI7SnL8vqlmg3/jsoOjiEnQ7zXsfqA=; b=AB3lXqbvW8T2MurvdZHzwORDduZ52NwieHXQRQvclDeAsnHFAVkeE04zK+f4osnHzP O0BWya1C0MjaIJvnoc0cGSiTHU2bYcL4ajseFBBWMb4W3Dgg3iaER4hMvjkJJK92vH1g rvtY0l+UKOujIZFDAaQe+HPhsz7i98Pouz1N4q1BsUJm7O1J/gnB0rYhq3T8fF2B7zkr xCG8kM/mXvceEmCVF8qGUPc7JzWJ6pUYr1G94EUHdTxchP92KCL0xRXTZaI91LwAl4Wv /HcmHrA3FLYD680OSnqKnVzrYE/klgpB0vwyGPA60F1zaDC74R+nnz5RmPn/zv7gSSiv Gy/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z+tNBFm2h6ldBjI7SnL8vqlmg3/jsoOjiEnQ7zXsfqA=; b=jRx3zo8B4fmW6wuhAASqM4TMgLKK+xUAkRKuf2TP4XX4ZWANg/+DNEW77wDOUkEWz1 Gvc10g2oYZZizxjI01575YWO6TH4LzEn4WcqN25TWGLtR5TaiGGofxWq2oQVpOfb2XT9 DCvRubTta85byjJiTRrmR0+jgtWnsM6GY1sWeFXGHMDAHTCpqBei2CdtmBQu0R2AuoXg KI5VhqPgMoDTS9Ua1ux0SoSOdt/l+wYAbmEb2s2yvt/M7KfU7Fn6RViRbaPDFxUauJTG s4XqZvaUxtfH0AMvNC/LJIYA+srTsYRV/2/g12z9RlaymDkvuBmlRZ0SVdQv1p7FnMYM r04A==
X-Gm-Message-State: AJaThX4QjlIx9lPPfbGPESiV3Dvuy/Oe3m76IT8GsuUiSCj2hIpiVn61 wYUhFbL0DmU1o7DSjkPQGxmJxff4zPPoPCm44Zg=
X-Google-Smtp-Source: AGs4zMYYK48B8Vehe/vwsjybdn7H/iJzWq4U95lU66ah9OUE0p4ovnocDnW2t0tqJ3dzPYKMqb4D6wue39qPWTrXFmY=
X-Received: by 10.13.192.198 with SMTP id b189mr1558808ywd.336.1510856806944;  Thu, 16 Nov 2017 10:26:46 -0800 (PST)
MIME-Version: 1.0
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>   <75C8CD33-AF67-4669-8548-EF318FC69BDE@jisc.ac.uk>
In-Reply-To: <75C8CD33-AF67-4669-8548-EF318FC69BDE@jisc.ac.uk>
From: Ca By 
Date: Thu, 16 Nov 2017 18:26:35 +0000
Message-ID: 
Subject: Re: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
To: Tim Chown 
Cc: 6man WG , Mark Andrews , Ole Troan , james woodyatt 
Content-Type: multipart/alternative; boundary="001a114e6f6248d4d3055e1dc3b7"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 18:26:50 -0000

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

On Thu, Nov 16, 2017 at 7:26 AM Tim Chown  wrote:

> > On 16 Nov 2017, at 12:42, Ca By  wrote:
> >
> > On Thu, Nov 16, 2017 at 1:53 AM Tim Chown  wrote:
> > Hi,
> >
> > > On 15 Nov 2017, at 23:04, james woodyatt  wrote:
> > >
> > > On Nov 15, 2017, at 13:47, Ole Troan  wrote:
> > >>
> > >>>> IMHO the optimal solution is:
> > >>>> - the network SHOULD provide a host with NAT64 prefix information
> in RA;
> > >>>
> > >>> Disagree. If the network has NAT64, then it should deploy RFC 7225.
> Ye gods, this is the very last thing that should be jammed into RA messag=
es.
> > >>
> > >> Do we really want PCP in IPv6?
> > >
> > > If we have any kind of NAT, then we need PCP. Using NAT without PCP
> considered harmful. That goes for NAT64 and NAT66.
> >
> > And PCP is still needed to negotiate firewall holes in a pure IPv6
> scenario, isn=E2=80=99t it?  Assuming the host with PCP is behind Simple =
Security.
> >
> > A question: is this something we should conducer for RFC6434-bis, or
> should we be silent on PCP?
> >
> > No
> >
> > >> Is PCP successful in IPv4?
> > >
> > > Well, there was this: <
> https://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf>
> > >
> > >> Or does it even work well with A+P based solutions?
> > >
> > > Designed expressly for it.
> >
> > I assumed PCP was designed with an eye firmly on future routed home
> networks where firewall holes need to be opened. What is the alternative?
> >
> > The alternative is secure host and no firewall. There is no firewall at
> the ietf conference right now, right?  Are you secure ? Is there a malwar=
e
> outbreak?
>
> Yet in practice pretty much every ISP deploying IPv6 to residential is
> doing so with RFC 6092, or stricter. Perhaps with a toggle to turn off
> firewalling, but that=E2=80=99s the reality.
>

Yes, security FUD marketing is very real

Speaking for one largish mobile network ipv6 deployment, we have not hand
any issues related to lack of stateful traffic inspection in the last 4
years of ipv6 deployment. So if we are doing a science experiment, we have
a control group which has faired the same as the experimental group.

I will accept landlines are a slightly different animal.


> OTOH it seems that PCP support in hosts / CPEs isn't exactly widespread.
>
> > The fatal flaw in PCP (aside from the name) is that it assumes the host
> needs protection yet it gives the host the power to control the firewall.
> Next gen malware will come via email (just like today), it will encrypt
> your hard drive, and then setup and c2 network on your pc via pcp
> controls.  Sad!
>
> True, and that happens with UPnP today...
>
> Tim

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



On Thu, Nov 16, 2017 =
at 7:26 AM Tim Chown <Tim.Chown@=
jisc.ac.uk> wrote:
> On =
16 Nov 2017, at 12:42, Ca By <cb.list6@gmail.com> wrote:

>

> On Thu, Nov 16, 2017 at 1:53 AM Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

> Hi,

>

> > On 15 Nov 2017, at 23:04, james woodyatt <jhw@google.com> wrote:

> >

> > On Nov 15, 2017, at 13:47, Ole Troan <otroan@employees.org> wrote:

> >>

> >>>> IMHO the optimal solution is:

> >>>> - the network SHOULD provide a host with NAT64 prefix=
 information in RA;

> >>>

> >>> Disagree. If the network has NAT64, then it should deploy=
 RFC 7225. Ye gods, this is the very last thing that should be jammed into =
RA messages.

> >>

> >> Do we really want PCP in IPv6?

> >

> > If we have any kind of NAT, then we need PCP. Using NAT without P=
CP considered harmful. That goes for NAT64 and NAT66.

>

> And PCP is still needed to negotiate firewall holes in a pure IPv6 sce=
nario, isn=E2=80=99t it?=C2=A0 Assuming the host with PCP is behind Simple =
Security.

>

> A question: is this something we should conducer for RFC6434-bis, or s=
hould we be silent on PCP?

>

> No

>

> >> Is PCP successful in IPv4?

> >

> > Well, there was this: <ht=
tps://www.ietf.org/proceedings/88/slides/slides-88-pcp-5.pdf>

> >

> >> Or does it even work well with A+P based solutions?

> >

> > Designed expressly for it.

>

> I assumed PCP was designed with an eye firmly on future routed home ne=
tworks where firewall holes need to be opened. What is the alternative?

>

> The alternative is secure host and no firewall. There is no firewall a=
t the ietf conference right now, right?=C2=A0 Are you secure ? Is there a m=
alware outbreak?



Yet in practice pretty much every ISP deploying IPv6 to residential is doin=
g so with RFC 6092, or stricter. Perhaps with a toggle to turn off firewall=
ing, but that=E2=80=99s the reality.



Yes, security FU=
D marketing is very real

Speaking for one largish mobile network ipv6 deployment, we have not hand =
any issues related to lack of stateful traffic inspection in the last 4 yea=
rs of ipv6 deployment. So if we are doing a science experiment, we have a c=
ontrol group which has faired the same as the experimental group.=C2=A0

I will accept landlines are=
 a slightly different animal.=C2=A0



OTOH it seems that PCP support in hosts / CPEs isn't exactly widespread=
.



> The fatal flaw in PCP (aside from the name) is that it assumes the hos=
t needs protection yet it gives the host the power to control the firewall.=
=C2=A0 Next gen malware will come via email (just like today), it will encr=
ypt your hard drive, and then setup and c2 network on your pc via pcp contr=
ols.=C2=A0 Sad!



True, and that happens with UPnP today...



Tim


--001a114e6f6248d4d3055e1dc3b7--


From nobody Thu Nov 16 12:06:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5796C1201FA for ; Thu, 16 Nov 2017 12:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8J4WKK2FsY4V for ; Thu, 16 Nov 2017 12:06:47 -0800 (PST)
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 F37801201F2 for ; Thu, 16 Nov 2017 12:06:46 -0800 (PST)
Received: by mail-pg0-x22d.google.com with SMTP id u3so147877pgn.7 for ; Thu, 16 Nov 2017 12:06:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ppQci6ArACTIr5ZTeIrQrkKTZRCovgbJ6DxIwHgqyn8=; b=O3syjpOdkVaqZStSYH5wbxcR3CKKxS9VPfxacxBYxNSi0F+obW6pRdMI2Q8r2RYJKe nmQW0CA/EUi7O+eW2anriKvWSM0cxPrMSw0H586bpPepLcPLzcA4Em8yYBeiOEKJmmAD Ve5RmI0KCldDzXxq21N7Ggz+Kkjrli4wlRsULbA/00Pyz+q9V++sisb447+S0fht8pGt lG0HMjxrAJ4kUZ+kqTX1bJUsFGB6gV0+G7klBkiAYzC61OzM0zubP3dNOdC6YZcmndu0 K1RVHa+IdrgVNv0XS02ZIhXEtc4QlDXmNSfFPfiSrbcx+PDLFdMr7pkHZ+AXHbqQccaU 7rAA==
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=ppQci6ArACTIr5ZTeIrQrkKTZRCovgbJ6DxIwHgqyn8=; b=XrXv40wdk5ItY4uZJZHHVf3/oStb3FD3cdg1W/Hu7FYsSVO5d1hAdr/HLmUg+Uv7F1 rXSaFOoT1alGUBnfE61drumo/L2xFUTQ0/3ucNTNgPQIudda/CZCtCfp5pn2vAHqZzT9 stILIxzozNeo9edM28PkWrnVeAn4KIcMRZAvbTbCiWRDvq3TAbrt+clV2h774Knfq9PH k1dCsYyTiVTr81/81pK+2dIs82cHgdqH+k/tyUOEJyC0S8byiUPmEmsWLrGl0Qi/rVdk UbX2VuhqKmFd7Zjb1wZy1M/I54QzD43/vWIAzYfO/psjr9jZ92cz6VJ0GuG5nCFtKjoJ Am8A==
X-Gm-Message-State: AJaThX7Gkg8AmoScLRrKuoeF+lyK8v6oQxHaHeGPB6Xs2x8NVdorfTvZ 9O9nt7yRew4O78LI2vB64Gw2EA==
X-Google-Smtp-Source: AGs4zMbcIrfNPhYeG3sxfL4vLSyZYqEoqIvEQWqeyJtNB1+SwHVuWM6MHo3sqoOQxFXna+MnNQi5Wg==
X-Received: by 10.84.224.131 with SMTP id s3mr2785690plj.39.1510862805122; Thu, 16 Nov 2017 12:06:45 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:a5ca:6de1:c280:7c3f? ([2620:0:10e7:10:a5ca:6de1:c280:7c3f]) by smtp.gmail.com with ESMTPSA id b78sm4009064pfc.21.2017.11.16.12.06.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 12:06:44 -0800 (PST)
From: james woodyatt 
Message-Id: <20724B57-F88D-4F19-9DF8-F492B733A03C@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A0CCE756-191B-426D-B481-FDD9AD1EB4E4"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
Date: Thu, 16 Nov 2017 12:06:43 -0800
In-Reply-To: <75C8CD33-AF67-4669-8548-EF318FC69BDE@jisc.ac.uk>
Cc: Ca By , 6man WG , Mark Andrews , Ole Troan 
To: Tim Chown 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>   <75C8CD33-AF67-4669-8548-EF318FC69BDE@jisc.ac.uk>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 20:06:49 -0000

--Apple-Mail=_A0CCE756-191B-426D-B481-FDD9AD1EB4E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 16, 2017, at 07:26, Tim Chown  wrote:
> On 16 Nov 2017, at 12:42, Ca By  wrote:
>>=20
>> I assumed PCP was designed with an eye firmly on future routed home =
networks where firewall holes need to be opened. [=E2=80=A6]

It was. In fact, that was the reason NAT-PMP evolved into PCP in the =
first place: because we needed to extend NAT-PMP to support punching =
holes in RFC 6092 firewalls.

>> The alternative is secure host and no firewall. There is no firewall =
at the ietf conference right now, right?  Are you secure ? Is there a =
malware outbreak?

That=E2=80=99s the alternative, but it=E2=80=99s not the dominant =
practice.

> Yet in practice pretty much every ISP deploying IPv6 to residential is =
doing so with RFC 6092, or stricter. Perhaps with a toggle to turn off =
firewalling, but that=E2=80=99s the reality.

Surveys I=E2=80=99ve seen show that most IPv6 residential networks =
outside of a few large providers in USA are using something like RFC =
6092 with no prior user action. Home users either have no option to =
disable the firewall or they have no knowledge of it. Anybody planning =
to deploy IPv6 applications in residential networks (and I=E2=80=99m =
absolutely one of them) would be absolutely stupid to expect any way for =
passive listeners to receive inbound flows from arbitrary remote =
endpoints. Both REC-48 and REC-49 in RFC 6092 are widely ignored in the =
field. (Which is the outcome I warned against when I was writing it.)

> OTOH it seems that PCP support in hosts / CPEs isn't exactly =
widespread.

Is there support in FreeBSD, Linux or Windows? I don=E2=80=99t think so.

>> The fatal flaw in PCP (aside from the name) is that it assumes the =
host needs protection yet it gives the host the power to control the =
firewall.  Next gen malware will come via email (just like today), it =
will encrypt your hard drive, and then setup and c2 network on your pc =
via pcp controls.  Sad!
>=20
> True, and that happens with UPnP today=E2=80=A6

UPnP has the added festival of third-party option enabled by default. =
It=E2=80=99s truly a magical wonder.


--james woodyatt >




--Apple-Mail=_A0CCE756-191B-426D-B481-FDD9AD1EB4E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 16, 2017, at 07:26, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
On 16 Nov =
2017, at 12:42, Ca By <cb.list6@gmail.com> wrote:

I assumed PCP =
was designed with an eye firmly on future routed home networks where =
firewall holes need to be opened. [=E2=80=A6]

It was. In fact, that was the reason NAT-PMP =
evolved into PCP in the first place: because we needed to extend NAT-PMP =
to support punching holes in RFC 6092 firewalls.

The alternative is secure host and no firewall. =
There is no firewall at the ietf conference right now, right?  Are =
you secure ? Is there a malware outbreak?

That=E2=80=99s the alternative, but it=E2=80=99s =
not the dominant practice.

Yet in practice =
pretty much every ISP deploying IPv6 to residential is doing so with RFC =
6092, or stricter. Perhaps with a toggle to turn off firewalling, but =
that=E2=80=99s the reality.

Surveys=
 I=E2=80=99ve seen show that most IPv6 residential networks outside of a =
few large providers in USA are using something like RFC 6092 with no =
prior user action. Home users either have no option to disable the =
firewall or they have no knowledge of it. Anybody planning to deploy =
IPv6 applications in residential networks (and I=E2=80=99m absolutely =
one of them) would be absolutely stupid to expect any way for passive =
listeners to receive inbound flows from arbitrary remote endpoints. Both =
REC-48 and REC-49 in RFC 6092 are widely ignored in the field. (Which is =
the outcome I warned against when I was writing it.)

OTOH it seems that PCP support in hosts / =
CPEs isn't exactly widespread.

Is =
there support in FreeBSD, Linux or Windows? I don=E2=80=99t think =
so.

The fatal flaw in PCP (aside =
from the name) is that it assumes the host needs protection yet it gives =
the host the power to control the firewall.  Next gen malware will =
come via email (just like today), it will encrypt your hard drive, and =
then setup and c2 network on your pc via pcp controls.  Sad!

True, and that =
happens with UPnP today=E2=80=A6

UPnP has the added festival of third-party option =
enabled by default. It=E2=80=99s truly a magical wonder.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_A0CCE756-191B-426D-B481-FDD9AD1EB4E4--


From nobody Thu Nov 16 12:48:58 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1949129407 for ; Thu, 16 Nov 2017 12:48:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ok3vkJIYJjT2 for ; Thu, 16 Nov 2017 12:48:55 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6B91200F3 for ; Thu, 16 Nov 2017 12:48:55 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7D05620091 for ; Thu, 16 Nov 2017 15:50:40 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 63A3E82639 for ; Thu, 16 Nov 2017 15:48:54 -0500 (EST)
From: Michael Richardson 
To: 6man WG 
Subject: Re: IPv6 only host NAT64 requirements?
In-Reply-To: <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 20:48:57 -0000

--=-=-=
Content-Type: text/plain


I thought we need PCP in order to enable any kind of incoming connections in
the home.

The default security of rfc7084 section 4.5, which recommends using RFC6092:

              Recommended Simple Security Capabilities in
                 Customer Premises Equipment (CPE) for
              Providing Residential IPv6 Internet Service

denied incoming TCP SYN packets, although I can't find the exact sentence
right now.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloN+bYACgkQgItw+93Q
3WUXjAf+LqxxMFU5cx60ma/Xvx7ta8TKVHkwiKmJwqpfKQZIH4TXA/anTX7RXAwS
aZcOz1UpPv7dxmk3CSjrVqcSwnzZQwqKIt6+xZ6Y4MzWLYjLE11qJn8exchPc5lf
CJs8VeLjMMliUFfuy4iPkNHbrlTHTZegGchNLHuyUpLLgtK7vS+YGpYaj/hXddK0
m5VUu/5HWohv5xJ/OKf0RUw0siPHBW9dyWozJ4DUKR/2F7hAw/Bz1zTe7xbV5pq0
eaI4NKvbbynvaP1cLR27Cg+rXHIYMhXrdNSyqgycv7GTxuIZoJ5oP5oLD6GYhsb2
2bLM5OEIIEeOwHLMupY/r40fxCow2w==
=ZGXv
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu Nov 16 12:51:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42C8129407 for ; Thu, 16 Nov 2017 12:51:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvwBZ5gKhne8 for ; Thu, 16 Nov 2017 12:51:44 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3058C129431 for ; Thu, 16 Nov 2017 12:51:44 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 178EE20091 for ; Thu, 16 Nov 2017 15:53:29 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F064E82639 for ; Thu, 16 Nov 2017 15:51:42 -0500 (EST)
From: Michael Richardson 
To: 6man WG 
Subject: Re: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
In-Reply-To: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com> 
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 20:51:46 -0000

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


Tim Chown  wrote:
    > And PCP is still needed to negotiate firewall holes in a pure IPv6
    > scenario, isn=E2=80=99t it?  Assuming the host with PCP is behind Sim=
ple
    > Security.

    > A question: is this something we should conducer for RFC6434-bis, or
    > should we be silent on PCP?

I think that we should mention PCP.
I don't know whether to write MAY, SHOULD or MUST.
Probably not MUST.

BTW: Is there any RA option to signal that PCP might be needed?


=2D-
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloN+l4ACgkQgItw+93Q
3WUr7Af8DS1e8gHvePk78AQRtgNF4pHXskHusCtHbHRsWE2/c3nWPa1Wh9SMjbB2
KX7SjIMD/0bKsictDl+YqALB1qIVQKl8OktsBobNP5/qwN9Kj9kRClKfMc518U1l
Ox8q350uMeRI+/hIPakxKVBJrQKT7oURxfObUIiZ4JheY4skoOM1FTZsJbxJOlfH
dPKw/Tin3NAf0xS6h5COY2WzuFWjfcEpDZV44ntZ/Q0RdtxyPFHELC4ND0D9OzNI
j4XuM+WDk9wI/cZTF36EGR9nvAM3BU9DYoKK3AaE5OLfxE86V7ngjlP28QGk7bR2
fhk22wygQoVqEjtbTo8YO9rIRhG0rA==
=brdI
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu Nov 16 14:03:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793C312944A for ; Thu, 16 Nov 2017 14:03:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Qqb-o74xaldo for ; Thu, 16 Nov 2017 14:03:09 -0800 (PST)
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 E6147126DD9 for ; Thu, 16 Nov 2017 14:03:08 -0800 (PST)
Received: by mail-pf0-x22a.google.com with SMTP id j28so355900pfk.8 for ; Thu, 16 Nov 2017 14:03:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eJ0TZyszXw7wLYzktCjeBxD9ujgC6NyYuX6ihm5CSB0=; b=eVo3dLIBP+Gk/PDqp2rNNnFZqPLLn8p0Wgci7keV+Dg/ctpg9OWQah+tbtC/HMTEOc RTltVlw/LLb7jjGlWIMOqEjw/oCcTl3PTkHuJJCL81GNYOkKrbX91l7FsP62224hnK4d 9Fh1XiIg82jFErqATfAmUzXxErwat1FFWayW9b7dNOJz1mixThMREGL65CegSqOSgeph DsB0ndKhCaE8NcpLRl4vQmfurFf095LwU+afqi2R5hRYKHzXwk8DC4eaDHR4Xt7xd+i8 CDn2fNx8h8X/BSyng3q5qXOvFZk7tcK2qQ9KSnzYwJdehJTp2ElYFV/gnoRTfBoEPSM0 Jbtw==
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=eJ0TZyszXw7wLYzktCjeBxD9ujgC6NyYuX6ihm5CSB0=; b=nK9Mn5XGqVb5qh1CfNJs+BeCaTZ1/zA7lZaSqKvxdgAXsv0JQ7g/8r1Rfv/f/5Ygv2 0jArF1pKkl0Vo2oUtGKjq7a5hjJ/koxtMMum0Ew4rq90Q/X6BkFwyU8VECjbwWOyWYcO 7GYqTxwjNqLlvKcZERbYNFxb5QHcL+xtamar5I1/1xyGJHLd5URMvqi3+l8njFSar+uR NOpGaNcJPPwYNXdwJGzAdB26ulTOTRolz9cRimfSbbSD4zmHtI8SBsDVil9y24L/akCI 7qJ6X2xmEF/54pq8UyB9ukio3Qg5eYfS+xhmO3xyaaIPO9Yo/jZAgmb4nhnoKPttkbSh YYcQ==
X-Gm-Message-State: AJaThX47rs4oz0B8B+sF0BjcG0dzEyrTp5rXexOTm4WBl73JM4LCFfVY v/sXL+X1XYOeqD/yQCtP3POhx/4UevM=
X-Google-Smtp-Source: AGs4zMaYoSA3/tNA4qaqqA19QJD19yMRVt9ULuy81Y/Y2BnQYl88wormHqH9ndj7z2ImwfG2sYI7fw==
X-Received: by 10.99.109.73 with SMTP id i70mr3119571pgc.134.1510869788311; Thu, 16 Nov 2017 14:03:08 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:a5ca:6de1:c280:7c3f? ([2620:0:10e7:10:a5ca:6de1:c280:7c3f]) by smtp.gmail.com with ESMTPSA id c73sm5479709pfd.139.2017.11.16.14.03.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 14:03:07 -0800 (PST)
From: james woodyatt 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_D1306F5A-45B0-4E40-A6B3-59E579A8C62F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
Date: Thu, 16 Nov 2017 14:03:06 -0800
In-Reply-To: <21029.1510865502@obiwan.sandelman.ca>
Cc: 6man WG 
To: Michael Richardson 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>  <21029.1510865502@obiwan.sandelman.ca>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 22:03:10 -0000

--Apple-Mail=_D1306F5A-45B0-4E40-A6B3-59E579A8C62F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 16, 2017, at 12:51, Michael Richardson  =
wrote:
>=20
> I think that we should mention PCP.
> I don't know whether to write MAY, SHOULD or MUST.
> Probably not MUST.

Given that discovering all the relevant PCP servers is potentially =
impossible without a DHCPv6 client, and those are not explicitly =
RECOMMENDED, I think the only reasonable option here is "MAY implement a =
PCP client=E2=80=9D and not =E2=80=9CSHOULD=E2=80=9D or =E2=80=9CMUST=E2=80=
=9D to implement a PCP client.

> BTW: Is there any RA option to signal that PCP might be needed?

The O flag can signal that RFC 7291 may be required to discover any =
additional PCP servers beyond the one that can be available at =
2001:1::1.


--james woodyatt >




--Apple-Mail=_D1306F5A-45B0-4E40-A6B3-59E579A8C62F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 16, 2017, at 12:51, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

I =
think that we should mention PCP.
I don't know whether to =
write MAY, SHOULD or MUST.
Probably not MUST.

Given =
that discovering all the relevant PCP servers is potentially impossible =
without a DHCPv6 client, and those are not explicitly RECOMMENDED, I =
think the only reasonable option here is "MAY implement a PCP client=E2=80=
=9D and not =E2=80=9CSHOULD=E2=80=9D or =E2=80=9CMUST=E2=80=9D to =
implement a PCP client.

BTW: Is there =
any RA option to signal that PCP might be =
needed?

The O flag can =
signal that RFC 7291 may be required to discover any additional PCP =
servers beyond the one that can be available at 2001:1::1.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_D1306F5A-45B0-4E40-A6B3-59E579A8C62F--


From nobody Thu Nov 16 14:26:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B011271FD for ; Thu, 16 Nov 2017 14:26:14 -0800 (PST)
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 p7iHPwOrcL69 for ; Thu, 16 Nov 2017 14:26:12 -0800 (PST)
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 64114126BF3 for ; Thu, 16 Nov 2017 14:26:12 -0800 (PST)
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 7C5663B69CB; Thu, 16 Nov 2017 22:26:10 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 433E1160087; Thu, 16 Nov 2017 22:26:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DBDB016008D; Thu, 16 Nov 2017 22:26:09 +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 wdPO3o4zv31X; Thu, 16 Nov 2017 22:26:09 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9F1F5160087; Thu, 16 Nov 2017 22:26:08 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
From: Mark Andrews 
In-Reply-To: <20724B57-F88D-4F19-9DF8-F492B733A03C@google.com>
Date: Fri, 17 Nov 2017 09:26:06 +1100
Cc: Tim Chown , Ca By , 6man WG , Ole Troan 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AF93DAF-CFB0-458C-BEE9-96DBACE1E366@isc.org>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>   <75C8CD33-AF67-4669-8548-EF318FC69BDE@jisc.ac.uk> <20724B57-F88D-4F19-9DF8-F492B733A03C@google.com>
To: james woodyatt 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 22:26:14 -0000

> On 17 Nov 2017, at 7:06 am, james woodyatt  wrote:
>=20
> On Nov 16, 2017, at 07:26, Tim Chown  wrote:
>> On 16 Nov 2017, at 12:42, Ca By  wrote:
>>>=20
>>> I assumed PCP was designed with an eye firmly on future routed home =
networks where firewall holes need to be opened. [=E2=80=A6]
>=20
> It was. In fact, that was the reason NAT-PMP evolved into PCP in the =
first place: because we needed to extend NAT-PMP to support punching =
holes in RFC 6092 firewalls.
>=20
>>> The alternative is secure host and no firewall. There is no firewall =
at the ietf conference right now, right?  Are you secure ? Is there a =
malware outbreak?
>=20
> That=E2=80=99s the alternative, but it=E2=80=99s not the dominant =
practice.
>=20
>> Yet in practice pretty much every ISP deploying IPv6 to residential =
is doing so with RFC 6092, or stricter. Perhaps with a toggle to turn =
off firewalling, but that=E2=80=99s the reality.
>=20
> Surveys I=E2=80=99ve seen show that most IPv6 residential networks =
outside of a few large providers in USA are using something like RFC =
6092 with no prior user action. Home users either have no option to =
disable the firewall or they have no knowledge of it. Anybody planning =
to deploy IPv6 applications in residential networks (and I=E2=80=99m =
absolutely one of them) would be absolutely stupid to expect any way for =
passive listeners to receive inbound flows from arbitrary remote =
endpoints. Both REC-48 and REC-49 in RFC 6092 are widely ignored in the =
field. (Which is the outcome I warned against when I was writing it.)

Then those ISP=E2=80=99s are delivering a broken Internet connection to =
their customers.

There is a significant customer base that configure their border routers =
to allow
incoming connections today.  The ability to do this is built into retail =
routers today.
Customers that need this ability don=E2=80=99t buy routers that don=E2=80=99=
t support it.

Personally I would prefer that a router just did anti spoofing filtering =
and nothing else by
default but that wasn=E2=80=99t the consensus.   Allow only allocated =
source addresses out
the north interface.  Block allocated source addresses in on the north =
interface.  This
stops compromised internal machines successfully spoofing someone else.  =
 The
also prevents someone else using spoofed address you are using coming in =
at the
cost of not being able to send a source routed packet to yourself.

Mark

>> OTOH it seems that PCP support in hosts / CPEs isn't exactly =
widespread.
>=20
> Is there support in FreeBSD, Linux or Windows? I don=E2=80=99t think =
so.
>=20
>>> The fatal flaw in PCP (aside from the name) is that it assumes the =
host needs protection yet it gives the host the power to control the =
firewall.  Next gen malware will come via email (just like today), it =
will encrypt your hard drive, and then setup and c2 network on your pc =
via pcp controls.  Sad!
>>=20
>> True, and that happens with UPnP today=E2=80=A6
>=20
> UPnP has the added festival of third-party option enabled by default. =
It=E2=80=99s truly a magical wonder.
>=20
>=20
> --james woodyatt 
>=20
>=20
>=20

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


From nobody Thu Nov 16 14:55:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87E6126C0F for ; Thu, 16 Nov 2017 14:55:36 -0800 (PST)
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 20fYFkciqBmR for ; Thu, 16 Nov 2017 14:55:35 -0800 (PST)
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 223B01250B8 for ; Thu, 16 Nov 2017 14:55:35 -0800 (PST)
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 454893B00B6; Thu, 16 Nov 2017 22:55:27 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 19865160041; Thu, 16 Nov 2017 22:55:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 042C8160087; Thu, 16 Nov 2017 22:55:27 +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 yxOrQojbBXp7; Thu, 16 Nov 2017 22:55:26 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 5F507160041; Thu, 16 Nov 2017 22:55:26 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv4 traffic on "ietf-v6ONLY" 
From: Mark Andrews 
In-Reply-To: 
Date: Fri, 17 Nov 2017 09:55:24 +1100
Cc: ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5895250E-29CE-4BB5-998F-EB2F79653FA8@isc.org>
References:     <5655992F-737A-4223-A917-63CAD6DF7A1D@cisco.com>   
To: Philip Homburg 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 22:55:37 -0000

I suspect we will see hosts turning off IPv4 apart from DHCPv4 discover =
when they see
RAs and they don=E2=80=99t get responses to DHCPv4 discover in a few =
years time.  You don=E2=80=99t
have to bring up IPv4 link-local.

There will be a check box that says =E2=80=9CIPv4 link-local with =
IPv6=E2=80=9D or something like that.
It will default on for a few releases then the vendors will switch it to =
off by default.  The
IETF really doesn=E2=80=99t have to do anything.  The OS vendors will do =
this all by themselves.

Mark

> On 17 Nov 2017, at 2:34 am, Philip Homburg =
 wrote:
>=20
>> I'm not saying that a rogue signal to turn off IPv4 isn't a problem. =
Just
> if your willing to ignore rogue IPv6 deployment, then worrying about a
>> rogue signal to turn off IPv4 seems kind of selective.
>=20
> If you want your 'no IPv4' signal to be ignored, then by all means =
make it
> part of some IPv6 signalling protocol.
>=20
> Nobody needs yet another attack vector.
>=20
> Of course, eventually, there will be so little IPv4, that not getting =
a=20
> DHCPv4 lease quickly is a good signal to stop trying. But that's quite =
a few
> years down the road.
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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


From nobody Thu Nov 16 20:50:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E959F120727 for ; Thu, 16 Nov 2017 20:50:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWYeG141XLZm for ; Thu, 16 Nov 2017 20:50:08 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2651120726 for ; Thu, 16 Nov 2017 20:50:08 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAH4o7kx024230 for ; Fri, 17 Nov 2017 05:50:07 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 16808200DA8 for ; Fri, 17 Nov 2017 05:50:07 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 01DD6200C9E for ; Fri, 17 Nov 2017 05:50:07 +0100 (CET)
Received: from [132.166.84.12] ([132.166.84.12]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAH4o5rt021250 for ; Fri, 17 Nov 2017 05:50:06 +0100
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: ipv6@ietf.org
References:     
From: Alexandre Petrescu 
Message-ID: 
Date: Fri, 17 Nov 2017 05:50:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 04:50:13 -0000

Le 15/11/2017 à 20:15, james woodyatt a écrit :
> On Nov 15, 2017, at 02:47, Philip Homburg 
> > 
> wrote:
>>
>> The safest option to do that is a DHCPv4 option that says 'no IPv4 
>> service here, go away'.
> 
> Better: extend ARP with a signal that says, “ARP is not welcome here."

During changes between the 3 SSIDs I noticed often the message "Windows 
detected an IP address conflict" popped up.  The explanation says that 
another computer on the network has the same address, contact the 
sysadmin, and more details are available.

This makes wonder whether someone put a computer there that responds to 
all ARP resolution requests for LLs 169, claiming them all.

It happens systematically when changing the ESSID from "ietf" to 
"ietf-v6ONLY".  If, prior to that change, I disable the IPv4 checkbox in 
interface Properties, the message does not pop up.

However, this message appears also when changing attachment from SSID 
"ietf-v6ONLY" to "ietf".

Alex

> 
> --james woodyatt >
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Thu Nov 16 21:12:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CE9128891 for ; Thu, 16 Nov 2017 21:12:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level: 
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeYE8gUHH-AV for ; Thu, 16 Nov 2017 21:12:07 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89CED1286CA for ; Thu, 16 Nov 2017 21:12:07 -0800 (PST)
Received: from mb.local ([IPv6:2001:67c:370:1998:2dc8:49fe:2970:a665]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id vAH5C386060322 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 17 Nov 2017 05:12:05 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2001:67c:370:1998:2dc8:49fe:2970:a665] claimed to be mb.local
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Alexandre Petrescu , ipv6@ietf.org
References:      
From: joel jaeggli 
Message-ID: <22f886f2-b2c8-aca5-ad4d-425a119f9ace@bogus.com>
Date: Fri, 17 Nov 2017 13:12:02 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:56.0) Gecko/20100101 Thunderbird/56.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 05:12:09 -0000

On 11/17/17 12:50, Alexandre Petrescu wrote:
> 
> 
> Le 15/11/2017 à 20:15, james woodyatt a écrit :
>> On Nov 15, 2017, at 02:47, Philip Homburg
>> > > wrote:
>>>
>>> The safest option to do that is a DHCPv4 option that says 'no IPv4
>>> service here, go away'.
>>
>> Better: extend ARP with a signal that says, “ARP is not welcome here."
> 
> During changes between the 3 SSIDs I noticed often the message "Windows
> detected an IP address conflict" popped up.  The explanation says that
> another computer on the network has the same address, contact the
> sysadmin, and more details are available.
> 
> This makes wonder whether someone put a computer there that responds to
> all ARP resolution requests for LLs 169, claiming them all.
> 
> It happens systematically when changing the ESSID from "ietf" to
> "ietf-v6ONLY".  If, prior to that change, I disable the IPv4 checkbox in
> interface Properties, the message does not pop up.

The arp / broadcast suppression proxy in the wireless controller is
responding afirmatively to the gratuitous arp that your client sends in
order to test  that it's auto-configured address is available. Roaming
rapidly between APs can achieve that. It thinks you're in two places at
one. sending any other kinda of packet first that would allow it to
update it's mac address table.


> However, this message appears also when changing attachment from SSID
> "ietf-v6ONLY" to "ietf".
> 
> Alex
> 
>>
>> --james woodyatt >
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Thu Nov 16 21:14:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB021286CA for ; Thu, 16 Nov 2017 21:14:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhaIfethVm6Q for ; Thu, 16 Nov 2017 21:14:11 -0800 (PST)
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 7A354127978 for ; Thu, 16 Nov 2017 21:14:11 -0800 (PST)
Received: by mail-pf0-x231.google.com with SMTP id q4so1100889pfg.13 for ; Thu, 16 Nov 2017 21:14:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=nxAwgatjUSzB/vi/4vQYabrCB2gScMxW9iuO5rwaw0w=; b=Og84U6z3Ow3eteN4oKVpCtiO5it/pjYU4+XNeqtJaEkeXczzrlF5aK9uz3RaUsg5qT W6H9QjUQFtf24pHrJeKkF+XNbYZRCBJlAiLb7KSb16Gyjaqoa4KM9SKXWRxqsNX45AFY 5uLb1Z3bhz9vZlVqkJpTSMF3YJurWP22k2kkqEpKjh+x1gZImuyLGWfBHjldvZ3aMBJe Aw19GyFL0omjOHdIkmNSbb/iUvRipVPylBYvZRRLxD2BpKc7hYloxfP1eSjJiyFPpgao jB1aD0ObhkH98I5J1PoXO9pcAClkHsG0l0c1Yv4DR7GJlaDjgyuxKfoE4ZTi7Lk0aYCO RuiA==
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=nxAwgatjUSzB/vi/4vQYabrCB2gScMxW9iuO5rwaw0w=; b=IxM8mBfrmvRxnGR2L7HhOiE5+e8YmP0PvzHmCkiplXGJ3uXR05PUzMKbnSvxScfal6 iYcbeEV/WcwXAGYnIx+wyRA8m4jaIf1MOyvnVJJyePc6ic2OA/7vV6v5GqfIq4c4QofP ghHzuxy6VDNxXh/ijlhQSy2T0EIg6V7ZAkk0iD1D9tyMZtAnW5CCG7oFoeOqSZ1Q9W5d Im3IsIlByfbVwTQ30bEOfM1mGNKQVrhY3PVpMz/bTKLHlQ7zx7AnwNpcOjIFvuI47qps LiYThZSZSW+sfGxUlWbQfsv4nDW7T6beWmQbjAIPFtDHXrX/1O4su53QelJpY7Vgs+8E n0Fg==
X-Gm-Message-State: AJaThX7L4bKfZufs+Kf0lius85Ers2IB/PrLr/3AtJ8QGMoxGmM3kTli Rq8ocXeLqkaKHCuWHm8XqF78ZQ==
X-Google-Smtp-Source: AGs4zMYksZ5Ce4htEXcV9JF0pnQ80Srun9yVrwFQ9hGWVlB3P4l/gaaAd2udDwYUPdYCLIGoc8mmyw==
X-Received: by 10.98.9.79 with SMTP id e76mr801399pfd.70.1510895650592; Thu, 16 Nov 2017 21:14:10 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id v15sm4989076pfa.50.2017.11.16.21.14.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 21:14:09 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: Alexandre Petrescu , ipv6@ietf.org
References:      
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <663c1a6b-8ee4-1162-5241-0d77421f7e33@gmail.com>
Date: Fri, 17 Nov 2017 18:14:15 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 05:14:13 -0000

On 17/11/2017 17:50, Alexandre Petrescu wrote:
>=20
>=20
> Le 15/11/2017 =C3=A0 20:15, james woodyatt a =C3=A9crit=C2=A0:
>> On Nov 15, 2017, at 02:47, Philip Homburg=20
>> >=20
>> wrote:
>>>
>>> The safest option to do that is a DHCPv4 option that says 'no IPv4=20
>>> service here, go away'.
>>
>> Better: extend ARP with a signal that says, =E2=80=9CARP is not welcom=
e here."
>=20
> During changes between the 3 SSIDs I noticed often the message "Windows=
=20
> detected an IP address conflict" popped up.  The explanation says that =

> another computer on the network has the same address, contact the=20
> sysadmin, and more details are available.
>=20
> This makes wonder whether someone put a computer there that responds to=
=20
> all ARP resolution requests for LLs 169, claiming them all.

It's a Windows 7 bug, I'm pretty sure. I think it fails to clear
something when changing to a new SSID but *not* receiving an
address. I reported it at https://tickets.meeting.ietf.org/ticket/1159

   Brian

>=20
> It happens systematically when changing the ESSID from "ietf" to=20
> "ietf-v6ONLY".  If, prior to that change, I disable the IPv4 checkbox i=
n=20
> interface Properties, the message does not pop up.
>=20
> However, this message appears also when changing attachment from SSID=20
> "ietf-v6ONLY" to "ietf".
>=20
> Alex
>=20
>>
>> --james woodyatt >
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From nobody Thu Nov 16 21:31:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34579128796 for ; Thu, 16 Nov 2017 21:31:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 iaEuNX8H9XPP for ; Thu, 16 Nov 2017 21:31:18 -0800 (PST)
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 4440C127B5A for ; Thu, 16 Nov 2017 21:31:18 -0800 (PST)
Received: by mail-it0-x229.google.com with SMTP id n134so2788495itg.3 for ; Thu, 16 Nov 2017 21:31:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JAryRrCg+35HtLb3hlWMfq33djLaSBYac2VlUyafghA=; b=WkSWHBYkc0DQz0J5GAxhND4z1PbRDWebNSWnqw6dZO/QNMm4mW7BLWJ1XdGUocBFad wcha6AI7V6ZdhDsKK8xx+eRqpfa/tH9K7h8wv6bAkP2SV++znRvjh4FBFDV5ar7S4S+7 /NLDLpFGG9COUQS8/LCy1Bsy24ogbv5U/33usskiB8/YZKrhLVBmXu0r51epRzmEezJ5 ATRjmcdBg+UgIN+qHxOPBfQuTtrCtCKxiAUfbGPRhhsYSHODC03CHoZ9RY9rKbKZouaN d8U8rv/mDTap6WoqJYUtq2UiEW1AQDsaoBEZgd0Nfj3IgOfYHo5hyUlbiEI/arDJ+vys namQ==
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=JAryRrCg+35HtLb3hlWMfq33djLaSBYac2VlUyafghA=; b=LuISeBMnM/6Pn0ys7veUga093lyWCUpTEwc7O7zS5Y8OXjqtXM+FlIUP2nrO054WSo w7Mxr5PV7sWIKjKEk6w/PzGpauJ6Tf9EdBNSeWcPR1GFo+gEEi3trfH8orVTuQV+qdJw STt9urYBA3AqcnNwiWRhyhNEr03TXgEiZAUcujm2KxCHq87dEwZPJVhmaHL10iYQ5XSE nI8uDmY6Zve+h6F91uEYMWm9hxk7I6Fp0sjX2Q9DGR63haIlYoFQ9SkaPuyoebYY8vZW CZjCynDUGTHaMAUek57Rji0JaWkSGCHcl+ymFQC/osdlfK8q2Rv1jDaPEHQxb4srsR62 osWQ==
X-Gm-Message-State: AJaThX7eCgqO7yMd+EGaW5SkciBii0pgrCyTg04TC3Pn/3vd9eyPyC9z lud9VVAodxdeWIWTeH2knDwJVg==
X-Google-Smtp-Source: AGs4zMYaUoJjomLkWJ5GpUZBFR1jXH4Q2tW7wrEJT9pb8U6/z6+QpEkMapmO4JK2k8AMhfMyRKcaMw==
X-Received: by 10.36.141.65 with SMTP id w62mr5699732itd.152.1510896677405; Thu, 16 Nov 2017 21:31:17 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id 31sm1304895ioq.10.2017.11.16.21.31.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 21:31:16 -0800 (PST)
Subject: Re: IPv4 traffic on "ietf-v6ONLY"
To: joel jaeggli , Alexandre Petrescu , ipv6@ietf.org
References:       <22f886f2-b2c8-aca5-ad4d-425a119f9ace@bogus.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <8cac6d39-bf4c-17de-45da-7969798d37c1@gmail.com>
Date: Fri, 17 Nov 2017 18:31:21 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <22f886f2-b2c8-aca5-ad4d-425a119f9ace@bogus.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 05:31:20 -0000

On 17/11/2017 18:12, joel jaeggli wrote:
> On 11/17/17 12:50, Alexandre Petrescu wrote:
>>
>>
>> Le 15/11/2017 =C3=A0 20:15, james woodyatt a =C3=A9crit=C2=A0:
>>> On Nov 15, 2017, at 02:47, Philip Homburg
>>> >> > wrote:
>>>>
>>>> The safest option to do that is a DHCPv4 option that says 'no IPv4
>>>> service here, go away'.
>>>
>>> Better: extend ARP with a signal that says, =E2=80=9CARP is not welco=
me here."
>>
>> During changes between the 3 SSIDs I noticed often the message "Window=
s
>> detected an IP address conflict" popped up.=C2=A0 The explanation says=
 that
>> another computer on the network has the same address, contact the
>> sysadmin, and more details are available.
>>
>> This makes wonder whether someone put a computer there that responds t=
o
>> all ARP resolution requests for LLs 169, claiming them all.
>>
>> It happens systematically when changing the ESSID from "ietf" to
>> "ietf-v6ONLY".=C2=A0 If, prior to that change, I disable the IPv4 chec=
kbox in
>> interface Properties, the message does not pop up.
>=20
> The arp / broadcast suppression proxy in the wireless controller is
> responding afirmatively to the gratuitous arp that your client sends in=

> order to test  that it's auto-configured address is available. Roaming
> rapidly between APs can achieve that. It thinks you're in two places at=

> one. sending any other kinda of packet first that would allow it to
> update it's mac address table.

Hang on... that makes sense within a single SSID, but why would the
controller share info between independent SSIDs?

Unfortunately there is no ARP traffic in the captures I made during the
week.

    Brian
>=20
>> However, this message appears also when changing attachment from SSID
>> "ietf-v6ONLY" to "ietf".
>>
>> Alex
>>
>>>
>>> --james woodyatt >
>>>
>>>
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From nobody Thu Nov 16 22:42:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041D2127843 for ; Thu, 16 Nov 2017 22:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yltAgPfaq-5S for ; Thu, 16 Nov 2017 22:42:10 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FB21200C1 for ; Thu, 16 Nov 2017 22:42:09 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id l8so4271360wmg.4 for ; Thu, 16 Nov 2017 22:42:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:mime-version:subject:date:references:cc:to:message-id;  bh=2xzu7updVFp2m19ZUBDfBA4O+t3Qg/XkffjKSYdFwXk=; b=N/SOsAjBzFUyCIZ1S7f7S0sLaCFvYBvXK4wh8kBr0MoI8wjVaixISxJgaJQIHC43Ef hpZdSN8/L82I2X6lJORSghwJnZDRBr5HKbkTOX+k6Q7CH+z89MIhdCx6HA6fb2dng2nU 1Xaam2P0j5+ICrbWXwojsQgJg+0sweatwXxdXXvvA+eRuxY/aiXbIBil5tPVu3mqbXi2 N3JxZU1XefDs7hRgRwmQ9h9cvKaFgaVShvUGVKk9JP8/3TM+KHeOXkHBGBOMAch126dC 2dqzd3xHgjPh9hv0lW1WOtZmbi3jIa6RTBh3Xw8EzHNiNMFanOs3BjT08apz7P9yBVdV AYxg==
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:cc:to :message-id; bh=2xzu7updVFp2m19ZUBDfBA4O+t3Qg/XkffjKSYdFwXk=; b=c+Qyx5LwsRT7EBUjCKh0B5IUzxfERwUiINgwBoO4XTYEs+AbdLcRlxVzU+3Mmk6fuM zPQw241Pr0kwIaE1kMAnWjM/pG+J5DA9kdZWjIs+n6BRhRqdPevKO7beWbLEh5CWVR7L 4UWtIcvRZZZcZpChteD/FVbulEBJjAts8FbYhPzPGijzo04jORD/+8O4a8TOsv5mFs7m IiA3U2THHsa6v4QoyK/Z1kwPwmMlcu7hsT4hn2ruSdcNO2v9EjYHLXNSo05kxAKRz8nz aVM4Kn5gi3jWAgbPCMcNfZZmkHcUgtfvgABiZQKSeVFLZxcTltXFpvNQjU6IBNOTIOYE wOEg==
X-Gm-Message-State: AJaThX4PWRd2d6WTPvwGXUIcqqFCHl3t4jxjXUDJmS8B+ZwAkf82J55u 642pwEzlMDfnh9uytxG1hDSZHE3+
X-Google-Smtp-Source: AGs4zMYrXyLb6tyAwrd+SPHe7VA9+R+vHlK9gpMIcLbenPJz9CIXQMSwo0+KSpjr5wiMe5sjtYowjQ==
X-Received: by 10.80.149.210 with SMTP id x18mr5836373eda.4.1510900927794; Thu, 16 Nov 2017 22:42:07 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:c8f6:2068:15f9:6113? ([2001:67c:1232:144:c8f6:2068:15f9:6113]) by smtp.gmail.com with ESMTPSA id j6sm1958040edj.58.2017.11.16.22.42.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 22:42:06 -0800 (PST)
From: Bob Hinden 
Content-Type: multipart/signed; boundary="Apple-Mail=_A7F2F96A-8770-41FC-A120-CDAFCDAD84D9"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
Date: Fri, 17 Nov 2017 14:42:03 +0800
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>
Cc: Bob Hinden , Brian Carpenter 
To: IPv6 List 
Message-Id: 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 06:42:13 -0000

--Apple-Mail=_A7F2F96A-8770-41FC-A120-CDAFCDAD84D9
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CD0A02B9-2B3E-4DC9-9014-287DAA172DC6"


--Apple-Mail=_CD0A02B9-2B3E-4DC9-9014-287DAA172DC6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 ND =
Router Advertisements.  =46rom the Introduction:

   Hosts that support IPv4 and IPv6, usually called dual stack hosts,
   need to work on IPv6 only networks.  That is, a link where there are
   no IPv4 routers and/or IPv4 services.  Monitoring of IPv6-only
   networks, for example at the IETF 100 meeting in Singapore, shows
   that current dual stack hosts will create local auto-configured IPv4
   addresses and attempt to reach IPv4 services.  A mechanism is needed
   to inform hosts that there is no IPv4 support and that they should
   turn off IPv4.

   Because there is no IPv4 support on these links, the only way to
   notify the dual stack hosts on the link is to use an IPv6 mechanism.
   An active notification will be much more robust than attempting to
   deduce this state by the lack of IPv4 responses or traffic.

   IPv4-only hosts, and dual-stack hosts that do not recognize the new
   flag, will continue to attempt IPv4 operations, in particular IPv4
   discovery protocols typically sent as link-layer broadcasts.  This
   legacy traffic cannot be prevented by any IPv6 mechanism.  The value
   of the new flag is limited to dual-stack hosts that recognize it.

We were originally thinking it would be an April 1 submission, but after =
reading the discussion on the IPv6 list, we decided it makes sense as a =
real submission :-)

Please review and comment.

Thanks,
Bob and Brian


> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-hinden-ipv4flag-00.txt
> Date: November 17, 2017 at 2:36:31 PM GMT+8
> To: "Robert M. Hinden" , "Robert Hinden" =
, "Brian Carpenter" 
>=20
>=20
> A new version of I-D, draft-hinden-ipv4flag-00.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
>=20
> Name:		draft-hinden-ipv4flag
> Revision:	00
> Title:		IPv6 Router Advertisement IPv4 Availability Flag
> Document date:	2017-11-17
> Group:		Individual Submission
> Pages:		5
> URL:            =
https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
> Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-00
> Htmlized:       =
https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-00
>=20
>=20
> Abstract:
>   This document specifies a Router Advertisement Flag to indicate that
>   there is no IPv4 service on the advertising router.  This document
>   updates RFC5175.
>=20
>=20
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> The IETF Secretariat
>=20


--Apple-Mail=_CD0A02B9-2B3E-4DC9-9014-287DAA172DC6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi,

Brian =
and I took a cut a defining an IPv4 Availability Flag for IPv6 ND Router =
Advertisements.  =46rom the Introduction:

   Hosts that support IPv4 =
and IPv6, usually called dual stack hosts,
  =
 need to work on IPv6 only networks.  That is, a link where =
there are
   no IPv4 routers and/or IPv4 =
services.  Monitoring of IPv6-only
  =
 networks, for example at the IETF 100 meeting in Singapore, =
shows
   that current dual stack hosts will =
create local auto-configured IPv4
   addresses =
and attempt to reach IPv4 services.  A mechanism is needed
   to inform hosts that there is no IPv4 support =
and that they should
   turn off IPv4.

   Because there is no IPv4 support =
on these links, the only way to
   notify the =
dual stack hosts on the link is to use an IPv6 mechanism.
   An active notification will be much more robust =
than attempting to
   deduce this state by the =
lack of IPv4 responses or traffic.

  =
 IPv4-only hosts, and dual-stack hosts that do not recognize the =
new
   flag, will continue to attempt IPv4 =
operations, in particular IPv4
   discovery =
protocols typically sent as link-layer broadcasts.  This
   legacy traffic cannot be prevented by any IPv6 =
mechanism.  The value
   of the new flag is =
limited to dual-stack hosts that recognize it.

We were originally thinking it would be =
an April 1 submission, but after reading the discussion on the IPv6 =
list, we decided it makes sense as a real submission :-)

Please review and =
comment.

Thanks,
Bob and Brian


Begin forwarded message:

From: =
internet-drafts@ietf.org
Subject: =
New Version =
Notification for draft-hinden-ipv4flag-00.txt
Date: =
November 17, 2017 at 2:36:31 PM =
GMT+8
To: =
"Robert M. Hinden" <bob.hinden@gmail.com>, "Robert Hinden" <bob.hinden@gmail.com>, "Brian Carpenter" <brian.e.carpenter@gmail.com>

A new version of I-D, draft-hinden-ipv4flag-00.txt
has been successfully submitted by Robert M. Hinden and =
posted to the
IETF repository.

Name:	=
	=
draft-hinden-ipv4flag
Revision:	00
Title:=
		=
IPv6 Router Advertisement IPv4 Availability Flag
Document date:	2017-11-17
Group:=
		=
Individual Submission
Pages:		5
URL: =
           https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.t=
xt
Status: =
        https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-00<=
/a>


Abstract:
 =
  This document specifies a Router Advertisement Flag to =
indicate that
   there is no IPv4 service on the =
advertising router.  This document
 =
  updates RFC5175.




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

The IETF Secretariat


=

--Apple-Mail=_CD0A02B9-2B3E-4DC9-9014-287DAA172DC6--

--Apple-Mail=_A7F2F96A-8770-41FC-A120-CDAFCDAD84D9
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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloOhLsACgkQrut0EXfn
u6hdbAf/X5C/CrduhpOV+pZcdGXg7aeQ6w68GQmb3ktmr8Z6wB7rxs8oo8VyYc37
ncCCGIM9AZqV+o6GNvjr9oBa9UUtxWbCnJ+M+eZ2d3rQtOr0m81vdEhCD61Rx3Ut
0DR7oYYX77Ipxu/VWwSXLdmeU7kuTr47cXFJxuC5S2r6hjYLBmO4PXeycVb+n5dt
2xBH6YJx9UfIVGXJ5cGIV/0BE/weVmMN5zjyShTyWcvZWGKuWpG89iw0RAWC99Fr
EzWUuNfjA3bN8UQveOkzwhgnM2QCXhDCyyt2NiuRa7JXL12hhDxRc9nncdMPc9qu
4M/9x/Dc/aVzIB350PIO0gx0iQtpZg==
=DDAb
-----END PGP SIGNATURE-----

--Apple-Mail=_A7F2F96A-8770-41FC-A120-CDAFCDAD84D9--


From nobody Thu Nov 16 22:52:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D38D126B72 for ; Thu, 16 Nov 2017 22:52:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level: 
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dILTVGPGR_oO for ; Thu, 16 Nov 2017 22:52:54 -0800 (PST)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419E31200E5 for ; Thu, 16 Nov 2017 22:52:54 -0800 (PST)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 01F69100DCE; Fri, 17 Nov 2017 07:52:53 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id D83DD80070; Fri, 17 Nov 2017 07:52:52 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Fri, 17 Nov 2017 07:52:52 +0100
From: 
To: Michael Richardson , 6man WG 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTXxxYyuElU1W99UW2Cmkb+owWL6MYIL0Q
Date: Fri, 17 Nov 2017 06:52:51 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07C3DA@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com> <20377.1510865334@obiwan.sandelman.ca>
In-Reply-To: <20377.1510865334@obiwan.sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 06:52:56 -0000

Hi Michael,=20

For the particular case of NAT64, this requirement from RFC6888 applies:=20

   REQ-9:  A CGN MUST implement a protocol giving subscribers explicit
      control over NAT mappings.  That protocol SHOULD be the Port
      Control Protocol [RFC6887].

I'm not aware of any requirement for the LAN. The only recommendation I'm a=
ware of is on the WAN interface of an IPv6 CPE:

   W-6:  The WAN interface of the CE router SHOULD support a Port
         Control Protocol (PCP) client as specified in [RFC6887] for use
         by applications on the CE router.  The PCP client SHOULD follow
         the procedure specified in Section 8.1 of [RFC6887] to discover
         its PCP server.  This document takes no position on whether
         such functionality is enabled by default or mechanisms by which
         users would configure the functionality.  Handling PCP requests
         from PCP clients in the LAN side of the CE router is out of
         scope.

Cheers,
Med

> -----Message d'origine-----
> De=A0: ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Michael Richards=
on
> Envoy=E9=A0: jeudi 16 novembre 2017 21:49
> =C0=A0: 6man WG
> Objet=A0: Re: IPv6 only host NAT64 requirements?
>=20
>=20
> I thought we need PCP in order to enable any kind of incoming connections
> in
> the home.
>=20
> The default security of rfc7084 section 4.5, which recommends using
> RFC6092:
>=20
>               Recommended Simple Security Capabilities in
>                  Customer Premises Equipment (CPE) for
>               Providing Residential IPv6 Internet Service
>=20
> denied incoming TCP SYN packets, although I can't find the exact sentence
> right now.
>=20
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails
> [


From nobody Thu Nov 16 23:22:00 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3A712773A for ; Thu, 16 Nov 2017 23:21:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 NkG_8aIayg6S for ; Thu, 16 Nov 2017 23:21:55 -0800 (PST)
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 8B85912741D for ; Thu, 16 Nov 2017 23:21:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510903313; x=1511508113; 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=a0nz6j/lcLwD0649h10xv0CkL fKJGWvtgCwZTocfM5Y=; b=QTxOlrJKyAOdFK0TAFlPGg/TMhxMHm3XlfKNk+Dy3 S/3Ajcl0+o6BpVBTZQBTAxnLUpHjx5/OCZrHFlGtKkyxTxaquDyGGyxUNgizspXG yBA7oEAsdxtFi1L1qbhXV5KWoJ42z6grsoRfT27TGLxV8JmtYwFJl+uPWmsV6u+B UM=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=UjTP3Qe77tbYvzXSLXDDFzhYo3Ty1ppbml6vJp2O93WAGSGQsDiZyKQPVFYr HhbZ+7DVsbMMc5pi76wKF71f54o8EiA8iOTkXTbNCEyHoJOGV82qxbhNB WFY+3r+Zdr6VpM3n92CsQfUyo9i5tmckR0qMlXOWjmHQWrSQPj+mUA=;
X-MDAV-Processed: mail.consulintel.es, Fri, 17 Nov 2017 08:21:53 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 17 Nov 2017 08:21:53 +0100
Received: from [172.20.60.6] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005626521.msg for ; Fri, 17 Nov 2017 08:21:53 +0100
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:171117:md50005626521::O2YVM3hmRo0s4/cS:00001bl8
X-Return-Path: prvs=1494ff0e50=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Fri, 17 Nov 2017 15:21:42 +0800
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
From: JORDI PALET MARTINEZ 
To: IPv6 List 
Message-ID: 
Thread-Topic: New Version Notification for draft-hinden-ipv4flag-00.txt
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Reply-To: jordi.palet@consulintel.es
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 07:21:58 -0000

At first sight, looks fine to me.

Regards,
Jordi
 

-----Mensaje original-----
De: ipv6  en nombre de Bob Hinden 
Responder a: 
Fecha: viernes, 17 de noviembre de 2017, 14:42
Para: IPv6 List 
CC: Bob Hinden 
Asunto: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt

    Hi,
    Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 ND Router Advertisements.  From the Introduction:
    
       Hosts that support IPv4 and IPv6, usually called dual stack hosts,
       need to work on IPv6 only networks.  That is, a link where there are
       no IPv4 routers and/or IPv4 services.  Monitoring of IPv6-only
       networks, for example at the IETF 100 meeting in Singapore, shows
       that current dual stack hosts will create local auto-configured IPv4
       addresses and attempt to reach IPv4 services.  A mechanism is needed
       to inform hosts that there is no IPv4 support and that they should
       turn off IPv4.
    
       Because there is no IPv4 support on these links, the only way to
       notify the dual stack hosts on the link is to use an IPv6 mechanism.
       An active notification will be much more robust than attempting to
       deduce this state by the lack of IPv4 responses or traffic.
    
       IPv4-only hosts, and dual-stack hosts that do not recognize the new
       flag, will continue to attempt IPv4 operations, in particular IPv4
       discovery protocols typically sent as link-layer broadcasts.  This
       legacy traffic cannot be prevented by any IPv6 mechanism.  The value
       of the new flag is limited to dual-stack hosts that recognize it.
    
    We were originally thinking it would be an April 1 submission, but after reading the discussion on the IPv6 list, we decided it makes sense as a real submission :-)
    
    Please review and comment.
    
    Thanks,
    Bob and Brian
    
    
    
    Begin forwarded message:
    
    From: internet-drafts@ietf.org
    
    Subject: New Version Notification for draft-hinden-ipv4flag-00.txt
    
    Date: November 17, 2017 at 2:36:31 PM GMT+8
    
    To: "Robert M. Hinden" , "Robert Hinden" , "Brian Carpenter" 
    
    
    
    A new version of I-D, draft-hinden-ipv4flag-00.txt
    has been successfully submitted by Robert M. Hinden and posted to the
    IETF repository.
    
    Name:		draft-hinden-ipv4flag
    Revision:	00
    Title:		IPv6 Router Advertisement IPv4 Availability Flag
    Document date:	2017-11-17
    Group:		Individual Submission
    Pages:		5
    URL:            https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
    Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-00
    
    
    Abstract:
       This document specifies a Router Advertisement Flag to indicate that
       there is no IPv4 service on the advertising router.  This document
       updates RFC5175.
    
    
    
    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org .
    
    The IETF Secretariat
    
    
    
    
    
    
    
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



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

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




From nobody Thu Nov 16 23:46:46 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AA8128C81; Thu, 16 Nov 2017 23:46:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UekRFtkjyWXH; Thu, 16 Nov 2017 23:46:37 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD95212741D; Thu, 16 Nov 2017 23:46:36 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:9ac:99fc:64d1:1909] (unknown [IPv6:2001:67c:1232:144:9ac:99fc:64d1:1909]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4C27480C3F; Fri, 17 Nov 2017 08:46:32 +0100 (CET)
Subject: Re: Upleveling discussion (was Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host))
To: Suresh Krishnan , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" 
Cc: Ted Lemon , Mark Smith , "Van De Velde, Gunter (Nokia - BE/Antwerp)" 
References:     <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com>  <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com>  <862687c9-c107-53a8-288a-29049097b0e1@acm.org>       
From: Fernando Gont 
Message-ID: 
Date: Fri, 17 Nov 2017 15:44:57 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 07:46:39 -0000

Hello, Suresh,


On 11/14/2017 11:22 AM, Suresh Krishnan wrote:
> Hi all,
>   I would like to summarize the issues that have been brought up, along
> with my views (I apologize for the long mail but I think it is warranted
> in this case)

Thanks for the summary!


> b) Mechanism does not work
> 
> Given that the mechanism has been implemented and deployed by the
> authors, I have a hard time taking this claim at face value. Providing
> an unique prefix per host has been standard practice in 3GPP mobile
> networks for the past *15 years*. based on recommendations from the IETF
> back at that time. When a mobile attaches, there is state created on the
> first hop router that does exactly what this draft wants to do. The only
> issue I see is a lack of mechanism to clean up stale prefixes if the
> hosts go away, but depending on the deployment this may or may not be an
> issue.

I don't think anyone has argued that the mechanism "does not work".

The issue raised has had to do with two things:

1) Reduced resiliency of SLAAC as a result of the required (previously
inexistent) state

2) The security implications associated with 1)

This means that SLAAC can break in new ways, and also that attackers can
attack SLAAC in new ways.


FWIW, the motivation for raising this discussion was the reduced
resiliency and reduced security of the corresponding deployment of
SLAAC. Essentially, it was either "bad timing" (on my side, as it
happened), or "worse timing" ( on my side, too -- i.e. not raise the
issue at all, and then just see the aforementioned issues happen). The
fact that the document is bcp made the above considerations even more of
a concern, since we are telling all IPv6 deployments that this document
is the way to go.

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





From nobody Thu Nov 16 23:56:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A141243F6 for ; Thu, 16 Nov 2017 23:56:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 juB8r57FYPep for ; Thu, 16 Nov 2017 23:56:08 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9376126557 for ; Thu, 16 Nov 2017 23:56:07 -0800 (PST)
Received: from [IPv6:2001:67c:1232:144:9ac:99fc:64d1:1909] (unknown [IPv6:2001:67c:1232:144:9ac:99fc:64d1:1909]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 871A880197; Fri, 17 Nov 2017 08:56:05 +0100 (CET)
Subject: Re: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Bob Hinden , IPv6 List 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> 
From: Fernando Gont 
Message-ID: <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar>
Date: Fri, 17 Nov 2017 15:57:52 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 07:56:11 -0000

HI, BOb,

Comments/questions:

* How about the case in which a user employs an IPv4-only printer on an
IPv6-only network?

* Does this document imply that IPv6 is bootstrapped first than, or in
parallel of, IPv4?

* If IPv4-has already been bootstrapped, would 4=1 still cause the node
to disable IPv4?

* If 4=1, but later 4=0, shuld that transition of the 4 bit trigger IPv4
configuration?


* Sec cons: see RFC7113 -- it seems that still the current state of
affairs for many implementations (unfortunately).


Thanks!

Cheers,
Fernando




On 11/17/2017 02:42 PM, Bob Hinden wrote:
> Hi,
> 
> Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 ND
> Router Advertisements.  From the Introduction:
> 
>    Hosts that support IPv4 and IPv6, usually called dual stack hosts,
>    need to work on IPv6 only networks.  That is, a link where there are
>    no IPv4 routers and/or IPv4 services.  Monitoring of IPv6-only
>    networks, for example at the IETF 100 meeting in Singapore, shows
>    that current dual stack hosts will create local auto-configured IPv4
>    addresses and attempt to reach IPv4 services.  A mechanism is needed
>    to inform hosts that there is no IPv4 support and that they should
>    turn off IPv4.
> 
>    Because there is no IPv4 support on these links, the only way to
>    notify the dual stack hosts on the link is to use an IPv6 mechanism.
>    An active notification will be much more robust than attempting to
>    deduce this state by the lack of IPv4 responses or traffic.
> 
>    IPv4-only hosts, and dual-stack hosts that do not recognize the new
>    flag, will continue to attempt IPv4 operations, in particular IPv4
>    discovery protocols typically sent as link-layer broadcasts.  This
>    legacy traffic cannot be prevented by any IPv6 mechanism.  The value
>    of the new flag is limited to dual-stack hosts that recognize it.
> 
> We were originally thinking it would be an April 1 submission, but after
> reading the discussion on the IPv6 list, we decided it makes sense as a
> real submission :-)
> 
> Please review and comment.
> 
> Thanks,
> Bob and Brian
> 
> 
>> Begin forwarded message:
>>
>> *From: *internet-drafts@ietf.org 
>> *Subject: **New Version Notification for draft-hinden-ipv4flag-00.txt*
>> *Date: *November 17, 2017 at 2:36:31 PM GMT+8
>> *To: *"Robert M. Hinden" > >, "Robert Hinden" > >, "Brian Carpenter"
>> >
>>
>>
>> A new version of I-D, draft-hinden-ipv4flag-00.txt
>> has been successfully submitted by Robert M. Hinden and posted to the
>> IETF repository.
>>
>> Name:draft-hinden-ipv4flag
>> Revision:00
>> Title:IPv6 Router Advertisement IPv4 Availability Flag
>> Document date:2017-11-17
>> Group:Individual Submission
>> Pages:5
>> URL:
>>            https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
>> Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-00
>> Htmlized:
>>       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-00
>>
>>
>> Abstract:
>>   This document specifies a Router Advertisement Flag to indicate that
>>   there is no IPv4 service on the advertising router.  This document
>>   updates RFC5175.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org
>> .
>>
>> The IETF Secretariat
>>
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Fri Nov 17 00:15:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2487F1293E4 for ; Fri, 17 Nov 2017 00:15:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 gFBbbjjCkFwc for ; Fri, 17 Nov 2017 00:15:21 -0800 (PST)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB14124319 for ; Fri, 17 Nov 2017 00:15:20 -0800 (PST)
Received: by mail-it0-x230.google.com with SMTP id u132so3176123ita.0 for ; Fri, 17 Nov 2017 00:15:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=layFOthoU0bqp2x63BAeIQLsVbdLtAF5fO7oDLZQM9M=; b=A8F6iVs2Ja08YfaeftjUvnS4mIJySGPskerLZDZYqEeoOlnpuNhyncHXdf/cKXeA1Y 0/YmLE75k49/4sE7HwZQiBRWIcGvC+qafaba2YZ/B9yAiwXuPhk1F6S9TiDuWczVhdQ2 STC11JBxskaDDfYMq06emG/wGNcCU7RTFt72ZGibJ99wrV0oTZ6oo07jL8bslxlEXRz3 a2832E1o7UvOOhNLnLOrNmVQzKn+0OwRxhHSgW2Rc/n4G6OpMEVP1klwPrNNhZciE5Pw jvYuYoEa/vUxiYlI1BCGZXRI2bNylxMA71yYcm6IQBaGAh7sDbhgLnkBWDnMIh56ypCv J86A==
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=layFOthoU0bqp2x63BAeIQLsVbdLtAF5fO7oDLZQM9M=; b=Pe7M2CGWWfsht0GBuR0HI+HmN2Rj6NRUocrs8AtJnTzrhqMcbo8+50+kZibrlzrfCN cpV8QuVTgMKxQQngpNJUmI53E9HAVkinv4QFBDvCG9PtVhJNAHNM+r5rBzHaFNz6e/bz g+6NKfwwBwt9FQ4nXLBOy1Akw54smu3Je6gWWC43kZ2zrYyQ68lyFDwycqBC7xsLCRBp XF6GNN7YNnkGWnKo5RhlnvZyq3HliPMPD7I65rEJ6ozayqBPPRDTk2y5rv25xFYibdWm Vo0YkbdhBoism8ZZEr0/EzvBbSSsk7zX6lWxWKfUnmzmnol2WkHlETHfjiQIci1ZEGDW lGrA==
X-Gm-Message-State: AJaThX6+TdbLpCGfNlLW2NjoYo2md4ah8mP9Wk7GGYAiTt0fT1wkZQJ1 ocGd4fqnRhUIkjcnpLPLylhujw==
X-Google-Smtp-Source: AGs4zMZzuEvxI76hS5ztefHbeRqcpJyxGQj9O9fE6W+aVA3m45AgIT9F74R3WbPBd1Ermj3IiWsmNQ==
X-Received: by 10.36.178.78 with SMTP id h14mr5346337iti.107.1510906519878; Fri, 17 Nov 2017 00:15:19 -0800 (PST)
Received: from [172.16.132.82] ([101.100.166.3]) by smtp.gmail.com with ESMTPSA id t69sm1852866itt.37.2017.11.17.00.15.17 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 00:15:18 -0800 (PST)
Subject: Re: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
To: ipv6@ietf.org
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <3814984e-4016-6574-b9cc-c961e939b57c@gmail.com>
Date: Fri, 17 Nov 2017 21:15:23 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 08:15:23 -0000

On 17/11/2017 20:57, Fernando Gont wrote:
> HI, BOb,
>=20
> Comments/questions:
>=20
> * How about the case in which a user employs an IPv4-only printer on an=

> IPv6-only network?

That question makes my head hurt. Why would you configure the flag =3D1 o=
n
such a network?

>=20
> * Does this document imply that IPv6 is bootstrapped first than, or in
> parallel of, IPv4?

First. Maybe we need to state that.

>=20
> * If IPv4-has already been bootstrapped, would 4=3D1 still cause the no=
de
> to disable IPv4?

There is a cunning "should not" in the text to cover corner cases. But
we probably need to discuss the corner cases anyway.

>=20
> * If 4=3D1, but later 4=3D0, shuld that transition of the 4 bit trigger=
 IPv4
> configuration?

Yes, we need to say something about that - linked to router lifetimes, I
think.

me -> airport shortly.

   Brian
>=20
>=20
> * Sec cons: see RFC7113 -- it seems that still the current state of
> affairs for many implementations (unfortunately).
>=20
>=20
> Thanks!
>=20
> Cheers,
> Fernando
>=20
>=20
>=20
>=20
> On 11/17/2017 02:42 PM, Bob Hinden wrote:
>> Hi,
>>
>> Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 N=
D
>> Router Advertisements. =C2=A0From the Introduction:
>>
>> =C2=A0 =C2=A0Hosts that support IPv4 and IPv6, usually called dual sta=
ck hosts,
>> =C2=A0 =C2=A0need to work on IPv6 only networks. =C2=A0That is, a link=
 where there are
>> =C2=A0 =C2=A0no IPv4 routers and/or IPv4 services. =C2=A0Monitoring of=
 IPv6-only
>> =C2=A0 =C2=A0networks, for example at the IETF 100 meeting in Singapor=
e, shows
>> =C2=A0 =C2=A0that current dual stack hosts will create local auto-conf=
igured IPv4
>> =C2=A0 =C2=A0addresses and attempt to reach IPv4 services. =C2=A0A mec=
hanism is needed
>> =C2=A0 =C2=A0to inform hosts that there is no IPv4 support and that th=
ey should
>> =C2=A0 =C2=A0turn off IPv4.
>>
>> =C2=A0 =C2=A0Because there is no IPv4 support on these links, the only=
 way to
>> =C2=A0 =C2=A0notify the dual stack hosts on the link is to use an IPv6=
 mechanism.
>> =C2=A0 =C2=A0An active notification will be much more robust than atte=
mpting to
>> =C2=A0 =C2=A0deduce this state by the lack of IPv4 responses or traffi=
c.
>>
>> =C2=A0 =C2=A0IPv4-only hosts, and dual-stack hosts that do not recogni=
ze the new
>> =C2=A0 =C2=A0flag, will continue to attempt IPv4 operations, in partic=
ular IPv4
>> =C2=A0 =C2=A0discovery protocols typically sent as link-layer broadcas=
ts. =C2=A0This
>> =C2=A0 =C2=A0legacy traffic cannot be prevented by any IPv6 mechanism.=
 =C2=A0The value
>> =C2=A0 =C2=A0of the new flag is limited to dual-stack hosts that recog=
nize it.
>>
>> We were originally thinking it would be an April 1 submission, but aft=
er
>> reading the discussion on the IPv6 list, we decided it makes sense as =
a
>> real submission :-)
>>
>> Please review and comment.
>>
>> Thanks,
>> Bob and Brian
>>
>>
>>> Begin forwarded message:
>>>
>>> *From: *internet-drafts@ietf.org 
>>> *Subject: **New Version Notification for draft-hinden-ipv4flag-00.txt=
*
>>> *Date: *November 17, 2017 at 2:36:31 PM GMT+8
>>> *To: *"Robert M. Hinden" >> >, "Robert Hinden" >> >, "Brian Carpenter"
>>> >
>>>
>>>
>>> A new version of I-D, draft-hinden-ipv4flag-00.txt
>>> has been successfully submitted by Robert M. Hinden and posted to the=

>>> IETF repository.
>>>
>>> Name:draft-hinden-ipv4flag
>>> Revision:00
>>> Title:IPv6 Router Advertisement IPv4 Availability Flag
>>> Document date:2017-11-17
>>> Group:Individual Submission
>>> Pages:5
>>> URL:
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0htt=
ps://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.txt
>>> Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datat=
racker.ietf.org/doc/draft-hinden-ipv4flag/
>>> Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/=
html/draft-hinden-ipv4flag-00
>>> Htmlized:
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/=
html/draft-hinden-ipv4flag-00
>>>
>>>
>>> Abstract:
>>> =C2=A0=C2=A0This document specifies a Router Advertisement Flag to in=
dicate that
>>> =C2=A0=C2=A0there is no IPv4 service on the advertising router. =C2=A0=
This document
>>> =C2=A0=C2=A0updates RFC5175.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org
>>> .
>>>
>>> The IETF Secretariat
>>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>=20
>=20


From nobody Fri Nov 17 00:17:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE393126E01 for ; Fri, 17 Nov 2017 00:17:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 TH3A_6V9dR6X for ; Fri, 17 Nov 2017 00:17:49 -0800 (PST)
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 1E7A7124319 for ; Fri, 17 Nov 2017 00:17:49 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id y80so4719586wmd.0 for ; Fri, 17 Nov 2017 00:17:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=30iuZU4tM4zO09liMG4Kw5MrS7jrHEB5BYIj8AWQwnc=; b=cbe/C7S88IVMXTNWVJkOInQDXlQXCmy9zIEEiFa9tebMAp0/FgZDOuBkBiJBdBoHr3 SDCwdMrRkfu2z7f+Yw72IRAG7qYJzdMwl3ab73Uf1jxCiQTRe/HCBO5ohOBdAc4DMgtR i90JoP4Ua3bZkMwTcrM+a0fCInmIFCmnjLSjoxYzSNAhg4ohEsqf826yIoa/kzVF7dH9 h4CAkBDMHceVIm1C8jsyMDzyhOFaaSJn7DFQph5iSeyUvezw7H8aOcbUQ070rN0YEK/i sOMHtrbzDOk6pnIR98GKoUFgNE1I3pBgdMHWVo1ZWWmMDSya5z97C43VGZg0nQ6fM6TE q6QQ==
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=30iuZU4tM4zO09liMG4Kw5MrS7jrHEB5BYIj8AWQwnc=; b=VZoEFs2MoFidLmaE/CSNTynbKMRZggHdAZbouYxndnGLxkDA787VDWXagu4lzztoHg Doz22AM+imG0eKbgrHsbBgZmQGVnofPWBMqGY8et/2IesM3wipDzvm6lU2Ik6/8hELJ5 c5t7zBCUiDXvUks2SQ7RIuD8MdBPCbTxGStY1WNfTTRRKYbq0gLlaJ1iBdNAdxEezk+7 Bx76hWOX3a3D9F1ZnqF0SgdAdLX5smY2M93J8ziENKizQ8rb4KqCVVKhR10vzLpW2MxJ ckTXJRpZUI3fN3q8U6sgyoPcMKm+Wok6AkpsYbYQeSYAJbgAu5dyIfLepXF49hUne8E2 KZHQ==
X-Gm-Message-State: AJaThX7ywIKziKtQa3Hf6XHt10vRmK9QJeVhpOnGGpi82OyzKki92xMq 8dZIBB8R7bOY97L1lrKRD85TV1jU
X-Google-Smtp-Source: AGs4zMZeO9iZtec2GvqauDCoPTc95RLvmqQNl4PLRhIoWpESbdeAQKftg6vfyof6gkazme+oJsx0qQ==
X-Received: by 10.28.18.1 with SMTP id 1mr3917294wms.88.1510906667575; Fri, 17 Nov 2017 00:17:47 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:47d:205e:4d5:c349? ([2001:67c:1232:144:47d:205e:4d5:c349]) by smtp.gmail.com with ESMTPSA id c22sm133257wme.2.2017.11.17.00.17.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 00:17:46 -0800 (PST)
From: Bob Hinden 
Message-Id: <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_82561F55-6C62-4C17-A999-EF4C500A53CD"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
Date: Fri, 17 Nov 2017 16:17:40 +0800
In-Reply-To: <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar>
Cc: Bob Hinden , IPv6 List 
To: Fernando Gont 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 08:17:52 -0000

--Apple-Mail=_82561F55-6C62-4C17-A999-EF4C500A53CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Fernando,

> On Nov 17, 2017, at 3:57 PM, Fernando Gont  =
wrote:
>=20
> HI, BOb,
>=20
> Comments/questions:
>=20
> * How about the case in which a user employs an IPv4-only printer on =
an
> IPv6-only network?

That=E2=80=99s not an IPv6-only network.  If the user or networks wants =
to use IPv4, then it shouldn=E2=80=99t set Flag=3D1.

>=20
> * Does this document imply that IPv6 is bootstrapped first than, or in
> parallel of, IPv4?
>=20
> * If IPv4-has already been bootstrapped, would 4=3D1 still cause the =
node
> to disable IPv4?

The flag is to tell the host to not use IPv4.  Once the host see the =
Flag=3D1, it should stop sending IPv4.

>=20
> * If 4=3D1, but later 4=3D0, shuld that transition of the 4 bit =
trigger IPv4
> configuration?
>=20

Then start using IPv4 again.

>=20
> * Sec cons: see RFC7113 -- it seems that still the current state of
> affairs for many implementations (unfortunately).

OK, thanks.

Bob

>=20
>=20
> Thanks!
>=20
> Cheers,
> Fernando
>=20
>=20
>=20
>=20
> On 11/17/2017 02:42 PM, Bob Hinden wrote:
>> Hi,
>>=20
>> Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 =
ND
>> Router Advertisements.  =46rom the Introduction:
>>=20
>>    Hosts that support IPv4 and IPv6, usually called dual stack hosts,
>>    need to work on IPv6 only networks.  That is, a link where there =
are
>>    no IPv4 routers and/or IPv4 services.  Monitoring of IPv6-only
>>    networks, for example at the IETF 100 meeting in Singapore, shows
>>    that current dual stack hosts will create local auto-configured =
IPv4
>>    addresses and attempt to reach IPv4 services.  A mechanism is =
needed
>>    to inform hosts that there is no IPv4 support and that they should
>>    turn off IPv4.
>>=20
>>    Because there is no IPv4 support on these links, the only way to
>>    notify the dual stack hosts on the link is to use an IPv6 =
mechanism.
>>    An active notification will be much more robust than attempting to
>>    deduce this state by the lack of IPv4 responses or traffic.
>>=20
>>    IPv4-only hosts, and dual-stack hosts that do not recognize the =
new
>>    flag, will continue to attempt IPv4 operations, in particular IPv4
>>    discovery protocols typically sent as link-layer broadcasts.  This
>>    legacy traffic cannot be prevented by any IPv6 mechanism.  The =
value
>>    of the new flag is limited to dual-stack hosts that recognize it.
>>=20
>> We were originally thinking it would be an April 1 submission, but =
after
>> reading the discussion on the IPv6 list, we decided it makes sense as =
a
>> real submission :-)
>>=20
>> Please review and comment.
>>=20
>> Thanks,
>> Bob and Brian
>>=20
>>=20
>>> Begin forwarded message:
>>>=20
>>> *From: *internet-drafts@ietf.org 
>>> *Subject: **New Version Notification for =
draft-hinden-ipv4flag-00.txt*
>>> *Date: *November 17, 2017 at 2:36:31 PM GMT+8
>>> *To: *"Robert M. Hinden" >> >, "Robert Hinden" =
>> >, "Brian Carpenter"
>>> >
>>>=20
>>>=20
>>> A new version of I-D, draft-hinden-ipv4flag-00.txt
>>> has been successfully submitted by Robert M. Hinden and posted to =
the
>>> IETF repository.
>>>=20
>>> Name:draft-hinden-ipv4flag
>>> Revision:00
>>> Title:IPv6 Router Advertisement IPv4 Availability Flag
>>> Document date:2017-11-17
>>> Group:Individual Submission
>>> Pages:5
>>> URL:
>>>            =
https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.txt
>>> Status:         =
https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
>>> Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-00
>>> Htmlized:
>>>       https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-00
>>>=20
>>>=20
>>> Abstract:
>>>   This document specifies a Router Advertisement Flag to indicate =
that
>>>   there is no IPv4 service on the advertising router.  This document
>>>   updates RFC5175.
>>>=20
>>>=20
>>>=20
>>>=20
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org
>>> .
>>>=20
>>> The IETF Secretariat
>>>=20
>>=20
>>=20
>>=20
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>=20
>=20
>=20
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>=20
>=20
>=20


--Apple-Mail=_82561F55-6C62-4C17-A999-EF4C500A53CD
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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloOmyQACgkQrut0EXfn
u6h+sAgAqS8sD3etHZeS0wuynmWkwJQ8k5MnOUE9GxlzgQyPGVihh4WLVfvuPiB+
lHXmXxDYsggZ7TwfMfOBg1d2nN+DJN4k9aDw4I1irvJShuqJlHpaiivm/nzWeMQ+
BM/KFTuLu3pC2GQg/wyxLuBHLIcITkW5krKqSCZIDSGvSW3CsIZ2d65YTHFM2YTD
FWx+B348o1pF13DkFSwKSwWPDB9dNGpGvlKDeWyQI3B2fXZiLfqdhGa/TqwcnvCg
Z2a9UHilwd7N8RVHs9fq2fgUs+xkrED8cqgxSQISH1li7b7POhwamqh5cSn2f0q2
v3wV8uXcjcvTeYdZXyMfBgDfGSO04g==
=A9UG
-----END PGP SIGNATURE-----

--Apple-Mail=_82561F55-6C62-4C17-A999-EF4C500A53CD--


From nobody Fri Nov 17 00:31:00 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AA2129432 for ; Fri, 17 Nov 2017 00:30:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXvGfQB2UcN3 for ; Fri, 17 Nov 2017 00:30:56 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 22422129417 for ; Fri, 17 Nov 2017 00:30:56 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id k66so1789898lfg.3 for ; Fri, 17 Nov 2017 00:30:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BNYtrpv0ATdnHigbWFjkEXkVBgimfjkRw2/0D4lPLlQ=; b=k7kpHedtHMnHiIt8Jklcaw3KWY+Mat/3mFjIUkQqSTu+gBdWey0LI3WNHgJTdvOJdE SmkMH88jq/52u/NR/bo/QRjzYxPg3p7nycG0gz9ILJM69ga11WE+9qgAdjnyw5S+Fxob XQGxRrWBhBNwtTDz57vyGKx0WHJt1E7YHy2NtuWvuskl0IflDxyAzDYbILaos6lYuR1G SNM2hBWqDDbSvdVs3fyMUq1if2KSyUD2f9gdeFRIuOg1uIMOucKYN8iKRv2YRbU0vtzf uQDM16nCWn98btvDFAXDUfuAs9hb6oQ0F33fiW7Lpp89JS8BYlv+K/VHTTNvYuC56Rd7 8jJg==
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=BNYtrpv0ATdnHigbWFjkEXkVBgimfjkRw2/0D4lPLlQ=; b=mYW75EvyU7L3OlbWtgGYqLNcg8viJpSKWcyp7bQwGrSExGJeoRrKR7OakyjfijC335 m7u/phviQ9nkkBFpYzxKmrd50PWxPS0isp4CBar9DGNaezJwQwGllTLnEYMRVRcO6IV5 5Rqe28Pqa42BOY3ueKi6pOZSgzOOvAFsAj6chrFXyHWPRAY9RdoYyOP1e+0cVHKe1oyg vWpFgMf5KHx09/8qXhTeMJTy1kRJmfHL0Pqpb+ZsbaUSCLT3dzzHmTBtHdArupBFXV3/ HvDNm6HDCM3b9CQbbUz4dnUQrE8nnCMirKgtCAxQjC0F3YZjIw3fm6xIeRf81NxzM46q S4UQ==
X-Gm-Message-State: AJaThX4h6EsnKLqCM8QJdKrUvtqgRRjEfVtMZWlxmos/W+v57IbMCPhd nhtOCeG+JAaB1/GBqFqrmv3ifUpHOhjikef+8G4=
X-Google-Smtp-Source: AGs4zMZHd4YQsUmchC/wuiYnsFAWGeBPCmaPoYX+u6a6WamxNtdfjZhwMasL0uxqE9i7lRxYbthVX/WM6BUKrq2BENI=
X-Received: by 10.46.68.195 with SMTP id b64mr424628ljf.121.1510907454267; Fri, 17 Nov 2017 00:30:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.205.2 with HTTP; Fri, 17 Nov 2017 00:30:33 -0800 (PST)
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Jen Linkova 
Date: Fri, 17 Nov 2017 19:30:33 +1100
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Mohamed Boucadair 
Cc: Ole Troan , 6man WG , Mark Andrews 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 08:30:59 -0000

On Thu, Nov 16, 2017 at 12:35 AM,   wrote:
>> IMHO the optimal solution is:
>> - the network SHOULD provide a host with NAT64 prefix information in
>> RA (I do not believe that information needs to be duplicated in DHCP
>> at all);
>
> [Med] Please check: https://tools.ietf.org/html/rfc7051#section-5.7.3

Thanks for pointing this out. To be honest I disagree with what that
section says.
I'm trying to refrain from participating  'SLAAC vs DHCPv6' so I will
not mention all those issues with multihoming for example but....
If you are saying that the prefix should not be distributed via RAs
because it needs to be configured on routers, then what about DNS
servers and SLAAC prefixes themselves?
There are SLAAC-only networks out there while RFC7934 does not
recommend DHCPv6 as the only way to configure clients.
So between those two RA does look like a better way.

> Things may get complex if multiple NSPs are used for load-balancing or if=
 destination based NAT64s are deployed. A list of issues is elaborated in h=
ttps://tools.ietf.org/html/rfc7225#section-3.1

It's more like v6ops question but I'm really curious if multiple
prefixes scenario is real.
RA option might contain multiple prefixes anyway.

>> >> On 15 Nov 2017, at 08:06, Mark Andrews  wrote:
>> >>
>> >>
>> >>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti 
>> wrote:
>> >>>
>> >>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews  wrote:
>> >>> Is there any reason to run DNS64 at all these days?  ipv4only.arpa c=
an
>> be a preconfigured
>> >>> zone which allows CLAT to get its mapping.  All the phones have CLAT
>> support.
>> >>>
>> >>> That's an interesting idea. It would work in theory, but such a
>> network would completely break devices that don't support 464xlat. That
>> gives up one of the major advantages of NAT64/DNS64, which is that it's =
a
>> 90% solution even just by itself - yes, IPv4-only applications and addre=
ss
>> literals exist, but most simple client/server applications Just Work
>> behind it.
>> >>
>> >> And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.  It b=
asically requires
>> EVERY DNS VALIDATOR ON
>> >> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64
>> SERVER.
>> >>
>> >> DNS64/NAT64 was presented as NOT REQUIRING node changes when first
>> mooted.  It keeps on
>> >> requiring more and more highly invasive node changes to support.  It
>> was from the very beginning
>> >> bad engineering.   To get IPv4 as a service some node changes are
>> required.  Lets make sure they
>> >> are MINIMAL ones.
>> >>
>> >> Just for the record DNSSEC validators need to send BOTH CD=3D0 and CD=
=3D1
>> queries to get answers
>> >> though a upstream VALIDATING server which includes a VALIDATING DNS64
>> server as CD=3D0 and
>> >> CD=3D1 address different DNSSEC threats.  I tried very hard to point =
that
>> out when RFC 6147 was
>> >> being written but the working group decide that CD indicated whether
>> the client was validating or
>> >> not.  There is NO SUCH INDICATION in a DNS message.
>> >>
>> >>  If a query arrives at a vDNS64 device with the "Checking Disabled"
>> >>   (CD) bit set, it is an indication that the querying agent wants all
>> >>   the validation data so it can do checking itself.  By local policy,
>> >>   vDNS64 could still validate, but it must return all data to the
>> >>   querying agent anyway.
>> >>
>> >> CD=3D0 queries causes the upstream validating servers to reject incom=
ing
>> spoofed answers
>> >> or stale answers (this is a common operational problem).
>> >>
>> >> CD=3D1 queries allow the validation to succeed when the upstream
>> validator has a bad trust
>> >> anchor or a bad clock which is rejecting legitimate answers.
>> >>
>> >> A validating client can=E2=80=99t just send CD=3D1 queries as the ups=
tream
>> validator doesn=E2=80=99t kick in.
>> >> The upstream validator can lock onto a stale answer source.  It needs
>> to send CD=3D0 queries
>> >> on validation failure to force the upstream validator to try multiple
>> sources.
>> >>
>> >> A validating client can=E2=80=99t just send CD=3D0.  It needs to send=
 CD=3D1 on
>> SERVFAIL in case the
>> >> upstream validator has a bad trust anchor (likely with the upcoming
>> root KSK roll) or has
>> >> a bad clock (these usually get fixed fast).
>> >>
>> >> Now to get a answer from a signed zone with servers with stale answer=
s
>> a validatiing DNS64 client
>> >> needs to send:
>> >>
>> >> a) send CD=3D1 and validation failure send CD=3D0 then on AAAA valida=
tion
>> failure send CD=3D1 and
>> >>    hope the TTL was not 0 and that is not cachable and there is no
>> assurance that you won=E2=80=99t get
>> >>    a answer from a stale source.
>> >>
>> >>       or
>> >>
>> >> b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 and =
hope
>> the TTL was not 0 as
>> >>    that is not cachable and there is no assurance that you won=E2=80=
=99t get a
>> answer from a stale source.
>> >>
>> >> TTL=3D0 answers exist.
>> >>
>> >> Note none of this is documented in a RFC.  You have to understand how
>> both DNSSEC and DNS64 work to
>> >> realise this.
>> >>
>> >> IPV4ONLY.ARPA is currently has a secure delegation which breaks prefi=
x
>> discover for DNS VALIDATORS.
>> >> Note =E2=80=9Cad=E2=80=9D is set in the flags.  Yes, I=E2=80=99ve sub=
mitted a errata.  Yes,
>> I=E2=80=99ve opened a ticket to get it fixed but
>> >> based on past experience that could take months if it happens at all.
>> You will note that the recursive
>> >> server is running on the loopback interface so all DNS answers are
>> being validated here.
>> >>
>> >> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
>> >> ;; BADCOOKIE, retrying.
>> >>
>> >> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
>> >> ;; global options: +cmd
>> >> ;; Got answer:
>> >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
>> >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL:=
 1
>> >>
>> >> ;; OPT PSEUDOSECTION:
>> >> ; EDNS: version: 0, flags:; udp: 4096
>> >> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
>> >> ;; QUESTION SECTION:
>> >> ;IPV4ONLY.ARPA.                       IN      A
>> >>
>> >> ;; ANSWER SECTION:
>> >> ipv4only.arpa.                26574   IN      A       192.0.0.171
>> >> ipv4only.arpa.                26574   IN      A       192.0.0.170
>> >>
>> >> ;; Query time: 0 msec
>> >> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> >> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
>> >> ;; MSG SIZE  rcvd: 115
>> >>
>> >> [rock:bind9/bin/named] marka%
>> >>
>> >>> It's not true that all phones have clat support. Notably, Apple not
>> only does not support it but appears ideologically opposed to it on the
>> grounds that it does not have a good exit strategy (because it makes it
>> possible to run IPv4-only apps forever).
>> >>
>> >>
>> >> --
>> >> Mark Andrews, ISC
>> >> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> >> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>> >>
>> >> --------------------------------------------------------------------
>> >> IETF IPv6 working group mailing list
>> >> ipv6@ietf.org
>> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> >> --------------------------------------------------------------------
>> >
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > ipv6@ietf.org
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>> >
>>
>>
>>
>> --
>> SY, Jen Linkova aka Furry
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------



--=20
SY, Jen Linkova aka Furry


From nobody Fri Nov 17 00:38:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EAE129411 for ; Fri, 17 Nov 2017 00:38:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 DBkmIMTPFeJg for ; Fri, 17 Nov 2017 00:38:09 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697261287A0 for ; Fri, 17 Nov 2017 00:38:09 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id l24so1455123pfj.6 for ; Fri, 17 Nov 2017 00:38:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pjoWuo5+/7nPfbV6izOrhs+jmW82By3frS5i5AguoSw=; b=rYozwLWSDLjWSBOyAkJNotfiUx8YKYqrv9yFqU1lpE4+IxzO7nnpxh9h9QMKG11kdM FUEE7T8VCVErDMVrvFYTYgy5M6p0lY3JItkKUSJ5zn+smJS7IuhWglowokIu5AhB0+sd 7kf+fp1ZSk02Cn0L47Z8KPpHNmQkNCegUy57MYdVnuN6oAtf2PXQzKq7gHWK/ojcax/P kNqW8k37/lWQUZ/0Aaj/qXRwrbLo6nAnuTNk63kbiIwxh7Ki4oVkaFOZywqB6RJbHeTL wBtiGI1j/Pxoaphb/dVNlYtgCFxqjqXx4m6ssUu3Urnmvz6NkpbwlkMbLduIIfmLyOPW csSQ==
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=pjoWuo5+/7nPfbV6izOrhs+jmW82By3frS5i5AguoSw=; b=r2OoTemJzNJPZGQhRVsqplpb2xVv9UpfnyPT57UbgW9YXPKMrK8ojl1IUUwPyek5Hm K5HuQGcTofcErpyB5MD3e5swmHSObj8Yq/VMrqWySpmRaa5Htdo2opAcIVlp75VQVvsC x/gzaWjnKu4ijYS7T61idKuy9AJVC68gXXnyVeJcJxFxMsMoCaNnzwsDcMT4YANofITR AWEmA/QOjRaXYaZ2KxGMW2od4BEE3YFZJWVkAuxD1ArV0kAgPh/TL9SBqUk911eL653z uh0kCTnj4OROrFYTcBSCoqzqEu616JaJpTy3hXpHKY70YZM1TvS83C3UxjXqveJ7T0j9 LkQw==
X-Gm-Message-State: AJaThX5kH8JW+JYFczUDTTZr70DWQmovebFbZBtWNe16QSrVWdQfdcDZ B5mv4/ZOXt9JjEtwY5O4cPU=
X-Google-Smtp-Source: AGs4zMbUJEsTLgaWOYCUErrzIHeySeSIO7d8HzrjH12Z/eDiuqsv9WXknQsDXRBfsaLl51Bbg48cFQ==
X-Received: by 10.159.235.151 with SMTP id f23mr4608502plr.384.1510907888703;  Fri, 17 Nov 2017 00:38:08 -0800 (PST)
Received: from [21.244.79.126] ([172.56.30.43]) by smtp.gmail.com with ESMTPSA id x1sm7396697pfh.113.2017.11.17.00.38.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 00:38:07 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: IPv6 only host NAT64 requirements?
From: Fred Baker 
X-Mailer: iPhone Mail (15B150)
In-Reply-To: 
Date: Fri, 17 Nov 2017 16:38:02 +0800
Cc: Mohamed Boucadair , 6man WG , Mark Andrews 
Content-Transfer-Encoding: quoted-printable
Message-Id: <962DDEC3-3F89-4A7E-9C54-D7C96D59BD24@gmail.com>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 
To: Jen Linkova 
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 08:38:12 -0000

Tore Anderson has a multiple prefix installation.

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

> On Nov 17, 2017, at 4:30 PM, Jen Linkova  wrote:
>=20
> On Thu, Nov 16, 2017 at 12:35 AM,   wrote:
>>> IMHO the optimal solution is:
>>> - the network SHOULD provide a host with NAT64 prefix information in
>>> RA (I do not believe that information needs to be duplicated in DHCP
>>> at all);
>>=20
>> [Med] Please check: https://tools.ietf.org/html/rfc7051#section-5.7.3
>=20
> Thanks for pointing this out. To be honest I disagree with what that
> section says.
> I'm trying to refrain from participating  'SLAAC vs DHCPv6' so I will
> not mention all those issues with multihoming for example but....
> If you are saying that the prefix should not be distributed via RAs
> because it needs to be configured on routers, then what about DNS
> servers and SLAAC prefixes themselves?
> There are SLAAC-only networks out there while RFC7934 does not
> recommend DHCPv6 as the only way to configure clients.
> So between those two RA does look like a better way.
>=20
>> Things may get complex if multiple NSPs are used for load-balancing or if=
 destination based NAT64s are deployed. A list of issues is elaborated in ht=
tps://tools.ietf.org/html/rfc7225#section-3.1
>=20
> It's more like v6ops question but I'm really curious if multiple
> prefixes scenario is real.
> RA option might contain multiple prefixes anyway.
>=20
>>>>> On 15 Nov 2017, at 08:06, Mark Andrews  wrote:
>>>>>=20
>>>>>=20
>>>>>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti 
>>> wrote:
>>>>>>=20
>>>>>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews  wrote:
>>>>>> Is there any reason to run DNS64 at all these days?  ipv4only.arpa ca=
n
>>> be a preconfigured
>>>>>> zone which allows CLAT to get its mapping.  All the phones have CLAT
>>> support.
>>>>>>=20
>>>>>> That's an interesting idea. It would work in theory, but such a
>>> network would completely break devices that don't support 464xlat. That
>>> gives up one of the major advantages of NAT64/DNS64, which is that it's a=

>>> 90% solution even just by itself - yes, IPv4-only applications and addre=
ss
>>> literals exist, but most simple client/server applications Just Work
>>> behind it.
>>>>>=20
>>>>> And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.  It ba=
sically requires
>>> EVERY DNS VALIDATOR ON
>>>>> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64
>>> SERVER.
>>>>>=20
>>>>> DNS64/NAT64 was presented as NOT REQUIRING node changes when first
>>> mooted.  It keeps on
>>>>> requiring more and more highly invasive node changes to support.  It
>>> was from the very beginning
>>>>> bad engineering.   To get IPv4 as a service some node changes are
>>> required.  Lets make sure they
>>>>> are MINIMAL ones.
>>>>>=20
>>>>> Just for the record DNSSEC validators need to send BOTH CD=3D0 and CD=3D=
1
>>> queries to get answers
>>>>> though a upstream VALIDATING server which includes a VALIDATING DNS64
>>> server as CD=3D0 and
>>>>> CD=3D1 address different DNSSEC threats.  I tried very hard to point t=
hat
>>> out when RFC 6147 was
>>>>> being written but the working group decide that CD indicated whether
>>> the client was validating or
>>>>> not.  There is NO SUCH INDICATION in a DNS message.
>>>>>=20
>>>>> If a query arrives at a vDNS64 device with the "Checking Disabled"
>>>>>  (CD) bit set, it is an indication that the querying agent wants all
>>>>>  the validation data so it can do checking itself.  By local policy,
>>>>>  vDNS64 could still validate, but it must return all data to the
>>>>>  querying agent anyway.
>>>>>=20
>>>>> CD=3D0 queries causes the upstream validating servers to reject incomi=
ng
>>> spoofed answers
>>>>> or stale answers (this is a common operational problem).
>>>>>=20
>>>>> CD=3D1 queries allow the validation to succeed when the upstream
>>> validator has a bad trust
>>>>> anchor or a bad clock which is rejecting legitimate answers.
>>>>>=20
>>>>> A validating client can=E2=80=99t just send CD=3D1 queries as the upst=
ream
>>> validator doesn=E2=80=99t kick in.
>>>>> The upstream validator can lock onto a stale answer source.  It needs
>>> to send CD=3D0 queries
>>>>> on validation failure to force the upstream validator to try multiple
>>> sources.
>>>>>=20
>>>>> A validating client can=E2=80=99t just send CD=3D0.  It needs to send C=
D=3D1 on
>>> SERVFAIL in case the
>>>>> upstream validator has a bad trust anchor (likely with the upcoming
>>> root KSK roll) or has
>>>>> a bad clock (these usually get fixed fast).
>>>>>=20
>>>>> Now to get a answer from a signed zone with servers with stale answers=

>>> a validatiing DNS64 client
>>>>> needs to send:
>>>>>=20
>>>>> a) send CD=3D1 and validation failure send CD=3D0 then on AAAA validat=
ion
>>> failure send CD=3D1 and
>>>>>   hope the TTL was not 0 and that is not cachable and there is no
>>> assurance that you won=E2=80=99t get
>>>>>   a answer from a stale source.
>>>>>=20
>>>>>      or
>>>>>=20
>>>>> b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 and h=
ope
>>> the TTL was not 0 as
>>>>>   that is not cachable and there is no assurance that you won=E2=80=99=
t get a
>>> answer from a stale source.
>>>>>=20
>>>>> TTL=3D0 answers exist.
>>>>>=20
>>>>> Note none of this is documented in a RFC.  You have to understand how
>>> both DNSSEC and DNS64 work to
>>>>> realise this.
>>>>>=20
>>>>> IPV4ONLY.ARPA is currently has a secure delegation which breaks prefix=

>>> discover for DNS VALIDATORS.
>>>>> Note =E2=80=9Cad=E2=80=9D is set in the flags.  Yes, I=E2=80=99ve subm=
itted a errata.  Yes,
>>> I=E2=80=99ve opened a ticket to get it fixed but
>>>>> based on past experience that could take months if it happens at all.
>>> You will note that the recursive
>>>>> server is running on the loopback interface so all DNS answers are
>>> being validated here.
>>>>>=20
>>>>> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
>>>>> ;; BADCOOKIE, retrying.
>>>>>=20
>>>>> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
>>>>> ;; global options: +cmd
>>>>> ;; Got answer:
>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
>>>>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1=

>>>>>=20
>>>>> ;; OPT PSEUDOSECTION:
>>>>> ; EDNS: version: 0, flags:; udp: 4096
>>>>> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
>>>>> ;; QUESTION SECTION:
>>>>> ;IPV4ONLY.ARPA.                       IN      A
>>>>>=20
>>>>> ;; ANSWER SECTION:
>>>>> ipv4only.arpa.                26574   IN      A       192.0.0.171
>>>>> ipv4only.arpa.                26574   IN      A       192.0.0.170
>>>>>=20
>>>>> ;; Query time: 0 msec
>>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>>> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
>>>>> ;; MSG SIZE  rcvd: 115
>>>>>=20
>>>>> [rock:bind9/bin/named] marka%
>>>>>=20
>>>>>> It's not true that all phones have clat support. Notably, Apple not
>>> only does not support it but appears ideologically opposed to it on the
>>> grounds that it does not have a good exit strategy (because it makes it
>>> possible to run IPv4-only apps forever).
>>>>>=20
>>>>>=20
>>>>> --
>>>>> Mark Andrews, ISC
>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>>>>>=20
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> ipv6@ietf.org
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>>=20
>>>>=20
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> SY, Jen Linkova aka Furry
>>>=20
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>=20
>=20
>=20
> --=20
> SY, Jen Linkova aka Furry
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Fri Nov 17 00:47:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC841200CF for ; Fri, 17 Nov 2017 00:47:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cedOk4DTMzM for ; Fri, 17 Nov 2017 00:47:11 -0800 (PST)
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 D796F129400 for ; Fri, 17 Nov 2017 00:47:09 -0800 (PST)
Received: by mail-pf0-x22a.google.com with SMTP id r62so1473204pfd.5 for ; Fri, 17 Nov 2017 00:47:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=kvnNC435VYffXOeHweZ7hkBTpoce0hKRIJ475j65oqo=; b=WY8Nlg4bhuhpiTe66z8I4LExc8Hia7jt3K/YYsUG9eKNseuxEzFKggxKPd8X3qB0on npuEeHEsAjtSzw+OxIf2g+nvz/NC/uYqVmzXmU+Dyi04Syi6Xb9gHVTk0oPkQBuGLa6y kKOEJBGstQK5efaBpOA67flbwLjxndLEZX/oPhUB8sDiFZhdxG4ZPl/fxy17Ki18ea1H rFCf9Yox5MTIY9a5ZgObCcSN1dBhaUS/nZYcQ5JrlVCUGAHbVI3xXm/AFCHZVSuwvDnC g2hLv11JbBaoiv+7YAFFutgpuRET/aLGgi3Jo9pkgSFfr0pYYf9bOrvVZ8qdhlU8942n KfYg==
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=kvnNC435VYffXOeHweZ7hkBTpoce0hKRIJ475j65oqo=; b=Vw2Z/4zxM9Sh8lNBD6GSx2vgHOR7sJHuWpyY96UTGb3YoYmZwbCnD0olTSiAb1mARk 1k7nQMty1FKfKZQ3CZOmKrnnl5ZWtZqtFvVD17zbwaCNI8EdjuxNlimUvTfwNxb5vzMI HP8yxeei0SaSaUYXR8dxk+WwONwB7hJ4uLJ/b/X9+C46p5p+Gr+4DhO0QuvCmtl3iRhr c02KmBO4NH16kcDgp0aYmuA/pVN5wMAbeNtKdG5C6I3SgxaWLoIA6VB2dKMd9Vgkx/2F g4M1p4rqB7NjE4yZwqHw+GCNxK9tEf6tmYrH/ckKg2uOW92oQVV4AhVqCnovZmP5tiiE cC9g==
X-Gm-Message-State: AJaThX7PDL8U/qmzidyyluu+j4zm0bnvXada251uDZeHVVC7ZR6jgdn9 r3FqsDRqzvsyyCr84XHqeog=
X-Google-Smtp-Source: AGs4zMbrEpqIQ8ya1ZTqz2uHDfJOuGKCpEyu9tp1yK3srvgKkbLPZrtuNkK+P20Qb5XIINLHpHup/A==
X-Received: by 10.99.154.65 with SMTP id e1mr4351294pgo.18.1510908429282; Fri, 17 Nov 2017 00:47:09 -0800 (PST)
Received: from [21.244.79.126] ([172.56.30.43]) by smtp.gmail.com with ESMTPSA id s65sm6031352pfj.81.2017.11.17.00.47.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 00:47:08 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: Re: IPv6 only host NAT64 requirements?
From: Fred Baker 
X-Mailer: iPhone Mail (15B150)
In-Reply-To: <962DDEC3-3F89-4A7E-9C54-D7C96D59BD24@gmail.com>
Date: Fri, 17 Nov 2017 16:47:02 +0800
Cc: Mohamed Boucadair , 6man WG , Mark Andrews 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <962DDEC3-3F89-4A7E-9C54-D7C96D59BD24@gmail.com>
To: Jen Linkova 
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 08:47:14 -0000

To be very honest, situations like Tore=E2=80=99s have always made me questi=
on the wisdom of a special prefix for IPv4/IPv6 NAT. One is communicating wi=
th a peer at an IPv6 address. One got the address because the initiating SYN=
-or-whatever came from it, or the address was provided in DNS. Tomorrow, wit=
h any luck, it will be a native address; today, it is a /96 embedded in a /6=
4, one of many /64s in the network.

Why should I know or care that the path to the peer has a NAT in it? Yes, th=
ere are some end to end session assumptions that fail. No matter what I do, t=
hey will fail. I at least have as good connectivity as I would have in an IP=
v4 network.

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

> On Nov 17, 2017, at 4:38 PM, Fred Baker  wrote:
>=20
> Tore Anderson has a multiple prefix installation.
>=20
> Sent using a machine that autocorrects in interesting ways...
>=20
>> On Nov 17, 2017, at 4:30 PM, Jen Linkova  wrote:
>>=20
>> On Thu, Nov 16, 2017 at 12:35 AM,   wrote:
>>>> IMHO the optimal solution is:
>>>> - the network SHOULD provide a host with NAT64 prefix information in
>>>> RA (I do not believe that information needs to be duplicated in DHCP
>>>> at all);
>>>=20
>>> [Med] Please check: https://tools.ietf.org/html/rfc7051#section-5.7.3
>>=20
>> Thanks for pointing this out. To be honest I disagree with what that
>> section says.
>> I'm trying to refrain from participating  'SLAAC vs DHCPv6' so I will
>> not mention all those issues with multihoming for example but....
>> If you are saying that the prefix should not be distributed via RAs
>> because it needs to be configured on routers, then what about DNS
>> servers and SLAAC prefixes themselves?
>> There are SLAAC-only networks out there while RFC7934 does not
>> recommend DHCPv6 as the only way to configure clients.
>> So between those two RA does look like a better way.
>>=20
>>> Things may get complex if multiple NSPs are used for load-balancing or i=
f destination based NAT64s are deployed. A list of issues is elaborated in h=
ttps://tools.ietf.org/html/rfc7225#section-3.1
>>=20
>> It's more like v6ops question but I'm really curious if multiple
>> prefixes scenario is real.
>> RA option might contain multiple prefixes anyway.
>>=20
>>>>>> On 15 Nov 2017, at 08:06, Mark Andrews  wrote:
>>>>>>=20
>>>>>>=20
>>>>>>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti 
>>>> wrote:
>>>>>>>=20
>>>>>>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews  wrote:=

>>>>>>> Is there any reason to run DNS64 at all these days?  ipv4only.arpa c=
an
>>>> be a preconfigured
>>>>>>> zone which allows CLAT to get its mapping.  All the phones have CLAT=

>>>> support.
>>>>>>>=20
>>>>>>> That's an interesting idea. It would work in theory, but such a
>>>> network would completely break devices that don't support 464xlat. That=

>>>> gives up one of the major advantages of NAT64/DNS64, which is that it's=
 a
>>>> 90% solution even just by itself - yes, IPv4-only applications and addr=
ess
>>>> literals exist, but most simple client/server applications Just Work
>>>> behind it.
>>>>>>=20
>>>>>> And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.  It b=
asically requires
>>>> EVERY DNS VALIDATOR ON
>>>>>> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A DNS64
>>>> SERVER.
>>>>>>=20
>>>>>> DNS64/NAT64 was presented as NOT REQUIRING node changes when first
>>>> mooted.  It keeps on
>>>>>> requiring more and more highly invasive node changes to support.  It
>>>> was from the very beginning
>>>>>> bad engineering.   To get IPv4 as a service some node changes are
>>>> required.  Lets make sure they
>>>>>> are MINIMAL ones.
>>>>>>=20
>>>>>> Just for the record DNSSEC validators need to send BOTH CD=3D0 and CD=
=3D1
>>>> queries to get answers
>>>>>> though a upstream VALIDATING server which includes a VALIDATING DNS64=

>>>> server as CD=3D0 and
>>>>>> CD=3D1 address different DNSSEC threats.  I tried very hard to point t=
hat
>>>> out when RFC 6147 was
>>>>>> being written but the working group decide that CD indicated whether
>>>> the client was validating or
>>>>>> not.  There is NO SUCH INDICATION in a DNS message.
>>>>>>=20
>>>>>> If a query arrives at a vDNS64 device with the "Checking Disabled"
>>>>>> (CD) bit set, it is an indication that the querying agent wants all
>>>>>> the validation data so it can do checking itself.  By local policy,
>>>>>> vDNS64 could still validate, but it must return all data to the
>>>>>> querying agent anyway.
>>>>>>=20
>>>>>> CD=3D0 queries causes the upstream validating servers to reject incom=
ing
>>>> spoofed answers
>>>>>> or stale answers (this is a common operational problem).
>>>>>>=20
>>>>>> CD=3D1 queries allow the validation to succeed when the upstream
>>>> validator has a bad trust
>>>>>> anchor or a bad clock which is rejecting legitimate answers.
>>>>>>=20
>>>>>> A validating client can=E2=80=99t just send CD=3D1 queries as the ups=
tream
>>>> validator doesn=E2=80=99t kick in.
>>>>>> The upstream validator can lock onto a stale answer source.  It needs=

>>>> to send CD=3D0 queries
>>>>>> on validation failure to force the upstream validator to try multiple=

>>>> sources.
>>>>>>=20
>>>>>> A validating client can=E2=80=99t just send CD=3D0.  It needs to send=
 CD=3D1 on
>>>> SERVFAIL in case the
>>>>>> upstream validator has a bad trust anchor (likely with the upcoming
>>>> root KSK roll) or has
>>>>>> a bad clock (these usually get fixed fast).
>>>>>>=20
>>>>>> Now to get a answer from a signed zone with servers with stale answer=
s
>>>> a validatiing DNS64 client
>>>>>> needs to send:
>>>>>>=20
>>>>>> a) send CD=3D1 and validation failure send CD=3D0 then on AAAA valida=
tion
>>>> failure send CD=3D1 and
>>>>>>  hope the TTL was not 0 and that is not cachable and there is no
>>>> assurance that you won=E2=80=99t get
>>>>>>  a answer from a stale source.
>>>>>>=20
>>>>>>     or
>>>>>>=20
>>>>>> b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 and h=
ope
>>>> the TTL was not 0 as
>>>>>>  that is not cachable and there is no assurance that you won=E2=80=99=
t get a
>>>> answer from a stale source.
>>>>>>=20
>>>>>> TTL=3D0 answers exist.
>>>>>>=20
>>>>>> Note none of this is documented in a RFC.  You have to understand how=

>>>> both DNSSEC and DNS64 work to
>>>>>> realise this.
>>>>>>=20
>>>>>> IPV4ONLY.ARPA is currently has a secure delegation which breaks prefi=
x
>>>> discover for DNS VALIDATORS.
>>>>>> Note =E2=80=9Cad=E2=80=9D is set in the flags.  Yes, I=E2=80=99ve sub=
mitted a errata.  Yes,
>>>> I=E2=80=99ve opened a ticket to get it fixed but
>>>>>> based on past experience that could take months if it happens at all.=

>>>> You will note that the recursive
>>>>>> server is running on the loopback interface so all DNS answers are
>>>> being validated here.
>>>>>>=20
>>>>>> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
>>>>>> ;; BADCOOKIE, retrying.
>>>>>>=20
>>>>>> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
>>>>>> ;; global options: +cmd
>>>>>> ;; Got answer:
>>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
>>>>>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL:=
 1
>>>>>>=20
>>>>>> ;; OPT PSEUDOSECTION:
>>>>>> ; EDNS: version: 0, flags:; udp: 4096
>>>>>> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
>>>>>> ;; QUESTION SECTION:
>>>>>> ;IPV4ONLY.ARPA.                       IN      A
>>>>>>=20
>>>>>> ;; ANSWER SECTION:
>>>>>> ipv4only.arpa.                26574   IN      A       192.0.0.171
>>>>>> ipv4only.arpa.                26574   IN      A       192.0.0.170
>>>>>>=20
>>>>>> ;; Query time: 0 msec
>>>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>>>> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
>>>>>> ;; MSG SIZE  rcvd: 115
>>>>>>=20
>>>>>> [rock:bind9/bin/named] marka%
>>>>>>=20
>>>>>>> It's not true that all phones have clat support. Notably, Apple not
>>>> only does not support it but appears ideologically opposed to it on the=

>>>> grounds that it does not have a good exit strategy (because it makes it=

>>>> possible to run IPv4-only apps forever).
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> Mark Andrews, ISC
>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>>>>>>=20
>>>>>> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> ipv6@ietf.org
>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> --------------------------------------------------------------------
>>>>>=20
>>>>>=20
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> ipv6@ietf.org
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> SY, Jen Linkova aka Furry
>>>>=20
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>=20
>>=20
>>=20
>> --=20
>> SY, Jen Linkova aka Furry
>>=20
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------


From nobody Fri Nov 17 00:48:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C7212944F for ; Fri, 17 Nov 2017 00:47:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level: 
X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjE5cq-gmJQg for ; Fri, 17 Nov 2017 00:47:47 -0800 (PST)
Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2325D1200CF for ; Fri, 17 Nov 2017 00:47:47 -0800 (PST)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 98475C08C1; Fri, 17 Nov 2017 09:47:45 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 7633E1A0073; Fri, 17 Nov 2017 09:47:45 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0361.001; Fri, 17 Nov 2017 09:47:45 +0100
From: 
To: Jen Linkova 
CC: Ole Troan , 6man WG , Mark Andrews 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTX35jswcBlM/8z0eNn33c3P4KiKMYP7TQ
Date: Fri, 17 Nov 2017 08:47:44 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 08:47:51 -0000

SGkgSmVuLCANCg0KUGxlYXNlIHNlZSBpbmxpbmUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0t
LU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogSmVuIExpbmtvdmEgW21haWx0bzpmdXJy
eTEzQGdtYWlsLmNvbV0NCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSAxNyBub3ZlbWJyZSAyMDE3IDA5
OjMxDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4gQ2PCoDogT2xlIFRyb2Fu
OyA2bWFuIFdHOyBNYXJrIEFuZHJld3MNCj4gT2JqZXTCoDogUmU6IElQdjYgb25seSBob3N0IE5B
VDY0IHJlcXVpcmVtZW50cz8NCj4gDQo+IE9uIFRodSwgTm92IDE2LCAyMDE3IGF0IDEyOjM1IEFN
LCAgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiA+PiBJTUhPIHRoZSBv
cHRpbWFsIHNvbHV0aW9uIGlzOg0KPiA+PiAtIHRoZSBuZXR3b3JrIFNIT1VMRCBwcm92aWRlIGEg
aG9zdCB3aXRoIE5BVDY0IHByZWZpeCBpbmZvcm1hdGlvbiBpbg0KPiA+PiBSQSAoSSBkbyBub3Qg
YmVsaWV2ZSB0aGF0IGluZm9ybWF0aW9uIG5lZWRzIHRvIGJlIGR1cGxpY2F0ZWQgaW4gREhDUA0K
PiA+PiBhdCBhbGwpOw0KPiA+DQo+ID4gW01lZF0gUGxlYXNlIGNoZWNrOiBodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvcmZjNzA1MSNzZWN0aW9uLTUuNy4zDQo+IA0KPiBUaGFua3MgZm9yIHBv
aW50aW5nIHRoaXMgb3V0LiBUbyBiZSBob25lc3QgSSBkaXNhZ3JlZSB3aXRoIHdoYXQgdGhhdA0K
PiBzZWN0aW9uIHNheXMuDQoNCltNZWRdIEkgYWxzbyBkaXNhZ3JlZSB3aXRoIG1hbnkgb2YgdGhl
IHBvaW50cyBpbiBSRkM3MDUxLCBidXQgdGhhdCBpcyB0aGUgZG9jdW1lbnQgd2hpY2ggcmVmbGVj
dHMgdGhlIElFVEYgY29uc2Vuc3VzIG9uIGxlYXJuaW5nIHByZWZpeDY0cy4gDQoNCldlIGhhZCBt
YW55IG9wcG9ydHVuaXRpZXMgaW4gdGhlIHBhc3QgdG8gaWdub3JlIHRoZSByZWNvbW1lbmRhdGlv
bnMgaW4gUkZDNzA1MSwgYnV0IHdlIGRpZG4ndC4gRm9yIGV4YW1wbGUsIFJGQzgxMTUgc2F5cyB0
aGUgZm9sbG93aW5nOiANCg0KPT0NCiAgIE5vdGUgdGhhdCBpdCB3YXMgdGVtcHRpbmcgdG8gZGVm
aW5lIHRocmVlIGRpc3RpbmN0IERIQ1B2NiBvcHRpb25zLA0KICAgYnV0IHRoYXQgYXBwcm9hY2gg
d2FzIG5vdCBhZG9wdGVkIGJlY2F1c2UgaXQgaGFzIGEgc2lkZSBlZmZlY3Q6IHRoZQ0KICAgc3Bl
Y2lmaWNhdGlvbiBvZiBhIERIQ1B2NiBvcHRpb24gdGhhdCBjb3VsZCBiZSB1c2VkIHRvIGRpc2Nv
dmVyDQogICB1bmljYXN0IFByZWZpeDY0cyBpbiBlbnZpcm9ubWVudHMgd2hlcmUgbXVsdGljYXN0
IGlzIG5vdCBlbmFibGVkLg0KICAgU3VjaCBhIHNpZGUgZWZmZWN0IGNvbmZsaWN0cyB3aXRoIHRo
ZSByZWNvbW1lbmRhdGlvbiB0byBzdXBwb3J0IHRoZQ0KICAgV2VsbC1Lbm93biBETlMgTmFtZSBo
ZXVyaXN0aWMgZGlzY292ZXJ5LWJhc2VkIG1ldGhvZCBmb3IgdW5pY2FzdC1vbmx5DQogICBlbnZp
cm9ubWVudHMgKFNlY3Rpb24gNiBvZiBbUkZDNzA1MV0pLg0KPT0NCg0KPiBJJ20gdHJ5aW5nIHRv
IHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nICAnU0xBQUMgdnMgREhDUHY2JyBzbyBJIHdpbGwN
Cj4gbm90IG1lbnRpb24gYWxsIHRob3NlIGlzc3VlcyB3aXRoIG11bHRpaG9taW5nIGZvciBleGFt
cGxlIGJ1dC4uLi4NCj4gSWYgeW91IGFyZSBzYXlpbmcgdGhhdCB0aGUgcHJlZml4IHNob3VsZCBu
b3QgYmUgZGlzdHJpYnV0ZWQgdmlhIFJBcw0KPiBiZWNhdXNlIGl0IG5lZWRzIHRvIGJlIGNvbmZp
Z3VyZWQgb24gcm91dGVycywgdGhlbiB3aGF0IGFib3V0IEROUw0KPiBzZXJ2ZXJzIGFuZCBTTEFB
QyBwcmVmaXhlcyB0aGVtc2VsdmVzPw0KPiBUaGVyZSBhcmUgU0xBQUMtb25seSBuZXR3b3JrcyBv
dXQgdGhlcmUgd2hpbGUgUkZDNzkzNCBkb2VzIG5vdA0KPiByZWNvbW1lbmQgREhDUHY2IGFzIHRo
ZSBvbmx5IHdheSB0byBjb25maWd1cmUgY2xpZW50cy4NCj4gU28gYmV0d2VlbiB0aG9zZSB0d28g
UkEgZG9lcyBsb29rIGxpa2UgYSBiZXR0ZXIgd2F5Lg0KDQpbTWVkXSBJdCBpcyBldmlkZW50IHRo
YXQgUkEtYmFzZWQgYXBwcm9hY2ggbWF5IGJlIGEgZ29vZCBjYW5kaWRhdGUgZm9yIHNvbWUgZGVw
bG95bWVudHMuIE90aGVycyBtYXkgYXJndWUgdGhhdCBhbm90aGVyIHNvbHV0aW9uIGlzIGFwcHJv
cHJpYXRlIGZvciB0aGVpciBkZXBsb3ltZW50LCBhbmQgc28gb24uIA0KDQo+IA0KPiA+IFRoaW5n
cyBtYXkgZ2V0IGNvbXBsZXggaWYgbXVsdGlwbGUgTlNQcyBhcmUgdXNlZCBmb3IgbG9hZC1iYWxh
bmNpbmcgb3INCj4gaWYgZGVzdGluYXRpb24gYmFzZWQgTkFUNjRzIGFyZSBkZXBsb3llZC4gQSBs
aXN0IG9mIGlzc3VlcyBpcyBlbGFib3JhdGVkDQo+IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9yZmM3MjI1I3NlY3Rpb24tMy4xDQo+IA0KPiBJdCdzIG1vcmUgbGlrZSB2Nm9wcyBxdWVz
dGlvbiBidXQgSSdtIHJlYWxseSBjdXJpb3VzIGlmIG11bHRpcGxlDQo+IHByZWZpeGVzIHNjZW5h
cmlvIGlzIHJlYWwuDQo+IFJBIG9wdGlvbiBtaWdodCBjb250YWluIG11bHRpcGxlIHByZWZpeGVz
IGFueXdheS4NCg0KW01lZF0gSW5kZWVkLiBJdCBpcyBhbHJlYWR5IEFDS2VkIGluIDcwNTE6IA0K
DQogICBOb3RlOiBJZiB0aGUgUkEgd291bGQgaW5jbHVkZSBtdWx0aXBsZSBOU1BzLCBJc3N1ZSAj
NSBjb3VsZCBiZSBzb2x2ZWQNCiAgIGFzIHdlbGwsIGJ1dCBvbmx5IGlmIG5vZGVzIGFzIGEgZ3Jv
dXAgd291bGQgc2VsZWN0IGRpZmZlcmVudCBOU1BzLA0KICAgaGVuY2Ugc3VwcG9ydGluZyBsb2Fk
IGJhbGFuY2luZy4gIEFzIHRoaXMgaXMgbm90IGNsZWFyLCB0aGlzIGl0ZW0gaXMNCiAgIG5vdCB5
ZXQgbGlzdGVkIHVuZGVyIFBST3Mgb3IgQ09Ocy4NCg0KPiANCj4gPj4gPj4gT24gMTUgTm92IDIw
MTcsIGF0IDA4OjA2LCBNYXJrIEFuZHJld3MgPG1hcmthQGlzYy5vcmc+IHdyb3RlOg0KPiA+PiA+
Pg0KPiA+PiA+Pg0KPiA+PiA+Pj4gT24gMTUgTm92IDIwMTcsIGF0IDM6NDAgYW0sIExvcmVuem8g
Q29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPg0KPiA+PiB3cm90ZToNCj4gPj4gPj4+DQo+ID4+
ID4+PiBPbiBUdWUsIE5vdiAxNCwgMjAxNyBhdCA2OjQ2IEFNLCBNYXJrIEFuZHJld3MgPG1hcmth
QGlzYy5vcmc+DQo+IHdyb3RlOg0KPiA+PiA+Pj4gSXMgdGhlcmUgYW55IHJlYXNvbiB0byBydW4g
RE5TNjQgYXQgYWxsIHRoZXNlIGRheXM/ICBpcHY0b25seS5hcnBhDQo+IGNhbg0KPiA+PiBiZSBh
IHByZWNvbmZpZ3VyZWQNCj4gPj4gPj4+IHpvbmUgd2hpY2ggYWxsb3dzIENMQVQgdG8gZ2V0IGl0
cyBtYXBwaW5nLiAgQWxsIHRoZSBwaG9uZXMgaGF2ZQ0KPiBDTEFUDQo+ID4+IHN1cHBvcnQuDQo+
ID4+ID4+Pg0KPiA+PiA+Pj4gVGhhdCdzIGFuIGludGVyZXN0aW5nIGlkZWEuIEl0IHdvdWxkIHdv
cmsgaW4gdGhlb3J5LCBidXQgc3VjaCBhDQo+ID4+IG5ldHdvcmsgd291bGQgY29tcGxldGVseSBi
cmVhayBkZXZpY2VzIHRoYXQgZG9uJ3Qgc3VwcG9ydCA0NjR4bGF0LiBUaGF0DQo+ID4+IGdpdmVz
IHVwIG9uZSBvZiB0aGUgbWFqb3IgYWR2YW50YWdlcyBvZiBOQVQ2NC9ETlM2NCwgd2hpY2ggaXMg
dGhhdCBpdCdzDQo+IGENCj4gPj4gOTAlIHNvbHV0aW9uIGV2ZW4ganVzdCBieSBpdHNlbGYgLSB5
ZXMsIElQdjQtb25seSBhcHBsaWNhdGlvbnMgYW5kDQo+IGFkZHJlc3MNCj4gPj4gbGl0ZXJhbHMg
ZXhpc3QsIGJ1dCBtb3N0IHNpbXBsZSBjbGllbnQvc2VydmVyIGFwcGxpY2F0aW9ucyBKdXN0IFdv
cmsNCj4gPj4gYmVoaW5kIGl0Lg0KPiA+PiA+Pg0KPiA+PiA+PiBBbmQgdGhhdCA5MCUg4oCcc29s
dXRpb27igJ0gaGFzIGxvdHMgb2YgZG93biBzaWRlcy4gIEl0IGJhc2ljYWxseQ0KPiByZXF1aXJl
cw0KPiA+PiBFVkVSWSBETlMgVkFMSURBVE9SIE9ODQo+ID4+ID4+IFRIRSBQTEFORVQgVE8gU1VQ
UE9SVCBETlM2NCBKVVNUIElOIENBU0UgSVQgSVMgVVNFRCBCRUhJTkQgQSBETlM2NA0KPiA+PiBT
RVJWRVIuDQo+ID4+ID4+DQo+ID4+ID4+IEROUzY0L05BVDY0IHdhcyBwcmVzZW50ZWQgYXMgTk9U
IFJFUVVJUklORyBub2RlIGNoYW5nZXMgd2hlbiBmaXJzdA0KPiA+PiBtb290ZWQuICBJdCBrZWVw
cyBvbg0KPiA+PiA+PiByZXF1aXJpbmcgbW9yZSBhbmQgbW9yZSBoaWdobHkgaW52YXNpdmUgbm9k
ZSBjaGFuZ2VzIHRvIHN1cHBvcnQuICBJdA0KPiA+PiB3YXMgZnJvbSB0aGUgdmVyeSBiZWdpbm5p
bmcNCj4gPj4gPj4gYmFkIGVuZ2luZWVyaW5nLiAgIFRvIGdldCBJUHY0IGFzIGEgc2VydmljZSBz
b21lIG5vZGUgY2hhbmdlcyBhcmUNCj4gPj4gcmVxdWlyZWQuICBMZXRzIG1ha2Ugc3VyZSB0aGV5
DQo+ID4+ID4+IGFyZSBNSU5JTUFMIG9uZXMuDQo+ID4+ID4+DQo+ID4+ID4+IEp1c3QgZm9yIHRo
ZSByZWNvcmQgRE5TU0VDIHZhbGlkYXRvcnMgbmVlZCB0byBzZW5kIEJPVEggQ0Q9MCBhbmQNCj4g
Q0Q9MQ0KPiA+PiBxdWVyaWVzIHRvIGdldCBhbnN3ZXJzDQo+ID4+ID4+IHRob3VnaCBhIHVwc3Ry
ZWFtIFZBTElEQVRJTkcgc2VydmVyIHdoaWNoIGluY2x1ZGVzIGEgVkFMSURBVElORw0KPiBETlM2
NA0KPiA+PiBzZXJ2ZXIgYXMgQ0Q9MCBhbmQNCj4gPj4gPj4gQ0Q9MSBhZGRyZXNzIGRpZmZlcmVu
dCBETlNTRUMgdGhyZWF0cy4gIEkgdHJpZWQgdmVyeSBoYXJkIHRvIHBvaW50DQo+IHRoYXQNCj4g
Pj4gb3V0IHdoZW4gUkZDIDYxNDcgd2FzDQo+ID4+ID4+IGJlaW5nIHdyaXR0ZW4gYnV0IHRoZSB3
b3JraW5nIGdyb3VwIGRlY2lkZSB0aGF0IENEIGluZGljYXRlZCB3aGV0aGVyDQo+ID4+IHRoZSBj
bGllbnQgd2FzIHZhbGlkYXRpbmcgb3INCj4gPj4gPj4gbm90LiAgVGhlcmUgaXMgTk8gU1VDSCBJ
TkRJQ0FUSU9OIGluIGEgRE5TIG1lc3NhZ2UuDQo+ID4+ID4+DQo+ID4+ID4+ICBJZiBhIHF1ZXJ5
IGFycml2ZXMgYXQgYSB2RE5TNjQgZGV2aWNlIHdpdGggdGhlICJDaGVja2luZyBEaXNhYmxlZCIN
Cj4gPj4gPj4gICAoQ0QpIGJpdCBzZXQsIGl0IGlzIGFuIGluZGljYXRpb24gdGhhdCB0aGUgcXVl
cnlpbmcgYWdlbnQgd2FudHMNCj4gYWxsDQo+ID4+ID4+ICAgdGhlIHZhbGlkYXRpb24gZGF0YSBz
byBpdCBjYW4gZG8gY2hlY2tpbmcgaXRzZWxmLiAgQnkgbG9jYWwNCj4gcG9saWN5LA0KPiA+PiA+
PiAgIHZETlM2NCBjb3VsZCBzdGlsbCB2YWxpZGF0ZSwgYnV0IGl0IG11c3QgcmV0dXJuIGFsbCBk
YXRhIHRvIHRoZQ0KPiA+PiA+PiAgIHF1ZXJ5aW5nIGFnZW50IGFueXdheS4NCj4gPj4gPj4NCj4g
Pj4gPj4gQ0Q9MCBxdWVyaWVzIGNhdXNlcyB0aGUgdXBzdHJlYW0gdmFsaWRhdGluZyBzZXJ2ZXJz
IHRvIHJlamVjdA0KPiBpbmNvbWluZw0KPiA+PiBzcG9vZmVkIGFuc3dlcnMNCj4gPj4gPj4gb3Ig
c3RhbGUgYW5zd2VycyAodGhpcyBpcyBhIGNvbW1vbiBvcGVyYXRpb25hbCBwcm9ibGVtKS4NCj4g
Pj4gPj4NCj4gPj4gPj4gQ0Q9MSBxdWVyaWVzIGFsbG93IHRoZSB2YWxpZGF0aW9uIHRvIHN1Y2Nl
ZWQgd2hlbiB0aGUgdXBzdHJlYW0NCj4gPj4gdmFsaWRhdG9yIGhhcyBhIGJhZCB0cnVzdA0KPiA+
PiA+PiBhbmNob3Igb3IgYSBiYWQgY2xvY2sgd2hpY2ggaXMgcmVqZWN0aW5nIGxlZ2l0aW1hdGUg
YW5zd2Vycy4NCj4gPj4gPj4NCj4gPj4gPj4gQSB2YWxpZGF0aW5nIGNsaWVudCBjYW7igJl0IGp1
c3Qgc2VuZCBDRD0xIHF1ZXJpZXMgYXMgdGhlIHVwc3RyZWFtDQo+ID4+IHZhbGlkYXRvciBkb2Vz
buKAmXQga2ljayBpbi4NCj4gPj4gPj4gVGhlIHVwc3RyZWFtIHZhbGlkYXRvciBjYW4gbG9jayBv
bnRvIGEgc3RhbGUgYW5zd2VyIHNvdXJjZS4gIEl0DQo+IG5lZWRzDQo+ID4+IHRvIHNlbmQgQ0Q9
MCBxdWVyaWVzDQo+ID4+ID4+IG9uIHZhbGlkYXRpb24gZmFpbHVyZSB0byBmb3JjZSB0aGUgdXBz
dHJlYW0gdmFsaWRhdG9yIHRvIHRyeQ0KPiBtdWx0aXBsZQ0KPiA+PiBzb3VyY2VzLg0KPiA+PiA+
Pg0KPiA+PiA+PiBBIHZhbGlkYXRpbmcgY2xpZW50IGNhbuKAmXQganVzdCBzZW5kIENEPTAuICBJ
dCBuZWVkcyB0byBzZW5kIENEPTEgb24NCj4gPj4gU0VSVkZBSUwgaW4gY2FzZSB0aGUNCj4gPj4g
Pj4gdXBzdHJlYW0gdmFsaWRhdG9yIGhhcyBhIGJhZCB0cnVzdCBhbmNob3IgKGxpa2VseSB3aXRo
IHRoZSB1cGNvbWluZw0KPiA+PiByb290IEtTSyByb2xsKSBvciBoYXMNCj4gPj4gPj4gYSBiYWQg
Y2xvY2sgKHRoZXNlIHVzdWFsbHkgZ2V0IGZpeGVkIGZhc3QpLg0KPiA+PiA+Pg0KPiA+PiA+PiBO
b3cgdG8gZ2V0IGEgYW5zd2VyIGZyb20gYSBzaWduZWQgem9uZSB3aXRoIHNlcnZlcnMgd2l0aCBz
dGFsZQ0KPiBhbnN3ZXJzDQo+ID4+IGEgdmFsaWRhdGlpbmcgRE5TNjQgY2xpZW50DQo+ID4+ID4+
IG5lZWRzIHRvIHNlbmQ6DQo+ID4+ID4+DQo+ID4+ID4+IGEpIHNlbmQgQ0Q9MSBhbmQgdmFsaWRh
dGlvbiBmYWlsdXJlIHNlbmQgQ0Q9MCB0aGVuIG9uIEFBQUENCj4gdmFsaWRhdGlvbg0KPiA+PiBm
YWlsdXJlIHNlbmQgQ0Q9MSBhbmQNCj4gPj4gPj4gICAgaG9wZSB0aGUgVFRMIHdhcyBub3QgMCBh
bmQgdGhhdCBpcyBub3QgY2FjaGFibGUgYW5kIHRoZXJlIGlzIG5vDQo+ID4+IGFzc3VyYW5jZSB0
aGF0IHlvdSB3b27igJl0IGdldA0KPiA+PiA+PiAgICBhIGFuc3dlciBmcm9tIGEgc3RhbGUgc291
cmNlLg0KPiA+PiA+Pg0KPiA+PiA+PiAgICAgICBvcg0KPiA+PiA+Pg0KPiA+PiA+PiBiKSBzZW5k
IENEPTAgYW5kIG9uIHZhbGlkYXRpb24gZmFpbHVyZSBvZiB0aGUgQUFBQSBzZW5kIENEPTEgYW5k
DQo+IGhvcGUNCj4gPj4gdGhlIFRUTCB3YXMgbm90IDAgYXMNCj4gPj4gPj4gICAgdGhhdCBpcyBu
b3QgY2FjaGFibGUgYW5kIHRoZXJlIGlzIG5vIGFzc3VyYW5jZSB0aGF0IHlvdSB3b27igJl0IGdl
dA0KPiBhDQo+ID4+IGFuc3dlciBmcm9tIGEgc3RhbGUgc291cmNlLg0KPiA+PiA+Pg0KPiA+PiA+
PiBUVEw9MCBhbnN3ZXJzIGV4aXN0Lg0KPiA+PiA+Pg0KPiA+PiA+PiBOb3RlIG5vbmUgb2YgdGhp
cyBpcyBkb2N1bWVudGVkIGluIGEgUkZDLiAgWW91IGhhdmUgdG8gdW5kZXJzdGFuZA0KPiBob3cN
Cj4gPj4gYm90aCBETlNTRUMgYW5kIEROUzY0IHdvcmsgdG8NCj4gPj4gPj4gcmVhbGlzZSB0aGlz
Lg0KPiA+PiA+Pg0KPiA+PiA+PiBJUFY0T05MWS5BUlBBIGlzIGN1cnJlbnRseSBoYXMgYSBzZWN1
cmUgZGVsZWdhdGlvbiB3aGljaCBicmVha3MNCj4gcHJlZml4DQo+ID4+IGRpc2NvdmVyIGZvciBE
TlMgVkFMSURBVE9SUy4NCj4gPj4gPj4gTm90ZSDigJxhZOKAnSBpcyBzZXQgaW4gdGhlIGZsYWdz
LiAgWWVzLCBJ4oCZdmUgc3VibWl0dGVkIGEgZXJyYXRhLiAgWWVzLA0KPiA+PiBJ4oCZdmUgb3Bl
bmVkIGEgdGlja2V0IHRvIGdldCBpdCBmaXhlZCBidXQNCj4gPj4gPj4gYmFzZWQgb24gcGFzdCBl
eHBlcmllbmNlIHRoYXQgY291bGQgdGFrZSBtb250aHMgaWYgaXQgaGFwcGVucyBhdA0KPiBhbGwu
DQo+ID4+IFlvdSB3aWxsIG5vdGUgdGhhdCB0aGUgcmVjdXJzaXZlDQo+ID4+ID4+IHNlcnZlciBp
cyBydW5uaW5nIG9uIHRoZSBsb29wYmFjayBpbnRlcmZhY2Ugc28gYWxsIEROUyBhbnN3ZXJzIGFy
ZQ0KPiA+PiBiZWluZyB2YWxpZGF0ZWQgaGVyZS4NCj4gPj4gPj4NCj4gPj4gPj4gW3JvY2s6Ymlu
ZDkvYmluL25hbWVkXSBtYXJrYSUgZGlnIElQVjRPTkxZLkFSUEENCj4gPj4gPj4gOzsgQkFEQ09P
S0lFLCByZXRyeWluZy4NCj4gPj4gPj4NCj4gPj4gPj4gOyA8PD4+IERpRyA5LjEyLjBiMitob3Rz
cG90K2FkZC1wcmVmZXRjaCttYXJrYSA8PD4+IElQVjRPTkxZLkFSUEENCj4gPj4gPj4gOzsgZ2xv
YmFsIG9wdGlvbnM6ICtjbWQNCj4gPj4gPj4gOzsgR290IGFuc3dlcjoNCj4gPj4gPj4gOzsgLT4+
SEVBREVSPDwtIG9wY29kZTogUVVFUlksIHN0YXR1czogTk9FUlJPUiwgaWQ6IDg1MDQNCj4gPj4g
Pj4gOzsgZmxhZ3M6IHFyIHJkIHJhIGFkOyBRVUVSWTogMSwgQU5TV0VSOiAyLCBBVVRIT1JJVFk6
IDAsDQo+IEFERElUSU9OQUw6IDENCj4gPj4gPj4NCj4gPj4gPj4gOzsgT1BUIFBTRVVET1NFQ1RJ
T046DQo+ID4+ID4+IDsgRUROUzogdmVyc2lvbjogMCwgZmxhZ3M6OyB1ZHA6IDQwOTYNCj4gPj4g
Pj4gOyBDT09LSUU6IDdkYmY4YmViNzliZTQ3YTA5ZWI1MzEzZDVhMGI3NzZmNGZhZTNhYTY5MzFk
OTU4MyAoZ29vZCkNCj4gPj4gPj4gOzsgUVVFU1RJT04gU0VDVElPTjoNCj4gPj4gPj4gO0lQVjRP
TkxZLkFSUEEuICAgICAgICAgICAgICAgICAgICAgICBJTiAgICAgIEENCj4gPj4gPj4NCj4gPj4g
Pj4gOzsgQU5TV0VSIFNFQ1RJT046DQo+ID4+ID4+IGlwdjRvbmx5LmFycGEuICAgICAgICAgICAg
ICAgIDI2NTc0ICAgSU4gICAgICBBICAgICAgIDE5Mi4wLjAuMTcxDQo+ID4+ID4+IGlwdjRvbmx5
LmFycGEuICAgICAgICAgICAgICAgIDI2NTc0ICAgSU4gICAgICBBICAgICAgIDE5Mi4wLjAuMTcw
DQo+ID4+ID4+DQo+ID4+ID4+IDs7IFF1ZXJ5IHRpbWU6IDAgbXNlYw0KPiA+PiA+PiA7OyBTRVJW
RVI6IDEyNy4wLjAuMSM1MygxMjcuMC4wLjEpDQo+ID4+ID4+IDs7IFdIRU46IFdlZCBOb3YgMTUg
MTA6MDg6MzEgQUVEVCAyMDE3DQo+ID4+ID4+IDs7IE1TRyBTSVpFICByY3ZkOiAxMTUNCj4gPj4g
Pj4NCj4gPj4gPj4gW3JvY2s6YmluZDkvYmluL25hbWVkXSBtYXJrYSUNCj4gPj4gPj4NCj4gPj4g
Pj4+IEl0J3Mgbm90IHRydWUgdGhhdCBhbGwgcGhvbmVzIGhhdmUgY2xhdCBzdXBwb3J0LiBOb3Rh
Ymx5LCBBcHBsZSBub3QNCj4gPj4gb25seSBkb2VzIG5vdCBzdXBwb3J0IGl0IGJ1dCBhcHBlYXJz
IGlkZW9sb2dpY2FsbHkgb3Bwb3NlZCB0byBpdCBvbiB0aGUNCj4gPj4gZ3JvdW5kcyB0aGF0IGl0
IGRvZXMgbm90IGhhdmUgYSBnb29kIGV4aXQgc3RyYXRlZ3kgKGJlY2F1c2UgaXQgbWFrZXMgaXQN
Cj4gPj4gcG9zc2libGUgdG8gcnVuIElQdjQtb25seSBhcHBzIGZvcmV2ZXIpLg0KPiA+PiA+Pg0K
PiA+PiA+Pg0KPiA+PiA+PiAtLQ0KPiA+PiA+PiBNYXJrIEFuZHJld3MsIElTQw0KPiA+PiA+PiAx
IFNleW1vdXIgU3QuLCBEdW5kYXMgVmFsbGV5LCBOU1cgMjExNywgQXVzdHJhbGlhDQo+ID4+ID4+
IFBIT05FOiArNjEgMiA5ODcxIDQ3NDIgICAgICAgICAgICAgIElOVEVSTkVUOiBtYXJrYUBpc2Mu
b3JnDQo+ID4+ID4+DQo+ID4+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ID4+IElFVEYgSVB2NiB3b3Jr
aW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+PiA+PiBpcHY2QGlldGYub3JnDQo+ID4+ID4+IEFk
bWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2lwdjYNCj4gPj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4gLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCj4gPj4gPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4g
Pj4gPiBpcHY2QGlldGYub3JnDQo+ID4+ID4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+PiA+IC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
DQo+ID4+ID4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gLS0NCj4gPj4gU1ksIEplbiBMaW5rb3Zh
IGFrYSBGdXJyeQ0KPiA+Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiBJRVRGIElQdjYgd29ya2lu
ZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gPj4gaXB2NkBpZXRmLm9yZw0KPiA+PiBBZG1pbmlzdHJh
dGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2
DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCj4gDQo+IC0tDQo+IFNZLCBKZW4gTGlua292YSBh
a2EgRnVycnkNCg==


From nobody Fri Nov 17 01:19:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DA1126CF6 for ; Fri, 17 Nov 2017 01:19:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5uHxLmy0bsLO for ; Fri, 17 Nov 2017 01:19:51 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A847124D6C for ; Fri, 17 Nov 2017 01:19:51 -0800 (PST)
Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 638522D50C7; Fri, 17 Nov 2017 09:19:49 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 9AF6F200C382EA; Fri, 17 Nov 2017 17:19:47 +0800 (+08)
From: Ole Troan 
Message-Id: <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_714E6486-8C39-4FB7-B616-18D6E9BA7FCF"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Fri, 17 Nov 2017 17:19:46 +0800
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Cc: Jen Linkova , 6man WG , Mark Andrews 
To: Mohamed Boucadair 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 09:19:54 -0000

--Apple-Mail=_714E6486-8C39-4FB7-B616-18D6E9BA7FCF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Med,

Thanks for all the references. Seems like most bases have been covered =
here. ;-)

For the IETF NAT64 IMHO I need:
 - No dependency on DNS64. Want to use recursive resolver I trust plus =
local validating resolver.
 - Not depend on the success of PCP for NAT64 prefix discovery
 - If the host couldn't learn the NAT64 prefix any other way, I suppose =
it could throw an ICMP echo towards
   64:ff9b::127.0.0.1 (or perhaps just 64:ff9b::)

But I also see there being different deployment options here.
Btw, for multiple NSPs, couldn't you partly solve that by injecting more =
specifics into routing?

Cheers,
Ole


> On 17 Nov 2017, at 16:47,  =
 wrote:
>=20
> Hi Jen,
>=20
> Please see inline.
>=20
> Cheers,
> Med
>=20
>> -----Message d'origine-----
>> De : Jen Linkova [mailto:furry13@gmail.com]
>> Envoy=C3=A9 : vendredi 17 novembre 2017 09:31
>> =C3=80 : BOUCADAIR Mohamed IMT/OLN
>> Cc : Ole Troan; 6man WG; Mark Andrews
>> Objet : Re: IPv6 only host NAT64 requirements?
>>=20
>> On Thu, Nov 16, 2017 at 12:35 AM,   =
wrote:
>>>> IMHO the optimal solution is:
>>>> - the network SHOULD provide a host with NAT64 prefix information =
in
>>>> RA (I do not believe that information needs to be duplicated in =
DHCP
>>>> at all);
>>>=20
>>> [Med] Please check: =
https://tools.ietf.org/html/rfc7051#section-5.7.3
>>=20
>> Thanks for pointing this out. To be honest I disagree with what that
>> section says.
>=20
> [Med] I also disagree with many of the points in RFC7051, but that is =
the document which reflects the IETF consensus on learning prefix64s.
>=20
> We had many opportunities in the past to ignore the recommendations in =
RFC7051, but we didn't. For example, RFC8115 says the following:
>=20
> =3D=3D
>   Note that it was tempting to define three distinct DHCPv6 options,
>   but that approach was not adopted because it has a side effect: the
>   specification of a DHCPv6 option that could be used to discover
>   unicast Prefix64s in environments where multicast is not enabled.
>   Such a side effect conflicts with the recommendation to support the
>   Well-Known DNS Name heuristic discovery-based method for =
unicast-only
>   environments (Section 6 of [RFC7051]).
> =3D=3D
>=20
>> I'm trying to refrain from participating  'SLAAC vs DHCPv6' so I will
>> not mention all those issues with multihoming for example but....
>> If you are saying that the prefix should not be distributed via RAs
>> because it needs to be configured on routers, then what about DNS
>> servers and SLAAC prefixes themselves?
>> There are SLAAC-only networks out there while RFC7934 does not
>> recommend DHCPv6 as the only way to configure clients.
>> So between those two RA does look like a better way.
>=20
> [Med] It is evident that RA-based approach may be a good candidate for =
some deployments. Others may argue that another solution is appropriate =
for their deployment, and so on.
>=20
>>=20
>>> Things may get complex if multiple NSPs are used for load-balancing =
or
>> if destination based NAT64s are deployed. A list of issues is =
elaborated
>> in https://tools.ietf.org/html/rfc7225#section-3.1
>>=20
>> It's more like v6ops question but I'm really curious if multiple
>> prefixes scenario is real.
>> RA option might contain multiple prefixes anyway.
>=20
> [Med] Indeed. It is already ACKed in 7051:
>=20
>   Note: If the RA would include multiple NSPs, Issue #5 could be =
solved
>   as well, but only if nodes as a group would select different NSPs,
>   hence supporting load balancing.  As this is not clear, this item is
>   not yet listed under PROs or CONs.
>=20
>>=20
>>>>>> On 15 Nov 2017, at 08:06, Mark Andrews  wrote:
>>>>>>=20
>>>>>>=20
>>>>>>> On 15 Nov 2017, at 3:40 am, Lorenzo Colitti 
>>>> wrote:
>>>>>>>=20
>>>>>>> On Tue, Nov 14, 2017 at 6:46 AM, Mark Andrews 
>> wrote:
>>>>>>> Is there any reason to run DNS64 at all these days?  =
ipv4only.arpa
>> can
>>>> be a preconfigured
>>>>>>> zone which allows CLAT to get its mapping.  All the phones have
>> CLAT
>>>> support.
>>>>>>>=20
>>>>>>> That's an interesting idea. It would work in theory, but such a
>>>> network would completely break devices that don't support 464xlat. =
That
>>>> gives up one of the major advantages of NAT64/DNS64, which is that =
it's
>> a
>>>> 90% solution even just by itself - yes, IPv4-only applications and
>> address
>>>> literals exist, but most simple client/server applications Just =
Work
>>>> behind it.
>>>>>>=20
>>>>>> And that 90% =E2=80=9Csolution=E2=80=9D has lots of down sides.  =
It basically
>> requires
>>>> EVERY DNS VALIDATOR ON
>>>>>> THE PLANET TO SUPPORT DNS64 JUST IN CASE IT IS USED BEHIND A =
DNS64
>>>> SERVER.
>>>>>>=20
>>>>>> DNS64/NAT64 was presented as NOT REQUIRING node changes when =
first
>>>> mooted.  It keeps on
>>>>>> requiring more and more highly invasive node changes to support.  =
It
>>>> was from the very beginning
>>>>>> bad engineering.   To get IPv4 as a service some node changes are
>>>> required.  Lets make sure they
>>>>>> are MINIMAL ones.
>>>>>>=20
>>>>>> Just for the record DNSSEC validators need to send BOTH CD=3D0 =
and
>> CD=3D1
>>>> queries to get answers
>>>>>> though a upstream VALIDATING server which includes a VALIDATING
>> DNS64
>>>> server as CD=3D0 and
>>>>>> CD=3D1 address different DNSSEC threats.  I tried very hard to =
point
>> that
>>>> out when RFC 6147 was
>>>>>> being written but the working group decide that CD indicated =
whether
>>>> the client was validating or
>>>>>> not.  There is NO SUCH INDICATION in a DNS message.
>>>>>>=20
>>>>>> If a query arrives at a vDNS64 device with the "Checking =
Disabled"
>>>>>>  (CD) bit set, it is an indication that the querying agent wants
>> all
>>>>>>  the validation data so it can do checking itself.  By local
>> policy,
>>>>>>  vDNS64 could still validate, but it must return all data to the
>>>>>>  querying agent anyway.
>>>>>>=20
>>>>>> CD=3D0 queries causes the upstream validating servers to reject
>> incoming
>>>> spoofed answers
>>>>>> or stale answers (this is a common operational problem).
>>>>>>=20
>>>>>> CD=3D1 queries allow the validation to succeed when the upstream
>>>> validator has a bad trust
>>>>>> anchor or a bad clock which is rejecting legitimate answers.
>>>>>>=20
>>>>>> A validating client can=E2=80=99t just send CD=3D1 queries as the =
upstream
>>>> validator doesn=E2=80=99t kick in.
>>>>>> The upstream validator can lock onto a stale answer source.  It
>> needs
>>>> to send CD=3D0 queries
>>>>>> on validation failure to force the upstream validator to try
>> multiple
>>>> sources.
>>>>>>=20
>>>>>> A validating client can=E2=80=99t just send CD=3D0.  It needs to =
send CD=3D1 on
>>>> SERVFAIL in case the
>>>>>> upstream validator has a bad trust anchor (likely with the =
upcoming
>>>> root KSK roll) or has
>>>>>> a bad clock (these usually get fixed fast).
>>>>>>=20
>>>>>> Now to get a answer from a signed zone with servers with stale
>> answers
>>>> a validatiing DNS64 client
>>>>>> needs to send:
>>>>>>=20
>>>>>> a) send CD=3D1 and validation failure send CD=3D0 then on AAAA
>> validation
>>>> failure send CD=3D1 and
>>>>>>   hope the TTL was not 0 and that is not cachable and there is no
>>>> assurance that you won=E2=80=99t get
>>>>>>   a answer from a stale source.
>>>>>>=20
>>>>>>      or
>>>>>>=20
>>>>>> b) send CD=3D0 and on validation failure of the AAAA send CD=3D1 =
and
>> hope
>>>> the TTL was not 0 as
>>>>>>   that is not cachable and there is no assurance that you won=E2=80=
=99t get
>> a
>>>> answer from a stale source.
>>>>>>=20
>>>>>> TTL=3D0 answers exist.
>>>>>>=20
>>>>>> Note none of this is documented in a RFC.  You have to understand
>> how
>>>> both DNSSEC and DNS64 work to
>>>>>> realise this.
>>>>>>=20
>>>>>> IPV4ONLY.ARPA is currently has a secure delegation which breaks
>> prefix
>>>> discover for DNS VALIDATORS.
>>>>>> Note =E2=80=9Cad=E2=80=9D is set in the flags.  Yes, I=E2=80=99ve =
submitted a errata.  Yes,
>>>> I=E2=80=99ve opened a ticket to get it fixed but
>>>>>> based on past experience that could take months if it happens at
>> all.
>>>> You will note that the recursive
>>>>>> server is running on the loopback interface so all DNS answers =
are
>>>> being validated here.
>>>>>>=20
>>>>>> [rock:bind9/bin/named] marka% dig IPV4ONLY.ARPA
>>>>>> ;; BADCOOKIE, retrying.
>>>>>>=20
>>>>>> ; <<>> DiG 9.12.0b2+hotspot+add-prefetch+marka <<>> IPV4ONLY.ARPA
>>>>>> ;; global options: +cmd
>>>>>> ;; Got answer:
>>>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8504
>>>>>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0,
>> ADDITIONAL: 1
>>>>>>=20
>>>>>> ;; OPT PSEUDOSECTION:
>>>>>> ; EDNS: version: 0, flags:; udp: 4096
>>>>>> ; COOKIE: 7dbf8beb79be47a09eb5313d5a0b776f4fae3aa6931d9583 (good)
>>>>>> ;; QUESTION SECTION:
>>>>>> ;IPV4ONLY.ARPA.                       IN      A
>>>>>>=20
>>>>>> ;; ANSWER SECTION:
>>>>>> ipv4only.arpa.                26574   IN      A       192.0.0.171
>>>>>> ipv4only.arpa.                26574   IN      A       192.0.0.170
>>>>>>=20
>>>>>> ;; Query time: 0 msec
>>>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>>>> ;; WHEN: Wed Nov 15 10:08:31 AEDT 2017
>>>>>> ;; MSG SIZE  rcvd: 115
>>>>>>=20
>>>>>> [rock:bind9/bin/named] marka%
>>>>>>=20
>>>>>>> It's not true that all phones have clat support. Notably, Apple =
not
>>>> only does not support it but appears ideologically opposed to it on =
the
>>>> grounds that it does not have a good exit strategy (because it =
makes it
>>>> possible to run IPv4-only apps forever).
>>>>>>=20
>>>>>>=20
>>>>>> --
>>>>>> Mark Andrews, ISC
>>>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>>>>>> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>>>>>>=20
>>>>>> =
--------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list
>>>>>> ipv6@ietf.org
>>>>>> Administrative Requests: =
https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> =
--------------------------------------------------------------------
>>>>>=20
>>>>>=20
>>>>> =
--------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> ipv6@ietf.org
>>>>> Administrative Requests: =
https://www.ietf.org/mailman/listinfo/ipv6
>>>>> =
--------------------------------------------------------------------
>>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> SY, Jen Linkova aka Furry
>>>>=20
>>>> =
--------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> =
--------------------------------------------------------------------
>>=20
>>=20
>>=20
>> --
>> SY, Jen Linkova aka Furry


--Apple-Mail=_714E6486-8C39-4FB7-B616-18D6E9BA7FCF
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+/bDNdvtpYqJhC33YFAloOqbIACgkQvtpYqJhC
33YyyxAAulfQ9p26TYu+RRsLQwdMyQgmiVpjpspnInASjsuptnULswxsUHWEjRA2
pRVLwS7CwIeXLowR9KN2GsqwTZGp4LIowZHc5wIag/ROnUfUTBbF3/dwZOiPDNRh
C6AK7Samk7+SjwGnYFRvo/lAAXo4yJwL+iC/2XS5m0tPuTEIRYmBIjHZmDBva+LF
5spwk53CpMcAqCixSTlKQo4WFzdX6lfG0QnpE1pCujxAfJ+E7TGHERNIquoawJJg
ghFYifKxrHdqXm+E92C0DNIxznvjx4HSTlktMKBKivPDmfy0adFahkUtxjh6QXx+
25CWbHwHvKgg6QRUnOPDUfQF2BHtzVU18K6IkxGyW5mP1rwqpCnAoA5ca0qwWpvw
tZl8iq2N3K2P1c7IgGiHC0QuG8juAXUtdLSpocAqKASSU+iV4qH7krfJy+oe58uW
z6Brof90G425R5+cd72v9I/NFZZvwGUoMrmlRlXiD0PB6w4a6IGconO5zsKqOesI
OnD1ngsHsSiwXQmY1ZxkuiIpJ27icoqRm5J/eV7tFatcPXhyV8yFaNJ06gMK+Uu3
214QhkDl5BUHFo/xUa8oIzWxaUl63wKFy9Pe1IjO5bEHq16IPiRzN7iJF+tSDtXk
Qd2GcQyu9fHHPEKIqhnwVuPPwPXxDKobv7E40PhuH2jA3l0sZVw=
=Npgl
-----END PGP SIGNATURE-----

--Apple-Mail=_714E6486-8C39-4FB7-B616-18D6E9BA7FCF--


From nobody Fri Nov 17 05:50:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FBE126FB3 for ; Fri, 17 Nov 2017 05:50:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 SOevx3h3j_m7 for ; Fri, 17 Nov 2017 05:50:16 -0800 (PST)
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 30042126C19 for ; Fri, 17 Nov 2017 05:50:16 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id A52C5C0A for ; Fri, 17 Nov 2017 13:50:15 +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 L5xdBREeO6_Q for ; Fri, 17 Nov 2017 07:50:15 -0600 (CST)
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-p7.oit.umn.edu (Postfix) with ESMTPS id EEDF5C37 for ; Fri, 17 Nov 2017 07:50:14 -0600 (CST)
Received: by mail-lf0-f72.google.com with SMTP id g35so587242lfi.0 for ; Fri, 17 Nov 2017 05:50:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5eYFL4JghNNvahIRYnhq7TNQfPLghJiF9neyQPwfW/M=; b=a4bYPGq10IKGSuwdd1FVWQHVarNkvxKp2Vkv3brnKZEnohztwCqveuzUFrnquOSIXL FYoDTCxluoqSfzG83nX1Tee6D9gnL6cEGEgXDlFX+FH/HsKPiPq3fzeK4dqa3lHcJkLR yfgR+NEhfLHwNmFpreUaPUIMlNN3WVDPizfpCAX5PRfhIYHcSWXIlCg6XUxxmsP/Zagb VJqrvfcVNymSSuZA2ewYjFOuQ3YCGd8JQQgEbkx6m3O1kALAu6S0H3RulhQxqHsVhjVM MVX6nCSxeHGW3smkJzAyh8JdgpFvu72IXHdjlXg0es14BetJH7tcRXscM5AdjrncHEwE OKUg==
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=5eYFL4JghNNvahIRYnhq7TNQfPLghJiF9neyQPwfW/M=; b=Kk6iKnBbKkZiHF85fNIj355NTHLeko0LKw1p1PzWsCDqiAEVUaZdgkx3kWFqrUrvfc RjE/gh6H4rE5Y/9l6hQezmSJ7oAFieX+sKWks0qd/fhH1mJJvmbb4IyYqlTE9dHnDKD+ yraA/nQHxxkpnnd8/MDE2vRdK9a9Fmy1UHeP9OgpXKOVRdR8wcci0wYNSz48NpFHEF75 hL7gdPcfncNOXiJzD3UE1IdV8G0qS1AGXt+KAnmZ2B/srtLJ8RENFTg4zhY4DPPFlCF8 7RKyiTKJJdgEZ5vHV+oKUhCGZ+c9ZI+k5699QzhL0YZ7P1VThYB1IbKVbh5wPgYnB4zV 1MCw==
X-Gm-Message-State: AJaThX6gKVfh7uYsafWINJPCG8VfAZYPQ7jElwRA3Oaeroe7rszOeQ6S 5iisa+HTUC1xJlDxnlGscoym2Tsaix3D6Mgq+WDhpHfHdianEOVI1cgKNDyVlZd3Klj5O6IVZnU QX32fsIiDuRwphFiD9jQ68ov4
X-Received: by 10.46.7.82 with SMTP id i18mr60957ljd.123.1510926613001; Fri, 17 Nov 2017 05:50:13 -0800 (PST)
X-Google-Smtp-Source: AGs4zMaRjs2Jpm+fy8jyOkFRAF+y9HctLTKl8RpsXKv1o5+Tyz7ZmZduSf1i+6Lj/pEDrIb4x/HoBVjFmOiPWidpKE4=
X-Received: by 10.46.7.82 with SMTP id i18mr60946ljd.123.1510926612687; Fri, 17 Nov 2017 05:50:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Fri, 17 Nov 2017 05:50:12 -0800 (PST)
In-Reply-To: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  
From: David Farmer 
Date: Fri, 17 Nov 2017 07:50:12 -0600
Message-ID: 
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Jordi Palet Martinez 
Cc: IPv6 List 
Content-Type: multipart/alternative; boundary="f403045f736c08071a055e2e0408"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 13:50:20 -0000

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

I think this is a good start. It covers the basic use case.  However as
currently defined, it says IPv4 is definitively not available and means the
network will not provide any backward compatibility for IPv4-only hosts. Or
for that matter, any early dual-stack hosts that do not support or can not
properly initialize a transition mechanism, such as NAT64. Further, if a
network operator wants to provide such backward compatibility it must
essentially provide a separate service to do so, such as a separate WiFi
SSID, and users need to understand the capabilities of there host to select
the proper service, which is not auto-configuration, or a very friendly
user experience.

It seems to me if we made a subtle change to the meaning of the flag, a
single service could support both IPv6-only and IPv4-only hosts. If the
meaning of the flag were modified to indicate that there is either no IPv4
service on the advertising router, or that any IPv4 service provided is
intended to be limited to only hosts needing it for backward
compatibility.  Primarily intended to support IPv4-only hosts, but could
also be used by dual-stack hosts that do not support or can not properly
initialize the transition mechanism(s) they support.

How is this different than providing dual-stack service as we know it
today?  Full dual-stack service needs to support IPv4 at scale for all
hosts on the network, what I'm proposing allows a limited scale legacy IPv4
service to be provided instead of a full scale IPv4 service.

I also suggest a "Host behavior" section be added.  Move the last paragraph
of section 2 into it, add that dual-stack hosts that support this flag and
properly initialize a transition mechanism that allows communication with
other the IPv4-only networks SHOULD NOT initialize their IPv4 stack.
Dual-stack hosts that support this flag and that do not support or cannot
initialize such a transition mechanism MAY attempt to initialize their IPv4
stack. It is expected that IPv4-only hosts and dual-stack hosts that do not
support this flag will attempt to initialize their IPv4 stack.

 Thanks.

On Fri, Nov 17, 2017 at 1:21 AM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

> At first sight, looks fine to me.
>
> Regards,
> Jordi
>
>
> -----Mensaje original-----
> De: ipv6  en nombre de Bob Hinden <
> bob.hinden@gmail.com>
> Responder a: 
> Fecha: viernes, 17 de noviembre de 2017, 14:42
> Para: IPv6 List 
> CC: Bob Hinden 
> Asunto: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
>
>     Hi,
>     Brian and I took a cut a defining an IPv4 Availability Flag for IPv6
> ND Router Advertisements.  From the Introduction:
>
>        Hosts that support IPv4 and IPv6, usually called dual stack hosts,
>        need to work on IPv6 only networks.  That is, a link where there are
>        no IPv4 routers and/or IPv4 services.  Monitoring of IPv6-only
>        networks, for example at the IETF 100 meeting in Singapore, shows
>        that current dual stack hosts will create local auto-configured IPv4
>        addresses and attempt to reach IPv4 services.  A mechanism is needed
>        to inform hosts that there is no IPv4 support and that they should
>        turn off IPv4.
>
>        Because there is no IPv4 support on these links, the only way to
>        notify the dual stack hosts on the link is to use an IPv6 mechanism.
>        An active notification will be much more robust than attempting to
>        deduce this state by the lack of IPv4 responses or traffic.
>
>        IPv4-only hosts, and dual-stack hosts that do not recognize the new
>        flag, will continue to attempt IPv4 operations, in particular IPv4
>        discovery protocols typically sent as link-layer broadcasts.  This
>        legacy traffic cannot be prevented by any IPv6 mechanism.  The value
>        of the new flag is limited to dual-stack hosts that recognize it.
>
>     We were originally thinking it would be an April 1 submission, but
> after reading the discussion on the IPv6 list, we decided it makes sense as
> a real submission :-)
>
>     Please review and comment.
>
>     Thanks,
>     Bob and Brian
>
>
>
>     Begin forwarded message:
>
>     From: internet-drafts@ietf.org
>
>     Subject: New Version Notification for draft-hinden-ipv4flag-00.txt
>
>     Date: November 17, 2017 at 2:36:31 PM GMT+8
>
>     To: "Robert M. Hinden" , "Robert Hinden" <
> bob.hinden@gmail.com>, "Brian Carpenter" 
>
>
>
>     A new version of I-D, draft-hinden-ipv4flag-00.txt
>     has been successfully submitted by Robert M. Hinden and posted to the
>     IETF repository.
>
>     Name:               draft-hinden-ipv4flag
>     Revision:   00
>     Title:              IPv6 Router Advertisement IPv4 Availability Flag
>     Document date:      2017-11-17
>     Group:              Individual Submission
>     Pages:              5
>     URL:            https://www.ietf.org/internet-
> drafts/draft-hinden-ipv4flag-00.txt
>     Status:         https://datatracker.ietf.org/
> doc/draft-hinden-ipv4flag/
>     Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-00
>     Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-hinden-ipv4flag-00
>
>
>     Abstract:
>        This document specifies a Router Advertisement Flag to indicate that
>        there is no IPv4 service on the advertising router.  This document
>        updates RFC5175.
>
>
>
>
>     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 <
> http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>
>
>
>
>
>
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>
>
>
>
> **********************************************
> IPv4 is over
> 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.
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
===============================================
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>
===============================================

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


I think this is a good start. It covers the basic use=
 case.=C2=A0 However as currently defined, it says IPv4 is definitively not=
 available and means the network will not provide any backward compatibilit=
y for IPv4-only hosts. Or for that matter, any early dual-stack hosts that =
do not support or can not properly initialize a=C2=A0transition mechanism, =
such as NAT64. Further, if a network operator wants to provide such backwar=
d compatibility it must essentially provide a separate service to do so, su=
ch as a separate WiFi SSID, and users need to understand the capabilities o=
f there host to select the proper service, which is not auto-configuration,=
 or a very friendly user experience.=C2=A0

It seem=
s to me if we made a subtle change to the meaning of the flag, a single ser=
vice could support both IPv6-only and IPv4-only hosts. If the meaning of th=
e flag were modified to indicate that there is either no IPv4 service on th=
e advertising router, or that any IPv4 service provided is intended to be l=
imited to only hosts needing it for backward compatibility.=C2=A0 Primarily=
 intended to support IPv4-only hosts, but could also be used by dual-stack =
hosts that do not support or can not properly initialize the transition mec=
hanism(s) they support.

How is this different than=
 providing dual-stack service as we know it today?=C2=A0 Full dual-stack se=
rvice needs to support IPv4 at scale for all hosts on the network, what I&#=
39;m proposing allows a limited scale legacy IPv4 service to be provided in=
stead of a full scale IPv4 service.

I also suggest=
 a "Host behavior" section be added.=C2=A0 Move the last paragrap=
h of section 2 into it, add that dual-stack hosts that support this flag an=
d properly initialize a=C2=A0transition mechanism that allows communication=
 with other the IPv4-only networks SHOULD NOT initialize their IPv4 stack. =
Dual-stack hosts that support this flag=C2=A0and that do not support or can=
not initialize such a transition mechanism MAY attempt to initialize their =
IPv4 stack. It is expected that IPv4-only hosts and dual-stack hosts that d=
o not support this flag will attempt to initialize their IPv4 stack.
<=
div>
=C2=A0Thanks.

On Fri, Nov 17, 2017 at 1:21 AM, JORDI PALET MARTINEZ =
<jordi.palet@consulintel.es> wrote:
At first sight, looks fine to me.


Regards,

Jordi





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

De: ipv6 <ipv=
6-bounces@ietf.org> en nombre de Bob Hinden <bob.hinden@gmail.com>

Responder a: <=
bob.hinden@gmail.com>

Fecha: viernes, 17 de noviembre de 2017, 14:42

Para: IPv6 List <ipv6=
@ietf.org>

CC: Bob Hinden <bob.hinden@gmail.com>

Asunto: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt



=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 Brian and I took a cut a defining an IPv4 Availability Flag f=
or IPv6 ND Router Advertisements.=C2=A0 From the Introduction:



=C2=A0 =C2=A0 =C2=A0 =C2=A0Hosts that support IPv4 and IPv6, usually called=
 dual stack hosts,

=C2=A0 =C2=A0 =C2=A0 =C2=A0need to work on IPv6 only networks.=C2=A0 That i=
s, a link where there are

=C2=A0 =C2=A0 =C2=A0 =C2=A0no IPv4 routers and/or IPv4 services.=C2=A0 Moni=
toring of IPv6-only

=C2=A0 =C2=A0 =C2=A0 =C2=A0networks, for example at the IETF 100 meeting in=
 Singapore, shows

=C2=A0 =C2=A0 =C2=A0 =C2=A0that current dual stack hosts will create local =
auto-configured IPv4

=C2=A0 =C2=A0 =C2=A0 =C2=A0addresses and attempt to reach IPv4 services.=C2=
=A0 A mechanism is needed

=C2=A0 =C2=A0 =C2=A0 =C2=A0to inform hosts that there is no IPv4 support an=
d that they should

=C2=A0 =C2=A0 =C2=A0 =C2=A0turn off IPv4.



=C2=A0 =C2=A0 =C2=A0 =C2=A0Because there is no IPv4 support on these links,=
 the only way to

=C2=A0 =C2=A0 =C2=A0 =C2=A0notify the dual stack hosts on the link is to us=
e an IPv6 mechanism.

=C2=A0 =C2=A0 =C2=A0 =C2=A0An active notification will be much more robust =
than attempting to

=C2=A0 =C2=A0 =C2=A0 =C2=A0deduce this state by the lack of IPv4 responses =
or traffic.



=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv4-only hosts, and dual-stack hosts that do no=
t recognize the new

=C2=A0 =C2=A0 =C2=A0 =C2=A0flag, will continue to attempt IPv4 operations, =
in particular IPv4

=C2=A0 =C2=A0 =C2=A0 =C2=A0discovery protocols typically sent as link-layer=
 broadcasts.=C2=A0 This

=C2=A0 =C2=A0 =C2=A0 =C2=A0legacy traffic cannot be prevented by any IPv6 m=
echanism.=C2=A0 The value

=C2=A0 =C2=A0 =C2=A0 =C2=A0of the new flag is limited to dual-stack hosts t=
hat recognize it.



=C2=A0 =C2=A0 We were originally thinking it would be an April 1 submission=
, but after reading the discussion on the IPv6 list, we decided it makes se=
nse as a real submission :-)



=C2=A0 =C2=A0 Please review and comment.



=C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 Bob and Brian







=C2=A0 =C2=A0 Begin forwarded message:



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



=C2=A0 =C2=A0 Subject: New Version Notification for draft-hinden-ipv4flag-0=
0.txt



=C2=A0 =C2=A0 Date: November 17, 2017 at 2:36:31 PM GMT+8



=C2=A0 =C2=A0 To: "Robert M. Hinden" <bob.hinden@gmail.com>, "Rober=
t Hinden" <bob.hinden@gmail.com>, "Brian Carpenter" <brian.e.carpenter@gma=
il.com>







=C2=A0 =C2=A0 A new version of I-D, draft-hinden-ipv4flag-00.txt

=C2=A0 =C2=A0 has been successfully submitted by Robert M. Hinden and poste=
d to the

=C2=A0 =C2=A0 IETF repository.



=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d=
raft-hinden-ipv4flag

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

=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 R=
outer Advertisement IPv4 Availability Flag

=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2017-11-17

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

=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5

=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-hi=
nden-ipv4flag-00.txt

=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/

=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-hinden-ipv4flag-00

=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-hinden-ipv4fla=
g-00





=C2=A0 =C2=A0 Abstract:

=C2=A0 =C2=A0 =C2=A0 =C2=A0This document specifies a Router Advertisement F=
lag to indicate that

=C2=A0 =C2=A0 =C2=A0 =C2=A0there is no IPv4 service on the advertising rout=
er.=C2=A0 This document

=C2=A0 =C2=A0 =C2=A0 =C2=A0updates RFC5175.









=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 <http://tools.ietf.org>.



=C2=A0 =C2=A0 The IETF Secretariat

















=C2=A0 =C2=A0 --------------------------------------------------------=
------------

=C2=A0 =C2=A0 IETF IPv6 working group mailing list

=C2=A0 =C2=A0 ipv6@ietf.=
org

=C2=A0 =C2=A0 Administrative Requests: https://www.ietf.or=
g/mailman/listinfo/ipv6

=C2=A0 =C2=A0 --------------------------------------------------------=
------------









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

IPv4 is over

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.







-----------------------------------------------------------------=
---

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

-----------------------------------------------------------------=
---





-- 
=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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
N=
etworking & Telecommunication Services
Office of Information Technol=
ogy
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 




--f403045f736c08071a055e2e0408--


From nobody Fri Nov 17 06:00:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0CA126CB6 for ; Fri, 17 Nov 2017 06:00:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=jive.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBWFI34pWrTk for ; Fri, 17 Nov 2017 06:00:26 -0800 (PST)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D866120727 for ; Fri, 17 Nov 2017 06:00:26 -0800 (PST)
Received: by mail-it0-x233.google.com with SMTP id b5so4120754itc.3 for ; Fri, 17 Nov 2017 06:00:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=n9bFQFcKLgHL7pU4GlTuSIhOyEa49tXmShXehhf+dRo=; b=rbPubWHr2HsX2zNHfCP3GUn93Y/u71QvTsqbGbRT99esOoLhSZn6x3JgYaXbcGCZbl bRr2y3Pj64YY6crS1EqpakKvIHO/W9AS07Thl9JSU4qm6xC3tSDJq5jmoijCb09YyXQd 4BntjzXMigSvXh7aBU1759cjHHAMfZfjqlL53/ggQeJ7iybITWAZNhuwP62FVjzHItxe ovG4vJyYyyj8l3ROfcUHJp7iFvjlFXxuMPqdItBG7UEZPV9Ke4aL249BnkW/lrOmycOU 0XGuZkCEVkDmife8GPctK8wyfahHIwoR7wPBSVxyEazIiT0KpUCSCYNDXEDegW8B9/7g rqBg==
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=n9bFQFcKLgHL7pU4GlTuSIhOyEa49tXmShXehhf+dRo=; b=LQ50ng8uWCFLs54njYegLqtPPMSgjCZwyqSy8044yDxDWAslcw/5JJ3hFfX6reXmW5 6/ND8VKbtvStoVHoZ6d+GavCdirY28GEoJu+kKMg/Zy2Itbn84VljY/qL7ayQHPf5Yqh HdsPR8MrKKN5wvBKgwvabLBSDDq2cYqXKmGce5bphUkmgpSu/E/P5FT1nSAA7CEK1Ibd K8cwaZ9fKsLW7H1wafqxjtre6f5MrZVa7EXvesodDcPJRxcy37eVMc2DtLekL/1BMxpj sECLgEz96Q+COFDDT7mVO5a2O1sXzgnyrJs6ATTyVG7gNNTk+qtFW5G6inbksWerQxBK c2RA==
X-Gm-Message-State: AJaThX4vnjcfKqc7j1ZiCHLzYtLcs19F04k6HFGbS0GACJj4sBn+8b4U rIVMGaKrSniH2nXVOSaJp83XmaNxlkuWa2HA29bZ6Q==
X-Google-Smtp-Source: AGs4zMb51seINn1WMdEt08BVasA25cGZp9SLr8Lzrx4PGtegCZCW1pxYIxLZk/QCP9umGcvNqe8g6i4r8us5oqtwBVc=
X-Received: by 10.36.23.68 with SMTP id 65mr6125476ith.62.1510927225907; Fri, 17 Nov 2017 06:00:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.146.193 with HTTP; Fri, 17 Nov 2017 06:00:05 -0800 (PST)
In-Reply-To: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> 
From: Simon Perreault 
Date: Fri, 17 Nov 2017 09:00:05 -0500
Message-ID: 
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Bob Hinden 
Cc: IPv6 List 
Content-Type: multipart/alternative; boundary="001a11439010953220055e2e2871"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 14:00:29 -0000

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

Hi Bob,

How is this different from
https://tools.ietf.org/html/draft-ietf-sunset4-noipv4-01 ?

Thanks,
Simon

2017-11-17 1:42 GMT-05:00 Bob Hinden :

> Hi,
>
> Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 ND
> Router Advertisements.  From the Introduction:
>
>    Hosts that support IPv4 and IPv6, usually called dual stack hosts,
>    need to work on IPv6 only networks.  That is, a link where there are
>    no IPv4 routers and/or IPv4 services.  Monitoring of IPv6-only
>    networks, for example at the IETF 100 meeting in Singapore, shows
>    that current dual stack hosts will create local auto-configured IPv4
>    addresses and attempt to reach IPv4 services.  A mechanism is needed
>    to inform hosts that there is no IPv4 support and that they should
>    turn off IPv4.
>
>    Because there is no IPv4 support on these links, the only way to
>    notify the dual stack hosts on the link is to use an IPv6 mechanism.
>    An active notification will be much more robust than attempting to
>    deduce this state by the lack of IPv4 responses or traffic.
>
>    IPv4-only hosts, and dual-stack hosts that do not recognize the new
>    flag, will continue to attempt IPv4 operations, in particular IPv4
>    discovery protocols typically sent as link-layer broadcasts.  This
>    legacy traffic cannot be prevented by any IPv6 mechanism.  The value
>    of the new flag is limited to dual-stack hosts that recognize it.
>
> We were originally thinking it would be an April 1 submission, but after
> reading the discussion on the IPv6 list, we decided it makes sense as a
> real submission :-)
>
> Please review and comment.
>
> Thanks,
> Bob and Brian
>
>
> Begin forwarded message:
>
> *From: *internet-drafts@ietf.org
> *Subject: **New Version Notification for draft-hinden-ipv4flag-00.txt*
> *Date: *November 17, 2017 at 2:36:31 PM GMT+8
> *To: *"Robert M. Hinden" , "Robert Hinden" <
> bob.hinden@gmail.com>, "Brian Carpenter" 
>
>
> A new version of I-D, draft-hinden-ipv4flag-00.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
>
> Name: draft-hinden-ipv4flag
> Revision: 00
> Title: IPv6 Router Advertisement IPv4 Availability Flag
> Document date: 2017-11-17
> Group: Individual Submission
> Pages: 5
> URL:            https://www.ietf.org/internet-drafts/draft-
> hinden-ipv4flag-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
> Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-
> hinden-ipv4flag-00
>
>
> Abstract:
>   This document specifies a Router Advertisement Flag to indicate that
>   there is no IPv4 service on the advertising router.  This document
>   updates RFC5175.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

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


Hi Bob,


<=
/div>
Thanks,
Simon
2017-11-17 1:42 GMT-05:00 Bob Hinden <bob.=
hinden@gmail.com>:
Hi,

Brian and I took a cut a=
 defining an IPv4 Availability Flag for IPv6 ND Router Advertisements.=C2=
=A0 From the Introduction:

=C2=A0 =C2=A0Hosts that=
 support IPv4 and IPv6, usually called dual stack hosts,
=C2=A0 =C2=A0ne=
ed to work on IPv6 only networks.=C2=A0 That is, a link where there are
=
=C2=A0 =C2=A0no IPv4 routers and/or IPv4 services.=C2=A0 Monitoring of IPv6=
-only
=C2=A0 =C2=A0networks, for example at the IETF 100 meeting in Sing=
apore, shows
=C2=A0 =C2=A0that current dual stack hosts will create loca=
l auto-configured IPv4
=C2=A0 =C2=A0addresses and attempt to reach IPv4 =
services.=C2=A0 A mechanism is needed
=C2=A0 =C2=A0to inform hosts that =
there is no IPv4 support and that they should
=C2=A0 =C2=A0turn off IPv4=
.

=C2=A0 =C2=A0Because there is no IPv4 support on these links, the =
only way to
=C2=A0 =C2=A0notify the dual stack hosts on the link is to u=
se an IPv6 mechanism.
=C2=A0 =C2=A0An active notification will be much m=
ore robust than attempting to
=C2=A0 =C2=A0deduce this state by the lack=
 of IPv4 responses or traffic.

=C2=A0 =C2=A0IPv4-only hosts, and dua=
l-stack hosts that do not recognize the new
=C2=A0 =C2=A0flag, will cont=
inue to attempt IPv4 operations, in particular IPv4
=C2=A0 =C2=A0discove=
ry protocols typically sent as link-layer broadcasts.=C2=A0 This
=C2=A0 =
=C2=A0legacy traffic cannot be prevented by any IPv6 mechanism.=C2=A0 The v=
alue
=C2=A0 =C2=A0of the new flag is limited to dual-stack hosts that re=
cognize it.

We were originally thinking it would b=
e an April 1 submission, but after reading the discussion on the IPv6 list,=
 we decided it makes sense as a real submission :-)

Please review and comment.

Thanks,
Bob=
 and Brian


Begin forw=
arded message:

From: internet-drafts=
@ietf.org
Subje=
ct: New Version Notification for draft-hinden-ipv4fl=
ag-00.txt
Date:=
 November 17, 2017 at 2:36:31 PM GMT+8
=

To: "Rober=
t M. Hinden" <bob.hinden@gmail.com>, "Robert Hinden" <bob.hinden@gmail.com>=
;, "Brian Carpenter" <brian.e.carpenter@gmail.com>


A new version of I-D, draft-hinden-ipv4flag-00.txt
h=
as been successfully submitted by Robert M. Hinden and posted to the
IET=
F repository.

Name:		draft-hinden-ipv4=
flag
Revision:	00
Title:		IPv6 Router Advertisement IPv4 Availability Flag
Document date:	2017-11-17
Group:		Individual =
Submission
Pages:		5
URL: =C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.txt=

Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
Ht=
mlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/=
html/draft-hinden-ipv4flag-00
Htmlized: =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/html=
/draft-hinden-ipv4flag-00


Abstract:
 =C2=A0=C2=A0Thi=
s document specifies a Router Advertisement Flag to indicate that
 =C2=
=A0=C2=A0there is no IPv4 service on the advertising router.=C2=A0 This doc=
ument
 =C2=A0=C2=A0updates RFC5175.




Please note that =
it may take a couple of minutes from the time of submission
until the ht=
mlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--------------------------=
------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

-----------------------------------------------------------------=
---





--001a11439010953220055e2e2871--


From nobody Fri Nov 17 06:05:42 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1973126CB6 for ; Fri, 17 Nov 2017 06:05:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5kup1_7NdFL for ; Fri, 17 Nov 2017 06:05:38 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929CC120727 for ; Fri, 17 Nov 2017 06:05:38 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vAHD5Ocf060351 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Nov 2017 13:05:24 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <5A0EECAE.4020505@foobar.org>
Date: Fri, 17 Nov 2017 14:05:34 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Bob Hinden 
CC: IPv6 List 
Subject: Re: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 14:05:41 -0000

Bob Hinden wrote:
> Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 ND
> Router Advertisements.  From the Introduction:

this idea was previously discussed in draft-ietf-sunset4-noipv4 /
draft-perreault-sunset4-noipv4 in ~april 2014.  At the time it failed to
gain consensus.

Nick


From nobody Fri Nov 17 06:08:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B021270B4 for ; Fri, 17 Nov 2017 06:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ml2SGuv25tLJ for ; Fri, 17 Nov 2017 06:08:21 -0800 (PST)
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 CBFC6120727 for ; Fri, 17 Nov 2017 06:08:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510927699; x=1511532499; 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=VrZjTpEjfBfqEZBWwq533iRNB sKmlGUX2FyT6TGEQQE=; b=dcAsxl0oayuLKdlHa1fKmhYbSjnmG1gLhhbyN1Hb5 2GZTWkb0D8e2hPfUqjbGvqO1wpkASlwkXSqo1TY/9JttNaIiloKKkZCl+KrboCtl jjpl/fRHEF0ZrNsAJim75S38IfIDMhqNvBQ4Z3ZFkvaYDINvB+qijO6YkBCVApkO Qc=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=c29lXP6lQ1oVxOQIgmzTeWpRKJFSZzJqv6EPRKMsXXGNfbJEU+x0uCtitYmS ggFe72rEDzFXFGtacLJl9KoBO2DkpPWvwrlH27q1ru99tLFKgSpDhM11m v4Dc39MxzlSeJZBjjeGqyyDyfWIDs2Ev2Zjhc1bmhxM4P2mXpirjEU=;
X-MDAV-Processed: mail.consulintel.es, Fri, 17 Nov 2017 15:08:18 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 17 Nov 2017 15:08:18 +0100
Received: from [172.20.60.6] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005627015.msg for ; Fri, 17 Nov 2017 15:08:17 +0100
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:171117:md50005627015::HUctSD4JhfE/XgBq:00002EBJ
X-Return-Path: prvs=1494ff0e50=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Fri, 17 Nov 2017 22:08:01 +0800
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
From: JORDI PALET MARTINEZ 
To: IPv6 List 
Message-ID: 
Thread-Topic: New Version Notification for draft-hinden-ipv4flag-00.txt
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 14:08:23 -0000

I=E2=80=99ve the feeling reading your proposal that you=E2=80=99re assuming=
 that the dual-stack hosts have the transition mechanism built-in. However,=
 this is happening mainly in smartphones when attached to the 3G/LTE link.

If the case is for devices in a home or corporate network, and there is a n=
eed for IPv4, then it is the CE or router the one that manages the flag, an=
d in that case, either the CE or router supports some transition mechanism =
(such as MAP or 464XLAT), or will set the flag to shop =E2=80=9Cno IPv4 ava=
ilable=E2=80=9D.

So, unless I=E2=80=99m missing something, I don=E2=80=99t see the point for=
 changing the flag from the actual text.

Regards,
Jordi
=20

-----Mensaje original-----
De: David Farmer 
Responder a: 
Fecha: viernes, 17 de noviembre de 2017, 21:50
Para: Jordi Palet Martinez 
CC: IPv6 List 
Asunto: Re: New Version Notification for draft-hinden-ipv4flag-00.txt

    I think this is a good start. It covers the basic use case.  However as=
 currently defined, it says IPv4 is definitively not available and means th=
e network will not provide any backward compatibility for IPv4-only hosts. =
Or for that matter, any early dual-stack hosts that do not support or can n=
ot properly initialize a transition mechanism, such as NAT64. Further, if a=
 network operator wants to provide such backward compatibility it must esse=
ntially provide a separate service to do so, such as a separate WiFi SSID, =
and users need to understand the capabilities of there host to select the p=
roper service, which is not auto-configuration, or a very friendly user exp=
erience.=20
   =20
    It seems to me if we made a subtle change to the meaning of the flag, a=
 single service could support both IPv6-only and IPv4-only hosts. If the me=
aning of the flag were modified to indicate that there is either no IPv4 se=
rvice on the advertising router, or that any IPv4 service provided is inten=
ded to be limited to only hosts needing it for backward compatibility.  Pri=
marily intended to support IPv4-only hosts, but could also be used by dual-=
stack hosts that do not support or can not properly initialize the transiti=
on mechanism(s) they support.
   =20
    How is this different than providing dual-stack service as we know it t=
oday?  Full dual-stack service needs to support IPv4 at scale for all hosts=
 on the network, what I'm proposing allows a limited scale legacy IPv4 serv=
ice to be provided instead of a full scale IPv4 service.
   =20
    I also suggest a "Host behavior" section be added.  Move the last parag=
raph of section 2 into it, add that dual-stack hosts that support this flag=
 and properly initialize a transition mechanism that allows communication w=
ith other the IPv4-only networks SHOULD NOT initialize their IPv4 stack. Du=
al-stack hosts that support this flag and that do not support or cannot ini=
tialize such a transition mechanism MAY attempt to initialize their IPv4 st=
ack. It is expected that IPv4-only hosts and dual-stack hosts that do not s=
upport this flag will attempt to initialize their IPv4 stack.
   =20
     Thanks.
   =20
    On Fri, Nov 17, 2017 at 1:21 AM, JORDI PALET MARTINEZ  wrote:
   =20
    At first sight, looks fine to me.
   =20
    Regards,
    Jordi
   =20
   =20
    -----Mensaje original-----
    De: ipv6  en nombre de Bob Hinden 
    Responder a: 
    Fecha: viernes, 17 de noviembre de 2017, 14:42
    Para: IPv6 List 
    CC: Bob Hinden 
    Asunto: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
   =20
        Hi,
        Brian and I took a cut a defining an IPv4 Availability Flag for IPv=
6 ND Router Advertisements.  From the Introduction:
   =20
           Hosts that support IPv4 and IPv6, usually called dual stack host=
s,
           need to work on IPv6 only networks.  That is, a link where there=
 are
           no IPv4 routers and/or IPv4 services.  Monitoring of IPv6-only
           networks, for example at the IETF 100 meeting in Singapore, show=
s
           that current dual stack hosts will create local auto-configured =
IPv4
           addresses and attempt to reach IPv4 services.  A mechanism is ne=
eded
           to inform hosts that there is no IPv4 support and that they shou=
ld
           turn off IPv4.
   =20
           Because there is no IPv4 support on these links, the only way to
           notify the dual stack hosts on the link is to use an IPv6 mechan=
ism.
           An active notification will be much more robust than attempting =
to
           deduce this state by the lack of IPv4 responses or traffic.
   =20
           IPv4-only hosts, and dual-stack hosts that do not recognize the =
new
           flag, will continue to attempt IPv4 operations, in particular IP=
v4
           discovery protocols typically sent as link-layer broadcasts.  Th=
is
           legacy traffic cannot be prevented by any IPv6 mechanism.  The v=
alue
           of the new flag is limited to dual-stack hosts that recognize it=
.
   =20
        We were originally thinking it would be an April 1 submission, but =
after reading the discussion on the IPv6 list, we decided it makes sense as=
 a real submission :-)
   =20
        Please review and comment.
   =20
        Thanks,
        Bob and Brian
   =20
   =20
   =20
        Begin forwarded message:
   =20
        From: internet-drafts@ietf.org
   =20
        Subject: New Version Notification for draft-hinden-ipv4flag-00.txt
   =20
        Date: November 17, 2017 at 2:36:31 PM GMT+8
   =20
        To: "Robert M. Hinden" , "Robert Hinden" , "Brian Carpenter" 
   =20
   =20
   =20
        A new version of I-D, draft-hinden-ipv4flag-00.txt
        has been successfully submitted by Robert M. Hinden and posted to t=
he
        IETF repository.
   =20
        Name:               draft-hinden-ipv4flag
        Revision:   00
        Title:              IPv6 Router Advertisement IPv4 Availability Fla=
g
        Document date:      2017-11-17
        Group:              Individual Submission
        Pages:              5
        URL:            https://www.ietf.org/internet-drafts/draft-hinden-i=
pv4flag-00.txt
        Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4f=
lag/
        Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-0=
0
        Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-=
ipv4flag-00
   =20
   =20
        Abstract:
           This document specifies a Router Advertisement Flag to indicate =
that
           there is no IPv4 service on the advertising router.  This docume=
nt
           updates RFC5175.
   =20
   =20
   =20
   =20
        Please note that it may take a couple of minutes from the time of s=
ubmission
        until the htmlized version and diff are available at tools.ietf.org=
  .
   =20
        The IETF Secretariat
   =20
   =20
   =20
   =20
   =20
   =20
   =20
   =20
        -------------------------------------------------------------------=
-
        IETF IPv6 working group mailing list
        ipv6@ietf.org
        Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
        -------------------------------------------------------------------=
-
   =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
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
   =20
   =20
   =20
   =20
   =20
   =20
    --=20
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer               Email:farmer@umn.edu 
    Networking & Telecommunication Services
    Office of Information Technology
    University of Minnesota  =20
    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=20
   =20
   =20
   =20



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

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




From nobody Fri Nov 17 06:49:56 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA59126CB6 for ; Fri, 17 Nov 2017 06:49:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 b6skaCpcRZOA for ; Fri, 17 Nov 2017 06:49:52 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76A8126B72 for ; Fri, 17 Nov 2017 06:49:52 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FE6C20072; Fri, 17 Nov 2017 09:51:40 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DCA5582B25; Fri, 17 Nov 2017 09:49:51 -0500 (EST)
From: Michael Richardson 
To: IPv6 List 
cc: Bob Hinden 
Subject: Re: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
In-Reply-To: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> 
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 14:49:54 -0000

--=-=-=
Content-Type: text/plain


Bob Hinden  wrote:
    > Brian and I took a cut a defining an IPv4 Availability Flag for IPv6
    > ND Router Advertisements. From the Introduction:

    > Hosts that support IPv4 and IPv6, usually called dual stack hosts,
    > need to work on IPv6 only networks. That is, a link where there are
    > no IPv4 routers and/or IPv4 services. Monitoring of IPv6-only

Didn't we do all of this in sunset4 two years+ ago? I'm sure Lorenzo or Jen
remembers the debate and will correct my mis-representations.

I don't recall what happened to that work.

There is/was real pressure to tell the zillions of v4 machines on the cable model
networks to stop with the DHCPv4 queries, because they took up bandwidth.

Some had religious misgivings about using IPv6 to say something about IPv4.

The security consideration discusson went something like this:
    - this is a trivial DOS if there is really an IPv4 network
    - hosts that want to do v4 must therefore take this as advice, rather
      than gospel, and try the IPv4 anyway.
    - since they will try the IPv4 anyway, the goal of shutting them up
      fails.

However, I am enthusistic about such a flag, even if it is advice only and
everyone has to ignore it for security reasons.  It announces a desired
policy for the router issuing it.  It says, "I do not offer native IPv4"

It can moderate the hosts' enthuasiam for finding an IPv4, can ask the human
for advice, and if you want to mount a DOS against the IPv4 network, just use
DHCPv4 as people do now.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloO9w8ACgkQgItw+93Q
3WUPlwf+Lk1nv0dgOqwwk3LttylNipC1Fy2rpqc80KVnCJicAvPWOjIDteCH7P7M
XqdfnLrOAwFsXWBpametLm7o2+nn+u+ufAZXU5igCBWWGqMOYIwLFaaVln2ljutb
LM1DG3Dp4ZczOhVN5ClOzVAp83TG/9L3eWq9cvJD5nyecCEQe9hg9EKSTBHWcb9A
e4zM2PLM3B8txygD5PkEMjLht/WQjCC7uHn4Wc7I7kluNErnyBOejXob2N/X9QXV
FHJQz32utkMr+pnFhiXRX7Lxz67HvF1IgfYlRGV7qWVmKohN0oGOGxTlK/NsJpA+
n9rilEq3uX2WcMQjp2IDcHWyPH/klw==
=J+nC
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Nov 17 08:12:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14312128B38 for ; Fri, 17 Nov 2017 08:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WRyzrRvFhEuc for ; Fri, 17 Nov 2017 08:12:28 -0800 (PST)
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 D16FE1243FE for ; Fri, 17 Nov 2017 08:12:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510935145; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=Rut6A+fltWzvQV0kbeOoNnUPxzRkNy4LeaCIAknxT+s=; b=FR7ZMfiblY4Z+fNk9oFOBAI1FPIUPZSnVvls/LOceAouobRBnKuHRGaH3yNH+LgzNhPpfitnRPhdkNYbDPXLL1HUeK+MWOyooQ40SfNsWT/7QysSdkLkuQNPxByXpY4OFjOh4WIT81UDAU5+Gg8Pnf4LD/ZS913z51pI/iXWFco=
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0144.outbound.protection.outlook.com [213.199.154.144]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-93-WGnoSdRHPdmhu5COV8BPHA-1; Fri, 17 Nov 2017 16:12:20 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1139.eurprd07.prod.outlook.com (10.163.188.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.2; Fri, 17 Nov 2017 16:12:17 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0260.001; Fri, 17 Nov 2017 16:12:17 +0000
From: Tim Chown 
To: james woodyatt 
CC: Michael Richardson , 6man WG 
Subject: Re: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
Thread-Topic: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
Thread-Index: AQHTXsCEK1gNvYa+mkyDyUX+Qr6diqMXe+gAgAAT8wCAATBOgA==
Date: Fri, 17 Nov 2017 16:12:17 +0000
Message-ID: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>  <21029.1510865502@obiwan.sandelman.ca> 
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.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:291b:568f:8b2c:9a0]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1139; 20:s6kCKzqgDJBsyVIQQj0w1Wch9A0d8MOakPv1KCTsfyk3D4JleXESkRUJZ8p10VE6SmuUOYOVBo/w/IaDT8v4i6wRiZ4qEgURUGRf8xT6NuUQO/Far7Q/9INidPEcZRpWCEe6TBU400WfxVX4JJB4sXdqY+q6NUbGe78mLNwI9qM=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 3c3cc2ac-ab83-4246-0d77-08d52dd5f91f
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1139; 
x-ms-traffictypediagnostic: AM3PR07MB1139:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(920507027)(10201501046)(6041248)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1139; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1139; 
x-forefront-prvs: 049486C505
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(24454002)(51444003)(199003)(83716003)(53936002)(54906003)(6246003)(316002)(6306002)(2900100001)(25786009)(6512007)(786003)(57306001)(105586002)(106356001)(5660300001)(2950100002)(42882006)(50226002)(6916009)(8936002)(101416001)(93886005)(74482002)(76176999)(50986999)(97736004)(82746002)(102836003)(6116002)(33656002)(2906002)(189998001)(229853002)(3660700001)(3280700002)(99286004)(966005)(72206003)(68736007)(86362001)(14454004)(305945005)(7736002)(36756003)(5250100002)(34040400001)(8676002)(4326008)(53546010)(6436002)(6486002)(6506006)(81156014)(81166006)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1139; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-ID: <7E7C75C6CF7F874FAD880F0FC8CA4019@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 3c3cc2ac-ab83-4246-0d77-08d52dd5f91f
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2017 16:12:17.2857 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1139
X-MC-Unique: WGnoSdRHPdmhu5COV8BPHA-1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 16:12:31 -0000

SGksDQoNCj4gT24gMTYgTm92IDIwMTcsIGF0IDIyOjAzLCBqYW1lcyB3b29keWF0dCA8amh3QGdv
b2dsZS5jb20+IHdyb3RlOg0KPiANCj4gT24gTm92IDE2LCAyMDE3LCBhdCAxMjo1MSwgTWljaGFl
bCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPj4gDQo+PiBJIHRo
aW5rIHRoYXQgd2Ugc2hvdWxkIG1lbnRpb24gUENQLg0KPj4gSSBkb24ndCBrbm93IHdoZXRoZXIg
dG8gd3JpdGUgTUFZLCBTSE9VTEQgb3IgTVVTVC4NCj4+IFByb2JhYmx5IG5vdCBNVVNULg0KPiAN
Cj4gR2l2ZW4gdGhhdCBkaXNjb3ZlcmluZyBhbGwgdGhlIHJlbGV2YW50IFBDUCBzZXJ2ZXJzIGlz
IHBvdGVudGlhbGx5IGltcG9zc2libGUgd2l0aG91dCBhIERIQ1B2NiBjbGllbnQsIGFuZCB0aG9z
ZSBhcmUgbm90IGV4cGxpY2l0bHkgUkVDT01NRU5ERUQsIEkgdGhpbmsgdGhlIG9ubHkgcmVhc29u
YWJsZSBvcHRpb24gaGVyZSBpcyAiTUFZIGltcGxlbWVudCBhIFBDUCBjbGllbnTigJ0gYW5kIG5v
dCDigJxTSE9VTETigJ0gb3Ig4oCcTVVTVOKAnSB0byBpbXBsZW1lbnQgYSBQQ1AgY2xpZW50Lg0K
DQpZZXMsIGlmIHdlIHdlcmUgdG8gYWRkIHNvbWV0aGluZywgSSBhZ3JlZSBmcm9tIGNvbW1lbnRz
IG1hZGUgdGhhdCBNQVkgaXMgdGhlIHN0cm9uZ2VzdCB3ZSBzaG91bGQgdXNlLiANCg0KQnV0IGFz
IHlvdSBzYXksIHdpdGggbGFjayBvZiBzdXBwb3J0IGluIGNvbW1vbiBPU2VzLCBpdOKAmXMgc29t
ZXdoYXQgbW9vdCBhdCBwcmVzZW50LiAgDQoNClRpbQ0KDQo+PiBCVFc6IElzIHRoZXJlIGFueSBS
QSBvcHRpb24gdG8gc2lnbmFsIHRoYXQgUENQIG1pZ2h0IGJlIG5lZWRlZD8NCj4gDQo+IFRoZSBP
IGZsYWcgY2FuIHNpZ25hbCB0aGF0IFJGQyA3MjkxIG1heSBiZSByZXF1aXJlZCB0byBkaXNjb3Zl
ciBhbnkgYWRkaXRpb25hbCBQQ1Agc2VydmVycyBiZXlvbmQgdGhlIG9uZSB0aGF0IGNhbiBiZSBh
dmFpbGFibGUgYXQgMjAwMToxOjoxLg0KPiANCj4gDQo+IC0tamFtZXMgd29vZHlhdHQgPGpod0Bn
b29nbGUuY29tPg0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2lu
ZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBS
ZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQoNCg==


From nobody Fri Nov 17 10:20:20 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2148126D85 for ; Fri, 17 Nov 2017 10:20:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 M9d5EVA5pEPt for ; Fri, 17 Nov 2017 10:20:15 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928421200FC for ; Fri, 17 Nov 2017 10:20:15 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id u70so2496333pfa.7 for ; Fri, 17 Nov 2017 10:20:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ezaowC1fS4mpvmosVprXTN1aUCgvtliOxLV2YIM8LK0=; b=Z+tKIoHZlXZbV+V27uPZdZ7YihTqXrMFvLIl6ewTsKJj3v214vXGxCYs5/HwCS+3EA NApha/QJUTQjBkhMoaoYgc2ZkTUeg3OcSeXTghqUBw+G7/pA5yPMbyXDEYuKjCVzu5H1 ywe1hEEJPutGriXtMGpIOr/ABuU55swwJegu8HtjQ3Qst7ExU3xKGLSQllufp4T+k1r1 npanhohfX/JC8IEewqvBgbNFURSrll6+SE8h1CrD9rBvg2Y7XlIPPHQXlFYgafD7bix4 /z7ht1qGMeHfjDHlPELogeLgGTRPAx22bHAvw2BCAokHkI+T+zctPh6suMp5PBe4aFNN SdGw==
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=ezaowC1fS4mpvmosVprXTN1aUCgvtliOxLV2YIM8LK0=; b=nLWE4aF4iDSVjf2cMMT7aLX7ydJLNI0x5TT0y58HBLMewHs/2yFfG1PAHLqsqk4zuL ce96OBwLYYlZOaQmZ36GQM8tOQloe6/dQDC4UF3yzihPr3LUTZPx/QjmaEM2Lrm5ANN0 6VMmYxlrf02HUG0pLLv4AQKXGhRQnmeFaGACfNtvJsfnB7VKg18d99fKF6xPJNN5dAHr UwqEU2JY+SdV1gUGi3pJfEmQhVmirPr3KXQVAHHSU/601P+i4N0JBJ9GUBo8s3Newi9A cb1Ps9PKrR5DubpVpXJ+aUafhfzqSYO1gNUTSbewvf+QQSsjBGmhVa34sVMCP4CAK2DM lXkg==
X-Gm-Message-State: AJaThX5FwjLCktbaTa/dgT26NH7mWYEf03fc8vOnMgsA0qGVCbeIyaKS wTDzxyZauzw4ySrSdJoFi58kzTgb7rKtOg==
X-Google-Smtp-Source: AGs4zMatAF4zEA/OAiAla84yMHXszTV015LTPrcOt2VgEy0N706serDGONZ+Qp98Qa5QQh9IJ+846w==
X-Received: by 10.99.119.15 with SMTP id s15mr5824925pgc.90.1510942814958; Fri, 17 Nov 2017 10:20:14 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:89ee:1fe0:c6da:36ef? ([2620:0:10e7:10:89ee:1fe0:c6da:36ef]) by smtp.gmail.com with ESMTPSA id y83sm8755232pfd.66.2017.11.17.10.20.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 10:20:14 -0800 (PST)
From: james woodyatt 
Message-Id: <3A7C224D-6756-4072-A9E0-004F3BCB6045@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A0EBF898-D0F3-499B-84A6-A12A9E252473"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Fri, 17 Nov 2017 10:20:13 -0800
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07C3DA@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Cc: Michael Richardson , 6man WG 
To: mohamed.boucadair@orange.com
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com> <20377.1510865334@obiwan.sandelman.ca> <787AE7BB302AE849A7480A190F8B93300A07C3DA@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 18:20:18 -0000

--Apple-Mail=_A0EBF898-D0F3-499B-84A6-A12A9E252473
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 16, 2017, at 22:52, mohamed.boucadair@orange.com wrote:
>=20
> Hi Michael,=20
>=20
> For the particular case of NAT64, this requirement from RFC6888 =
applies:=20
>=20
>   REQ-9:  A CGN MUST implement a protocol giving subscribers explicit
>      control over NAT mappings.  That protocol SHOULD be the Port
>      Control Protocol [RFC6887].
>=20
> I'm not aware of any requirement for the LAN. [=E2=80=A6]

It=E2=80=99s a recommendation in RFC 6092. There is a whole section =
about it.

  >

It doesn=E2=80=99t mention PCP explicitly because RFC 6092 predates the =
creation of the PCP working group. It recognized that A) there was no =
standard to protocol to recommend, and B) it was necessary to recommend =
the deployment of something non-standard until there is a standard =
available. Hence, the strangeness of section 3.4 and the text of the =
included recommendation.

                                          Until a consensus emerges
 around a specific method, the following recommendations are the best
 guidance available.

   REC-48: Internet gateways with IPv6 simple security capabilities
   SHOULD implement a protocol to permit applications to solicit inbound
   traffic without advance knowledge of the addresses of exterior nodes
   with which they expect to communicate.

It would probably be a good idea to revise RFC 6092 to explicitly =
recommend PCP here.


--james woodyatt >




--Apple-Mail=_A0EBF898-D0F3-499B-84A6-A12A9E252473
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 16, 2017, at 22:52, mohamed.boucadair@orange.com wrote:

Hi =
Michael, 

For the particular case of NAT64, =
this requirement from RFC6888 applies: 

 =
  REQ-9:  A CGN MUST implement a protocol giving =
subscribers explicit
 =
     control over NAT mappings.  That =
protocol SHOULD be the Port
 =
     Control Protocol [RFC6887].

I'm not aware of any requirement for the LAN. =
[=E2=80=A6]

It=E2=80=99s=
 a recommendation in RFC 6092. There is a whole section about =
it.


It doesn=E2=80=99t mention PCP explicitly =
because RFC 6092 predates the creation of the PCP working group. It =
recognized that A) there was no standard to protocol to recommend, and =
B) it was necessary to recommend the deployment of something =
non-standard until there is a standard available. Hence, the strangeness =
of section 3.4 and the text of the included =
recommendation.

                                          Until a consensus emerges
 around a specific method, the following recommendations are the best
 guidance available.

   REC-48: =
Internet gateways with IPv6 simple security capabilities
   SHOULD implement a protocol to permit applications to solicit inbound
   traffic without advance knowledge of the addresses of exterior nodes
   with which they expect to communicate.

It would probably be a good idea to =
revise RFC 6092 to explicitly recommend PCP here.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_A0EBF898-D0F3-499B-84A6-A12A9E252473--


From nobody Fri Nov 17 10:39:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B321242F5 for ; Fri, 17 Nov 2017 10:39:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 UPfWJDtD4wte for ; Fri, 17 Nov 2017 10:39:08 -0800 (PST)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32F21241FC for ; Fri, 17 Nov 2017 10:39:08 -0800 (PST)
Received: by mail-pg0-x22e.google.com with SMTP id 4so2558571pge.1 for ; Fri, 17 Nov 2017 10:39:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E9LSrEOO5a8/cha3MgArrYFuBDT+eD8MaYyNfrSQ5zg=; b=finGhjiVRvCK/OLOHcLcC5Yz/I1YHmX3oRafcCbyqaZCZBywTB5o+j54s/+3vYuuis +pZh+4X6rVH7jDiV23XiTQJInHvSn2x6Me1MplpA9cXbPW4aLBbXDBq/y7q9Cg5z7aT/ Hwb3U0Gk94qjB7jNj+4MWCINUigay9qZkXsTKe2wlwGvbpeQGASCEMdyKZI8dUM5Fh0a hV2qr/xirN5q50qpSQExVWByknw11hlxQ5efudhX5va+x08m9YlTTU2c6yfun12z8sL/ 3tksnTtv29u8DjO7anaMLHButqMmjj/ZY9cSzcvP+Ujo03RIXNH/Sv9Lp5Cn53AEVR23 iuYQ==
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=E9LSrEOO5a8/cha3MgArrYFuBDT+eD8MaYyNfrSQ5zg=; b=bQMuMySfLDVQRWfj/kcpOI4lfFJU1+Xg0c8b9g0rVLwtLQd04nvDmREf0naB/lrU0Q ZQmOwoQ4zk4PwSULAAnDKP8Q4Hu0Jju1n08yiy1mFtnArAx09WL+3f1FLo9vI90AzHup 8Z0zHADaSPaa344zaUjKQIYfnzy7JnuCg8GJ1aQAhv+DNaFTr0LErnzJAlAJGZfuXmf1 0ss2cLQe1rjVp9o+9UX4TwvHlTKMzXQvu9OZ5oa+sFoYbhANpGjTseaRP/ScBwVSoqbm eSoAFwzPLlQ3DHU9s1aWdlWREMYU7i4CmD6kDZVSyUOKWsdy7OZlsWQdqsvVSgq1j2xb lIbA==
X-Gm-Message-State: AJaThX57+0C5P1kKnPl6O9/nysT1Fci09U0xqWwrO/otrOvOPE47rOoi vKo4r2+H+9QXn9uIYccLCI6sQVbHXOAFPg==
X-Google-Smtp-Source: AGs4zMaWDBdmNQ7QHfXI50U6L7JUtnt1ANo3UpYZTSABnWGPDF2mmUt3ab49zI8y58dwjVmBL11qIQ==
X-Received: by 10.98.13.212 with SMTP id 81mr3000214pfn.205.1510943948284; Fri, 17 Nov 2017 10:39:08 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:89ee:1fe0:c6da:36ef? ([2620:0:10e7:10:89ee:1fe0:c6da:36ef]) by smtp.gmail.com with ESMTPSA id q22sm3771352pfj.94.2017.11.17.10.39.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 10:39:07 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
From: james woodyatt 
In-Reply-To: <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com>
Date: Fri, 17 Nov 2017 10:39:06 -0800
Cc: Fernando Gont , IPv6 List 
Content-Transfer-Encoding: quoted-printable
Message-Id: <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com>
To: Bob Hinden 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 18:39:10 -0000

On Nov 17, 2017, at 00:17, Bob Hinden  wrote:
>=20
> The flag is to tell the host to not use IPv4.  Once the host see the =
Flag=3D1, it should stop sending IPv4.

The draft is very confused about what the flag means. And both of the =
conflicting descriptions in the draft are in conflict with this =
statement. Here are the three conflicting positions (I=E2=80=99m =
wondering how many will emerge before this can be sent back to the April =
1 queue).

  =E2=80=94 "IPv4 is Not Available on this Router"

  =E2=80=94 "A host that receives only RAs with the flag set to 1 should =
not attempt IPv4 operations, unless it subsequently receives at least =
one RA with the flag set to zero."

  =E2=80=94 "A host that receives Flag=3D1 should stop sending IPv4" (to =
what routers? on which interfaces? until what condition arises?).

Please send this draft back into the For Comedy Purposes Only category =
and leave the serious business of this topic to the SUNSET4 working =
group, which is actually chartered to deal with it.


--james woodyatt 




From nobody Fri Nov 17 15:32:10 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B9F120724 for ; Fri, 17 Nov 2017 15:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHCuUgN0UzcC for ; Fri, 17 Nov 2017 15:32:07 -0800 (PST)
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 F044F127275 for ; Fri, 17 Nov 2017 15:32:06 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id b189so9155969wmd.5 for ; Fri, 17 Nov 2017 15:32:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TgvmOMrtUfndJz0eTelgzX7dzHghii7xxQloE8ev6Og=; b=n3lkywLNqVA6QO6LFkMDdEi5QELPP5w+ZGsAV/dEGEVHs3xj9uTehhze7cdwF+qsB1 dL1Mi6CHGC5XUXKu22Wz7c+7ycE/PLCFSlQLo6ols7zqIJIEQGFvDeziBQkpWaLQ0KH+ mNjl/h/jy1RzKhVwXvXewHAyCxlpV6fUsYem0ynD1L55aFy++uRt+9ve0pWadnthJRI1 nHsFmitoJPvNNhyx+4dZ4avw8P1lUrjwUcOQwwOo+gEmtm7YvA2wxiLjeaIw5/eDOGmY Oxd1LLMOqJNJFzPiLD5raKoDg0xDDIraSCRwJQ0IUaEvciyngnHILTN23evji+ei4b7d diDg==
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=TgvmOMrtUfndJz0eTelgzX7dzHghii7xxQloE8ev6Og=; b=Cxq+lEHmdedXG0kRkCuSE17G/B1bZHulL55QBoA5tO5gV1AGwY7dUgZc4fCsPWurCI BV/KIsWZlPa2vga63RErRXibKiHdPp+ZB+sJ7xggDuiwSQDHFWv2C1/DeKE4LXT4p+EB 63jvb/dzp0WqIS5Pi1m0tjCRsiCnyeYTsH9A06eRo6o822rLAaKcw2CL4LuYrwgtDBza 9IWJpyJEqBeTwskr67xX2FmmeI4kYhp5auvKyTiwV+ZgMgIAqI82j9KHPycf08npE/Op 0aMmcxg72Rvzicn6HL7uvesL06QUj36vvcvYWFGnKAlVdup9YpERY/bJiNsD6DPZJWeL 9qgA==
X-Gm-Message-State: AJaThX4g10gKcQhhmaOzZWEmPlm8WWMD0zdLnim6gtlw4Uvx0qeVt3fX GnWVqAGoEGx5pD5eIAAfUXg=
X-Google-Smtp-Source: AGs4zMYwW1MoePeK711ivigZWVpRDguY2zId1IU24N4e6o4H3iYUgzOydU0xj/6oR7cYM4cAGLJ0qA==
X-Received: by 10.28.62.145 with SMTP id l139mr5366364wma.150.1510961525492; Fri, 17 Nov 2017 15:32:05 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:59aa:f59:2eed:52fb? ([2001:67c:1232:144:59aa:f59:2eed:52fb]) by smtp.gmail.com with ESMTPSA id e131sm6625688wmg.1.2017.11.17.15.32.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 15:32:03 -0800 (PST)
From: Bob Hinden 
Message-Id: <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_5F4DA7BF-B65E-420A-8688-ED747E4B808B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
Date: Sat, 18 Nov 2017 07:31:58 +0800
In-Reply-To: <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com>
Cc: Bob Hinden , Fernando Gont , IPv6 List 
To: james woodyatt 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Nov 2017 23:32:09 -0000

--Apple-Mail=_5F4DA7BF-B65E-420A-8688-ED747E4B808B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

James,

Cutting to the end:

> On Nov 18, 2017, at 2:39 AM, james woodyatt  wrote:
>=20
> On Nov 17, 2017, at 00:17, Bob Hinden  wrote:
>>=20
>> The flag is to tell the host to not use IPv4.  Once the host see the =
Flag=3D1, it should stop sending IPv4.
>=20
> The draft is very confused about what the flag means. And both of the =
conflicting descriptions in the draft are in conflict with this =
statement. Here are the three conflicting positions (I=E2=80=99m =
wondering how many will emerge before this can be sent back to the April =
1 queue).
>=20
>  =E2=80=94 "IPv4 is Not Available on this Router"
>=20
>  =E2=80=94 "A host that receives only RAs with the flag set to 1 =
should not attempt IPv4 operations, unless it subsequently receives at =
least one RA with the flag set to zero."
>=20
>  =E2=80=94 "A host that receives Flag=3D1 should stop sending IPv4" =
(to what routers? on which interfaces? until what condition arises?).
>=20
> Please send this draft back into the For Comedy Purposes Only category =
and leave the serious business of this topic to the SUNSET4 working =
group, which is actually chartered to deal with it.
>=20

That=E2=80=99s harsh.

I note that the relevant draft in sunset4 has been updated in 3 years, =
and Sunset four hasn=E2=80=99t meet since IETF97.  Doesn=E2=80=99t seem =
like anything will happen there.

We wrote this to solve what I think is a real issue observed with the =
use of NAT64 on the IETF100 network.

Bob




>=20
> --james woodyatt 
>=20
>=20
>=20


--Apple-Mail=_5F4DA7BF-B65E-420A-8688-ED747E4B808B
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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloPcW4ACgkQrut0EXfn
u6j1fwf/Y8PPYVpWfgA66F10w75158jmc1mU4rOdS0ZTXPm96GYYQN3iElgbW1Rn
tIYgHaCDjrNcff5xQbbf2a/wW90qANirNLNTpWJmryFQbgZ4vEkoMvq5mGOQV4Yt
9VqLDTarJltEnbLL2bLFJ+xexL6UskLxuPEV2H/lC4SDMizbgjDjqEakZETqYGmD
aVSH5l+6Y36UIGAVSoe0WghvxhyrZswCsShl7etm/z+gqWZW10wYmmQVcSr8hhTk
DzAJjwMBkF+RPNgPD4fhDYIX8R1FkbBC6VHONN29nTiFfCYFd40ECY7W/US6IHZc
Svlb3GcN7+Al7UzmNFu+BbhRH46X6A==
=I20w
-----END PGP SIGNATURE-----

--Apple-Mail=_5F4DA7BF-B65E-420A-8688-ED747E4B808B--


From nobody Fri Nov 17 18:20:10 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B23120721 for ; Fri, 17 Nov 2017 18:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 FrESjnLQzhsA for ; Fri, 17 Nov 2017 18:20:06 -0800 (PST)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54470124E15 for ; Fri, 17 Nov 2017 18:20:06 -0800 (PST)
Received: by mail-pg0-x22e.google.com with SMTP id z184so3237922pgd.13 for ; Fri, 17 Nov 2017 18:20:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=D9Kl613onYl3nrYiYz2yaZ8BHRvHZyaFu/CHoNhXVfQ=; b=NEUTU8OUTYs9JZ+CwCocQC4USMUM8kBFKtffLSIKWFtGi1PPUBdAMKqFfkz3I/MXRc IBc/cydIlk2mGCY7gr3oo+vMLJbmj39YqQi6dBDhIk1Lw+bbHUWz+rwK2+PqL5XtX1B8 84//RDNkSE3G/rYjQedvnnPTJ91sBDJwQY8i4ibj23Y04kcZkz3Iajyw6X/XPWwHXRa4 Wyr5E/ihsp+HBbwqO8VLP4UZOy4pvix5E6B6j8I4ODr595s977B57HHjevWlMeu6Sy1K EIFgfGigosndJI9s9llxwo4QnwrTr5b1Lrz9kGG7Af5KbgfNi9GIxQNHE2Pd/A6P4Eze k4pw==
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=D9Kl613onYl3nrYiYz2yaZ8BHRvHZyaFu/CHoNhXVfQ=; b=Ryyjdlg32mZjUGRC4nuWZVGRH4Q1ShVdN+G6P+1nyeau04w8g075MLKorF4w5zZqzb Bfa6TE2r6daQc2Q7iITdDbiEBJzOhslH2g7TioLhj1XybSZsKDutPkVDg8kQ0HeDkKwz 2AM21o2yOI45lR95aNDeFnaYQl4e0dA/i9QIREIXwMA+sGz8smACu+EP7z5le7pGWWri PyuDLIfgjtD31v2oVOapzzOsY2SZxKWalDto6laBcCK6IglbxbnT7KT7J0J1UScyHT74 4PaCouXX6IcX4604ljJ2ucaeVzTyO+a+KieT7YfdlKU5ifQTwe56zFOiLzz7k6gnykOB Raxw==
X-Gm-Message-State: AJaThX6k2jiRvGNjFiORqtpQQ2aAP2m2shXBsHu6kiCS+apao8g/6hlX U6ApBksDwsEtYQ6cduFwf6LBJLUvWAw=
X-Google-Smtp-Source: AGs4zMaa8fvBhS+s9/u5mWH6MkzmPlnmGaGyVw38Jj6ALvuZhczIJgg3eSKz7QFoYxoApbKu9ZCAEg==
X-Received: by 10.98.245.68 with SMTP id n65mr4028020pfh.113.1510971605512; Fri, 17 Nov 2017 18:20:05 -0800 (PST)
Received: from ?IPv6:2620::10e7:10:59c:dedc:46fd:69d4? ([2620:0:10e7:10:59c:dedc:46fd:69d4]) by smtp.gmail.com with ESMTPSA id v28sm8888324pfl.118.2017.11.17.18.20.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 18:20:04 -0800 (PST)
From: james woodyatt 
Message-Id: <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5511B676-3343-4C93-A2EB-0AA97E7EA758"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
Date: Fri, 17 Nov 2017 18:20:03 -0800
In-Reply-To: <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com>
Cc: Fernando Gont , IPv6 List 
To: Bob Hinden 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com> <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 02:20:08 -0000

--Apple-Mail=_5511B676-3343-4C93-A2EB-0AA97E7EA758
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 17, 2017, at 15:31, Bob Hinden  wrote:
> On Nov 18, 2017, at 2:39 AM, james woodyatt  wrote:
>> On Nov 17, 2017, at 00:17, Bob Hinden  wrote:
>>>=20
>>> The flag is to tell the host to not use IPv4.  Once the host see the =
Flag=3D1, it should stop sending IPv4.
>>=20
>> The draft is very confused about what the flag means. And both of the =
conflicting descriptions in the draft are in conflict with this =
statement. Here are the three conflicting positions (I=E2=80=99m =
wondering how many will emerge before this can be sent back to the April =
1 queue).
>>=20
>> =E2=80=94 "IPv4 is Not Available on this Router"
>>=20
>> =E2=80=94 "A host that receives only RAs with the flag set to 1 =
should not attempt IPv4 operations, unless it subsequently receives at =
least one RA with the flag set to zero."
>>=20
>> =E2=80=94 "A host that receives Flag=3D1 should stop sending IPv4" =
(to what routers? on which interfaces? until what condition arises?).
>>=20
>> Please send this draft back into the For Comedy Purposes Only =
category and leave the serious business of this topic to the SUNSET4 =
working group, which is actually chartered to deal with it.
>>=20
>=20
> That=E2=80=99s harsh.
>=20
> I note that the relevant draft in sunset4 has been updated in 3 years, =
and Sunset four hasn=E2=80=99t meet since IETF97.  Doesn=E2=80=99t seem =
like anything will happen there.

The SUNSET4 working group still has an active charter.

> We wrote this to solve what I think is a real issue observed with the =
use of NAT64 on the IETF100 network.


It=E2=80=99s not a good solution. The issue is quite a bit more complex =
than jamming a new flag into the RA message will allow.

Consider the current behavior of some of the products that my employers =
produce, which send RA messages (lifetime=3D0) on their Wi-Fi interfaces =
to distribute PIO elements to hosts that need ULA addresses in the Nest =
Weave fabric space. Under this draft, each currently fielded Nest device =
would cancel the 4=3D1 flag sent by any IPv6-only default gateway. Which =
is a kinda silly thing to do when you=E2=80=99re a router between =
Wi-Fi=E2=84=A2 and Thread=E2=84=A2 and Thread=E2=84=A2 is an IPv6-only =
link layer. Wouldn=E2=80=99t you think setting 4=3D1 to be a good idea =
in that case? Alas, it=E2=80=99s not. If we do that, then any dual-stack =
hosts on a network with an IPv4-only CE router will shut off their IPv4 =
activity, and they will not get any IPv6 service through us. This is =
probably not what anyone wants, so we would of course never ever, not in =
a million years, never send 4=3D1 in our RA messages.

Now, you might say we shouldn=E2=80=99t send RA messages at all (even =
with lifetime=3D0) unless we are willing to be a default router. You =
might say that the default router should forward our Weave fabric prefix =
to us from hosts on the LAN. And I would say, that sounds like a capital =
idea, except each and every one of the workable technical alternatives =
to get hosts to self-assign on-link addresses, and set host route =
entries for a working route to the rest of the Weave fabric behind our =
local router, or at least to have a reliable means of routing on home =
networks through the usual default route at the CE router, have all been =
roundly rejected by industry and at least three separate IETF working =
groups. We do what we can because it=E2=80=99s the only thing that =
works.

So, no=E2=80=A6 we=E2=80=99re not going to stop sending RA messages =
(lifetime=3D0) . And so, we=E2=80=99re going to step on this 4=3D1 bit =
until the end of time. In other words, this draft won=E2=80=99t do what =
it hopes to do.


--james woodyatt >




--Apple-Mail=_5511B676-3343-4C93-A2EB-0AA97E7EA758
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 17, 2017, at 15:31, Bob Hinden <bob.hinden@gmail.com> wrote:
On Nov 18, 2017, at 2:39 =
AM, james woodyatt <jhw@google.com> wrote:
On Nov 17, 2017, at 00:17, Bob Hinden <bob.hinden@gmail.com> wrote:

The flag is to tell the host to =
not use IPv4.  Once the host see the Flag=3D1, it should stop =
sending IPv4.

The draft is =
very confused about what the flag means. And both of the conflicting =
descriptions in the draft are in conflict with this statement. Here are =
the three conflicting positions (I=E2=80=99m wondering how many will =
emerge before this can be sent back to the April 1 queue).

=E2=80=94 "IPv4 is Not Available on this =
Router"

=E2=80=94 "A host that receives =
only RAs with the flag set to 1 should not attempt IPv4 operations, =
unless it subsequently receives at least one RA with the flag set to =
zero."

=E2=80=94 "A host that receives =
Flag=3D1 should stop sending IPv4" (to what routers? on which =
interfaces? until what condition arises?).

Please send this draft back into the For Comedy Purposes Only =
category and leave the serious business of this topic to the SUNSET4 =
working group, which is actually chartered to deal with it.


That=E2=80=99s =
harsh.

I note that the =
relevant draft in sunset4 has been updated in 3 years, and Sunset four =
hasn=E2=80=99t meet since IETF97.  Doesn=E2=80=99t seem like =
anything will happen there.

The SUNSET4 =
working group still has an active charter.

We wrote this to solve what I think is a =
real issue observed with the use of NAT64 on the IETF100 =
network.

It=E2=80=99s not a good =
solution. The issue is quite a bit more complex than jamming a new flag =
into the RA message will allow.

Consider the current behavior of some =
of the products that my employers produce, which send RA messages =
(lifetime=3D0) on their Wi-Fi interfaces to distribute PIO elements to =
hosts that need ULA addresses in the Nest Weave fabric space. Under this =
draft, each currently fielded Nest device would cancel the 4=3D1 flag =
sent by any IPv6-only default gateway. Which is a kinda silly thing to =
do when you=E2=80=99re a router between Wi-Fi=E2=84=A2 and Thread=E2=84=A2=
 and Thread=E2=84=A2 is an IPv6-only link layer. Wouldn=E2=80=99t you =
think setting 4=3D1 to be a good idea in that case? Alas, it=E2=80=99s =
not. If we do that, then any dual-stack hosts on a network with an =
IPv4-only CE router will shut off their IPv4 activity, and they will not =
get any IPv6 service through us. This is probably not what anyone wants, =
so we would of course never ever, not in a million years, never send 4=3D1=
 in our RA messages.

Now, you might say we shouldn=E2=80=99t send RA messages at =
all (even with lifetime=3D0) unless we are willing to be a default =
router. You might say that the default router should forward our Weave =
fabric prefix to us from hosts on the LAN. And I would say, that sounds =
like a capital idea, except each and every one of the workable technical =
alternatives to get hosts to self-assign on-link addresses, and set host =
route entries for a working route to the rest of the Weave fabric behind =
our local router, or at least to have a reliable means of routing on =
home networks through the usual default route at the CE router, have all =
been roundly rejected by industry and at least three separate IETF =
working groups. We do what we can because it=E2=80=99s the only thing =
that works.

So, =
no=E2=80=A6 we=E2=80=99re not going to stop sending RA messages =
(lifetime=3D0) . And so, we=E2=80=99re going to step on this 4=3D1 bit =
until the end of time. In other words, this draft won=E2=80=99t do what =
it hopes to do.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_5511B676-3343-4C93-A2EB-0AA97E7EA758--


From nobody Fri Nov 17 18:39:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49A8124E15 for ; Fri, 17 Nov 2017 18:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nW4BsPbIU3zW for ; Fri, 17 Nov 2017 18:39:42 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F27D120721 for ; Fri, 17 Nov 2017 18:39:42 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id b189so9691799wmd.0 for ; Fri, 17 Nov 2017 18:39:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fXIUfZFSLm2+2NeUmJfF5soWJqsTXvwh3UeCW69gXek=; b=qCjkr0il78kHl7I1BKSlmMpbk6kJnDurCR5ucb4ol1XXX/vr4r+vDGosVfNaZOo3ez 3JXdEf6Q/W4IFJzMe4Y2Q8dTVSrSoMA+q8U3kqMRSyqs3+iIaBvMP8pP4c5i4uxDZYzp b7684i9ECGTicLUtBMlzB9dM0hicvaJMBW6nfmY6/ni3XIpn3WWsL4EQBAl5HdjhNe7x JgmVpcBMSiF4Mbnp49HIbGIsrpxHSlOwGIICVlKv2kjtuQ/Dhuxl50vwvNgCe0DrA7ct rIjj8G/BkBUqcuGi1FFTomrw9qSoBujt8sNAH6PflVIkz+ERTofLZT/zlbDqn+BM9a81 kceQ==
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=fXIUfZFSLm2+2NeUmJfF5soWJqsTXvwh3UeCW69gXek=; b=njYuug+zc9F+JUBplc75zlq5IPSOXX3DmGmSjbXfz29+AHtcUv7d24Wwe9+D1rsaKE H1vboYcTiznmaM5QiDQ4GRaiCMGTkHYDJcN8ZHqZhhWN9rn/dooLfZd6RvzqUF5YjUvZ V6ZJ+uxniL26sP1idWiSOEF7Q9T7MW4eg/FsUW4cUzxITsBs2lkBHEF/7Mue4Zdvyhn1 9SiLUg4uvt84SIVNUxZLm+kScpQKkJobOT5VkaNrFytZOhX9NaY7xqhBRXADM6vdhLn4 Oj9DNsVZIJrNbOcDQXKJzIhG1TRfpBmdljMDNcpAmN8nL5Bd2Pt/Kjk3Jqmf1opvQd7B L0OA==
X-Gm-Message-State: AJaThX4khCH3PKWbEOrBvk2iKz8XfjD4BZbOoTxnUKEda9ryefVYvaEQ R7/9A1pCnCirOvz4NX+AwiM=
X-Google-Smtp-Source: AGs4zMaLZRkLHo+bbHlfeX2cROU6vBO09Olnubnp8WHUiVW1eNREVy3lHvC3n6ML4IczTw/tk/C0+A==
X-Received: by 10.28.35.4 with SMTP id j4mr4585521wmj.55.1510972780568; Fri, 17 Nov 2017 18:39:40 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:59aa:f59:2eed:52fb? ([2001:67c:1232:144:59aa:f59:2eed:52fb]) by smtp.gmail.com with ESMTPSA id t19sm2887245wrb.58.2017.11.17.18.39.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Nov 2017 18:39:39 -0800 (PST)
From: Bob Hinden 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_DD946799-A194-4766-8114-9735D24E3C66"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
Date: Sat, 18 Nov 2017 10:39:34 +0800
In-Reply-To: <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com>
Cc: Bob Hinden , IPv6 List 
To: james woodyatt 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com> <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com> <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 02:39:45 -0000

--Apple-Mail=_DD946799-A194-4766-8114-9735D24E3C66
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

James,

> On Nov 18, 2017, at 10:20 AM, james woodyatt  wrote:
>=20
> On Nov 17, 2017, at 15:31, Bob Hinden  wrote:
>> On Nov 18, 2017, at 2:39 AM, james woodyatt  wrote:
>>> On Nov 17, 2017, at 00:17, Bob Hinden  wrote:
>>>>=20
>>>> The flag is to tell the host to not use IPv4.  Once the host see =
the Flag=3D1, it should stop sending IPv4.
>>>=20
>>> The draft is very confused about what the flag means. And both of =
the conflicting descriptions in the draft are in conflict with this =
statement. Here are the three conflicting positions (I=E2=80=99m =
wondering how many will emerge before this can be sent back to the April =
1 queue).
>>>=20
>>> =E2=80=94 "IPv4 is Not Available on this Router"
>>>=20
>>> =E2=80=94 "A host that receives only RAs with the flag set to 1 =
should not attempt IPv4 operations, unless it subsequently receives at =
least one RA with the flag set to zero."
>>>=20
>>> =E2=80=94 "A host that receives Flag=3D1 should stop sending IPv4" =
(to what routers? on which interfaces? until what condition arises?).
>>>=20
>>> Please send this draft back into the For Comedy Purposes Only =
category and leave the serious business of this topic to the SUNSET4 =
working group, which is actually chartered to deal with it.
>>>=20
>>=20
>> That=E2=80=99s harsh.
>>=20
>> I note that the relevant draft in sunset4 has been updated in 3 =
years, and Sunset four hasn=E2=80=99t meet since IETF97.  Doesn=E2=80=99t =
seem like anything will happen there.
>=20
> The SUNSET4 working group still has an active charter.
>=20
>> We wrote this to solve what I think is a real issue observed with the =
use of NAT64 on the IETF100 network.
>=20
> It=E2=80=99s not a good solution. The issue is quite a bit more =
complex than jamming a new flag into the RA message will allow.
>=20
> Consider the current behavior of some of the products that my =
employers produce, which send RA messages (lifetime=3D0) on their Wi-Fi =
interfaces to distribute PIO elements to hosts that need ULA addresses =
in the Nest Weave fabric space. Under this draft, each currently fielded =
Nest device would cancel the 4=3D1 flag sent by any IPv6-only default =
gateway. Which is a kinda silly thing to do when you=E2=80=99re a router =
between Wi-Fi=E2=84=A2 and Thread=E2=84=A2 and Thread=E2=84=A2 is an =
IPv6-only link layer. Wouldn=E2=80=99t you think setting 4=3D1 to be a =
good idea in that case? Alas, it=E2=80=99s not. If we do that, then any =
dual-stack hosts on a network with an IPv4-only CE router will shut off =
their IPv4 activity, and they will not get any IPv6 service through us. =
This is probably not what anyone wants, so we would of course never =
ever, not in a million years, never send 4=3D1 in our RA messages.

I hadn=E2=80=99t thought of this use case (using IPv6 on a link with =
only IPv4 internet connectivity), I agree that you would not want to be =
setting the flag to 1 unless you had knowledge of there not being any =
IPv4.

Would the issue be resolved if the text said something to the effect of =
only act on this flag if the router is also saying it is a default =
router, that is lifetime > zero?  I think that is the intent.   Seem to =
me this would allow you to continue your current operation and not =
disrupt the IPv4 on the link.

Also, who am I to argue that you shouldn=E2=80=99t use ULA addresses :-)

Bob

>=20
> Now, you might say we shouldn=E2=80=99t send RA messages at all (even =
with lifetime=3D0) unless we are willing to be a default router. You =
might say that the default router should forward our Weave fabric prefix =
to us from hosts on the LAN. And I would say, that sounds like a capital =
idea, except each and every one of the workable technical alternatives =
to get hosts to self-assign on-link addresses, and set host route =
entries for a working route to the rest of the Weave fabric behind our =
local router, or at least to have a reliable means of routing on home =
networks through the usual default route at the CE router, have all been =
roundly rejected by industry and at least three separate IETF working =
groups. We do what we can because it=E2=80=99s the only thing that =
works.




>=20
> So, no=E2=80=A6 we=E2=80=99re not going to stop sending RA messages =
(lifetime=3D0) . And so, we=E2=80=99re going to step on this 4=3D1 bit =
until the end of time. In other words, this draft won=E2=80=99t do what =
it hopes to do.
>=20
>=20
> --james woodyatt 
>=20
>=20
>=20


--Apple-Mail=_DD946799-A194-4766-8114-9735D24E3C66
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

iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAloPnWYACgkQrut0EXfn
u6iAiwgAwe9b17qNpAR75oC+kmQRhIG3LPnvEubwn9EgWrGv9AXpavxQSlbZiFAw
Bx3hQ9+LqfcK5VJDq96Stgd7BPzjtA0lgjnEXU7D/fR8I15R3e99oWmkygjGeCd3
hKVnm7G9u7W7SEgjmepXgkC0vE8t3TzVdrsw1XC+QVhnSBHyX7CefCkg6zGNEhyC
wU5ASy/SsDgLYM1tpScH5l1hAQpgg37aaHPK0G6ohaHyOsOO80YB75n3sdncKmXM
r/9tTylgc4Rly0ksSv5tMnNL4DuDklL97iAZBqr8xwB2vlF8DMnBzqFKRxWKedvG
l18aYNj1QEJAifk31fH4zKAvl7jdjg==
=jApz
-----END PGP SIGNATURE-----

--Apple-Mail=_DD946799-A194-4766-8114-9735D24E3C66--


From nobody Sat Nov 18 00:47:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76DC126B7E for ; Sat, 18 Nov 2017 00:47:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Y9XnzTYvLnon for ; Sat, 18 Nov 2017 00:47:05 -0800 (PST)
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 E86161200C1 for ; Sat, 18 Nov 2017 00:47:04 -0800 (PST)
Received: by mail-io0-x236.google.com with SMTP id x63so11082909ioe.6 for ; Sat, 18 Nov 2017 00:47:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UyvP6VsyM0l8PHR0hAvRiwuSTQ9yoxUYOL3fOK8/UUo=; b=UduEtRWIr8jCrM1367viCnyCP9akbDmBHSvv6mF25SslwEY2Rx3itsS1DU95eVxkUa Gv4yW1kWRWP+FVr2YoNl1kLsJsXENa+En3en4C7B23u3w61DnH1LVYR1HxMXGmgv6hsJ 7HNNfIG8RP4u6roKW5yajCSd8T9XfoXlIg+1j2Xyt/9Xb9/5IZGFBmDUcfx7NqKx/6Nj GjFqO174OWHgyyQwzPkK11D7r3o6nnewjnW8N8KFgUY+/UMZsBCAN/OZYoPMlApBUGg/ 6PSZakBp34HstNrPN2Xsn5qolKC1/aU6pHuZK0nRs13z5eExL1J5JygSU6BFsGavUqrX nkRg==
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=UyvP6VsyM0l8PHR0hAvRiwuSTQ9yoxUYOL3fOK8/UUo=; b=P10QHZS4VDsvsQ95QcayGMbx0x1MEjJCiCdf6TxAaLBVnb5URzsAcS5ayp/a8kytIo FSeSU/MgYYt8BYOrM3dWF0CF06xLTqKmEIOLowE/NwNDS3ncxm2+ForCBrxDaEiYijHs 9Io9I58LvyHypznFhLqdMNjB8i7C2x/ml1AvAyN/CQu3TFTdWx58dWBrrGd4kAvqE7r2 ES7H7ucdiAcPTD3kS51WoqxzsA4Wdq88o0DxwovnYuOvbJW1M+Yi9e0CLRsocqWPfVsP ryIOBq4jzo4F7CigBqreUtBxYaLrRhab2e1RYP4P2TTx3VyYTS1vAmAuJ9k/Yl9CtZYd yl6A==
X-Gm-Message-State: AJaThX54wdJNVM3BXCXjLq5TtTnAtTNKF+TqLVWbgov3wTzjOAY98GDy MZUncUxVFWsZztIAsgN9xbu1H8SMgGy83ZhcHz3d3sC4
X-Google-Smtp-Source: AGs4zMbYq0mnLzfxJoAH2kgd8zKuZGtlMxcfqpjN6ebrC5sISpQPwC4kYqEHN3CKuwo6zk5iY+aJxjI+lrO2Xm4XY6Y=
X-Received: by 10.107.16.206 with SMTP id 75mr6179058ioq.83.1510994823839; Sat, 18 Nov 2017 00:47:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.16.155 with HTTP; Sat, 18 Nov 2017 00:46:42 -0800 (PST)
In-Reply-To: <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com> <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com> <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com>
From: Lorenzo Colitti 
Date: Sat, 18 Nov 2017 17:46:42 +0900
Message-ID: 
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: james woodyatt 
Cc: Bob Hinden , IPv6 List ,  Fernando Gont 
Content-Type: multipart/alternative; boundary="001a113eda96bc0a90055e3de50a"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 08:47:07 -0000

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

On Sat, Nov 18, 2017 at 11:20 AM, james woodyatt  wrote:

> Wouldn=E2=80=99t you think setting 4=3D1 to be a good idea in that case? =
Alas, it=E2=80=99s
> not. If we do that, then any dual-stack hosts on a network with an
> IPv4-only CE router will shut off their IPv4 activity, and they will not
> get any IPv6 service through us. This is probably not what anyone wants, =
so
> we would of course never ever, not in a million years, never send 4=3D1 i=
n
> our RA messages.
>

Yep, a single flag won't work unless all routers agree on it. What about an
option that signified there was no IPv4 on the network? If the option is
sent by any of the routers on the link, then hosts would not attempt IPv4
configuration.

Not sure how that would support IPv4 becoming available once the option has
been set. Also, not clear how to deal with the DOS scenario where a rogue
RA disables all IPv4 on the network until the end of time.

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


On S=
at, Nov 18, 2017 at 11:20 AM, james woodyatt <jhw@google.com> =
wrote:
Wouldn=E2=80=99t you think setting 4=3D1 to be a good idea in that c=
ase? Alas, it=E2=80=99s not. If we do that, then any dual-stack hosts on a =
network with an IPv4-only CE router will shut off their IPv4 activity, and =
they will not get any IPv6 service through us. This is probably not what an=
yone wants, so we would of course never ever, not in a million years, never=
 send 4=3D1 in our RA messages.

Yep, a single flag won't work unless all routers agree on it. What abo=
ut an option that signified there was no IPv4 on the network? If the option=
 is sent by any of the routers on the link, then hosts would not attempt IP=
v4 configuration.

Not sure how that would support =
IPv4 becoming available once the option has been set. Also, not clear how t=
o deal with the DOS scenario where a rogue RA disables all IPv4 on the netw=
ork until the end of time.


--001a113eda96bc0a90055e3de50a--


From nobody Sat Nov 18 01:22:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231D6126DFF for ; Sat, 18 Nov 2017 01:22:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYYa5bDs_QvE for ; Sat, 18 Nov 2017 01:22:47 -0800 (PST)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 709FB12421A for ; Sat, 18 Nov 2017 01:22:47 -0800 (PST)
Received: by mail-lf0-x22b.google.com with SMTP id k66so5167608lfg.3 for ; Sat, 18 Nov 2017 01:22:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JzhOGhFa7U6HhVJEufI9hjksNING5wTg/rOhY9cNdWY=; b=JDqMlYiyF8w5geYpf2+BftNS82WGAb7ph5t1BdZ5FUbLJco2xIYKTc1QVU3C90AcQf 582uuVGuHfax9eFlq4kUafxTgwV4z5AyNZHVlPN2gaQ0yYG6n+9u3WEWC6foEt3bFaa9 8lTe3dzW+uj6w+CQ3QCRE7VsJDJuEFQ+QUiqk0Uq+urzQJrtqVBWpEs8NedDllooUrJt pIcGNMUHVnD3726Qqww/skK02pRhYfT/AACk+r1ahpjmbRfqVaT306IHRd+Gta4mvyFt +0jIiTOJ1FWkjqTDgRLylzQs3WlJ+PuhZIlwdBRUYEDA65k2f/lB1y8D2SUCaG/GcIcI aFFg==
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=JzhOGhFa7U6HhVJEufI9hjksNING5wTg/rOhY9cNdWY=; b=Ck6AbUjTSHtej7ZMEqWaapLcb17V5U6reyY8o+iMgFa6KM5L0KJ/e0KsgheIOgMSEw MLWlnWlC6dpYk3vQJtjTIpFPAjvCKwbxXKuepZZZWYM38g3lUqM/23RiZQE8LIhxflqT 8JUw9onlLZ/7z/uqFzeHcqetV42j9HyGlYGYEGadEsTiJX/Iw3Dxcab22HZ1iT8mRcnJ cE7jwlmbdUO3Md047PHdZp6GjzKuk+PScJaoWgECxL+MUHr/+ABdjaU16UfF66gcrRPB dmamEvqJ6QjzfDWNjZmwagzImGKq8CVHUION5jo1BoMMeka7yQBBHVxjG39NlSKmrh46 Hsbw==
X-Gm-Message-State: AJaThX4nJ86c4YJ4mIVunxtlTNamcsBi/zyDdn2jWeFJLKhsKFnl5gmC QzNGTqW+XiQJGrGzWaLIeirNrHuNGuFrIgQ9gzs=
X-Google-Smtp-Source: AGs4zMZIgsqCpX37OMnVfT38bUZ4jUuzloTHwLKAhd/P+vXEVnj0oUdhPywQ+x9tcG+PzaBO+V/g7rOtH+wOGb07IRQ=
X-Received: by 10.25.109.6 with SMTP id i6mr1765102lfc.73.1510996965490; Sat, 18 Nov 2017 01:22:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.205.2 with HTTP; Sat, 18 Nov 2017 01:22:24 -0800 (PST)
In-Reply-To: <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>
From: Jen Linkova 
Date: Sat, 18 Nov 2017 20:22:24 +1100
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: james woodyatt 
Cc: Ole Troan , 6man WG , Mark Andrews 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 09:22:49 -0000

On Thu, Nov 16, 2017 at 6:07 AM, james woodyatt  wrote:
> IMHO the optimal solution is:
> - the network SHOULD provide a host with NAT64 prefix information in RA;
>
>
> Disagree. If the network has NAT64, then it should deploy RFC 7225.

Even if does not deploy it for NAT44? Do we really want to make NAT64
deployments more complicated than
just replacing NAT44 with NAT64? ;)

-- 
SY, Jen Linkova aka Furry


From nobody Sat Nov 18 03:10:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AD4126D3F for ; Sat, 18 Nov 2017 03:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyYDauPzsH2D for ; Sat, 18 Nov 2017 03:10:28 -0800 (PST)
Received: from patsy.thehobsons.co.uk (ruthandcrusoe.plus.com [81.174.150.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB3712025C for ; Sat, 18 Nov 2017 03:10:28 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from simons-macbookpro.lan (unknown [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id C8AC11BC37 for ; Sat, 18 Nov 2017 11:09:36 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
From: Simon Hobson 
In-Reply-To: 
Date: Sat, 18 Nov 2017 11:09:25 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <82D69638-7AD1-41B8-A2AD-EE94EAEB5106@thehobsons.co.uk>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com> <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com> <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com> 
To: IPv6 List 
X-Mailer: Apple Mail (2.1510)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 11:10:30 -0000

Lorenzo Colitti  wrote:

> What about an option that signified there was no IPv4 on the network? =
If the option is sent by any of the routers on the link, then hosts =
would not attempt IPv4 configuration.

Doesn't that come with exactly the same problem as described ? If *ANY* =
router on the network provides IPv6 only, then it'll signal that there's =
no IPv4 on the network even though there may well be. Since that router =
may or may not actually provide full connectivity, and even if it does =
it may not be what the network people want devices to be using, then the =
end result is "device sends RA, breaks network".

> Not sure how that would support IPv4 becoming available once the =
option has been set.

Presumably the device would stop signalling that there's no IPv4, and =
then it's up to the hosts to decide if they will try configuring it.

> Also, not clear how to deal with the DOS scenario where a rogue RA =
disables all IPv4 on the network until the end of time.

That's not really a new threat. A rogue device can issue RAs and make =
itself the default router and break IPv6 - so the only new aspect is =
that it can break hosts that do try connecting via both IPv4 and IPv6. =
Looking ahead to the final destination of having no IPv4, then the end =
effect is the same - a rogue device can use RAs to break the network.


From nobody Sat Nov 18 04:52:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B8F126DED for ; Sat, 18 Nov 2017 04:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 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_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 8jqz0_MHstTg for ; Sat, 18 Nov 2017 04:52:01 -0800 (PST)
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 697741200E5 for ; Sat, 18 Nov 2017 04:52:01 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id g73so11402350ioj.8 for ; Sat, 18 Nov 2017 04:52:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AHjut/L7WKmBEZWdxYSgvYnuA+B4rvXU2QSReEZSD8I=; b=SalRL9V0pKfTy5lT9WXGooI7+U2+jhb9PHSAMulNBulwi4rUMeo3Y5l/OmFlGRXCYK Bho0TLUHeJYKsBuAs0Dys+V4lcH8SwwrAAVOuwrufoe9FnRrxFCNCm0MKsXUrEmx+0hm cLFZepuX/N3Z3sCKaSUflEkHulx1U6KSx8SV4IyuinXPQAMkIIfCnW4Rst9HdqUGmICQ FJY7mxTxG5geOz9Ubc5Ge1F1rsKeJrpFXmhhP/qj9loSmaxP9LBxm51LyPpHaQA35LWF dES1vlcKGzQCQ07ic5z3bzN4k8IB5PC+SDtG/77Efaxhnw6yAJvzKvTJTyt2Vj9WmK2u wl9A==
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=AHjut/L7WKmBEZWdxYSgvYnuA+B4rvXU2QSReEZSD8I=; b=VtrMLuQkMq6Ac3LbibDjI1nGmU/iu7/HJTQuDQbBetMVQHdm2E+u6P3FMrLUG5ZgcA 7v6crIRcc8nPSMyTqbIYlplG3DnHAoQbUycDWYAO9/Jl4vaPvV69Cg4wWBQ5lPqoxzyJ 2ZxGjoowg3SaAVNjaYaaVrSmg+XIQsnJUyi+CCq59MPSIiyw55a32Idvx/HG9DCI09Yn vr8UBBHigmRWxPfSEAyd4ERYv/p1Pwua62LGla78YgdX5qOM+ZESfxBGyjC++JyX/QuY xmHrvE97ZlfGNvtTgPDWqpOax2xnqC0KANRDpCg4+valLOiva6Mqh5qQSUWvRxccI/yH 9Xyg==
X-Gm-Message-State: AJaThX4Xu/QtjD9uEodLDBnI9GMFFz4uGbwIkeVf4Mrfk2Cl5ZOFXlEs MOAlBnWaVOWWwk3qzx6VgqWK1KPsgINeF9nBvZlmHCPE
X-Google-Smtp-Source: AGs4zMZaSO4nSNDHJYQi9ezDJw7ais1V/31P4KIGE96t+7sIwpmNBdRaW3HMGCL6kz414ix8hNbX3VXMmZbfN8ty7qg=
X-Received: by 10.107.53.42 with SMTP id c42mr6962241ioa.254.1511009520118; Sat, 18 Nov 2017 04:52:00 -0800 (PST)
MIME-Version: 1.0
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com> <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com> <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com>  <82D69638-7AD1-41B8-A2AD-EE94EAEB5106@thehobsons.co.uk>
In-Reply-To: <82D69638-7AD1-41B8-A2AD-EE94EAEB5106@thehobsons.co.uk>
From: Lorenzo Colitti 
Date: Sat, 18 Nov 2017 12:51:49 +0000
Message-ID: 
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Simon Hobson 
Cc: IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary="001a11449a44b366b6055e4151a5"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 12:52:03 -0000

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

On Sat, 18 Nov 2017, 20:10 Simon Hobson,  wrote:

> > What about an option that signified there was no IPv4 on the network? If
> the option is sent by any of the routers on the link, then hosts would not
> attempt IPv4 configuration.
>
> Doesn't that come with exactly the same problem as described ? If *ANY*
> router on the network provides IPv6 only, then it'll signal that there's no
> IPv4 on the network even though there may well be.
>

It would be up to the administrator to ensure that no router sent the
option unless the network were truly IPv4-only. So the situation you
describe would be a configuration error.

That would mean that the option could only be used in managed networks.

Not great, I agree.

>

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


On Sat, =
18 Nov 2017, 20:10 Simon Hobson, <linux@thehobsons.co.uk> wrote:

> What about an option that signified there was no IPv4 on the network? =
If the option is sent by any of the routers on the link, then hosts would n=
ot attempt IPv4 configuration.



Doesn't that come with exactly the same problem as described ? If *ANY*=
 router on the network provides IPv6 only, then it'll signal that there=
's no IPv4 on the network even though there may well be.

It would be up =
to the administrator to ensure that no router sent the option unless the ne=
twork were truly IPv4-only. So the situation you describe would be a config=
uration error.

That woul=
d mean that the option could only be used in managed networks.

Not great, I agree.




--001a11449a44b366b6055e4151a5--


From nobody Sat Nov 18 05:12:53 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FABB126DEE for ; Sat, 18 Nov 2017 05:12:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.801
X-Spam-Level: 
X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[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 5DWK9iDh4KuL for ; Sat, 18 Nov 2017 05:12:50 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D071200E5 for ; Sat, 18 Nov 2017 05:12:50 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id j198so2676246ywg.9 for ; Sat, 18 Nov 2017 05:12:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F/Eis+jKzf4MChwtulHhUYPfQPowWyPexu6MnOr/ceU=; b=G9KdUrqRUr/RkCAPK8qqOX7sMjbATO88IV/iDzzh3kC/fV5oaJTPZ1/Pei2+B5Cpaf JroSaxCOCo7K+nQ5IeuWaZd2mjOVjWr1+xCghKm9L4hygC3V/NZljLVyKS4DLLf1aIeP pDsZlv+Js7mGi8GndhtBlkyqPhZHNGqZB/hpHkJEwchNZfd2bUKB271Ey8c1pKsL536N D4RDigcG/BqGKL1faaPnLoowQDSsoqrQZivmxApEe/ijhGmF8n6RgZgr1LWvu39E+4FQ a5I24tWiDhkAw4nTOMM+kyGxiyG+PWBy3eTA+ps13/j46NCObQHHM5FTGAvl8I4MoOun ePcA==
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=F/Eis+jKzf4MChwtulHhUYPfQPowWyPexu6MnOr/ceU=; b=o4pRRsrneIyuEx8wqzIXxKk/iF48ejqXNWb0FCVrKZ6Wo7srCb/Or/U4SDIlieE6aq H+/VuRQgFYNnJvRAgVQzHaMMmvO7R0V3mrwO+4vAj4RboDbix6QnlBzxVRYWHl6lB9Kv rSOTwphGmUgSMtp0l2IdnnzDqUfDyo+805OpgJA1ll4FYw2yMe9Ibeun500MZg5JddBI WgXKup3mr0D+o3nxikNthD/4zv+NYGYoxxoq+30Cif1O77PS+K+OjeIOnyJTUNh39upw /VTdzJwfDb43QkkySjEdnUWNXQQpPUVMH0C2TnyxcGev5fskqf3YzrbIlYW//0hJ5G+8 IBcw==
X-Gm-Message-State: AJaThX6oGTYQZhkJTGF3jKxjur+L7jWPKb5uPSi3PgQjaW/KS3KS/wHI gx1xAEUVSuuDp31e15TWCAS38eIOKZU+3d77pojCPA==
X-Google-Smtp-Source: AGs4zMaI0OfaN2hKcB8SAoHffFxZ+tDa1hvp5y43eSK6MYsrjbc3YTABG6Ld2xKp6uJkfANQ3ZfdHQ/GmAd/cCjsd7M=
X-Received: by 10.129.133.131 with SMTP id v125mr5096760ywf.442.1511010769038;  Sat, 18 Nov 2017 05:12:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.187.17 with HTTP; Sat, 18 Nov 2017 05:12:28 -0800 (PST)
In-Reply-To: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> 
From: Erik Kline 
Date: Sat, 18 Nov 2017 22:12:28 +0900
Message-ID: 
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Bob Hinden 
Cc: IPv6 List 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114f221a2c8fec055e419cfb"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 13:12:52 -0000

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

I like this, and it seems similar to something that came out of some
sidebar conversations I was having in Singapore.

Here are a few changes I might suggest, followed by how I could see
implementing such a thing in an OS like Android.

    [1] I would propose making it an EFO bit and leave the reserved
bits for potentially more IPv6-critical information signaling.

    [2] I would not say that 0 means "IPv4 is Available on this
Router" but rather "this router makes no attestation about the
availability or lack thereof of IPv4".

The actual implementation that I could see being reasonable is as follows.

Because every OS starts IPv4 and IPv6 configuration paths in parallel
on link-up/link-attach, I think the most reasonable thing to do is to
interpret this flag as the "save your electrons flag".

In Android I think I would propose that we consider the bit only after
we have satisfactory global IPv6 provisioning, which I would define
as:

    [a] at least one valid (i.e. non-deprecated), non-ULA, GUA

    [b] at least one valid (i.e. non-deprecated) default route

    [c] at least one valid (i.e. non-deprecated) DNS server

Additionally, we could include a successful internet connectivity
check as a requirement, just to make sure we keep trying IPv4 until
any captive portal has been passed.

Finally: once IPv6 can be categorized as "working", and we saw no
other RAs with 0 in the extended flags options nor any RAs without
extended flags options, and we hadn't yet found any DHCPv4 server,
then we could use the "save your electrons" flag as a signal to stop
our DHCPv4 client.  Operating Systems that implement IPv4 link-local
communications (Android does not) might use this signal to disable
that as well.

--001a114f221a2c8fec055e419cfb
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg8maiwZLsNaX6cKGbXE49J45R4QulYhOv
DDDrOa2vX3UwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTE4
MTMxMjQ5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAFRKF/7qFmwmjm9nA9WNt6e8fKW9T/YOfyKCR3JEW34tgYBWMpko
jWa7kPjKDRYGh1K1o0DhlIXf/EqJg4y/6a+GMGdeENDLpe/nE1I1DkOiebVl8c5pbhFGVg7XeT+j
G/W18BCQU61mz52kO3YoNvsqkxQr4gpHlJkD7Ll8qEJJPczVm4ys+S4qsRjxur9UEg1TUR+I7N8N
NN/GtXsCxnAfiarQM5Ja1DTVyiE762PXyvxqVmtsV1d4SQaiduTeIZ1Ea/R+FCZyR4en7z4cJgzc
21iSPvIMiVajRm6a3dXtewobHaePDAazAAfiW2JxUWLg191CsirwsDwqA8IM1v8=
--001a114f221a2c8fec055e419cfb--


From nobody Sat Nov 18 05:15:43 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F7E126CBF for ; Sat, 18 Nov 2017 05:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxVHaUWV2Yrq for ; Sat, 18 Nov 2017 05:15:40 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7145E1200E5 for ; Sat, 18 Nov 2017 05:15:39 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vAICFNcn017830 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Nov 2017 12:15:23 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <5A103276.6060001@foobar.org>
Date: Sat, 18 Nov 2017 13:15:34 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Lorenzo Colitti 
CC: Simon Hobson , IETF IPv6 Mailing List 
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com> <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com> <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com>  <82D69638-7AD1-41B8-A2AD-EE94EAEB5106@thehobsons.co.uk> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 13:15:41 -0000

Lorenzo Colitti wrote:
> On Sat, 18 Nov 2017, 20:10 Simon Hobson,  wrote:
>     Doesn't that come with exactly the same problem as described ? If
>     *ANY* router on the network provides IPv6 only, then it'll signal
>     that there's no IPv4 on the network even though there may well be.
> 
> It would be up to the administrator to ensure that no router sent the
> option unless the network were truly IPv4-only. So the situation you
> describe would be a configuration error.

there would also be a SAVI implication here; otherwise any connected
host on an l2 domain would be able to disable ipv4 on any host that was
listening to a flag of this form.

These and other issues were brought up before in the context of the
sunset4 draft.

Nick


From nobody Sat Nov 18 05:24:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FD2126D74 for ; Sat, 18 Nov 2017 05:24:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Level: 
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 whXC1dKIDp-J for ; Sat, 18 Nov 2017 05:24:23 -0800 (PST)
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 EB998126B6E for ; Sat, 18 Nov 2017 05:24:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1511011460; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=6GW2g7qEsjPS2WBCq8nJ+QiKoDpLEAm8HI/xiYMuVw8=; b=Wa64pnzF1fCh4LN5YnwxFMXhb+iTVri51j76A38JHVaMHSshNeW2uedosLge5cQxMXzux1Qr/mZdl4GH3fLPPjRbRePMyD2qpVov0Ej5sDCprkhpHow8jm2D9sh0LSwxOHts9+3RMAulxfOdA3MBInW2ytdWtEN72DMTT4rYEkE=
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0246.outbound.protection.outlook.com [213.199.154.246]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-21-ICc_SyUmPBGwfMWgA4d-fA-1; Sat, 18 Nov 2017 13:24:15 +0000
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.260.2; Sat, 18 Nov 2017 13:24:14 +0000
Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::d9b7:5aa5:5084:74c2%13]) with mapi id 15.20.0260.001; Sat, 18 Nov 2017 13:24:13 +0000
From: Tim Chown 
To: Erik Kline 
CC: Bob Hinden , IPv6 List 
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
Thread-Topic: New Version Notification for draft-hinden-ipv4flag-00.txt
Thread-Index: AQHTYG7i5kNf/E4LqE21AqWzsMjgsaMaIC6A
Date: Sat, 18 Nov 2017 13:24:13 +0000
Message-ID: <7A8296F8-197A-47E7-B793-30CEE4AA3EB1@jisc.ac.uk>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.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.3445.4.7)
x-originating-ip: [2001:a88:d510:1101:7117:5632:cec4:6680]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM3PR07MB1140; 20:lQPQwsJ3DKnufyr47NbrTOqL9P4rIDGy0DdLBcwAt9XQeD7HrfKhp95Lrv3TCo7YJtHIp3QUl9OoAYISpHvonREEMUJ1nhuA2O4pzItyidmCz+Dck3znyae2EwS4xbE2I08iMCsSGvr2wl7yu4PT0M/7QWDy0Rl+LvIDYjp11/Y=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 3e1274a3-ab74-4369-2aa0-08d52e87a961
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM3PR07MB1140; 
x-ms-traffictypediagnostic: AM3PR07MB1140:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(153496737603132)(275809806118684); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(3231022)(920507027)(6041248)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(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: 04953B1F22
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(24454002)(82746002)(2900100001)(83716003)(53546010)(74482002)(786003)(316002)(6506006)(6116002)(102836003)(99286004)(72206003)(39060400002)(97736004)(8936002)(36756003)(50226002)(229853002)(478600001)(6436002)(6486002)(54906003)(5890100001)(189998001)(4326008)(106356001)(5660300001)(230783001)(101416001)(105586002)(42882006)(6916009)(2950100002)(2906002)(5250100002)(34040400001)(86362001)(25786009)(3660700001)(50986999)(305945005)(68736007)(8676002)(7736002)(76176999)(53936002)(6512007)(6246003)(57306001)(14454004)(81166006)(33656002)(3280700002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1140; 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-Network-Message-Id: 3e1274a3-ab74-4369-2aa0-08d52e87a961
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2017 13:24:13.9660 (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: ICc_SyUmPBGwfMWgA4d-fA-1
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 13:24:27 -0000

> On 18 Nov 2017, at 13:12, Erik Kline  wrote:
>=20
> I like this, and it seems similar to something that came out of some
> sidebar conversations I was having in Singapore.
>=20
> Here are a few changes I might suggest, followed by how I could see
> implementing such a thing in an OS like Android.
>=20
>    [1] I would propose making it an EFO bit and leave the reserved
> bits for potentially more IPv6-critical information signaling.
>=20
>    [2] I would not say that 0 means "IPv4 is Available on this
> Router" but rather "this router makes no attestation about the
> availability or lack thereof of IPv4".
>=20
> The actual implementation that I could see being reasonable is as follows=
.
>=20
> Because every OS starts IPv4 and IPv6 configuration paths in parallel
> on link-up/link-attach, I think the most reasonable thing to do is to
> interpret this flag as the "save your electrons flag".
>=20
> In Android I think I would propose that we consider the bit only after
> we have satisfactory global IPv6 provisioning, which I would define
> as:
>=20
>    [a] at least one valid (i.e. non-deprecated), non-ULA, GUA
>=20
>    [b] at least one valid (i.e. non-deprecated) default route
>=20
>    [c] at least one valid (i.e. non-deprecated) DNS server
>=20
> Additionally, we could include a successful internet connectivity
> check as a requirement, just to make sure we keep trying IPv4 until
> any captive portal has been passed.
>=20
> Finally: once IPv6 can be categorized as "working", and we saw no
> other RAs with 0 in the extended flags options nor any RAs without
> extended flags options, and we hadn't yet found any DHCPv4 server,
> then we could use the "save your electrons" flag as a signal to stop
> our DHCPv4 client.  Operating Systems that implement IPv4 link-local
> communications (Android does not) might use this signal to disable
> that as well.

So the flag might be the IPv4 equivalent hint to the IPv6 M/O flag, or it m=
ight be a stronger hint to also not auto configure a v4 LL.  I think when s=
unset4 last discussed this idea the focus was on the former case.

Perhaps this is this something to introduce with the PvD work?  The presenc=
e or not of v4 service is a property of a PvD, and in scenarios with multip=
le PvDs the host can choose to use v4 (or not) for each PvD?

Tim


From nobody Sat Nov 18 05:42:03 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582AB126B6E for ; Sat, 18 Nov 2017 05:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[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 NmNjbrAlHylr for ; Sat, 18 Nov 2017 05:41:59 -0800 (PST)
Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002: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 9F83D120726 for ; Sat, 18 Nov 2017 05:41:59 -0800 (PST)
Received: by mail-yb0-x22d.google.com with SMTP id p19so1451310ybd.2 for ; Sat, 18 Nov 2017 05:41:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LvXLR75GgrrWfIOi/127Ky5pIm7cN0xVbQrr1Ik7eGw=; b=bV6THEW4VTfamO35QEAnJWij+cnECVg5iUPY+2kl6IdrqqoHEjX/CKAWodmQSuU9R/ GK4z+4jlWxSjD5QSa2OQlXaWUJcyNwJVl3eASBaDjXafXGPjIT1fD1oK7Ety3BiHN8yI esLIDMxzWtiwVpvfF42FnY9e44ahfBxVLQpbz1q+TdOPemMWWlV8lTmKNiOnNHSZA6BZ SBZK7Y9Md/X1MwwWkGElwPkhvbq5UNKaYNUj15rjprYRNg6oGAO3Ylj5mgImjaHcSJrq Ki5rSh8snTXWoQFlYcrhl7H24ZSRw3g+cLB1PZ3JlxcKZ2yAxMPdxD7U01SLaGG5DiwP 8Y1A==
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=LvXLR75GgrrWfIOi/127Ky5pIm7cN0xVbQrr1Ik7eGw=; b=rN4+vPE1eL+UlVabz3gDT2qp9XcY2v2V9SUJTiMJFSx9n9hDES8KHBXpDnGX+855I4 475W2eGC+xdqtvhL5eSPMpyBDu1RBrzq9lfYu/5iuxcTpxmxVzi5inBX0BZhsULj8j3h tRanYCb7O2KQy7qOyre8OpJpWjSEPxnFdf6CmtwjXwO1aD4wWi5ltfO8si4aMvvnWoBH vue5ZYHYGxJc8HqpPh+5QVj2kpmnfbLeTbMYEvFtsy6qaf35ofr/YnPUFNjnVul3jJ3z vXb+wT40AdK5NF0pK7fZaUXI/3KivcmP8UJBj/cQHQ53YI676+YWxdR6T8tjTq/5w2F3 B7VQ==
X-Gm-Message-State: AJaThX7shnfVl3fPwddmhGQ9EAPwy2McfdKPnELb8nq2AIT1jf3HrOR4 SHO75sfZVrC6syLS2gKcli9kLS7+8kH50IKjb2iOSA==
X-Google-Smtp-Source: AGs4zMZlyRM5Ae7L/+Bp7669y3LSKeEU0uWOra/AbW1ivq1B3f4nsTBzDAZlqjZ19+vwHmD0aDbxYFjzKj4ckRX1+i8=
X-Received: by 10.37.189.74 with SMTP id p10mr5184926ybm.185.1511012518404; Sat, 18 Nov 2017 05:41:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.187.17 with HTTP; Sat, 18 Nov 2017 05:41:37 -0800 (PST)
In-Reply-To: <7A8296F8-197A-47E7-B793-30CEE4AA3EB1@jisc.ac.uk>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <7A8296F8-197A-47E7-B793-30CEE4AA3EB1@jisc.ac.uk>
From: Erik Kline 
Date: Sat, 18 Nov 2017 22:41:37 +0900
Message-ID: 
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Tim Chown 
Cc: Bob Hinden , IPv6 List 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="089e0828949c72e161055e420424"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 13:42:01 -0000

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

On 18 November 2017 at 22:24, Tim Chown  wrote:
>> On 18 Nov 2017, at 13:12, Erik Kline  wrote:
>>
>> I like this, and it seems similar to something that came out of some
>> sidebar conversations I was having in Singapore.
>>
>> Here are a few changes I might suggest, followed by how I could see
>> implementing such a thing in an OS like Android.
>>
>>    [1] I would propose making it an EFO bit and leave the reserved
>> bits for potentially more IPv6-critical information signaling.
>>
>>    [2] I would not say that 0 means "IPv4 is Available on this
>> Router" but rather "this router makes no attestation about the
>> availability or lack thereof of IPv4".
>>
>> The actual implementation that I could see being reasonable is as follows.
>>
>> Because every OS starts IPv4 and IPv6 configuration paths in parallel
>> on link-up/link-attach, I think the most reasonable thing to do is to
>> interpret this flag as the "save your electrons flag".
>>
>> In Android I think I would propose that we consider the bit only after
>> we have satisfactory global IPv6 provisioning, which I would define
>> as:
>>
>>    [a] at least one valid (i.e. non-deprecated), non-ULA, GUA
>>
>>    [b] at least one valid (i.e. non-deprecated) default route
>>
>>    [c] at least one valid (i.e. non-deprecated) DNS server
>>
>> Additionally, we could include a successful internet connectivity
>> check as a requirement, just to make sure we keep trying IPv4 until
>> any captive portal has been passed.
>>
>> Finally: once IPv6 can be categorized as "working", and we saw no
>> other RAs with 0 in the extended flags options nor any RAs without
>> extended flags options, and we hadn't yet found any DHCPv4 server,
>> then we could use the "save your electrons" flag as a signal to stop
>> our DHCPv4 client.  Operating Systems that implement IPv4 link-local
>> communications (Android does not) might use this signal to disable
>> that as well.
>
> So the flag might be the IPv4 equivalent hint to the IPv6 M/O flag, or it might be a stronger hint to also not auto configure a v4 LL.  I think when sunset4 last discussed this idea the focus was on the former case.
>
> Perhaps this is this something to introduce with the PvD work?  The presence or not of v4 service is a property of a PvD, and in scenarios with multiple PvDs the host can choose to use v4 (or not) for each PvD?

PvD information is for configuration information above and beyond
bootstrapping configuration.  Whether or not IPv4 service is available
on-link is part of the bootstrapping configuration.  Besides, the PvD
may provide IPv4 service via NAT64, but that's separate from what's
available on the link.

I think it should be a hint, yes.  But you raise a good point: IPv4
Internet access not being available on-link is different from, say,
0x0800 ethertype being filtered out by the infrastructure (perhaps 2
bits?).  Still, a hint would be useful for us to save transmitting
useless packets and we could even install a hardware filter to drop
all 0x800 in the wifi chip, further saving us from wake-ups (on
networks where 0x800 wasn't dropped).

--089e0828949c72e161055e420424
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg8AZbuBZUkSE2c2oD+oPMWlI0zD7WxH9I
S3HXYNM94A8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTE4
MTM0MTU5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBABra3DhfVHBCtIK2W1Sfs1WUSrJVVpssSX2zpwPZHkRqnY936ClQ
ULQQ0F1aBVC7F7U4yuTeDFvZvv3BotJQ7KlVG4EhCgUYoeFcdjpdJAHh4k//hdjAY4uUNxrXqOTr
nN6JSVF8gOws9H/NJZYFyw3pSRsUTgP8WNUAuvl9QQjP52ms+0LrdUuhRta+Oqgrix7Isi+QHwI+
z3N8snEXY9iUtZso0RJTjq6KdGRpsoEK4uc7A2QTzMAwHaVWDp7z1Luo+u0iVJXpSWIs1mAGuL9R
Z2f8Wle66OyWZZCGyHdM6SmRc7i/ghtuDJtI67CZRs19kDAtS/Jc76+UzonLW5A=
--089e0828949c72e161055e420424--


From nobody Sat Nov 18 06:40:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A14127077 for ; Sat, 18 Nov 2017 06:40:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.55
X-Spam-Level: 
X-Spam-Status: No, score=-0.55 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNQP5beG1MaP for ; Sat, 18 Nov 2017 06:40:05 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 DF6E4120726 for ; Sat, 18 Nov 2017 06:40:04 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id f134so5623552lfg.8 for ; Sat, 18 Nov 2017 06:40:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z8asHcJs1gsml2FazpHF8rrKqy2r5WpNBHFsz7Ie+xo=; b=ErtYMh3JU8LFnM9p3pUdNz/TWrn3Dad2LEs0U519Bjvq1ve8uvqkEJlw7P8o5JBiMZ tXUA9OA677irNXjE8XCiHUbXmmcBlH8arJPKGkjpQpv+nFgjOfreqkZoMYWL9GOvSRWM OEXQE+UuqHdNCx5eja4FEvudcBHzXfhht9tJbZAKhUecwFz6+PiTgpkPEcm1btxQ/wCA EydJB7a4n65L0oZwUG88lKmHm+lySP1z7y2WmvScsH1x01hWcD3mzeDksA/mamFwF9uk oH+wsacWWZQudROE+lCIOf71ZcAcZyr5pqiIQgef8Fh8mwSNEWiYkwWyMN9Q1DFckhir ClOg==
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=Z8asHcJs1gsml2FazpHF8rrKqy2r5WpNBHFsz7Ie+xo=; b=F63X3042fMkyMKnkIeeM116kNUR94jk2YHwvsODwOyHJ04eimGybpxaSU+4tuWwH4/ 7UKTB31XKT5Fx1U7yMEG8lDC3YEu+05uZqlGfEXqSjcyz9bZwPg5HBeSZXi3Hw8euaho +4q45KrkqrkgyUOmxnMBn1wJ3+4XSVU+9/vckz15E/wmJXgL36EOplDWFHLUH7BU5gMa pBYHWvdKAIm+8q6oRr1UAFAOuS5TTRvMweraOFTYEcvi06ck1gCc6y97Fzz5dteqQGgd 0GM48bEI2T5jGLAxFH5KRGLwKjsE9QcYvyImHf60sVH7zs4X1fkC+vgIcAiQbtyseFqq 1g2A==
X-Gm-Message-State: AJaThX6fNiclpBNQkxjtmLKdU9zMF8tN2KjcjNrZpsf9iKrxI33JSU4D C/42bE6ecxHs8H5qGLSq5P2z7Q165MLoksDS+wE=
X-Google-Smtp-Source: AGs4zMYoGFBBKkL5pf0NJiTr/I6q+HjK5pNCOwfckGxRJeSlWyhhScPIj+ghtbCjFwx88CAnen1AlFpeCueT6wS2QBs=
X-Received: by 10.25.26.143 with SMTP id a137mr1969044lfa.105.1511016002960; Sat, 18 Nov 2017 06:40:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.205.2 with HTTP; Sat, 18 Nov 2017 06:39:42 -0800 (PST)
In-Reply-To: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> 
From: Jen Linkova 
Date: Sun, 19 Nov 2017 01:39:42 +1100
Message-ID: 
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Bob Hinden 
Cc: IPv6 List 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 14:40:07 -0000

Hi Bob,

To be honest I'm not convinced that there is a real problem to be solved..
The draft says

'A mechanism is needed  to inform hosts that there is no IPv4 support
and that they should turn off IPv4.'
and it would be great to have more detailed problem statement IMHO...

It looks to me that when you are saying 'there is no IPv4 support on a
link' you mean 'a router does not provide IPv4 connectivity'.  However
it still might be
IPv4 connectivity within the given broadcast domain and the router has
nothing to do with it.

If the problem is 'IPv4 broadcast noise on the link' then it should be
solved on L2 level and the network should not switch ethertype 0x0800.
If the problem is 'all those noisy DHCPv4 requests the first-hop
router has to drop because DHCP relay is not configured' then the
router interface should not accept IPv4 packets at all, problem
solved.

Also it's not clear what a host is supposed to do if it'd been
receiving RAs with that flag set 0 and at some point subsequent RAs
started to arrive with that bit set to 1...
Shall the host stop all IPv4 operations attempts? Basically how that
information could be updated?


On Fri, Nov 17, 2017 at 5:42 PM, Bob Hinden  wrote:
> Hi,
>
> Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 ND
> Router Advertisements.  From the Introduction:
>
>    Hosts that support IPv4 and IPv6, usually called dual stack hosts,
>    need to work on IPv6 only networks.  That is, a link where there are
>    no IPv4 routers and/or IPv4 services.  Monitoring of IPv6-only
>    networks, for example at the IETF 100 meeting in Singapore, shows
>    that current dual stack hosts will create local auto-configured IPv4
>    addresses and attempt to reach IPv4 services.  A mechanism is needed
>    to inform hosts that there is no IPv4 support and that they should
>    turn off IPv4.
>
>    Because there is no IPv4 support on these links, the only way to
>    notify the dual stack hosts on the link is to use an IPv6 mechanism.
>    An active notification will be much more robust than attempting to
>    deduce this state by the lack of IPv4 responses or traffic.
>
>    IPv4-only hosts, and dual-stack hosts that do not recognize the new
>    flag, will continue to attempt IPv4 operations, in particular IPv4
>    discovery protocols typically sent as link-layer broadcasts.  This
>    legacy traffic cannot be prevented by any IPv6 mechanism.  The value
>    of the new flag is limited to dual-stack hosts that recognize it.
>
> We were originally thinking it would be an April 1 submission, but after
> reading the discussion on the IPv6 list, we decided it makes sense as a real
> submission :-)
>
> Please review and comment.
>
> Thanks,
> Bob and Brian
>
>
> Begin forwarded message:
>
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-hinden-ipv4flag-00.txt
> Date: November 17, 2017 at 2:36:31 PM GMT+8
> To: "Robert M. Hinden" , "Robert Hinden"
> , "Brian Carpenter" 
>
>
> A new version of I-D, draft-hinden-ipv4flag-00.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
>
> Name: draft-hinden-ipv4flag
> Revision: 00
> Title: IPv6 Router Advertisement IPv4 Availability Flag
> Document date: 2017-11-17
> Group: Individual Submission
> Pages: 5
> URL:
> https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
> Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-00
>
>
> Abstract:
>   This document specifies a Router Advertisement Flag to indicate that
>   there is no IPv4 service on the advertising router.  This document
>   updates RFC5175.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
SY, Jen Linkova aka Furry


From nobody Sat Nov 18 07:32:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B6A127337 for ; Sat, 18 Nov 2017 07:32:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.075
X-Spam-Level: *
X-Spam-Status: No, score=1.075 tagged_above=-999 required=5 tests=[DATE_IN_PAST_03_06=1.076, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOB8LaagGZim for ; Sat, 18 Nov 2017 07:32:09 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814EE126DCA for ; Sat, 18 Nov 2017 07:32:09 -0800 (PST)
Received: from [172.19.248.238] (unknown [57.190.1.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id ACE55800DD; Sat, 18 Nov 2017 16:31:57 +0100 (CET)
Subject: Re: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Michael Richardson , IPv6 List 
Cc: Bob Hinden 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <8380.1510930191@obiwan.sandelman.ca>
From: Fernando Gont 
Message-ID: <56c0064f-72b9-98f7-68ec-23d7b6718ece@si6networks.com>
Date: Sat, 18 Nov 2017 20:00:09 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <8380.1510930191@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 15:32:11 -0000

On 11/17/2017 10:49 PM, Michael Richardson wrote:
> 
> Bob Hinden  wrote:
[....
> 
> The security consideration discusson went something like this:
>     - this is a trivial DOS if there is really an IPv4 network
>     - hosts that want to do v4 must therefore take this as advice, rather
>       than gospel, and try the IPv4 anyway.
>     - since they will try the IPv4 anyway, the goal of shutting them up
>       fails.
> 
> However, I am enthusistic about such a flag, even if it is advice only and
> everyone has to ignore it for security reasons.  It announces a desired
> policy for the router issuing it.  It says, "I do not offer native IPv4"
> 
> It can moderate the hosts' enthuasiam for finding an IPv4, can ask the human
> for advice, and if you want to mount a DOS against the IPv4 network, just use
> DHCPv4 as people do now.

It is not the same: the IPv5 could be protected sith something a la
dhcp-snooping, and unprotected nn the IPv6 side. And this mechanism
could allow an IPv4 DoS where otherwise not possible.

Note: The above is *not* an argument against this proposal, but rather
feedback aimed at raising awareness about possible issues. The above
should be described in the Sec Cons section.

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





From nobody Sat Nov 18 08:03:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B37A126C2F for ; Sat, 18 Nov 2017 08:03:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.075
X-Spam-Level: *
X-Spam-Status: No, score=1.075 tagged_above=-999 required=5 tests=[DATE_IN_PAST_03_06=1.076, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8xBR1S9_W8R for ; Sat, 18 Nov 2017 08:03:28 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2677120726 for ; Sat, 18 Nov 2017 08:03:28 -0800 (PST)
Received: from [172.19.248.238] (unknown [57.190.1.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3CB4F80A81; Sat, 18 Nov 2017 17:03:17 +0100 (CET)
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Lorenzo Colitti , james woodyatt 
Cc: IPv6 List , Bob Hinden , Fernando Gont 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com> <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com> <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com> 
From: Fernando Gont 
Message-ID: 
Date: Sat, 18 Nov 2017 20:14:41 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 16:03:30 -0000

On 11/18/2017 04:46 PM, Lorenzo Colitti wrote:
> On Sat, Nov 18, 2017 at 11:20 AM, james woodyatt  > wrote:
> 
>     Wouldn’t you think setting 4=1 to be a good idea in that case? Alas,
>     it’s not. If we do that, then any dual-stack hosts on a network with
>     an IPv4-only CE router will shut off their IPv4 activity, and they
>     will not get any IPv6 service through us. This is probably not what
>     anyone wants, so we would of course never ever, not in a million
>     years, never send 4=1 in our RA messages.
> 
> 
> Yep, a single flag won't work unless all routers agree on it. What about
> an option that signified there was no IPv4 on the network? If the option
> is sent by any of the routers on the link, then hosts would not attempt
> IPv4 configuration.

What would be the difference between encoding the info in an option vs
in a flag?



> Not sure how that would support IPv4 becoming available once the option
> has been set. Also, not clear how to deal with the DOS scenario where a
> rogue RA disables all IPv4 on the network until the end of time.

The only "fix" would be accepting that both versions of IP have become
more and more entangled, and as soon as there's an attack vector  in one
of them, the other version of the protocol can be screwed up. --
something along the lines of RFC7123 and  RFC7359.

Me, I'm generally of the idea of keeping both protocols as
separate/isolated as possible. But if the wg decides to pursue the idea
in this document, the above model of "now one version of the protocol
can be attacked via the other version" should be clearly stated.

Thanks!

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





From nobody Sat Nov 18 08:05:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E8D127419 for ; Sat, 18 Nov 2017 08:05:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.075
X-Spam-Level: *
X-Spam-Status: No, score=1.075 tagged_above=-999 required=5 tests=[DATE_IN_PAST_03_06=1.076, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMsxJ8yBUC2j for ; Sat, 18 Nov 2017 08:05:11 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E435120726 for ; Sat, 18 Nov 2017 08:05:11 -0800 (PST)
Received: from [172.19.248.238] (unknown [57.190.1.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6B2F980A81; Sat, 18 Nov 2017 17:05:02 +0100 (CET)
Subject: Re: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
To: Tim Chown , james woodyatt 
Cc: Michael Richardson , 6man WG 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com>  <21029.1510865502@obiwan.sandelman.ca>  
From: Fernando Gont 
Message-ID: <89a28a07-7025-f6c1-05a7-529bc14b7c95@si6networks.com>
Date: Sat, 18 Nov 2017 20:18:26 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 16:05:12 -0000

On 11/18/2017 12:12 AM, Tim Chown wrote:
> Hi,
> 
>> On 16 Nov 2017, at 22:03, james woodyatt  wrote:
>>
>> On Nov 16, 2017, at 12:51, Michael Richardson  wrote:
>>>
>>> I think that we should mention PCP.
>>> I don't know whether to write MAY, SHOULD or MUST.
>>> Probably not MUST.
>>
>> Given that discovering all the relevant PCP servers is potentially impossible without a DHCPv6 client, and those are not explicitly RECOMMENDED, I think the only reasonable option here is "MAY implement a PCP client†and not “SHOULD†or “MUST†to implement a PCP client.
> 
> Yes, if we were to add something, I agree from comments made that MAY is the strongest we should use. 
> 
> But as you say, with lack of support in common OSes, it’s somewhat moot at present.  

100% agreed. But at the same time, that's circular reasoning ;-)

Thanks!

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





From nobody Sat Nov 18 10:45:10 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3656126D46 for ; Sat, 18 Nov 2017 10:45:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.301
X-Spam-Level: 
X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEiM5Q_Grqgb for ; Sat, 18 Nov 2017 10:45:07 -0800 (PST)
Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A2E126B6E for ; Sat, 18 Nov 2017 10:45:07 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 64A559930B for ; Sat, 18 Nov 2017 13:45:06 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; s=sasl; bh=BA000CPiqxNZxpOfmCIugOk74 xc=; b=M1CUuQFYXXrZCPV2WrnVljxvY6kDo0isphY52RSsFZEoanliQymMKCpP1 CD6DUR4VAO+8cBYgFoV/ww2wgTRzKQgqLdn6ht/1wPzg32Xb2v36xKCS5JHTRWNp ua2ml4q4bjxSw2uWAyoE5SK7WOrBhEXoQmLpYlsm4sjKUR7JF8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; q=dns; s=sasl; b=QUZbKq08D1OhxNlgjUW 9XASn/idOxaA86RzPWfmOhuPqmq+b9go9BBPGAvAM3bGFUQtqWpwRIw3XAyS4JKD LTfkJanq/vAjbYC74e4M2Sm9uZ5q+c7idiZ9/krYBmyCQsbDtDmBVNfHRvpd8zLE FhRBgVz92ZlBVeLeBRPAXhDM=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5C99A99308 for ; Sat, 18 Nov 2017 13:45:06 -0500 (EST)
Received: from mail-qt0-f171.google.com (unknown [209.85.216.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id CFC32992FE for ; Sat, 18 Nov 2017 13:45:05 -0500 (EST)
Received: by mail-qt0-f171.google.com with SMTP id h42so10547047qtk.11 for ; Sat, 18 Nov 2017 10:45:05 -0800 (PST)
X-Gm-Message-State: AJaThX4Ny+pUvf7ZLqsgGJ+/lAAUpzffMpfofCxZxB7v42wZbUl+h3dB ka7Gml9Wj7+BkCigHdFUjNu2B3aj4ywJDtR5Myg=
X-Google-Smtp-Source: AGs4zMYBhNK7AR7z455Hs3fDBh0LtSlOngpx/cwaGegi49ovbopwhuvcnpcrjEeEAbYrn7WI3FYM/ygE8I74+VhbWD4=
X-Received: by 10.200.52.137 with SMTP id w9mr14543338qtb.290.1511030705371; Sat, 18 Nov 2017 10:45:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.22.139 with HTTP; Sat, 18 Nov 2017 10:44:44 -0800 (PST)
From: "C. M. Heard" 
Date: Sat, 18 Nov 2017 10:44:44 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: Updating to RFC6434 to deal with 8200-style header insertion by IPIP
To: Tim Chown 
Cc: Brian E Carpenter , Fernando Gont ,  "C. M. Heard" , 6man WG ,  Michael Richardson 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Pobox-Relay-ID: 982F11A4-CC90-11E7-A8B5-575F0C78B957-06080547!pb-smtp2.pobox.com
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 18:45:08 -0000

On Mon, Nov 13, 2017 at 8:15 AM, Tim Chown wrote:
> On 7 Nov 2017, at 19:29, Brian E Carpenter wrote:
>> On 08/11/2017 00:20, Tim Chown wrote:
>>> On 6 Nov 2017, at 19:35, Brian E Carpenter wrote:
>>>> On 07/11/2017 07:02, Fernando Gont wrote:
>>>>> On 11/02/2017 04:33 PM, Brian E Carpenter wrote:
[...]
>>>>>> Strictly speaking, RFC8200 doesn't specify what to do with
>>>>>> an unrecognized upper-layer header.
>>>>>
>>>>> Based on the std, anything that is unknown is an EH. In the
>>>>> context of RFC8200/RFC2460, there's only:
>>>>>
>>>>> * Known EHs
>>>>> * Known ULP
>>>>> * Unknown EHs
>>>>>
>>>> Yes, that's what the text says but I wish we'd fixed it in 8200
>>>> to acknowledge that there is a 4th case (Unknown ULP) and that
>>>> it cannot be distinguished from the 3rd case. Acknowledging
>>>> that is much better than ignoring it. I'm happy with Ole's
>>>> suggestion that this (and the resulting ICMP 1 behaviour) should
>>>> be mentioned in 6434bis - as a clarification, not a new
>>>> invention.

Actually, RFC 8200 is carefully worded, and the three cases it
discusses are:

* Known EHs
* Known ULP
* Unknown Next Header value

That last bullet includes both unknown EHs and unknown ULPs.
RFC 8200 says to process both in the same way.

That being said, this point is easily missed (witness this discussion
and earlier ones on the topic). So a clarification would be useful.

>>> This seems a reasonable approach to me.  Would you like to
>>> propose text, Brian?
>>
>> After this:
>>
>> 5.1.  Internet Protocol Version 6 - RFC 8200
>>
>>   The Internet Protocol Version 6 is specified in [RFC8200].  This
>>   specification MUST be supported.
>>
>>   Any unrecognized extension headers or options MUST be processed
>>   as described in RFC 8200.
>>
>> insert something like:
>>
>>   Note that it is impossible for a node to distinguish between an
>>   unrecognized extension header and an unrecognized upper layer
>>   protocol. Therefore, a node will behave in the same way for
>>   either of these cases, in particular by returning an ICMP
>>   Parameter Problem message with code 1 ("unrecognized Next Header
>>   type encountered") even for an unrecognized upper layer
>>   protocol.
>
> This is the text TimW will present in 6man; it seems fine to me,
> and hopefully we=E2=80=99ll have consensus.

I am fine with this text.

Mike Heard


From nobody Sat Nov 18 11:40:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EF1126B6E for ; Sat, 18 Nov 2017 11:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPAZdverlpCL for ; Sat, 18 Nov 2017 11:40:26 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016A51200FC for ; Sat, 18 Nov 2017 11:40:26 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id t69so4355228pfg.4 for ; Sat, 18 Nov 2017 11:40:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Vbo3+NSjxJoUdjRuhZvIqCsoZ8W73jwJRAD9jWeQnmU=; b=mNjc51j+XNgm1djilvpH6iYUBDiWHD/Gv/yaGq1mA70NFCZ5kzX3sYE2DKNZHSsw6o wp5dXfC49qMDu4LDXzLiLwUGgR0Yo1Z3OZLgmgg6fHEWPIgYkI9rQHEMUg+TcUnMKScW V/fa3CMJN6Wl6FvvWTYDH/YeFB28xTqo46MZyeFVrTc8khSgliW9fRW2My3kVhdPuqrI 2VI2bfGRKe/8czzo++lWmOOxVMQEuWr3P94tJoQG8TlklVxnnQccx1K6TzDpl8zki6CG jQZhWdxJv7yyE4UwBnA1389s/p5ZCrGMU9dTXNuhvwFrxp5CckZ/15dl/drLJTIwFb4o xjTg==
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=Vbo3+NSjxJoUdjRuhZvIqCsoZ8W73jwJRAD9jWeQnmU=; b=SYB1T9eKkqJgVT0r90NSyZyOB0ANcYWgFxWGsNK2NiiHRTSBBm4Tth0aJoTpal8PTb 24cYOTqcNASCSuWEGsLeypbivD8oiGXtBkESMYnkfNVt4bJZLi1mweLfyGw5QXxHz7Rr 170s+U0hJB5hW9kMeMPUpOC/+fPO1Xru9wERVdh6wFUYsNXQvMGLVHMmiVGC9XlAzSsG MQRAcb1k++w8ZmIc2yMNhwTXff44D1QvsePwhHVFrepMIyWkSOiP4YrbS1iJvRywYlTt HtB+0A9OS8kMrnClMHHFUdBe0XNbQJGAEMnNbnVMXyJpaePty85dCvfvPwMFQxVZHU3C HaRA==
X-Gm-Message-State: AJaThX5GAed2W8RuYgdd6M8h/Ghw5dpO292T9J2wpyism4/ELF9j6MSm 54XzMkUiLAKZkkin2yeQaqAnbQ==
X-Google-Smtp-Source: AGs4zMY11RGsuY1CBXmgBgOJNfAhs/eQPAAyQviN4KLpXdxsK6htLPrZDjkGGDvwd64NlaVhYtoaqQ==
X-Received: by 10.101.81.10 with SMTP id f10mr8842308pgq.148.1511034025329; Sat, 18 Nov 2017 11:40:25 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id q16sm11623903pgq.79.2017.11.18.11.40.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Nov 2017 11:40:23 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Jen Linkova 
Cc: 6man WG , Mark Andrews 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>
Date: Sun, 19 Nov 2017 08:40:18 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 19:40:27 -0000

On 18/11/2017 22:22, Jen Linkova wrote:
> On Thu, Nov 16, 2017 at 6:07 AM, james woodyatt  wrote:
>> IMHO the optimal solution is:
>> - the network SHOULD provide a host with NAT64 prefix information in RA;
>>
>>
>> Disagree. If the network has NAT64, then it should deploy RFC 7225.
> 
> Even if does not deploy it for NAT44? Do we really want to make NAT64
> deployments more complicated than
> just replacing NAT44 with NAT64? ;)

IMHO, no. Also, I don't believe that "should deploy RFC 7225" is
documented anywhere as a normative requirement.

To be clear: I used ietf-nat64 all week, and all the things that didn't work
are not an issue on a dual-stack network. From the host's point of view,
dual-stack is definitively superior, IMNSHO, and nothing is going to
change that. NAT64 is second-best. It may appear to be cheaper for some
operators in some scenarios, that's all. 

    Brian


From nobody Sat Nov 18 11:59:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B97126D85 for ; Sat, 18 Nov 2017 11:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCVtYAuYAnQk for ; Sat, 18 Nov 2017 11:59:28 -0800 (PST)
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 8661F1200FC for ; Sat, 18 Nov 2017 11:59:28 -0800 (PST)
Received: by mail-pf0-x234.google.com with SMTP id b6so4361930pff.10 for ; Sat, 18 Nov 2017 11:59:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qLHRsn9tbwEz3fb0R+2odZyJSVbkYAHbS2oRta1IaHc=; b=NF2Hdrn9lMFe+K3/Ux4Vj44Nd9Fd9yt2Og+xzP9NA6Y8goxNpdM0K8J4uR9zVMcAEg Kp0y0ubfNSOWEDl+ONkRLO2euhaHM3Ybo8/EnPIdwZVLaxMFIsw8Mr82j3LS9F5k+O8j XVnJ5eNznia4FMHOIGslBV/U5LUlDIO5xE6wjZBuc1uxdzmQfoSLLPg/tMesG6dLHvhx uev0jJZQyGcLK4QaTr6MTWivX3/s1xW+jKNiImdku8zGyHjIv8Gz5ubc9zbolzsXxsMN tIXD54ndZ5dgycsYxdIjB6OMdtm+W0WaJKsuA1ETG25EtA+U4nkblOcPexQzS8WJZ/ao sFJQ==
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=qLHRsn9tbwEz3fb0R+2odZyJSVbkYAHbS2oRta1IaHc=; b=P6xGBO1x1EgF9cMH2Fwilu0td3z9HRMzWYX6GZdQzuSyxTu6QBL7SXQ5OsDrPKMUcW rhTUUYcXjOVcPdw/30G0Hf6s/pFDFRKM5xLEto7FAw+Gq6aM9xbYeUMw0ZmamhbTUQid XUN0nPK1oQZPOsEHgSplX9UGyACUgN7+/pGHyWjBxcbMLZPEXAd2olMsajjNQ+WLNUJv chtuBL0Y2osiLiasdXTWQUkWACjJMDQLp5E2uh0nuvE2zsGG5io4W/HK0bgi49JCUgEF YFDwovPbY1BDqWvCbzZ0aIeYOT5rv5GZA7G39GQlP1tNXe3M2i4MSkvIUm/jQKRrpDGT LlmA==
X-Gm-Message-State: AJaThX7tW10xNtke66hFO/qNl7Wq7yJLB7CnHh55TUWapFI1VdzN42aH LgiLi4W/xNN8H+qMCtzzKyCvPg==
X-Google-Smtp-Source: AGs4zMY+Qnxl+pCrqsPGahnSLkNHcNQEAFpADc0SIH4XOGX9yjk0EuPImPFyMnEmAz+xisUXBVKsbg==
X-Received: by 10.98.234.9 with SMTP id t9mr6164607pfh.92.1511035167681; Sat, 18 Nov 2017 11:59:27 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v28sm12326683pfl.118.2017.11.18.11.59.25 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Nov 2017 11:59:26 -0800 (PST)
Subject: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: ipv6@ietf.org
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>
Date: Sun, 19 Nov 2017 08:59:22 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 19:59:30 -0000

Regards
   Brian Carpenter



On 19/11/2017 03:39, Jen Linkova wrote:
> Hi Bob,
> 
> To be honest I'm not convinced that there is a real problem to be solved..
> The draft says
> 
> 'A mechanism is needed  to inform hosts that there is no IPv4 support
> and that they should turn off IPv4.'
> and it would be great to have more detailed problem statement IMHO...

Indeed. If there is no serious problem, don't fix. What I seemed to hear
in Singapore was that people weren't happy with just ignoring the small
amount of residual IPv4 traffic on ietf-nat64 (about 1% in the measurement
by Bob Hinden). However, from what I saw, most of it is layer 2 broadcast
traffic, which is more of a burden for the infrastructure. We need to decide
whether we care.

(As to whether this belongs in 6man or sunset4, that's a secondary question.
As for the other comments on this thread, I am too jet lagged to respond
right now... later.)

     Brian

> 
> It looks to me that when you are saying 'there is no IPv4 support on a
> link' you mean 'a router does not provide IPv4 connectivity'.  However
> it still might be
> IPv4 connectivity within the given broadcast domain and the router has
> nothing to do with it.
> 
> If the problem is 'IPv4 broadcast noise on the link' then it should be
> solved on L2 level and the network should not switch ethertype 0x0800.
> If the problem is 'all those noisy DHCPv4 requests the first-hop
> router has to drop because DHCP relay is not configured' then the
> router interface should not accept IPv4 packets at all, problem
> solved.
> 
> Also it's not clear what a host is supposed to do if it'd been
> receiving RAs with that flag set 0 and at some point subsequent RAs
> started to arrive with that bit set to 1...
> Shall the host stop all IPv4 operations attempts? Basically how that
> information could be updated?
> 
> 
> On Fri, Nov 17, 2017 at 5:42 PM, Bob Hinden  wrote:
>> Hi,
>>
>> Brian and I took a cut a defining an IPv4 Availability Flag for IPv6 ND
>> Router Advertisements.  From the Introduction:
>>
>>    Hosts that support IPv4 and IPv6, usually called dual stack hosts,
>>    need to work on IPv6 only networks.  That is, a link where there are
>>    no IPv4 routers and/or IPv4 services.  Monitoring of IPv6-only
>>    networks, for example at the IETF 100 meeting in Singapore, shows
>>    that current dual stack hosts will create local auto-configured IPv4
>>    addresses and attempt to reach IPv4 services.  A mechanism is needed
>>    to inform hosts that there is no IPv4 support and that they should
>>    turn off IPv4.
>>
>>    Because there is no IPv4 support on these links, the only way to
>>    notify the dual stack hosts on the link is to use an IPv6 mechanism.
>>    An active notification will be much more robust than attempting to
>>    deduce this state by the lack of IPv4 responses or traffic.
>>
>>    IPv4-only hosts, and dual-stack hosts that do not recognize the new
>>    flag, will continue to attempt IPv4 operations, in particular IPv4
>>    discovery protocols typically sent as link-layer broadcasts.  This
>>    legacy traffic cannot be prevented by any IPv6 mechanism.  The value
>>    of the new flag is limited to dual-stack hosts that recognize it.
>>
>> We were originally thinking it would be an April 1 submission, but after
>> reading the discussion on the IPv6 list, we decided it makes sense as a real
>> submission :-)
>>
>> Please review and comment.
>>
>> Thanks,
>> Bob and Brian
>>
>>
>> Begin forwarded message:
>>
>> From: internet-drafts@ietf.org
>> Subject: New Version Notification for draft-hinden-ipv4flag-00.txt
>> Date: November 17, 2017 at 2:36:31 PM GMT+8
>> To: "Robert M. Hinden" , "Robert Hinden"
>> , "Brian Carpenter" 
>>
>>
>> A new version of I-D, draft-hinden-ipv4flag-00.txt
>> has been successfully submitted by Robert M. Hinden and posted to the
>> IETF repository.
>>
>> Name: draft-hinden-ipv4flag
>> Revision: 00
>> Title: IPv6 Router Advertisement IPv4 Availability Flag
>> Document date: 2017-11-17
>> Group: Individual Submission
>> Pages: 5
>> URL:
>> https://www.ietf.org/internet-drafts/draft-hinden-ipv4flag-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-hinden-ipv4flag/
>> Htmlized:       https://tools.ietf.org/html/draft-hinden-ipv4flag-00
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-hinden-ipv4flag-00
>>
>>
>> Abstract:
>>   This document specifies a Router Advertisement Flag to indicate that
>>   there is no IPv4 service on the advertising router.  This document
>>   updates RFC5175.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> 
> 


From nobody Sat Nov 18 12:25:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04374124C27 for ; Sat, 18 Nov 2017 12:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvO4uqZWn2lo for ; Sat, 18 Nov 2017 12:25:36 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3E11200FC for ; Sat, 18 Nov 2017 12:25:36 -0800 (PST)
Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx1.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eG9gD-0004mi-II for ipv6@ietf.org; Sat, 18 Nov 2017 21:25:34 +0100
Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eG9gA-0003xn-Ad for ipv6@ietf.org; Sat, 18 Nov 2017 15:25:30 -0500
Received: (qmail 2580 invoked from network); 18 Nov 2017 20:25:28 -0000
Received: from unknown (HELO [192.168.100.66]) (Authenticated-user:_huitema@huitema.net@[80.13.34.254]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Nov 2017 20:25:28 -0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Christian Huitema 
X-Mailer: iPhone Mail (15A432)
In-Reply-To: <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>
Date: Sat, 18 Nov 2017 21:25:18 +0100
Cc: ipv6@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <19B39788-CEC6-478A-A303-7F42904533DF@huitema.net>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>
To: Brian E Carpenter 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
X-Originating-IP: 168.144.250.245
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5snUWQNcinYl+CA90gVnPyUXv9krsgRhBn0ayn6qsUc7YAgODqM07LCG aCgxVhZftbgNzB/4Jkrw1eDLcif59fv4UJdSTt3DQ8ZQIEoDOhMzB98yDTitFWvbHwz9vKZpm3I5 mq5AFk9iXeoOoZGPBgSZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyZFjIToX6GLbbHCBsyyfoCLFQwbgMCItJaYYOhQRv6/ UGCCdcO9rYg2M7/KQ/lbg5vh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GtlU9Sx4c4OycrwO9wG8u65nHEeB4hpRrmo/duzUUp/Jj EBKbJAt4fJDFRcLYgGwkesqyLhgq8qU3+sLgGjd2QXLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+I5H9kml+5WbFWXP46fIup4j2lB9TLiDMfXuvSrucRXqq613YX/JpkaqfAljBKlD3psib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 20:25:38 -0000

...
>=20
> Indeed. If there is no serious problem, don't fix. What I seemed to hear
> in Singapore was that people weren't happy with just ignoring the small
> amount of residual IPv4 traffic on ietf-nat64 (about 1% in the measurement=

> by Bob Hinden). However, from what I saw, most of it is layer 2 broadcast
> traffic, which is more of a burden for the infrastructure. We need to deci=
de
> whether we care.

If people really care, they should just program the local routers and switch=
es to block the IPv4 related multicast traffic. That will be much more direc=
t than a bit in some RA.



>=20
> (As to whether this belongs in 6man or sunset4, that's a secondary questio=
n.
> As for the other comments on this thread, I am too jet lagged to respond
> right now... later.)

How about a transition rule for dual stack implementations? If there is IPv6=
 connectivity, don=E2=80=99t bother trying to establish IPv4? Maybe qualify t=
hat rule with availability of a 6to4 prefix?

Yes, looks for something sunset4 should work on, if sunset4 is actually aliv=
e.

=E2=80=94 Christian Huitema=20=


From nobody Sat Nov 18 12:39:03 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE061124C27 for ; Sat, 18 Nov 2017 12:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb1oCKP4geJ2 for ; Sat, 18 Nov 2017 12:39:00 -0800 (PST)
Received: from patsy.thehobsons.co.uk (ruthandcrusoe.plus.com [81.174.150.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECD01200FC for ; Sat, 18 Nov 2017 12:39:00 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from simons-macbookpro.lan (unknown [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id A45AC1BC37 for ; Sat, 18 Nov 2017 20:38:11 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
From: Simon Hobson 
In-Reply-To: <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>
Date: Sat, 18 Nov 2017 20:37:59 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>
To: ipv6@ietf.org
X-Mailer: Apple Mail (2.1510)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 20:39:02 -0000

Brian E Carpenter  wrote:

> Indeed. If there is no serious problem, don't fix. What I seemed to =
hear
> in Singapore was that people weren't happy with just ignoring the =
small
> amount of residual IPv4 traffic on ietf-nat64 (about 1% in the =
measurement
> by Bob Hinden). However, from what I saw, most of it is layer 2 =
broadcast
> traffic, which is more of a burden for the infrastructure. We need to =
decide
> whether we care.

On that basis, isn't the simplest and most compatible (in that it =
doesn't need any systems to be updated to support it*) to configure =
filters in the infrastructure as already suggested ?

> On 19/11/2017 03:39, Jen Linkova wrote:
>> If the problem is 'IPv4 broadcast noise on the link' then it should =
be
>> solved on L2 level and the network should not switch ethertype =
0x0800.
>> If the problem is 'all those noisy DHCPv4 requests the first-hop
>> router has to drop because DHCP relay is not configured' then the
>> router interface should not accept IPv4 packets at all, problem
>> solved.


* The only requirement is that the infrastructure (APs, switches, =
routers) have the facility. And all this is in the hands of the network =
operator regardless of the nature of the clients connecting though it.=


From nobody Sat Nov 18 14:07:10 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01AF1243FE for ; Sat, 18 Nov 2017 14:07:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 o7CP_AJtXP9L for ; Sat, 18 Nov 2017 14:07:07 -0800 (PST)
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 D045A1200B9 for ; Sat, 18 Nov 2017 14:07:06 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 1816D5F5 for ; Sat, 18 Nov 2017 22:07:06 +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 ljIXthkBV3DB for ; Sat, 18 Nov 2017 16:07:05 -0600 (CST)
Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 78249239 for ; Sat, 18 Nov 2017 16:07:05 -0600 (CST)
Received: by mail-lf0-f70.google.com with SMTP id g35so1293967lfi.0 for ; Sat, 18 Nov 2017 14:07:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sycw35sYF2O303ESTNcz96zRB6unjGCfbwzQ6yMV/js=; b=BvnkwBkQS2F1pn2DmGbvy5iNAwIiMKxi0fxeDXk+Q9Ma/4+xRzqbVbA6/LfF8rZhCe 9VvhcvmKVtCCzuo1AU0ew7717jGs29XuhHhjI2rYYw/4YiQ9Xq9uaNSVG0QnovdDV/ZZ xpXXMlz4E7YVwKO1Y9zQZTpeOkK8jZ9l42QgABVwiv3xNJbYaqZY8Jx+4lAXaTkeCgV5 MdYuDStEdBuLzF7GAELpoxQFmwR+tBAw90/UlSIDy1zCLykIKZHMfW/FR8bJvyAr+6y9 6FhuscIN5ks4HNuwhnR7BUTJMCb+zkwBnFrz6vT6iyTfDW2t/7RzW3rRI5XvuBSUyS5X 46yw==
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=sycw35sYF2O303ESTNcz96zRB6unjGCfbwzQ6yMV/js=; b=boUdhQNJ1tkcRFQwJ/CZ7gS2RXsfm2pZ7kHbQSHDB+3w7YLJ0Bn2ffzNXw/uM9nufd Qa6jVpK4qXN0Y1l/+Xfg7BvoJf966SlklW0p8ReZNG3iHwKMFsMfXdtsQNRrdJnACmW1 qW80o+MNIUZ0wwXG6Hqs0GR8wQQFy/jLItPpWJpqPgo745gyTY4UDJ+VUHtN+S/ta9vH 2BiP+YFtn34O6jQ9AchqnOO4zzsTkuTkI8HobiyFDSbEYF4eSvXtE/xIvxJydK0USbiI B94zxDmX3GLtq+nyXVUnoE0Y2n0MutUa2tOw8kuvjWrVsvqZsrcWPDl0iZOk4PwiAQNx 1NPg==
X-Gm-Message-State: AJaThX4F/5CdrSSYn6quXFKzh61IDD+cmX1HkZklOUObqCTmFdihg/g2 bFAz+TXLyEi20S5dlEz2Xx6vV1H3fZx/tl9+9VEIhZ96POu3HvWTinM0s7sMSMPMBXhe9oeRfJm qly8SUKxTBHTSCHTGkmOorVEL
X-Received: by 10.46.20.83 with SMTP id 19mr2626669lju.23.1511042823925; Sat, 18 Nov 2017 14:07:03 -0800 (PST)
X-Google-Smtp-Source: AGs4zMYS4YvHCJLZbfiz75GrCC676zuH6o9Vjg8dDGzW4123QnJIqSGJfbsp7N5uBiGC+BAGCaBqn6F8xpIqha0Gt8c=
X-Received: by 10.46.20.83 with SMTP id 19mr2626663lju.23.1511042823639; Sat, 18 Nov 2017 14:07:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Sat, 18 Nov 2017 14:07:03 -0800 (PST)
In-Reply-To: <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>
From: David Farmer 
Date: Sat, 18 Nov 2017 16:07:03 -0600
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Brian E Carpenter 
Cc: 6man WG 
Content-Type: multipart/alternative; boundary="f403045fb998be6b90055e491201"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Nov 2017 22:07:09 -0000

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

On Sat, Nov 18, 2017 at 1:59 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

>
> Regards
>    Brian Carpenter
>
> On 19/11/2017 03:39, Jen Linkova wrote:
> > Hi Bob,
> >
> > To be honest I'm not convinced that there is a real problem to be
> solved..
> > The draft says
> >
> > 'A mechanism is needed  to inform hosts that there is no IPv4 support
> > and that they should turn off IPv4.'
> > and it would be great to have more detailed problem statement IMHO...
>
> Indeed. If there is no serious problem, don't fix. What I seemed to hear
> in Singapore was that people weren't happy with just ignoring the small
> amount of residual IPv4 traffic on ietf-nat64 (about 1% in the measurement
> by Bob Hinden). However, from what I saw, most of it is layer 2 broadcast
> traffic, which is more of a burden for the infrastructure. We need to
> decide
> whether we care.
>
> (As to whether this belongs in 6man or sunset4, that's a secondary
> question.
> As for the other comments on this thread, I am too jet lagged to respond
> right now... later.)
>
>      Brian
>

Here is some analysis of the issues as I see them, hopefully this can help
lead us toward a problem statement;

I believe there are two separate issues here;

1. Security exposure; the inverse of the problems discussed in RFC7123,
basically malicious or accidental IPv4 service.
2. Residual IPv4 traffic, especially broadcast traffic; DHCP solicits,
IPv4-LL, ARP, service discovery, etc...

There are several solutions available already;

A. Filter Ethertypes 0x0800 and 0x806 altogether
B. Rogue DHCP server filtering or DHCP snooping
C. Proxy ARP
D. Service Discovery Proxy or Filtering

How much of an actual problem the issues are and the efficacy of solutions
depends on the type of network technology and the environment its used in;

For wired networks, the residual IPv4 traffic, even the fact that it's
mostly broadcast, isn't a significant issue.  The primary problem in here
is the security exposure, and solution B is usually sufficient protection,
but if that isn't, solution A will totally eliminate this risk.

For WiFi networks it's a little more complicate; low density WiFi
environments are similar to wired networks, the primary issue being the
security exposure, with the same solutions, discussed above. However, there
is an additional secondary issue, the residual IPv4 broadcast traffic could
unnecessarily impact other devices, especially battery powered devices.
Frequently, at least in enterprise WiFi networks, solutions C and D are
implemented to reduce the impact of IPv4 broadcast traffic in operational
WiFi networks, they will have the same effect on the residual IPv4
broadcast traffic in this case.  But, again solution A implemented within
the WiFi network will totally eliminate both the security exposure and the
impact of broadcast traffic on other devices.

However, the residual IPv4 traffic still consumes radio airtime, even if
the WiFi network discards the traffic. In very high dentistry and therefore
typically congested WiFi environments this unnecessary traffic only
increase the over-the-air congestion. Furthermore, broadcast traffic in a
WiFi networks consume more airtime that comparable unicast traffic (worst
case as much as 300 times, but 10-50 times is very typical), increasing the
impact of the residual IPv4 traffic that is mostly broadcast. Only a
solution that keep hosts from generating the residual IPv4 traffic in the
first place can help reduce over-the-air congestion in these environments.

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>
===============================================

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




On Sat, Nov 18, 2017 at 1:59 PM, Brian E Carpenter &l=
t;brian.e.=
carpenter@gmail.com> wrote:


Regards

=C2=A0 =C2=A0Brian Carpenter


On 19/11/2017 03:39, Jen Linkova wrote:

> Hi Bob,

>

> To be honest I'm not convinced that there is a real problem to be =
solved..

> The draft says

>

> 'A mechanism is needed=C2=A0 to inform hosts that there is no IPv4=
 support

> and that they should turn off IPv4.'

> and it would be great to have more detailed problem statement IMHO...<=
br>


Indeed. If there is no serious problem, don't fix. What I seemed to hea=
r

in Singapore was that people weren't happy with just ignoring the small=


amount of residual IPv4 traffic on ietf-nat64 (about 1% in the measurement<=
br>
by Bob Hinden). However, from what I saw, most of it is layer 2 broadcast
traffic, which is more of a burden for the infrastructure. We need to decid=
e

whether we care.



(As to whether this belongs in 6man or sunset4, that's a secondary ques=
tion.

As for the other comments on this thread, I am too jet lagged to respond
right now... later.)



=C2=A0 =C2=A0 =C2=A0Brian

Here is some =
analysis of the issues as I see them, hopefully this can help lead us towar=
d a problem statement;

I believe there are tw=
o separate issues here;=C2=A0

1. Security exposure=
; the inverse of the problems discussed in RFC7123, basically malicious or =
accidental IPv4 service.=C2=A0
2. Residual IPv4 traffic, especial=
ly broadcast traffic; DHCP solicits, IPv4-LL, ARP, service discovery, etc..=
.

There are several solutions available already;

A. Filter Ethertypes 0x0800 and 0x806 altogether
B. Rogue DHCP server filtering or DHCP snooping
C. Proxy =
ARP=C2=A0
D. Service Discovery Proxy or Filtering

<=
/div>
How much of an actual problem the issues are and the efficacy of =
solutions depends on the type of network technology and the environment its=
 used in;

For wired networks, the residual IPv4 tr=
affic, even the fact that it's mostly broadcast, isn't a significan=
t issue.=C2=A0 The primary problem in here is the security exposure, and so=
lution B is usually sufficient protection, but if that isn't, solution =
A will totally eliminate this risk.

For WiFi netwo=
rks it's a little more complicate; low density WiFi environments are si=
milar to wired networks, the primary issue being the security exposure, wit=
h the same solutions, discussed above. However, there is an additional seco=
ndary issue, the residual IPv4 broadcast traffic could unnecessarily impact=
 other devices, especially battery powered devices. Frequently, at least in=
 enterprise WiFi networks, solutions C and D are implemented to reduce the =
impact of IPv4 broadcast traffic in operational WiFi networks, they will ha=
ve the same effect on the residual IPv4 broadcast traffic in this case.=C2=
=A0 But, again solution A implemented within the WiFi network will totally =
eliminate both the security exposure and the impact of broadcast traffic on=
 other devices.=C2=A0 =C2=A0=C2=A0

However, the re=
sidual IPv4 traffic still consumes radio airtime, even if the WiFi network =
discards the traffic. In very high dentistry and therefore typically conges=
ted WiFi environments this unnecessary traffic only increase the over-the-a=
ir congestion. Furthermore, broadcast traffic in a WiFi networks consume mo=
re airtime that comparable unicast traffic (worst case as much as 300 times=
, but 10-50 times is very typical), increasing the impact of the residual I=
Pv4 traffic that is=C2=A0mostly broadcast. Only a solution that keep hosts =
from generating the residual IPv4 traffic in the first place can help reduc=
e over-the-air congestion in these environments.=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 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 




--f403045fb998be6b90055e491201--


From nobody Sat Nov 18 17:03:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CA4126CE8 for ; Sat, 18 Nov 2017 17:03:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy37AUGwBtG3 for ; Sat, 18 Nov 2017 17:03:27 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F7B126CBF for ; Sat, 18 Nov 2017 17:03:27 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 6772A2D5126; Sun, 19 Nov 2017 01:03:26 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id C0DB7200C79A4F; Sun, 19 Nov 2017 02:03:24 +0100 (CET)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_4B0BE73A-47C3-49AE-B505-7E3A087F6716"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Sun, 19 Nov 2017 02:03:23 +0100
In-Reply-To: <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>
Cc: Jen Linkova , 6man WG , Mark Andrews 
To: Brian E Carpenter 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>  <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 01:03:29 -0000

--Apple-Mail=_4B0BE73A-47C3-49AE-B505-7E3A087F6716
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Brian,

> To be clear: I used ietf-nat64 all week, and all the things that =
didn't work
> are not an issue on a dual-stack network. =46rom the host's point of =
view,
> dual-stack is definitively superior, IMNSHO, and nothing is going to
> change that. NAT64 is second-best. It may appear to be cheaper for =
some
> operators in some scenarios, that's all.

=46rom that perspective, "IPv4 only" is still best. But that's not where =
we want to be, is it?

The original transition plan was for all networks, hosts and application =
to be dual-stacked, then when that point was reached, there would be no =
more traffic on the "IPv4 Internet" and it could be turned off. We now =
know that this point is not within sight.

Dual-stack as a transition is a failure. Dual-stack is a deployment =
model where we bear the cost caused by the IPv4 laggards.

IPv6 only + NAT64 is progress. It relegates IPv4 to the edges.
We want a situation where IPv4 only services are fronted by IPv6, and =
the cost born by those operating those services.

The challenge we have in front of us is to make IPv6 only work.

Ole


--Apple-Mail=_4B0BE73A-47C3-49AE-B505-7E3A087F6716
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+/bDNdvtpYqJhC33YFAloQ2FsACgkQvtpYqJhC
33Yc3w/+JW9JRiTpVQ4DC6XXAvmQJ8y5AhvilwUqjvzxlH7tlj3neb2s7bpxcTTA
TXYAX9y+VnUtJdsWTHzXYb9ivShGrV2ZYNYXEFWiFeA5jG1dtLnvhhVAYRlSl5Oc
R2P97KjAAklxyGdf3lYx2dDZkKZkjh7upxeo/D12pFKhYS2gOxMyY5Q9KpmzgfJG
DDX+xDtnEwnOnx3swM1FqDKXCIjkNue0Vknvml9gGuPpOZcQhQo95JeNoFrMYoFT
2S2GcuZH7eI5x2IZRGYQWlt2NUsbetDrfR1GyRMxr3NkWL6tGQZj2acTauKEWGV8
qQZSaKJryECD6+VETF24rfMgvf1GzstEWyAXzzwb+4ntAOKEMH2gZWG/QwWKoFxq
qHMruD/RYpvZ2d0MzWVSmWZPgGSl0QGdWfOCWIf/fIBoI8aUUhyVSZ+yi6XsZJCp
Ar/8ggC1nkM4lbSflVJe2oRetVsYqBMYZO5zpSolbiZVMVCdyfTnT2VFxqX5RuY2
wvcylYQjTvUe80JtC/Wbs8OhAb8TTSwKoPvbYDFvztGY6D1n/tO42W2rGpJwH+8M
RVL4HhNcmdETBvEThEeqpKEHo42QeBjD75g93N3XmX1WrEjE++sKLEK55HsSx5XV
zh2MM1pMnP2CisTPnjcRm3XzaRAZJ0zxh2WYSrbE9Emeen4NaxU=
=Wfvp
-----END PGP SIGNATURE-----

--Apple-Mail=_4B0BE73A-47C3-49AE-B505-7E3A087F6716--


From nobody Sun Nov 19 01:45:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AE6120724 for ; Sun, 19 Nov 2017 01:45:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 cYTJ_BkfuiaZ for ; Sun, 19 Nov 2017 01:45:31 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF281200C1 for ; Sun, 19 Nov 2017 01:45:31 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id A5229AF; Sun, 19 Nov 2017 10:45:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511084727; bh=c+Yoh9Y0ff19BPvgK6odM0nsFB1sZ00EWZ8ADKOE0X0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WCSfxsGupRbwIlSmDCznhT6PxsrNk9sd5NxgrJlsHJfdPAMI43V1l8L8tTeN7D8j9 JK+6KCfAO5bl2sf7DMBdJCrL+eNj/TkWlbjJpBwGh0tfe6rwLbOsop64Jhkr23BkDS ViVN6xvsLb/dZpz7KbB/FpU/fg9W2ko0TSCBtlVQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8D51B9F; Sun, 19 Nov 2017 10:45:27 +0100 (CET)
Date: Sun, 19 Nov 2017 10:45:27 +0100 (CET)
From: Mikael Abrahamsson 
To: Ole Troan 
cc: 6man WG 
Subject: Re: IPv6 only host NAT64 requirements?
In-Reply-To: 
Message-ID: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>  <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 09:45:34 -0000

On Sun, 19 Nov 2017, Ole Troan wrote:

> The challenge we have in front of us is to make IPv6 only work.

When I speak to vendors about this, I get different answers. Some are 
saying "nobody will deploy IPv6 only, so why should I make changes in my 
desktop OS to support it for legacy applications?"

And I imagine any access provider will say "I can't deploy IPv6 only, 
because it'll break a lot of applications that people are using on desktop 
OSes".

So this is classic catch 22.

This was fixed on Android by throwing up hands and giving up on IPv6 only, 
and just installing CLAT on it to make sure most legacy applications just 
work.

On iOS it was fixed by doing bump-in-the-API plus mandating Apps work 
properly, and then waiting, and weeding out apps that didn't work because 
some mobile operators said "we're going to deploy this on a per-device 
type basis" after testing that these workarounds were successful.

MacOS is in-between, because applications that use the Apple APIs get 
bump-in-the-API help, but the ones that use the socket API doesn't. So 
here it's a mix of both worlds.

Windows has none of this. Linux also has none of this out of the box on 
any flavour of Linux I am aware of. This means lots of applications do not 
work.

Long tail of applications, is long.

Believing that all apps will get fixed on Windows and Linux (and MacOS) is 
for me a veeeeery long game to play. Also it's a nice idea to start 
opening tickets and trying to get them fixed, but again. Long tail is 
long.

So only practical way forward here I can see that would yield rewards in 
the next few years is for OSes to implement bump-in-the-API even for 
legacy socket API using applications, that would automatically turn on 
NAT64 traversal for legacy IPv4 applications.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Sun Nov 19 02:15:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEE61243F6 for ; Sun, 19 Nov 2017 02:15:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 TyZjT0ZzA0sb for ; Sun, 19 Nov 2017 02:15:05 -0800 (PST)
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 94A421200C1 for ; Sun, 19 Nov 2017 02:15:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511086172; x=1511690972; 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=QJ1IO4VxZAgTt8M3c6TPMrYek uOeK5gR+SkpSDY007U=; b=NOQiHK/z8TK1EadYuErQQi0dZqXVoU6cxzVjZW5cx Bhn5/+kDxI9oVSVrMJQvXuIS7Rk858sKeg7zp5axYB4q62U+GGlCFLaFZW7RdhzP I9Wmz0EFQxHqriCDtUV1JfuQseIRAxDwN1CBhdCfU6iE0SSNQJngVgSpBf50L8Ka aU=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=mjN9abYOB+GOZJSR8WyUfxIT/i7VlBQg+7oEv6BgNqvbPowrGEyCs3fUhIZe muuMy4kW82msqv3L/uOnJkj+hz4Kmf6VgyY5yE2yxsewDiLNhnbmhgxo7 wS7zKygoG2tMdpRJ6+WHJKZwGV3fGK9T5jlbissfTXe4haZzUetrl8=;
X-MDAV-Processed: mail.consulintel.es, Sun, 19 Nov 2017 11:09:31 +0100
X-Spam-Processed: mail.consulintel.es, Sun, 19 Nov 2017 11:09:30 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005629750.msg for ; Sun, 19 Nov 2017 11:09:29 +0100
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:171119:md50005629750::W+14dh1CNKJmGVhl:00009zQZ
X-Return-Path: prvs=14962de760=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Sun, 19 Nov 2017 07:50:28 +0000
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
From: JORDI PALET MARTINEZ 
To: 6man WG 
Message-ID: 
Thread-Topic: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 10:15:08 -0000

Agree with your analysis, but the problem I see is that many WiFi networks =
are very simple, even with high level of congestion, and they may not be ab=
le to apply such simple filters. Even home networks may have the same issue=
s.

One way or the other, hosts get updated frequently, but switches, APs and L=
2 infrastructure don=E2=80=99t, even CEs or small routers in many hotspots =
don=E2=80=99t get updated.

Also, IPv4-only devices are typically never updated. For example, you buy t=
oday an IP camera, and is not easy to find one which is dual-stack. Of cour=
se, in this case the problem is different, because they will not work in a =
NAT64 IPv6-only network =E2=80=A6

Because most of this traffic is created by laptops, tablets and smartphones=
 that are the ones with frequently get updated, may be the ideal solution w=
ill be something in the stack, not relaying in the router update (so not re=
laying in RA, options, etc.), that automatically detects the lack of IPv4 s=
upport (trying to avoid fake DHCP servers), so they automatically stop send=
ing any IPv4 traffic, or even using IPv4 link-local?

Regards,
Jordi
=20

-----Mensaje original-----
De: ipv6  en nombre de David Farmer 
Responder a: 
Fecha: s=C3=A1bado, 18 de noviembre de 2017, 22:07
Para: Brian E Carpenter 
CC: 6man WG 
Asunto: Re: problem statement [was Re: New Version Notification for draft-h=
inden-ipv4flag-00.txt]

   =20
   =20
    On Sat, Nov 18, 2017 at 1:59 PM, Brian E Carpenter  wrote:
   =20
   =20
    Regards
       Brian Carpenter
   =20
    On 19/11/2017 03:39, Jen Linkova wrote:
    > Hi Bob,
    >
    > To be honest I'm not convinced that there is a real problem to be sol=
ved..
    > The draft says
    >
    > 'A mechanism is needed  to inform hosts that there is no IPv4 support
    > and that they should turn off IPv4.'
    > and it would be great to have more detailed problem statement IMHO...
   =20
    Indeed. If there is no serious problem, don't fix. What I seemed to hea=
r
    in Singapore was that people weren't happy with just ignoring the small
    amount of residual IPv4 traffic on ietf-nat64 (about 1% in the measurem=
ent
    by Bob Hinden). However, from what I saw, most of it is layer 2 broadca=
st
    traffic, which is more of a burden for the infrastructure. We need to d=
ecide
    whether we care.
   =20
    (As to whether this belongs in 6man or sunset4, that's a secondary ques=
tion.
    As for the other comments on this thread, I am too jet lagged to respon=
d
    right now... later.)
   =20
         Brian
   =20
   =20
   =20
    Here is some analysis of the issues as I see them, hopefully this can h=
elp lead us toward a problem statement;
   =20
    I believe there are two separate issues here;=20
   =20
    1. Security exposure; the inverse of the problems discussed in RFC7123,=
 basically malicious or accidental IPv4 service.=20
    2. Residual IPv4 traffic, especially broadcast traffic; DHCP solicits, =
IPv4-LL, ARP, service discovery, etc...
   =20
    There are several solutions available already;
   =20
    A. Filter Ethertypes 0x0800 and 0x806 altogether
    B. Rogue DHCP server filtering or DHCP snooping
    C. Proxy ARP=20
    D. Service Discovery Proxy or Filtering
   =20
    How much of an actual problem the issues are and the efficacy of soluti=
ons depends on the type of network technology and the environment its used =
in;
   =20
    For wired networks, the residual IPv4 traffic, even the fact that it's =
mostly broadcast, isn't a significant issue.  The primary problem in here i=
s the security exposure, and solution B is usually sufficient protection, b=
ut if that isn't, solution A will totally eliminate this risk.
   =20
    For WiFi networks it's a little more complicate; low density WiFi envir=
onments are similar to wired networks, the primary issue being the security=
 exposure, with the same solutions, discussed above. However, there is an a=
dditional secondary issue, the residual IPv4 broadcast traffic could unnece=
ssarily impact other devices, especially battery powered devices. Frequentl=
y, at least in enterprise WiFi networks, solutions C and D are implemented =
to reduce the impact of IPv4 broadcast traffic in operational WiFi networks=
, they will have the same effect on the residual IPv4 broadcast traffic in =
this case.  But, again solution A implemented within the WiFi network will =
totally eliminate both the security exposure and the impact of broadcast tr=
affic on other devices.   =20
   =20
    However, the residual IPv4 traffic still consumes radio airtime, even i=
f the WiFi network discards the traffic. In very high dentistry and therefo=
re typically congested WiFi environments this unnecessary traffic only incr=
ease the over-the-air congestion. Furthermore, broadcast traffic in a WiFi =
networks consume more airtime that comparable unicast traffic (worst case a=
s much as 300 times, but 10-50 times is very typical), increasing the impac=
t of the residual IPv4 traffic that is mostly broadcast. Only a solution th=
at keep hosts from generating the residual IPv4 traffic in the first place =
can help reduce over-the-air congestion in these environments.=20
   =20
   =20
    Thanks
   =20
    --=20
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
    David Farmer               Email:farmer@umn.edu 
    Networking & Telecommunication Services
    Office of Information Technology
    University of Minnesota  =20
    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=20
   =20
   =20
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
   =20



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

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




From nobody Sun Nov 19 02:15:20 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB71812700F for ; Sun, 19 Nov 2017 02:15:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 IZqg6a3ZElAc for ; Sun, 19 Nov 2017 02:15:11 -0800 (PST)
Received: from mail.consulintel.com (mail.consulintel.com [213.0.69.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C99126DED for ; Sun, 19 Nov 2017 02:15:10 -0800 (PST)
X-MDAV-Processed: mail.consulintel.com, Sun, 19 Nov 2017 11:15:08 +0100
Received: from mail.consulintel.es by mail.consulintel.com (Cipher TLSv1:-SHA:128) (MDaemon PRO v11.0.3) with ESMTP id md50000952571.msg for ; Sun, 19 Nov 2017 11:15:07 +0100
X-Spam-Processed: mail.consulintel.com, Sun, 19 Nov 2017 11:15:07 +0100 (not processed: spam filter heuristic analysis disabled)
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Return-Path: prvs=14969faf01=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511086171; x=1511690971; 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=Uz8TBocArOnbs/FCV+p8hww6w 3GfSsARV0vT+JegIeM=; b=h9Mw656tSP5c6K3274ki6O1B6y9G5qRjRgNg+zN6p FlhmWxpQLeg39w6WRYhlNMpjUvF/wNANHDcXFEcJ1gxDsukQhV4qpSK45GSZilON lkOG7GBiY3xqED3c7GH32Qxe0OvVe14IPruKZc2qXEvGT51v7cOTxHfej5CKmfpp B4=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=EussYhahRGyk8Rjrva4Ax8XqtKSD/aQAw0TEc1agr5EiHJYQZ4Plkyv2aYIF YD2TZHjBwKdE6cvKAV0Gh0paXP0xDSPflqqtn6jmjh+QA8z6DPyFzj4Kr yqF1G5a/40WymwU/87sKVHLWCuZ1QSYjF/ICIl71Y0g76kVI0hde4I=;
X-MDAV-Processed: mail.consulintel.es, Sun, 19 Nov 2017 11:09:31 +0100
X-Spam-Processed: mail.consulintel.es, Sun, 19 Nov 2017 11:09:30 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005629749.msg for ; Sun, 19 Nov 2017 11:09:29 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:171119:md50005629749::vlV9XC7vfx4u57CR:00007+UO
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Sun, 19 Nov 2017 07:39:05 +0000
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 6man WG 
Message-ID: <6F8C95C5-5106-43AC-A888-F1B38256EA1C@consulintel.es>
Thread-Topic: IPv6 only host NAT64 requirements?
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>  <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 10:15:14 -0000

Fully agree with Ole, but not in one specific point =E2=80=A6

-> We want a situation where IPv4 only services are fronted by IPv6, and th=
e cost born by those operating those services.

I don=E2=80=99t see an easy way for people with IPv4-only services to pay f=
or the cost. If I=E2=80=99m an ISP and want to connect customers to Interne=
t, even if I deploy IPv6, if I don=E2=80=99t provide myself a NAT64 (probab=
ly together with CLAT at the CEs), my customers will go away, because I=E2=
=80=99ve no solution to =E2=80=9Ccharge=E2=80=9D the cost of my NAT64 to th=
e =E2=80=9Cbad and outdated=E2=80=9D service providers that rely only in IP=
v4 (and IPv4-only DNSSEC).

Also, if I want customers that have IPv4-only devices at home, I still need=
 to provide some sort of IPv4-as-a-service for that.

If we pretend that to happen, either we find a *real* way to make responsib=
les of the cost to the =E2=80=9Cugly=E2=80=9D content providers, or we will=
 fail again as we failed assuming that dual-stack will be deployed at the r=
ight time so we can turn-off IPv4.

Regards,
Jordi
=20

-----Mensaje original-----
De: ipv6  en nombre de Ole Troan 
Responder a: 
Fecha: domingo, 19 de noviembre de 2017, 1:03
Para: Brian E Carpenter 
CC: 6man WG , Mark Andrews 
Asunto: Re: IPv6 only host NAT64 requirements?

    Brian,
   =20
    > To be clear: I used ietf-nat64 all week, and all the things that didn=
't work
    > are not an issue on a dual-stack network. From the host's point of vi=
ew,
    > dual-stack is definitively superior, IMNSHO, and nothing is going to
    > change that. NAT64 is second-best. It may appear to be cheaper for so=
me
    > operators in some scenarios, that's all.
   =20
    From that perspective, "IPv4 only" is still best. But that's not where =
we want to be, is it?
   =20
    The original transition plan was for all networks, hosts and applicatio=
n to be dual-stacked, then when that point was reached, there would be no m=
ore traffic on the "IPv4 Internet" and it could be turned off. We now know =
that this point is not within sight.
   =20
    Dual-stack as a transition is a failure. Dual-stack is a deployment mod=
el where we bear the cost caused by the IPv4 laggards.
   =20
    IPv6 only + NAT64 is progress. It relegates IPv4 to the edges.
    We want a situation where IPv4 only services are fronted by IPv6, and t=
he cost born by those operating those services.
   =20
    The challenge we have in front of us is to make IPv6 only work.
   =20
    Ole
   =20
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
   =20



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

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





From nobody Sun Nov 19 02:53:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107B4126BFD for ; Sun, 19 Nov 2017 02:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npq-yLpO3A5Y for ; Sun, 19 Nov 2017 02:53:37 -0800 (PST)
Received: from patsy.thehobsons.co.uk (ruthandcrusoe.plus.com [81.174.150.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51AE1243F6 for ; Sun, 19 Nov 2017 02:53:37 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from simons-macbookpro.lan (unknown [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 9A6E01BC3A for ; Sun, 19 Nov 2017 10:52:49 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: IPv6 only host NAT64 requirements?
From: Simon Hobson 
In-Reply-To: 
Date: Sun, 19 Nov 2017 10:52:37 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <631A266B-A0BC-4457-A09B-3DBC3BE94BFB@thehobsons.co.uk>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>  <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>  
To: 6man WG 
X-Mailer: Apple Mail (2.1510)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 10:53:39 -0000

Mikael Abrahamsson  wrote:

> Believing that all apps will get fixed on Windows and Linux (and =
MacOS) is for me a veeeeery long game to play. Also it's a nice idea to =
start opening tickets and trying to get them fixed, but again. Long tail =
is long.

Indeed, and I think you can probably measure that in decades rather than =
years !
Simple example - Windows XP "should" be dead, but it's not. There are =
still a lot of XP machines still in use (we have one in the house) on =
the basis that "it still works, why fix it ?"
My Mum still uses an old eMac running (IIRC) OS X 10.5 - on the basis =
that she knows how to drive it, and switching her to something newer =
will take "a bit of learning time" which is hard for someone her age and =
state of forgetfulness. I do have a newer computer for her, but it's =
finding time to sit down and explain all the differences - so far in =
preparation, she's been switched from Eudora to Apple Mail so that's one =
big change dealt with.

So yes, just wishing for IPv4 to go away in a few years because =
"everything will support IPv6" is just wishful thinking. No ISP is going =
to do something that's going to break a proportion of their customers' =
setups - just the helpdesk time (explaining that it's time for an =
upgrade) would cost them a fortune.


From nobody Sun Nov 19 02:59:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936B11200CF for ; Sun, 19 Nov 2017 02:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ets_91TYLRjy for ; Sun, 19 Nov 2017 02:59:18 -0800 (PST)
Received: from patsy.thehobsons.co.uk (ruthandcrusoe.plus.com [81.174.150.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D01126B72 for ; Sun, 19 Nov 2017 02:59:12 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from simons-macbookpro.lan (unknown [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 9B3B31BC37 for ; Sun, 19 Nov 2017 10:50:13 +0000 (UTC)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
From: Simon Hobson 
In-Reply-To: 
Date: Sun, 19 Nov 2017 10:50:00 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A8CF860-375C-4EC8-84DE-D10945F9B1FC@thehobsons.co.uk>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  
To: 6man WG 
X-Mailer: Apple Mail (2.1510)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 10:59:19 -0000

JORDI PALET MARTINEZ  wrote:

> Agree with your analysis, but the problem I see is that many WiFi =
networks are very simple, even with high level of congestion, and they =
may not be able to apply such simple filters. Even home networks may =
have the same issues.

I would suggest that the sort of network (ie one aimed as very high =
user-counts) where the traffic is a real issue are also the sort of =
network running on "higher end" kit with the capability required, and =
run by people who understand the issues. For home networks, it's not =
going to be a real issue - other than in high-density situations =
(apartment blocks) where just things like 2.4GHz band congestion is =
already an issue.

> One way or the other, hosts get updated frequently

Not completely. See my post in the other thread, there's a lot of legacy =
stuff around. OK, Windows XP and WiFi in a sports stadium isn't going to =
be a significant issue, but a lot of users do not upgrade their phones =
every year or two - I'm only on my second in 2 decades ! And for older =
models, manufacturers have a tendency to simply abandon them so they =
won't get updates - for "older", this can mean "sold last month" if some =
of the anecdotes are correct.

> , but switches, APs and L2 infrastructure don=92t, even CEs or small =
routers in many hotspots don=92t get updated.

Again, I would suggest that where it matters, they'll get updated. If =
the operator sees a lot of IPv4 traffic and it's impacting on network =
performance, then they have an incentive to do something about it.

> ... that automatically detects the lack of IPv4 support (trying to =
avoid fake DHCP servers), so they automatically stop sending any IPv4 =
traffic, or even using IPv4 link-local?

How ?
How do you differentiate between a network with a missing DHCP4 server =
and one that doesn't run IPv4 at all ? If you simply assume that "no =
DHCP4 =3D=3D no IPv4" then all that automagical networking using IPv4 LL =
will break. So realistically you can only assume there's no IPv4 if =
explicitly told - which comes back to having to have a mechanism to =
tell, and update everything involved to know about it.

Probably the best that can be done by the client is to be "less =
aggressive" in trying to configure IPv4 when IPv6 is available and you =
don't seem to see IPv4 traffic from other nodes. That way, if a network =
does employ L2 filtering, nodes will reduce their IPv4 broadcast traffic =
- but it shouldn't impact anything else.
Don't forget that in the cases being discussed (high density networks), =
the network operators typically have zero control over the clients =
connecting.


From nobody Sun Nov 19 05:34:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9611127873 for ; Sun, 19 Nov 2017 05:34:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 nlgBdYLnxTcD for ; Sun, 19 Nov 2017 05:34:29 -0800 (PST)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF731270AB for ; Sun, 19 Nov 2017 05:34:29 -0800 (PST)
Received: by mail-io0-x22a.google.com with SMTP id i184so5750490ioa.0 for ; Sun, 19 Nov 2017 05:34:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9emmbXtWqCCDNZDVGc7dCjk4RTpzlnIqfreHXH3aPhk=; b=P0siFOUKGO+LH2XLOCkrAcxUWO/FlazUW1n6a+Cyh85fgW5I6UUbOBz+0nFZWtjKRg Ibo7Z0lH/UxDevqnbinrFDtt+db543vPuKMZJaab6mpHbmqnd1+3xH3uMhal2qWR+7lm sOawzGjjPtILq5jfNhWBxRpxcYByRSOlaAaEYhYYmr6jx535J/xW1EBluMIAuwEwOwCJ yy6Jh7pEOTD+RydJ8A0vuwn/UZUOuAr2xZdzgkeYpZzFceHkRNXWe0IgSbO5yw2e+35T 7SxJjzaHlXMwXqNBspM4knkmUTUtTq5/Zyej4ePQE6JlL25gQ9J+YAwnNn0tQ8VK2RMk 5+fg==
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=9emmbXtWqCCDNZDVGc7dCjk4RTpzlnIqfreHXH3aPhk=; b=l7febpO7oPGRzooyZrrqoOqi07ksy8IFEf+mLD7lS1tTGDiX6k5JDmQCbQiOwPjY4B UtE4oz3GrqMhN4hdTCLykIlm5E4o3XvPBilbFefhnq1Rsa8GHwWnuzaopHrPFFuOs3uV ptsB/7eGRvsjmbC1UzUbl0wlAqSjT6e7sPUWSuekFgmkcz1RZhda+e2SDztqjwWrixER xwPgiD7TUMYeAgF6rWpnyvu1IiChYkUpAGxJbjyw8hJXcAz01sNJvO15+9C6/cK4xZJb IOpUq57sOhf/nGCEavJ1VsvTXlmpZ1BP3yQvhqaBG18/HqxxQff6ocm3BP54VTGrLrSt txpg==
X-Gm-Message-State: AJaThX6QqSr7jLTHDdcl3h5C/wWS8aSzLSHQiJqnEnuQP3JP//qF8X1P PZpY7i0+3ihFmlKZEB9JhahqyPvhwgKLezHRtsmijw==
X-Google-Smtp-Source: AGs4zMYbrIoWMIRd99B0ZhrEfTR8CJfUjI8LwHR14WUb+CaxO99yvaBkCnfslmJOJQ4UWiRL6Ns9DugwsPbhq5eWYBM=
X-Received: by 10.107.53.42 with SMTP id c42mr10500718ioa.254.1511098468357; Sun, 19 Nov 2017 05:34:28 -0800 (PST)
MIME-Version: 1.0
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>
In-Reply-To: <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>
From: Lorenzo Colitti 
Date: Sun, 19 Nov 2017 13:34:15 +0000
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: "Brian E. Carpenter" 
Cc: IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary="001a11449a446df39c055e56079d"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 13:34:31 -0000

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

On Sun, 19 Nov 2017, 04:59 Brian E Carpenter, 
wrote:

> However, from what I saw, most of it is layer 2 broadcast
> traffic, which is more of a burden for the infrastructure. We need to
> decide
> whether we care.
>

Let's not forget about battery life. According to the numbers in RFC 7772,
on a phone even just sending DHCPv4 packets every 2 minutes could reduce
battery life by ~8% compared to a completely idle device.

>

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


On Sun, =
19 Nov 2017, 04:59 Brian E Carpenter, <brian.e.carpenter@gmail.com> wrote:
However, from what I saw, most of it is layer 2 broad=
cast

traffic, which is more of a burden for the infrastructure. We need to decid=
e

whether we care.

Let's not forget about battery life. According to the n=
umbers in RFC 7772, on a phone even just sending DHCPv4 packets every 2 min=
utes could reduce battery life by ~8% compared to a completely idle device.=





--001a11449a446df39c055e56079d--


From nobody Sun Nov 19 06:10:53 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C6D126DFB for ; Sun, 19 Nov 2017 06:10:51 -0800 (PST)
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 GR7XhiIh7xjT for ; Sun, 19 Nov 2017 06:10:50 -0800 (PST)
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 1E2C31200E5 for ; Sun, 19 Nov 2017 06:10:50 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id z125so1918433ywb.0 for ; Sun, 19 Nov 2017 06:10:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KFs/zWC4JbA61u0eHM43DQ/XmqgzssMXLYZWU2jzj00=; b=Kloyh0/mV12VhAaxe8O3RUiLbUcS61IgXyQNGJqX6aGV0Gi2QgS1y1AHdLJB5O+1Jf mm9VEe2EQpY25C/j2Igp0s232sI2gXYqMLhF3Pbb+BgIWHHYB0bCyMMHItjd4DSfsEkd XIGYg/hP7XZRdKPziUKk/0Fjq7dHClmwVpoY2sN/BWV3oQRiRc7NisJPWWnrk83/Phed 08UfKBwOXlAY0HYEcZRh9o+78g4qwyjs421ih9+p+Z2S3rCNLlV2NN0yyaolEclwOrvr 68JPg2kMcbXSfO15mWb/n3zJjWubEgTYdM2i6wTdDo9DYNkA1C1zHXZfO4VaHKXDtQki Zw2g==
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=KFs/zWC4JbA61u0eHM43DQ/XmqgzssMXLYZWU2jzj00=; b=FOrko2wz2hxhX3N3ysnn2hJyqH56z+p+qozcqj1icVL2++Kn6HtP6mlAdmwurlylkK RPAylv2DjJSuWt9857g/zGpQZ/2f5p3hfSd9QIZ5WoNJ1J3hlpJ4jdRYS8Mh2hSCXQYx OBRCvXykOGWTCi59jSa7liKZqgAMjgr4eGVES+6/FjPuzcceKbt+oRxr890zMMJrrrs+ zUGX1u0go5fbcQ5/NmUvKyrE8CFGldDW3NVVVdoq4V3+zRNfCfuui9r5uO0C9WbHFqfH 0cIXsE80+I5JMY0CNpIQqWn79ulUw3Z3Nav0Y3UKSU/J4YgCJhXLZWAJqhSMN+KEQjk8 0aEA==
X-Gm-Message-State: AJaThX5qCxHzKOe7q6RdizJH26vaA/oB47xNtYZtXtHpHNtRPw4M+7Cr GZdInl1s8V643yJoaQoMKmfe/thuQkdtqKRVgnQ=
X-Google-Smtp-Source: AGs4zMYt8WjoI1ADd+Ghqpk+w3dJeCaXq6nXubR3h2CcN1UOQfKy5iU6NaFJRFls9xeD9hLZFeK5ldgNN1e8bWaR0MM=
X-Received: by 10.129.197.72 with SMTP id o8mr7475746ywj.164.1511100649307; Sun, 19 Nov 2017 06:10:49 -0800 (PST)
MIME-Version: 1.0
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>  <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>  
In-Reply-To: 
From: Ca By 
Date: Sun, 19 Nov 2017 14:10:38 +0000
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Mikael Abrahamsson 
Cc: 6man WG , Ole Troan 
Content-Type: multipart/alternative; boundary="94eb2c1a5b7e6c0528055e568902"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 14:10:52 -0000

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

On Sun, Nov 19, 2017 at 1:45 AM Mikael Abrahamsson  wrote:

> On Sun, 19 Nov 2017, Ole Troan wrote:
>
> > The challenge we have in front of us is to make IPv6 only work.
>
> When I speak to vendors about this, I get different answers. Some are
> saying "nobody will deploy IPv6 only, so why should I make changes in my
> desktop OS to support it for legacy applications?"
>
> And I imagine any access provider will say "I can't deploy IPv6 only,
> because it'll break a lot of applications that people are using on desktop
> OSes".
>
> So this is classic catch 22.
>
> This was fixed on Android by throwing up hands and giving up on IPv6 only,
> and just installing CLAT on it to make sure most legacy applications just
> work.
>
> On iOS it was fixed by doing bump-in-the-API plus mandating Apps work
> properly, and then waiting, and weeding out apps that didn't work because
> some mobile operators said "we're going to deploy this on a per-device
> type basis" after testing that these workarounds were successful.
>
> MacOS is in-between, because applications that use the Apple APIs get
> bump-in-the-API help, but the ones that use the socket API doesn't. So
> here it's a mix of both worlds.
>
> Windows has none of this.



Windows supports 464xlat

https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/



Linux also has none of this out of the box on
> any flavour of Linux I am aware of. This means lots of applications do not
> work.
>
> Long tail of applications, is long.
>
> Believing that all apps will get fixed on Windows and Linux (and MacOS) is
> for me a veeeeery long game to play. Also it's a nice idea to start
> opening tickets and trying to get them fixed, but again. Long tail is
> long.
>
> So only practical way forward here I can see that would yield rewards in
> the next few years is for OSes to implement bump-in-the-API even for
> legacy socket API using applications, that would automatically turn on
> NAT64 traversal for legacy IPv4 applications.
>
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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



On Sun, Nov 19, 2017 =
at 1:45 AM Mikael Abrahamsson <swmik=
e@swm.pp.se> wrote:
On Sun, =
19 Nov 2017, Ole Troan wrote:



> The challenge we have in front of us is to make IPv6 only work.



When I speak to vendors about this, I get different answers. Some are

saying "nobody will deploy IPv6 only, so why should I make changes in =
my

desktop OS to support it for legacy applications?"



And I imagine any access provider will say "I can't deploy IPv6 on=
ly,

because it'll break a lot of applications that people are using on desk=
top

OSes".



So this is classic catch 22.



This was fixed on Android by throwing up hands and giving up on IPv6 only,<=
br>
and just installing CLAT on it to make sure most legacy applications just
work.



On iOS it was fixed by doing bump-in-the-API plus mandating Apps work

properly, and then waiting, and weeding out apps that didn't work becau=
se

some mobile operators said "we're going to deploy this on a per-de=
vice

type basis" after testing that these workarounds were successful.



MacOS is in-between, because applications that use the Apple APIs get

bump-in-the-API help, but the ones that use the socket API doesn't. So<=
br>
here it's a mix of both worlds.



Windows has none of this. 


Windows supports 464xlat




Linux also has none o=
f this out of the box on

any flavour of Linux I am aware of. This means lots of applications do not<=
br>
work.



Long tail of applications, is long.



Believing that all apps will get fixed on Windows and Linux (and MacOS) is<=
br>
for me a veeeeery long game to play. Also it's a nice idea to start

opening tickets and trying to get them fixed, but again. Long tail is

long.



So only practical way forward here I can see that would yield rewards in
the next few years is for OSes to implement bump-in-the-API even for

legacy socket API using applications, that would automatically turn on

NAT64 traversal for legacy IPv4 applications.



--

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



--------------------------------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/list=
info/ipv6

--------------------------------------------------------------------




--94eb2c1a5b7e6c0528055e568902--


From nobody Sun Nov 19 06:25:15 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37391126DFF for ; Sun, 19 Nov 2017 06:25:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck9HeX2zFbvz for ; Sun, 19 Nov 2017 06:25:12 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372D8124205 for ; Sun, 19 Nov 2017 06:25:11 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vAJDOunx007776 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Nov 2017 13:24:56 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <5A119443.2030108@foobar.org>
Date: Sun, 19 Nov 2017 14:25:07 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Lorenzo Colitti 
CC: "Brian E. Carpenter" , IETF IPv6 Mailing List 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 14:25:14 -0000

Lorenzo Colitti wrote:
> Let's not forget about battery life. According to the numbers in RFC
> 7772, on a phone even just sending DHCPv4 packets every 2 minutes could
> reduce battery life by ~8% compared to a completely idle device.

is there any guarantee in this situation that any other apps would not
be chattering in the background over ipv6 anyway?  From what I've seen
on tcpdump, mobile phones tend to be extraordinarily noisy, and a dhcpv4
packet every two minutes would, in any situation where I've examined
mobile phone traffic from normal handsets, be nothing more than
background noise.

Also, the whole internet isn't a mobile phone network, and what might be
relevant or appropriate on a cell network might not be in any way
relevant to another type of network.  Without meaning to state the
obvious, it would be important to take this into account when framing
any problem statement.

One relatively straightforward way of dealing with extraneous dhcpv4
packets would be to create a new dhcpv4 reply option hinting to the
requester to cease DHCPv4 requests on the interface in question, or to
slow down the request rate from one every two minutes to one every X
minutes where X is network defined.

Nick


From nobody Sun Nov 19 06:45:58 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0D01200C5 for ; Sun, 19 Nov 2017 06:45:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 uzagrWQ1EWYd for ; Sun, 19 Nov 2017 06:45:55 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2B91243FE for ; Sun, 19 Nov 2017 06:45:54 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id F3C10AF; Sun, 19 Nov 2017 15:45:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511102753; bh=+NC3aZfP8XHsfM2xkxsh7JQaLp4d2USYmE71m0VWMFg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ef0P3sPntkNYbTtnAAB5M7NS+oG+jTFHHv7piyN085FeVWFd1rsFxABMtNbZzR+kC //deRNVJFWtEHhPOidMFbM1jRI+Twn5SISdDHvAEYEQEjIvxSaUjVa88ctfs8saSkK JZbikqpLdRvIi8utf88y4/Dv2xDlnDuejXNmHNfM=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F10939F; Sun, 19 Nov 2017 15:45:52 +0100 (CET)
Date: Sun, 19 Nov 2017 15:45:52 +0100 (CET)
From: Mikael Abrahamsson 
To: Ca By 
cc: 6man WG , Ole Troan 
Subject: Re: IPv6 only host NAT64 requirements?
In-Reply-To: 
Message-ID: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>  <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 14:45:57 -0000

On Sun, 19 Nov 2017, Ca By wrote:

> Windows supports 464xlat
>
> https://blogs.technet.microsoft.com/networking/2017/07/13/core-network-stack-features-in-the-creators-update-for-windows-10/

Only on 3GPP interfaces, not on regular NICs.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Sun Nov 19 06:53:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FFC126D46 for ; Sun, 19 Nov 2017 06:53:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 VpEPjAet9VtW for ; Sun, 19 Nov 2017 06:53:49 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD310126D3F for ; Sun, 19 Nov 2017 06:53:49 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 57B38AF; Sun, 19 Nov 2017 15:53:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511103228; bh=s4iVqCQZeGpag3CWkBXMZLYmpu8DNfE1FkNmwsypmJ4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=SZ1gpthEG6wOsVoY0HMFqVMQ+6KDneNcmsEfUM4s58TNcCQDf99mZ6R9tGUcAKkVU vv0uNmh1O8KTUkmOJmZC3lXrO3/+HjgQzzjN3AqMsq17JTzfWG4ClAmL8cOSDuEdMY 72FHyckUZIDhkHA0WhLCjz+82CED3EkWx24Qraac=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 554959F; Sun, 19 Nov 2017 15:53:48 +0100 (CET)
Date: Sun, 19 Nov 2017 15:53:48 +0100 (CET)
From: Mikael Abrahamsson 
To: Lorenzo Colitti 
cc: james woodyatt , IPv6 List ,  Bob Hinden , Fernando Gont 
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
In-Reply-To: 
Message-ID: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com> <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com> <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 14:53:51 -0000

On Sat, 18 Nov 2017, Lorenzo Colitti wrote:

> Not sure how that would support IPv4 becoming available once the option 
> has been set. Also, not clear how to deal with the DOS scenario where a 
> rogue RA disables all IPv4 on the network until the end of time.

I think any "No IPv4"-flag would need to be just a hint to the hosts, and 
it would only be relevant to the router actually sending that RA.

So if your normal DHCPv4 "give up" time is X, then if this flag it set, 
shorten X to something much less?

The IPv6 specs say M=1 is a hint that tells the host that it might use 
DHCPv6 to acquire addresses if it so wants, right? Nothing says it can't 
do IA_NA request if M=0, and nothing says a host does the wrong thing if 
it doesn't do IA_NA request? I think this flag should be the same level of 
hint, and then the rest is up to the host implementation to do what it 
think is best.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Sun Nov 19 11:28:59 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B16126CF9 for ; Sun, 19 Nov 2017 11:28:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOLSDA4punby for ; Sun, 19 Nov 2017 11:28:56 -0800 (PST)
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 55E08126CF6 for ; Sun, 19 Nov 2017 11:28:55 -0800 (PST)
Received: by mail-pf0-x234.google.com with SMTP id l24so5669100pfj.6 for ; Sun, 19 Nov 2017 11:28:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bD4ukzRiyGm4J5o9W1NP0azAUUi5VRHxfj8dKADR2F0=; b=iJOTsdT5VrWOArj9VgGTOY69QE8nqvXrakvDQ62f9IEPfleBQqKZ9R7wHzNe/rm4s3 chBz11BZTkqSkHarUWMR/PEYAQO9BcZW2B07S8KUC2yE6vRvVW752vGWfPwZPVq26ekm Rv8GC1le5RejCj+8TFw7WNChl93pN+pdRYGnJKau/AHKfeK1/LwXN3Nh+trgyTSb+Hhp bgoonE471zyx0THoafn7l1qFMBQN0SAzahvpMK7Us/aYmWdtWntJWvX9u/kill7XMt/p K2L8elwSIpMiqZPjINwllNFnRKHwrUsTBYjQ/LwT1s4yHwVU9X55Cs6uwsNHNIrl0FyJ +LRQ==
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=bD4ukzRiyGm4J5o9W1NP0azAUUi5VRHxfj8dKADR2F0=; b=aiN5TVEo1hwrmUqaendrqwaQfO2tuPJwqK9+MHUFvZiu74ziC9orGt/5TZ/QYynPDD e9+IShd0xxNXD/hpo7Mkf9upRcxY7wmjEhaDSVLEZeD7hAEUmE0HU9xYM7ZaykQxlwjv sPMigLuoZUofEMcCFyBbiJJZsinie9BSoOm0IPXlooH4QWKZGTBo9guWykDOY9s78yZb iQmfGPd5U20gITU0ys0KYMKnC8nFGovcDiO75x3iJN5qgs7B3lM40Ehju2pib/f05w2b gingNLSow5SbuSVtajrmgDzreHkB1AcnB7Zq8sX5UdcSrrltuDANP5OU+SYL4IpKo2sR PgJA==
X-Gm-Message-State: AJaThX5OUOwp5ETKbFdA11KcYtOvKnRQ2YnIUwbVk+40HiU48xTkOqEj IQRxEpXYsLNFbI4cFrZWSSduKA==
X-Google-Smtp-Source: AGs4zMYuLIyljVy1EppyBdS4GbFKGq14qhBNxJbfq+tM6Pnh6tl1F0vhd+aSUwdZ8xUyw6sMSPg0hQ==
X-Received: by 10.84.235.136 with SMTP id p8mr11413026plk.263.1511119734808; Sun, 19 Nov 2017 11:28:54 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id o88sm15759734pfj.175.2017.11.19.11.28.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Nov 2017 11:28:53 -0800 (PST)
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Nick Hilliard , Lorenzo Colitti 
Cc: IETF IPv6 Mailing List 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <3d606744-a2b6-e310-da5e-39f46c21e5a7@gmail.com>
Date: Mon, 20 Nov 2017 08:28:49 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <5A119443.2030108@foobar.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 19:28:58 -0000

On 20/11/2017 03:25, Nick Hilliard wrote:
> Lorenzo Colitti wrote:
>> Let's not forget about battery life. According to the numbers in RFC
>> 7772, on a phone even just sending DHCPv4 packets every 2 minutes could
>> reduce battery life by ~8% compared to a completely idle device.
> 
> is there any guarantee in this situation that any other apps would not
> be chattering in the background over ipv6 anyway?  From what I've seen
> on tcpdump, mobile phones tend to be extraordinarily noisy, and a dhcpv4
> packet every two minutes would, in any situation where I've examined
> mobile phone traffic from normal handsets, be nothing more than
> background noise.
> 
> Also, the whole internet isn't a mobile phone network, and what might be
> relevant or appropriate on a cell network might not be in any way
> relevant to another type of network.  

My phone has been instructed to prefer WiFi when there is a choice.

> Without meaning to state the
> obvious, it would be important to take this into account when framing
> any problem statement.
> 
> One relatively straightforward way of dealing with extraneous dhcpv4
> packets would be to create a new dhcpv4 reply option hinting to the
> requester to cease DHCPv4 requests on the interface in question, or to
> slow down the request rate from one every two minutes to one every X
> minutes where X is network defined.

The hypothesis of this draft is that there is no IPv4 support, hence
nobody to send a DHCP(v4) reply.

otoh, unable to resist solutionism even in this thread, a minor update
to RFC2131 would allow battery-powered devices to slow down the
DHCPDISCOVER rate as much as they want to.

    Brian


From nobody Sun Nov 19 13:06:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74041241F5 for ; Sun, 19 Nov 2017 13:06:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O0p4-ofbpN3 for ; Sun, 19 Nov 2017 13:06:16 -0800 (PST)
Received: from patsy.thehobsons.co.uk (ruthandcrusoe.plus.com [81.174.150.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8F5124319 for ; Sun, 19 Nov 2017 13:06:16 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
Received: from simons-macbookpro.lan (unknown [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 815E21BC37 for ; Sun, 19 Nov 2017 21:05:27 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
From: Simon Hobson 
In-Reply-To: <3d606744-a2b6-e310-da5e-39f46c21e5a7@gmail.com>
Date: Sun, 19 Nov 2017 21:05:15 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <1BDF79E1-788D-42B7-AC0D-A9253C3E7130@thehobsons.co.uk>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org> <3d606744-a2b6-e310-da5e-39f46c21e5a7@gmail.com>
To: IETF IPv6 Mailing List 
X-Mailer: Apple Mail (2.1510)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 21:06:18 -0000

Brian E Carpenter  wrote:

>> Also, the whole internet isn't a mobile phone network, and what might =
be
>> relevant or appropriate on a cell network might not be in any way
>> relevant to another type of network. =20
>=20
> My phone has been instructed to prefer WiFi when there is a choice.

I think you've missed the point. Yes, there's a lot of phones around, =
but there are laptops, desktops, embedded systems, thermostats, =
doorbells/locks, ..... So it's not about whether a phone uses the mobile =
network or WiFi, it's about all those other devices that aren't mobile =
phones connected to networks that aren't mobile phone networks.



From nobody Sun Nov 19 13:19:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3623512009C for ; Sun, 19 Nov 2017 13:19:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAe_l_CnKeLG for ; Sun, 19 Nov 2017 13:19:51 -0800 (PST)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1273C12711A for ; Sun, 19 Nov 2017 13:19:51 -0800 (PST)
Received: by mail-pf0-x233.google.com with SMTP id x7so5786516pfa.1 for ; Sun, 19 Nov 2017 13:19:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8rv8HapGRyTvW6L13YrN6+bt73O5jXcFKKDVYm+gCFc=; b=K/bwZafMv81SP5cgLHoPGnvlf33+VQ4HAcHaKTXk9buU1VVYsm7XcU8GuJ8ytSH8hp hydehsa1FQL6m7vjEqcNEql+MR8dAWBWS/k/dksFT53CRGbsLtCFpZTmzQmNHdsXBVlc gF1Y11hMZINRrQhT3u7J1AWPjYBdAn7X5oHn3x66gXWcgeEZ4BTiM5t++CHwDXLpLaQ7 vEh6jlKiMBwWa9++Ma8WF3FnoTzu+WLJ8eFh1SmTUWRMzetXq5cF/f9SBmWvXeuWvhYq SXAUjlwKY+09fi9R069u1wVKK8RksBkqxf4G19+xFIXymdO3tOZ4GiKN1x5nO7KTIxSt gvGw==
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=8rv8HapGRyTvW6L13YrN6+bt73O5jXcFKKDVYm+gCFc=; b=jW4VCt/I74dMBGaVSG+3xvhnDVIOJZKti7iPVtz2f37rIXkpPd21s1I4P6NwOfClSA +tFlwHbg4EmHbR03WJqFHqBO82o06IqiyyvPSi1br9vxF/x3AgY3aRG6mUDxJa2ID79M gpCHyYKCJPfjyKuc1poUYtOrtYzlDoDdZ1Iq2vBjzIBLfgD0xZhgPlEZ8Rigpg23Q7he HZyP2i7raXxWZBCfDy0CtE4nreJoEp5aACooTuajGFFPu7vjkPQcEbPxgRGNxTWvMcUa sm+dy+ZAstI62qeliIqvNBTEWAyqG2R9bLsy6iCv+TQKRjMzlHtKdePkV8eNqvBbGjE+ Ousw==
X-Gm-Message-State: AJaThX43oynV6AyIJTkuUPx+23/vj7bsSdq2KCEgiJQp6i9T2qC1KLvq UFUAPnTOnypwbEZOicdG69H+kg==
X-Google-Smtp-Source: AGs4zMYQVpgKGjL+kvPbDzEaDA0nddriC76zOqtZ3fB6UC3oBKsV9h58zZJDwgXxktF6NlIdqFd2/A==
X-Received: by 10.101.73.74 with SMTP id q10mr4873104pgs.127.1511126390387; Sun, 19 Nov 2017 13:19:50 -0800 (PST)
Received: from ?IPv6:2406:e001:3d21:1:28cc:dc4c:9703:6781? ([2406:e001:3d21:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id h81sm16718219pfh.119.2017.11.19.13.19.48 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Nov 2017 13:19:49 -0800 (PST)
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: ipv6@ietf.org
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org> <3d606744-a2b6-e310-da5e-39f46c21e5a7@gmail.com> <1BDF79E1-788D-42B7-AC0D-A9253C3E7130@thehobsons.co.uk>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <2e6a38c3-f9e9-80ad-97b8-0bd77a5b83ab@gmail.com>
Date: Mon, 20 Nov 2017 10:19:46 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <1BDF79E1-788D-42B7-AC0D-A9253C3E7130@thehobsons.co.uk>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 21:19:52 -0000

On 20/11/2017 10:05, Simon Hobson wrote:
> Brian E Carpenter  wrote:
> 
>>> Also, the whole internet isn't a mobile phone network, and what might be
>>> relevant or appropriate on a cell network might not be in any way
>>> relevant to another type of network.  
>>
>> My phone has been instructed to prefer WiFi when there is a choice.
> 
> I think you've missed the point. Yes, there's a lot of phones around, but there are laptops, desktops, embedded systems, thermostats, doorbells/locks, ..... So it's not about whether a phone uses the mobile network or WiFi, it's about all those other devices that aren't mobile phones connected to networks that aren't mobile phone networks.

Of course. What I meant is that you can't exclude cell phones from
the problem of what happens on WiFi, regardless of how they behave
on cellular.

    Brian


From nobody Sun Nov 19 14:10:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2901205D3 for ; Sun, 19 Nov 2017 14:10:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQgZwJ8iu-bp for ; Sun, 19 Nov 2017 14:10:36 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9503212009C for ; Sun, 19 Nov 2017 14:10:36 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vAJLAKVk064896 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Nov 2017 21:10:21 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <5A120157.7060404@foobar.org>
Date: Sun, 19 Nov 2017 22:10:31 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Brian E Carpenter 
CC: IETF IPv6 Mailing List 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org> <3d606744-a2b6-e310-da5e-39f46c21e5a7@gmail.com>
In-Reply-To: <3d606744-a2b6-e310-da5e-39f46c21e5a7@gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 22:10:38 -0000

Brian E Carpenter wrote:
> The hypothesis of this draft is that there is no IPv4 support, hence
> nobody to send a DHCP(v4) reply.

It just seems operationally simpler to create a new option in dhcpv4
with simple and clear semantics than define a new flag in RA, requiring
a vendor-defined (but out-of-scope for the ID) mechanism on each host to
get each client kernel to communicate something to the dhcpv4 client to
do the same thing.  There are a lot of things to go wrong in that path,
but far fewer if you have a stub dhcpv4 server handing out "ain't no
ipv4 here" messages on an otherwise unconnected ipv4 address.

> otoh, unable to resist solutionism even in this thread, a minor update
> to RFC2131 would allow battery-powered devices to slow down the
> DHCPDISCOVER rate as much as they want to.

this would seem like an obvious and sensible optimisation.

Nick


From nobody Sun Nov 19 14:37:01 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F1612009C for ; Sun, 19 Nov 2017 14:37:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 d_DPRyw06C6s for ; Sun, 19 Nov 2017 14:36:58 -0800 (PST)
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 CBEC01200C1 for ; Sun, 19 Nov 2017 14:36:58 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 5F693964 for ; Sun, 19 Nov 2017 22:36:58 +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 uXFhLhUUAElc for ; Sun, 19 Nov 2017 16:36:58 -0600 (CST)
Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 035E182A for ; Sun, 19 Nov 2017 16:36:57 -0600 (CST)
Received: by mail-lf0-f70.google.com with SMTP id m1so1640809lfj.11 for ; Sun, 19 Nov 2017 14:36:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gol83rEOhGyXILEaMKENGdWfwoQQ/mZLC9AiU5JJqSE=; b=IP76JKHs3MXlUGJfw4OwPu/wzMxAu+rpT10k4NNMbZihBpFJ0AOCUxG1R4T15+jNQ8 3tliScNlaceDGKRgI91R7LgZOcGs7LmUMGV1j4OW5+hTbXg0kxMexXJQKbc3ofIlm3Rm vlJkniY2dB9BTtb2Vcb9wqBd5ajOxxSTYLnUl8OaDm2ArcTpmMZabo4TonXWpaniq7ya hlIm/7O05psBnaSLAROxSUMd/f0oAxhRykR6IoC3FD7+ih0kfgd1r8eeW6MttkRBCdOV qHAA+5D220HUst+kL5Uf3bLGasMU6zVXa2SIsqD9ZCxft9QGnazuzkes/Yj71MwwzZ25 ZF6w==
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=Gol83rEOhGyXILEaMKENGdWfwoQQ/mZLC9AiU5JJqSE=; b=Kjnkj7KXvK13+X15WGkAugBfjOLIeh4pa/fX+B1XDrshp7nTcOPCz+ctQ/H60rtXZ5 dskvL2ckv+p1K9AyON6iTlERZLvP1lDLiDbeteVq0NNw+HgZMc2D5HCA1ySQBXmGAf+R nhgD3Sy+APoLH8qb3TMT/G+hQHEVJhBMp+yIfqSZuqhUhfCYgCUM5+Oe3Z/BkWSTOyY0 IwioHCv82pej6QJQIF5A+t/fKXcjeyUOR6TaNGQPa8tEkahl9Hb8qlYWcd9i3N/m8SJS jipfbiHaECTqsKiiIGWPtRIyuFmHw5wN1mWtiB1dYUpLSOIjS5TnyfLkg6ROWrfV6VeF 7A9g==
X-Gm-Message-State: AJaThX44Rhgoyly+5gBZWytjZSb50hLmq4EdFHPf6EvcBx2DAHOVK4GA T4FGFmxT9n2XBc89f8Ov26/8rzNaLpj5mNaHZ+MrXF8VWlc/dXkzdvZHJ5eXfA6nu2fDtb/Ibnt yAQyVKLdgJp6uZlPh2FjvduWV
X-Received: by 10.46.23.144 with SMTP id 16mr3653280ljx.162.1511131016479; Sun, 19 Nov 2017 14:36:56 -0800 (PST)
X-Google-Smtp-Source: AGs4zMa7uHE+rYCxtQuwH8vffgJDQ4KyRxS/+f3Mk2GUhCtMYE03Lvbc/ZsAAb9b8D55ZTw1dQo41t54KViYXWrwl6g=
X-Received: by 10.46.23.144 with SMTP id 16mr3653272ljx.162.1511131016164; Sun, 19 Nov 2017 14:36:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Sun, 19 Nov 2017 14:36:55 -0800 (PST)
In-Reply-To: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  
From: David Farmer 
Date: Sun, 19 Nov 2017 16:36:55 -0600
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Jordi Palet Martinez 
Cc: 6man WG 
Content-Type: multipart/alternative; boundary="94eb2c074a206d84bf055e5d9b17"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 22:37:00 -0000

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

On Sun, Nov 19, 2017 at 1:50 AM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

> Agree with your analysis, but the problem I see is that many WiFi network=
s
> are very simple, even with high level of congestion, and they may not be
> able to apply such simple filters. Even home networks may have the same
> issues.
>
> One way or the other, hosts get updated frequently, but switches, APs and
> L2 infrastructure don=E2=80=99t, even CEs or small routers in many hotspo=
ts don=E2=80=99t
> get updated.
>
> Also, IPv4-only devices are typically never updated. For example, you buy
> today an IP camera, and is not easy to find one which is dual-stack. Of
> course, in this case the problem is different, because they will not work
> in a NAT64 IPv6-only network =E2=80=A6
>
> Because most of this traffic is created by laptops, tablets and
> smartphones that are the ones with frequently get updated, may be the ide=
al
> solution will be something in the stack, not relaying in the router updat=
e
> (so not relaying in RA, options, etc.), that automatically detects the la=
ck
> of IPv4 support (trying to avoid fake DHCP servers), so they automaticall=
y
> stop sending any IPv4 traffic, or even using IPv4 link-local?
>
> Regards,
> Jordi
>

We're not going to be able drain the swamp of unmanaged networks and
devices.  They already have serious problems with rogue DHCP server, too
many broadcasts not letting battery powered devices sleep, security
problems like crazy, etc... Changing them to IPv6-only isn't going to
fundamentally fix their problems. In fact changing them to IPv6-only, I'm
afraid will only make their problems worse, not better.  I think IPv6-only
(tuning off IPv4) is a way forward for managed networks, not for unmanaged
networks. Unfortunately, I think unmanaged networks are better off with
dual-stack and keeping classic IPv4 support.

The open question in my mind is can a managed IPv6-only network support
unmanaged BYOD devices, that is my goal for this work. If both the network
and the devices are managed you should be able to do IPv6-only right now,
the 3G/LTE guys have shown that.  The open question is can we do the same
thing on managed WiFi and BYOD, with literally no control over the devices.

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

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




On Sun, Nov 19, 2017 at 1:50 AM, JORDI PALET MARTINEZ <jordi.=
palet@consulintel.es> wrote:
Agree with your analysis, but the problem I see is tha=
t many WiFi networks are very simple, even with high level of congestion, a=
nd they may not be able to apply such simple filters. Even home networks ma=
y have the same issues.



One way or the other, hosts get updated frequently, but switches, APs and L=
2 infrastructure don=E2=80=99t, even CEs or small routers in many hotspots =
don=E2=80=99t get updated.



Also, IPv4-only devices are typically never updated. For example, you buy t=
oday an IP camera, and is not easy to find one which is dual-stack. Of cour=
se, in this case the problem is different, because they will not work in a =
NAT64 IPv6-only network =E2=80=A6



Because most of this traffic is created by laptops, tablets and smartphones=
 that are the ones with frequently get updated, may be the ideal solution w=
ill be something in the stack, not relaying in the router update (so not re=
laying in RA, options, etc.), that automatically detects the lack of IPv4 s=
upport (trying to avoid fake DHCP servers), so they automatically stop send=
ing any IPv4 traffic, or even using IPv4 link-local?



Regards,

Jordi

We're not going to=
 be able drain the swamp of unmanaged networks and devices.=C2=A0 They alre=
ady have serious problems with rogue DHCP server, too many broadcasts not l=
etting battery powered devices sleep, security problems like crazy, etc... =
Changing them to IPv6-only isn't going to fundamentally fix their probl=
ems. In fact changing them to IPv6-only, I'm afraid will only make thei=
r problems worse, not better.=C2=A0 I think IPv6-only (tuning off IPv4) is =
a way forward for managed networks, not for unmanaged networks. Unfortunate=
ly, I think unmanaged networks are better off with dual-stack and keeping c=
lassic IPv4 support.

The open question in my=
 mind is can a managed IPv6-only network support unmanaged BYOD devices, th=
at is my goal for this work. If both the network and the devices are manage=
d you should be able to do IPv6-only right now, the 3G/LTE guys have shown =
that.=C2=A0 The open question is can we do the same thing on managed WiFi a=
nd BYOD, with literally no control over the devices.=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 Email:farmer@umn.edu
=
Networking & Telecommunication Services
Office of Information Techno=
logy
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 




--94eb2c074a206d84bf055e5d9b17--


From nobody Sun Nov 19 14:47:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656151200CF for ; Sun, 19 Nov 2017 14:47:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpwt-FJa4rD5 for ; Sun, 19 Nov 2017 14:47:20 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989BD12009C for ; Sun, 19 Nov 2017 14:47:20 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C395820072 for ; Sun, 19 Nov 2017 17:49:15 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 08CBB829D1 for ; Sun, 19 Nov 2017 17:47:19 -0500 (EST)
From: Michael Richardson 
To: ipv6@ietf.org
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
In-Reply-To: <19B39788-CEC6-478A-A303-7F42904533DF@huitema.net>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com> <19B39788-CEC6-478A-A303-7F42904533DF@huitema.net>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 22:47:22 -0000

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


Christian Huitema  wrote:
    >> (As to whether this belongs in 6man or sunset4, that's a secondary q=
uestion.
    >> As for the other comments on this thread, I am too jet lagged to res=
pond
    >> right now... later.)

    > How about a transition rule for dual stack implementations? If there =
is
    > IPv6 connectivity, don=E2=80=99t bother trying to establish IPv4? May=
be qualify
    > that rule with availability of a 6to4 prefix?

    > Yes, looks for something sunset4 should work on, if sunset4 is actual=
ly alive.

I think that Erik's description got things: it's about saving joules of pow=
er
by not trying too hard to find IPv4 when it's just not around.

I think that you (Christian) bring up the question for a future where IPv4
networks are rare and IPv6 is universally deployed.   Should we make some
provision today for that eventuality so that products in the field will do
the right thing at the right time?   What exactly do we mean by that?
(Not every device is a smartphone that gets replaced every two years and
firmware upgraded a few times a year)

Jen makes the good point that if we are concerned about the infrastructure
being bothered by 0x800 packets (and perhaps more annoying arp broadcasts),
then we should just block the packets in the right places.  I think that th=
is
is sometimes good advice.  But, I'm a bit concerned when we advise blocking
things like that... how many of us have tried to run IPv6 LL traffic over an
infrastructure that decided anything !0x800 must be was evil?

=2D-
Michael Richardson , Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloSCfUACgkQgItw+93Q
3WUbnwf+PHnOe6D/6z+7ZEaaPQ1NU099LBLXsGbSf8GATChrGsCGpBnfSVtcB9xe
qIzHo2/dCgMc1goTjMv8/yIhSlwDkqV5G6PQwKW+pSe+1Zr5gmiuy8UlVUfGlPlX
8gwUoyGpxEM6H6lQeHlj7pGRk+q7T4mZvNyisQrts1Hpm/wtuZY1H7zPRraOsywX
AV1FBIV4d8T6r3XH29VBDvoEfF1YXTsDNWrXY833cm6S0Dm7OuJ6vlxIOG3OS+fH
CzIXEkFBCnsfk05p14g4f0kdBwoIkk8fwcJ31GwLTntsp1DCX4sxdIbfTBa6IUVR
wbJ13tdABSlRWug/57hBI1Zry+YpVg==
=4bJp
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Sun Nov 19 15:17:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDCDA1200B9 for ; Sun, 19 Nov 2017 15:17:22 -0800 (PST)
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 abl3VJeBAlS4 for ; Sun, 19 Nov 2017 15:17:21 -0800 (PST)
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 62EE612009C for ; Sun, 19 Nov 2017 15:17:21 -0800 (PST)
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 9B92E3B6593; Sun, 19 Nov 2017 23:17:17 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 893B216003E; Sun, 19 Nov 2017 23:17:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 79CBD16006E; Sun, 19 Nov 2017 23:17: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 gbJfRL3DRRft; Sun, 19 Nov 2017 23:17:17 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9ED9E16003E; Sun, 19 Nov 2017 23:17:16 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
From: Mark Andrews 
In-Reply-To: 
Date: Mon, 20 Nov 2017 10:17:14 +1100
Cc: Ole Troan , 6man WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <83B04565-4A62-47AE-90FA-13F9254C5A1C@isc.org>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>  <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>  
To: Mikael Abrahamsson 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 19 Nov 2017 23:17:23 -0000

> On 19 Nov 2017, at 8:45 pm, Mikael Abrahamsson  =
wrote:
>=20
> On Sun, 19 Nov 2017, Ole Troan wrote:
>=20
>> The challenge we have in front of us is to make IPv6 only work.
>=20
> When I speak to vendors about this, I get different answers. Some are =
saying "nobody will deploy IPv6 only, so why should I make changes in my =
desktop OS to support it for legacy applications?=E2=80=9D

Well as this stage you can say that there are ISP that are deploying =
IPv6-only on
the access network with DS-Lite to provide IPv4 as a service.  If you =
want your
host to be able to connect directly to such ISPs you need to add support =
to detect
that DS-Lite is in use (a IPv6 DHCP option) and bring up a IPv4 in IPv6 =
tunnel to
the ISPs B4 router.

Repeat this for other transition technologies that you are aware is in =
use.

> And I imagine any access provider will say "I can't deploy IPv6 only, =
because it'll break a lot of applications that people are using on =
desktop OSes".
>=20
> So this is classic catch 22.

You stop talk ipv6-only and start talking ipv6-only access + ipv4 as a =
service.

It=E2=80=99s only a =E2=80=9Ccatch 22=E2=80=9D because people fail to =
look at the options available.  ISPs
are going ipv6-only access + ipv4 as a service because it is easier to =
manage than
dual stack access + 44CGN.   Many ISPs deliver CPE routers that support =
DS-Lite
so the customer still see IPv4 + IPv6.

The question to host vendors is =E2=80=9Cdo you want your machines to be =
able to connect
directly to ISP=E2=80=99s that have ipv6-only access networks or not?=E2=80=
=9D  Ipv6-only access
networks are a reality.

> This was fixed on Android by throwing up hands and giving up on IPv6 =
only, and just installing CLAT on it to make sure most legacy =
applications just work.
>=20
> On iOS it was fixed by doing bump-in-the-API plus mandating Apps work =
properly, and then waiting, and weeding out apps that didn't work =
because some mobile operators said "we're going to deploy this on a =
per-device type basis" after testing that these workarounds were =
successful.
>=20
> MacOS is in-between, because applications that use the Apple APIs get =
bump-in-the-API help, but the ones that use the socket API doesn't. So =
here it's a mix of both worlds.
>=20
> Windows has none of this. Linux also has none of this out of the box =
on any flavour of Linux I am aware of. This means lots of applications =
do not work.
>=20
> Long tail of applications, is long.
>=20
> Believing that all apps will get fixed on Windows and Linux (and =
MacOS) is for me a veeeeery long game to play. Also it's a nice idea to =
start opening tickets and trying to get them fixed, but again. Long tail =
is long.
>=20
> So only practical way forward here I can see that would yield rewards =
in the next few years is for OSes to implement bump-in-the-API even for =
legacy socket API using applications, that would automatically turn on =
NAT64 traversal for legacy IPv4 applications.
>=20
> --=20
> Mikael Abrahamsson    email: swmike@swm.pp.se
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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


From nobody Sun Nov 19 17:05:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1301C120721 for ; Sun, 19 Nov 2017 17:05:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 JIT0KYP-tpVi for ; Sun, 19 Nov 2017 17:05:54 -0800 (PST)
Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45D031201F8 for ; Sun, 19 Nov 2017 17:05:54 -0800 (PST)
Received: by mail-io0-x229.google.com with SMTP id q64so1249563iof.13 for ; Sun, 19 Nov 2017 17:05:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ueLRlF1PWQP/jMwOfUTy5H42HAo1sk0YpAzqqmsFM44=; b=nNTyJhqnWjttGr9ppidiObeCwLKW1XhOq2oC6UfjdEdV0yATlZvvopZFRwFZagITCr /607ZV/egyulUwIIAp6WOsT+QkkI+qmntORSur6hpghGBR3kzwt103mLyDaag0xV3UY+ NktfLMKIZDun5s26/nY0uxcNxD7hTPvB/SOcu+6d2ypic3FfhE6IBrQec4BTzJgrK7f9 gmTX4ix+8fAmPhxYBRdqnJCL40S+cNRttZIqSDv482OLPYFFYxREhXZhpwiBcQ5ARklu xGvlF0t/wfLvXCGKIrfGrRhOTclfbEFzz6g+BfxHQaTqRIOqobbXSAIeUFclLrBQBVBP iyRA==
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=ueLRlF1PWQP/jMwOfUTy5H42HAo1sk0YpAzqqmsFM44=; b=FExbE5F+wmEM6jQkUr3FZN2NNf/oZd5Hn/jWc9Mf0hF7YG6DDw3vhDn+Bo+nITTxWI Tdza7WMJAjXjin52lAqE0LGoK2AlCCvLrAS+JcXu1roqCIQoXxRn5DPagzyTaNL161Kd eSD5wtTubh43oW83D71Iu0z5FSgp/Z1ytF1ARcHntj3UrZrpSdE4lRZsbJE6ffSPtYt2 e1ZxpVU2MjjTmtgIYuSU6395cbFYmCvq2U5wYVgzF1L7uFh/OlgB+fkZA9ql4jZgtvo+ XkPcdHGFPYZBYbJJD0BX0E1KTRHgnk28nHf/q4BIhHhmhUWsFJqKMteHPH7cpV0zUP+4 Onhg==
X-Gm-Message-State: AJaThX4qEoBgJ97MsBVhyGZalSZkYIRc1AnHhHAtsbFo0h7guam1+1vf jLOEO/C1qgj0Pn/D4KhjYxad+I9W3NWImYH9UAiOE9y06Vw=
X-Google-Smtp-Source: AGs4zMafafe10SvOrx0h4rWE/S6im3xV5kKGgSw1uRznLgj3LxqXbECOanqH2Pr5VB3i1+uloV2qsZqcKEgQejv7LJ8=
X-Received: by 10.107.134.227 with SMTP id q96mr12131326ioi.197.1511139952999;  Sun, 19 Nov 2017 17:05:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.16.155 with HTTP; Sun, 19 Nov 2017 17:05:32 -0800 (PST)
In-Reply-To: <5A119443.2030108@foobar.org>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>
From: Lorenzo Colitti 
Date: Mon, 20 Nov 2017 10:05:32 +0900
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Nick Hilliard 
Cc: "Brian E. Carpenter" , IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary="001a1145f48a1b3aa4055e5fb025"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 01:05:56 -0000

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

On Sun, Nov 19, 2017 at 11:25 PM, Nick Hilliard  wrote:

> > Let's not forget about battery life. According to the numbers in RFC
> > 7772, on a phone even just sending DHCPv4 packets every 2 minutes could
> > reduce battery life by ~8% compared to a completely idle device.
>
> is there any guarantee in this situation that any other apps would not
> be chattering in the background over ipv6 anyway?


No, but a lot of that can be dropped in firmware more cheaply. Waking up to
send a packet is more expensive.

Also, the whole internet isn't a mobile phone network, and what might be
> relevant or appropriate on a cell network might not be in any way
> relevant to another type of network.


The most relevant of which being, of course, DHCPv4 itself, which is not
used on cell networks. :-)


> One relatively straightforward way of dealing with extraneous dhcpv4
> packets would be to create a new dhcpv4 reply option hinting to the
> requester to cease DHCPv4 requests on the interface in question, or to
> slow down the request rate from one every two minutes to one every X
> minutes where X is network defined.
>

That would certainly work. Like any other DHCP option it would require
constant polling on the part of the client, but if X is high enough that
doesn't matter. Also, unlike the RA option, it makes it impossible to
change the flag with a network push, but in the long term that doesn't
matter either.

A harder problem is how to add this to DHCPv4 in a way that doesn't
negatively affect 20+ years of deployed client implementations. It can't
just be another option in the OFFER or ACK packets, since those contain the
client's IP address. I don't think it can be a new option in the NAK since
RFC 2131 says that if a client gets a NAK it should restart, and I bet
there are clients out there that restart immediately without waiting (which
would cause a loop). A new message type, with consequent modifications to
the DHCPv4 state machine? That seems pretty heavyweight.

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


On S=
un, Nov 19, 2017 at 11:25 PM, Nick Hilliard <nick@foobar.org> wrote:
> Let's not forget about battery life. According to the =
numbers in RFC

> 7772, on a phone even just sending DHCPv4 packets every 2 minutes coul=
d

> reduce battery life by ~8% compared to a completely idle device.



is there any guarantee in this situation that any other apps would n=
ot

be chattering in the background over ipv6 anyway?

No, but a lot of that can be dropped in firmware more cheaply. Wakin=
g up to send a packet is more expensive.

Also, the whole internet isn't a mo=
bile phone network, and what might be

relevant or appropriate on a cell network might not be in any way

relevant to another type of network.

The mo=
st relevant of which being, of course, DHCPv4 itself, which is not used on =
cell networks. :-)
=C2=A0
One relatively straightforward way of dealing with extraneo=
us dhcpv4

packets would be to create a new dhcpv4 reply option hinting to the

requester to cease DHCPv4 requests on the interface in question, or to

slow down the request rate from one every two minutes to one every X

minutes where X is network defined.

Tha=
t would certainly work. Like any other DHCP option it would require constan=
t polling on the part of the client, but if X is high enough that doesn'=
;t matter. Also, unlike the RA option, it makes it impossible to change the=
 flag with a network push, but in the long term that doesn't matter eit=
her.

A harder problem is how to add this to DHCPv4=
 in a way that doesn't negatively affect 20+ years of deployed client i=
mplementations. It can't just be another option in the OFFER or ACK pac=
kets, since those contain the client's IP address. I don't think it=
 can be a new option in the NAK since RFC 2131 says that if a client gets a=
 NAK it should restart, and I bet there are clients out there that restart =
immediately without waiting (which would cause a loop).=C2=A0A new message =
type, with consequent modifications to the DHCPv4 state machine? That seems=
 pretty heavyweight.


--001a1145f48a1b3aa4055e5fb025--


From nobody Sun Nov 19 17:16:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65EB1201F8 for ; Sun, 19 Nov 2017 17:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 YHUt3rD0agH1 for ; Sun, 19 Nov 2017 17:16:33 -0800 (PST)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949571201F2 for ; Sun, 19 Nov 2017 17:16:33 -0800 (PST)
Received: by mail-io0-x231.google.com with SMTP id q64so1265755iof.13 for ; Sun, 19 Nov 2017 17:16:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wVGQ+uqtOhYa1YuFWO5Z3jM4Sn4xy2ULoQJdNMMpmMc=; b=K2x1fIx6GxDZTqVnkj7RGFwQtPLLYmtWTRKhOQWiL4z/ijo0tMQLfkA9p/DI4HXVP4 GemBj9dDeagWJJdJu/AVwIE1YiBfT3xQ2S9QZr6wFtO/E32SkJaf8+tTZZ+mNvp+j6IR ztvEy8W5v7mBQN2Ge/6JGvBwEvhsUBq3c/5f1/sGHRUEyep8q/UPOmvFrRuaZw/VBVAM 9F4hoIwO00VpwWYUxUv9j3woR+0W37X8sGacHIupFtp1nE7EJ5/qbNR+Bw9AD/DAJ1U1 k5VJsFNZyHRprWa6hm5XwoOdGquM6j/0qkabPpgk0xNJ4FlVRKroYDymhdF3OwRn1qKz zi9A==
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=wVGQ+uqtOhYa1YuFWO5Z3jM4Sn4xy2ULoQJdNMMpmMc=; b=rSKJTurC+kdKHX3VHUab3TGuAHVTCjqvSoGpqt+zsO4Yg0WzMuoHkbUjejGOyaEGkP EZZoUqNAEruibbVRoQkSKQoQ5g82/T6STYRts7hp9pVoUe3CdZdKEvV5IE6RGzmw2eMM BLirwinHFOKrFPVq9T7I3CK9V5MrS3Gu1/LXcuf78t/4AHk+XWhz/8sunF50Xw3cQvOO vBrhmchIXy+mewV964h7Gotg9t+gWuYhVl33nm/rZd691UikPOYG78hIJ+nK7QciWTIV AcMZNFV6BeNPLAVjapdlBgPmpe7rWuRQmt9dz+5fTHwCELsg21Grmhtq9tuMt4QngEb3 hRZg==
X-Gm-Message-State: AJaThX7XbV3hs44LL5SsRsRaB8TtFUwb7fheHvpNrZA+4CTw0p4NX1Rp SSOq4Kze0P6DltWA2g8qsI2Hxd7bK2fNB+hP1COH3FkxJAs=
X-Google-Smtp-Source: AGs4zMYNz+IEjKWAMyaM4d4ZnR76rKOByFT+5+Z/d6Ja99lhIrjeasj1AVY3QKWkZX+k40eMeoJnvhYLSaj6+CGLcMg=
X-Received: by 10.107.16.206 with SMTP id 75mr12011707ioq.83.1511140592472; Sun, 19 Nov 2017 17:16:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.16.155 with HTTP; Sun, 19 Nov 2017 17:16:11 -0800 (PST)
In-Reply-To: <3d606744-a2b6-e310-da5e-39f46c21e5a7@gmail.com>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org> <3d606744-a2b6-e310-da5e-39f46c21e5a7@gmail.com>
From: Lorenzo Colitti 
Date: Mon, 20 Nov 2017 10:16:11 +0900
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Brian E Carpenter 
Cc: Nick Hilliard , IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary="001a113eda96390524055e5fd633"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 01:16:35 -0000

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

On Mon, Nov 20, 2017 at 4:28 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> The hypothesis of this draft is that there is no IPv4 support, hence
> nobody to send a DHCP(v4) reply.
>
> otoh, unable to resist solutionism even in this thread, a minor update
> to RFC2131 would allow battery-powered devices to slow down the
> DHCPDISCOVER rate as much as they want to.
>

I don't think the backoff schedule of current clients is dictated so much
by RFC2131 (e.g., Android already uses 120 seconds instead of 64) as it is
by operational expectations: if IPv4 appears you probably want to start
using it after a reasonable amount of time. In the absence of explicit
indication from the network, is it reasonable to back off sending
DHCPDISCOVER to once per hour? Day? Week? Year?

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


On M=
on, Nov 20, 2017 at 4:28 AM, Brian E Carpenter <brian.e.carpente=
r@gmail.com> wrote:
The hypothesis of this draft is that there is no IPv4 support, =
hence

nobody to send a DHCP(v4) reply.



otoh, unable to resist solutionism even in this thread, a minor update

to RFC2131 would allow battery-powered devices to slow down the

DHCPDISCOVER rate as much as they want to.

<=
div>I don't think the backoff schedule of current clients is dictated s=
o much by RFC2131 (e.g., Android already uses 120 seconds instead of 64)=C2=
=A0as it is by operational expectations: if IPv4 appears you probably want =
to start using it after a reasonable amount of time. In the absence of expl=
icit indication from the network, is it reasonable to back off sending DHCP=
DISCOVER to once per hour? Day? Week? Year?


--001a113eda96390524055e5fd633--


From nobody Sun Nov 19 18:45:16 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6023126D45 for ; Sun, 19 Nov 2017 18:45:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 UG6PbNxobKNA for ; Sun, 19 Nov 2017 18:45:13 -0800 (PST)
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 943E51201F2 for ; Sun, 19 Nov 2017 18:45:13 -0800 (PST)
Received: by mail-it0-x234.google.com with SMTP id r127so10269728itb.5 for ; Sun, 19 Nov 2017 18:45:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U9rZ/k7UGde/DHXXNS6e7iOLOCy79fX+bavT+dZAZBQ=; b=KS5DGxzGhC9GkNtN0AO8ZkksaAX0jCxYskmw3h6ipNtKTNxcttaxSe5SqS72ZlZxL6 YPAso50Ejx84FKz+pxo04DXfOIhB5mIwzIvVLi0vFD2Nqu2EDguo3P5858Wj2cYQcYDu 5W7MkkfD9q8pfpTxmRmjADGjckvJZfXkkFTdS7Hnmij6u7Sf9YV6lrMU5homlTaOnZtn eXftHRrZsFBsgDJcINfaaL+EhgYkD1VndaJZ/MghCeAkWWaGuFAiBiNrV4GW8zPWnWMv dBENHcbVBsaNW6xXl8EOdqU5TVskVJJ8G/bYN/0EAUJrQne2muLgQ557IkOwR8aGHkMh +7/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U9rZ/k7UGde/DHXXNS6e7iOLOCy79fX+bavT+dZAZBQ=; b=tqf0Bg20LrLV0iq7kaqs/asbhFoiMc6RdltFIWGs3wyr4Gucir2Kvv+V56u6I2hMhm R8Yu/X7fASi1NdKSPx/6ypAy3jJ0gfYfhzsgXSGtpvpEYr3H2WpCOxkyTZ98bMl39Nsn WlBzzlo5tVNC3nOTr8OExu0L6i6ZbK+Xg+8DxmwUIAbwHfzmrNxr2Mfn4+1sJtFOzxOD +nfWFmBAU4LOITq36HIg1D5OrZ6Hj8Pc7ruEIXjnqDRlNVGnCpcTf9ppnUH9nCdIObc8 gkmqghC1/rXQdckfltjyiJbqHVQ5prARYXqF1AsvN80v5eoOVTG2lTuJXv2XC7vGQ3BX QEIA==
X-Gm-Message-State: AJaThX56N8shuq/6Evv5C3JskdZv03SgmWH90D0U35dfiKFq4/czLfmy N3TpJf43PPMdZXugh3xMq+yLDIfDIoGlb361dQ/ocbvk
X-Google-Smtp-Source: AGs4zMbrpldUuKz1YMcsmiPVrR9hrjqA+/Hv3Wkd0jJsjiy36BDCFt/tRU2Om+PH0L92e5oVkNbf7+IfGJxdNwJrgGQ=
X-Received: by 10.36.34.67 with SMTP id o64mr12471977ito.106.1511145912559; Sun, 19 Nov 2017 18:45:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.16.155 with HTTP; Sun, 19 Nov 2017 18:44:51 -0800 (PST)
In-Reply-To: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  <4393db44-6427-5905-c3b4-60a546f88807@gont.com.ar> <0F60023D-9EDA-4C5D-9ABB-27BEAD294780@gmail.com> <5CFC106B-E118-4576-9D0C-F9A59289A7E1@google.com> <05978309-F55F-4E1E-BDCE-B14352FC654E@gmail.com> <79680F90-1F77-4934-9A1A-2B0DE9B43525@google.com>  
From: Lorenzo Colitti 
Date: Mon, 20 Nov 2017 11:44:51 +0900
Message-ID: 
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Fernando Gont 
Cc: james woodyatt , IPv6 List , Bob Hinden , Fernando Gont 
Content-Type: multipart/alternative; boundary="001a1143d2e452f949055e611353"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 02:45:15 -0000

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

On Sat, Nov 18, 2017 at 9:14 PM, Fernando Gont 
wrote:

> > Yep, a single flag won't work unless all routers agree on it. What about
> > an option that signified there was no IPv4 on the network? If the option
> > is sent by any of the routers on the link, then hosts would not attempt
> > IPv4 configuration.
>
> What would be the difference between encoding the info in an option vs
> in a flag?
>

A flag only has two values, 0 or 1. A boolean option can have three values:
not present, 0 or 1. The same can be achieved through two flags, of course.

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


On S=
at, Nov 18, 2017 at 9:14 PM, Fernando Gont <fgont@si6networks.com&=
gt; wrote:
> Y=
ep, a single flag won't work unless all routers agree on it. What about=


> an option that signified there was no IPv4 on the network? If the opti=
on

> is sent by any of the routers on the link, then hosts would not attemp=
t

> IPv4 configuration.



What would be the difference between encoding the info in an option =
vs

in a flag?

A flag only has two values, =
0 or 1. A boolean option can have three values: not present, 0 or 1. The sa=
me can be achieved through two flags, of course.


--001a1143d2e452f949055e611353--


From nobody Sun Nov 19 20:17:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DA1126C22 for ; Sun, 19 Nov 2017 20:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV0GGOIFPuA9 for ; Sun, 19 Nov 2017 20:17:12 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 F1EC7126579 for ; Sun, 19 Nov 2017 20:17:11 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id x68so8545256lff.0 for ; Sun, 19 Nov 2017 20:17:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kPq53zradKHuL/uTDM7IoE3T5aDOx9QVUFpqd4Bg5Gk=; b=bL81sRg7vp4eg9rL56WEEf8lgSFLjjtjnmj7wIAkHEuv7P/5SDSlP2RR6ngAXJm3DS kv4qOwmhIoTZpQ5rYg+/4e1QCxkYcYJftSGgk1TK8dJtbyxFJTCMv4RZ5UWQPTCNA1Ma 1/61eUEV+uC4do4P8PXgvBCfk0HQe+D4//VLKhEWhQgqaNbW5qv9zKrX9ijNKv+o8ye9 3PniuOk6ArYN0oSuB9Gw/VOmjx03eGCWsMOClQrua2lNJDOHsCPQsVTLrHmhlQmtr2PN GmRoW0eYXrpDeoUCXp1r+jDORcjLKyFVPn/xuDDc8Zafm1w9yjoNtvPNNec/XO/Z399v Aw6Q==
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=kPq53zradKHuL/uTDM7IoE3T5aDOx9QVUFpqd4Bg5Gk=; b=r4wESxQPhZeqJXKv8B8oIb9n4nyFHOb9GlEG/5PWF1NG7twAbDaGZO3RCB/luo97Ds nudfT4VygvN1Fbmr5QAwlC7hiGhKIR6gVydrq7FsADfxhzQHoTvjSBKCmVdalpw3L0c4 i8wmyHHYQ/ImT1XY99dpr0Y28dL4psXOv9YDdMCsJ1/sR+RTyn9IPtPS5p8dFNNrr9qI fyF5cmDQt9M8HJuG+jYGD8CGOOriDLGFJal7y/E7tmxw4/kiRd/jrsGvOfmU20idn8nB GgO9pQf8ItvvNZ3g0NxI0SbayManAPCupSb0yVz87cwrnYT92KpBLL6FljRSq0KoXn1H sgkw==
X-Gm-Message-State: AJaThX5hJRBTL9sAwAeDwzIZ6psO1KwH9FOjxWt+eF3VtqII/tROGYR8 9xf74YHZxq0bUZzP2p6WiZ6+RbKcoqXqDx7M4jwKEQ==
X-Google-Smtp-Source: AGs4zMa2D9XQzMLLy4YlqcrdDY84d+6aPwkjHsGOA3BEeh8d6K5iI22BUZNT44Me3tdjO1tGRWisP6id2Me92dCqA2k=
X-Received: by 10.46.2.17 with SMTP id 17mr4169617ljc.67.1511151430093; Sun, 19 Nov 2017 20:17:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.205.2 with HTTP; Sun, 19 Nov 2017 20:16:49 -0800 (PST)
In-Reply-To: <5A119443.2030108@foobar.org>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>
From: Jen Linkova 
Date: Mon, 20 Nov 2017 15:16:49 +1100
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Nick Hilliard 
Cc: Lorenzo Colitti , IETF IPv6 Mailing List 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 04:17:13 -0000

On Mon, Nov 20, 2017 at 1:25 AM, Nick Hilliard  wrote:
> One relatively straightforward way of dealing with extraneous dhcpv4
> packets would be to create a new dhcpv4 reply option hinting to the
> requester to cease DHCPv4 requests on the interface in question, or to
> slow down the request rate from one every two minutes to one every X
> minutes where X is network defined.

The idea of using a protocol X to tell device 'there is no protocol X
on this link' sounds very entertaining ;)
If I run a single-stack network I do not want to configure IPv4
addresses, dhcp relays etc on v6-only interfaces
and most likely I have no desire to run DHCPv4 for those segments. I
might not even allow v4 traffic on the link at all
(as it reduces the attack surface).

There are two unrelated things which could be done:
A) To protect the network from excessive amount of undesirable (v4)
traffic some actions need to be taken on the network level. Those
actions
could not be completely delegated to hosts as most likely we are
talking about large number of devices, uncontrolled, potentially
outdated etc.
However the network indeed could provide some hints to hosts in case
those hosts are willing to listen. Here comes B)
B) To improve the device performance at v6-only network, the device
can do smth to detect the lack of IPv4 on the link (either explicitly,
like the RA flag we are discussing) or implicitly (no DHCPv4 replies
-> back-off etc).


-- 
SY, Jen Linkova aka Furry


From nobody Sun Nov 19 22:35:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E651128B93 for ; Sun, 19 Nov 2017 22:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 yijryaNM2oR4 for ; Sun, 19 Nov 2017 22:35:05 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42334128B8F for ; Sun, 19 Nov 2017 22:35:05 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 14167B0; Mon, 20 Nov 2017 07:35:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511159702; bh=+gdvhJJJb2taGn8nl98jYSwFkeofvuosETAjdpK8tbg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=2MsbUYR3VeP+/YKOBkSLo0IHojQ6/1Rnlxvt1VgZqetCgNP9bb8bAnsyd4EdzQbrB zsiDjWXY8JPSkkwmmXzJ5GD7HChNootu/wUNHhb/WCsWxTl6/4JnzNC+cUM4BQWKsu zv53BCHFDceOhQYoou+kXs7QyMgc6zsiv3QZzDqM=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0DE159F; Mon, 20 Nov 2017 07:35:02 +0100 (CET)
Date: Mon, 20 Nov 2017 07:35:02 +0100 (CET)
From: Mikael Abrahamsson 
To: Mark Andrews 
cc: Ole Troan , 6man WG 
Subject: Re: IPv6 only host NAT64 requirements?
In-Reply-To: <83B04565-4A62-47AE-90FA-13F9254C5A1C@isc.org>
Message-ID: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>  <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>   <83B04565-4A62-47AE-90FA-13F9254C5A1C@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-2103843934-1511159702=:32099"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 06:35:07 -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-2103843934-1511159702=:32099
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 20 Nov 2017, Mark Andrews wrote:

> Well as this stage you can say that there are ISP that are deploying IPv6-only on
> the access network with DS-Lite to provide IPv4 as a service.  If you want your
> host to be able to connect directly to such ISPs you need to add support to detect
> that DS-Lite is in use (a IPv6 DHCP option) and bring up a IPv4 in IPv6 tunnel to
> the ISPs B4 router.

Most ds-lite networks are DOCSIS networks, and no host can connect 
directly to that. They'll end up behind a router, which will give the host 
a dual stack service. Sure, you can bridge the modem but the expectation 
is still that you'll connect a ds.lite capable router to that.

> You stop talk ipv6-only and start talking ipv6-only access + ipv4 as a service.

Same thing. Not helping.

> It’s only a “catch 22†because people fail to look at the options 
> available.  ISPs are going ipv6-only access + ipv4 as a service because 
> it is easier to manage than dual stack access + 44CGN.  Many ISPs 
> deliver CPE routers that support DS-Lite so the customer still see IPv4 
> + IPv6.

No, ISPs are not doing that, because hosts do not work properly in this 
scenario. iOS and Android does, but nothing else. So the "else" software 
vendors can just sit back, do nothing and play chicken race.

> The question to host vendors is “do you want your machines to be able to 
> connect directly to ISP’s that have ipv6-only access networks or not?†
> Ipv6-only access networks are a reality.

I doubt vendors get any feature requests to support this scenario. When 
it doesn't work, people will blame the ISP. This means ISPs won't deply 
this.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-2103843934-1511159702=:32099--


From nobody Sun Nov 19 23:28:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C27129458 for ; Sun, 19 Nov 2017 23:28:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 fSNKWqPzE1EM for ; Sun, 19 Nov 2017 23:28:52 -0800 (PST)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3C56129454 for ; Sun, 19 Nov 2017 23:28:51 -0800 (PST)
Received: by mail-it0-x233.google.com with SMTP id n134so10857630itg.1 for ; Sun, 19 Nov 2017 23:28:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ct8th3EIPPDexXgfqiQRpYI6xnJDKBuCrSNbc89j+SM=; b=dtgM0uR88IIzBX8BAMUww1iWKQkBgQ20bb9eGTff3a8e/68b3bECg6bVlG53doCe4d PwCAVpacwDA8fbyccbWbp2skhTLVZSzmCuUqdUwtC0+wrnOOHOu7psu7wc6yJaHkCwkS A6ZkDqYHBMyuPND7tz+8x8r7aMWQqDyIFkxBnyw5oF1feqqZegHcvzQJo0U6tDmsirB4 4xyhnhw5VafGlKIlcXZpd0mICiFFdpxeaHLjMrbMef+FwnfZKO04CIFsYsQgv39FawxK Yu94PWu2E/QbfVWSQJABNszqCEasfj20k062H+pWp2ZH1O/4QvVSVfxwJC751Z7sblFZ gp/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ct8th3EIPPDexXgfqiQRpYI6xnJDKBuCrSNbc89j+SM=; b=kOTdTctMyxmBKcGkQqbxUfXv2Iau52TVTNi+Pbmh197NTWNbTFV9XEDWRKA1VKDB3D Gq3ertex6UVgqQgqOCbsqqehMhQknrY9s7LvxsxP83Xao8dNhBHRhREjp4r/esZFsUBX eKwHrH0Lp6tdCpFnqDEVLtc+AeyqOB96NyShIg2SbvsfQHVFOlnCemb+nZXNa5484OiU gOQMlacS5N5ZAmWQWgTbjO17+s9oV3ZF1dzyNFf/7ueBbs1v/KDiafkuCCuXLDM4xrOT BV4O+LdV/QG4laX5NKV0kEA5N0pwn3QlyCJ+7vYKf5Y9Pkf7Y6jaf8g0OYxeu/IWDoBI xnww==
X-Gm-Message-State: AJaThX7LQH/6Ci7KaZAJ3zu0+EyXtA2cHZ8+cxH2ikK7jdkfmgjmRpjD GdFCg6dkHzfZLMeRq8baK9iBQu9Os4gP5WR7hwo41Q==
X-Google-Smtp-Source: AGs4zMamlb3YAzmgxiJ9Usx6fdTQw8dTWAnlc4pEcKlf8IvZYBdlhosgu4ygMKQ8rvW3kkYDnPCHbic7mbQtspaCRrM=
X-Received: by 10.36.172.31 with SMTP id s31mr17463331ite.124.1511162930713; Sun, 19 Nov 2017 23:28:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.16.155 with HTTP; Sun, 19 Nov 2017 23:28:30 -0800 (PST)
In-Reply-To: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org> 
From: Lorenzo Colitti 
Date: Mon, 20 Nov 2017 16:28:30 +0900
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Jen Linkova 
Cc: Nick Hilliard , IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary="94eb2c1fc0f8afa54a055e65098e"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 07:28:53 -0000

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

On Mon, Nov 20, 2017 at 1:16 PM, Jen Linkova  wrote:

> The idea of using a protocol X to tell device 'there is no protocol X
> on this link' sounds very entertaining ;)
> If I run a single-stack network I do not want to configure IPv4
> addresses, dhcp relays etc on v6-only interfaces
> and most likely I have no desire to run DHCPv4 for those segments. I
> might not even allow v4 traffic on the link at all
> (as it reduces the attack surface).
>

Sure. But you wouldn't need complicated infrastructure for this - if all
that's necessary is to respond to a DHCPv4 request with a canned "no DHCPv4
here" packet that is always the same, that's a lot easier to deploy than a
full DHCPv4 infrastructure.

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


On M=
on, Nov 20, 2017 at 1:16 PM, Jen Linkova <furry13@gmail.com>=
 wrote:
The idea of using a protocol X to=
 tell device 'there is no protocol X

on this link' sounds very entertaining ;)

If I run a single-stack network I do not want to configure IPv4

addresses, dhcp relays etc on v6-only interfaces

and most likely I have no desire to run DHCPv4 for those segments. I

might not even allow v4 traffic on the link at all

(as it reduces the attack surface).

Sur=
e. But you wouldn't need complicated infrastructure for this - if all t=
hat's necessary is to respond to a DHCPv4 request with a canned "n=
o DHCPv4 here" packet that is always the same, that's a lot easier=
 to deploy than a full DHCPv4 infrastructure.


--94eb2c1fc0f8afa54a055e65098e--


From nobody Sun Nov 19 23:41:55 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E24129463 for ; Sun, 19 Nov 2017 23:41:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level: 
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diHLfWUCUbDH for ; Sun, 19 Nov 2017 23:41:51 -0800 (PST)
Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76B7124207 for ; Sun, 19 Nov 2017 23:41:50 -0800 (PST)
Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 5EF45C093E; Mon, 20 Nov 2017 08:41:49 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 2F7F6180065; Mon, 20 Nov 2017 08:41:49 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 08:41:48 +0100
From: 
To: Ole Troan 
CC: Jen Linkova , 6man WG , Mark Andrews 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTX4U1swcBlM/8z0eNn33c3P4KiKMc5AXw
Date: Mon, 20 Nov 2017 07:41:48 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org>
In-Reply-To: <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 07:41:53 -0000

SGkgT2xlLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t
TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBPbGUgVHJvYW4gW21haWx0bzpvdHJvYW5A
ZW1wbG95ZWVzLm9yZ10NCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSAxNyBub3ZlbWJyZSAyMDE3IDEw
OjIwDQo+IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4gQ2PCoDogSmVuIExpbmtv
dmE7IDZtYW4gV0c7IE1hcmsgQW5kcmV3cw0KPiBPYmpldMKgOiBSZTogSVB2NiBvbmx5IGhvc3Qg
TkFUNjQgcmVxdWlyZW1lbnRzPw0KPiANCj4gTWVkLA0KPiANCj4gVGhhbmtzIGZvciBhbGwgdGhl
IHJlZmVyZW5jZXMuIFNlZW1zIGxpa2UgbW9zdCBiYXNlcyBoYXZlIGJlZW4gY292ZXJlZA0KPiBo
ZXJlLiA7LSkNCj4gDQo+IEZvciB0aGUgSUVURiBOQVQ2NCBJTUhPDQoNCltNZWRdIEFzIHlvdSBh
cmUgbWVudGlvbmluZyAiSUVURiIgZXhwbGljaXRseSwgTkFUNjQgbWF5IG5vdCBiZSB0aGUgYXBw
cm9wcmlhdGUgIklQdjQgc2VydmljZSBjb250aW51aXR5IiBzb2x1dGlvbiBoZXJlLiANCg0KIEkg
bmVlZDoNCj4gIC0gTm8gZGVwZW5kZW5jeSBvbiBETlM2NC4gV2FudCB0byB1c2UgcmVjdXJzaXZl
IHJlc29sdmVyIEkgdHJ1c3QgcGx1cw0KPiBsb2NhbCB2YWxpZGF0aW5nIHJlc29sdmVyLg0KPiAg
LSBOb3QgZGVwZW5kIG9uIHRoZSBzdWNjZXNzIG9mIFBDUCBmb3IgTkFUNjQgcHJlZml4IGRpc2Nv
dmVyeQ0KPiAgLSBJZiB0aGUgaG9zdCBjb3VsZG4ndCBsZWFybiB0aGUgTkFUNjQgcHJlZml4IGFu
eSBvdGhlciB3YXksIEkgc3VwcG9zZSBpdA0KPiBjb3VsZCB0aHJvdyBhbiBJQ01QIGVjaG8gdG93
YXJkcw0KPiAgICA2NDpmZjliOjoxMjcuMC4wLjEgKG9yIHBlcmhhcHMganVzdCA2NDpmZjliOjop
DQo+IA0KDQpbTWVkXSBGYWlyLiBUaGF0IGlzIGFub3RoZXIgImFkZCBteSBmYXZvcml0ZSBzb2x1
dGlvbiIgdG8gdGhlIGxpc3QuIA0KDQo+IEJ1dCBJIGFsc28gc2VlIHRoZXJlIGJlaW5nIGRpZmZl
cmVudCBkZXBsb3ltZW50IG9wdGlvbnMgaGVyZS4NCj4gQnR3LCBmb3IgbXVsdGlwbGUgTlNQcywg
Y291bGRuJ3QgeW91IHBhcnRseSBzb2x2ZSB0aGF0IGJ5IGluamVjdGluZyBtb3JlDQo+IHNwZWNp
ZmljcyBpbnRvIHJvdXRpbmc/DQoNCltNZWRdIEl0IGlzIG5vdCBvbmx5IGFib3V0IGZvcndhcmRp
bmcvcm91dGluZywgYnV0IGFsc28gaG93IGEgaG9zdCBjYW4gcGljayB0aGUgYXBwcm9wcmlhdGUg
cHJlZml4NjQgZm9yIGFkZHJlc3Mgc3ludGhlc2lzLiBUaGluZ3MgbWF5IGJlIG9idmlvdXMgaWYg
eW91IGNhbiBjb25zaWRlciB0aGUgZXhhbXBsZSBvZiBSRkM3MDUwOg0KDQoNCiAgICAgICAgICAg
ICAgICAgICAgICBOQVQ2NCAiQSIgLS0tLS0gSVB2NC1vbmx5IHNlcnZlcnMgaW4gYSBkYXRhIGNl
bnRlcg0KICAgICAgICAgICAgICAgICAgICAgLw0KICAgSVB2Ni1vbmx5IG5vZGUtLS08DQogICAg
ICAgICAgICAgICAgICAgICBcDQogICAgICAgICAgICAgICAgICAgICAgTkFUNjQgIkIiIC0tLS0t
IElQdjQgSW50ZXJuZXQgDQoNCg0KPiANCj4gQ2hlZXJzLA0KPiBPbGUNCj4gDQo+IA0KPiA+IE9u
IDE3IE5vdiAyMDE3LCBhdCAxNjo0NywgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+
IDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4gPg0KPiA+IEhpIEplbiwN
Cj4gPg0KPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE1lZA0K
PiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZSA6IEplbiBMaW5r
b3ZhIFttYWlsdG86ZnVycnkxM0BnbWFpbC5jb21dDQo+ID4+IEVudm95w6kgOiB2ZW5kcmVkaSAx
NyBub3ZlbWJyZSAyMDE3IDA5OjMxDQo+ID4+IMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09M
Tg0KPiA+PiBDYyA6IE9sZSBUcm9hbjsgNm1hbiBXRzsgTWFyayBBbmRyZXdzDQo+ID4+IE9iamV0
IDogUmU6IElQdjYgb25seSBob3N0IE5BVDY0IHJlcXVpcmVtZW50cz8NCj4gPj4NCj4gPj4gT24g
VGh1LCBOb3YgMTYsIDIwMTcgYXQgMTI6MzUgQU0sICA8bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl
LmNvbT4NCj4gd3JvdGU6DQo+ID4+Pj4gSU1ITyB0aGUgb3B0aW1hbCBzb2x1dGlvbiBpczoNCj4g
Pj4+PiAtIHRoZSBuZXR3b3JrIFNIT1VMRCBwcm92aWRlIGEgaG9zdCB3aXRoIE5BVDY0IHByZWZp
eCBpbmZvcm1hdGlvbiBpbg0KPiA+Pj4+IFJBIChJIGRvIG5vdCBiZWxpZXZlIHRoYXQgaW5mb3Jt
YXRpb24gbmVlZHMgdG8gYmUgZHVwbGljYXRlZCBpbiBESENQDQo+ID4+Pj4gYXQgYWxsKTsNCj4g
Pj4+DQo+ID4+PiBbTWVkXSBQbGVhc2UgY2hlY2s6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9yZmM3MDUxI3NlY3Rpb24tNS43LjMNCj4gPj4NCj4gPj4gVGhhbmtzIGZvciBwb2ludGluZyB0
aGlzIG91dC4gVG8gYmUgaG9uZXN0IEkgZGlzYWdyZWUgd2l0aCB3aGF0IHRoYXQNCj4gPj4gc2Vj
dGlvbiBzYXlzLg0KPiA+DQo+ID4gW01lZF0gSSBhbHNvIGRpc2FncmVlIHdpdGggbWFueSBvZiB0
aGUgcG9pbnRzIGluIFJGQzcwNTEsIGJ1dCB0aGF0IGlzDQo+IHRoZSBkb2N1bWVudCB3aGljaCBy
ZWZsZWN0cyB0aGUgSUVURiBjb25zZW5zdXMgb24gbGVhcm5pbmcgcHJlZml4NjRzLg0KPiA+DQo+
ID4gV2UgaGFkIG1hbnkgb3Bwb3J0dW5pdGllcyBpbiB0aGUgcGFzdCB0byBpZ25vcmUgdGhlIHJl
Y29tbWVuZGF0aW9ucyBpbg0KPiBSRkM3MDUxLCBidXQgd2UgZGlkbid0LiBGb3IgZXhhbXBsZSwg
UkZDODExNSBzYXlzIHRoZSBmb2xsb3dpbmc6DQo+ID4NCj4gPiA9PQ0KPiA+ICAgTm90ZSB0aGF0
IGl0IHdhcyB0ZW1wdGluZyB0byBkZWZpbmUgdGhyZWUgZGlzdGluY3QgREhDUHY2IG9wdGlvbnMs
DQo+ID4gICBidXQgdGhhdCBhcHByb2FjaCB3YXMgbm90IGFkb3B0ZWQgYmVjYXVzZSBpdCBoYXMg
YSBzaWRlIGVmZmVjdDogdGhlDQo+ID4gICBzcGVjaWZpY2F0aW9uIG9mIGEgREhDUHY2IG9wdGlv
biB0aGF0IGNvdWxkIGJlIHVzZWQgdG8gZGlzY292ZXINCj4gPiAgIHVuaWNhc3QgUHJlZml4NjRz
IGluIGVudmlyb25tZW50cyB3aGVyZSBtdWx0aWNhc3QgaXMgbm90IGVuYWJsZWQuDQo+ID4gICBT
dWNoIGEgc2lkZSBlZmZlY3QgY29uZmxpY3RzIHdpdGggdGhlIHJlY29tbWVuZGF0aW9uIHRvIHN1
cHBvcnQgdGhlDQo+ID4gICBXZWxsLUtub3duIEROUyBOYW1lIGhldXJpc3RpYyBkaXNjb3Zlcnkt
YmFzZWQgbWV0aG9kIGZvciB1bmljYXN0LW9ubHkNCj4gPiAgIGVudmlyb25tZW50cyAoU2VjdGlv
biA2IG9mIFtSRkM3MDUxXSkuDQo+ID4gPT0NCj4gPg0KPiA+PiBJJ20gdHJ5aW5nIHRvIHJlZnJh
aW4gZnJvbSBwYXJ0aWNpcGF0aW5nICAnU0xBQUMgdnMgREhDUHY2JyBzbyBJIHdpbGwNCj4gPj4g
bm90IG1lbnRpb24gYWxsIHRob3NlIGlzc3VlcyB3aXRoIG11bHRpaG9taW5nIGZvciBleGFtcGxl
IGJ1dC4uLi4NCj4gPj4gSWYgeW91IGFyZSBzYXlpbmcgdGhhdCB0aGUgcHJlZml4IHNob3VsZCBu
b3QgYmUgZGlzdHJpYnV0ZWQgdmlhIFJBcw0KPiA+PiBiZWNhdXNlIGl0IG5lZWRzIHRvIGJlIGNv
bmZpZ3VyZWQgb24gcm91dGVycywgdGhlbiB3aGF0IGFib3V0IEROUw0KPiA+PiBzZXJ2ZXJzIGFu
ZCBTTEFBQyBwcmVmaXhlcyB0aGVtc2VsdmVzPw0KPiA+PiBUaGVyZSBhcmUgU0xBQUMtb25seSBu
ZXR3b3JrcyBvdXQgdGhlcmUgd2hpbGUgUkZDNzkzNCBkb2VzIG5vdA0KPiA+PiByZWNvbW1lbmQg
REhDUHY2IGFzIHRoZSBvbmx5IHdheSB0byBjb25maWd1cmUgY2xpZW50cy4NCj4gPj4gU28gYmV0
d2VlbiB0aG9zZSB0d28gUkEgZG9lcyBsb29rIGxpa2UgYSBiZXR0ZXIgd2F5Lg0KPiA+DQo+ID4g
W01lZF0gSXQgaXMgZXZpZGVudCB0aGF0IFJBLWJhc2VkIGFwcHJvYWNoIG1heSBiZSBhIGdvb2Qg
Y2FuZGlkYXRlIGZvcg0KPiBzb21lIGRlcGxveW1lbnRzLiBPdGhlcnMgbWF5IGFyZ3VlIHRoYXQg
YW5vdGhlciBzb2x1dGlvbiBpcyBhcHByb3ByaWF0ZQ0KPiBmb3IgdGhlaXIgZGVwbG95bWVudCwg
YW5kIHNvIG9uLg0KPiA+DQo+ID4+DQo+ID4+PiBUaGluZ3MgbWF5IGdldCBjb21wbGV4IGlmIG11
bHRpcGxlIE5TUHMgYXJlIHVzZWQgZm9yIGxvYWQtYmFsYW5jaW5nIG9yDQo+ID4+IGlmIGRlc3Rp
bmF0aW9uIGJhc2VkIE5BVDY0cyBhcmUgZGVwbG95ZWQuIEEgbGlzdCBvZiBpc3N1ZXMgaXMNCj4g
ZWxhYm9yYXRlZA0KPiA+PiBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIyNSNz
ZWN0aW9uLTMuMQ0KPiA+Pg0KPiA+PiBJdCdzIG1vcmUgbGlrZSB2Nm9wcyBxdWVzdGlvbiBidXQg
SSdtIHJlYWxseSBjdXJpb3VzIGlmIG11bHRpcGxlDQo+ID4+IHByZWZpeGVzIHNjZW5hcmlvIGlz
IHJlYWwuDQo+ID4+IFJBIG9wdGlvbiBtaWdodCBjb250YWluIG11bHRpcGxlIHByZWZpeGVzIGFu
eXdheS4NCj4gPg0KPiA+IFtNZWRdIEluZGVlZC4gSXQgaXMgYWxyZWFkeSBBQ0tlZCBpbiA3MDUx
Og0KPiA+DQo+ID4gICBOb3RlOiBJZiB0aGUgUkEgd291bGQgaW5jbHVkZSBtdWx0aXBsZSBOU1Bz
LCBJc3N1ZSAjNSBjb3VsZCBiZSBzb2x2ZWQNCj4gPiAgIGFzIHdlbGwsIGJ1dCBvbmx5IGlmIG5v
ZGVzIGFzIGEgZ3JvdXAgd291bGQgc2VsZWN0IGRpZmZlcmVudCBOU1BzLA0KPiA+ICAgaGVuY2Ug
c3VwcG9ydGluZyBsb2FkIGJhbGFuY2luZy4gIEFzIHRoaXMgaXMgbm90IGNsZWFyLCB0aGlzIGl0
ZW0gaXMNCj4gPiAgIG5vdCB5ZXQgbGlzdGVkIHVuZGVyIFBST3Mgb3IgQ09Ocy4NCj4gPg0KPiA+
Pg0KPiA+Pj4+Pj4gT24gMTUgTm92IDIwMTcsIGF0IDA4OjA2LCBNYXJrIEFuZHJld3MgPG1hcmth
QGlzYy5vcmc+IHdyb3RlOg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gT24gMTUgTm92
IDIwMTcsIGF0IDM6NDAgYW0sIExvcmVuem8gQ29saXR0aSA8bG9yZW56b0Bnb29nbGUuY29tPg0K
PiA+Pj4+IHdyb3RlOg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gVHVlLCBOb3YgMTQsIDIwMTcg
YXQgNjo0NiBBTSwgTWFyayBBbmRyZXdzIDxtYXJrYUBpc2Mub3JnPg0KPiA+PiB3cm90ZToNCj4g
Pj4+Pj4+PiBJcyB0aGVyZSBhbnkgcmVhc29uIHRvIHJ1biBETlM2NCBhdCBhbGwgdGhlc2UgZGF5
cz8gIGlwdjRvbmx5LmFycGENCj4gPj4gY2FuDQo+ID4+Pj4gYmUgYSBwcmVjb25maWd1cmVkDQo+
ID4+Pj4+Pj4gem9uZSB3aGljaCBhbGxvd3MgQ0xBVCB0byBnZXQgaXRzIG1hcHBpbmcuICBBbGwg
dGhlIHBob25lcyBoYXZlDQo+ID4+IENMQVQNCj4gPj4+PiBzdXBwb3J0Lg0KPiA+Pj4+Pj4+DQo+
ID4+Pj4+Pj4gVGhhdCdzIGFuIGludGVyZXN0aW5nIGlkZWEuIEl0IHdvdWxkIHdvcmsgaW4gdGhl
b3J5LCBidXQgc3VjaCBhDQo+ID4+Pj4gbmV0d29yayB3b3VsZCBjb21wbGV0ZWx5IGJyZWFrIGRl
dmljZXMgdGhhdCBkb24ndCBzdXBwb3J0IDQ2NHhsYXQuDQo+IFRoYXQNCj4gPj4+PiBnaXZlcyB1
cCBvbmUgb2YgdGhlIG1ham9yIGFkdmFudGFnZXMgb2YgTkFUNjQvRE5TNjQsIHdoaWNoIGlzIHRo
YXQNCj4gaXQncw0KPiA+PiBhDQo+ID4+Pj4gOTAlIHNvbHV0aW9uIGV2ZW4ganVzdCBieSBpdHNl
bGYgLSB5ZXMsIElQdjQtb25seSBhcHBsaWNhdGlvbnMgYW5kDQo+ID4+IGFkZHJlc3MNCj4gPj4+
PiBsaXRlcmFscyBleGlzdCwgYnV0IG1vc3Qgc2ltcGxlIGNsaWVudC9zZXJ2ZXIgYXBwbGljYXRp
b25zIEp1c3QgV29yaw0KPiA+Pj4+IGJlaGluZCBpdC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBBbmQg
dGhhdCA5MCUg4oCcc29sdXRpb27igJ0gaGFzIGxvdHMgb2YgZG93biBzaWRlcy4gIEl0IGJhc2lj
YWxseQ0KPiA+PiByZXF1aXJlcw0KPiA+Pj4+IEVWRVJZIEROUyBWQUxJREFUT1IgT04NCj4gPj4+
Pj4+IFRIRSBQTEFORVQgVE8gU1VQUE9SVCBETlM2NCBKVVNUIElOIENBU0UgSVQgSVMgVVNFRCBC
RUhJTkQgQSBETlM2NA0KPiA+Pj4+IFNFUlZFUi4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBETlM2NC9O
QVQ2NCB3YXMgcHJlc2VudGVkIGFzIE5PVCBSRVFVSVJJTkcgbm9kZSBjaGFuZ2VzIHdoZW4gZmly
c3QNCj4gPj4+PiBtb290ZWQuICBJdCBrZWVwcyBvbg0KPiA+Pj4+Pj4gcmVxdWlyaW5nIG1vcmUg
YW5kIG1vcmUgaGlnaGx5IGludmFzaXZlIG5vZGUgY2hhbmdlcyB0byBzdXBwb3J0Lg0KPiBJdA0K
PiA+Pj4+IHdhcyBmcm9tIHRoZSB2ZXJ5IGJlZ2lubmluZw0KPiA+Pj4+Pj4gYmFkIGVuZ2luZWVy
aW5nLiAgIFRvIGdldCBJUHY0IGFzIGEgc2VydmljZSBzb21lIG5vZGUgY2hhbmdlcyBhcmUNCj4g
Pj4+PiByZXF1aXJlZC4gIExldHMgbWFrZSBzdXJlIHRoZXkNCj4gPj4+Pj4+IGFyZSBNSU5JTUFM
IG9uZXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSnVzdCBmb3IgdGhlIHJlY29yZCBETlNTRUMgdmFs
aWRhdG9ycyBuZWVkIHRvIHNlbmQgQk9USCBDRD0wIGFuZA0KPiA+PiBDRD0xDQo+ID4+Pj4gcXVl
cmllcyB0byBnZXQgYW5zd2Vycw0KPiA+Pj4+Pj4gdGhvdWdoIGEgdXBzdHJlYW0gVkFMSURBVElO
RyBzZXJ2ZXIgd2hpY2ggaW5jbHVkZXMgYSBWQUxJREFUSU5HDQo+ID4+IEROUzY0DQo+ID4+Pj4g
c2VydmVyIGFzIENEPTAgYW5kDQo+ID4+Pj4+PiBDRD0xIGFkZHJlc3MgZGlmZmVyZW50IEROU1NF
QyB0aHJlYXRzLiAgSSB0cmllZCB2ZXJ5IGhhcmQgdG8gcG9pbnQNCj4gPj4gdGhhdA0KPiA+Pj4+
IG91dCB3aGVuIFJGQyA2MTQ3IHdhcw0KPiA+Pj4+Pj4gYmVpbmcgd3JpdHRlbiBidXQgdGhlIHdv
cmtpbmcgZ3JvdXAgZGVjaWRlIHRoYXQgQ0QgaW5kaWNhdGVkDQo+IHdoZXRoZXINCj4gPj4+PiB0
aGUgY2xpZW50IHdhcyB2YWxpZGF0aW5nIG9yDQo+ID4+Pj4+PiBub3QuICBUaGVyZSBpcyBOTyBT
VUNIIElORElDQVRJT04gaW4gYSBETlMgbWVzc2FnZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJZiBh
IHF1ZXJ5IGFycml2ZXMgYXQgYSB2RE5TNjQgZGV2aWNlIHdpdGggdGhlICJDaGVja2luZyBEaXNh
YmxlZCINCj4gPj4+Pj4+ICAoQ0QpIGJpdCBzZXQsIGl0IGlzIGFuIGluZGljYXRpb24gdGhhdCB0
aGUgcXVlcnlpbmcgYWdlbnQgd2FudHMNCj4gPj4gYWxsDQo+ID4+Pj4+PiAgdGhlIHZhbGlkYXRp
b24gZGF0YSBzbyBpdCBjYW4gZG8gY2hlY2tpbmcgaXRzZWxmLiAgQnkgbG9jYWwNCj4gPj4gcG9s
aWN5LA0KPiA+Pj4+Pj4gIHZETlM2NCBjb3VsZCBzdGlsbCB2YWxpZGF0ZSwgYnV0IGl0IG11c3Qg
cmV0dXJuIGFsbCBkYXRhIHRvIHRoZQ0KPiA+Pj4+Pj4gIHF1ZXJ5aW5nIGFnZW50IGFueXdheS4N
Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBDRD0wIHF1ZXJpZXMgY2F1c2VzIHRoZSB1cHN0cmVhbSB2YWxp
ZGF0aW5nIHNlcnZlcnMgdG8gcmVqZWN0DQo+ID4+IGluY29taW5nDQo+ID4+Pj4gc3Bvb2ZlZCBh
bnN3ZXJzDQo+ID4+Pj4+PiBvciBzdGFsZSBhbnN3ZXJzICh0aGlzIGlzIGEgY29tbW9uIG9wZXJh
dGlvbmFsIHByb2JsZW0pLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IENEPTEgcXVlcmllcyBhbGxvdyB0
aGUgdmFsaWRhdGlvbiB0byBzdWNjZWVkIHdoZW4gdGhlIHVwc3RyZWFtDQo+ID4+Pj4gdmFsaWRh
dG9yIGhhcyBhIGJhZCB0cnVzdA0KPiA+Pj4+Pj4gYW5jaG9yIG9yIGEgYmFkIGNsb2NrIHdoaWNo
IGlzIHJlamVjdGluZyBsZWdpdGltYXRlIGFuc3dlcnMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQSB2
YWxpZGF0aW5nIGNsaWVudCBjYW7igJl0IGp1c3Qgc2VuZCBDRD0xIHF1ZXJpZXMgYXMgdGhlIHVw
c3RyZWFtDQo+ID4+Pj4gdmFsaWRhdG9yIGRvZXNu4oCZdCBraWNrIGluLg0KPiA+Pj4+Pj4gVGhl
IHVwc3RyZWFtIHZhbGlkYXRvciBjYW4gbG9jayBvbnRvIGEgc3RhbGUgYW5zd2VyIHNvdXJjZS4g
IEl0DQo+ID4+IG5lZWRzDQo+ID4+Pj4gdG8gc2VuZCBDRD0wIHF1ZXJpZXMNCj4gPj4+Pj4+IG9u
IHZhbGlkYXRpb24gZmFpbHVyZSB0byBmb3JjZSB0aGUgdXBzdHJlYW0gdmFsaWRhdG9yIHRvIHRy
eQ0KPiA+PiBtdWx0aXBsZQ0KPiA+Pj4+IHNvdXJjZXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQSB2
YWxpZGF0aW5nIGNsaWVudCBjYW7igJl0IGp1c3Qgc2VuZCBDRD0wLiAgSXQgbmVlZHMgdG8gc2Vu
ZCBDRD0xIG9uDQo+ID4+Pj4gU0VSVkZBSUwgaW4gY2FzZSB0aGUNCj4gPj4+Pj4+IHVwc3RyZWFt
IHZhbGlkYXRvciBoYXMgYSBiYWQgdHJ1c3QgYW5jaG9yIChsaWtlbHkgd2l0aCB0aGUgdXBjb21p
bmcNCj4gPj4+PiByb290IEtTSyByb2xsKSBvciBoYXMNCj4gPj4+Pj4+IGEgYmFkIGNsb2NrICh0
aGVzZSB1c3VhbGx5IGdldCBmaXhlZCBmYXN0KS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBOb3cgdG8g
Z2V0IGEgYW5zd2VyIGZyb20gYSBzaWduZWQgem9uZSB3aXRoIHNlcnZlcnMgd2l0aCBzdGFsZQ0K
PiA+PiBhbnN3ZXJzDQo+ID4+Pj4gYSB2YWxpZGF0aWluZyBETlM2NCBjbGllbnQNCj4gPj4+Pj4+
IG5lZWRzIHRvIHNlbmQ6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gYSkgc2VuZCBDRD0xIGFuZCB2YWxp
ZGF0aW9uIGZhaWx1cmUgc2VuZCBDRD0wIHRoZW4gb24gQUFBQQ0KPiA+PiB2YWxpZGF0aW9uDQo+
ID4+Pj4gZmFpbHVyZSBzZW5kIENEPTEgYW5kDQo+ID4+Pj4+PiAgIGhvcGUgdGhlIFRUTCB3YXMg
bm90IDAgYW5kIHRoYXQgaXMgbm90IGNhY2hhYmxlIGFuZCB0aGVyZSBpcyBubw0KPiA+Pj4+IGFz
c3VyYW5jZSB0aGF0IHlvdSB3b27igJl0IGdldA0KPiA+Pj4+Pj4gICBhIGFuc3dlciBmcm9tIGEg
c3RhbGUgc291cmNlLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgICAgb3INCj4gPj4+Pj4+DQo+ID4+
Pj4+PiBiKSBzZW5kIENEPTAgYW5kIG9uIHZhbGlkYXRpb24gZmFpbHVyZSBvZiB0aGUgQUFBQSBz
ZW5kIENEPTEgYW5kDQo+ID4+IGhvcGUNCj4gPj4+PiB0aGUgVFRMIHdhcyBub3QgMCBhcw0KPiA+
Pj4+Pj4gICB0aGF0IGlzIG5vdCBjYWNoYWJsZSBhbmQgdGhlcmUgaXMgbm8gYXNzdXJhbmNlIHRo
YXQgeW91IHdvbuKAmXQgZ2V0DQo+ID4+IGENCj4gPj4+PiBhbnN3ZXIgZnJvbSBhIHN0YWxlIHNv
dXJjZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUVEw9MCBhbnN3ZXJzIGV4aXN0Lg0KPiA+Pj4+Pj4N
Cj4gPj4+Pj4+IE5vdGUgbm9uZSBvZiB0aGlzIGlzIGRvY3VtZW50ZWQgaW4gYSBSRkMuICBZb3Ug
aGF2ZSB0byB1bmRlcnN0YW5kDQo+ID4+IGhvdw0KPiA+Pj4+IGJvdGggRE5TU0VDIGFuZCBETlM2
NCB3b3JrIHRvDQo+ID4+Pj4+PiByZWFsaXNlIHRoaXMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSVBW
NE9OTFkuQVJQQSBpcyBjdXJyZW50bHkgaGFzIGEgc2VjdXJlIGRlbGVnYXRpb24gd2hpY2ggYnJl
YWtzDQo+ID4+IHByZWZpeA0KPiA+Pj4+IGRpc2NvdmVyIGZvciBETlMgVkFMSURBVE9SUy4NCj4g
Pj4+Pj4+IE5vdGUg4oCcYWTigJ0gaXMgc2V0IGluIHRoZSBmbGFncy4gIFllcywgSeKAmXZlIHN1
Ym1pdHRlZCBhIGVycmF0YS4gIFllcywNCj4gPj4+PiBJ4oCZdmUgb3BlbmVkIGEgdGlja2V0IHRv
IGdldCBpdCBmaXhlZCBidXQNCj4gPj4+Pj4+IGJhc2VkIG9uIHBhc3QgZXhwZXJpZW5jZSB0aGF0
IGNvdWxkIHRha2UgbW9udGhzIGlmIGl0IGhhcHBlbnMgYXQNCj4gPj4gYWxsLg0KPiA+Pj4+IFlv
dSB3aWxsIG5vdGUgdGhhdCB0aGUgcmVjdXJzaXZlDQo+ID4+Pj4+PiBzZXJ2ZXIgaXMgcnVubmlu
ZyBvbiB0aGUgbG9vcGJhY2sgaW50ZXJmYWNlIHNvIGFsbCBETlMgYW5zd2VycyBhcmUNCj4gPj4+
PiBiZWluZyB2YWxpZGF0ZWQgaGVyZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBbcm9jazpiaW5kOS9i
aW4vbmFtZWRdIG1hcmthJSBkaWcgSVBWNE9OTFkuQVJQQQ0KPiA+Pj4+Pj4gOzsgQkFEQ09PS0lF
LCByZXRyeWluZy4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiA7IDw8Pj4gRGlHIDkuMTIuMGIyK2hvdHNw
b3QrYWRkLXByZWZldGNoK21hcmthIDw8Pj4gSVBWNE9OTFkuQVJQQQ0KPiA+Pj4+Pj4gOzsgZ2xv
YmFsIG9wdGlvbnM6ICtjbWQNCj4gPj4+Pj4+IDs7IEdvdCBhbnN3ZXI6DQo+ID4+Pj4+PiA7OyAt
Pj5IRUFERVI8PC0gb3Bjb2RlOiBRVUVSWSwgc3RhdHVzOiBOT0VSUk9SLCBpZDogODUwNA0KPiA+
Pj4+Pj4gOzsgZmxhZ3M6IHFyIHJkIHJhIGFkOyBRVUVSWTogMSwgQU5TV0VSOiAyLCBBVVRIT1JJ
VFk6IDAsDQo+ID4+IEFERElUSU9OQUw6IDENCj4gPj4+Pj4+DQo+ID4+Pj4+PiA7OyBPUFQgUFNF
VURPU0VDVElPTjoNCj4gPj4+Pj4+IDsgRUROUzogdmVyc2lvbjogMCwgZmxhZ3M6OyB1ZHA6IDQw
OTYNCj4gPj4+Pj4+IDsgQ09PS0lFOiA3ZGJmOGJlYjc5YmU0N2EwOWViNTMxM2Q1YTBiNzc2ZjRm
YWUzYWE2OTMxZDk1ODMgKGdvb2QpDQo+ID4+Pj4+PiA7OyBRVUVTVElPTiBTRUNUSU9OOg0KPiA+
Pj4+Pj4gO0lQVjRPTkxZLkFSUEEuICAgICAgICAgICAgICAgICAgICAgICBJTiAgICAgIEENCj4g
Pj4+Pj4+DQo+ID4+Pj4+PiA7OyBBTlNXRVIgU0VDVElPTjoNCj4gPj4+Pj4+IGlwdjRvbmx5LmFy
cGEuICAgICAgICAgICAgICAgIDI2NTc0ICAgSU4gICAgICBBICAgICAgIDE5Mi4wLjAuMTcxDQo+
ID4+Pj4+PiBpcHY0b25seS5hcnBhLiAgICAgICAgICAgICAgICAyNjU3NCAgIElOICAgICAgQSAg
ICAgICAxOTIuMC4wLjE3MA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IDs7IFF1ZXJ5IHRpbWU6IDAgbXNl
Yw0KPiA+Pj4+Pj4gOzsgU0VSVkVSOiAxMjcuMC4wLjEjNTMoMTI3LjAuMC4xKQ0KPiA+Pj4+Pj4g
OzsgV0hFTjogV2VkIE5vdiAxNSAxMDowODozMSBBRURUIDIwMTcNCj4gPj4+Pj4+IDs7IE1TRyBT
SVpFICByY3ZkOiAxMTUNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBbcm9jazpiaW5kOS9iaW4vbmFtZWRd
IG1hcmthJQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+PiBJdCdzIG5vdCB0cnVlIHRoYXQgYWxsIHBob25l
cyBoYXZlIGNsYXQgc3VwcG9ydC4gTm90YWJseSwgQXBwbGUNCj4gbm90DQo+ID4+Pj4gb25seSBk
b2VzIG5vdCBzdXBwb3J0IGl0IGJ1dCBhcHBlYXJzIGlkZW9sb2dpY2FsbHkgb3Bwb3NlZCB0byBp
dCBvbg0KPiB0aGUNCj4gPj4+PiBncm91bmRzIHRoYXQgaXQgZG9lcyBub3QgaGF2ZSBhIGdvb2Qg
ZXhpdCBzdHJhdGVneSAoYmVjYXVzZSBpdCBtYWtlcw0KPiBpdA0KPiA+Pj4+IHBvc3NpYmxlIHRv
IHJ1biBJUHY0LW9ubHkgYXBwcyBmb3JldmVyKS4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+
Pj4gLS0NCj4gPj4+Pj4+IE1hcmsgQW5kcmV3cywgSVNDDQo+ID4+Pj4+PiAxIFNleW1vdXIgU3Qu
LCBEdW5kYXMgVmFsbGV5LCBOU1cgMjExNywgQXVzdHJhbGlhDQo+ID4+Pj4+PiBQSE9ORTogKzYx
IDIgOTg3MSA0NzQyICAgICAgICAgICAgICBJTlRFUk5FVDogbWFya2FAaXNjLm9yZw0KPiA+Pj4+
Pj4NCj4gPj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLQ0KPiA+Pj4+Pj4gSUVURiBJUHY2IHdvcmtpbmcg
Z3JvdXAgbWFpbGluZyBsaXN0DQo+ID4+Pj4+PiBpcHY2QGlldGYub3JnDQo+ID4+Pj4+PiBBZG1p
bmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9pcHY2DQo+ID4+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+
Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCj4gPj4+Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBs
aXN0DQo+ID4+Pj4+IGlwdjZAaWV0Zi5vcmcNCj4gPj4+Pj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVz
dHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+Pj4+PiAt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KPiA+Pj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IC0tDQo+
ID4+Pj4gU1ksIEplbiBMaW5rb3ZhIGFrYSBGdXJyeQ0KPiA+Pj4+DQo+ID4+Pj4gLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCj4gPj4+PiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gPj4+PiBp
cHY2QGlldGYub3JnDQo+ID4+Pj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+Pj4+IC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+
DQo+ID4+DQo+ID4+DQo+ID4+IC0tDQo+ID4+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCg0K


From nobody Sun Nov 19 23:51:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BC912947E for ; Sun, 19 Nov 2017 23:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 ynnCimO_jXUs for ; Sun, 19 Nov 2017 23:51:24 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE62912946C for ; Sun, 19 Nov 2017 23:51:23 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 988FFB0; Mon, 20 Nov 2017 08:51:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511164281; bh=AWS+rhmlboj5gdICHBBAjxbIeT+WUemxAFEAbU4vNUw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=IUb8hWSrctSzBLBIX4CrrV3LpEfR2K5FY9wuXqKis8MPRmSrAE74aiAYjaV0J9c4j s1Dh4BCf/zedI10xGFILIeE1XV7qXH8+1RviI9J7Zv8L7pueKxKzLSB5Z7F2bkyqzX BNjPSAe+ws2KfSZTVQPrfKJMA6Mlmmaz6G7/egg4=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 811D39F; Mon, 20 Nov 2017 08:51:21 +0100 (CET)
Date: Mon, 20 Nov 2017 08:51:21 +0100 (CET)
From: Mikael Abrahamsson 
To: Lorenzo Colitti 
cc: Jen Linkova , IETF IPv6 Mailing List 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
In-Reply-To: 
Message-ID: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 07:51:26 -0000

On Mon, 20 Nov 2017, Lorenzo Colitti wrote:

> Sure. But you wouldn't need complicated infrastructure for this - if all 
> that's necessary is to respond to a DHCPv4 request with a canned "no 
> DHCPv4 here" packet that is always the same, that's a lot easier to 
> deploy than a full DHCPv4 infrastructure.

This functionality doesn't exist today in any access network I know of. 
It's also non-trivial to do considering how access networks are done. 
Preferrably one would like to ahve an ethertype filter on the access port 
to only allow 0x86dd and nothing else. Then putting this flag into IPv4 
means this isn't possible.

IPv6 is the next generation IP protocol. I prefer that it can signal that 
the legacy version is not available, instead of having to keep legacy IP 
functionality around.

... or we put it in some other L2 protocol, such as LLDP.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Mon Nov 20 00:33:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1041294B7 for ; Mon, 20 Nov 2017 00:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7DUrwPmBS4e for ; Mon, 20 Nov 2017 00:33:37 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85621294B8 for ; Mon, 20 Nov 2017 00:33:34 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 079FD2D4F99; Mon, 20 Nov 2017 08:33:34 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 48A1D200C8E3FB; Mon, 20 Nov 2017 09:33:31 +0100 (CET)
From: Ole Troan 
Message-Id: <0C83562D-859B-438C-9A90-2480BB166737@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_6B8DAD20-9F85-4D2D-8535-8836E7CD519C"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 20 Nov 2017 09:33:30 +0100
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Cc: Jen Linkova , 6man WG , Mark Andrews 
To: Mohamed Boucadair 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 08:33:39 -0000

--Apple-Mail=_6B8DAD20-9F85-4D2D-8535-8836E7CD519C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Med,

>>=20
>> For the IETF NAT64 IMHO
>=20
> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the =
appropriate "IPv4 service continuity" solution here.

Why not?
Interesting to hear your views here, especially since it "almost" worked =
at IETF100.

> I need:
>> - No dependency on DNS64. Want to use recursive resolver I trust plus
>> local validating resolver.
>> - Not depend on the success of PCP for NAT64 prefix discovery
>> - If the host couldn't learn the NAT64 prefix any other way, I =
suppose it
>> could throw an ICMP echo towards
>>   64:ff9b::127.0.0.1 (or perhaps just 64:ff9b::)
>>=20
>=20
> [Med] Fair. That is another "add my favorite solution" to the list.
>=20
>> But I also see there being different deployment options here.
>> Btw, for multiple NSPs, couldn't you partly solve that by injecting =
more
>> specifics into routing?
>=20
> [Med] It is not only about forwarding/routing, but also how a host can =
pick the appropriate prefix64 for address synthesis. Things may be =
obvious if you can consider the example of RFC7050:
>=20
>=20
>                      NAT64 "A" ----- IPv4-only servers in a data =
center
>                     /
>   IPv6-only node---<
>                     \
>                      NAT64 "B" ----- IPv4 Internet

Firstly this seems like it is over engineered. Has anyone actually =
deployed NAT64 this way?
(Given that this is quite rare even in IPv6 only or IPv4 only scenarios. =
Look at implementation status of RIO for example).

Secondly, RFC7050 says:

   The heuristic discovery method described herein does not support
   learning of the possible rules used by a DNS64 server for mapping
   specific IPv4 address ranges to separate Pref64::/n prefixes.
   Therefore, nodes will use the same discovered Pref64::/n to
   synthesize IPv6 addresses from any IPv4 address.  This can cause
   issues for routing and connectivity establishment procedures.  The
   operator of the NAT64 and the DNS64 ought to take this into account
   in the network design.

Which to me reads, this just doesn't work.

If we think NAT64 is a fundamental piece of technology to make progress =
on the transition, then I think we should focus on making it as simple =
and deployable as possible.

Cheers,
Ole

--Apple-Mail=_6B8DAD20-9F85-4D2D-8535-8836E7CD519C
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+/bDNdvtpYqJhC33YFAloSk1oACgkQvtpYqJhC
33ZDcQ//RRGrRfG2X3fFiaOMODppTn/ZqTlHL3IyrwKEjBOJnAn7oyrhtDe395vj
LNKexJ+O9xWk9CX7Im4L5pJpDEx9Itmtwjmk/0o5DMcOBfH/Y8azeNksPCKjJXBF
Jn3sWbTnEEZCZpNEBgn2ynTL5eF5CkkMgc2BJwDZzg84b/h6wcLvrlLDUZQHLgtW
VwY7xzsrd0Lt6y7yjpdCY7a9M0hcVZPrB0WBAXl9ilcj4tK+4rDxis5Nhm+gF/+5
pupqEYab2urNSyZzSXgZa6mO7rNr+Z/tO6esIMkOlLH07v+SJGkjv9lFSstP4XOD
vVDqFbHCNRq5L9JeF9MruSB8GmrUiYUNKIvdcDp/uokcWWQybaXknKw/aEncc50V
WQMiMwIbgfxk6PUfCZq+xRoNVYQAOMerltpsJuqgpBJL1yHavEVL6lf69Lh8kXLr
OOw7TmaLDgy84Zgrv3uVLfRGZlGxfycnTtatHW+S9a4YrO0pw26Pefd+qlBbevPj
kP9KJMB7Ow+0ql3deGYRUfTSy++T868tatG4fl24qbyjlru0x7wUkZuWBWE1YuYM
V8wbhOoNiiLlpYspHqSPCm0e0eDzh4RUNTq/v21XeYbCgrB+IznPMXZ9YVCViyBd
LSqGuAl7I1l5BfZ6QoyUHUzqe1HjqCSLDH50Fk1+eDbwEJlK9Bk=
=w/WJ
-----END PGP SIGNATURE-----

--Apple-Mail=_6B8DAD20-9F85-4D2D-8535-8836E7CD519C--


From nobody Mon Nov 20 00:40:58 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9FD12941C for ; Mon, 20 Nov 2017 00:40:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOqTAEpnRx1v for ; Mon, 20 Nov 2017 00:40:54 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428401294B8 for ; Mon, 20 Nov 2017 00:40:54 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 915332D5038; Mon, 20 Nov 2017 08:40:53 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 2CB2C200C8EBCB; Mon, 20 Nov 2017 09:40:51 +0100 (CET)
From: Ole Troan 
Message-Id: <1986EEC9-ED01-40D1-A1E6-3B7703A8ED34@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_C39C4FD5-7337-421E-8FC3-205BC014667B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 20 Nov 2017 09:40:50 +0100
In-Reply-To: <83B04565-4A62-47AE-90FA-13F9254C5A1C@isc.org>
Cc: Mikael Abrahamsson , 6man WG 
To: Mark Andrews 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>  <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>   <83B04565-4A62-47AE-90FA-13F9254C5A1C@isc.org>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 08:40:56 -0000

--Apple-Mail=_C39C4FD5-7337-421E-8FC3-205BC014667B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Mark,

>>> The challenge we have in front of us is to make IPv6 only work.
>>=20
>> When I speak to vendors about this, I get different answers. Some are =
saying "nobody will deploy IPv6 only, so why should I make changes in my =
desktop OS to support it for legacy applications?=E2=80=9D
>=20
> Well as this stage you can say that there are ISP that are deploying =
IPv6-only on
> the access network with DS-Lite to provide IPv4 as a service.  If you =
want your
> host to be able to connect directly to such ISPs you need to add =
support to detect
> that DS-Lite is in use (a IPv6 DHCP option) and bring up a IPv4 in =
IPv6 tunnel to
> the ISPs B4 router.
>=20
> Repeat this for other transition technologies that you are aware is in =
use.
>=20
>> And I imagine any access provider will say "I can't deploy IPv6 only, =
because it'll break a lot of applications that people are using on =
desktop OSes".
>>=20
>> So this is classic catch 22.
>=20
> You stop talk ipv6-only and start talking ipv6-only access + ipv4 as a =
service.
>=20
> It=E2=80=99s only a =E2=80=9Ccatch 22=E2=80=9D because people fail to =
look at the options available.  ISPs
> are going ipv6-only access + ipv4 as a service because it is easier to =
manage than
> dual stack access + 44CGN.   Many ISPs deliver CPE routers that =
support DS-Lite
> so the customer still see IPv4 + IPv6.
>=20
> The question to host vendors is =E2=80=9Cdo you want your machines to =
be able to connect
> directly to ISP=E2=80=99s that have ipv6-only access networks or =
not?=E2=80=9D  Ipv6-only access
> networks are a reality.

=46rom the perspective of the host and the application, "IPv4 as a =
service" is hardly progress.
(Progress being defined as something moving us towards an IPv6 only =
network).

IPv4aaS offers dual stack to the hosts. Sure, it is typically carried =
over IPv6, and it allows the access network to use IPv6 transport. But =
from the perspective of delivering the service, it could as well have =
been ATM.

The other coin of IPv4aaS is that it is a mechanism that allows IPv4 to =
scale indefinitely.

The tragicomedy of where we are at the moment is that an ISP would offer =
better service to the end-user network by delivering IPv4 only service =
over it's IPv4aaS infrastructure... we need to find a way to move off =
dual-stack.

Ole



--Apple-Mail=_C39C4FD5-7337-421E-8FC3-205BC014667B
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+/bDNdvtpYqJhC33YFAloSlRIACgkQvtpYqJhC
33YkPw/+Kq2ttZImrnY2ojsOhfoXkzFFR0x1n4LIAQDVJe3419/UTWElSlYtY3EN
83jaEeOSVRZjsP9WogxdQGXq6nG75+eEd8ioGOZt9odkRKtZXz/IAZZMXg/uX02j
eb5Nfx/y1grD6M2xXUHJPEmGAO2ck6dc5swG3TLhjL1Eb9vBEFnkfYjcskB60leP
a/fDMnvo1QMPjr21GgRjdA4AR8JbmdhaNsV40lrHADkHJ5JJ9aqXihSk8O2pbhsN
V3yeA58Z9grzBc9f5RE0bj4gcAoq2cFX7c6edWC8/ysLsndCV3oSiRY8UAq2qi0e
UQ5T5Uxwr9KCBk0eeSAnSXjIL8nvjHMjzAfBtA+fwoaxPzqkgEoCpqVS/QWIRRUc
dAFoHt9vW3DpF39fEMeL3uDbxOY5JrGobL8ak3kG1Zp1dHzMpZxM0G98ouz4ag5c
DruD8iPsMKwAPU+7WWi6kV3onPCGyA+7VVSNktBzqyJaNO+zEkpV39GvD5Ham85R
LkpSwkyLrEduL2GV/GItt6ckf+N4MGkg91WFrDt0iMWeAarccEOGLAzNIYxLmv7O
lNJvX2IGQYthjfpVOJZLGgXaMEd4JLY0FbI44SfInmr2u9ocB/Y5T11fNiUAqUf+
xtwqqd1BnrxpPCUh0nfls1Q5lOWO0hxMVPFAol36jUSN+CRcn5E=
=N6N2
-----END PGP SIGNATURE-----

--Apple-Mail=_C39C4FD5-7337-421E-8FC3-205BC014667B--


From nobody Mon Nov 20 01:52:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5933129511 for ; Mon, 20 Nov 2017 01:52:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level: 
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u_6qUhSheOz for ; Mon, 20 Nov 2017 01:52:24 -0800 (PST)
Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B6812762F for ; Mon, 20 Nov 2017 01:52:24 -0800 (PST)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 9D98C100DF8; Mon, 20 Nov 2017 10:52:22 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 7A9E180086; Mon, 20 Nov 2017 10:52:22 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 10:52:22 +0100
From: 
To: Ole Troan 
CC: Jen Linkova , 6man WG , Mark Andrews 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTYdpD3uy1rjGI6UW4xb2YAmW0iqMc+Ubw
Date: Mon, 20 Nov 2017 09:52:22 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org>
In-Reply-To: <0C83562D-859B-438C-9A90-2480BB166737@employees.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 09:52:26 -0000

Re-,

Please see inline.=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: Ole Troan [mailto:otroan@employees.org]
> Envoy=E9=A0: lundi 20 novembre 2017 09:34
> =C0=A0: BOUCADAIR Mohamed IMT/OLN
> Cc=A0: Jen Linkova; 6man WG; Mark Andrews
> Objet=A0: Re: IPv6 only host NAT64 requirements?
>=20
> Hi Med,
>=20
> >>
> >> For the IETF NAT64 IMHO
> >
> > [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the
> appropriate "IPv4 service continuity" solution here.
>=20
> Why not?

[Med] Because dual-stack can do the job without any extra effort.

> Interesting to hear your views here, especially since it "almost" worked
> at IETF100.

[Med] I don't have any doubt that NAT64 will work module some issues and fi=
xes (more can be found in https://tools.ietf.org/html/rfc6889#section-3 (An=
alysis of Stateful 64 Translation)). There are deployments cases where thes=
e fixes are wroth to be enforced, while it is not justified in others. I'm =
for NAT64 as an "IPv4 service continuity" for mobile networks where there i=
s a pressure on private IPv4 addresses, but I'm for DS-Lite and MAP-E for f=
ixed networks given there is no implications on the host itself; the "compl=
exity" will be hidden by a CPE.=20

It is a case by case exercise.

>=20
> > I need:
> >> - No dependency on DNS64. Want to use recursive resolver I trust plus
> >> local validating resolver.
> >> - Not depend on the success of PCP for NAT64 prefix discovery
> >> - If the host couldn't learn the NAT64 prefix any other way, I suppose
> it
> >> could throw an ICMP echo towards
> >>   64:ff9b::127.0.0.1 (or perhaps just 64:ff9b::)
> >>
> >
> > [Med] Fair. That is another "add my favorite solution" to the list.
> >
> >> But I also see there being different deployment options here.
> >> Btw, for multiple NSPs, couldn't you partly solve that by injecting
> more
> >> specifics into routing?
> >
> > [Med] It is not only about forwarding/routing, but also how a host can
> pick the appropriate prefix64 for address synthesis. Things may be obviou=
s
> if you can consider the example of RFC7050:
> >
> >
> >                      NAT64 "A" ----- IPv4-only servers in a data center
> >                     /
> >   IPv6-only node---<
> >                     \
> >                      NAT64 "B" ----- IPv4 Internet
>=20
> Firstly this seems like it is over engineered. Has anyone actually
> deployed NAT64 this way?

[Med] This is a scenario that can be considered by some mobile operators at=
 the Gi interface. Multiple prefixes are discussed in Section 4.2. of RFC72=
69 (NAT64 Deployment Options and Experience) that was produced by v6ops.

> (Given that this is quite rare even in IPv6 only or IPv4 only scenarios.
> Look at implementation status of RIO for example).
>=20
> Secondly, RFC7050 says:
>=20
>    The heuristic discovery method described herein does not support
>    learning of the possible rules used by a DNS64 server for mapping
>    specific IPv4 address ranges to separate Pref64::/n prefixes.
>    Therefore, nodes will use the same discovered Pref64::/n to
>    synthesize IPv6 addresses from any IPv4 address.  This can cause
>    issues for routing and connectivity establishment procedures.  The
>    operator of the NAT64 and the DNS64 ought to take this into account
>    in the network design.
>=20
> Which to me reads, this just doesn't work.

[Med] Correct. This is one of the limitations of the heuristic approach. =20

>=20
> If we think NAT64 is a fundamental piece of technology to make progress o=
n
> the transition, then I think we should focus on making it as simple and
> deployable as possible.

[Med] NAT64 spec does not make any assumption about the deployment case. It=
s limitations are well-known and documented since years.=20

IMHO, the required pieces for "simple" deployment scenarios are out there:
- prefix discovery using the heuristic
- local address synthesis to solve issues related to address literals/refer=
rals.=20

Advanced features have been also specified, e.g.,=20
- if you want to allow for incoming connections: e.g., access a video serve=
r
- if you want to avoid overloading NAT64 with all sorts of ALGs
- if you want to avoid draining the battery of your mobile because of the k=
eepalive messages
- ...

>=20
> Cheers,
> Ole


From nobody Mon Nov 20 02:38:06 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DD8129530 for ; Mon, 20 Nov 2017 02:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xS6bpCL7Eh7r for ; Mon, 20 Nov 2017 02:38:02 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C1C8120046 for ; Mon, 20 Nov 2017 02:38:02 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id E78EE2D5104; Mon, 20 Nov 2017 10:38:00 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 75160200C97B4B; Mon, 20 Nov 2017 11:37:57 +0100 (CET)
From: Ole Troan 
Message-Id: <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_024077A9-37BC-4D41-BCC1-4B0AC5C524BB"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 20 Nov 2017 11:37:56 +0100
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Cc: Jen Linkova , 6man WG , Mark Andrews 
To: Mohamed Boucadair 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 10:38:04 -0000

--Apple-Mail=_024077A9-37BC-4D41-BCC1-4B0AC5C524BB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Med,

>>>=20
>>> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the
>> appropriate "IPv4 service continuity" solution here.
>>=20
>> Why not?
>=20
> [Med] Because dual-stack can do the job without any extra effort.

That's not a valid answer, when the question to be explored is "Is it =
possible to run IPv6 only hosts?".

The arguments against dual stack:
 - expensive to operate
 - little progress towards the end goal of IPv6 only

I think you can make a fair case that the end-user experience today is =
best with IPv4 only.

>> Interesting to hear your views here, especially since it "almost" =
worked
>> at IETF100.
>=20
> [Med] I don't have any doubt that NAT64 will work module some issues =
and fixes (more can be found in =
https://tools.ietf.org/html/rfc6889#section-3 (Analysis of Stateful 64 =
Translation)). There are deployments cases where these fixes are wroth =
to be enforced, while it is not justified in others. I'm for NAT64 as an =
"IPv4 service continuity" for mobile networks where there is a pressure =
on private IPv4 addresses, but I'm for DS-Lite and MAP-E for fixed =
networks given there is no implications on the host itself; the =
"complexity" will be hidden by a CPE.
>=20
> It is a case by case exercise.

Again, trying to move us forward with IPv6 only hosts.

>>> I need:
>>>> - No dependency on DNS64. Want to use recursive resolver I trust =
plus
>>>> local validating resolver.
>>>> - Not depend on the success of PCP for NAT64 prefix discovery
>>>> - If the host couldn't learn the NAT64 prefix any other way, I =
suppose
>> it
>>>> could throw an ICMP echo towards
>>>>  64:ff9b::127.0.0.1 (or perhaps just 64:ff9b::)
>>>>=20
>>>=20
>>> [Med] Fair. That is another "add my favorite solution" to the list.
>>>=20
>>>> But I also see there being different deployment options here.
>>>> Btw, for multiple NSPs, couldn't you partly solve that by injecting
>> more
>>>> specifics into routing?
>>>=20
>>> [Med] It is not only about forwarding/routing, but also how a host =
can
>> pick the appropriate prefix64 for address synthesis. Things may be =
obvious
>> if you can consider the example of RFC7050:
>>>=20
>>>=20
>>>                     NAT64 "A" ----- IPv4-only servers in a data =
center
>>>                    /
>>>  IPv6-only node---<
>>>                    \
>>>                     NAT64 "B" ----- IPv4 Internet
>>=20
>> Firstly this seems like it is over engineered. Has anyone actually
>> deployed NAT64 this way?
>=20
> [Med] This is a scenario that can be considered by some mobile =
operators at the Gi interface. Multiple prefixes are discussed in =
Section 4.2. of RFC7269 (NAT64 Deployment Options and Experience) that =
was produced by v6ops.

You can achieve load-balancing without having to push that requirement =
all the way down to the host.

>> (Given that this is quite rare even in IPv6 only or IPv4 only =
scenarios.
>> Look at implementation status of RIO for example).
>>=20
>> Secondly, RFC7050 says:
>>=20
>>   The heuristic discovery method described herein does not support
>>   learning of the possible rules used by a DNS64 server for mapping
>>   specific IPv4 address ranges to separate Pref64::/n prefixes.
>>   Therefore, nodes will use the same discovered Pref64::/n to
>>   synthesize IPv6 addresses from any IPv4 address.  This can cause
>>   issues for routing and connectivity establishment procedures.  The
>>   operator of the NAT64 and the DNS64 ought to take this into account
>>   in the network design.
>>=20
>> Which to me reads, this just doesn't work.
>=20
> [Med] Correct. This is one of the limitations of the heuristic =
approach.
>=20
>>=20
>> If we think NAT64 is a fundamental piece of technology to make =
progress on
>> the transition, then I think we should focus on making it as simple =
and
>> deployable as possible.
>=20
> [Med] NAT64 spec does not make any assumption about the deployment =
case. Its limitations are well-known and documented since years.
>=20
> IMHO, the required pieces for "simple" deployment scenarios are out =
there:
> - prefix discovery using the heuristic
> - local address synthesis to solve issues related to address =
literals/referrals.
>=20
> Advanced features have been also specified, e.g.,
> - if you want to allow for incoming connections: e.g., access a video =
server
> - if you want to avoid overloading NAT64 with all sorts of ALGs
> - if you want to avoid draining the battery of your mobile because of =
the keepalive messages

Yep, but I think the cat is largely out of the bag here, and an =
application must work in the "smallest common denominator" network.

Cheers,
Ole

--Apple-Mail=_024077A9-37BC-4D41-BCC1-4B0AC5C524BB
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+/bDNdvtpYqJhC33YFAloSsIQACgkQvtpYqJhC
33Y09xAArCTiE3WUfFKHdIkG0Rxojpv4kDc2Cue5dmZdFG/vFGzQATUq5wnNbkmf
WPoBTJZzK9BiS2dLaPnLqE2BoVwK2sXyqQtW+xOuv6HObbEN3vR3JUXrplfKnKdj
fJXLysKBNJ1ipJbtxFahJ2hAPawdG8FRq82tcTUR0mcJ4k/zmuBYVdpzlqQr61oj
PZpuW2zJ3S35HU8jlbQGcT472V4Du4H3NFnqwWHpsst0Wnq98PXzIsfdZpHLMNn2
KfQdjkWtHtuILFapz9poMHeRi5eN5F/YbWcEjMgAL1GeLZNQYDc6/mtuazNgcVIt
Q5bT/ZEDISTMt+sJDPZAiYtBbpkfJUPgn1PcAPficKzuMgKAkxLaY0oJKzrirsX+
7Jv0NnLO2C/rHN6t9jJo2xtrEb8lw8nHfFz2PcBwSmh9nqW9T6V9oGq/a+giLZI3
XfiyWlFh+9s5FVy5reLWFFzFxaCV9q74L+fpP1K9wMMkeGcf6WH5RvmxWCwz5Yxg
9H0qN3swaHvVhHPtoRi5Lquv1kYe9H2t5deyjaZBnRL+AhkJp8RNLkzYEckoKhdM
S+h6Xq8NJO/W9fqIE2CgYWyxaoVNcZ71iZQ2N5snNWd+i+1xA2Na+LqMJHBwDXsI
YhU0IfScYcOzHaBn1w0/jJk2nlpDn4+UbmxePSQJq46slCyolAU=
=Kn6X
-----END PGP SIGNATURE-----

--Apple-Mail=_024077A9-37BC-4D41-BCC1-4B0AC5C524BB--


From nobody Mon Nov 20 03:12:25 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07F9127010 for ; Mon, 20 Nov 2017 03:12:23 -0800 (PST)
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 56DD7bRmc_wv for ; Mon, 20 Nov 2017 03:12:22 -0800 (PST)
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 28F98129540 for ; Mon, 20 Nov 2017 03:12:22 -0800 (PST)
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 3F60C3B1F24; Mon, 20 Nov 2017 11:12:17 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 0B1D5160053; Mon, 20 Nov 2017 11:12:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id EFE31160072; Mon, 20 Nov 2017 11:12:15 +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 QKHIGgz-624Z; Mon, 20 Nov 2017 11:12:15 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 0669D160053; Mon, 20 Nov 2017 11:12:14 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
From: Mark Andrews 
In-Reply-To: <1986EEC9-ED01-40D1-A1E6-3B7703A8ED34@employees.org>
Date: Mon, 20 Nov 2017 22:12:12 +1100
Cc: Mikael Abrahamsson , 6man WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>  <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>   <83B04565-4A62-47AE-90FA-13F9254C5A1C@isc.org> <1986EEC9-ED01-40D1-A1E6-3B7703A8ED34@employees.org>
To: Ole Troan 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 11:12:23 -0000

> On 20 Nov 2017, at 7:40 pm, Ole Troan  wrote:
>=20
> Mark,
>=20
>>>> The challenge we have in front of us is to make IPv6 only work.
>>>=20
>>> When I speak to vendors about this, I get different answers. Some =
are saying "nobody will deploy IPv6 only, so why should I make changes =
in my desktop OS to support it for legacy applications?=E2=80=9D
>>=20
>> Well as this stage you can say that there are ISP that are deploying =
IPv6-only on
>> the access network with DS-Lite to provide IPv4 as a service.  If you =
want your
>> host to be able to connect directly to such ISPs you need to add =
support to detect
>> that DS-Lite is in use (a IPv6 DHCP option) and bring up a IPv4 in =
IPv6 tunnel to
>> the ISPs B4 router.
>>=20
>> Repeat this for other transition technologies that you are aware is =
in use.
>>=20
>>> And I imagine any access provider will say "I can't deploy IPv6 =
only, because it'll break a lot of applications that people are using on =
desktop OSes".
>>>=20
>>> So this is classic catch 22.
>>=20
>> You stop talk ipv6-only and start talking ipv6-only access + ipv4 as =
a service.
>>=20
>> It=E2=80=99s only a =E2=80=9Ccatch 22=E2=80=9D because people fail to =
look at the options available.  ISPs
>> are going ipv6-only access + ipv4 as a service because it is easier =
to manage than
>> dual stack access + 44CGN.   Many ISPs deliver CPE routers that =
support DS-Lite
>> so the customer still see IPv4 + IPv6.
>>=20
>> The question to host vendors is =E2=80=9Cdo you want your machines to =
be able to connect
>> directly to ISP=E2=80=99s that have ipv6-only access networks or =
not?=E2=80=9D  Ipv6-only access
>> networks are a reality.
>=20
> =46rom the perspective of the host and the application, "IPv4 as a =
service" is hardly progress.
> (Progress being defined as something moving us towards an IPv6 only =
network).
>=20
> IPv4aaS offers dual stack to the hosts. Sure, it is typically carried =
over IPv6, and it allows the access network to use IPv6 transport. But =
from the perspective of delivering the service, it could as well have =
been ATM.

IPv4aaS delivers IPv6 connectivity to the customer net.  That is better =
than IPv4 only.  It moves the global percentage of IPv6 traffic upwards. =
 It allows customers to offer services on well known ports.  We need to =
reach 90 something percent IPv6 traffic before most people will be =
willing to turn off IPv4.

I=E2=80=99d prefer mechanisms that can be out sourced so ISPs can off =
the deliver of IPv4 as a service to someone else in the future.  The =
costs then go back onto only those that need to reach legacy only =
services.

> The other coin of IPv4aaS is that it is a mechanism that allows IPv4 =
to scale indefinitely.

There are limits to how many customers can share a IP address especially =
if you are allowing incoming connections by mapping ports to customers.  =
 Even stateless mapping, eyeball only, imposes costs.

> The tragicomedy of where we are at the moment is that an ISP would =
offer better service to the end-user network by delivering IPv4 only =
service over it's IPv4aaS infrastructure... we need to find a way to =
move off dual-stack.

Moving off dual stack will come.  It just hard to force it.  Encouraging =
every small step in the right direction is important.

I=E2=80=99m sure there are a couple of Summer of Code projects in going =
through the existing applications that make network connections and 1) =
adding IPv6 support if it doesn=E2=80=99t exist and 2) adding happy =
eyeball style connection creation where the application is {S}TCP based. =
 Contribute those changes back to the projects.

> Ole

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


From nobody Mon Nov 20 03:32:35 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89CE127010 for ; Mon, 20 Nov 2017 03:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0B74sIHlZo00 for ; Mon, 20 Nov 2017 03:32:32 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5588C1200FC for ; Mon, 20 Nov 2017 03:32:32 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id B839D2D508B; Mon, 20 Nov 2017 11:32:30 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0E75C200C9D742; Mon, 20 Nov 2017 12:32:29 +0100 (CET)
From: Ole Troan 
Message-Id: <2D7A9BB2-3F7D-4DB7-B574-4596AAE9C0F4@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_6D075E5C-4B11-45DF-BA9B-C58FE33D271B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 20 Nov 2017 12:32:27 +0100
In-Reply-To: 
Cc: Mikael Abrahamsson , 6man WG 
To: Mark Andrews 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com>  <8470b00f-ecc5-0a63-fd8f-a4e2f65a005d@gmail.com>   <83B04565-4A62-47AE-90FA-13F9254C5A1C@isc.org> <1986EEC9-ED01-40D1-A1E6-3B7703A8ED34@employees.org> 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 11:32:34 -0000

--Apple-Mail=_6D075E5C-4B11-45DF-BA9B-C58FE33D271B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Mark,

>> IPv4aaS offers dual stack to the hosts. Sure, it is typically carried =
over IPv6, and it allows the access network to use IPv6 transport. But =
from the perspective of delivering the service, it could as well have =
been ATM.
>=20
> IPv4aaS delivers IPv6 connectivity to the customer net.  That is =
better than IPv4 only.  It moves the global percentage of IPv6 traffic =
upwards.  It allows customers to offer services on well known ports.  We =
need to reach 90 something percent IPv6 traffic before most people will =
be willing to turn off IPv4.

But for _me_ on my local network, with my applications... I haven't =
found anything better with it...
examples?

> I=E2=80=99d prefer mechanisms that can be out sourced so ISPs can off =
the deliver of IPv4 as a service to someone else in the future.  The =
costs then go back onto only those that need to reach legacy only =
services.
>=20
>> The other coin of IPv4aaS is that it is a mechanism that allows IPv4 =
to scale indefinitely.
>=20
> There are limits to how many customers can share a IP address =
especially if you are allowing incoming connections by mapping ports to =
customers.   Even stateless mapping, eyeball only, imposes costs.

Not really. A+P gives you 48 bit addressing. ;-)
And especially not with upcoming new transport layers.
With traditional NAT, you burn one outside NAT port per multiple =
connections to same external destination:port.
We should ask CAIDA for an analysis.
Continuing to scale IPv4 is possible. It's not going to be free... far =
from it, but that seems to be where we're backwards walking ourselves =
into.

>> The tragicomedy of where we are at the moment is that an ISP would =
offer better service to the end-user network by delivering IPv4 only =
service over it's IPv4aaS infrastructure... we need to find a way to =
move off dual-stack.
>=20
> Moving off dual stack will come.  It just hard to force it.  =
Encouraging every small step in the right direction is important.

But I think we should encourage it, we should make it as edible as =
possible, and we should try to push the burden of interoperability over =
to the laggards.

> I=E2=80=99m sure there are a couple of Summer of Code projects in =
going through the existing applications that make network connections =
and 1) adding IPv6 support if it doesn=E2=80=99t exist and 2) adding =
happy eyeball style connection creation where the application is {S}TCP =
based.  Contribute those changes back to the projects.

As I said we didn't find many applications during the hackathon.
The main culprits in my home is bath scale, light bulbs, weather =
stations.
The other culprits are the plethora of open source projects around VM =
and container networking, those are largely IPv4 NAT based.

Cheers,
Ole

--Apple-Mail=_6D075E5C-4B11-45DF-BA9B-C58FE33D271B
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+/bDNdvtpYqJhC33YFAloSvUsACgkQvtpYqJhC
33bZrRAAzPlz96ELEJSFcuxKFGyNLKVkSEIZqT9zX5vRWRryG+JXfx4LHJQ/iqCy
8p4Fey8FialobTMAb6wDoG1gCGGNbxgbB5FAMQTAuQvyw6c7Ko/WfyeFSYHv7ehP
qusPO0NApxttjxCIr1DL7f9lmO6tPzzYPe+Pu55PtWOIkEPgKHuCmYGbq+4x7cwh
UA30UeZ5Oc8fuokSC+HEgppcW6umCVZct7MdobkqV18Fy3ZwpOOxbcfsdJxSrmOW
CerYfn3y4BDXrANxf+JTY/jWywScq8aihj1T+lPJW1MGmuBioDCHvbG/R6SdNn0p
++bJH+KLed7fFlq5jJ5LoLqyr0q0v0yqVzwMFVsAD8DFKcUSNTvo1/TqSlQlTwV4
F6eDoJHxI9Vbk65o0Jep/uNXyDtjL+O9BdXx8WWEnR1VE+fXNJot+XrprQchIKTd
SbexdnJD0vA0cHRz+3qDSDcX6kWXfsu/YwvRI6orc+73/F3tmEy8CSOD2ZsDicGy
8W1nw2gG07kMD7Dd4/WpZlH9ETP3RGWO8rp4m7LwCrDDP2yK3w44yHnw8ZC46097
vDytFV3XfH6d7FvUXDMw/w8qLAVBzZLJPEm1ptx1KExAjQbXt57w3nMtHVhDB0cr
P21rmaqmrn7C0UM3gGxI98aj+sEVqjKFNFyilBkbFg0ixgYM9rs=
=d2fi
-----END PGP SIGNATURE-----

--Apple-Mail=_6D075E5C-4B11-45DF-BA9B-C58FE33D271B--


From nobody Mon Nov 20 04:21:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10B4129568 for ; Mon, 20 Nov 2017 04:21:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level: 
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zt3rF12J93ZN for ; Mon, 20 Nov 2017 04:21:31 -0800 (PST)
Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00C01200FC for ; Mon, 20 Nov 2017 04:21:30 -0800 (PST)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 39B2840E57; Mon, 20 Nov 2017 13:21:29 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 1AE201C0070; Mon, 20 Nov 2017 13:21:29 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 13:21:28 +0100
From: 
To: Ole Troan 
CC: Jen Linkova , 6man WG , Mark Andrews 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTYeum5aCFTrEcrUibDPVkNExo9aMdK0uA
Date: Mon, 20 Nov 2017 12:21:27 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org>
In-Reply-To: <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 12:21:33 -0000

Re-,

Please see inline.=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: Ole Troan [mailto:otroan@employees.org]
> Envoy=E9=A0: lundi 20 novembre 2017 11:38
> =C0=A0: BOUCADAIR Mohamed IMT/OLN
> Cc=A0: Jen Linkova; 6man WG; Mark Andrews
> Objet=A0: Re: IPv6 only host NAT64 requirements?
>=20
> Med,
>=20
> >>>
> >>> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the
> >> appropriate "IPv4 service continuity" solution here.
> >>
> >> Why not?
> >
> > [Med] Because dual-stack can do the job without any extra effort.
>=20
> That's not a valid answer, when the question to be explored is "Is it
> possible to run IPv6 only hosts?".

[Med] You should admit that there are questions that don't make sense if no=
t contextualized. =20

>=20
> The arguments against dual stack:
>  - expensive to operate
>  - little progress towards the end goal of IPv6 only

[Med] These are generic statements, Ole. We are talking about the IETF case=
.=20
* The IETF has no control on the hosts that connect to the IETF network,
* IETF attendees who are using corporate devices, have no control on these =
hosts

So, how forcing devices to use "IPv6+nat64" will help here?=20

>=20
> I think you can make a fair case that the end-user experience today is
> best with IPv4 only.

[Med] It depends for "which user", Ole. Consider the example of a bittorren=
t user who may prefer IPv6 vs. IPv4.

>=20
> >> Interesting to hear your views here, especially since it "almost"
> worked
> >> at IETF100.
> >
> > [Med] I don't have any doubt that NAT64 will work module some issues an=
d
> fixes (more can be found in https://tools.ietf.org/html/rfc6889#section-3
> (Analysis of Stateful 64 Translation)). There are deployments cases where
> these fixes are wroth to be enforced, while it is not justified in others=
.
> I'm for NAT64 as an "IPv4 service continuity" for mobile networks where
> there is a pressure on private IPv4 addresses, but I'm for DS-Lite and
> MAP-E for fixed networks given there is no implications on the host
> itself; the "complexity" will be hidden by a CPE.
> >
> > It is a case by case exercise.
>=20
> Again, trying to move us forward with IPv6 only hosts.
>=20
> >>> I need:
> >>>> - No dependency on DNS64. Want to use recursive resolver I trust plu=
s
> >>>> local validating resolver.
> >>>> - Not depend on the success of PCP for NAT64 prefix discovery
> >>>> - If the host couldn't learn the NAT64 prefix any other way, I
> suppose
> >> it
> >>>> could throw an ICMP echo towards
> >>>>  64:ff9b::127.0.0.1 (or perhaps just 64:ff9b::)
> >>>>
> >>>
> >>> [Med] Fair. That is another "add my favorite solution" to the list.
> >>>
> >>>> But I also see there being different deployment options here.
> >>>> Btw, for multiple NSPs, couldn't you partly solve that by injecting
> >> more
> >>>> specifics into routing?
> >>>
> >>> [Med] It is not only about forwarding/routing, but also how a host ca=
n
> >> pick the appropriate prefix64 for address synthesis. Things may be
> obvious
> >> if you can consider the example of RFC7050:
> >>>
> >>>
> >>>                     NAT64 "A" ----- IPv4-only servers in a data cente=
r
> >>>                    /
> >>>  IPv6-only node---<
> >>>                    \
> >>>                     NAT64 "B" ----- IPv4 Internet
> >>
> >> Firstly this seems like it is over engineered. Has anyone actually
> >> deployed NAT64 this way?
> >
> > [Med] This is a scenario that can be considered by some mobile operator=
s
> at the Gi interface. Multiple prefixes are discussed in Section 4.2. of
> RFC7269 (NAT64 Deployment Options and Experience) that was produced by
> v6ops.
>=20
> You can achieve load-balancing without having to push that requirement al=
l
> the way down to the host.

[Med] I know. There is no reco to achieve NAT64 load-balancing. It is legit=
imate to hear from both of them.=20

>=20
> >> (Given that this is quite rare even in IPv6 only or IPv4 only
> scenarios.
> >> Look at implementation status of RIO for example).
> >>
> >> Secondly, RFC7050 says:
> >>
> >>   The heuristic discovery method described herein does not support
> >>   learning of the possible rules used by a DNS64 server for mapping
> >>   specific IPv4 address ranges to separate Pref64::/n prefixes.
> >>   Therefore, nodes will use the same discovered Pref64::/n to
> >>   synthesize IPv6 addresses from any IPv4 address.  This can cause
> >>   issues for routing and connectivity establishment procedures.  The
> >>   operator of the NAT64 and the DNS64 ought to take this into account
> >>   in the network design.
> >>
> >> Which to me reads, this just doesn't work.
> >
> > [Med] Correct. This is one of the limitations of the heuristic approach=
.
> >
> >>
> >> If we think NAT64 is a fundamental piece of technology to make progres=
s
> on
> >> the transition, then I think we should focus on making it as simple an=
d
> >> deployable as possible.
> >
> > [Med] NAT64 spec does not make any assumption about the deployment case=
.
> Its limitations are well-known and documented since years.
> >
> > IMHO, the required pieces for "simple" deployment scenarios are out
> there:
> > - prefix discovery using the heuristic
> > - local address synthesis to solve issues related to address
> literals/referrals.
> >
> > Advanced features have been also specified, e.g.,
> > - if you want to allow for incoming connections: e.g., access a video
> server
> > - if you want to avoid overloading NAT64 with all sorts of ALGs
> > - if you want to avoid draining the battery of your mobile because of
> the keepalive messages
>=20
> Yep, but I think the cat is largely out of the bag here, and an
> application must work in the "smallest common denominator" network.

[Med] More concretely?=20

>=20
> Cheers,
> Ole


From nobody Mon Nov 20 05:37:03 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0411298BA for ; Mon, 20 Nov 2017 05:37:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAfsrtlZmFJB for ; Mon, 20 Nov 2017 05:37:00 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B101267BB for ; Mon, 20 Nov 2017 05:37:00 -0800 (PST)
Received: from h.hanazo.no (unknown [173.38.220.35]) (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 AA9A12D5038; Mon, 20 Nov 2017 13:36:59 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 4B957200CAD856; Mon, 20 Nov 2017 14:36:54 +0100 (CET)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_162733EB-6FCA-4157-9AC3-509305E430E3"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 20 Nov 2017 14:36:53 +0100
In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Cc: Jen Linkova , 6man WG , Mark Andrews 
To: Mohamed Boucadair 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 13:37:02 -0000

--Apple-Mail=_162733EB-6FCA-4157-9AC3-509305E430E3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Med,

>>>>> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be =
the
>>>> appropriate "IPv4 service continuity" solution here.
>>>>=20
>>>> Why not?
>>>=20
>>> [Med] Because dual-stack can do the job without any extra effort.
>>=20
>> That's not a valid answer, when the question to be explored is "Is it
>> possible to run IPv6 only hosts?".
>=20
> [Med] You should admit that there are questions that don't make sense =
if not contextualized.

Freely admitted. Although I thought that was made clear both earlier in =
thread and by subject. ;)

>> The arguments against dual stack:
>> - expensive to operate
>> - little progress towards the end goal of IPv6 only
>=20
> [Med] These are generic statements, Ole. We are talking about the IETF =
case.
> * The IETF has no control on the hosts that connect to the IETF =
network,
> * IETF attendees who are using corporate devices, have no control on =
these hosts
>=20
> So, how forcing devices to use "IPv6+nat64" will help here?

Eat own dogfood. Many IETF people are developers or work for companies =
having applications not working.
As I said there were a minimum of applications that didn't work. =
Corporate VPNs largely did. Jen has the final numbers.

[...]

>>> Advanced features have been also specified, e.g.,
>>> - if you want to allow for incoming connections: e.g., access a =
video
>> server
>>> - if you want to avoid overloading NAT64 with all sorts of ALGs
>>> - if you want to avoid draining the battery of your mobile because =
of
>> the keepalive messages
>>=20
>> Yep, but I think the cat is largely out of the bag here, and an
>> application must work in the "smallest common denominator" network.
>=20
> [Med] More concretely?

- ALGs do more harm than gain. Applications have been forced to deal =
with NAT traversal. As in ICE/STUN/TURN.
  Applications must work with any NAT also those without ALGs. ALGs are =
dead.
- For the applications that need the keepalive wouldn't they send =
traffic anyway, so that it wouldn't be an additional battery drain.
  Example of application that doesn't?
- Incoming connections? Didn't think we did that on the Internet =
anymore? :-(
  That's static configuration in one case, and for the other symmetric =
hole punching (as in the ICE/STUN case).

Would PCP have helped, yes, possibly, but given that applications must =
work without it anyway...

Cheers,
Ole




--Apple-Mail=_162733EB-6FCA-4157-9AC3-509305E430E3
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+/bDNdvtpYqJhC33YFAloS2nUACgkQvtpYqJhC
33aAHBAAlc+YUbF8bStycSXIA07fCAVTCkkt6hFHFztTd+3oMh+G0npPCQMQGcGV
1BjgrsM71pShpFuMm6/UHo6vCOXT0mkCnpFd+tDBXfLCElpHUYOrzlfJ303Ylvh/
+yRen11sJlhV7l/uOsEz7rqku6LrQkZTZxFyuvslIZNhJQsp4Pby9BWOufDyKA6R
TEXdnMoWlptouGTBXSxMCXb4zF800Fp0lvu14EDv4GPCnqn+OKBM8tSjkeC1u0M3
mckto3lTzSop8jtfs+RVhWd5cX2Hybia9IBWqXADEVqfv6RhOy2zyw7+xiPuWTgV
9QoNwcXGMsJyy4lcVToty26xedyuuB7QnbCT6oGg1LOuwGxOw8Z3Pn/loWU21tLT
k+h26zId/KPeFV1j306HFj1/KqIL/faoG0yxNJjLojkfPLGGZhAPrVCwS/6vx0ZY
BO5KddZNtKB2eABQ9rlDrjCGiIW+eX5Y905jstYnR3e1C70qYzGYXc9x1+WEGQga
Brh1yFwgCN68GyQ9/uLL8ywPItnfpa5NSFGmBDBEe/+jk1S6fQf53tLoSLhwqHo4
+FTNgCyZxBP4eks9FBS4DR8p149A1/bIKqUTELLLKQCMY2cvLL0Nl8r7YiTWvJ9G
SpVsfnDIGo54mwFoPhf0jZffEreKnaRdMjUtHAXI97eo2UqV3Gc=
=54PC
-----END PGP SIGNATURE-----

--Apple-Mail=_162733EB-6FCA-4157-9AC3-509305E430E3--


From nobody Mon Nov 20 06:04:46 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E07126C0F for ; Mon, 20 Nov 2017 06:04:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 N2HWI0jKzwh9 for ; Mon, 20 Nov 2017 06:04:43 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9ABD129A9B for ; Mon, 20 Nov 2017 06:04:43 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id ED99120072 for ; Mon, 20 Nov 2017 09:06:41 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 060AD829D1 for ; Mon, 20 Nov 2017 09:04:43 -0500 (EST)
From: Michael Richardson 
To: 6man WG 
Subject: Re: IPv6 only host NAT64 requirements?
In-Reply-To: <0C83562D-859B-438C-9A90-2480BB166737@employees.org>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 14:04:45 -0000

--=-=-=
Content-Type: text/plain


Ole Troan  wrote:
    >> NAT64 "A" ----- IPv4-only servers in a data center
    >> /
    >> IPv6-only node---<
    >> \
    >> NAT64 "B" ----- IPv4 Internet

    > Firstly this seems like it is over engineered. Has anyone actually
    > deployed NAT64 this way?

Yes, it's a really good way to deal with overlapping RFC1918 ranges (used for
managing devices) in different data centers. (The boot server is always at
192.168.1.2, the serial console is always at 192.168.1.3, etc.)

I've done this as far back as 2008 (with "NAT64" being implemented by a TCP
proxy terminating the entire IPv6/32)

I didn't have to pick the right source address, but I can see how this might
be an issue.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloS4PoACgkQgItw+93Q
3WUIxgf7B95Mobl1N51mL1YBNo/CebiUVpZPf2aS5v0N+8IokWjx8AVWxsNSpD6V
8jliUWEEwNew6N1fuAYO4hwIWTmeemviaqFRg/cJt/BCSMEyAeqeut4nS8kEEV5x
2ObFTKEixrXo227/21+xrD2CFzjMRExIZbEBxWztXyo5GLsocxfZMVkOknJ7hfXe
vwtBXxWhvk4mzLqLGpspUku4gNiA/DY74Qwk8ovHpjhE5m8yNMiukcIPSFI40ySB
kPSy3jMPIW0fadn0y0Wx7ju363i4qdsrb++fY/TlGvguENKYwLBlckN9fAaU6L0E
Z1TCm/57UIYFUEXcQ4KwK8QYufJqQw==
=YmH1
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Nov 20 06:09:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4DD1296B0 for ; Mon, 20 Nov 2017 06:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TR5g3g18maZU for ; Mon, 20 Nov 2017 06:09:41 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71CB129A9C for ; Mon, 20 Nov 2017 06:09:40 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAKE9cY4005931 for ; Mon, 20 Nov 2017 15:09:38 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B4F6B20876E for ; Mon, 20 Nov 2017 15:09:38 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id ABCFB2086FA for ; Mon, 20 Nov 2017 15:09:38 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAKE9ccT029328 for ; Mon, 20 Nov 2017 15:09:38 +0100
Subject: Re: IPv6 only host NAT64 requirements?
To: ipv6@ietf.org
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 
From: Alexandre Petrescu 
Message-ID: <32ebefa2-219b-83a6-ecc8-068ed96f71da@gmail.com>
Date: Mon, 20 Nov 2017 15:09:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 14:09:47 -0000

Le 20/11/2017 à 14:36, Ole Troan a écrit :
> Med,
> 
>>>>>> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the
>>>>> appropriate "IPv4 service continuity" solution here.
>>>>>
>>>>> Why not?
>>>>
>>>> [Med] Because dual-stack can do the job without any extra effort.
>>>
>>> That's not a valid answer, when the question to be explored is "Is it
>>> possible to run IPv6 only hosts?".
>>
>> [Med] You should admit that there are questions that don't make sense if not contextualized.
> 
> Freely admitted. Although I thought that was made clear both earlier in thread and by subject. ;)
> 
>>> The arguments against dual stack:
>>> - expensive to operate
>>> - little progress towards the end goal of IPv6 only
>>
>> [Med] These are generic statements, Ole. We are talking about the IETF case.
>> * The IETF has no control on the hosts that connect to the IETF network,
>> * IETF attendees who are using corporate devices, have no control on these hosts
>>
>> So, how forcing devices to use "IPv6+nat64" will help here?
> 
> Eat own dogfood. Many IETF people are developers or work for companies having applications not working.

Agreed.

> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.

My VPN did not work and I wont be able to make my employer change the VPN.

Alex

> 
> [...]
> 
>>>> Advanced features have been also specified, e.g.,
>>>> - if you want to allow for incoming connections: e.g., access a video
>>> server
>>>> - if you want to avoid overloading NAT64 with all sorts of ALGs
>>>> - if you want to avoid draining the battery of your mobile because of
>>> the keepalive messages
>>>
>>> Yep, but I think the cat is largely out of the bag here, and an
>>> application must work in the "smallest common denominator" network.
>>
>> [Med] More concretely?
> 
> - ALGs do more harm than gain. Applications have been forced to deal with NAT traversal. As in ICE/STUN/TURN.
>    Applications must work with any NAT also those without ALGs. ALGs are dead.
> - For the applications that need the keepalive wouldn't they send traffic anyway, so that it wouldn't be an additional battery drain.
>    Example of application that doesn't?
> - Incoming connections? Didn't think we did that on the Internet anymore? :-(
>    That's static configuration in one case, and for the other symmetric hole punching (as in the ICE/STUN case).
> 
> Would PCP have helped, yes, possibly, but given that applications must work without it anyway...
> 
> Cheers,
> Ole
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Mon Nov 20 06:27:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E66129AA3 for ; Mon, 20 Nov 2017 06:27:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM-lETvXio1o for ; Mon, 20 Nov 2017 06:27:50 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B48129A9C for ; Mon, 20 Nov 2017 06:27:50 -0800 (PST)
Received: from h.hanazo.no (unknown [173.38.220.35]) (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 6AE842D513A; Mon, 20 Nov 2017 14:27:50 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id DF4A0200CB3166; Mon, 20 Nov 2017 15:27:44 +0100 (CET)
From: Ole Troan 
Message-Id: <653854F1-4F76-42AD-B476-FBA0C7858D9C@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_34CD0AE9-2BDB-446B-A521-CF37FF8FAC66"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 20 Nov 2017 15:27:43 +0100
In-Reply-To: <29312.1511186682@obiwan.sandelman.ca>
Cc: 6man WG 
To: Michael Richardson 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <29312.1511186682@obiwan.sandelman.ca>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 14:27:53 -0000

--Apple-Mail=_34CD0AE9-2BDB-446B-A521-CF37FF8FAC66
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Michael,

At the risk of making the 6man list into behave...

>>> NAT64 "A" ----- IPv4-only servers in a data center
>>> /
>>> IPv6-only node---<
>>> \
>>> NAT64 "B" ----- IPv4 Internet
>=20
>> Firstly this seems like it is over engineered. Has anyone actually
>> deployed NAT64 this way?
>=20
> Yes, it's a really good way to deal with overlapping RFC1918 ranges =
(used for
> managing devices) in different data centers. (The boot server is =
always at
> 192.168.1.2, the serial console is always at 192.168.1.3, etc.)
>=20
> I've done this as far back as 2008 (with "NAT64" being implemented by =
a TCP
> proxy terminating the entire IPv6/32)
>=20
> I didn't have to pick the right source address, but I can see how this =
might
> be an issue.

Right, but how would a host know which NAT64 prefix to combine =
192.168.1.2 with?

Cheers,
Ole


--Apple-Mail=_34CD0AE9-2BDB-446B-A521-CF37FF8FAC66
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+/bDNdvtpYqJhC33YFAloS5l8ACgkQvtpYqJhC
33ZkJA/+JbbadVNA+MyIyVnbSrqwKxhwpCSU9clRdyScWnm652LSg03bk2x2MRSF
VXglitgbd8GkEkcpS/xi8NZC/ZQDJfWifsgo8NchgiGFPoX2eNa/lnOp0P90yemz
IG0H40v5PeM02M8MgWJi2vRjCvH0cii7I4/+5QoAyB9VnhmK1w0VBzOcuDqCRW1C
P+e1Ar5b5eCtrnBxNMyUR8ixc+Vc2gMwdbhsl8LSH6t6dkSx0L20eIwQLqYvSa9E
hyFLTzMtxMa5oKtoH6e9/ifIVWRpnAv79gg+itKT3Sbf2GvWC6Y1l2wVNa1C3bYn
PgKAv++ATt+zifpNkR2qM/pDeEv35cOgEbGrBQVR14hBV6E/CBPcgiqOIAM1O/Ox
9tiWr864A46TaI0235Qxlz6l8cS7HiDKY51qXFdSCCZiXFL3waeha/uEXwHR0PIr
VLeBcbg6SCSsJUVDxgcTpMtYv3mAjNsXkfqcZuSTvIOuOq0jRo6VJR6Mn134fq2l
EW7Eht0nFoXI0ArU72oDQItcjeB/LdoraqILfEDL4U1ORIjXfrdcnOBVqDzxnWK/
7emFDXekSOFIzTzCCNt/kSyEEQZBP3cuRvC+nlbrfqS6m6FyMDysSqKc+wjMKrld
o/KBmJCdt20Z90ArSE8/DnsoHbdr9L9Krm9rnHhkY8ebxJ391vQ=
=QepM
-----END PGP SIGNATURE-----

--Apple-Mail=_34CD0AE9-2BDB-446B-A521-CF37FF8FAC66--


From nobody Mon Nov 20 06:33:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A3D129A9C for ; Mon, 20 Nov 2017 06:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb9rJX_9N5dw for ; Mon, 20 Nov 2017 06:33:08 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFDF126C0F for ; Mon, 20 Nov 2017 06:33:07 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAKEX6bb018531 for ; Mon, 20 Nov 2017 15:33:06 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 43E1C208810 for ; Mon, 20 Nov 2017 15:33:06 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 31267201952 for ; Mon, 20 Nov 2017 15:33:06 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAKEX5Zc030760 for ; Mon, 20 Nov 2017 15:33:06 +0100
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: ipv6@ietf.org
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>   
From: Alexandre Petrescu 
Message-ID: <05ec66fb-e48f-b891-3c98-12fb5381bf35@gmail.com>
Date: Mon, 20 Nov 2017 15:33:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 14:33:09 -0000

Le 20/11/2017 à 08:51, Mikael Abrahamsson a écrit :
> On Mon, 20 Nov 2017, Lorenzo Colitti wrote:
> 
>> Sure. But you wouldn't need complicated infrastructure for this - if 
>> all that's necessary is to respond to a DHCPv4 request with a canned 
>> "no DHCPv4 here" packet that is always the same, that's a lot easier 
>> to deploy than a full DHCPv4 infrastructure.
> 
> This functionality doesn't exist today in any access network I know of. 

That may not exist, but the counterpart functionality of blocking all 
that is _not_ IPv4 may exist.

On my enterprise IPv4-only network my laptop's RJ45 leds did not even 
blink this morning.  It was because I had unchecked IPv4 on my Windows, 
because I used in the Terminal Room at IETF, which was IPv6 only.

I suppose the switches on my enterprise network block all RJ45 that dont 
reply to IPv4, and block them hardly (RJ45 leds are off).

Same laptop connected to a dumb hub had the leds on.

Alex

[snip]


From nobody Mon Nov 20 06:47:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D11C129A9C for ; Mon, 20 Nov 2017 06:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level: 
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe3TYS_DRKXT for ; Mon, 20 Nov 2017 06:47:15 -0800 (PST)
Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C85B129A90 for ; Mon, 20 Nov 2017 06:47:15 -0800 (PST)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id B54E44081B; Mon, 20 Nov 2017 15:47:13 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 95A981A007F; Mon, 20 Nov 2017 15:47:13 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 15:47:13 +0100
From: 
To: Ole Troan 
CC: Jen Linkova , 6man WG , Mark Andrews 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTYgSm9lmKEv6P8USKvynolT4dKKMdT7Sw
Date: Mon, 20 Nov 2017 14:47:12 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A07D800@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 14:47:17 -0000

Re-,

Please see inline.=20

Cheers,
Med

> -----Message d'origine-----
> De=A0: Ole Troan [mailto:otroan@employees.org]
> Envoy=E9=A0: lundi 20 novembre 2017 14:37
> =C0=A0: BOUCADAIR Mohamed IMT/OLN
> Cc=A0: Jen Linkova; 6man WG; Mark Andrews
> Objet=A0: Re: IPv6 only host NAT64 requirements?
>=20
> Med,
>=20
> >>>>> [Med] As you are mentioning "IETF" explicitly, NAT64 may not be the
> >>>> appropriate "IPv4 service continuity" solution here.
> >>>>
> >>>> Why not?
> >>>
> >>> [Med] Because dual-stack can do the job without any extra effort.
> >>
> >> That's not a valid answer, when the question to be explored is "Is it
> >> possible to run IPv6 only hosts?".
> >
> > [Med] You should admit that there are questions that don't make sense i=
f
> not contextualized.
>=20
> Freely admitted. Although I thought that was made clear both earlier in
> thread and by subject. ;)
>=20
> >> The arguments against dual stack:
> >> - expensive to operate
> >> - little progress towards the end goal of IPv6 only
> >
> > [Med] These are generic statements, Ole. We are talking about the IETF
> case.
> > * The IETF has no control on the hosts that connect to the IETF network=
,
> > * IETF attendees who are using corporate devices, have no control on
> these hosts
> >
> > So, how forcing devices to use "IPv6+nat64" will help here?
>=20
> Eat own dogfood. Many IETF people are developers or work for companies
> having applications not working.
> As I said there were a minimum of applications that didn't work. Corporat=
e
> VPNs largely did. Jen has the final numbers.=20
>=20
> [...]
>=20
> >>> Advanced features have been also specified, e.g.,
> >>> - if you want to allow for incoming connections: e.g., access a video
> >> server
> >>> - if you want to avoid overloading NAT64 with all sorts of ALGs
> >>> - if you want to avoid draining the battery of your mobile because of
> >> the keepalive messages
> >>
> >> Yep, but I think the cat is largely out of the bag here, and an
> >> application must work in the "smallest common denominator" network.
> >
> > [Med] More concretely?
>=20
> - ALGs do more harm than gain.

[Med] Fully agree.=20

 Applications have been forced to deal with
> NAT traversal. As in ICE/STUN/TURN.

[Med] I used to know that ICE failure rate for webrtc, for example, is high=
. I don't know if that situation changed since then. =20

>   Applications must work with any NAT also those without ALGs. ALGs are
> dead.
> - For the applications that need the keepalive wouldn't they send traffic
> anyway, so that it wouldn't be an additional battery drain.
>   Example of application that doesn't?

[Med] You can consider the example of a SIP application that send keepalive=
s even if there no ongoing media session. If that application knows the ass=
igned lifetime, it will adjust according.=20

The problem is about the default value of the keepalive message. For exampl=
e, ipsec uses 20s. Other protocols are setting this value to 15s or 30s. Be=
low an excerpt of the impact on the battery as a function of the default va=
lue:

                According to [Power], the consumption of a cellular
                device with a keep-alive interval equal to 20 seconds
                (which is the default value in [RFC3948], for example)
                is 29 mA (2G) / 34 mA (3G).  This consumption is reduced
                to 16 mA (2G) / 24 mA (3G) when the interval is
                increased to 40 seconds, to 9.1 mA (2G) / 16 mA (3G) if
                the interval is equal to 150 seconds, and to 7.3 mA (2G)
                / 14 mA (3G) if the interval is equal to 180 seconds.
                When no keep-alive is issued, the consumption would be
                5.2 mA (2G) / 6.1 mA (3G).  The impact of keepalive
                messages would be more severe if multiple applications
                are issuing those messages (e.g., SIP, IPsec, etc.).

> - Incoming connections? Didn't think we did that on the Internet anymore?
> :-(
>   That's static configuration in one case, and for the other symmetric
> hole punching (as in the ICE/STUN case).
>=20
> Would PCP have helped, yes, possibly, but given that applications must
> work without it anyway...
>=20
> Cheers,
> Ole
>=20
>=20


From nobody Mon Nov 20 06:50:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47466129A9F for ; Mon, 20 Nov 2017 06:50:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8iNbl4-x4tc for ; Mon, 20 Nov 2017 06:50:09 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F37DF129A9C for ; Mon, 20 Nov 2017 06:50:08 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAKEo6Fq028048 for ; Mon, 20 Nov 2017 15:50:06 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A7B8920886A for ; Mon, 20 Nov 2017 15:50:06 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9DA732087A5 for ; Mon, 20 Nov 2017 15:50:06 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAKEo6QV022044 for ; Mon, 20 Nov 2017 15:50:06 +0100
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: ipv6@ietf.org
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  
From: Alexandre Petrescu 
Message-ID: 
Date: Mon, 20 Nov 2017 15:50:06 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 14:50:11 -0000

Le 19/11/2017 à 08:50, JORDI PALET MARTINEZ a écrit :
> Agree with your analysis, but the problem I see is that many WiFi 
> networks are very simple, even with high level of congestion, and 
> they may not be able to apply such simple filters. Even home
> networks may have the same issues.
> 
> One way or the other, hosts get updated frequently, but switches,
> APs and L2 infrastructure don’t, even CEs or small routers in many 
> hotspots don’t get updated.
> 
> Also, IPv4-only devices are typically never updated. For example,
> you buy today an IP camera, and is not easy to find one which is 
> dual-stack.

I tend to agree with this text, Jordi.

Recently I contacted a manufacturer of advanced camera-like lidars.
They do IPv4 only and broadcast to 255.255.255.255.  They request the
user to use closed circuits to avoid the noise due to broadcast.  They
said they dont have plans for IPv6 in the camera, in their roadmaps.

So we filed a ticket to add IPv6 in the device, hoping for some
resolution in a certain future.

Alex

  Of course, in this case the problem is different, because
> they will not work in a NAT64 IPv6-only network …
> 
> Because most of this traffic is created by laptops, tablets and 
> smartphones that are the ones with frequently get updated, may be
> the ideal solution will be something in the stack, not relaying in
> the router update (so not relaying in RA, options, etc.), that 
> automatically detects the lack of IPv4 support (trying to avoid fake 
> DHCP servers), so they automatically stop sending any IPv4 traffic, 
> or even using IPv4 link-local?
> 
> Regards, Jordi
> 
> 
> -----Mensaje original----- De: ipv6  en
> nombre de David Farmer  Responder a: 
> Fecha: sábado, 18 de noviembre de 2017, 22:07 Para: Brian E
> Carpenter  CC: 6man WG 
> Asunto: Re: problem statement [was Re: New Version Notification for 
> draft-hinden-ipv4flag-00.txt]
> 
> 
> 
> On Sat, Nov 18, 2017 at 1:59 PM, Brian E Carpenter 
>  wrote:
> 
> 
> Regards Brian Carpenter
> 
> On 19/11/2017 03:39, Jen Linkova wrote:
>> Hi Bob,
>> 
>> To be honest I'm not convinced that there is a real problem to be 
>> solved.. The draft says
>> 
>> 'A mechanism is needed  to inform hosts that there is no IPv4 
>> support and that they should turn off IPv4.' and it would be great 
>> to have more detailed problem statement IMHO...
> 
> Indeed. If there is no serious problem, don't fix. What I seemed to 
> hear in Singapore was that people weren't happy with just ignoring 
> the small amount of residual IPv4 traffic on ietf-nat64 (about 1% in 
> the measurement by Bob Hinden). However, from what I saw, most of it 
> is layer 2 broadcast traffic, which is more of a burden for the 
> infrastructure. We need to decide whether we care.
> 
> (As to whether this belongs in 6man or sunset4, that's a secondary 
> question. As for the other comments on this thread, I am too jet 
> lagged to respond right now... later.)
> 
> Brian
> 
> 
> 
> Here is some analysis of the issues as I see them, hopefully this
> can help lead us toward a problem statement;
> 
> I believe there are two separate issues here;
> 
> 1. Security exposure; the inverse of the problems discussed in 
> RFC7123, basically malicious or accidental IPv4 service. 2. Residual 
> IPv4 traffic, especially broadcast traffic; DHCP solicits, IPv4-LL, 
> ARP, service discovery, etc...
> 
> There are several solutions available already;
> 
> A. Filter Ethertypes 0x0800 and 0x806 altogether B. Rogue DHCP
> server filtering or DHCP snooping C. Proxy ARP D. Service Discovery
> Proxy or Filtering
> 
> How much of an actual problem the issues are and the efficacy of 
> solutions depends on the type of network technology and the 
> environment its used in;
> 
> For wired networks, the residual IPv4 traffic, even the fact that 
> it's mostly broadcast, isn't a significant issue.  The primary 
> problem in here is the security exposure, and solution B is usually 
> sufficient protection, but if that isn't, solution A will totally 
> eliminate this risk.
> 
> For WiFi networks it's a little more complicate; low density WiFi 
> environments are similar to wired networks, the primary issue being 
> the security exposure, with the same solutions, discussed above. 
> However, there is an additional secondary issue, the residual IPv4 
> broadcast traffic could unnecessarily impact other devices, 
> especially battery powered devices. Frequently, at least in 
> enterprise WiFi networks, solutions C and D are implemented to
> reduce the impact of IPv4 broadcast traffic in operational WiFi
> networks, they will have the same effect on the residual IPv4
> broadcast traffic in this case.  But, again solution A implemented
> within the WiFi network will totally eliminate both the security
> exposure and the impact of broadcast traffic on other devices.
> 
> However, the residual IPv4 traffic still consumes radio airtime,
> even if the WiFi network discards the traffic. In very high dentistry
> and therefore typically congested WiFi environments this unnecessary 
> traffic only increase the over-the-air congestion. Furthermore, 
> broadcast traffic in a WiFi networks consume more airtime that 
> comparable unicast traffic (worst case as much as 300 times, but 
> 10-50 times is very typical), increasing the impact of the residual 
> IPv4 traffic that is mostly broadcast. Only a solution that keep 
> hosts from generating the residual IPv4 traffic in the first place 
> can help reduce over-the-air congestion in these environments.
> 
> 
> 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  
> ===============================================
> 
> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 
> 
> 
> 
> ********************************************** IPv4 is over 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.
> 
> 
> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 


From nobody Mon Nov 20 06:54:10 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0EA129A90 for ; Mon, 20 Nov 2017 06:54:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y46LvZOfLUHJ for ; Mon, 20 Nov 2017 06:54:06 -0800 (PST)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9874F126C0F for ; Mon, 20 Nov 2017 06:54:06 -0800 (PST)
Received: by mail-ua0-x234.google.com with SMTP id 21so6043309uas.13 for ; Mon, 20 Nov 2017 06:54:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=BbuV4uDc5EOSSn1HRIXWfZx/aXIh/l66yx65DHP2tzA=; b=HDRY6vmtxgCamPQZHj2Dl1Aamiit3zBSNyZYIOVWTkbNer9lnYd5i6lRLjbVZAfldu RuhewqtWM+NUgDXCJzsTQZ0Q/7hA+8S9n+oWXSRBqoKIbntRI4CEn7ot2sFROQbtUjXN V4q+F1rDHKutmD6plPs3+9bQJO8BdyxNtqoCQyh1K9wBHnR04R+tfRSjBqvme2+bEs8r rjlpIVrq5Q3qAg1a3iux2wSVZxYvBPIaXwRwYreeJXHCTu8S9UjWtkh55v4BXo5Ax+WH r5QorrWlJQwb1wgayrsb99Sw61Aad1jpqLsDh/MN7KqBbG0roPD7WykNgQZn48VCIFqC zEEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=BbuV4uDc5EOSSn1HRIXWfZx/aXIh/l66yx65DHP2tzA=; b=r3mlLitedP4h40mXzsZljYBcTmuwnm2LvVFOZBOu4d+N2pQXR0kY2tOg69lWGY0hD6 XVEnQ5hyH7nZgXG2dSCSWAGMZ16TsPjHN5fWxC50e6Z3mCjNvhRb2uhkcNAEHqpa/Hgf m5HZMJkbHzTFPnpiGsWcEGzaRCPYZjyBIjawLJ4AbAoxCMYlGES0jNy3UnqVg7S+8KXO vCdJhjuI8U1C9YHpFWOEpNrefLSLBrGW9I1jCDMDA5lFhdY8GTJHFJJNdYeX0t6Mw8rB xScJbDSgu9eZUOxOMgMRHgl+vl3QIApQqAcvi9bAMuWQ4KsrVXizb/j+5MhQ8zEjBy/d 8RdQ==
X-Gm-Message-State: AJaThX68HKtqZ24whIpRwZqUWbC7BGpLMebqAAzJkhS70Vnylg/xXzHr +vE4ptW8M7tOaFg+dAgbWhF9nILC
X-Google-Smtp-Source: AGs4zMbuTTr1d9ABte0XX2BBEmiJxFEHCh4LGGnd8s0lXkP13DVEnfqoOJT76zuLk9niE+TNFyskAA==
X-Received: by 10.159.34.238 with SMTP id 101mr12283809uan.141.1511189645223;  Mon, 20 Nov 2017 06:54:05 -0800 (PST)
Received: from MacBook-Pro-de-admin-alejandro.local ([190.142.55.3]) by smtp.gmail.com with ESMTPSA id 5sm2772883vkh.10.2017.11.20.06.54.04 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 06:54:04 -0800 (PST)
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: ipv6@ietf.org
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <05ec66fb-e48f-b891-3c98-12fb5381bf35@gmail.com>
From: Alejandro Acosta 
Message-ID: <4d9c0872-2402-f4da-5b9f-6d33cb010f4b@gmail.com>
Date: Mon, 20 Nov 2017 10:54:02 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <05ec66fb-e48f-b891-3c98-12fb5381bf35@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: es-ES
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 14:54:08 -0000

Hello,


El 20/11/17 a las 10:33 a.m., Alexandre Petrescu escribió:
>
>
> Le 20/11/2017 à 08:51, Mikael Abrahamsson a écrit :
>> On Mon, 20 Nov 2017, Lorenzo Colitti wrote:
>>
>>> Sure. But you wouldn't need complicated infrastructure for this - if
>>> all that's necessary is to respond to a DHCPv4 request with a canned
>>> "no DHCPv4 here" packet that is always the same, that's a lot easier
>>> to deploy than a full DHCPv4 infrastructure.
>>
>> This functionality doesn't exist today in any access network I know of. 
>
> That may not exist, but the counterpart functionality of blocking all
> that is _not_ IPv4 may exist.
>
> On my enterprise IPv4-only network my laptop's RJ45 leds did not even
> blink this morning.  It was because I had unchecked IPv4 on my
> Windows, because I used in the Terminal Room at IETF, which was IPv6
> only.
>
> I suppose the switches on my enterprise network block all RJ45 that
> dont reply to IPv4, and block them hardly (RJ45 leds are off).

What a interesting situation..., may I ask which switches are you using?
(if you don't want to mention it publicly I accept unicast)



>
> Same laptop connected to a dumb hub had the leds on.
>
> Alex
>
> [snip]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Mon Nov 20 07:59:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7803129B22 for ; Mon, 20 Nov 2017 07:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v80-pjxbXYg1 for ; Mon, 20 Nov 2017 07:59:37 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB126129B21 for ; Mon, 20 Nov 2017 07:59:36 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vAKExLaD097282 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Nov 2017 14:59:21 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local
Message-ID: <5A12FBE4.9030101@foobar.org>
Date: Mon, 20 Nov 2017 15:59:32 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Mikael Abrahamsson 
CC: IETF IPv6 Mailing List 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>   
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 15:59:40 -0000

Mikael Abrahamsson wrote:
> This functionality doesn't exist today in any access network I know of.
> It's also non-trivial to do considering how access networks are done.

Both of these statements also apply to encoding a no-ipv4 flag in an RA
message.

> Preferrably one would like to ahve an ethertype filter on the access
> port to only allow 0x86dd and nothing else. Then putting this flag into
> IPv4 means this isn't possible.

if you can filter everything except 0x86dd (or the equivalent for
different media, e.g. docsis, pppoe, etc), then the ipv4 problem
statement which draft-hinden-ipv4flag is intended to solve has already
been handled.

> IPv6 is the next generation IP protocol. I prefer that it can signal
> that the legacy version is not available, instead of having to keep
> legacy IP functionality around.
> 
> ... or we put it in some other L2 protocol, such as LLDP.

It comes down where in your stack you want to put your hacks.  A sentry
dhcpv4 agent is simple to define in terms of protocol scope, behaviour
and meaning, and has relatively well constrained requirements in terms
of the amount of ipv4 infrastructure required to sustain it (virtually
none, in the minimal case).

If you want to define and implement this functionality via some other
protocol, it requires potentially substantial complication on the client
side, as well as creating a requirement to define what is meant by "no
ipv4".  This, IIRC, was one of the issues that led to the sunset4 draft
not progressing further.

Nick


From nobody Mon Nov 20 11:37:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B493120713 for ; Mon, 20 Nov 2017 11:37:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S40ysdz2Bi6Z for ; Mon, 20 Nov 2017 11:37:31 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB57512EA81 for ; Mon, 20 Nov 2017 11:37:30 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id r62so8016913pfd.5 for ; Mon, 20 Nov 2017 11:37:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/QAj1Ar5KXUpwM7JMaK+4OkufHThGOQdXAhzCAG8WT0=; b=H1bf85nJP17r3BlbxCBFqyteAbZoeWTh+th/UlOtG+mAI9fvQozDzemtrhejeMdMz7 HiHEofTDH2jDfoFaGyQJ5ey8HA1qH0Hd6rDi01cBp0WkeFbxiXwZ12S/99FOeHSA6VEe rTnNxgKNAsr8BgPhguIBJqCCX2vzuFaACECATz1CryDNUSVN+6igVF/TFSiYOOXX5qj8 uvcRPwYQaYRu7EOKqRmP6iKnxepAOb0x/EWgHynYJ4Fs+fI7L5VYyhYJxEPwcFIn9tnS jOJFPi/LxtJaCDYXmQVFKtfCFN1vF6poJs1gJ2BqmFF+Yw1GDWXQrEw5Kau9WZ5/wmDp V1+w==
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=/QAj1Ar5KXUpwM7JMaK+4OkufHThGOQdXAhzCAG8WT0=; b=BWbg4yjWZbz1MdA49IcpPc3LHx7NCAN7JIEbUBxOa58u+8BXvAOXPb5iRwajYmLJGp Vac8bYsBM/QK4ZWVSahAuIZhyV60SDTsqsfyEgR6P9AbU7o55Fl2NVmSrmM5Ep2nwA8U VJKdItYfcEtMCoAn8CQ8niPcYPhigpz/R6+MKCzEnXaeZJF0XC+OrSUffAdyOYn1z9eG L3lCtBFDpjpw1/T7TuEaNJaYq/N9OmOneQtA5gXyGyz35j4UjngqVoRALpKS4pZs1sm5 kcYyQQ2Mq0IG8qfeVbxEHS2flI0EuW25BjSSUVLhuAib8lhf9n6gjCfNapdcwqbiVHoA 58Bg==
X-Gm-Message-State: AJaThX7oF6Q6nGdnQ65oHpsi/Cwa2iaCDA9eN5VTNMrD8CdDGyVnZTY/ FyFA8DFb54e07qo63nfw3NM=
X-Google-Smtp-Source: AGs4zMasCus2cOXTr78O+EAkIjUb2lWSvxVRnNCN+nqujwhP5EFayo0er8BU7jls19qz5uhKvF/sHA==
X-Received: by 10.98.247.26 with SMTP id h26mr12275282pfi.233.1511206650321; Mon, 20 Nov 2017 11:37:30 -0800 (PST)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l191sm25573936pfc.180.2017.11.20.11.37.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 11:37:29 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan , Mohamed Boucadair 
Cc: 6man WG , Mark Andrews 
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Tue, 21 Nov 2017 08:37:28 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 19:37:32 -0000

On 21/11/2017 02:36, Ole Troan wrote:
...>> [Med] These are generic statements, Ole. We are talking about the IETF case.
>> * The IETF has no control on the hosts that connect to the IETF network,
>> * IETF attendees who are using corporate devices, have no control on these hosts
>>
>> So, how forcing devices to use "IPv6+nat64" will help here?
> 
> Eat own dogfood. Many IETF people are developers or work for companies having applications not working.
> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.

However, as long as even one application, such as one VPN, or one
literal IPv4 address, fails, that represents millions of failure cases
if we consider the whole world (e.g. imagine every hotel network in
the world running IPv6+NAT64 only). That simply isn't viable. Dual
stack in every hotel room in the world is viable, from the hotel guests'
point of view. Operators might not like it, but users wouldn't care.

    Brian


From nobody Mon Nov 20 11:52:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C5512EA8D for ; Mon, 20 Nov 2017 11:52:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIS2whlfs4QR for ; Mon, 20 Nov 2017 11:52:40 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89F41204DA for ; Mon, 20 Nov 2017 11:52:40 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 1D77B2D512A; Mon, 20 Nov 2017 19:52:38 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 71BB6200CC5471; Mon, 20 Nov 2017 20:52:36 +0100 (CET)
From: Ole Troan 
Message-Id: <82952FDF-0AA3-49EF-B3A6-1FAA61FC5C01@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_C6E2CF8E-CCA4-4E3C-AE8E-1DAC2DC5291B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 20 Nov 2017 20:52:35 +0100
In-Reply-To: 
Cc: Mohamed Boucadair , 6man WG ,  Mark Andrews 
To: Brian E Carpenter 
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 19:52:43 -0000

--Apple-Mail=_C6E2CF8E-CCA4-4E3C-AE8E-1DAC2DC5291B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> ...>> [Med] These are generic statements, Ole. We are talking about =
the IETF case.
>>> * The IETF has no control on the hosts that connect to the IETF =
network,
>>> * IETF attendees who are using corporate devices, have no control on =
these hosts
>>>=20
>>> So, how forcing devices to use "IPv6+nat64" will help here?
>>=20
>> Eat own dogfood. Many IETF people are developers or work for =
companies having applications not working.
>> As I said there were a minimum of applications that didn't work. =
Corporate VPNs largely did. Jen has the final numbers.
>=20
> However, as long as even one application, such as one VPN, or one
> literal IPv4 address, fails, that represents millions of failure cases
> if we consider the whole world (e.g. imagine every hotel network in
> the world running IPv6+NAT64 only). That simply isn't viable. Dual
> stack in every hotel room in the world is viable, from the hotel =
guests'
> point of view. Operators might not like it, but users wouldn't care.

Nor would they if the hotel room was IPv4 only...
Would they?

Ole

--Apple-Mail=_C6E2CF8E-CCA4-4E3C-AE8E-1DAC2DC5291B
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+/bDNdvtpYqJhC33YFAloTMoMACgkQvtpYqJhC
33YvkQ/9EzJHK91kePKBoQEid4AFs0kQyxTXrug4LQ8gE8tDpDrImsID61GmnE91
gImsmzccWYdReesq6Jc3SJjGWVNW7oqZ8KPN1FzJmMZgZdiIeUSmjYZmxZkgLXht
+uIjK4122mti2r8Yqe230iunKy1wJLblJaZiwWLrxCjrM2JHmaGF7ugbip1SkRSI
qeKbW8Qhk8r5xcGk7o0YkEWwmc+fFvZ7IROIda0GIr3kbm9bF7ZEb4XNWP3clCla
xjLqtNT8Zh9nmc7EHBzl/u2n7EL7GaGdZMrOt+A1R9WwRvukyCWfI8C4yKap43OJ
BjTSgQKpHCCfJqulO3F9n5zRZS1ynRav2MDcwaCz7MerbjkdazN/fnlI6hkIRiRc
snGeuDkkIrMFchIAPcKlyNsblgl0OYVBH1enck1VVBQmGTD6BDWjPZaJdT2l/RXg
KtmZvITI4CeNwJwR2hGtM1c6bJRnloe/H2xERp3r/p1arXQ72SC6Ud4GjIvKj1NW
VjY3e15pNNGRtBWWUGeIvpJ+twI5zAhUm4ulyRnS8yhLnxmI33uVlaEE1gnCQSYV
o9rO35wTqsDx8hetHO+0Np9byQwCDzzLzINmJdiwn3EgoVGvV2cmAz7iJt5ZN6O/
3b7r/VEuIpX4I/2lCvDG3lnIcvcd92lAf3t8+ptIE20aQJ3GPWg=
=TNKC
-----END PGP SIGNATURE-----

--Apple-Mail=_C6E2CF8E-CCA4-4E3C-AE8E-1DAC2DC5291B--


From nobody Mon Nov 20 12:10:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE7C12EA93 for ; Mon, 20 Nov 2017 12:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Q93yVCRLYT6W for ; Mon, 20 Nov 2017 12:10:39 -0800 (PST)
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 53321126BF7 for ; Mon, 20 Nov 2017 12:10:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511208637; x=1511813437; 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=cDkBmImMnQhR6CGoFndw/grjA cbyCv/ecmWyCRLDLM0=; b=m31o/kv2PUF8CbLqZceuDdjXvJVowAXIEOW9u9DdT 8DROho6MqKishZQ3VwfwiLmgcOeThyvfEr6BZyOYI6E4rBxAbAiEDgoAK7+xGLTd Y33LUlCOzUqF2N/mXo2cnzGxrZgADq79SfpIq8i7vKU4u1b8II+qOGEcdBxzRSsz D8=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=VOFuIV/GWXPiRuXLq9JI+cxt4r+KcvlDXgxpkQaQMOcVhMV5ZJCgXUjvw6I/ ZhvOcx7q0SJX8mPNCed3bQm92gPqVITujiUNKLjDfhOdaRLlqBx6gg0uZ 9jziXoFB6RPQjMbj1LjCKreltre0sahukxDQszOnDQClInt1UY50fc=;
X-MDAV-Processed: mail.consulintel.es, Mon, 20 Nov 2017 21:10:37 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 20 Nov 2017 21:10:36 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005632724.msg for ; Mon, 20 Nov 2017 21:10:36 +0100
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:171120:md50005632724::nHeYk3CP2sQkaKpa:000073Ch
X-Return-Path: prvs=1497b6414a=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Mon, 20 Nov 2017 21:10:32 +0100
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 6man WG 
Message-ID: <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es>
Thread-Topic: IPv6 only host NAT64 requirements?
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  
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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 20:10:42 -0000

It is clear to me that hotel rooms need to provide IPv6 + IPv4-as-a-service=
 (for example using a CE or AP with CLAT).

The hotel network or its access can be IPv6-only and then the ISP provide t=
he NAT64.

I=E2=80=99m sure someone will argue that this means perpetuating IPv4: Is n=
ot the case.

The case is being realistic about what an ISP or an hotel or any other orga=
nizations NEEDs to provide to their customers if they want to keep them.

If the hotels provide IPv6 + IPv4-as-a-service, the customer is happy and m=
ore and more traffic is moving from IPv4 to IPv6 in a natural way.

If some app developers don=E2=80=99t see it, or if some content providers o=
r enterprises where the VPN is being connected, there will be a point where=
 the IPv4 traffic is meaningless and they have the risk that at that point =
the IPv4-as-a-service is not offered anymore, not because the cost of the C=
LAT, but because the cost of the NAT64.

The only way we can motivate all them to move to IPv6 is to make sure that =
when, for example 75% of the Internet traffic is IPv6, we clearly announce =
that IPv4 is historical, has not maintenance, and will be dropped and unsup=
ported and will not be able to be reachable. It is the ISPs work to decide =
if they want to keep providing NAT64 or not, and to tell their customers. A=
t some point, more and more ISPs will drop that service. Wherever that poin=
t is at the 75% of IPv6 traffic or 95% or something in the middle is to be =
decided by each ISP, also maybe depending on their competitors, etc.

I recall a few years ago when a phone company in Spain still had a few cust=
omers with old =E2=80=9Cpulse disk phones=E2=80=9D. They took the decision =
to cancel the contract to those customers if they don=E2=80=99t want to get=
 the phone replaces with DTMF phones.

Same today is happening with customers with ADSL where there is GPON covera=
ge. You accept to be replaced to GPON, or they cancel the contract, because=
 it is more expensive to keep a few =E2=80=9Cold fashioned=E2=80=9D custome=
rs that the profit they generate.

Regards,
Jordi
=20

-----Mensaje original-----
De: ipv6  en nombre de Brian E Carpenter 
Organizaci=C3=B3n: University of Auckland
Responder a: 
Fecha: lunes, 20 de noviembre de 2017, 20:37
Para: Ole Troan , Mohamed Boucadair 
CC: 6man WG , Mark Andrews 
Asunto: Re: IPv6 only host NAT64 requirements?

    On 21/11/2017 02:36, Ole Troan wrote:
    ...>> [Med] These are generic statements, Ole. We are talking about the=
 IETF case.
    >> * The IETF has no control on the hosts that connect to the IETF netw=
ork,
    >> * IETF attendees who are using corporate devices, have no control on=
 these hosts
    >>
    >> So, how forcing devices to use "IPv6+nat64" will help here?
    >=20
    > Eat own dogfood. Many IETF people are developers or work for companie=
s having applications not working.
    > As I said there were a minimum of applications that didn't work. Corp=
orate VPNs largely did. Jen has the final numbers.
   =20
    However, as long as even one application, such as one VPN, or one
    literal IPv4 address, fails, that represents millions of failure cases
    if we consider the whole world (e.g. imagine every hotel network in
    the world running IPv6+NAT64 only). That simply isn't viable. Dual
    stack in every hotel room in the world is viable, from the hotel guests=
'
    point of view. Operators might not like it, but users wouldn't care.
   =20
        Brian
   =20
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
   =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 Nov 20 12:12:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAF3129C4B for ; Mon, 20 Nov 2017 12:12:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah7VvrknZ-BP for ; Mon, 20 Nov 2017 12:12:22 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BAE126BF7 for ; Mon, 20 Nov 2017 12:12:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAKKCKjN001475; Mon, 20 Nov 2017 13:12:20 -0700
Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vAKKCHZu001359 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 13:12:17 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 12:12:16 -0800
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 12:12:16 -0800
From: "Manfredi, Albert E" 
To: Brian E Carpenter 
CC: 6man WG 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTX4U1Tsj/Jo7wXkmQQz+YITZm9KMc5AXwgACXiQCAABYJAIAADLsAgAAc7ICAABUUgIAAZL8A//961JA=
Date: Mon, 20 Nov 2017 20:12:16 +0000
Message-ID: 
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  
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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 20:12:24 -0000

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter

> However, as long as even one application, such as one VPN, or one
> literal IPv4 address, fails, that represents millions of failure
> cases if we consider the whole world (e.g. imagine every hotel
> network in the world running IPv6+NAT64 only).

Very instructive thread for me, I must say. I'm getting this sense of urgen=
cy, to be rid of IPv4, but it comes from the IETF 6man wg and some ISPs. Ul=
timately, it's not up to 6man to decide. It's up to device vendors, and up =
to the deployed base of devices. The IETF can only suggest, and ISP network=
s have to meet the real world needs.

> Dual stack in every hotel room in the world is viable, from the
> hotel guests' point of view.

This seems the most practical answer, whether it's a client server model, s=
uch as in a hotel room, or a peer to peer network. In a mostly peer to peer=
 network, the normal case would be for IPv6 hosts to be introduced graduall=
y. I'm not sure how anything other than dual stack can work, in this case. =
If the goal is to have continuous robust operation of the network, during a=
n indefinitely long transitional phase, because no one up the chain could c=
are less about the nitty gritty, they just want everything to keep working =
flawlessly, then what motivation would there be for anything other than dua=
l stack? The only practical solution is to introduce IPv6 hosts only if the=
y are dual stack. And then carefully, on a case by case basis, individual s=
ubsystems that do not need to interoperate with IPv4 subsystems can shut of=
f IPv4.

I realize that such transition drag on for years. But again, in the greater=
 scheme of things, this matters very little to those who must make sure the=
 systems work at all times.

Bert



From nobody Mon Nov 20 12:13:01 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FDD12EA93 for ; Mon, 20 Nov 2017 12:12:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 2UdzJua6YqXg for ; Mon, 20 Nov 2017 12:12:56 -0800 (PST)
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 33ED512EAA5 for ; Mon, 20 Nov 2017 12:12:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511208774; x=1511813574; 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=v5BLhJOPcaiXRQrh6c6rib+Qd wntto79wM+K6vP+Eqw=; b=IVIBLcrJcQDVRlryilTFtXWUbunz/OOyNveDBz5wq XtqDqOIwXnfkAXSZtOwR+cYpr0A2Pt1UnDKM+wKbW3yLVCkuM0CZTLHkvaXEgK5h kO48V/q2a10z6VeCCIiggN4ZyZV2pTZnJab22KTi7TEYP93VVJ1do1Y7fXQFp6Dq PQ=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=sqosDLClCELZvdJw5nfLohDTpRibJKkbxZxSccx+P82EDatsE3hOyPJKqrgu Lq4Gu+t78DqISoocY6vAeUae3XNQVeyT3/0WTrXYh5rSYsrB7Mw5UzSYB RtMDzoJPA3l/F25YB225EqVLj1mKltlVZhKykcTbRxDlf5d9sxtceg=;
X-MDAV-Processed: mail.consulintel.es, Mon, 20 Nov 2017 21:12:54 +0100
X-Spam-Processed: mail.consulintel.es, Mon, 20 Nov 2017 21:12:52 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005632730.msg for ; Mon, 20 Nov 2017 21:12:52 +0100
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:171120:md50005632730::L29ErrD+WiPDTR5X:0000DuyN
X-Return-Path: prvs=1497b6414a=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Mon, 20 Nov 2017 21:12:50 +0100
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 6man WG 
Message-ID: 
Thread-Topic: IPv6 only host NAT64 requirements?
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es>
In-Reply-To: <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 20:12:59 -0000

And by the way =E2=80=A6

At some point the NAT64 service, instead of being provided by the ISP it wi=
ll make sense to be provided by third party companies, even if there is som=
e extra delay to reach a remote NAT64, etc., and even if there is an extra =
cost for that customer that still requires it.

Regards,
Jordi
=20

-----Mensaje original-----
De: ipv6  en nombre de JORDI PALET MARTINEZ 
Responder a: 
Fecha: lunes, 20 de noviembre de 2017, 21:11
Para: 6man WG 
Asunto: Re: IPv6 only host NAT64 requirements?

    It is clear to me that hotel rooms need to provide IPv6 + IPv4-as-a-ser=
vice (for example using a CE or AP with CLAT).
   =20
    The hotel network or its access can be IPv6-only and then the ISP provi=
de the NAT64.
   =20
    I=E2=80=99m sure someone will argue that this means perpetuating IPv4: =
Is not the case.
   =20
    The case is being realistic about what an ISP or an hotel or any other =
organizations NEEDs to provide to their customers if they want to keep them=
.
   =20
    If the hotels provide IPv6 + IPv4-as-a-service, the customer is happy a=
nd more and more traffic is moving from IPv4 to IPv6 in a natural way.
   =20
    If some app developers don=E2=80=99t see it, or if some content provide=
rs or enterprises where the VPN is being connected, there will be a point w=
here the IPv4 traffic is meaningless and they have the risk that at that po=
int the IPv4-as-a-service is not offered anymore, not because the cost of t=
he CLAT, but because the cost of the NAT64.
   =20
    The only way we can motivate all them to move to IPv6 is to make sure t=
hat when, for example 75% of the Internet traffic is IPv6, we clearly annou=
nce that IPv4 is historical, has not maintenance, and will be dropped and u=
nsupported and will not be able to be reachable. It is the ISPs work to dec=
ide if they want to keep providing NAT64 or not, and to tell their customer=
s. At some point, more and more ISPs will drop that service. Wherever that =
point is at the 75% of IPv6 traffic or 95% or something in the middle is to=
 be decided by each ISP, also maybe depending on their competitors, etc.
   =20
    I recall a few years ago when a phone company in Spain still had a few =
customers with old =E2=80=9Cpulse disk phones=E2=80=9D. They took the decis=
ion to cancel the contract to those customers if they don=E2=80=99t want to=
 get the phone replaces with DTMF phones.
   =20
    Same today is happening with customers with ADSL where there is GPON co=
verage. You accept to be replaced to GPON, or they cancel the contract, bec=
ause it is more expensive to keep a few =E2=80=9Cold fashioned=E2=80=9D cus=
tomers that the profit they generate.
   =20
    Regards,
    Jordi
    =20
   =20
    -----Mensaje original-----
    De: ipv6  en nombre de Brian E Carpenter 
    Organizaci=C3=B3n: University of Auckland
    Responder a: 
    Fecha: lunes, 20 de noviembre de 2017, 20:37
    Para: Ole Troan , Mohamed Boucadair 
    CC: 6man WG , Mark Andrews 
    Asunto: Re: IPv6 only host NAT64 requirements?
   =20
        On 21/11/2017 02:36, Ole Troan wrote:
        ...>> [Med] These are generic statements, Ole. We are talking about=
 the IETF case.
        >> * The IETF has no control on the hosts that connect to the IETF =
network,
        >> * IETF attendees who are using corporate devices, have no contro=
l on these hosts
        >>
        >> So, how forcing devices to use "IPv6+nat64" will help here?
        >=20
        > Eat own dogfood. Many IETF people are developers or work for comp=
anies having applications not working.
        > As I said there were a minimum of applications that didn't work. =
Corporate VPNs largely did. Jen has the final numbers.
       =20
        However, as long as even one application, such as one VPN, or one
        literal IPv4 address, fails, that represents millions of failure ca=
ses
        if we consider the whole world (e.g. imagine every hotel network in
        the world running IPv6+NAT64 only). That simply isn't viable. Dual
        stack in every hotel room in the world is viable, from the hotel gu=
ests'
        point of view. Operators might not like it, but users wouldn't care=
.
       =20
            Brian
       =20
        -------------------------------------------------------------------=
-
        IETF IPv6 working group mailing list
        ipv6@ietf.org
        Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
        -------------------------------------------------------------------=
-
       =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
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
   =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 Nov 20 12:34:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3169712E041 for ; Mon, 20 Nov 2017 12:34:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StRzc54lTaog for ; Mon, 20 Nov 2017 12:34:14 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 DEFE6120713 for ; Mon, 20 Nov 2017 12:34:13 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id x68so11593615lff.0 for ; Mon, 20 Nov 2017 12:34:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zu+bIKdfgeKFwwYm5C40Dp/H0ahEsssK0aghAh5Cp8I=; b=uTsjBcGqFzOqjPWgGqvTv1YPbQnquaEXJSRYxhgbCsjy6+u53HzPBGAsP4OKB+r/y2 FwXig7ltLC0pUguUcdtA4AOFdq/yjcmqAX5p4o0GbhGcCInGPg+F6KBxZch+WnkKwM0M mcfcvX3SZy1JcgJxNeThuiJcF2End7ZHR5x/1qhNc5rHgnvEwkas2gJ2XXQbYtYMLpSf U5fYqg7l1O4wswx25Loc1qlCAYaUCle3ucaH4KFUWc20NLa9FOx7jBbyOorWDH5zjAGG 4hKfbUI0OUb9hQyCTGbujNq/CZE8fNQ/zSnl+zx10k01e9CKw8iOYDyXVmyxFHImcMQZ Iepg==
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=zu+bIKdfgeKFwwYm5C40Dp/H0ahEsssK0aghAh5Cp8I=; b=G9KZp9txmJIIAtZe2uUlJtotZ40Z+W58aNbvayVZVT9fEyBJoP0OpTsG8oprYVCY8G MwSgspk0BuJz2MxHpfSrbR/VzDsPU/qJkInTqOowwSIf0aXEKNIYt2bq00K6r9zAd7g/ +6zZZ4/RbcoF5Pz+5jS7wvMm7GAwDnO+DG6IKak9xj0rrLko1MgF60ihyT6p+ZmAneQI FzwZhFZ+71aLhIiQ2FQSQH4kbj1xETLHJxaLG4OJW4UPm1KvsVhWsMf6GcMyiEngXKXL Qp9FKLubfRaoWiVclhfTC0xKZwcEEqbOTYheKOiLgLHR4i4CTVlTzl9l4Fhc9Y2XeeBh oGpQ==
X-Gm-Message-State: AJaThX4ifdc/85tolHSpQT6nS3vy4MZmOj68nHFNqPNC0lgBR42SaQGk DbQ+Der/oqDLlZ6JxDv2oCBUTvwlcAC9QePRkIE=
X-Google-Smtp-Source: AGs4zMZeDOGOLQnGtKK+CrUFVPmHw8pk+GbyoQuQ8bYpw67nG3whZcaSg8FCEvtcS1duiPspEouMvggGQN6u2dzvMAA=
X-Received: by 10.25.26.4 with SMTP id a4mr2124513lfa.105.1511210051999; Mon, 20 Nov 2017 12:34:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.205.2 with HTTP; Mon, 20 Nov 2017 12:33:50 -0800 (PST)
In-Reply-To: 
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   
From: Jen Linkova 
Date: Tue, 21 Nov 2017 07:33:50 +1100
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: "Manfredi, Albert E" 
Cc: Brian E Carpenter , 6man WG 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 20:34:16 -0000

On Tue, Nov 21, 2017 at 7:12 AM, Manfredi, Albert E
 wrote:
> Very instructive thread for me, I must say. I'm getting this sense of urg=
ency, to be rid of IPv4, but it comes from the IETF 6man wg and some ISPs.
>Ultimately, it's not up to 6man to decide.

I do not see this thread as 6man deciding that everyone is to get rid
of Ipv4 right now. I see it as 'there are networks deploying IPv6-only
hosts and 6man is discussing how to help hosts to operate in such
environment'.

>It's up to device vendors,  and up to the deployed base of devices.
>The IETF can only suggest, and ISP networks have to meet the real world ne=
eds.

People from the real world is coming to IETF saying 'we are deploying
Ipv6-only hosts' [1] [2]

References:
[1[ https://datatracker.ietf.org/meeting/100/materials/slides-100-v6ops-ses=
sa-ipv6-only-deployment-at-cisco/
[2] https://datatracker.ietf.org/meeting/99/materials/agenda-99-v6ops/

>> Dual stack in every hotel room in the world is viable, from the
>> hotel guests' point of view.
>
> This seems the most practical answer, whether it's a client server model,=
 such as in a hotel room, or a peer to peer network. In a mostly peer to pe=
er network, the normal case would be for IPv6 hosts to be introduced gradua=
lly. I'm not sure how anything other than dual stack can work, in this case=
. If the goal is to have continuous robust operation of the network, during=
 an indefinitely long transitional phase, because no one up the chain could=
 care less about the nitty gritty, they just want everything to keep workin=
g flawlessly, then what motivation would there be for anything other than d=
ual stack? The only practical solution is to introduce IPv6 hosts only if t=
hey are dual stack. And then carefully, on a case by case basis, individual=
 subsystems that do not need to interoperate with IPv4 subsystems can shut =
off IPv4.
>
> I realize that such transition drag on for years. But again, in the great=
er scheme of things, this matters very little to those who must make sure t=
he systems work at all times.
>
> Bert
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



--=20
SY, Jen Linkova aka Furry


From nobody Mon Nov 20 12:53:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471C712EAA8 for ; Mon, 20 Nov 2017 12:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kQO57Cmh40w for ; Mon, 20 Nov 2017 12:53:38 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 95AEE126DFB for ; Mon, 20 Nov 2017 12:53:37 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id k66so11646666lfg.3 for ; Mon, 20 Nov 2017 12:53:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j0vPbMT1q92GC38AKqKUZfIqB8coCQhU99aaqTWA7bY=; b=UDw97yfq5WwfwLLb/uLBaZplQMRS2AswXPj54XQtA5/Exy68igWewYzse2xLNfuUQX oYyNkMH77jGnl2dgII+Y2vMrOgmjG3ilCuD2vrjhCW32jvLx8/mHF9LCsmkmQFN3023S 7X+5TdJ7cp0Ux2xbLB5Airl+NuRPs3M/E3aKzRX/sSa/aP6IdKsQFeZ7s1llfGJ2qC7o SHQ6NnK3suk/gsCbaZqiMLrXWimZnmlaJjFdbYjwUFuKow5t5HCLP7Ch+GcrobYdlZDv RIK+Jk62o4B9hJIPopglUpDIBKe5C9TP4TtaH6nYQxOogM9dew+qHUnqFxD4Yz9Eb62y aQLQ==
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=j0vPbMT1q92GC38AKqKUZfIqB8coCQhU99aaqTWA7bY=; b=Mdd+WqZr3Hw136VboU5G+HS4//FtSFpM/3awyMoJzEzMVqPZuSt2wLxty4jZpo1Tye hhk33jUfS2YXTtLe9jGhFMeZEAL4vCxwEPPdk5kwgEX0Gw+iBV3rNnv3DT0UEuP3/Mzi uDmVOuwpZMh4tm0DO4EbzdRNgVPvYgYJo2Vk7RFkzbtZSVy+4JMHTBOQtSk+Oe7FY+lg Wdeq9dY8XJurXJBmK16mt2cH7dNAg2e+zgxnATOYNcyidnrAlBmZRS7TVgK5LQ75wi2A j2sZZS3IHx74o2hD35X9vnlGYitnKHSKwr2HK86J73ZJM/q1/VNFo3zMYE8ZjvdIwLxf Uu7Q==
X-Gm-Message-State: AJaThX7rG25/nN4tHYDR5tAQ1uugo45Mgx0OxqdU3dc+aMSzw68ti/n0 D12kH9dKk2d/pFZEy1tOuo9lF9g6cvwhnlEI7XY=
X-Google-Smtp-Source: AGs4zMZ7MiEP21LIFqvsKANeB/A3WFA0i39DSIopSREWfU3JNeraU3c7o2+7BB7YjrgLjdF/tNZ/AYv6lsx1yzr0c/Q=
X-Received: by 10.25.87.12 with SMTP id l12mr4092595lfb.111.1511211215745; Mon, 20 Nov 2017 12:53:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.205.2 with HTTP; Mon, 20 Nov 2017 12:53:14 -0800 (PST)
In-Reply-To: 
References:    <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org>  <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org>  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 
From: Jen Linkova 
Date: Tue, 21 Nov 2017 07:53:14 +1100
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: Mohamed Boucadair , 6man WG ,  Mark Andrews 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 20:53:39 -0000

On Tue, Nov 21, 2017 at 12:36 AM, Ole Troan  wrote:
>>> The arguments against dual stack:
>>> - expensive to operate
>>> - little progress towards the end goal of IPv6 only
>>
>> [Med] These are generic statements, Ole. We are talking about the IETF case.
>> * The IETF has no control on the hosts that connect to the IETF network,
>> * IETF attendees who are using corporate devices, have no control on these hosts
>>
>> So, how forcing devices to use "IPv6+nat64" will help here?

I'm still working on the experiment results write-up but off top of my
head I can tell you that:
1) people told me they are coming back to their IT departments asking
them to fix their VPNs. As there are other places out there providing
Ipv6-only as a 'primary/default' wifi (AFAIR FOSDEM is doing this, for
example, not mentioning some companies deploying v6-only networks) I
think it's quite useful for those people to be prepared.
2) bug reports for the broken applications were filled
3) we finally have some numbers on 'what % of people can not get their
work done if their devices do not have v4 addresses' - before it was
just
'some saying that it would never work while others saying it works just fine'.
4) we observed that the situation has improved even since IETF99 so we
are moving in right direction.
5) as a result of the experiment some changes have been applied to the
IETF network to improve it and bugs opened with vendors.
6) we are having this discussion in 6man about host requirements.

on Friday afternoon I discovered that I had turned off Ipv4 on my
laptop on Tue morning and left it like that...Noticed it only because
got connected
to Ipv4-only network ;)))

> Eat own dogfood. Many IETF people are developers or work for companies having applications not working.
> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.

Stay tuned, I'm getting the numbers together, will get it done this week.

-- 
SY, Jen Linkova aka Furry


From nobody Mon Nov 20 12:59:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DDA126DFB for ; Mon, 20 Nov 2017 12:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MFCEEh3P5zh for ; Mon, 20 Nov 2017 12:59:51 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE30124BFA for ; Mon, 20 Nov 2017 12:59:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAKKxndG023720; Mon, 20 Nov 2017 13:59:50 -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 vAKKxlDs023703 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 13:59:47 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 12:59:46 -0800
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 12:59:46 -0800
From: "Manfredi, Albert E" 
To: Jen Linkova 
CC: 6man WG 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTX4U1Tsj/Jo7wXkmQQz+YITZm9KMc5AXwgACXiQCAABYJAIAADLsAgAAc7ICAABUUgIAAZL8A//961JCAAJTrAP//fMjw
Date: Mon, 20 Nov 2017 20:59:46 +0000
Message-ID: <1c924e25e7214ff0937123ba3f0e57cb@XCH15-06-11.nw.nos.boeing.com>
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.137.12.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 20:59:53 -0000

LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEplbiBMaW5rb3ZhIFttYWlsdG86ZnVy
cnkxM0BnbWFpbC5jb21dIA0KDQo+IFBlb3BsZSBmcm9tIHRoZSByZWFsIHdvcmxkIGlzIGNvbWlu
ZyB0byBJRVRGIHNheWluZyAnd2UgYXJlIGRlcGxveWluZw0KPiBJcHY2LW9ubHkgaG9zdHMnIFsx
XSBbMl0NCg0KUmVmZXJlbmNlczoNClsxWyBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21l
ZXRpbmcvMTAwL21hdGVyaWFscy9zbGlkZXMtMTAwLXY2b3BzLXNlc3NhLWlwdjYtb25seS1kZXBs
b3ltZW50LWF0LWNpc2NvLw0KWzJdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGlu
Zy85OS9tYXRlcmlhbHMvYWdlbmRhLTk5LXY2b3BzLw0KDQpPa2F5LiBTbywgcGVvcGxlIGNhbiBm
b2xsb3cgd2hhdGV2ZXIgYXBwcm9hY2ggdGhleSBwcmVmZXIsIGJ1dCBteSBmaXJzdCByZWFjdGlv
biB3YXMgdGhhdCBzd2l0Y2hpbmcgb3ZlciB0byBJUHY2ICpieSBsb2NhdGlvbiogc2VlbXMgYW4g
b2RkIHdheSB0byBnbyBhYm91dCBpdC4gSWYgaXQgd2VyZSB1cCB0byBtZSwgSSdkIHNheSBub3Qg
dG8gdXNlIHRoYXQgbW9kZWwuIEl0J3MgbW9yZSBhIG1hdHRlciBvZiBlbmQgdG8gZW5kIGZ1bmN0
aW9ucyB1c2VkLCBieSBob3N0cyBpbiBhIGdpdmVuIHN1Ym5ldC4gSWYgYSBnaXZlbiBzdWJuZXQg
Y2FuIGRlbW9uc3RyYXRlIHRoYXQgYWxsIG9mIGl0cyBob3N0cycgbmVlZHMgY2FuIGJlIG1ldCwg
ZW5kIHRvIGVuZCwgd2l0aCBJUHY2IG9ubHksIHRoZW4gZ3JlYXQuIFNodXQgb2ZmIElQdjQgaW4g
dGhhdCBvbmUgc3VibmV0LiBCdXQgImVuZCB0byBlbmQiIHNlc3Npb25zIGFyZSBmcmVxdWVudGx5
IG5vdCBjb25maW5lZCB0byBvbmUgbG9jYXRpb24sIGFuZCBpdCBhbHNvIHNlZW1zIHVubGlrZWx5
IHRoYXQgYWxsIGhvc3RzIGluIGFsbCBzdWJuZXRzLCBpbiBhIGdpdmVuIGxvY2F0aW9uLCBoYXZl
IHRoZSBzYW1lIG5lZWRzLg0KDQpUaGUgaG90ZWwgbW9kZWwgdGhhdCBCcmlhbiBvZmZlcmVkIHNl
ZW1zIHRvIHJlZmxlY3Qgd2hhdCBzaG91bGQgYmUgdGhlIG1vc3QgZ2VuZXJpYyByZWFsaXR5LiBE
aXZlcnNlIGRldmljZXMsIGRpdmVyc2UgbmVlZHMsIGxvY2F0aW9uIGlzbid0IHRoZSBwcmltYXJ5
IGZhY3RvciB0byBiZSBjb25zaWRlcmVkLiBJIHJlYWxpemUgdGhhdCB0aGVyZSdzIHNvbWUgc29y
dCBvZiBtYW5hZ2VtZW50IGFwcGVhbCwgdG8gbWFrZSB0aGlzIGEgImJ5IGxvY2F0aW9uIiBpc3N1
ZS4NCg0KQmVydA0KDQo=


From nobody Mon Nov 20 13:05:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AAC12E056 for ; Mon, 20 Nov 2017 13:05:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level: 
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo4q44D_6tcX for ; Mon, 20 Nov 2017 13:05:27 -0800 (PST)
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 9EE3D128CD5 for ; Mon, 20 Nov 2017 13:05:27 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob17.registeredsite.com (8.14.4/8.14.4) with ESMTP id vAKL5OTG046284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 20 Nov 2017 16:05:25 -0500
Received: (qmail 26200 invoked by uid 0); 20 Nov 2017 21:05:24 -0000
X-TCPREMOTEIP: 184.185.35.18
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.2.160?) (lee@asgard.org@184.185.35.18) by 0 with ESMTPA; 20 Nov 2017 21:05:24 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Mon, 20 Nov 2017 16:05:19 +0800
Subject: Re: IPv6 only host NAT64 requirements?
From: Lee Howard 
To: "Manfredi, Albert E" , Brian E Carpenter 
CC: 6man WG 
Message-ID: 
Thread-Topic: IPv6 only host NAT64 requirements?
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 21:05:29 -0000

On 11/21/17, 4:12 AM, "ipv6 on behalf of Manfredi, Albert E"
 wrote:

>-----Original Message-----
>From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
>
>> However, as long as even one application, such as one VPN, or one
>> literal IPv4 address, fails, that represents millions of failure
>> cases if we consider the whole world (e.g. imagine every hotel
>> network in the world running IPv6+NAT64 only).
>
>Very instructive thread for me, I must say. I'm getting this sense of
>urgency, to be rid of IPv4, but it comes from the IETF 6man wg and some
>ISPs. Ultimately, it's not up to 6man to decide. It's up to device
>vendors, and up to the deployed base of devices. The IETF can only
>suggest, and ISP networks have to meet the real world needs.

It=E2=80=99s a multi-legged stool, where network operators, device vendors, and
content all have a role, and will make their own operational decisions.
Operators may decide not to support IPv4-only devices or applications, or
to charge more for them, or to provide translators. Device makers may
decide to support dual-stack, or CLAT, or IPv6-only, or IPv4-only. Etc.

>
>> Dual stack in every hotel room in the world is viable, from the
>> hotel guests' point of view.
>
>This seems the most practical answer, whether it's a client server model,
>such as in a hotel room, or a peer to peer network. In a mostly peer to
>peer network, the normal case would be for IPv6 hosts to be introduced
>gradually. I'm not sure how anything other than dual stack can work, in
>this case. If the goal is to have continuous robust operation of the
>network, during an indefinitely long transitional phase, because no one
>up the chain could care less about the nitty gritty, they just want
>everything to keep working flawlessly, then what motivation would there
>be for anything other than dual stack?

IPv4 addresses selling for US$15 each and rising? At what price do
operators stop doing native dual stack?

> The only practical solution is to introduce IPv6 hosts only if they are
>dual stack. And then carefully, on a case by case basis, individual
>subsystems that do not need to interoperate with IPv4 subsystems can shut
>off IPv4.

It=E2=80=99s too late for dual-stack to be the transition plan.

>
>I realize that such transition drag on for years. But again, in the
>greater scheme of things, this matters very little to those who must make
>sure the systems work at all times.

Yes, years.
https://pbs.twimg.com/media/C_vRuRUXYAAwxN5.jpg:large
Five years until 90% of hosts have IPv6. It=E2=80=99s going to be a bumpy few
years, especially for those who insist IPv6 is somebody else=E2=80=99s problem.

Lee



From nobody Mon Nov 20 13:18:59 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D38812EAB3 for ; Mon, 20 Nov 2017 13:18:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.349
X-Spam-Level: 
X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsPIPd3BsQrw for ; Mon, 20 Nov 2017 13:18:55 -0800 (PST)
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 AB4C71241FC for ; Mon, 20 Nov 2017 13:18:55 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob13.registeredsite.com (8.14.4/8.14.4) with ESMTP id vAKLIqND020168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 20 Nov 2017 16:18:52 -0500
Received: (qmail 12876 invoked by uid 0); 20 Nov 2017 21:18:52 -0000
X-TCPREMOTEIP: 184.185.35.18
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.2.160?) (lee@asgard.org@184.185.35.18) by 0 with ESMTPA; 20 Nov 2017 21:18:51 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Mon, 20 Nov 2017 16:18:45 +0800
Subject: Re: IPv6 only host NAT64 requirements?
From: Lee Howard 
To: "Manfredi, Albert E" , Jen Linkova 
CC: 6man WG 
Message-ID: 
Thread-Topic: IPv6 only host NAT64 requirements?
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>     <1c924e25e7214ff0937123ba3f0e57cb@XCH15-06-11.nw.nos.boeing.com>
In-Reply-To: <1c924e25e7214ff0937123ba3f0e57cb@XCH15-06-11.nw.nos.boeing.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 21:18:57 -0000

On 11/21/17, 4:59 AM, "ipv6 on behalf of Manfredi, Albert E"
 wrote:

>-----Original Message-----
>From: Jen Linkova [mailto:furry13@gmail.com]
>
>> People from the real world is coming to IETF saying 'we are deploying
>> Ipv6-only hosts' [1] [2]
>
>References:
>[1[=20
>https://datatracker.ietf.org/meeting/100/materials/slides-100-v6ops-sessa-
>ipv6-only-deployment-at-cisco/
>[2] https://datatracker.ietf.org/meeting/99/materials/agenda-99-v6ops/
>
>Okay. So, people can follow whatever approach they prefer, but my first
>reaction was that switching over to IPv6 *by location* seems an odd way
>to go about it. If it were up to me, I'd say not to use that model. It's
>more a matter of end to end functions used, by hosts in a given subnet.
>If a given subnet can demonstrate that all of its hosts' needs can be
>met, end to end, with IPv6 only, then great. Shut off IPv4 in that one
>subnet. But "end to end" sessions are frequently not confined to one
>location, and it also seems unlikely that all hosts in all subnets, in a
>given location, have the same needs.

Not sure what your goal is here in complaining about someone else=E2=80=99s
deployment model.

A building on a campus probably is a single subnet. Not sure how you=E2=80=99d
find out what doesn=E2=80=99t work over IPv6 (plus NAT64) without trying it.

>
>The hotel model that Brian offered seems to reflect what should be the
>most generic reality. Diverse devices, diverse needs, location isn't the
>primary factor to be considered. I realize that there's some sort of
>management appeal, to make this a "by location" issue.

Hospitality networks have specific engineering requirements which may not
be generalizable. For one, they have different users and devices daily:
unlike an enterprise network, devices that tech support fixes don=E2=80=99t stay
fixed (new devices come in). A support call to an ISP subscriber might
cost the same or less than a hotel support call, but if the call is
repeated every time there=E2=80=99s a new user, the hotel has a very different
problem. Plus, of course, hotels are pretty much all Wi-Fi, which may not
be true of enterprise or campus or data center networks.

Lee

>
>Bert
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>ipv6@ietf.org
>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>



From nobody Mon Nov 20 13:41:19 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24BAC12960D; Mon, 20 Nov 2017 13:41:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiqyzTfcSRQt; Mon, 20 Nov 2017 13:40:59 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C777128CD5; Mon, 20 Nov 2017 13:40:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAKLevsF015464; Mon, 20 Nov 2017 14:40:57 -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 vAKLesjW015085 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 14:40:54 -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; Mon, 20 Nov 2017 13:40:53 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 13:40:53 -0800
From: "Templin, Fred L" 
To: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" , "dhcwg@ietf.org" 
Subject: Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57Ng==
Date: Mon, 20 Nov 2017 21:40:53 +0000
Message-ID: <9debb1672e3d4f0d89d672d64e0fe579@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.137.12.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 21:41:01 -0000

Hello,

IPv6 ND and DHCPv6 have traditionally been thought of as independent functi=
ons,
with the requirement that the IPv6 ND RS/RA exchange has to happen first so=
 that
the node can examine the M/O bits to determine whether it can use DHCPv6. A=
s
nearly as I can tell, this two round-trip process (IPv6 RS/RA followed by D=
HCPv6
Solicit/Reply) is the only argument conceivable against DHCPv6 from a funct=
ional
standpoint.

The two round-trip process can add significant delay and waste bandwidth es=
pecially
on low-end data links like many aviation wireless links. It can also impart=
 unnecessary
messaging overhead on more robust links during periods of congestion.

This document therefore proposes a unification of IPv6 ND and DHCPv6 where
the two functions work together as if they were one. This is accommodated b=
y
a new IPv6 ND option in RS/RA messages called the "DHCPv6 option". By worki=
ng
together as one function, IPv6 ND and DHCPv6 can supply requesting nodes wi=
th
all link-specific autoconfiguration information and any managed address/pre=
fix
delegations in a single round trip message exchange.

I would ask these discussion lists to consider what is it that you really d=
on't
like about DHCPv6. Maybe you think it is ugly. Maybe you don't like the way
the acronym rolls off your tongue when you speak it. Maybe it has an onerou=
s
stigma of being stateful. But, then I would also ask you to consider what a
replacement would look like. Because, I think any suitable replacement
would have to essentially duplicate what DHCPv6 already does.

Comments?

Fred


-----Original Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte=
rnet-drafts@ietf.org
Sent: Monday, November 20, 2017 1:21 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-templin-6man-dhcpv6-ndopt-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


        Title           : The DHCPv6 Option for IPv6 Neighbor Discovery
        Author          : Fred L. Templin
	Filename        : draft-templin-6man-dhcpv6-ndopt-00.txt
	Pages           : 6
	Date            : 2017-11-20

Abstract:
   IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for
   nodes to discover neighbors, routers, prefixes and other services on
   the link.  It also supports a manner of StateLess Address
   AutoConfiguration (SLAAC).  The Dynamic Host Configuration Protocol
   for IPv6 (DHCPv6) specifies a service for the stateful delegation of
   addresses and prefixes.

   Currently, at least two round-trip message exchanges are necessary in
   order to perform the IPv6ND router discovery and DHCPv6 address/
   prefix delegation functions.  This document presents a protocol for
   combining these two round trips into a single round trip by joining
   the two services into a single unified service.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-6man-dhcpv6-ndopt-00
https://datatracker.ietf.org/doc/html/draft-templin-6man-dhcpv6-ndopt-00


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt



From nobody Mon Nov 20 14:17:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23E212EAA8; Mon, 20 Nov 2017 14:17:45 -0800 (PST)
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 ht2wn5Jv2Rkj; Mon, 20 Nov 2017 14:17:43 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAC012704A; Mon, 20 Nov 2017 14:17:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5567; q=dns/txt; s=iport; t=1511216263; x=1512425863; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=o7Gbr6O1d1hKAY5ie5y8CcLvt35i+SMSHGSvCtnlry8=; b=XdHC2EN2qjTMSlblS07XBLHcIjvX18NhEL9otCzQoKRBJ0Oafdbkf/PP yM/xmvbOoBo8G2Iztdqa4fBt+QrlYZUbpDSExXEvS5eUd1/QgyTNiizw4 C4cwMsQ/rU64nhK7VTFrj1Q0Lc82ampNEIbFG9QVca0Wr/dLh7JAlVJUN E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DpAAATUxNa/5FdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOLmZuJweOF48ogX2WYoIRChgNhRYChH0/GAEBAQEBAQEBAWs?= =?us-ascii?q?ohR4BAQEBAwEBODQLDAQCAQgRBAEBHwkHJwsUCQgBAQQOBQgBihwQqmmKdgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2DNIIHhmmDJIIphUYFijyYAgKHcINqiSeCH2K?= =?us-ascii?q?BGoQQiyqHPoU0dYgeAhEZAYE5AR85gXR6FR8qgmQJglAfgWd3AYo9gRQBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,430,1505779200"; d="scan'208";a="33593890"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2017 22:17:42 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAKMHgHN012026 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Nov 2017 22:17:42 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 16:17:41 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 16:17:41 -0600
From: "Bernie Volz (volz)" 
To: "Templin, Fred L" 
CC: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" , "dhcwg@ietf.org" 
Subject: RE: Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgABURPw
Date: Mon, 20 Nov 2017 22:17:41 +0000
Message-ID: 
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>
In-Reply-To: <9debb1672e3d4f0d89d672d64e0fe579@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: [10.98.1.198]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 22:17:46 -0000

Fred:

I'm not so sure that this idea is really needed. You can always start both =
RS and DHCPv6 at the same time if you always know you want to use DHCPv6?


In section 2, aren't you missing some "pad" octets to "make" the DHCPv6 mes=
sage (really the IPv6 ND DHCPv6 option) a multiple of 8 octets long (as the=
 "Length" field in the ND header is a multiple of 8). A better design, beca=
use there are no DHCPv6 "pad" options, might be:

A) The pad bytes are after the IPv6 ND Length field (your reserved) and dep=
end on the padding needed - these would be 0 octets before the msg-type to =
make the length work out (so the IPv6 ND DHCPv6 option ends at an 8 octet b=
oundary). When extracting the DHCPv6 message, any first octets that are 0 v=
alues would be skipped to find the start of the msg-type (since the DHCPv6 =
msg-type cannot be 0).

B) Use the 2 reserved octets to specify the real length of the DHCPv6 messa=
ge. Any octets beyond these are ignored. Alternatively, you could use 1 oct=
et to indicate the number of pad octets (and leave the other octet as reser=
ved).

And, of course the maximum sized DHCPv6 message you can send is 8 * 256 - 4=
 =3D 2,044 octets.


Also, for the "DHCPv6 Solicit" message, I think you want to say "DHCPv6 Sol=
icit w/Rapid Commit"? (You mention Rapid Commit only in the Introduction.)


- Bernie

-----Original Message-----
From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L
Sent: Monday, November 20, 2017 4:41 PM
To: 6man@ietf.org; v6ops@ietf.org; dhcwg@ietf.org
Subject: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified functi=
on

Hello,

IPv6 ND and DHCPv6 have traditionally been thought of as independent functi=
ons, with the requirement that the IPv6 ND RS/RA exchange has to happen fir=
st so that the node can examine the M/O bits to determine whether it can us=
e DHCPv6. As nearly as I can tell, this two round-trip process (IPv6 RS/RA =
followed by DHCPv6
Solicit/Reply) is the only argument conceivable against DHCPv6 from a funct=
ional standpoint.

The two round-trip process can add significant delay and waste bandwidth es=
pecially on low-end data links like many aviation wireless links. It can al=
so impart unnecessary messaging overhead on more robust links during period=
s of congestion.

This document therefore proposes a unification of IPv6 ND and DHCPv6 where =
the two functions work together as if they were one. This is accommodated b=
y a new IPv6 ND option in RS/RA messages called the "DHCPv6 option". By wor=
king together as one function, IPv6 ND and DHCPv6 can supply requesting nod=
es with all link-specific autoconfiguration information and any managed add=
ress/prefix delegations in a single round trip message exchange.

I would ask these discussion lists to consider what is it that you really d=
on't like about DHCPv6. Maybe you think it is ugly. Maybe you don't like th=
e way the acronym rolls off your tongue when you speak it. Maybe it has an =
onerous stigma of being stateful. But, then I would also ask you to conside=
r what a replacement would look like. Because, I think any suitable replace=
ment would have to essentially duplicate what DHCPv6 already does.

Comments?

Fred


-----Original Message-----
From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte=
rnet-drafts@ietf.org
Sent: Monday, November 20, 2017 1:21 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-templin-6man-dhcpv6-ndopt-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.


        Title           : The DHCPv6 Option for IPv6 Neighbor Discovery
        Author          : Fred L. Templin
	Filename        : draft-templin-6man-dhcpv6-ndopt-00.txt
	Pages           : 6
	Date            : 2017-11-20

Abstract:
   IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for
   nodes to discover neighbors, routers, prefixes and other services on
   the link.  It also supports a manner of StateLess Address
   AutoConfiguration (SLAAC).  The Dynamic Host Configuration Protocol
   for IPv6 (DHCPv6) specifies a service for the stateful delegation of
   addresses and prefixes.

   Currently, at least two round-trip message exchanges are necessary in
   order to perform the IPv6ND router discovery and DHCPv6 address/
   prefix delegation functions.  This document presents a protocol for
   combining these two round trips into a single round trip by joining
   the two services into a single unified service.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-6man-dhcpv6-ndopt-00
https://datatracker.ietf.org/doc/html/draft-templin-6man-dhcpv6-ndopt-00


Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie=
tf.org/ietf/1shadow-sites.txt


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


From nobody Mon Nov 20 14:38:53 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1797312EAE4; Mon, 20 Nov 2017 14:38:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rweG1KR2P0F2; Mon, 20 Nov 2017 14:38:45 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2711241FC; Mon, 20 Nov 2017 14:38:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAKMci2k039193; Mon, 20 Nov 2017 15:38:44 -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 vAKMcfnc039180 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 15:38:41 -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, 20 Nov 2017 14:38:40 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 14:38:40 -0800
From: "Templin, Fred L" 
To: "Bernie Volz (volz)" 
CC: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" , "dhcwg@ietf.org" 
Subject: RE: Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgABURPwAAD8gZA=
Date: Mon, 20 Nov 2017 22:38:40 +0000
Message-ID: 
References: <9debb1672e3d4f0d89d672d64e0fe579@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.137.12.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 22:38:48 -0000

Hi Bernie,

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com]
> Sent: Monday, November 20, 2017 2:18 PM
> To: Templin, Fred L 
> Cc: 6man@ietf.org; v6ops@ietf.org; dhcwg@ietf.org
> Subject: RE: Combining IPv6 ND and DHCPv6 into a single, unified function
>=20
> Fred:
>=20
> I'm not so sure that this idea is really needed. You can always start bot=
h RS and DHCPv6 at the same time if you always know you want
> to use DHCPv6?

I only want a (single request, single reply) message exchange; I don't want=
 to have
to start multiple exchanges even if in parallel. I am worried about links t=
hat have
bandwidth well south of 1Mbps - some as low as 32Kbps.=20

> In section 2, aren't you missing some "pad" octets to "make" the DHCPv6 m=
essage (really the IPv6 ND DHCPv6 option) a multiple of 8
> octets long (as the "Length" field in the ND header is a multiple of 8). =
A better design, because there are no DHCPv6 "pad" options,
> might be:
>=20
> A) The pad bytes are after the IPv6 ND Length field (your reserved) and d=
epend on the padding needed - these would be 0 octets
> before the msg-type to make the length work out (so the IPv6 ND DHCPv6 op=
tion ends at an 8 octet boundary). When extracting the
> DHCPv6 message, any first octets that are 0 values would be skipped to fi=
nd the start of the msg-type (since the DHCPv6 msg-type
> cannot be 0).

Yes, that works. We could also steal three bits from the "Reserved" field t=
o encode a
"pad length" value. The value would tell how many trailing zero octets are =
present.

> B) Use the 2 reserved octets to specify the real length of the DHCPv6 mes=
sage. Any octets beyond these are ignored. Alternatively,
> you could use 1 octet to indicate the number of pad octets (and leave the=
 other octet as reserved).

Right, I like using three bits from the Reserved field to encode the number=
 of
pad octets. Good catch.

> And, of course the maximum sized DHCPv6 message you can send is 8 * 256 -=
 4 =3D 2,044 octets.

Yes, that should be enough but should be noted. Thanks.

> Also, for the "DHCPv6 Solicit" message, I think you want to say "DHCPv6 S=
olicit w/Rapid Commit"? (You mention Rapid Commit only in
> the Introduction.)

Yes. Rapid Commit is assumed everywhere but should be explicitly stated.

Thanks - Fred
=20
> - Bernie
>=20
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Templin, Fred L
> Sent: Monday, November 20, 2017 4:41 PM
> To: 6man@ietf.org; v6ops@ietf.org; dhcwg@ietf.org
> Subject: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified func=
tion
>=20
> Hello,
>=20
> IPv6 ND and DHCPv6 have traditionally been thought of as independent func=
tions, with the requirement that the IPv6 ND RS/RA
> exchange has to happen first so that the node can examine the M/O bits to=
 determine whether it can use DHCPv6. As nearly as I can
> tell, this two round-trip process (IPv6 RS/RA followed by DHCPv6
> Solicit/Reply) is the only argument conceivable against DHCPv6 from a fun=
ctional standpoint.
>=20
> The two round-trip process can add significant delay and waste bandwidth =
especially on low-end data links like many aviation wireless
> links. It can also impart unnecessary messaging overhead on more robust l=
inks during periods of congestion.
>=20
> This document therefore proposes a unification of IPv6 ND and DHCPv6 wher=
e the two functions work together as if they were one.
> This is accommodated by a new IPv6 ND option in RS/RA messages called the=
 "DHCPv6 option". By working together as one function,
> IPv6 ND and DHCPv6 can supply requesting nodes with all link-specific aut=
oconfiguration information and any managed address/prefix
> delegations in a single round trip message exchange.
>=20
> I would ask these discussion lists to consider what is it that you really=
 don't like about DHCPv6. Maybe you think it is ugly. Maybe you
> don't like the way the acronym rolls off your tongue when you speak it. M=
aybe it has an onerous stigma of being stateful. But, then I
> would also ask you to consider what a replacement would look like. Becaus=
e, I think any suitable replacement would have to
> essentially duplicate what DHCPv6 already does.
>=20
> Comments?
>=20
> Fred
>=20
>=20
> -----Original Message-----
> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of in=
ternet-drafts@ietf.org
> Sent: Monday, November 20, 2017 1:21 PM
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-templin-6man-dhcpv6-ndopt-00.txt
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
>=20
>         Title           : The DHCPv6 Option for IPv6 Neighbor Discovery
>         Author          : Fred L. Templin
> 	Filename        : draft-templin-6man-dhcpv6-ndopt-00.txt
> 	Pages           : 6
> 	Date            : 2017-11-20
>=20
> Abstract:
>    IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for
>    nodes to discover neighbors, routers, prefixes and other services on
>    the link.  It also supports a manner of StateLess Address
>    AutoConfiguration (SLAAC).  The Dynamic Host Configuration Protocol
>    for IPv6 (DHCPv6) specifies a service for the stateful delegation of
>    addresses and prefixes.
>=20
>    Currently, at least two round-trip message exchanges are necessary in
>    order to perform the IPv6ND router discovery and DHCPv6 address/
>    prefix delegation functions.  This document presents a protocol for
>    combining these two round trips into a single round trip by joining
>    the two services into a single unified service.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-templin-6man-dhcpv6-ndopt-00
> https://datatracker.ietf.org/doc/html/draft-templin-6man-dhcpv6-ndopt-00
>=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
> _______________________________________________
> 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



From nobody Mon Nov 20 14:39:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A914612EAF4 for ; Mon, 20 Nov 2017 14:39:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izkzY7g1sI1A for ; Mon, 20 Nov 2017 14:39:19 -0800 (PST)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC5512EAFA for ; Mon, 20 Nov 2017 14:39:04 -0800 (PST)
Received: by mail-pf0-x22d.google.com with SMTP id a84so8365665pfl.0 for ; Mon, 20 Nov 2017 14:39:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yjvwXH3pY3xxO12w92QTRh+/QpBmw6g/9Ju/Bxivf7E=; b=Kt9o7D+LzZ+qPuWTLxid/wtQTEHH7Zy2vC4T1vwyOohvr7M1+VEJKrlDnXlp/anyQ3 AlwbO/5UIsTNKabb1Dyb4r0c8Vse6k2dyakbIk5MKTVHyLFLXMDh6SDF3kD42GZthEyZ Abg6UBbIxn52lPU9s0TNtygtiO9YYquCoeNmDt1VaLorrgWxuwRDRk3A3HH8FcC2GtGD a2bHN8cxyYceajMQg+LQgTfrplJKeR0MDb8a8GnhgiNyzxx6sYz8F9hRkEVsSP9/DuPA Nxdf+Si+zg+GcNufLRxMkP8UdHAZ0u6NiVbdKhNM/2SWeMkgR8FIB2Z0eo1pXXp8DzUF lTig==
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=yjvwXH3pY3xxO12w92QTRh+/QpBmw6g/9Ju/Bxivf7E=; b=iG2WcJHA9S0JSoLmUgeInk1uKUwYEdxCN7cw8iozPSaKkuP2Vu8gOlezIoWNvI3XXa U3ZG9euXMOD9iSVGoxX7wGJhVWQZ9CdqaJi+xxhzv6wqqQ17kRaERc2qYeVGH44R908F eh7jLg+4TvyTPrJJ/dreSlRzHQV7tefODjfcmCXYNn+T8m4xZG3udlH4pD8scgoA4xqK Z4VQvuVFuOTHJBTCXWBXOl38DU1CVDXGGBBlYSyPSss7BAVDjdDg7XsAm6jRhrQsVydb WhJq9NGTGawPmY5A/NeYbWZ7oDNoEAFltwzNrJ7hnFO7lma2YHlUgtpufFFkoiqmCh9d hhSw==
X-Gm-Message-State: AJaThX4Fa1lcjzrFBXiYIm7YZEF/LPdmRFQgp2C+YnsdhkpXijPp3Wy3 58nvGzaXMBTHEICRU9dizFLAyA==
X-Google-Smtp-Source: AGs4zMY06eHN/4g8/UUs4qOICuyPFPq8m4V1igxTnUjctUTlrxm5i1qGfkGfoZPAdm1suK5PdgJajQ==
X-Received: by 10.84.248.65 with SMTP id e1mr14955946pln.284.1511217543219; Mon, 20 Nov 2017 14:39:03 -0800 (PST)
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 e8sm21409475pfk.6.2017.11.20.14.39.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 14:39:01 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: jordi.palet@consulintel.es, 6man WG 
References:    <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <1df96ff3-3d42-19d2-aa63-5404adffcd3b@gmail.com>
Date: Tue, 21 Nov 2017 11:38:59 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 22:39:32 -0000

On 21/11/2017 09:10, JORDI PALET MARTINEZ wrote:
> It is clear to me that hotel rooms need to provide IPv6 + IPv4-as-a-ser=
vice (for example using a CE or AP with CLAT).
>=20
> The hotel network or its access can be IPv6-only and then the ISP provi=
de the NAT64.

What users need is that the WiFi (or, rarely, the RJ45 connector) support=
s
native IPv4 and native IPv6. If  the SP wants IPv6-only on the hotel's
access link, then the hotel's CE must use one of the known solutions.
I don't care if it's CLAT or dslite or homebrew. It must not place unusua=
l
requirements on the user's device, since by definition in such a scenario=

the user device and its applications are random and only a lowest common
denominator can be assumed.

> I=E2=80=99m sure someone will argue that this means perpetuating IPv4: =
Is not the case.

The religious aspect is not important; the market doesn't care about
religion. IPv4 will die when it's ready to die, and not before.

> The case is being realistic about what an ISP or an hotel or any other =
organizations NEEDs to provide to their customers if they want to keep th=
em.
>=20
> If the hotels provide IPv6 + IPv4-as-a-service, the customer is happy=20

And I believe that is the *only* way to make all customers happy
while deploying IPv6. Also, it can only be motivated if accessing
Facebook, Google etc. is faster or cheaper using IPv6, providing
an incentive for change.

> and more and more traffic is moving from IPv4 to IPv6 in a natural way.=

>=20
> If some app developers don=E2=80=99t see it, or if some content provide=
rs or enterprises where the VPN is being connected, there will be a point=
 where the IPv4 traffic is meaningless and they have the risk that at tha=
t point the IPv4-as-a-service is not offered anymore, not because the cos=
t of the CLAT, but because the cost of the NAT64.

Whatever the reason, ISPs won't do this until it affects a
negligible number of users, given the cost of help desk
calls compared to everything else.

> The only way we can motivate all them to move to IPv6 is to make sure t=
hat when, for example 75% of the Internet traffic is IPv6, we clearly ann=
ounce that IPv4 is historical, has not maintenance, and will be dropped a=
nd unsupported and will not be able to be reachable.=20

I don't know who you mean by "we". Certainly the IETF has no
power to make such statements.

Regards,
   Brian

> It is the ISPs work to decide if they want to keep providing NAT64 or n=
ot, and to tell their customers. At some point, more and more ISPs will d=
rop that service. Wherever that point is at the 75% of IPv6 traffic or 95=
% or something in the middle is to be decided by each ISP, also maybe dep=
ending on their competitors, etc.
>=20
> I recall a few years ago when a phone company in Spain still had a few =
customers with old =E2=80=9Cpulse disk phones=E2=80=9D. They took the dec=
ision to cancel the contract to those customers if they don=E2=80=99t wan=
t to get the phone replaces with DTMF phones.
>=20
> Same today is happening with customers with ADSL where there is GPON co=
verage. You accept to be replaced to GPON, or they cancel the contract, b=
ecause it is more expensive to keep a few =E2=80=9Cold fashioned=E2=80=9D=
 customers that the profit they generate.
>=20
> Regards,
> Jordi
> =20
>=20
> -----Mensaje original-----
> De: ipv6  en nombre de Brian E Carpenter 
> Organizaci=C3=B3n: University of Auckland
> Responder a: 
> Fecha: lunes, 20 de noviembre de 2017, 20:37
> Para: Ole Troan , Mohamed Boucadair 
> CC: 6man WG , Mark Andrews 
> Asunto: Re: IPv6 only host NAT64 requirements?
>=20
>     On 21/11/2017 02:36, Ole Troan wrote:
>     ...>> [Med] These are generic statements, Ole. We are talking about=
 the IETF case.
>     >> * The IETF has no control on the hosts that connect to the IETF =
network,
>     >> * IETF attendees who are using corporate devices, have no contro=
l on these hosts
>     >>
>     >> So, how forcing devices to use "IPv6+nat64" will help here?
>     >=20
>     > Eat own dogfood. Many IETF people are developers or work for comp=
anies having applications not working.
>     > As I said there were a minimum of applications that didn't work. =
Corporate VPNs largely did. Jen has the final numbers.
>    =20
>     However, as long as even one application, such as one VPN, or one
>     literal IPv4 address, fails, that represents millions of failure ca=
ses
>     if we consider the whole world (e.g. imagine every hotel network in=

>     the world running IPv6+NAT64 only). That simply isn't viable. Dual
>     stack in every hotel room in the world is viable, from the hotel gu=
ests'
>     point of view. Operators might not like it, but users wouldn't care=
=2E
>    =20
>         Brian
>    =20
>     -------------------------------------------------------------------=
-
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=

>     -------------------------------------------------------------------=
-
>    =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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From nobody Mon Nov 20 14:44:06 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B391312EAEC for ; Mon, 20 Nov 2017 14:44:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ev9AKvwbYPw for ; Mon, 20 Nov 2017 14:44:03 -0800 (PST)
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 66D9912EAEA for ; Mon, 20 Nov 2017 14:44:03 -0800 (PST)
Received: by mail-pf0-x236.google.com with SMTP id r88so4411756pfi.2 for ; Mon, 20 Nov 2017 14:44:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PCX+foOurkasWjs6F2WOi3wt3ZPqLMvS5affK4wQdK8=; b=TvVe+i4xul1jNbuINjFleHaRSPdA6sVqsWMueGBTsPtY0HlpEIy6SoFj1ZkV77LSQv z6fwiQAUO/tpc7Zy6ZHghaaua0WiK6rCkYuqg23u72+C6m2tdeQgq7cOQnSgAFapu4W3 K3XJIr3nVVaoYpuxDtmNby7kVgmWoHMv21w6OMgpW4o9CZjl69bCiL0luy4N03Ks0cmW B6dl8bkuJ63KMlAFw06P55NUi248UfXK6TFvjusZn3wEY6XmE3VfpbyDojM9AQq0QXOH USJl9rfj20wCplJnMqqHHBZbP2dikMybjA8X77ky0VTGjH4tGFfnQ+/fnLsNL7GFXKb3 CI0A==
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=PCX+foOurkasWjs6F2WOi3wt3ZPqLMvS5affK4wQdK8=; b=XpPe03V8hAEvT20EjJvMQhHh9mxxoVDImTWu0gn7m6kEefOw7J/W5jWFGzDGJXiDM2 nDXjHqZGaNjjDTlPCbJu9c60ketj0CjLFWSyyCCI4kvdoQGd7kf81H+ZL9ROzKp9fbG6 1j1kETm2mcx1oFSQVtB8YNhNCGT0WIiEmQu2q3UPbOOkOLSimg8lPwx/u8aN59cAgD99 JnEE8GvCIc7CGQeWvLb/5v1s5G8X60pjvhmSWAMjLXztA3plG/iC0hhexOOBfn2ff48l ZzOMPhSoNFbnNfnByq02eX/ORSf22TYvKk12MvF0IqU/lZTepVebOtyufdaeJRXVgHOz SueA==
X-Gm-Message-State: AJaThX4N+6Z8KJquZh27HVSMgMNY2wlKJazY5X0xjv0R4Vjy2PRyLOKS TKTTf88ErfquE0ozFFG7lxnQNw==
X-Google-Smtp-Source: AGs4zMa9qcEEe9xosfj6ijF11nyEzWD7hBYnceZwG2W2sR+ev1BPr/1PbjfKh/5OQ8hJRTWVG4yNhg==
X-Received: by 10.84.241.206 with SMTP id t14mr15354976plm.375.1511217842747;  Mon, 20 Nov 2017 14:44:02 -0800 (PST)
Received: from [130.216.38.102] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.102]) by smtp.gmail.com with ESMTPSA id m13sm16498420pgp.61.2017.11.20.14.44.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 14:44:01 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Lee Howard , "Manfredi, Albert E" 
Cc: 6man WG 
References:   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>    
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <3a20ce57-2a61-bca3-9e25-6d4c38c12888@gmail.com>
Date: Tue, 21 Nov 2017 11:44:00 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 22:44:05 -0000

On 20/11/2017 21:05, Lee Howard wrote:
=2E..
=20
> It=E2=80=99s too late for dual-stack to be the transition plan.

In my mind it never was a transition plan. It was, and remains,
a co-existence plan, which will go away when co-existence
is no longer needed.

One thing that we demonstrated very convincingly last week
is that there are enough legacy devices and applications in
existing user hosts that the co-existence plan is still needed.
(And, BTW, we demonstated it for user hosts belonging to
relatively sophisticated users.)

    Brian


From nobody Mon Nov 20 14:51:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C25112E056 for ; Mon, 20 Nov 2017 14:51:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnhQzhJYOU7C for ; Mon, 20 Nov 2017 14:51:16 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28252129C4B for ; Mon, 20 Nov 2017 14:51:16 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 595722D510E; Mon, 20 Nov 2017 22:51:15 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id BCD61200CD6D2B; Mon, 20 Nov 2017 23:51:13 +0100 (CET)
From: Ole Troan 
Message-Id: <200AD734-6AEC-4CE9-A921-B9555821B646@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_2C9EB2C6-B0F1-4CCC-9200-69A8DFF1AB44"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Mon, 20 Nov 2017 23:51:12 +0100
In-Reply-To: <3a20ce57-2a61-bca3-9e25-6d4c38c12888@gmail.com>
Cc: Lee Howard , "Manfredi, Albert E" , 6man WG 
To: Brian E Carpenter 
References:   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>     <3a20ce57-2a61-bca3-9e25-6d4c38c12888@gmail.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 22:51:17 -0000

--Apple-Mail=_2C9EB2C6-B0F1-4CCC-9200-69A8DFF1AB44
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

Brian,

> One thing that we demonstrated very convincingly last week
> is that there are enough legacy devices and applications in
> existing user hosts that the co-existence plan is still needed.
> (And, BTW, we demonstated it for user hosts belonging to
> relatively sophisticated users.)

Huh?
Data please.

Ole

--Apple-Mail=_2C9EB2C6-B0F1-4CCC-9200-69A8DFF1AB44
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+/bDNdvtpYqJhC33YFAloTXGAACgkQvtpYqJhC
33YGqBAAkXDv7slLgr/Gcfh+zUoB8KDftepTQuHUqmvcL4ihB1zhvTpfEcxVsukx
QW73M26vLs2pNJCEqTVjjPxeT56C2adzMAjguGTGZECjEBDluUtUat+gOQpVojLX
6r6plQTIAz8jIOPw9OnyhfJFwsXujASwPqB6AHJWxDFVDA4BRadTyKEW4YAY0eFs
epys7DsLKC4HAM8v0jhJe/JxKYewevYs6xpE49hGvgqPOuOgJHVWtdMb8798j8z5
22QizTHRgFfFDMyhwfYLoDkolSN3PzLVUliFQWE1I/96uNamNTP54Dy0d8ndQcD8
TJlkYJI8TMGQbVWz3Y4miPpS30lVFVzGfOIsmLJbl8+2Kmi3fVyEItREzdX5AXRt
SzftAcwngm/VG651iuIXGA1H8CtMO+GGsfEtbc92hcDsHyv9lpCit0eRTakKoSaF
3g5j9AdpMIiEo6ljGpdfVVeLZHsWa22K/uaRwXr/1Cwq4r4o4XO8hPUpAD0S52Un
VP93Srp0CJx6zGI/IbZwTwLMiK8RmcS8z3Wo3d2/voecDERbaAN8JgVJJjxCo8Rw
JOEye9idKbWSnjmQqN1g6UEv66J/m3m1S60ivXisHvUtcZNPGsuQ5dD4FVYVWCOr
wtoqyljXZYQY6UQDvAP5q4F94gRUodOAc9B4Q9F3ewrhMip2MI0=
=mQWW
-----END PGP SIGNATURE-----

--Apple-Mail=_2C9EB2C6-B0F1-4CCC-9200-69A8DFF1AB44--


From nobody Mon Nov 20 15:31:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB46129AA8 for ; Mon, 20 Nov 2017 15:31:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np-EO7BEN8bD for ; Mon, 20 Nov 2017 15:31:02 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478B5120713 for ; Mon, 20 Nov 2017 15:31:02 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id i15so8445889pfa.3 for ; Mon, 20 Nov 2017 15:31:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JGiiw0vFXgtW/bMbDU1JLeFhQWvG74t2jYBCvAhRJkY=; b=tHv1MxvUR2U4k4cGDUxwuVrP73EqEXUB9VMQO/YI+0zRanqEfc4hQEYYGurxWoZRw0 UHeryHiAXRJfhigjtYt2X4uaJmU3+TkN4fh7HC/Ce2ASVqTD+kjMH0I2BavH+Gexrysp 2F8llYNyWzHLuEw2aFx/kxGIZ/d1LTpaRpBfaRzvQCXglBqr3eiwcwBmHCcBsxhE0ScE 3yDiCZfFdFhajNMQeGIw+J/eUt7HLhDadhPy9F98zNnKqaN5dgvYex/6QMsN8aEKn/1r WPPEyiWtH++HsxFT9PKEGg2yFqL13/DV1KFXJ0zohPsaUaY7ErVp+V4DwdK925SsZNyt nrFw==
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=JGiiw0vFXgtW/bMbDU1JLeFhQWvG74t2jYBCvAhRJkY=; b=hK9WjDm57GF3GiN3DakOnqQraBwnMSraGoqp0z/tE1ZTGyiPE6PWC5bzzUPuJY7VWK Q4N5X+aBLDnRkEzo9tO3KqGG1zH+tiS3+RxuIUq3f1zF8Zn1lb2b6Jpn23BgMZHZZ27I gBIh7lADFWE3H6H5GswHBgPGv1BljVIbjHyDLpiLJeNqWiuKrviAKJ3kaK54NAbG9a7M iMfNk5Zx6clEJBr1mWuNj8CtpSNgoal5M239x+rl+D/14UconIJkC0Htm7sRf+KjhEvu bNwzeja0OXwBv7QBnUWxvF0dTkUC+GtGSMM+5h3CwO9V5YgavZttq9nJNzTPUVmTdhuJ MXaw==
X-Gm-Message-State: AJaThX6zzlk+io8umCYsfnFMkIWWvu/QV3iqqsxGQaNudNv5oHHEaKW1 PZ8L/59+wo21B5i13I4ZlSvm9w==
X-Google-Smtp-Source: AGs4zMbfv3gr3wglaLBy0kpzByz4zDA+1igaCoaoUr0CT9wgPdgRSO+lvx01yGuqvIUTwbl0brla9Q==
X-Received: by 10.98.149.72 with SMTP id p69mr13099550pfd.76.1511220661466; Mon, 20 Nov 2017 15:31:01 -0800 (PST)
Received: from [130.216.38.102] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.102]) by smtp.gmail.com with ESMTPSA id m9sm21133896pff.26.2017.11.20.15.30.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 15:31:00 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: Lee Howard , "Manfredi, Albert E" , 6man WG 
References:   <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>     <3a20ce57-2a61-bca3-9e25-6d4c38c12888@gmail.com> <200AD734-6AEC-4CE9-A921-B9555821B646@employees.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Tue, 21 Nov 2017 12:30:57 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <200AD734-6AEC-4CE9-A921-B9555821B646@employees.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 23:31:04 -0000

On 21/11/2017 11:51, Ole Troan wrote:
> Brian,
> 
>> One thing that we demonstrated very convincingly last week
>> is that there are enough legacy devices and applications in
>> existing user hosts that the co-existence plan is still needed.
>> (And, BTW, we demonstated it for user hosts belonging to
>> relatively sophisticated users.)
> 
> Huh?
> Data please.

Well, I assume that Jen et al will produce a summary report, but
the number of tickets at https://tickets.meeting.ietf.org/wiki/nat64
tells me that ietf-nat64 did not provide a smooth co-existence
experience for everybody. Imagine that each of those tickets equates
to one support call per week, multiplied by the number of hotels
in the world.

   Brian


From nobody Mon Nov 20 15:34:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2BE12E041; Mon, 20 Nov 2017 15:34:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXNwzk01sj94; Mon, 20 Nov 2017 15:34:42 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8936D120713; Mon, 20 Nov 2017 15:34:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 7B8154A; Tue, 21 Nov 2017 00:34:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1511220875; bh=qONPhq/mE69X79DllZWFFCdG/SkTHeT9OQQorW5IbCc=; b=X fF8shk0Q6RimVA7bd7lDHVUGKYa/Y/Om+fhv8SP3kbt+xJM4sBlFL2vMYshbPEMt AeqsFPoDE7hOevG6oZHAJTfAX+l7DI2GKgY7AEYYcvLbEcH+uDTWPk08Udmkq1sc 3Qjx4NXr9zxTByzg34C4Bt46UVkUoEjwjHcr2TZXP4=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DlhoRH3SETBw; Tue, 21 Nov 2017 00:34:35 +0100 (CET)
Received: from [IPv6:2a02:a213:a301:1000:f870:7e30:2e3a:e0db] (unknown [IPv6:2a02:a213:a301:1000:f870:7e30:2e3a:e0db]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 5337C49; Tue, 21 Nov 2017 00:34:34 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann 
In-Reply-To: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>
Date: Tue, 21 Nov 2017 00:34:32 +0100
Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" , "dhcwg@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F30D7F6-7859-4D2B-B550-8C8CB944FF9F@steffann.nl>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>
To: "Templin, Fred L" 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 23:34:45 -0000

Hi,

> This document therefore proposes a unification of IPv6 ND and DHCPv6 =
where
> the two functions work together as if they were one. This is =
accommodated by
> a new IPv6 ND option in RS/RA messages called the "DHCPv6 option". By =
working
> together as one function, IPv6 ND and DHCPv6 can supply requesting =
nodes with
> all link-specific autoconfiguration information and any managed =
address/prefix
> delegations in a single round trip message exchange.

Interesting way of doing this. I have thought about combining ND and =
DHCPv6 before, but more as a different distribution mechanism: ND for =
pushing options to all clients on the network, and DHCPv6 for clients =
requesting specific options for themselves. Just to make it possible to =
use both mechanisms for all options (MAP/DSLite/etc options in RA would =
be nice).

What you are doing is another way of looking at it. If I understand =
correctly you're basically keeping the full functionality of DHCPv6 but =
using RS/RA as a transport instead of UDP. I wonder what the speed =
benefit of that would be in practice. Also compared to "impatient" =
systems that send out DHCPv6 a request before even receiving an RA.

> I would ask these discussion lists to consider what is it that you =
really don't
> like about DHCPv6. Maybe you think it is ugly. Maybe you don't like =
the way
> the acronym rolls off your tongue when you speak it. Maybe it has an =
onerous
> stigma of being stateful. But, then I would also ask you to consider =
what a
> replacement would look like. Because, I think any suitable replacement
> would have to essentially duplicate what DHCPv6 already does.

In my opinion DHCPv6 is fine. I implemented a server and it is a *lot* =
cleaner to implement than DHCPv4. Just plain UDP on link-local and =
multicast sockets :)  Especially the stateless version is very easy to =
implement. It's not the ultimate configuration protocol, and for certain =
things distributing information via RA is a much better fit to the way =
the network is run. But DHCPv6 has its place and its role, and in =
certain environments (DHCPv6-PD in ISP networks, DHCPv6 in enterprise =
etc) it does what the network and system operators need.

The main problem with DHCPv6 as an operator has been dealing with DUIDs =
when the link-layer address in the DUID is based on a different =
interface than the interface sending the DHCPv6 request. Mostly because =
the requesting interface's MAC address has always been used with DHCPv4 =
and is often printed on the outside of the device. But these days LDRA =
and DHCPv6 relays can tell the DHCPv6 server what the MAC address of the =
requesting interface was, and we can use that to identify the client (in =
addition to its DUID). With vendors starting to implement this relay =
option this is mostly a solved problem now.

Another thing that makes me a bit sad is the lack of DHCPv6 reconfigure =
support. That could be used to take away some of the complaints against =
DHCPv6 (and any client-initiated configuration protocol) that there is =
no way for the network to inform the client of changes.

I see no need to replace it with something else that would indeed need =
to duplicate its functionality.

Cheers,
Sander


From nobody Mon Nov 20 15:44:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1F3129AA8 for ; Mon, 20 Nov 2017 15:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XGbjz4rIAev for ; Mon, 20 Nov 2017 15:44:55 -0800 (PST)
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 F19F5120713 for ; Mon, 20 Nov 2017 15:44:54 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id q4so8446820pfg.13 for ; Mon, 20 Nov 2017 15:44:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y2yDQnP+5Mbl/psXQvq97NSELXNDc5uEpbcfeOmlnjE=; b=gF0PyKdh4Q9sPWauFjv479NwrGPCIKWE6s1l9PQOQiiEMLQRXZ3bG3ftQT0iirE8fa +PUGwz8XRMtZyPmWThpGYJhu5DhEGpjyPS7L7hY7dYC1oTmlWFMa9cKp4+Lg8Ky9SNMR kq1tGlDCm4ph/n+Q6vqKTXV+nYamBDIZ+K3NxFGbBcYgFRhvLFc/7svPfONRR2/G2l4G 77JCOPGCBE1FBc6CJz0QFsL2UghHbP5jPSMXHwK+O8Y2boFm2bB0YX0uJq/TYPv+woJf du/dfBybb/HPT1umhEPc2pKMFGQ20C96IU+ICa07wr874b0RF/OUvdLEHj3Ah3syaPu7 d/Jg==
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=Y2yDQnP+5Mbl/psXQvq97NSELXNDc5uEpbcfeOmlnjE=; b=Si8+i6s4dWhKsCjm4BvPT1KLdyhfgq4lgdxa/JjtZ0O3Zl+l5g16MQkFnAT6pMci5L zOXCQNm196IQo9asku/jhxsVflpoIQJGKmfhXP8tnStaZVGcV3Ue3j7jO7eMRRPI4/e3 gCslt0xA4NM5GKlqfYmNZiQI3208CcsTgFaYUIjGCJTfMXBKXco22ek+4YdIlp/fxO7F rjJvh5zWBj6pGE/KMCm9jIz6dF8KzJOLnQGKFQcehP2oZtY0qbU7ooI5ImpcYHVCmvxB 7CHFGOJKVW6881ZirTWjqYWWe5kFlGIjZrPZQGN80WPGtPvT42A4iEL4UcmaF0qmhSpG DN2g==
X-Gm-Message-State: AJaThX56AGsSWTZucFXLGLcIxrpe92O8QocJcgg78SvS5ehc8ocmF5eH jhB2gIxgt5Enbdh7xphGMsh2XA==
X-Google-Smtp-Source: AGs4zMbj5Hes0jaYp8IggmyLhPW3yIqT+eOpu8V8P1Q10pNL34wdLGtq4I51InRDhtH3wuTCgqvReg==
X-Received: by 10.98.159.135 with SMTP id v7mr822401pfk.162.1511221494129; Mon, 20 Nov 2017 15:44:54 -0800 (PST)
Received: from [130.216.38.102] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.102]) by smtp.gmail.com with ESMTPSA id n72sm22724097pfg.109.2017.11.20.15.44.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 15:44:53 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Jen Linkova , "Manfredi, Albert E" 
Cc: 6man WG 
References:  <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>    
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <2b0b213c-2ef5-a1cf-4f6e-92e4e6841baa@gmail.com>
Date: Tue, 21 Nov 2017 12:44:52 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 23:44:56 -0000

Jen,
On 21/11/2017 09:33, Jen Linkova wrote:
> On Tue, Nov 21, 2017 at 7:12 AM, Manfredi, Albert E
>  wrote:
>> Very instructive thread for me, I must say. I'm getting this sense of urgency, to be rid of IPv4, but it comes from the IETF 6man wg and some ISPs.
>> Ultimately, it's not up to 6man to decide.
> 
> I do not see this thread as 6man deciding that everyone is to get rid
> of Ipv4 right now. I see it as 'there are networks deploying IPv6-only
> hosts and 6man is discussing how to help hosts to operate in such
> environment'.

Fair enough. But now, and for many years, IPv6-only hosts** will
be unusual (except on some cellular networks); IPv4-only hosts are 
common, and dual stack hosts are common.

** In my book, a host that contains even one IPv4-only application
cannot be considered as an "IPv6-only" host.
 
>> It's up to device vendors,  and up to the deployed base of devices.
>> The IETF can only suggest, and ISP networks have to meet the real world needs.
> 
> People from the real world is coming to IETF saying 'we are deploying
> Ipv6-only hosts' [1] [2]

Sure. And I think the tests last week showed two things:
1. NAT64/DNS64 is viable for IPv6-only hosts (setting aside DNSSEC).
2. IPv6-only hosts are far from universal, even among IETF
participants.

And BTW thanks for the effort behind ietf-nat64. I think it
was a very valuable effort.

Regards,
    Brian


From nobody Mon Nov 20 15:53:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFA712EAF1 for ; Mon, 20 Nov 2017 15:53:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 V8wqZGhv90KD for ; Mon, 20 Nov 2017 15:53:29 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E6B12EAF0 for ; Mon, 20 Nov 2017 15:53:29 -0800 (PST)
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id F0B7A2D5120; Mon, 20 Nov 2017 23:53:28 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 491C8200CDCCBE; Tue, 21 Nov 2017 00:53:27 +0100 (CET)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_A2D2AAFC-C763-47ED-9C97-751230222F39"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: IPv6 only host NAT64 requirements?
Date: Tue, 21 Nov 2017 00:53:26 +0100
In-Reply-To: 
Cc: Lee Howard , "Manfredi, Albert E" , 6man WG 
To: Brian E Carpenter 
References:   <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>     <3a20ce57-2a61-bca3-9e25-6d4c38c12888@gmail.com> <200AD734-6AEC-4CE9-A921-B9555821B646@employees.org> 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Nov 2017 23:53:31 -0000

--Apple-Mail=_A2D2AAFC-C763-47ED-9C97-751230222F39
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Brian,

>>> One thing that we demonstrated very convincingly last week
>>> is that there are enough legacy devices and applications in
>>> existing user hosts that the co-existence plan is still needed.
>>> (And, BTW, we demonstated it for user hosts belonging to
>>> relatively sophisticated users.)
>>=20
>> Huh?
>> Data please.
>=20
> Well, I assume that Jen et al will produce a summary report, but
> the number of tickets at https://tickets.meeting.ietf.org/wiki/nat64
> tells me that ietf-nat64 did not provide a smooth co-existence
> experience for everybody. Imagine that each of those tickets equates
> to one support call per week, multiplied by the number of hotels
> in the world.

The purpose of the experiment was to get some real data.
Before jumping to conclusions let's get the report. No-one thought this =
would work without a single flaw.
And this experiment is not about providing IPv6 only service to hotels, =
it is about providing IPv6 only + NAT64 to the IETF network.

32 tickets. Where people were encouraged to report anything. You cannot =
just assume those are real issues without looking at them.
E.g. you can discount 1151, 1175, 1185, 1160, 1174, 1172, 1159 straight =
away.
Some tickets may contain multiple issues and so on.

Looks like we're left with a handful of applications and some OS issues. =
We're not talking rocket science to get those fixed.

Ole

--Apple-Mail=_A2D2AAFC-C763-47ED-9C97-751230222F39
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+/bDNdvtpYqJhC33YFAloTavYACgkQvtpYqJhC
33akzg//ea68tovs1Og5K2JNhDSyTp9I4/Bav3CUWElAcI+qqkhASeuNkrfTZBOf
HjlHrKOQxTBxsK/5nANCCl3JJwY+naq0JkTL3bfEJKMCvi3vbk9jro1KkgI7Mdvs
ADXEsMNTbcX3VQgyB4iXYd2ZaebDJqLZan7ZlUs52mv2LVlphz0cPW3dxJoU7m+a
pJ5MHftHiUekvhiqUY7656e+A1Cu4bYyW85Itzyi8EOiGZo5VsWyMXeHvwOuG8jI
rizSeotKnn05ER1o5RTOi2mdOwiFzMI2+SWz/Ji4fVirNG2GXoo1/jruPVgH3K5B
kcNkI3n66t089ayrpPa/UwcPxNPlJ1oJ6aolcVG4bbjfX/aOIs2ClQaYyaQahZwE
Fcks7vV0jaxjEifUIBO/mLijelg/PXYKnBBXMPm9OBpa89BJ1BVu98CdxogFwTan
jZuYr04P2v9bZEUxQMY5Qzrhz2umlEeF3CXuHJt2Au3lntrag0pY4mTYg96tpsi4
uQCMJk/jBtTezPYqxDj5as46qlYeQGAseRDGTM1ue/EoZAbWiKCO2NF0KgZHktJt
86QH6sN8Rjwim/vfHAxtaMP3op5YnExnSHHeW3Om3WXZEYceuqC0kTPo/v8yNGvg
wwz0NyrcjVKLMnU4YePyZcySv+vdeoD/H98RcgMEW04CvSaheMk=
=7iYj
-----END PGP SIGNATURE-----

--Apple-Mail=_A2D2AAFC-C763-47ED-9C97-751230222F39--


From nobody Mon Nov 20 16:29:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC9F12EAFA for ; Mon, 20 Nov 2017 16:29:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfxpxYuNk39v for ; Mon, 20 Nov 2017 16:29:38 -0800 (PST)
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 6ED5812EAF5 for ; Mon, 20 Nov 2017 16:29:38 -0800 (PST)
Received: by mail-pf0-x234.google.com with SMTP id r88so4593514pfi.2 for ; Mon, 20 Nov 2017 16:29:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+iUJ4EhZz+BB5Y3cpZGIEm7J4x8XlWBD2Wb/4oC2D7E=; b=IFIjXA1257vYz5qvAks/AZXc5lDY6QI6ymPpcWyG0Lgc0jhDD7o+yssVeplOcAiwGh m2iFHrOcAzAaXZ+VWP5tpljlijkzdxrAgWSbIs7gVDe2hETMorP4ZHRubUEU2le9WM8L CO+lU7VSOmHnM4XczJ/o7FuoClAR+TXqMZUkCdz7I1HulxoLFGQnUsijzGPIIuJNVYxQ 5QAnJBDYGrz2P4Uhfwc2nJj/sYyeudhiurTi7oH0EjlvYB0qFF/8neRBiIhG0N6SPbjH EOgHPzIPFmTrToNj/5WRhqW0byC98DoHBL0lVu5gUGyJWu5g3vz9iBk5Mc+2/2/BCXAv da1A==
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=+iUJ4EhZz+BB5Y3cpZGIEm7J4x8XlWBD2Wb/4oC2D7E=; b=ZiQjk1QHXlpHdMPyNFJIZ2/JBAbOjZz2S+/PfvlnPYDpmtKkOGfFJmEuBMyQr7bb2Q L0MB6/5GdQNWIje4fxaacXK/2Ck/RUSSDTtCDpKRJV0aa0QvAfqbn7GFUkxTBazXRTzV rDr3clNhePkRPbWzsCKmr1U0RBl98uXB9jfrDcmic7A2JKKwOk53cKHPQ/WVIflI5sjP rxdeGQMOPEPh8nClPCu7aF0vk8/T6BviHEngj4lMgXRom6q3Pg8wk9ZyjPElKMSXrLzn wAaj+CWVxf9pHPuoYudUYHdIf6cEYHL7jx23woyUTyiM63ly+322KEc3CP+CesVPhnuR Hsuw==
X-Gm-Message-State: AJaThX4VJGMNHG1hoUlF1JvZGbcsKvgzDRlmbCnTCZgxUP9cXacyseAS T+MjT0UBN94gRlLvhrCZwPCrbw==
X-Google-Smtp-Source: AGs4zMbp+qgJr5pAfTjI7VD8IgvfdvNzo+VvFIuxXFZ8GHW/ppzc7kMul8UY/FN2NOiRvleHh8h8Jw==
X-Received: by 10.101.96.138 with SMTP id t10mr909728pgu.335.1511224177476; Mon, 20 Nov 2017 16:29:37 -0800 (PST)
Received: from [172.24.41.18] ([202.36.244.186]) by smtp.gmail.com with ESMTPSA id t2sm23830741pfk.90.2017.11.20.16.29.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 16:29:35 -0800 (PST)
Subject: Re: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Bob Hinden , IPv6 List 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <13371e43-d71c-d667-b6cb-b7af5c90a6c2@gmail.com>
Date: Tue, 21 Nov 2017 13:29:32 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 00:29:40 -0000

Hi,

Here are some consolidated responses to a very long thread:

> draft-ietf-sunset4-noipv4

Sorry we were unaware of that. I think that a new look at
this approach is needed given the increased experience
that we now have. But at the very minimum our draft
should recognize the earlier work.

>  If the
> meaning of the flag were modified to indicate that there is either no I=
Pv4
> service on the advertising router, or that any IPv4 service provided is=

> intended to be limited to only hosts needing it for backward
> compatibility... what I'm proposing allows a limited scale legacy IPv4
> service to be provided instead of a full scale IPv4 service.

I think that semantic ("we have IPv4 but please don't use it") is
unlikely to work in our dog-eats-dog Internet.

> I also suggest a "Host behavior" section be added.

Good idea.

> I=E2=80=99ve the feeling reading your proposal that you=E2=80=99re assu=
ming that the dual-stack hosts have the transition mechanism built-in

That's certainly not my intention. Cellular networks are different,
but in a general-purpose network, classical dual stack hosts is
the only safe assumption. We should clarify the document scope.

> - this is a trivial DOS if there is really an IPv4 network

Any single occurrence of flag=3D=3D0 says IPv4 is available. Any number
of flag=3D=3D1 does not change this. So this attack does not exist.
=20
>   =E2=80=94 "A host that receives Flag=3D1 should stop sending IPv4"=20

Yes, that is wrong as a stand-alone statement; it needs to be
qualified (in the simplest case, "only Flag=3D1", but it needs
to refer to unexpired router lifetimes, so more words are needed.)
=20
> So, no=E2=80=A6 we=E2=80=99re not going to stop sending RA messages (li=
fetime=3D0) . And so, we=E2=80=99re going to step on this 4=3D1 bit until=
 the end of time. In other words, this draft won=E2=80=99t do what it hop=
es to do.

So who is defeating the intent of the existing standards there?
OK, maybe we'd better not have that conversation. We'll think
about whether special-casing lifetime=3D=3D0, but the solution is
fail-safe: even one unexpired RA with flag=3D=3D0 will override any
number of flag=3D=3D1. We will never switch off IPv4 in such a case.

> Yep, a single flag won't work unless all routers agree on it.

That's a feature, not a bug. That's why the proposal is fail-safe.

> It would be up to the administrator to ensure that no router sent the
> option unless the network were truly IPv4-only.

No. It's router-by-router, so *all* routers must send flag=3D=3D1 to
change host behaviour to IPv6-only. Default host behaviour is
dual stack.

>     [1] I would propose making it an EFO bit and leave the reserved
> bits for potentially more IPv6-critical information signaling.

Don't you think that switching off IPv4 is IPv6-critical? :-)








From nobody Mon Nov 20 16:40:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357E512EAFA for ; Mon, 20 Nov 2017 16:40:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mT1AyiinB_V for ; Mon, 20 Nov 2017 16:40:00 -0800 (PST)
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 751B8129A9D for ; Mon, 20 Nov 2017 16:40:00 -0800 (PST)
Received: by mail-pg0-x22a.google.com with SMTP id p9so8755367pgc.8 for ; Mon, 20 Nov 2017 16:40:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CKZc8dVi4yOBpXs5l1iEQavcbsHJTvAernn9i3F4TyQ=; b=W6Q6PQO6qMaeZSpyrzcwjsDRn8hZG0qXns2vCSITtDzyC6pGHxikfFdf/as+RSv4Pk fZJKe+TMpfKZhWuwypbbvbRRr/b0kKDo8a2Rgs7ipskfnL3eQQzu7TsGjXhDubbQ7/aR idO2C0y5xeWNi7kIsA+edzyVf1nq1kbqLNZ/iYDo0ru2iBqPpO6ZVP2pilR5T1zHukG/ bQqFF6Vod7/ildOiUnGm2I81cyxOwd1nkEwTUtfBomzcyZFkHclTitWAOa2FccHxTHoZ KQYBHG9HNOlJ3XHyWIItlJs2TicSa3vJVs89l2GXSQu/oUuABsZlpvXi3e6G1qY4hYXZ 5s2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=CKZc8dVi4yOBpXs5l1iEQavcbsHJTvAernn9i3F4TyQ=; b=lSNwlpb7ehLB3T6PYcKEzCN997Q2kVcPHPHgn3QfzDoDb6zNuaVISdBb7sp0CsuQXL qk4HAGelLKlh/1UVRs6SnJwJGyc7Bg+8v9LIbVrl9xBjNWmkbps3xstS1c7uYycxYO7k nYqf2zXJl/turhTNUp3QhHkBamuZJTYIvRX/UvNl6493OqnIiiL7eicGURuRtsDGQouY vs87SDIl98IEKkmXCYH+IAbkKNaX2h2PdBW5cW5sevQI2m+8oNa3QFq7S6OUwu3pkXxS /suGX1K7TSylXVlDZDF7cfTCzUCKkQukp/kVPm+qPqxaz26KO1z8YAo6wBVtY2PltmP/ /KMg==
X-Gm-Message-State: AJaThX4RXZA0R8gJ6yTW+0Ax2LOgMqkyCOrd2BS5UyVbmI0Ofq4sxR5F pHocJ7xgkA/rwgz8u16Ok9AdUg==
X-Google-Smtp-Source: AGs4zMa23UeHZopIKup08TvYDGw/oM6Aw+pa8jteAOcnRUt8lxam5pg6MJcgy2Y7+6aEVqDa6zgIuw==
X-Received: by 10.98.161.25 with SMTP id b25mr13232861pff.103.1511224799720; Mon, 20 Nov 2017 16:39:59 -0800 (PST)
Received: from [172.24.41.18] ([202.36.244.186]) by smtp.gmail.com with ESMTPSA id w20sm23336227pfi.89.2017.11.20.16.39.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 16:39:58 -0800 (PST)
From: Brian E Carpenter 
Subject: Re: Fwd: New Version Notification for draft-hinden-ipv4flag-00.txt
To: Bob Hinden , IPv6 List 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com> 
Organization: University of Auckland
Message-ID: <01ba0acb-0528-a6b9-8830-e5d1d44de6c2@gmail.com>
Date: Tue, 21 Nov 2017 13:39:56 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 00:40:02 -0000

Hi,

This time, not truncated by fat-fingering.

Here are some consolidated responses to a very long thread:

> draft-ietf-sunset4-noipv4

Sorry we were unaware of that. I think that a new look at
this approach is needed given the increased experience
that we now have. But at the very minimum our draft
should recognize the earlier work.

>  If the
> meaning of the flag were modified to indicate that there is either no I=
Pv4
> service on the advertising router, or that any IPv4 service provided is=

> intended to be limited to only hosts needing it for backward
> compatibility... what I'm proposing allows a limited scale legacy IPv4
> service to be provided instead of a full scale IPv4 service.

I think that semantic ("we have IPv4 but please don't use it") is
unlikely to work in our dog-eats-dog Internet.

> I also suggest a "Host behavior" section be added.

Good idea.

> I=E2=80=99ve the feeling reading your proposal that you=E2=80=99re assu=
ming that the dual-stack hosts have the transition mechanism built-in

That's certainly not my intention. Cellular networks are different,
but in a general-purpose network, classical dual stack hosts is
the only safe assumption. We should clarify the document scope.

> - this is a trivial DOS if there is really an IPv4 network

Any single occurrence of flag=3D=3D0 says IPv4 is available. Any number
of flag=3D=3D1 does not change this. So this attack does not exist.
=20
>   =E2=80=94 "A host that receives Flag=3D1 should stop sending IPv4"=20

Yes, that is wrong as a stand-alone statement; it needs to be
qualified (in the simplest case, "only Flag=3D1", but it needs
to refer to unexpired router lifetimes, so more words are needed.)
=20
> So, no=E2=80=A6 we=E2=80=99re not going to stop sending RA messages (li=
fetime=3D0) . And so, we=E2=80=99re going to step on this 4=3D1 bit until=
 the end of time. In other words, this draft won=E2=80=99t do what it hop=
es to do.

So who is defeating the intent of the existing standards there?
OK, maybe we'd better not have that conversation. We'll think
about whether special-casing lifetime=3D=3D0, but the solution is
fail-safe: even one unexpired RA with flag=3D=3D0 will override any
number of flag=3D=3D1. We will never switch off IPv4 in such a case.

> Yep, a single flag won't work unless all routers agree on it.

That's a feature, not a bug. That's why the proposal is fail-safe.

> It would be up to the administrator to ensure that no router sent the
> option unless the network were truly IPv4-only.

No. It's router-by-router, so *all* routers must send flag=3D=3D1 to
change host behaviour to IPv6-only. Default host behaviour is
dual stack.

>     [1] I would propose making it an EFO bit and leave the reserved
> bits for potentially more IPv6-critical information signaling.

Don't you think that switching off IPv4 is IPv6-critical? :-)

>     [2] I would not say that 0 means "IPv4 is Available on this
> Router" but rather "this router makes no attestation about the
> availability or lack thereof of IPv4"

I'm not sure.  It doesn't really matter, because it's only when
there are no unexpired RAs with flag=3D=3D0 that we switch off IPv4.
So the only assertion that matters is that flag=3D=3D1 means "I don't
route IPv4, but I don't know what other routers do."

>=20
> there would also be a SAVI implication here; otherwise any connected
> host on an l2 domain would be able to disable ipv4 on any host that was=

> listening to a flag of this form.

No. As long as at least one unexpired RA has flag=3D=3D0, nobody stops
trying IPv4. A bad actor can send as many flag=3D=3D1 bogons as it
wants; they will be no-ops.

    Brian








From nobody Mon Nov 20 17:01:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354C812EB08 for ; Mon, 20 Nov 2017 17:01:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7icNt2lyiwCx for ; Mon, 20 Nov 2017 17:01:53 -0800 (PST)
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 2A55412EB07 for ; Mon, 20 Nov 2017 17:01:53 -0800 (PST)
Received: by mail-pf0-x22a.google.com with SMTP id r88so4650213pfi.2 for ; Mon, 20 Nov 2017 17:01:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=t35qHIlP8nwOudO5jIQkYv5FtGyAw6yXMRp7w7chNUE=; b=cfTrb5QMYxw7AE6mJgulMF6O0PwMEnxptG5byXH8g4huCxI+PWugbc4yn5srUXEgsQ 0RYfgLrYqPOajvsJcFZ+gXITS5n4Ei6GTlhn/OMKLy3NgLEF81SU5u2mbGgeYL4qZav3 FN1Tjj0gaK9y2ZeqYaFZGiIYIDH7kR3o21jWbO0/BTJM9CiD/d42zOmWgOLFJv63HQJQ nieUZNMb+ZDlQ0/3kVStBjDOVauYG23HfNjTRGsk5wjWzNl046LCa19aETGzbB6Ici3L l8H6punzeDqqvbpuN5xNEsc7R5afTU1/ie23FqS7CxNV8EFlkAQmA+pLw/Bzh0vM34cr D+CA==
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=t35qHIlP8nwOudO5jIQkYv5FtGyAw6yXMRp7w7chNUE=; b=tiFFk5awDpeIuJblOsaVA2cVUzxaBL7ah8qGH2NTMf4EkbMS48rxPVTE6OF0zcrIjo XB/IMnsdvTp3KASOCUkMMLaxO5sAmo0KbHw0OAcPVNzKazl16bERr8aP8B1JiCG0mlu4 GoUW5jTS/0AdfguHv69wrilwUUER502y0pXXH8Y8HIi0AyfzEdlkwciri7xp+g2GmfO2 DYQP0SrnKqr2tbepK5PG7iThhNF5dJcHc/gfWAPj/eCl6CmPq3B+v+XTWrBiEmVyxnc+ HIlq6a0UaA09esgnIYIhDVDxfY/9vjuJXDct9+B3HdpnQ54SFyTdmFGVvIgp5tENtdvs Q4bg==
X-Gm-Message-State: AJaThX48GW2I2aA/C44kG086Y/WOP2t7auwXqgMmoV2GyPw5Q4h1XciO Bnk4DAQLRshLtWdgkoBGkHxnQg==
X-Google-Smtp-Source: AGs4zMZgjbgwAx4bgyC3lBqLTPbAVhq6d9seA1fcTeIhM1gWOLXQ+pECJbQ8SvVZsK3BRtrmV4riQA==
X-Received: by 10.101.68.69 with SMTP id e5mr14922821pgq.282.1511226112000; Mon, 20 Nov 2017 17:01:52 -0800 (PST)
Received: from [172.24.41.18] ([202.36.244.186]) by smtp.gmail.com with ESMTPSA id 76sm21705747pfn.179.2017.11.20.17.01.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 17:01:50 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Ole Troan 
Cc: Lee Howard , "Manfredi, Albert E" , 6man WG 
References:  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>     <3a20ce57-2a61-bca3-9e25-6d4c38c12888@gmail.com> <200AD734-6AEC-4CE9-A921-B9555821B646@employees.org>  
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <16d4277c-5ea7-1615-fecb-355436e1fcfc@gmail.com>
Date: Tue, 21 Nov 2017 14:01:47 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 01:01:56 -0000

On 21/11/2017 12:53, Ole Troan wrote:
> Brian,
> 
>>>> One thing that we demonstrated very convincingly last week
>>>> is that there are enough legacy devices and applications in
>>>> existing user hosts that the co-existence plan is still needed.
>>>> (And, BTW, we demonstated it for user hosts belonging to
>>>> relatively sophisticated users.)
>>>
>>> Huh?
>>> Data please.
>>
>> Well, I assume that Jen et al will produce a summary report, but
>> the number of tickets at https://tickets.meeting.ietf.org/wiki/nat64
>> tells me that ietf-nat64 did not provide a smooth co-existence
>> experience for everybody. Imagine that each of those tickets equates
>> to one support call per week, multiplied by the number of hotels
>> in the world.
> 
> The purpose of the experiment was to get some real data.
> Before jumping to conclusions let's get the report. No-one thought this would work without a single flaw.
> And this experiment is not about providing IPv6 only service to hotels, it is about providing IPv6 only + NAT64 to the IETF network.
> 
> 32 tickets. Where people were encouraged to report anything. You cannot just assume those are real issues without looking at them.
> E.g. you can discount 1151, 1175, 1185, 1160, 1174, 1172, 1159 straight away.
> Some tickets may contain multiple issues and so on.
> 
> Looks like we're left with a handful of applications and some OS issues. We're not talking rocket science to get those fixed.

Sure, and we should try. But we can't fix legacy hosts in the hands of the general public.

   Brian


From nobody Mon Nov 20 17:15:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3591205F0 for ; Mon, 20 Nov 2017 17:15:37 -0800 (PST)
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 wZAEELxLuswh for ; Mon, 20 Nov 2017 17:15:35 -0800 (PST)
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 64E09120454 for ; Mon, 20 Nov 2017 17:15:35 -0800 (PST)
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 C459A3AC64E; Tue, 21 Nov 2017 01:15:32 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 8DFE0160082; Tue, 21 Nov 2017 01:15:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7E99916006A; Tue, 21 Nov 2017 01:15:32 +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 4AjfIqb_ZVKG; Tue, 21 Nov 2017 01:15:32 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 99EF8160054; Tue, 21 Nov 2017 01:15:31 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: IPv6 only host NAT64 requirements?
From: Mark Andrews 
In-Reply-To: <16d4277c-5ea7-1615-fecb-355436e1fcfc@gmail.com>
Date: Tue, 21 Nov 2017 12:15:29 +1100
Cc: Ole Troan , 6man WG 
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C1C841F-2443-4E24-8BC8-1863A8D063E6@isc.org>
References:  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>     <3a20ce57-2a61-bca3-9e25-6d4c38c12888@gmail.com> <200AD734-6AEC-4CE9-A921-B9555821B646@employees.org>   <16d4277c-5ea7-1615-fecb-355436e1fcfc@gmail.com>
To: Brian E Carpenter 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 01:15:37 -0000

> On 21 Nov 2017, at 12:01 pm, Brian E Carpenter =
 wrote:
>=20
> On 21/11/2017 12:53, Ole Troan wrote:
>> Brian,
>>=20
>>>>> One thing that we demonstrated very convincingly last week
>>>>> is that there are enough legacy devices and applications in
>>>>> existing user hosts that the co-existence plan is still needed.
>>>>> (And, BTW, we demonstated it for user hosts belonging to
>>>>> relatively sophisticated users.)
>>>>=20
>>>> Huh?
>>>> Data please.
>>>=20
>>> Well, I assume that Jen et al will produce a summary report, but
>>> the number of tickets at https://tickets.meeting.ietf.org/wiki/nat64
>>> tells me that ietf-nat64 did not provide a smooth co-existence
>>> experience for everybody. Imagine that each of those tickets equates
>>> to one support call per week, multiplied by the number of hotels
>>> in the world.
>>=20
>> The purpose of the experiment was to get some real data.
>> Before jumping to conclusions let's get the report. No-one thought =
this would work without a single flaw.
>> And this experiment is not about providing IPv6 only service to =
hotels, it is about providing IPv6 only + NAT64 to the IETF network.
>>=20
>> 32 tickets. Where people were encouraged to report anything. You =
cannot just assume those are real issues without looking at them.
>> E.g. you can discount 1151, 1175, 1185, 1160, 1174, 1172, 1159 =
straight away.
>> Some tickets may contain multiple issues and so on.
>>=20
>> Looks like we're left with a handful of applications and some OS =
issues. We're not talking rocket science to get those fixed.
>=20
> Sure, and we should try. But we can't fix legacy hosts in the hands of =
the general public.

But we can send feed back to the vendors of the products they are using =
that the product they are shipping does not work in this environment for =
this reason.  More and more of their clients will be behind some sort of =
IPv6 as a service and there products should work in that environment.  =
Eventually the fixed will get deployed.

I also think it is a myth that we tell ourselves that hosts won=E2=80=99t =
get updated.  They get updated all the time provided the vendor of the =
product puts out a fix.  Its getting the vendor to publish the fix that =
is the hard part.

Mark

>   Brian
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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


From nobody Mon Nov 20 17:42:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D821242F7 for ; Mon, 20 Nov 2017 17:42:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjWOqXSxjfQu for ; Mon, 20 Nov 2017 17:42:29 -0800 (PST)
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 2B808124217 for ; Mon, 20 Nov 2017 17:42:29 -0800 (PST)
Received: by mail-pf0-x234.google.com with SMTP id 17so8653067pfn.12 for ; Mon, 20 Nov 2017 17:42:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BxhFkL4Zgi4evhIWj0matdWiqLQ6GQr1GPrenwoLaAA=; b=UMJMFBc4Y5TVNe+v950XNfev6CaD3j9DmeHt9YoC9YhG2kr+Y+izn9WQVEmO9Hcdsh N3RRkyxMPn8nw/POQ+rJdaTmONsvVhnG5k2JIupjurli4UmO1Vi7CQDwQDC+ubCulmB9 CrZEWPwSFxWMhj/3T+9bjsc54ltQhArwV/hKFq3FeOraTrcWwyc+PoXUk7ozfcuKJAE+ spfZyyJmuFaj1f784FnSx/xaEy6G6/6+D9ngpjk5SPbZ5OhOuYCKfnF0c3YgapwucmMm MqTkEw+C7UUGQmyqlzTZr7ue1A32sKZyOQQKUi5EXDcT8RGir7zxVkycVcohzmeVph2f sjKQ==
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=BxhFkL4Zgi4evhIWj0matdWiqLQ6GQr1GPrenwoLaAA=; b=cLdpJ9qUTHV7yOPfJUc49ff5NsCWbgQOr8LK2tNiryzDGEIZPok69VJeuwngIFA7xI oriYix8I5LcwEBFr7/hS9jGc/4kLesELWPI3yx3Oe2jzTkvpvbYlcnYh7a0PIOeRn6Th JjwwvtisnAv5PiO8DG3+mHDNyrs/MxJDmBkNlXo0/sZ4W8bZeqgvm40wT/f1kVECXBq8 PnEfrfYbpOAXcJy0G/l3Z/Spg93chSEGyCribcWVfMPXTTeLFJY356IAoZLzwN7m0u3W xGq9IIUs5rsyh02GO1c3TQOU50MaLHULqbV9FFFwTXl4U//U9JgRII9RSU6RejyCssff b60g==
X-Gm-Message-State: AJaThX5kWapZeYbLTuXwX8+LIwBfic7ENvCS2yXb9aCfDaKcajx9kpFH BD0Jtwwcn0tIZTcHGyR5jxzT/g==
X-Google-Smtp-Source: AGs4zMb6+sqx4xB3ZKp8irlLgODt6mPquJEhg54FwD10qi54hQLSulImnLTY4W2X7k1zDLERxPHVqw==
X-Received: by 10.84.246.194 with SMTP id j2mr15578424plt.7.1511228548161; Mon, 20 Nov 2017 17:42:28 -0800 (PST)
Received: from [130.216.38.102] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.102]) by smtp.gmail.com with ESMTPSA id y20sm20862251pgc.52.2017.11.20.17.42.26 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 17:42:27 -0800 (PST)
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: ipv6@ietf.org
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com> <19B39788-CEC6-478A-A303-7F42904533DF@huitema.net>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <0a8f6120-bb8e-a4ae-d011-01d0a19c341a@gmail.com>
Date: Tue, 21 Nov 2017 14:42:26 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <19B39788-CEC6-478A-A303-7F42904533DF@huitema.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 01:42:31 -0000

Another response to multiple points:
=20
> If people really care, they should just program the local routers and s=
witches to block the IPv4 related multicast traffic. That will be much mo=
re direct than a bit in some RA.

Layer 2 or layer 3 blocking is fine, but it doesn't help
the battery life of the dual stack hosts.

> How about a transition rule for dual stack implementations? If there is=
 IPv6 connectivity, don=E2=80=99t bother trying to establish IPv4? Maybe =
qualify that rule with availability of a 6to4 prefix?

I really hope you didn't mean "6to4". But that heuristic will only help
if all apps are IPv6-capable, which the IP stack cannot know. (It also
leaves IPv4 literals out in the cold.)

> 1. Security exposure; the inverse of the problems discussed in RFC7123,=

> basically malicious or accidental IPv4 service.
> 2. Residual IPv4 traffic, especially broadcast traffic; DHCP solicits,
> IPv4-LL, ARP, service discovery, etc...

The proposal addresses only one thing: attempting to reduce
futile IPv4 traffic. It neither creates nor blocks IPv4 traffic.

> In very high dentistry and therefore
> typically congested WiFi environments...

A new view of dentist's office networking ;-)

> Probably the best that can be done by the client is to be "less aggress=
ive" in trying to configure IPv4 when IPv6 is available and you don't see=
m to see IPv4 traffic from other nodes.

Indeed, but that's mainly an implementation choice. This proposal offers
a hint to assist that heuristic, if you like.

> Let's not forget about battery life.

Agreed. Every little helps.

> It just seems operationally simpler to create a new option in dhcpv4

I don't see how that works on a network with no DHCPv4 server.

> if IPv4 appears you probably want to start
> using it after a reasonable amount of time.

Indeed. And under the proposal, any RA with flag=3D=3D0 would be
an instant trigger to wake up the IPv4 stack. (And no, that
isn't a serious DOS risk, since it is no worse than what
we have today.)

   Brian



From nobody Mon Nov 20 20:11:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886C9126C23 for ; Mon, 20 Nov 2017 20:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeZitmFc2l2Q for ; Mon, 20 Nov 2017 20:11:35 -0800 (PST)
Received: from tyo162.gate.nec.co.jp (tyo162.gate.nec.co.jp [114.179.232.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B6E1201F2 for ; Mon, 20 Nov 2017 20:11:34 -0800 (PST)
Received: from mailgate02.nec.co.jp ([114.179.233.122]) by tyo162.gate.nec.co.jp (8.15.1/8.15.1) with ESMTPS id vAL4BPK2022900 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 21 Nov 2017 13:11:25 +0900
Received: from mailsv02.nec.co.jp (mailgate-v.nec.co.jp [10.204.236.94]) by mailgate02.nec.co.jp (8.15.1/8.15.1) with ESMTP id vAL4BPV2024049; Tue, 21 Nov 2017 13:11:25 +0900
Received: from mail03.kamome.nec.co.jp (mail03.kamome.nec.co.jp [10.25.43.7]) by mailsv02.nec.co.jp (8.15.1/8.15.1) with ESMTP id vAL4Ae6n013897;  Tue, 21 Nov 2017 13:11:25 +0900
Received: from bpxc99gp.gisp.nec.co.jp ([10.38.151.149] [10.38.151.149]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-4552791; Tue, 21 Nov 2017 13:11:03 +0900
Received: from BPXM24GP.gisp.nec.co.jp ([10.38.151.216]) by BPXC21GP.gisp.nec.co.jp ([10.38.151.149]) with mapi id 14.03.0319.002; Tue, 21 Nov 2017 13:11:02 +0900
From: Masanobu Kawashima 
To: "jordi.palet@consulintel.es" , 6man WG 
Subject: RE: IPv6 only host NAT64 requirements?
Thread-Topic: IPv6 only host NAT64 requirements?
Thread-Index: AQHTX4U1kdVLYyQoy0SFVq2ZnvkKraMc5AXw//96jQCAABYJAIAADLsAgAAc7ICAABUUgIAAZL4AgAAJPgCAAACkAIABCKFg
Date: Tue, 21 Nov 2017 04:11:01 +0000
Message-ID: <81A3232BEF82944C8F23DB1CFE276F0F494BDF1B@BPXM24GP.gisp.nec.co.jp>
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es> 
In-Reply-To: 
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.3.141.9]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 04:11:37 -0000

DQpIaSBKb3JkaSwgDQoNCj4gQXQgc29tZSBwb2ludCB0aGUgTkFUNjQgc2VydmljZSwgaW5zdGVh
ZCBvZiBiZWluZyBwcm92aWRlZCBieSB0aGUgSVNQIGl0IHdpbGwgbWFrZSBzZW5zZSB0byBiZSBw
cm92aWRlZCBieSB0aGlyZCBwYXJ0eQ0KPiBjb21wYW5pZXMsIGV2ZW4gaWYgdGhlcmUgaXMgc29t
ZSBleHRyYSBkZWxheSB0byByZWFjaCBhIHJlbW90ZSBOQVQ2NCwgZXRjLiwgYW5kIGV2ZW4gaWYg
dGhlcmUgaXMgYW4gZXh0cmEgY29zdCBmb3IgdGhhdA0KPiBjdXN0b21lciB0aGF0IHN0aWxsIHJl
cXVpcmVzIGl0LiANCg0KSW4gSmFwYW4sIEpQSVgoSmFwYW4gSW50ZXJuZXQgRXhjaGFuZ2UpIGlz
IHByb3ZpZGluZyA0NjRYTEFUIHRyaWFsIHNlcnZpY2UgDQp0byBJU1BzLiANCmh0dHBzOi8vd3d3
LmpwaXguYWQuanAvZW4vdGVjaG5pY2FsX2V4Y2hhbmdlLnBocCANCg0KUExBVChOQVQ2NCBzZXJ2
aWNlKSBpcyBwcm92aWRpbmcgZnJvbSBKUElYLCB0aGVuIElTUHMgYXJlIHVzaW5nIENMQVQgQ1BF
LiANCldlIG1pZ2h0IG5lZWQgdGhpcyBraW5kIG9mIHNlcnZpY2UgbmVhciBmdXR1cmUuIA0KSnVz
dCBGWUkuIDotKSANCg0KUmVnYXJkcywgDQpNYXNhbm9idSANCg0KPT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09IA0KIE5FQyBQbGF0Zm9ybXMsIEx0ZC4gICAgICAgICAgICAgICAg
IA0KIEFjY2Vzcy1EZXZpY2UgRGl2aXNpb24gICAgICAgICAgICAgIA0KIEtBV0FTSElNQSBNYXNh
bm9idSAgICAgICAgICAgICAgICAgIA0KIGthd2FzaGltYW1AdnguanAubmVjLmNvbSAgICAgICAg
ICAgIA0KIGh0dHBzOi8vd3d3Lm5lY3BsYXRmb3Jtcy5jby5qcC9lbi8gIA0KPT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09IA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm
IE9mIEpPUkRJIFBBTEVUIE1BUlRJTkVaDQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDIxLCAy
MDE3IDU6MTMgQU0NCj4gVG86IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJl
OiBJUHY2IG9ubHkgaG9zdCBOQVQ2NCByZXF1aXJlbWVudHM/DQo+IA0KPiBBbmQgYnkgdGhlIHdh
eSDigKYNCj4gDQo+IEF0IHNvbWUgcG9pbnQgdGhlIE5BVDY0IHNlcnZpY2UsIGluc3RlYWQgb2Yg
YmVpbmcgcHJvdmlkZWQgYnkgdGhlIElTUCBpdCB3aWxsIG1ha2Ugc2Vuc2UgdG8gYmUgcHJvdmlk
ZWQgYnkgdGhpcmQgcGFydHkNCj4gY29tcGFuaWVzLCBldmVuIGlmIHRoZXJlIGlzIHNvbWUgZXh0
cmEgZGVsYXkgdG8gcmVhY2ggYSByZW1vdGUgTkFUNjQsIGV0Yy4sIGFuZCBldmVuIGlmIHRoZXJl
IGlzIGFuIGV4dHJhIGNvc3QgZm9yIHRoYXQNCj4gY3VzdG9tZXIgdGhhdCBzdGlsbCByZXF1aXJl
cyBpdC4NCj4gDQo+IFJlZ2FyZHMsDQo+IEpvcmRpDQo+IA0KPiANCj4gLS0tLS1NZW5zYWplIG9y
aWdpbmFsLS0tLS0NCj4gRGU6IGlwdjYgPGlwdjYtYm91bmNlc0BpZXRmLm9yZz4gZW4gbm9tYnJl
IGRlIEpPUkRJIFBBTEVUIE1BUlRJTkVaIDxqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4gUmVz
cG9uZGVyIGE6DQo+IDxqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcz4NCj4gRmVjaGE6IGx1bmVz
LCAyMCBkZSBub3ZpZW1icmUgZGUgMjAxNywgMjE6MTENCj4gUGFyYTogNm1hbiBXRyA8aXB2NkBp
ZXRmLm9yZz4NCj4gQXN1bnRvOiBSZTogSVB2NiBvbmx5IGhvc3QgTkFUNjQgcmVxdWlyZW1lbnRz
Pw0KPiANCj4gICAgIEl0IGlzIGNsZWFyIHRvIG1lIHRoYXQgaG90ZWwgcm9vbXMgbmVlZCB0byBw
cm92aWRlIElQdjYgKyBJUHY0LWFzLWEtc2VydmljZSAoZm9yIGV4YW1wbGUgdXNpbmcgYSBDRSBv
ciBBUCB3aXRoIENMQVQpLg0KPiANCj4gICAgIFRoZSBob3RlbCBuZXR3b3JrIG9yIGl0cyBhY2Nl
c3MgY2FuIGJlIElQdjYtb25seSBhbmQgdGhlbiB0aGUgSVNQIHByb3ZpZGUgdGhlIE5BVDY0Lg0K
PiANCj4gICAgIEnigJltIHN1cmUgc29tZW9uZSB3aWxsIGFyZ3VlIHRoYXQgdGhpcyBtZWFucyBw
ZXJwZXR1YXRpbmcgSVB2NDogSXMgbm90IHRoZSBjYXNlLg0KPiANCj4gICAgIFRoZSBjYXNlIGlz
IGJlaW5nIHJlYWxpc3RpYyBhYm91dCB3aGF0IGFuIElTUCBvciBhbiBob3RlbCBvciBhbnkgb3Ro
ZXIgb3JnYW5pemF0aW9ucyBORUVEcyB0byBwcm92aWRlIHRvIHRoZWlyIGN1c3RvbWVycw0KPiBp
ZiB0aGV5IHdhbnQgdG8ga2VlcCB0aGVtLg0KPiANCj4gICAgIElmIHRoZSBob3RlbHMgcHJvdmlk
ZSBJUHY2ICsgSVB2NC1hcy1hLXNlcnZpY2UsIHRoZSBjdXN0b21lciBpcyBoYXBweSBhbmQgbW9y
ZSBhbmQgbW9yZSB0cmFmZmljIGlzIG1vdmluZyBmcm9tIElQdjQNCj4gdG8gSVB2NiBpbiBhIG5h
dHVyYWwgd2F5Lg0KPiANCj4gICAgIElmIHNvbWUgYXBwIGRldmVsb3BlcnMgZG9u4oCZdCBzZWUg
aXQsIG9yIGlmIHNvbWUgY29udGVudCBwcm92aWRlcnMgb3IgZW50ZXJwcmlzZXMgd2hlcmUgdGhl
IFZQTiBpcyBiZWluZyBjb25uZWN0ZWQsDQo+IHRoZXJlIHdpbGwgYmUgYSBwb2ludCB3aGVyZSB0
aGUgSVB2NCB0cmFmZmljIGlzIG1lYW5pbmdsZXNzIGFuZCB0aGV5IGhhdmUgdGhlIHJpc2sgdGhh
dCBhdCB0aGF0IHBvaW50IHRoZSBJUHY0LWFzLWEtc2VydmljZQ0KPiBpcyBub3Qgb2ZmZXJlZCBh
bnltb3JlLCBub3QgYmVjYXVzZSB0aGUgY29zdCBvZiB0aGUgQ0xBVCwgYnV0IGJlY2F1c2UgdGhl
IGNvc3Qgb2YgdGhlIE5BVDY0Lg0KPiANCj4gICAgIFRoZSBvbmx5IHdheSB3ZSBjYW4gbW90aXZh
dGUgYWxsIHRoZW0gdG8gbW92ZSB0byBJUHY2IGlzIHRvIG1ha2Ugc3VyZSB0aGF0IHdoZW4sIGZv
ciBleGFtcGxlIDc1JSBvZiB0aGUgSW50ZXJuZXQgdHJhZmZpYw0KPiBpcyBJUHY2LCB3ZSBjbGVh
cmx5IGFubm91bmNlIHRoYXQgSVB2NCBpcyBoaXN0b3JpY2FsLCBoYXMgbm90IG1haW50ZW5hbmNl
LCBhbmQgd2lsbCBiZSBkcm9wcGVkIGFuZCB1bnN1cHBvcnRlZCBhbmQgd2lsbA0KPiBub3QgYmUg
YWJsZSB0byBiZSByZWFjaGFibGUuIEl0IGlzIHRoZSBJU1BzIHdvcmsgdG8gZGVjaWRlIGlmIHRo
ZXkgd2FudCB0byBrZWVwIHByb3ZpZGluZyBOQVQ2NCBvciBub3QsIGFuZCB0byB0ZWxsIHRoZWly
DQo+IGN1c3RvbWVycy4gQXQgc29tZSBwb2ludCwgbW9yZSBhbmQgbW9yZSBJU1BzIHdpbGwgZHJv
cCB0aGF0IHNlcnZpY2UuIFdoZXJldmVyIHRoYXQgcG9pbnQgaXMgYXQgdGhlIDc1JSBvZiBJUHY2
IHRyYWZmaWMNCj4gb3IgOTUlIG9yIHNvbWV0aGluZyBpbiB0aGUgbWlkZGxlIGlzIHRvIGJlIGRl
Y2lkZWQgYnkgZWFjaCBJU1AsIGFsc28gbWF5YmUgZGVwZW5kaW5nIG9uIHRoZWlyIGNvbXBldGl0
b3JzLCBldGMuDQo+IA0KPiAgICAgSSByZWNhbGwgYSBmZXcgeWVhcnMgYWdvIHdoZW4gYSBwaG9u
ZSBjb21wYW55IGluIFNwYWluIHN0aWxsIGhhZCBhIGZldyBjdXN0b21lcnMgd2l0aCBvbGQg4oCc
cHVsc2UgZGlzayBwaG9uZXPigJ0uIFRoZXkNCj4gdG9vayB0aGUgZGVjaXNpb24gdG8gY2FuY2Vs
IHRoZSBjb250cmFjdCB0byB0aG9zZSBjdXN0b21lcnMgaWYgdGhleSBkb27igJl0IHdhbnQgdG8g
Z2V0IHRoZSBwaG9uZSByZXBsYWNlcyB3aXRoIERUTUYgcGhvbmVzLg0KPiANCj4gICAgIFNhbWUg
dG9kYXkgaXMgaGFwcGVuaW5nIHdpdGggY3VzdG9tZXJzIHdpdGggQURTTCB3aGVyZSB0aGVyZSBp
cyBHUE9OIGNvdmVyYWdlLiBZb3UgYWNjZXB0IHRvIGJlIHJlcGxhY2VkIHRvIEdQT04sDQo+IG9y
IHRoZXkgY2FuY2VsIHRoZSBjb250cmFjdCwgYmVjYXVzZSBpdCBpcyBtb3JlIGV4cGVuc2l2ZSB0
byBrZWVwIGEgZmV3IOKAnG9sZCBmYXNoaW9uZWTigJ0gY3VzdG9tZXJzIHRoYXQgdGhlIHByb2Zp
dCB0aGV5DQo+IGdlbmVyYXRlLg0KPiANCj4gICAgIFJlZ2FyZHMsDQo+ICAgICBKb3JkaQ0KPiAN
Cj4gDQo+ICAgICAtLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiAgICAgRGU6IGlwdjYgPGlw
djYtYm91bmNlc0BpZXRmLm9yZz4gZW4gbm9tYnJlIGRlIEJyaWFuIEUgQ2FycGVudGVyIDxicmlh
bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+DQo+ICAgICBPcmdhbml6YWNpw7NuOiBVbml2ZXJzaXR5
IG9mIEF1Y2tsYW5kDQo+ICAgICBSZXNwb25kZXIgYTogPGJyaWFuLmUuY2FycGVudGVyQGdtYWls
LmNvbT4NCj4gICAgIEZlY2hhOiBsdW5lcywgMjAgZGUgbm92aWVtYnJlIGRlIDIwMTcsIDIwOjM3
DQo+ICAgICBQYXJhOiBPbGUgVHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPiwgTW9oYW1lZCBC
b3VjYWRhaXIgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+ICAgICBDQzogNm1hbiBX
RyA8aXB2NkBpZXRmLm9yZz4sIE1hcmsgQW5kcmV3cyA8bWFya2FAaXNjLm9yZz4NCj4gICAgIEFz
dW50bzogUmU6IElQdjYgb25seSBob3N0IE5BVDY0IHJlcXVpcmVtZW50cz8NCj4gDQo+ICAgICAg
ICAgT24gMjEvMTEvMjAxNyAwMjozNiwgT2xlIFRyb2FuIHdyb3RlOg0KPiAgICAgICAgIC4uLj4+
IFtNZWRdIFRoZXNlIGFyZSBnZW5lcmljIHN0YXRlbWVudHMsIE9sZS4gV2UgYXJlIHRhbGtpbmcg
YWJvdXQgdGhlIElFVEYgY2FzZS4NCj4gICAgICAgICA+PiAqIFRoZSBJRVRGIGhhcyBubyBjb250
cm9sIG9uIHRoZSBob3N0cyB0aGF0IGNvbm5lY3QgdG8gdGhlIElFVEYgbmV0d29yaywNCj4gICAg
ICAgICA+PiAqIElFVEYgYXR0ZW5kZWVzIHdobyBhcmUgdXNpbmcgY29ycG9yYXRlIGRldmljZXMs
IGhhdmUgbm8gY29udHJvbCBvbiB0aGVzZSBob3N0cw0KPiAgICAgICAgID4+DQo+ICAgICAgICAg
Pj4gU28sIGhvdyBmb3JjaW5nIGRldmljZXMgdG8gdXNlICJJUHY2K25hdDY0IiB3aWxsIGhlbHAg
aGVyZT8NCj4gICAgICAgICA+DQo+ICAgICAgICAgPiBFYXQgb3duIGRvZ2Zvb2QuIE1hbnkgSUVU
RiBwZW9wbGUgYXJlIGRldmVsb3BlcnMgb3Igd29yayBmb3IgY29tcGFuaWVzIGhhdmluZyBhcHBs
aWNhdGlvbnMgbm90IHdvcmtpbmcuDQo+ICAgICAgICAgPiBBcyBJIHNhaWQgdGhlcmUgd2VyZSBh
IG1pbmltdW0gb2YgYXBwbGljYXRpb25zIHRoYXQgZGlkbid0IHdvcmsuIENvcnBvcmF0ZSBWUE5z
IGxhcmdlbHkgZGlkLiBKZW4gaGFzIHRoZSBmaW5hbA0KPiBudW1iZXJzLg0KPiANCj4gICAgICAg
ICBIb3dldmVyLCBhcyBsb25nIGFzIGV2ZW4gb25lIGFwcGxpY2F0aW9uLCBzdWNoIGFzIG9uZSBW
UE4sIG9yIG9uZQ0KPiAgICAgICAgIGxpdGVyYWwgSVB2NCBhZGRyZXNzLCBmYWlscywgdGhhdCBy
ZXByZXNlbnRzIG1pbGxpb25zIG9mIGZhaWx1cmUgY2FzZXMNCj4gICAgICAgICBpZiB3ZSBjb25z
aWRlciB0aGUgd2hvbGUgd29ybGQgKGUuZy4gaW1hZ2luZSBldmVyeSBob3RlbCBuZXR3b3JrIGlu
DQo+ICAgICAgICAgdGhlIHdvcmxkIHJ1bm5pbmcgSVB2NitOQVQ2NCBvbmx5KS4gVGhhdCBzaW1w
bHkgaXNuJ3QgdmlhYmxlLiBEdWFsDQo+ICAgICAgICAgc3RhY2sgaW4gZXZlcnkgaG90ZWwgcm9v
bSBpbiB0aGUgd29ybGQgaXMgdmlhYmxlLCBmcm9tIHRoZSBob3RlbCBndWVzdHMnDQo+ICAgICAg
ICAgcG9pbnQgb2Ygdmlldy4gT3BlcmF0b3JzIG1pZ2h0IG5vdCBsaWtlIGl0LCBidXQgdXNlcnMg
d291bGRuJ3QgY2FyZS4NCj4gDQo+ICAgICAgICAgICAgIEJyaWFuDQo+IA0KPiAgICAgICAgIC0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQo+ICAgICAgICAgSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0
DQo+ICAgICAgICAgaXB2NkBpZXRmLm9yZw0KPiAgICAgICAgIEFkbWluaXN0cmF0aXZlIFJlcXVl
c3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gICAgICAg
ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+IA0KPiANCj4gICAgICoqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gICAgIElQdjQgaXMgb3Zlcg0KPiAgICAgQXJl
IHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+ICAgICBodHRwOi8vd3d3LmNvbnN1
bGludGVsLmVzDQo+ICAgICBUaGUgSVB2NiBDb21wYW55DQo+IA0KPiAgICAgVGhpcyBlbGVjdHJv
bmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQg
b3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQNCj4gdG8gYmUgZm9y
IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBm
dXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWluZywNCj4g
ZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwg
ZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkg
cHJvaGliaXRlZA0KPiBhbmQgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZS4g
SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBk
aXNjbG9zdXJlLCBjb3B5aW5nLA0KPiBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50
cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFj
aGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLA0KPiB3aWxsIGJlIGNvbnNpZGVyZWQg
YSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2Vu
ZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kDQo+IGRlbGV0ZSBpdC4N
Cj4gDQo+IA0KPiANCj4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgICBJRVRGIElQdjYgd29ya2luZyBn
cm91cCBtYWlsaW5nIGxpc3QNCj4gICAgIGlwdjZAaWV0Zi5vcmcNCj4gICAgIEFkbWluaXN0cmF0
aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYN
Cj4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAgICAgKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKg0KPiAgICAgSVB2NCBpcyBvdmVyDQo+ICAgICBBcmUgeW91IHJl
YWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gICAgIGh0dHA6Ly93d3cuY29uc3VsaW50ZWwu
ZXMNCj4gICAgIFRoZSBJUHY2IENvbXBhbnkNCj4gDQo+ICAgICBUaGlzIGVsZWN0cm9uaWMgbWVz
c2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25m
aWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZA0KPiB0byBiZSBmb3IgdGhlIGV4
Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIg
bm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nLA0KPiBkaXN0cmli
dXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlm
IHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJp
dGVkDQo+IGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3Ug
YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1
cmUsIGNvcHlpbmcsDQo+IGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRo
aXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmls
ZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsDQo+IHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1p
bmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8g
aW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQNCj4gZGVsZXRlIGl0Lg0KPiANCj4g
DQo+IA0KPiANCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqDQo+IElQdjQgaXMgb3Zlcg0KPiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IElu
dGVybmV0ID8NCj4gaHR0cDovL3d3dy5jb25zdWxpbnRlbC5lcw0KPiBUaGUgSVB2NiBDb21wYW55
DQo+IA0KPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGlj
aCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBp
bnRlbmRlZCB0byBiZQ0KPiBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwo
cykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNj
bG9zdXJlLCBjb3B5aW5nLA0KPiBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBv
ZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVk
IGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkDQo+IGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQg
YSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50
IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsDQo+IGRpc3RyaWJ1dGlvbiBv
ciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlh
bGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsDQo+
IHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5
IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlv
biBhbmQNCj4gZGVsZXRlIGl0Lg0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQ
djYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlz
dHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p
cHY2DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tDQo=


From nobody Mon Nov 20 21:31:02 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A62A129C3F; Mon, 20 Nov 2017 21:31:01 -0800 (PST)
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 ThJjxw4ksmqm; Mon, 20 Nov 2017 21:30:59 -0800 (PST)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E451126DC2; Mon, 20 Nov 2017 21:30:59 -0800 (PST)
Received: by mail-ua0-x22a.google.com with SMTP id l25so7459696uag.8; Mon, 20 Nov 2017 21:30:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=55iotgwYDEun5pcC4ZmLAWzIXw4JoluxR5LzvmbP8XM=; b=FFxN0ItcHD3iX+zN9q3a0V3oGE8wWflUub1yy0AJuRQIZo7pbs36fNNzpyt38xB5EV mDcxyDOCPSZxiqhj29PEy5UaYalzlbOPcqE8ybGZ2TvMf29EcMxrSzAZWWhMQekR6jSR ERDL7Fm7PyAvHs7Hj74QHH5tZsiSarx4tLgDCQTfGDQsVJNVqL7wii08DFKn3uD1us08 atCz07Q6eS4nxKYcSz9s44kxiPS+J2qnqWmUlC8y8p/ip6J+m7gQ2asEESQqMkNgAFUp WFO9RZjVEI0iTSFpAsQW/UsySRyUXsOpTSrZAwEnIJV0/QZHR336MprYTKq8m6Ys2+5b +rFQ==
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=55iotgwYDEun5pcC4ZmLAWzIXw4JoluxR5LzvmbP8XM=; b=O85fEVh4k+upb3kvKEqlrmaLYt2g1iysA1GKyzXoAWxLlWN2ueJe1iXNGk9Lig5vFn +pqbCt0RMuut9zGIsPtMRL+tCVuUp61dH++P8hgQdAI1dso/rFAQevsB/7l/aQM8QtQm vyFXWYFc2bkQJl7ETuSQ24u4vNxvcGYruyW/ORx2jtAeYvlqU73s0Xzmr75ehqUt7irq tkWOYrELgXQ0SyjqKo7Q5NgvtQGn0tL5as4HEHL/hx3IFPHfsWQ7Vl+vRDKRvN6NSwik uKXPiVSB3GFijRNzkeE9EV/wgW4DqfIrYT3G7Y5bOiecYZx2j1dOPBFLdhFYXrnQZPS6 13ug==
X-Gm-Message-State: AJaThX7ZNgKtgRGu+fsYm2+t5ZX/5FaXZj4G6POldmL4HExx8wcBsV80 ouYGnrwgV9p4nKIbxPKNaaw1ubA87d3hgTng6rg=
X-Google-Smtp-Source: AGs4zMYCKui49ekjgWR70ahcuMJerdetafaDrElVTxM5BZsweN5lm1aRJQ9IgRLYl4b5+WgLqBg7PD5cWXJJ/SvOX7c=
X-Received: by 10.176.11.5 with SMTP id b5mr14103253uak.118.1511242258082; Mon, 20 Nov 2017 21:30:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.69.68 with HTTP; Mon, 20 Nov 2017 21:30:57 -0800 (PST)
Received: by 10.176.69.68 with HTTP; Mon, 20 Nov 2017 21:30:57 -0800 (PST)
In-Reply-To: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>
From: Mark Smith 
Date: Tue, 21 Nov 2017 16:30:57 +1100
Message-ID: 
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: "Templin, Fred L" 
Cc: 6MAN <6man@ietf.org>, v6ops list , "dhcwg@ietf.org" 
Content-Type: multipart/alternative; boundary="089e08266864f67310055e77814c"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 05:31:01 -0000

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

Hi Fred,

I think this fundamentally violates the principle that the network is
application agnostic or transparent, allowing it to support any new host
residing application without any upgrades to the network. I think the
principle of network application transparency should apply to application
configuration.

We don't have to upgrade routers to carry new application protocols, we
shouldn't have to upgrade routers to support configuring new applications.

"Internet Transparency and Application Configuration"

https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2


Regards,
Mark.




On 21 Nov. 2017 08:41, "Templin, Fred L"  wrote:

> Hello,
>
> IPv6 ND and DHCPv6 have traditionally been thought of as independent
> functions,
> with the requirement that the IPv6 ND RS/RA exchange has to happen first
> so that
> the node can examine the M/O bits to determine whether it can use DHCPv6.
> As
> nearly as I can tell, this two round-trip process (IPv6 RS/RA followed by
> DHCPv6
> Solicit/Reply) is the only argument conceivable against DHCPv6 from a
> functional
> standpoint.
>
> The two round-trip process can add significant delay and waste bandwidth
> especially
> on low-end data links like many aviation wireless links. It can also
> impart unnecessary
> messaging overhead on more robust links during periods of congestion.
>
> This document therefore proposes a unification of IPv6 ND and DHCPv6 where
> the two functions work together as if they were one. This is accommodated
> by
> a new IPv6 ND option in RS/RA messages called the "DHCPv6 option". By
> working
> together as one function, IPv6 ND and DHCPv6 can supply requesting nodes
> with
> all link-specific autoconfiguration information and any managed
> address/prefix
> delegations in a single round trip message exchange.
>
> I would ask these discussion lists to consider what is it that you really
> don't
> like about DHCPv6. Maybe you think it is ugly. Maybe you don't like the way
> the acronym rolls off your tongue when you speak it. Maybe it has an
> onerous
> stigma of being stateful. But, then I would also ask you to consider what a
> replacement would look like. Because, I think any suitable replacement
> would have to essentially duplicate what DHCPv6 already does.
>
> Comments?
>
> Fred
>
>
> -----Original Message-----
> From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of
> internet-drafts@ietf.org
> Sent: Monday, November 20, 2017 1:21 PM
> To: i-d-announce@ietf.org
> Subject: I-D Action: draft-templin-6man-dhcpv6-ndopt-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : The DHCPv6 Option for IPv6 Neighbor Discovery
>         Author          : Fred L. Templin
>         Filename        : draft-templin-6man-dhcpv6-ndopt-00.txt
>         Pages           : 6
>         Date            : 2017-11-20
>
> Abstract:
>    IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for
>    nodes to discover neighbors, routers, prefixes and other services on
>    the link.  It also supports a manner of StateLess Address
>    AutoConfiguration (SLAAC).  The Dynamic Host Configuration Protocol
>    for IPv6 (DHCPv6) specifies a service for the stateful delegation of
>    addresses and prefixes.
>
>    Currently, at least two round-trip message exchanges are necessary in
>    order to perform the IPv6ND router discovery and DHCPv6 address/
>    prefix delegation functions.  This document presents a protocol for
>    combining these two round trips into a single round trip by joining
>    the two services into a single unified service.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-templin-6man-dhcpv6-ndopt/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-templin-6man-dhcpv6-ndopt-00
> https://datatracker.ietf.org/doc/html/draft-templin-6man-dhcpv6-ndopt-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

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


Hi Fred,

I t=
hink this fundamentally violates the principle that the network is applicat=
ion agnostic or transparent, allowing it to support any new host residing a=
pplication without any upgrades to the network. I think the principle of ne=
twork application transparency should apply to application configuration.

We don't have to upgr=
ade routers to carry new application protocols, we shouldn't have to up=
grade routers to support configuring new applications.

"Internet Transparency and Application Configuration"=
;


Regard=
s,
Mark.




On 21 Nov. 2017 08:41, "Templin, =
Fred L" <Fred.L.Templi=
n@boeing.com> wrote:
Hello,



IPv6 ND and DHCPv6 have traditionally been thought of as independent functi=
ons,

with the requirement that the IPv6 ND RS/RA exchange has to happen first so=
 that

the node can examine the M/O bits to determine whether it can use DHCPv6. A=
s

nearly as I can tell, this two round-trip process (IPv6 RS/RA followed by D=
HCPv6

Solicit/Reply) is the only argument conceivable against DHCPv6 from a funct=
ional

standpoint.



The two round-trip process can add significant delay and waste bandwidth es=
pecially

on low-end data links like many aviation wireless links. It can also impart=
 unnecessary

messaging overhead on more robust links during periods of congestion.



This document therefore proposes a unification of IPv6 ND and DHCPv6 where<=
br>
the two functions work together as if they were one. This is accommodated b=
y

a new IPv6 ND option in RS/RA messages called the "DHCPv6 option"=
. By working

together as one function, IPv6 ND and DHCPv6 can supply requesting nodes wi=
th

all link-specific autoconfiguration information and any managed address/pre=
fix

delegations in a single round trip message exchange.



I would ask these discussion lists to consider what is it that you really d=
on't

like about DHCPv6. Maybe you think it is ugly. Maybe you don't like the=
 way

the acronym rolls off your tongue when you speak it. Maybe it has an onerou=
s

stigma of being stateful. But, then I would also ask you to consider what a=


replacement would look like. Because, I think any suitable replacement

would have to essentially duplicate what DHCPv6 already does.



Comments?



Fred





-----Original Message-----

From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org

Sent: Monday, November 20, 2017 1:21 PM

To: i-d-announce@ietf.org

Subject: I-D Action: draft-templin-6man-dhcpv6-ndopt-00.txt





A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.





=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 The DHCPv6 Option for IPv6 Neighbor Discovery

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Fred=
 L. Templin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-tem=
plin-6man-dhcpv6-ndopt-00.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 6

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2017-11-20



Abstract:

=C2=A0 =C2=A0IPv6 Neighbor Discovery (IPv6ND) specifies a control message s=
et for

=C2=A0 =C2=A0nodes to discover neighbors, routers, prefixes and other servi=
ces on

=C2=A0 =C2=A0the link.=C2=A0 It also supports a manner of StateLess Address=


=C2=A0 =C2=A0AutoConfiguration (SLAAC).=C2=A0 The Dynamic Host Configuratio=
n Protocol

=C2=A0 =C2=A0for IPv6 (DHCPv6) specifies a service for the stateful delegat=
ion of

=C2=A0 =C2=A0addresses and prefixes.



=C2=A0 =C2=A0Currently, at least two round-trip message exchanges are neces=
sary in

=C2=A0 =C2=A0order to perform the IPv6ND router discovery and DHCPv6 addres=
s/

=C2=A0 =C2=A0prefix delegation functions.=C2=A0 This document presents a pr=
otocol for

=C2=A0 =C2=A0combining these two round trips into a single round trip by jo=
ining

=C2=A0 =C2=A0the two services into a single unified service.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/d=
oc/draft-templin-6man-dhcpv6-ndopt/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft=
-templin-6man-dhcpv6-ndopt-00

https://datatracker.ietf.org=
/doc/html/draft-templin-6man-dhcpv6-ndopt-00





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

I-D-Announce mailing list

I-D-Announce@ietf.org

https://www.ietf.org/m=
ailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html<=
/a>

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt





_______________________________________________

v6ops mailing list

v6ops@ietf.org

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




--089e08266864f67310055e77814c--


From nobody Mon Nov 20 21:49:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA911242F5 for ; Mon, 20 Nov 2017 21:49:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 cBqPau7NJWqC for ; Mon, 20 Nov 2017 21:49:14 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC85124239 for ; Mon, 20 Nov 2017 21:49:14 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 00B4EB1; Tue, 21 Nov 2017 06:49:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511243352; bh=OLoCAhMjeGzQxXWs3LbdhVSlWSDygXnpdB8smQzWcuE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=kh9LJVYJnmY2jA8Np28QYwMbnl6Vnw/zJ8wu4z8ZuL7+giOyCuJmloKiyqXBlI7mL Xis4pJOc4Q1WUmGoD8al7WBA7bcHFrfX/orbDIQ7OVCWwR6xS2zxfiRPLKdDMYD/Zi BpZ+VfM5FlBG6BhKeKVOvMevxFda0JxDyMFAYmXc=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id F27EBB0; Tue, 21 Nov 2017 06:49:11 +0100 (CET)
Date: Tue, 21 Nov 2017 06:49:11 +0100 (CET)
From: Mikael Abrahamsson 
To: Nick Hilliard 
cc: IETF IPv6 Mailing List 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
In-Reply-To: <5A12FBE4.9030101@foobar.org>
Message-ID: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 05:49:16 -0000

On Mon, 20 Nov 2017, Nick Hilliard wrote:

> It comes down where in your stack you want to put your hacks.  A sentry

Indeed. And I'd rather put this hack in IPv6, as it requires adding code 
to configure and send an additional RA option compared to requiring a 
complete IPv4 stack and DHCPv4 code to send some option there.

In 5-10 years, I might not want an IPv4 stack in a lot of network 
equipment.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Mon Nov 20 22:07:26 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284A412EAEF for ; Mon, 20 Nov 2017 22:07:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 9k8glksEisZE for ; Mon, 20 Nov 2017 22:07:24 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30BB12EAE9 for ; Mon, 20 Nov 2017 22:07:23 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6FE19B1; Tue, 21 Nov 2017 07:07:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511244440; bh=Y4Cy5gBD5vQzDRx/YXq2wvb6GRsgWQDrM3ISWHQ1DiQ=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bWPPzMC+7AIcbsCrcmnkcwd2g7EhjIA3t7fqzEdMwNO70N2pYUGRD+1FMr8Hp4R+b qKZhz6RjNR/oyiRjUrQiXr0yVtjUBrTTTLy4OlC+W6dFRzF3dLLZ57xpse1hKfqpkq OcWULtIRd8yDjZ8Rtr8ZgdifAT5nONbNOXYmHQg8=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 582E0B0; Tue, 21 Nov 2017 07:07:20 +0100 (CET)
Date: Tue, 21 Nov 2017 07:07:20 +0100 (CET)
From: Mikael Abrahamsson 
To: Lee Howard 
cc: "Manfredi, Albert E" ,  Brian E Carpenter , 6man WG 
Subject: Re: IPv6 only host NAT64 requirements?
In-Reply-To: 
Message-ID: 
References:   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>    
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-2062346328-1511244440=:32099"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 06:07:25 -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-2062346328-1511244440=:32099
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT

On Mon, 20 Nov 2017, Lee Howard wrote:

> It’s too late for dual-stack to be the transition plan.

Well, I wouldn't say that. Let's augment instead:

1. IPv4
2. Dual stack
3. IPv6

What we have discovered is that step 3 won't be reached anytime soon 
because too many people are stuck at 1.

So to give people who want to go to 3 for their access, we need them to be 
able to realise 2 by means of v4aaS.

So for me the plan is still "interop between IPv4 and IPv6" but it might 
not be dual stack everywhere, instead it's v4aaS. Because long tail is 
long.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se
---137064504-2062346328-1511244440=:32099--


From nobody Mon Nov 20 22:16:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED9612EB24 for ; Mon, 20 Nov 2017 22:16:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 3hHiBcQLgGwr for ; Mon, 20 Nov 2017 22:16:51 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A6A127333 for ; Mon, 20 Nov 2017 22:16:50 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2A08DB1; Tue, 21 Nov 2017 07:16:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511245009; bh=nQmQYMYYgDCI4UPyl3kYCc3iufAh1inrL3wrJHZUyvk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bDvAxOYUitew95p3IzZyV0KlS7TwgbB4g6FPCgiA8FgLa/K1SZMlsVHHdP1Ia9CO+ hMRVSYdiylV5qe4rs59JbKu6wN/b4fSvcvzAvKMRWgL+fu8x0D1s4Yc8E0nEkd0fdz DdaylCwJP798Mbo1yexUkyXzBIONnxrotICRy2xs=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 12305B0; Tue, 21 Nov 2017 07:16:49 +0100 (CET)
Date: Tue, 21 Nov 2017 07:16:49 +0100 (CET)
From: Mikael Abrahamsson 
To: Ole Troan 
cc: Brian E Carpenter , 6man WG 
Subject: Re: IPv6 only host NAT64 requirements?
In-Reply-To: <200AD734-6AEC-4CE9-A921-B9555821B646@employees.org>
Message-ID: 
References:   <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>     <3a20ce57-2a61-bca3-9e25-6d4c38c12888@gmail.com> <200AD734-6AEC-4CE9-A921-B9555821B646@employees.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 06:16:52 -0000

On Mon, 20 Nov 2017, Ole Troan wrote:

> Brian,
>
>> One thing that we demonstrated very convincingly last week
>> is that there are enough legacy devices and applications in
>> existing user hosts that the co-existence plan is still needed.
>> (And, BTW, we demonstated it for user hosts belonging to
>> relatively sophisticated users.)
>
> Huh?
> Data please.

Oh, come on.

For me:

Mosh didn't work (it's single stack once it's connected)
Steam doesn't work (even on Win10). I have no idea how many games do not 
work (because I can't start them), but I'd bet it's A LOT.
Nothing on my corporate VM works (because Parallels does IPv4 NAT, and 
needs to be explicitly configured to be bridged to some NIC/wifi to even 
get the RS on the outside). My VPN doesn't work even if I bridge. Software 
update on Win7 doesn't work on IPv6 only.

These are just things I myself discovered. Yes, getting the VPNs working 
might be a good step (because they'd now be v4aaS) but saying 
v6-only+NAT64 or something, is a viable option in the near future for 
99.9% of users, that's just being silly.

Yes, Jen probably can do it because her employer uses Chrome as its main 
tool for getting anything done. Personally I have in the neighborhood of a 
hundred applications running on my Mac. If I had a windows 7 machine 
as my only environemnt (because enterprise), things would be even worse.

The mass of installed things on devices that need ipv4 literals to work is 
staggering, especially in the long tail. So without bump-in-the-API or 
CLAT, this just won't work in the next 10 years.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Mon Nov 20 22:26:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509D012EB2B; Mon, 20 Nov 2017 22:26:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 jW5QS-H9p4C8; Mon, 20 Nov 2017 22:26:01 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12AD12EB3B; Mon, 20 Nov 2017 22:25:35 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id D811CB1; Tue, 21 Nov 2017 07:25:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511245533; bh=fkBGjQ941tGk3kC34q5Zsia2PYuYDqFxiJTlwq7su5w=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=p5qDXCLmRyApjqZ4ZVGIkH9hPdYT18EtlLgZbJ44XhOFmjuN0Grqd9K1TCvRkZpOJ x3CNtrpB4hBuKM17wdlbdwAgMgaPrGGpxnaE2jpnu/g5G3SWJcEZHpMOhgU/GXt7lC 2PYyyQF4dTanTK9bLekpwMuhXcWnTxPQZzDVJD7U=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D4261B0; Tue, 21 Nov 2017 07:25:33 +0100 (CET)
Date: Tue, 21 Nov 2017 07:25:33 +0100 (CET)
From: Mikael Abrahamsson 
To: Mark Smith 
cc: "Templin, Fred L" ,  "dhcwg@ietf.org" , v6ops list ,  6MAN <6man@ietf.org>
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
In-Reply-To: 
Message-ID: 
References: <9debb1672e3d4f0d89d672d64e0fe579@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: text/plain; format=flowed; charset=US-ASCII
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 06:26:02 -0000

On Tue, 21 Nov 2017, Mark Smith wrote:

> Hi Fred,
>
> I think this fundamentally violates the principle that the network is
> application agnostic or transparent, allowing it to support any new host
> residing application without any upgrades to the network. I think the
> principle of network application transparency should apply to application
> configuration.
>
> We don't have to upgrade routers to carry new application protocols, we
> shouldn't have to upgrade routers to support configuring new applications.
>
> "Internet Transparency and Application Configuration"
>
> https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2

DHCP is a pain for rapidly changing (perhaps mobile) environments. It's 
fundamentally a polling protocol where the network hands out resources for 
a certain amount of time, and there is little chance to invalidate them. 
It's stateful.

Devices need addresses to communicate. So if environments that are dynamic 
and require fast/short setup times to gain addresses, then we need the 
network to support that.

This is not an "application" as in a program running somewhere. This is a 
deployment scenario where devices need addresses quickly with short 
turnaround times and in a bandwidth constrained environment. Saying we 
can't change the network to support this is just silly.

So you think 6lo was a bad idea and violated the network agonostic 
principle?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Mon Nov 20 22:48:23 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77801275F4 for ; Mon, 20 Nov 2017 22:48:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 NlgawPc4Y8J0 for ; Mon, 20 Nov 2017 22:48:09 -0800 (PST)
Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 75E2B12751F for <6man@ietf.org>; Mon, 20 Nov 2017 22:48:08 -0800 (PST)
Received: by mail-yb0-x232.google.com with SMTP id g184so4052051ybg.3 for <6man@ietf.org>; Mon, 20 Nov 2017 22:48:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SQ+jf+k5U0corcBjvGIXPcHmyQRbZWjIrr+icRwU0Qk=; b=SENsDxiE2zDlm7ZS0gj1E675tL0iXu976bGBQk66RdbBeCmuTNx6gfSWa9IKlIPL1b FtpxboHezUnr0ftCq/NoSTR27+z3FBUJogbsGZN9TdbP6NczXrgK5IhHlNdCw2Gwgww4 BAdJH3TsvdpiGqIBdR9aaxZGQZmsTGjEW6D9xPiqkngjdVKh3t9LyOc7//3VvF0IpH2f d7rm4IEuRG2he93D5ovKVf7SX6JYrp9RVSQCsD/YbO7D55RsbQIgnG7djPXAU4KqQNHS eQioXQ5TZuR4IycIyrnfLH9roRGqDmEQ4b4vQTu8cN5sYn6QCRuxL4fL6N/lU7Lhz2sJ pUTw==
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=SQ+jf+k5U0corcBjvGIXPcHmyQRbZWjIrr+icRwU0Qk=; b=pBTkotWO5wiNcTrRdTkyiMjAU4ZHnx3w2kv7Ny3baE/D2nsjIrLDeGzhAK2BgxsIdC JH7WlxP4P8uAf42Yn9hA6SB2lGlhTeQhDt60O/3cUR7g2lDTeKWEeYZ4745kMf/tgaFu 5mm0vHc2yxdz1AzyP+kvBgn1ZN5qOHLCblnAMl455I+4SPfHShwKVSEOEwYhTSj6Awqw cq0/mNHckqd2m2Ffk3QJUluW8N+tC6012ZZSv5JtcnlWb0HC4R6QD3YqPHpcXRZH5lqY tmnDHkYag/55By8oRNoPTdAxqSmqDAgD3mOSUs+MLSrIaFhFhwQGw/EOnmIK8qpCbI0l B/XA==
X-Gm-Message-State: AJaThX5t8kr8x2CT62ginkZjo/O2rRpnPgDHUnW/nJo13qF1fqrUCbMh Q7gqtsMjwpDdEedkzU3rqZE7l/bfowvVgUaayGHDWQ==
X-Google-Smtp-Source: AGs4zMaW8QvqdgK5DImGhQXoeexE+HjuOwVIie6ut7k44jcd1tCpEmfSpLGzNSrzFMqSd2tGOGrMSYfkRFBQrZEgNHE=
X-Received: by 10.37.203.85 with SMTP id b82mr6452268ybg.57.1511246887209; Mon, 20 Nov 2017 22:48:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.4.194 with HTTP; Mon, 20 Nov 2017 22:47:46 -0800 (PST)
In-Reply-To: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>
From: Lorenzo Colitti 
Date: Tue, 21 Nov 2017 15:47:46 +0900
Message-ID: 
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: "Templin, Fred L" 
Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" , "dhcwg@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c05bdcce243cb055e789515"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 06:48:12 -0000

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

On Tue, Nov 21, 2017 at 6:40 AM, Templin, Fred L 
wrote:

> I would ask these discussion lists to consider what is it that you really
> don't
> like about DHCPv6. Maybe you think it is ugly.


As generally implemented and deployed, I think the main things that are
wrong with DHCPv6 are as follows. Note that these are not necessarily
limits imposed the protocol itself, but they are definitely limits imposed
by the implementations and how people typically deploy them. As such, the
following are not required to be true, but are only true in practice in the
vast majority of deployments.

   - In stateful form:
      - Inability to support multiple sources of information (the client
      picks the first lease it gets).
      - Very difficult to update devices when network changes because it's
      fundamentally based on leases and renews and RECONFIGURE is not (widely)
      implemented.
      - Makes possible stateful address assignment of individual IP
      addresses. It's really not a good idea to rely only on this for IP
      addressing, but there are decades of operational practice around
it in IPv4
      and old habits (and legacy deployed systems) die hard.
      - Typically deployed using relays and centralized assignment, which
      is very unsuited to topology changes.
         - If all you have is a central addressing server, you don't want
         to bother that server with constant topology updates from all over the
         network so it can update the hosts.
         - Also, if the topology changes enough, the server might even be
         unreachable from some hosts.
      - In stateless form:
      - Very hard to update devices when anything changes on the network.
      The minimum in the stateless DHCPv6 RFC is 10 minutes, which is *way* too
      long for certain types of networks like mobile hotspots.

The inability to update hosts with new network information is a crucial
weakness because it forces networks to appear to hosts as if they never
change. But networks change all the time. If you can't update the hosts on
a timely basis about a changes, either you never change the network, or you
have an outage, or you lie to the hosts. So we end up with things like VRRP
and NAT to ensure the host never sees the network change.

NAT, of course, is the ultimate way of never changing anything - you could
deploy IPv4 by assigning every host on every network 192.168.1.2 (gateway
and DNS server 192.16.1.1) and just NATing everything with layer-2 aware
NAT.

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


On T=
ue, Nov 21, 2017 at 6:40 AM, Templin, Fred L <Fred.L.Templin@boei=
ng.com> wrote:
I would ask these discussion lists to consider what is it that you r=
eally don't

like about DHCPv6. Maybe you think it is ugly.

<=
div>As generally implemented and deployed, I think the main things that are=
 wrong with DHCPv6 are as follows. Note that these are not necessarily limi=
ts imposed the protocol itself, but they are definitely limits imposed by t=
he implementations and how people typically deploy them. As such, the follo=
wing are not required to be true, but are only true in practice in the vast=
 majority of deployments.
  • In stateful form:
    • I=
nability to support multiple sources of information (the client picks the f=
irst lease it gets).
    • Very difficult to update devices when network =
changes because it's fundamentally based on leases and renews and RECON=
FIGURE is not (widely) implemented.
    • Makes possible stateful address=
 assignment of individual IP addresses. It's really not a good idea to =
rely only on this for IP addressing, but there are decades of operational p=
ractice around it in IPv4 and old habits (and legacy deployed systems) die =
hard.
    • Typically=C2=A0deployed using relays and centralized assignme=
nt, which is very unsuited to topology changes.
      • If all you have=
 is a central addressing server, you don't want to bother that server w=
ith constant topology updates from all over the network so it can update th=
e hosts.
      • Also, if the topology changes enough, the server might eve=
n be unreachable from some hosts.
  • In stateless form:
    • =

    • Very hard to update devices when anything changes on the network. T=
he minimum in the stateless DHCPv6 RFC is 10 minutes, which is *way* too lo=
ng for certain types of networks like mobile hotspots.
T=
he inability to update hosts with new network information is a crucial weak=
ness because it forces networks to appear to hosts as if they never change.=
 But networks change all the time. If you can't update the hosts on a t=
imely basis about a changes, either you never change the network, or you ha=
ve an outage, or you lie to the hosts. So we end up with things like VRRP a=
nd NAT to ensure the host never sees the network change.

NAT, of course, is the ultimate way of never changing anything - you=
 could deploy IPv4 by assigning every host on every network 192.168.1.2 (ga=
teway and DNS server 192.16.1.1) and just NATing everything with layer-2 aw=
are NAT.


--94eb2c05bdcce243cb055e789515--


From nobody Mon Nov 20 23:06:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78245128AFE for ; Mon, 20 Nov 2017 23:06:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZKMIjVBvnx5 for ; Mon, 20 Nov 2017 23:06:24 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 79BEB12EB87 for ; Mon, 20 Nov 2017 23:05:31 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id i14so12883917lfc.1 for ; Mon, 20 Nov 2017 23:05:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2YmNVAPvh9DjguKE9tV9XIlYaiBY3eYjZl6APerDS3o=; b=HDYeCdFXscoCTzVT/xi4elLIy5RwdkGMw0ouqon1FxuNWJb3k9AMjXs69JfmAlXoB2 /9KJxVF6ztw6vAGmX0vf/66jjWq80TQF4MqTYre8OVT3CcfJpeixhoX/4TSwtI5PMiI3 Us4EgC38UBGKIn8E6piMWxRrdamgpdeXuvwSQZK6t0w2mGsJ2k3+NV3IbauslmLdsIMc tXrxx4s5wdjEUBrnt9eVMRaVU+etWe5ggDuR3QQIQbwx5YbMdG0L1JOp09U+/fO9sJOP mQcK7d/CwRBy1hbB/6imGun7UTHuCKi1U0Ui1cdO73kBdT3ZjM+CwYh6RgyN/62/G3c5 VN4Q==
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=2YmNVAPvh9DjguKE9tV9XIlYaiBY3eYjZl6APerDS3o=; b=rn/lLAQrDZco5RjquHSI1jbSWrkLHpvBiQqA1TPP6ulxU9F9ofObXfSu+4HV8Y+t/s lc1LRee99VAnL/fOpOiWTNdXe20wGH1EpKZgENCNw6fHXimWPuTnrffCDZJyUboPWqxH sRy79l+NWJwCwqiUv2sg9UGfKWhzWYWL7yPOsBtRe0hFgFWd+Q0adQgxIG6V0t54O3Qb TqLCO8+fFLtehh1fLPr4Dfrosdc7q8c9tWGzLXZeGBWeHuFbmRNxu5gVON8JwpYkmw04 aBEEbpZaZT9weJYC6JF7k8O09y0CnSWC/nkc8YtzZokLtHk5y4pg+uhC3DISD5dcE0tc p2nw==
X-Gm-Message-State: AJaThX5QaQTy/vaG/GUQL5uP3WHHkThfG5++9hRQjrzEubUMmN+SITFg ED6kyxeVefVbih7UWlvgGtm+svEw6o3VXMe/fcM=
X-Google-Smtp-Source: AGs4zMZH30o7IPNqkFqAR6oxTwLrDQojrLVYJNFm+LwOF+51ywB13NHvFQPtPrdzcPDQG5D+ai6X6q8UrZ8AsrlGpdI=
X-Received: by 10.46.71.143 with SMTP id u137mr5767049lja.79.1511247929492; Mon, 20 Nov 2017 23:05:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.235.73 with HTTP; Mon, 20 Nov 2017 23:05:08 -0800 (PST)
In-Reply-To: <2b0b213c-2ef5-a1cf-4f6e-92e4e6841baa@gmail.com>
References:  <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>     <2b0b213c-2ef5-a1cf-4f6e-92e4e6841baa@gmail.com>
From: Jen Linkova 
Date: Tue, 21 Nov 2017 18:05:08 +1100
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Brian E Carpenter 
Cc: "Manfredi, Albert E" , 6man WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 07:06:25 -0000

On Tue, Nov 21, 2017 at 10:44 AM, Brian E Carpenter
 wrote:
> Fair enough. But now, and for many years, IPv6-only hosts** will
> be unusual (except on some cellular networks); IPv4-only hosts are
> common, and dual stack hosts are common.
>
> ** In my book, a host that contains even one IPv4-only application
> cannot be considered as an "IPv6-only" host.
>
>> People from the real world is coming to IETF saying 'we are deploying
>> Ipv6-only hosts' [1] [2]
>
> Sure. And I think the tests last week showed two things:
> 1. NAT64/DNS64 is viable for IPv6-only hosts (setting aside DNSSEC).
> 2. IPv6-only hosts are far from universal, even among IETF
> participants.

What I really wanted to know was exactly how universal those hosts are..

Unfortunately only 33 people have responded to the survey I sent ;( 8
of them said that they can not get their work
done on NAT64 while for the rest it was either "everything worked just
fine" or "smth was broken but not critical" (and yes, there was that
network issue which
affected the user experience..;(

It also showed that some applications which used to be IPv4-only are
now working on NAT64 network.
At least when you run the latest version of the app/the latest version of OSes.

I see it that way: I'm running a network and I do not want to run a
dual-stack one. At least I'd like to minimize IPv4-only/dual-stack
surface.
The fact that there will be some old hosts/apps which could not work
on v4-only network just means that I might not be able
to migrate *all* hosts to v6-only overnight/any time soon.
The same way I still keep 2.4Ghz SSIDs (and some devices using it) in
addition to 5Ghz ones (where majority of devices are sitting).
Number of Ipv4-only applications will go down overtime and eventually
it would not have much sense to maintain them
(as it would be cheaper to get rid of them than maintain dual-stack
only for a few old things..).
When that moment comes for a given network depends on many factors indeed.

> And BTW thanks for the effort behind ietf-nat64. I think it
> was a very valuable effort.

You are welcome, I'm glad to hear that people find this experiment useful.
All credits goes to the IETF NOC actually, I was just a messenger ;)
(and someone who enjoyed running Wireshark ;))

-- 
SY, Jen Linkova aka Furry


From nobody Tue Nov 21 00:36:36 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28A8129401 for ; Tue, 21 Nov 2017 00:36:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 Y1ebawly5OJ1 for ; Tue, 21 Nov 2017 00:36:32 -0800 (PST)
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 D046812773A for ; Tue, 21 Nov 2017 00:36:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511253390; x=1511858190; 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=obFYJpPR4lz/0N8+GrJB2Hf6i a0O8GF4vgreSJOrn4E=; b=l916m63heK5g2H31blOmEsY0OTxlCnWAoznSUyoD3 fdja+ullKFl9U7D0oEszNrr5chTurmMXlbmMLkylTg3QdSLknLWZv78bM2X0LpwJ lVRh7oj6P2IMgl3M2W9VCkzpI2u3IxM1oxLAgrDWW9+084TJCPC+BQDgKXtLOD+3 M4=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=L0VF97o/O9AaDYYg4g9LUx4KvL3M0z0939tfobGgHDqQeQ6TRO70WGq0G1HE aWI5P9WSiU4tLU7yybwjDOPhRiVoutFRP8Zi/McJkGos9YpUn++Fd72nL JZbgyWkV9RO1oCi7L2n/5cTsvkAben/iCOsl8jr+hz6AB4kudngIXM=;
X-MDAV-Processed: mail.consulintel.es, Tue, 21 Nov 2017 09:36:29 +0100
X-Spam-Processed: mail.consulintel.es, Tue, 21 Nov 2017 09:36:28 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005633528.msg for ; Tue, 21 Nov 2017 09:36:28 +0100
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:171121:md50005633528::QikN8+2nKgxchbOA:00001kCv
X-Return-Path: prvs=14985c1375=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Tue, 21 Nov 2017 09:36:23 +0100
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 6man WG 
Message-ID: <1AFC5341-820B-4ECB-B565-4C1160A3F691@consulintel.es>
Thread-Topic: IPv6 only host NAT64 requirements?
References:    <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es> <1df96ff3-3d42-19d2-aa63-5404adffcd3b@gmail.com>
In-Reply-To: <1df96ff3-3d42-19d2-aa63-5404adffcd3b@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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 08:36:35 -0000

> It is clear to me that hotel rooms need to provide IPv6 + IPv4-as-a-servi=
ce (for example using a CE or AP with CLAT).
    >=20
    > The hotel network or its access can be IPv6-only and then the ISP pro=
vide the NAT64.
   =20
    What users need is that the WiFi (or, rarely, the RJ45 connector) suppo=
rts
    native IPv4 and native IPv6. If  the SP wants IPv6-only on the hotel's
    access link, then the hotel's CE must use one of the known solutions.
    I don't care if it's CLAT or dslite or homebrew. It must not place unus=
ual
    requirements on the user's device, since by definition in such a scenar=
io
    the user device and its applications are random and only a lowest commo=
n
    denominator can be assumed.

[Jordi] Just to be clear on this: When I say the hotel CE or AP with CLAT, =
I mean the same as you =E2=80=93 users get in the RJ45/WiFi dual stack (as =
per today private IPv4 plus global IPv6). The point is that user device doe=
sn=E2=80=99t require anything =E2=80=9Cnew=E2=80=9D or =E2=80=9Cextra=E2=80=
=9D.
   =20
    > I=E2=80=99m sure someone will argue that this means perpetuating IPv4=
: Is not the case.
   =20
    The religious aspect is not important; the market doesn't care about
    religion. IPv4 will die when it's ready to die, and not before.
   =20
    > The case is being realistic about what an ISP or an hotel or any othe=
r organizations NEEDs to provide to their customers if they want to keep th=
em.
    >=20
    > If the hotels provide IPv6 + IPv4-as-a-service, the customer is happy=
=20
   =20
    And I believe that is the *only* way to make all customers happy
    while deploying IPv6. Also, it can only be motivated if accessing
    Facebook, Google etc. is faster or cheaper using IPv6, providing
    an incentive for change.

[Jordi] The fact that some content providers are still not on IPv6, means t=
hose contents/services will be slightly slower (NAT64, CGN, etc.), and I gu=
ess more and more transit providers will have less incentive to keep the =
=E2=80=9Cquality=E2=80=9D of the IPv4 path at the same level as the IPv6 on=
e if there is less and less usage. May be some transit providers or ISPs wi=
ll start charging some extra for IPv4 because the extra cost of maintaining=
 it for a number of users which is going down =E2=80=A6 I see that already =
happening in the access for xDSL links vs GPON.
   =20
    > and more and more traffic is moving from IPv4 to IPv6 in a natural wa=
y.
    >=20
    > If some app developers don=E2=80=99t see it, or if some content provi=
ders or enterprises where the VPN is being connected, there will be a point=
 where the IPv4 traffic is meaningless and they have the risk that at that =
point the IPv4-as-a-service is not offered anymore, not because the cost of=
 the CLAT, but because the cost of the NAT64.
   =20
    Whatever the reason, ISPs won't do this until it affects a
    negligible number of users, given the cost of help desk
    calls compared to everything else.
   =20
    > The only way we can motivate all them to move to IPv6 is to make sure=
 that when, for example 75% of the Internet traffic is IPv6, we clearly ann=
ounce that IPv4 is historical, has not maintenance, and will be dropped and=
 unsupported and will not be able to be reachable.=20
   =20
    I don't know who you mean by "we". Certainly the IETF has no
    power to make such statements.

[Jordi] sunset4 is IETF. I think we should go that way as soon as possible,=
 because after we have RFCs, it takes at least a couple of years to start f=
looding into the market. So, we disagree here, we can make IPv4 =E2=80=9Cso=
mehow=E2=80=9D historic in order to do the last push from the technical per=
spective. Each vendor and ISP will decide, but for example, if there is an =
RFC, many governments, for public procurement, will consider it, and this i=
s, in turn a pushing factor for vendors and ISPs in that country. From my o=
wn experience being contracted by several governments in order to mandate I=
Pv6 support in laws for public procurement, I can tell you that in a matter=
 of months, many other countries took similar decisions looking for the ear=
lier ones, so it becomes a snowball, and at the end it affects also industr=
y and residential users, it just takes time. I=E2=80=99m sure ISOC, ICANN a=
nd other organizations will be able to support that =E2=80=9Cpublic call=E2=
=80=9D once do our work in sunset4.

    Regards,
       Brian
   =20
    > It is the ISPs work to decide if they want to keep providing NAT64 or=
 not, and to tell their customers. At some point, more and more ISPs will d=
rop that service. Wherever that point is at the 75% of IPv6 traffic or 95% =
or something in the middle is to be decided by each ISP, also maybe dependi=
ng on their competitors, etc.
    >=20
    > I recall a few years ago when a phone company in Spain still had a fe=
w customers with old =E2=80=9Cpulse disk phones=E2=80=9D. They took the dec=
ision to cancel the contract to those customers if they don=E2=80=99t want =
to get the phone replaces with DTMF phones.
    >=20
    > Same today is happening with customers with ADSL where there is GPON =
coverage. You accept to be replaced to GPON, or they cancel the contract, b=
ecause it is more expensive to keep a few =E2=80=9Cold fashioned=E2=80=9D c=
ustomers that the profit they generate.
    >=20
    > Regards,
    > Jordi
    > =20
    >=20
    > -----Mensaje original-----
    > De: ipv6  en nombre de Brian E Carpenter 
    > Organizaci=C3=B3n: University of Auckland
    > Responder a: 
    > Fecha: lunes, 20 de noviembre de 2017, 20:37
    > Para: Ole Troan , Mohamed Boucadair 
    > CC: 6man WG , Mark Andrews 
    > Asunto: Re: IPv6 only host NAT64 requirements?
    >=20
    >     On 21/11/2017 02:36, Ole Troan wrote:
    >     ...>> [Med] These are generic statements, Ole. We are talking abo=
ut the IETF case.
    >     >> * The IETF has no control on the hosts that connect to the IET=
F network,
    >     >> * IETF attendees who are using corporate devices, have no cont=
rol on these hosts
    >     >>
    >     >> So, how forcing devices to use "IPv6+nat64" will help here?
    >     >=20
    >     > Eat own dogfood. Many IETF people are developers or work for co=
mpanies having applications not working.
    >     > As I said there were a minimum of applications that didn't work=
. Corporate VPNs largely did. Jen has the final numbers.
    >    =20
    >     However, as long as even one application, such as one VPN, or one
    >     literal IPv4 address, fails, that represents millions of failure =
cases
    >     if we consider the whole world (e.g. imagine every hotel network =
in
    >     the world running IPv6+NAT64 only). That simply isn't viable. Dua=
l
    >     stack in every hotel room in the world is viable, from the hotel =
guests'
    >     point of view. Operators might not like it, but users wouldn't ca=
re.
    >    =20
    >         Brian
    >    =20
    >     -----------------------------------------------------------------=
---
    >     IETF IPv6 working group mailing list
    >     ipv6@ietf.org
    >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ip=
v6
    >     -----------------------------------------------------------------=
---
    >    =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
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > ipv6@ietf.org
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------
    >=20
   =20
   =20



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

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




From nobody Tue Nov 21 00:39:23 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE95129426 for ; Tue, 21 Nov 2017 00:39:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 3rJ6xHZKg_qP for ; Tue, 21 Nov 2017 00:39:18 -0800 (PST)
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 8471212773A for ; Tue, 21 Nov 2017 00:39:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511253555; x=1511858355; 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=q9oDxx6G08A5Kadg6EAfdAkef YepA8XawVgFC8X1r7o=; b=euQMY145AzLBtpKwEZS4ZfE/6dQXuxLrhunEKcTpf FNEGPne3triud/PDOKe3wmdgBFeHBUtdtIlKv9eauAQyug62ItymKZ/52bUyQ7nx CE/eimmIhGp6HesgbQPacARvb/92IbQ7CGauILd3G9j4vYFs9fSuuwVRoBOUZtWS oc=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=EmpR1ALVJEc938Zk0Rl3h/Ku2U2A/pdEKOIihMGkuUketFI8dTAGoRa++sfr dZ2RnGFww1dBmcc5e3ctZuqs71EaR4e27emC0EWIZa0m9+/3dUXfJASFK BzUfowXvfS/qwAM8rI2VfIT6ISVtZlycnrlubF1EKa0hDgnAA7seDQ=;
X-MDAV-Processed: mail.consulintel.es, Tue, 21 Nov 2017 09:39:15 +0100
X-Spam-Processed: mail.consulintel.es, Tue, 21 Nov 2017 09:39:14 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005633531.msg for ; Tue, 21 Nov 2017 09:39:13 +0100
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:171121:md50005633531::7bGHY6k0xZXnjyGg:00000obJ
X-Return-Path: prvs=14985c1375=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Tue, 21 Nov 2017 09:39:09 +0100
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 6man WG 
Message-ID: 
Thread-Topic: IPv6 only host NAT64 requirements?
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   <5DAEE862-0BD0-4DA6-AE7A-B4B6A2CAE617@consulintel.es>  <81A3232BEF82944C8F23DB1CFE276F0F494BDF1B@BPXM24GP.gisp.nec.co.jp>
In-Reply-To: <81A3232BEF82944C8F23DB1CFE276F0F494BDF1B@BPXM24GP.gisp.nec.co.jp>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 08:39:20 -0000

Hi Masanobu,

Yeah, knew that, but didn=E2=80=99t looked at that web page before, and it =
looks to me very interesting action for IXs ;-)

There is at least a company that I know, already offering this as a commerc=
ial service.

Regards,
Jordi
=20

-----Mensaje original-----
De: Masanobu Kawashima 
Responder a: 
Fecha: martes, 21 de noviembre de 2017, 5:11
Para: "jordi.palet@consulintel.es" , 6man WG 
Asunto: RE: IPv6 only host NAT64 requirements?

   =20
    Hi Jordi,=20
   =20
    > At some point the NAT64 service, instead of being provided by the ISP=
 it will make sense to be provided by third party
    > companies, even if there is some extra delay to reach a remote NAT64,=
 etc., and even if there is an extra cost for that
    > customer that still requires it.=20
   =20
    In Japan, JPIX(Japan Internet Exchange) is providing 464XLAT trial serv=
ice=20
    to ISPs.=20
    https://www.jpix.ad.jp/en/technical_exchange.php=20
   =20
    PLAT(NAT64 service) is providing from JPIX, then ISPs are using CLAT CP=
E.=20
    We might need this kind of service near future.=20
    Just FYI. :-)=20
   =20
    Regards,=20
    Masanobu=20
   =20
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
     NEC Platforms, Ltd.                =20
     Access-Device Division             =20
     KAWASHIMA Masanobu                 =20
     kawashimam@vx.jp.nec.com           =20
     https://www.necplatforms.co.jp/en/ =20
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
   =20
   =20
    > -----Original Message-----
    > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of JORDI PALET MA=
RTINEZ
    > Sent: Tuesday, November 21, 2017 5:13 AM
    > To: 6man WG 
    > Subject: Re: IPv6 only host NAT64 requirements?
    >=20
    > And by the way =E2=80=A6
    >=20
    > At some point the NAT64 service, instead of being provided by the ISP=
 it will make sense to be provided by third party
    > companies, even if there is some extra delay to reach a remote NAT64,=
 etc., and even if there is an extra cost for that
    > customer that still requires it.
    >=20
    > Regards,
    > Jordi
    >=20
    >=20
    > -----Mensaje original-----
    > De: ipv6  en nombre de JORDI PALET MARTINEZ  Responder a:
    > 
    > Fecha: lunes, 20 de noviembre de 2017, 21:11
    > Para: 6man WG 
    > Asunto: Re: IPv6 only host NAT64 requirements?
    >=20
    >     It is clear to me that hotel rooms need to provide IPv6 + IPv4-as=
-a-service (for example using a CE or AP with CLAT).
    >=20
    >     The hotel network or its access can be IPv6-only and then the ISP=
 provide the NAT64.
    >=20
    >     I=E2=80=99m sure someone will argue that this means perpetuating =
IPv4: Is not the case.
    >=20
    >     The case is being realistic about what an ISP or an hotel or any =
other organizations NEEDs to provide to their customers
    > if they want to keep them.
    >=20
    >     If the hotels provide IPv6 + IPv4-as-a-service, the customer is h=
appy and more and more traffic is moving from IPv4
    > to IPv6 in a natural way.
    >=20
    >     If some app developers don=E2=80=99t see it, or if some content p=
roviders or enterprises where the VPN is being connected,
    > there will be a point where the IPv4 traffic is meaningless and they =
have the risk that at that point the IPv4-as-a-service
    > is not offered anymore, not because the cost of the CLAT, but because=
 the cost of the NAT64.
    >=20
    >     The only way we can motivate all them to move to IPv6 is to make =
sure that when, for example 75% of the Internet traffic
    > is IPv6, we clearly announce that IPv4 is historical, has not mainten=
ance, and will be dropped and unsupported and will
    > not be able to be reachable. It is the ISPs work to decide if they wa=
nt to keep providing NAT64 or not, and to tell their
    > customers. At some point, more and more ISPs will drop that service. =
Wherever that point is at the 75% of IPv6 traffic
    > or 95% or something in the middle is to be decided by each ISP, also =
maybe depending on their competitors, etc.
    >=20
    >     I recall a few years ago when a phone company in Spain still had =
a few customers with old =E2=80=9Cpulse disk phones=E2=80=9D. They
    > took the decision to cancel the contract to those customers if they d=
on=E2=80=99t want to get the phone replaces with DTMF phones.
    >=20
    >     Same today is happening with customers with ADSL where there is G=
PON coverage. You accept to be replaced to GPON,
    > or they cancel the contract, because it is more expensive to keep a f=
ew =E2=80=9Cold fashioned=E2=80=9D customers that the profit they
    > generate.
    >=20
    >     Regards,
    >     Jordi
    >=20
    >=20
    >     -----Mensaje original-----
    >     De: ipv6  en nombre de Brian E Carpenter <=
brian.e.carpenter@gmail.com>
    >     Organizaci=C3=B3n: University of Auckland
    >     Responder a: 
    >     Fecha: lunes, 20 de noviembre de 2017, 20:37
    >     Para: Ole Troan , Mohamed Boucadair 
    >     CC: 6man WG , Mark Andrews 
    >     Asunto: Re: IPv6 only host NAT64 requirements?
    >=20
    >         On 21/11/2017 02:36, Ole Troan wrote:
    >         ...>> [Med] These are generic statements, Ole. We are talking=
 about the IETF case.
    >         >> * The IETF has no control on the hosts that connect to the=
 IETF network,
    >         >> * IETF attendees who are using corporate devices, have no =
control on these hosts
    >         >>
    >         >> So, how forcing devices to use "IPv6+nat64" will help here=
?
    >         >
    >         > Eat own dogfood. Many IETF people are developers or work fo=
r companies having applications not working.
    >         > As I said there were a minimum of applications that didn't =
work. Corporate VPNs largely did. Jen has the final
    > numbers.
    >=20
    >         However, as long as even one application, such as one VPN, or=
 one
    >         literal IPv4 address, fails, that represents millions of fail=
ure cases
    >         if we consider the whole world (e.g. imagine every hotel netw=
ork in
    >         the world running IPv6+NAT64 only). That simply isn't viable.=
 Dual
    >         stack in every hotel room in the world is viable, from the ho=
tel guests'
    >         point of view. Operators might not like it, but users wouldn'=
t care.
    >=20
    >             Brian
    >=20
    >         -------------------------------------------------------------=
-------
    >         IETF IPv6 working group mailing list
    >         ipv6@ietf.org
    >         Administrative Requests: https://www.ietf.org/mailman/listinf=
o/ipv6
    >         -------------------------------------------------------------=
-------
    >=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 privile=
ged or confidential. The information is intended
    > to be for the exclusive use of the individual(s) named above and furt=
her non-explicilty authorized disclosure, copying,
    > distribution or use of the contents of this information, even if part=
ially, including attached files, is strictly prohibited
    > and will be considered a criminal offense. If you are not the intende=
d recipient be aware that any disclosure, copying,
    > distribution or use of the contents of this information, even if part=
ially, including attached files, is strictly prohibited,
    > will be considered a criminal offense, so you must reply to the origi=
nal sender to inform about this communication and
    > delete it.
    >=20
    >=20
    >=20
    >     -----------------------------------------------------------------=
---
    >     IETF IPv6 working group mailing list
    >     ipv6@ietf.org
    >     Administrative Requests: https://www.ietf.org/mailman/listinfo/ip=
v6
    >     -----------------------------------------------------------------=
---
    >=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 privile=
ged or confidential. The information is intended
    > to be for the exclusive use of the individual(s) named above and furt=
her non-explicilty authorized disclosure, copying,
    > distribution or use of the contents of this information, even if part=
ially, including attached files, is strictly prohibited
    > and will be considered a criminal offense. If you are not the intende=
d recipient be aware that any disclosure, copying,
    > distribution or use of the contents of this information, even if part=
ially, including attached files, is strictly prohibited,
    > will be considered a criminal offense, so you must reply to the origi=
nal sender to inform about this communication and
    > delete it.
    >=20
    >=20
    >=20
    >=20
    >=20
    >=20
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.consulintel.es
    > The IPv6 Company
    >=20
    > This electronic message contains information which may be privileged =
or confidential. The information is intended to be
    > for the exclusive use of the individual(s) named above and further no=
n-explicilty authorized disclosure, copying,
    > distribution or use of the contents of this information, even if part=
ially, including attached files, is strictly prohibited
    > and will be considered a criminal offense. If you are not the intende=
d recipient be aware that any disclosure, copying,
    > distribution or use of the contents of this information, even if part=
ially, including attached files, is strictly prohibited,
    > will be considered a criminal offense, so you must reply to the origi=
nal sender to inform about this communication and
    > delete it.
    >=20
    >=20
    >=20
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > ipv6@ietf.org
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------
   =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 Nov 21 01:40:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68AFD12944A for ; Tue, 21 Nov 2017 01:40:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] 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 pl1f6S8BCEA7 for ; Tue, 21 Nov 2017 01:40:20 -0800 (PST)
Received: from smtp12.doorway.no (smtp12.doorway.no [212.125.205.195]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AEF3120227 for ; Tue, 21 Nov 2017 01:40:19 -0800 (PST)
Received: from dware1044.doorway.loc (10.0.20.54) by smtp12.doorway.no (10.0.21.42) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 21 Nov 2017 10:40:13 +0100
Received: from olen-ws.dhcp.nlogic.no (84.208.27.142) by dware1044.doorway.loc (10.0.20.54) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 21 Nov 2017 10:40:13 +0100
Subject: Re: IPv6 only host NAT64 requirements?
To: 
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  
From: Ola Thoresen 
Message-ID: <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no>
Date: Tue, 21 Nov 2017 10:40:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: [84.208.27.142]
X-ClientProxiedBy: DWARE1041.doorway.loc (10.0.20.51) To dware1044.doorway.loc (10.0.20.54)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 09:40:22 -0000

On 20. nov. 2017 20:37, Brian E Carpenter wrote:

> On 21/11/2017 02:36, Ole Troan wrote:
> ...>> [Med] These are generic statements, Ole. We are talking about the IETF case.
>>> * The IETF has no control on the hosts that connect to the IETF network,
>>> * IETF attendees who are using corporate devices, have no control on these hosts
>>>
>>> So, how forcing devices to use "IPv6+nat64" will help here?
>> Eat own dogfood. Many IETF people are developers or work for companies having applications not working.
>> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.
> However, as long as even one application, such as one VPN, or one
> literal IPv4 address, fails, that represents millions of failure cases
> if we consider the whole world (e.g. imagine every hotel network in
> the world running IPv6+NAT64 only). That simply isn't viable. Dual
> stack in every hotel room in the world is viable, from the hotel guests'
> point of view. Operators might not like it, but users wouldn't care.

In hotel rooms and other "public" or "guest" networks, there are so many 
things that fail already, due to NAT, misconfigured firewalls, 
unmaintained blocklists, SSL-proxies and whatnot, so you can hardly 
expect any services other than basic web-surfing without https to work.
Not that this is an ideal situation today, but i do not believe that "if 
even one VPN or one liter IPv4 address fails" should be a showstopper 
for introducing this.
Possibly, or even probably, introducing IPv6 (-only and NAT64) will even 
make the situation better for a lot of people, as you get rid of all the 
horrible NAT solutions for services that are already dual stacked.


Rgds.

Ola Thoresen


From nobody Tue Nov 21 02:07:44 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D478129462 for ; Tue, 21 Nov 2017 02:07:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 FSFyabK6gfkJ for ; Tue, 21 Nov 2017 02:07:40 -0800 (PST)
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 5AA58129443 for ; Tue, 21 Nov 2017 02:07:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511258846; x=1511863646; 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=dE+kzhNaaYCPFF0KsTuIhElGC onszD66wZEYh1dPJYk=; b=XHNKfxFwPcDwVeqRVORRqwpklKAycLvFBJsiwgdcY vjxs/n5EPU1K+DAO1K1z/HOguwREaTdNm2GKhF22W/ZB9C0xHRYfVZgSWQ7oo9+q UGM8so28zYrXvsgbe1+fZqtZ47NJaot4sFW/rixCGTDnfr1ed103KCk312AGsuSa QY=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=eijbGwpyNe5if29CxYrwJlIFVzyvoll6HcYdsFl4vNdx7jkKnipwGuw46mFc YOkjzjQVzgNv+HHPXpASOWhM61DtrnwQ0IViv4ndZuyOKuCUt3NtI6daW NxYDp/0EXvAA4yxca5t+Gt5uZ6zgH7D/k/c+wWDmNpAGVF6s6swzvk=;
X-MDAV-Processed: mail.consulintel.es, Tue, 21 Nov 2017 11:07:24 +0100
X-Spam-Processed: mail.consulintel.es, Tue, 21 Nov 2017 11:07:22 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005633641.msg for ; Tue, 21 Nov 2017 11:07:21 +0100
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:171121:md50005633641::zqYh3JNZCoKQigyi:000050VJ
X-Return-Path: prvs=14985c1375=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ipv6@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Tue, 21 Nov 2017 11:07:14 +0100
Subject: Re: IPv6 only host NAT64 requirements?
From: JORDI PALET MARTINEZ 
To: 
Message-ID: <10F26994-3EC2-4998-84EC-09486743D7CE@consulintel.es>
Thread-Topic: IPv6 only host NAT64 requirements?
References:  <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org>   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no>
In-Reply-To: <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Reply-To: jordi.palet@consulintel.es
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 10:07:42 -0000

I will even say that introducing NAT64+CLAT will solve more problems that if there is NAT+CGN or NAT+CGN+NAT64.

As you indicate, the support for IPv6 will resolve 99.99% of the issues for dual-stacked services and I think NAT64 will improve the % of failures vs CGN+NAT, and if the 464XLAT is properly configured, only a few % of remote IPv4-only-DNSSEC services will fail. 

Regards,
Jordi
 

-----Mensaje original-----
De: ipv6  en nombre de Ola Thoresen 
Responder a: 
Fecha: martes, 21 de noviembre de 2017, 10:40
Para: 
Asunto: Re: IPv6 only host NAT64 requirements?

    On 20. nov. 2017 20:37, Brian E Carpenter wrote:
    
    > On 21/11/2017 02:36, Ole Troan wrote:
    > ...>> [Med] These are generic statements, Ole. We are talking about the IETF case.
    >>> * The IETF has no control on the hosts that connect to the IETF network,
    >>> * IETF attendees who are using corporate devices, have no control on these hosts
    >>>
    >>> So, how forcing devices to use "IPv6+nat64" will help here?
    >> Eat own dogfood. Many IETF people are developers or work for companies having applications not working.
    >> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.
    > However, as long as even one application, such as one VPN, or one
    > literal IPv4 address, fails, that represents millions of failure cases
    > if we consider the whole world (e.g. imagine every hotel network in
    > the world running IPv6+NAT64 only). That simply isn't viable. Dual
    > stack in every hotel room in the world is viable, from the hotel guests'
    > point of view. Operators might not like it, but users wouldn't care.
    
    In hotel rooms and other "public" or "guest" networks, there are so many 
    things that fail already, due to NAT, misconfigured firewalls, 
    unmaintained blocklists, SSL-proxies and whatnot, so you can hardly 
    expect any services other than basic web-surfing without https to work.
    Not that this is an ideal situation today, but i do not believe that "if 
    even one VPN or one liter IPv4 address fails" should be a showstopper 
    for introducing this.
    Possibly, or even probably, introducing IPv6 (-only and NAT64) will even 
    make the situation better for a lot of people, as you get rid of all the 
    horrible NAT solutions for services that are already dual stacked.
    
    
    Rgds.
    
    Ola Thoresen
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    



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

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




From nobody Tue Nov 21 03:39:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D36212946F for ; Tue, 21 Nov 2017 03:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nqVaxrAiMSl for ; Tue, 21 Nov 2017 03:39:36 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7937D12946E for ; Tue, 21 Nov 2017 03:39:36 -0800 (PST)
Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 896E22D5104; Tue, 21 Nov 2017 11:39:34 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 98FB2200CE08BA; Tue, 21 Nov 2017 12:39:31 +0100 (CET)
From: Ole Troan 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_B5AD5BD3-D45C-4988-8B5C-3F3C7376A58B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
Date: Tue, 21 Nov 2017 12:39:30 +0100
In-Reply-To: 
Cc: Nick Hilliard , 6man WG 
To: Mikael Abrahamsson 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org> 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 11:39:38 -0000

--Apple-Mail=_B5AD5BD3-D45C-4988-8B5C-3F3C7376A58B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

We might consider disabling IPv4 on a network in the same fashion that =
we did it for AppleTalk, Apollo Domain, Banyan VINES, DECNet, CLNS, XNS, =
IPX...

This isn't a new problem.

Ole

> On 21 Nov 2017, at 06:49, Mikael Abrahamsson  wrote:
>=20
> On Mon, 20 Nov 2017, Nick Hilliard wrote:
>=20
>> It comes down where in your stack you want to put your hacks.  A =
sentry
>=20
> Indeed. And I'd rather put this hack in IPv6, as it requires adding =
code to configure and send an additional RA option compared to requiring =
a complete IPv4 stack and DHCPv4 code to send some option there.
>=20
> In 5-10 years, I might not want an IPv4 stack in a lot of network =
equipment.
>=20
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--Apple-Mail=_B5AD5BD3-D45C-4988-8B5C-3F3C7376A58B
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+/bDNdvtpYqJhC33YFAloUEHIACgkQvtpYqJhC
33ZEYBAApKWEkqBTKBzouUEq9tfLgGfuYywpk8ZzDLulqQS/mx3ZF2Ynt3lr0aXC
7oRl48DFqCM4TmIQUs4r0U9TlV0wB1uUUQtSsYUCsG30fBCRDA7QXYXwjYhzvqRN
WGg/+EcO9OjHSbNDfPaNY6lkFclU4ThkWGZHERuA7+qTVLLjpgez5P3GNWvbnH/1
so4LuG5gUKkdsMCG9aS7h8FbxJTs7LTd7VCV1MHQe74ITolOlCQwoFS/CMSnsWFB
GZSGKMs/VHudZXt/nZUgIBCaXUleElcbo91YQBDTYWK8naIUsVAbrSs1kEM6dkNj
+UlTwmt8mpPxLrkdnr1bmfTIn6YDEvDtzXbehQ4IkhPm3YYB4bv1ut2Gwxe1ocz3
waHQLcKL3AldjEbwTqvaTuWgUXKVjsCt7FwtwaF+X9yj3WBeWFOFqFxXDAbYeM5m
52HdNot2XUsAxcZLbHhYV/j+MXvGE3XnV8ZMnzwA0zUOGmrXhCtGzTSyi43AYr0s
Q+aS9uecsk5N05X4xY4RKx6ORuL4b1FtaRRnjojvC5aGHmtlxMXSJJDAnRalJ6Pq
VZhpW6zSbJZXl6ncx1VnTr1IIi+OukbBe0UQeQ8BRB8A1l/4F1fWzQ36WfnIEyec
h/P8BocZKxUywnBhTIQfKaaAof9udfXAtbhnBEdU1VJzL9+i+z4=
=xcM9
-----END PGP SIGNATURE-----

--Apple-Mail=_B5AD5BD3-D45C-4988-8B5C-3F3C7376A58B--


From nobody Tue Nov 21 04:32:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7421D129480 for ; Tue, 21 Nov 2017 04:32:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 wPEY7tj3mOoJ for ; Tue, 21 Nov 2017 04:32:46 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D87A12947B for ; Tue, 21 Nov 2017 04:32:46 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0C911B1; Tue, 21 Nov 2017 13:32:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511267564; bh=xW5caPp8gErKLjB0EcohUqRHvL01kIdkpQ7GePLhsdA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=R12Q1Zbb33WoZMNguZiezJAXN+jirBq3B3R7xk2xoyHSjYZWaY8EQXsVQkh56NcZW bELEDagAQJh+qM62wwV7qNsqxT3d4IuOaePnGEgyysbzJEzN8t2CG1fEyhht6OXwX8 uxPQ6VCxHPBlrisAMpMd0ZB5bqIlD8BaFKpN8t4M=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0894CB0; Tue, 21 Nov 2017 13:32:44 +0100 (CET)
Date: Tue, 21 Nov 2017 13:32:44 +0100 (CET)
From: Mikael Abrahamsson 
To: Ole Troan 
cc: Nick Hilliard , 6man WG 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
In-Reply-To: 
Message-ID: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 12:32:49 -0000

On Tue, 21 Nov 2017, Ole Troan wrote:

> We might consider disabling IPv4 on a network in the same fashion that we did it for AppleTalk, Apollo Domain, Banyan VINES, DECNet, CLNS, XNS, IPX...
>
> This isn't a new problem.

The new thing is that most devices nowadays are connected using radio and 
not wired, the way they were before. Also, back on those days security 
typically wasn't high on the agenda. How many worried about MITM attacks 
on those protocols?

Also, they were typically used in managed environments. BYOD wasn't really 
a thing back then.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Tue Nov 21 05:43:51 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1543127977 for ; Tue, 21 Nov 2017 05:43:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 jG9O0PePdBoC for ; Tue, 21 Nov 2017 05:43:47 -0800 (PST)
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 65603129488 for ; Tue, 21 Nov 2017 05:43:47 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id C2451566 for ; Tue, 21 Nov 2017 13:43:46 +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 DHj6z_UXExb6 for ; Tue, 21 Nov 2017 07:43:46 -0600 (CST)
Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 64356150 for ; Tue, 21 Nov 2017 07:43:46 -0600 (CST)
Received: by mail-lf0-f71.google.com with SMTP id d10so666995lfj.17 for ; Tue, 21 Nov 2017 05:43:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5VEv40gt8UoUtw2PURYosD3m+L0GlGCkc69xOYsETsI=; b=VViorfsdgPTLYJrqJYos8POxgKIZI/1V97XxUmL4kvw46ZLVEX0nzHmjD3k5JiCVdu ijffT0ZltWOD4Ou6Gk7ADdKg4BYBmT6r6xcSIQHalIYhoGopgfc1TSZh73wpDtKfdHs7 f+oVe7nEzjy1y5ukxIrYERozl+XdwwyKU8fFQO08BrmMIdb4y2eq7Pl/jXrdNUO6jHKL XLVqI+UUUOeTes3m8lplqtyrDvM9O1D9mmSSCazuRjQ4j9Fg+Hul0HD72WnglrMx+wAc RVmoiP1b6UjOv9RdXmQDtpeRboivc3tgBy6RPjnpBsNgjYPj1dDRVrD0h/51i8c+yJrT yrrw==
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=5VEv40gt8UoUtw2PURYosD3m+L0GlGCkc69xOYsETsI=; b=k0QbkGy0bSq1FxaWERcApysN6g5HmdAk5CSz/0zEJDd3auK6s4sTAwwbs8px4Qfvrc DGrSSlNj2uyTtQ6wU3/SBNxe2hJ0RvW5F9vRCsHgg/Wgo+XnmbCsdSgISZC8g2OTHHIb /73qH3zNQ2SS4+XXNmAVGU97HpcbUYXasw2UWIpGtCbPnI6tOvGEQ0dlONR0KoFji0dV Mdhy2wzCETvioV5pj/0Q1QOTN1DUOewj7roeznwwWiJTTpjHXWqEt71q988e0Vpzj2ev WAJBTGFm2gSiQgnE9yBRZJgqCgu28A+rGe4fHXG8r8d41J/lwp1DC7gm11IeDlwlOfGQ xspw==
X-Gm-Message-State: AJaThX6QfID0uMoDQD6bOmFKmuvsxViiK4720IWx/obwlE0OLLcMNoN9 7AwBelUs0DFJShPgSN/4VTlLIDhwQQZGmoq+ovqOBTfBi6stxjmh+/W0nmGDcwDxHP6pLqazpQk YvNYEHZt47PIILhoJoaHUUYHd
X-Received: by 10.46.95.28 with SMTP id t28mr5823047ljb.110.1511271824944; Tue, 21 Nov 2017 05:43:44 -0800 (PST)
X-Google-Smtp-Source: AGs4zMbHpteP6sIkUOQAZUa/6F4VA4M3PMzB3aOxvcEwR9w2iL+c8YEan2Q9e5dZNYjd8S+wnsEz7K1llN32k6bV5Vg=
X-Received: by 10.46.95.28 with SMTP id t28mr5823041ljb.110.1511271824667; Tue, 21 Nov 2017 05:43:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Tue, 21 Nov 2017 05:43:43 -0800 (PST)
In-Reply-To: <0a8f6120-bb8e-a4ae-d011-01d0a19c341a@gmail.com>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com> <19B39788-CEC6-478A-A303-7F42904533DF@huitema.net> <0a8f6120-bb8e-a4ae-d011-01d0a19c341a@gmail.com>
From: David Farmer 
Date: Tue, 21 Nov 2017 07:43:43 -0600
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Brian E Carpenter 
Cc: 6man WG 
Content-Type: multipart/alternative; boundary="94eb2c079fb844cc53055e7e6496"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 13:43:49 -0000

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

On Mon, Nov 20, 2017 at 7:42 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Another response to multiple points:
>
...

> > 1. Security exposure; the inverse of the problems discussed in RFC7123,
> > basically malicious or accidental IPv4 service.
> > 2. Residual IPv4 traffic, especially broadcast traffic; DHCP solicits,
> > IPv4-LL, ARP, service discovery, etc...
>
> The proposal addresses only one thing: attempting to reduce
> futile IPv4 traffic. It neither creates nor blocks IPv4 traffic.
>

That might be, but this thread is about a problem statement, and
conceivably that could add to the draft. Anyway we shouldn't ignore #1, I
think at least something should be said in the security considerations
section on the subject.  Also since this uses RAs, the security
considerations section should probably say something about rogue RAs and
the options to protect against them.


> > In very high dentistry and therefore
> > typically congested WiFi environments...
>
> A new view of dentist's office networking ;-)
>

Serendipitous and amusing autocorrecto :)

....

> > if IPv4 appears you probably want to start
> > using it after a reasonable amount of time.
>
> Indeed. And under the proposal, any RA with flag==0 would be
> an instant trigger to wake up the IPv4 stack. (And no, that
> isn't a serious DOS risk, since it is no worse than what
> we have today.)
>

Should Router Preference [RFC4191] play in this equation?  Should an RA
with a Router Preference = High and this flag = 1 be overridden by
different RA with Router Preference = Low and this flag = 0. I'm not sure I
have an answer, but this probably should be addressed in the draft either
way.

I bring this up as setting Router Preference to High is a common technique
to help protect against at least accidental RAs. Yes malicious RAs can use
a Router Preference of High, but all rogue RAs I've seen in the wild had a
medium (default) Router Preference.

-- 
===============================================
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
===============================================

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




On Mon, Nov 20, 2017 at 7:42 PM, Brian E Carpenter &l=
t;brian.e.=
carpenter@gmail.com> wrote:
Another response to multiple points:
...=C2=A0

> 1. Security exposure; the inverse of the problems discussed in RFC7123=
,

> basically malicious or accidental IPv4 service.

> 2. Residual IPv4 traffic, especially broadcast traffic; DHCP solicits,=


> IPv4-LL, ARP, service discovery, etc...



The proposal addresses only one thing: attempting to reduce

futile IPv4 traffic. It neither creates nor blocks IPv4 traffic.

That might be, but this thread is about a problem=
 statement, and conceivably that could add to the draft. Anyway we shouldn&=
#39;t ignore #1, I think at least something should be said in the security =
considerations section on the subject.=C2=A0 Also since this uses RAs, the =
security considerations section should probably say something about rogue R=
As and the options to protect against them.=C2=A0
=C2=A0

> In very high dentistry and therefore

> typically congested WiFi environments...



A new view of dentist's office networking ;-)

=

Serendipitous and amusing autocorrecto :)

....
> if IPv4=
 appears you probably want to start

> using it after a reasonable amount of time.



Indeed. And under the proposal, any RA with flag=3D=3D0 would be

an instant trigger to wake up the IPv4 stack. (And no, that

isn't a serious DOS risk, since it is no worse than what

we have today.)

=

Should Router Preference [RFC4191] play in this =
equation?=C2=A0 Should an RA with a Router Preference =3D High and this fla=
g =3D 1 be overridden by different RA with Router Preference =3D Low and th=
is flag =3D 0. I'm not sure I have an answer, but this probably should =
be addressed in the draft either way.

<=
/div>
I bring this up as setting Router Preferenc=
e to High is a common technique to help protect against at least accidental=
 RAs. Yes malicious RAs can use a Router Preference of High, but all rogue =
RAs I've seen in the wild had a medium (default) Router Preference.=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:farme=
r@umn.edu
Networking & Telecommunication Services
Office of I=
nformation Technology
University of Minnesota=C2=A0=C2=A0 
2218 Unive=
rsity 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 




--94eb2c079fb844cc53055e7e6496--


From nobody Tue Nov 21 07:47:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9682D1294F3 for ; Tue, 21 Nov 2017 07:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOD28xsDjlNP for ; Tue, 21 Nov 2017 07:47:44 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7225B1294E2 for ; Tue, 21 Nov 2017 07:47:07 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vALEkqdT074799 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Nov 2017 14:46:52 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <5A144A78.6060108@foobar.org>
Date: Tue, 21 Nov 2017 15:47:04 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Mikael Abrahamsson 
CC: IETF IPv6 Mailing List 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 15:47:47 -0000

Mikael Abrahamsson wrote:
> Indeed. And I'd rather put this hack in IPv6, as it requires adding code
> to configure and send an additional RA option compared to requiring a
> complete IPv4 stack and DHCPv4 code to send some option there.

I agree it will simplify things on the operator side, slightly.  The
complication on the client side is substantial though, and it's usually
the client side where we run into deployment problems due to high levels
of heterogeneity and in this case, layering issues, i.e. using ipv6 to
signal to a kernel which needs to message-pass to a dhcpv4 userland
process to stop issuing queries on a specific interface or to otherwise
implement what we mean by this flag.  There would also be a requirement
for the network edge to be able to filter out RAs with this option,
given that the ipv6 / RA model is to be able to deploy multiple routers
and we cannot assume that this flag would be limited to e.g. cellular
networks or resi access networks or whatever.  This added complication
is why I question the wisdom of the RA approach.  Simple, even if it
doesn't solve everything, is usually better.

Nick


From nobody Tue Nov 21 07:52:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2818412955F; Tue, 21 Nov 2017 07:52:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HW-fkMptjflL; Tue, 21 Nov 2017 07:52:18 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E5C129534; Tue, 21 Nov 2017 07:50:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vALFojDV013407; Tue, 21 Nov 2017 08:50:45 -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 vALFobZS013336 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 21 Nov 2017 08:50:38 -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, 21 Nov 2017 07:50:37 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 21 Nov 2017 07:50:37 -0800
From: "Templin, Fred L" 
To: Mark Smith 
CC: 6MAN <6man@ietf.org>, v6ops list , "dhcwg@ietf.org" 
Subject: RE: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgAhww6AAASvdJA=
Date: Tue, 21 Nov 2017 15:50:37 +0000
Message-ID: <73d88abadeb643c68670093eee31d31a@XCH15-06-08.nw.nos.boeing.com>
References: <9debb1672e3d4f0d89d672d64e0fe579@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.137.12.6]
Content-Type: multipart/alternative; boundary="_000_73d88abadeb643c68670093eee31d31aXCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 15:52:26 -0000

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

SGkgTWFyaywNCg0KV2hhdCB3ZSBhcmUgZG9pbmcgaGVyZSBpcyBwcm9wZXJseSBqb2luaW5nIHRo
ZSBJUHY2IE5EIGFuZCBESENQdjYgZnVuY3Rpb25zIGludG8NCmEgc2luZ2xlIHVuaWZpZWQgYXV0
b2NvbmZpZ3VyYXRpb24gc2VydmljZSBmb3IgYWxsIHRpbWUuIFJvdXRlcnMgdGhhdCBkb27igJl0
IHJlY29nbml6ZQ0KdGhlIERIQ1B2NiBvcHRpb24gaW4gUlMgbWVzc2FnZXMgd2lsbCBzaW1wbHkg
aWdub3JlIGl0IGFuZCBwcm9jZXNzIGl0IGFzIGEgcGxhaW4NCnZhbmlsbGEgUkZDNDg2MSBSUy4g
SW4gdGhhdCBjYXNlLCBhbGwgUkZDNDg2MSBmdW5jdGlvbnMgc3RpbGwgYXBwbHksIGluY2x1ZGlu
ZyB0aGUNCnByb2Nlc3Npbmcgb2YgdGhlIOKAmE3igJkgYW5kIOKAmE/igJkgYml0cy4gSXQgaXMg
ZnVsbHkgYmFja3dhcmRzIGNvbXBhdGlibGUgYW5kIGRvZXMNCm5vdCByZXF1aXJlIGFueSBjaGFu
Z2VzIHRvIGV4aXN0aW5nIHJvdXRlcnMuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogTWFyayBT
bWl0aCBbbWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb21dDQpTZW50OiBNb25kYXksIE5vdmVt
YmVyIDIwLCAyMDE3IDk6MzEgUE0NClRvOiBUZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGlu
QGJvZWluZy5jb20+DQpDYzogNk1BTiA8Nm1hbkBpZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3Bz
QGlldGYub3JnPjsgZGhjd2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIENvbWJpbmlu
ZyBJUHY2IE5EIGFuZCBESENQdjYgaW50byBhIHNpbmdsZSwgdW5pZmllZCBmdW5jdGlvbg0KDQpI
aSBGcmVkLA0KDQpJIHRoaW5rIHRoaXMgZnVuZGFtZW50YWxseSB2aW9sYXRlcyB0aGUgcHJpbmNp
cGxlIHRoYXQgdGhlIG5ldHdvcmsgaXMgYXBwbGljYXRpb24gYWdub3N0aWMgb3IgdHJhbnNwYXJl
bnQsIGFsbG93aW5nIGl0IHRvIHN1cHBvcnQgYW55IG5ldyBob3N0IHJlc2lkaW5nIGFwcGxpY2F0
aW9uIHdpdGhvdXQgYW55IHVwZ3JhZGVzIHRvIHRoZSBuZXR3b3JrLiBJIHRoaW5rIHRoZSBwcmlu
Y2lwbGUgb2YgbmV0d29yayBhcHBsaWNhdGlvbiB0cmFuc3BhcmVuY3kgc2hvdWxkIGFwcGx5IHRv
IGFwcGxpY2F0aW9uIGNvbmZpZ3VyYXRpb24uDQoNCldlIGRvbid0IGhhdmUgdG8gdXBncmFkZSBy
b3V0ZXJzIHRvIGNhcnJ5IG5ldyBhcHBsaWNhdGlvbiBwcm90b2NvbHMsIHdlIHNob3VsZG4ndCBo
YXZlIHRvIHVwZ3JhZGUgcm91dGVycyB0byBzdXBwb3J0IGNvbmZpZ3VyaW5nIG5ldyBhcHBsaWNh
dGlvbnMuDQoNCg0KIkludGVybmV0IFRyYW5zcGFyZW5jeSBhbmQgQXBwbGljYXRpb24gQ29uZmln
dXJhdGlvbiINCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zbWl0aC12Nm9wcy1j
ZS1kaGNwdjYtdHJhbnNwYXJlbmN5LTAwI3NlY3Rpb24tMg0KDQoNClJlZ2FyZHMsDQpNYXJrLg0K
DQoNCg0KDQpPbiAyMSBOb3YuIDIwMTcgMDg6NDEsICJUZW1wbGluLCBGcmVkIEwiIDxGcmVkLkwu
VGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3Jv
dGU6DQpIZWxsbywNCg0KSVB2NiBORCBhbmQgREhDUHY2IGhhdmUgdHJhZGl0aW9uYWxseSBiZWVu
IHRob3VnaHQgb2YgYXMgaW5kZXBlbmRlbnQgZnVuY3Rpb25zLA0Kd2l0aCB0aGUgcmVxdWlyZW1l
bnQgdGhhdCB0aGUgSVB2NiBORCBSUy9SQSBleGNoYW5nZSBoYXMgdG8gaGFwcGVuIGZpcnN0IHNv
IHRoYXQNCnRoZSBub2RlIGNhbiBleGFtaW5lIHRoZSBNL08gYml0cyB0byBkZXRlcm1pbmUgd2hl
dGhlciBpdCBjYW4gdXNlIERIQ1B2Ni4gQXMNCm5lYXJseSBhcyBJIGNhbiB0ZWxsLCB0aGlzIHR3
byByb3VuZC10cmlwIHByb2Nlc3MgKElQdjYgUlMvUkEgZm9sbG93ZWQgYnkgREhDUHY2DQpTb2xp
Y2l0L1JlcGx5KSBpcyB0aGUgb25seSBhcmd1bWVudCBjb25jZWl2YWJsZSBhZ2FpbnN0IERIQ1B2
NiBmcm9tIGEgZnVuY3Rpb25hbA0Kc3RhbmRwb2ludC4NCg0KVGhlIHR3byByb3VuZC10cmlwIHBy
b2Nlc3MgY2FuIGFkZCBzaWduaWZpY2FudCBkZWxheSBhbmQgd2FzdGUgYmFuZHdpZHRoIGVzcGVj
aWFsbHkNCm9uIGxvdy1lbmQgZGF0YSBsaW5rcyBsaWtlIG1hbnkgYXZpYXRpb24gd2lyZWxlc3Mg
bGlua3MuIEl0IGNhbiBhbHNvIGltcGFydCB1bm5lY2Vzc2FyeQ0KbWVzc2FnaW5nIG92ZXJoZWFk
IG9uIG1vcmUgcm9idXN0IGxpbmtzIGR1cmluZyBwZXJpb2RzIG9mIGNvbmdlc3Rpb24uDQoNClRo
aXMgZG9jdW1lbnQgdGhlcmVmb3JlIHByb3Bvc2VzIGEgdW5pZmljYXRpb24gb2YgSVB2NiBORCBh
bmQgREhDUHY2IHdoZXJlDQp0aGUgdHdvIGZ1bmN0aW9ucyB3b3JrIHRvZ2V0aGVyIGFzIGlmIHRo
ZXkgd2VyZSBvbmUuIFRoaXMgaXMgYWNjb21tb2RhdGVkIGJ5DQphIG5ldyBJUHY2IE5EIG9wdGlv
biBpbiBSUy9SQSBtZXNzYWdlcyBjYWxsZWQgdGhlICJESENQdjYgb3B0aW9uIi4gQnkgd29ya2lu
Zw0KdG9nZXRoZXIgYXMgb25lIGZ1bmN0aW9uLCBJUHY2IE5EIGFuZCBESENQdjYgY2FuIHN1cHBs
eSByZXF1ZXN0aW5nIG5vZGVzIHdpdGgNCmFsbCBsaW5rLXNwZWNpZmljIGF1dG9jb25maWd1cmF0
aW9uIGluZm9ybWF0aW9uIGFuZCBhbnkgbWFuYWdlZCBhZGRyZXNzL3ByZWZpeA0KZGVsZWdhdGlv
bnMgaW4gYSBzaW5nbGUgcm91bmQgdHJpcCBtZXNzYWdlIGV4Y2hhbmdlLg0KDQpJIHdvdWxkIGFz
ayB0aGVzZSBkaXNjdXNzaW9uIGxpc3RzIHRvIGNvbnNpZGVyIHdoYXQgaXMgaXQgdGhhdCB5b3Ug
cmVhbGx5IGRvbid0DQpsaWtlIGFib3V0IERIQ1B2Ni4gTWF5YmUgeW91IHRoaW5rIGl0IGlzIHVn
bHkuIE1heWJlIHlvdSBkb24ndCBsaWtlIHRoZSB3YXkNCnRoZSBhY3JvbnltIHJvbGxzIG9mZiB5
b3VyIHRvbmd1ZSB3aGVuIHlvdSBzcGVhayBpdC4gTWF5YmUgaXQgaGFzIGFuIG9uZXJvdXMNCnN0
aWdtYSBvZiBiZWluZyBzdGF0ZWZ1bC4gQnV0LCB0aGVuIEkgd291bGQgYWxzbyBhc2sgeW91IHRv
IGNvbnNpZGVyIHdoYXQgYQ0KcmVwbGFjZW1lbnQgd291bGQgbG9vayBsaWtlLiBCZWNhdXNlLCBJ
IHRoaW5rIGFueSBzdWl0YWJsZSByZXBsYWNlbWVudA0Kd291bGQgaGF2ZSB0byBlc3NlbnRpYWxs
eSBkdXBsaWNhdGUgd2hhdCBESENQdjYgYWxyZWFkeSBkb2VzLg0KDQpDb21tZW50cz8NCg0KRnJl
ZA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJLUQtQW5ub3VuY2UgW21h
aWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91bmNlLWJv
dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h
aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDIw
LCAyMDE3IDE6MjEgUE0NClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5v
dW5jZUBpZXRmLm9yZz4NClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LXRlbXBsaW4tNm1hbi1k
aGNwdjYtbmRvcHQtMDAudHh0DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl
IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KDQoNCiAgICAg
ICAgVGl0bGUgICAgICAgICAgIDogVGhlIERIQ1B2NiBPcHRpb24gZm9yIElQdjYgTmVpZ2hib3Ig
RGlzY292ZXJ5DQogICAgICAgIEF1dGhvciAgICAgICAgICA6IEZyZWQgTC4gVGVtcGxpbg0KICAg
ICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC10ZW1wbGluLTZtYW4tZGhjcHY2LW5kb3B0LTAw
LnR4dA0KICAgICAgICBQYWdlcyAgICAgICAgICAgOiA2DQogICAgICAgIERhdGUgICAgICAgICAg
ICA6IDIwMTctMTEtMjANCg0KQWJzdHJhY3Q6DQogICBJUHY2IE5laWdoYm9yIERpc2NvdmVyeSAo
SVB2Nk5EKSBzcGVjaWZpZXMgYSBjb250cm9sIG1lc3NhZ2Ugc2V0IGZvcg0KICAgbm9kZXMgdG8g
ZGlzY292ZXIgbmVpZ2hib3JzLCByb3V0ZXJzLCBwcmVmaXhlcyBhbmQgb3RoZXIgc2VydmljZXMg
b24NCiAgIHRoZSBsaW5rLiAgSXQgYWxzbyBzdXBwb3J0cyBhIG1hbm5lciBvZiBTdGF0ZUxlc3Mg
QWRkcmVzcw0KICAgQXV0b0NvbmZpZ3VyYXRpb24gKFNMQUFDKS4gIFRoZSBEeW5hbWljIEhvc3Qg
Q29uZmlndXJhdGlvbiBQcm90b2NvbA0KICAgZm9yIElQdjYgKERIQ1B2Nikgc3BlY2lmaWVzIGEg
c2VydmljZSBmb3IgdGhlIHN0YXRlZnVsIGRlbGVnYXRpb24gb2YNCiAgIGFkZHJlc3NlcyBhbmQg
cHJlZml4ZXMuDQoNCiAgIEN1cnJlbnRseSwgYXQgbGVhc3QgdHdvIHJvdW5kLXRyaXAgbWVzc2Fn
ZSBleGNoYW5nZXMgYXJlIG5lY2Vzc2FyeSBpbg0KICAgb3JkZXIgdG8gcGVyZm9ybSB0aGUgSVB2
Nk5EIHJvdXRlciBkaXNjb3ZlcnkgYW5kIERIQ1B2NiBhZGRyZXNzLw0KICAgcHJlZml4IGRlbGVn
YXRpb24gZnVuY3Rpb25zLiAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBhIHByb3RvY29sIGZvcg0K
ICAgY29tYmluaW5nIHRoZXNlIHR3byByb3VuZCB0cmlwcyBpbnRvIGEgc2luZ2xlIHJvdW5kIHRy
aXAgYnkgam9pbmluZw0KICAgdGhlIHR3byBzZXJ2aWNlcyBpbnRvIGEgc2luZ2xlIHVuaWZpZWQg
c2VydmljZS4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk
cmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRlbXBsaW4t
Nm1hbi1kaGNwdjYtbmRvcHQvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2
YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10ZW1wbGluLTZt
YW4tZGhjcHY2LW5kb3B0LTAwDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s
L2RyYWZ0LXRlbXBsaW4tNm1hbi1kaGNwdjYtbmRvcHQtMDANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0
IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz
aW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0
IHRvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNCkludGVybmV0LURyYWZ0
cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRm
Lm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VA
aWV0Zi5vcmc8bWFpbHRvOkktRC1Bbm5vdW5jZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJbnRlcm5ldC1EcmFmdCBkaXJlY3Rv
cmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0Kb3IgZnRwOi8vZnRwLmlldGYu
b3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9y
ZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3Y2b3BzDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K
CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0
dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt
c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm
b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN
Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0
dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp
biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1
bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp
ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl
bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i
cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgTWFyayw8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoYXQgd2UgYXJlIGRvaW5nIGhlcmUgaXMgcHJv
cGVybHkgam9pbmluZyB0aGUgSVB2NiBORCBhbmQgREhDUHY2IGZ1bmN0aW9ucyBpbnRvPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPmEgc2luZ2xlIHVuaWZpZWQgYXV0b2NvbmZpZ3VyYXRpb24gc2VydmljZSBm
b3IgYWxsIHRpbWUuIFJvdXRlcnMgdGhhdCBkb27igJl0IHJlY29nbml6ZTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj50aGUgREhDUHY2IG9wdGlvbiBpbiBSUyBtZXNzYWdlcyB3aWxsIHNpbXBseSBpZ25vcmUg
aXQgYW5kIHByb2Nlc3MgaXQgYXMgYSBwbGFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj52YW5pbGxhIFJG
QzQ4NjEgUlMuIEluIHRoYXQgY2FzZSwgYWxsIFJGQzQ4NjEgZnVuY3Rpb25zIHN0aWxsIGFwcGx5
LCBpbmNsdWRpbmcgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnByb2Nlc3Npbmcgb2YgdGhlIOKAmE3i
gJkgYW5kIOKAmE/igJkgYml0cy4gSXQgaXMgZnVsbHkgYmFja3dhcmRzIGNvbXBhdGlibGUgYW5k
IGRvZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+bm90IHJlcXVpcmUgYW55IGNoYW5nZXMgdG8gZXhpc3Rp
bmcgcm91dGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo
YW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw
YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp
biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6enNtaXRoQGdt
YWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDIwLCAyMDE3IDk6
MzEgUE08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4sIEZyZWQgTCAmbHQ7RnJlZC5MLlRlbXBsaW5A
Ym9laW5nLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IDZNQU4gJmx0OzZtYW5AaWV0Zi5vcmcmZ3Q7
OyB2Nm9wcyBsaXN0ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs7IGRoY3dnQGlldGYub3JnPGJyPg0K
PGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIENvbWJpbmluZyBJUHY2IE5EIGFuZCBESENQdjYg
aW50byBhIHNpbmdsZSwgdW5pZmllZCBmdW5jdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBGcmVkLDxvOnA+PC9vOnA+PC9wPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGlzIGZ1bmRhbWVudGFsbHkgdmlv
bGF0ZXMgdGhlIHByaW5jaXBsZSB0aGF0IHRoZSBuZXR3b3JrIGlzIGFwcGxpY2F0aW9uIGFnbm9z
dGljIG9yIHRyYW5zcGFyZW50LCBhbGxvd2luZyBpdCB0byBzdXBwb3J0IGFueSBuZXcgaG9zdCBy
ZXNpZGluZyBhcHBsaWNhdGlvbiB3aXRob3V0IGFueSB1cGdyYWRlcyB0byB0aGUgbmV0d29yay4g
SSB0aGluayB0aGUgcHJpbmNpcGxlIG9mIG5ldHdvcmsgYXBwbGljYXRpb24NCiB0cmFuc3BhcmVu
Y3kgc2hvdWxkIGFwcGx5IHRvIGFwcGxpY2F0aW9uIGNvbmZpZ3VyYXRpb24uPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGRvbid0IGhhdmUg
dG8gdXBncmFkZSByb3V0ZXJzIHRvIGNhcnJ5IG5ldyBhcHBsaWNhdGlvbiBwcm90b2NvbHMsIHdl
IHNob3VsZG4ndCBoYXZlIHRvIHVwZ3JhZGUgcm91dGVycyB0byBzdXBwb3J0IGNvbmZpZ3VyaW5n
IG5ldyBhcHBsaWNhdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUg
c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj4mcXVvdDtJ
bnRlcm5ldCBUcmFuc3BhcmVuY3kgYW5kIEFwcGxpY2F0aW9uIENvbmZpZ3VyYXRpb24mcXVvdDs8
bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg
aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNtaXRoLXY2b3BzLWNlLWRo
Y3B2Ni10cmFuc3BhcmVuY3ktMDAjc2VjdGlvbi0yIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtc21pdGgtdjZvcHMtY2UtZGhjcHY2LXRyYW5zcGFyZW5jeS0wMCNzZWN0aW9uLTI8
L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk1hcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPk9uIDIxIE5vdi4gMjAxNyAwODo0MSwgJnF1b3Q7VGVtcGxpbiwgRnJl
ZCBMJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSI+
RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K
PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg
MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t
cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvLDxicj4NCjxicj4NCklQdjYg
TkQgYW5kIERIQ1B2NiBoYXZlIHRyYWRpdGlvbmFsbHkgYmVlbiB0aG91Z2h0IG9mIGFzIGluZGVw
ZW5kZW50IGZ1bmN0aW9ucyw8YnI+DQp3aXRoIHRoZSByZXF1aXJlbWVudCB0aGF0IHRoZSBJUHY2
IE5EIFJTL1JBIGV4Y2hhbmdlIGhhcyB0byBoYXBwZW4gZmlyc3Qgc28gdGhhdDxicj4NCnRoZSBu
b2RlIGNhbiBleGFtaW5lIHRoZSBNL08gYml0cyB0byBkZXRlcm1pbmUgd2hldGhlciBpdCBjYW4g
dXNlIERIQ1B2Ni4gQXM8YnI+DQpuZWFybHkgYXMgSSBjYW4gdGVsbCwgdGhpcyB0d28gcm91bmQt
dHJpcCBwcm9jZXNzIChJUHY2IFJTL1JBIGZvbGxvd2VkIGJ5IERIQ1B2Njxicj4NClNvbGljaXQv
UmVwbHkpIGlzIHRoZSBvbmx5IGFyZ3VtZW50IGNvbmNlaXZhYmxlIGFnYWluc3QgREhDUHY2IGZy
b20gYSBmdW5jdGlvbmFsPGJyPg0Kc3RhbmRwb2ludC48YnI+DQo8YnI+DQpUaGUgdHdvIHJvdW5k
LXRyaXAgcHJvY2VzcyBjYW4gYWRkIHNpZ25pZmljYW50IGRlbGF5IGFuZCB3YXN0ZSBiYW5kd2lk
dGggZXNwZWNpYWxseTxicj4NCm9uIGxvdy1lbmQgZGF0YSBsaW5rcyBsaWtlIG1hbnkgYXZpYXRp
b24gd2lyZWxlc3MgbGlua3MuIEl0IGNhbiBhbHNvIGltcGFydCB1bm5lY2Vzc2FyeTxicj4NCm1l
c3NhZ2luZyBvdmVyaGVhZCBvbiBtb3JlIHJvYnVzdCBsaW5rcyBkdXJpbmcgcGVyaW9kcyBvZiBj
b25nZXN0aW9uLjxicj4NCjxicj4NClRoaXMgZG9jdW1lbnQgdGhlcmVmb3JlIHByb3Bvc2VzIGEg
dW5pZmljYXRpb24gb2YgSVB2NiBORCBhbmQgREhDUHY2IHdoZXJlPGJyPg0KdGhlIHR3byBmdW5j
dGlvbnMgd29yayB0b2dldGhlciBhcyBpZiB0aGV5IHdlcmUgb25lLiBUaGlzIGlzIGFjY29tbW9k
YXRlZCBieTxicj4NCmEgbmV3IElQdjYgTkQgb3B0aW9uIGluIFJTL1JBIG1lc3NhZ2VzIGNhbGxl
ZCB0aGUgJnF1b3Q7REhDUHY2IG9wdGlvbiZxdW90Oy4gQnkgd29ya2luZzxicj4NCnRvZ2V0aGVy
IGFzIG9uZSBmdW5jdGlvbiwgSVB2NiBORCBhbmQgREhDUHY2IGNhbiBzdXBwbHkgcmVxdWVzdGlu
ZyBub2RlcyB3aXRoPGJyPg0KYWxsIGxpbmstc3BlY2lmaWMgYXV0b2NvbmZpZ3VyYXRpb24gaW5m
b3JtYXRpb24gYW5kIGFueSBtYW5hZ2VkIGFkZHJlc3MvcHJlZml4PGJyPg0KZGVsZWdhdGlvbnMg
aW4gYSBzaW5nbGUgcm91bmQgdHJpcCBtZXNzYWdlIGV4Y2hhbmdlLjxicj4NCjxicj4NCkkgd291
bGQgYXNrIHRoZXNlIGRpc2N1c3Npb24gbGlzdHMgdG8gY29uc2lkZXIgd2hhdCBpcyBpdCB0aGF0
IHlvdSByZWFsbHkgZG9uJ3Q8YnI+DQpsaWtlIGFib3V0IERIQ1B2Ni4gTWF5YmUgeW91IHRoaW5r
IGl0IGlzIHVnbHkuIE1heWJlIHlvdSBkb24ndCBsaWtlIHRoZSB3YXk8YnI+DQp0aGUgYWNyb255
bSByb2xscyBvZmYgeW91ciB0b25ndWUgd2hlbiB5b3Ugc3BlYWsgaXQuIE1heWJlIGl0IGhhcyBh
biBvbmVyb3VzPGJyPg0Kc3RpZ21hIG9mIGJlaW5nIHN0YXRlZnVsLiBCdXQsIHRoZW4gSSB3b3Vs
ZCBhbHNvIGFzayB5b3UgdG8gY29uc2lkZXIgd2hhdCBhPGJyPg0KcmVwbGFjZW1lbnQgd291bGQg
bG9vayBsaWtlLiBCZWNhdXNlLCBJIHRoaW5rIGFueSBzdWl0YWJsZSByZXBsYWNlbWVudDxicj4N
CndvdWxkIGhhdmUgdG8gZXNzZW50aWFsbHkgZHVwbGljYXRlIHdoYXQgREhDUHY2IGFscmVhZHkg
ZG9lcy48YnI+DQo8YnI+DQpDb21tZW50cz88YnI+DQo8YnI+DQpGcmVkPGJyPg0KPGJyPg0KPGJy
Pg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBJLUQtQW5ub3VuY2UgW21h
aWx0bzo8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmciPmktZC1h
bm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mDQo8YSBocmVmPSJtYWls
dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+
PGJyPg0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyMCwgMjAxNyAxOjIxIFBNPGJyPg0KVG86IDxh
IGhyZWY9Im1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmciPmktZC1hbm5vdW5jZUBpZXRmLm9y
ZzwvYT48YnI+DQpTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC10ZW1wbGluLTZtYW4tZGhjcHY2
LW5kb3B0LTAwLnR4dDxicj4NCjxicj4NCjxicj4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2
YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+
DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogVGhlIERIQ1B2NiBPcHRpb24gZm9yIElQ
djYgTmVpZ2hib3IgRGlzY292ZXJ5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1
dGhvciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBGcmVkIEwuIFRlbXBsaW48
YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgOiBkcmFmdC10ZW1wbGluLTZtYW4tZGhjcHY2LW5kb3B0LTAwLnR4dDxicj4N
CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7OiA2PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERh
dGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTctMTEtMjA8
YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7SVB2NiBOZWlnaGJvciBEaXNj
b3ZlcnkgKElQdjZORCkgc3BlY2lmaWVzIGEgY29udHJvbCBtZXNzYWdlIHNldCBmb3I8YnI+DQom
bmJzcDsgJm5ic3A7bm9kZXMgdG8gZGlzY292ZXIgbmVpZ2hib3JzLCByb3V0ZXJzLCBwcmVmaXhl
cyBhbmQgb3RoZXIgc2VydmljZXMgb248YnI+DQombmJzcDsgJm5ic3A7dGhlIGxpbmsuJm5ic3A7
IEl0IGFsc28gc3VwcG9ydHMgYSBtYW5uZXIgb2YgU3RhdGVMZXNzIEFkZHJlc3M8YnI+DQombmJz
cDsgJm5ic3A7QXV0b0NvbmZpZ3VyYXRpb24gKFNMQUFDKS4mbmJzcDsgVGhlIER5bmFtaWMgSG9z
dCBDb25maWd1cmF0aW9uIFByb3RvY29sPGJyPg0KJm5ic3A7ICZuYnNwO2ZvciBJUHY2IChESENQ
djYpIHNwZWNpZmllcyBhIHNlcnZpY2UgZm9yIHRoZSBzdGF0ZWZ1bCBkZWxlZ2F0aW9uIG9mPGJy
Pg0KJm5ic3A7ICZuYnNwO2FkZHJlc3NlcyBhbmQgcHJlZml4ZXMuPGJyPg0KPGJyPg0KJm5ic3A7
ICZuYnNwO0N1cnJlbnRseSwgYXQgbGVhc3QgdHdvIHJvdW5kLXRyaXAgbWVzc2FnZSBleGNoYW5n
ZXMgYXJlIG5lY2Vzc2FyeSBpbjxicj4NCiZuYnNwOyAmbmJzcDtvcmRlciB0byBwZXJmb3JtIHRo
ZSBJUHY2TkQgcm91dGVyIGRpc2NvdmVyeSBhbmQgREhDUHY2IGFkZHJlc3MvPGJyPg0KJm5ic3A7
ICZuYnNwO3ByZWZpeCBkZWxlZ2F0aW9uIGZ1bmN0aW9ucy4mbmJzcDsgVGhpcyBkb2N1bWVudCBw
cmVzZW50cyBhIHByb3RvY29sIGZvcjxicj4NCiZuYnNwOyAmbmJzcDtjb21iaW5pbmcgdGhlc2Ug
dHdvIHJvdW5kIHRyaXBzIGludG8gYSBzaW5nbGUgcm91bmQgdHJpcCBieSBqb2luaW5nPGJyPg0K
Jm5ic3A7ICZuYnNwO3RoZSB0d28gc2VydmljZXMgaW50byBhIHNpbmdsZSB1bmlmaWVkIHNlcnZp
Y2UuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y
IHRoaXMgZHJhZnQgaXM6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtdGVtcGxpbi02bWFuLWRoY3B2Ni1uZG9wdC8iIHRhcmdldD0iX2JsYW5rIj5o
dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLTZtYW4tZGhjcHY2
LW5kb3B0LzwvYT48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBh
dmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LXRlbXBsaW4tNm1hbi1kaGNwdjYtbmRvcHQtMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGVtcGxpbi02bWFuLWRoY3B2Ni1uZG9wdC0wMDwv
YT48YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry
YWZ0LXRlbXBsaW4tNm1hbi1kaGNwdjYtbmRvcHQtMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXRlbXBsaW4tNm1hbi1kaGNwdjYt
bmRvcHQtMDA8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr
ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVu
dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJl
Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRmLm9y
ZzwvYT4uPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh
bm9ueW1vdXMgRlRQIGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5l
dC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy
YWZ0cy88L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQpJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i
bWFpbHRvOkktRC1Bbm5vdW5jZUBpZXRmLm9yZyI+SS1ELUFubm91bmNlQGlldGYub3JnPC9hPjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFu
bm91bmNlSW50ZXJuZXQtRHJhZnQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTxicj4NCkludGVybmV0LURyYWZ0PC9hPiBk
aXJlY3RvcmllczogPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCIgdGFy
Z2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDwvYT48YnI+DQpv
ciA8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dCIgdGFy
Z2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0PC9h
Pjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2
b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcD4N
CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_73d88abadeb643c68670093eee31d31aXCH150608nwnosboeingcom_--


From nobody Tue Nov 21 08:00:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F20812EBA8; Tue, 21 Nov 2017 07:59:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0b0zPSomPZxK; Tue, 21 Nov 2017 07:59:49 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4083A1296B0; Tue, 21 Nov 2017 07:57:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vALFvcvU025442; Tue, 21 Nov 2017 08:57:38 -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 vALFvTCG025189 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 21 Nov 2017 08:57:29 -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, 21 Nov 2017 07:57:29 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 21 Nov 2017 07:57:29 -0800
From: "Templin, Fred L" 
To: Mikael Abrahamsson , Mark Smith 
CC: "dhcwg@ietf.org" , v6ops list , 6MAN <6man@ietf.org>
Subject: RE: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgAhww6AAAHoKYAAAvzUoA==
Date: Tue, 21 Nov 2017 15:57:29 +0000
Message-ID: 
References: <9debb1672e3d4f0d89d672d64e0fe579@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.137.12.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 15:59:52 -0000

Hi Mikael,

> -----Original Message-----
> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]
> Sent: Monday, November 20, 2017 10:26 PM
> To: Mark Smith 
> Cc: Templin, Fred L ; dhcwg@ietf.org; v6ops li=
st ; 6MAN <6man@ietf.org>
> Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified =
function
>=20
> On Tue, 21 Nov 2017, Mark Smith wrote:
>=20
> > Hi Fred,
> >
> > I think this fundamentally violates the principle that the network is
> > application agnostic or transparent, allowing it to support any new hos=
t
> > residing application without any upgrades to the network. I think the
> > principle of network application transparency should apply to applicati=
on
> > configuration.
> >
> > We don't have to upgrade routers to carry new application protocols, we
> > shouldn't have to upgrade routers to support configuring new applicatio=
ns.
> >
> > "Internet Transparency and Application Configuration"
> >
> > https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00=
#section-2
>=20
> DHCP is a pain for rapidly changing (perhaps mobile) environments. It's

I am using DHCPv6 PD for mobile hosts and networks over VPNs and it works
great. If the node moves, it simply sends an IPv6ND unsolicited NA message
to update the router's neighbor cache, and the prefix delegation remains
stable.=20

> fundamentally a polling protocol where the network hands out resources fo=
r
> a certain amount of time, and there is little chance to invalidate them.

DHCPv6 Release is the client's function for invalidating prefix delegations=
.
DHCPv6 Reconfigure is the router's function for invalidating them.

> It's stateful.

Anything that manages a delegated prefix is going to necessarily be statefu=
l.
If a different stateful protocol were developed it would be a functional
equivalent of DHCPv6.=20

> Devices need addresses to communicate. So if environments that are dynami=
c
> and require fast/short setup times to gain addresses, then we need the
> network to support that.
>=20
> This is not an "application" as in a program running somewhere. This is a
> deployment scenario where devices need addresses quickly with short
> turnaround times and in a bandwidth constrained environment. Saying we
> can't change the network to support this is just silly.
>=20
> So you think 6lo was a bad idea and violated the network agonostic
> principle?

I don't know how the above relates to DHCPv6.

Thanks - Fred
fred.l.templin@boeing.com
=20
> --
> Mikael Abrahamsson    email: swmike@swm.pp.se



From nobody Tue Nov 21 08:17:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACF4129535 for ; Tue, 21 Nov 2017 08:17:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 42a4K-_V3QBv for ; Tue, 21 Nov 2017 08:17:26 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC20129515 for ; Tue, 21 Nov 2017 08:17:26 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5676BB1; Tue, 21 Nov 2017 17:17:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511281044; bh=3idwUfQjPUAShQ2vCF9KKVwSRyE9Z/2o1LFAxRNmLiw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=zigbDwviXD+ltxfd7xGkv9vvYjsD3c1mTt8dDdIbOVl0wt3jfbqcGxU4pV/FpSRZI NwuFTVPoU0acHUEUsDdnl2bQ7W6Xo6Y83WcRtJCD6M/nmhP927n/N/4Vel8gMo/HUy w6GVRc4oOCuE4mQST3YfxwTI5MUbOGIFQHoKp2m4=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3EFE5B0; Tue, 21 Nov 2017 17:17:24 +0100 (CET)
Date: Tue, 21 Nov 2017 17:17:24 +0100 (CET)
From: Mikael Abrahamsson 
To: Nick Hilliard 
cc: IETF IPv6 Mailing List 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
In-Reply-To: <5A144A78.6060108@foobar.org>
Message-ID: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 16:17:28 -0000

On Tue, 21 Nov 2017, Nick Hilliard wrote:

> is why I question the wisdom of the RA approach.  Simple, even if it 
> doesn't solve everything, is usually better.

Then I guess we should not do anything on the protocol side, and just have 
a sunset4 document that tells hosts that "if you get IPv6 and there seems 
to be no IPv4 in any timely fashion, stop asking for IPv4 information".

I think this is what Ole is saying he wants.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Tue Nov 21 08:18:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E499129510 for ; Tue, 21 Nov 2017 08:18:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 PSY2Q3NlsbR9 for ; Tue, 21 Nov 2017 08:18:35 -0800 (PST)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002: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 59DDB129515 for ; Tue, 21 Nov 2017 08:18:35 -0800 (PST)
Received: by mail-yb0-x22b.google.com with SMTP id i126so4682928ybi.12 for ; Tue, 21 Nov 2017 08:18:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NKH5CW/MN9iXoEBL+/q2y2L5R0bwjboReQQYixWT1zg=; b=ByyqnaUFIq60NW/mh+JDUBKLUts4NrDUV9sugpPg1Ty5cheJPMwEvRaG/aEo510FVo PrUP/5G7xo+jIAJZFbkN4LPFARCfkvsbidt3IjTcQC09/0FlGEJSAfdDdm7MZoyG+mnr 73SaJBFdFLP66uz2nP69iTFmd/3N+kJm9LcdBcATl/Rs2InED0SnRVPIwf2Ou6N94Zbv 7Kp95eyYdYCj4wp0rpivlMUT/Gxz2XxZT35kHDAwTeInfqiQRIDaAR7H9Q82vZcRuZpC 4RwNrZWUK+7F7ncUY3d27HFr5nqjB9uwnMr/HxYqvyJDAO7oodCRaUkAR5uQIP2aKX8v 12oA==
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=NKH5CW/MN9iXoEBL+/q2y2L5R0bwjboReQQYixWT1zg=; b=OL8EAXXeYoasL5gpLhaXZICCrom81QHf8O7Ps/PbottVELeOAiiW5r4OH4Q5ZS5ocu YMdzNYnu4aQ1DlOICr+1dztn1xsGKvo5QTZPuBIhkgoPHPW+S6STabSPgsPMdG1sWyzJ WazYc1Rc9Qa2tdnQ8XhdmbqyFVGziwzjmpdRdInoOKg2VkWyc6fhbQC9TkoG6Cplrjav /sXxDC/lzr4sKd6iSV1MoQWLS3YI40bUmyuz1b/EGu+IXsrgeFycJCQnd13cbxWDUMG1 9qVs9sjpULOsRUaOGjFKCmmyUwOoiwCF9kv1SzNt7CBmUn11k8z04szxnmbrqgCfOSnC szBw==
X-Gm-Message-State: AJaThX7fUXe0Q3shJ2PiUY0SOCeHw9F9KIuYCl2DfXbdre/AGv7UvDTK bdbYeyudVp6oRmR8+IjDk9PfI1RXZCsXvKcV9a8fwM3v2HM=
X-Google-Smtp-Source: AGs4zMYA0t2d1x9ZfxiCL8v3/tpCBU+hDaNSnR+vqJYf2a8K8Tj1Ab7ApXpbIyGqKXJzEwUHQ6AK8WMzQAQQtaB14A4=
X-Received: by 10.37.39.67 with SMTP id n64mr11499657ybn.119.1511281114165; Tue, 21 Nov 2017 08:18:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.4.194 with HTTP; Tue, 21 Nov 2017 08:18:13 -0800 (PST)
In-Reply-To: <5A144A78.6060108@foobar.org>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.org>
From: Lorenzo Colitti 
Date: Wed, 22 Nov 2017 01:18:13 +0900
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Nick Hilliard 
Cc: Mikael Abrahamsson , IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary="94eb2c13501af7e68a055e808d26"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 16:18:36 -0000

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

On Wed, Nov 22, 2017 at 12:47 AM, Nick Hilliard  wrote:

> > Indeed. And I'd rather put this hack in IPv6, as it requires adding code
> > to configure and send an additional RA option compared to requiring a
> > complete IPv4 stack and DHCPv4 code to send some option there.
>
> I agree it will simplify things on the operator side, slightly.  The
> complication on the client side is substantial though,


As an implementer I don't think it would make much of a difference. Yes,
maybe the DHCPv4 option is slightly simpler, but in practice IPv4 and IPv6
provisioning need to be tightly coordinated anyway for things to work well.


> There would also be a requirement
> for the network edge to be able to filter out RAs with this option,


Why is it not sufficient to configure the routers that emit the RAs?

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


On W=
ed, Nov 22, 2017 at 12:47 AM, Nick Hilliard <nick@foobar.org> wrote:
> Indeed. And I'd rather put this hack in IPv6, as it re=
quires adding code

> to configure and send an additional RA option compared to requiring a<=
br>
> complete IPv4 stack and DHCPv4 code to send some option there.



I agree it will simplify things on the operator side, slightly.=C2=
=A0 The

complication on the client side is substantial though,
As an implementer I don't think it would make much of a dif=
ference. Yes, maybe the DHCPv4 option is slightly simpler, but in practice =
IPv4 and IPv6 provisioning need to be tightly coordinated anyway for things=
 to work well.
=C2=A0
There would also be a requirement

for the network edge to be able to filter out RAs with this option,

Why is it not sufficient to configure the routers =
that emit the RAs?


--94eb2c13501af7e68a055e808d26--


From nobody Tue Nov 21 10:28:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9B129B6D for ; Tue, 21 Nov 2017 10:28:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVX7oCzqxNaX for ; Tue, 21 Nov 2017 10:28:48 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E91B1267BB for ; Tue, 21 Nov 2017 10:28:48 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2C57620008; Tue, 21 Nov 2017 13:30:50 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2178E82C48; Tue, 21 Nov 2017 13:28:47 -0500 (EST)
From: Michael Richardson 
To: IETF IPv6 Mailing List 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
In-Reply-To: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.org> 
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 18:28:50 -0000

--=-=-=
Content-Type: text/plain


Mikael Abrahamsson  wrote:
    nick> is why I question the wisdom of the RA approach.  Simple, even if it
    nick> doesn't solve everything, is usually better.

    > Then I guess we should not do anything on the protocol side, and just have a
    > sunset4 document that tells hosts that "if you get IPv6 and there seems to be
    > no IPv4 in any timely fashion, stop asking for IPv4 information".

    > I think this is what Ole is saying he wants.

And hosts should do this for both v4 and v6 by heuristic anyway, because no
matter what we do, it won't be deployed tomorrow.
So that BCP is worth writing.

I'd also like to see a recommendation not to configure IPv4 LL so quickly,
the way that many systems do today, preferring to use v6LL.  Why? because I
think that v4-ARPs wake up more hosts than v6 NDs, and we also have efficient-ND.

We had a WG a decade ago called Detecting Network Attachment (DNA)... I'm
sure that there are documents we could reference... and I think this (BCP) work
belongs in sunset4.

I wonder if we can get consensus on the above statement?



====

Having SAID all of that, I still believe that an RA option (not flag bit)
that declared on behalf of the router, "I do not speak IPv4" might be worth
standardizing.  Perhaps, we should rather name the option, "I speak only IPv6"
since many of the devices also do not not speak XNS or AppleTalk.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloUcF4ACgkQgItw+93Q
3WVxegf/XekqApbzHdOv2kEbRuE4WSrM8AsvilGX943QfrsZqKm1wwwpcmb1T1iw
yod7S5PkH3AMDwZG5CiqjzOd3VYnI9os7WTbSHpdo4xSYtPQOjbfU0CXbew6jiSb
QXmWaBnQDQ2vKE/V0YDdQEyA8c1KeehdpOGKCavZlbV0GqK9CzV+ZRkXvljMeo+r
E/7PPy+sjh7N3MlRRHD9xS8hFDo4PC2iciOHPXdpmSqUmbF/+j6scoaxFofDzypX
Yx95VHAX7jAmus6bY0MbDS4nZ+AO3sf5/9HKGS+qtJocjC9z2DSh14T/UM5DUSdg
+A86D37Rp6M0CsgAmh5+zvBF5xI7vA==
=qKpn
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Nov 21 12:40:06 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D41129BCD for ; Tue, 21 Nov 2017 12:40:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBtbarDUOnuI for ; Tue, 21 Nov 2017 12:40:03 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D877B1204DA for ; Tue, 21 Nov 2017 12:40:02 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id l188so4310325wma.1 for ; Tue, 21 Nov 2017 12:40:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=b19hNQuxu4iBh/4LWIcRtsE/LUcslqcVvsXR423Pem0=; b=WfSPAI0ufLaHg2Cg7jp12zbt/d/KK0LPY/JsPbQ5n9W4wmifhu8LBh43o/wjiRPkLU aN0c4MPqMD8kOO97p+kEyEc/qIYLPBnZEUjV15muPPGiMQRKMflst2cj/nhbeu5QLOG8 DcxRU97X6VOcxIqNujgsBZm0eHh/Wad/xQAprOQvMjDnRfUlmCGcjgnyHTWgNf56nmJw hFYDMeLd4fVQSXXdg3l1DFsr1mWZ4nI01pk50BXDSD0JvxykO36zcepu4uhMCiiDaTWv Ot50oj3xsnjt6dvbABiDOs+QZP7z1s+V8sh6NLJzAC2bWLa8nOJvasl1NJzilhoTyYz8 Se/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b19hNQuxu4iBh/4LWIcRtsE/LUcslqcVvsXR423Pem0=; b=BEiuF45zQlkthmwjUI6h0F/lHDrJw3p++doKB8MqdzXS8sje8UNXe4BHU+uIf1xXtr oKAC5ILKOr/Foq8FN+/+P3/xDPsM/AZayk2Vl1foTbg2OKHSimkMdPSRmcWgfepu5TpH b3S7BJJUERzr8Ddalj3TSnpk5QP6fGk9RiErqzDMNaki8Bd2TzGj0x7tv6c8zimeA8ZN HOhKE10biHLC6vXnwMsEYrtplLqyyx+RUz/TEtmThv5aB2ZqgcFwYV9N2ImPmfcwItlJ UEsH+K/+q/Z5uS6MGt71JCF9YLjwu30Jbr6c7mcrwAJUuHg5aaZ3bUvHj3UCEp2VcSyk 7l6w==
X-Gm-Message-State: AJaThX766fuBLHrCTCNekbldj7HxMgFmUEZaIb7lPYjWy+m1jJelFIyW WTWROCKJP5v2q6wxtL9h2x+DzQ==
X-Google-Smtp-Source: AGs4zMbvqpYo+6w+m68aHN1ZVN5ZR8NiVRdz7+CrBIuH12wV7rDXdi6gPEul5U0DUREoW2fWd60WfA==
X-Received: by 10.80.182.35 with SMTP id b32mr26821753ede.205.1511296801237; Tue, 21 Nov 2017 12:40:01 -0800 (PST)
Received: from [192.168.1.206] (150.241-136-217.adsl-static.isp.belgacom.be. [217.136.241.150]) by smtp.gmail.com with ESMTPSA id g45sm9690993eda.88.2017.11.21.12.38.49 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 12:40:00 -0800 (PST)
From: Alexandre Petrescu 
X-Google-Original-From: Alexandre Petrescu 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: ipv6@ietf.org
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  
Message-ID: 
Date: Tue, 21 Nov 2017 21:38:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 20:40:05 -0000

Le 21/11/2017 à 12:39, Ole Troan a écrit :
> We might consider disabling IPv4 on a network in the same fashion
> that we did it for AppleTalk, Apollo Domain, Banyan VINES, DECNet,
> CLNS, XNS, IPX...
> 
> This isn't a new problem.

Let me remember.
When I switched a PC AT 286 from IPX to TCP/IP it was because the latter
gave access to remote servers and persons rather than just big disk on a
local LAN.  Sunsite.doc.ic.ac.uk was important because, among other
things, gave access to RFCs, which IPX LAN server wouldnt.

This would translate today into putting the RFCs and I-Ds on IPv6 only.
(datatracker, tools.ietf.org, etc)  Or the email lists, or the other
services.

Alex

> 
> Ole
> 
>> On 21 Nov 2017, at 06:49, Mikael Abrahamsson 
>> wrote:
>> 
>> On Mon, 20 Nov 2017, Nick Hilliard wrote:
>> 
>>> It comes down where in your stack you want to put your hacks.  A
>>> sentry
>> 
>> Indeed. And I'd rather put this hack in IPv6, as it requires adding
>> code to configure and send an additional RA option compared to
>> requiring a complete IPv4 stack and DHCPv4 code to send some option
>> there.
>> 
>> In 5-10 years, I might not want an IPv4 stack in a lot of network
>> equipment.
>> 
>> -- Mikael Abrahamsson    email: swmike@swm.pp.se
>> 
>> --------------------------------------------------------------------
>>
>> 
IETF IPv6 working group mailing list
>> ipv6@ietf.org Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6 
>> --------------------------------------------------------------------
>
>> 
> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 


From nobody Tue Nov 21 13:03:22 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C48B129486 for ; Tue, 21 Nov 2017 13:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMYUSHAKffy6 for ; Tue, 21 Nov 2017 13:03:20 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55F6126BF6 for ; Tue, 21 Nov 2017 13:03:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vALL3JlW005459; Tue, 21 Nov 2017 14:03: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 vALL3I6K005444 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 21 Nov 2017 14:03:18 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 21 Nov 2017 13:03:17 -0800
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Tue, 21 Nov 2017 13:03:17 -0800
From: "Manfredi, Albert E" 
To: Alexandre Petrescu , "ipv6@ietf.org" 
Subject: RE: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
Thread-Topic: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
Thread-Index: AQHTYKfIMdTNtDQDekiJqpZcip0oNqMcOvuAgAAON4CAAOhfgIAANY8AgAAGYoCAAIhmAIAA582AgABh4ACAAJabAP//e+Vg
Date: Tue, 21 Nov 2017 21:03:17 +0000
Message-ID: <7f7b9bc2a02c4ad9ab633aab3413242f@XCH15-06-11.nw.nos.boeing.com>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.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
x-originating-ip: [137.137.12.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 21:03:22 -0000

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandre Petrescu

> When I switched a PC AT 286 from IPX to TCP/IP it was because the
> latter gave access to remote servers and persons rather than just
> big disk on a local LAN.  Sunsite.doc.ic.ac.uk was important because,
> among other things, gave access to RFCs, which IPX LAN server wouldnt.

Enterprise nets were running multiple protocols including IP, and it became=
 easier to just use IP. I would say, analogous to running dual stack today,=
 and then eventually you drop IPv4.

In my case, we had all switched over to WFWG at some point, so we all had t=
he IP stack installed in hosts already. Over time, the only app we were usi=
ng DECnet for became e-mail (VMSmail), so we simply switched over to a diff=
erent e-mail system. That seems like where we might end up with IPv4, but n=
ot there yet.

At home, ISP dialup service was always IP and only IP. That followed after =
the enterprise network at work, though.

> This would translate today into putting the RFCs and I-Ds on IPv6 only.
> (datatracker, tools.ietf.org, etc)  Or the email lists, or the other
> services.

Not really comparable, right? The vast majority of people can't even spell =
IETF, let alone care about reading RFCs. Yes, even the vast majority of peo=
ple on enterprise networks, couldn't care less about reading RFCs. So this =
would just become a nuisance for many people, especially those whose enterp=
rise nets do not support IPv6 yet.

Bert



From nobody Tue Nov 21 14:33:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B723126B6E for ; Tue, 21 Nov 2017 14:33:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6srZGJQAKSCL for ; Tue, 21 Nov 2017 14:33:10 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638921241F5 for ; Tue, 21 Nov 2017 14:33:09 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vALLWqA6025147 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Nov 2017 21:32:53 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <5A14A9A1.5020803@foobar.org>
Date: Tue, 21 Nov 2017 22:33:05 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Lorenzo Colitti 
CC: IETF IPv6 Mailing List 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.org> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 22:33:12 -0000

Lorenzo Colitti wrote:
> On Wed, Nov 22, 2017 at 12:47 AM, Nick Hilliard  wrote:
> > There would also be a requirement
> > for the network edge to be able to filter out RAs with this option,
> 
> Why is it not sufficient to configure the routers that emit the RAs?

because you're assuming congruity between ipv4 and ipv6 connectivity on
a network, which is not codified in any ietf document that I'm aware of.
 If there is a incongruity between management of the two protocols, then
the l2 network must have a mechanism to stop an ipv6 gateway from
attempting shutting down ipv4 services.

Nick


From nobody Tue Nov 21 14:40:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4CA1241F5 for ; Tue, 21 Nov 2017 14:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 fND-xCdvERho for ; Tue, 21 Nov 2017 14:40:43 -0800 (PST)
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 BE76F126B6E for ; Tue, 21 Nov 2017 14:40:42 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id j198so6403511ywg.9 for ; Tue, 21 Nov 2017 14:40:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=754sQw46/khhayYssVhGc1QdmY+XEJawgxU07PuBPgY=; b=cUEIjo1EVMm+0ekYq1uvcI8NwdZl6FD4FjcCXFRuA17dhao7sWvEFcZy4e/z5e1e+P flQG/gpUbcsdHRrT/OCEc2L8/ERaY1TqVecGAswP/aXuzo4VhTfDq/gHus1E308VvgbP hfdoBGlj+TitdRS3MEDvGRfZcooDBJ/On2CVO63p6/NFzkAIPL0ktbiRlJ2+nxep5ljM PHBtg2GXZdLU0+OLFzHM9Xf7DQ/+0VGxwqSbeZMYIgpwMHJtn4aSuCsZYXZ/Y+za1pM3 uBjOqEjj8hkwSJOCwrRcaL1J6vY87JF1e/wMeoarH9LcCn8o38GYxQjwsX9W80qeiyCQ 1tGA==
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=754sQw46/khhayYssVhGc1QdmY+XEJawgxU07PuBPgY=; b=rRB6BIX6zOX24946SQC3RYIwHr0peDJuKwE81tx0sruBviIGBh3bMeBQtppgKyWK4I 3l5kzZ16vQXLvHlHqr/woyHxY9rUiL9EBljbJgU52dGI3CL9vFSgVC4qwVG2xjZ6TmoM d4GKZHHDmxiSW51YLI1tSIE0hgBRpVSnX4mywO3eoW7Q+uB/DcKLW3ohvLHoQeLWYTlp UMorP0gPm5/VByAXcCHXs4mphNJA/tjljqAY7zgSZf//sEdYx1T6lAGJOVunDsDvcFhC v9WywRneM+bX/KAyq3Q1KLbY68vW7R5mumnQUf/eldUAdSusrjZGq7I/xlMgj6M4IFIm fngQ==
X-Gm-Message-State: AJaThX4lEEDteMvEouYG2K7nDb0q3hhqUtZtGV8nUX0/qYcOusWzLjDm omcttlGBuvxUu6oqfnZ4kAwmla55nNSjl/HGHkf9tkzxLy0=
X-Google-Smtp-Source: AGs4zMahZ6zHHr5h+Q5MJhiq23RSs0ZvHlHDH+lL3u7ksGuWYsdPBIbZA/JIK6mdhRjnZ8F/jZ3RkWvVqV6zttG7cTA=
X-Received: by 10.129.154.143 with SMTP id r137mr12060065ywg.251.1511304041689;  Tue, 21 Nov 2017 14:40:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.187.17 with HTTP; Tue, 21 Nov 2017 14:40:20 -0800 (PST)
In-Reply-To: <6863.1511288927@obiwan.sandelman.ca>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.org>  <6863.1511288927@obiwan.sandelman.ca>
From: Erik Kline 
Date: Tue, 21 Nov 2017 22:40:20 +0000
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Michael Richardson 
Cc: IETF IPv6 Mailing List 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c0b8dbe960e0f055e85e441"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 22:40:45 -0000

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

> Having SAID all of that, I still believe that an RA option (not flag bit)
> that declared on behalf of the router, "I do not speak IPv4" might be worth
> standardizing.  Perhaps, we should rather name the option, "I speak only IPv6"
> since many of the devices also do not not speak XNS or AppleTalk.

I agree it should denote "I'm IPv6-only".  But I don't think we need
to take a full 8 bytes (minimum ND option size) to say this.

--94eb2c0b8dbe960e0f055e85e441
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
BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgLFwxjJkRp7JZ5x5o5HRoeRIG5M8vd/P0
fvaqLWYctN4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTIx
MjI0MDQyWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI
AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB
MA0GCSqGSIb3DQEBAQUABIIBAFeHtKRvVD07ZSJjPhRVbaTC56fFJr2BA51LfQnoyrAlaFtfJNcg
ltiKolgvG5q/3/X3iw2vlVP81LnKTMhQ+0jT3NjqVNcFFgpsp8SPEG76LnbgY8G8Tbxw8I1oGT7d
vCiyODrSQ+7HPiwORLkzD8hufT4+tEHKuEuWbFc9wa3hnQbC2g5TIPD4W5VGP6qRNznjvQPrWBTp
udJUonrsTXBg6W/N/A46qONGWMWp3hQYWX8kTZ9DsdS0VvKSF6Kyj4lV/uNX0O4oEn4+lcWNUoGu
yUWxzpL3Kk9AiPhsp44nvnqycsLtfrMdskL4ElyHnbLkIesgYDCuXZrmCgZnYzM=
--94eb2c0b8dbe960e0f055e85e441--


From nobody Tue Nov 21 16:01:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511BB129BF5 for ; Tue, 21 Nov 2017 16:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPLLcQFiKKU4 for ; Tue, 21 Nov 2017 16:01:45 -0800 (PST)
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 EFD27129BF3 for ; Tue, 21 Nov 2017 16:01:44 -0800 (PST)
Received: by mail-pg0-x235.google.com with SMTP id z184so11488044pgd.13 for ; Tue, 21 Nov 2017 16:01:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=WGLVQDX8rVCEpzYV6R7ftZJkrD9jLjWlwKR1VW1xuQ4=; b=AdnrdjU4zNDMLUEqhahJWJFeX/6tXoZ0TOnqhihacpqVJDqhZ9UnWalrA2WazplGqC c0jmk5Rk4+rGj1OHAF809RTpN2I5DiWM7TYHKG5aNFjTq9pp3bu4BFH2RO2S/fV+aHwe SgpI78hEyEV6M+se+Du1l3ejVUsfzI9F5xx2lOsW1NsaxBOlidAWoOB7kQc63ZUodjm9 TzqPyIyVq9cNQn8cpmGl/swC3Kd+94MxQeefd5V6ZoqnqyBGNR9UExatvLZFORtkxOOH aeHRl6XnPrO7WnRrTtpVXDgcRwAOt8qQIGlFV0/goAoCR4juPRqCmBUuMt49CJDHassP 8qkA==
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=WGLVQDX8rVCEpzYV6R7ftZJkrD9jLjWlwKR1VW1xuQ4=; b=KKs0jH2ST67Hvyrr2sBk/JE/wNgeVlf5vUFiY2GYMWXrx1zDC861epkCp/IvJhQuvK aS3Ep9vVQ2pkNDBvLHZbsNbejgII8YqTCSbqZCEZc9/sM6pN+/vZndQ0bujnR6lCaMFB MZCbWJvoecE7/x2X2VHapD/s4mpgixaiFYqIHfCvRD7q6Vr/xfmapUO47mZTUA62kgca DuPlD4xBqbDOfpyTtQE3Jpjk/O9gagYqZfQeMYMFT20N6gUgKCZSRkLE2gH9I4IJjtzZ +jGISw4jTwRuP5eorOX/W2dgTBJhRGEgk7D+MqSVMQp/i2UIBbMY3QjdMiCE9w0G8Ii/ joGg==
X-Gm-Message-State: AJaThX7J5+7S0+RO6hfrVFjUdYUqduA9VpQT+O7Rd85fZUU7Mu7QhpmH 6GCx48cfJ9BQKl6ZZwekeWPziz5+
X-Google-Smtp-Source: AGs4zMYDyiwamSDE9LFZBDbi2cWbXUFYqvwYr/nvgCxZdgn+qXAFiLdq7WCJE/9ffQKtVl83/1wtbQ==
X-Received: by 10.99.163.25 with SMTP id s25mr18911865pge.310.1511308904032; Tue, 21 Nov 2017 16:01:44 -0800 (PST)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a78sm26659314pfl.155.2017.11.21.16.01.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 16:01:42 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Ola Thoresen , ipv6@ietf.org
References:    <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <0a13ea07-6b60-9ae6-659e-c054acdc156d@gmail.com>
Date: Wed, 22 Nov 2017 13:01:44 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 00:01:46 -0000

in line...

On 21/11/2017 22:40, Ola Thoresen wrote:
> On 20. nov. 2017 20:37, Brian E Carpenter wrote:
> 
>> On 21/11/2017 02:36, Ole Troan wrote:
>> ...>> [Med] These are generic statements, Ole. We are talking about the IETF case.
>>>> * The IETF has no control on the hosts that connect to the IETF network,
>>>> * IETF attendees who are using corporate devices, have no control on these hosts
>>>>
>>>> So, how forcing devices to use "IPv6+nat64" will help here?
>>> Eat own dogfood. Many IETF people are developers or work for companies having applications not working.
>>> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.
>> However, as long as even one application, such as one VPN, or one
>> literal IPv4 address, fails, that represents millions of failure cases
>> if we consider the whole world (e.g. imagine every hotel network in
>> the world running IPv6+NAT64 only). That simply isn't viable. Dual
>> stack in every hotel room in the world is viable, from the hotel guests'
>> point of view. Operators might not like it, but users wouldn't care.
> 
> In hotel rooms and other "public" or "guest" networks, there are so many 
> things that fail already, due to NAT, misconfigured firewalls, 
> unmaintained blocklists, SSL-proxies and whatnot, so you can hardly 
> expect any services other than basic web-surfing without https to work.
> Not that this is an ideal situation today, but i do not believe that "if 
> even one VPN or one liter IPv4 address fails" should be a showstopper 
> for introducing this.

Hotels won't make that choice, but the providers of hotel networks will,
entirely based on their perception of the number of help desk calls
they will have to handle for any given change. Since they haven't even
made the move from IPv4 to dual stack, I think we'll wait a long time
before they attempt any form of IPv6-only. Sad but true.

> Possibly, or even probably, introducing IPv6 (-only and NAT64) will even 
> make the situation better for a lot of people, as you get rid of all the 
> horrible NAT solutions for services that are already dual stacked.

But those horrible NAT solutions are up and running today. For this
class of operator, any change is bad news, unfortunately. What is their
incentive to make such a change?

    Brian


From nobody Tue Nov 21 16:15:04 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5D3129493 for ; Tue, 21 Nov 2017 16:15:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNCpNa5TzDYg for ; Tue, 21 Nov 2017 16:15:02 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C4C1200E5 for ; Tue, 21 Nov 2017 16:15:02 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id r14so4557534pfl.11 for ; Tue, 21 Nov 2017 16:15:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IKAg00o34IFE1afLccRtTwbBsrYtSEuMDsuHjA5w7u8=; b=dPXjHDtbF3XYeXO3yAw+GnUWSUVqS3/e1PAcFrlVkfGTMDMuigP6/CEsJKR0HVV63x AjXZ3wAXDTatdqRGmS6Pi0My0pH0yMRAJNy0odTPs8Tw0iPjwBvklexnEqasMY94YSb/ 6ILJauR4dEFDjAQU7n67028ZA1v7HcKyv4e1EDkLUlYcruqXRY4QLwK9+WHa8iP31icg 30fxKQNufOyFLcVaGdUKH5YGzzXMi5He1Mgju4JlIJogo3U1uvNuzwYj41oT1+EvI+7e cieCeZmSfi1VrcoRbE0GSAUfOc6VzicQe0dZn6AcDa3Dd6Q1SI30U7Ok2pA1QEGesN0Z 4Z6A==
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=IKAg00o34IFE1afLccRtTwbBsrYtSEuMDsuHjA5w7u8=; b=MnwFy8tYWMjyC/yI+DivW8aeG0wg/Qpsh8+Owd33eB6K8xUBaqL6U7/5mUAn1Nu5YZ cKj29wxln/9WqG1q80oIHAjpqXYt0UAyG8529QQ2tQWdeyBj+TwsvWu4LQt7Zd5sWE/O XguJBTiCw1coK3tnROYD3tNYAWcbVRWRo++na2a52BcY+pHhVFRtI+pL1gtgrc7oZ/gj WEuFpUkibjG0tXZMlXqMdfQ/4NGOgLF9Zo7AHz+WtWi1w2gbv4kGhNdw/ExLEKZU0Cwg xhffviWlB+p2R8UyGjQr7ksTcjqOzfyKWTNdsSUENX7L8edfvy4mOZelSAmYg/B3UvQ9 zW5A==
X-Gm-Message-State: AJaThX6VMePTv1mtwU/qdjFH/cPVVI/FqbIoBHpRqbM+A1YIB9U/Ekn4 MOyLEr19OMD/gi4y5u/bXSwA+6kZ
X-Google-Smtp-Source: AGs4zMa8rvQ1bWthjSCTFXXjc1U5Q7q8DxpXLohpF/asseifg3J46SNVcqnjHwpOhe5wa72iaYftIw==
X-Received: by 10.84.131.12 with SMTP id 12mr19177926pld.418.1511309701226; Tue, 21 Nov 2017 16:15:01 -0800 (PST)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id r90sm17902178pfj.148.2017.11.21.16.14.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 16:15:00 -0800 (PST)
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Nick Hilliard , Lorenzo Colitti 
Cc: IETF IPv6 Mailing List 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.org>  <5A14A9A1.5020803@foobar.org>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Wed, 22 Nov 2017 13:15:02 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <5A14A9A1.5020803@foobar.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 00:15:04 -0000

On 22/11/2017 11:33, Nick Hilliard wrote:
> Lorenzo Colitti wrote:
>> On Wed, Nov 22, 2017 at 12:47 AM, Nick Hilliard  wrote:
>>> There would also be a requirement
>>> for the network edge to be able to filter out RAs with this option,
>>
>> Why is it not sufficient to configure the routers that emit the RAs?
> 
> because you're assuming congruity between ipv4 and ipv6 connectivity on
> a network, which is not codified in any ietf document that I'm aware of.
>  If there is a incongruity between management of the two protocols, then
> the l2 network must have a mechanism to stop an ipv6 gateway from
> attempting shutting down ipv4 services.

This is a very interesting point. If every IPv6 router on a link believes
there is no IPv4 router/DHCP service, they would all send flag==1 in the
proposed solution. So the proposal only works if at least one IPv6 router
is colocated with an IPv4 router, and therefore knows to send flag==0.
Oops.

   Brian


From nobody Tue Nov 21 16:23:46 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29492129493 for ; Tue, 21 Nov 2017 16:23:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9gRoBSR3LSC for ; Tue, 21 Nov 2017 16:23:43 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E3801200E5 for ; Tue, 21 Nov 2017 16:23:42 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id vALNNRHJ038724 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Nov 2017 23:23:27 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Message-ID: <5A14C38B.1070809@foobar.org>
Date: Wed, 22 Nov 2017 00:23:39 +0000
From: Nick Hilliard 
User-Agent: Postbox 5.0.20 (Macintosh/20171012)
MIME-Version: 1.0
To: Brian E Carpenter 
CC: IETF IPv6 Mailing List 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.org>  <5A14A9A1.5020803@foobar.org> 
In-Reply-To: 
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 00:23:45 -0000

Brian E Carpenter wrote:
> This is a very interesting point. If every IPv6 router on a link believes
> there is no IPv4 router/DHCP service, they would all send flag==1 in the
> proposed solution. So the proposal only works if at least one IPv6 router
> is colocated with an IPv4 router, and therefore knows to send flag==0.
> Oops.

This would lead to a race condition on the client + a requirement for
suitable semantics to be defined in the spec to work out what to do if
mixed signals were received from different ipv6 routers.  This assumes
that you can send out an RA with flag==0 in order to mean that ipv4
should be re-enabled again.

Nick


From nobody Tue Nov 21 16:35:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FFF129BFF for ; Tue, 21 Nov 2017 16:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewuk95S3n_w2 for ; Tue, 21 Nov 2017 16:35:43 -0800 (PST)
Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 46447126DEE for ; Tue, 21 Nov 2017 16:35:43 -0800 (PST)
Received: by mail-ot0-x22e.google.com with SMTP id t79so12179076ota.3 for ; Tue, 21 Nov 2017 16:35:43 -0800 (PST)
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=LfYjvhkK6a2z4gh78VE0hw5kPpNUovZqF0fFcQY3cGs=; b=BDTZdPGxTq2JOMHaxzf/zFBFzQB4RtaFUM22081WoAxrqPUCEPHCcqRX60wiUDFpIG Vt2ZO5QTdXufD4+EO0CqCTtCRahBJCuhtLXn/V1skB5W00CEwLKttU3bKjjCyaTskFsE AfYVeX3QqBMYDKIEcVq5TU3zJEuVR15p9rYMTnE1t9DkD0OnD/JiD4D2Tyf3+TrvDRk/ DQZ7uBJ9MtRQ9n6K0mMqomyfcjGuZgu4zLUH46cO8t9BCkyXndz5Kdt6lf9a2VrZcD8t UwlOZJulU81V3CoCu/SMENhXPeqVjco4dVmCN6cmOuSJlbCFeFJDjavTJSDiOYs9JOIM bIMw==
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=LfYjvhkK6a2z4gh78VE0hw5kPpNUovZqF0fFcQY3cGs=; b=DM+5Eil5PB5ZZeef6jkKz5KUUW5G1d/BtNDMxriVOa7u7lIRSyqymajlc4hmCADvJJ AHAthYseFxmTfK/tZV4PprcpDm7+6XXJUjlW+mvcOHNL3tS24L2PziZR4s5bA3F0LcIV JklSBg5RyBrtxFdjO0YuQWZ/APD0wdpF2wi8wQkW7tA7NIxXJydQPqio8cjPW+wZn+kc O25dghHerDW5ZArB47K80Z91kjG7aq1AbqHAPPvFFAWGa/vhyUWPcTP7NoWsYn+TMlGt es/ok3DpR0TpDGdw3xdqpZqdCLYvNnN/xTt82MsI4y9yBRz9EQFFESAj+bq5lAld5OiT U3bw==
X-Gm-Message-State: AJaThX5xKFy7oEvbZJMAYDjBaLmAsbSDOBlr6AJuCjUF+XL6SEGVsZAF LoocMveLwrdRqmHNcee/GdWE2iCd
X-Google-Smtp-Source: AGs4zMYxiEaJBlTV9Dplyml09t30KDcsQMAl8t4IoljSXORoSrlB2CH2O6twVSgvzP0Z0xKqDOawSw==
X-Received: by 10.157.51.144 with SMTP id u16mr11539019otc.292.1511310942364;  Tue, 21 Nov 2017 16:35:42 -0800 (PST)
Received: from ?IPv6:2600:8802:5600:f7a::1005? ([2600:8802:5600:f7a::1005]) by smtp.gmail.com with ESMTPSA id q67sm6035372oif.11.2017.11.21.16.35.40 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 16:35:40 -0800 (PST)
From: Fred Baker 
Content-Type: multipart/signed; boundary="Apple-Mail=_CD772DB4-D1BB-4246-A7C4-BABC74790FEC"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
Date: Tue, 21 Nov 2017 16:35:38 -0800
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.org>  <5A14A9A1.5020803@foobar.org>  <5A14C38B.1070809@foobar.org>
To: IETF IPv6 Mailing List 
In-Reply-To: <5A14C38B.1070809@foobar.org>
Message-Id: 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 00:35:44 -0000

--Apple-Mail=_CD772DB4-D1BB-4246-A7C4-BABC74790FEC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I read through the thread and part of the draft. I think there is a =
fundamental issue.

>    This document specifies a Router Advertisement Flag to indicate =
that
>    there is no IPv4 service on the advertising router.

That doesn't tell the receiver anything about other routers, and =
especially IPv4-only routers that might exist in the environment. I =
don't think one can conclude from the receipt of an RA, or for that =
matter every RA from every IPv6-capable router in the environment, that =
there is no IPv4 service in the environment. One might conclude that =
from the lack of a response to a DHCP request for an IPv4 address. What =
I would expect the host to do is an exponential backoff to only asking =
for an address every mumble minutes, which would be lost in the noise.

I don't see the point.

--Apple-Mail=_CD772DB4-D1BB-4246-A7C4-BABC74790FEC
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+AFAloUxloACgkQEhdRnd2G
P+AYsA//SmsFkE3y1gKQOVlDR/KXHc/j2nILID3EOhzWIdrn+P/TXSKp0p6ZERkt
J9pr0onMiXd/r+e58d7dxdVYQin/4Wdqahh/cyHkWURv9rxHvSpp/QI5awbpmBqk
k7Q9qaVkwHICGuj6jZbGDA5c14ezZaGa6Hxd41BK1NI19OM/YzXMHWqZ1oG040lx
DvMGloEAplEbmScagUPT30lOSL8rdOlnlCUnet/VvUsmnaNNRv7VVAO2W1FEKdO0
8QjKMh5sbm4TAlZP3grAxh39w49ftsTeJipgoucG38m6S0x7o9d4NVoMfN5cw1Ex
zLeD2xM1GkJ+OsN9YnIX4RtZb/QIPLUHrRECxD/I1XWJLlylkR/TUE223o7uBKue
A8LgDLwFSJkkxjVGzh/NYPI2tstHanGIX9TTrqLbuJOmHrZk79wfVIFULZrWvuqB
p4/SgAJlWbQgbWzbOGhy4YObOBbVxJ4TEKy8hwQxiWhrydVkQQVdp1EQBRv8hTvP
2CXP/7vo6IPXqJDHEw9QaEtdT7F6Icgk7/XGoFBpVQ+Y+ESECf/x1SAxp2Vm1DNE
+SU4v96yUpt65SS7eSmKG5L7Pb8LahYRh1DgFWCejztInRaPWL6bk7RGrI+0zoVa
gA+MFwcNnHuJr+ylupZv05B1HuDE6xa4ZJA5/wPezwtD4Kol2Ww=
=5xYk
-----END PGP SIGNATURE-----

--Apple-Mail=_CD772DB4-D1BB-4246-A7C4-BABC74790FEC--


From nobody Tue Nov 21 16:42:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E762129493 for ; Tue, 21 Nov 2017 16:42:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 8vsuzj2PvPjt for ; Tue, 21 Nov 2017 16:42:26 -0800 (PST)
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 48D10126DEE for ; Tue, 21 Nov 2017 16:42:26 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id B45337B2 for ; Wed, 22 Nov 2017 00:42:25 +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 mh15esXYgNpI for ; Tue, 21 Nov 2017 18:42:25 -0600 (CST)
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 5C553842 for ; Tue, 21 Nov 2017 18:42:25 -0600 (CST)
Received: by mail-lf0-f69.google.com with SMTP id m1so3361152lfj.11 for ; Tue, 21 Nov 2017 16:42:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eUuLm0N2sl3W5zrslRH1DA1Ucg5JPJxvSG9UoD5dtMc=; b=Ui9EPZT/9i7szOFVijLLLaO4PxeW+1jQpsA4Q+77KpkM2sOWUMwnZWWBvqga6L600Y 0YKssmP1QZ5ScM8fc9lWhInyUR/xjSQXMHVucEAVGWxfCcYcx5wRxP8BK5iJCDnmZnej 1oy/QYxj2T/iYrlbdRTl+r8HOYm9tsDtboSARcmzSXi0c0sNFnrHsSKiIVGGHUs49em2 nljgN7TZiZm1RLme8nkdrR9mMhdt8EWW2Wk6XV6tcpCkKldjZSY8vRieGx4K2ZgZGh6L Tl6FgKpTlSTl6g2rteP4lWEp2WWAahn8ls5iEK+dtAK8ZyCi2Pv4J+4U+LrOfuDl/UDS dNiA==
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=eUuLm0N2sl3W5zrslRH1DA1Ucg5JPJxvSG9UoD5dtMc=; b=fSCXaJ0gAuyT82L9pFvRpdrHJEBX3QmC1/ao+yF3nUN5X6SRPubSbHFiZnHmPrmmA8 aztrX7dCD7GQK2y62QROAl3yR6EGjx/Y1jJWpsU/xpInoRTzlpzTYXN/0uyXkpxKa/zg WQlS2KovnN8PTRZI2N4QuB2RLD2jImYX26xoVSKbGntRp+fVqwM+nZGLn/s/qbRdh7Z5 bgT0LSu7lDj3srtsz+1/wRbN9eflvk8MjO/aoKTl7/3aeUIX7bfwfoL7A29Njbr358/j oGv6HfCyDA4TKINaCbExR4q91ZjPG6ghoKwSAaiWGtWSIwJQHfw9e6+WCo6bSL0pVa2u IBIg==
X-Gm-Message-State: AJaThX4FANs29Rg0Vo3EpczI9Rr0sCqWHJtrh35qaajA/l8qM60Iw2zC wM/EuExiinMum5aiiMSIH4SJj5Ck5sXLrcH39say5gU1pOXhikBKPIEjNOlLh4ixzqanIwAE0gz Ve9ZJJHypMBtkXNZv7NS+YM+t
X-Received: by 10.25.15.161 with SMTP id 33mr6461446lfp.57.1511311343735; Tue, 21 Nov 2017 16:42:23 -0800 (PST)
X-Google-Smtp-Source: AGs4zMa5BVdgSEOADxRuDiOurZkDOJL42UGt/jNOriFOLa1WO4wXSl+zLzNVZ7RNoXliRLhsEJChE/jiIRi8V2G8H2Y=
X-Received: by 10.25.15.161 with SMTP id 33mr6461441lfp.57.1511311343503; Tue, 21 Nov 2017 16:42:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Tue, 21 Nov 2017 16:42:22 -0800 (PST)
In-Reply-To: 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.org>  <5A14A9A1.5020803@foobar.org> 
From: David Farmer 
Date: Tue, 21 Nov 2017 18:42:22 -0600
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Brian E Carpenter 
Cc: Nick Hilliard , Lorenzo Colitti ,  IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary="001a113f2200c665f2055e879724"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 00:42:28 -0000

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

On Tue, Nov 21, 2017 at 6:15 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 22/11/2017 11:33, Nick Hilliard wrote:
> > Lorenzo Colitti wrote:
> >> On Wed, Nov 22, 2017 at 12:47 AM, Nick Hilliard 
> wrote:
> >>> There would also be a requirement
> >>> for the network edge to be able to filter out RAs with this option,
> >>
> >> Why is it not sufficient to configure the routers that emit the RAs?
> >
> > because you're assuming congruity between ipv4 and ipv6 connectivity on
> > a network, which is not codified in any ietf document that I'm aware of.
> >  If there is a incongruity between management of the two protocols, then
> > the l2 network must have a mechanism to stop an ipv6 gateway from
> > attempting shutting down ipv4 services.
>
> This is a very interesting point. If every IPv6 router on a link believes
> there is no IPv4 router/DHCP service, they would all send flag==1 in the
> proposed solution. So the proposal only works if at least one IPv6 router
> is colocated with an IPv4 router, and therefore knows to send flag==0.
> Oops.
>

This is a problem only if the flag is set automatically and their is no
mechanism to override the automatic setting.  Most routers with an IPv6
address configured on an interface by default will send an RA unless you
configure them not to.  So, an IPv6 router without IPv4 configured on the
interface should set this flag, unless configured otherwise.  In other
words you need to be able to tell an IPv6 router there is IPv4 on the
interface even if router is not providing it.

It is quite possible that the IPv6 topology is incongruous from the IPv4
topology, however it is doubtful than the management is also incongruous.

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
===============================================

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




On Tue, Nov 21, 2017 at 6:15 PM, Brian E Carpenter &l=
t;brian.e.=
carpenter@gmail.com> wrote:
On 22/11/2017 11:33, Nick Hilliard wrote:

> Lorenzo Colitti wrote:

>> On Wed, Nov 22, 2017 at 12:47 AM, Nick Hilliard <nick@foobar.org> wrote:

>>> There would also be a requirement

>>> for the network edge to be able to filter out RAs with this op=
tion,

>>

>> Why is it not sufficient to configure the routers that emit the RA=
s?

>

> because you're assuming congruity between ipv4 and ipv6 connectivi=
ty on

> a network, which is not codified in any ietf document that I'm awa=
re of.

>=C2=A0 If there is a incongruity between management of the two protocol=
s, then

> the l2 network must have a mechanism to stop an ipv6 gateway from

> attempting shutting down ipv4 services.



This is a very interesting point. If every IPv6 router on a link believes
there is no IPv4 router/DHCP service, they would all send flag=3D=3D1 in th=
e

proposed solution. So the proposal only works if at least one IPv6 router
is colocated with an IPv4 router, and therefore knows to send flag=3D=3D0.<=
br>
Oops.

This is a problem only if the fla=
g is set automatically and their is no mechanism to override the automatic =
setting.=C2=A0 Most routers with an IPv6 address configured on an interface=
 by default will send an RA unless you configure them not to.=C2=A0 So, an =
IPv6 router without IPv4 configured on the interface should set this flag, =
unless configured otherwise.=C2=A0 In other words you need to be able to te=
ll an IPv6 router there is IPv4 on the interface even if router is not prov=
iding it.=C2=A0

It is quite possible that the IPv6=
 topology is incongruous from the IPv4 topology, however it is doubtful tha=
n the management is also incongruous.

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 &am=
p; Telecommunication Services
Office of Information Technology
Univer=
sity 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 




--001a113f2200c665f2055e879724--


From nobody Tue Nov 21 18:32:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93B1129C13 for ; Tue, 21 Nov 2017 18:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMI2PD0NGqmj for ; Tue, 21 Nov 2017 18:32:27 -0800 (PST)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56610120713 for ; Tue, 21 Nov 2017 18:32:27 -0800 (PST)
Received: by mail-pf0-x22d.google.com with SMTP id t69so11314811pfg.4 for ; Tue, 21 Nov 2017 18:32:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v4WJNh3MSrXts2qJ9+BBXaCU3pSGlTCHSMOthaD53sU=; b=We8lqeus4NO71cKkhH2WWI3g4rgWXZVh5ebHYWC7LIsk+aG5dcSWHYW7Q/Kg0/ipjS 67gYKMGtYGoNE7BXvfmAfUl6ySIh0v/x2CPK3WMikFGxDBo5taRQrMcQ6lmzdcPgMlnq U6jOfXh/Es+xg/m0VMME6bvW1utchqfMKsRYq+cDi27i0WnF9xUkY/9FutERiSyPUj5g 4ovNxUAgXvxNfzgkeEuI/3tAfU3VcBsfcYjIBDfC4fJyRPHiA+MR3y2Lsdaw6t5LtWWM vCpbRPt176WJuaxAKTqFBrXJQO0neapEgOrNlWEk0B36m93XA2jh71IUl8aAH7hW8WQ9 ckVw==
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=v4WJNh3MSrXts2qJ9+BBXaCU3pSGlTCHSMOthaD53sU=; b=NTzJTauOtL6qkT5d+A0c/y1S2oJBYBcYh/cXLLwp99S5pxqIMkOQOmCrY6jsS4Aeqz kZa+BSS4cpopVCopxaGV0c8ZRH1OefYFJG+lx93dJ0fG4cw1C0JwygMRCBUtK3ZO5gly TmSXpcCuWzm6l/nqwhew+YHfhUaChWabDnCeHMTOWVzUumk1ZXr47vTz/Hqd0Ug9BATf Sz9ZABY842LIFYWA187uyBGN2tcY5LuUBAYY1N10HT/9EwGDB857FNJvqWl4het7uPtc E8F0SUdIpFRQhvKTew+clBJRwcDb7FV+J8gf99onEFxwBIkADiclwtsDW3nQH5U1MgRq CNrQ==
X-Gm-Message-State: AJaThX5c2NV+vEqrAFKBL8ewpgTEglxn0ughByF2nfTUWBBO+hWSMYQD Tir6eJ3KasdKvCb2emPTgF7Dg4FR
X-Google-Smtp-Source: AGs4zMZj5H5Peq4TXkzoyyRBIhTQFOjJFPMEVRX/VdFsZjhaPIu9lESPmIfE1I16pnFcoU+HEK8m+Q==
X-Received: by 10.99.126.6 with SMTP id z6mr18863089pgc.126.1511317946605; Tue, 21 Nov 2017 18:32:26 -0800 (PST)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id l191sm31346912pfc.180.2017.11.21.18.32.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 18:32:25 -0800 (PST)
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: David Farmer 
Cc: Nick Hilliard , Lorenzo Colitti , IETF IPv6 Mailing List 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.org>  <5A14A9A1.5020803@foobar.org>  
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <0a91f2b8-d8d2-438b-e5a2-57eed62e053c@gmail.com>
Date: Wed, 22 Nov 2017 15:32:27 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 02:32:29 -0000

On 22/11/2017 13:42, David Farmer wrote:
> On Tue, Nov 21, 2017 at 6:15 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>> On 22/11/2017 11:33, Nick Hilliard wrote:
>>> Lorenzo Colitti wrote:
>>>> On Wed, Nov 22, 2017 at 12:47 AM, Nick Hilliard 
>> wrote:
>>>>> There would also be a requirement
>>>>> for the network edge to be able to filter out RAs with this option,
>>>>
>>>> Why is it not sufficient to configure the routers that emit the RAs?
>>>
>>> because you're assuming congruity between ipv4 and ipv6 connectivity on
>>> a network, which is not codified in any ietf document that I'm aware of.
>>>  If there is a incongruity between management of the two protocols, then
>>> the l2 network must have a mechanism to stop an ipv6 gateway from
>>> attempting shutting down ipv4 services.
>>
>> This is a very interesting point. If every IPv6 router on a link believes
>> there is no IPv4 router/DHCP service, they would all send flag==1 in the
>> proposed solution. So the proposal only works if at least one IPv6 router
>> is colocated with an IPv4 router, and therefore knows to send flag==0.
>> Oops.
>>
> 
> This is a problem only if the flag is set automatically and their is no
> mechanism to override the automatic setting.  Most routers with an IPv6
> address configured on an interface by default will send an RA unless you
> configure them not to.  So, an IPv6 router without IPv4 configured on the
> interface should set this flag, unless configured otherwise.  In other
> words you need to be able to tell an IPv6 router there is IPv4 on the
> interface even if router is not providing it.
> 
> It is quite possible that the IPv6 topology is incongruous from the IPv4
> topology, however it is doubtful than the management is also incongruous.

Yes, but do you think we should push a mechanism that assumes correct
configuration by humans in order to work reliably? 
(Arguing against my own proposal, not for the first time ;-).

     Brian


From nobody Tue Nov 21 19:52:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B15129490 for ; Tue, 21 Nov 2017 19:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_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 xCyTX7UZySQ6 for ; Tue, 21 Nov 2017 19:52:21 -0800 (PST)
Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5AF126557 for ; Tue, 21 Nov 2017 19:52:20 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 6330E92D for ; Wed, 22 Nov 2017 03:52:20 +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 05Rv9acM7SMT for ; Tue, 21 Nov 2017 21:52:20 -0600 (CST)
Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id CD37B840 for ; Tue, 21 Nov 2017 21:52:19 -0600 (CST)
Received: by mail-lf0-f71.google.com with SMTP id q21so3465431lfb.12 for ; Tue, 21 Nov 2017 19:52:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MDIBqP5k52IiT7RKklNz7jcFTVXNOJo7jiaXe14hFgE=; b=fRZJ4+EtFgohyvCGNxQgGne8sAcahIGgGy8sAQEJuDH3iFGfZnDU+jF+RECiyAjY5K PMxNi+ur+BOA86DNbw2lxUVgPrXNqmVEx+WNN0b+5tS1nXw2OR+ELiMlAdZ/+zTH0Bzu e4SUDmod5aVBVAxf4QqbD2K1SJmWQ18luK0xryYygt+No8QWBjwMJo5drpFbT5GEQQfO zGzXIHpyjRaBjyD+u0JFmgG7CE5nnnsrv1HM7EBT1y1ZRP3Th76LA752vgYsYg6QXseH gun19xA+61qt9UEEDfxwPplrY+eUSsbrmrOxhcXV49rzSUJl2ypmvt9lkqJl6NQj5Tx/ VvNw==
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=MDIBqP5k52IiT7RKklNz7jcFTVXNOJo7jiaXe14hFgE=; b=BeYgNKI8MfhjHFLQpXN3P7IeSYfm+Cs6tlJISbr0Hvbr/FrjuwUe81QyigKZLd0UGI lgUSH73BfVGLmTFbrm14U3TsG/inX3qg/e1dQfRC5+HA8WbTsHT3NecEIBxu42kswFZP XpiaE9YcL5eQ0IS+Osmr7/TW7XErC7yhp7vVUTyn1KS6CQUE1kRSne15nKgs1fK4A6DN c2zIJ72L+3onp44iQjSwqH5A3E7TMz6zNwzaNqxjW9cg29PLLkMLvYye9+TO1tjQo0vz 2FmfWQf2JDoWqfjOXd9oTSX1MBD9bm+5RbbhUZdau84GYK0mSVtOtcIJQ+97Q4JgyIk0 PF7Q==
X-Gm-Message-State: AJaThX669codwNuMc1T2ZmKDVgcu01SCP9OSn8e84/EdiLTxXeF9nkXP mG3K008dYfdT0DO0d1S7k5Uokuc6qYCv4pXRNH+WKYt53BtFrpOPxHghTjHQEJDTLu2+VYD0j1f wyKfEqTkxz4a9m3oy86sMgc6Y
X-Received: by 10.46.7.82 with SMTP id i18mr5986726ljd.123.1511322738261; Tue, 21 Nov 2017 19:52:18 -0800 (PST)
X-Google-Smtp-Source: AGs4zMY5GxbvoO931NYkXOgJX05fEsQn2x2a9ze2VHnIHgHP2CgGX8CINWTagNDnM6D3SB8OLwc5w+C9GubKYFG77To=
X-Received: by 10.46.7.82 with SMTP id i18mr5986721ljd.123.1511322738035; Tue, 21 Nov 2017 19:52:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.217.89 with HTTP; Tue, 21 Nov 2017 19:52:17 -0800 (PST)
In-Reply-To: <0a91f2b8-d8d2-438b-e5a2-57eed62e053c@gmail.com>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.org>  <5A14A9A1.5020803@foobar.org>   <0a91f2b8-d8d2-438b-e5a2-57eed62e053c@gmail.com>
From: David Farmer 
Date: Tue, 21 Nov 2017 21:52:17 -0600
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Brian E Carpenter 
Cc: Nick Hilliard , Lorenzo Colitti ,  IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary="f403045f736cf12114055e8a3eec"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 03:52:23 -0000

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

On Tue, Nov 21, 2017 at 8:32 PM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 22/11/2017 13:42, David Farmer wrote:
> > On Tue, Nov 21, 2017 at 6:15 PM, Brian E Carpenter <
> > brian.e.carpenter@gmail.com> wrote:
> >
> >> On 22/11/2017 11:33, Nick Hilliard wrote:
> >>> Lorenzo Colitti wrote:
> >>>> On Wed, Nov 22, 2017 at 12:47 AM, Nick Hilliard 
> >> wrote:
> >>>>> There would also be a requirement
> >>>>> for the network edge to be able to filter out RAs with this option,
> >>>>
> >>>> Why is it not sufficient to configure the routers that emit the RAs?
> >>>
> >>> because you're assuming congruity between ipv4 and ipv6 connectivity on
> >>> a network, which is not codified in any ietf document that I'm aware
> of.
> >>>  If there is a incongruity between management of the two protocols,
> then
> >>> the l2 network must have a mechanism to stop an ipv6 gateway from
> >>> attempting shutting down ipv4 services.
> >>
> >> This is a very interesting point. If every IPv6 router on a link
> believes
> >> there is no IPv4 router/DHCP service, they would all send flag==1 in the
> >> proposed solution. So the proposal only works if at least one IPv6
> router
> >> is colocated with an IPv4 router, and therefore knows to send flag==0.
> >> Oops.
> >>
> >
> > This is a problem only if the flag is set automatically and their is no
> > mechanism to override the automatic setting.  Most routers with an IPv6
> > address configured on an interface by default will send an RA unless you
> > configure them not to.  So, an IPv6 router without IPv4 configured on the
> > interface should set this flag, unless configured otherwise.  In other
> > words you need to be able to tell an IPv6 router there is IPv4 on the
> > interface even if router is not providing it.
> >
> > It is quite possible that the IPv6 topology is incongruous from the IPv4
> > topology, however it is doubtful than the management is also incongruous.
>
> Yes, but do you think we should push a mechanism that assumes correct
> configuration by humans in order to work reliably?
> (Arguing against my own proposal, not for the first time ;-).
>

If you have the funds to build two separate infrastructures, which is what
we are talking about here, one for IPv4 and separate one for IPv6, you
should have the funds to pay for humans smart enough to manage the two
separate infrastructures.  An IPv6 topology incongruous from the IPv4
topology is not going to be a common deployment model, at least for anyone
who will be relying on auto-configuration.

-- 
===============================================
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
===============================================

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




On Tue, Nov 21, 2017 at 8:32 PM, Brian E Carpenter &l=
t;brian.e.=
carpenter@gmail.com> wrote:
On 22/11/2017 13:42, David Farmer wrote:

> On Tue, Nov 21, 2017 at 6:15 PM, Brian E Carpenter <

> brian.e.carpenter@gmail=
.com> wrote:

>

>> On 22/11/2017 11:33, Nick Hilliard wrote:

>>> Lorenzo Colitti wrote:

>>>> On Wed, Nov 22, 2017 at 12:47 AM, Nick Hilliard <nick@foobar.org>

>> wrote:

>>>>> There would also be a requirement

>>>>> for the network edge to be able to filter out RAs with=
 this option,

>>>>

>>>> Why is it not sufficient to configure the routers that emi=
t the RAs?

>>>

>>> because you're assuming congruity between ipv4 and ipv6 co=
nnectivity on

>>> a network, which is not codified in any ietf document that I&#=
39;m aware of.

>>>=C2=A0 If there is a incongruity between management of the two =
protocols, then

>>> the l2 network must have a mechanism to stop an ipv6 gateway f=
rom

>>> attempting shutting down ipv4 services.

>>

>> This is a very interesting point. If every IPv6 router on a link b=
elieves

>> there is no IPv4 router/DHCP service, they would all send flag=3D=
=3D1 in the

>> proposed solution. So the proposal only works if at least one IPv6=
 router

>> is colocated with an IPv4 router, and therefore knows to send flag=
=3D=3D0.

>> Oops.

>>

>

> This is a problem only if the flag is set automatically and their is n=
o

> mechanism to override the automatic setting.=C2=A0 Most routers with a=
n IPv6

> address configured on an interface by default will send an RA unless y=
ou

> configure them not to.=C2=A0 So, an IPv6 router without IPv4 configure=
d on the

> interface should set this flag, unless configured otherwise.=C2=A0 In =
other

> words you need to be able to tell an IPv6 router there is IPv4 on the<=
br>
> interface even if router is not providing it.

>

> It is quite possible that the IPv6 topology is incongruous from the IP=
v4

> topology, however it is doubtful than the management is also incongruo=
us.



Yes, but do you think we should push a mechanism that assumes correct

configuration by humans in order to work reliably?

(Arguing against my own proposal, not for the first time ;-).

If you have the funds to build two separate infrastr=
uctures, which is what we are talking about here, one for IPv4 and separate=
 one for IPv6, you should have the funds to pay for humans smart enough to =
manage the two separate infrastructures.=C2=A0 An IPv6 topology incongruous=
 from the IPv4 topology is not going to be a common deployment model, at le=
ast for anyone who will be relying on auto-configuration.=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 &am=
p; Telecommunication Services
Office of Information Technology
Univer=
sity 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 




--f403045f736cf12114055e8a3eec--


From nobody Tue Nov 21 23:19:21 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF771128B38; Tue, 21 Nov 2017 23:19:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.539
X-Spam-Level: 
X-Spam-Status: No, score=0.539 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, LONGWORDS=2.035, 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 4fO-vw4tl3GY; Tue, 21 Nov 2017 23:19:11 -0800 (PST)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 D9826126B71; Tue, 21 Nov 2017 23:19:10 -0800 (PST)
Received: by mail-ua0-x229.google.com with SMTP id 108so9988677uaf.2; Tue, 21 Nov 2017 23:19:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jjL03jsDFGZA1hGK95LCPER95NpwRhSyHUIX6cVvUIc=; b=WdtzxXEFwLtyR/+lhXTJniW/pwy/GGC6jnmUwCWp8ALIByCWJBGj8b5Zo0V0LOGgIy k4DN5crr6xkIGf/wkmgOipRebt3DIjTkCgeFCqw+AtI3icB25sCOSyXgIXEZTdaiVgul wdLkjNjE+IgjURFGg1XQBbUBQ1Qr4hrcLjReS0Dyk33fHih67a0njg56QKFzYI7KvACi utxnI4CR0F7WIvMJ2k387S065Dg0z3CQ8XohjF6vwVO6gYISf1mr6PkYz2KziMT/VtZe Db/Ydprk23ACgib0EqmOvqfysrO8khLsuRYU3LgXy+Czw5Vg+I/nr624xpx7zq1MeMkh 3FKg==
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=jjL03jsDFGZA1hGK95LCPER95NpwRhSyHUIX6cVvUIc=; b=LHScaVlkJn0BICTL4NDVr++zHMYnIt8kdZuwOXPXA4m9MNP+CK1Zo9XbHFFiveW72y Na5R6DgIOr3rHhSATw1kzKimOQrjQoamdXNBZTojcSbRPoM0z07uHghzwmmkMnbID7BZ Wni/Gcn3agjmwWPmEGwRuI9KZEboFvDILq659HNsCZvpA5vuXRdWq0YhKxDy5QYNxYu4 Qn7re2ez1DDF4xpYRurhs9V9b/7uIg2GPg826MfPzb7mzfjENHrJ9cPkS/Tn2iDr/fiV 63gHYOllK7YnhTX5fa4eyd06/8whZc3YNY6AbesaJSdyBjcf3LYinCWlc7n6ykkMHlV8 Rrkw==
X-Gm-Message-State: AJaThX6My8Hnfc9jNSYtlTNet5sFhcAxqrF25tn+oiciCN0VksPBH7NU LpbEehyPfvDgYKPRuwbZuwKswUv8NI6iOeh584o=
X-Google-Smtp-Source: AGs4zMbWAYFLkrmvzs8rT4iWVL7BCYbgHAOJgiD/tEO1YFbqlfnhCv60fSygw90aXlLJHs/yCr5wM1HRyF/wyXSP11M=
X-Received: by 10.176.78.17 with SMTP id g17mr16520680uah.169.1511335149766; Tue, 21 Nov 2017 23:19:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.69.68 with HTTP; Tue, 21 Nov 2017 23:19:09 -0800 (PST)
Received: by 10.176.69.68 with HTTP; Tue, 21 Nov 2017 23:19:09 -0800 (PST)
In-Reply-To: <7F30D7F6-7859-4D2B-B550-8C8CB944FF9F@steffann.nl>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com> <7F30D7F6-7859-4D2B-B550-8C8CB944FF9F@steffann.nl>
From: Mark Smith 
Date: Wed, 22 Nov 2017 18:19:09 +1100
Message-ID: 
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: Sander Steffann 
Cc: "Templin, Fred L" , dhcwg@ietf.org,  "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="f403043c48acbd0bdd055e8d2213"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 07:19:13 -0000

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

On 21 Nov. 2017 10:34 am, "Sander Steffann"  wrote:

Hi,

> This document therefore proposes a unification of IPv6 ND and DHCPv6 where
> the two functions work together as if they were one. This is accommodated
by
> a new IPv6 ND option in RS/RA messages called the "DHCPv6 option". By
working
> together as one function, IPv6 ND and DHCPv6 can supply requesting nodes
with
> all link-specific autoconfiguration information and any managed
address/prefix
> delegations in a single round trip message exchange.

Interesting way of doing this. I have thought about combining ND and DHCPv6
before, but more as a different distribution mechanism: ND for pushing
options to all clients on the network,


So how often do you want to upgrade router firmware? Everytime you want to
deploy an application that uses a new DHCPV6 option?

What do you do when the router vendor says, "we're never going to implement
that new DHCPV6 option in that router model, we don't have enough customers
any more for that model to justify all the development and testing time".
Never deploy the application?

What do you do if the router before says, "that DHCPv6 option is on our
implementation road map, we're expecting to implement it in 6 months
time."? Wait six months before you deploy the application?

Pushing layer 4+ configuration options into ND creates a dependency on
router firmware for application deployment that doesn't exist today in
either ND or DHCPV6.

Another example of this trap. Remember that NTP amplification DoS from 3 or
4 years ago? One place I'm aware of were using their PE routers to also
provide customers with NTP time, and the router implementation was
vulnerable. From memory, the vendor took around a week to release a fix.
Then the next 6 to 8 weeks were spent organising high impact change
controls because router firmware upgrades either required reboots or there
was a hazard of one. The number of PE routers was in the 10s, imagine time
and effort, and vulnerability exposure time if there were 100s or 1000s of
PE routers providing NTP time to customers.

Compare that to if the NTP service/application was not "in" the network,
not "in" the routers' control planes, and as service reachable over the
network. Only patches to the NTP servers would have been necessary, and
there would have been far fewer of those.




and DHCPv6 for clients requesting specific options for themselves. Just to
make it possible to use both mechanisms for all options (MAP/DSLite/etc
options in RA would be nice).

What you are doing is another way of looking at it. If I understand
correctly you're basically keeping the full functionality of DHCPv6 but
using RS/RA as a transport instead of UDP. I wonder what the speed benefit
of that would be in practice. Also compared to "impatient" systems that
send out DHCPv6 a request before even receiving an RA.

> I would ask these discussion lists to consider what is it that you really
don't
> like about DHCPv6. Maybe you think it is ugly. Maybe you don't like the
way
> the acronym rolls off your tongue when you speak it. Maybe it has an
onerous
> stigma of being stateful. But, then I would also ask you to consider what
a
> replacement would look like. Because, I think any suitable replacement
> would have to essentially duplicate what DHCPv6 already does.

In my opinion DHCPv6 is fine. I implemented a server and it is a *lot*
cleaner to implement than DHCPv4. Just plain UDP on link-local and
multicast sockets :)  Especially the stateless version is very easy to
implement. It's not the ultimate configuration protocol, and for certain
things distributing information via RA is a much better fit to the way the
network is run. But DHCPv6 has its place and its role, and in certain
environments (DHCPv6-PD in ISP networks, DHCPv6 in enterprise etc) it does
what the network and system operators need.

The main problem with DHCPv6 as an operator has been dealing with DUIDs
when the link-layer address in the DUID is based on a different interface
than the interface sending the DHCPv6 request. Mostly because the
requesting interface's MAC address has always been used with DHCPv4 and is
often printed on the outside of the device. But these days LDRA and DHCPv6
relays can tell the DHCPv6 server what the MAC address of the requesting
interface was, and we can use that to identify the client (in addition to
its DUID). With vendors starting to implement this relay option this is
mostly a solved problem now.

Another thing that makes me a bit sad is the lack of DHCPv6 reconfigure
support. That could be used to take away some of the complaints against
DHCPv6 (and any client-initiated configuration protocol) that there is no
way for the network to inform the client of changes.

I see no need to replace it with something else that would indeed need to
duplicate its functionality.

Cheers,
Sander

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

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




On 21 Nov. 2017 10:34 am, "Sander Steffann" <sander@steffann.nl> wrote:
Hi,




> This document therefore proposes a unification of IPv6 ND and DHCPv6 w=
here

> the two functions work together as if they were one. This is accommoda=
ted by

> a new IPv6 ND option in RS/RA messages called the "DHCPv6 option&=
quot;. By working

> together as one function, IPv6 ND and DHCPv6 can supply requesting nod=
es with

> all link-specific autoconfiguration information and any managed addres=
s/prefix

> delegations in a single round trip message exchange.




Interesting way of doing this. I have thought about combining ND and =
DHCPv6 before, but more as a different distribution mechanism: ND for pushi=
ng options to all clients on the network,

So how often do you want to upgr=
ade router firmware? Everytime you want to deploy an application that uses =
a new DHCPV6 option?

Wha=
t do you do when the router vendor says, "we're never going to imp=
lement that new DHCPV6 option in that router model, we don't have enoug=
h customers any more for that model to justify all the development and test=
ing time". Never deploy the application?

What do you do if the router before says, "that =
DHCPv6 option is on our implementation road map, we're expecting to imp=
lement it in 6 months time."? Wait six months before you deploy the ap=
plication?

Pushing layer=
 4+ configuration options into ND creates a dependency on router firmware f=
or application deployment that doesn't exist today in either ND or DHCP=
V6.

Another example of t=
his trap. Remember that NTP amplification DoS from 3 or 4 years ago? One pl=
ace I'm aware of were using their PE routers to also provide customers =
with NTP time, and the router implementation was vulnerable. From memory, t=
he vendor took around a week to release a fix. Then the next 6 to 8 weeks w=
ere spent organising high impact change controls because router firmware up=
grades either required reboots or there was a hazard of one. The number of =
PE routers was in the 10s, imagine time and effort, and vulnerability expos=
ure time if there were 100s or 1000s of PE routers providing NTP time to cu=
stomers.

Compare that to=
 if the NTP service/application was not "in" the network, not &qu=
ot;in" the routers' control planes, and as service reachable over =
the network. Only patches to the NTP servers would have been necessary, and=
 there would have been far fewer of those.



=

 and DHCPv6 for clients requesting specific=
 options for themselves. Just to make it possible to use both mechanisms fo=
r all options (MAP/DSLite/etc options in RA would be nice).



What you are doing is another way of looking at it. If I understand correct=
ly you're basically keeping the full functionality of DHCPv6 but using =
RS/RA as a transport instead of UDP. I wonder what the speed benefit of tha=
t would be in practice. Also compared to "impatient" systems that=
 send out DHCPv6 a request before even receiving an RA.




> I would ask these discussion lists to consider what is it that you rea=
lly don't

> like about DHCPv6. Maybe you think it is ugly. Maybe you don't lik=
e the way

> the acronym rolls off your tongue when you speak it. Maybe it has an o=
nerous

> stigma of being stateful. But, then I would also ask you to consider w=
hat a

> replacement would look like. Because, I think any suitable replacement=


> would have to essentially duplicate what DHCPv6 already does.




In my opinion DHCPv6 is fine. I implemented a server and it is a *lot=
* cleaner to implement than DHCPv4. Just plain UDP on link-local and multic=
ast sockets :)=C2=A0 Especially the stateless version is very easy to imple=
ment. It's not the ultimate configuration protocol, and for certain thi=
ngs distributing information via RA is a much better fit to the way the net=
work is run. But DHCPv6 has its place and its role, and in certain environm=
ents (DHCPv6-PD in ISP networks, DHCPv6 in enterprise etc) it does what the=
 network and system operators need.



The main problem with DHCPv6 as an operator has been dealing with DUIDs whe=
n the link-layer address in the DUID is based on a different interface than=
 the interface sending the DHCPv6 request. Mostly because the requesting in=
terface's MAC address has always been used with DHCPv4 and is often pri=
nted on the outside of the device. But these days LDRA and DHCPv6 relays ca=
n tell the DHCPv6 server what the MAC address of the requesting interface w=
as, and we can use that to identify the client (in addition to its DUID). W=
ith vendors starting to implement this relay option this is mostly a solved=
 problem now.



Another thing that makes me a bit sad is the lack of DHCPv6 reconfigure sup=
port. That could be used to take away some of the complaints against DHCPv6=
 (and any client-initiated configuration protocol) that there is no way for=
 the network to inform the client of changes.



I see no need to replace it with something else that would indeed need to d=
uplicate its functionality.



Cheers,

Sander




-----------------------------------------------------------------=
---

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

-----------------------------------------------------------------=
---





--f403043c48acbd0bdd055e8d2213--


From nobody Tue Nov 21 23:33:32 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0912EB4D for ; Tue, 21 Nov 2017 23:33:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.035
X-Spam-Level: 
X-Spam-Status: No, score=0.035 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, LONGWORDS=2.035, 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 FZ_3Pwm8TtER for ; Tue, 21 Nov 2017 23:33:29 -0800 (PST)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22AC12EB2D for <6man@ietf.org>; Tue, 21 Nov 2017 23:33:28 -0800 (PST)
Received: by mail-yb0-x230.google.com with SMTP id x72so5529494ybg.11 for <6man@ietf.org>; Tue, 21 Nov 2017 23:33:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G4xKUa6+HAprE45vV0YEbcl72O5FS1IYmIKDP3tZnEE=; b=P22BOuSY4wQ4Ao4F0kXBRR+MZJ1OhoYZSBIVw90CtBPMyWOOdh8x1vLgigWQiXqwfg N2ZyXaEyPA582qarRXuUdxqDPD7eJMN/U2A31Y+l5Tt1MCD59ykDg3umwlv4qULcW1UY NMcdb3k7C/B2AKdGZRaT1+Itzr4xrKN5B3MbtiiRso4OIKOAnCOCrzLxy/CZ/16pJk9V dwpq/ALXxYYkyijkyOvlALLsXm0w5g2o1qt/mwZTILMMJprXDSSSUc2g5nTd+Nmy4QR0 Nwwh9CL3kyyuprR1X5m5U2NVOTxYyKsWJAXudbmXyj1ubdDrJjdiJ+LczkhgNG/YHFUy 4/3A==
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=G4xKUa6+HAprE45vV0YEbcl72O5FS1IYmIKDP3tZnEE=; b=H5zusJsfld+Qlp0ErigK2Z6pyx43LP0XfrIr//b4bh8LshtczY8lh0crUig4s1YAuK GvbQj28TLdz7QbhMRnGx8MJ4ZTrSiP6A0djUyFBFRlj2eaTLAcpaFNW8sldFbluw6fEa uqAomNYORRmynZm0jBu7WSng99fE1b38wwDU3OtRKZWOTqSETItHq9e3P3zmMzK4BuBV YEQ/dG6feo3ugt7o+nk7BUgzeFZeOV/Ex0WCxT0PWW0UK5+YjH1Cqj08VZcQxH03ykQR ZKDdJT4btBsFkvTQ/2mJ4hxGmEpXhLFQQ22ossawPHB5u8GbDiqnUWyGhReS1fTVWuvJ XsWw==
X-Gm-Message-State: AJaThX6binuc8+nOeDV4dUDIah1IYy7SKwNg1WPYHEVwuWh/Foc0opr5 6TUNfd0KDnn390c0uid85rDSjKp4NTZ7VJT3cERG5Q==
X-Google-Smtp-Source: AGs4zMbDUyjFKEDafZ8EvUydtVHDJ+R+PHpw06BpeOkILp6GEsmt3jJqZZRi6zQDIN6AaB154cy0aYdpETA1E0/5MhM=
X-Received: by 10.37.66.75 with SMTP id p72mr13086674yba.63.1511336007721; Tue, 21 Nov 2017 23:33:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.4.194 with HTTP; Tue, 21 Nov 2017 23:33:07 -0800 (PST)
In-Reply-To: 
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com> <7F30D7F6-7859-4D2B-B550-8C8CB944FF9F@steffann.nl> 
From: Lorenzo Colitti 
Date: Wed, 22 Nov 2017 16:33:07 +0900
Message-ID: 
Subject: Re: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: Mark Smith 
Cc: Sander Steffann , dhcwg@ietf.org, "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11c04b04e0ee4f055e8d55ee"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 07:33:30 -0000

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

On Wed, Nov 22, 2017 at 4:19 PM, Mark Smith  wrote:

> Pushing layer 4+ configuration options into ND creates a dependency on
> router firmware for application deployment that doesn't exist today in
> either ND or DHCPV6.
>
> Another example of this trap. Remember that NTP amplification DoS from 3
> or 4 years ago? One place I'm aware of were using their PE routers to also
> provide customers with NTP time, and the router implementation was
> vulnerable. From memory, the vendor took around a week to release a fix.
> Then the next 6 to 8 weeks were spent organising high impact change
> controls because router firmware upgrades either required reboots or there
> was a hazard of one. The number of PE routers was in the 10s, imagine time
> and effort, and vulnerability exposure time if there were 100s or 1000s of
> PE routers providing NTP time to customers.
>
> Compare that to if the NTP service/application was not "in" the network,
> not "in" the routers' control planes, and as service reachable over the
> network. Only patches to the NTP servers would have been necessary, and
> there would have been far fewer of those.
>

These are all good reasons for ND being limited to only those options that
are strictly necessary for connectivity. There are those who argue that
even DHCPv6 is too low-level for that sort of thing and that
application-level configuration should be moved to another protocol.

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


On W=
ed, Nov 22, 2017 at 4:19 PM, Mark Smith <markzzzsmith@gmail.com&g=
t; wrote:
Pushing layer 4+ configuration options into ND creates a de=
pendency on router firmware for application deployment that doesn't exi=
st today in either ND or DHCPV6.

Another example of this trap. Remember that NTP amplifi=
cation DoS from 3 or 4 years ago? One place I'm aware of were using the=
ir PE routers to also provide customers with NTP time, and the router imple=
mentation was vulnerable. From memory, the vendor took around a week to rel=
ease a fix. Then the next 6 to 8 weeks were spent organising high impact ch=
ange controls because router firmware upgrades either required reboots or t=
here was a hazard of one. The number of PE routers was in the 10s, imagine =
time and effort, and vulnerability exposure time if there were 100s or 1000=
s of PE routers providing NTP time to customers.
Compare that to if the NTP service/application was=
 not "in" the network, not "in" the routers' contro=
l planes, and as service reachable over the network. Only patches to the NT=
P servers would have been necessary, and there would have been far fewer of=
 those.

These are all good reas=
ons for ND being limited to only those options that are strictly necessary =
for connectivity. There are those who argue that even DHCPv6 is too low-lev=
el for that sort of thing and that application-level configuration should b=
e moved to another protocol.


--001a11c04b04e0ee4f055e8d55ee--


From nobody Wed Nov 22 00:05:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81259126CBF for ; Wed, 22 Nov 2017 00:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2POpNhcrhnCU for ; Wed, 22 Nov 2017 00:05:44 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF03127444 for ; Wed, 22 Nov 2017 00:05:44 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAM85gZR046651 for ; Wed, 22 Nov 2017 09:05:42 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7663B20289C for ; Wed, 22 Nov 2017 09:05:42 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5878F2025EC for ; Wed, 22 Nov 2017 09:05:42 +0100 (CET)
Received: from [132.166.84.211] ([132.166.84.211]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAM85eHS012682 for ; Wed, 22 Nov 2017 09:05:41 +0100
Subject: Re: IPv6 only host NAT64 requirements?
To: ipv6@ietf.org
References:   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no> <0a13ea07-6b60-9ae6-659e-c054acdc156d@gmail.com>
From: Alexandre Petrescu 
Message-ID: <2bbae231-d57e-4ba7-8ac5-65dbba9a9da2@gmail.com>
Date: Wed, 22 Nov 2017 09:05:39 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <0a13ea07-6b60-9ae6-659e-c054acdc156d@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 08:05:47 -0000

Le 22/11/2017 à 01:01, Brian E Carpenter a écrit :
> in line...
> 
> On 21/11/2017 22:40, Ola Thoresen wrote:
>> On 20. nov. 2017 20:37, Brian E Carpenter wrote:
>>
>>> On 21/11/2017 02:36, Ole Troan wrote:
>>> ...>> [Med] These are generic statements, Ole. We are talking about the IETF case.
>>>>> * The IETF has no control on the hosts that connect to the IETF network,
>>>>> * IETF attendees who are using corporate devices, have no control on these hosts
>>>>>
>>>>> So, how forcing devices to use "IPv6+nat64" will help here?
>>>> Eat own dogfood. Many IETF people are developers or work for companies having applications not working.
>>>> As I said there were a minimum of applications that didn't work. Corporate VPNs largely did. Jen has the final numbers.
>>> However, as long as even one application, such as one VPN, or one
>>> literal IPv4 address, fails, that represents millions of failure cases
>>> if we consider the whole world (e.g. imagine every hotel network in
>>> the world running IPv6+NAT64 only). That simply isn't viable. Dual
>>> stack in every hotel room in the world is viable, from the hotel guests'
>>> point of view. Operators might not like it, but users wouldn't care.
>>
>> In hotel rooms and other "public" or "guest" networks, there are so many
>> things that fail already, due to NAT, misconfigured firewalls,
>> unmaintained blocklists, SSL-proxies and whatnot, so you can hardly
>> expect any services other than basic web-surfing without https to work.
>> Not that this is an ideal situation today, but i do not believe that "if
>> even one VPN or one liter IPv4 address fails" should be a showstopper
>> for introducing this.
> 
> Hotels won't make that choice, but the providers of hotel networks will,
> entirely based on their perception of the number of help desk calls
> they will have to handle for any given change. Since they haven't even
> made the move from IPv4 to dual stack, I think we'll wait a long time
> before they attempt any form of IPv6-only. Sad but true.
> 
>> Possibly, or even probably, introducing IPv6 (-only and NAT64) will even
>> make the situation better for a lot of people, as you get rid of all the
>> horrible NAT solutions for services that are already dual stacked.
> 
> But those horrible NAT solutions are up and running today.

It will be noticed that on NAT64 ESSID the experience is worse than on 
IPv4, at least for VPN sessions.

Alex

  For this
> class of operator, any change is bad news, unfortunately. What is their
> incentive to make such a change?
> 
>      Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Wed Nov 22 01:37:38 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2D61292AE for ; Wed, 22 Nov 2017 01:37:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mDeXCovh-twp for ; Wed, 22 Nov 2017 01:37:34 -0800 (PST)
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 16002128DF6 for ; Wed, 22 Nov 2017 01:37:34 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id k3so6909022ywk.8 for ; Wed, 22 Nov 2017 01:37:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HaiTkoMd/fQWfOErUa8bhcNxbyPBhMrcOXJ3lwk7Slo=; b=MlN0tlGT7pSLtd46RwD0oM1O03q3M6BISpezJLkwXto3EfvXqCfjYOviC1A83sXwft dPuiQSq4kK5m0VM4jf1nPZiH8XC0gw45eUwIqZwhkVQLsoJAH5paagCaj1ScrPbp9Nvc R9aQX9jzL4bHTy63Th5iWEXUi/DoLL1+AgB5bB3itQ+ZpMW16QyuabDXtaJf5p5H3Rg7 z9fFjdsS1uHRkdEPaE/VvJko4Y6Cy1wUbULShh6tC3Tl0OUYxBammlZPykkWERl1UxPJ FZFvHpLzGwJMaOxGAbfu6CVfDuseAjihzpq815xjEc9vgn+HZtl5dwrR3Sw3IRECo+AV yFOw==
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=HaiTkoMd/fQWfOErUa8bhcNxbyPBhMrcOXJ3lwk7Slo=; b=UJuDSlYX45nqeWRdZCFfebmF9STpsrgOJGl6W8DcNRReFRPR6FcJ7Av9I0SPmrr9e4 JTN3RELDi8WHMUz9pFjeVWGR4AQkfS3pIpz4JwtMKakvoC0++mVhU7wG0iq6keD1dzl4 MBcPXfViHD7XXbPeL2kPD1M+sEFbEBUlURq8oKJlkLV4mmt+WlmKTIGH/OfeSEYCeplV wBGB8cA5gimUt0W1oMKSQ/p0zYknW+Obb2POiTXqmIyv1yqPcSOOEhuoB4py2w6ZhSLs FIdlwET5yrXkJxBp2UdFEL3A98sT6SFc4JpPWOZRzQPuOx/2aAxugn6gw/X2k1bguKIX t+Tg==
X-Gm-Message-State: AJaThX65D5cpFP8Hu2kS/kPexgV8sp6Q5dlVa/GbJKs+hG5sD79rW0c9 wRJrQhWWYkFs0WTSqciDfJa5dmTmNUNgmGZpJWvn03TX
X-Google-Smtp-Source: AGs4zMbIYxrpXf06JJkE7vzYssmv+/rQkTvrzeyYEBogPhTr07txlkXZem6jzq8Pt+UaC4MpO5IrWsyGTeRD7bfY1Pc=
X-Received: by 10.129.241.10 with SMTP id h10mr7244989ywm.141.1511343452966; Wed, 22 Nov 2017 01:37:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.4.194 with HTTP; Wed, 22 Nov 2017 01:37:11 -0800 (PST)
In-Reply-To: <5A14A9A1.5020803@foobar.org>
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>   <649be36e-5006-7688-448f-bc2794d6a39c@gmail.com>  <5A119443.2030108@foobar.org>    <5A12FBE4.9030101@foobar.org>  <5A144A78.6060108@foobar.org>  <5A14A9A1.5020803@foobar.org>
From: Lorenzo Colitti 
Date: Wed, 22 Nov 2017 18:37:11 +0900
Message-ID: 
Subject: Re: problem statement [was Re: New Version Notification for draft-hinden-ipv4flag-00.txt]
To: Nick Hilliard 
Cc: IETF IPv6 Mailing List 
Content-Type: multipart/alternative; boundary="089e08329e48a68ab7055e8f116f"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 09:37:35 -0000

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

On Wed, Nov 22, 2017 at 7:33 AM, Nick Hilliard  wrote:

> > On Wed, Nov 22, 2017 at 12:47 AM, Nick Hilliard  wrote:
> > > There would also be a requirement
> > > for the network edge to be able to filter out RAs with this option,
> >
> > Why is it not sufficient to configure the routers that emit the RAs?
>
> because you're assuming congruity between ipv4 and ipv6 connectivity on
> a network, which is not codified in any ietf document that I'm aware of.
>  If there is a incongruity between management of the two protocols, then
> the l2 network must have a mechanism to stop an ipv6 gateway from
> attempting shutting down ipv4 services.
>

I don't get it. That's a configuration error. If the operator misconfigures
the network, then the network doesn't work.

Sure, the proposed solution won't work when IPv4 and IPv6 are managed by
different operators. That doesn't seem like a big drawback, since this
situation is quite rare.

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


On W=
ed, Nov 22, 2017 at 7:33 AM, Nick Hilliard <nick@foobar.org> w=
rote:
> On Wed, Nov 2=
2, 2017 at 12:47 AM, Nick Hilliard <n=
ick@foobar.org> wrote:

> > There would also be a requirement

> > for the network edge to be able to filter out RAs with this optio=
n,

>

> Why is it not sufficient to configure the routers that emit the RAs?


because you're assuming congruity between ipv4 and ipv6 connecti=
vity on

a network, which is not codified in any ietf document that I'm aware of=
.

=C2=A0If there is a incongruity between management of the two protocols, th=
en

the l2 network must have a mechanism to stop an ipv6 gateway from

attempting shutting down ipv4 services.

I don't get it. That's a configuration error. If the operator misc=
onfigures the network, then the network doesn't work.

Sure, the proposed solution won't work when IPv4 and IPv6 are m=
anaged by different operators. That doesn't seem like a big drawback, s=
ince this situation is quite rare.


--089e08329e48a68ab7055e8f116f--


From nobody Wed Nov 22 05:53:06 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497BF129449 for ; Wed, 22 Nov 2017 05:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 17tK3KEADzRM for ; Wed, 22 Nov 2017 05:53:03 -0800 (PST)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C18212944E for ; Wed, 22 Nov 2017 05:52:56 -0800 (PST)
Received: by mail-yb0-x22a.google.com with SMTP id n185so5649723yba.6 for ; Wed, 22 Nov 2017 05:52:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9oYMlepPONEfSFWlP4xXDRMz6SREAjadRkXOFWz1iBI=; b=FfrPraUe3C9wUK4f4LWgfzuskj6FxwILqnkNkgVrAnt5qn2VFFZjP5e7xFTtsDwQKk mztst3ka4V+whDLkDrNxK7RX86a9W/XoVq31aWarBrtKB5hV1JvU2iZjmOvrlCXKJCNe ygz9ROL6ZDvFIHTgBSk9aTMoCoTv7iDHunJYCIs0Jiwqexc6Xl+DBO0vdHBQGbkLOLZg bZ68CPKwITeASDtysDbMed+gkA/YcTAm03ze8kXf/lMi/lAN58WzC5JT0XHMnC5c0yW9 8R/vPbU2RRRvchGRbwZWZkmHYb5AbtKJ7ZVO/8UJAKUsxksr/WLnMchDhYZSb2EOP4/X iidw==
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=9oYMlepPONEfSFWlP4xXDRMz6SREAjadRkXOFWz1iBI=; b=Jaqx0DMjqiqKaNkqoQnOZHJBbGGl9bevwcvPeUkV3fOor7GkH3fQiaV5mbKe1IFcm5 XBE9kmjLPvBoEzMGKD44WiQLPwR+HQSCK47MyfL2DkAHO1djueDF9+TSIhSycDll0TPH WIN1DPHjh8wU5irugkrxVTlr1xqG9YENcP3IGpCfXewXNMXAAtkS58GJapHNpKnNcT1J VL+bOdLReMs+zXaE8FTL63Gp5o8QgJ2rL4B9Tf40NtWcIDPudfMm7FX0KShL2dxkgACl wvZVhrEnlQFlweQEOWzOd77LD8494/1tZ04BBIvyXoaBmJDdS7YoG+jX4Bk+J1nmh9Nj E68w==
X-Gm-Message-State: AJaThX4RSJd4cTOK6tsQghTqPq+p08eJ1aWzlZ2Mc8vWhgkNUVDQvNjn N4sLnVr6dThMd3+2Q6aPNr76qtSsrELa+kb30qLwsg==
X-Google-Smtp-Source: AGs4zMa9j6F5P6HUjeA62y/D98p6BpbUxUM2kGuD1QGDFTR9vV0atY0Ut4w7C64oxgdcODgPhvHmW1YWOwMUOVDlR6Q=
X-Received: by 10.37.179.66 with SMTP id k2mr12787826ybg.53.1511358775699; Wed, 22 Nov 2017 05:52:55 -0800 (PST)
MIME-Version: 1.0
References:   <787AE7BB302AE849A7480A190F8B93300A07AD68@OPEXCLILMA3.corporate.adroot.infra.ftgroup>  <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no> <0a13ea07-6b60-9ae6-659e-c054acdc156d@gmail.com> <2bbae231-d57e-4ba7-8ac5-65dbba9a9da2@gmail.com>
In-Reply-To: <2bbae231-d57e-4ba7-8ac5-65dbba9a9da2@gmail.com>
From: Ca By 
Date: Wed, 22 Nov 2017 13:52:44 +0000
Message-ID: 
Subject: Re: IPv6 only host NAT64 requirements?
To: Alexandre Petrescu 
Cc: ipv6@ietf.org
Content-Type: multipart/alternative; boundary="f403045e317af43103055e92a284"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 13:53:05 -0000

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

On Wed, Nov 22, 2017 at 12:05 AM Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

>
>
> Le 22/11/2017 =C3=A0 01:01, Brian E Carpenter a =C3=A9crit :
> > in line...
> >
> > On 21/11/2017 22:40, Ola Thoresen wrote:
> >> On 20. nov. 2017 20:37, Brian E Carpenter wrote:
> >>
> >>> On 21/11/2017 02:36, Ole Troan wrote:
> >>> ...>> [Med] These are generic statements, Ole. We are talking about
> the IETF case.
> >>>>> * The IETF has no control on the hosts that connect to the IETF
> network,
> >>>>> * IETF attendees who are using corporate devices, have no control o=
n
> these hosts
> >>>>>
> >>>>> So, how forcing devices to use "IPv6+nat64" will help here?
> >>>> Eat own dogfood. Many IETF people are developers or work for
> companies having applications not working.
> >>>> As I said there were a minimum of applications that didn't work.
> Corporate VPNs largely did. Jen has the final numbers.
> >>> However, as long as even one application, such as one VPN, or one
> >>> literal IPv4 address, fails, that represents millions of failure case=
s
> >>> if we consider the whole world (e.g. imagine every hotel network in
> >>> the world running IPv6+NAT64 only). That simply isn't viable. Dual
> >>> stack in every hotel room in the world is viable, from the hotel
> guests'
> >>> point of view. Operators might not like it, but users wouldn't care.
> >>
> >> In hotel rooms and other "public" or "guest" networks, there are so ma=
ny
> >> things that fail already, due to NAT, misconfigured firewalls,
> >> unmaintained blocklists, SSL-proxies and whatnot, so you can hardly
> >> expect any services other than basic web-surfing without https to work=
.
> >> Not that this is an ideal situation today, but i do not believe that "=
if
> >> even one VPN or one liter IPv4 address fails" should be a showstopper
> >> for introducing this.
> >
> > Hotels won't make that choice, but the providers of hotel networks will=
,
> > entirely based on their perception of the number of help desk calls
> > they will have to handle for any given change. Since they haven't even
> > made the move from IPv4 to dual stack, I think we'll wait a long time
> > before they attempt any form of IPv6-only. Sad but true.
> >
> >> Possibly, or even probably, introducing IPv6 (-only and NAT64) will ev=
en
> >> make the situation better for a lot of people, as you get rid of all t=
he
> >> horrible NAT solutions for services that are already dual stacked.
> >
> > But those horrible NAT solutions are up and running today.
>
> It will be noticed that on NAT64 ESSID the experience is worse than on
> IPv4, at least for VPN sessions.
>


How would the vpn service be improved? If the VPN server / peer was ipv6
enabled then it would just be e2e v6, no?

I like to refer back to Occam=E2=80=99s Razor e2e v6 rather than transition=
 Rube
Goldberg


> Alex
>
>   For this
> > class of operator, any change is bad news, unfortunately. What is their
> > incentive to make such a change?
> >
> >      Brian
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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



On Wed, Nov 22, 2017 =
at 12:05 AM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:




Le 22/11/2017 =C3=A0 01:01, Brian E Carpenter a =C3=A9crit=C2=A0:

> in line...

>

> On 21/11/2017 22:40, Ola Thoresen wrote:

>> On 20. nov. 2017 20:37, Brian E Carpenter wrote:

>>

>>> On 21/11/2017 02:36, Ole Troan wrote:

>>> ...>> [Med] These are generic statements, Ole. We are ta=
lking about the IETF case.

>>>>> * The IETF has no control on the hosts that connect to=
 the IETF network,

>>>>> * IETF attendees who are using corporate devices, have=
 no control on these hosts

>>>>>

>>>>> So, how forcing devices to use "IPv6+nat64" =
will help here?

>>>> Eat own dogfood. Many IETF people are developers or work f=
or companies having applications not working.

>>>> As I said there were a minimum of applications that didn&#=
39;t work. Corporate VPNs largely did. Jen has the final numbers.

>>> However, as long as even one application, such as one VPN, or =
one

>>> literal IPv4 address, fails, that represents millions of failu=
re cases

>>> if we consider the whole world (e.g. imagine every hotel netwo=
rk in

>>> the world running IPv6+NAT64 only). That simply isn't viab=
le. Dual

>>> stack in every hotel room in the world is viable, from the hot=
el guests'

>>> point of view. Operators might not like it, but users wouldn&#=
39;t care.

>>

>> In hotel rooms and other "public" or "guest" n=
etworks, there are so many

>> things that fail already, due to NAT, misconfigured firewalls,

>> unmaintained blocklists, SSL-proxies and whatnot, so you can hardl=
y

>> expect any services other than basic web-surfing without https to =
work.

>> Not that this is an ideal situation today, but i do not believe th=
at "if

>> even one VPN or one liter IPv4 address fails" should be a sho=
wstopper

>> for introducing this.

>

> Hotels won't make that choice, but the providers of hotel networks=
 will,

> entirely based on their perception of the number of help desk calls
> they will have to handle for any given change. Since they haven't =
even

> made the move from IPv4 to dual stack, I think we'll wait a long t=
ime

> before they attempt any form of IPv6-only. Sad but true.

>

>> Possibly, or even probably, introducing IPv6 (-only and NAT64) wil=
l even

>> make the situation better for a lot of people, as you get rid of a=
ll the

>> horrible NAT solutions for services that are already dual stacked.=


>

> But those horrible NAT solutions are up and running today.



It will be noticed that on NAT64 ESSID the experience is worse than on

IPv4, at least for VPN sessions.




How would the vpn service be improved? If the VPN server / peer=
 was ipv6 enabled then it would just be e2e v6, no?
=

I like to refer back to Occam=E2=80=99s Razor e=
2e v6 rather than transition Rube Goldberg=C2=A0


Alex



=C2=A0 For this

> class of operator, any change is bad news, unfortunately. What is thei=
r

> incentive to make such a change?

>

>=C2=A0 =C2=A0 =C2=A0 Brian

>

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list

> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman=
/listinfo/ipv6

> --------------------------------------------------------------------
>



--------------------------------------------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/list=
info/ipv6

--------------------------------------------------------------------




--f403045e317af43103055e92a284--


From nobody Wed Nov 22 07:25:42 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C2412944C; Wed, 22 Nov 2017 07:25:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.184
X-Spam-Level: 
X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LONGWORDS=2.035, 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 bvXQjwLdYmJE; Wed, 22 Nov 2017 07:25:32 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5289612940E; Wed, 22 Nov 2017 07:25:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAMFPVTK042154; Wed, 22 Nov 2017 08:25:31 -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 vAMFPLYc041974 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 22 Nov 2017 08:25: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; Wed, 22 Nov 2017 07:25:20 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 22 Nov 2017 07:25:20 -0800
From: "Templin, Fred L" 
To: Mark Smith , Sander Steffann 
CC: "dhcwg@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>
Subject: RE: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgBHE5fNABDBcvA=
Date: Wed, 22 Nov 2017 15:25:20 +0000
Message-ID: <8593f50c724f4cbaa549c7cd6e6b91c0@XCH15-06-08.nw.nos.boeing.com>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com> <7F30D7F6-7859-4D2B-B550-8C8CB944FF9F@steffann.nl> 
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_8593f50c724f4cbaa549c7cd6e6b91c0XCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 15:25:35 -0000

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

SGkgTWFyaywNCg0KVGhlIHJvdXRlciBkb2VzbuKAmXQgbmVlZCB0byBpbXBsZW1lbnQgREhDUHY2
IHNlcnZlcjsgaXQgY2FuIGltcGxlbWVudCBESENQdjYNCnJlbGF5LCBvciBpdCBjYW4gbm90IGlt
cGxlbWVudCBESENQdjYgYXQgYWxsIGFuZCBpdCB3aWxsIGNvbnRpbnVlIHRvIHdvcmsgdGhlIHdh
eSBpdA0KYWx3YXlzIGhhcy4NCg0KWW91ciBhcmd1bWVudCBhYm91dCAgaGF2aW5nIHRvIHVwZGF0
ZSByb3V0ZXIgZmlybXdhcmUgd2hlbiBhIG5ldyBESENQdjYNCm9wdGlvbiBpcyBzcGVjaWZpZWQg
aXMgbm8gZGlmZmVyZW50IHRoYW4gdGhlIGNhc2Ugd2hlbiBhIG5ldyBJUHY2IE5EIG9wdGlvbiBp
cw0Kc3BlY2lmaWVkIOKAkyBib3RoIGFyZSBhcHBsaWNhdGlvbnMsIGFuZCB1cGRhdGVzIHRvIGVp
dGhlciB3b3VsZCBuZWVkIHRvIGJlDQphY2NvbW1vZGF0ZWQuIFdpdGggdGhpcyBwcm9wb3NhbCwg
d2UgZ2V0IGEgdW5pZmllZCBzdGF0ZWxlc3Mvc3RhdGVmdWwgc2VydmljZQ0KdGhhdCBjYW4gbmF0
aXZlbHkgaGFuZGxlIGFsbCBJUHY2IGF1dG9jb25maWd1cmF0aW9uIHNlcnZpY2VzIG5vdyBhbmQg
aW50byB0aGUNCmZ1dHVyZS4NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBNYXJrIFNtaXRoIFtt
YWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDIx
LCAyMDE3IDExOjE5IFBNDQpUbzogU2FuZGVyIFN0ZWZmYW5uIDxzYW5kZXJAc3RlZmZhbm4ubmw+
DQpDYzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPjsgZGhjd2dA
aWV0Zi5vcmc7IHY2b3BzQGlldGYub3JnOyA2bWFuQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2
b3BzXSBDb21iaW5pbmcgSVB2NiBORCBhbmQgREhDUHY2IGludG8gYSBzaW5nbGUsIHVuaWZpZWQg
ZnVuY3Rpb24NCg0KDQoNCk9uIDIxIE5vdi4gMjAxNyAxMDozNCBhbSwgIlNhbmRlciBTdGVmZmFu
biIgPHNhbmRlckBzdGVmZmFubi5ubDxtYWlsdG86c2FuZGVyQHN0ZWZmYW5uLm5sPj4gd3JvdGU6
DQpIaSwNCg0KPiBUaGlzIGRvY3VtZW50IHRoZXJlZm9yZSBwcm9wb3NlcyBhIHVuaWZpY2F0aW9u
IG9mIElQdjYgTkQgYW5kIERIQ1B2NiB3aGVyZQ0KPiB0aGUgdHdvIGZ1bmN0aW9ucyB3b3JrIHRv
Z2V0aGVyIGFzIGlmIHRoZXkgd2VyZSBvbmUuIFRoaXMgaXMgYWNjb21tb2RhdGVkIGJ5DQo+IGEg
bmV3IElQdjYgTkQgb3B0aW9uIGluIFJTL1JBIG1lc3NhZ2VzIGNhbGxlZCB0aGUgIkRIQ1B2NiBv
cHRpb24iLiBCeSB3b3JraW5nDQo+IHRvZ2V0aGVyIGFzIG9uZSBmdW5jdGlvbiwgSVB2NiBORCBh
bmQgREhDUHY2IGNhbiBzdXBwbHkgcmVxdWVzdGluZyBub2RlcyB3aXRoDQo+IGFsbCBsaW5rLXNw
ZWNpZmljIGF1dG9jb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGFuZCBhbnkgbWFuYWdlZCBhZGRy
ZXNzL3ByZWZpeA0KPiBkZWxlZ2F0aW9ucyBpbiBhIHNpbmdsZSByb3VuZCB0cmlwIG1lc3NhZ2Ug
ZXhjaGFuZ2UuDQpJbnRlcmVzdGluZyB3YXkgb2YgZG9pbmcgdGhpcy4gSSBoYXZlIHRob3VnaHQg
YWJvdXQgY29tYmluaW5nIE5EIGFuZCBESENQdjYgYmVmb3JlLCBidXQgbW9yZSBhcyBhIGRpZmZl
cmVudCBkaXN0cmlidXRpb24gbWVjaGFuaXNtOiBORCBmb3IgcHVzaGluZyBvcHRpb25zIHRvIGFs
bCBjbGllbnRzIG9uIHRoZSBuZXR3b3JrLA0KDQpTbyBob3cgb2Z0ZW4gZG8geW91IHdhbnQgdG8g
dXBncmFkZSByb3V0ZXIgZmlybXdhcmU/IEV2ZXJ5dGltZSB5b3Ugd2FudCB0byBkZXBsb3kgYW4g
YXBwbGljYXRpb24gdGhhdCB1c2VzIGEgbmV3IERIQ1BWNiBvcHRpb24/DQoNCldoYXQgZG8geW91
IGRvIHdoZW4gdGhlIHJvdXRlciB2ZW5kb3Igc2F5cywgIndlJ3JlIG5ldmVyIGdvaW5nIHRvIGlt
cGxlbWVudCB0aGF0IG5ldyBESENQVjYgb3B0aW9uIGluIHRoYXQgcm91dGVyIG1vZGVsLCB3ZSBk
b24ndCBoYXZlIGVub3VnaCBjdXN0b21lcnMgYW55IG1vcmUgZm9yIHRoYXQgbW9kZWwgdG8ganVz
dGlmeSBhbGwgdGhlIGRldmVsb3BtZW50IGFuZCB0ZXN0aW5nIHRpbWUiLiBOZXZlciBkZXBsb3kg
dGhlIGFwcGxpY2F0aW9uPw0KDQpXaGF0IGRvIHlvdSBkbyBpZiB0aGUgcm91dGVyIGJlZm9yZSBz
YXlzLCAidGhhdCBESENQdjYgb3B0aW9uIGlzIG9uIG91ciBpbXBsZW1lbnRhdGlvbiByb2FkIG1h
cCwgd2UncmUgZXhwZWN0aW5nIHRvIGltcGxlbWVudCBpdCBpbiA2IG1vbnRocyB0aW1lLiI/IFdh
aXQgc2l4IG1vbnRocyBiZWZvcmUgeW91IGRlcGxveSB0aGUgYXBwbGljYXRpb24/DQoNClB1c2hp
bmcgbGF5ZXIgNCsgY29uZmlndXJhdGlvbiBvcHRpb25zIGludG8gTkQgY3JlYXRlcyBhIGRlcGVu
ZGVuY3kgb24gcm91dGVyIGZpcm13YXJlIGZvciBhcHBsaWNhdGlvbiBkZXBsb3ltZW50IHRoYXQg
ZG9lc24ndCBleGlzdCB0b2RheSBpbiBlaXRoZXIgTkQgb3IgREhDUFY2Lg0KDQpBbm90aGVyIGV4
YW1wbGUgb2YgdGhpcyB0cmFwLiBSZW1lbWJlciB0aGF0IE5UUCBhbXBsaWZpY2F0aW9uIERvUyBm
cm9tIDMgb3IgNCB5ZWFycyBhZ28/IE9uZSBwbGFjZSBJJ20gYXdhcmUgb2Ygd2VyZSB1c2luZyB0
aGVpciBQRSByb3V0ZXJzIHRvIGFsc28gcHJvdmlkZSBjdXN0b21lcnMgd2l0aCBOVFAgdGltZSwg
YW5kIHRoZSByb3V0ZXIgaW1wbGVtZW50YXRpb24gd2FzIHZ1bG5lcmFibGUuIEZyb20gbWVtb3J5
LCB0aGUgdmVuZG9yIHRvb2sgYXJvdW5kIGEgd2VlayB0byByZWxlYXNlIGEgZml4LiBUaGVuIHRo
ZSBuZXh0IDYgdG8gOCB3ZWVrcyB3ZXJlIHNwZW50IG9yZ2FuaXNpbmcgaGlnaCBpbXBhY3QgY2hh
bmdlIGNvbnRyb2xzIGJlY2F1c2Ugcm91dGVyIGZpcm13YXJlIHVwZ3JhZGVzIGVpdGhlciByZXF1
aXJlZCByZWJvb3RzIG9yIHRoZXJlIHdhcyBhIGhhemFyZCBvZiBvbmUuIFRoZSBudW1iZXIgb2Yg
UEUgcm91dGVycyB3YXMgaW4gdGhlIDEwcywgaW1hZ2luZSB0aW1lIGFuZCBlZmZvcnQsIGFuZCB2
dWxuZXJhYmlsaXR5IGV4cG9zdXJlIHRpbWUgaWYgdGhlcmUgd2VyZSAxMDBzIG9yIDEwMDBzIG9m
IFBFIHJvdXRlcnMgcHJvdmlkaW5nIE5UUCB0aW1lIHRvIGN1c3RvbWVycy4NCg0KQ29tcGFyZSB0
aGF0IHRvIGlmIHRoZSBOVFAgc2VydmljZS9hcHBsaWNhdGlvbiB3YXMgbm90ICJpbiIgdGhlIG5l
dHdvcmssIG5vdCAiaW4iIHRoZSByb3V0ZXJzJyBjb250cm9sIHBsYW5lcywgYW5kIGFzIHNlcnZp
Y2UgcmVhY2hhYmxlIG92ZXIgdGhlIG5ldHdvcmsuIE9ubHkgcGF0Y2hlcyB0byB0aGUgTlRQIHNl
cnZlcnMgd291bGQgaGF2ZSBiZWVuIG5lY2Vzc2FyeSwgYW5kIHRoZXJlIHdvdWxkIGhhdmUgYmVl
biBmYXIgZmV3ZXIgb2YgdGhvc2UuDQoNCg0KDQoNCmFuZCBESENQdjYgZm9yIGNsaWVudHMgcmVx
dWVzdGluZyBzcGVjaWZpYyBvcHRpb25zIGZvciB0aGVtc2VsdmVzLiBKdXN0IHRvIG1ha2UgaXQg
cG9zc2libGUgdG8gdXNlIGJvdGggbWVjaGFuaXNtcyBmb3IgYWxsIG9wdGlvbnMgKE1BUC9EU0xp
dGUvZXRjIG9wdGlvbnMgaW4gUkEgd291bGQgYmUgbmljZSkuDQoNCldoYXQgeW91IGFyZSBkb2lu
ZyBpcyBhbm90aGVyIHdheSBvZiBsb29raW5nIGF0IGl0LiBJZiBJIHVuZGVyc3RhbmQgY29ycmVj
dGx5IHlvdSdyZSBiYXNpY2FsbHkga2VlcGluZyB0aGUgZnVsbCBmdW5jdGlvbmFsaXR5IG9mIERI
Q1B2NiBidXQgdXNpbmcgUlMvUkEgYXMgYSB0cmFuc3BvcnQgaW5zdGVhZCBvZiBVRFAuIEkgd29u
ZGVyIHdoYXQgdGhlIHNwZWVkIGJlbmVmaXQgb2YgdGhhdCB3b3VsZCBiZSBpbiBwcmFjdGljZS4g
QWxzbyBjb21wYXJlZCB0byAiaW1wYXRpZW50IiBzeXN0ZW1zIHRoYXQgc2VuZCBvdXQgREhDUHY2
IGEgcmVxdWVzdCBiZWZvcmUgZXZlbiByZWNlaXZpbmcgYW4gUkEuDQoNCj4gSSB3b3VsZCBhc2sg
dGhlc2UgZGlzY3Vzc2lvbiBsaXN0cyB0byBjb25zaWRlciB3aGF0IGlzIGl0IHRoYXQgeW91IHJl
YWxseSBkb24ndA0KPiBsaWtlIGFib3V0IERIQ1B2Ni4gTWF5YmUgeW91IHRoaW5rIGl0IGlzIHVn
bHkuIE1heWJlIHlvdSBkb24ndCBsaWtlIHRoZSB3YXkNCj4gdGhlIGFjcm9ueW0gcm9sbHMgb2Zm
IHlvdXIgdG9uZ3VlIHdoZW4geW91IHNwZWFrIGl0LiBNYXliZSBpdCBoYXMgYW4gb25lcm91cw0K
PiBzdGlnbWEgb2YgYmVpbmcgc3RhdGVmdWwuIEJ1dCwgdGhlbiBJIHdvdWxkIGFsc28gYXNrIHlv
dSB0byBjb25zaWRlciB3aGF0IGENCj4gcmVwbGFjZW1lbnQgd291bGQgbG9vayBsaWtlLiBCZWNh
dXNlLCBJIHRoaW5rIGFueSBzdWl0YWJsZSByZXBsYWNlbWVudA0KPiB3b3VsZCBoYXZlIHRvIGVz
c2VudGlhbGx5IGR1cGxpY2F0ZSB3aGF0IERIQ1B2NiBhbHJlYWR5IGRvZXMuDQpJbiBteSBvcGlu
aW9uIERIQ1B2NiBpcyBmaW5lLiBJIGltcGxlbWVudGVkIGEgc2VydmVyIGFuZCBpdCBpcyBhICps
b3QqIGNsZWFuZXIgdG8gaW1wbGVtZW50IHRoYW4gREhDUHY0LiBKdXN0IHBsYWluIFVEUCBvbiBs
aW5rLWxvY2FsIGFuZCBtdWx0aWNhc3Qgc29ja2V0cyA6KSAgRXNwZWNpYWxseSB0aGUgc3RhdGVs
ZXNzIHZlcnNpb24gaXMgdmVyeSBlYXN5IHRvIGltcGxlbWVudC4gSXQncyBub3QgdGhlIHVsdGlt
YXRlIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wsIGFuZCBmb3IgY2VydGFpbiB0aGluZ3MgZGlzdHJp
YnV0aW5nIGluZm9ybWF0aW9uIHZpYSBSQSBpcyBhIG11Y2ggYmV0dGVyIGZpdCB0byB0aGUgd2F5
IHRoZSBuZXR3b3JrIGlzIHJ1bi4gQnV0IERIQ1B2NiBoYXMgaXRzIHBsYWNlIGFuZCBpdHMgcm9s
ZSwgYW5kIGluIGNlcnRhaW4gZW52aXJvbm1lbnRzIChESENQdjYtUEQgaW4gSVNQIG5ldHdvcmtz
LCBESENQdjYgaW4gZW50ZXJwcmlzZSBldGMpIGl0IGRvZXMgd2hhdCB0aGUgbmV0d29yayBhbmQg
c3lzdGVtIG9wZXJhdG9ycyBuZWVkLg0KDQpUaGUgbWFpbiBwcm9ibGVtIHdpdGggREhDUHY2IGFz
IGFuIG9wZXJhdG9yIGhhcyBiZWVuIGRlYWxpbmcgd2l0aCBEVUlEcyB3aGVuIHRoZSBsaW5rLWxh
eWVyIGFkZHJlc3MgaW4gdGhlIERVSUQgaXMgYmFzZWQgb24gYSBkaWZmZXJlbnQgaW50ZXJmYWNl
IHRoYW4gdGhlIGludGVyZmFjZSBzZW5kaW5nIHRoZSBESENQdjYgcmVxdWVzdC4gTW9zdGx5IGJl
Y2F1c2UgdGhlIHJlcXVlc3RpbmcgaW50ZXJmYWNlJ3MgTUFDIGFkZHJlc3MgaGFzIGFsd2F5cyBi
ZWVuIHVzZWQgd2l0aCBESENQdjQgYW5kIGlzIG9mdGVuIHByaW50ZWQgb24gdGhlIG91dHNpZGUg
b2YgdGhlIGRldmljZS4gQnV0IHRoZXNlIGRheXMgTERSQSBhbmQgREhDUHY2IHJlbGF5cyBjYW4g
dGVsbCB0aGUgREhDUHY2IHNlcnZlciB3aGF0IHRoZSBNQUMgYWRkcmVzcyBvZiB0aGUgcmVxdWVz
dGluZyBpbnRlcmZhY2Ugd2FzLCBhbmQgd2UgY2FuIHVzZSB0aGF0IHRvIGlkZW50aWZ5IHRoZSBj
bGllbnQgKGluIGFkZGl0aW9uIHRvIGl0cyBEVUlEKS4gV2l0aCB2ZW5kb3JzIHN0YXJ0aW5nIHRv
IGltcGxlbWVudCB0aGlzIHJlbGF5IG9wdGlvbiB0aGlzIGlzIG1vc3RseSBhIHNvbHZlZCBwcm9i
bGVtIG5vdy4NCg0KQW5vdGhlciB0aGluZyB0aGF0IG1ha2VzIG1lIGEgYml0IHNhZCBpcyB0aGUg
bGFjayBvZiBESENQdjYgcmVjb25maWd1cmUgc3VwcG9ydC4gVGhhdCBjb3VsZCBiZSB1c2VkIHRv
IHRha2UgYXdheSBzb21lIG9mIHRoZSBjb21wbGFpbnRzIGFnYWluc3QgREhDUHY2IChhbmQgYW55
IGNsaWVudC1pbml0aWF0ZWQgY29uZmlndXJhdGlvbiBwcm90b2NvbCkgdGhhdCB0aGVyZSBpcyBu
byB3YXkgZm9yIHRoZSBuZXR3b3JrIHRvIGluZm9ybSB0aGUgY2xpZW50IG9mIGNoYW5nZXMuDQoN
Ckkgc2VlIG5vIG5lZWQgdG8gcmVwbGFjZSBpdCB3aXRoIHNvbWV0aGluZyBlbHNlIHRoYXQgd291
bGQgaW5kZWVkIG5lZWQgdG8gZHVwbGljYXRlIGl0cyBmdW5jdGlvbmFsaXR5Lg0KDQpDaGVlcnMs
DQpTYW5kZXINCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcg
bGlzdA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZl
IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQoNCg==

--_000_8593f50c724f4cbaa549c7cd6e6b91c0XCH150608nwnosboeingcom_
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
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIE1hcmssPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgcm91dGVyIGRvZXNu4oCZdCBuZWVkIHRvIGlt
cGxlbWVudCBESENQdjYgc2VydmVyOyBpdCBjYW4gaW1wbGVtZW50IERIQ1B2NjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5yZWxheSwgb3IgaXQgY2FuIG5vdCBpbXBsZW1lbnQgREhDUHY2IGF0IGFsbCBhbmQg
aXQgd2lsbCBjb250aW51ZSB0byB3b3JrIHRoZSB3YXkgaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YWx3
YXlzIGhhcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPllvdXIg
YXJndW1lbnQgYWJvdXQgJm5ic3A7aGF2aW5nIHRvIHVwZGF0ZSByb3V0ZXIgZmlybXdhcmUgd2hl
biBhIG5ldyBESENQdjY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+b3B0aW9uIGlzIHNwZWNpZmllZCBpcyBu
byBkaWZmZXJlbnQgdGhhbiB0aGUgY2FzZSB3aGVuIGEgbmV3IElQdjYgTkQgb3B0aW9uIGlzPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPnNwZWNpZmllZCDigJMgYm90aCBhcmUgYXBwbGljYXRpb25zLCBhbmQg
dXBkYXRlcyB0byBlaXRoZXIgd291bGQgbmVlZCB0byBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hY2Nv
bW1vZGF0ZWQuIFdpdGggdGhpcyBwcm9wb3NhbCwgd2UgZ2V0IGEgdW5pZmllZCBzdGF0ZWxlc3Mv
c3RhdGVmdWwgc2VydmljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGF0IGNhbiBuYXRpdmVseSBoYW5k
bGUgYWxsIElQdjYgYXV0b2NvbmZpZ3VyYXRpb24gc2VydmljZXMgbm93IGFuZCBpbnRvIHRoZTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj5mdXR1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWFyayBTbWl0aCBbbWFpbHRvOm1h
cmt6enpzbWl0aEBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1i
ZXIgMjEsIDIwMTcgMTE6MTkgUE08YnI+DQo8Yj5Ubzo8L2I+IFNhbmRlciBTdGVmZmFubiAmbHQ7
c2FuZGVyQHN0ZWZmYW5uLm5sJmd0Ozxicj4NCjxiPkNjOjwvYj4gVGVtcGxpbiwgRnJlZCBMICZs
dDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0OzsgZGhjd2dAaWV0Zi5vcmc7IHY2b3BzQGll
dGYub3JnOyA2bWFuQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIENv
bWJpbmluZyBJUHY2IE5EIGFuZCBESENQdjYgaW50byBhIHNpbmdsZSwgdW5pZmllZCBmdW5jdGlv
bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjEg
Tm92LiAyMDE3IDEwOjM0IGFtLCAmcXVvdDtTYW5kZXIgU3RlZmZhbm4mcXVvdDsgJmx0OzxhIGhy
ZWY9Im1haWx0bzpzYW5kZXJAc3RlZmZhbm4ubmwiPnNhbmRlckBzdGVmZmFubi5ubDwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt
YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KJmd0OyBUaGlzIGRvY3VtZW50IHRoZXJlZm9yZSBw
cm9wb3NlcyBhIHVuaWZpY2F0aW9uIG9mIElQdjYgTkQgYW5kIERIQ1B2NiB3aGVyZTxicj4NCiZn
dDsgdGhlIHR3byBmdW5jdGlvbnMgd29yayB0b2dldGhlciBhcyBpZiB0aGV5IHdlcmUgb25lLiBU
aGlzIGlzIGFjY29tbW9kYXRlZCBieTxicj4NCiZndDsgYSBuZXcgSVB2NiBORCBvcHRpb24gaW4g
UlMvUkEgbWVzc2FnZXMgY2FsbGVkIHRoZSAmcXVvdDtESENQdjYgb3B0aW9uJnF1b3Q7LiBCeSB3
b3JraW5nPGJyPg0KJmd0OyB0b2dldGhlciBhcyBvbmUgZnVuY3Rpb24sIElQdjYgTkQgYW5kIERI
Q1B2NiBjYW4gc3VwcGx5IHJlcXVlc3Rpbmcgbm9kZXMgd2l0aDxicj4NCiZndDsgYWxsIGxpbmst
c3BlY2lmaWMgYXV0b2NvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gYW5kIGFueSBtYW5hZ2VkIGFk
ZHJlc3MvcHJlZml4PGJyPg0KJmd0OyBkZWxlZ2F0aW9ucyBpbiBhIHNpbmdsZSByb3VuZCB0cmlw
IG1lc3NhZ2UgZXhjaGFuZ2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPkludGVyZXN0aW5nIHdheSBvZiBkb2luZyB0aGlzLiBJIGhhdmUgdGhvdWdodCBhYm91
dCBjb21iaW5pbmcgTkQgYW5kIERIQ1B2NiBiZWZvcmUsIGJ1dCBtb3JlIGFzIGEgZGlmZmVyZW50
IGRpc3RyaWJ1dGlvbiBtZWNoYW5pc206IE5EIGZvciBwdXNoaW5nIG9wdGlvbnMgdG8gYWxsIGNs
aWVudHMgb24gdGhlIG5ldHdvcmssPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBob3cg
b2Z0ZW4gZG8geW91IHdhbnQgdG8gdXBncmFkZSByb3V0ZXIgZmlybXdhcmU/IEV2ZXJ5dGltZSB5
b3Ugd2FudCB0byBkZXBsb3kgYW4gYXBwbGljYXRpb24gdGhhdCB1c2VzIGEgbmV3IERIQ1BWNiBv
cHRpb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPldoYXQgZG8geW91IGRvIHdoZW4gdGhlIHJvdXRlciB2ZW5kb3Igc2F5cywgJnF1b3Q7d2Un
cmUgbmV2ZXIgZ29pbmcgdG8gaW1wbGVtZW50IHRoYXQgbmV3IERIQ1BWNiBvcHRpb24gaW4gdGhh
dCByb3V0ZXIgbW9kZWwsIHdlIGRvbid0IGhhdmUgZW5vdWdoIGN1c3RvbWVycyBhbnkgbW9yZSBm
b3IgdGhhdCBtb2RlbCB0byBqdXN0aWZ5IGFsbCB0aGUgZGV2ZWxvcG1lbnQgYW5kIHRlc3Rpbmcg
dGltZSZxdW90Oy4gTmV2ZXIgZGVwbG95DQogdGhlIGFwcGxpY2F0aW9uPzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGRvIHlvdSBkbyBp
ZiB0aGUgcm91dGVyIGJlZm9yZSBzYXlzLCAmcXVvdDt0aGF0IERIQ1B2NiBvcHRpb24gaXMgb24g
b3VyIGltcGxlbWVudGF0aW9uIHJvYWQgbWFwLCB3ZSdyZSBleHBlY3RpbmcgdG8gaW1wbGVtZW50
IGl0IGluIDYgbW9udGhzIHRpbWUuJnF1b3Q7PyBXYWl0IHNpeCBtb250aHMgYmVmb3JlIHlvdSBk
ZXBsb3kgdGhlIGFwcGxpY2F0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5QdXNoaW5nIGxheWVyIDQmIzQzOyBjb25maWd1cmF0aW9uIG9w
dGlvbnMgaW50byBORCBjcmVhdGVzIGEgZGVwZW5kZW5jeSBvbiByb3V0ZXIgZmlybXdhcmUgZm9y
IGFwcGxpY2F0aW9uIGRlcGxveW1lbnQgdGhhdCBkb2Vzbid0IGV4aXN0IHRvZGF5IGluIGVpdGhl
ciBORCBvciBESENQVjYuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkFub3RoZXIgZXhhbXBsZSBvZiB0aGlzIHRyYXAuIFJlbWVtYmVyIHRoYXQg
TlRQIGFtcGxpZmljYXRpb24gRG9TIGZyb20gMyBvciA0IHllYXJzIGFnbz8gT25lIHBsYWNlIEkn
bSBhd2FyZSBvZiB3ZXJlIHVzaW5nIHRoZWlyIFBFIHJvdXRlcnMgdG8gYWxzbyBwcm92aWRlIGN1
c3RvbWVycyB3aXRoIE5UUCB0aW1lLCBhbmQgdGhlIHJvdXRlciBpbXBsZW1lbnRhdGlvbiB3YXMg
dnVsbmVyYWJsZS4gRnJvbSBtZW1vcnksDQogdGhlIHZlbmRvciB0b29rIGFyb3VuZCBhIHdlZWsg
dG8gcmVsZWFzZSBhIGZpeC4gVGhlbiB0aGUgbmV4dCA2IHRvIDggd2Vla3Mgd2VyZSBzcGVudCBv
cmdhbmlzaW5nIGhpZ2ggaW1wYWN0IGNoYW5nZSBjb250cm9scyBiZWNhdXNlIHJvdXRlciBmaXJt
d2FyZSB1cGdyYWRlcyBlaXRoZXIgcmVxdWlyZWQgcmVib290cyBvciB0aGVyZSB3YXMgYSBoYXph
cmQgb2Ygb25lLiBUaGUgbnVtYmVyIG9mIFBFIHJvdXRlcnMgd2FzIGluIHRoZSAxMHMsIGltYWdp
bmUNCiB0aW1lIGFuZCBlZmZvcnQsIGFuZCB2dWxuZXJhYmlsaXR5IGV4cG9zdXJlIHRpbWUgaWYg
dGhlcmUgd2VyZSAxMDBzIG9yIDEwMDBzIG9mIFBFIHJvdXRlcnMgcHJvdmlkaW5nIE5UUCB0aW1l
IHRvIGN1c3RvbWVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Q29tcGFyZSB0aGF0IHRvIGlmIHRoZSBOVFAgc2VydmljZS9hcHBsaWNhdGlv
biB3YXMgbm90ICZxdW90O2luJnF1b3Q7IHRoZSBuZXR3b3JrLCBub3QgJnF1b3Q7aW4mcXVvdDsg
dGhlIHJvdXRlcnMnIGNvbnRyb2wgcGxhbmVzLCBhbmQgYXMgc2VydmljZSByZWFjaGFibGUgb3Zl
ciB0aGUgbmV0d29yay4gT25seSBwYXRjaGVzIHRvIHRoZSBOVFAgc2VydmVycyB3b3VsZCBoYXZl
IGJlZW4gbmVjZXNzYXJ5LCBhbmQgdGhlcmUgd291bGQgaGF2ZSBiZWVuDQogZmFyIGZld2VyIG9m
IHRob3NlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgREhDUHY2IGZvciBjbGll
bnRzIHJlcXVlc3Rpbmcgc3BlY2lmaWMgb3B0aW9ucyBmb3IgdGhlbXNlbHZlcy4gSnVzdCB0byBt
YWtlIGl0IHBvc3NpYmxlIHRvIHVzZSBib3RoIG1lY2hhbmlzbXMgZm9yIGFsbCBvcHRpb25zIChN
QVAvRFNMaXRlL2V0YyBvcHRpb25zIGluIFJBIHdvdWxkIGJlIG5pY2UpLjxicj4NCjxicj4NCldo
YXQgeW91IGFyZSBkb2luZyBpcyBhbm90aGVyIHdheSBvZiBsb29raW5nIGF0IGl0LiBJZiBJIHVu
ZGVyc3RhbmQgY29ycmVjdGx5IHlvdSdyZSBiYXNpY2FsbHkga2VlcGluZyB0aGUgZnVsbCBmdW5j
dGlvbmFsaXR5IG9mIERIQ1B2NiBidXQgdXNpbmcgUlMvUkEgYXMgYSB0cmFuc3BvcnQgaW5zdGVh
ZCBvZiBVRFAuIEkgd29uZGVyIHdoYXQgdGhlIHNwZWVkIGJlbmVmaXQgb2YgdGhhdCB3b3VsZCBi
ZSBpbiBwcmFjdGljZS4gQWxzbyBjb21wYXJlZA0KIHRvICZxdW90O2ltcGF0aWVudCZxdW90OyBz
eXN0ZW1zIHRoYXQgc2VuZCBvdXQgREhDUHY2IGEgcmVxdWVzdCBiZWZvcmUgZXZlbiByZWNlaXZp
bmcgYW4gUkEuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQomZ3Q7IEkgd291bGQgYXNrIHRoZXNlIGRp
c2N1c3Npb24gbGlzdHMgdG8gY29uc2lkZXIgd2hhdCBpcyBpdCB0aGF0IHlvdSByZWFsbHkgZG9u
J3Q8YnI+DQomZ3Q7IGxpa2UgYWJvdXQgREhDUHY2LiBNYXliZSB5b3UgdGhpbmsgaXQgaXMgdWds
eS4gTWF5YmUgeW91IGRvbid0IGxpa2UgdGhlIHdheTxicj4NCiZndDsgdGhlIGFjcm9ueW0gcm9s
bHMgb2ZmIHlvdXIgdG9uZ3VlIHdoZW4geW91IHNwZWFrIGl0LiBNYXliZSBpdCBoYXMgYW4gb25l
cm91czxicj4NCiZndDsgc3RpZ21hIG9mIGJlaW5nIHN0YXRlZnVsLiBCdXQsIHRoZW4gSSB3b3Vs
ZCBhbHNvIGFzayB5b3UgdG8gY29uc2lkZXIgd2hhdCBhPGJyPg0KJmd0OyByZXBsYWNlbWVudCB3
b3VsZCBsb29rIGxpa2UuIEJlY2F1c2UsIEkgdGhpbmsgYW55IHN1aXRhYmxlIHJlcGxhY2VtZW50
PGJyPg0KJmd0OyB3b3VsZCBoYXZlIHRvIGVzc2VudGlhbGx5IGR1cGxpY2F0ZSB3aGF0IERIQ1B2
NiBhbHJlYWR5IGRvZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkluIG15IG9waW5pb24gREhDUHY2IGlzIGZpbmUuIEkgaW1wbGVtZW50ZWQgYSBzZXJ2ZXIg
YW5kIGl0IGlzIGEgKmxvdCogY2xlYW5lciB0byBpbXBsZW1lbnQgdGhhbiBESENQdjQuIEp1c3Qg
cGxhaW4gVURQIG9uIGxpbmstbG9jYWwgYW5kIG11bHRpY2FzdCBzb2NrZXRzIDopJm5ic3A7IEVz
cGVjaWFsbHkgdGhlIHN0YXRlbGVzcyB2ZXJzaW9uIGlzIHZlcnkgZWFzeSB0byBpbXBsZW1lbnQu
IEl0J3Mgbm90IHRoZSB1bHRpbWF0ZQ0KIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wsIGFuZCBmb3Ig
Y2VydGFpbiB0aGluZ3MgZGlzdHJpYnV0aW5nIGluZm9ybWF0aW9uIHZpYSBSQSBpcyBhIG11Y2gg
YmV0dGVyIGZpdCB0byB0aGUgd2F5IHRoZSBuZXR3b3JrIGlzIHJ1bi4gQnV0IERIQ1B2NiBoYXMg
aXRzIHBsYWNlIGFuZCBpdHMgcm9sZSwgYW5kIGluIGNlcnRhaW4gZW52aXJvbm1lbnRzIChESENQ
djYtUEQgaW4gSVNQIG5ldHdvcmtzLCBESENQdjYgaW4gZW50ZXJwcmlzZSBldGMpIGl0IGRvZXMN
CiB3aGF0IHRoZSBuZXR3b3JrIGFuZCBzeXN0ZW0gb3BlcmF0b3JzIG5lZWQuPGJyPg0KPGJyPg0K
VGhlIG1haW4gcHJvYmxlbSB3aXRoIERIQ1B2NiBhcyBhbiBvcGVyYXRvciBoYXMgYmVlbiBkZWFs
aW5nIHdpdGggRFVJRHMgd2hlbiB0aGUgbGluay1sYXllciBhZGRyZXNzIGluIHRoZSBEVUlEIGlz
IGJhc2VkIG9uIGEgZGlmZmVyZW50IGludGVyZmFjZSB0aGFuIHRoZSBpbnRlcmZhY2Ugc2VuZGlu
ZyB0aGUgREhDUHY2IHJlcXVlc3QuIE1vc3RseSBiZWNhdXNlIHRoZSByZXF1ZXN0aW5nIGludGVy
ZmFjZSdzIE1BQyBhZGRyZXNzIGhhcyBhbHdheXMNCiBiZWVuIHVzZWQgd2l0aCBESENQdjQgYW5k
IGlzIG9mdGVuIHByaW50ZWQgb24gdGhlIG91dHNpZGUgb2YgdGhlIGRldmljZS4gQnV0IHRoZXNl
IGRheXMgTERSQSBhbmQgREhDUHY2IHJlbGF5cyBjYW4gdGVsbCB0aGUgREhDUHY2IHNlcnZlciB3
aGF0IHRoZSBNQUMgYWRkcmVzcyBvZiB0aGUgcmVxdWVzdGluZyBpbnRlcmZhY2Ugd2FzLCBhbmQg
d2UgY2FuIHVzZSB0aGF0IHRvIGlkZW50aWZ5IHRoZSBjbGllbnQgKGluIGFkZGl0aW9uIHRvIGl0
cyBEVUlEKS4NCiBXaXRoIHZlbmRvcnMgc3RhcnRpbmcgdG8gaW1wbGVtZW50IHRoaXMgcmVsYXkg
b3B0aW9uIHRoaXMgaXMgbW9zdGx5IGEgc29sdmVkIHByb2JsZW0gbm93Ljxicj4NCjxicj4NCkFu
b3RoZXIgdGhpbmcgdGhhdCBtYWtlcyBtZSBhIGJpdCBzYWQgaXMgdGhlIGxhY2sgb2YgREhDUHY2
IHJlY29uZmlndXJlIHN1cHBvcnQuIFRoYXQgY291bGQgYmUgdXNlZCB0byB0YWtlIGF3YXkgc29t
ZSBvZiB0aGUgY29tcGxhaW50cyBhZ2FpbnN0IERIQ1B2NiAoYW5kIGFueSBjbGllbnQtaW5pdGlh
dGVkIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wpIHRoYXQgdGhlcmUgaXMgbm8gd2F5IGZvciB0aGUg
bmV0d29yayB0byBpbmZvcm0gdGhlIGNsaWVudA0KIG9mIGNoYW5nZXMuPGJyPg0KPGJyPg0KSSBz
ZWUgbm8gbmVlZCB0byByZXBsYWNlIGl0IHdpdGggc29tZXRoaW5nIGVsc2UgdGhhdCB3b3VsZCBp
bmRlZWQgbmVlZCB0byBkdXBsaWNhdGUgaXRzIGZ1bmN0aW9uYWxpdHkuPGJyPg0KPGJyPg0KQ2hl
ZXJzLDxicj4NClNhbmRlcjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGlu
ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciPmlwdjZAaWV0Zi5vcmc8
L2E+PGJyPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjxicj4NCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_8593f50c724f4cbaa549c7cd6e6b91c0XCH150608nwnosboeingcom_--


From nobody Wed Nov 22 07:52:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3A412940E; Wed, 22 Nov 2017 07:52:32 -0800 (PST)
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 p7_X2hvRou0g; Wed, 22 Nov 2017 07:52:30 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1B212945D; Wed, 22 Nov 2017 07:52:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAMFqSE7013292; Wed, 22 Nov 2017 08:52:28 -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 vAMFqMhA013247 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 22 Nov 2017 08:52:22 -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; Wed, 22 Nov 2017 07:52:21 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 22 Nov 2017 07:52:21 -0800
From: "Templin, Fred L" 
To: Lorenzo Colitti 
CC: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org" , "dhcwg@ietf.org" 
Subject: RE: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgAkcdkAADO+44A=
Date: Wed, 22 Nov 2017 15:52:21 +0000
Message-ID: <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com>
References: <9debb1672e3d4f0d89d672d64e0fe579@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_4e01cd6cc5234daca2f7be55b8cc28b0XCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 15:52:32 -0000

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

SGkgTG9yZW56bywNCg0KSSByZXNwZWN0IHlvdXIgdGFraW5nIHRoZSB0aW1lIHRvIHBvc3QgdGhp
cyB1c2VmdWwgY3JpdGlxdWUsIGFuZCBleHBlY3QgdGhhdCBvdGhlcnMNCndpdGggYSBkZWVwZXIg
YmFja2dyb3VuZCBpbiB0aGUgREhDUHY2IGFyY2hpdGVjdHVyZSB3b3VsZCB3YW50IHRvIHJlc3Bv
bmQgaW4NCmRldGFpbC4gVGhhbmsgeW91IGZvciBzaGFyaW5nIHlvdXIgdGhvdWdodHMuDQoNCkZv
ciBteXNlbGYsIEluIG15IGVudmlyb25tZW50IEkgaGF2ZSBtb2JpbGUgbm9kZSBjbGllbnRzIHdp
dGggbWFueSByb3V0ZXJzDQpvbiB0aGUgbGluayDigJMgZWFjaCBvZiB3aGljaCBpbXBsZW1lbnRz
IHRoZSBESENQdjYgcmVsYXkgYW5kL29yIHNlcnZlci4gVGhlDQpsaW5rIGlzIE5CTUEsIG1lYW5p
bmcgdGhhdCBtdWx0aWNhc3QgaXMgbm90IHN1cHBvcnRlZCBuYXRpdmVseSwgc28gdGhhdCB0aGUN
CmNsaWVudCBoYXMgdG8gc2VuZCB0aGUgREhDUHY2IFNvbGljaXQgdG8gb25lIG9yIGEgY291cGxl
IG9mIHJvdXRlcnMgdmlhIExMDQptdWx0aWNhc3QgdG8gTDIgdW5pY2FzdCBtYXBwaW5nLiBUaGUg
Y2xpZW50IGdldHMgdGhlIGV4YWN0IHNhbWUgc2VydmljZQ0KcmVnYXJkbGVzcyBvZiB3aGljaCBy
b3V0ZXIgb3Igcm91dGVycyBpdCBwaWNrcy4NCg0KQXMgbG9uZyBhcyB0aGUgY2xpZW50IHJlbWFp
bnMgb24gdGhlIGxpbmssIGl0IGNhbiBjb250aW51ZSB0byBtYWludGFpbiB0aGUNCnByZWZpeCBk
ZWxlZ2F0aW9ucyBpdCBoYXMgcmVjZWl2ZWQgZnJvbSBpdHMgcm91dGVycywgYW5kIGNhbiBldmVu
IGNoYW5nZSB0bw0KYSBkaWZmZXJlbnQgc2V0IG9mIHJvdXRlcnMgaWYgaXQgdGhpbmtzIHRoYXQg
d291bGQgZ2l2ZSBiZXR0ZXIgc2VydmljZS4gVGhpcyBpcw0KdHJ1ZSBldmVuIGlmIHRoZSBjbGll
bnTigJlzIEwyIGFkZHJlc3NlcyBjaGFuZ2UsIHdoaWNoIGlzIHNpZ25hbGVkIGJ5IHNlbmRpbmcN
CnVuc29saWNpdGVkIE5BcyB0byB0aGUgcm91dGVycyB0aGUgc2FtZSBhcyBzcGVjaWZpZWQgaW4g
UkZDNDg2MS4NCg0KQWdhaW4sIHRoaXMgaXMganVzdCB3aGF0IEkgYW0gZG9pbmcgaW4gbXkgZW52
aXJvbm1lbnQgYW5kIGl0IGdpdmVzIGEgdmVyeQ0Kc2F0aXNmYWN0b3J5IHNlcnZpY2UuIFdoYXQg
bXkgZHJhZnQgaXMgcHJvcG9zaW5nIGlzIGEgdW5pZmljYXRpb24gb2YgSVB2NiBORA0KYW5kIERI
Q1B2NiB0byBnaXZlIHRoZSBiZXN0IGZ1bmN0aW9ucyBvZiBib3RoIHN0YXRlbGVzcyBhbmQgc3Rh
dGVmdWwNCmF1Y29uZmlndXJhdGlvbiBpbiBhIHNpbmdsZSB1bmlmaWVkIHBhY2thZ2UuIEFuZCwg
aWYgREhDUHY2IHdvdWxkIG5vdA0KYmUgc3VpdGFibGUgZm9yIHN1cHBvcnRpbmcgdGhlIHN0YXRl
ZnVsIGZ1bmN0aW9uLCB0aGVuIHdlIHdvdWxkIGhhdmUgdG8NCmRlZmluZSBzb21ldGhpbmcgbmV3
IHRoYXQgaXMuDQoNClRoYW5rcyAtIEZyZWQNCg0KRnJvbTogTG9yZW56byBDb2xpdHRpIFttYWls
dG86bG9yZW56b0Bnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyMCwgMjAxNyAx
MDo0OCBQTQ0KVG86IFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4N
CkNjOiA2bWFuQGlldGYub3JnOyB2Nm9wc0BpZXRmLm9yZzsgZGhjd2dAaWV0Zi5vcmcNClN1Ympl
Y3Q6IFJlOiBbdjZvcHNdIENvbWJpbmluZyBJUHY2IE5EIGFuZCBESENQdjYgaW50byBhIHNpbmds
ZSwgdW5pZmllZCBmdW5jdGlvbg0KDQpPbiBUdWUsIE5vdiAyMSwgMjAxNyBhdCA2OjQwIEFNLCBU
ZW1wbGluLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208bWFpbHRvOkZyZWQuTC5U
ZW1wbGluQGJvZWluZy5jb20+PiB3cm90ZToNCkkgd291bGQgYXNrIHRoZXNlIGRpc2N1c3Npb24g
bGlzdHMgdG8gY29uc2lkZXIgd2hhdCBpcyBpdCB0aGF0IHlvdSByZWFsbHkgZG9uJ3QNCmxpa2Ug
YWJvdXQgREhDUHY2LiBNYXliZSB5b3UgdGhpbmsgaXQgaXMgdWdseS4NCg0KQXMgZ2VuZXJhbGx5
IGltcGxlbWVudGVkIGFuZCBkZXBsb3llZCwgSSB0aGluayB0aGUgbWFpbiB0aGluZ3MgdGhhdCBh
cmUgd3Jvbmcgd2l0aCBESENQdjYgYXJlIGFzIGZvbGxvd3MuIE5vdGUgdGhhdCB0aGVzZSBhcmUg
bm90IG5lY2Vzc2FyaWx5IGxpbWl0cyBpbXBvc2VkIHRoZSBwcm90b2NvbCBpdHNlbGYsIGJ1dCB0
aGV5IGFyZSBkZWZpbml0ZWx5IGxpbWl0cyBpbXBvc2VkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbnMg
YW5kIGhvdyBwZW9wbGUgdHlwaWNhbGx5IGRlcGxveSB0aGVtLiBBcyBzdWNoLCB0aGUgZm9sbG93
aW5nIGFyZSBub3QgcmVxdWlyZWQgdG8gYmUgdHJ1ZSwgYnV0IGFyZSBvbmx5IHRydWUgaW4gcHJh
Y3RpY2UgaW4gdGhlIHZhc3QgbWFqb3JpdHkgb2YgZGVwbG95bWVudHMuDQoNCiAgKiAgIEluIHN0
YXRlZnVsIGZvcm06DQoNCiAgICAgKiAgIEluYWJpbGl0eSB0byBzdXBwb3J0IG11bHRpcGxlIHNv
dXJjZXMgb2YgaW5mb3JtYXRpb24gKHRoZSBjbGllbnQgcGlja3MgdGhlIGZpcnN0IGxlYXNlIGl0
IGdldHMpLg0KICAgICAqICAgVmVyeSBkaWZmaWN1bHQgdG8gdXBkYXRlIGRldmljZXMgd2hlbiBu
ZXR3b3JrIGNoYW5nZXMgYmVjYXVzZSBpdCdzIGZ1bmRhbWVudGFsbHkgYmFzZWQgb24gbGVhc2Vz
IGFuZCByZW5ld3MgYW5kIFJFQ09ORklHVVJFIGlzIG5vdCAod2lkZWx5KSBpbXBsZW1lbnRlZC4N
CiAgICAgKiAgIE1ha2VzIHBvc3NpYmxlIHN0YXRlZnVsIGFkZHJlc3MgYXNzaWdubWVudCBvZiBp
bmRpdmlkdWFsIElQIGFkZHJlc3Nlcy4gSXQncyByZWFsbHkgbm90IGEgZ29vZCBpZGVhIHRvIHJl
bHkgb25seSBvbiB0aGlzIGZvciBJUCBhZGRyZXNzaW5nLCBidXQgdGhlcmUgYXJlIGRlY2FkZXMg
b2Ygb3BlcmF0aW9uYWwgcHJhY3RpY2UgYXJvdW5kIGl0IGluIElQdjQgYW5kIG9sZCBoYWJpdHMg
KGFuZCBsZWdhY3kgZGVwbG95ZWQgc3lzdGVtcykgZGllIGhhcmQuDQogICAgICogICBUeXBpY2Fs
bHkgZGVwbG95ZWQgdXNpbmcgcmVsYXlzIGFuZCBjZW50cmFsaXplZCBhc3NpZ25tZW50LCB3aGlj
aCBpcyB2ZXJ5IHVuc3VpdGVkIHRvIHRvcG9sb2d5IGNoYW5nZXMuDQoNCiAgICAgICAgKiAgIElm
IGFsbCB5b3UgaGF2ZSBpcyBhIGNlbnRyYWwgYWRkcmVzc2luZyBzZXJ2ZXIsIHlvdSBkb24ndCB3
YW50IHRvIGJvdGhlciB0aGF0IHNlcnZlciB3aXRoIGNvbnN0YW50IHRvcG9sb2d5IHVwZGF0ZXMg
ZnJvbSBhbGwgb3ZlciB0aGUgbmV0d29yayBzbyBpdCBjYW4gdXBkYXRlIHRoZSBob3N0cy4NCiAg
ICAgICAgKiAgIEFsc28sIGlmIHRoZSB0b3BvbG9neSBjaGFuZ2VzIGVub3VnaCwgdGhlIHNlcnZl
ciBtaWdodCBldmVuIGJlIHVucmVhY2hhYmxlIGZyb20gc29tZSBob3N0cy4NCg0KICAqICAgSW4g
c3RhdGVsZXNzIGZvcm06DQoNCiAgICAgKiAgIFZlcnkgaGFyZCB0byB1cGRhdGUgZGV2aWNlcyB3
aGVuIGFueXRoaW5nIGNoYW5nZXMgb24gdGhlIG5ldHdvcmsuIFRoZSBtaW5pbXVtIGluIHRoZSBz
dGF0ZWxlc3MgREhDUHY2IFJGQyBpcyAxMCBtaW51dGVzLCB3aGljaCBpcyAqd2F5KiB0b28gbG9u
ZyBmb3IgY2VydGFpbiB0eXBlcyBvZiBuZXR3b3JrcyBsaWtlIG1vYmlsZSBob3RzcG90cy4NClRo
ZSBpbmFiaWxpdHkgdG8gdXBkYXRlIGhvc3RzIHdpdGggbmV3IG5ldHdvcmsgaW5mb3JtYXRpb24g
aXMgYSBjcnVjaWFsIHdlYWtuZXNzIGJlY2F1c2UgaXQgZm9yY2VzIG5ldHdvcmtzIHRvIGFwcGVh
ciB0byBob3N0cyBhcyBpZiB0aGV5IG5ldmVyIGNoYW5nZS4gQnV0IG5ldHdvcmtzIGNoYW5nZSBh
bGwgdGhlIHRpbWUuIElmIHlvdSBjYW4ndCB1cGRhdGUgdGhlIGhvc3RzIG9uIGEgdGltZWx5IGJh
c2lzIGFib3V0IGEgY2hhbmdlcywgZWl0aGVyIHlvdSBuZXZlciBjaGFuZ2UgdGhlIG5ldHdvcmss
IG9yIHlvdSBoYXZlIGFuIG91dGFnZSwgb3IgeW91IGxpZSB0byB0aGUgaG9zdHMuIFNvIHdlIGVu
ZCB1cCB3aXRoIHRoaW5ncyBsaWtlIFZSUlAgYW5kIE5BVCB0byBlbnN1cmUgdGhlIGhvc3QgbmV2
ZXIgc2VlcyB0aGUgbmV0d29yayBjaGFuZ2UuDQoNCk5BVCwgb2YgY291cnNlLCBpcyB0aGUgdWx0
aW1hdGUgd2F5IG9mIG5ldmVyIGNoYW5naW5nIGFueXRoaW5nIC0geW91IGNvdWxkIGRlcGxveSBJ
UHY0IGJ5IGFzc2lnbmluZyBldmVyeSBob3N0IG9uIGV2ZXJ5IG5ldHdvcmsgMTkyLjE2OC4xLjIg
KGdhdGV3YXkgYW5kIEROUyBzZXJ2ZXIgMTkyLjE2LjEuMSkgYW5kIGp1c3QgTkFUaW5nIGV2ZXJ5
dGhpbmcgd2l0aCBsYXllci0yIGF3YXJlIE5BVC4NCg==

--_000_4e01cd6cc5234daca2f7be55b8cc28b0XCH150608nwnosboeingcom_
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
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u
RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K
CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh
Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z
by1saXN0LWlkOjM4MzY3NDY2NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTUyNTY5MzM5ODt9
DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv
bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt
c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K
CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ
bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp
c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z
aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJ
e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm
b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i
ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z
dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n
ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg
bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt
dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl
OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN
Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250
LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy
Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBMb3JlbnpvLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSByZXNwZWN0IHlvdXIg
dGFraW5nIHRoZSB0aW1lIHRvIHBvc3QgdGhpcyB1c2VmdWwgY3JpdGlxdWUsIGFuZCBleHBlY3Qg
dGhhdCBvdGhlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+d2l0aCBhIGRlZXBlciBiYWNrZ3JvdW5kIGlu
IHRoZSBESENQdjYgYXJjaGl0ZWN0dXJlIHdvdWxkIHdhbnQgdG8gcmVzcG9uZCBpbjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj5kZXRhaWwuIFRoYW5rIHlvdSBmb3Igc2hhcmluZyB5b3VyIHRob3VnaHRzLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Rm9yIG15c2VsZiwgSW4g
bXkgZW52aXJvbm1lbnQgSSBoYXZlIG1vYmlsZSBub2RlIGNsaWVudHMgd2l0aCBtYW55IHJvdXRl
cnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+b24gdGhlIGxpbmsg4oCTIGVhY2ggb2Ygd2hpY2ggaW1wbGVt
ZW50cyB0aGUgREhDUHY2IHJlbGF5IGFuZC9vciBzZXJ2ZXIuIFRoZTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5saW5rIGlzIE5CTUEsIG1lYW5pbmcgdGhhdCBtdWx0aWNhc3QgaXMgbm90IHN1cHBvcnRlZCBu
YXRpdmVseSwgc28gdGhhdCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Y2xpZW50IGhhcyB0byBzZW5k
IHRoZSBESENQdjYgU29saWNpdCB0byBvbmUgb3IgYSBjb3VwbGUgb2Ygcm91dGVycyB2aWEgTEw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+bXVsdGljYXN0IHRvIEwyIHVuaWNhc3QgbWFwcGluZy4gVGhlIGNs
aWVudCBnZXRzIHRoZSBleGFjdCBzYW1lIHNlcnZpY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+cmVnYXJk
bGVzcyBvZiB3aGljaCByb3V0ZXIgb3Igcm91dGVycyBpdCBwaWNrcy48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFzIGxvbmcgYXMgdGhlIGNsaWVudCByZW1haW5z
IG9uIHRoZSBsaW5rLCBpdCBjYW4gY29udGludWUgdG8gbWFpbnRhaW4gdGhlPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPnByZWZpeCBkZWxlZ2F0aW9ucyBpdCBoYXMgcmVjZWl2ZWQgZnJvbSBpdHMgcm91dGVy
cywgYW5kIGNhbiBldmVuIGNoYW5nZSB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hIGRpZmZlcmVudCBz
ZXQgb2Ygcm91dGVycyBpZiBpdCB0aGlua3MgdGhhdCB3b3VsZCBnaXZlIGJldHRlciBzZXJ2aWNl
LiBUaGlzIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRydWUgZXZlbiBpZiB0aGUgY2xpZW504oCZcyBM
MiBhZGRyZXNzZXMgY2hhbmdlLCB3aGljaCBpcyBzaWduYWxlZCBieSBzZW5kaW5nPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPnVuc29saWNpdGVkIE5BcyB0byB0aGUgcm91dGVycyB0aGUgc2FtZSBhcyBzcGVj
aWZpZWQgaW4gUkZDNDg2MS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPkFnYWluLCB0aGlzIGlzIGp1c3Qgd2hhdCBJIGFtIGRvaW5nIGluIG15IGVudmlyb25tZW50
IGFuZCBpdCBnaXZlcyBhIHZlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+c2F0aXNmYWN0b3J5IHNlcnZp
Y2UuIFdoYXQgbXkgZHJhZnQgaXMgcHJvcG9zaW5nIGlzIGEgdW5pZmljYXRpb24gb2YgSVB2NiBO
RDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj5hbmQgREhDUHY2IHRvIGdpdmUgdGhlIGJlc3QgZnVuY3Rpb25z
IG9mIGJvdGggc3RhdGVsZXNzIGFuZCBzdGF0ZWZ1bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hdWNvbmZp
Z3VyYXRpb24gaW4gYSBzaW5nbGUgdW5pZmllZCBwYWNrYWdlLiBBbmQsIGlmIERIQ1B2NiB3b3Vs
ZCBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YmUgc3VpdGFibGUgZm9yIHN1cHBvcnRpbmcgdGhlIHN0
YXRlZnVsIGZ1bmN0aW9uLCB0aGVuIHdlIHdvdWxkIGhhdmUgdG88bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
ZGVmaW5lIHNvbWV0aGluZyBuZXcgdGhhdCBpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu
ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBMb3JlbnpvIENvbGl0dGkg
W21haWx0bzpsb3JlbnpvQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBO
b3ZlbWJlciAyMCwgMjAxNyAxMDo0OCBQTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiwgRnJlZCBM
ICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gNm1hbkBp
ZXRmLm9yZzsgdjZvcHNAaWV0Zi5vcmc7IGRoY3dnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8
L2I+IFJlOiBbdjZvcHNdIENvbWJpbmluZyBJUHY2IE5EIGFuZCBESENQdjYgaW50byBhIHNpbmds
ZSwgdW5pZmllZCBmdW5jdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTm92IDIxLCAyMDE3IGF0IDY6
NDAgQU0sIFRlbXBsaW4sIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGlu
QGJvZWluZy5jb20iIHRhcmdldD0iX2JsYW5rIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu
MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SSB3b3VsZCBhc2sgdGhlc2UgZGlzY3Vzc2lvbiBsaXN0cyB0byBjb25zaWRlciB3aGF0
IGlzIGl0IHRoYXQgeW91IHJlYWxseSBkb24ndDxicj4NCmxpa2UgYWJvdXQgREhDUHY2LiBNYXli
ZSB5b3UgdGhpbmsgaXQgaXMgdWdseS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIGdlbmVyYWxseSBpbXBsZW1lbnRlZCBhbmQg
ZGVwbG95ZWQsIEkgdGhpbmsgdGhlIG1haW4gdGhpbmdzIHRoYXQgYXJlIHdyb25nIHdpdGggREhD
UHY2IGFyZSBhcyBmb2xsb3dzLiBOb3RlIHRoYXQgdGhlc2UgYXJlIG5vdCBuZWNlc3NhcmlseSBs
aW1pdHMgaW1wb3NlZCB0aGUgcHJvdG9jb2wgaXRzZWxmLCBidXQgdGhleSBhcmUgZGVmaW5pdGVs
eSBsaW1pdHMgaW1wb3NlZCBieSB0aGUgaW1wbGVtZW50YXRpb25zDQogYW5kIGhvdyBwZW9wbGUg
dHlwaWNhbGx5IGRlcGxveSB0aGVtLiBBcyBzdWNoLCB0aGUgZm9sbG93aW5nIGFyZSBub3QgcmVx
dWlyZWQgdG8gYmUgdHJ1ZSwgYnV0IGFyZSBvbmx5IHRydWUgaW4gcHJhY3RpY2UgaW4gdGhlIHZh
c3QgbWFqb3JpdHkgb2YgZGVwbG95bWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxl
dmVsMSBsZm8xIj4NCkluIHN0YXRlZnVsIGZvcm06PG86cD48L286cD48L2xpPjwvdWw+DQo8dWwg
dHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87
bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KSW5hYmlsaXR5IHRvIHN1cHBvcnQgbXVsdGlwbGUg
c291cmNlcyBvZiBpbmZvcm1hdGlvbiAodGhlIGNsaWVudCBwaWNrcyB0aGUgZmlyc3QgbGVhc2Ug
aXQgZ2V0cykuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6
bDAgbGV2ZWwyIGxmbzEiPg0KVmVyeSBkaWZmaWN1bHQgdG8gdXBkYXRlIGRldmljZXMgd2hlbiBu
ZXR3b3JrIGNoYW5nZXMgYmVjYXVzZSBpdCdzIGZ1bmRhbWVudGFsbHkgYmFzZWQgb24gbGVhc2Vz
IGFuZCByZW5ld3MgYW5kIFJFQ09ORklHVVJFIGlzIG5vdCAod2lkZWx5KSBpbXBsZW1lbnRlZC48
bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDIg
bGZvMSI+DQpNYWtlcyBwb3NzaWJsZSBzdGF0ZWZ1bCBhZGRyZXNzIGFzc2lnbm1lbnQgb2YgaW5k
aXZpZHVhbCBJUCBhZGRyZXNzZXMuIEl0J3MgcmVhbGx5IG5vdCBhIGdvb2QgaWRlYSB0byByZWx5
IG9ubHkgb24gdGhpcyBmb3IgSVAgYWRkcmVzc2luZywgYnV0IHRoZXJlIGFyZSBkZWNhZGVzIG9m
IG9wZXJhdGlvbmFsIHByYWN0aWNlIGFyb3VuZCBpdCBpbiBJUHY0IGFuZCBvbGQgaGFiaXRzIChh
bmQgbGVnYWN5IGRlcGxveWVkIHN5c3RlbXMpIGRpZSBoYXJkLjxvOnA+PC9vOnA+PC9saT48bGkg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NClR5cGljYWxseSZu
YnNwO2RlcGxveWVkIHVzaW5nIHJlbGF5cyBhbmQgY2VudHJhbGl6ZWQgYXNzaWdubWVudCwgd2hp
Y2ggaXMgdmVyeSB1bnN1aXRlZCB0byB0b3BvbG9neSBjaGFuZ2VzLjxvOnA+PC9vOnA+PC9saT48
L3VsPg0KPC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPHVsIHR5
cGU9InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMyBs
Zm8xIj4NCklmIGFsbCB5b3UgaGF2ZSBpcyBhIGNlbnRyYWwgYWRkcmVzc2luZyBzZXJ2ZXIsIHlv
dSBkb24ndCB3YW50IHRvIGJvdGhlciB0aGF0IHNlcnZlciB3aXRoIGNvbnN0YW50IHRvcG9sb2d5
IHVwZGF0ZXMgZnJvbSBhbGwgb3ZlciB0aGUgbmV0d29yayBzbyBpdCBjYW4gdXBkYXRlIHRoZSBo
b3N0cy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs
ZXZlbDMgbGZvMSI+DQpBbHNvLCBpZiB0aGUgdG9wb2xvZ3kgY2hhbmdlcyBlbm91Z2gsIHRoZSBz
ZXJ2ZXIgbWlnaHQgZXZlbiBiZSB1bnJlYWNoYWJsZSBmcm9tIHNvbWUgaG9zdHMuPG86cD48L286
cD48L2xpPjwvdWw+DQo8L3VsPg0KPC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSW4gc3RhdGVsZXNzIGZvcm06
PG86cD48L286cD48L2xpPjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xl
Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0KVmVy
eSBoYXJkIHRvIHVwZGF0ZSBkZXZpY2VzIHdoZW4gYW55dGhpbmcgY2hhbmdlcyBvbiB0aGUgbmV0
d29yay4gVGhlIG1pbmltdW0gaW4gdGhlIHN0YXRlbGVzcyBESENQdjYgUkZDIGlzIDEwIG1pbnV0
ZXMsIHdoaWNoIGlzICp3YXkqIHRvbyBsb25nIGZvciBjZXJ0YWluIHR5cGVzIG9mIG5ldHdvcmtz
IGxpa2UgbW9iaWxlIGhvdHNwb3RzLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW5hYmlsaXR5IHRvIHVwZGF0ZSBob3N0cyB3aXRo
IG5ldyBuZXR3b3JrIGluZm9ybWF0aW9uIGlzIGEgY3J1Y2lhbCB3ZWFrbmVzcyBiZWNhdXNlIGl0
IGZvcmNlcyBuZXR3b3JrcyB0byBhcHBlYXIgdG8gaG9zdHMgYXMgaWYgdGhleSBuZXZlciBjaGFu
Z2UuIEJ1dCBuZXR3b3JrcyBjaGFuZ2UgYWxsIHRoZSB0aW1lLiBJZiB5b3UgY2FuJ3QgdXBkYXRl
IHRoZSBob3N0cyBvbiBhIHRpbWVseSBiYXNpcyBhYm91dA0KIGEgY2hhbmdlcywgZWl0aGVyIHlv
dSBuZXZlciBjaGFuZ2UgdGhlIG5ldHdvcmssIG9yIHlvdSBoYXZlIGFuIG91dGFnZSwgb3IgeW91
IGxpZSB0byB0aGUgaG9zdHMuIFNvIHdlIGVuZCB1cCB3aXRoIHRoaW5ncyBsaWtlIFZSUlAgYW5k
IE5BVCB0byBlbnN1cmUgdGhlIGhvc3QgbmV2ZXIgc2VlcyB0aGUgbmV0d29yayBjaGFuZ2UuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5BVCwg
b2YgY291cnNlLCBpcyB0aGUgdWx0aW1hdGUgd2F5IG9mIG5ldmVyIGNoYW5naW5nIGFueXRoaW5n
IC0geW91IGNvdWxkIGRlcGxveSBJUHY0IGJ5IGFzc2lnbmluZyBldmVyeSBob3N0IG9uIGV2ZXJ5
IG5ldHdvcmsgMTkyLjE2OC4xLjIgKGdhdGV3YXkgYW5kIEROUyBzZXJ2ZXIgMTkyLjE2LjEuMSkg
YW5kIGp1c3QgTkFUaW5nIGV2ZXJ5dGhpbmcgd2l0aCBsYXllci0yIGF3YXJlIE5BVC48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_4e01cd6cc5234daca2f7be55b8cc28b0XCH150608nwnosboeingcom_--


From nobody Wed Nov 22 08:53:56 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11E912946A; Wed, 22 Nov 2017 08:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lOJBay1e9242; Wed, 22 Nov 2017 08:53:52 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01580129467; Wed, 22 Nov 2017 08:53:51 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B039F20008; Wed, 22 Nov 2017 11:55:56 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6E3F882B25; Wed, 22 Nov 2017 11:53:50 -0500 (EST)
From: Michael Richardson 
To: "dhcwg\@ietf.org" , "v6ops\@ietf.org" , "6man\@ietf.org" <6man@ietf.org>
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
In-Reply-To: <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 16:53:54 -0000

--=-=-=
Content-Type: text/plain


My understanding is that Fred Templin essentially wants to carry DHCP
(configuration) options in ND/RA.

I think that they are most often stateless (i.e. not addresses at all or
other resources).

I've heard the IPv4 PPP folks lament that they should have just had an IPCP
option to carry DHCPv4 options, and indeed that's why we have almost no IP6CP
options, as it's all done by ND and DHCPv6.

{Having implemented a DHCPv6 server just to serve PPP links, it really feels
dumb.  Yes, the management is all centralized, but it's centralized via
RADIUS, not via DHCP relays. }

So I suggest that Fred should go ahead with his document as Experimental,
with our blessing, and an obligation to report on how well it works in
his situation.   Given the timescales that I think his industry works at, he
might need more time than an average Experimental code allocation.
He would have to deal how/if/when all experimental systems would be withdrawn
should the experiment be unsuccessful, I think.

I guess he could use ND codes 253/254, but I think an assignment would not
kill here.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloVq54ACgkQgItw+93Q
3WVBNQf/dGSMArhAYik9rBPqi5zChB/fhiJPPN4ytZ8HeFwKVKDeby3kNtr9KQ7i
DjCkX7VXPmspkhbSY47f7dBsH3DqRAvxNVnlMzUGeWedVFsT06VSrxpxzX0DeVAA
//gegRPw/UPjNkQHZtkA61Lea++jO46RiYNAdy+IXHdO/NZh7B7Zo5KW+S4rQxWJ
xUYSbQrs8hfR6Kx9acFPpXr6MrkfGmD6Ig3Rzo7kuzCt7nE6jP4adnAhLT5iBwOq
wLGtsSkJB4qeF/NvmUc7ZddC9QOTUSj763FfkxYxPfFKuRD2TtrHwg38k4pJ9nIU
YdkxhEq2AObGuqwL+iD0lGX0qwjbeA==
=nKEy
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Nov 22 09:31:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B31129494; Wed, 22 Nov 2017 09:31:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cly663AL68p; Wed, 22 Nov 2017 09:31:41 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179D5129492; Wed, 22 Nov 2017 09:31:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAMHVe5r048212; Wed, 22 Nov 2017 10:31:40 -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 vAMHVUSJ047750 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 22 Nov 2017 10:31:30 -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, 22 Nov 2017 09:31:29 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Wed, 22 Nov 2017 09:31:29 -0800
From: "Templin, Fred L" 
To: Michael Richardson , "dhcwg@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>
Subject: RE: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgAkcdkAADO+44AAE7ZgAAAPkJMw
Date: Wed, 22 Nov 2017 17:31:29 +0000
Message-ID: <53abe623d4bd418c9799b9e8d94e8006@XCH15-06-08.nw.nos.boeing.com>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca>
In-Reply-To: <27327.1511369630@obiwan.sandelman.ca>
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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 17:31:42 -0000

Hi Michael,

This isn't an experiment; this is a unified stateless/stateful autoconfigur=
ation
service for IPv6 for all time.

We all want prefix delegation, and that will necessarily be a stateful func=
tion.
And, if the prefix delegation service would not be DHCPv6 PD then we would
need to develop a new PD architecture. Either way, though, it should be
implemented as a unified function with IPv6ND.

Thanks - Fred

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson
> Sent: Wednesday, November 22, 2017 8:54 AM
> To: dhcwg@ietf.org; v6ops@ietf.org; 6man@ietf.org
> Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified =
function
>=20
>=20
> My understanding is that Fred Templin essentially wants to carry DHCP
> (configuration) options in ND/RA.
>=20
> I think that they are most often stateless (i.e. not addresses at all or
> other resources).
>=20
> I've heard the IPv4 PPP folks lament that they should have just had an IP=
CP
> option to carry DHCPv4 options, and indeed that's why we have almost no I=
P6CP
> options, as it's all done by ND and DHCPv6.
>=20
> {Having implemented a DHCPv6 server just to serve PPP links, it really fe=
els
> dumb.  Yes, the management is all centralized, but it's centralized via
> RADIUS, not via DHCP relays. }
>=20
> So I suggest that Fred should go ahead with his document as Experimental,
> with our blessing, and an obligation to report on how well it works in
> his situation.   Given the timescales that I think his industry works at,=
 he
> might need more time than an average Experimental code allocation.
> He would have to deal how/if/when all experimental systems would be withd=
rawn
> should the experiment be unsuccessful, I think.
>=20
> I guess he could use ND codes 253/254, but I think an assignment would no=
t
> kill here.
>=20
> --
> Michael Richardson , Sandelman Software Works
>  -=3D IPv6 IoT consulting =3D-
>=20
>=20



From nobody Wed Nov 22 16:19:02 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44531293E4; Wed, 22 Nov 2017 16:19:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-VebzRhkgg7; Wed, 22 Nov 2017 16:18:59 -0800 (PST)
Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0620A126C22; Wed, 22 Nov 2017 16:18:59 -0800 (PST)
Received: by mail-ot0-x230.google.com with SMTP id u10so15015084otc.12; Wed, 22 Nov 2017 16:18:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mkVHLGosuK6D4fvH5NX735h1EAbKVAXRkwin/j2h4iU=; b=extC4uDo9MJNqdc/fKhxmqTVEUwIxxOVlZqaLtDcms5XRcH6rYr1NuDYjUiCs4jqOO cmmprSlrbt0Oss+kUa1JQH0GRHerwb1KL5JmgJspuF2kytEXdhOnWWqen+un2TU8tZBG DEUdyQCrpzb9XfzCqOod6HGtjQTA9accgSXy4/HOH2D9dMhu84ECdIwKDfRmefLco7IL CUzcHJGmif9ogYdk3XOpxDgd3o62Guh+fcyX9+RbCRJR24yYJYHIXPPCj66/GVpu3J5v FWAXkdBA6ju+U6cOxT1Uc35zEBSWwQky3E128onE3/aOReQTfwPIMh+5qucNCP2iYwi8 EKAg==
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=mkVHLGosuK6D4fvH5NX735h1EAbKVAXRkwin/j2h4iU=; b=UkU0uq4QA+8qQSYYew9URp+HTza+rqelJ3oeWDan2e9+O3QSprY5Gt4HsYOXxH6ppA Qo1D2xmTivUDdX01+hzjuSSoZGBOsIVfI/Yk79WxvmJ3SrO8TSWdCO4flknVEtwLBsLC b33txHgZMLR5xMRJ7Az88jMssnIKdiQOomeMr6iUbjKXvHOzTlTDcZD43om4/Z4pZ9aU mlmilZn6jwCKPF/9f/SwRAhzoEKX9X7PyeF2nkz20XKWDto6CGGcTG2lEMR73ucI4Bxb nipwEWOHaA6tgiqteR57iHKmjCJ16PpCQoO0oAjsaIdJ7JS6tHK3W37iIlF7WpURGgPU PDzw==
X-Gm-Message-State: AJaThX7QDbhFx/2F2g9qcVkAL5xxh0mT/WHl3Wk061BeJl6qEugWEGB4 cJt8puFT/Y20+Sf7nrDsmOMu7zPd
X-Google-Smtp-Source: AGs4zMZuSsk6cEn3qwf5uaLvzSgMtZVNeDhlZ6LWVUND7eQjLNkJjJ/X4Kxm8cZhyPTzmMtjmNT0RA==
X-Received: by 10.157.8.163 with SMTP id 32mr14250859otf.114.1511396338391; Wed, 22 Nov 2017 16:18:58 -0800 (PST)
Received: from ?IPv6:2600:8802:5600:f7a::1005? ([2600:8802:5600:f7a::1005]) by smtp.gmail.com with ESMTPSA id r184sm6900080oia.40.2017.11.22.16.18.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Nov 2017 16:18:57 -0800 (PST)
From: Fred Baker 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_7ADA12C3-756D-4F37-B43D-1A8598748450"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Date: Wed, 22 Nov 2017 16:18:54 -0800
In-Reply-To: <27327.1511369630@obiwan.sandelman.ca>
Cc: "dhcwg@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>
To: Michael Richardson 
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Nov 2017 00:19:00 -0000

--Apple-Mail=_7ADA12C3-756D-4F37-B43D-1A8598748450
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Nov 22, 2017, at 8:53 AM, Michael Richardson =
 wrote:
>=20
> My understanding is that Fred Templin essentially wants to carry DHCP
> (configuration) options in ND/RA.

On thing that I have never understood is the lack of an RA option that =
carries any DHCPv6 option. This entire silly debate would end if RAs =
encompassed DHCP options.

--Apple-Mail=_7ADA12C3-756D-4F37-B43D-1A8598748450
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+AFAloWE+4ACgkQEhdRnd2G
P+CpkhAAmBXEEfCxZSoRTbbFwPifHGgJsokbFLqUCgz40Ss+K6onZFZM6o+fBAA3
HWfKNhAa1vzVdsBUuoUp6t7hD1ZMnnuUJZM9eNoRmDg0G4TIM2aRYDCe3a/SFeWD
pminvtyW9sbf4VJWKst3Mr9rwJPFLpjE8kfoxN5xHYQobknwn/519PRHXMxuDHjT
OesGZ964TVPBUlgS3VTBaZgsV55icCps9URIBH3Xe70YQ1od4I8lDYkRLTmYxcKf
4gFI6HiuUNWGtHbCizKaeHeY0LHL60yRrigxHDTOFYJM75ONOIU3UXD7VQvFVP5A
9LskBIh+u1RR0wbAJ2dNXq42FEAUOy/wtpkkrJKNq1JkDhAaEX6gmY3m7K//rNpi
MBA86PzWKSZ9mMpCYK98d7qTGDndvg/ufRqMaR7c718GnwVsRrVvpAexDxoYMrAt
4c2POCVJfwrrK/swo105gMxMhgy5hZ4qXwufcWTAe1rd//bNsFVa1rwZoZ+Dl6VO
/kY1O1sQ+fP3sfiFmW9HkNvrs0TwLmV1clySZVkMfk2KqHGZpqK7VDha9uW3/M0u
43+IA0MTlcJ5KHSEQrWVyZ4dmNfYOYO2ittSWcGF/36V87I/uvm+bPBFTXwuIHQ6
O3+1XDuY0A+aRqSTaDT41xvOFvMbEAgzXe+U1wEX8zNe0ZSEzcc=
=ylOJ
-----END PGP SIGNATURE-----

--Apple-Mail=_7ADA12C3-756D-4F37-B43D-1A8598748450--


From nobody Wed Nov 22 17:18:46 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7AA1200F3 for ; Wed, 22 Nov 2017 17:18:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vszXbey04cZK for ; Wed, 22 Nov 2017 17:18:43 -0800 (PST)
Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::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 96E081200CF for ; Wed, 22 Nov 2017 17:18:43 -0800 (PST)
Received: by mail-pl0-x236.google.com with SMTP id k7so1754155pln.13 for ; Wed, 22 Nov 2017 17:18:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=U51gJQroOS87LP+L4YONcpZ/kqSnjcb6gWIKFaON5vE=; b=HRIjyVjMPQLaS5jG++bF/HppBdjYMv1i9r6CXRRr/gkDjEg+ZxM0WWK7Cizc/jOfx7 pzE4FXIiB1WcTXtJN4+9FWfN3xGRfdbR43cqMEVtsaRiF6XxrbIigXdgRdpPQOllUH2/ lQccrLNzaOkEMJ/psH2MbVhQdFpDGiQ8N3Qp8BQ2kgejn2fakUuxx3TEp0lmeHqUtV3D vkCgxeePkahEFtv3aleyItiJJjYyCKKwM4ZoZ5tky043/cW9b0lwzCow8tbSZ2cwcG6t P1z+TpJRWFd2XSyn3Z2ECvj4yehhs0PMpBhnvfjbq0L9e5Z0ao8nHHKOPP8XW14rZTiW 0L8w==
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=U51gJQroOS87LP+L4YONcpZ/kqSnjcb6gWIKFaON5vE=; b=r6XIQEDON4DEgjnI18pT2Qe0xoRu0t/FRTN36/W3XSJpgX+pxSMS+L/VdJzDn+7DWl lroqQKHPvHYlyIcQeCvWjTcrKKwLeiKS982nC6CEQVrNMSKub8k9J0lNz0atLogloVL+ auFdhB/LX99Rn5M9a0m3SrfdZeCxx4PcBPHVnR6i2u1nF9yEE8XE8rf01qRC+rvAnOoL 6PvDUu/z55XDP/udbW+eA07tq692lV7ffGLPzErb5mluOWF1pIsPA2TXif7ZFfw1aVm7 mnnxIGK786W2aCrib3FszI6A/vcutgfEbzypt9zNZ2QUCX/zX+2+FHJLBuKEYVcFJGmc GgOg==
X-Gm-Message-State: AJaThX5MjOxs7bS4RRoDcHMkc5EBviW8d/8zH8H4penO0vb11RmrkyPI av1evUidhjYWN+BgVG9Dcm9zfg==
X-Google-Smtp-Source: AGs4zMZi3mUTZIVgmdx8ED8ryFtWABDkxwz9wqj36tVmgNKKK63vJVYAeK4+6CSNBvULmj4oroudnQ==
X-Received: by 10.84.240.70 with SMTP id h6mr4549312plt.349.1511399922644; Wed, 22 Nov 2017 17:18:42 -0800 (PST)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id t6sm4536293pfl.76.2017.11.22.17.18.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Nov 2017 17:18:41 -0800 (PST)
Subject: Re: IPv6 only host NAT64 requirements?
To: Ca By , Alexandre Petrescu 
Cc: ipv6@ietf.org
References:   <787AE7BB302AE849A7480A190F8B93300A07C625@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7EE41034-132E-45F0-8F76-6BA6AFE3E916@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D481@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0C83562D-859B-438C-9A90-2480BB166737@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D534@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <26A31D20-46C2-473E-9565-59E5BA85ED8B@employees.org> <787AE7BB302AE849A7480A190F8B93300A07D63D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>   <46365c7f-f9e9-0559-9f09-d6b565ff7f99@nlogic.no> <0a13ea07-6b60-9ae6-659e-c054acdc156d@gmail.com> <2bbae231-d57e-4ba7-8ac5-65dbba9a9da2@gmail.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Thu, 23 Nov 2017 14:18:45 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Nov 2017 01:18:44 -0000

On 23/11/2017 02:52, Ca By wrote:
> On Wed, Nov 22, 2017 at 12:05 AM Alexandre Petrescu <
> alexandre.petrescu@gmail.com> wrote:
>=20
>>
>>
>> Le 22/11/2017 =C3=A0 01:01, Brian E Carpenter a =C3=A9crit :



>>>> Possibly, or even probably, introducing IPv6 (-only and NAT64) will =
even
>>>> make the situation better for a lot of people, as you get rid of all=
 the
>>>> horrible NAT solutions for services that are already dual stacked.
>>>
>>> But those horrible NAT solutions are up and running today.
>>
>> It will be noticed that on NAT64 ESSID the experience is worse than on=

>> IPv4, at least for VPN sessions.
>>
>=20
>=20
> How would the vpn service be improved? If the VPN server / peer was ipv=
6
> enabled then it would just be e2e v6, no?
>=20
> I like to refer back to Occam=E2=80=99s Razor e2e v6 rather than transi=
tion Rube
> Goldberg

I think we all agree on the long-term fix. The issue seems to be how
we can best (or least badly) deal with legacy hosts and apps that
will be out there for years, generating help desk calls or lost
business.

"Hi! Your hotel group has been removed from our corporate travel
plan because none of our employees can connect to our corporate VPN
from your hotels any more, as confirmed by your WiFi supplier."

   Brian


From nobody Thu Nov 23 10:05:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF701201F8; Thu, 23 Nov 2017 10:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2zKCcpijuJ9; Thu, 23 Nov 2017 10:05:21 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF34124D6C; Thu, 23 Nov 2017 10:05:21 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4B8412008C; Thu, 23 Nov 2017 13:07:30 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 64CD08068A; Thu, 23 Nov 2017 13:05:20 -0500 (EST)
From: Michael Richardson 
To: Fred Baker 
cc: "dhcwg\@ietf.org" , "v6ops\@ietf.org" , "6man\@ietf.org" <6man@ietf.org>
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
In-Reply-To: 
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca> 
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Nov 2017 18:05:22 -0000

--=-=-=
Content-Type: text/plain


Fred Baker  wrote:
    >> My understanding is that Fred Templin essentially wants to carry DHCP
    >> (configuration) options in ND/RA.

    > On thing that I have never understood is the lack of an RA option that
    > carries any DHCPv6 option. This entire silly debate would end if RAs
    > encompassed DHCP options.

I think that this is mostly what Fred wants to define.

Apparently he also wants to do stateful DHCPv6 things (such as PD), which I
am much less enthusiastic about putting into RAs/NDs as they cease to be
idempotent.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-




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

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

iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAloXDeAACgkQgItw+93Q
3WUREwf9EEknMV1btlM5eXBxmPuH7oO98dxeRIeGXkAaLXfJBNfkgwD3wpIiSG/C
9h1hKQE/GUBRg/OVmngMJpk67t4Tk/fO5yJHa3EilhdJ17RFYx2A8YlPEcRFhISp
pcFNYY6yGxhHJRup4VuyjEyVt6pjG1+1ETM8HE3+DrsixYKiWleNMYLnlXNh3+vv
GSC9i0MNTF6FYP57PjmdGM4m354xvPE5/XMduFru/X2x4ssybXnvs83RT5MCs3tP
xd41xSl4ZpbpbCDYe6IUu9coWtgaphAdDe6dhBgd5NCDheW8TdzANeVF75aIHf4h
IwRdOyh7m6LNAmNxBqp98o5V/X9lVg==
=kboT
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Nov 24 12:36:21 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D3E129329 for ; Fri, 24 Nov 2017 12:36:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 qTNfwNfzBcK0 for ; Fri, 24 Nov 2017 12:36:18 -0800 (PST)
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 057B0127ABE for <6man@ietf.org>; Fri, 24 Nov 2017 12:36:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511555776; x=1512160576; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=N8QCJDcY/K4KfCBo3DQtLep9h Le65IuilLFIcC7yQCk=; b=ZalaJ3b5qLl93Hjrbd4RsUSDfPT9OKpnsHzgMTkAp rI9RPpS/l0g2fDmtmVsoaj1WiZxMgkbvHPHEMQP/nmUORnBBl9E90jwvu6tqe3oF kDszUmsBg2kaZG8+nxwP2gApGZqJ7Jy6eTvjCC5ZWTJ8/sAfXu3rpteyp5ZjMhuY +U=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=cIfZSYBiNrp9kkfWF8J+Om3/75ATUeIdDJqY+ygyDJ+FnjTrDd+rUe0hv6i/ mUxJSTz5R8YrxiZCf1aU6pj8LZe2zVJM5stomV3c8WvGhUMt2KTMMIN4e tPS1ZLzkgW51Z2Eh9MEP0OXRMbys8/SdAg+WFzWJtGS2B3d2eswKjk=;
X-MDAV-Processed: mail.consulintel.es, Fri, 24 Nov 2017 21:36:16 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 24 Nov 2017 21:36:15 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005637839.msg for <6man@ietf.org>; Fri, 24 Nov 2017 21:36:14 +0100
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:171124:md50005637839::325mXMH4cQcTnsAI:0000AC1y
X-Return-Path: prvs=1501b83790=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: 6man@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Fri, 24 Nov 2017 21:36:11 +0100
Subject: FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
From: JORDI PALET MARTINEZ 
To: 
CC: , <6man@ietf.org>, 
Message-ID: 
Thread-Topic: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com>
In-Reply-To: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Reply-To: jordi.palet@consulintel.es
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Nov 2017 20:36:20 -0000

Hi,

I=E2=80=99ve posted =E2=80=9CTowards a Worldwide IPv6-Ready DNS Infrastruct=
ure=E2=80=9D

https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/

I believe this is covered by the charter of sunset4, however, it is very re=
levant as well for a recent discussion in 6man and v6ops and of course, it =
is relevant as well to dnsop.

I will love to get some inputs. I order to avoid unnecessary noise in sever=
al mail exploders, I will suggest responding only in sunset4.

Regards,
Jordi
=20


-----Mensaje original-----
De: 
Responder a: 
Fecha: viernes, 24 de noviembre de 2017, 21:30
Para: Jordi Palet Martinez , Jordi Martinez=
 
Asunto: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.=
txt

   =20
    A new version of I-D, draft-palet-sunset4-ipv6-ready-dns-00.txt
    has been successfully submitted by Jordi Palet Martinez and posted to t=
he
    IETF repository.
   =20
    Name:		draft-palet-sunset4-ipv6-ready-dns
    Revision:	00
    Title:		Towards a Worldwide IPv6-Ready DNS Infrastructure
    Document date:	2017-11-23
    Group:		Individual Submission
    Pages:		4
    URL:            https://www.ietf.org/internet-drafts/draft-palet-sunset=
4-ipv6-ready-dns-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-palet-sunset4-ip=
v6-ready-dns/
    Htmlized:       https://tools.ietf.org/html/draft-palet-sunset4-ipv6-re=
ady-dns-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-sunse=
t4-ipv6-ready-dns-00
   =20
   =20
    Abstract:
       This document defines the timing for implementing an IPv6-Ready
       global DNS infrastructure, worldwide, in order to allow the global
       IPv6-only deployment.
   =20
                                                                           =
          =20
   =20
   =20
    Please note that it may take a couple of minutes from the time of submi=
ssion
    until the htmlized version and diff are available at tools.ietf.org.
   =20
    The IETF Secretariat
   =20
   =20



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

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




From nobody Fri Nov 24 12:47:50 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5981293E8 for ; Fri, 24 Nov 2017 12:47:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6klfbYIbyR62 for ; Fri, 24 Nov 2017 12:47:41 -0800 (PST)
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 7543C1293E1 for <6man@ietf.org>; Fri, 24 Nov 2017 12:47:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511556460; x=1512161260; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:CC:Message-ID: Thread-Topic:References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=vviGiOd48ye4ysI+uuDVxaZbi wUkxB109MI4gNsNhqs=; b=G+rrLjrbgteyojoM6VLaLtG1g3E0M7pzNuULuruah 04wlvT7Malw71QveVVgPuFzdSCL+oEfz4TkWEOzUwl1mXttJ0GXXbdkA5x6Ez8/n j5trJiFKxHLJjp10zK9q0Up4HG2cgBHNkaro2dXq4e4OSfOcJJXrDen70F4Z2a3c ws=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=IHpd/kh4jaBLyhTTAEANFbMzVstEttpq6ofKUjj4f5ZdSSzXFIULv2XP6PRe O/ITDUYqcIEqQuqoWb7Tiy3knsrU+4ths8+lokHaN2UsQlfjtwkQ1a3b8 FQXC/FtCoD1DM28nZOXrscKjFt2GTbisHIyzFVl8yDLTa/HMAcgZDY=;
X-MDAV-Processed: mail.consulintel.es, Fri, 24 Nov 2017 21:47:39 +0100
X-Spam-Processed: mail.consulintel.es, Fri, 24 Nov 2017 21:47:39 +0100
Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005637852.msg for <6man@ietf.org>; Fri, 24 Nov 2017 21:47:37 +0100
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:171124:md50005637852::FH7J0s+mEQGtZX11:00000b2i
X-Return-Path: prvs=1501b83790=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: 6man@ietf.org
User-Agent: Microsoft-MacOutlook/f.27.0.171010
Date: Fri, 24 Nov 2017 21:47:33 +0100
Subject: Re: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
From: JORDI PALET MARTINEZ 
To: 
CC: , <6man@ietf.org>, 
Message-ID: <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es>
Thread-Topic: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Nov 2017 20:47:44 -0000

By the way, forgot to mention something else.

I=E2=80=99ve started also to work in a policy proposal for ICANN in order t=
o make sure that we get aligned.

Regards,
Jordi
=20

-----Mensaje original-----
De: JORDI PALET MARTINEZ 
Fecha: viernes, 24 de noviembre de 2017, 21:36
Para: 
CC: , <6man@ietf.org>, 
Asunto: FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns=
-00.txt

    Hi,
   =20
    I=E2=80=99ve posted =E2=80=9CTowards a Worldwide IPv6-Ready DNS Infrast=
ructure=E2=80=9D
   =20
    https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/
   =20
    I believe this is covered by the charter of sunset4, however, it is ver=
y relevant as well for a recent discussion in 6man and v6ops and of course,=
 it is relevant as well to dnsop.
   =20
    I will love to get some inputs. I order to avoid unnecessary noise in s=
everal mail exploders, I will suggest responding only in sunset4.
   =20
    Regards,
    Jordi
    =20
   =20
   =20
    -----Mensaje original-----
    De: 
    Responder a: 
    Fecha: viernes, 24 de noviembre de 2017, 21:30
    Para: Jordi Palet Martinez , Jordi Mart=
inez 
    Asunto: New Version Notification for draft-palet-sunset4-ipv6-ready-dns=
-00.txt
   =20
       =20
        A new version of I-D, draft-palet-sunset4-ipv6-ready-dns-00.txt
        has been successfully submitted by Jordi Palet Martinez and posted =
to the
        IETF repository.
       =20
        Name:		draft-palet-sunset4-ipv6-ready-dns
        Revision:	00
        Title:		Towards a Worldwide IPv6-Ready DNS Infrastructure
        Document date:	2017-11-23
        Group:		Individual Submission
        Pages:		4
        URL:            https://www.ietf.org/internet-drafts/draft-palet-su=
nset4-ipv6-ready-dns-00.txt
        Status:         https://datatracker.ietf.org/doc/draft-palet-sunset=
4-ipv6-ready-dns/
        Htmlized:       https://tools.ietf.org/html/draft-palet-sunset4-ipv=
6-ready-dns-00
        Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-s=
unset4-ipv6-ready-dns-00
       =20
       =20
        Abstract:
           This document defines the timing for implementing an IPv6-Ready
           global DNS infrastructure, worldwide, in order to allow the glob=
al
           IPv6-only deployment.
       =20
                                                                           =
              =20
       =20
       =20
        Please note that it may take a couple of minutes from the time of s=
ubmission
        until the htmlized version and diff are available at tools.ietf.org=
.
       =20
        The IETF Secretariat
       =20
       =20
   =20



**********************************************
IPv4 is over
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 Nov 24 19:01:05 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89281124B18 for ; Fri, 24 Nov 2017 19:00:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.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 xzfwPAbPbESg for ; Fri, 24 Nov 2017 19:00:55 -0800 (PST)
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 A2C501293FF for <6man@ietf.org>; Fri, 24 Nov 2017 19:00:55 -0800 (PST)
Received: by mail-pg0-x235.google.com with SMTP id j16so16369100pgn.9 for <6man@ietf.org>; Fri, 24 Nov 2017 19:00:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S6OI+0sSkj+VRF/0aZv1/01O1ZBFJQD/4HzKrMP9hSQ=; b=CTp3bvf5/vvskRESUNJullTiOrucoUGin166WIcswbQiwhsBydFkeRUGcnAMipH6Ho Kelgou5BTsvEgRt7Kd30dQEhepDI0jDVOvSxVhL6D0ClyKNH/+g/pPR2Ej/zo6EuxtMA A6iXAzNV0N3p9VJNcEOI21HWRvMI2w+CbNGy3hUOLna3OBYJiRbJet31RvJPH3pTwnMF eqjdmHUqkOTNimWT3oNXDRGZ2iXDwV9Pcnl0wPdHEUXaJxUKvzDjlsFrr1O9bf+SU0bL vEnsw8AnSnqLf8xaYL7UN9McLpo6bkI4DtSmYOdFBK7jJpf7ZqWWsqFoSUgHiW5zC/Lm qiqg==
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=S6OI+0sSkj+VRF/0aZv1/01O1ZBFJQD/4HzKrMP9hSQ=; b=s7JHSmlPf/40n/A7RGy+mjWJ/k7GYB4BjhP7O60VL69wA3keyJf9Zx8CKTCHuNprk1 po/m/fTneN9Y/ylUkpGryUtLx6gY/hief1/61JAeLeFYTAbcbjuoggMdx4ESPY1Ita+0 rauJBHw1WnWJby1K3MLA3nZyu6/C2321U5U0DTTJf1wtQ4FZfDjMyNoYiYocr8SoeviR NqT51YcjGcbEMtTxf8I1YmXutnYbim3CMhy0lIjzKvgYlb2JGKcm6uH5TbODiepyYAbB MG/VsX/inh9EwxSrQJS9dfWOKd+cL9sajTdV00z6N1nJixZ+Vi4PLewEkKjS0FTd6V8E yflw==
X-Gm-Message-State: AJaThX5o+Po4SYNZMa3j4teu52a8wRUORgY47aTfvu6Mrna+6GF5dE7J 6I0hdHj9YK7W9avEraBQxrFaZScsd5mppOn7iCQC1Q==
X-Google-Smtp-Source: AGs4zMaz8jY/YxvgWIW491duqWEOydasFY4T+rtQMlsNNIb7vN/IVMo2Pr1Q5QERt02sT5VwAK2nZc+UK/eAtGCFRb4=
X-Received: by 10.101.82.76 with SMTP id q12mr29896243pgp.140.1511578854927; Fri, 24 Nov 2017 19:00:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.139.5 with HTTP; Fri, 24 Nov 2017 19:00:54 -0800 (PST)
In-Reply-To: 
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> 
From: Bob Harold 
Date: Fri, 24 Nov 2017 22:00:54 -0500
Message-ID: 
Subject: Re: [DNSOP] FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
To: jordi.palet@consulintel.es
Cc: sunset4@ietf.org, IETF DNSOP WG , 6man@ietf.org, v6sop@ietf.org
Content-Type: multipart/alternative; boundary="f403043e6878b2bd67055ec5e0b5"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Nov 2017 03:00:58 -0000

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

On Fri, Nov 24, 2017 at 3:36 PM, JORDI PALET MARTINEZ <
jordi.palet@consulintel.es> wrote:

> Hi,
>
> I=E2=80=99ve posted =E2=80=9CTowards a Worldwide IPv6-Ready DNS Infrastru=
cture=E2=80=9D
>
> https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/
>
> I believe this is covered by the charter of sunset4, however, it is very
> relevant as well for a recent discussion in 6man and v6ops and of course,
> it is relevant as well to dnsop.
>
> I will love to get some inputs. I order to avoid unnecessary noise in
> several mail exploders, I will suggest responding only in sunset4.
>
> Regards,
> Jordi
>
>
>
> -----Mensaje original-----
> De: 
> Responder a: 
> Fecha: viernes, 24 de noviembre de 2017, 21:30
> Para: Jordi Palet Martinez , Jordi
> Martinez 
> Asunto: New Version Notification for draft-palet-sunset4-ipv6-
> ready-dns-00.txt
>
>
>     A new version of I-D, draft-palet-sunset4-ipv6-ready-dns-00.txt
>     has been successfully submitted by Jordi Palet Martinez and posted to
> the
>     IETF repository.
>
>     Name:               draft-palet-sunset4-ipv6-ready-dns
>     Revision:   00
>     Title:              Towards a Worldwide IPv6-Ready DNS Infrastructure
>     Document date:      2017-11-23
>     Group:              Individual Submission
>     Pages:              4
>     URL:            https://www.ietf.org/internet-
> drafts/draft-palet-sunset4-ipv6-ready-dns-00.txt
>     Status:         https://datatracker.ietf.org/
> doc/draft-palet-sunset4-ipv6-ready-dns/
>     Htmlized:       https://tools.ietf.org/html/draft-palet-sunset4-ipv6-
> ready-dns-00
>     Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-palet-sunset4-ipv6-ready-dns-00
>
>
>     Abstract:
>        This document defines the timing for implementing an IPv6-Ready
>        global DNS infrastructure, worldwide, in order to allow the global
>        IPv6-only deployment.
>
>
As much as I would like to see the transition happen,
Realistically, IPv4 will continue to 'work', for a large number of users,
for a very long time.
If you multiply your times by 10 (or more) and work hard, you might be
successful in phasing out most of IPv4 in DNS.
But forcing users to change seems like a bad idea.

I note issues like:
- Cloud providers (Amazon, Google, Azure?) only provide a private IPv4
address to virtual machines.  They use NAT to get an IPv6 address for
incoming traffic.  I don't know of any way to do IPv6 outgoing.  (I could
be wrong, still learning here.)
- Android does not support DHCPv6.
- DNS64 breaks DNSSEC.
- There are probably a large number of legacy hardware devices and software
programs that do not support IPv6, but will still be running 10 or 20 years
from now.
I expect there are many more, but those come to mind.

--=20
Bob Harold

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



=
On Fri, Nov 24, 2017 at 3:36 PM, JORDI PALET MARTINEZ <=
;jordi.pale=
t@consulintel.es> wrote:
Hi=
,



I=E2=80=99ve posted =E2=80=9CTowards a Worldwide IPv6-Ready DNS Infrastruct=
ure=E2=80=9D



https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/



I believe this is covered by the charter of sunset4, however, it is very re=
levant as well for a recent discussion in 6man and v6ops and of course, it =
is relevant as well to dnsop.



I will love to get some inputs. I order to avoid unnecessary noise in sever=
al mail exploders, I will suggest responding only in sunset4.



Regards,

Jordi







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

De: <internet-drafts@ietf.or=
g>

Responder a: <internet-draft=
s@ietf.org>

Fecha: viernes, 24 de noviembre de 2017, 21:30

Para: Jordi Palet Martinez <jordi.palet@theipv6company.com>, Jordi Martinez <jordi.palet@theipv6company.com>

Asunto: New Version Notification for draft-palet-sunset4-ipv6-ready-dn=
s-00.txt





=C2=A0 =C2=A0 A new version of I-D, draft-palet-sunset4-ipv6-ready-dns=
-00.txt

=C2=A0 =C2=A0 has been successfully submitted by Jordi Palet Martinez and p=
osted to the

=C2=A0 =C2=A0 IETF repository.



=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d=
raft-palet-sunset4-ipv6-ready-dns

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

=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Toward=
s a Worldwide IPv6-Ready DNS Infrastructure

=C2=A0 =C2=A0 Document date:=C2=A0 =C2=A0 =C2=A0 2017-11-23

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

=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4

=C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-dr=
afts/draft-palet-sunset4-ipv6-ready-dns-00.txt

=C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-palet-su=
nset4-ipv6-ready-dns/

=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-palet-sunset4-ipv6-ready-dns-00

=C2=A0 =C2=A0 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-p=
alet-sunset4-ipv6-ready-dns-00





=C2=A0 =C2=A0 Abstract:

=C2=A0 =C2=A0 =C2=A0 =C2=A0This document defines the timing for implementin=
g an IPv6-Ready

=C2=A0 =C2=A0 =C2=A0 =C2=A0global DNS infrastructure, worldwide, in order t=
o allow the global

=C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6-only deployment.



As much as I would like to see the tra=
nsition happen, 
Realistically, IPv4 will continue to 'wo=
rk', for a large number of users, for a very long time.
If yo=
u multiply your times by 10 (or more) and work hard, you might be successfu=
l in phasing out most of IPv4 in DNS.
But forcing users to change=
 seems like a bad idea.

I note issues like:
- Cloud providers (Amazon, Google, Azure?) only provide a private I=
Pv4 address to virtual machines.=C2=A0 They use NAT to get an IPv6 address =
for incoming traffic.=C2=A0 I don't know of any way to do IPv6 outgoing=
.=C2=A0 (I could be wrong, still learning here.)
- Android do=
es not support DHCPv6.
- DNS64 breaks DNSSEC.
- There a=
re probably a large number of legacy hardware devices and software programs=
 that do not support IPv6, but will still be running 10 or 20 years from no=
w.
I expect there are many more, but those come to mind.
<=
/div>

-- 
Bob Harold

<=
div>=C2=A0 


--f403043e6878b2bd67055ec5e0b5--


From nobody Sat Nov 25 11:00:41 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C73128891; Sat, 25 Nov 2017 11:00:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9paqs2D-qo6W; Sat, 25 Nov 2017 11:00:26 -0800 (PST)
Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B94E1288B8; Sat, 25 Nov 2017 11:00:24 -0800 (PST)
Received: by mail-ot0-x244.google.com with SMTP id s12so21163295otc.0; Sat, 25 Nov 2017 11:00:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7FXK9Hbsy2NvXHbs21RXBKze0r25JhyaY220NVjBj5I=; b=H08aUilHx4bXp2Hh0gIcaZoj7DH4LEzaYRSrkUkaaJqq+8g9i9Eja7uui7aAOZcBPU zEqRo+Q0xKXVh0AYWwCaZWxB31HxQzhSxlkzbi6Ml1iM2hacw37UrqM1qZglp2PAd4Gg SN7HoXpsQ4XDQeJBJts3EjpcfjqrLdmz0biq8RtuB1mjeujp8XlN7x5DjVT5m8j7BbOx 6ThPnVJZ/f6hAixHRwZO4/aTJdOl/lS6aoO6M1r239okM123vyHUD01Jm+KmLiVWpjS7 UMGGw86fCqhfYTEic0BpUN0rPVpVKzbq5K50+VBi7dCt+CTL/w8Nl4ZuLYAUhWFj+pxn ht+g==
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=7FXK9Hbsy2NvXHbs21RXBKze0r25JhyaY220NVjBj5I=; b=JNVBpkRZMeM7+lSj1Z1UEtvPAMo9vMxrwqLSEArQx35wqS9WiTEBOXDMxJXlpnGWd9 F00NCzerxoMNdKSv3TLl9BSmnmyGO76xpAcEAlI/9+RcssLWWkcU+Cgm42XuPV44Uf2P ho7S6DYkjH3m13s/6OM45SYecJ6YQ8197q+aAjLTrp3+vZa5ThPCqbkE+4EvPcrvw/fP 5iHmsV5plG33yF1vTh30vfWP7ePaGgWJSE33lcTVY5y6UdDTa7K6D53vL3afix1CxN6T 5VFbKbu0An0XCTX5TeaA06x1LEdUW6qnedPYbbEbIh30+oMo8L5uaGP3F1RLnhqVBsHh XBDQ==
X-Gm-Message-State: AJaThX6dd9F9DXJ96l0wOUIQXmFzDBzNupct/chou/PqSvChS+F0Veri HWzAxEXybOkRulE6jTYYWZ6aTkU/
X-Google-Smtp-Source: AGs4zMap2WjSCeEO/jMKuSU/gFUaQSpFW6ZlyMVAM2Twr+rhUsBEcgT83oV89mem4er0KDiZWw7j+A==
X-Received: by 10.157.25.42 with SMTP id j42mr6903047ota.348.1511636423695; Sat, 25 Nov 2017 11:00:23 -0800 (PST)
Received: from ?IPv6:2600:8802:5600:f7a::1019? ([2600:8802:5600:f7a::1019]) by smtp.gmail.com with ESMTPSA id j9sm6648182oth.31.2017.11.25.11.00.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Nov 2017 11:00:22 -0800 (PST)
From: Fred Baker 
Message-Id: <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_560B97F8-4746-470D-A2C3-5112656EC11E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
Date: Sat, 25 Nov 2017 11:00:19 -0800
In-Reply-To: <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es>
Cc: sunset4@ietf.org, dnsop@ietf.org, 6man@ietf.org, "v6ops@ietf.org WG" , Daniel Karrenberg 
To: JORDI PALET MARTINEZ 
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com>  <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Nov 2017 19:00:28 -0000

--Apple-Mail=_560B97F8-4746-470D-A2C3-5112656EC11E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Nov 24, 2017, at 12:47 PM, JORDI PALET MARTINEZ =
 wrote:
>=20
> I=E2=80=99ve started also to work in a policy proposal for ICANN in =
order to make sure that we get aligned.

One thing you might want to think about: the root servers are all =
IPv6-capable today and serve requests using IPv6, and the 1541 TLDs are =
all required by contract with ICANN to be IPv6-capable. I think you'll =
find yourself holding the burden of proof that the infrastructure isn't =
capable of IPv6-only operation today.

RSO statistics are available from http://www.root-servers.org/. ICANN =
TLDs are at https://data.iana.org/TLD/tlds-alpha-by-domain.txt.

Reading through your draft, what I see that is probably not present =
today is an IPv6 address for every SLD, which is to say names like =
"example.com".

What might be worth your while (I copy Daniel because he did a similar =
study using RIPE Atlas not too long ago and can point you to relevant =
documentation on how to do one yourself) would be to set up a RIPE Atlas =
study that accesses the Root, ccTLD, and gTLD authoritative servers =
using their IPv6 addresses and reports on the status of that from a wide =
variety of locations.

--Apple-Mail=_560B97F8-4746-470D-A2C3-5112656EC11E
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+AFAloZvcQACgkQEhdRnd2G
P+B0HhAAjOpoPOzOOJXgAKPM0i+bCxze23Cgl90TFT2eAgiMRXCgEgKd+70ExW1J
CPfwnQd2TL7iB9erucbaD9EnPyZMLatSUjxydKoGiX4E0Niq7teXlhFREG2a+VZS
3gCoTvQremntqZ9pO8yckaxPjh3BXKE5GCwTdqa4S+X0oPe8oafBnVkqBFy/xJso
QGIsPad25z8tQW/sYSh3j4lE52Hwwts6+YzNtw/J7c9Qytm3gCI+YBJ6/wv1Zp7R
esUN0kSja2Le21JxARNNkDygFx8tyxUq/FIjU/Gtca+AsFHHOdXxq/zR6RMcfAnM
a3xIHTocm0QzjsbiTJBs6HalyY7Xb3EnllBW+L/nEe1UDeqkDP77rmkAhP5hBsVl
wSyaA6reEkpURDNCHDbseRlL7Mt/erIrJe1TfJQCw3B0r3ooD843LqLHiFOPcxbB
gG0eDipbG72SfitohFsgD7N5PGae0j7b3yazvy+meaQJoD4RFcZQoOUmwV+xq4be
iYHGLtBvuuUVOA0Te0tqxAj/hUeuAb2jIdYZcCsyYFr/u33A6K9SM6rnAOeyujrh
oxznyI022Jrs7MspncO9DqwDk3w9m2Bi89RfKSp/FrpPT5FVl8+CsitZDsW0cQl3
F5QMvWuPKB0N8GY5vt1fycTbRpCmtZzVQojBkaKOg8mG0G2J4s8=
=REKM
-----END PGP SIGNATURE-----

--Apple-Mail=_560B97F8-4746-470D-A2C3-5112656EC11E--


From nobody Sat Nov 25 15:46:10 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E50127B60 for ; Sat, 25 Nov 2017 15:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3uGQ030iNN6 for ; Sat, 25 Nov 2017 15:45:57 -0800 (PST)
Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7902E127B73 for <6man@ietf.org>; Sat, 25 Nov 2017 15:45:56 -0800 (PST)
Received: by mail-io0-x230.google.com with SMTP id i38so32759925iod.2 for <6man@ietf.org>; Sat, 25 Nov 2017 15:45:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=G68r27NadI28O8vYjtH//gET3CZW+SX2XoXu1ua3LRE=; b=CEtOEOTGignHqylyzb5I3+sdWFyLric1tR/xzVhR/XLCofdhRmjla3pb33GOtreXYt RL8bLkRskJFrnhY9hAHHm67ZYPvI5vxNoYZxWp2u0T0c2zYo1P6SfQtObk3BkkYANAJv MM8UzCvyHugcEiKaG6fAsisX4zsN4C8TiR20M=
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=G68r27NadI28O8vYjtH//gET3CZW+SX2XoXu1ua3LRE=; b=OOs6N9umrqbZIYoij7YJRLB0pxP/nKK4ngIiProLYuklDGR9nJs8DESdvzkWswhqzP dkayFRs8fcnnEqFbvThcC4MnpS8QpTcAR1MhYwzfnhdYj+vvqPjwCtRvQLyLlzc29p79 myzXAtAGuAHygHHqYIA2qCAm9Llf0NdJK1xg42ROojAZ1P8kxaQJiBRkHz5UgDbbcNSw HPKDPvwuXEi3w9rZNKi21jRFtUmnkP5GP4/eATE/qkxhd2oBnu+u8FRIVfnT+v+MiJtm YdD8EgWrboo0qLh+Dz65snAgyryR/SA5L5j2P6sweozg20sjDgBEnuZ+ADayN7ZwnUjU QUNw==
X-Gm-Message-State: AJaThX5RbrjYOFWzL1QoPaHoutCmCJL3YMIZSoEdCrypAjyzSxKpq+Ia GFlxGA6xvL+C4GoM/gU2CIqvCw==
X-Google-Smtp-Source: AGs4zMbuRuIyKP/D80dRHyhwqCglS6QhrQo/TjEnWpoLtqQlKH9iFxgSB1ppUYbpr6Ed2iGhafyx9Q==
X-Received: by 10.107.198.84 with SMTP id w81mr37726401iof.151.1511653555568;  Sat, 25 Nov 2017 15:45:55 -0800 (PST)
Received: from ?IPv6:2607:f2c0:101:3:b07e:ddeb:fe18:44cf? (node-131dv5j4grjd2zso9b.ipv6.teksavvy.com. [2607:f2c0:101:3:b07e:ddeb:fe18:44cf]) by smtp.gmail.com with ESMTPSA id q6sm4972037ita.38.2017.11.25.15.45.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Nov 2017 15:45:53 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
Subject: Re: [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
From: Joe Abley 
X-Mailer: iPad Mail (15B202)
In-Reply-To: <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com>
Date: Sat, 25 Nov 2017 18:45:52 -0500
Cc: JORDI PALET MARTINEZ , dnsop@ietf.org, 6man@ietf.org, Daniel Karrenberg , "v6ops@ietf.org WG" , sunset4@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca>
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com>  <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com>
To: Fred Baker 
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Nov 2017 23:45:59 -0000

Hi Fred,

[I haven't read Jordi's draft; I'm just responding to what I've read in this=
 thread.]

On Nov 25, 2017, at 14:00, Fred Baker  wrote:

> One thing you might want to think about: the root servers are all IPv6-cap=
able today and serve requests using IPv6, and the 1541 TLDs are all required=
 by contract with ICANN to be IPv6-capable. I think you'll find yourself hol=
ding the burden of proof that the infrastructure isn't capable of IPv6-only o=
peration today.

monster:~]% egrep -c '^[A-Z]' /usr/share/misc/iso3166=20
249
[monster:~]%=20

There are potentially 249 TLDs that are not operated under any such contract=
 with ICANN, although I agree that the majority of ccTLDs have at least one n=
ameserver that is v6-capable (maybe all, but I haven't checked and I wouldn'=
t want to assume).

The important clients for all of these authoritative servers from the perspe=
ctive of end-users are resolvers. I think it's uncontroversial to suggest wi=
thout citation that not all resolvers used by end-users today are v6-capable=
, or downstream from a resolver that is v6-capable. So we are not ready to t=
urn off v4 today unless significant collateral damage is considered acceptab=
le (and surely it's not).

This is a relatively small problem to solve, though (note use of "relatively=
"). I think it would actually be practical to announce a sunset for v4 on gT=
LD and root servers at some suitable target date in the not too distant futu=
re, the implementation of which could be mainly handled within the root zone=
 itself.

Aside from the techno-political v6-deployment motivations, I think there wou=
ld be good engineering reasons to sunset v4 in root and TLD servers.

Such a move would open the door to the complete removal of v4 transport from=
 all of those servers which would eliminate them as viable amplifiers in att=
acks against v4 targets. It would also provide greater motivation to deal wi=
th any unreliability in v6 operations in the DNS or connecting networks, fra=
gmentation-related transport issues, etc which will surely otherwise see min=
imal attention so long as working v4 transport masks v6 problems.


Joe=


From nobody Sun Nov 26 19:46:56 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EAC126B7E; Sun, 26 Nov 2017 19:46:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqVSjtGXzrDZ; Sun, 26 Nov 2017 19:46:53 -0800 (PST)
Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104C81205D3; Sun, 26 Nov 2017 19:46:53 -0800 (PST)
Received: by mail-pf0-x22f.google.com with SMTP id r14so10275618pfl.11; Sun, 26 Nov 2017 19:46:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:cc:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b+E/h92+SqZYEkRaXhFKGCc9LGqaPmFi9VVYbQMMVwg=; b=D7j8PuAMffgnfUFjmF+btp8D4Iy1Eouoxtgm6XfOzgvxesO2q+70QZ/mYw458Dev5g 4Z6yoxRnRC3W/ogHJ/1++P649iiNB+0gsbuuVNzknY/s3QB6CWNfzwtcOR5IDYvvx4lN +VD964/d70bgfdZEZL6W4LfTfDQMcGMDYfxYdo29QvQSyyEvLMZukwuiXigQHSzIkJfO h6LT/3ZF3y4bNnOoGliEAFnHbdZ+FJrPAjAn5afDTCciY8ON15v5avxFNhRYhpKkTrM5 fzUjM8mV4ZIzCTu0WYCw3/u7mkd6Nkbnp/uLX251xnEmMejN1n7QeYFwENfMY/OCbULs W1GQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=b+E/h92+SqZYEkRaXhFKGCc9LGqaPmFi9VVYbQMMVwg=; b=q5rKYhR53IXS+ycXS6LalFqcbba1A/mUEq4YfyRbN7Ne6v9g7Ij3W5WPkebxIQYoC/ VK9ls/50N+C8sBf/5dFJ9GnCb2gqw4pdphDTzHmRrsiiOujdsF1j9qNWfXi+OLccRzT+ 0inN3TMCxuLdwTLPJly/zcYQOgsr5bKU6VCyXXZ6hVjhK0dZXOhMxICde7qrpiLJr2CK zgUr1RxlMhm/4kxPus3ncimaQxdiWcl1DHnzfY4Cofp1zUeorR/Z51gv8rik2TgleV8W 6bqK8ErJQKzsJ54x4bcOPXKbzk9ePIF/L0r4y+h3xKkixaL7uWYQCR7IUIVCmnenEkHs Ny1g==
X-Gm-Message-State: AJaThX46AAaARkk7cT981d89LeXhvovRO7HPUMC+UupBnxkvQvX2w/Ti zTqjsMezYK42MIkvQPENngP9Dg==
X-Google-Smtp-Source: AGs4zMYdfRPR2feAGl5noCKZhn44uhFP2ls78Z03UGK4hdR/aRIKPysSO+nZSujjFuGo6X0UH7dRTA==
X-Received: by 10.98.99.68 with SMTP id x65mr18067510pfb.56.1511754412114; Sun, 26 Nov 2017 19:46:52 -0800 (PST)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a13sm39035736pgq.10.2017.11.26.19.46.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Nov 2017 19:46:50 -0800 (PST)
From: Brian E Carpenter 
Subject: Re: [ROLL] WGLC of useof rplinfo
To: consultancy@vanderstok.org, roll@ietf.org
Cc: emarobl , Michael Richardson , 6man 
References: 
Organization: University of Auckland
Message-ID: <1bc47bb5-46b3-1268-dbcc-98ee0795a015@gmail.com>
Date: Mon, 27 Nov 2017 16:46:39 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 03:46:54 -0000

On 22/11/2017 21:56, peter van der Stok wrote:



> I have a review request for you from the ROLL WG.
> You previously reviewed useofrplinfo wrt how headers are
> inserted.  In the light of RFC8200 being published, could you access 
> whether
> useofrplinfo is inline with the new guidance as part of the useofrplinfo 
> WGLC?
> 
> Please post to the roll ML, and please cc 6man.
> 
> Many thanks,
> 
> peter

I looked at the way the hop-by-hop option is redefined here, and the
suggested use of IPv6-in-IPv6 encapsulation to attach the HbH option
to packets. To me it seems consistent with RFC 8200.

That's the only aspect I reviewed.

A couple of nits:

The phrases "IPv6-in-IPv6", "IP-in-IP" and "IPIP" occur pretty randomly
and I think it's confusing. I suggest picking one, defining it carefully
in section 2.1, and using it consistently.

> 10.  IANA Considerations
> 
>    This document updates the registration made in [RFC6553] Destination
>    Options and Hop-by-Hop Options registry from 0x63 to 0x23.
> 
> 
>   Hex Value  Binary Value
>              act  chg  rest     Description              Reference
>   ---------  ---  ---  -------  -----------------       ----------
>    0x23      00    1   00011   RPL Option                [RFCXXXX]
>    0x63      01    1   00011   RPL Option(DEPRECATED) [RFC6553][RFCXXXX]

I don't think you can *tell* IANA to do this, because the whole 8 bits
are allocated for a given use, not just the bottom 5. You can ask them to
mark 0x63 as deprecated, and request a new 00 1 xxxxx option code. You
can even suggest politely to assign 00 1 00011, but it's their decision.

Regards
   Brian


From nobody Mon Nov 27 01:44:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15447127B73; Mon, 27 Nov 2017 01:44:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR3mSPTR7SJ0; Mon, 27 Nov 2017 01:44:01 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9FAE127B5A; Mon, 27 Nov 2017 01:44:01 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5A09E280B8D; Mon, 27 Nov 2017 10:43:59 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id 53274281DB4; Mon, 27 Nov 2017 10:43:59 +0100 (CET)
Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 4C216280B8D; Mon, 27 Nov 2017 10:43:59 +0100 (CET)
Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 48B086423520; Mon, 27 Nov 2017 10:43:59 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id 3D50F40034; Mon, 27 Nov 2017 10:43:59 +0100 (CET)
Date: Mon, 27 Nov 2017 10:43:59 +0100
From: Stephane Bortzmeyer 
To: JORDI PALET MARTINEZ 
Cc: sunset4@ietf.org, dnsop@ietf.org, 6man@ietf.org, v6sop@ietf.org
Subject: Re: FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
Message-ID: <20171127094359.z3asfj72vvur27pr@nic.fr>
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
X-Operating-System: Debian GNU/Linux 9.2
X-Kernel: Linux 4.9.0-3-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bogosity: No, tests=bogofilter, spamicity=0.000077, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.27.93316
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 09:44:05 -0000

On Fri, Nov 24, 2017 at 09:36:11PM +0100,
 JORDI PALET MARTINEZ  wrote 
 a message of 54 lines which said:

> I’ve posted “Towards a Worldwide IPv6-Ready DNS Infrastructureâ€
> 
> https://datatracker.ietf.org/doc/draft-palet-sunset4-ipv6-ready-dns/

Besides the good remarks on ccTLDs that you already had (management of
ccTLDs is not ICANN's business), a few remarks:

> In general, that means having AAAA RRs in addition to A RRs,
> ensuring that PMTUD works correctly and fragmentation is correctly
> handled.

The problem is that it is not entirely in the hands of the manager of
the DNS authoritative server: the problem may be on the client
side. And it is hard for the sysadmin of an authoritative DNS server
to know if his clients received the fragments.

>   1.  Root and TLDs MUST be IPv6-Ready in 6 months.

The ICANN root is IPv6-ready for a long time. Otherwise, the
experience of Yeti draft-song-yeti-testbed-experience might be useful.

>   2.  Authoritative NS MUST be IPv6-Ready in 12 months.

At every level in the DNS tree? Noble goal but which seems completely
unrealistic. How will you convince Joe User, who manages the NS for
foo.bar.example.com to act?


From nobody Mon Nov 27 01:46:13 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B114127B5A; Mon, 27 Nov 2017 01:46:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKTG00pevSS8; Mon, 27 Nov 2017 01:46:10 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D24127B31; Mon, 27 Nov 2017 01:46:10 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id D3ADF280B8D; Mon, 27 Nov 2017 10:46:08 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id CC459281DB4; Mon, 27 Nov 2017 10:46:08 +0100 (CET)
Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id C566D280B8D; Mon, 27 Nov 2017 10:46:08 +0100 (CET)
Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id C1FB76423520; Mon, 27 Nov 2017 10:46:08 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id BBB9540034; Mon, 27 Nov 2017 10:46:08 +0100 (CET)
Date: Mon, 27 Nov 2017 10:46:08 +0100
From: Stephane Bortzmeyer 
To: Bob Harold 
Cc: jordi.palet@consulintel.es, IETF DNSOP WG , 6man@ietf.org, v6sop@ietf.org, sunset4@ietf.org
Subject: Re: FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
Message-ID: <20171127094608.2usyoujtzv2k5unx@nic.fr>
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
X-Operating-System: Debian GNU/Linux 9.2
X-Kernel: Linux 4.9.0-3-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bogosity: No, tests=bogofilter, spamicity=0.000003, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.27.93916
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 09:46:11 -0000

On Fri, Nov 24, 2017 at 10:00:54PM -0500,
 Bob Harold  wrote 
 a message of 203 lines which said:

> - DNS64 breaks DNSSEC.

That's not a fair summary. People should read RFC 6147 and 7050
before repeating this.


From nobody Mon Nov 27 01:50:33 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB1B127B31; Mon, 27 Nov 2017 01:50:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3Z5t_x6om7d; Mon, 27 Nov 2017 01:50:25 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCF6127419; Mon, 27 Nov 2017 01:50:24 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 87349281E21; Mon, 27 Nov 2017 10:50:23 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id 7ED78281E66; Mon, 27 Nov 2017 10:50:23 +0100 (CET)
Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 77DA9281E21; Mon, 27 Nov 2017 10:50:23 +0100 (CET)
Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 74B9D6423520; Mon, 27 Nov 2017 10:50:23 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id 6E6BC40034; Mon, 27 Nov 2017 10:50:23 +0100 (CET)
Date: Mon, 27 Nov 2017 10:50:23 +0100
From: Stephane Bortzmeyer 
To: Joe Abley 
Cc: Fred Baker , "v6ops@ietf.org WG" , 6man@ietf.org, Daniel Karrenberg , dnsop@ietf.org, sunset4@ietf.org
Subject: Re: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
Message-ID: <20171127095023.tv7bu2mmemj6su4d@nic.fr>
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com>  <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca>
X-Operating-System: Debian GNU/Linux 9.2
X-Kernel: Linux 4.9.0-3-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.11.27.93916
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 09:50:26 -0000

On Sat, Nov 25, 2017 at 06:45:52PM -0500,
 Joe Abley  wrote 
 a message of 28 lines which said:

> I think it's uncontroversial to suggest without citation that not
> all resolvers used by end-users today are v6-capable,

See this experience
.
It was three years ago, we can re-run it but I'm afraid it will show
that it is still the case.

Quote: "As expected, the success rate with IPv6-only domain names
(around two thirds) is much lower than with "mixed" domain names. We
are not yet ready to switch off IPv4 . If you serve a domain name only
on IPv6 name servers, you will get less traffic (and probably less
spam, too)."




From nobody Mon Nov 27 04:28:30 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6366A128961; Mon, 27 Nov 2017 04:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTWoYauQKwH6; Mon, 27 Nov 2017 04:28:20 -0800 (PST)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C330124D37; Mon, 27 Nov 2017 04:28:20 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:40409) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eJIWG-000LA0-1X (Exim 4.89) (return-path ); Mon, 27 Nov 2017 12:28:16 +0000
Date: Mon, 27 Nov 2017 12:28:16 +0000
From: Tony Finch 
To: Joe Abley 
cc: Fred Baker ,  "v6ops@ietf.org WG" , 6man@ietf.org,  Daniel Karrenberg , dnsop@ietf.org,  sunset4@ietf.org
Subject: Re: [v6ops] [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
In-Reply-To: <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca>
Message-ID: 
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com>  <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 12:28:22 -0000

Joe Abley  wrote:
>
> There are potentially 249 TLDs that are not operated under any such
> contract with ICANN, although I agree that the majority of ccTLDs have
> at least one nameserver that is v6-capable (maybe all, but I haven't
> checked and I wouldn't want to assume).

Quick root zone stats:

zones 1542
servers 4216

Most servers are dual-stacked; 539 are v4-only, and 2 are v6-only
(j.zdnscloud.com and i.zdnscloud.com).

The 31 TLDs with no v6 nameservers:

ai.
bb.
bh.
ck.
dj.
fk.
gf.
hm.
kp.
mh.
mil.
mp.
mq.
mv.
ni.
pf.
pk.
sl.
sr.
st.
to.
uz.
ws.
xn--l1acc.
xn--lgbbat1ad8j.
xn--mgba3a4f16a.
xn--mgbai9azgqp6j.
xn--wgbh1c.
xn--ygbi2ammx.
ye.
zw.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Biscay, Fitzroy: Variable 3 or 4 until later in south, otherwise westerly 5 or
6, veering northwesterly 4 or 5, except in south Fitzroy, becoming
northeasterly 5 or 6 in southeast Fitzroy. Slight at first in south, ohterwise
moderate or rough. Rain or squally showers. Moderate or good.


From nobody Mon Nov 27 05:20:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CC0128AFE; Mon, 27 Nov 2017 05:20:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wIpzy-m9KGxs; Mon, 27 Nov 2017 05:20:29 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213471286B1; Mon, 27 Nov 2017 05:20:29 -0800 (PST)
Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id vARDJMcf026239; Mon, 27 Nov 2017 08:20:24 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2egjx9rsvq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Nov 2017 08:20:24 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vARDKNDj018396; Mon, 27 Nov 2017 08:20:23 -0500
Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vARDKEIc018320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Nov 2017 08:20:16 -0500
Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi132.aldc.att.com (RSA Interceptor); Mon, 27 Nov 2017 13:19:55 GMT
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.227]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0361.001; Mon, 27 Nov 2017 08:19:54 -0500
From: "STARK, BARBARA H" 
To: Fred Baker , Michael Richardson 
CC: "dhcwg@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>
Subject: RE: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgAkcdkAADO+44AADW0NAAAPizUAANmFatA=
Date: Mon, 27 Nov 2017 13:19:54 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DCC2BF8@GAALPA1MSGUSRBF.ITServices.sbc.com>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.70.217.252]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-27_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711270184
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 13:20:31 -0000

> > My understanding is that Fred Templin essentially wants to carry DHCP
> > (configuration) options in ND/RA.
>=20
> On thing that I have never understood is the lack of an RA option that ca=
rries
> any DHCPv6 option. This entire silly debate would end if RAs encompassed
> DHCP options.

Thus forcing either routers or hosts (or both) to support two distinct mech=
anisms to do the same thing if there is to be any hope of interoperability.=
 And if the host supports both, then it also needs to implement code for wh=
ich wins when both are present and the options provided have conflicting in=
fo.
If you really want DHCPv6 options in RAs for closed ecosystem use cases, in=
clude a huge caveat that routers are not required to support both mechanism=
s -- routers are only required to do DHCPv6. Any host that only implements =
receipt of DHCPv6 options via RA must not expect to operate in an open ecos=
ystem. Put the burden on the hosts.=20
Barbara


From nobody Mon Nov 27 09:30:40 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE0B128854; Mon, 27 Nov 2017 09:30:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6Pcp5-GpXwb; Mon, 27 Nov 2017 09:30:27 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F19F126557; Mon, 27 Nov 2017 09:30:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vARHUPb9004287; Mon, 27 Nov 2017 10:30: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-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vARHUKLa003882 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 27 Nov 2017 10:30:20 -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, 27 Nov 2017 09:30:19 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Mon, 27 Nov 2017 09:30:19 -0800
From: "Templin, Fred L" 
To: Fred Baker , Michael Richardson 
CC: "dhcwg@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>
Subject: RE: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgAkcdkAADO+44AAEoFNVADsr44Q
Date: Mon, 27 Nov 2017 17:30:19 +0000
Message-ID: 
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca> 
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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 17:30:28 -0000

Hi Fred,

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fred Baker
> Sent: Wednesday, November 22, 2017 4:19 PM
> To: Michael Richardson 
> Cc: dhcwg@ietf.org; v6ops@ietf.org; 6man@ietf.org
> Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified =
function
>=20
>=20
>=20
> > On Nov 22, 2017, at 8:53 AM, Michael Richardson =
 wrote:
> >
> > My understanding is that Fred Templin essentially wants to carry DHCP
> > (configuration) options in ND/RA.
>=20
> On thing that I have never understood is the lack of an RA option that ca=
rries any DHCPv6 option. This entire silly debate would end if
> RAs encompassed DHCP options.

Yes, that is what the draft says. The client's DHCPv6 request messages are
included in RS options, and the server's DHCPv6 reply messages are included
in RA options. A unified IPv6 ND/DHCPv6 autoconfiguration service.

As near as I can tell, everyone wants prefix delegation which is by nature
a stateful service. Some seem to be questioning DHCPv6 as the correct
architecture for the stateful service, but if not DHCPv6 then there would
need to be a new prefix delegation architecture - perhaps a design from
scratch. But, when all is said and done, it would end up looking very much
like DHCPv6.

Thanks - Fred=20


From nobody Mon Nov 27 09:58:57 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECB5128D69 for ; Mon, 27 Nov 2017 09:58:51 -0800 (PST)
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=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_Rso36p2gTb for ; Mon, 27 Nov 2017 09:58:51 -0800 (PST)
Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B3A1292AE for <6man@ietf.org>; Mon, 27 Nov 2017 09:58:49 -0800 (PST)
X-Original-To: 6man@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 33D854412C for <6man@ietf.org>; Mon, 27 Nov 2017 18:58:47 +0100 (CET)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 1F86341B96; Mon, 27 Nov 2017 18:58:47 +0100 (CET)
Received: by moebius4.space.net (Postfix, from userid 1007) id 10D791BFA7; Mon, 27 Nov 2017 18:58:47 +0100 (CET)
Date: Mon, 27 Nov 2017 18:58:46 +0100
From: Gert Doering 
To: Tony Finch 
Cc: Joe Abley , "v6ops@ietf.org WG" , 6man@ietf.org, Daniel Karrenberg , dnsop@ietf.org, sunset4@ietf.org
Subject: Re: [v6ops] [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
Message-ID: <20171127175846.GH45648@Space.Net>
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com>  <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> 
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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 17:58:51 -0000

Hi,

On Mon, Nov 27, 2017 at 12:28:16PM +0000, Tony Finch wrote:
> The 31 TLDs with no v6 nameservers:
[..]

> mil.

Yay.  Like, IPv6 mandate, and all that.

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 Nov 27 10:09:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5724B1242F5 for ; Mon, 27 Nov 2017 10:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zckS5zTr8Xm2 for ; Mon, 27 Nov 2017 10:09:24 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B43128D6F for <6man@ietf.org>; Mon, 27 Nov 2017 10:09:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vARI9OAt009741; Mon, 27 Nov 2017 11:09:24 -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 vARI9ExK009314 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 27 Nov 2017 11:09:14 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 27 Nov 2017 10:09:13 -0800
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1320.000; Mon, 27 Nov 2017 10:09:13 -0800
From: "Manfredi, Albert E" 
To: Gert Doering 
CC: "6man@ietf.org" <6man@ietf.org>
Subject: RE: [v6ops] [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
Thread-Topic: [v6ops] [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
Thread-Index: AQHTZ3tNOpWBkJt6aE2GrGbUNCkopaMpCeMA//97OvA=
Date: Mon, 27 Nov 2017 18:09:13 +0000
Message-ID: 
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com>  <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca>  <20171127175846.GH45648@Space.Net>
In-Reply-To: <20171127175846.GH45648@Space.Net>
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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 18:09:26 -0000

-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Gert Doering

On Mon, Nov 27, 2017 at 12:28:16PM +0000, Tony Finch wrote:
>> The 31 TLDs with no v6 nameservers:
>> [..]
>>
>> mil.
>
> Yay.  Like, IPv6 mandate, and all that.

Heh heh.

Perversely, when/if IPv4 really does phase out, IPv4-only could become a "s=
ecurity feature."

Bert



From nobody Mon Nov 27 11:41:54 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2902C12706D for ; Mon, 27 Nov 2017 11:41:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ybpLJWsMCzqY for ; Mon, 27 Nov 2017 11:41:50 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E28127010 for ; Mon, 27 Nov 2017 11:41:50 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id a84so17847385pfl.0 for ; Mon, 27 Nov 2017 11:41:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ICyE17+Us90Y64fQsfysOFSKPU2oRClpN4VyTlE1eOI=; b=GWmxm0RHWU+6E4Z7Y4F0vO+wGjXoLVCsHvuI9WhIYDQ6f5OvsIxv5IJXfLmCdu2kSi DdT5R+VyYegr/mATlub4q1r5qRdtcLjLOVpSBtpB8OPRDOWSulwrE59xhQTyJxB75Gc7 huj/l7jnXhTQKLmYvkfuJL9tzJ/ulOMjja8FFXEku50ErJRuwn8fW/9MFdahZErHQhfy JQARgDtlhXZ/qJC+et4489baJsaocLzboG8qyD+KFvAjNj/0VfQIRKiUo8LTfwKduNSo blU3UHaTBVjX7KAycREPKyDZHPT99XKvS2x+zzcuHQabYp/6qCORCSqABUmDSLkfG0K1 vKgA==
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=ICyE17+Us90Y64fQsfysOFSKPU2oRClpN4VyTlE1eOI=; b=H3arSHT3UOxrEGK3VOY02zCBWHtYR72oQ/0six1HUfEG1JsBinOpZKb1SguZbvZ2xP B8ABI+AYZ2/RkAvtO+wiEW+91de+lvmfpBSaXMZAjeFQLE63SttcadThCoqtLjF5zAEe TrqjJ93ivJIGWeojuJp0W6hhxhPNZ+SjbnWDgFJWeyR2ULZhK2VwbghwTbi4xIv67UhF 41d7Z+ZstNbZ4J+Ck569USr2yM3RReGXfRa9M/W/pJybHkT6qkOe2XrpfIUsnN7lleBN KT1T1KCY0+sH6s4ejgWs7DuilIUHgp29oS2zJ6zaCVfSYS25GocmvDa58g9+SM63um0B PcUA==
X-Gm-Message-State: AJaThX7JCQob3rldVXuWFtrA1YPlh+obng81jy0SAbLl7DLEjtT2lsyP b12bON/lTSMKsh0MZDawc5cwwg==
X-Google-Smtp-Source: AGs4zMbrOfXVrt14VxAZKDefA5Bx+FEHr/bxyYQILF6F/o65BLU5fXSwuxGrtfYZ6Y481oJVP6dvTg==
X-Received: by 10.101.90.71 with SMTP id z7mr31613707pgs.14.1511811709560; Mon, 27 Nov 2017 11:41:49 -0800 (PST)
Received: from ?IPv6:2620::10e7:8:81aa:ef31:38e6:6aaa? ([2620:0:10e7:8:81aa:ef31:38e6:6aaa]) by smtp.gmail.com with ESMTPSA id b8sm27000327pff.26.2017.11.27.11.41.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 11:41:48 -0800 (PST)
From: james woodyatt 
Message-Id: <923B5965-B31D-4EB5-9ADC-4AA052C21CA9@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_787132CE-CFA1-43FB-8EB3-E815C00A14F6"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
Date: Mon, 27 Nov 2017 11:41:47 -0800
In-Reply-To: 
Cc: IPv6 List 
To: Erik Kline 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 19:41:52 -0000

--Apple-Mail=_787132CE-CFA1-43FB-8EB3-E815C00A14F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 18, 2017, at 05:12, Erik Kline  wrote:
>=20
> Operating Systems that implement IPv4 link-local communications =
(Android does not) might use this signal to disable that as well.

Dear Apple and Microsoft: please do not do that or you will break Nest =
Weave pairing on your handsets in networks where IPv6 multicast is =
blocked at the Wi-Fi access point. We fall back to IPv4 link-local =
broadcast when we can=E2=80=99t use IPv6 link-local multicast for =
service discovery.


--james woodyatt >




--Apple-Mail=_787132CE-CFA1-43FB-8EB3-E815C00A14F6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 18, 2017, at 05:12, Erik Kline <ek@google.com> wrote:

Operating Systems that implement IPv4 =
link-local communications (Android does not) might use this signal =
to disable that as well.

Dear Apple and Microsoft: please do not do that or =
you will break Nest Weave pairing on your handsets in networks where =
IPv6 multicast is blocked at the Wi-Fi access point. We fall back to =
IPv4 link-local broadcast when we can=E2=80=99t use IPv6 link-local =
multicast for service discovery.




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_787132CE-CFA1-43FB-8EB3-E815C00A14F6--


From nobody Mon Nov 27 12:14:21 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998D41293EB for ; Mon, 27 Nov 2017 12:14:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Q9UShv-4QMZF for ; Mon, 27 Nov 2017 12:14:19 -0800 (PST)
Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::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 EF33D1293E4 for ; Mon, 27 Nov 2017 12:14:18 -0800 (PST)
Received: by mail-pl0-x22b.google.com with SMTP id 61so9169364plf.4 for ; Mon, 27 Nov 2017 12:14:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KRfoKIp4aWkKEnkVbGSMt5AbR+dzSsz7VBv1BMyx3nM=; b=QCVa+oT7BcBlIxRurMtAYzcqWsdysRMx1luLHiGE2GKxPsqLlSAbd6FzHJyY7KQrp0 Kzhi82ZBT5fYQDzeGn8yowetsgmuo9adrGY8VIeuWbgCgGx1y4uv0liRV/1MSh4RlpPd vqKIWJ2e1nKeHGs60cXft1Y4UVW3pLql72VMJhEq/N9P/H9LHfhbp63IJUHw9Lrb6ioc 6L/A+58c7o7XzSdAhaVvwIz57t+9xAedGEzzMf2dW00BW1k8nGHMnbEQ13g/MNcW++hj D1zM26g6KMcHomsTuRi2z4k2FAA9xRVDLnMmh/wHP4AhRhdzpsVxn/BEJ5l6y6+qotLc ZC/Q==
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=KRfoKIp4aWkKEnkVbGSMt5AbR+dzSsz7VBv1BMyx3nM=; b=s089asYzj5WBa8xwuTWZq94EKoH9w90HyX6yO/Vg69YLFpVvBmxTR6l4XQOL4qxL19 Rfr6otKDzHYdQeG/MsWgrPGo+U9GvqhhqBNRVWuis+/V3zquJcZGTo2xh4WqDkdYplbH JAcJK5BZhuKgswWTtNdIC7GWbFZFeYQiINhdZ/5iiVzsPI+usJTh23gtKS/Kt59uIXvX qmq3U66ndaNMrmmnfB5SZR88L8oeK+7M5eSj0K2I443PFBSvBAF7DXLRHXI42HfRzBeo 8Re8k96ebnbSfoMjtGMDQofBY5wCLXwIYqtmGhha7FOqsOF99TxTfFGDp+HIZPb5lDgg /aOw==
X-Gm-Message-State: AJaThX4tkvxgDhJ9k07fdTOXICJs0/nGHeVAjxtAXPX1jvqbSBk0qDji oJ4h6XmtstSjFTN7BUavOvhCnQ==
X-Google-Smtp-Source: AGs4zMbbIyVY3SpqQIwax6FJcmGl6CxacgKsO8ivHzqQFOzNFHhaPuV+zrD7GxmQpQeXg6KPrE0oHQ==
X-Received: by 10.159.218.152 with SMTP id w24mr38128919plp.336.1511813658060;  Mon, 27 Nov 2017 12:14:18 -0800 (PST)
Received: from ?IPv6:2620::10e7:8:81aa:ef31:38e6:6aaa? ([2620:0:10e7:8:81aa:ef31:38e6:6aaa]) by smtp.gmail.com with ESMTPSA id p19sm53302326pfj.140.2017.11.27.12.14.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 12:14:17 -0800 (PST)
From: james woodyatt 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_2609D9C6-9E0B-4CD9-B1B2-D3E13F8DA6C1"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: New Version Notification for draft-hinden-ipv4flag-00.txt
Date: Mon, 27 Nov 2017 12:14:16 -0800
In-Reply-To: 
Cc: IPv6 List 
To: Jen Linkova 
References: <151090059151.22321.3357672601322845792.idtracker@ietfa.amsl.com>  
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 20:14:20 -0000

--Apple-Mail=_2609D9C6-9E0B-4CD9-B1B2-D3E13F8DA6C1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On Nov 18, 2017, at 06:39, Jen Linkova  wrote:
>=20
> It looks to me that when you are saying 'there is no IPv4 support on a =
link' you mean 'a router does not provide IPv4 connectivity'.  However =
it still might be IPv4 connectivity within the given broadcast domain =
and the router has nothing to do with it.

Indeed, and this is an important to distinction to bear in mind. I hope =
everyone involved in this discussion remembers it.

> If the problem is 'IPv4 broadcast noise on the link' then it should be =
solved on L2 level and the network should not switch ethertype 0x0800.

Better would be not to switch Ether Type 0x806 when the PTYPE=3D0x800. =
Or it should reject configuration via IPCP. Or or or...

> If the problem is 'all those noisy DHCPv4 requests the first-hop =
router has to drop because DHCP relay is not configured' then the router =
interface should not accept IPv4 packets at all, problem solved.


If the problem is noisy hosts using IPv4 group communication for mDNS =
and DHCP discovery, then the problem is the same as =E2=80=9CIPv4 =
broadcast noise on the link=E2=80=9D and it should be handled the same =
way.

If you want to stop link-local IPv4 communication on the link, the right =
way to do that is by blocking ARP with PTYPE=3D0x800, and probably some =
kind of ARP packet that specifically tells IPv4 implementations that =
this network will never deliver an ARP packet with PTYPE=3D0x800 to a =
host so it can stop trying.

If you want to stop noisy hosts trying to reach Internet via IPv4 via an =
unprovisioned route, then the right way to tell them to shut them up is =
to decline DHCP requests for IPv4 default router address, and tell host =
operating system developers that when the only DHCP server on the link =
is declining to configure any IPv4 default router address, it=E2=80=99s =
not a misconfiguration: the network really means it, there is no default =
IPv4 router. (In the PPP case, provide only an IPv4 link-local address.)


--james woodyatt >




--Apple-Mail=_2609D9C6-9E0B-4CD9-B1B2-D3E13F8DA6C1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

On Nov 18, 2017, at 06:39, Jen Linkova <furry13@gmail.com> =
wrote:

It looks to me that =
when you are saying 'there is no IPv4 support on a link' you mean 'a =
router does not provide IPv4 connectivity'. =
 However it still might be IPv4 connectivity =
within the given broadcast domain and the router has nothing to do with =
it.

Indeed, and this is an important to distinction to =
bear in mind. I hope everyone involved in this discussion remembers =
it.

If the problem is 'IPv4 broadcast noise on the =
link' then it should be solved on L2 level and the network should =
not switch ethertype 0x0800.

Better =
would be not to switch Ether Type 0x806 when the PTYPE=3D0x800. Or it =
should reject configuration via IPCP. Or or or...

If the problem is =
'all those noisy DHCPv4 requests the first-hop router has to drop =
because DHCP relay is not configured' then the router interface =
should not accept IPv4 packets at all, problem solved.

If the problem is noisy hosts using =
IPv4 group communication for mDNS and DHCP discovery, then the problem =
is the same as =E2=80=9CIPv4 broadcast noise on the link=E2=80=9D and it =
should be handled the same way.

If you want to stop link-local IPv4 =
communication on the link, the right way to do that is by blocking ARP =
with PTYPE=3D0x800, and probably some kind of ARP packet that =
specifically tells IPv4 implementations that this network will never =
deliver an ARP packet with PTYPE=3D0x800 to a host so it can stop =
trying.

If you =
want to stop noisy hosts trying to reach Internet via IPv4 via an =
unprovisioned route, then the right way to tell them to shut them up is =
to decline DHCP requests for IPv4 default router address, and tell host =
operating system developers that when the only DHCP server on the link =
is declining to configure any IPv4 default router address, it=E2=80=99s =
not a misconfiguration: the network really means it, there is no default =
IPv4 router. (In the PPP case, provide only an IPv4 link-local =
address.)




--james woodyatt <jhw@google.com>







=

--Apple-Mail=_2609D9C6-9E0B-4CD9-B1B2-D3E13F8DA6C1--


From nobody Mon Nov 27 14:30:14 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D380127077; Mon, 27 Nov 2017 14:30:00 -0800 (PST)
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 KH2S5UzUOr9Z; Mon, 27 Nov 2017 14:29:59 -0800 (PST)
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 25D081200C5; Mon, 27 Nov 2017 14:29:59 -0800 (PST)
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 E7B8C3B9A22; Mon, 27 Nov 2017 22:29:56 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A758E160048; Mon, 27 Nov 2017 22:29:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8FC53160070; Mon, 27 Nov 2017 22:29:56 +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 8uek7jRJZ179; Mon, 27 Nov 2017 22:29:56 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9A94C160048; Mon, 27 Nov 2017 22:29:54 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
From: Mark Andrews 
In-Reply-To: <20171127094608.2usyoujtzv2k5unx@nic.fr>
Date: Tue, 28 Nov 2017 09:29:51 +1100
Cc: Bob Harold , IETF DNSOP WG , 6man@ietf.org, v6sop@ietf.org, sunset4@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <04ECB158-1EF1-4CEF-937F-65048B10F2F5@isc.org>
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com>   <20171127094608.2usyoujtzv2k5unx@nic.fr>
To: Stephane Bortzmeyer 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 22:30:01 -0000

DNS64 requires EVERY validating client to support DNS64 prefix discover =
and
implement DNS64.  If that isn=E2=80=99t breaks DNSSEC I don=E2=80=99t =
know what is.

> On 27 Nov 2017, at 8:46 pm, Stephane Bortzmeyer  =
wrote:
>=20
> On Fri, Nov 24, 2017 at 10:00:54PM -0500,
> Bob Harold  wrote=20
> a message of 203 lines which said:
>=20
>> - DNS64 breaks DNSSEC.
>=20
> That's not a fair summary. People should read RFC 6147 and 7050
> before repeating this.
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

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


From nobody Mon Nov 27 14:31:29 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1E41293F9; Mon, 27 Nov 2017 14:31:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAvNQxRNPa50; Mon, 27 Nov 2017 14:31:26 -0800 (PST)
Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230D2126DC2; Mon, 27 Nov 2017 14:31:26 -0800 (PST)
Received: by mail-pl0-x22d.google.com with SMTP id 62so9361115plc.7; Mon, 27 Nov 2017 14:31:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BTuGH5y2wiOLoZuhjCh+bW/jVeqjqQ9GuUPoB8YDA48=; b=exp39JfuezshD4ns3VmqnP8aB13KMM+0TcOIP2VnOCzhw3S9dnKSwfJTT4A8zZJpow cyjfrMvbJuJCmEkWdNP5r1ikHcMpmgxV7VhvSSautW99lMHLVv4yKWDx8qUu8FzkIWMw 8TWFW0byifqVwE5FgKnbKsQoa6IW4Up8YBvLH1QPfUmyO/9S78DFupfzIifHLjmZ4hRg QAdLg6zPPBhcqh4pe5+M81k1uUHVVagZdoiWk6B7W/13Eb/AF3n409mOQhBr9GS230+E OtxUzXidHJwVQRqY7+marjlw+b/OkUwoJ3LBHHbGfWBZugo8KQz47p+6IezHCmL+llru rQdg==
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:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=BTuGH5y2wiOLoZuhjCh+bW/jVeqjqQ9GuUPoB8YDA48=; b=a7TUfc0ANTqNutltRbDK0zPLT9yFRDiJez/OKPIWviuKyJRBk9OeG5wR3zHUyqqW7+ mMiytBQnOxktzPVBYlhgxt/Z4Sjn/zZhC3yGseMSl1/1YaLRSBlF/oo9QWz76vXDtbxC kvX1iuqmIcJ+QXv98sLxMGs4WvZ6NivJOZ2agAV4GcDWqjG2vikY3iEASvbGH2FrQ+7Q t7SQvQJdohVE/G6iKGokO2Ft4kUGbzb5Sg1x2UkmjTnbCryjZh9ZkKDQ+uZjqZai2nTX a2bi5OwX2FPt/aE0j5oqjFHzv2BJn9J2QTu2F2o9NTT1DAaro3Q7IbH1v/N3V6lPuFn7 LFow==
X-Gm-Message-State: AJaThX5b/vt6TL6aH/fJQo0ys6QDYWKYUB6CSmqQBOYJK6BJf6LzZB8N UyJRDvzsv6mOKkXGUqU/TgHL6Q==
X-Google-Smtp-Source: AGs4zMZBwWVQ7pXUPyzvoVj0S0iNrTjnoklJMewFpe5fujTAQ4qPtrmwIjE8fqGwdJbD4+7wIRKV4g==
X-Received: by 10.159.252.131 with SMTP id bb3mr38953852plb.68.1511821885263;  Mon, 27 Nov 2017 14:31:25 -0800 (PST)
Received: from [130.216.38.112] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.112]) by smtp.gmail.com with ESMTPSA id f83sm57008753pfj.23.2017.11.27.14.31.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 14:31:24 -0800 (PST)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: draft-voyer-6man-extension-header-insertion@ietf.org
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com>
Cc: 6man 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>
Date: Tue, 28 Nov 2017 11:31:23 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <151120281628.21912.1099097760493570225@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 22:31:28 -0000

Hi,

I'm probably repeating myself, but it seems clear that this draft
in its present form will never get anywhere. Firstly I will try to
justify this statement, and secondly I'll try to make some
constructive suggestions.

I. The problems with the current draft:

I.1. No RFC is allowed to have more than five authors without
an extremely good reason. If six or seven people have contributed 
roughly equal amounts you might just be able to persuade the
RFC Editor to list everybody, but 18? Never.
https://tools.ietf.org/html/rfc7322#section-4.1.1

I.2. More serious is the tone, which starts with the Abstract.
"The network operator and vendor community has clearly indicated..."
is, to put it mildly, out of place in an IETF document. We work
by facts and rough consensus, not by declarations by vested
interests. I think a lot of people will simply stop reading
the draft after that sentence.

The tone needs to be rational and factual argument about why
the proposed mechanism is both desirable and harmless. The
abstract needs to be a factual summary.

I.3. A detail is that since this draft recommends ignoring
a rule in RFC 8200, it needs to be aimed at the standards
track with Updates: 8200.

I.4. Another detail is that in some places the draft seems
to assume that only segment routing headers will be
candidates for insertion. That may be true today, but
probably not for ever.

II. Constructive suggestions.

I understand that the idea is to propose that this rule
in https://tools.ietf.org/html/rfc8200#section-4 :

"  Extension headers (except for the Hop-by-Hop Options header) are not
   processed, inserted, or deleted by any node along a packet's delivery
   path, until the packet reaches the node (or each of the set of nodes,
   in the case of multicast) identified in the Destination Address field
   of the IPv6 header."

MAY be ignored within an administrative domain for packets that
terminate within that domain. If that's the intention, I think
there are several logical steps in the argument that need to
be laid out. A lot of the ideas are already in the draft; this
is mainly about making a clear and logical case that the whole
community can understand.

1. Introduction, outline of use cases [1].
2. Precise definition of a domain and of its boundary, ingresses and egresses.
3. Explanation of how the class of packets eligible for header insertion are identified [2].
4. Explanation of how the well-known issues are avoided (PMTUD, fragmentation, IPSec).
5. Clear statement of what header manipulations are allowed and which devices may perform them.
6. Precise statement of which text in RFC 8200 is updated.
7. Security considerations 

[1] More details on use cases could be an appendix. 

[2] https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02#section-3 
is IMHO correct as far as transit packets go. But it
should be presented as a mainstream part of the proposal,
not as an example.

I hope this is helpful.
   Brian Carpenter



On 21/11/2017 07:33, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : Insertion of IPv6 Segment Routing Headers in a Controlled Domain
>         Authors         : Daniel Voyer
>                           Daniel Bernier
>                           John Leddy
>                           Clarence Filsfils
>                           Darren Dukes
>                           Stefano Previdi
>                           Stefano Salsano
>                           Antonio Cianfrani
>                           David Lebrun
>                           Olivier Bonaventure
>                           Prem Jonnalagadda
>                           Milad Sharif
>                           Hani Elmalky
>                           Ahmed Abdelsalam
>                           Robert Raszuk
>                           Arthi Ayyangar
>                           Dirk Steinberg
> 	Filename        : draft-voyer-6man-extension-header-insertion-02.txt
> 	Pages           : 14
> 	Date            : 2017-11-20
> 
> Abstract:
>    The network operator and vendor community has clearly indicated that
>    IPv6 header insertion is useful and required.  This is notably the
>    case when the entire journey of the packet remains in its source
>    domain.  In such a context, it does not matter where the extension
>    header is inserted.  The source domain may decide to place the IPv6
>    extension header insertion where it suits its best: at the source of
>    the packet or at any midpoint within the source domain.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02
> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> 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 Nov 27 15:07:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30BC127735; Mon, 27 Nov 2017 15:07:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wryXlkIsDVYX; Mon, 27 Nov 2017 15:07:08 -0800 (PST)
Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA6A129418; Mon, 27 Nov 2017 15:06:56 -0800 (PST)
Received: by mail-pl0-x232.google.com with SMTP id 62so9415272plc.7; Mon, 27 Nov 2017 15:06:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=KN56Uo02hyqoy7mK57VNlb9KSTcib0rnDbdDpRsYXi0=; b=S29vQqaDaksWPkiemhFbezQ76pK7zvpilp1EshSkk5YXXWUD9QoaXPJaZPrl9KihlJ e7zAVnIjx13oBN52AINeDYdD/XZQV923uuWI2ZztfjagcEKMtiwd1icjVHK22edUL71M kXKkhIbzt2F3inLgO2cPU0rcXPMFF/NT6nG7wXgOIsDXyikbEh466ZrlKoAcTEv0TkCs BfYX6DDvBGMxSp6FB0vdbgRJixym+X11T8jZK7hqS8GI3r2BQ0obd4Jp1lB8O6AXdQUt DJObLTYaGvP+uXrvGtIGN5NhxcSoY6nsk7pgeGswCdWkpcjt8m+1l/LtNOfnA0PS8FTh kuqw==
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=KN56Uo02hyqoy7mK57VNlb9KSTcib0rnDbdDpRsYXi0=; b=KcSVU+pEQFnY3npBSLzblELVV3f8PCvk2f//fHXdemEuATAjbheL9SHHO9AujaLAeV dMJxYHRji3bkkJ/7+fieZkudcqU1wiksMQIJvLxyR6ieej5VKNmubPhJBdo51UG+8q2t K0KsIa0w03JSU7PQxNdHbkhRrTXwQ/1tfcUN6FZPP/FYwwUbpyI+YD6gKlbJMqe0Tmz0 /1wPfvb0P7FJUZ5ZT2eHUNlLN1E+fr9JIK+FBsPhA/vt8vMrfSoKnJy5fKBYOPGmfmg7 EVLamUCofH9hcCdHiDgojKwYO0CGWWLCBfBBFHTNiIKneSpfJVlI+UK3BJkjyMw3wy3N qOdg==
X-Gm-Message-State: AJaThX6y9xDeAw7YpQBHfeWgz0GZ6nF/xke9r3Ze2R+Xzbe5DlPB9r+E Dq5JUA34D21OVMNF/f7vDD1MJQ==
X-Google-Smtp-Source: AGs4zMZCzaje/gkmtqxmNqBU5QmW/rKQXMt6yJA0yX806ZExQ2ui/HoLv0oJ6VzHfuCDau0V4ADMmQ==
X-Received: by 10.84.248.77 with SMTP id e13mr40917370pln.200.1511824015875; Mon, 27 Nov 2017 15:06:55 -0800 (PST)
Received: from [130.216.38.112] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.112]) by smtp.gmail.com with ESMTPSA id k130sm17438416pfc.100.2017.11.27.15.06.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 15:06:55 -0800 (PST)
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: "STARK, BARBARA H" , Fred Baker , Michael Richardson 
Cc: "dhcwg@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca>  <2D09D61DDFA73D4C884805CC7865E6114DCC2BF8@GAALPA1MSGUSRBF.ITServices.sbc.com>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <8a5feb3a-d18e-1773-0539-3da22e582c70@gmail.com>
Date: Tue, 28 Nov 2017 12:06:53 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCC2BF8@GAALPA1MSGUSRBF.ITServices.sbc.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 23:07:10 -0000

On 28/11/2017 02:19, STARK, BARBARA H wrote:
>>> My understanding is that Fred Templin essentially wants to carry DHCP
>>> (configuration) options in ND/RA.
>>
>> On thing that I have never understood is the lack of an RA option that carries
>> any DHCPv6 option. This entire silly debate would end if RAs encompassed
>> DHCP options.
> 
> Thus forcing either routers or hosts (or both) to support two distinct mechanisms to do the same thing if there is to be any hope of interoperability. 

Yes and no. Let's consider a host that needs a particular piece of
information. As an example, consider the address of the next-hop router
for a given prefix. There are three separate parts to this:

1. Receiving some sort of message containing an appropriate option.
2. Decoding the option
3. Storing the result.

The important one is #3. The mechanism for storing the result
is unavoidable, and stateful, whatever the delivery protocol
and encoding.

In the real world, most hosts today have several versions of
#1 in their code: RA, DHCP, RADIUS come to mind. (What they
enable is another matter.)

So where's the duplication? It seems to be in the decoding
step. With a little software engineering, there could be
a single decoder that handles all the possible formats, and
doesn't care which protocol delivered it.

> And if the host supports both, then it also needs to implement code for which wins when both are present and the options provided have conflicting info.

I suspect that is needed anyway, in the general case.

> If you really want DHCPv6 options in RAs for closed ecosystem use cases, include a huge caveat that routers are not required to support both mechanisms -- routers are only required to do DHCPv6.

Yes, if an option is primarily defined for DHCP, that makes sense.

> Any host that only implements receipt of DHCPv6 options via RA must not expect to operate in an open ecosystem. Put the burden on the hosts.

Probably. Unless this thing becomes popular.

   Brian


From nobody Mon Nov 27 15:59:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D68512940B; Mon, 27 Nov 2017 15:59:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZuyifAf7aCQ; Mon, 27 Nov 2017 15:59:15 -0800 (PST)
Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::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 31CB8124207; Mon, 27 Nov 2017 15:59:15 -0800 (PST)
Received: by mail-pl0-x230.google.com with SMTP id z3so9493446plh.9; Mon, 27 Nov 2017 15:59:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jtrXwChv3NuxsISHjCuOzlOt3Stdr6flHT+kD6sXXgY=; b=U7V33F4OHjROxm/339qL2qyPQwH3JUUhimSc8f6WfX+xb8bSOuzKXOPzEBuNRFQHhR Ttvkr+aDwWb+TNtanCiMx1nZuwFYQEwciGrHfKUF/JPJMhLQiWjWWh+QZTnPOdFW9jeU CtNgKGxH/ak0hzeQgNsGG+8v+KMNT1gtkRokSK3SCoyBui25PNIzE/nB+jS5+h/7lcRk M8CX4JOK+FKij3Q/sJPi9irH58ccyx2pTxFx0Q59icPOU9EMc3U5csjWLo6/j9Ldr+ye 2+6CIk+ID8FGF55mSlqcDApUZTxPxithMZyVdODXz3WOAAUzaBQB8ip9bz3NQ5JnyrlM EGSA==
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=jtrXwChv3NuxsISHjCuOzlOt3Stdr6flHT+kD6sXXgY=; b=S6DMuqZU766mvzpjVUWjb91ptOwYNz2HqfGg/Jy2evPhPF8LSp1B0GjZNvhLwn3brt NwEoVUB+8qLxSRUichnurmg7C+GGg82BHxpmDYvyMF2n8XQBjAtmgcme5/VFFcLYvpKn 9/O/gkSpsJkUB6Ro+axNCoSxckeQD8lDzIdpCPSo8wO/Sd4uZDWUcrECSbnE3juTL0E2 k7OuFXOeFxEziKitHV+BBhJSjHfYATC3BWdFw3WY9GmeXKSqjMibZJcX21EYc7C0fTmC moFM1YwN0OH54CT80RbUHyWRkQAvvBHW/ngNByKw7TX0U+RsYTPqwCSjXL/KFKPsg3ic HUYQ==
X-Gm-Message-State: AJaThX6SGRzS0uOtayxYNKKEKQxdoWYk4BTXmvjZZvlVfHFJRESWpHw/ MHI3NWbaZb1muhbiPA85cPNxow==
X-Google-Smtp-Source: AGs4zMbR7rStqiXtxLE4CWM6wMUDDk4g8y/qguCgAQirzCh9XZRlGCoPmFrlbc97bdqcGql5r6uc8Q==
X-Received: by 10.159.218.73 with SMTP id x9mr37763235plv.92.1511827154569; Mon, 27 Nov 2017 15:59:14 -0800 (PST)
Received: from [130.216.38.112] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.112]) by smtp.gmail.com with ESMTPSA id q83sm17610925pfk.68.2017.11.27.15.59.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 15:59:13 -0800 (PST)
Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: Michael Richardson , Fred Baker 
Cc: "dhcwg@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca>  <26398.1511460320@obiwan.sandelman.ca>
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <26ad77cc-c61c-52b0-201d-464f5b771368@gmail.com>
Date: Tue, 28 Nov 2017 12:59:12 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <26398.1511460320@obiwan.sandelman.ca>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 27 Nov 2017 23:59:17 -0000

On 24/11/2017 07:05, Michael Richardson wrote:
> 
> Fred Baker  wrote:
>     >> My understanding is that Fred Templin essentially wants to carry DHCP
>     >> (configuration) options in ND/RA.
> 
>     > On thing that I have never understood is the lack of an RA option that
>     > carries any DHCPv6 option. This entire silly debate would end if RAs
>     > encompassed DHCP options.
> 
> I think that this is mostly what Fred wants to define.
> 
> Apparently he also wants to do stateful DHCPv6 things (such as PD), which I
> am much less enthusiastic about putting into RAs/NDs as they cease to be
> idempotent.

I think a key sentence in the draft is this:
"The IPv6 ND function then acts as a Lightweight DHCPv6
 Relay Agent (LDRA) [RFC6221] to forward the message to the DHCPv6
 relay or server function on-board the router."

If it's clear that ND is serving only as a lightweight relay,
doesn't your concern go away? As far as I can see, lightweight
relays are stateless.

      Brian


From nobody Mon Nov 27 17:22:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDC6126DD9 for ; Mon, 27 Nov 2017 17:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=herbertland-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 6aAquO_dwu2X for ; Mon, 27 Nov 2017 17:22:13 -0800 (PST)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D63E1200C1 for ; Mon, 27 Nov 2017 17:22:13 -0800 (PST)
Received: by mail-qk0-x22c.google.com with SMTP id p19so35061037qke.2 for ; Mon, 27 Nov 2017 17:22:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iVFmH9i3jvJ6Di/SX1W8/Hp3191HmkTQMUP7WNn2A/w=; b=EkSrbN6cftYPwTJ4kRewWlYtO7IIRJNkqKnZYOttSMhj/e6stkGc3jn5VEWGUOEZEk 4dZbTHSdzuu3o8M6WXzZGhGGYxHbdhEkx4jq1aCAgv4iYuA94P55Jf8xnDrVldojd80u y4QVWzqWXA/YHxFxHvXNdKP7h7SE78MDXhQObJ+OXiidprSI9PvB/nkTDGCGJ1UngsJl jUYRMi0lHmoWNGM5hYW5oE93ev4nmO/bQPXWBh065mm9wesJTIRrbFtHCWSnV2Adn/pZ cIFQXRdglVp9Jv0tqcL8aFdzfpbh0D+Z7ekaBjOVRy67QqoWZfQvKqneE1TsCDkk3Izr SHAA==
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=iVFmH9i3jvJ6Di/SX1W8/Hp3191HmkTQMUP7WNn2A/w=; b=Fa324tpa1iOkd95Dy/XbTBwTE9EGLWkXZeVAOzwroaXe0h/BzTAs1W+NlE57VQlnCc ZoBtSYzS7OsbQokQ8CJsGYMtZOgAk/hMhZZ00mG6aMH/bcbUe4JpdwrnH5BVHYBI2rHz e9R2e6khB4Zplvwz1Z0abA8gn0RRQV7QSMX7Zfv4AVdmCrcahnrT6NBnrliBwdBRb3pu XbkqUH+nVxGN9oXMx689XDrv2JHd1S2WSgB45+/vpdLFA+XlyKXv2V2iCRM0/88+5UF6 xeS6CzJgI+CsyQSlbCt6jGXtSF6w4fV953LZT3IicC+nLtFifInYyqD0+dBNRUkN9sjs n5EA==
X-Gm-Message-State: AJaThX5jq+qtTA3el8eDvXozNqUcDkV/TBDRH2f8gM3vUzRuzH+wh/Jz TtfODB6KyvJVCbf2ojbgyRPwr1v0FllQBQ+3X5UxSA==
X-Google-Smtp-Source: AGs4zMbpAevsbmQeCBaUASLsXXamB/XfvWMsx7DlUsOnSFMdjeTBv0HIDrQNfMAm1l7xsue8Amwmq50cMbArzcToZlo=
X-Received: by 10.55.215.67 with SMTP id m64mr62309187qki.91.1511832132069; Mon, 27 Nov 2017 17:22:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.43.121 with HTTP; Mon, 27 Nov 2017 17:22:11 -0800 (PST)
In-Reply-To: <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>
From: Tom Herbert 
Date: Mon, 27 Nov 2017 17:22:11 -0800
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Brian E Carpenter 
Cc: draft-voyer-6man-extension-header-insertion@ietf.org, 6man 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 01:22:16 -0000

On Mon, Nov 27, 2017 at 2:31 PM, Brian E Carpenter
 wrote:
> Hi,
>
> I'm probably repeating myself, but it seems clear that this draft
> in its present form will never get anywhere. Firstly I will try to
> justify this statement, and secondly I'll try to make some
> constructive suggestions.
>
> I. The problems with the current draft:
>
> I.1. No RFC is allowed to have more than five authors without
> an extremely good reason. If six or seven people have contributed
> roughly equal amounts you might just be able to persuade the
> RFC Editor to list everybody, but 18? Never.
> https://tools.ietf.org/html/rfc7322#section-4.1.1
>
> I.2. More serious is the tone, which starts with the Abstract.
> "The network operator and vendor community has clearly indicated..."
> is, to put it mildly, out of place in an IETF document. We work
> by facts and rough consensus, not by declarations by vested
> interests. I think a lot of people will simply stop reading
> the draft after that sentence.
>
> The tone needs to be rational and factual argument about why
> the proposed mechanism is both desirable and harmless. The
> abstract needs to be a factual summary.
>
> I.3. A detail is that since this draft recommends ignoring
> a rule in RFC 8200, it needs to be aimed at the standards
> track with Updates: 8200.
>
> I.4. Another detail is that in some places the draft seems
> to assume that only segment routing headers will be
> candidates for insertion. That may be true today, but
> probably not for ever.
>
+1

I'm also leary of proposals that redefine protocol behavior on the
basis that it will only be used in a controlled domain. This entails
assumptions that all devices (both intermediate devices and end hosts)
in the domain play by these rules, creates several corner cases that
need to be dealt with, and necessitates rationalization that packets
using non-interoperable protocol are never leaked out of the domain.

For instance, here is a corner case that I see...

>From the draft:

"The source domain may decide to place the IPv6 extension header
insertion where it suits its best: at the source of the packet or at
any midpoint within the source domain"

This statement implies that all hosts are under control of the source
domain, but that is not typically the case. A source host on its own
accord may create a packet with extension headers, some of which might
be the same type that intermediate devices insert and remove. It's not
clear what the disposition is of such packets and their extension
headers in in this draft.

Another question that comes to mind is why encapsulation does not work
here. That is encapsulate the packet on ingress to the domain, use
whatever extension headers are needed in the outer header, and
decapsulate on egress (i.e. this was the original "answer" to
extension header insertion). I'm guessing this might be because of
packet overhead, but it would be nice to see the reasons articulated.

Tom

> II. Constructive suggestions.
>
> I understand that the idea is to propose that this rule
> in https://tools.ietf.org/html/rfc8200#section-4 :
>
> "  Extension headers (except for the Hop-by-Hop Options header) are not
>    processed, inserted, or deleted by any node along a packet's delivery
>    path, until the packet reaches the node (or each of the set of nodes,
>    in the case of multicast) identified in the Destination Address field
>    of the IPv6 header."
>
> MAY be ignored within an administrative domain for packets that
> terminate within that domain. If that's the intention, I think
> there are several logical steps in the argument that need to
> be laid out. A lot of the ideas are already in the draft; this
> is mainly about making a clear and logical case that the whole
> community can understand.
>
> 1. Introduction, outline of use cases [1].
> 2. Precise definition of a domain and of its boundary, ingresses and egresses.
> 3. Explanation of how the class of packets eligible for header insertion are identified [2].
> 4. Explanation of how the well-known issues are avoided (PMTUD, fragmentation, IPSec).
> 5. Clear statement of what header manipulations are allowed and which devices may perform them.
> 6. Precise statement of which text in RFC 8200 is updated.
> 7. Security considerations
>
> [1] More details on use cases could be an appendix.
>
> [2] https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02#section-3
> is IMHO correct as far as transit packets go. But it
> should be presented as a mainstream part of the proposal,
> not as an example.
>
> I hope this is helpful.
>    Brian Carpenter
>
>
>
> On 21/11/2017 07:33, internet-drafts@ietf.org wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>>         Title           : Insertion of IPv6 Segment Routing Headers in a Controlled Domain
>>         Authors         : Daniel Voyer
>>                           Daniel Bernier
>>                           John Leddy
>>                           Clarence Filsfils
>>                           Darren Dukes
>>                           Stefano Previdi
>>                           Stefano Salsano
>>                           Antonio Cianfrani
>>                           David Lebrun
>>                           Olivier Bonaventure
>>                           Prem Jonnalagadda
>>                           Milad Sharif
>>                           Hani Elmalky
>>                           Ahmed Abdelsalam
>>                           Robert Raszuk
>>                           Arthi Ayyangar
>>                           Dirk Steinberg
>>       Filename        : draft-voyer-6man-extension-header-insertion-02.txt
>>       Pages           : 14
>>       Date            : 2017-11-20
>>
>> Abstract:
>>    The network operator and vendor community has clearly indicated that
>>    IPv6 header insertion is useful and required.  This is notably the
>>    case when the entire journey of the packet remains in its source
>>    domain.  In such a context, it does not matter where the extension
>>    header is inserted.  The source domain may decide to place the IPv6
>>    extension header insertion where it suits its best: at the source of
>>    the packet or at any midpoint within the source domain.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-voyer-6man-extension-header-insertion/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02
>> https://datatracker.ietf.org/doc/html/draft-voyer-6man-extension-header-insertion-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-voyer-6man-extension-header-insertion-02
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> 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
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Mon Nov 27 21:22:23 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF76126DD9 for ; Mon, 27 Nov 2017 21:22:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 KvQCdsg-Pfy1 for ; Mon, 27 Nov 2017 21:22:20 -0800 (PST)
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 7ABC61201F8 for <6man@ietf.org>; Mon, 27 Nov 2017 21:22:20 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id k191so12839870ywe.1 for <6man@ietf.org>; Mon, 27 Nov 2017 21:22:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F4JbUxgVK5DiwbrmUMAH++GyHjlmYhDr8uHGeNL611E=; b=IxZDwrJw6AiJ62cYLqmwIMSM81J2//OdBM/2iZt6Vk7zmqMlP4hPSW+IJASWT+gJXI x5QRH75jnshu7QTOaoz8qnhij00QsEDdsLd7DuS/4JRpmp/CYp3GUFgSJNqL0ppCnEku 3/jwDH1taH/VCVEbCURrUa2VnYbPxCPDlfmztuv2MDL/YJT4riUHoiuBj3Ei0HQofO6J VD64x6uFohRGh57ZV3OlqiPhYy96u5EEo8d0yvEvtGJXfzag2H1Ofo3amuFmwT7dk6eH ZjZgQ+TCSoOVqry98Yab17SZC7v195wxx2k74VjsBG8s2ikHJEXdsVRNqBsICvrGruiH GZtw==
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=F4JbUxgVK5DiwbrmUMAH++GyHjlmYhDr8uHGeNL611E=; b=Y42kA7R5Wir1g6BmcfTTPpt0xsvbAD5T6kgIWAJrK3daZulaI26znZ/ZIA7CNUosKh WoWcybPctbtEbtYRiHOA63m0ngEYKgXOpFBfrHsRPa2wVsRmCPVCO6DeGkVlF1T7YdZw RnPTDRh55z16F7KhhTaOCituLbWFxrhtpe0z4N83bFNe0O/4yOErXgz2P4DlQAm0G98y kvzBEqYdmFpkn8X077bQjQgwYa//b+4ykmFb6yNE+Hp08e8sQp351T4FJFdwVqATtgM6 R1h+j2kudoq+KMtDv9heGRp2ls9SOdUDORIYBrAYgjtJR/+NoX/M7ooyB15VzVtoJmSI M9yg==
X-Gm-Message-State: AJaThX5GZRky5QooetcYLznAbpZFNzg1LoZ+E7TKMYrUuwsGi6ZhYaK3 UdCNop8Mv8gkIqcs+aZ++IZx7v1F9MSJkPEEdvHxsw==
X-Google-Smtp-Source: AGs4zMbo/78We1GsJ3/+no0Gqso04bjEKzQD3zqTjlmwFl7XjIRL+sRF+3+KfRnwCs9kd6bCm4aWo6+/3CIrcJSIBIY=
X-Received: by 10.13.232.140 with SMTP id r134mr27137246ywe.344.1511846539466;  Mon, 27 Nov 2017 21:22:19 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.4.194 with HTTP; Mon, 27 Nov 2017 21:21:58 -0800 (PST)
In-Reply-To: <8a5feb3a-d18e-1773-0539-3da22e582c70@gmail.com>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca>  <2D09D61DDFA73D4C884805CC7865E6114DCC2BF8@GAALPA1MSGUSRBF.ITServices.sbc.com> <8a5feb3a-d18e-1773-0539-3da22e582c70@gmail.com>
From: Lorenzo Colitti 
Date: Tue, 28 Nov 2017 14:21:58 +0900
Message-ID: 
Subject: Re: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: Brian E Carpenter 
Cc: "STARK, BARBARA H" , Fred Baker , Michael Richardson , "dhcwg@ietf.org" ,  "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c086fbaf12236055f0433fe"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 05:22:22 -0000

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

On Tue, Nov 28, 2017 at 8:06 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Yes and no. Let's consider a host that needs a particular piece of
> information. As an example, consider the address of the next-hop router
> for a given prefix. There are three separate parts to this:
>
> 1. Receiving some sort of message containing an appropriate option.
> 2. Decoding the option
> 3. Storing the result.
> [...]
>

You can't really separate these steps because the protocols that deliver
configuration information have different semantics. For example, DHCPv6 is
poll-based and requires explicit renewal, but RAs are push-based.

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


On T=
ue, Nov 28, 2017 at 8:06 AM, Brian E Carpenter <brian.e.carpente=
r@gmail.com> wrote:
Yes and=
 no. Let's consider a host that needs a particular piece of

information. As an example, consider the address of the next-hop router

for a given prefix. There are three separate parts to this:



1. Receiving some sort of message containing an appropriate option.

2. Decoding the option

3. Storing the result.

[...]



You can't really separate these steps =
because the protocols that deliver configuration information have different=
 semantics. For example, DHCPv6 is poll-based and requires explicit renewal=
, but RAs are push-based.


--94eb2c086fbaf12236055f0433fe--


From nobody Tue Nov 28 09:02:34 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8390126DED; Tue, 28 Nov 2017 09:02:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3fBUk-qPpPa; Tue, 28 Nov 2017 09:02:19 -0800 (PST)
Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD08128B8D; Tue, 28 Nov 2017 09:02:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vASH2Ise021448; Tue, 28 Nov 2017 10:02:19 -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 vASH2HjG021437 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 28 Nov 2017 10:02:17 -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, 28 Nov 2017 09:02:17 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 28 Nov 2017 09:02:17 -0800
From: "Templin, Fred L" 
To: "STARK, BARBARA H" , Fred Baker , Michael Richardson 
CC: "dhcwg@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>
Subject: RE: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgAkcdkAADO+44AAEoFNVAD1MWEAACiUpcA=
Date: Tue, 28 Nov 2017 17:02:17 +0000
Message-ID: 
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca>  <2D09D61DDFA73D4C884805CC7865E6114DCC2BF8@GAALPA1MSGUSRBF.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DCC2BF8@GAALPA1MSGUSRBF.ITServices.sbc.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 17:02:21 -0000

Hi, if there is some concern about backwards compatibility and accepting
configuration information from multiple sources the scenario is as follows:

- the host MAY include a DHCPv6 Request option in its RS message
- routers that do not recognize the DHCPv6 Request option, or that
   do not implement a DHCPv6 relay or server, ignore the option and
   return an RA with no DHCPv6 option and with M/O bits set as normal
- routers that recognize the DHCPv6 Request option and that implement
   a DHCPv6 relay or server process the DHCPv6 Request then include a
   DHCPv6 Reply option in unicast RAs that they send back to the host
- the host processes the RA message and also processes the DHCPv6
   Reply while accepting the union of the configuration information
   provided by both IPv6 ND and DHCPv6

Note that there will never be a time that a router includes a DHCPv6 Reply
option in its RA message unless the host first included a DHCPv6 Request
option in its RS. And, even if it did, hosts that do not recognize the opti=
on
will simply ignore it and process the rest of the RA message as normal.

The approach is therefore fully backwards compatible and provides
the best combination of both IPv6 ND and DHCPv6 autoconfiguration.

Thanks - Fred

> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of STARK, BARBARA H
> Sent: Monday, November 27, 2017 5:20 AM
> To: Fred Baker ; Michael Richardson 
> Cc: dhcwg@ietf.org; v6ops@ietf.org; 6man@ietf.org
> Subject: Re: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 into a single, =
unified function
>=20
> > > My understanding is that Fred Templin essentially wants to carry DHCP
> > > (configuration) options in ND/RA.
> >
> > On thing that I have never understood is the lack of an RA option that =
carries
> > any DHCPv6 option. This entire silly debate would end if RAs encompasse=
d
> > DHCP options.
>=20
> Thus forcing either routers or hosts (or both) to support two distinct me=
chanisms to do the same thing if there is to be any hope of
> interoperability. And if the host supports both, then it also needs to im=
plement code for which wins when both are present and the
> options provided have conflicting info.
> If you really want DHCPv6 options in RAs for closed ecosystem use cases, =
include a huge caveat that routers are not required to
> support both mechanisms -- routers are only required to do DHCPv6. Any ho=
st that only implements receipt of DHCPv6 options via RA
> must not expect to operate in an open ecosystem. Put the burden on the ho=
sts.
> Barbara
>=20
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg



From nobody Tue Nov 28 09:09:17 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1218C128AFE; Tue, 28 Nov 2017 09:09:00 -0800 (PST)
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 kIJ1Vej7IMtZ; Tue, 28 Nov 2017 09:08:56 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 409DF1289B5; Tue, 28 Nov 2017 09:08:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vASH8tXE057433; Tue, 28 Nov 2017 10:08:55 -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 vASH8okO057012 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 28 Nov 2017 10:08:50 -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, 28 Nov 2017 09:08:49 -0800
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1320.000; Tue, 28 Nov 2017 09:08:49 -0800
From: "Templin, Fred L" 
To: Lorenzo Colitti , Brian E Carpenter 
CC: "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>, Michael Richardson , "dhcwg@ietf.org" 
Subject: RE: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Topic: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
Thread-Index: AdNiReoj4OrwrQYST+iGtIF1uM57NgAkcdkAADO+44ABGI3TgAAYdG1w
Date: Tue, 28 Nov 2017 17:08:49 +0000
Message-ID: <32546f10ef9a4859a3a61163c8e82429@XCH15-06-08.nw.nos.boeing.com>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca>  <2D09D61DDFA73D4C884805CC7865E6114DCC2BF8@GAALPA1MSGUSRBF.ITServices.sbc.com> <8a5feb3a-d18e-1773-0539-3da22e582c70@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: multipart/alternative; boundary="_000_32546f10ef9a4859a3a61163c8e82429XCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 17:09:02 -0000

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

SGkgTG9yZW56bywNCg0KSW4gdGhpcyBwcm9wb3NhbCwgREhDUHY2IGFuZCBJUHY2IE5EIHBlYWNl
ZnVsbHkgY29leGlzdC4gQWZ0ZXIgdGhlIGluaXRpYWwgYXV0b2NvbmZpZ3VyYXRpb24sDQppZiB0
aGUgaG9zdCBuZWVkcyB0byByZW5ldywgcmVsZWFzZSwgcmViaW5kLCBldGMuIGl0IHNpbXBseSBp
c3N1ZXMgYSBuZXcgUlMgYW5kIHRoZSByb3V0ZXINCnJlc3BvbmRzIHdpdGggYSBuZXcgUkEuIFNv
LCBhbGwgSVB2NiBORCBhbmQgREhDUHY2IG9wZXJhdGlvbnMgYXJlIGRyaXZlbiBmcm9tIGEgc2lu
Z2xlDQplbmdpbmUsIG5hbWVseSBSUy9SQS4NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBpcHY2
IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG9yZW56byBDb2xp
dHRpDQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDI3LCAyMDE3IDk6MjIgUE0NClRvOiBCcmlhbiBF
IENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPg0KQ2M6IHY2b3BzQGlldGYu
b3JnOyA2bWFuQGlldGYub3JnOyBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1h
bi5jYT47IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBbdjZvcHNdIENvbWJp
bmluZyBJUHY2IE5EIGFuZCBESENQdjYgaW50byBhIHNpbmdsZSwgdW5pZmllZCBmdW5jdGlvbg0K
DQpPbiBUdWUsIE5vdiAyOCwgMjAxNyBhdCA4OjA2IEFNLCBCcmlhbiBFIENhcnBlbnRlciA8YnJp
YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPG1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5j
b20+PiB3cm90ZToNClllcyBhbmQgbm8uIExldCdzIGNvbnNpZGVyIGEgaG9zdCB0aGF0IG5lZWRz
IGEgcGFydGljdWxhciBwaWVjZSBvZg0KaW5mb3JtYXRpb24uIEFzIGFuIGV4YW1wbGUsIGNvbnNp
ZGVyIHRoZSBhZGRyZXNzIG9mIHRoZSBuZXh0LWhvcCByb3V0ZXINCmZvciBhIGdpdmVuIHByZWZp
eC4gVGhlcmUgYXJlIHRocmVlIHNlcGFyYXRlIHBhcnRzIHRvIHRoaXM6DQoNCjEuIFJlY2Vpdmlu
ZyBzb21lIHNvcnQgb2YgbWVzc2FnZSBjb250YWluaW5nIGFuIGFwcHJvcHJpYXRlIG9wdGlvbi4N
CjIuIERlY29kaW5nIHRoZSBvcHRpb24NCjMuIFN0b3JpbmcgdGhlIHJlc3VsdC4NClsuLi5dDQoN
CllvdSBjYW4ndCByZWFsbHkgc2VwYXJhdGUgdGhlc2Ugc3RlcHMgYmVjYXVzZSB0aGUgcHJvdG9j
b2xzIHRoYXQgZGVsaXZlciBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGhhdmUgZGlmZmVyZW50
IHNlbWFudGljcy4gRm9yIGV4YW1wbGUsIERIQ1B2NiBpcyBwb2xsLWJhc2VkIGFuZCByZXF1aXJl
cyBleHBsaWNpdCByZW5ld2FsLCBidXQgUkFzIGFyZSBwdXNoLWJhc2VkLg0K

--_000_32546f10ef9a4859a3a61163c8e82429XCH150608nwnosboeingcom_
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
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIExvcmVuem8sPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiB0aGlzIHByb3Bvc2FsLCBESENQdjYgYW5k
IElQdjYgTkQgcGVhY2VmdWxseSBjb2V4aXN0LiBBZnRlciB0aGUgaW5pdGlhbCBhdXRvY29uZmln
dXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aWYgdGhlIGhvc3QgbmVlZHMgdG8gcmVuZXcsIHJl
bGVhc2UsIHJlYmluZCwgZXRjLiBpdCBzaW1wbHkgaXNzdWVzIGEgbmV3IFJTIGFuZCB0aGUgcm91
dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnJlc3BvbmRzIHdpdGggYSBuZXcgUkEuIFNvLCBhbGwgSVB2
NiBORCBhbmQgREhDUHY2IG9wZXJhdGlvbnMgYXJlIGRyaXZlbiBmcm9tIGEgc2luZ2xlPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPmVuZ2luZSwgbmFtZWx5IFJTL1JBLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGlwdjYgW21haWx0
bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkxvcmVuem8gQ29s
aXR0aTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDI3LCAyMDE3IDk6MjIgUE08
YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIEUgQ2FycGVudGVyICZsdDticmlhbi5lLmNhcnBlbnRlckBn
bWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZzsgNm1hbkBpZXRmLm9y
ZzsgTWljaGFlbCBSaWNoYXJkc29uICZsdDttY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhJmd0Ozsg
ZGhjd2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkaGN3Z10gW3Y2b3BzXSBD
b21iaW5pbmcgSVB2NiBORCBhbmQgREhDUHY2IGludG8gYSBzaW5nbGUsIHVuaWZpZWQgZnVuY3Rp
b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5PbiBUdWUsIE5vdiAyOCwgMjAxNyBhdCA4OjA2IEFNLCBCcmlhbiBFIENh
cnBlbnRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t
bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcyBh
bmQgbm8uIExldCdzIGNvbnNpZGVyIGEgaG9zdCB0aGF0IG5lZWRzIGEgcGFydGljdWxhciBwaWVj
ZSBvZjxicj4NCmluZm9ybWF0aW9uLiBBcyBhbiBleGFtcGxlLCBjb25zaWRlciB0aGUgYWRkcmVz
cyBvZiB0aGUgbmV4dC1ob3Agcm91dGVyPGJyPg0KZm9yIGEgZ2l2ZW4gcHJlZml4LiBUaGVyZSBh
cmUgdGhyZWUgc2VwYXJhdGUgcGFydHMgdG8gdGhpczo8YnI+DQo8YnI+DQoxLiBSZWNlaXZpbmcg
c29tZSBzb3J0IG9mIG1lc3NhZ2UgY29udGFpbmluZyBhbiBhcHByb3ByaWF0ZSBvcHRpb24uPGJy
Pg0KMi4gRGVjb2RpbmcgdGhlIG9wdGlvbjxicj4NCjMuIFN0b3JpbmcgdGhlIHJlc3VsdC48YnI+
DQpbLi4uXTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+WW91IGNhbid0IHJlYWxseSBzZXBhcmF0ZSB0aGVzZSBzdGVwcyBiZWNhdXNl
IHRoZSBwcm90b2NvbHMgdGhhdCBkZWxpdmVyIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gaGF2
ZSBkaWZmZXJlbnQgc2VtYW50aWNzLiBGb3IgZXhhbXBsZSwgREhDUHY2IGlzIHBvbGwtYmFzZWQg
YW5kIHJlcXVpcmVzIGV4cGxpY2l0IHJlbmV3YWwsIGJ1dCBSQXMgYXJlIHB1c2gtYmFzZWQuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_32546f10ef9a4859a3a61163c8e82429XCH150608nwnosboeingcom_--


From nobody Tue Nov 28 11:29:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB458128E00; Tue, 28 Nov 2017 11:29:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqmIqKLPy_WS; Tue, 28 Nov 2017 11:29:22 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A422126BF6; Tue, 28 Nov 2017 11:29:21 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id y89so379846pfk.0; Tue, 28 Nov 2017 11:29:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IPK09va3l9vR4YYkGW6QNQY2w6gwUgm5hCdp3I6oApE=; b=Kqlbo4mVIxXPJ3F82R7lBNQFH7oYKRvfIjfHQS4aH6pbmQQoNF0o+It3pUvf3BEkhX r1CQiDBYFuHXVd+D5PP4VU+ctanCoNmsQ7knEflJ9PkNYO1azbuM5IRgPFo2FRFoup37 iwkacdWiupprzaUFR5ieAkbC4i0E2inN6r7xzESJgZoLwBAj3tUgawypoCj5GgujIWOK rekAAvNXKZLSDxtx2FrE0sh/4/kKgULS7y/U42IMatShLYuSrL13CKKv+QXQRbBq4Bkk yLmOp3tuMnogmpHAl+XJxhGFOGoZNSyF72x6NDLfopzVysdXvU42RRlScj0eA28DqJAl kFHQ==
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=IPK09va3l9vR4YYkGW6QNQY2w6gwUgm5hCdp3I6oApE=; b=jkgw1VSkCJIsryB1A4YhhI0wX+8w5s8UeSPn94eiHGxyxDkGflzT1GKAhHQeIOMHac EBdcBejq+iYduTVwtTomNPVBy9u0Ow/OCs7hAPlmlVrlcjUJLcpIYPBKiCrtuJ9TX4rv kaGWR/o6o/WiDDwf5PBpm/fw5p62zA4sSDof11HXvV4ddHNMPxrYDm/VtDWJZeS/a91f InqhtkzUFZ1MR7S7nfS0SvjsnOa5t8GY6Eof1rmF4gHiYhRkL2W+sdXZSwvxZCf0MtB1 LPl7B91HbcBkc1amIIpdwrfSYjyejJ9E3gjwvgQDGyF2UViNU2ab31uUisllvjtu0dtd 3yEg==
X-Gm-Message-State: AJaThX5jivz26FShbssSVA47TlZEErsQfJlB51ERvGe/lOaWqYs4NkHS iYKIzmpCzNvS3j31j643/WlopQ==
X-Google-Smtp-Source: AGs4zMZXmMLVoOeOM4JjNDsdKaJ9RZLCww8AaY67C584W2qjP11IpdpMXeNbz/k5xkqk1cqHSu1sbg==
X-Received: by 10.101.68.65 with SMTP id e1mr219465pgq.282.1511897360208; Tue, 28 Nov 2017 11:29:20 -0800 (PST)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id c191sm57951940pfg.24.2017.11.28.11.29.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 11:29:18 -0800 (PST)
Subject: Re: [dhcwg] [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function
To: Lorenzo Colitti 
Cc: "STARK, BARBARA H" , Fred Baker , Michael Richardson , "dhcwg@ietf.org" , "v6ops@ietf.org" , "6man@ietf.org" <6man@ietf.org>
References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com>  <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca>  <2D09D61DDFA73D4C884805CC7865E6114DCC2BF8@GAALPA1MSGUSRBF.ITServices.sbc.com> <8a5feb3a-d18e-1773-0539-3da22e582c70@gmail.com> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <2611432c-ac26-105c-927e-3c4fd4309c2e@gmail.com>
Date: Wed, 29 Nov 2017 08:29:18 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 19:29:24 -0000

On 28/11/2017 18:21, Lorenzo Colitti wrote:
> On Tue, Nov 28, 2017 at 8:06 AM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>> Yes and no. Let's consider a host that needs a particular piece of
>> information. As an example, consider the address of the next-hop router
>> for a given prefix. There are three separate parts to this:
>>
>> 1. Receiving some sort of message containing an appropriate option.
>> 2. Decoding the option
>> 3. Storing the result.
>> [...]
>>
> 
> You can't really separate these steps because the protocols that deliver
> configuration information have different semantics. For example, DHCPv6 is
> poll-based and requires explicit renewal, but RAs are push-based.

I think those are mechanical details. RAs expire & the host waits
for renewal; a DHCP host solicits renewal; but from a bird's eye view
that is a hidden distinction.

    Brian


From nobody Tue Nov 28 15:48:48 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 637BF1205F0; Tue, 28 Nov 2017 15:48:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: ipv6@ietf.org
Subject: I-D Action: draft-ietf-6man-maxra-04.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151191292737.8012.4506707148184310117@ietfa.amsl.com>
Date: Tue, 28 Nov 2017 15:48:47 -0800
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 23:48:47 -0000

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

        Title           : Support for adjustable maximum router lifetimes per-link
        Authors         : Suresh Krishnan
                          Jouni Korhonen
                          Samita Chakrabarti
                          Erik Nordmark
                          Andrew Yourtchenko
	Filename        : draft-ietf-6man-maxra-04.txt
	Pages           : 6
	Date            : 2017-11-28

Abstract:
   The IPv6 Neighbor Discovery protocol specifies the maximum time
   allowed between sending unsolicited multicast Router Advertisements
   from a router interface as well as the maximum router lifetime.  It
   also allows the limits to be overridden by link-layer specific
   documents.  This document allows for overriding these values on a
   per-link basis.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-maxra-04
https://datatracker.ietf.org/doc/html/draft-ietf-6man-maxra-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-maxra-04


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

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


From nobody Wed Nov 29 15:13:51 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCAB127909; Wed, 29 Nov 2017 15:13:49 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ben Campbell 
To: "The IESG" 
Cc: draft-ietf-6man-maxra@ietf.org, otroan@employees.org, bob.hinden@gmail.com, 6man-chairs@ietf.org, bob.hinden@gmail.com, ipv6@ietf.org
Subject: Ben Campbell's No Objection on draft-ietf-6man-maxra-04: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151199722945.4873.13441604401624392248.idtracker@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 15:13:49 -0800
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 23:13:49 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-6man-maxra-04: No Objection

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-6man-maxra/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Editorial Comments:

- Abstract: Please mention the fact this updates 4861 in the abstract.

- Given that there are at least a few "should" and "must" instances in lower
case, please consider using the boilerplate from 8174 rather than 2119.



From nobody Wed Nov 29 20:55:27 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A43C4124207; Wed, 29 Nov 2017 20:55:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Roach 
To: "The IESG" 
Cc: draft-ietf-6man-maxra@ietf.org, otroan@employees.org, bob.hinden@gmail.com, 6man-chairs@ietf.org, bob.hinden@gmail.com, ipv6@ietf.org
Subject: Adam Roach's No Objection on draft-ietf-6man-maxra-04: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151201771866.4797.9693649301468187935.idtracker@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 20:55:18 -0800
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 04:55:19 -0000

Adam Roach has entered the following ballot position for
draft-ietf-6man-maxra-04: No Objection

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-6man-maxra/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my discuss and comment. I find the formulation in the
document being updated problematic, but you've done a deft job of not repeating
the error in this document.



From nobody Wed Nov 29 22:42:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0F512025C for ; Wed, 29 Nov 2017 22:42:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.2
X-Spam-Level: 
X-Spam-Status: No, score=-2.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_LOW=-0.7, 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 (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g_O0QFM-cz52 for ; Wed, 29 Nov 2017 22:42:25 -0800 (PST)
Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184B61200F1 for <6man@ietf.org>; Wed, 29 Nov 2017 22:42:25 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id AA2F1C6B44 for <6man@ietf.org>; Thu, 30 Nov 2017 01:42:22 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; s=sasl; bh=AJ73Lp LndfQ192dGMDIKwwlURjA=; b=aivVycHto9WKvFvLoVQ66vJWmVO/lb159Ukv+j LkDxExfesdl8kWzygigPJQwOPAo/iP2aJvgh5JZNOE25MehktnX23Iko+Spek3CM 9AfJIoJeg7qQpIYisQFj0QJ0m3QYdKOq3x/LtE0D0vfg5MtDh1BuBFtY/QgKCkyW wpXtE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; q=dns; s=sasl; b= TvgxIKvCwF6071EzU9xNpJ85dDZcJClfcUiAWprD0e5zz6wR1jTqf0HFpj6Nik19 j0sh5DkVt70Esh3tKw6q80SHkChdtHD2CYzIJXCdaJNfwnwzXrs0EzZo/gUs99oP ozG71CS8cLXOqU/MI5ZXkGo+UoKRL+JCZxVRgMRaAbk=
Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id A252DC6B43 for <6man@ietf.org>; Thu, 30 Nov 2017 01:42:22 -0500 (EST)
Received: from mail-qt0-f173.google.com (unknown [209.85.216.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 287CEC6B42 for <6man@ietf.org>; Thu, 30 Nov 2017 01:42:22 -0500 (EST)
Received: by mail-qt0-f173.google.com with SMTP id w10so7510219qtb.10 for <6man@ietf.org>; Wed, 29 Nov 2017 22:42:22 -0800 (PST)
X-Gm-Message-State: AKGB3mIMSx0jhtf/gh/T6rlZ341L1cXZlQ+BCqVUO4U8vRpnSnnzxhif 4x+9qAO+thOYzWW3YBiYETw9ZivxgrOpwZd0rYM=
X-Google-Smtp-Source: AGs4zMaHDtZRo6/BsaivROiHDDwElBewW859m/eT709vvEvj3OqkB4lyGklt8Kp/R5UBeWILl6K3XKxnuaIZxPCofRM=
X-Received: by 10.200.36.9 with SMTP id c9mr2274743qtc.182.1512024141735; Wed, 29 Nov 2017 22:42:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.86.239 with HTTP; Wed, 29 Nov 2017 22:42:01 -0800 (PST)
From: "C. M. Heard" 
Date: Wed, 29 Nov 2017 22:42:01 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
Subject: Re: draft-voyer-6man-extension-header-insertion
To: 6MAN <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
X-Pobox-Relay-ID: 9E5EFB18-D599-11E7-9DDD-8EF31968708C-06080547!pb-smtp1.pobox.com
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 06:42:27 -0000

The following comments, initially made against the -00 version of this
document, remain unaddressed in the -01 and -02 versions. Please see
https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-02#section-3
for the most recent text.

On Wed, May 24, 2017 at 9:46 AM, C. M. Heard  wrote:
> First, it still is not clear to me why it is considered decisively
> advantageous to add the outer IPv6 header at the ingress to the SR domain
> (node 1) and then insert the SRH at the intermediate that detects the link
> failure (node 2) instead of just doing the encapsulation at the
> intermediate node itself. An explanation would help. If it requires
> consideration of other use cases to make that case, you may want to consider
> adding one or more of those use cases to the draft.
>
> Second, suppose that a second link failure is detected at node 4 (see
> https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-00#section-3).
> If that triggers SRH insertion because of fast reroute, then there will
> be two SRH's in the packet, which would make it malformed. To avoid this
> problem, it seems to me that node 4 would need to rebuild the existing SRH,
> encapsulate the packet in another outer IPv6 header, or else drop the packet.
> By analogy with how fast protection switching works in transport NEs, I
> understand that protecting agains multiple link failures may be out of scope,
> but even so, multiple link failures should not result in malformed packets.
>
> Looking forward to further discussion.
>
> Mike Heard


From nobody Thu Nov 30 01:47:27 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EB11200C5; Thu, 30 Nov 2017 01:47:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZcChs_K-D-hb; Thu, 30 Nov 2017 01:47:24 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC658128E00; Thu, 30 Nov 2017 01:47:23 -0800 (PST)
Received: from [192.168.3.67] (109-155-16-190.fibertel.com.ar [190.16.155.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3AAA782D06; Thu, 30 Nov 2017 10:47:19 +0100 (CET)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Brian E Carpenter , draft-voyer-6man-extension-header-insertion@ietf.org
Cc: 6man 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>
From: Fernando Gont 
Message-ID: 
Date: Thu, 30 Nov 2017 17:14:07 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 09:47:26 -0000

On 11/28/2017 06:31 AM, Brian E Carpenter wrote:
[...]
> II. Constructive suggestions.
> 
> I understand that the idea is to propose that this rule
> in https://tools.ietf.org/html/rfc8200#section-4 :
> 
> "  Extension headers (except for the Hop-by-Hop Options header) are not
>    processed, inserted, or deleted by any node along a packet's delivery
>    path, until the packet reaches the node (or each of the set of nodes,
>    in the case of multicast) identified in the Destination Address field
>    of the IPv6 header."
> 
> MAY be ignored within an administrative domain for packets that
> terminate within that domain. If that's the intention, I think
> there are several logical steps in the argument that need to
> be laid out. 

IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
-- this is the standard, straightforward and most clean approach.

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





From nobody Thu Nov 30 04:45:45 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64513127F0E; Thu, 30 Nov 2017 04:45:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IydNyGCRGDfB; Thu, 30 Nov 2017 04:45:42 -0800 (PST)
Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8FC12708C; Thu, 30 Nov 2017 04:45:42 -0800 (PST)
Received: from h.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 4ED732D5126; Thu, 30 Nov 2017 12:45:42 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 99286200FA52F2; Thu, 30 Nov 2017 13:45:40 +0100 (CET)
From: Ole Troan 
Message-Id: <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_F5FD38A9-5A19-445A-80B0-A4CD16F8EB10"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
Date: Thu, 30 Nov 2017 13:45:39 +0100
In-Reply-To: 
Cc: Brian E Carpenter , draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
To: Fernando Gont 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 12:45:44 -0000

--Apple-Mail=_F5FD38A9-5A19-445A-80B0-A4CD16F8EB10
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

>=20
> IMO, #1 thing to be discussed is why normal encapsulation wouldn't =
work
> -- this is the standard, straightforward and most clean approach.

The best example I've heard is when you don't have a natural tunnel =
endpoint to encapsulate to.

Ole

--Apple-Mail=_F5FD38A9-5A19-445A-80B0-A4CD16F8EB10
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+/bDNdvtpYqJhC33YFAlof/XMACgkQvtpYqJhC
33YrDBAAwSpB791oGKNKLe+/5lxt2+NBkg+QNBeFA4i9eNJff1h4rYbTqVluOgD+
xCbbHtgor4tA9hh+lpZSegbX3sBMEo/v5btYw+VsPm0m7JjONr14SWQVVg/b3yo3
XR3ZByQI/F0I1MPuTI446W3lpxsQFjmsoOz5wPqeFhg4oPRZb/Utt9Z4hITUzg3N
aUB5jilWfMP4ioMLwUX1RlN14whGGVo2U1Q79cwnVTdlxyEUetuJSqJk+5pPBJlB
Uepaf8ZdQKPm8Gn+ss3IluPRb6+Dx8gw7twWj2e3ibqLlRNZqIQFj/5JqFp+LVKG
XLpSBvSqjJ3SDY7MD/V8DmV2VPuQI1M1ML/E1Tv2JIS/n9Gijs3KmGUnNWezZF9K
9nCGn71mYwcNcT4S+Awh2oLg5VyO1GhzkZ9GeH/93FcugXNKjurTpGeYCj6Qg+l+
/E68fPYccn4vO82OsyANNjBQtE4+CljkG/o3qX/10DWiKX33A+iT99z+Lf0yc6jz
Kc4NO9QbVyzbfjGO47B3/y4AqOxqi/FUttkZsyKrD73sEZCwEFsTMg0h7VOg9ub/
2HgjFNJekOxgv1WKkC7vYuyxb+uH9qsdzSeTwRVCTNIemaEu1Y85IdEb5f9ufmsu
hnn52j1cgsnrWf3ozKOANXhavulQYUJvzTXu8w767FjyLRwiXL4=
=jfHF
-----END PGP SIGNATURE-----

--Apple-Mail=_F5FD38A9-5A19-445A-80B0-A4CD16F8EB10--


From nobody Thu Nov 30 05:30:40 2017
Return-Path: 
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B511293F4; Thu, 30 Nov 2017 05:30:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins 
To: "The IESG" 
Cc: draft-ietf-6man-maxra@ietf.org, otroan@employees.org, bob.hinden@gmail.com, 6man-chairs@ietf.org, bob.hinden@gmail.com, ipv6@ietf.org
Subject: Spencer Dawkins' No Objection on draft-ietf-6man-maxra-04: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151204863852.4788.13886631243889351728.idtracker@ietfa.amsl.com>
Date: Thu, 30 Nov 2017 05:30:38 -0800
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 13:30:38 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-6man-maxra-04: No Objection

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-6man-maxra/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Everyone likely knows this, but is it worth adding a suggestion to retry
rejected RAs with a Router Lifetime of more than 9000 seconds, with a new RA
that uses 9000 seconds?

5.  Host Behavior

   Legacy hosts on a link with updated routers may have issues with a
   Router Lifetime of more than 9000 seconds.  In the few
   implementations we have tested with general purpose operating
   systems, there does not seem to be any issues with setting this field
   to more than 9000, but there might be implementations that
   incorrectly (since RFC4861 requires receivers to handle any value)
   reject such RAs.

I think this meshes with Mirja's suggestion to state whether 9000 is still the
default ...



From nobody Thu Nov 30 05:51:47 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A222412947C; Thu, 30 Nov 2017 05:51:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gspAzq3hl4tX; Thu, 30 Nov 2017 05:51:39 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4089B129485; Thu, 30 Nov 2017 05:51:39 -0800 (PST)
Received: from [192.168.3.67] (109-155-16-190.fibertel.com.ar [190.16.155.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 16A7381854; Thu, 30 Nov 2017 14:51:23 +0100 (CET)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Ole Troan 
Cc: Brian E Carpenter , draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>
From: Fernando Gont 
Message-ID: 
Date: Thu, 30 Nov 2017 21:14:10 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 13:51:46 -0000

On 11/30/2017 08:45 PM, Ole Troan wrote:
>>
>> IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
>> -- this is the standard, straightforward and most clean approach.
> 
> The best example I've heard is when you don't have a natural tunnel endpoint to encapsulate to.

What's a natural tunnel-endpoint here? Aren't you expecting such
endpoint to exist, to remove the inserted EH, after all? (and listing it
in the RH)

I seem to remember some folks arguing that the rationale for EH
insertion is that performance go to hell if they do proper encapsulation...

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





From nobody Thu Nov 30 11:35:09 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B942A12945D; Thu, 30 Nov 2017 11:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxjkDR-DbbsL; Thu, 30 Nov 2017 11:35:01 -0800 (PST)
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 D8105129447; Thu, 30 Nov 2017 11:35:00 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id v19so14534468wmh.5; Thu, 30 Nov 2017 11:35:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=muMj6wuwM7M6VeWkLrL52V5rMou84QQGhRwltFWavvk=; b=Sh0E9PLUowFRySWE+9cOnL1qKbI3VoT6BuIZ+3old5WkSMkj/OdewqLJ7cSudK5nrF 2uwn1kthSF2hjSp4/njhL7sJR/TKznTBzJfSFN87uUMR4N9tK84jDQmvT6SpiwGz028t DVMCpeOW4MmwXYtQNiChmc2Q1tidrx/5XLQ5vRdmrsWcmzAbUX0vd6KTOgTpYfEv+lEZ +E+ai9KfcqdSuo0BZdxhmjo2QdCODngXPDCkdmcQ9JlRRSqS8x4s9o0vVTFXFApIjL0y Ij6Lt+klYp3zR05vxYWhuLZ5gDa/K0bzLJj+zu1709tMSTF2OsvcCyqG0HDpLyH/O9JE x5vg==
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=muMj6wuwM7M6VeWkLrL52V5rMou84QQGhRwltFWavvk=; b=IztUf64LLr0w6/mzlQoqJFrrFi0Q8iLDGN90wQb8DBu7LpgeqJ1MK7CHkiFBiJtc4f 5glb+LCNY1p7P8oKkF7WspV74y5uqgysbnY0gAIgEVNBNRYZjxAz7eht251pR/9xDIDe aq6xMdQHFYmEayhcTZgph/G2NUj29Hss0LRYti/LQ9UoQqV1QEOk8REPkok7/ZrhhYGm HbtsLrAmrJ2kndc6gZap8OxKzb0JLzA5SRK3epM6NzyihtFzYjAmM1EzhwkOfpl423Xm v61qw6jbrm3WogjQWwQKE/ZI0GgfN+UMdcJGEe4Aoe95bdusvw3bGX43X1Ew3cXsNwPa hsWg==
X-Gm-Message-State: AJaThX78qpxuajSQhiuHoUccoz+WDjbTazg1gHufIwDg4cbFtt1SZ/75 mOmujjXBKf3A7BQ/Q+OOaNjJZvLlTy7sJlpz2/U=
X-Google-Smtp-Source: AGs4zMbNqcHkr/e6nc1PduSHFLAI2wUWQAr4D1qrjWCZBKvBUFVOfwjiOFQaKwWDp0fo+Sk3vPpwy1PTLT2ZkAJvBso=
X-Received: by 10.28.136.15 with SMTP id k15mr1366316wmd.147.1512070499201; Thu, 30 Nov 2017 11:34:59 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.54.217 with HTTP; Thu, 30 Nov 2017 11:34:58 -0800 (PST)
In-Reply-To: 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> 
From: Robert Raszuk 
Date: Thu, 30 Nov 2017 20:34:58 +0100
X-Google-Sender-Auth: UxI5gOXoYR0vAKvUU7yqdrd0iLE
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Fernando Gont 
Cc: Ole Troan , Brian E Carpenter ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: multipart/alternative; boundary="001a1144242afaf699055f3858ab"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 19:35:08 -0000

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

Hi Fernando,

So in the case of encapsulation you normally put the node performing the
encap as source address. That may impact how you handle this packet via
number of services or even by src-dst routing correct ?

So while perhaps some may consider it "cleaner" I think both variants have
their own use cases and should be supported.

Thx,
R.

On Thu, Nov 30, 2017 at 2:14 PM, Fernando Gont 
wrote:

> On 11/30/2017 08:45 PM, Ole Troan wrote:
> >>
> >> IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
> >> -- this is the standard, straightforward and most clean approach.
> >
> > The best example I've heard is when you don't have a natural tunnel
> endpoint to encapsulate to.
>
> What's a natural tunnel-endpoint here? Aren't you expecting such
> endpoint to exist, to remove the inserted EH, after all? (and listing it
> in the RH)
>
> I seem to remember some folks arguing that the rationale for EH
> insertion is that performance go to hell if they do proper encapsulation...
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>

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


Hi Fernando,
So in the case of encapsulation you normally put=
 the node performing the encap as source address. That may impact how you h=
andle this packet via number of services or even by src-dst routing correct=
 ?=C2=A0

So while perh=
aps some may consider it "cleaner" I think both variants have the=
ir own use cases and should be supported.=C2=A0
Thx,
R.
=

On Thu, Nov 30, 2017 at 2:14 PM, Fernando Go=
nt <fgont@si6networks.com> wrote:
On 11/30/2017 08:45 PM, Ole Troan wrote:

>>

>> IMO, #1 thing to be discussed is why normal encapsulation wouldn&#=
39;t work

>> -- this is the standard, straightforward and most clean approach.<=
br>
>

> The best example I've heard is when you don't have a natural t=
unnel endpoint to encapsulate to.



What's a natural tunnel-endpoint here? Aren't you expecting =
such

endpoint to exist, to remove the inserted EH, after all? (and listing it
in the RH)



I seem to remember some folks arguing that the rationale for EH

insertion is that performance go to hell if they do proper encapsulation...=





--

Fernando Gont

SI6 Networks

e-mail: fgont@si6networks.com<=
br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492













--001a1144242afaf699055f3858ab--


From nobody Thu Nov 30 11:35:31 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05931294AC; Thu, 30 Nov 2017 11:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtFhnRGnvG8g; Thu, 30 Nov 2017 11:35:24 -0800 (PST)
Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::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 E48E31294B2; Thu, 30 Nov 2017 11:35:22 -0800 (PST)
Received: by mail-pl0-x22e.google.com with SMTP id 1so4842891pla.7; Thu, 30 Nov 2017 11:35:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RkP1FhsjUUIuwSHHf+hPXfv5vbtDQLIBR4AQKcPiqzM=; b=H5GrIeY/FAQp6Zn18cpBEc4dRR6kh/UbB0tjz3HEz2pCbl5WbbZQN6XVqB5wSvAHaO 8X1/sw3yY12zzI38hpfyHVX+QkoLngMTZu+PDGZ3MfI/f/JDLwxx8PT3DS0DqN24IPuM JKzKVWWPV1nfq/X3Z9MIaqbPquk69vBm8gAiVQD2/nPn68L3t/SKbhHt0fYjBam6HubM MgVKOpbcgelr1aFTeVf+wjEbsxlAakRz1k5HLfo+Jsl9PjI250BFmGRom6NzDOUz1grs s30ptGWXgHOnBv57oRZVDjaN5jRfeHvITBCrpOzKrfAGsa02BbjoLF0k7h4Pk1hH6Ax4 GyFQ==
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=RkP1FhsjUUIuwSHHf+hPXfv5vbtDQLIBR4AQKcPiqzM=; b=CelZks9s721h/DeuDhsVCI3RY3tdfBBKrxpLJ46IgFuwcgVVI2+31Nrfi7norBteoF cX8uZMvjt1M4phBQZrFKBUJbdbCmn6LVqsfM2TtzIDFuori5oRADlh+vwJGsdGm5qVjE ixb6i9/4jV8hESo/Lw8gnMdHcvmAXh9to1PWNhUAR/sR/lJ7oLjVDAhaEUupMSVjN7vg I7mFpv8f8u2VKGY7n10/Fa7MmzYGJGS94Ilv6qCT2vqsncK0inp4IJEbFtjPxcCD+C9J 5cgtZoodELxUa2hy0hkuDx5mbJVGL6V+w7id9M6jF5VRqetIlBoDxYki99QNWMfrMDvJ bDPg==
X-Gm-Message-State: AJaThX45NitZNpJg83Xdej1qdBGoOZwnctMd8JHG79qPcmDpyvjQKbaV nGKIICjZHAMSUj43kkXmo78JbQ==
X-Google-Smtp-Source: AGs4zMaAzZUaJjh6VFswgpwxfHl4WrhIz9roWP2ZzRaxCZiTdmWZCjBQnsaMCdOWlhRqHtS9QVc6+g==
X-Received: by 10.159.198.70 with SMTP id y6mr3769513plt.334.1512070522171; Thu, 30 Nov 2017 11:35:22 -0800 (PST)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id z23sm8098997pgc.2.2017.11.30.11.35.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 11:35:21 -0800 (PST)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Fernando Gont , Ole Troan 
Cc: draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> 
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: <6a9fa2d7-5754-ff17-c5b4-2c6c34002acd@gmail.com>
Date: Fri, 1 Dec 2017 08:35:26 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 19:35:25 -0000

On 01/12/2017 02:14, Fernando Gont wrote:
> On 11/30/2017 08:45 PM, Ole Troan wrote:
>>>
>>> IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
>>> -- this is the standard, straightforward and most clean approach.
>>
>> The best example I've heard is when you don't have a natural tunnel endpoint to encapsulate to.
> 
> What's a natural tunnel-endpoint here? Aren't you expecting such
> endpoint to exist, to remove the inserted EH, after all? (and listing it
> in the RH)
> 
> I seem to remember some folks arguing that the rationale for EH
> insertion is that performance go to hell if they do proper encapsulation...

There will be 40 extra bytes, and they are bytes that could in fact
duplicate the effect of a routing header by changing the apparent
destination address. And if some additional DPI is needed, a node
would need to look through the encapsulation anyway.

This is a question that the draft does indeed need to address.

    Brian


From nobody Thu Nov 30 13:05:11 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A402F1294DB; Thu, 30 Nov 2017 13:05:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 r5xVSGBCIlnr; Thu, 30 Nov 2017 13:05:07 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8183A1294D4; Thu, 30 Nov 2017 13:05:07 -0800 (PST)
Received: from [192.168.3.67] (109-155-16-190.fibertel.com.ar [190.16.155.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 79BB182C31; Thu, 30 Nov 2017 22:04:46 +0100 (CET)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Robert Raszuk 
Cc: Ole Troan , Brian E Carpenter , draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>  
From: Fernando Gont 
Message-ID: <8263fbba-8f37-fc4b-596d-33fa9cc2fe30@si6networks.com>
Date: Fri, 1 Dec 2017 04:59:47 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 21:05:09 -0000

On 12/01/2017 03:34 AM, Robert Raszuk wrote:
> Hi Fernando,
> 
> So in the case of encapsulation you normally put the node performing the
> encap as source address. That may impact how you handle this packet via
> number of services or even by src-dst routing correct ? 
> 
> So while perhaps some may consider it "cleaner" I think both variants
> have their own use cases and should be supported. 

Inserting an EH as suggested is not IPv6, and can break a number of
things. The very least I would expect for a proposal to do so is why
that cannot be done with proper encapsulation. --> i.e., add an outter
IPv6 header with a RH header, and do your thing, as oppose to insert the
RH in there.

Of the top of my head, if part of the claim is the controlled
environment, and that this controlled environment will take care of the
"butchered" packets to be brought back into their original shape, I'd
expect that having a dst addr of a system that can actually do that (as
in the normal encapsulation case) is kind of a requirement...

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





From nobody Thu Nov 30 13:19:08 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A911294B7 for ; Thu, 30 Nov 2017 13:19:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 JoGJBw6fglP6 for ; Thu, 30 Nov 2017 13:19:05 -0800 (PST)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 7BD15127871 for ; Thu, 30 Nov 2017 13:19:05 -0800 (PST)
Received: by mail-qt0-x22c.google.com with SMTP id b10so2885580qti.11 for ; Thu, 30 Nov 2017 13:19:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lbgu00Yu/YojcxNithqTLw1z3XhOCw4yIX71L3myW4w=; b=WZZyHTJbBJVUiaJ32aYhhwHMoLMgzREhaRuoIdTxhXvlEO5rs0tm6rKTzQcuELJSBX aa5qheTciI0vDQxi1WRurrwE7sKYZy94nnTwViSNZvGyc+MmbjrhbFzNfsjK2RUB0TtP HOplJa5pkILAgFbXJ4iWzf06J7Akhm0UuEFo9E9DAVF/JSVgh6tRAD4diEKnRWJPcl0Z GZXzdL1jbyzqbXtQIuMTbQgo7a6D2vVdmAtdLc+28ou0Rpqtr/2mE2uOcWimVM1HbaLp n/MtVpOdH8YzGjer+pWMulmHch8n1ppFLIqryGo9ejzzssVQu6MCai4h0HsGTvEgToFt AjKg==
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=lbgu00Yu/YojcxNithqTLw1z3XhOCw4yIX71L3myW4w=; b=Crn9g2/gkFnTeeb3GQOftLPXWthLwAd2eOd0xlsxwZK3s+XByRVMXMPrTF3oA4wZM2 NhzP8vY/9wcDiMwkwSjxryN4f5lSCOPio6EBx9srHrcBg+cwVfcpbXSohwbMpJkDHh3g a78eeZVPfxDbWEygbTfVYA0pXtRH9YZMsm4fa0ED0S9SZ8apU/PfOn48ly86BEok9VEI /962wp77TCOVcjJ20n3qI6c2dzHCTnPRgIoJiAD/UImC8+X6k5PY8gMmrVt5Ptp0XSnh P6vLmUQxwmTtagMhW/23sG7JRtXKmpgiSMYUXSv9ESx1SRA9fo4xzgb59LhWgcIfR1+g kyjA==
X-Gm-Message-State: AKGB3mJP+fWWzPF+9clABqYi1m0uBJukQ9Gie2c49I0d/MFDllrfV2k5 WlooD1BSlOf9c8Pq+clMeiZ7xYXC6RRwb3/b83eNtg==
X-Google-Smtp-Source: AGs4zMYo/P0n/3MzKtP5oRy31IyjqYHEm9Qy3Lx5lqsxNmQq7uFAUxEP5N2jiUlAmEtWuIKPUrccy1xCxGlbiPI+n7Q=
X-Received: by 10.200.49.101 with SMTP id h34mr5505646qtb.112.1512076744518; Thu, 30 Nov 2017 13:19:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.43.121 with HTTP; Thu, 30 Nov 2017 13:19:04 -0800 (PST)
In-Reply-To: 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>  
From: Tom Herbert 
Date: Thu, 30 Nov 2017 13:19:04 -0800
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Robert Raszuk 
Cc: Fernando Gont ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 21:19:07 -0000

On Thu, Nov 30, 2017 at 11:34 AM, Robert Raszuk  wrote:
> Hi Fernando,
>
> So in the case of encapsulation you normally put the node performing the
> encap as source address. That may impact how you handle this packet via
> number of services or even by src-dst routing correct ?
>
Robert,

I don't understand your point. Isn't the underlying idea here to use
SR to source route a packet through a domain? I don't see why an outer
source address of a tunnel is relevant for that. Also, I'd point out
that encapsulation is hardly a new concept. It is well deployed in
various forms and many network services have already adapted to its
use.

> So while perhaps some may consider it "cleaner" I think both variants have
> their own use cases and should be supported.
>
It's not just about being cleaner, there are questions about
correctness that need to be addressed.

Tom


From nobody Thu Nov 30 13:21:18 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA101127871; Thu, 30 Nov 2017 13:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 Yj4EnxN-Uym1; Thu, 30 Nov 2017 13:21:14 -0800 (PST)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5F2127A91; Thu, 30 Nov 2017 13:21:14 -0800 (PST)
Received: by mail-wr0-x233.google.com with SMTP id v22so8036127wrb.0; Thu, 30 Nov 2017 13:21:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=IDaAahJXlcrvrmXkWbZylTsf0Wa6jayl8/5hPiBjkUg=; b=o4v1OabQMx5D6mvad7JxHlCjIpai3r8ObQp4GyMaZeHHn4XF7/4keIita9gDYTEvDT lKK9Lrebg72k+2QuNzj9F8UtRKR1Rr3BPth/gLRXsDiOFs52faed72szc/am7BbbjEKK ErNEWp4BpYBh0g6RaLbQ0a9H0mzJe82ZMHTNk3wiGqZahv24rB6m2raqwcX1WQNVNci8 e96xz6Ra9RBgYb61cCDF7qWBbRI8lWjsjYOEUgxvqkIm26Sn2iBLLe6qeKg3Pcq2cDUE rxxDAVhgFImsb1+FyJBlNsWrJu/HbpeK+EoA61AHaWOSrXF7tYhPkXQR5pkDkCS5OOkU Mgpw==
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=IDaAahJXlcrvrmXkWbZylTsf0Wa6jayl8/5hPiBjkUg=; b=ZHo9NN3sdShOSnP63XD2RBctDjjiAnBT7Bpk0onTkbzBkgwX9x4DuaNFQ/pzYgDRZg ssH0oLkBFmFmE23CHKx6lPmk+t5/4Zfy5teJTHt7yWWq9rNOTwndOGayye7so3aX4APY CJwtwRFrJSNI/XKJMGgBTwVuXdedR0TuTTwnoS0tv6i3UcENkBiYhHrUy6NKyi+o97HE 3n5Fv6SVLTNAntjOSJ4Q6gabxsiqAYTuQeIcGRcAexhA4OFHxogSd4qBxGnmo7fIYOiT 5K61e4kA9aNy+zkpFxEH5WCQ2AEVxzEMaUWaSjYOuhhLI1P5BWjkNNEEae1mDWRKlUoO 7uJQ==
X-Gm-Message-State: AJaThX55f86++7Y9Sc6FMr8AtU8Hz2voFGyK5GC1P7wzkvfhP9DUxLp1 AcIL5dr1Tb1Lid28gkWlw0auFwBtUmlLXL2+ifU=
X-Google-Smtp-Source: AGs4zMY6t34pOMsaNWvOjQ69j5aXo5W74hQPyfxsSDP55CII9Z7G3ai1mvSUhHHSawWxf+xNHibZHWDXw+9VZS1WklM=
X-Received: by 10.223.158.203 with SMTP id b11mr3139564wrf.256.1512076872191;  Thu, 30 Nov 2017 13:21:12 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.54.217 with HTTP; Thu, 30 Nov 2017 13:21:11 -0800 (PST)
In-Reply-To: <8263fbba-8f37-fc4b-596d-33fa9cc2fe30@si6networks.com>
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>   <8263fbba-8f37-fc4b-596d-33fa9cc2fe30@si6networks.com>
From: Robert Raszuk 
Date: Thu, 30 Nov 2017 22:21:11 +0100
X-Google-Sender-Auth: Wqn9c8xi3x21WGXLovfJa2xSrVg
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Fernando Gont 
Cc: Ole Troan , Brian E Carpenter ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: multipart/alternative; boundary="089e0820c404d718be055f39d4a1"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 21:21:16 -0000

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

As I think it has been very clearly documented in number of drafts dst
address of the packet in the SRv6 domain is the address of the next segment
routing node which swaps it to next segment etc ... So dst address of the
imposed encapsulation will never be the end node which is seen as hope to
put the packet to the "original shape".

I was specifically referring to src address not dst address of the
encapsulated packet.

Thx,
R.

On Thu, Nov 30, 2017 at 9:59 PM, Fernando Gont 
wrote:

> On 12/01/2017 03:34 AM, Robert Raszuk wrote:
> > Hi Fernando,
> >
> > So in the case of encapsulation you normally put the node performing the
> > encap as source address. That may impact how you handle this packet via
> > number of services or even by src-dst routing correct ?
> >
> > So while perhaps some may consider it "cleaner" I think both variants
> > have their own use cases and should be supported.
>
> Inserting an EH as suggested is not IPv6, and can break a number of
> things. The very least I would expect for a proposal to do so is why
> that cannot be done with proper encapsulation. --> i.e., add an outter
> IPv6 header with a RH header, and do your thing, as oppose to insert the
> RH in there.
>
> Of the top of my head, if part of the claim is the controlled
> environment, and that this controlled environment will take care of the
> "butchered" packets to be brought back into their original shape, I'd
> expect that having a dst addr of a system that can actually do that (as
> in the normal encapsulation case) is kind of a requirement...
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>

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



As I think=
 it has been very clearly documented in number of drafts dst address of the=
 packet in the SRv6 domain is the address of the next segment routing node =
which swaps it to next segment etc ... So dst address of the imposed encaps=
ulation will never be the end node which is seen as hope to put the packet =
to the "original shape".=C2=A0

=

I was specifically referring to src address not dst addr=
ess of the encapsulated packet.=C2=A0

Thx,
R.

On Thu, Nov 30, 2017 at 9:59 PM, =
Fernando Gont <fgont@si6networks.com> wrote:
On 12/01/2017 03:34 AM, Robert Rasz=
uk wrote:

> Hi Fernando,

>

> So in the case of encapsulation you normally put the node performing t=
he

> encap as source address. That may impact how you handle this packet vi=
a

> number of services or even by src-dst routing correct ?=C2=A0

>

> So while perhaps some may consider it "cleaner" I think both=
 variants

> have their own use cases and should be supported.



Inserting an EH as suggested is not IPv6, and can break a number of<=
br>
things. The very least I would expect for a proposal to do so is why

that cannot be done with proper encapsulation. --> i.e., add an outter
IPv6 header with a RH header, and do your thing, as oppose to insert the
RH in there.



Of the top of my head, if part of the claim is the controlled

environment, and that this controlled environment will take care of the

"butchered" packets to be brought back into their original shape,=
 I'd

expect that having a dst addr of a system that can actually do that (as

in the normal encapsulation case) is kind of a requirement...




--

Fernando Gont

SI6 Networks

e-mail: fgont@si6networks.com<=
br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492













--089e0820c404d718be055f39d4a1--


From nobody Thu Nov 30 13:25:39 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0B1127871; Thu, 30 Nov 2017 13:25:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkCuEafqF1DZ; Thu, 30 Nov 2017 13:25:36 -0800 (PST)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 139071294CF; Thu, 30 Nov 2017 13:25:36 -0800 (PST)
Received: by mail-wm0-x232.google.com with SMTP id g130so3166634wme.0; Thu, 30 Nov 2017 13:25:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=RHGw5RERQ2OKqSsstgHpDo3l1wKAO9A+y+N2/Sf8kfk=; b=utkLE7KYZ5FEYfwQA0JXayNtYLJn+Zff3CPIq7uOgpCCQRPa4IJaJRPX8yeLz/1LIs Cmf5l/vT2PZYVGg7qva9Eq1DPRuyoHv1zC7JPnoPKhchlGWgs+dlTd3hmPbYx4ArDsty MJhqBeJfrnx/pM73F3Kbx5qrfTyUEulENfEZyeRU8HrwyDeTFdj4UxYc+yCt2/fEsNSf Lt3LPXd/pgv5jQ1iWg4ZUML47u3kCQxbJP0MiyOV8MNE+rEab1RScCz/T4r8P5LSl9yk JRLx0Uy1iD8Dm0AqcP+IoZASDZxuk5R3ZI4IWojxTU96doTTEKLCTGZNY23kHlKffNmq WP0A==
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=RHGw5RERQ2OKqSsstgHpDo3l1wKAO9A+y+N2/Sf8kfk=; b=Dx54Tu+Qld46q09ZpwrtlbDwF6f5b0fV4vI0iNwSOZt6zejC9V4W7sUyprZvpJv9fB RgEfU7ouGN9vbiFZuOLg44DgNQ2t+1HpyPzZ3BT6fHAmu5NcY1Y0nNIGgcRxnAwBPVeP TAyooK5Lv42bfAyWlk6WecG0dUGpUTrPowK+dnY1Toj06KoTcjQwxUpSdDd17i04k0vc 86oL2Vbpfc/tFSaPEeOtHeHJgMaEsEsX3riGMiT3KxB9nILbdkmUlHL2e287SM84ZTSR NxNOyHwkqxtGeYszmWjE8PQ3xhAq7rEsH4dMde9JUTsmT2mT95xniE1A1Ij+/6dYBA1Q 3BMg==
X-Gm-Message-State: AJaThX4TWv3llc5EYpkuvsI87cFHiQ+lEaDGW2MfSWHl1zDakZBXfehl r/Ls8plAwPthPt6wvzbSgtO/LaJmZy6QtcBkGfo=
X-Google-Smtp-Source: AGs4zMaawbf1HBn9eFJWHsC7rLtge6QG1ydg0IkGklHI5+X7nG1UrHzIG44eWBIYQMfEXtnZAWvlhPe0hcVB0B7VKgc=
X-Received: by 10.28.107.5 with SMTP id g5mr1721919wmc.125.1512077134400; Thu, 30 Nov 2017 13:25:34 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.54.217 with HTTP; Thu, 30 Nov 2017 13:25:33 -0800 (PST)
In-Reply-To: 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>   
From: Robert Raszuk 
Date: Thu, 30 Nov 2017 22:25:33 +0100
X-Google-Sender-Auth: QD8XSAhTMb9SNRItvHhcSDVZsMI
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Tom Herbert 
Cc: Fernando Gont ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: multipart/alternative; boundary="001a11462f5678117b055f39e4b5"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 21:25:38 -0000

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

Tom,

Imagine the case where packets are subject to go via service chains. I can
steer the packet to the router which has service nodes connected to it but
original src address may be used to decide which service given packet is
subject to take.

Sure I can impose an SR function and map it up front such that the router
above would never need to inspect src address, but why to construct such
architecture which only allows limited set of network programming as
opposed to offer the choice on how to setup things by network operators ?

Thx,
R.

On Thu, Nov 30, 2017 at 10:19 PM, Tom Herbert  wrote:

> On Thu, Nov 30, 2017 at 11:34 AM, Robert Raszuk  wrote:
> > Hi Fernando,
> >
> > So in the case of encapsulation you normally put the node performing the
> > encap as source address. That may impact how you handle this packet via
> > number of services or even by src-dst routing correct ?
> >
> Robert,
>
> I don't understand your point. Isn't the underlying idea here to use
> SR to source route a packet through a domain? I don't see why an outer
> source address of a tunnel is relevant for that. Also, I'd point out
> that encapsulation is hardly a new concept. It is well deployed in
> various forms and many network services have already adapted to its
> use.
>
> > So while perhaps some may consider it "cleaner" I think both variants
> have
> > their own use cases and should be supported.
> >
> It's not just about being cleaner, there are questions about
> correctness that need to be addressed.
>
> Tom
>

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


Tom,

=

Imagine the case where packets are subject to go via ser=
vice chains. I can steer the packet to the router which has service nodes c=
onnected to it but original src address may be used to decide which service=
 given packet is subject to take.=C2=A0

<=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small">Sure I can impose an SR function and map it up front such=
 that the router above would never need to inspect src address, but why to =
construct such architecture which only allows limited set of network progra=
mming as opposed to offer the choice on how to setup things by network oper=
ators ?=C2=A0

Thx,
=
R.

On =
Thu, Nov 30, 2017 at 10:19 PM, Tom Herbert <tom@herbertland.com><=
/span> wrote:
On Thu, No=
v 30, 2017 at 11:34 AM, Robert Raszuk <robert@raszuk.net> wrote:

> Hi Fernando,

>

> So in the case of encapsulation you normally put the node performing t=
he

> encap as source address. That may impact how you handle this packet vi=
a

> number of services or even by src-dst routing correct ?

>

Robert,



I don't understand your point. Isn't the underlying idea here to us=
e

SR to source route a packet through a domain? I don't see why an outer<=
br>
source address of a tunnel is relevant for that. Also, I'd point out
that encapsulation is hardly a new concept. It is well deployed in

various forms and many network services have already adapted to its

use.



> So while perhaps some may consider it "cleaner" I think both=
 variants have

> their own use cases and should be supported.

>

It's not just about being cleaner, there are questions about

correctness that need to be addressed.



Tom





--001a11462f5678117b055f39e4b5--


From nobody Thu Nov 30 13:27:53 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D23128B88; Thu, 30 Nov 2017 13:27:51 -0800 (PST)
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 oZW7x-OsecW7; Thu, 30 Nov 2017 13:27:49 -0800 (PST)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C830127871; Thu, 30 Nov 2017 13:27:49 -0800 (PST)
Received: by mail-ua0-x22f.google.com with SMTP id i92so6701381uad.7; Thu, 30 Nov 2017 13:27:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TPVIVPtOtqTj4k9Bpo4PJK1FuUewetscnFDaoYwZlTw=; b=qAHNi24EVELH/GDk0FnimBT4IBOohdpkqN3fVQUu4TBAuS77llAwLsl6dGp5NWahcX 2I+wtcPjrlT/ccf0iL/aVesPoH+8GALoGxZ6gMuM6K3MTFN+FZU002e6TrbQs271fLzL 54uWKKLPNuivqmAUTLa/+AljD/HXnZf/XdLfTTQw6v7C5ZMcwDD2nc6h2g74pgv7Ipib BVNChWMobOTUolVj1X8oAry8d8sLuZAhn50FvGvFHnqLNTSmijhAqqaauPC3yHvkHpRh 3d8DKbecKmbrGtyDfq8t6DE1Qz9jbAndOYUKyO7DpHC9g4FgOiAqHtRu8tpfHd1nFmRj Kp8A==
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=TPVIVPtOtqTj4k9Bpo4PJK1FuUewetscnFDaoYwZlTw=; b=bs7VmPnz+EpLOALN/rnbgBKVPvl0oRioKp1rzVCxtnR7F0Z0m8JnNCyuO8r0B1vGZ3 2Rs4HsRj3582gcwV5JfuKhjIaVZMFlqKDwHHXQ5mnk5tViVQNawR+3yc3JNDyQpuaeeI pkmRJKKWYVDTZ5qCZioBUuGUIZ6n8QLHtgZlpCMURdFjBPAusAuL7nyNM/U+vv9dEh5+ xJYvfkbnJx+j7UfRGliSHTz9YvVhaQTlbzIvopQZE/y2tZTquIP5od6vpiTmRWfUqwjw c52ffekROMJ6DfCnu78PGXIdSKGvK+blqg+xER7416RBIySvZdXYIv/3VkiscDaF352C jSgQ==
X-Gm-Message-State: AJaThX7EKE6UI0LSRwIiZRDdUOJlG+CZALf9QA9XCkAE/OqkubBSucOl fJGSvpgNWtvJyTzsC6qKbvyptWdvjAj7GmkWhAg=
X-Google-Smtp-Source: AGs4zMZicGOMh8kx9OzsiM2XUxtcLTTJZVChEF/Uox02WKPTxFRUkckyeccUUEGSgtW0giZi7q5ldhzeZj2liTT2T2I=
X-Received: by 10.176.19.130 with SMTP id m2mr3109241uae.57.1512077268119; Thu, 30 Nov 2017 13:27:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.56.218 with HTTP; Thu, 30 Nov 2017 13:27:47 -0800 (PST)
Received: by 10.159.56.218 with HTTP; Thu, 30 Nov 2017 13:27:47 -0800 (PST)
In-Reply-To: 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>  
From: Mark Smith 
Date: Fri, 1 Dec 2017 08:27:47 +1100
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Robert Raszuk 
Cc: Fernando Gont ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: multipart/alternative; boundary="001a1145675e70777e055f39eca3"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 21:27:51 -0000

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

On 1 Dec. 2017 6:35 am, "Robert Raszuk"  wrote:

Hi Fernando,

So in the case of encapsulation you normally put the node performing the
encap as source address. That may impact how you handle this packet via
number of services or even by src-dst routing correct ?

So while perhaps some may consider it "cleaner" I think both variants have
their own use cases and should be supported.



The trouble is they're not explained at all.

All there is is an assertion that "operators want this", which is the
logical fallacy of an appeal to authority.

 I'm an operator, and I don't want it. I think it'll be harder to
troubleshoot than NAT over the Internet and NAT is bad enough.


Thx,
R.

On Thu, Nov 30, 2017 at 2:14 PM, Fernando Gont 
wrote:

> On 11/30/2017 08:45 PM, Ole Troan wrote:
> >>
> >> IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
> >> -- this is the standard, straightforward and most clean approach.
> >
> > The best example I've heard is when you don't have a natural tunnel
> endpoint to encapsulate to.
>
> What's a natural tunnel-endpoint here? Aren't you expecting such
> endpoint to exist, to remove the inserted EH, after all? (and listing it
> in the RH)
>
> I seem to remember some folks arguing that the rationale for EH
> insertion is that performance go to hell if they do proper encapsulation...
>
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

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




On 1 Dec. 2017 6:35 am, "Robert Raszuk" <robert@raszuk.net> wrote:
Hi Fer=
nando,

So in the case =
of encapsulation you normally put the node performing the encap as source a=
ddress. That may impact how you handle this packet via number of services o=
r even by src-dst routing correct ?=C2=A0

So while perhaps some may consider it "cleaner&quo=
t; I think both variants have their own use cases and should be supported.=
=C2=A0


The trouble is they're =
not explained at all.

Al=
l there is is an assertion that "operators want this", which is t=
he logical fallacy of an appeal to authority.

=C2=A0I'm an operator, and I don't want it. I=
 think it'll be harder to troubleshoot than NAT over the Internet and N=
AT is bad enough.


Thx,
=
R.

On Thu, Nov 30, 2017 at 2:14 PM, Fernando Gont <fgont@si6networks.com> wrote:
On 11/30/2017 08:45 PM, Ole Troan wrote:

>>

>> IMO, #1 thing to be discussed is why normal encapsulation wouldn&#=
39;t work

>> -- this is the standard, straightforward and most clean approach.<=
br>
>

> The best example I've heard is when you don't have a natural t=
unnel endpoint to encapsulate to.



What's a natural tunnel-endpoint here? Aren't you expecting =
such

endpoint to exist, to remove the inserted EH, after all? (and listing it
in the RH)



I seem to remember some folks arguing that the rationale for EH

insertion is that performance go to hell if they do proper encapsulation...=





--

Fernando Gont

SI6 Networks

e-mail: fgont@si=
6networks.com

PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492














------------------------------------------------------------=
--------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

-----------------------------------------------------------------=
---





--001a1145675e70777e055f39eca3--


From nobody Thu Nov 30 13:44:56 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785E11294EF; Thu, 30 Nov 2017 13:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 GJ60P8AQMUop; Thu, 30 Nov 2017 13:44:37 -0800 (PST)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47BC21205D3; Thu, 30 Nov 2017 13:44:37 -0800 (PST)
Received: by mail-wr0-x229.google.com with SMTP id x49so8065625wrb.13; Thu, 30 Nov 2017 13:44:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=w86EPWJVE8euRmuIy/blY9ybi0J0R7RJDjdOx8Udc1k=; b=VboMUjKg1NKKKLDmpbCcY7wbFnd/GePc20SR3d9rLf/SrwS1IL3YP2U/+LdQUXJa7o 1yEfkWLNpFN2M0jvM06dZ+UXQ0VHV6PAUCdyCGTYGccHWTeUNTmPVsiZI+ggLsnMXTvp vPRMu+en+k+2tXy+cXVtwZzSJevIwxzzXh9RBuzEbULKZxj77nDEa4U61FAL+2uWHFZo DO0PtSLtCnU8WUcHxzCFlEwjFW7q+m0pcU5BkLbd8StVZDtHIbRTcFGsgITLfp3MLODR JaQyTZ3l6sz6Sy6z2NBm+ppZW3HC5/G6sH6j4PfEdN50efkNPMMEej1nSLqVeNXyfoVJ AF+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=w86EPWJVE8euRmuIy/blY9ybi0J0R7RJDjdOx8Udc1k=; b=KCiJRtAwNEaiF7zptILP1GhyqVvE9U5TPq3TwjgaTznj8WX70GGt4D0o+3liBJJd8o g5CYh77bmOQyR6UFkC0KSgOlH6tS/BNtlFGuahoejEnZbeceFT2GGfiNDeIE3pjJWTHK qwzrKjPpiUEHii69qr8UIijgAdvIjmoORSy8qF/MYe6EUMwcczabbATTsizQ7h3bkNmn UWqP+ETn8SjCDDBzcMUwbK4HULYhnGEWEfS2m2QDkeKESlg/kgcekp1ifE68k1WbAOM+ pc/6zYbjsC8PPpNRxr8gtLioMz7N7zylo1MH5itmBJwJoutM4U678nxx9ABu6AL7hqd2 spzw==
X-Gm-Message-State: AJaThX7rPEXgket8NuQVNxFhjmWRtkcsSLNlDhh0MHliVu9Af0qcYq28 xhNRUA+GH9WWhgIM+BVWSTPFyESokBz/88laUJg=
X-Google-Smtp-Source: AGs4zMbMRv+RlF40OrCTyVWa5QwZGSQ9lG8OTit9lqDCJLncfxS4nyFt5g7UeyGs9EwdO7a2Sn1VWqpcdb9snjBiJ90=
X-Received: by 10.223.157.206 with SMTP id q14mr3005131wre.223.1512078275583;  Thu, 30 Nov 2017 13:44:35 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.54.217 with HTTP; Thu, 30 Nov 2017 13:44:35 -0800 (PST)
In-Reply-To: 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>   
From: Robert Raszuk 
Date: Thu, 30 Nov 2017 22:44:35 +0100
X-Google-Sender-Auth: CH4kFCXqe-NDTUkLa0jbXRZz2Ck
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Mark Smith 
Cc: Fernando Gont ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: multipart/alternative; boundary="f403043990d47d2414055f3a286e"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 21:44:39 -0000

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

>  I'm an operator, and I don't want it.

If you don't want it - do not use it.

> and NAT is bad enough.

While I am not a NAT supporter imagine you are running an enterprise with
15,000 CEs each connected to customers with different (and often
overlapping) IPv4 networks. You have a choice to do local proxy at all
customer sites for all types of services you offer or do NAT and get
customer's queries to your POPs. Just think what makes sense and what not
in such scenario.

Best,
R.

On Thu, Nov 30, 2017 at 10:27 PM, Mark Smith  wrote:

>
>
> On 1 Dec. 2017 6:35 am, "Robert Raszuk"  wrote:
>
> Hi Fernando,
>
> So in the case of encapsulation you normally put the node performing the
> encap as source address. That may impact how you handle this packet via
> number of services or even by src-dst routing correct ?
>
> So while perhaps some may consider it "cleaner" I think both variants have
> their own use cases and should be supported.
>
>
>
> The trouble is they're not explained at all.
>
> All there is is an assertion that "operators want this", which is the
> logical fallacy of an appeal to authority.
>
>  I'm an operator, and I don't want it. I think it'll be harder to
> troubleshoot than NAT over the Internet and NAT is bad enough.
>
>
> Thx,
> R.
>
> On Thu, Nov 30, 2017 at 2:14 PM, Fernando Gont 
> wrote:
>
>> On 11/30/2017 08:45 PM, Ole Troan wrote:
>> >>
>> >> IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
>> >> -- this is the standard, straightforward and most clean approach.
>> >
>> > The best example I've heard is when you don't have a natural tunnel
>> endpoint to encapsulate to.
>>
>> What's a natural tunnel-endpoint here? Aren't you expecting such
>> endpoint to exist, to remove the inserted EH, after all? (and listing it
>> in the RH)
>>
>> I seem to remember some folks arguing that the rationale for EH
>> insertion is that performance go to hell if they do proper
>> encapsulation...
>>
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>

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


>=C2=A0 I'm an operator, and I don't want=
 it.

If you don't want it=
 - do not use it.=C2=A0=C2=A0

>=
 and NAT is bad enough.

While I am n=
ot a NAT supporter imagine you are running an enterprise with 15,000 CEs ea=
ch connected to customers with different (and often overlapping) IPv4 netwo=
rks. You have a choice to do local proxy at all customer sites for all type=
s of services you offer or do NAT and get customer's queries to your PO=
Ps. Just think what makes sense and what not in such scenario.=C2=A0=


Best,
R.
<=
/div>

On Thu, Nov =
30, 2017 at 10:27 PM, Mark Smith <markzzzsmith@gmail.com> wrote:


On=
 1 Dec. 2017 6:35 am, "Robert Raszuk" <robert@raszuk.net> wrote:
Hi Fernando,

So in the case of encapsulation you normally put the node per=
forming the encap as source address. That may impact how you handle this pa=
cket via number of services or even by src-dst routing correct ?=C2=A0

So while perhaps some may =
consider it "cleaner" I think both variants have their own use ca=
ses and should be supported.=C2=A0


The trouble is they're not explained at all.

All there is is an assertion that "=
operators want this", which is the logical fallacy of an appeal to aut=
hority.

=C2=A0I'm an=
 operator, and I don't want it. I think it'll be harder to troubles=
hoot than NAT over the Internet and NAT is bad enough.


Thx,
=
R.

On Thu, Nov 30, 2017 at 2:14 P=
M, Fernando Gont <fgont@si6networks.com> wrote:
On 11/30/2017 08:45 PM, Ole Troan wrote:
>>

>> IMO, #1 thing to be discussed is why normal encapsulation wouldn&#=
39;t work

>> -- this is the standard, straightforward and most clean approach.<=
br>
>

> The best example I've heard is when you don't have a natural t=
unnel endpoint to encapsulate to.



What's a natural tunnel-endpoint here? Aren't you expecting =
such

endpoint to exist, to remove the inserted EH, after all? (and listing it
in the RH)



I seem to remember some folks arguing that the rationale for EH

insertion is that performance go to hell if they do proper encapsulation...=





--

Fernando Gont

SI6 Networks

e-mail: fgont@si=
6networks.com

PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492














------------------------------------=
--------------------------------

IETF IPv6 working group mailing list

ipv6@ietf.org

Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

-----------------------------------------------------------------=
---








--f403043990d47d2414055f3a286e--


From nobody Thu Nov 30 13:54:48 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B051294F4 for ; Thu, 30 Nov 2017 13:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 VizlD0OWYsAe for ; Thu, 30 Nov 2017 13:54:44 -0800 (PST)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 6EF3C1294F0 for ; Thu, 30 Nov 2017 13:54:44 -0800 (PST)
Received: by mail-qt0-x234.google.com with SMTP id b10so3001162qti.11 for ; Thu, 30 Nov 2017 13:54:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I83KPG3xnZxkO3wyvvWTliN35drDQJTmi6EOuyRlBcs=; b=xuzcMWaLN32EShQFRQy9FYZKvzmBD61fy7kpGgYc8VHgZpC4c1Owa3Vdebz6oZdVui 7oyHC0tpBD/jpSNb7/4LjhGtHSw8ZI9f0j+xofFVbYv0kpbuQTnRVjuA5JqKUrUhGWnw QmGFGpgO+1a+Mvrsx+huRohfP7NcucwIV1TX76Y2vUiFtPm1mOduyWkBlmpNooD+KbuA hlxM/rCxgMPHem+I+EdYkhikdBEXGeijhinoOizLxyubsXRYDieC/bwJpdQ6XW8k3cU/ nNA61uUgU/2kJ2QIXLq+M4T6xnvQQzZShbCrVK7NiVE+grM45IxHP259G2OZCWmcy9XD RoGQ==
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=I83KPG3xnZxkO3wyvvWTliN35drDQJTmi6EOuyRlBcs=; b=hH+usp05FblDXl9UbNj40tTfGPeNKzgHAnME2u/IjQ7u6bAT8XAzpa9GOy7sy5UI2S MsbVRChHb77q7pgGJUBD5SUcrjIl2rkD8lKORV/4JeBbqCA7g0o1pLIP8BGGN8/wsZoF ybPcT75v/jqBsk92tVIR4ab+HoeyGfaIuTarG1JKdxOQ3tjLb9eAnS/ShkKe/j3h9CEC sb+gJCFajyZ+jmKScW/SoSahl7L8HPl3Cqrw1fjT1zrdBXploAN5RwPBxFGcFCkpxf5H uA+u3DgoQEb7t1aUjc2uyy2GdqKmwrEhibpvySoQlK7Lw7LlZB3JPXtFGWvGQqwEyc8c Ca8g==
X-Gm-Message-State: AKGB3mLk/zrYWrwmcLzsS/g16WPeOji0FZPgnC3Sz9n4+7+xbeC4dj6/ MrSKFi9LqX7fU2I0h2jVHK+vnMzlRYWhwJtAhZ3fVA==
X-Google-Smtp-Source: AGs4zMai/u9f7TPtEU3w+t+uQhuzLCAs/ptmn24IwL1MVDlNWzVSPsVnLxN8N3bEy32iJxgYriP7seNj88y7EAk6v+s=
X-Received: by 10.200.49.99 with SMTP id h32mr5555813qtb.196.1512078883522; Thu, 30 Nov 2017 13:54:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.43.121 with HTTP; Thu, 30 Nov 2017 13:54:43 -0800 (PST)
In-Reply-To: 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>    
From: Tom Herbert 
Date: Thu, 30 Nov 2017 13:54:43 -0800
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Robert Raszuk 
Cc: Fernando Gont ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 21:54:46 -0000

On Thu, Nov 30, 2017 at 1:25 PM, Robert Raszuk  wrote:
> Tom,
>
> Imagine the case where packets are subject to go via service chains. I can
> steer the packet to the router which has service nodes connected to it but
> original src address may be used to decide which service given packet is
> subject to take.
>
> Sure I can impose an SR function and map it up front such that the router
> above would never need to inspect src address, but why to construct such
> architecture which only allows limited set of network programming as opposed
> to offer the choice on how to setup things by network operators ?
>
Robert,

Because the architecture, or at least protocol, is not correct.

Suppose a device inserts an EH into a packet that downstream causes
the packet to be dropped and generates an ICMP error which goes back
to the source. What is a source host supposed do with this? It might
be able to determine that it didn't send the EH, and if it's lucky it
might even be able to parse the offending EH and maybe even sees the
problem that caused the error. But then what? How does the host tell
the network to stop mucking with its packets so that they no longer
get dropped and the source host doesn't get blamed?

ICMP handling is just one of several issues that needs to be
addressed. If the only answer is that these aren't concerns because
the protocol is only deployed in controlled networks, then I claim
that's nothing more than hand waving which is not robust and doesn't
scale.

Tom


From nobody Thu Nov 30 14:07:49 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871B1126B6E; Thu, 30 Nov 2017 14:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 BTZcTVgI5fWk; Thu, 30 Nov 2017 14:07:46 -0800 (PST)
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 113171200CF; Thu, 30 Nov 2017 14:07:46 -0800 (PST)
Received: by mail-wr0-x22f.google.com with SMTP id x49so8118150wrb.13; Thu, 30 Nov 2017 14:07:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Y7IcYBBPRmF5QODGGTQrj60e6pLLwQ5KRbzFjH3/0Rw=; b=G9w/WAV/DMktKjaW6X7EPqMXIMaI/4hk6OaM/XYK9SRZ0lnjOQgG7i1nJjeC3XZIiJ XiR+QFl1NYO88d1W82J6iKNl0xtPKpKzY591LxoI1d2RwFZTTlycXNCLCPD+RLHPWPFz F4Tb3psH5Y67xyNNMopvKRfA76hxuf9meHqVMVfVBd5u4QuGdAmrMyHVutdigt7CmpEY iq2/ZBMYXTDLPd1rI76cT2ttH1zY9qweqbbTBboOiA4QnESUFQHOjdmwjSXidGaNwdMt sev63EeVlPmknkf9rNSAPdTQhOmlkVKfpL7f2AWUFgvNM8wrNKsz5wQOyUZGk02wANbT bh8g==
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=Y7IcYBBPRmF5QODGGTQrj60e6pLLwQ5KRbzFjH3/0Rw=; b=T2pmbzN/dd8vALZzJK6e+NgTlf6SxIJE1eE/d+fUQVWfazkKcHvTAIt+EZ6n8j+1fC mrW8grardbe8d8LMJjWeU815z8EmUgAZxXyAsVcqpu7wfZiVD9wxIOuTZrwo8uPZLFxw MXeLl5/02Li/3COaG7hPk+8kmcDuS/ysa4/Di3WrcttFw7GHcjgPZxmew4cI3/BLJjvn RsCjeGWNounU7oWynb8jj4nEeQtRL4CyQyPtwqklwmvhAzkYVoLUHuD+5sID2uAiEEkr qU/xU1qPQFWH/6raQ5FrnYSiY49jLmGUaHxiWY9FELxEC0CaK0WtBXPCVCaFUjEmpvWV +Q5g==
X-Gm-Message-State: AJaThX53Z1GcIF7Npu7gi2m5fcIUlyRxehJnVMqwNWWn3MUWEU7wU8O4 LhRx9ddagppIdCew6nUWV7bXZTvNei1zVsdRj5k=
X-Google-Smtp-Source: AGs4zMZ8dl1ZTOOhV3nit0zlCwUAGTddjWm+iHJil+LttMn8N46HaFtmibF6cRpsfOebfD9yo5KK7Oj+Asend4SIxn4=
X-Received: by 10.223.182.81 with SMTP id i17mr3230730wre.224.1512079664282; Thu, 30 Nov 2017 14:07:44 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.54.217 with HTTP; Thu, 30 Nov 2017 14:07:43 -0800 (PST)
In-Reply-To: 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>     
From: Robert Raszuk 
Date: Thu, 30 Nov 2017 23:07:43 +0100
X-Google-Sender-Auth: WFihk51e3Tr7Dj6QHaj85UcLh3s
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Tom Herbert 
Cc: Fernando Gont ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: multipart/alternative; boundary="f4030439df9043039f055f3a7b50"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 22:07:47 -0000

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

Tom,

The biggest advantage of SRv6 in contrast to SR-MPLS is that the SRH (one
or more) are not modified through the SR applicability of the packets.

So node which understands SRv6 can generate ICMP to both src of the packet
(poor host) as well as ingress node in SR domain (as it is explicitly
listed in Ingress Node TLV of first SRH). Node which does not understand
SRv6 will likely only send it to original src .. but this is a feature not
a bug. This is how traceroute works.

If you do encap how will host now see all the nodes on the way traceroute
or tracepath ? Do you think that hosts admins will be happy to be blinded
by 6man ?

Btw I am not the one who ever claimed applicability to "controlled
networks" or "wall gardens" so don't try to use that one with me :)). For
me the much bigger question is what should go into data plane and what is
better to go in control plane. We may end up with both and let
customers/operators choose. But hand waving that doing innovation in data
plane is scary is not the approach I would endorse.

We would be still doing token ring or FDDI ....

Cheers,
R.


On Thu, Nov 30, 2017 at 10:54 PM, Tom Herbert  wrote:

> On Thu, Nov 30, 2017 at 1:25 PM, Robert Raszuk  wrote:
> > Tom,
> >
> > Imagine the case where packets are subject to go via service chains. I
> can
> > steer the packet to the router which has service nodes connected to it
> but
> > original src address may be used to decide which service given packet is
> > subject to take.
> >
> > Sure I can impose an SR function and map it up front such that the router
> > above would never need to inspect src address, but why to construct such
> > architecture which only allows limited set of network programming as
> opposed
> > to offer the choice on how to setup things by network operators ?
> >
> Robert,
>
> Because the architecture, or at least protocol, is not correct.
>
> Suppose a device inserts an EH into a packet that downstream causes
> the packet to be dropped and generates an ICMP error which goes back
> to the source. What is a source host supposed do with this? It might
> be able to determine that it didn't send the EH, and if it's lucky it
> might even be able to parse the offending EH and maybe even sees the
> problem that caused the error. But then what? How does the host tell
> the network to stop mucking with its packets so that they no longer
> get dropped and the source host doesn't get blamed?
>
> ICMP handling is just one of several issues that needs to be
> addressed. If the only answer is that these aren't concerns because
> the protocol is only deployed in controlled networks, then I claim
> that's nothing more than hand waving which is not robust and doesn't
> scale.
>
> Tom
>

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


Tom,

=

The biggest advantage of SRv6 in contrast to SR-MPLS is =
that the SRH (one or more) are not modified through the SR applicability of=
 the packets.=C2=A0

So=
 node which understands SRv6 can generate ICMP to both src of the packet (p=
oor host) as well as ingress node in SR domain (as it is explicitly listed =
in Ingress Node TLV of first SRH). Node which does not understand SRv6 will=
 likely only send it to original src .. but this is a feature not a bug. Th=
is is how traceroute works.=C2=A0

If you do encap how will host now see all the nodes on the wa=
y traceroute or tracepath ? Do you think that hosts admins will be happy to=
 be blinded by 6man ?=C2=A0

Btw I am not the one who ever claimed applicability to "controll=
ed networks" or "wall gardens" so don't try to use that =
one with me :)). For me the much bigger question is what should go into dat=
a plane and what is better to go in control plane. We may end up with both =
and let customers/operators choose. But hand waving that doing innovation i=
n data plane is scary is not the approach I would endorse.=C2=A0

We would be still doing token ri=
ng or FDDI ....=C2=A0

=
Cheers,
R.


On Thu, Nov 30, 2017 at 10:54 PM, Tom =
Herbert <tom@herbertland.com> wrote:
On Thu, Nov 30, 2017 at 1:25 PM, Robert Rasz=
uk <robert@raszuk.net> wrote=
:

> Tom,

>

> Imagine the case where packets are subject to go via service chains. I=
 can

> steer the packet to the router which has service nodes connected to it=
 but

> original src address may be used to decide which service given packet =
is

> subject to take.

>

> Sure I can impose an SR function and map it up front such that the rou=
ter

> above would never need to inspect src address, but why to construct su=
ch

> architecture which only allows limited set of network programming as o=
pposed

> to offer the choice on how to setup things by network operators ?

>

Robert,



Because the architecture, or at least protocol, is not correct.



Suppose a device inserts an EH into a packet that downstream causes

the packet to be dropped and generates an ICMP error which goes back

to the source. What is a source host supposed do with this? It might

be able to determine that it didn't send the EH, and if it's lucky =
it

might even be able to parse the offending EH and maybe even sees the

problem that caused the error. But then what? How does the host tell

the network to stop mucking with its packets so that they no longer

get dropped and the source host doesn't get blamed?



ICMP handling is just one of several issues that needs to be

addressed. If the only answer is that these aren't concerns because

the protocol is only deployed in controlled networks, then I claim

that's nothing more than hand waving which is not robust and doesn'=
t

scale.



Tom





--f4030439df9043039f055f3a7b50--


From nobody Thu Nov 30 14:30:37 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00EC129504 for ; Thu, 30 Nov 2017 14:30:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 YqsSd1R22bhH for ; Thu, 30 Nov 2017 14:30:33 -0800 (PST)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 E94131286C7 for ; Thu, 30 Nov 2017 14:30:32 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id d4so10836522qtj.5 for ; Thu, 30 Nov 2017 14:30:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6kzHiNcxGjojk9A15bwqxMAIL3Eer9Nlzqn7DFr19ek=; b=SpksG9NQbwfkijcrmJhRyv+dITRY+SctsOdUfDgu/XHUPUL7+UsNotuumMLQ1W6dZ/ he5BmiCfTo9p0oHc/E+t/e+VNgdSIafT/85K2r+1HKHQRgY+0WDENzfDsMPiioLjUIol dN3CjplpNK9kAeDBYMv67xXO/xRuGb2mbU+zaxxNjmmjA7t1IVieqNvTb4oCGcJC5HBr /F6iYkKvsTmIbO+oyJ+GuclDI9cKGFQd6/BwZnyjFbdVx4gLZWquYMukSmsng46iT3fA 0p9ivd9+k4OAwBfMvQyneyn3vJsv9aDswAnW9ToSvhr+LZ0MlS+rHfKQr5eTh2xeeelp 0TbQ==
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=6kzHiNcxGjojk9A15bwqxMAIL3Eer9Nlzqn7DFr19ek=; b=SdZHsadsQDTk/fiQhnx7GlMzBkeIP3kktSG28OxvUYa7Oz1hLJOkHKqeplnnyGDdRo qwAqmQEEo9xOQ88Nt31NcJ6kskH83N5DmQ5xxAfjZYniIZE4x6pwD4fqJRRLhX0ikN+D acYFiKCPsAqAtReMCTEA645OMMYv3fkmP+ynfEvtqriGEgQ1o6LnceTyWVdETlxxRPcc y6TbnfAfvmlvVNlXZiCtadpXWXgXrPLPxSPuQGie8TypGIPvdstAjy+IC8pE9iNioJXv 2wPWx3fLPIEugYshnU8Z8/lqYKdLYlMbYcNdDfGv6Dz0YPOOodnVkRH22hadAlZ1AzMp wM4g==
X-Gm-Message-State: AKGB3mIZNIAXOAoIdnxQ0837y80a0IrrdrzV6xSEqiAw9YcF+qILtfTt UMLjb3Eldmh7466x8/T7OVOSLFglscnDa4bEMgKuZw==
X-Google-Smtp-Source: AGs4zMb/o+U4RLumKFFPdHLpMfAg4rv31g3JwoAg4JcLIUSoh5lg5HfAV8RrRfMK8wkrGcUuWXVfnFpnv6HpZIv8Mbw=
X-Received: by 10.200.22.91 with SMTP id x27mr5765353qtk.226.1512081031970; Thu, 30 Nov 2017 14:30:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.43.121 with HTTP; Thu, 30 Nov 2017 14:30:31 -0800 (PST)
In-Reply-To: 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>      
From: Tom Herbert 
Date: Thu, 30 Nov 2017 14:30:31 -0800
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Robert Raszuk 
Cc: Fernando Gont ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 22:30:36 -0000

On Thu, Nov 30, 2017 at 2:07 PM, Robert Raszuk  wrote:
> Tom,
>
> The biggest advantage of SRv6 in contrast to SR-MPLS is that the SRH (one or
> more) are not modified through the SR applicability of the packets.
>
> So node which understands SRv6 can generate ICMP to both src of the packet
> (poor host) as well as ingress node in SR domain (as it is explicitly listed
> in Ingress Node TLV of first SRH). Node which does not understand SRv6 will
> likely only send it to original src .. but this is a feature not a bug. This
> is how traceroute works.
>
But it is a bug. This is sending ICMP errors to hosts about packets
containing tcontent that they could not have possibly sent. What's
worse is that if the ICMP error contains the SR header this gives the
host a whole bunch of detail about the internal structure and paths of
the network which seems like a security issue to me.

> If you do encap how will host now see all the nodes on the way traceroute or
> tracepath ? Do you think that hosts admins will be happy to be blinded by
> 6man ?
>
A nice solution to the traceroute issue for encapsulation has already
proposed. See https://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-03.
Many similar issues regarding encpasulation (dealing the MTU, ECN,
diff-serv propagation, etc.) have also been thought through in various
RFCs (RFC4459 for instance discusses the MTU and fragmentation).

Tom


Tom


From nobody Thu Nov 30 14:48:28 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7F2127010; Thu, 30 Nov 2017 14:48:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level: 
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 uCSo5CrwJqNq; Thu, 30 Nov 2017 14:48:05 -0800 (PST)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49007124205; Thu, 30 Nov 2017 14:48:05 -0800 (PST)
Received: by mail-wr0-x233.google.com with SMTP id y21so8200485wrc.1; Thu, 30 Nov 2017 14:48:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=G9RKzwOT5VB+shgOtZtNuyfl/dRMzaWA9sNlf7gXHyE=; b=qqCwrWfLvZKoU3y3XN+Gn3x/zwcmTN0OKuJ7yPI7Y68L+PS/GvNaVC0ItG3rfkkT1o dVDDUvzn1GhVSwD2tv0qTxPhLR3zEPm9rTD136GfdpDwLTqFO+mBSeNutk1Ho0uk0nx1 Y1TBM8u4xbQ4GE79MzyeaOGSmCCnoHBu/wwn6Ra9XsLhsCYSTDqNibsJFfeIEzlGdug3 KmlsQMKCtpQVgC7WCAD0RHadxfPRzx5WbO73DEJC6vUNRZLFmhFTaU0tSYs0brA85Rcs JiQEtnU6DOP0q8rg6HO0FH9U1t2GQ/2ZAPYh/CU/GwVIEN2A8Gf8VW6yW4gDgF6pNixB nEGg==
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=G9RKzwOT5VB+shgOtZtNuyfl/dRMzaWA9sNlf7gXHyE=; b=V7grsnEkIPAPiEE5J87yTsxrF3F2q9PGP1vqIrcDAnel9Q/jmNs2qWLFvQox+kgM4r ABHh9bfur7qda2+qEdUY3ZK0R1p9oZtLBjtZVRveGbQTOZGkcacG/ZEiDRr0rMRLnPYh 7KOB/f8Hka03gxGLaU57yIzHAAVmHCbc38+iMcL3TNJSXrByYIxQPCPblBMj4rkEXHN9 2N1y+Al/NwMm991R4YVXoFTcl73CvYr24P4pBVOsZyJYoTlbGfignhyg6MEY7CmM3gSm SCG4XICNSFXScYy5Y/53wflYeKCrCSx7HdY932OLGKA7BoPive1gxg14AeLvqqJFeCSH SPIw==
X-Gm-Message-State: AJaThX4L+e3722vtW3JKgs76ScljcRMeC/p/2ZOu0Iw3sorlhttorYPY 8y+oPJdbba7YNUDBow/7tQNnIG1f3O+Pb7scfI8=
X-Google-Smtp-Source: AGs4zMaBrNzQihQNhp6QvuBtcojoUsNCBnA3mZ56P+br3VKCqubltYDfu66pANwarXUZCP1jNNt3veKpMs1AlIx5eOE=
X-Received: by 10.223.163.216 with SMTP id m24mr3315506wrb.107.1512082083703;  Thu, 30 Nov 2017 14:48:03 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.54.217 with HTTP; Thu, 30 Nov 2017 14:48:03 -0800 (PST)
In-Reply-To: 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>       
From: Robert Raszuk 
Date: Thu, 30 Nov 2017 23:48:03 +0100
X-Google-Sender-Auth: NgOrHFLC9qByjI_znx2G9iJUUr4
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Tom Herbert 
Cc: Fernando Gont ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: multipart/alternative; boundary="f403045f19c27871ff055f3b0ba5"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 22:48:07 -0000

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

> A nice solution to the traceroute issue for encapsulation has already
> proposed. See https://tools.ietf.org/html/draft-nordmark-nvo3-
> transcending-traceroute-03.
>

=E2=80=8BAnd where in the v6 header would you place a T-flag ? =E2=80=8B

The proposal above is about the overlay. SRv6 is not an overlay you want it
to become. *It is underlay.* I think this is biggest disconnect with this
and previous 6man discussions on that topic.

//RR.

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



--f403045f19c27871ff055f3b0ba5--


From nobody Thu Nov 30 15:08:52 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724DC12009C for ; Thu, 30 Nov 2017 15:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 dThglGUlGJb8 for ; Thu, 30 Nov 2017 15:08:49 -0800 (PST)
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 E44AB1294E1 for ; Thu, 30 Nov 2017 15:08:48 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id r184so11054887qke.8 for ; Thu, 30 Nov 2017 15:08:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F8T6QesgGAIBOl67gVRPxIxMMxpnVO1ivEDFr6IP3XM=; b=suuujgjJ4VupCnWCajVgZfZ1PHWYU3My5JRraioSSB/KmqSEQL3xm6pPLcAgEN6e6+ HdiOMmrCIbbexcPZ8qcst4lXvhNzM2QzAVQGIJzihSlASZZ88iVz9YGWhYRcv3mVRI0d SOYsp3/+bDya1vjj6tD+Ur/g24CiEOM0LmZBufSHajvwYydAYbMLijrOha0SJkfrtGER cT4jrJe7vWwbgdrWM/YsM/LdK2wUDp4SvPrbEQfbysTc3GMfxDV2Ydt9sNOoo+UJu45U DFgTWHzLWf+xR+Hz6Iud3pGB1mUtd/KEx0SQpNGp7eghSswedG5dRBWvJXE0VuH1IrIY x3fg==
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=F8T6QesgGAIBOl67gVRPxIxMMxpnVO1ivEDFr6IP3XM=; b=BY9mLOKfTadvUB8f/JPSJIaVw56oJCJ9Eg+c02HKbeALDygmGIPzm1z20KmYz2YI7V 7NMLLPCutIemkiAv8Tuy/HC9/Q1Ndvo4DJBhxzgLag0fdod+YhzS3kJoE63VXd8JSx32 BSp3usaHKsSq09dmXagxOdVI19PsxgrAXbZlOjQcBTfcDKQP/wYJAmhbYCOYHxrfUW7F es6/Z9fks/vfgZ9PC/TfqPgs51yNKaZobUTRxJ+Cwa/TIL2WSAVAN6dXEk8Qn5i+pIaS mRSzERlr9Lonx4KLhYhMdyl8z/V57/TUKBQZuvEToRGDpEZUQCuJs6bbK/PRW9D9fk5g ao3A==
X-Gm-Message-State: AKGB3mJTDEcw8T1yNRZwGpbHoAgWf2lqLPcWvV27BGWsE0dSXlcsbWsX SwwOKyumeAZisIHpQHJMqswwOR9CMD4wjMc0i2K8xw==
X-Google-Smtp-Source: AGs4zMaMkl8i256GKIIeKqzqieyuU0JZnP3ALmkp9jDSiYycrTd3sBqSudZNhQ03LML31ghzb7YoBhfHD1Tnh6lhha4=
X-Received: by 10.55.19.19 with SMTP id d19mr4728373qkh.189.1512083328036; Thu, 30 Nov 2017 15:08:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.43.121 with HTTP; Thu, 30 Nov 2017 15:08:47 -0800 (PST)
In-Reply-To: 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>        
From: Tom Herbert 
Date: Thu, 30 Nov 2017 15:08:47 -0800
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Robert Raszuk 
Cc: Fernando Gont ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 23:08:50 -0000

On Thu, Nov 30, 2017 at 2:48 PM, Robert Raszuk  wrote:
>
>>
>> A nice solution to the traceroute issue for encapsulation has already
>> proposed. See
>> https://tools.ietf.org/html/draft-nordmark-nvo3-transcending-traceroute-03.
>
>
> And where in the v6 header would you place a T-flag ?
>
It goes in an encapsulation header (GUE or VXLAN for instance). This
is also where bits can be put for OAM  instead of needing to overload
bits in the flow label that was previously proposed (another proposed
protocol exception that is justified by a "controlled environment"
constraint).

> The proposal above is about the overlay. SRv6 is not an overlay you want it
> to become. *It is underlay.* I think this is biggest disconnect with this
> and previous 6man discussions on that topic.

I don't think distinction of whether this is an overlay or underlay
relevant. What is relevant is whether the protocol is correct and
whether this justifies an exception to RFC8200 which explicitly states
that nodes in the path cannot insert extension headers.

In any case, there has been good feedback on this draft. I hope you
and the other authors will take all this into consideration for the
next draft version.

Tom


From nobody Thu Nov 30 16:15:24 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418C9126DC2; Thu, 30 Nov 2017 16:15:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20VpRl1u6JG7; Thu, 30 Nov 2017 16:15:21 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CD0124D68; Thu, 30 Nov 2017 16:15:21 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id j124so3854821pfc.2; Thu, 30 Nov 2017 16:15:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ILQ8JitEQRPWFcFpufqnHJWv7kmMwz1BHq2/151Y3KQ=; b=KjzqwP9uC4Sq6hDwVvqqLkj/FnXIsWVnREiJqc6MdzECAYrVsGIM+ub/ZmdGRClz7h Ny3QWpQ5Iwz920ZVr6nR7+6rCGBF0jx7cpNNVQ0HAWloEsKw4IWRF1zQWbVnHCAT7SlC 8r7iWMSKX4Qq4WyF2apJNpi26sfKiSl4z/8Itm6jHzKuruulOIqX3b8Nck0ueognFIh9 PoHxSY1q0UTd7BKQzoxwVhioGijdv192+1XNIQNHYsDCRc1HRhUtjsm61xlGjzWNdHrs gD1KELxLQL13lancSOHrMX7oqVQUoOzy8h1lxKqfQ8OO/0RWKsPnhck5C6y2ivdcjAui EODA==
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=ILQ8JitEQRPWFcFpufqnHJWv7kmMwz1BHq2/151Y3KQ=; b=Uff4jszCIsVdRuFl9A6qfNhfy9p73L2yclGmaTY7WklQP49TWdi0KOD94iICEAbDEu k4HOR68+OlOeKK/IfCXpKGRntgYkNTIheUnnbxgsVzkFvFsE81wfRr28eEYSqN9W42S3 5N2EDnU4pif0O3bMfE0Yoi1WGEBkbAfPFn4QkrLoTZZ/cl6Mn03HMck+P8uwGKbcQv6f Gsb0CWDKdD8AZHJw1FP4UYAkK6sQcdBIQgt2Teq6+eevN2nhuayMf3+tpNUHeKigKFg8 3/kC+Tz9V8iA1EZraTn3l8mr4O8eJb5193WKMhVvjT6wbeaOq0sg6wdpEApFJFwl/AEX rFHw==
X-Gm-Message-State: AJaThX6YX9VHKr4vDvqZv+oG8ddmDf4zFfNoWMRsWXSXWJjiuqO4cu/v 427rlBrigOZeVYhUKJ5RWK4yyQ==
X-Google-Smtp-Source: AGs4zMZEqA46BekSHPyvScukWlx2FgOOdNLsF3k9mZTLVx9/CqUWAwNAD35mOyXZXqmhVT8uSsMRfQ==
X-Received: by 10.98.224.7 with SMTP id f7mr8350786pfh.177.1512087320663; Thu, 30 Nov 2017 16:15:20 -0800 (PST)
Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 68sm8510269pfx.186.2017.11.30.16.15.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 16:15:19 -0800 (PST)
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Mark Smith , Robert Raszuk 
Cc: Fernando Gont , draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>   
From: Brian E Carpenter 
Organization: University of Auckland
Message-ID: 
Date: Fri, 1 Dec 2017 13:15:24 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.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: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Dec 2017 00:15:23 -0000

On 01/12/2017 10:27, Mark Smith wrote:
> On 1 Dec. 2017 6:35 am, "Robert Raszuk"  wrote:
> 
> Hi Fernando,
> 
> So in the case of encapsulation you normally put the node performing the
> encap as source address. That may impact how you handle this packet via
> number of services or even by src-dst routing correct ?
> 
> So while perhaps some may consider it "cleaner" I think both variants have
> their own use cases and should be supported.
> 
> 
> 
> The trouble is they're not explained at all.
> 
> All there is is an assertion that "operators want this", which is the
> logical fallacy of an appeal to authority.
> 
>  I'm an operator, and I don't want it. I think it'll be harder to
> troubleshoot than NAT over the Internet and NAT is bad enough.

What I'm seeing in this thread are rational arguments for and against
the proposal. I agree about the logical fallacy in the abstract of the
current draft, but that's fixable with a few seconds use of the cursor
and Delete key. I'd like to see the rational arguments in the next version
of the draft.

   Brian

> 
> 
> Thx,
> R.
> 
> On Thu, Nov 30, 2017 at 2:14 PM, Fernando Gont 
> wrote:
> 
>> On 11/30/2017 08:45 PM, Ole Troan wrote:
>>>>
>>>> IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
>>>> -- this is the standard, straightforward and most clean approach.
>>>
>>> The best example I've heard is when you don't have a natural tunnel
>> endpoint to encapsulate to.
>>
>> What's a natural tunnel-endpoint here? Aren't you expecting such
>> endpoint to exist, to remove the inserted EH, after all? (and listing it
>> in the RH)
>>
>> I seem to remember some folks arguing that the rationale for EH
>> insertion is that performance go to hell if they do proper encapsulation...
>>
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>
>>
>>
>>
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Thu Nov 30 17:03:12 2017
Return-Path: 
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F87126C83 for ; Thu, 30 Nov 2017 17:03:12 -0800 (PST)
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=herbertland-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 7WRmYOJEJVe5 for ; Thu, 30 Nov 2017 17:03:10 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 62BB1126B7F for ; Thu, 30 Nov 2017 17:03:10 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id j207so11296223qke.10 for ; Thu, 30 Nov 2017 17:03:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0vUhyauQAUFsXC844E90SHpZFLRTLyQhQNsjiqL9WjI=; b=M3JJZvsb9UCfHiJmouzyg0lGWRTRPxfE/NU8ClAzgsTBWOurDMttqn4cgQIcTbGWKy s0ARvxtmC1A/7OId2F25UZ8mFKFxlePu8pxrl5yGVZVIPw48e+p1zc/FXM5vWMDPch4u E9VaUH9vkpIQR1HgDHS1GCbUZbB1R4S0oOmqfPzlnhvjEqI0D4Q+rafYVZ8Cq73PyRu/ OsYh62nfcm5AJTWMwgZZG68SkXEHzOBud1etGdj9v0DfaQlduOyMCcGVuecpXg80QKP4 2FCd0PFUqaTBYSi/JSnKEx2Jzoa8EP9XfOYnbOadsxp5MV5vJ8z6c7VDuBRqUbsXUN1v 2gDA==
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=0vUhyauQAUFsXC844E90SHpZFLRTLyQhQNsjiqL9WjI=; b=q/0jT53LnWTNhwFDyZ3XzgvOkGKCzoef4cT7QRygzBWjzApjAi6g3GvLJz+kb8bCaQ JV9ceyxroM8XjVn/s2d9HSC8so7b/q3dBZvTrMGaloOqiHot8z2VY7IkhlVrQIE1BH5o 7608HAugP9biahdim5F1wCL+BNy8tySCRO2xdKvNc4yTzcbx8JeKCQcDw/oAZIRoewNu 95Df3gMkblifA/1bEAax5ErT5LtZf8e92EIRdOt5lqSwqf78Vahjh2phJ2145uTk3jLn 4gkxTv3wrF60+uhHIIkUkCSJjyo6F7XESb6G210dbWrMscPU0T+5jjVslVYX9gTb2HHo XEKw==
X-Gm-Message-State: AKGB3mIi+XwMKTb2Lvp5b/EanCaghGVOOq89mIxo+coLQHqT8W50mOsI Fg6nJb3RgNsz04jCehh2r92kpeKMVsxmK9l74S6v8A==
X-Google-Smtp-Source: AGs4zMYP6SVprVJtl1h10jiv0geiMpgEp9tBLfjWp8jAsrAeRkptWYPLRZRWNcmAehiDPHI5bNC8tiLU6n7s8RtC3+0=
X-Received: by 10.55.150.6 with SMTP id y6mr5882724qkd.182.1512090189341; Thu, 30 Nov 2017 17:03:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.43.121 with HTTP; Thu, 30 Nov 2017 17:03:08 -0800 (PST)
In-Reply-To: 
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com>  <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org>    
From: Tom Herbert 
Date: Thu, 30 Nov 2017 17:03:08 -0800
Message-ID: 
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Brian E Carpenter 
Cc: Mark Smith , Robert Raszuk ,  Fernando Gont ,  draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 01 Dec 2017 01:03:12 -0000

On Thu, Nov 30, 2017 at 4:15 PM, Brian E Carpenter
 wrote:
> On 01/12/2017 10:27, Mark Smith wrote:
>> On 1 Dec. 2017 6:35 am, "Robert Raszuk"  wrote:
>>
>> Hi Fernando,
>>
>> So in the case of encapsulation you normally put the node performing the
>> encap as source address. That may impact how you handle this packet via
>> number of services or even by src-dst routing correct ?
>>
>> So while perhaps some may consider it "cleaner" I think both variants have
>> their own use cases and should be supported.
>>
>>
>>
>> The trouble is they're not explained at all.
>>
>> All there is is an assertion that "operators want this", which is the
>> logical fallacy of an appeal to authority.
>>
>>  I'm an operator, and I don't want it. I think it'll be harder to
>> troubleshoot than NAT over the Internet and NAT is bad enough.
>
> What I'm seeing in this thread are rational arguments for and against
> the proposal. I agree about the logical fallacy in the abstract of the
> current draft, but that's fixable with a few seconds use of the cursor
> and Delete key. I'd like to see the rational arguments in the next version
> of the draft.
>
It's not just the abstact that promote the logical fallacy, it occurs
elsewhere in the draft. For instance:

"Obviously, this FRR service increases the size of the packet during
its journey within domain D.  This is well-known to operators.
Well-known mitigation techniques have been deployed for more than 15
years"

This seems like a pretty useless statement in a protocol
specification. Either the mitigations should be articulated here or
the applicable RFCs describing them should be referenced.

Tom

>    Brian
>
>>
>>
>> Thx,
>> R.
>>
>> On Thu, Nov 30, 2017 at 2:14 PM, Fernando Gont 
>> wrote:
>>
>>> On 11/30/2017 08:45 PM, Ole Troan wrote:
>>>>>
>>>>> IMO, #1 thing to be discussed is why normal encapsulation wouldn't work
>>>>> -- this is the standard, straightforward and most clean approach.
>>>>
>>>> The best example I've heard is when you don't have a natural tunnel
>>> endpoint to encapsulate to.
>>>
>>> What's a natural tunnel-endpoint here? Aren't you expecting such
>>> endpoint to exist, to remove the inserted EH, after all? (and listing it
>>> in the RH)
>>>
>>> I seem to remember some folks arguing that the rationale for EH
>>> insertion is that performance go to hell if they do proper encapsulation...
>>>
>>> --
>>> Fernando Gont
>>> SI6 Networks
>>> e-mail: fgont@si6networks.com
>>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>>>
>>>
>>>
>>>
>>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------