From nobody Wed Nov 1 00:09:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A4213F639 for ; Wed, 1 Nov 2017 00:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 LSfblT6u_Ujj for ; Wed, 1 Nov 2017 00:08:56 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87E913FE13 for ; Wed, 1 Nov 2017 00:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1509520134; x=1510124934; 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=5Lep8wy+qPVh896KZSPnV67sZ /OZuiuTRJ/zqF2HhN8=; b=DwW67R7l/9XqZ4v3WMy8UhuMBeKBbWUgiXbWiaZtB NrEAMGXq39qbMLQCzU6/b91mowo5i5p5pw4x6hBZEcLSxXKH3a8nl3YJXxGyk8DK c5utvvCV6FtTsNX0nGPgKAIqKgG2288qGEHXNrN1ZAz42Vpj5uLYm6a7PQZaHHMV /s= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=rV2oZ2nmAHa1M2GOXXpbp+6n9g6VZvdj9vVt9iH0ukRgqmDKx/fwLf2lE+1H PjHAWJ8TPaH2WtBlaz1MkwDx+W6Yl2C5KrO8+KFMUijzUAl3eY2GkOS6x aOF9r/qofZGfuO3pCFVYlS8gezY76MWNnIIolBwK9Oqa+JG/FxCbYg=; X-MDAV-Processed: mail.consulintel.es, Wed, 01 Nov 2017 08:08:54 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 01 Nov 2017 08:08:53 +0100 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005612204.msg for ; Wed, 01 Nov 2017 08:08: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:171101:md50005612204::IREC808LZIq2XLbI:00001Q++ X-Return-Path: prvs=1478feaab1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Wed, 01 Nov 2017 08:08:51 +0100 From: JORDI PALET MARTINEZ To: v6ops list Message-ID: Thread-Topic: [v6ops] Google Alert - IPv6 References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@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: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 07:09:00 -0000 Totally agree, however there is a subtle situation here, when we associate = this to the origin of the thread =E2=80=A6 CGN If an unlawful action has been done with that phone, the phone owner will b= e responsible in front of the law to identify the person who has go the pho= ne. Otherwise, the courts will judge you as the author of the unlawful acti= on. Same as if you are the owner of a car that has an accident and don=E2=80=99= t stop, unless you identify in and undoubtable way a third person driving t= he car, it will be your problem. So, and this is what I was trying to point to the EU article 29 working par= ty many years ago, even if you identify an IP address, it is almost impossi= ble to say this is personal data, you need to correlate that with many many= many other data, and even do, unless you have a live record of he/she bein= g in front of the keyboard at that specific time. However, the implications of CGN for the police is that, without a CGN, the= owner for the phone that done that unlawful act (in EU you need to provide= a legal ID to have a phone line) using that IP address, the identification= is =E2=80=9Cdirect=E2=80=9D, no further investigation is needed and is the= owner the responsible to identify a third party if that's the case. With C= GN, if the IP address is shared and there are no source ports records, the = investigation brings the police to a number of people, may be only 16, may = be hundreds, which is a big issue. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Fred Baker Responder a: Fecha: mi=C3=A9rcoles, 1 de noviembre de 2017, 2:59 Para: DY Kim CC: v6ops list , Tore Anderson , Dave O'Reilly= Asunto: Re: [v6ops] Google Alert - IPv6 I think that misses the point. If you identify yourself to the phone, i= t knows that you are holding it. You might then pass it to someone else, wh= o uses it. The phone doesn't know who is holding it, only that you unlocked= it. =20 But that's not the point. The point is that someone *else* observing yo= ur phone's traffic or location data makes the assumption that the phone is = with or being used by you. You didn't present your fingerprint to them; the= y are observing after the fact and making inferences. =20 Now, as an investigative tool, that makes sense - in a high percentage = of cases, the person using your phone is you. So they can use that as a wor= king assumption in the conduct of an investigation. But the working assumpt= ion doesn't prove anything, it only gives hints that have to be further ver= ified to turn into proof. =20 > On Nov 1, 2017, at 5:47 AM, DY Kim wrote: >=20 > When unlocking your smart phone, you might use the =E2=80=98finger to= uch=E2=80=99 identification, in which case the device use might identify th= e individual. >=20 > When a password or swipe pattern is used, the association might be we= aker since those could be stolen. >=20 > --- > DY >=20 >> On 1 Nov 2017, at 10:42, Mark Smith wrote: >>=20 >> There really needs to be something else that supports or proves use = of a device other than an assumption that an IP address is tightly coupled = to a device's owner, and therefore all actions associated with an IP addres= s are those of the device's owner. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Nov 1 00:32:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6B13FE42 for ; Wed, 1 Nov 2017 00:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uefAVQcqoSmR for ; Wed, 1 Nov 2017 00:32:36 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC17813FE40 for ; Wed, 1 Nov 2017 00:32:36 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C70323AF7F4; Wed, 1 Nov 2017 07:32:34 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id AB5F7160042; Wed, 1 Nov 2017 07:32:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 81BEE160064; Wed, 1 Nov 2017 07:32:34 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id C3WlNfwJXaaB; Wed, 1 Nov 2017 07:32:34 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 14960160042; Wed, 1 Nov 2017 07:32:34 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 653A48DDFD9C; Wed, 1 Nov 2017 18:32:31 +1100 (AEDT) To: jordi.palet@consulintel.es Cc: v6ops list From: Mark Andrews References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-reply-to: Your message of "Wed, 01 Nov 2017 08:08:51 +0100." Date: Wed, 01 Nov 2017 18:32:31 +1100 Message-Id: <20171101073231.653A48DDFD9C@rock.dv.isc.org> Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 07:32:38 -0000 In message , JORDI PALET M ARTINEZ writes: > Totally agree, however there is a subtle situation here, when we > associate this to the origin of the thread CGN > > If an unlawful action has been done with that phone, the phone owner will > be responsible in front of the law to identify the person who has go the > phone. Otherwise, the courts will judge you as the author of the unlawful > action. Please cite the relevent law. Phone are hacked all the time. Phones are shared all the time. There is only ever a strong correlation never absolute proof. For proof you need other data. > Same as if you are the owner of a car that has an accident and dont stop, > unless you identify in and undoubtable way a third person driving the > car, it will be your problem. Cars get stolen all the time and sometimes the first you know about is a knock on the door. The owner of the vehicle is just the first step in the investigation. Things like a speeding fine may get lumbered on you but failure to stop requires more that you are the owner of the vechicle to be proven. > So, and this is what I was trying to point to the EU article 29 working > party many years ago, even if you identify an IP address, it is almost > impossible to say this is personal data, you need to correlate that with > many many many other data, and even do, unless you have a live record of > he/she being in front of the keyboard at that specific time. > > However, the implications of CGN for the police is that, without a CGN, > the owner for the phone that done that unlawful act (in EU you need to > provide a legal ID to have a phone line) using that IP address, the > identification is direct, no further investigation is needed and is the > owner the responsible to identify a third party if that's the case. With > CGN, if the IP address is shared and there are no source ports records, > the investigation brings the police to a number of people, may be only > 16, may be hundreds, which is a big issue. Only if you are looking at single events. Multiple events will probably whittle the set down to a subscriber. That doesn't necessarially identify a individual. > Regards, > Jordi -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Nov 1 00:53:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADEC13F569 for ; Wed, 1 Nov 2017 00:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZGVM7uP1fYX for ; Wed, 1 Nov 2017 00:53:11 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C5E713F700 for ; Wed, 1 Nov 2017 00:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1509522789; x=1510127589; 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=oITVvgIxbTKHvu1S5txhxgmns u2p8jGIAbDsjAH6Smc=; b=jDaAUZQFJA7RECQg7BLxHzLFjvBZUleJuML1THykT ZULeFgz3sYNl+hWEVtbwiHYvLHV2PW9f4/qtilnrd5QKBNAsuRCMjS5JW3IVhIR+ 5UJgqgkOKpliTZvoL6oP7UWEWtjVx+Jj1yCcpyr0C7aRa8CrvJ+w4wvuUX6B4T24 LQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=P4WS3W2QKeZnmuv/QG4ELX9/LTCl8M0PX3A7pKAI//IoE9M0eM58zAoAqEt2 2ohI8jqgifvHX0/CMfeMwX9MJWCUJybGhQX4JohsXHMJs9MNovdKjH754 7ocf6KHwlc2AOh9gpBWgiZL7cktgJEX201ZkhP5lgam7XUzkLw9WGc=; X-MDAV-Processed: mail.consulintel.es, Wed, 01 Nov 2017 08:53:09 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 01 Nov 2017 08:53:08 +0100 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005612239.msg for ; Wed, 01 Nov 2017 08:53:07 +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:171101:md50005612239::/KFKupwFdD62MgRz:00002/+P X-Return-Path: prvs=1478feaab1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Wed, 01 Nov 2017 08:53:05 +0100 From: JORDI PALET MARTINEZ To: v6ops list Message-ID: <2013D3DA-0366-41F2-A0E8-07F5563C5D07@consulintel.es> Thread-Topic: [v6ops] Google Alert - IPv6 References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171101073231.653A48DDFD9C@rock.dv.isc.org> In-Reply-To: <20171101073231.653A48DDFD9C@rock.dv.isc.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 07:53:13 -0000 I=E2=80=99m not a lawyer, but I can tell this are the facts in EU, in gener= al. I=E2=80=99m sure you can google for that. If the phone has been hacked or the car stolen, your lawyer will need to pr= ove that it was the case. If you know who hacked your phone you lawyer need= to prove that, police may believe you and do the investigation by themselv= es but it they don=E2=80=99t find a way to prove that =E2=80=A6 it is your = problem, unless you have an irrefutable alibi. I=E2=80=99ve a case recently (and this happened many times in Spain). A com= pany car drove by one employee was exceeding speed limit in 10 Km/h (100 eu= ros fine). The fine comes to the company. Company has 10 days to identify t= he driver, and did that. The driver denies it. If you don=E2=80=99t have a = way to prove that he is lying, you now pay the fine, plus 600 additional eu= ros because the law assumes that you tried to cheat them. So, unless the dr= iver voluntarily recognizes it, or you have a record signed by the person t= aking the car, you=E2=80=99re lost (because you made the mistake to provide= the car to an employee, friend, thief, without actually having a record fo= r that). There are plenty of cases that a car is stolen to do something wrong, and u= nless you prove that you were at that time in another place, your lawyer ne= ed to defend you. Just consider if you were sleeping alone and the car was = stolen during the night, and the bad thing happened during the night, but y= ou only claim to the police for the stolen car in the next morning =E2=80= =A6 How you prove that actually was not you? Note that I fully agree. IP is not personal data (and I tried to argue abou= t that many times), but law says so in EU (not sure in other countries/regi= ons). Regards, Jordi =20 -----Mensaje original----- De: Mark Andrews Responder a: Fecha: mi=C3=A9rcoles, 1 de noviembre de 2017, 8:32 Para: CC: v6ops list Asunto: Re: [v6ops] Google Alert - IPv6 =20 In message , JORDI= PALET M ARTINEZ writes: > Totally agree, however there is a subtle situation here, when we > associate this to the origin of the thread CGN > > If an unlawful action has been done with that phone, the phone owner = will > be responsible in front of the law to identify the person who has go = the > phone. Otherwise, the courts will judge you as the author of the unla= wful > action. =20 Please cite the relevent law. Phone are hacked all the time. Phones are shared all the time. There is only ever a strong correlation never absolute proof. For proof you need other data. =20 > Same as if you are the owner of a car that has an accident and dont s= top, > unless you identify in and undoubtable way a third person driving the > car, it will be your problem. =20 Cars get stolen all the time and sometimes the first you know about is a knock on the door. The owner of the vehicle is just the first step in the investigation. Things like a speeding fine may get lumbered on you but failure to stop requires more that you are the owner of the vechicle to be proven. =20 > So, and this is what I was trying to point to the EU article 29 worki= ng > party many years ago, even if you identify an IP address, it is almos= t > impossible to say this is personal data, you need to correlate that w= ith > many many many other data, and even do, unless you have a live record= of > he/she being in front of the keyboard at that specific time. > > However, the implications of CGN for the police is that, without a CG= N, > the owner for the phone that done that unlawful act (in EU you need t= o > provide a legal ID to have a phone line) using that IP address, the > identification is direct, no further investigation is needed and is t= he > owner the responsible to identify a third party if that's the case. W= ith > CGN, if the IP address is shared and there are no source ports record= s, > the investigation brings the police to a number of people, may be onl= y > 16, may be hundreds, which is a big issue. =20 Only if you are looking at single events. Multiple events will probably whittle the set down to a subscriber. That doesn't necessarially identify a individual. =20 > Regards, > Jordi =20 =20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org =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 1 05:02:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D9B13F71B for ; Wed, 1 Nov 2017 05:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XydiBxyLozL5 for ; Wed, 1 Nov 2017 05:02:02 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD4F13F718 for ; Wed, 1 Nov 2017 05:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1509537720; x=1510142520; 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=/9QbOwCS2qccW2spDSB7kv162 GI2H7P3H/uIjUe2otw=; b=VRhniIMoPI3MRxR2tOAs1GFvM0B/eebua1VNDwan0 Sz9G67zHhOPugeUJS0umJ84MV67YtrltKGjUEE55e4wV/W6S2p3fZNsz5qqs0rq0 3TpRR0CjFxv+OQ5d7/wiTZJvdfTkpxLUISBuDygRzuAC1jYUxwwDxkcdoN3Rih2v QM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=DenS3Uuox5BlGdcD2vxL0eCpaE824PyYKdkDgHXzC51MYw5pHDQU9JegxWF8 5NcQEf4wLMlEHtSvIuV+pb22cD3zS3B4B2+JV1VeuLT5WVuj2i3/G3aGu J5GrJilbHkPEVqW9MB8D4qbRJaiV/PmTp1NOYLvEyFgrLIXcXHyQZw=; X-MDAV-Processed: mail.consulintel.es, Wed, 01 Nov 2017 13:02:00 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 01 Nov 2017 13:01:56 +0100 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005612482.msg for ; Wed, 01 Nov 2017 13:01:54 +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:171101:md50005612482::6Dv+9HuKBmwGISZ+:0000049F X-Return-Path: prvs=1478feaab1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Wed, 01 Nov 2017 13:01:53 +0100 From: JORDI PALET MARTINEZ To: "" Message-ID: Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-02.txt References: <150824269847.21561.8932178346065454678.idtracker@ietfa.amsl.com> <44FD0037-CAFC-401B-A9E4-A976CB2A35F7@consulintel.es> <389AFC32-C6D5-4075-8617-E88CDF86CB01@consulintel.es> <3E196E02-87F9-4140-BE9C-5B21F69EE7E1@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 12:02:07 -0000 When I was updating this document from v02 to v03, I was considering includ= ing the definition of IPv4-only. However, being the document a terminology about IPv6-only, I decided that i= ncluding IPv4-only doesn=E2=80=99t make too much sense and can be inferred = from the IPv6-only definition and the rest of terms in the document. In fact, if we agree to include it, I think it will be something like the s= ame as we have for IPv6-only, so: - IPv4-only network - IPv4-only WAN/access - IPv4-only LAN - IPv4-only host/router - Transitional IPv4 host/router Yes, I know, I can just define IPv6-only =E2=80=9C*=E2=80=9D (wildcard), an= d IPv4-only *, and make a 1 page ID. But not being more specific is the pro= blem I=E2=80=99m trying to resolve: the lack of clarity when we speak about= this. Thoughts? Regards, Jordi =20 -----Mensaje original----- De: George Michaelson Responder a: Fecha: mi=C3=A9rcoles, 18 de octubre de 2017, 0:24 Para: Fred Baker CC: JORDI PALET MARTINEZ , "" <= v6ops@ietf.org> Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-onl= y-02.txt Not that anyone doesn't understand this, but a 'network' could quite possibly "not support" IPv4 and still have IPv4 packets on it. So, you can expect to see ARP. you can expect to see DHCP requests. You can even see half-open TCP. =20 Diagnostically, the state of being 'IPv6 only' doesn't mean there is no IPv4 packet types on the wire. it just means they aren't being supported, carried forward, responded to by deliberate deployment choices. No router is being proffered, no DNS service is being proferred. =20 But if somebody turns up an IPv4 DHCP server, responds to ARP, and offers a default route, You are not necessarily blocking them. =20 An IPv4 *blocked* network would be one, which uses lower level (layer 2) switch or other methods to refuse to forward frames which carry IPv4 and associated (ARP) traffic. =20 Thats different. =20 -G =20 On Wed, Oct 18, 2017 at 4:06 AM, Fred Baker = wrote: > > >> On Oct 17, 2017, at 10:43 AM, JORDI PALET MARTINEZ wrote: >> >> - I think a short "Definition of IPv4-only" would be useful to in= clude. > > A little rumination in context. Hats off. > > To me, an IPv4-only thing is a thing that can only communicate using = IPv4. That would be true of an IPv4-only host, an IPv4-only LAN, or an IPv4= -only network. In each case, there is a question of perspective: if an ISP = only offers a subscriber IPv4 addresses or prefixes, then the subscriber is= IPv4-only from the ISP's perspective, even though it might be using someth= ing else internally or when communicating via some other connectivity. If w= e are speaking from the perspective of the host itself, it might mean that = it is perfectly capable of communicating using something else, but it has o= nly been provisioned with an IPv4 address, or it can communicate with peers= on its LAN using something else, but the router is IPv4-only, and so when = it communicates with devices beyond the router (or they try to communicate = with it), IPv4 is the only thing that works. > > So, suggested text: > > IPv4-only: only capable of or provisioned to communicate using IPv4. = The description is always from a perspective, whether the perspective of a = host or network seeking to communicate, or that of another host or network = describing a communication peer. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Nov 1 07:07:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E021B13FAAF for ; Wed, 1 Nov 2017 07:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vj4lP7H8G3vE for ; Wed, 1 Nov 2017 07:07:17 -0700 (PDT) Received: from atl4mhob04.registeredsite.com (atl4mhob04.registeredsite.com [209.17.115.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AD0113FAEF for ; Wed, 1 Nov 2017 07:07:16 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob04.registeredsite.com (8.14.4/8.14.4) with ESMTP id vA1E7A8R008490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 1 Nov 2017 10:07:10 -0400 Received: (qmail 16382 invoked by uid 0); 1 Nov 2017 14:07:10 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 1 Nov 2017 14:07:10 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Wed, 01 Nov 2017 10:07:04 -0400 From: Lee Howard To: "Dave O'Reilly" CC: Warren Kumari , "v6ops@ietf.org" , Tore Anderson Message-ID: Thread-Topic: [v6ops] Google Alert - IPv6 References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@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: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 14:07:19 -0000 On 10/29/17, 8:32 PM, "Dave O'Reilly" wrote: > >>=20 >>=20 >>> Can we regulate our way out of this problem? >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>=20 >> Probably not. Countries with the highest IPv6 deployment have had either >> no government influence, or little more than government talking with >> industry about their IPv6 deployment plans. Countries with IPv6 mandates >> on industry seem to have very low actual deployment. >>=20 > >I completely agree with you that there are too many regulatory models >around the world for a recommendation of regulatory solutions to this >problem to be likely to meet with much success. However, Belgium has the >highest IPv6 adoption rate on the planet according to >https://www.google.com/intl/en/ipv6/statistics.html#tab=3Dper-country-ipv6-a >doption&tab=3Dper-country-ipv6-adoption and I understand that the reason >for this is that the telecoms regulator in Belgium required that a >maximum of (I think it was) 16 people can be sharing a single IP address >on a CGNAT at any given time. I forget the exact figures but it was >definitely a regulatory intervention. My understanding, which is indirect, is that Belgian law enforcement and telecom regulators sat down with ISPs and said, =E2=80=9COur reading of EU law says CGN is illegal.=E2=80=9D And ISPs said, =E2=80=9CWe have to do CGN, or turn off th= e Internet, (or maybe increase Internet prices to buy IPv4 addresses).=E2=80=9D So the regulators agreed to forebear enforcement of the no-CGN law unless address sharing exceeded 16 users per address. I have been unable to find this agreement in writing, though. That might be intentional. So, yes, I suppose it is regulatory intervention, but it=E2=80=99s not new regulation, it=E2=80=99s a different inteprpretation than other EU member states have of EU law. And it=E2=80=99s not a regulation, it=E2=80=99s an unwritten understand= ing (or forebearance).=20 I would welcome correction if my understanding is inaccurate our outdated. > >>>=20 >>>=20 >>> However, the obvious question to ask is - are the Belgian authorities >>> catching any more criminals now that they have such a high adoption >>>rate >>> of IPv6? Has the problem of crime attribution due to CGNAT gone away >>>for >>> them, or does it actually require global adoption of IPv6? >>=20 >> The question is more like, =E2=80=9CAre Belgian authorities catching more >> criminals than other countries in proportion to their IPv6 deployment?=E2=80= =9D >> They=E2=80=99re probably not catching more bad guys than they were before CGN, >> they=E2=80=99re just trying not to lose ground. >> And the answer is probably not good, because although Belgium has great >> numbers on eyeballs, their IPv6 deployment on content sites is still >>weak >> (https://www.vyncke.org/ipv6status/detailed.php?country=3Dbe ). >>=20 >>=20 > >Exactly! So they can attribute domestic IPv6 activity to domestic IPv6 >addresses but the second IPv4 to IPv6 transition takes place they=E2=80=99re no >better off than anyone else. Do you mean IPv6 is no better than CGN for attribution, or do you mean IPv6 is no better than native IPv4? > >>>=20 >>> The role of the IETF in this >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> Right from the front page of the IETF website: "The mission of the IETF >>> is to make the Internet work better by producing high quality, relevant >>> technical documents that influence the way people design, use, and >>>manage >>> the Internet.=E2=80=9D >>>=20 >>> Large scale address sharing technologies present a challenge to the >>> management of the Internet so that seems to fit right within the remit >>>of >>> the IETF to me. Correct me if I=E2=80=99m wrong... >>=20 >> Not entirely, but this seems more operational to me, and might be better >> targeted as a recommendation for how to manage servers. >>=20 > >Well, the IETF has already published such recommendations (RFC6302). The >question is what, if anything, else the IETF can/should do. > >I wrote this document and I didn=E2=80=99t really know what to do with it, so I >published it as an internet draft and have been trying to collect input >on what/where the best places to progress the conversation are=E2=80=A6and here >we are. I do think it has been a good discussion. You might propose it as a talk at NANOG, RIPE, or whatever your local NOG is. Even better would be to get in front of web server operators, but I don=E2=80=99t know whether or where they meet. Lee > >daveor > > From nobody Wed Nov 1 08:09:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BF813F73C for ; Wed, 1 Nov 2017 08:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 C8J8iVQArlZA for ; Wed, 1 Nov 2017 08:09:44 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 AFE331386A2 for ; Wed, 1 Nov 2017 08:09:43 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id f8so3027255qta.5 for ; Wed, 01 Nov 2017 08:09:43 -0700 (PDT) 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=yhtXl4WAQ2Tfqj2/wV5SxSrKu5gaVWZ0v8YGkRSqIao=; b=GpF1BaL+pYw8Toxx1dxFLLzqbtVKmLU695eOFYRI7nPFSUn9cHyGZaLdnJTdVSqAqJ XcDO6+8pN3lZAdxYjq4Cs2KWbAVO03kAs2z94UqyRxAwfNY0vpUkGXOqrzp5MHW1EC3P RvgR9Z1dWlo1FTecqOOnHtP8+YvC9B97o436A/HayXhXtPN9eKWID8s9WhgOqd+Xi5Hu nbMRUo7mTxZNTQ2+YZvhq0/KjqHehdI0IyFo7/rI2uojqHoMcYsA0Z8xK2ZG0YJqOq0G q0iU8UXOPiVIVLDrMR1pn9iV79nZrJbSM4fa8T3vp+f40LCQLipXfAwrWituH28du8TY L5wQ== 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=yhtXl4WAQ2Tfqj2/wV5SxSrKu5gaVWZ0v8YGkRSqIao=; b=d+nEFzsqAN5MwRDFldPUsDtTCAlVoax0if7l73sjFS0ojwZQVSmvmcmV/v2q+d5yJ/ x0cZwGYd07ryvMXaX1DcoqHTUWDtCuK+1K9Kp+KR+ydBrXu5u2YWjXzpRWzVEPickKp6 fEqHbWaTyh2D08+yVNyaa4Ucpw8UCqvMoO3sC2NIMYU4GFKJLIsyUJE91gxT/exSkfMb nYyYi0hUf18KZOxgULfnxQABLW8DtJMyzxHQ2o0WRC4U9t/HpvtbRu0tSq7kLY2R8SZT rA77kmabVrX2ikHvuVPbiOOVQ2AN7+W5NOl5KtumWjMya38WYcrB2hf+bK8jSFy0N75p zYNQ== X-Gm-Message-State: AMCzsaWf//BJDdcVanOjyINbEHAp9npWt6mtVz7Uc7WwzY7UluTd9Ys8 k45nbzdfDQHLJBjEkCNvL9u9Dj7kIqosGsKtuyVlWg== X-Google-Smtp-Source: ABhQp+S9oz37bzx7K5m+rifceJn+vjF+WmIqcFeB18zxOGxrwVhK8KsqpQxvg9N57dxqYfU70rmUj8ed/FE/glkuuh0= X-Received: by 10.200.53.89 with SMTP id z25mr325544qtb.58.1509548982686; Wed, 01 Nov 2017 08:09:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Wed, 1 Nov 2017 08:09:41 -0700 (PDT) In-Reply-To: <2013D3DA-0366-41F2-A0E8-07F5563C5D07@consulintel.es> References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171101073231.653A48DDFD9C@rock.dv.isc.org> <2013D3DA-0366-41F2-A0E8-07F5563C5D07@consulintel.es> From: Tom Herbert Date: Wed, 1 Nov 2017 08:09:41 -0700 Message-ID: To: Jordi Palet Martinez Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 15:09:46 -0000 On Wed, Nov 1, 2017 at 12:53 AM, JORDI PALET MARTINEZ wrote: > I=E2=80=99m not a lawyer, but I can tell this are the facts in EU, in gen= eral. I=E2=80=99m sure you can google for that. > > If the phone has been hacked or the car stolen, your lawyer will need to = prove that it was the case. If you know who hacked your phone you lawyer ne= ed to prove that, police may believe you and do the investigation by themse= lves but it they don=E2=80=99t find a way to prove that =E2=80=A6 it is you= r problem, unless you have an irrefutable alibi. > > I=E2=80=99ve a case recently (and this happened many times in Spain). A c= ompany car drove by one employee was exceeding speed limit in 10 Km/h (100 = euros fine). The fine comes to the company. Company has 10 days to identify= the driver, and did that. The driver denies it. If you don=E2=80=99t have = a way to prove that he is lying, you now pay the fine, plus 600 additional = euros because the law assumes that you tried to cheat them. So, unless the = driver voluntarily recognizes it, or you have a record signed by the person= taking the car, you=E2=80=99re lost (because you made the mistake to provi= de the car to an employee, friend, thief, without actually having a record = for that). > Jordi, In California there was a proposal to equip garbage tracks with cameras that would capture license plates and send them to law enforcement for tracking. The ostensible rationale was to only track criminals and that the information wouldn't be used to track otherwise law abiding citizens. This plan, not unexpectedly, cause a huge backlash because of privacy concerns. License plates are associated with vehicles which are associated with owners. Tracking license plates of personal vehicles is equivalent to tracking the whereabouts of the owner or at least someone in their family or friends. In the US at least, there's not a lot of trust in the government that it wouldn't use such information for widespread surveillance of citizens. > There are plenty of cases that a car is stolen to do something wrong, and= unless you prove that you were at that time in another place, your lawyer = need to defend you. Just consider if you were sleeping alone and the car wa= s stolen during the night, and the bad thing happened during the night, but= you only claim to the police for the stolen car in the next morning =E2=80= =A6 How you prove that actually was not you? > > Note that I fully agree. IP is not personal data (and I tried to argue ab= out that many times), but law says so in EU (not sure in other countries/re= gions). > I think this may contradict your example above. If a crime is committed and the IP address traces back to my device then it's clear that I'm going to be investigated at least as a person of interest if not a suspect. So I personally have been identified by authorities via IP address and it's now up to me to prove I didn't do anything wrong. In this case, the IP address is personally identifiable information because it was used to identify an individual. Again, it is not within the definition of an IP address that it doesn't identify individuals. Whether it does or not determined by how they are used and assigned. Tom > Regards, > Jordi > > > -----Mensaje original----- > De: Mark Andrews > Responder a: > Fecha: mi=C3=A9rcoles, 1 de noviembre de 2017, 8:32 > Para: > CC: v6ops list > Asunto: Re: [v6ops] Google Alert - IPv6 > > > In message , JOR= DI PALET M > ARTINEZ writes: > > Totally agree, however there is a subtle situation here, when we > > associate this to the origin of the thread CGN > > > > If an unlawful action has been done with that phone, the phone owne= r will > > be responsible in front of the law to identify the person who has g= o the > > phone. Otherwise, the courts will judge you as the author of the un= lawful > > action. > > Please cite the relevent law. Phone are hacked all the time. Phones > are shared all the time. There is only ever a strong correlation > never absolute proof. For proof you need other data. > > > Same as if you are the owner of a car that has an accident and dont= stop, > > unless you identify in and undoubtable way a third person driving t= he > > car, it will be your problem. > > Cars get stolen all the time and sometimes the first you know about > is a knock on the door. The owner of the vehicle is just the first > step in the investigation. Things like a speeding fine may get > lumbered on you but failure to stop requires more that you are the > owner of the vechicle to be proven. > > > So, and this is what I was trying to point to the EU article 29 wor= king > > party many years ago, even if you identify an IP address, it is alm= ost > > impossible to say this is personal data, you need to correlate that= with > > many many many other data, and even do, unless you have a live reco= rd of > > he/she being in front of the keyboard at that specific time. > > > > However, the implications of CGN for the police is that, without a = CGN, > > the owner for the phone that done that unlawful act (in EU you need= to > > provide a legal ID to have a phone line) using that IP address, the > > identification is direct, no further investigation is needed and is= the > > owner the responsible to identify a third party if that's the case.= With > > CGN, if the IP address is shared and there are no source ports reco= rds, > > the investigation brings the police to a number of people, may be o= nly > > 16, may be hundreds, which is a big issue. > > Only if you are looking at single events. Multiple events will > probably whittle the set down to a subscriber. That doesn't > necessarially identify a individual. > > > Regards, > > Jordi > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Nov 1 10:17:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BA013F95D for ; Wed, 1 Nov 2017 10:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgAh1XDRcrp4 for ; Wed, 1 Nov 2017 10:17:05 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948E713F96B for ; Wed, 1 Nov 2017 10:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1509556621; x=1510161421; 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=UW+aA3kP5dZvqBWgU1csZbPME AvW+LqoKZEK9b6qe/E=; b=Cpea/exmc5JNVYRakBQTZ4oLisH4oPz7dgni0LOMe h10d/iHlfHCU6WKoOvAo26wpowHuhTLZmD5OVYPaAmGLsNgaY6hmC2iv7H7PU7IZ d3UfKSz2AIaFVqzTm8EzGLMxr0K55fvBEipcDZGDxRgUjzAaml3D54sS0ZwVEcCg ng= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=TYWhaHDndO2s+dhHQ36Nyz9sXJ9j6+j9O3qRZXWiSr/XcGN2U4pZs1YRZvhm Z9bmpaxgaQrqw1xfhuuq6c6EvW1MC5CqAVUFJRWZliNi7EQrrQ5D3uDe5 e0OjpmDhnxvH2CggLBXoiTrTEKqQQmew9MU6LECPvbmCgBjg591mjo=; X-MDAV-Processed: mail.consulintel.es, Wed, 01 Nov 2017 18:17:01 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 01 Nov 2017 18:17:00 +0100 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005612783.msg for ; Wed, 01 Nov 2017 18:17:00 +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:171101:md50005612783::8FRPnkrBEcvBat91:00004XxA X-Return-Path: prvs=1478feaab1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Wed, 01 Nov 2017 18:16:56 +0100 From: JORDI PALET MARTINEZ To: v6ops list Message-ID: Thread-Topic: [v6ops] Google Alert - IPv6 References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171101073231.653A48DDFD9C@rock.dv.isc.org> <2013D3DA-0366-41F2-A0E8-07F5563C5D07@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 17:17:08 -0000 Hi Tom, Not sure to understand what is a garbage track =E2=80=A6 Anyway, yes, laws = unfortunately differ and sometimes too much from country to country. What I= said apply to Spain, and I believe to most of the EU countries. I wrote it wrong, let me rephrase it: =E2=80=9CI fully agree that consideri= ng an IP as personal data is broken=E2=80=9D. Regards, Jordi =20 -----Mensaje original----- De: Tom Herbert Responder a: Fecha: mi=C3=A9rcoles, 1 de noviembre de 2017, 16:09 Para: Jordi Palet Martinez CC: v6ops list Asunto: Re: [v6ops] Google Alert - IPv6 On Wed, Nov 1, 2017 at 12:53 AM, JORDI PALET MARTINEZ wrote: > I=E2=80=99m not a lawyer, but I can tell this are the facts in EU, in= general. I=E2=80=99m sure you can google for that. > > If the phone has been hacked or the car stolen, your lawyer will need= to prove that it was the case. If you know who hacked your phone you lawye= r need to prove that, police may believe you and do the investigation by th= emselves but it they don=E2=80=99t find a way to prove that =E2=80=A6 it is= your problem, unless you have an irrefutable alibi. > > I=E2=80=99ve a case recently (and this happened many times in Spain).= A company car drove by one employee was exceeding speed limit in 10 Km/h (= 100 euros fine). The fine comes to the company. Company has 10 days to iden= tify the driver, and did that. The driver denies it. If you don=E2=80=99t h= ave a way to prove that he is lying, you now pay the fine, plus 600 additio= nal euros because the law assumes that you tried to cheat them. So, unless = the driver voluntarily recognizes it, or you have a record signed by the pe= rson taking the car, you=E2=80=99re lost (because you made the mistake to p= rovide the car to an employee, friend, thief, without actually having a rec= ord for that). > Jordi, =20 In California there was a proposal to equip garbage tracks with cameras that would capture license plates and send them to law enforcement for tracking. The ostensible rationale was to only track criminals and that the information wouldn't be used to track otherwise law abiding citizens. This plan, not unexpectedly, cause a huge backlash because of privacy concerns. License plates are associated with vehicles which are associated with owners. Tracking license plates of personal vehicles is equivalent to tracking the whereabouts of the owner or at least someone in their family or friends. In the US at least, there's not a lot of trust in the government that it wouldn't use such information for widespread surveillance of citizens. =20 > There are plenty of cases that a car is stolen to do something wrong,= and unless you prove that you were at that time in another place, your law= yer need to defend you. Just consider if you were sleeping alone and the ca= r was stolen during the night, and the bad thing happened during the night,= but you only claim to the police for the stolen car in the next morning = =E2=80=A6 How you prove that actually was not you? > > Note that I fully agree. IP is not personal data (and I tried to argu= e about that many times), but law says so in EU (not sure in other countrie= s/regions). > I think this may contradict your example above. If a crime is committed and the IP address traces back to my device then it's clear that I'm going to be investigated at least as a person of interest if not a suspect. So I personally have been identified by authorities via IP address and it's now up to me to prove I didn't do anything wrong. In this case, the IP address is personally identifiable information because it was used to identify an individual. =20 Again, it is not within the definition of an IP address that it doesn't identify individuals. Whether it does or not determined by how they are used and assigned. =20 Tom =20 > Regards, > Jordi > > > -----Mensaje original----- > De: Mark Andrews > Responder a: > Fecha: mi=C3=A9rcoles, 1 de noviembre de 2017, 8:32 > Para: > CC: v6ops list > Asunto: Re: [v6ops] Google Alert - IPv6 > > > In message ,= JORDI PALET M > ARTINEZ writes: > > Totally agree, however there is a subtle situation here, when w= e > > associate this to the origin of the thread CGN > > > > If an unlawful action has been done with that phone, the phone = owner will > > be responsible in front of the law to identify the person who h= as go the > > phone. Otherwise, the courts will judge you as the author of th= e unlawful > > action. > > Please cite the relevent law. Phone are hacked all the time. Ph= ones > are shared all the time. There is only ever a strong correlation > never absolute proof. For proof you need other data. > > > Same as if you are the owner of a car that has an accident and = dont stop, > > unless you identify in and undoubtable way a third person drivi= ng the > > car, it will be your problem. > > Cars get stolen all the time and sometimes the first you know abo= ut > is a knock on the door. The owner of the vehicle is just the fir= st > step in the investigation. Things like a speeding fine may get > lumbered on you but failure to stop requires more that you are th= e > owner of the vechicle to be proven. > > > So, and this is what I was trying to point to the EU article 29= working > > party many years ago, even if you identify an IP address, it is= almost > > impossible to say this is personal data, you need to correlate = that with > > many many many other data, and even do, unless you have a live = record of > > he/she being in front of the keyboard at that specific time. > > > > However, the implications of CGN for the police is that, withou= t a CGN, > > the owner for the phone that done that unlawful act (in EU you = need to > > provide a legal ID to have a phone line) using that IP address,= the > > identification is direct, no further investigation is needed an= d is the > > owner the responsible to identify a third party if that's the c= ase. With > > CGN, if the IP address is shared and there are no source ports = records, > > the investigation brings the police to a number of people, may = be only > > 16, may be hundreds, which is a big issue. > > Only if you are looking at single events. Multiple events will > probably whittle the set down to a subscriber. That doesn't > necessarially identify a individual. > > > Regards, > > Jordi > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 1 11:11:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F25313F9E9 for ; Wed, 1 Nov 2017 11:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=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 FjRRY0_9dyQr for ; Wed, 1 Nov 2017 11:11:28 -0700 (PDT) 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 D664013F9B8 for ; Wed, 1 Nov 2017 11:11:27 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id q83so3765413qke.6 for ; Wed, 01 Nov 2017 11:11:27 -0700 (PDT) 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=0gK+rPYdMtdRosSbLMNYMBy19uSACmJB3+fHTIwWQPo=; b=JkKwg1JoZancgn/2OUBBM0s/3trBwrfVuyVRwUNNLfTh7CZKZH3wiIZ3DFFky6DqMa wIk/BjzQ0KWkrJNGafSz07C/QdN/97h8GHKyAt1msyHJiG6Hd+5/YIIOdIGy4WoslLu/ /EqlXHge4XW9z2RflDJUkUWwQJqYIF+wSlivsvsZ74XT69NnhBR17ntL40aM9QfEjH8Y DizB5JHdWHouLc9mXUklMfHijOKWLQCzQe99ub+/NmBibAfW3FrHzAH+LQ1zA3zmePm1 z0ixo4x4SERi9+NgGfC3SJ/ctCmoR087MggoJwlLe5FL6KsQd/BQBSCiOTS26k+pOhKa dtDw== 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=0gK+rPYdMtdRosSbLMNYMBy19uSACmJB3+fHTIwWQPo=; b=FAZIyckPJMgiKAKp16SQe8Sl8R6/rmSPQrCC/vCKnkExkFiYfujWoQJc8S0B6QzyCs v07D2fK1N7FjGOJeEuxx9GfJTvmtMWKdd/2z/2u+YOMO5c3ypVIC5h5iRc2u/ZEBQT8K OI0SWNWh1/ByKguwEODXglzGo3ZF7tFBIX+0xYEYw6v43PN9BFq/uLc9YHp+JtcwJLzp rhgWSKZKTLHjmtID1CNKDf7fACDFyWS7A0tPbi3ihZ4wvHFYhec3gRIYyy+h+ph3+crq 6pLKp9cBknZatFLXN+yKTn0PMvHoOTF+rmK3mAEbnf6vLpPOt5FtSefTnYR+x3Zrt0gv TfkQ== X-Gm-Message-State: AJaThX5Qpvzk1ZthRj0crWc0A/9u4gwj7NrDWVcuU8Q+FXnnbxOru5TT w7A8o5bzHAoZRQGkxC7H8jqWNI+5ZvcozR8cg235Vw== X-Google-Smtp-Source: ABhQp+SjmU8E6OVgB8UK+wdk+zVdZJhu5f81Ckuyjda0A3g1+P2EGkvNiVbuogSX+dBY7bXtOA4uoSJ8Jwrh/O4pOkU= X-Received: by 10.55.132.133 with SMTP id g127mr1188238qkd.72.1509559886955; Wed, 01 Nov 2017 11:11:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Wed, 1 Nov 2017 11:11:26 -0700 (PDT) In-Reply-To: References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171101073231.653A48DDFD9C@rock.dv.isc.org> <2013D3DA-0366-41F2-A0E8-07F5563C5D07@consulintel.es> From: Tom Herbert Date: Wed, 1 Nov 2017 11:11:26 -0700 Message-ID: To: Jordi Palet Martinez Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 18:11:29 -0000 On Wed, Nov 1, 2017 at 10:16 AM, JORDI PALET MARTINEZ wrote: > Hi Tom, > > Not sure to understand what is a garbage track =E2=80=A6 Anyway, yes, law= s unfortunately differ and sometimes too much from country to country. What= I said apply to Spain, and I believe to most of the EU countries. Jordi, I meant "garbage truck". > > I wrote it wrong, let me rephrase it: =E2=80=9CI fully agree that conside= ring an IP as personal data is broken=E2=80=9D. > Brokenness is relative. It seems that for LEA gleaning identity from an IP address is a good thing. For someone very concerned about their privacy, an IP address containing PII is a bad thing. I believe IETF tries to be agnostic in such matters. Protocols and mechanisms can be built with strong security and privacy without purposely building in trap doors for regulatory authorities to exploit. But, neither does IETF do much to prevent individual countries to regulate communications within their jurisdiction. Tom From nobody Wed Nov 1 11:21:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A19213FA18 for ; Wed, 1 Nov 2017 11:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 aBdVxMCrLdF3 for ; Wed, 1 Nov 2017 11:21:16 -0700 (PDT) Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A113413FA1A for ; Wed, 1 Nov 2017 11:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1509560473; x=1510165273; 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=3Perrh5xmyXy74RJVxeAxdT64 2HieuUkxuTcfXbT15g=; b=VIwvwZ71DAhmqt6bDy5025aObEngTaaXW1QZSyzE7 Z3w8GOmcR7DEBHHIYI7PAIyP1FwTm848PUEoZLoY/4kE/iiawdqN/xDIQXbDK8oB O9zHZo6GUhs7A2DBw3Ai07O0q3i6xTGxC8/HrDUCeL2SE76lSrjp0QkI/m7beY7M 28= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=dsHp0lLjgW9xpAxnmk69vP4ou3yjM6CJe2il+1vnU3CrTi8c8ZPxwVrzgtIb 8bo5JzwXleyEDHBMvqO9+yYBlXlbq/1xhM3ed2yhT8JM1yf0HeDAwjCx1 Nr1PxOMvlHptJ/sse2pcS0hUtKDXPYeU0RfW/0L65brlmj32L/nT+I=; X-MDAV-Processed: mail.consulintel.es, Wed, 01 Nov 2017 19:21:13 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 01 Nov 2017 19:21:12 +0100 Received: from [10.10.10.134] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005612861.msg for ; Wed, 01 Nov 2017 19:21:11 +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:171101:md50005612861::y4z690qeqlRQKtXO:00001OhB X-Return-Path: prvs=1478feaab1=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Wed, 01 Nov 2017 19:21:07 +0100 From: JORDI PALET MARTINEZ To: v6ops list Message-ID: <4F8571B9-FCF3-4E6D-87AE-2AA5D37F917E@consulintel.es> Thread-Topic: [v6ops] Google Alert - IPv6 References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171101073231.653A48DDFD9C@rock.dv.isc.org> <2013D3DA-0366-41F2-A0E8-07F5563C5D07@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 18:21:17 -0000 Broken (in my opinion) in the sense of the EU privacy considerations. They consider IP addresses as personal data, which is not. And this conside= ration has many implications and extra cost for operators, etc., as it impl= ies further security measures to keep that data =E2=80=9Csafe=E2=80=9D. For LEA, IP addresses being personal data or not, has no difference, in the= sense that rules that mandate the storage to be able to track criminals ar= en=E2=80=99t different one way or the other. Saludos, Jordi =20 -----Mensaje original----- De: Tom Herbert Responder a: Fecha: mi=C3=A9rcoles, 1 de noviembre de 2017, 19:11 Para: Jordi Palet Martinez CC: v6ops list Asunto: Re: [v6ops] Google Alert - IPv6 On Wed, Nov 1, 2017 at 10:16 AM, JORDI PALET MARTINEZ wrote: > Hi Tom, > > Not sure to understand what is a garbage track =E2=80=A6 Anyway, yes,= laws unfortunately differ and sometimes too much from country to country. = What I said apply to Spain, and I believe to most of the EU countries. =20 Jordi, =20 I meant "garbage truck". =20 > > I wrote it wrong, let me rephrase it: =E2=80=9CI fully agree that con= sidering an IP as personal data is broken=E2=80=9D. > Brokenness is relative. It seems that for LEA gleaning identity from an IP address is a good thing. For someone very concerned about their privacy, an IP address containing PII is a bad thing. I believe IETF tries to be agnostic in such matters. Protocols and mechanisms can be built with strong security and privacy without purposely building in trap doors for regulatory authorities to exploit. But, neither does IETF do much to prevent individual countries to regulate communications within their jurisdiction. =20 Tom =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 1 11:46:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04CD13FD06 for ; Wed, 1 Nov 2017 11:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 svUMht_5LRkL for ; Wed, 1 Nov 2017 11:46:55 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 C078013FD05 for ; Wed, 1 Nov 2017 11:46:54 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id z19so3863156qtg.11 for ; Wed, 01 Nov 2017 11:46:54 -0700 (PDT) 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=XLSuprw+dgP2pG71k8MQlIDlsIx0/m3FOH9Geqk5/i8=; b=bdb3BiLjppve0/8ogF9dCX32MzLX/FBxTBhLMkgcPkxC5ORXK62K3TGD017Gq3nOVb 3QiOvKpfwdC9CVXfjpAINCdWx9iW/IFSFrIHxErU9nNKnxuuD/rUeLjQUK6NSZJhVhRl Sn/JLpC89KRbBiqfZL36/Rn/ptKE7NAjcZ0JiYl8QCnQwCOh9Ec9CEIVyoU8/KZDjRJL C1Ki0aVNTGuj2Zz1xdzhnrL/In8AMjSmBAFY9C8eWe5GQWLmQRUxVfRRzQYdoKoYoT7p PxQnQn9k/uD9XtDntfwWGJuE4MJOWZxJu98u9yzYikq8FKMguDJuAN70lIp0IV8aS3VL w4JA== 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=XLSuprw+dgP2pG71k8MQlIDlsIx0/m3FOH9Geqk5/i8=; b=NvuKsL8Q/qySCyckPTvA7KMBxyadW2xO9Qpd7mkGqVC/aN2rGUgnNWtWp5qHzwpqnC xBN06GTcPCZUN14ao4lrjOCjux/E5N4sauPiLWdwQQtHj1HGSOm5gmVSMJ66CVdszesE UAUQ4NUHtM0PkD+b/KD9xfVnWK5VXPjmrjjcitbLHdA8nSzt9SAyPUzYs7+AXZerDlDO +wjMjKDo8ETqTYwAkqOCsgn96SkNdCzr2trbsJL1MU4QDKklBped9sHnJrsn9fqd65Y1 xDRsSd4gYGuFDxV7cH0j0JNAiMdyiRxcIACdjinhJxdrab1af/Y9Hha+VZae0RTydSK6 dJrg== X-Gm-Message-State: AMCzsaW1Qg631/g1Vu9bX9QrdKV1Bpl+p2ZYcnUCj+lVqdsKq2rShiYM b/U5xbbRbtm2YTWQFzF+1ODz+1pMjaYa/Bcnjdh9TQ== X-Google-Smtp-Source: ABhQp+SQo4Y/svMWdFwu/JzQ4BfmtptwdiW/oMYLZrBtdsDJt5agJb1zGZwPIK2m9xwx2vMiIiEtAb/HS3j5RdMKp0c= X-Received: by 10.237.35.58 with SMTP id h55mr1363154qtc.108.1509562013858; Wed, 01 Nov 2017 11:46:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Wed, 1 Nov 2017 11:46:52 -0700 (PDT) In-Reply-To: <4F8571B9-FCF3-4E6D-87AE-2AA5D37F917E@consulintel.es> References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171101073231.653A48DDFD9C@rock.dv.isc.org> <2013D3DA-0366-41F2-A0E8-07F5563C5D07@consulintel.es> <4F8571B9-FCF3-4E6D-87AE-2AA5D37F917E@consulintel.es> From: Tom Herbert Date: Wed, 1 Nov 2017 11:46:52 -0700 Message-ID: To: Jordi Palet Martinez Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 18:46:57 -0000 On Wed, Nov 1, 2017 at 11:21 AM, JORDI PALET MARTINEZ wrote: > Broken (in my opinion) in the sense of the EU privacy considerations. > > They consider IP addresses as personal data, which is not. And this consi= deration has many implications and extra cost for operators, etc., as it im= plies further security measures to keep that data =E2=80=9Csafe=E2=80=9D. > Jordi, That might be an issue to take up with EU then. AFAICT an effort illegalize CGNAT or limit the number of users behind a NAT address is an attempt to put PII into IP addresses for law enforcement purposes. This is policy, there's nothing inherent in IP protocol or addressing architecture that prevents that. The article that Mark posted (https://telsoc.org/ajtde/2015-04-v3-n1/a4) might demonstrate that implementing such a policy is futile to achieving its underlying goals. Tom From nobody Wed Nov 1 13:36:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4013B13FEB8 for ; Wed, 1 Nov 2017 13:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, 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 1MiIF8MiPIhR for ; Wed, 1 Nov 2017 13:35:59 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 CDC4D13F7EE for ; Wed, 1 Nov 2017 13:35:58 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id g69so2234686vke.5 for ; Wed, 01 Nov 2017 13:35:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NsP9V7Gar9aqqzP/WGDa3JtQNNDIaZ0fvzKuErJ/BgA=; b=CbdnREye1id7ASnKd2begzkFjdYAtv5IYhbJ13YoPwDG1rd7T8fd20MXnA+jyj5Pe8 HZe/0fnvT9VmEz1clX0Fbrq187YgCFlSGkePSPifAbxlTZadwsi8+GxXtUHnADvX1uL5 BRs4w3bQM74q6tzmXjci2+QwYT60bAVq+ohOj6Ap74oYctYp2xIAMd/kIu/v+KKF7jKm Ezq4KcK3877S0ZHa2qOX7wQUA/P8HXIS4IKv4fhKll+DdQorkfJLycD5hY+l4+/8Uwop vP7QNZOSCOPRVuPVI4LgDws73xO5TSNW6oOo9S0XVOu9dEWSBNY2NEvg82SUaYrnpwG/ qNtQ== 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=NsP9V7Gar9aqqzP/WGDa3JtQNNDIaZ0fvzKuErJ/BgA=; b=j064wDEjGIih1CM9+ugBFLJbFLJ7pbgEiAJnbSkIhCBWC6b2V3Dr+vdyHGmZ6ekvhH wcSgj6EmReAuaQfk1cpf0KO4ubRSawAVO/caRatwWc80pXnx1DPnwWkz5JirhpyIA32v 7zsfzN7rey4+1V6hN9yjRXLelO33dvHXjsRlBmTAgmNzmM8Wng4i+77xTf4FhqWdY/PO 10X4IDbcd/w62xgzqwqtoEvZWQ86i+fg/DPvb2nVvJg0fv8mbQTld2jZ5Lu7fV9JipNy SzCy6hBPyKv+6sE90kWYH89nMPbCxhdAlPWXLzKLe9aSX0bweiUWUztZhqgby1mdBNx2 6mKw== X-Gm-Message-State: AMCzsaVSn7nZENJmGfgSZ7oulEMnc5ZeWO5v71FOYA9oT28Ll+5N2b0S Tf6RmhclDUVdFJyXyAhQX0WBOAdPHMxcAl2bEYQ= X-Google-Smtp-Source: ABhQp+QeEh+bPSZVwOHSGinNy56Q/RRs4NtCNWVbualEDk09CnUo9h0jz6VKfjIFhKRrzTwn4wqg+D8y6k9Sl8LRuBE= X-Received: by 10.31.115.14 with SMTP id o14mr853527vkc.79.1509568557706; Wed, 01 Nov 2017 13:35:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Wed, 1 Nov 2017 13:35:27 -0700 (PDT) In-Reply-To: <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> References: <150860492012.3131.14623048904955800548.idtracker@ietfa.amsl.com> <0EAB4149-AFE9-4770-8242-6D8E05889091@consulintel.es> <66E223E7-73B5-49BA-AA40-5AA632F3F755@consulintel.es> <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> From: Mark Smith Date: Thu, 2 Nov 2017 07:35:27 +1100 Message-ID: To: Ole Troan Cc: Mikael Abrahamsson , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 20:36:00 -0000 Hi Ole, On 30 October 2017 at 08:49, Ole Troan wrote: > Mark, > >> On 29 Oct 2017, at 22:27, Mark Smith wrote: >> >> I think ND should be used on PPP,/POS etc. links for that reason. It ens= ures the address is present on the link before trying to send a packet to i= t. RFC4861 seems to be saying that because it says it applies to all link t= ypes, and it only makes an exception of NBMA links. > > The IPv6 implementations I work on, only does address resolution on link = types which have L2 addresses. > > There=E2=80=99s nothing stopping you from doing it on those links, but I = can certainly find no requirement to do it in 4861 either. > While I agree it is a little ambiguous, I think there are direct statements and statements that make implications that ND as described in RFC4861 is to be used over true p2p links, with ND meaning more than just link layer address resolution - ND meaning the description in the Abstract and Introduction i.e. "IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors." "... Finally, nodes use the protocol to actively keep track of which neighbors are reachable and which are not, and to detect changed link-layer addresses." I think the two key statements are "discover each other's presence" and "actively keep track of which neighbors are reachable and which are not" if "address resolution" isn't performed on a true p2p link, then a node is also not discovering a neighbor's presence. If it isn't discovering a neighbor's presence, then it can't actively track whether the neighbor is reachable or not. The ND NS/NA transaction provides both the link-layer address of the neighbor if it has one, and positive confirmation of the existence or presence of the address. I think there are more statements that imply ND NS/NAs are expected to be used over true p2p links. 1. Introduction "Unless specified otherwise (in a document that covers operating IP over a particular link type) this document applies to all link types." There is no separate RFC about running ND over p2p links, so RFC4861 applies to true p2p links. "However, because ND uses link-layer multicast for some of its services, it is possible that on some link types (e.g., Non-Broadcast Multi-Access (NBMA) links), alternative protocols or mechanisms to implement those services will be specified (in the appropriate document covering the operation of IP over a particular link type)." The exception link types seem to be links that don't support multicast and are NBMA links. 2.2. Link Types "point-to-point - a link that connects exactly two interfaces. A point-to-point link is assumed to have multicast capability and a link-local address." So true p2p links are assumed to be multicast capable links, meaning they don't fall into the NBMA link exception. 7.3. Neighbor Unreachability Detection "... Thus, a node actively tracks the reachability "state" for the neighbors to which it is sending packets. Neighbor Unreachability Detection is used for all paths between hosts and neighboring nodes, including host-to-host, host-to-router, and router-to-host communication. Neighbor Unreachability Detection may also be used between routers, but is not required if an equivalent mechanism is available, for example, as part of the routing protocols." No mentioned exclusions for p2p or any type of link. Very explicitly states that nodes' track neighbor reachability. The exception in the second paragraph is covering using something like OSPF's hello protocol as a substitute to track neighbor reachability/unreachability. However, static routing or DHCPv6-PD may be being used over the link to "distribute" routing information, and neither of them have a neighbor presence detection protocol, so NUD has to be used. Unreachability detection requires discovery of reachability. There are two choices. Either prevent the packet loop occurring if a packet is sent to a destination that doesn't exist, by probing for its existence via ND NS, or mitigate the consequences of the loop after it has already occurred. I think prevention is better than mitigation. Regards, Mark. From nobody Wed Nov 1 14:05:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EBA13F69E for ; Wed, 1 Nov 2017 14:05:09 -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 KTMGonuYLW2T for ; Wed, 1 Nov 2017 14:05:08 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E74136934 for ; Wed, 1 Nov 2017 14:05:08 -0700 (PDT) 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 027562D4FD1; Wed, 1 Nov 2017 21:05:06 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id B5454200908F30; Wed, 1 Nov 2017 22:05:03 +0100 (CET) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_580F812A-325F-4F14-B226-23BA2F215758"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Date: Wed, 1 Nov 2017 22:05:02 +0100 In-Reply-To: Cc: Mikael Abrahamsson , v6ops list To: Mark Smith References: <150860492012.3131.14623048904955800548.idtracker@ietfa.amsl.com> <0EAB4149-AFE9-4770-8242-6D8E05889091@consulintel.es> <66E223E7-73B5-49BA-AA40-5AA632F3F755@consulintel.es> <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 21:05:10 -0000 --Apple-Mail=_580F812A-325F-4F14-B226-23BA2F215758 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Mark, I most definitely think doing address resolution on links without = link-layer addresses is the wrong thing to do. Sure, other ND functions are being used. NUD isn't typically useful on = router to router links. Often p2p links have link-layer notification on = link state too, and I'd argue that the benefit of a router doing NUD = towards hosts have limited usefulness, unless it is to garbage collect = state. If we ever get to update NUD, I would argue quite hard for = simplification of the protocol. > There are two choices. Either prevent the packet loop occurring if a > packet is sent to a destination that doesn't exist, by probing for its > existence via ND NS, or mitigate the consequences of the loop after it > has already occurred. I think prevention is better than mitigation. If this is the problem you are trying to solve, then we have already = solved that. See rfc4443, from changelog: - In the description of Destination Unreachable messages, Code 3, added rule prohibiting forwarding of packets back onto point-to- point links from which they were received, if their destination addresses belong to the link itself ("anti-ping-ponging" rule). Was there any other unresolved problem I missed? Cheers, Ole --Apple-Mail=_580F812A-325F-4F14-B226-23BA2F215758 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+/bDNdvtpYqJhC33YFAln6Nv4ACgkQvtpYqJhC 33YtNg//aEqNFufav5PhJU4Bl7hMbddtXCmnfsOu1wRSfkxHUJKOu9yD/N7jszcC ToG+TcUwkClEyBJaGC2voYQChsQ7ThIehI6Y/B7HVCiX/30aM9DC8t9tPYRY1+5z OVR57SzL47kMlm6mCcAgW+zSkaiOtIeSatgLJqVQ87sXCGJaaAt6uaRwsN/HTq9u We1lpqQNk2MtJfXewpbs7ur33+WEyFHs4idb9fQgh1LgPDgqx02DQCIsO60uIb+r ASShEcVh9/L/q9OUZq5woK/UApeiY/QtLbB4oW4dY9tqakX2jFhGvDcLjVBiFYK4 nZ/j8A3LoEhgVA04Q5RKinTgjILMzM1joGYj95pqTZ4NNGjXcPZ6o9MRHQa6Y2UE nE/vUzjcqTkfZ498q+6TP3DAYMeIz8oOQg6z+qR79BhjAkJBLzCTFGhVFbmXbM7/ G+YCA7zLG+nQPu5fd5Sbeh58XovYBFqdX81EMc4AIXCb1B51Lp12XJTMK7Tz3aeo MsxAo8yEqbBtJDfXCKIGa2UoxCHG/r245PhUTGDVV8VhG1576wQXVAlvfNe8LR3y klryTU13fBV1SHO9vCzRwtAYg+jzmFCquZN9uUm/SfQwmWLMXDStnw/fSm59izbJ 1wq+GPj5/cFnE0qsXKJbBz2WXw9o82UCXfpuunNqWEQ3xtptSPk= =Kve4 -----END PGP SIGNATURE----- --Apple-Mail=_580F812A-325F-4F14-B226-23BA2F215758-- From nobody Thu Nov 2 00:55:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E14C13FA60 for ; Thu, 2 Nov 2017 00:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JkWc51bSVl1 for ; Thu, 2 Nov 2017 00:54:58 -0700 (PDT) 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 DEC3613FA5F for ; Thu, 2 Nov 2017 00:54:57 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id b9so9306700wmh.0 for ; Thu, 02 Nov 2017 00:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:subject:message-id:to; bh=zfAUursTKoR/uYIlE9l0BcyeNEQcBbHf00okVZvc3Ho=; b=n08rgsNEvZGI4UHuunpKdi+gTHCfx9vfjbpnVe8DGPNDvjC1Olzl2tdGA/G69HFAna 8THtdGiLgTDY+2zdI3qo47ADKpZcY9HZBcWRI6UBVidNXZEDRRMZFUcauTkPHMwmSHEK fBFAt66PvRYe84kIHIi0zyw3hJPXqgMvGH7iIHIactVuEM5yBydC2f5oZCM6sPaAF/Za UomEPgCq4NT6PVIeEqenWS4wteg/+hi8wc9P9YfXcYImD0viuBIc3KjagT0PBnqqavwF DVVi7BM0zL2VorD+iLngUrGGR7C9Fru6wYlEJK3sSFr2V2FtFLQP0ErWAid/VKvWzG5F 65UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:subject:message-id:to; bh=zfAUursTKoR/uYIlE9l0BcyeNEQcBbHf00okVZvc3Ho=; b=QESJdr9jp+0GO2fMaxblxTKKwWH1tjL7SwSJpXYewmNTqQmxLZ4ifbnOfE0EClfVQl puwQ8xyc6qgj/9MWVNScr66Xw4w+V41HeLmR+jfgLlzNhslpELdAcQOL2KSIRN7eYyFa uOJZxJKfunx9KB8Mb3RVN6bKKpy34Nyp74owbqaMroifLqnAfyRXuLHm4eprrXorDd1k ex+tGHCndPgeoOsa8DqvO6/OMbxtZX+iaCkyXs8431dtCXuZHHIc0HBhG+SxaeaAZlC/ Yo/sfctSwYYT5ALGxmIL5BxXLxx09dHpZvag77FxN7wYpWO6eANWizTVKYg5T/QrbIQc 9lsw== X-Gm-Message-State: AMCzsaU9y85j4xsg7Rm6Qk6yh8KlBt5eV5RtjeV3HyRM9wcibpTL18J1 VoUaeo9y96S7xjtXUaSK7R240YpD X-Google-Smtp-Source: ABhQp+TCEmdGsrg2XNXXXwtRM3mUsd+zN7QWcrQ0eMimd0KhytJLeaoFYVwCbR5ptAodvt08xodhXA== X-Received: by 10.28.65.133 with SMTP id o127mr841419wma.146.1509609296319; Thu, 02 Nov 2017 00:54:56 -0700 (PDT) Received: from 204.66.20.149.in-addr.arpa (204.66.20.149.in-addr.arpa. [149.20.66.204]) by smtp.gmail.com with ESMTPSA id 89sm1136888wri.79.2017.11.02.00.54.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 00:54:55 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_DD64E7EF-9ED0-4162-A95C-ADD7DDDD5586"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Thu, 2 Nov 2017 11:54:47 +0400 Message-Id: To: v6ops list X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [v6ops] Time for agenda bashing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 07:55:00 -0000 --Apple-Mail=_DD64E7EF-9ED0-4162-A95C-ADD7DDDD5586 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The chairs have posted a preliminary agenda for IETF 100 at = https://datatracker.ietf.org/meeting/100/materials/agenda-100-v6ops/. = The time to bash it is now... Current state of play is as follows. The chairs try to put things on the = agenda that (1) match our charter, (2) have been posted or updated since the previous IETF meeting (in this = case, 2017-07-22), and (3) which have had supportive email in v6ops@ietf.org. For the past few meetings, we have also included invited talks. In July, = we heard about Microsoft's work on IPv6-only networking. This time, we = will hear about Cisco's IPv6-only experience. In March, we are having = conversations that may result in a talk about the US Government as a = dual stack enterprise network. RFC Editor: AUTH48 2017-10-25 draft-ietf-v6ops-unique-ipv6-prefix-per-host RFC Editor: EDIT 2017-10-31 draft-ietf-v6ops-rfc6555bis WG: Unupdated WG Document 2017-06-12 draft-ietf-v6ops-rfc7084-bis 2017-05-05 draft-ietf-v6ops-ipv6rtr-reqs WG: Updated WG Document 2017-10-09 draft-ietf-v6ops-conditional-ras Individual Submission: Unupdated 2017-07-17 draft-hilliard-v6ops-host-addr-update 2017-06-30 draft-jjmb-v6ops-ietf-ipv6-only-incremental 2017-06-28 draft-xcf-v6ops-chinatelecom-deployment 2017-06-17 draft-baker-v6ops-cpe-autoconfigure 2017-06-11 draft-palet-v6ops-rfc7084-bis2 2017-06-11 draft-palet-v6ops-rfc7084-bis4-hncp Individual Submission: Updated 2017-10-30 draft-palet-v6ops-ipv6-only 2017-10-30 draft-shytyi-v6ops-danir 2017-10-29 draft-palet-v6ops-he-reporting 2017-10-29 draft-palet-v6ops-p2p-from-customer-prefix 2017-10-17 draft-palet-v6ops-rfc7084-bis-transition 2017-10-17 draft-xli-v6ops-cernet-deployment 2017-10-16 draft-templin-v6ops-pdhost 2017-10-09 draft-palet-v6ops-464xlat-deployment 2017-08-28 draft-xu-v6ops-dslite-redundancy 2017-08-01 draft-dykim-v6ops-sid6 --Apple-Mail=_DD64E7EF-9ED0-4162-A95C-ADD7DDDD5586 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+AFAln6z0cACgkQEhdRnd2G P+DgOQ/+JM+tnM/GFghp3Xfp2G41v6Dpjnu2ZMg0jVarIbRv+WZgnixN7bYWccPg ACTh5UXpp5cCjK3XIBRx0iFE4LKoGNb6hta6AD5M59XKOiwweUNAaMJxOI1O4kop cCGYnjLPJOqioh3FD/5wuZo1lXKnzuAe2WUC11f02P/hQ+U4G9EIXrW8xeuxv5Ga r4+yzszTQ+Rcn/o5rSazrmeCvfk11TiROAyRpv2PQ642oRm1K2NQyCdt++11Sf+4 3HrvQIwrxFxGGnSRXggKFtWHE/7RfFPz3DqPMFO+6FuIFS4r8tkpuztOaw3+TU3o cYZO9qkLohSFmAHImTszBZ7AcH75NpoGwV2eyB7O6EY8jDU2dTuKjJdYZwUoTu6D 3Y290oViFMYnAoEQHZzCR7KoQBkDe9Yn1jH8M8OMzkWidbcH+xD8nRHoHFZZIxTD k/tTrjKmU/YSabZyTh33Es8uz6l+ZXPHRfSizx4U5H5lLiO96oGKarkVnYFoOsHv K7F8NrXn8oEinZO7+CS1wGPm15I0D3TgHmG1JebGDQzUCv8zEtzIufQX9DbH/0Cn lQQOdUTisU4zav/bms1NuqdtM8JJAmb8zMtwJ4iZz0Y6HQ9cml9Ok6Tcin6LtHCc WTQCCrJP7NrPhYEWYAnn2Yiah4d1Y48JlgLG+lZdtS55Q9n6gvY= =VzOI -----END PGP SIGNATURE----- --Apple-Mail=_DD64E7EF-9ED0-4162-A95C-ADD7DDDD5586-- From nobody Thu Nov 2 06:02:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F7C13F45D for ; Thu, 2 Nov 2017 06:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3tHGhvPM4nZ for ; Thu, 2 Nov 2017 06:02:48 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0112.outbound.protection.outlook.com [104.47.0.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BFA138103 for ; Thu, 2 Nov 2017 06:02:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lHa4RHI374mQn8okES0+tmdEtokWooHWKfKv4sA8+dY=; b=SPvbLWpGB+Dy8iiuyD4lDNs2FM04ZoluAQ4/2goem4cwE5aQjJvT1bYs8Nh/1bD0vY6IwRWchTnE6H0UMWYTKeK7KVzwfj6vQXFGKTnFZZpc9aRWfsLpWNLP3Bj5XUbO2SLAJru3Gbdf3t6ozil3jJOf8zEHxIQtjxS5NDftnpM= Received: from pc6 (86.169.153.236) by VI1PR0701MB3006.eurprd07.prod.outlook.com (2603:10a6:800:87::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Thu, 2 Nov 2017 13:02:44 +0000 Message-ID: <047701d353da$7e3a4400$4001a8c0@gateway.2wire.net> From: "t.petch" To: , "Mark Andrews" Cc: "v6ops list" References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171101073231.653A48DDFD9C@rock.dv.isc.org> Date: Thu, 2 Nov 2017 12:59:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: VI1PR0602CA0010.eurprd06.prod.outlook.com (2603:10a6:800:bc::20) To VI1PR0701MB3006.eurprd07.prod.outlook.com (2603:10a6:800:87::20) X-MS-Office365-Filtering-Correlation-Id: 4628b163-4e21-43b2-8a48-08d521f2025e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(8989060)(201703031133081)(201702281549075)(8990040)(2017052603238); SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 3:TRUZ8upinqWSx7Uh52GDoh87Y9GKxYVSS2a+384YkmcfANruuGYQvVbiYHKlzaEY6pE9u7q91b70kRJKU76KX9+hJiyObKipnuA8Hdk2EuZOcIp2zpUepR1jhMR5uci+c3+zkPEEXwNNlEQUMs4sBcn/gyop8VmbY98f7W3lc4GXBjMIrzTtlY2rIpu5mATienb4WiX1bWLrr59lKHnBolrCPFIvyuo1dD2umXUFyWmtw6/+oet3MGYJxCUzMsox; 25:+AKvhtGQz4CtjJD/8OTNtah+6gz3hRI3PVAHuOS0r50nODLhn6O6D0ZYy4MsId6+9YK+2g9HVlFxqt2H7BbTtufsyqoF4QBDn6xyfRjutIKbEeqBJPP7DDC01jODJOG33fdFNKBDodHrt4HbOC98fKLWPb6grkzXOaoWQtmO9SnKhi6Td/1UmGlvUhso2PO1eiPCcFQ8vTSzxrkgwXEtVAI5U7jwgH0ebpUJqpWt4tHnQd2PN448Xw4it1ZhhCpUYoxKMYZIX0A4Gb2R0d5kbkP2LSMWSZjXLEudrvX/VlmOd6/wVy/TOXrqnGYXzN+3msFs149Bm1ooUFv04frh7A==; 31:EN70nK+U+YhvclhrpAsXtMckbQE0Uu5Jnskffl6FEepxFBACuSD8WqI4H8OEkELcdxgqXGTtBxR6ONA+142GNwNxZyu1oYNg2ZiCRGwpmhyaPk7ibQOmRHH/aRQKHLQum9Xvp0+pL52KLfh/nB6uglKBQLRSDSETP9UNZ1Ac3Lwkw7gX8vAhrlFMQAlEf3udlaDP3QfIgbg3CSlMUn+0Nbh5p25QkwHyoD+FmuxLpQ0= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI1PR0701MB3006: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Exchange-Antispam-Report-Test: UriScan:(60795455431006); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231020)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0701MB3006; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 4:/GwDmNxlhelOgtYq/Da5ADavO6FeO0VWlQtR4SN73c7jAkocUIqdb/mcorVV1tSfUQnOzyXAZDd+5GK7Mh62TOyZstp2RrGyWOQQNhwBPyvzW0sjwX3uhd57QrUnl5tP6hvjzy0McihoH8vO+gnw7WbS4y1vkGaD+sxxNwGtm0tekJRHKmsmIU/uYrz5/phie1UTXmdZLk8rjcr0yQAi6+3DXD6PI9F3M/WAhZmlc79oJZrKKoRQR5sgtqq+6gWftvMlL57IacvxQLkS3vU9HLPZ1qYkhACiN6uWxMI/5iT7ObDlSqGZqJaNG71bsW+L X-Forefront-PRVS: 047999FF16 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(13464003)(199003)(189002)(76176999)(97736004)(68736007)(7736002)(33646002)(81156014)(44716002)(25786009)(5660300001)(305945005)(8936002)(101416001)(81166006)(3846002)(8676002)(106356001)(9686003)(105586002)(2906002)(6116002)(189998001)(93886005)(230700001)(1556002)(23756003)(50466002)(1456003)(61296003)(6496005)(6306002)(6666003)(84392002)(6246003)(478600001)(53936002)(15650500001)(50226002)(110136005)(116806002)(62236002)(50986999)(16526018)(14496001)(47776003)(6486002)(316002)(81686999)(966005)(81816999)(4720700003)(229853002)(86362001)(66066001)(4326008)(44736005)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3006; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3006; 23:mO1BX5HgFOVee6nOgJVsAChToDPgdeHT1Me9Z?= =?iso-8859-1?Q?z44gtxVw/orEYMWhLRtLwfJmgiy20LOCka5YnOCxn309GO0ZAxVtE0jNxV?= =?iso-8859-1?Q?8PUh1XcrJq+ILMrTiAKisISPxiIympQsrIunr8Ol56bOQ3lWPjFAXjfUOE?= =?iso-8859-1?Q?sxTXEgswwh9Rwa68AnSPZry58lm+4EXocsa9aUuHX9UpZqtBoKnBkSJ3Sg?= =?iso-8859-1?Q?vvdFhQX/rb0B44gnBhLTeQGNRkDvelhtG0hvprSmSqqvSXNVh1ZMjcX8u5?= =?iso-8859-1?Q?xk7PtNztr+aWp3qQOuXtx4uy5icrYTCK8ppWuQ1imS4sP07ylJ71O/9HcC?= =?iso-8859-1?Q?6Gfv2w3aNbpHWP8G9RxjFAmL3m3sr6jeBv64ddDBosOjAKQLVkUPsXhzLk?= =?iso-8859-1?Q?NyeEjzfZpN38PzL8YXv4+wZGMl8DtIs2HtIYePNEYWSabkBbIvYisQfP0l?= =?iso-8859-1?Q?Mmsjj8NAh6uYkMbTATz3VWae/1JE4yxkaFVOfBEUTaA435S8+/TtiOOWwG?= =?iso-8859-1?Q?nZkj0mV2ypg5ZyfH1MdIuhAVpI12TE8rWI3Kg5EW/DlsTVME9hOZjxw6TP?= =?iso-8859-1?Q?vUmVQi0FZNTi1lDah3+L66SqDSLtLimWYxnGq6dTlpBga0jkunXS/W7K0J?= =?iso-8859-1?Q?O3xGnt29r74734udtuDawMS00X5rITVzOQ+Rn0Jh63Vt+1WgfL4Y0GDvOo?= =?iso-8859-1?Q?fX82yJU6EvO/bT2wtXXQ7Fdcf+qMbonCxLUJDcNPoX8Ahck+b2z6CYHwVi?= =?iso-8859-1?Q?CT2SKrSk7xqI9DxqWa8vrYYPVcLUgdExN63Jby0MfPSQ9LLBRBf56gGwY9?= =?iso-8859-1?Q?ReZLpIuGpgTlMU6W2Uo6rm2xbtt2fpw8/OHc1OPgkEPnhkDXleD2xzhJqI?= =?iso-8859-1?Q?0/B+v1kb5TSQTdf+NupQGqLyG8CYoEeUaZufZ0p/kR3tG5rJzxm4nna150?= =?iso-8859-1?Q?/XjzyJG3SiDF+UjYBLyfliXT5v0+dESs3oaDwPRGNUymYMUZdgdIfKCivm?= =?iso-8859-1?Q?PPCWRHJexAqa6pWXRD1OndxbXKDzDbWjCoJQ3XHtamYhXXSlEDi6Yb4Bw4?= =?iso-8859-1?Q?yPhJCWgtJ5SQxwqlP5VkH6+adY8GvPmSzyKjUepqiDTbHrU83k7gIhj7Qe?= =?iso-8859-1?Q?agMu9TLxx+UMX22He703KLMEBWsVgzA9tFK18ixFI/58/8iEqTe/6LyvVe?= =?iso-8859-1?Q?5LNoe21KbbgTJ8miQJikWBArCPCFXdcxCmwHpuumSQHGX4qth51WHrvoDh?= =?iso-8859-1?Q?c5Nd89o6EkUu+BT2DqAQ9THq8xRRTI6sLYn1WoYbpMo2L1YUQfbOBRLxOi?= =?iso-8859-1?Q?z/NSuvkAvcV6LkJZxNHM67WuNYijlB5FeY4uYdYAk1gC7x/nANQAR5Z6NP?= =?iso-8859-1?Q?qURptvHLB2yzP6nRSLPYvWBkelDt7fSYCx3ubaQdQ0SL6e+V0dwA1okSKm?= =?iso-8859-1?Q?VNKFQCQJ7aMZ7eU/oQiYaCPJaLfRbZwkjSBJT/qDuCmdik/3FaiZyUp71U?= =?iso-8859-1?Q?Ok04FD3LmEaGvTXYHFTbc6Zc3zczTa/TwDCkv4mqPZ1?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 6:WoohE3ILUHUL/APGmuCxvRQAAEzF1647pEXkeyGO1WqZbr+GrHUdEY53LRY8AUVqT1GXwebB97vTyhWBhydC8Bw5ZQGZZm2uq1HmOwHIszHoxxTdF8iXXv/j1Md9NrdV3NWv2ksgv7Ulb7kCcfbSlA7dWRMnd+izIxVu1FlB9ReE6v7s1OL4zLiMboVKJ4nDEWVeWEaIvj+yTPbOHts6yvnFhTmxYYom0xRrM+Mh7/8/Mm3/Codhoa00B4Tzm4NT53/IuV0KGPuYbHW2AJVIuC3YRlYNpQOiB28N/FfhKVIwWGQ/cadS/1NINkE/7hfRnOH9r6/TNda+EhXmes4dV9LQy5D3YQ3gwSV0BubVF2Y=; 5:7+0d7uUd0gN7eIlXreTqOQaxdy9e2Sq+FnBRj9xFm6XZ5t+yAwr6UcgKMBU1jrlfr7tCrhZyMk2GXkQd17KhJ8ybWMPK3lg3qEdXxuWh82AruVVol3Q94OjVzHoAGczkaFuAi+TPbJOmvsN6pd543ETBwAC4Sj9irW976j2CYhs=; 24:L2m3neZFuKwON/8kbqEEdU/x3wFzIB18STCeDxtDfHD3UoCxy20TfRhVwAMMiuyW5649jihTfAWrAElmja4xBvr4ln+jG9cZu5PKbE+6teY=; 7:iinzANNnvo959KlpJP5Wa1tvT9cu7FrN2nPfn1X6HXvc+MaOY8HyveS6xH40WpMTQbU7Vf7n2pRB2i2cUxX3CtljwEY0pivtO/cG4QSkk5G8DkQJYGnPQzbhw5WgrzUqjOtzEL2XvWRk9tHWG33nixW+p7RWv4/T9MBCvNZJqekvjAy5dR6h5kq4k/y6Zo/nIzEgkazjcHhACFor9M2UYjRScOpS42WmTOnR9qjYtcisOD7dUjkHZZ1qEB4ZgDur SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2017 13:02:44.4283 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4628b163-4e21-43b2-8a48-08d521f2025e X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3006 Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 13:02:55 -0000 ----- Original Message ----- From: "Mark Andrews" Sent: Wednesday, November 01, 2017 7:32 AM > JORDI PALET MARTINEZ writes: > > Totally agree, however there is a subtle situation here, when we > > associate this to the origin of the thread CGN > > > > If an unlawful action has been done with that phone, the phone owner will > > be responsible in front of the law to identify the person who has go the > > phone. Otherwise, the courts will judge you as the author of the unlawful > > action. > > Please cite the relevent law. Phone are hacked all the time. Phones > are shared all the time. There is only ever a strong correlation > never absolute proof. For proof you need other data. > > > Same as if you are the owner of a car that has an accident and dont stop, > > unless you identify in and undoubtable way a third person driving the > > car, it will be your problem. > > Cars get stolen all the time and sometimes the first you know about > is a knock on the door. The owner of the vehicle is just the first > step in the investigation. Things like a speeding fine may get > lumbered on you but failure to stop requires more that you are the > owner of the vechicle to be proven. Mark UK law changed some years ago and introduced, or reinforced, the concept of a Registered Keeper of a vehicle and, in some cases, they are legally responsible, e.g. to say who was driving at the time an offence was committed; if they do not oblige, then they are liable, and can and do get convicted in a court of law. It means that change of ownership must be registered promptly which has led to a number of court cases. As I recall, this change in the law came about because too many people were saying 'I cannot remember' and so prosecutions were failing. The popular press is for ever referring to an IP address as 'identifying' who was doing what; while we may know better, most people, doubtless some law enforcement agencies, do not. As the use of the Internet for crime grows, and people's losses mount, so I see this wish to identify who did what when via an IP address growing ever stronger so I think we will see changes to the law to identify who 'owns' an address and who is then obliged to reveal data about its use at a given time. On the other hand, prosections for criminal negligence against companies fail, or are not even brought, because UK law has required individuals to be identified as responsible, not the company, per se, as a legal entity. This has been the case for decades and this issue often surfaces after a significant tragedy but the appetite for change seems limited, so perhaps identifying people by IP address will go the same way. Either way, I think we need to keep abreast of developments in our varous jurisdictions. Tom Petch > > So, and this is what I was trying to point to the EU article 29 working > > party many years ago, even if you identify an IP address, it is almost > > impossible to say this is personal data, you need to correlate that with > > many many many other data, and even do, unless you have a live record of > > he/she being in front of the keyboard at that specific time. > > > > However, the implications of CGN for the police is that, without a CGN, > > the owner for the phone that done that unlawful act (in EU you need to > > provide a legal ID to have a phone line) using that IP address, the > > identification is direct, no further investigation is needed and is the > > owner the responsible to identify a third party if that's the case. With > > CGN, if the IP address is shared and there are no source ports records, > > the investigation brings the police to a number of people, may be only > > 16, may be hundreds, which is a big issue. > > Only if you are looking at single events. Multiple events will > probably whittle the set down to a subscriber. That doesn't > necessarially identify a individual. > > > Regards, > > Jordi > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Nov 2 09:56:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EC013F74C for ; Thu, 2 Nov 2017 09:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=daveor.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4c-Vgwxkc5E for ; Thu, 2 Nov 2017 09:56:47 -0700 (PDT) Received: from vps.ftrsolutions.com (vps.ftrsolutions.com [5.77.39.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4290413F621 for ; Thu, 2 Nov 2017 09:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daveor.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type: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=OqVM2cHjvfJZxUGq+puDQx7V2xN22ADvcX9DD+mQdwE=; b=lYxmv2ck7Ym+A7DgZD+k08ysEX /JT2euCAkOvJ8MNGemLCBQDm1ufZcWhQ2VV7qLNGqlbpu0t159FqOFmC+4/WZOSbPlTL6lQnrMZwk vQwSMOZMMRAjjAKwZK6xlP5F9SbwYfR0PXJaduKP+KK4aJAWNuPCLD1biDWKHg8DfT2A=; Received: from [83.103.212.135] (port=62237 helo=[172.16.102.121]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAInN-0002bf-0u; Thu, 02 Nov 2017 16:56:45 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave O'Reilly In-Reply-To: <1A0AE76A-FA3C-4BDE-B8D9-C8D2E060A8A8@gmail.com> Date: Thu, 2 Nov 2017 16:56:46 +0000 Cc: Mark Smith , Tore Anderson , "v6ops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <81B18C7D-76F7-40BC-8252-D833DDF95254@daveor.com> References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22C655A9-AE02-4885-98B5-7515C49E7F2B@employees.org> <95274753-7241-47DE-B463-0341248FAE38@employees.org> <5FA44821-D6C2-4A9C-A1A5-59BECB65B4F4@gmail.com> <1A0AE76A-FA3C-4BDE-B8D9-C8D2E060A8A8@gmail.com> To: Fred Baker X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.ftrsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - daveor.com X-Get-Message-Sender-Via: vps.ftrsolutions.com: authenticated_id: dave@daveor.com X-Authenticated-Sender: vps.ftrsolutions.com: dave@daveor.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:56:49 -0000 Totally agree with your assessment of the value of IP data - it cannot = alone be used to identify an individual, and I don=E2=80=99t think = you=E2=80=99d find many law enforcement officers anywhere who would = disagree with that assessment. As I mentioned in the email I just wrote, = even if the IP address identifies a specific device/endpoint (which it = almost always doesn=E2=80=99t) that in no way attributes the activity of = that device to a specific individual.=20 HOWEVER: taken in the broader context of an investigation, IP address = can play an important role in either pointing the investigation in a = particular direction or corroborating evidence gathered from other = sources. daveor > On 30 Oct 2017, at 02:41, Fred Baker wrote: >=20 >=20 >=20 >> On Oct 29, 2017, at 11:48 PM, Mark Smith = wrote: >>=20 >> Geoff Huston's article on >>=20 >> Metadata Retention and the Internet >>=20 >> https://telsoc.org/ajtde/2015-04-v3-n1/a4 >>=20 >> might be of interest. >>=20 >> "The Metadata Retention measures being considered in Australia make = some sweeping assumptions about the semantics of IP addresses and their = association with individual subscribers to the Internet. But are these = assumptions warranted?" >=20 > In that context, the European Data Retention Directive (which has now = been struck down by the European Privacy Court) and the activities by = the "Five Eyes" in that regard, notably the US NSA, have been very much = about metadata. I asked a Dutch agency representative once what their = reason for lawful intercept in general and metadata capture specifically = was, and he indicated "mapping criminal networks". They wanted to = determine who spoke with whom, with a view to identifying members of a = community, presumably an evil community. >=20 > I note that the European Privacy Court has (apparently) specified that = an IP address is "Individually Identifiable Information", the kind of = thing that might be discussed in https://tools.ietf.org/html/rfc7721. I = have asked repeatedly what privacy folks think might be an IID below the = application layer, and that is the one thing they have come up with. On = the point, I would argue that data of that type is not *identification*, = but it might be possible to correlate it with other information due to = operational practice. To my mind, stomping out correlations is a game of = whack-a-mole; someone that desperately wants to find a correlation will = probably find something that mostly works for their purposes, even if = they have to discard spurious correlations to do so. In my view, that's = what we see here: we might be able to correlate an IP address with a = computer or subscriber, but we can't stop people in a business or family = from using each other's computers. It is at best an investigative tool, = not proof of something in particular. From nobody Thu Nov 2 09:58:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06A813B432 for ; Thu, 2 Nov 2017 09:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=daveor.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCr5vRNHEIgl for ; Thu, 2 Nov 2017 09:58:55 -0700 (PDT) Received: from vps.ftrsolutions.com (vps.ftrsolutions.com [5.77.39.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AC913ACAB for ; Thu, 2 Nov 2017 09:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daveor.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type: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=CKLCrZbk+AtH4+CaviptBy+eehfXCLlSBNMG8vHFANQ=; b=iGLBQcMEQvRxWgHOsKbwJJged2 A9WWLaX3cz0jC6U8/yPCqS+Ay0TatCNuCPO697/CElB50gOj+a/JAxjHZu+fIr/1s3cLHP1gtuF9m 4qCN6VQGKXYAzBvsD0x0qZB3kqvfZUctQpacX6EhLaqT1rf2Lb03YdIWsmYVLIV5B4yc=; Received: from [83.103.212.135] (port=62244 helo=[172.16.102.121]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAIpR-0002ee-5L; Thu, 02 Nov 2017 16:58:53 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave O'Reilly In-Reply-To: Date: Thu, 2 Nov 2017 16:58:54 +0000 Cc: Warren Kumari , "v6ops@ietf.org" , Tore Anderson Content-Transfer-Encoding: quoted-printable Message-Id: References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: Ole Troan X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.ftrsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - daveor.com X-Get-Message-Sender-Via: vps.ftrsolutions.com: authenticated_id: dave@daveor.com X-Authenticated-Sender: vps.ftrsolutions.com: dave@daveor.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:58:56 -0000 Totally agree. As I mentioned in the email that I just wrote, even if = the IP address identifies a device that is no indication of who was in = control of that device at a particular time. Don=E2=80=99t forget that = there are other possibilities, for example, that the device may have = been remote controlled by e.g. malware - I think this point would be = pretty well understood in the law enforcement community but I will = review the draft and clarify this point if necessary. Thanks, daveor > On 30 Oct 2017, at 09:03, Ole Troan wrote: >=20 > Hi Dave, >=20 >>> Major comment: >>> 3) The document talks about identifying an individual, and in places = a subscriber endpoint. What it does identify, is the _originating = network_. What you get is the public interface address of the customer = CPE. Which looks like a network from the inside. >>> Make it very clear that this does not identify individual hosts. And = it might be worth noting that traffic my enter the originating network = from outside. E.g. through VPNs, TOR exits, shared WIFI and whatnot. >>>=20 >>=20 >> Yes, I completely agree. >>=20 >> I do address this point in the -01 revision scope section: >>=20 >> "Clearly no single solution will address the problem of crime = attribution on the Internet. Load balancers, proxies and other network = infrastructure may also, intentionally or as a side-effect, obfuscate = the true source of Internet traffic and these problems will continue to = exist with or without the presence of large-scale address sharing = technologies (like Carrier-Grade NAT and A+P).=E2=80=9D >>=20 >> I wanted to mention the point without getting dragged into details of = all of the possible scenarios where an IP address does not represent an = individual or subscriber endpoint (apart from CGNAT). I was of the = opinion that there is a risk of trying to =E2=80=9Cboil the ocean=E2=80=9D= with a document like this so I was trying to keep the focus as tightly = as possible on the issues raised by CGNAT. >>=20 >> In light of this, do you think this needs to be more explicitly = discussed or clarified? >=20 > I think that's fine. > As long as you make it clear that: > - the IP address _never_ identifies an individual. > - it identifies a host, a source network, or the obfuscated result of = a TOR gateway, VPN, another NAT, LB etc, etc... >=20 > But never, ever by itself an individual person. >=20 > Best regards, > Ole From nobody Thu Nov 2 10:01:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD0513F74C for ; Thu, 2 Nov 2017 10:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=daveor.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzdXaCgbCJbC for ; Thu, 2 Nov 2017 10:01:42 -0700 (PDT) Received: from vps.ftrsolutions.com (vps.ftrsolutions.com [5.77.39.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8B513B262 for ; Thu, 2 Nov 2017 10:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daveor.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type: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=RlGWT3G9/RKohz5LOefwGzUNfw6tOZWVF5L0WIdZzQ8=; b=XPr3EfWZvB2D9waJddTe0VUCLD EWUwpCrMwzqpk2mHPapWoAdSYCdX2FWXU5bn6SOWWay39h5IvdsT6JzqY4lyXnQ71AMJa1dIdk/tU X03lm7ocXRLrtBZ1b69Ip8GdT3a/fbGsTURtNEHBIKHpbSSqIx00B405H9lfaJvHyZmA=; Received: from [83.103.212.135] (port=62258 helo=[172.16.102.121]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAIs8-0002hB-Dp; Thu, 02 Nov 2017 17:01:40 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave O'Reilly In-Reply-To: Date: Thu, 2 Nov 2017 17:01:40 +0000 Cc: Ole Troan , "v6ops@ietf.org" , Tore Anderson Content-Transfer-Encoding: quoted-printable Message-Id: <2A3259DF-AB23-468C-B737-01B876812C62@daveor.com> References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: Tom Herbert X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.ftrsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - daveor.com X-Get-Message-Sender-Via: vps.ftrsolutions.com: authenticated_id: dave@daveor.com X-Authenticated-Sender: vps.ftrsolutions.com: dave@daveor.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 17:01:44 -0000 Two questions getting slightly conflated here.=20 1. Whether an IP address represents a specific device (it doesn=E2=80=99t = in most cases) or individual (it doesn=E2=80=99t without corroborating = evidence from some other source) 2. Whether an IP address is judged (legally) to be personally = identifying information (it is, in the EU at least) I don=E2=80=99t think I have much more to contribute on these points = apart from what I have already put in the emails just sent. daveor > On 30 Oct 2017, at 14:48, Tom Herbert wrote: >=20 > On Mon, Oct 30, 2017 at 2:03 AM, Ole Troan = wrote: >> Hi Dave, >>=20 >>>> Major comment: >>>> 3) The document talks about identifying an individual, and in = places a subscriber endpoint. What it does identify, is the _originating = network_. What you get is the public interface address of the customer = CPE. Which looks like a network from the inside. >>>> Make it very clear that this does not identify individual hosts. = And it might be worth noting that traffic my enter the originating = network from outside. E.g. through VPNs, TOR exits, shared WIFI and = whatnot. >>>>=20 >>>=20 >>> Yes, I completely agree. >>>=20 >>> I do address this point in the -01 revision scope section: >>>=20 >>> "Clearly no single solution will address the problem of crime = attribution on the Internet. Load balancers, proxies and other network = infrastructure may also, intentionally or as a side-effect, obfuscate = the true source of Internet traffic and these problems will continue to = exist with or without the presence of large-scale address sharing = technologies (like Carrier-Grade NAT and A+P).=E2=80=9D >>>=20 >>> I wanted to mention the point without getting dragged into details = of all of the possible scenarios where an IP address does not represent = an individual or subscriber endpoint (apart from CGNAT). I was of the = opinion that there is a risk of trying to =E2=80=9Cboil the ocean=E2=80=9D= with a document like this so I was trying to keep the focus as tightly = as possible on the issues raised by CGNAT. >>>=20 >>> In light of this, do you think this needs to be more explicitly = discussed or clarified? >>=20 >> I think that's fine. >> As long as you make it clear that: >> - the IP address _never_ identifies an individual. >=20 > Ole, >=20 > I don't think this is something that can be part of the definition of > an IP address, it's more of a desirable property of how IP addresses > are assigned and used. For instance, a smartphone is given an IP > address and technically identifies the host. But given that there is a > likely one to one correspondence between personal device (and its > address) to an individual user, the IP address of the device > effectively identifies the individual or at least can be used with a > little more information to do so. In this case, the IP address seems > to be Personally Identifiable Information. >=20 > Tom >=20 >> - it identifies a host, a source network, or the obfuscated result of = a TOR gateway, VPN, another NAT, LB etc, etc... >>=20 >> But never, ever by itself an individual person. >>=20 >> Best regards, >> Ole >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From nobody Thu Nov 2 10:07:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C1813F79E for ; Thu, 2 Nov 2017 10:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=daveor.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z6HUfEPOYvr for ; Thu, 2 Nov 2017 10:07:16 -0700 (PDT) Received: from vps.ftrsolutions.com (vps.ftrsolutions.com [5.77.39.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FA913F7B0 for ; Thu, 2 Nov 2017 10:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daveor.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type: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=kGjNHa55kUR9iO/B/Cmmbx7yaP6SV/b+E+BNDkoaIDY=; b=Bxm5pXIgDgPa+Yp6JEK7jBv1my IVRRCYoR/Q2cx/33VMw+EGXiEhZb7wzp6ChHMQiFadGcGpHon6PG7c0l+sjJxEFFjCqLRXbz2vTYK 3Ag8iRehl0tuwQ3kZahHm4XXuHdcf9KdknZfvEGibvB/sxTzCYayGg5UPnYnrDW0s0jc=; Received: from [83.103.212.135] (port=62276 helo=[172.16.102.121]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAIxQ-0002nG-Pa; Thu, 02 Nov 2017 17:07:08 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave O'Reilly In-Reply-To: Date: Thu, 2 Nov 2017 17:07:09 +0000 Cc: Mark Smith , Tom Herbert , Tore Anderson , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: DY Kim X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.ftrsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - daveor.com X-Get-Message-Sender-Via: vps.ftrsolutions.com: authenticated_id: dave@daveor.com X-Authenticated-Sender: vps.ftrsolutions.com: dave@daveor.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 17:07:25 -0000 All sorts of scenarios could still arise to challenge that assumption. = For instance, a person could be forced to enter their credentials under = duress. If you need to establish that a person was using a device at a = particular time =E2=80=9Cbeyond a reasonable doubt=E2=80=9D you really = need something like a statement from them that they were the only person = to ever use their device and/or a statement that they had it in their = possession at a particular time (i.e. wasn=E2=80=99t lost or stolen). = All pretty standard stuff from a law enforcement point of view.=20 That is all, of course, presuming you can associate an IP address with a = specific device (you may have seen the recently published Internet Draft = on crime attribution in cases involving large-scale IP address sharing = :-)) daveor > On 1 Nov 2017, at 01:47, DY Kim wrote: >=20 > When unlocking your smart phone, you might use the =E2=80=98finger = touch=E2=80=99 identification, in which case the device use might = identify the individual. >=20 > When a password or swipe pattern is used, the association might be = weaker since those could be stolen. >=20 > --- > DY >=20 >> On 1 Nov 2017, at 10:42, Mark Smith wrote: >>=20 >> There really needs to be something else that supports or proves use = of a device other than an assumption that an IP address is tightly = coupled to a device's owner, and therefore all actions associated with = an IP address are those of the device's owner. >=20 From nobody Thu Nov 2 10:12:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307C013F7A2 for ; Thu, 2 Nov 2017 10:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=daveor.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IH3BRsUgvyuY for ; Thu, 2 Nov 2017 10:12:48 -0700 (PDT) Received: from vps.ftrsolutions.com (vps.ftrsolutions.com [5.77.39.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259961386DE for ; Thu, 2 Nov 2017 10:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daveor.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type: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=xROmqji2IP18fN6L2E7UVRmcy08dOM+pB4rg5Bbmck4=; b=ZtlGTMzeH6OwCy3qRVGnfVSyhB nbFE3LJ/bA1TXWrqp1ezQlPqHbzruSTIIttTpFXTXxuL/IxOIGCuA9DuZJ9Kk/FkY/UzeYR2sqwwS tmQ94SDOpKZdTCY0Aua+B96o2hXAlP69R6HJpZE5ofaerip3/qnQPQ+GWvu4d+H7ftP0=; Received: from [83.103.212.135] (port=62318 helo=[172.16.102.121]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAJ2a-0002sr-Vf; Thu, 02 Nov 2017 17:12:29 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave O'Reilly In-Reply-To: Date: Thu, 2 Nov 2017 17:12:29 +0000 Cc: Mark Smith , Ole Troan , v6ops list , Tore Anderson Content-Transfer-Encoding: quoted-printable Message-Id: <8C09CC26-AA68-4E1F-98F4-963B5A53F875@daveor.com> References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: Tom Herbert X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.ftrsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - daveor.com X-Get-Message-Sender-Via: vps.ftrsolutions.com: authenticated_id: dave@daveor.com X-Authenticated-Sender: vps.ftrsolutions.com: dave@daveor.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 17:12:49 -0000 Tom, I have a question. You say: =20 >>=20 > Mark, >=20 > I think the point is that for privacy we _don't_ want IP addresses to > identify individuals, but it is work to ensure that they don't. The > fact that a device can be shared makes the coupling weaker, but > probably not weak enough to be considered good privacy unless the > population sharing the device is large enough to avoid statistical > inference. >=20 I never understood this to be a design consideration of IPv4 (I don=E2=80=99= t know about IPv6 but perhaps others could enlighten me?). In either = case, is it the case that =E2=80=9Cwe don=E2=80=99t want IP addresses to = identify individuals=E2=80=9D? Is it not more the case that the = evolution of technologies on the Internet has, as a side effect, meant = that IP addresses don=E2=80=99t identify individuals? >> There really needs to be something else that supports or proves use = of a >> device other than an assumption that an IP address is tightly coupled = to a >> device's owner, and therefore all actions associated with an IP = address are >> thoe se of the device's owner. >=20 > I believe there is. It is common for apps, like email, social > networking, etc. to login to a service with username and password. > When login is done, the service now has a mapping of an individual to > an IP address. That mapping could then be exploited to identify the > same individual in completely unrelated communications, hence breaking > privacy. This could be done external to the device and the network > provider and across different jurisdictions. The problem is > exacerbated if the app is always connected so that whenever the > devices gets a new IP address to user mapping maintained by some third > party is kept up to date. Also, in this case, randomizing addresses at > some frequency may no provide much benefit to privacy unless every > connection gets a different source address (which is effectively is > what CGNAT gives). >=20 You don=E2=80=99t even need to log in to anything - isn=E2=80=99t this = exactly how doubleclick et-al work? They drop a cookie on your browser = and then follow you around the Internet on all sites with double-click = banners?=20 Same problem for any application layer identifying information - but = also a bit beyond the scope of the CGNAT discussion... daveor From nobody Thu Nov 2 10:17:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C5813F758 for ; Thu, 2 Nov 2017 10:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=daveor.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3ZoMvqlQrtl for ; Thu, 2 Nov 2017 10:16:59 -0700 (PDT) Received: from vps.ftrsolutions.com (vps.ftrsolutions.com [5.77.39.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D22213F503 for ; Thu, 2 Nov 2017 10:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daveor.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Content-Type: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=2gi6dP8JdFDIVyDtnjDxXZkubsdSegOYZivc9CP90ec=; b=ktSYNIXoiTiR3GjZgMHciccdkl X4X5XpCYANFEUjMWmmxBxWIakVLHZruDyd/r5FD/hP65Aj7j4u2m4jFzAycNyTKomeVnQMfI8X1Q5 G6iStYbcjEXWScYhXIdNArbWSYBFqIeXgrA4OEObK0c2eJCkdr7yjOboqY9rNINDfiJw=; Received: from [83.103.212.135] (port=62332 helo=[172.16.102.121]) by vps.ftrsolutions.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAJ6v-0002xP-E1; Thu, 02 Nov 2017 17:16:57 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave O'Reilly In-Reply-To: Date: Thu, 2 Nov 2017 17:16:58 +0000 Cc: Warren Kumari , "v6ops@ietf.org" , Tore Anderson Content-Transfer-Encoding: quoted-printable Message-Id: <4371DA07-BEE2-4CD3-B6AC-8D2547F8360B@daveor.com> References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: Lee Howard X-Mailer: Apple Mail (2.3124) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.ftrsolutions.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - daveor.com X-Get-Message-Sender-Via: vps.ftrsolutions.com: authenticated_id: dave@daveor.com X-Authenticated-Sender: vps.ftrsolutions.com: dave@daveor.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 17:17:01 -0000 > On 1 Nov 2017, at 14:07, Lee Howard wrote: >=20 >=20 >=20 > On 10/29/17, 8:32 PM, "Dave O'Reilly" wrote: >>=20 >>>=20 >>>=20 >>>> Can we regulate our way out of this problem? >>>> = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>=20 >>> Probably not. Countries with the highest IPv6 deployment have had = either >>> no government influence, or little more than government talking with >>> industry about their IPv6 deployment plans. Countries with IPv6 = mandates >>> on industry seem to have very low actual deployment. >>>=20 >>=20 >> I completely agree with you that there are too many regulatory models >> around the world for a recommendation of regulatory solutions to this >> problem to be likely to meet with much success. However, Belgium has = the >> highest IPv6 adoption rate on the planet according to >> = https://www.google.com/intl/en/ipv6/statistics.html#tab=3Dper-country-ipv6= -a >> doption&tab=3Dper-country-ipv6-adoption and I understand that the = reason >> for this is that the telecoms regulator in Belgium required that a >> maximum of (I think it was) 16 people can be sharing a single IP = address >> on a CGNAT at any given time. I forget the exact figures but it was >> definitely a regulatory intervention. >=20 >=20 > My understanding, which is indirect, is that Belgian law enforcement = and > telecom regulators sat down with ISPs and said, =E2=80=9COur reading = of EU law > says CGN is illegal.=E2=80=9D And ISPs said, =E2=80=9CWe have to do = CGN, or turn off the > Internet, (or maybe increase Internet prices to buy IPv4 = addresses).=E2=80=9D So > the regulators agreed to forebear enforcement of the no-CGN law unless > address sharing exceeded 16 users per address. >=20 > I have been unable to find this agreement in writing, though. That = might > be intentional. >=20 > So, yes, I suppose it is regulatory intervention, but it=E2=80=99s not = new > regulation, it=E2=80=99s a different inteprpretation than other EU = member states > have of EU law. And it=E2=80=99s not a regulation, it=E2=80=99s an = unwritten understanding > (or forebearance).=20 >=20 > I would welcome correction if my understanding is inaccurate our = outdated. >=20 >=20 I know it was a regulatory intervention alright but I don=E2=80=99t know = the details of the discussion, perhaps it is a voluntary code of = practice. In either case, such interventions are unlikely to be broadly = applicable as a solution to the crime attribution problem. >>=20 >>>>=20 >>>>=20 >>>> However, the obvious question to ask is - are the Belgian = authorities >>>> catching any more criminals now that they have such a high adoption >>>> rate >>>> of IPv6? Has the problem of crime attribution due to CGNAT gone = away >>>> for >>>> them, or does it actually require global adoption of IPv6? >>>=20 >>> The question is more like, =E2=80=9CAre Belgian authorities catching = more >>> criminals than other countries in proportion to their IPv6 = deployment?=E2=80=9D >>> They=E2=80=99re probably not catching more bad guys than they were = before CGN, >>> they=E2=80=99re just trying not to lose ground. >>> And the answer is probably not good, because although Belgium has = great >>> numbers on eyeballs, their IPv6 deployment on content sites is still >>> weak >>> (https://www.vyncke.org/ipv6status/detailed.php?country=3Dbe ). >>>=20 >>>=20 >>=20 >> Exactly! So they can attribute domestic IPv6 activity to domestic = IPv6 >> addresses but the second IPv4 to IPv6 transition takes place = they=E2=80=99re no >> better off than anyone else. >=20 > Do you mean IPv6 is no better than CGN for attribution, or do you mean > IPv6 is no better than native IPv4? >=20 What I meant was that at some point IPv6 to IPv4 translation will need = to take place, which is essentially a form of large scale address = sharing, similar but not identical to the CGNAT problem (similar enough = to form part of this discussion in any case). Until IPv6 is ubiquitous = and IPv4 is no longer routable this problem will remain to a greater or = lesser extent. >>=20 >>>>=20 >>>> The role of the IETF in this >>>> = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 >>>>=20 >>>> Right from the front page of the IETF website: "The mission of the = IETF >>>> is to make the Internet work better by producing high quality, = relevant >>>> technical documents that influence the way people design, use, and >>>> manage >>>> the Internet.=E2=80=9D >>>>=20 >>>> Large scale address sharing technologies present a challenge to the >>>> management of the Internet so that seems to fit right within the = remit >>>> of >>>> the IETF to me. Correct me if I=E2=80=99m wrong... >>>=20 >>> Not entirely, but this seems more operational to me, and might be = better >>> targeted as a recommendation for how to manage servers. >>>=20 >>=20 >> Well, the IETF has already published such recommendations (RFC6302). = The >> question is what, if anything, else the IETF can/should do. >>=20 >> I wrote this document and I didn=E2=80=99t really know what to do = with it, so I >> published it as an internet draft and have been trying to collect = input >> on what/where the best places to progress the conversation are=E2=80=A6= and here >> we are. >=20 > I do think it has been a good discussion. You might propose it as a = talk > at NANOG, RIPE, or whatever your local NOG is. Even better would be to = get > in front of web server operators, but I don=E2=80=99t know whether or = where they > meet. >=20 Good idea, I will investigate this further. I have been trying to find = out how best to approach OWASP and the apache software foundation to try = and get the discussion going with them at least. No success so far, but = I=E2=80=99ll keep going. daveor From nobody Thu Nov 2 11:07:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B5913F75F for ; Thu, 2 Nov 2017 11:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6ZAXAJHpGmlH for ; Thu, 2 Nov 2017 11:07:47 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D0213F56A for ; Thu, 2 Nov 2017 11:07:46 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id p1so476400qtg.2 for ; Thu, 02 Nov 2017 11:07:46 -0700 (PDT) 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=yvTzlST2YbNtQeAOfLMbYtW2tqfXQ8O0uPEfuEGf6ao=; b=ndTLtJ00/CICJa900GAxwJVdsfYVYpxRZdw0zCOEwlL/rl+OuWkZPnBjQIVHEbUYQE fOzlJdiYJ2MuUt50tuEaYaUAgLWoHdOtu4xc7j6ea2P5BIKTO5oUBV8ZHO/YmnvWhbhM c7hmY5IXssC11JBISECpX60Ik8FxIDmae2VyLEJKb1CBkjqiVIGrZiaADosn+HB/V0bt m+AXO9OeeBz07Qvu9NFmKANkEZLUY0rRf/HxsIYoMWzaBZgoGVzfg4yPXF0n35vzaayf kbi+8IxtiLecNzAlClssrJ9bnr6K51TprmpKE8ZAaD5OwxSujlm2FmWI1R4V0DnRwVRG u0KA== 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=yvTzlST2YbNtQeAOfLMbYtW2tqfXQ8O0uPEfuEGf6ao=; b=oFLvSZdeYy5SAPOvfOuG+ncJUyNx/C/0iloGaRK2/GjhtNnq6P4bknScJnaaH6odwn IKN5cl1PbjxXvBgDzv0hvid2fLblxJ+hlKMh7hneRDsK6J5/cwEGeGRw6ciiQQg3ZI98 vLYwUbW2es3WZYKVl4H2zMcAQHKgfmPov2puMyyq9m9HvFkF5541ybhAtpbMJMpGzByd Gl5JZx5iSKlLkNn4SK1PR4xUN6Qdxv23HSMreAEVb5PidbTPQvKzQ0SQGo2MLuaAqq7O nORDQRs2ySHuOO3IGDnUXjUpxJbY9l1y0Wf/VPGC4UXDkWaN2UqJJTZtCvMVnq82ab9L CcAg== X-Gm-Message-State: AMCzsaW7B+8kMoySEkcSjg1avP55yKQWVmSFtCjDyVkQcTqxlpN6wh4P xmJVsmMmi789zlN9WsBRAsWlvxAS00gQ9mCCM3JVQQ== X-Google-Smtp-Source: ABhQp+Sufinw6P3OVcxE5K3j8+Phho4B4mRn5XmysxirKcmgUzFI1SqsaffraC8FPxupjariCek6Ot3KfAmXHcPSWbU= X-Received: by 10.237.35.58 with SMTP id h55mr6275504qtc.108.1509646065951; Thu, 02 Nov 2017 11:07:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Thu, 2 Nov 2017 11:07:44 -0700 (PDT) In-Reply-To: <8C09CC26-AA68-4E1F-98F4-963B5A53F875@daveor.com> References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <8C09CC26-AA68-4E1F-98F4-963B5A53F875@daveor.com> From: Tom Herbert Date: Thu, 2 Nov 2017 11:07:44 -0700 Message-ID: To: "Dave O'Reilly" Cc: Mark Smith , Ole Troan , v6ops list , Tore Anderson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 18:07:49 -0000 On Thu, Nov 2, 2017 at 10:12 AM, Dave O'Reilly wrote: > Tom, I have a question. > > You say: > >>> >> Mark, >> >> I think the point is that for privacy we _don't_ want IP addresses to >> identify individuals, but it is work to ensure that they don't. The >> fact that a device can be shared makes the coupling weaker, but >> probably not weak enough to be considered good privacy unless the >> population sharing the device is large enough to avoid statistical >> inference. >> > > I never understood this to be a design consideration of IPv4 (I don=E2=80= =99t know about IPv6 but perhaps others could enlighten me?). In either cas= e, is it the case that =E2=80=9Cwe don=E2=80=99t want IP addresses to ident= ify individuals=E2=80=9D? Is it not more the case that the evolution of tec= hnologies on the Internet has, as a side effect, meant that IP addresses do= n=E2=80=99t identify individuals? Dave, It wasn't and isn't a design consideration of IPv4. However, it seems to be an accidental side effect of NAT. With a large population of NAT users behind a NAT address there is a strong decoupling between an address and the device or individual associated with the device as viewed externally. That can be contrasted with some of the addressing concepts of IPv6 which entailed used stable identifiers based on a permanent MAC address. In the absence of any mechanisms like NAT that obfuscate addresses, addresses with stable identifiers allow unrelated flows to be correlated to have come from the same source device. When the device is a personal device, then the address can then be correlated to an individual with some degree of accuracy that they are the user. This issue is addressed in RFC4941 which randomizes interface identifiers. RFC4941 allows an IPv6 address to be changed with some frequency, but isn't really intended to give a different source address per flow like NAT effectively does. > > > >>> There really needs to be something else that supports or proves use of = a >>> device other than an assumption that an IP address is tightly coupled t= o a >>> device's owner, and therefore all actions associated with an IP address= are >>> thoe se of the device's owner. >> >> I believe there is. It is common for apps, like email, social >> networking, etc. to login to a service with username and password. >> When login is done, the service now has a mapping of an individual to >> an IP address. That mapping could then be exploited to identify the >> same individual in completely unrelated communications, hence breaking >> privacy. This could be done external to the device and the network >> provider and across different jurisdictions. The problem is >> exacerbated if the app is always connected so that whenever the >> devices gets a new IP address to user mapping maintained by some third >> party is kept up to date. Also, in this case, randomizing addresses at >> some frequency may no provide much benefit to privacy unless every >> connection gets a different source address (which is effectively is >> what CGNAT gives). >> > > You don=E2=80=99t even need to log in to anything - isn=E2=80=99t this ex= actly how doubleclick et-al work? They drop a cookie on your browser and th= en follow you around the Internet on all sites with double-click banners? > IIRC (I spent some time working in ads), cookies aren't used that way any more since it's an obvious violation of privacy. There is need for remarketing and cross device advertising, but the correlations can be made within double-click system and not exposed to just any advertiser. Companies such as Google obviously collect a lot of PII, and it's clear that they have obligation and got to great pains to protect it (grant it Equifax and others seem to be glaring failures in protecting PII). > Same problem for any application layer identifying information - but also= a bit beyond the scope of the CGNAT discussion... > Right, but similar to security, if we want to build a system that has good privacy characteristics then privacy at every layer, even networking layer, should be considered. Tom From nobody Thu Nov 2 14:02:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B090813F95E for ; Thu, 2 Nov 2017 14:02:28 -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 27WyXi-gczi9 for ; Thu, 2 Nov 2017 14:02:27 -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 4213C13F682 for ; Thu, 2 Nov 2017 14:02:27 -0700 (PDT) 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 196962D5003; Thu, 2 Nov 2017 21:02:26 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 8AEED200943FC0; Thu, 2 Nov 2017 22:02:24 +0100 (CET) From: Ole Troan Message-Id: <1814ADDF-C2FD-4877-A646-36DD959F8B1B@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_F651F3B6-9396-4F56-8D67-08017070EBC6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Date: Thu, 2 Nov 2017 22:02:23 +0100 In-Reply-To: Cc: Warren Kumari , "v6ops@ietf.org" , Tore Anderson To: Dave O'Reilly References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3445.1.7) Archived-At: Subject: Re: [v6ops] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 21:02:29 -0000 --Apple-Mail=_F651F3B6-9396-4F56-8D67-08017070EBC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dave, > Totally agree. As I mentioned in the email that I just wrote, even if = the IP address identifies a device that is no indication of who was in = control of that device at a particular time. Don=E2=80=99t forget that = there are other possibilities, for example, that the device may have = been remote controlled by e.g. malware - I think this point would be = pretty well understood in the law enforcement community but I will = review the draft and clarify this point if necessary. Thanks that would be appreciated. It doesn't appear to be equally well understood in e.g. the copyright = industry, so it is worth making this point very clear. Best regards, Ole --Apple-Mail=_F651F3B6-9396-4F56-8D67-08017070EBC6 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+/bDNdvtpYqJhC33YFAln7h98ACgkQvtpYqJhC 33Y3hA/+LQpZsPjZ9MLwt/0P2E4RzkEEKFMkkVcaiwZ01sLdnRTAnHAmJGtoXCYv A1zkvUSuit4XpPVyJpW4KQ4xh2TTOr2TttzkuNsl238IAV7nbaLrOsI6OywhiMbb iZJUl5dtRL+mrrCxlaOtdU5DadgV4v6UmEugU/ph1A8gCNbCQCW6QT0/4jfUBOG6 9xehXVcrX4XQjnPwdkEU197l6nG3FiN5dUF6Qb5umPUeEYZJ7RZ9sD2ZDEmD+uz2 wCDvOsoxLFgvVM/k7kXlAVlDXcsemZjFucY+m7JCa/zK/gU74Uf257sxQyKkhAaz /wEtTRoDwlHOd0ZrCPfOFAQtALHLWUQ60a6679liui6a4I+nRnQ7kY+t1xiD7wpC sU6nTsItk6P3fIEe/pNAUrEKg7TWjneFYX0s2vSrkFCYddyQVT4lS68OKvHHC4yE 3z1YVmJH/vZlKgXjISEf9YTqMr4prkBTr8KJz4DJd38T2rb1Fu/P9xRRRjlz7OSY mnwrGRITaIpixTRaEqonB95BOQMCQIENS3mWSBQBo+VKOI+IZSc++vIgF6JxpKJN Q3sai1XGyYZ1x5RD9BdjHU3MFjvOOFzgwkXxaRMZ/SyxzElvE8+EoGqRPhZprbUr ERc4Eb0cmhfVkcYm2aDQI3oz4v8rdgOYmFmBCJ9w+K4VlJECQcM= =5dNC -----END PGP SIGNATURE----- --Apple-Mail=_F651F3B6-9396-4F56-8D67-08017070EBC6-- From nobody Thu Nov 2 14:07:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C7213F95E for ; Thu, 2 Nov 2017 14:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tahz9YG2mtf9 for ; Thu, 2 Nov 2017 14:07:20 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 9ED4813F682 for ; Thu, 2 Nov 2017 14:07:20 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id j2so579944vki.4 for ; Thu, 02 Nov 2017 14:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tGKcelLpluesqfo+cEMd3ID5VC9PGvSJXiMRbjTJxGc=; b=d8+s4P+mNv3qCj+KZWzHDp3g/kN7zJhpXrtRcRKQGxOpgOU8uAKqq/FTQDVWtFWFYX EEVkBwnnZ8VAjY2kfTLnJWxWHAqq83fDegyuSD3CYkS1L9Gg8S/HAZzeJZ0CcplUbFBn cHAZPzp9nhsbWEV2G4Ka60O9DmB1ti2vy37Cxvbl8zzpWtGwqLTpNnVKWYYGgnPzoSts t44OZnidN3oMWfxStGkCf+K+ITk914fCqZDHnKphy3stJpR3VEWU7QiRY9Gzn0Y5qz0j gco95F8shBsvVj6oYBVhhrjxt65oz0lJsLgCZ+nIceCrxVNSZFnrAXRO2aI+dg6vlqyN IhlQ== 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=tGKcelLpluesqfo+cEMd3ID5VC9PGvSJXiMRbjTJxGc=; b=WS/PV9jAhhnWyjmHBaIsVY1eG4tPiRBPJ4eDEXZmkLCWS6Ef7V9W/Ur2DQVXv5U9jX 4PXUb2Ja4pIuXLX6bH0N8uOtGZ/QohTvyczrcET/lk1Ab11shEsVV6s0qBquzVt3ZL8I 2HBUH3G8t+lEpEX1TlyvU5vXxTldCsuIt8Yy0gcREvQjJbh6qhH7M5V1YusmUs4AyLdG dTPBr5o23GrG+f7WOVCY4LycfHjlXakoI8pzDu1NV6bmcOOZMevN+ialDB0CChPSI7pV 97W3+QF2N/28mWE2hSYUT3rJo4EewfMx4+eyUBphVPTPgtqmSAiNbet7rkjKizTFPHQs W0vg== X-Gm-Message-State: AMCzsaW906PtNCPS3gDG5gzYIahYvXrA7hMtaK1i/HA6Z5AG8LOrFxrU dVhLKOXQ12XaoO1ludmX8WIiXTIa3gGdrtaYW3Q= X-Google-Smtp-Source: ABhQp+QdXRf5Afy1QG+Ldz0YiOIA/a8/ik/An+yOEXeFWeUWoxtCrG7GFOsgPpHHwVusK9SmBv2/c9UB9vfnSZ9WHU8= X-Received: by 10.31.165.214 with SMTP id o205mr3898457vke.147.1509656839651; Thu, 02 Nov 2017 14:07:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Thu, 2 Nov 2017 14:07:18 -0700 (PDT) Received: by 10.159.52.221 with HTTP; Thu, 2 Nov 2017 14:07:18 -0700 (PDT) In-Reply-To: References: <20395E98-DA55-447F-BEFE-CB581A88BB78@gmail.com> <20171019083506.6627a166@echo.ms.redpill-linpro.com> <787AE7BB302AE849A7480A190F8B93300A056EB5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22C655A9-AE02-4885-98B5-7515C49E7F2B@employees.org> <95274753-7241-47DE-B463-0341248FAE38@employees.org> <5FA44821-D6C2-4A9C-A1A5-59BECB65B4F4@gmail.com> <1A0AE76A-FA3C-4BDE-B8D9-C8D2E060A8A8@gmail.com> <81B18C7D-76F7-40BC-8252-D833DDF95254@daveor.com> From: Mark Smith Date: Fri, 3 Nov 2017 08:07:18 +1100 Message-ID: To: "Dave O'Reilly" Cc: Fred Baker , Tore Anderson , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a11415eeea90758055d065fe9" Archived-At: Subject: Re: [v6ops] [SUSPECTED SPAM] Google Alert - IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 21:07:22 -0000 --001a11415eeea90758055d065fe9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 3 Nov. 2017 3:56 am, "Dave O'Reilly" wrote: Totally agree with your assessment of the value of IP data - it cannot alone be used to identify an individual, and I don=E2=80=99t think you=E2= =80=99d find many law enforcement officers anywhere who would disagree with that assessment. As I mentioned in the email I just wrote, even if the IP address identifies a specific device/endpoint (which it almost always doesn=E2=80=99t) that in= no way attributes the activity of that device to a specific individual. HOWEVER: taken in the broader context of an investigation, IP address can play an important role in either pointing the investigation in a particular direction or corroborating evidence gathered from other sources. I doubt anybody here disagrees with that. The concern I have is that LEAs adopt a view that because address sharing is not necessary in IPv6, an IPv6 address becomes believed to be indisputable and absolute evidence that a particular individual who owns the device assigned that IPv6 address is the person responsible for all actions committed using that IPv6 address. I think the fundamental human desire for doing the least possible and making your evidence collecting job as easy as clicking a mouse button a few times makes that a risk. Regards, Mark. daveor > On 30 Oct 2017, at 02:41, Fred Baker wrote: > > > >> On Oct 29, 2017, at 11:48 PM, Mark Smith wrote: >> >> Geoff Huston's article on >> >> Metadata Retention and the Internet >> >> https://telsoc.org/ajtde/2015-04-v3-n1/a4 >> >> might be of interest. >> >> "The Metadata Retention measures being considered in Australia make some sweeping assumptions about the semantics of IP addresses and their association with individual subscribers to the Internet. But are these assumptions warranted?" > > In that context, the European Data Retention Directive (which has now been struck down by the European Privacy Court) and the activities by the "Five Eyes" in that regard, notably the US NSA, have been very much about metadata. I asked a Dutch agency representative once what their reason for lawful intercept in general and metadata capture specifically was, and he indicated "mapping criminal networks". They wanted to determine who spoke with whom, with a view to identifying members of a community, presumably an evil community. > > I note that the European Privacy Court has (apparently) specified that an IP address is "Individually Identifiable Information", the kind of thing that might be discussed in https://tools.ietf.org/html/rfc7721. I have asked repeatedly what privacy folks think might be an IID below the application layer, and that is the one thing they have come up with. On the point, I would argue that data of that type is not *identification*, but it might be possible to correlate it with other information due to operational practice. To my mind, stomping out correlations is a game of whack-a-mole; someone that desperately wants to find a correlation will probably find something that mostly works for their purposes, even if they have to discard spurious correlations to do so. In my view, that's what we see here: we might be able to correlate an IP address with a computer or subscriber, but we can't stop people in a business or family from using each other's computers. It is at best an investigative tool, not proof of something in particular. --001a11415eeea90758055d065fe9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 3 Nov. 2017 3:56 am, "Dave O'Reilly" <rfc@daveor.com> wrote:
Totally agree with your assessment of the va= lue of IP data - it cannot alone be used to identify an individual, and I d= on=E2=80=99t think you=E2=80=99d find many law enforcement officers anywher= e who would disagree with that assessment. As I mentioned in the email I ju= st wrote, even if the IP address identifies a specific device/endpoint (whi= ch it almost always doesn=E2=80=99t) that in no way attributes the activity= of that device to a specific individual.

HOWEVER: taken in the broader context of an investigation, IP address can p= lay an important role in either pointing the investigation in a particular = direction or corroborating evidence gathered from other sources.

I dou= bt anybody here disagrees with that.

The concern I have is that LEAs adopt a view that because addr= ess sharing is not necessary in IPv6, an IPv6 address becomes believed to b= e indisputable and absolute evidence that a particular individual who owns = the device assigned that IPv6 address is the person responsible for all act= ions committed using that IPv6 address. I think the fundamental human desir= e for doing the least possible and making your evidence collecting job as e= asy as clicking a mouse button a few times makes that a risk.

Regards,
Mark.=


daveor


> On 30 Oct 2017, at 02:41, Fred Baker <fredbaker.ietf@gmail.com> wrote:
>
>
>
>> On Oct 29, 2017, at 11:48 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
>>
>> Geoff Huston's article on
>>
>> Metadata Retention and the Internet
>>
>> https://telsoc.org/ajtde/2015-04-v3-n1/a4=
>>
>> might be of interest.
>>
>> "The Metadata Retention measures being considered in Australi= a make some sweeping assumptions about the semantics of IP addresses and th= eir association with individual subscribers to the Internet. But are these = assumptions warranted?"
>
> In that context, the European Data Retention Directive (which has now = been struck down by the European Privacy Court) and the activities by the &= quot;Five Eyes" in that regard, notably the US NSA, have been very muc= h about metadata. I asked a Dutch agency representative once what their rea= son for lawful intercept in general and metadata capture specifically was, = and he indicated "mapping criminal networks". They wanted to dete= rmine who spoke with whom, with a view to identifying members of a communit= y, presumably an evil community.
>
> I note that the European Privacy Court has (apparently) specified that= an IP address is "Individually Identifiable Information", the ki= nd of thing that might be discussed in https://tools.ietf.org/htm= l/rfc7721. I have asked repeatedly what privacy folks think might = be an IID below the application layer, and that is the one thing they have = come up with. On the point, I would argue that data of that type is not *id= entification*, but it might be possible to correlate it with other informat= ion due to operational practice. To my mind, stomping out correlations is a= game of whack-a-mole; someone that desperately wants to find a correlation= will probably find something that mostly works for their purposes, even if= they have to discard spurious correlations to do so. In my view, that'= s what we see here: we might be able to correlate an IP address with a comp= uter or subscriber, but we can't stop people in a business or family fr= om using each other's computers. It is at best an investigative tool, n= ot proof of something in particular.


--001a11415eeea90758055d065fe9-- From nobody Thu Nov 2 23:17:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56EC13FC23 for ; Thu, 2 Nov 2017 23:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqA-U42t2pzu for ; Thu, 2 Nov 2017 23:17:11 -0700 (PDT) Received: from correo.unam.mx (smtp2.unam.mx [132.248.10.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49EE613FB9A for ; Thu, 2 Nov 2017 23:17:11 -0700 (PDT) Received: from pine.servidores.unam.mx (132.248.10.10) by MAILBOX01.unam.local (172.16.2.63) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 3 Nov 2017 00:29:42 -0600 Date: Fri, 3 Nov 2017 00:17:09 -0600 From: Azael Fernandez Alcantara X-X-Sender: afaza@pine.servidores.unam.mx To: Jordi Palet Martinez CC: "" In-Reply-To: Message-ID: References: <150824269847.21561.8932178346065454678.idtracker@ietfa.amsl.com> <44FD0037-CAFC-401B-A9E4-A976CB2A35F7@consulintel.es> <389AFC32-C6D5-4075-8617-E88CDF86CB01@consulintel.es> <3E196E02-87F9-4140-BE9C-5B21F69EE7E1@gmail.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-125564406-297086666-1509689727=:4739" Content-ID: X-Originating-IP: [132.248.10.10] X-ClientProxiedBy: CAS01.unam.local (172.16.2.28) To MAILBOX01.unam.local (172.16.2.63) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 06:17:14 -0000 ---125564406-297086666-1509689727=:4739 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: Hi all, I also agree to include the other mentioned IPv4-only definitions that would help at the same the time to clarify the IPv6-only definitions. But in this were the case, maybe it would be better to change the title of the draft with something like "IPv6-only / IPv4-only Terminology Definitions" , in order not to have a second draft with a title "IPv4-only Terminology Definition" that would not be good to have it in a separate document. BEST, SALUDOS, _______ Azael On Wed, 1 Nov 2017, JORDI PALET MARTINEZ wrote: > When I was updating this document from v02 to v03, I was considering including the definition of IPv4-only. > > However, being the document a terminology about IPv6-only, I decided > that including IPv4-only doesn’t make too much sense and can be inferred > from the IPv6-only definition and the rest of terms in the document. > > In fact, if we agree to include it, I think it will be something like the same as we have for IPv6-only, so: > - IPv4-only network > - IPv4-only WAN/access > - IPv4-only LAN > - IPv4-only host/router > - Transitional IPv4 host/router > > Yes, I know, I can just define IPv6-only “*” (wildcard), and IPv4-only > *, and make a 1 page ID. But not being more specific is the problem I’m > trying to resolve: the lack of clarity when we speak about this. > > Thoughts? > > Regards, > Jordi > > > -----Mensaje original----- > De: George Michaelson > Responder a: > Fecha: miércoles, 18 de octubre de 2017, 0:24 > Para: Fred Baker > CC: JORDI PALET MARTINEZ , "" > Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-02.txt > > Not that anyone doesn't understand this, but a 'network' could quite > possibly "not support" IPv4 and still have IPv4 packets on it. So, you > can expect to see ARP. you can expect to see DHCP requests. You can > even see half-open TCP. > > Diagnostically, the state of being 'IPv6 only' doesn't mean there is > no IPv4 packet types on the wire. it just means they aren't being > supported, carried forward, responded to by deliberate deployment > choices. No router is being proffered, no DNS service is being > proferred. > > But if somebody turns up an IPv4 DHCP server, responds to ARP, and > offers a default route, You are not necessarily blocking them. > > An IPv4 *blocked* network would be one, which uses lower level (layer > 2) switch or other methods to refuse to forward frames which carry > IPv4 and associated (ARP) traffic. > > Thats different. > > -G > > On Wed, Oct 18, 2017 at 4:06 AM, Fred Baker wrote: > > > > > >> On Oct 17, 2017, at 10:43 AM, JORDI PALET MARTINEZ wrote: > >> > >> - I think a short "Definition of IPv4-only" would be useful to include. > > > > A little rumination in context. Hats off. > > > > To me, an IPv4-only thing is a thing that can only communicate using IPv4. That would be true of an IPv4-only host, an IPv4-only LAN, or an IPv4-only network. In each case, there is a question of perspective: if an ISP only offers a subscriber IPv4 addresses or prefixes, then the subscriber is IPv4-only from the ISP's perspective, even though it might be using something else internally or when communicating via some other connectivity. If we are speaking from the perspective of the host itself, it might mean that it is perfectly capable of communicating using something else, but it has only been provisioned with an IPv4 address, or it can communicate with peers on its LAN using something else, but the router is IPv4-only, and so when it communicates with devices beyond the router (or they try to communicate with it), IPv4 is the only thing that works. > > > > So, suggested text: > > > > IPv4-only: only capable of or provisioned to communicate using IPv4. The description is always from a perspective, whether the perspective of a host or network seeking to communicate, or that of another host or network describing a communication peer. > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops ---125564406-297086666-1509689727=:4739-- From nobody Fri Nov 3 00:14:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4030613FCA8 for ; Fri, 3 Nov 2017 00:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJHVmfBFU2ib for ; Fri, 3 Nov 2017 00:13:55 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5417D13FBBB for ; Fri, 3 Nov 2017 00:13:55 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id j15so1645403wre.8 for ; Fri, 03 Nov 2017 00:13:55 -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=K2Slbj3fG/IxugI0VXeDPd7ZLWHaR+c+fIzX/I8HH4I=; b=BcRzMFYQDeipm2969KwRGvHJ51Gwb3kO08dFwwTs3m0ctT/SiPdnD35MdnNhknnpZ6 n1X7IUdcTHCjRgDadnmRR9W6rcxaXUd4VzfRtHhsavXUSOUk1UzK889Q0OOUKxLyZIbC 0DwM/0e1IS7xEaJPP8fwWGP7F+cgTuGnp7tFcZ/SeY3UXKIEJMnO0oTrR3CYqWbNkggX XLL4HVS4HDNkcOQpt3SyRWn19yyHcHXi/iUCMQQ7e1FYCw++Ok+rXq5sR3NchfNMmytf dmgiQ39H/zFcJYq4p/tc/UkqfJy46/A/9HbRhFSpDKoNlSdxs/v3slmHT56qLv5CSPLq +YuA== 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=K2Slbj3fG/IxugI0VXeDPd7ZLWHaR+c+fIzX/I8HH4I=; b=gJokCOrurs/09CTDl9yJCfqEx82w4sbOi8g0BFo1Wh/ck1qQurY66imj2EyqPL4EpR oJCtbRt2lJfDFlcfDDZHkANKMcLajX76P3dpx8Mqkdi4/QCMcvXD1eMZ3n3BwqxTITas hUFLE0f8Sak4QXLNAkosvWmN8Im7SW1LZ0zoD/Xe3QQX+9RohEG4m/wjoHPxgBHUybtU sIVvfzQVXovkcDk3z0SFRxEdzeMqnvHmmJeDuNMwK471UELJrjPoe4z0+M7KaPakuNiH 23PTzZ0DcGtcbxCvjkFzL0OTLZLiWxVNbe/jn4R4qZY9l9bv8GgG6h7JR8ZDYYqYJ8mw TCcQ== X-Gm-Message-State: AMCzsaVyzP9AAFKwuI51m74eZL3tkO3bQOBPsi7bcAbbGaPy8F7gB1aU ks7uxVCEdTCFBslCipUgPhc= X-Google-Smtp-Source: ABhQp+SomJkw9RbDTQaoSJgkRrERhc1ucrZuP6zlNnjQY4LAQn40m2s+KPuPqWWkReqnKt7eJ/PUCQ== X-Received: by 10.223.134.106 with SMTP id 39mr4773632wrw.134.1509693233730; Fri, 03 Nov 2017 00:13:53 -0700 (PDT) Received: from 136.66.20.149.in-addr.arpa (136.66.20.149.in-addr.arpa. [149.20.66.136]) by smtp.gmail.com with ESMTPSA id l15sm5321346wrb.45.2017.11.03.00.13.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Nov 2017 00:13:52 -0700 (PDT) From: Fred Baker Message-Id: <2B6BE39F-6DD7-4A01-B725-D2326FA76632@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A0B6F631-A946-4D38-B22F-31CB750999FD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.11\)) Date: Fri, 3 Nov 2017 11:13:45 +0400 In-Reply-To: Cc: "" To: JORDI PALET MARTINEZ References: <150824269847.21561.8932178346065454678.idtracker@ietfa.amsl.com> <44FD0037-CAFC-401B-A9E4-A976CB2A35F7@consulintel.es> <389AFC32-C6D5-4075-8617-E88CDF86CB01@consulintel.es> <3E196E02-87F9-4140-BE9C-5B21F69EE7E1@gmail.com> X-Mailer: Apple Mail (2.3445.5.11) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 07:13:59 -0000 --Apple-Mail=_A0B6F631-A946-4D38-B22F-31CB750999FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hats off... =46rom my perspective, whether something is mumble-only is a statement = made about it by another party, asserting that they can only communicate = with it using mumble (and BTW, personally I would define = {IPv4|IPv6}-only, not IPv4-only and separately IPv6-only). I don't = generally know why I can only communicate with something using a given = protocol, only that it is the case. For example, www.ipv6.example.com is = an IPv6-only service if it has a AAAA record and not an A record, even = if the computer in question has an IPv4 address. It is indistinguishable = from a system that has only an IPv6 address from the perspective of an = observer. In general, it is difficult to enforce the policy that a = network be {IPv4|IPv6}-only, because the hosts in it can generate = {IPv6|IPv4} link-local addresses and communicate using them. I could = imagine a network administrator asserting that his or her network is = mumble-only by policy, only to discover hosts communicating within it = using protocols the sysadmin didn't intend. > On Nov 1, 2017, at 4:01 PM, JORDI PALET MARTINEZ = wrote: >=20 > When I was updating this document from v02 to v03, I was considering = including the definition of IPv4-only. >=20 > However, being the document a terminology about IPv6-only, I decided = that including IPv4-only doesn=E2=80=99t make too much sense and can be = inferred from the IPv6-only definition and the rest of terms in the = document. >=20 > In fact, if we agree to include it, I think it will be something like = the same as we have for IPv6-only, so: > - IPv4-only network > - IPv4-only WAN/access > - IPv4-only LAN > - IPv4-only host/router > - Transitional IPv4 host/router >=20 > Yes, I know, I can just define IPv6-only =E2=80=9C*=E2=80=9D = (wildcard), and IPv4-only *, and make a 1 page ID. But not being more = specific is the problem I=E2=80=99m trying to resolve: the lack of = clarity when we speak about this. >=20 > Thoughts? >=20 > Regards, > Jordi >=20 >=20 > -----Mensaje original----- > De: George Michaelson > Responder a: > Fecha: mi=C3=A9rcoles, 18 de octubre de 2017, 0:24 > Para: Fred Baker > CC: JORDI PALET MARTINEZ , = "" > Asunto: Re: [v6ops] New Version Notification for = draft-palet-v6ops-ipv6-only-02.txt >=20 > Not that anyone doesn't understand this, but a 'network' could = quite > possibly "not support" IPv4 and still have IPv4 packets on it. So, = you > can expect to see ARP. you can expect to see DHCP requests. You can > even see half-open TCP. >=20 > Diagnostically, the state of being 'IPv6 only' doesn't mean there = is > no IPv4 packet types on the wire. it just means they aren't being > supported, carried forward, responded to by deliberate deployment > choices. No router is being proffered, no DNS service is being > proferred. >=20 > But if somebody turns up an IPv4 DHCP server, responds to ARP, and > offers a default route, You are not necessarily blocking them. >=20 > An IPv4 *blocked* network would be one, which uses lower level = (layer > 2) switch or other methods to refuse to forward frames which carry > IPv4 and associated (ARP) traffic. >=20 > Thats different. >=20 > -G >=20 > On Wed, Oct 18, 2017 at 4:06 AM, Fred Baker = wrote: >>=20 >>=20 >>> On Oct 17, 2017, at 10:43 AM, JORDI PALET MARTINEZ = wrote: >>>=20 >>> - I think a short "Definition of IPv4-only" would be useful to = include. >>=20 >> A little rumination in context. Hats off. >>=20 >> To me, an IPv4-only thing is a thing that can only communicate using = IPv4. That would be true of an IPv4-only host, an IPv4-only LAN, or an = IPv4-only network. In each case, there is a question of perspective: if = an ISP only offers a subscriber IPv4 addresses or prefixes, then the = subscriber is IPv4-only from the ISP's perspective, even though it might = be using something else internally or when communicating via some other = connectivity. If we are speaking from the perspective of the host = itself, it might mean that it is perfectly capable of communicating = using something else, but it has only been provisioned with an IPv4 = address, or it can communicate with peers on its LAN using something = else, but the router is IPv4-only, and so when it communicates with = devices beyond the router (or they try to communicate with it), IPv4 is = the only thing that works. >>=20 >> So, suggested text: >>=20 >> IPv4-only: only capable of or provisioned to communicate using IPv4. = The description is always from a perspective, whether the perspective of = a host or network seeking to communicate, or that of another host or = network describing a communication peer. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_A0B6F631-A946-4D38-B22F-31CB750999FD 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+AFAln8FykACgkQEhdRnd2G P+BtXQ//fQYFoJ/QyxKTszdLh1F/iWeDB+5iz7Pbzr0qMCd5fYlLsIxN5MWCQz6F zu6hVo4EHNvonTJQ+nWX4md1r07rT0ZCSiknUfR6PsQYQt3TORfFKKaj61xsF3Il lOqlRrfzHy+nYNofbWTSi7PnCecRsLZLFsW2Yw6KmeUDMBK5REmtpOG9Min+hFJN XVYkVU8nvQ3VfJ3wOj6ao65xBuZ5VUVzhlwy7lVFheqhoPLqj258pGUqa2NfL/Y2 1R+u/fwcgJmnDUmEMFXmPxKMieumb1XUJlaQp59UxZaNp8OG+UJ8SjIhrK0/GJcH O8JIYuwbsM5AOiC+s8cFZompLW2Z2pgwT0F5UhBPpR5wYHAZUxbjl4LTfqSdQ88z /cgzSmk/XrV32vH5zSkX4iTNDdnZvglW+HLaB/vlvsBDoR6GWJg+MONWEQP20Qsv uPF//dp4wvXaqswxuC8ODal2eaOsaqOqcvP7sxK5ZlZH8UqoybY9kUu+6C5Ity+Y X4Pi020Z5Jxqt/XbYRxrQrgro3ugiGUehuqLSXP2JOSYhL2PdKmgGgRiMCPYPKjM bflmja9R/YEz+8ptySbs3OYO9pxaeBzlw4WJYFgCjbXPwShZoXtoBQILA0jJb/TK ela4XGFObu/ok5aax3rlO589wYOtkJqOBTuieaNAHJBs4f6CsbM= =Owwa -----END PGP SIGNATURE----- --Apple-Mail=_A0B6F631-A946-4D38-B22F-31CB750999FD-- From nobody Fri Nov 3 07:51:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DEB13FDCD for ; Fri, 3 Nov 2017 07:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFjfTYXLqChY for ; Fri, 3 Nov 2017 07:51:42 -0700 (PDT) Received: from atl4mhob01.registeredsite.com (atl4mhob01.registeredsite.com [209.17.115.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1A313FDC5 for ; Fri, 3 Nov 2017 07:51:42 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob01.registeredsite.com (8.14.4/8.14.4) with ESMTP id vA3Epc3B018537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 3 Nov 2017 10:51:38 -0400 Received: (qmail 16300 invoked by uid 0); 3 Nov 2017 14:51:38 -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; 3 Nov 2017 14:51:38 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Fri, 03 Nov 2017 10:51:35 -0400 From: Lee Howard To: Fred Baker , JORDI PALET MARTINEZ CC: "" Message-ID: Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-02.txt References: <150824269847.21561.8932178346065454678.idtracker@ietfa.amsl.com> <44FD0037-CAFC-401B-A9E4-A976CB2A35F7@consulintel.es> <389AFC32-C6D5-4075-8617-E88CDF86CB01@consulintel.es> <3E196E02-87F9-4140-BE9C-5B21F69EE7E1@gmail.com> <2B6BE39F-6DD7-4A01-B725-D2326FA76632@gmail.com> In-Reply-To: <2B6BE39F-6DD7-4A01-B725-D2326FA76632@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 14:51:44 -0000 On 11/3/17, 3:13 AM, "v6ops on behalf of Fred Baker" wrote: >Hats off... Similarly unhatted. > >From my perspective, whether something is mumble-only is a statement made >about it by another party, asserting that they can only communicate with >it using mumble (and BTW, personally I would define {IPv4|IPv6}-only, not >IPv4-only and separately IPv6-only). As a principle, that makes sense to me. But when I dig into it, I can=E2=80=99t support it. If you have no IP route to me, that doesn=E2=80=99t mean I don=E2=80=99t support IP. If I only have IPv6 on all interfaces, and you only have IPv4 on all interfaces, but you can reach me over IPv4 through some transition mechanism, does that mean that you no longer fit the description of IPv4-only and I am not IPv6-only? If you can reach some hosts via transition mechanisms provided by their ISP or network operator (etc.), but you can=E2=80=99t reach other hosts that only have IPv6 because there is no transition mechanism, how would we describe you?=20 >I don't generally know why I can only communicate with something using a >given protocol, only that it is the case. For example, >www.ipv6.example.com is an IPv6-only service if it has a AAAA record and >not an A record, even if the computer in question has an IPv4 address. It >is indistinguishable from a system that has only an IPv6 address from the >perspective of an observer. In general, it is difficult to enforce the >policy that a network be {IPv4|IPv6}-only, because the hosts in it can >generate {IPv6|IPv4} link-local addresses and communicate using them. I >could imagine a network administrator asserting that his or her network >is mumble-only by policy, only to discover hosts communicating within it >using protocols the sysadmin didn't intend. There=E2=80=99s a difference between a descriptive definition and a prescriptive definition. We can assert that =E2=80=9CIPv4-only host=E2=80=9D is a description of a device that only has IPv4 addresses configured on it, and that description can be used until someone discovers that the device has IPv6 link-local addresses. That doesn=E2=80=99t mean the description is wrong, just that it turns out not to apply. Lee > >> On Nov 1, 2017, at 4:01 PM, JORDI PALET MARTINEZ >> wrote: >>=20 >> When I was updating this document from v02 to v03, I was considering >>including the definition of IPv4-only. >>=20 >> However, being the document a terminology about IPv6-only, I decided >>that including IPv4-only doesn=E2=80=99t make too much sense and can be inferre= d >>from the IPv6-only definition and the rest of terms in the document. >>=20 >> In fact, if we agree to include it, I think it will be something like >>the same as we have for IPv6-only, so: >> - IPv4-only network >> - IPv4-only WAN/access >> - IPv4-only LAN >> - IPv4-only host/router >> - Transitional IPv4 host/router >>=20 >> Yes, I know, I can just define IPv6-only =E2=80=9C*=E2=80=9D (wildcard), and IPv4-on= ly >>*, and make a 1 page ID. But not being more specific is the problem I=E2=80=99m >>trying to resolve: the lack of clarity when we speak about this. >>=20 >> Thoughts? >>=20 >> Regards, >> Jordi >>=20 >>=20 >> -----Mensaje original----- >> De: George Michaelson >> Responder a: >> Fecha: mi=C3=A9rcoles, 18 de octubre de 2017, 0:24 >> Para: Fred Baker >> CC: JORDI PALET MARTINEZ , >>"" >> Asunto: Re: [v6ops] New Version Notification for >>draft-palet-v6ops-ipv6-only-02.txt >>=20 >> Not that anyone doesn't understand this, but a 'network' could quite >> possibly "not support" IPv4 and still have IPv4 packets on it. So, >>you >> can expect to see ARP. you can expect to see DHCP requests. You can >> even see half-open TCP. >>=20 >> Diagnostically, the state of being 'IPv6 only' doesn't mean there is >> no IPv4 packet types on the wire. it just means they aren't being >> supported, carried forward, responded to by deliberate deployment >> choices. No router is being proffered, no DNS service is being >> proferred. >>=20 >> But if somebody turns up an IPv4 DHCP server, responds to ARP, and >> offers a default route, You are not necessarily blocking them. >>=20 >> An IPv4 *blocked* network would be one, which uses lower level (layer >> 2) switch or other methods to refuse to forward frames which carry >> IPv4 and associated (ARP) traffic. >>=20 >> Thats different. >>=20 >> -G >>=20 >> On Wed, Oct 18, 2017 at 4:06 AM, Fred Baker >> wrote: >>>=20 >>>=20 >>>> On Oct 17, 2017, at 10:43 AM, JORDI PALET MARTINEZ >>>> wrote: >>>>=20 >>>> - I think a short "Definition of IPv4-only" would be useful to >>>>include. >>>=20 >>> A little rumination in context. Hats off. >>>=20 >>> To me, an IPv4-only thing is a thing that can only communicate using >>>IPv4. That would be true of an IPv4-only host, an IPv4-only LAN, or an >>>IPv4-only network. In each case, there is a question of perspective: if >>>an ISP only offers a subscriber IPv4 addresses or prefixes, then the >>>subscriber is IPv4-only from the ISP's perspective, even though it >>>might be using something else internally or when communicating via some >>>other connectivity. If we are speaking from the perspective of the host >>>itself, it might mean that it is perfectly capable of communicating >>>using something else, but it has only been provisioned with an IPv4 >>>address, or it can communicate with peers on its LAN using something >>>else, but the router is IPv4-only, and so when it communicates with >>>devices beyond the router (or they try to communicate with it), IPv4 is >>>the only thing that works. >>>=20 >>> So, suggested text: >>>=20 >>> IPv4-only: only capable of or provisioned to communicate using IPv4. >>>The description is always from a perspective, whether the perspective >>>of a host or network seeking to communicate, or that of another host or >>>network describing a communication peer. >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged or >>confidential. The information is intended to be for the exclusive use of >>the individual(s) named above and further non-explicilty authorized >>disclosure, copying, distribution or use of the contents of this >>information, even if partially, including attached files, is strictly >>prohibited and will be considered a criminal offense. If you are not the >>intended recipient be aware that any disclosure, copying, distribution >>or use of the contents of this information, even if partially, including >>attached files, is strictly prohibited, will be considered a criminal >>offense, so you must reply to the original sender to inform about this >>communication and delete it. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Nov 6 08:00:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5B713FC58 for ; Mon, 6 Nov 2017 08:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4XnikKJ81DB for ; Mon, 6 Nov 2017 08:00:01 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0115.outbound.protection.outlook.com [104.47.0.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA2C13F698 for ; Mon, 6 Nov 2017 08:00:00 -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=5jv4jZIdikQNgMVdUVeoKa9VhFIwgSsCUsM61eZhrwM=; b=sj3l1j3N/JaC0WAOtrouVOtwN5hhOKhvQ56eFHK+2hsRoqWeT3W92c6rAPq6Ls1ADdQKTyLzHzcppO/kbnqiYMjKG+tdFnq/agqmWKXp/0WuW348b+nJt0OLc6hOc7wzCp3OUJSGpMGwziRcgFaluYDMzW/UkiADcjXIKeCqsJQ= Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) 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 15:59:58 +0000 Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004%14]) with mapi id 15.20.0218.005; Mon, 6 Nov 2017 15:59:58 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYw Date: Mon, 6 Nov 2017 15:59:58 +0000 Message-ID: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> In-Reply-To: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [141.135.12.190] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2836; 6:0b0oyL5gNhUX/eWZ2oYksuUNjMBk2p/JL2MU0xylAFDoqVdO2MzfIJboC9vRJxoRBfVFVh5OQikYVHpYBKL/Mu9hSvir43EM5UqVCdV4MTs4JdEnFQVSMh3bTi9zAwypxzuarQjGMM7JelyrZY2pNsf/JSyHQpqljp7iz1ZjsdbV8MliT8zf/Srdwt7XOiaOMo7NC4cWrrSG9f+LtIrm9qXh7sn2mU8eFejJqEmifY1cMfE11hxyMAbx2fs6BmSuR4lYPB4E988myDmA435ybpSa2vaMdCb8QF8XRGsq2qsJkokChvxMawwCTRygxbXms6sYyAhNrJt3kZ8+GElbKfhu6O7el7qRt76FVREUnXk=; 5:5dfzToJuPetreinLum4jLsOmOzZzdIcUpy6mtHCGK7xaLb9xqQTP+sGSNjglCTjQHwgTk52xiz1zGbWgnddQg06WPUD5UtrUhVGgoUAyJFfWUZI1nSpQ8+Tc87puEvLvies2EX2BOW/HujujlcaBCTfpJjng/a7whwUnZS5Qho0=; 24:VtgNU4dhhU5LIL4kSCrwUQw2tWHbO0tBsPf5nR/NbHRfwr6+HGRJQR1SR1gNRlht4ubSGxEbAsmuQ8Nc2zOCna69ykIEt3ENjfLt+kYVnOM=; 7:AzYFjl2UwGeqVLToBWjyYhmed/xkSCO7qTjMHebZK0F3tObhiWV8UpeSI4nB6y+eM90uQVdrsdoM6CRYIOccbWyvwniP5Jlf1d13SGQ5v12PfwQ/rrBxem1L1lGuTOrx4m9kR94mU5s+FBUJDr9rdu1Wt7CR88V7vrarMo/xT5zDer95OSczb3Em2Eq3aAGNbTP/yZfctKwkUFC6WVFZsKdswddmna4nuJfOXHd9CdEQgtBlot4LrvaZitWSDfFU x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a49d1885-1da7-4037-3d43-08d5252f6e0a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM5PR0701MB2836; x-ms-traffictypediagnostic: AM5PR0701MB2836: x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597)(43073073696351); 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)(100000703101)(100105400095)(3231021)(6055026)(6041248)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2836; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2836; x-forefront-prvs: 048396AFA0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(377424004)(199003)(189002)(13464003)(6306002)(2473003)(5660300001)(50986999)(9686003)(2950100002)(3280700002)(6916009)(53936002)(86362001)(229853002)(7696004)(2906002)(14454004)(2900100001)(55016002)(76176999)(54356999)(316002)(3660700001)(68736007)(4326008)(99286004)(6436002)(966005)(8936002)(4001150100001)(97736004)(74316002)(53546010)(230783001)(305945005)(66066001)(6506006)(81156014)(8676002)(25786009)(105586002)(478600001)(189998001)(81166006)(2351001)(15650500001)(101416001)(7736002)(5640700003)(33656002)(106356001)(5250100002)(102836003)(3846002)(2501003)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2836; 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: a49d1885-1da7-4037-3d43-08d5252f6e0a X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2017 15:59:58.1554 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2836 Archived-At: Subject: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 16:00:08 -0000 SWYgYW55IGZlZWRiYWNrIG9yIGNvbW1lbnRzIChwcmVmZXJhYmx5IGNvbnN0cnVjdGl2ZSksIHRo ZW4gcGxlYXNlIGhhdmUgdGhlIGRpc2N1c3Npb24gaW5jbHVkaW5nIFNQUklORyBXRyBpbiBjYw0K DQpHLw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFRodXJz ZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDE2OjM1DQpUbzogR2l1c2VwcGUgRmlvY2NvbGEgPGdpdXNl cHBlLmZpb2Njb2xhQHRlbGVjb21pdGFsaWEuaXQ+OyBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9r aWEgLSBCRS9BbnR3ZXJwKSA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+OyBNdWxleSwg UHJhdmVlbiAoTm9raWEgLSBVUy9Nb3VudGFpbiBWaWV3KSA8cHJhdmVlbi5tdWxleUBub2tpYS5j b20+OyBNYXVybyBDb2NpZ2xpbyA8bWF1cm8uY29jaWdsaW9AdGVsZWNvbWl0YWxpYS5pdD4NClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZmlvY2NvbGEtc3ByaW5n LWZsb3ctbGFiZWwtYWx0LW1hcmstMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJrLTAxLnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHaXVzZXBwZSBGaW9jY29sYSBhbmQgcG9zdGVkIHRv IHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1maW9jY29sYS1zcHJpbmctZmxv dy1sYWJlbC1hbHQtbWFyaw0KUmV2aXNpb246CTAxDQpUaXRsZToJCVVzaW5nIHRoZSBJUHY2IEZs b3cgTGFiZWwgZm9yIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IHdpdGggQWx0ZXJuYXRlIE1hcmtp bmcgTWV0aG9kIGluIFNlZ21lbnQgUm91dGluZw0KRG9jdW1lbnQgZGF0ZToJMjAxNy0xMC0yNg0K R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJOA0KVVJMOiAgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1maW9jY29sYS1zcHJp bmctZmxvdy1sYWJlbC1hbHQtbWFyay0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maW9jY29sYS1zcHJpbmctZmxvdy1sYWJlbC1h bHQtbWFyay8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0LW1hcmstMDENCkh0bWxpemVkOiAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWZpb2Njb2xhLXNw cmluZy1mbG93LWxhYmVsLWFsdC1tYXJrLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFs dC1tYXJrLTAxDQoNCkFic3RyYWN0Og0KICAgW1JGQzYyOTRdIG1ha2VzIGEgc3VydmV5IG9mIFBy b3Bvc2VkIFVzZSBDYXNlcyBmb3IgdGhlIElQdjYgRmxvdw0KICAgTGFiZWwuICBUaGUgSVB2NiBw cm90b2NvbCBpbmNsdWRlcyBhIGZsb3cgbGFiZWwgaW4gZXZlcnkgcGFja2V0DQogICBoZWFkZXIs IGJ1dCB0aGlzIGZpZWxkIGlzLCBhY2NvcmRpbmcgdG8gW1JGQzYyOTRdLCBub3QgdXNlZCBpbg0K ICAgcHJhY3RpY2UuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdGhlIGFsdGVybmF0ZSBt YXJraW5nIG1ldGhvZA0KICAgY2FuIGJlIHVzZWQgYXMgdGhlIHBhc3NpdmUgcGVyZm9ybWFuY2Ug bWVhc3VyZW1lbnQgbWV0aG9kIGluIGEgSVB2Ng0KICAgZG9tYWluLg0KDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Nov 6 13:12:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 Mon Nov 6 16:28:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A03313FB62; Mon, 6 Nov 2017 16:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 wDWrs15F-Jt9; Mon, 6 Nov 2017 16:27:57 -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 4DE6413FADA; Mon, 6 Nov 2017 16:27:57 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id i5so8992468pfe.6; Mon, 06 Nov 2017 16:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=asWAZ4qGZ0F2nWXhqLCPAOm199cW9I5P7MYOI1IJqNk=; b=Hbh4P9dVlVRK+rq6Ixo41shvDLP8RdesXwC72OSL8UVq6Hy7fqTXtKYfYJtOVVdSgB 70CppIGbQ0T++A7I/VJojipv5aUtOHScmhSdQUVjzE7Vh2YxHx/AxD+4/GBF4JmBJfuw C/YqSXAWfXmEV+kTNnu+ZXK15jBc5IgrAu/L7sjBb9KIqVLx6/qcpvZB2IZc15KKdP6R BMRNsvrDheTFOqU0MX8UidB9AbFkz4tQlfychu2gvVoXOTiVPg9DzvGubafbfN0u1p2r tBDyA5uZgojvlodfTTC7czdUI1x2RLA5pvlzI5xVP3lger/xmCBVhqfYUazrczVjboGn 2D1A== 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:cc :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=asWAZ4qGZ0F2nWXhqLCPAOm199cW9I5P7MYOI1IJqNk=; b=fW6VHDUlmkUGueWON+X4ksP6Z1RzZd/KpoyJzphjdzhi5QVjggvyMLGn28o93YPp67 IlMVq8pGeLcDEIsX5f9c759+jCu6k93gVUYAlrolo3+u9BlsUkyavnv4u15XY4qFYQr+ MHXQd5LhPtj2yO/zhSI7tOMLgEX9ugO6dPyi8f75E0oSKbmp9+M6C37JyPkASCIsJ/bl A/fY8Q8J+e5S4vA5aaRYn7ShCt52oHAh2BXlcaFNOa93CwaLeUxaKU33ahKUo+/jf39y MUSggK1ncp7WPkHwI6Pg5nwLnALm9vIUu8+inrAmuH6gp00esFOpe19/2ktYI5PBDxjL FdGg== X-Gm-Message-State: AMCzsaUxiauJBuTQ8ShQF3RxvbRFWZE/NQatpupQNoPap7QsZURW8FPE ii5MvNOHT7x9aFUTP8BVXPAhlA== X-Google-Smtp-Source: ABhQp+T7hLaFzujLDSxndHSjEAZvsvokrimx42JYlS22TAmaGLytNbGgkapcxTIsC+6bCIGbat9sSQ== X-Received: by 10.99.116.25 with SMTP id p25mr16966814pgc.327.1510014476548; Mon, 06 Nov 2017 16:27:56 -0800 (PST) Received: from [130.216.38.15] (ggim001.sfac.auckland.ac.nz. [130.216.38.15]) by smtp.gmail.com with ESMTPSA id z86sm27767514pfk.34.2017.11.06.16.27.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 16:27:55 -0800 (PST) To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Cc: spring@ietf.org Message-ID: <0b256dd6-d5e2-a7ca-d71e-08dfe5f360ae@gmail.com> Date: Tue, 7 Nov 2017 13:27: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: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 00:27:59 -0000 Hi, > but this field is, according to [RFC6294], not used in practice. I don't think it's very useful to cite in 2017 a document published in 2011 based on realities in 2010 or earlier. Actually I think you can actually delete the whole phrase; since the proposal tries to respect RFC6437, it is irrelevant anyway. The draft cites RFC2460 but that is obsolete; please cite RFC8200 instead. > The use of the other 18 bits is not specified in this document > because is out of scope here. But it should follow [RFC6437]. I think is a slight simplification. What you are saying is the 18 bits should be a pseudo-random number (following the guidance given in 6437 for all 20 bits) and the 2 bits will have local semantics but will be set to 00 (I assume) for packets that leave the domain, thus retaining 18 bits of entropy instead of 20. (Which means there will only be about 256k possible flow label values, instead of a million, but that is still plenty of scope for load balancing.) Regards Brian On 07/11/2017 04:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > 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 ; 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 > > > 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-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=draft-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 > From nobody Mon Nov 6 17:13:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C8A13F979 for ; Mon, 6 Nov 2017 17:13:09 -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 m0Sh95O911Kl for ; Mon, 6 Nov 2017 17:13:07 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 0EFF913F6BC for ; Mon, 6 Nov 2017 17:13:07 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id o6so6424335qkh.3 for ; Mon, 06 Nov 2017 17:13:07 -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=FIzW3DSF3afeJxz9K9xIe1QwTb7E5VDQCJca+LaA5t0=; b=00u3x0wkgFWU4fbX0hDldmLgjkQtfETjZpu2TPj+As3B4QqkDYbqCdIVWhtFqk0ikV 5+R+t1ijHeZQRNfCM/h6c/SO56zZAyMxrYaXgnLMILKuzBg0XxIumAVvF7bf+t0CRDgV uPokpbMGl85K0w/Wiv4LF1o/ywlo1HwTgF/pwTw/2ffCEIoTT4MeqSAdWxRFUzQ24Owd nDQ+lFcvQnM3jhnSbeq7VzCA1/XOybjHRGV9NAxmJqXvHaHBxXknYVUKN+OAXCEE3gF8 2JpQaGpyhKUkqIju8D5K2Sr4fv1kcMpNQW218loUvmMBtmiQLd8T2cJyvaSZHtst+MJ1 9Taw== 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=FIzW3DSF3afeJxz9K9xIe1QwTb7E5VDQCJca+LaA5t0=; b=RbrGbOEUxiGZEX1IaEOHR1XHbZgZvFFWKP8hEarTUUp5+9yNcjap6xRT1du1USP8zk jjaarLx5CtZWGJ350kK8KCbS50ChncXgJBMRjU2Qqi0gTW2IlmZ4MpVsO6EO9P9T3qyO 2NCs2JPa79+i9+P5mGTpRbX6gCJ6rItbe3Cr+MQR0C4nveogdr8RY3wcpaJ2VXyEz85h mzhEjyc+0ilx4DoTjBZ6LiDRvaA8pweGQs/ij81N6qTHyhYl58s/mY3UB9YLcZCLZafv EctHOr3Fp4clhN2LRFD64CzU9fKa0LXHOqck/s2CsFpwi7S8fjqf1mu8uxfri8JNiD8Y edcQ== X-Gm-Message-State: AJaThX5Nk7SNwmkxzXITNPpEsQNIJDbwjoRIBAtDeta98t6+LZaNauDQ yXIgZH3YqFrigx04zUcYQxq+TUBC/UM/PCYn98AXJg== X-Google-Smtp-Source: ABhQp+Qs5ZInoCF+kA9lbJAXeo8GuITyly+giTMmsu4ypFCBT7PjI0xitSPE7VrNZaOZIdaUtf97sYYWDuqeOd/SdAo= X-Received: by 10.55.155.86 with SMTP id d83mr24396992qke.311.1510017186018; Mon, 06 Nov 2017 17:13:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Mon, 6 Nov 2017 17:13:05 -0800 (PST) In-Reply-To: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Mon, 6 Nov 2017 17:13:05 -0800 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 01:13:09 -0000 On Mon, Nov 6, 2017 at 7:59 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > 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 ; 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 > > > 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-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=draft-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. > Hi, Per section 3, either all the switches in a domain need to be update to mask the bits or use flow label for ECMP needs to be disabled for the domain. Neither of these options seem very desirable to me. Can the assigned bits be in the high order bits of the flow label? This might make some manipulation easier. >From section 1: "Based on these considerations, it is allowed to use the flow label field in a managed domain, assuming when a packet leaves the domain, the original flow label value MUST be restored." In this proposal, if two bits are overwritten by an intermediate node, how are their original values restored when leaving the domain? Tom From nobody Mon Nov 6 21:16:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1B613FB2A; Mon, 6 Nov 2017 21:16:15 -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 53qiTehkdYJp; Mon, 6 Nov 2017 21:16:13 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E721C13FAFC; Mon, 6 Nov 2017 21:16:12 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id n22so8037506uaj.13; Mon, 06 Nov 2017 21:16:12 -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=EDbUPfguqJgs8tnWOtOwG8mnVZULBSLrFV0t6NnZJhs=; b=KB/3MwaE32mQiKNGgYEQdBlteTYzlnyZHxsr9fXEO/8A9x6ENKW+K74x88RDL4V6ws ARotTmHaYvyEBa9nfdqfjijQxpJUlIBFFFmRLqLilVGsLgz6/tmTnMI2F82HeMQnyzAj jOUAFgG78AzelHr4Y/2XrsYtel3hDSmjJSPiNr9Y7c9NoOZt83Hb3yk/GpVZrV9yzsuc InGprgiX3Ldpc88uHJOX5Q3EMfXvVROFARFlPj20mk5ARZC4ArxFfQzMkB1qR62oYjpS mhj/LMfu/DNncEb8xs45awy+mcdiQKMPbSYiGNdzKwsmSElZYfen1gfV8HxyvZX5FvR5 VthA== 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=EDbUPfguqJgs8tnWOtOwG8mnVZULBSLrFV0t6NnZJhs=; b=VMoK7/2d7sZAFMHZMYF3hIrtpnNCRQOz7rH6iNNfnD6bt+aZ29fGRLbtg1rlYZMsdt dG/70xWxWMovoQHEibrDqreRBAysfAZACn1yw6tbCYgCd7NOhpW65tUhD9yOWs8KIzRy 5opgzavj9uJVsycbqkImfRitSzhuWEoUA2y+7GzdDcPs7F/LDY7QkFOeiopp+HjHnO3s SjNbry84DBZXYZJp3FI48MoJRTaY+5Ph+cWlYwTOO/Pq5dKg9X299qCnraQrVYZTPvRp GkfSTu9N4vIhjxbIjp66jKgLCclRB0DVbhT6YaKbAF7vj0OrcB0bso3x2PGNAxwWdmWK UJeQ== X-Gm-Message-State: AMCzsaWcjvW2odOidE2FxOHhqbRMVPhhzpdM7EDA4BaTDtOeQLd8DAGA jvQ0hbSJJi0li/gg2GYUkHEceSZjqKXfeukeOwI= X-Google-Smtp-Source: ABhQp+QviJ6kNbHXKTDMHai/p3UAZSboSZYtBg8u436n+MHpLtO4lUg0NvKtFmelA7bCRquQTqxYp1pyFxxmQ8UiEco= X-Received: by 10.176.74.15 with SMTP id q15mr14297000uae.120.1510031771908; Mon, 06 Nov 2017 21:16:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Mon, 6 Nov 2017 21:15:41 -0800 (PST) In-Reply-To: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> From: Mark Smith Date: Tue, 7 Nov 2017 16:15:41 +1100 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" , spring@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 05:16:15 -0000 On 7 November 2017 at 02:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > If any feedback or comments (preferably constructive), then please have the discussion including SPRING WG in cc > So this draft, similar to the IPv6 EH insertion draft, doesn't answer the fundamental question of why. What technical and engineering reasons justify reusing the flow label field, contrary to its specification? What alternatives were considered that don't violate the the flow label specification, and why are their drawbacks so significant that they justify ignoring the flow label specification? Use of IPv6 fields can be novel, however the novelty has to fit within the specifications to ensure interoperability. "[RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used in controlled environment," I'm sure it doesn't. During the original discussions that resulted in RFC6437, I suggested the idea of Flow Label domains similar to DSCP domains. It was ignored for valid reasons. This is the discussion mentioned in the first paragraph of appendix A in RFC6436. "A model was discussed in an earlier version of this document which defined a notion of 'flow label domain' analogous to a differentiated services domain [RFC2474]. This model would have encouraged local usage of the flow label as an alternative to any form of generic use, but it required complex rules for the behavior of domain boundary routers, and proved controversial in discussion." Here's what the flow label specification RFC says, "Once set to a non-zero value, the Flow Label is expected to be delivered unchanged to the destination node(s). A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1" I don't think the use in this draft is a "compelling operational security reason". A network can have a number of egress points. To be able to restore flow label values upon egress, either all of the flow label restoration state for all in-flight packets' flow label values will have to be kept synchronised at all of the egress points, or kept synchronised in accordance with where the routing protocol determines is the current egress point for the packet. In this latter case, while in flight, the egress point could change, meaning the packet's egress path changes, and there then occurs a race between when the packet reaches the exit point and the flow label restoration state for that packet reaches that egress point so that it can be restored. So are packets going to be held/delayed upon ingress such that they can never reach the egress point before their original flow label value information reaches that egress point first? If they're not, then there is no assurance that the original flow label value can be restored, and the domain isn't closed anymore. The modified packet leaves the "closed domain" with the modification unrestored. "The IPv6 protocol includes a flow label in every packet header, but this field is, according to [RFC6294], not used in practice." RFC6294 was published in 2011, 6 years ago. Implementations have changed since then. The Linux kernel is setting flow label values per RFC6437 per Tom Herbert's Linux kernel patch in the order of 2 years ago. Random flow labels look to be also being set by Mac OS X around the same time (July 2015) - https://www.ietf.org/mail-archive/web/ipv6/current/msg22820.html Windows was the major hold out - the latest Windows 10 Creater Update is now setting Flow Labels. https://www.ietf.org/mail-archive/web/ipv6/current/msg22820.html It seems people are starting to believe "closed domains" can be used to justify modifying packets in flight, in any way they'd like to modify them. In theory and in specifications, the modifications are guaranteed to be reversed at egress, in practice, contrary to specifications, implementations and network operations are not guaranteed and perfect. The reversal may not occur at egress due to implementation bugs, partial device failures or operator configuration error or omission. These sorts of in-flight changes are not conservative, making them contrary to the Robustness Principle. As shown by RFC1918 address and route leaks, "closed domains" attached to the Internet aren't guaranteed to be closed. A closed domain network can only be truly closed off from the Internet if it is completely isolated with an air gap. Regards, Mark. > G/ > > -----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 > > > 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-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=draft-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 From nobody Mon Nov 6 22:44:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB40813FB70 for ; Mon, 6 Nov 2017 22:44:22 -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 btYrgzsrOqco for ; Mon, 6 Nov 2017 22:44:19 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0133.outbound.protection.outlook.com [104.47.2.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290AC13FAC5 for ; Mon, 6 Nov 2017 22:44:19 -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=gd44DJkwjZpo7/2CBitlez0xwVS5sT+70dbK58b7W4I=; b=nEaExW3hSuRIULC2rANqRQItVRq1JEyN54CrI/SRVUTFseahBmT0GV9cCCH9Ip8dlGAAqJsOqGg3XYSpUw+WrIUuIIF/mG5FANt0qaqTZp6hfNcP6cA5TKAoXqyezEq01H7ORm40ZiCRSmtpgVNuEeBJkFM+gX3GyZNGdl73uAM= Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB2834.eurprd07.prod.outlook.com (10.168.155.137) 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 06:44:16 +0000 Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 06:44:16 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Tom Herbert CC: "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYwgACbq4CAAFvKQA== Date: Tue, 7 Nov 2017 06:44:16 +0000 Message-ID: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [81.242.22.169] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2834; 6:TirCtCfu7snOmfItdKiS7ImdLQi804lCDaiTdrv7ja7CpbG2i9GOt3agM60VjqkmODg/juKtqkmLq20oFu4l9n82Lz3lgBTaiwviyDWSqbk0IVgqJRaSX4cCMBDcTq083M7c8YCdXvMvBZCdQ/vgxasB1V7hufBcGiAXPtlKODYiP2IIkMVAZhoHFuJYYFa/VQsJEYFXpoxQf4Uz/RbUBW+FpaBJmHL/4T6VfabsHXce52Wm9pGJHGa7Esu4S0E04iNOXXGaM7YMJ9EFsy/saITzqZt/EG9ckkcwNw4DGmOYOdSL4c84/qZTciUPEraDmn89ZIRH50cVY/5BXNQuq38x10eC1sBXLkqjym5DZwM=; 5:x1g2Urd64UAvRs6qZz7BMaYNChHkckc0r7sulz6f4DtApsLT8PP9mj9H9WdxUbgPIgZsy4UwjnWFexhH6x2QwZUTvDD5Gw/oME/Jva7z0tikMB/E4GJaF+aGknixOgOlQHWHOYJU/RWl5T7QTvOjQeIFEJ2k1T75XvxiMzn9vWU=; 24:dVDk0skdRTaG/K6LzMTFOXkN4dmYcha+LVUkXJ1ChwzUlyrGXu9Ov/x7iO+g2xuHeht47wNTW0hem1zfUmPHA9jnCTx0c+A2NecLnYzCvY0=; 7:iYJe6613tyi6ARyZFW5VF96UsYreAoHagSTURypBI0qQ/QYBY3TyI1dJOI1DyHmOyVMtgk6dOCdVjuHwKc3T58YzvTVwNQWjiP4TOH8IkNPGIMASUCrWoTWCe7PYfvB81mWP6P71oumuocR2J2tUhOQoaDzXq6F31eAc3ec9rCktBQoY1IgroflNRcriYCWFh1oMicWFW+XuLO/dEurgylqKq8PQnoXJyhVK3ITzdQjEJdQZDD5IS8xpWZv8jLG3 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bf82d13b-84fb-447e-4f82-08d525aaf763 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM5PR0701MB2834; x-ms-traffictypediagnostic: AM5PR0701MB2834: x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597)(43073073696351); 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)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2834; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2834; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(377424004)(24454002)(189002)(199003)(13464003)(305945005)(478600001)(33656002)(102836003)(54356999)(97736004)(55016002)(81156014)(106356001)(99286004)(6246003)(4001150100001)(6306002)(9686003)(3846002)(101416001)(6116002)(189998001)(50986999)(561944003)(81166006)(2900100001)(105586002)(7736002)(8676002)(53936002)(15650500001)(76176999)(8936002)(229853002)(6506006)(2906002)(966005)(3280700002)(7696004)(6436002)(230783001)(2950100002)(86362001)(25786009)(74316002)(68736007)(66066001)(53546010)(4326008)(316002)(5660300001)(6916009)(3660700001)(14454004)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2834; 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: bf82d13b-84fb-447e-4f82-08d525aaf763 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 06:44:16.7317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2834 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 06:44:23 -0000 SGkgVG9tLA0KDQotLT4NCkZyb20gc2VjdGlvbiAxOg0KDQoiQmFzZWQgb24gdGhlc2UgY29uc2lk ZXJhdGlvbnMsIGl0IGlzIGFsbG93ZWQgdG8gdXNlIHRoZSBmbG93IGxhYmVsIGZpZWxkIGluIGEg bWFuYWdlZCBkb21haW4sIGFzc3VtaW5nIHdoZW4gYSBwYWNrZXQgbGVhdmVzIHRoZSBkb21haW4s IHRoZSBvcmlnaW5hbCBmbG93IGxhYmVsIHZhbHVlIE1VU1QgYmUgcmVzdG9yZWQuIg0KDQpJbiB0 aGlzIHByb3Bvc2FsLCBpZiB0d28gYml0cyBhcmUgb3ZlcndyaXR0ZW4gYnkgYW4gaW50ZXJtZWRp YXRlIG5vZGUsIGhvdyBhcmUgdGhlaXIgb3JpZ2luYWwgdmFsdWVzIHJlc3RvcmVkIHdoZW4gbGVh dmluZyB0aGUgZG9tYWluPw0KLS0+DQoNCkdWPiAgQmVjYXVzZSB0aGUgZmllbGQgdGhhdCBhcmUg YmVpbmcgZmlkZGxlZCB3aXRoIGFyZSBvbiB0aGUgSVB2NiBTUnY2IG91dGVyIGVuY2Fwc3VsYXRp b24gaGVhZGVyLiBXaGVuIHRoZSBvcmlnaW5hbCBwYWNrZXQgbGVhdmVzIHRoZSBjb250cm9sbGVk IGRvbWFpbiwgdGhlbiB0aGF0IGhlYWRlciBpcyByZW1vdmVkIGFnYWluLCBhbmQgdGhlIG9yaWdp bmFsIElQdjYgcGFja2V0IHdpdGggb3JpZ2luYWwgaGVhZGVycyBhcHBlYXIgYWdhaW4uIA0KDQpH Lw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVG9tIEhlcmJlcnQgW21haWx0 bzp0b21AaGVyYmVydGxhbmQuY29tXSANClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDcsIDIwMTcg MDI6MTMNClRvOiBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8Z3Vu dGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+DQpDYzogdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbdjZvcHNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZpb2Nj b2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJrLTAxLnR4dA0KDQpPbiBNb24sIE5vdiA2LCAy MDE3IGF0IDc6NTkgQU0sIFZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtDQpCRS9BbnR3ZXJw KSA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+IHdyb3RlOg0KPiBJZiBhbnkgZmVlZGJh Y2sgb3IgY29tbWVudHMgKHByZWZlcmFibHkgY29uc3RydWN0aXZlKSwgdGhlbiBwbGVhc2UgDQo+ IGhhdmUgdGhlIGRpc2N1c3Npb24gaW5jbHVkaW5nIFNQUklORyBXRyBpbiBjYw0KPg0KPiBHLw0K Pg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFRodXJz ZGF5LCBPY3RvYmVyIDI2LCAyMDE3IDE2OjM1DQo+IFRvOiBHaXVzZXBwZSBGaW9jY29sYSA8Z2l1 c2VwcGUuZmlvY2NvbGFAdGVsZWNvbWl0YWxpYS5pdD47IFZhbiBEZSANCj4gVmVsZGUsIEd1bnRl ciAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+OyAN Cj4gTXVsZXksIFByYXZlZW4gKE5va2lhIC0gVVMvTW91bnRhaW4gVmlldykgPHByYXZlZW4ubXVs ZXlAbm9raWEuY29tPjsgDQo+IE1hdXJvIENvY2lnbGlvIDxtYXVyby5jb2NpZ2xpb0B0ZWxlY29t aXRhbGlhLml0Pg0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiBk cmFmdC1maW9jY29sYS1zcHJpbmctZmxvdy1sYWJlbC1hbHQtbWFyay0wMS50eHQNCj4NCj4NCj4g QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFs dC1tYXJrLTAxLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdpdXNl cHBlIEZpb2Njb2xhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4NCj4gTmFt ZTogICAgICAgICAgIGRyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJrDQo+ IFJldmlzaW9uOiAgICAgICAwMQ0KPiBUaXRsZTogICAgICAgICAgVXNpbmcgdGhlIElQdjYgRmxv dyBMYWJlbCBmb3IgUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQgd2l0aCBBbHRlcm5hdGUgTWFya2lu ZyBNZXRob2QgaW4gU2VnbWVudCBSb3V0aW5nDQo+IERvY3VtZW50IGRhdGU6ICAyMDE3LTEwLTI2 DQo+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6ICAgICAg ICAgIDgNCj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1maW9jY29sYS1zcHJpbmctZmxvdy1sYWJlbC1hbHQtbWFyay0wMS50eHQNCj4g U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZp b2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJrLw0KPiBIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVs LWFsdC1tYXJrLTAxDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9odG1sL2RyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJrLTAx DQo+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0LW1hcmstMDENCj4NCj4gQWJzdHJhY3Q6 DQo+ICAgIFtSRkM2Mjk0XSBtYWtlcyBhIHN1cnZleSBvZiBQcm9wb3NlZCBVc2UgQ2FzZXMgZm9y IHRoZSBJUHY2IEZsb3cNCj4gICAgTGFiZWwuICBUaGUgSVB2NiBwcm90b2NvbCBpbmNsdWRlcyBh IGZsb3cgbGFiZWwgaW4gZXZlcnkgcGFja2V0DQo+ICAgIGhlYWRlciwgYnV0IHRoaXMgZmllbGQg aXMsIGFjY29yZGluZyB0byBbUkZDNjI5NF0sIG5vdCB1c2VkIGluDQo+ICAgIHByYWN0aWNlLiAg VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRoZSBhbHRlcm5hdGUgbWFya2luZyBtZXRob2QN Cj4gICAgY2FuIGJlIHVzZWQgYXMgdGhlIHBhc3NpdmUgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQg bWV0aG9kIGluIGEgSVB2Ng0KPiAgICBkb21haW4uDQo+DQpIaSwNCg0KUGVyIHNlY3Rpb24gMywg ZWl0aGVyIGFsbCB0aGUgc3dpdGNoZXMgaW4gYSBkb21haW4gbmVlZCB0byBiZSB1cGRhdGUgdG8g bWFzayB0aGUgYml0cyBvciB1c2UgZmxvdyBsYWJlbCBmb3IgRUNNUCBuZWVkcyB0byBiZSBkaXNh YmxlZCBmb3IgdGhlIGRvbWFpbi4gTmVpdGhlciBvZiB0aGVzZSBvcHRpb25zIHNlZW0gdmVyeSBk ZXNpcmFibGUgdG8gbWUuDQoNCkNhbiB0aGUgYXNzaWduZWQgYml0cyBiZSBpbiB0aGUgaGlnaCBv cmRlciBiaXRzIG9mIHRoZSBmbG93IGxhYmVsPw0KVGhpcyBtaWdodCBtYWtlIHNvbWUgbWFuaXB1 bGF0aW9uIGVhc2llci4NCg0KRnJvbSBzZWN0aW9uIDE6DQoNCiJCYXNlZCBvbiB0aGVzZSBjb25z aWRlcmF0aW9ucywgaXQgaXMgYWxsb3dlZCB0byB1c2UgdGhlIGZsb3cgbGFiZWwgZmllbGQgaW4g YSBtYW5hZ2VkIGRvbWFpbiwgYXNzdW1pbmcgd2hlbiBhIHBhY2tldCBsZWF2ZXMgdGhlIGRvbWFp biwgdGhlIG9yaWdpbmFsIGZsb3cgbGFiZWwgdmFsdWUgTVVTVCBiZSByZXN0b3JlZC4iDQoNCklu IHRoaXMgcHJvcG9zYWwsIGlmIHR3byBiaXRzIGFyZSBvdmVyd3JpdHRlbiBieSBhbiBpbnRlcm1l ZGlhdGUgbm9kZSwgaG93IGFyZSB0aGVpciBvcmlnaW5hbCB2YWx1ZXMgcmVzdG9yZWQgd2hlbiBs ZWF2aW5nIHRoZSBkb21haW4/DQoNClRvbQ0K From nobody Mon Nov 6 22:56:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37E013FB49; Mon, 6 Nov 2017 22:56:27 -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 8lB3RgrVPfeY; Mon, 6 Nov 2017 22:56:24 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0093.outbound.protection.outlook.com [104.47.0.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1209413FAC5; Mon, 6 Nov 2017 22:56:23 -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=m8jyNFkzjr/xO/RqXH+GwTizlVCK/IeGgb5fHiAVUb8=; b=dptdHaL1SFKP/ehxzPqlujSDhmbAfguMKPazXthMUJO5f+33pzuoRw7OpAtLLU4rpZOwYXF2dWLU3S/JN/UQj1jYZ0m9Oj/SWnS+zN5e05Ex7TEM02fHPwqX4WuAohjphnY3VVNxgANEzYiCkOuxXDEPomQ19m2wWNYqNON5CN8= Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) 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 06:56:21 +0000 Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 06:56:20 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Mark Smith CC: "v6ops@ietf.org" , "spring@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYwgADfc4CAABjTgA== Date: Tue, 7 Nov 2017 06:56:20 +0000 Message-ID: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [81.242.22.169] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2836; 6:F6Zzya3wos2i2BFBEE1SOB9a4ZEk2whopCtBckHlocC9aaAkNy/gPyQuAVbILzIf50DbXfSM8SahI18m5ZwQock6u09rA2jQtuFEy6+vjjrSr85HgpUvb7g6J0Cp4sZQlT9DzmDrLYnDtMUnB680es5vTxpeIziyvkL1NDrA0Q5Rq3HmiS6hdpdOIhXRdxK1tl8jbniPFwtYZFJxj04hIDpsfBslsTJ03r4kbU4tg35B91Mhmj7GWuFFVnWbx9nRiv2QPRbI4UBN0Q1vsFKx2YddCeWrv5BEDPvuKaCFsa1OZs+XSqxvIK4ljDIvWZh2Fio447ljrSY3OPx3HqP/gc3Hduzk0iJJ4NZQzoKuIk0=; 5:RxzISgi6yzfCzfBeTIpAVM10Gdd5rG9A4a6FjNeKV1SgvTk4CgrZJmi2CjxX2qJxBemxXJ9S2X41xCjMgSvphMPsIuWqGqkTIVDlUTmTu4c5h+3uPN0T08XF9RMseRz/PD4M4OeSF/ToVuTHTLbvsuaB1aqTEQfp/W8wF9pJUA8=; 24:U7s5O0Z60FBaphfep6mGM2vj+rIvfS4rpnqmzD6pP1Db0UjBO8l9gmyTUYl5T9t/ZzBOf3QGQI5+pl7kdRei75KfwY8QVaSKMKlyXQplAsM=; 7:QFpoqhqTYkynMPHfCTfYu3VT+ibmBwnbVG9EWNFxyb3t+tbtrHyoZiPHgaTu9slFvFXrs0I8YFvMrszOZRef6deaUkI/oSg9cGmrLRcH2skS4dP0iqG8ifvyFLjCwtsgRWJSkteR+G9jpKbYc/oKz2X5W9N9TP8Gxhdak4KTYUoocy3wPn8lcSyY18u9KhoSdRBAOxQdJ1sxzb2Wow3BK9Pcu4ycijOvMukhYFlm0hj0RY+yev5layJCwwycyN/b x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 65cef218-7544-48f6-1069-08d525aca70b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM5PR0701MB2836; x-ms-traffictypediagnostic: AM5PR0701MB2836: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(82608151540597)(43073073696351)(17755550239193); 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)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2836; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2836; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(24454002)(377424004)(199003)(189002)(13464003)(6306002)(5660300001)(9686003)(3280700002)(6916009)(53936002)(86362001)(50986999)(2950100002)(561944003)(229853002)(7696004)(2906002)(39060400002)(2900100001)(14454004)(316002)(54356999)(6246003)(55016002)(54906003)(68736007)(4326008)(3660700001)(76176999)(99286004)(8676002)(6436002)(1411001)(966005)(53546010)(4001150100001)(74316002)(8936002)(105586002)(305945005)(6506006)(97736004)(66066001)(5890100001)(81156014)(478600001)(25786009)(189998001)(15650500001)(230783001)(101416001)(33656002)(81166006)(7736002)(6116002)(102836003)(106356001)(3846002)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2836; 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 65cef218-7544-48f6-1069-08d525aca70b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 06:56:20.9290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2836 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 06:56:28 -0000 SGkgTWFyaywNCg0KVGhlIGZsb3cgbGFiZWwgb2YgdGhlIG9yaWdpbmFsIHBhY2tldCBpcyB1bnRv dWNoZWQuIEl0IGlzIG5ldmVyIG1hbmlwdWxhdGVkIGluIHRoaXMgcHJvcG9zYWwuIFRoZSBmbG93 IGxhYmVsIHRoYXQgaXMgc2V0IGluIHRoaXMgcHJvcG9zYWwgaXMgZG9uZSBhdCB0aGUgU1J2NiB0 dW5uZWwtaGVhZCBlbmQgd2hpY2ggaW1wb3NlcyB0aGUgU1J2NiBlbmNhcHN1bGF0aW9uIGhlYWRl ci4gSXQgaXMgdGhpcyBlbmNhcHN1bGF0aW9uIGhlYWRlciB3aGljaCBoYXMgdGhlIGZsb3cgbGFi ZWwgd2hpY2ggaXMgdXNlZCBpbiB0aGlzIGRyYWZ0LiAgDQpTbyBiYXNpY2FsbHksIGl0IGlzIGp1 c3QgdGhlIFNSdjYgdHVubmVsIG91dGVyIGVuY2FwIGhlYWRlciB3aGljaCBpcyB1c2VkIGZvciBh bHRlcm5hdGUgcGFja2V0IG1hcmtpbmcuIEFuZCB0aGlzIGlzIHNldCBvbmx5IG9uZSB0aW1lIGJ5 IHRoZSBvcmlnaW5hbCBTUnY2IHR1bm5lbCBoZWFkLWVuZCByb3V0ZXIgKHdoaWNoIGlzIHRoZSBz b3VyY2UgYWRkcmVzcyBvZiB0aGUgSVB2NiBTUnY2IHR1bm5lbC4uLikuIFRoaXMgb3V0ZXIgU1J2 NiBoZWFkZXIgaXMgcmVtb3ZlZCB3aGVuIHRoZSBwYWNrZXQgZXhpdHMgdGhlIFNSdjYgZG9tYWlu LCBhbmQgdGhlIG9yaWdpbmFsIGZsb3cgbGFiZWwgYXBwZWFycyBhZ2FpbiB1bnRvdWNoZWQuIFRo aXMgZG9lcyBub3QgYnJlYWsgYW55IFJGQyBhdCBhbGwgYmVjYXVzZSBhbGwgYmVjYXVzZSB0aGUg b3JpZ2luYWwgZmxvdy1sYWJlbCBvZiB0aGUgb3JpZ2luYWwgSVB2NiBwYWNrZXQgaXMgbmV2ZXIg dG91Y2hlZC4NCg0KU28sIGluIHRoaXMgcHJvcG9zYWwgdGhlcmUgaXMgbm8gZGV2aWNlIHdoaWNo IGlzIGNoYW5naW5nIGZsb3ctbGFiZWxzIGF0IGFsbC4gSXQgaXMgb25seSBkdXJpbmcgdGhlIGlt cG9zaW5nIG9mIHRoZSBTUnY2IG91dGVyIGhlYWRlciwgdGhhdCB0aGUgZmxvdyBsYWJlbCBmaWVs ZCBpcyBzZXQgb25jZSBmb3IgQWx0ZXJuYXRlIG1hcmtpbmcgcHVycG9zZXMgaW5zaWRlIHRoZSBv dXRlciBTUnY2IHR1bm5lbCBoZWFkZXIuDQoNCkhvcGUgaXQgY2xhcmlmaWVzPw0KDQpHLw0KDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcmsgU21pdGggW21haWx0bzpt YXJrenp6c21pdGhAZ21haWwuY29tXSANClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDcsIDIwMTcg MDY6MTYNClRvOiBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8Z3Vu dGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+DQpDYzogdjZvcHNAaWV0Zi5vcmc7IHNwcmluZ0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0LW1hcmstMDEudHh0DQoN Ck9uIDcgTm92ZW1iZXIgMjAxNyBhdCAwMjo1OSwgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lh IC0gQkUvQW50d2VycCkgPGd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tPiB3cm90ZToNCj4g SWYgYW55IGZlZWRiYWNrIG9yIGNvbW1lbnRzIChwcmVmZXJhYmx5IGNvbnN0cnVjdGl2ZSksIHRo ZW4gcGxlYXNlIA0KPiBoYXZlIHRoZSBkaXNjdXNzaW9uIGluY2x1ZGluZyBTUFJJTkcgV0cgaW4g Y2MNCj4NCg0KU28gdGhpcyBkcmFmdCwgc2ltaWxhciB0byB0aGUgSVB2NiBFSCBpbnNlcnRpb24g ZHJhZnQsIGRvZXNuJ3QgYW5zd2VyIHRoZSBmdW5kYW1lbnRhbCBxdWVzdGlvbiBvZiB3aHkuDQoN CldoYXQgdGVjaG5pY2FsIGFuZCBlbmdpbmVlcmluZyByZWFzb25zIGp1c3RpZnkgcmV1c2luZyB0 aGUgZmxvdyBsYWJlbCBmaWVsZCwgY29udHJhcnkgdG8gaXRzIHNwZWNpZmljYXRpb24/IFdoYXQg YWx0ZXJuYXRpdmVzIHdlcmUgY29uc2lkZXJlZCB0aGF0IGRvbid0IHZpb2xhdGUgdGhlIHRoZSBm bG93IGxhYmVsIHNwZWNpZmljYXRpb24sIGFuZCB3aHkgYXJlIHRoZWlyIGRyYXdiYWNrcyBzbyBz aWduaWZpY2FudCB0aGF0IHRoZXkganVzdGlmeSBpZ25vcmluZyB0aGUgZmxvdyBsYWJlbCBzcGVj aWZpY2F0aW9uPyBVc2Ugb2YgSVB2NiBmaWVsZHMgY2FuIGJlIG5vdmVsLCBob3dldmVyIHRoZSBu b3ZlbHR5IGhhcyB0byBmaXQgd2l0aGluIHRoZSBzcGVjaWZpY2F0aW9ucyB0byBlbnN1cmUgaW50 ZXJvcGVyYWJpbGl0eS4NCg0KIltSRkM2NDM2XSBhbmQgW1JGQzY0MzddIG9wZW4gdGhlIGRvb3Ig Zm9yIElQdjYgRmxvdyBMYWJlbCB0byBiZSB1c2VkDQogICBpbiBjb250cm9sbGVkIGVudmlyb25t ZW50LCINCg0KSSdtIHN1cmUgaXQgZG9lc24ndC4gRHVyaW5nIHRoZSBvcmlnaW5hbCBkaXNjdXNz aW9ucyB0aGF0IHJlc3VsdGVkIGluIFJGQzY0MzcsIEkgc3VnZ2VzdGVkIHRoZSBpZGVhIG9mIEZs b3cgTGFiZWwgZG9tYWlucyBzaW1pbGFyIHRvIERTQ1AgZG9tYWlucy4gSXQgd2FzIGlnbm9yZWQg Zm9yIHZhbGlkIHJlYXNvbnMuIFRoaXMgaXMgdGhlIGRpc2N1c3Npb24gbWVudGlvbmVkIGluIHRo ZSBmaXJzdCBwYXJhZ3JhcGggb2YgYXBwZW5kaXggQSBpbiBSRkM2NDM2Lg0KDQoiQSBtb2RlbCB3 YXMgZGlzY3Vzc2VkIGluIGFuIGVhcmxpZXIgdmVyc2lvbiBvZiB0aGlzIGRvY3VtZW50IHdoaWNo DQogICBkZWZpbmVkIGEgbm90aW9uIG9mICdmbG93IGxhYmVsIGRvbWFpbicgYW5hbG9nb3VzIHRv IGEgZGlmZmVyZW50aWF0ZWQNCiAgIHNlcnZpY2VzIGRvbWFpbiBbUkZDMjQ3NF0uICBUaGlzIG1v ZGVsIHdvdWxkIGhhdmUgZW5jb3VyYWdlZCBsb2NhbA0KICAgdXNhZ2Ugb2YgdGhlIGZsb3cgbGFi ZWwgYXMgYW4gYWx0ZXJuYXRpdmUgdG8gYW55IGZvcm0gb2YgZ2VuZXJpYyB1c2UsDQogICBidXQg aXQgcmVxdWlyZWQgY29tcGxleCBydWxlcyBmb3IgdGhlIGJlaGF2aW9yIG9mIGRvbWFpbiBib3Vu ZGFyeQ0KICAgcm91dGVycywgYW5kIHByb3ZlZCBjb250cm92ZXJzaWFsIGluIGRpc2N1c3Npb24u Ig0KDQoNCkhlcmUncyB3aGF0IHRoZSBmbG93IGxhYmVsIHNwZWNpZmljYXRpb24gUkZDIHNheXMs DQoNCiJPbmNlIHNldCB0byBhIG5vbi16ZXJvIHZhbHVlLCB0aGUgRmxvdyBMYWJlbCBpcyBleHBl Y3RlZCB0byBiZQ0KICAgZGVsaXZlcmVkIHVuY2hhbmdlZCB0byB0aGUgZGVzdGluYXRpb24gbm9k ZShzKS4gIEEgZm9yd2FyZGluZyBub2RlDQogICBNVVNUIGVpdGhlciBsZWF2ZSBhIG5vbi16ZXJv IGZsb3cgbGFiZWwgdmFsdWUgdW5jaGFuZ2VkIG9yIGNoYW5nZSBpdA0KICAgb25seSBmb3IgY29t cGVsbGluZyBvcGVyYXRpb25hbCBzZWN1cml0eSByZWFzb25zIGFzIGRlc2NyaWJlZCBpbg0KICAg U2VjdGlvbiA2LjEiDQoNCkkgZG9uJ3QgdGhpbmsgdGhlIHVzZSBpbiB0aGlzIGRyYWZ0IGlzIGEg ImNvbXBlbGxpbmcgb3BlcmF0aW9uYWwgc2VjdXJpdHkgcmVhc29uIi4NCg0KQSBuZXR3b3JrIGNh biBoYXZlIGEgbnVtYmVyIG9mIGVncmVzcyBwb2ludHMuIFRvIGJlIGFibGUgdG8gcmVzdG9yZSBm bG93IGxhYmVsIHZhbHVlcyB1cG9uIGVncmVzcywgZWl0aGVyIGFsbCBvZiB0aGUgZmxvdyBsYWJl bCByZXN0b3JhdGlvbiBzdGF0ZSBmb3IgYWxsIGluLWZsaWdodCBwYWNrZXRzJyBmbG93IGxhYmVs IHZhbHVlcyB3aWxsIGhhdmUgdG8gYmUga2VwdCBzeW5jaHJvbmlzZWQgYXQgYWxsIG9mIHRoZSBl Z3Jlc3MgcG9pbnRzLCBvciBrZXB0IHN5bmNocm9uaXNlZCBpbiBhY2NvcmRhbmNlIHdpdGggd2hl cmUgdGhlIHJvdXRpbmcgcHJvdG9jb2wgZGV0ZXJtaW5lcyBpcyB0aGUgY3VycmVudCBlZ3Jlc3Mg cG9pbnQgZm9yIHRoZSBwYWNrZXQuDQoNCkluIHRoaXMgbGF0dGVyIGNhc2UsIHdoaWxlIGluIGZs aWdodCwgdGhlIGVncmVzcyBwb2ludCBjb3VsZCBjaGFuZ2UsIG1lYW5pbmcgdGhlIHBhY2tldCdz IGVncmVzcyBwYXRoIGNoYW5nZXMsIGFuZCB0aGVyZSB0aGVuIG9jY3VycyBhIHJhY2UgYmV0d2Vl biB3aGVuIHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgZXhpdCBwb2ludCBhbmQgdGhlIGZsb3cgbGFi ZWwgcmVzdG9yYXRpb24gc3RhdGUgZm9yIHRoYXQgcGFja2V0IHJlYWNoZXMgdGhhdCBlZ3Jlc3Mg cG9pbnQgc28gdGhhdCBpdCBjYW4gYmUgcmVzdG9yZWQuDQoNClNvIGFyZSBwYWNrZXRzIGdvaW5n IHRvIGJlIGhlbGQvZGVsYXllZCB1cG9uIGluZ3Jlc3Mgc3VjaCB0aGF0IHRoZXkgY2FuIG5ldmVy IHJlYWNoIHRoZSBlZ3Jlc3MgcG9pbnQgYmVmb3JlIHRoZWlyIG9yaWdpbmFsIGZsb3cgbGFiZWwg dmFsdWUgaW5mb3JtYXRpb24gcmVhY2hlcyB0aGF0IGVncmVzcyBwb2ludCBmaXJzdD8gSWYgdGhl eSdyZSBub3QsIHRoZW4gdGhlcmUgaXMgbm8gYXNzdXJhbmNlIHRoYXQgdGhlIG9yaWdpbmFsIGZs b3cgbGFiZWwgdmFsdWUgY2FuIGJlIHJlc3RvcmVkLCBhbmQgdGhlIGRvbWFpbiBpc24ndCBjbG9z ZWQgYW55bW9yZS4gVGhlIG1vZGlmaWVkIHBhY2tldCBsZWF2ZXMgdGhlICJjbG9zZWQgZG9tYWlu IiB3aXRoIHRoZSBtb2RpZmljYXRpb24gdW5yZXN0b3JlZC4NCg0KDQoiVGhlIElQdjYgcHJvdG9j b2wgaW5jbHVkZXMgYSBmbG93IGxhYmVsIGluIGV2ZXJ5IHBhY2tldA0KICAgaGVhZGVyLCBidXQg dGhpcyBmaWVsZCBpcywgYWNjb3JkaW5nIHRvIFtSRkM2Mjk0XSwgbm90IHVzZWQgaW4NCiAgIHBy YWN0aWNlLiINCg0KUkZDNjI5NCB3YXMgcHVibGlzaGVkIGluIDIwMTEsIDYgeWVhcnMgYWdvLiBJ bXBsZW1lbnRhdGlvbnMgaGF2ZSBjaGFuZ2VkIHNpbmNlIHRoZW4uDQoNClRoZSBMaW51eCBrZXJu ZWwgaXMgc2V0dGluZyBmbG93IGxhYmVsIHZhbHVlcyBwZXIgUkZDNjQzNyBwZXIgVG9tIEhlcmJl cnQncyBMaW51eCBrZXJuZWwgcGF0Y2ggaW4gdGhlIG9yZGVyIG9mIDIgeWVhcnMgYWdvLg0KDQpS YW5kb20gZmxvdyBsYWJlbHMgbG9vayB0byBiZSBhbHNvIGJlaW5nIHNldCBieSBNYWMgT1MgWCBh cm91bmQgdGhlIHNhbWUgdGltZSAoSnVseSAyMDE1KSAtDQoNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvaXB2Ni9jdXJyZW50L21zZzIyODIwLmh0bWwNCg0KV2luZG93cyB3 YXMgdGhlIG1ham9yIGhvbGQgb3V0IC0gdGhlIGxhdGVzdCBXaW5kb3dzIDEwIENyZWF0ZXIgVXBk YXRlIGlzIG5vdyBzZXR0aW5nIEZsb3cgTGFiZWxzLg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2lwdjYvY3VycmVudC9tc2cyMjgyMC5odG1sDQoNCg0KSXQgc2VlbXMg cGVvcGxlIGFyZSBzdGFydGluZyB0byBiZWxpZXZlICJjbG9zZWQgZG9tYWlucyIgY2FuIGJlIHVz ZWQgdG8ganVzdGlmeSBtb2RpZnlpbmcgcGFja2V0cyBpbiBmbGlnaHQsIGluIGFueSB3YXkgdGhl eSdkIGxpa2UgdG8gbW9kaWZ5IHRoZW0uIEluIHRoZW9yeSBhbmQgaW4gc3BlY2lmaWNhdGlvbnMs IHRoZSBtb2RpZmljYXRpb25zIGFyZSBndWFyYW50ZWVkIHRvIGJlIHJldmVyc2VkIGF0IGVncmVz cywgaW4gcHJhY3RpY2UsIGNvbnRyYXJ5IHRvIHNwZWNpZmljYXRpb25zLCBpbXBsZW1lbnRhdGlv bnMgYW5kIG5ldHdvcmsgb3BlcmF0aW9ucyBhcmUgbm90IGd1YXJhbnRlZWQgYW5kIHBlcmZlY3Qu IFRoZSByZXZlcnNhbCBtYXkgbm90IG9jY3VyIGF0IGVncmVzcyBkdWUgdG8gaW1wbGVtZW50YXRp b24gYnVncywgcGFydGlhbCBkZXZpY2UgZmFpbHVyZXMgb3Igb3BlcmF0b3IgY29uZmlndXJhdGlv biBlcnJvciBvciBvbWlzc2lvbi4gVGhlc2Ugc29ydHMgb2YgaW4tZmxpZ2h0IGNoYW5nZXMgYXJl IG5vdCBjb25zZXJ2YXRpdmUsIG1ha2luZyB0aGVtIGNvbnRyYXJ5IHRvIHRoZSBSb2J1c3RuZXNz IFByaW5jaXBsZS4NCg0KQXMgc2hvd24gYnkgUkZDMTkxOCBhZGRyZXNzIGFuZCByb3V0ZSBsZWFr cywgImNsb3NlZCBkb21haW5zIiBhdHRhY2hlZCB0byB0aGUgSW50ZXJuZXQgYXJlbid0IGd1YXJh bnRlZWQgdG8gYmUgY2xvc2VkLiBBIGNsb3NlZCBkb21haW4gbmV0d29yayBjYW4gb25seSBiZSB0 cnVseSBjbG9zZWQgb2ZmIGZyb20gdGhlIEludGVybmV0IGlmIGl0IGlzIGNvbXBsZXRlbHkgaXNv bGF0ZWQgd2l0aCBhbiBhaXIgZ2FwLg0KDQoNClJlZ2FyZHMsDQpNYXJrLg0KDQo+IEcvDQo+DQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gU2VudDogVGh1cnNkYXks IE9jdG9iZXIgMjYsIDIwMTcgMTY6MzUNCj4gVG86IEdpdXNlcHBlIEZpb2Njb2xhIDxnaXVzZXBw ZS5maW9jY29sYUB0ZWxlY29taXRhbGlhLml0PjsgVmFuIERlIA0KPiBWZWxkZSwgR3VudGVyIChO b2tpYSAtIEJFL0FudHdlcnApIDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT47IA0KPiBN dWxleSwgUHJhdmVlbiAoTm9raWEgLSBVUy9Nb3VudGFpbiBWaWV3KSA8cHJhdmVlbi5tdWxleUBu b2tpYS5jb20+OyANCj4gTWF1cm8gQ29jaWdsaW8gPG1hdXJvLmNvY2lnbGlvQHRlbGVjb21pdGFs aWEuaXQ+DQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0 LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJrLTAxLnR4dA0KPg0KPg0KPiBBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0LW1h cmstMDEudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR2l1c2VwcGUg RmlvY2NvbGEgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPg0KPiBOYW1lOiAg ICAgICAgICAgZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0LW1hcmsNCj4gUmV2 aXNpb246ICAgICAgIDAxDQo+IFRpdGxlOiAgICAgICAgICBVc2luZyB0aGUgSVB2NiBGbG93IExh YmVsIGZvciBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCB3aXRoIEFsdGVybmF0ZSBNYXJraW5nIE1l dGhvZCBpbiBTZWdtZW50IFJvdXRpbmcNCj4gRG9jdW1lbnQgZGF0ZTogIDIwMTctMTAtMjYNCj4g R3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczogICAgICAgICAg OA0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJrLTAxLnR4dA0KPiBTdGF0 dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlvY2Nv bGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0LW1hcmsvDQo+IEh0bWxpemVkOiAgICAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0 LW1hcmstMDENCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0LW1hcmstMDENCj4g RGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1m aW9jY29sYS1zcHJpbmctZmxvdy1sYWJlbC1hbHQtbWFyay0wMQ0KPg0KPiBBYnN0cmFjdDoNCj4g ICAgW1JGQzYyOTRdIG1ha2VzIGEgc3VydmV5IG9mIFByb3Bvc2VkIFVzZSBDYXNlcyBmb3IgdGhl IElQdjYgRmxvdw0KPiAgICBMYWJlbC4gIFRoZSBJUHY2IHByb3RvY29sIGluY2x1ZGVzIGEgZmxv dyBsYWJlbCBpbiBldmVyeSBwYWNrZXQNCj4gICAgaGVhZGVyLCBidXQgdGhpcyBmaWVsZCBpcywg YWNjb3JkaW5nIHRvIFtSRkM2Mjk0XSwgbm90IHVzZWQgaW4NCj4gICAgcHJhY3RpY2UuICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdGhlIGFsdGVybmF0ZSBtYXJraW5nIG1ldGhvZA0KPiAg ICBjYW4gYmUgdXNlZCBhcyB0aGUgcGFzc2l2ZSBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudCBtZXRo b2QgaW4gYSBJUHY2DQo+ICAgIGRvbWFpbi4NCj4NCj4NCj4NCj4NCj4NCj4gUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWls aW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wcw0K From nobody Mon Nov 6 23:15:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CD613FC05 for ; Mon, 6 Nov 2017 23:15:44 -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 ivKe5PauZAbQ for ; Mon, 6 Nov 2017 23:15:43 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 824D113FC01 for ; Mon, 6 Nov 2017 23:15:43 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id v3so7341852vkb.8 for ; Mon, 06 Nov 2017 23:15:43 -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=aSCn6Hzi2NTgCyfh6O0oUFmtSdOi0oSWmy+/eumS+Yg=; b=sa5NdE0e73QS8dxt3QbtDZ/sU9wbL6TKg0P8mjVcAl94aPcONW7OymENFU8Pw6Jvd2 HXScJB5zfilHTI6kvev1nwPTkSXOcsm9/ZrQbfpx4xclGOMEimnBLSSNW8vTByl9VWwN mPadeiaORptXR7G9p40GnAWPGyUTeDlgWrp47S0gxHNN5cdV9jikSBn2kbVGEE2G1X8P 2icymGBqqB7nvWVuMIQuPUdAVjJ6WxaKTRGtLetM+2IIlCRGHNb6/WYHB1vW6JfaPiRI Ha5cIpAKHqO5+29jR69Wv6Vm6xY8ENvd+riZ0p0pe8zGApX3DLxv0uHlOSzU3d/u8ffx NNvg== 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=aSCn6Hzi2NTgCyfh6O0oUFmtSdOi0oSWmy+/eumS+Yg=; b=MaEQI486Ji2rObVzLTjHFOE+2zGjuqUdaIjabAoNTmaeQeX88NWPQWnxg6j5O/JRRj FvgGvHU2+7AJ2U3kqdpiZAkhMkdWm0se0KBRD8ZVQboJfJJI8wSLrtJR42SyuLOafLDe yHSIhDNv2mu1cpYDdQQ7Y9v4BXxXk/DJPI2AIhq92gGKgUp2uWOyhbx0dGWKh1j3jrWq yIPpuugzbP72P+HUhA8Pqx1GKcCyW5qIyh2dEx1yTvWH0XUgE+DcOrz4CeKaZv1lZgWM 9s5gYhp2Gl/DGeF24tD+cFVmdU2e748WQ5eyXr+QE3x2fdZ1SrOsZFILHjNkge0aavAW 6jNA== X-Gm-Message-State: AMCzsaWu397r98X5S5rBCVdC6z7ulgsR2GVPT2M+tfVWjIRho0+690is 1X1qbtcgzHuCBjE4jwWrUXNgM1pVSOFpmiEt/HG5BQ== X-Google-Smtp-Source: ABhQp+QDPI84IDrPYYyvKtNVbkoUZkQ+wGXn/DAyD+lk1oALghuXL97qwz3B1/9w3YwHKanJfPLmCneBdLi1+8yYXz4= X-Received: by 10.31.198.70 with SMTP id w67mr13996171vkf.101.1510038942344; Mon, 06 Nov 2017 23:15:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Mon, 6 Nov 2017 23:15:11 -0800 (PST) In-Reply-To: References: <150860492012.3131.14623048904955800548.idtracker@ietfa.amsl.com> <0EAB4149-AFE9-4770-8242-6D8E05889091@consulintel.es> <66E223E7-73B5-49BA-AA40-5AA632F3F755@consulintel.es> <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> From: Mark Smith Date: Tue, 7 Nov 2017 18:15:11 +1100 Message-ID: To: Ole Troan Cc: Mikael Abrahamsson , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 07:15:45 -0000 Hi Ole, On 2 November 2017 at 08:05, Ole Troan wrote: > Mark, > > I most definitely think doing address resolution on links without link-la= yer addresses is the wrong thing to do. Neighbor Discovery is more than just address resolution. It does two things= : 1. discovers and proves the presence of the neighbor (or more accurately, the presence of the address being discovered) 2. resolves the link-layer address if the link uses them. If the only purpose of Neighbor Discovery was address resolution, then RFC4861 would be called "IPv6 Address Resolution", and would certainly have text saying clearly that it didn't apply to point-to-point links without link-layer addresses. > Sure, other ND functions are being used. NUD isn't typically useful on ro= uter to router links. Often p2p links have link-layer notification on link = state too, and I'd argue that the benefit of a router doing NUD towards hos= ts have limited usefulness, unless it is to garbage collect state. That state can be very useful for troubleshooting. It provides a table of devices/addresses present on the link. Because the presence of devices is discovered and tracked, other functions such as security functions can leverage it. > If we ever get to update NUD, I would argue quite hard for simplification= of the protocol. > >> There are two choices. Either prevent the packet loop occurring if a >> packet is sent to a destination that doesn't exist, by probing for its >> existence via ND NS, or mitigate the consequences of the loop after it >> has already occurred. I think prevention is better than mitigation. > > If this is the problem you are trying to solve, then we have already solv= ed that. > See rfc4443, from changelog: > > - In the description of Destination Unreachable messages, Code 3, > added rule prohibiting forwarding of packets back onto point-to- > point links from which they were received, if their destination > addresses belong to the link itself ("anti-ping-ponging" rule). > > Was there any other unresolved problem I missed? > So that's a solution to the problem not performing neighbor discovery on p2p links created. I assume not performing neighbor discovery on p2p links is thought to be an optimisation. However it also created an exception. Instead of all of the ND functions in RFC4861 being performed on all links, leaving out the Source/Target Link-layer Address NS/NA option when it isn't necessary, we now have two distinct classes of links: - links for which neighbors and their IPv6 addresses are discovered - links for which neighbors and their IPv6 addresses aren't discovered IPv6 seems to have had a goal of generalisation (e.g., link-layer ARP protocol functions moved into ICMPv6, address and parameter setting moved out of PPP IPCP). Treating all links as similarly as possible, hiding the minor differences (which in the case of p2p links is just leaving out the "Source/Target Link-layer Address NS/NA option" and related processing), is simpler and more general. Much of the text I provided from RFC4861 reads to me as though generalisation of different link type handling is the goal. This optimisation then created issues that then caused RFC4443 to have to be modified to suit. It also resulted in RFC6164 which implies it fixes the problem, however as it doesn't discover if the remote address in the /127 exists, a ping-pong loop can still form. If the optimisation causes issues that have to be worked around somewhere else, and the optimisation doesn't provide an obvious benefit, is it really a useful and worth while optimsation? Regards, Mark. From nobody Tue Nov 7 00:04:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5701C13FB8A; Tue, 7 Nov 2017 00:04:05 -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 nW4nKD5S_r3u; Tue, 7 Nov 2017 00:04:03 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 3049813FB32; Tue, 7 Nov 2017 00:04:03 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id y196so3912952vkc.5; Tue, 07 Nov 2017 00:04:03 -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=2GN+MvcO7t1KGh9r9uIlR8xI7eTaNsnhCCgAl+G54b4=; b=NDK0ZOJnU/qRfG864ivVA7t/LFsrspvHTN2FLpJkCKqMGfWQLzRA3Z6cpC2ecR2EIm 63W6SnDnDMvTChBw4et0FLHSEYLsJ3hh+QNzPJdi6MD9gLh6gp3l31H2c7EBdgxRoZ5S zJc8sACW1uwHtWHOhgO1XA4UkhaKizxqh+5Bt/2TMq2yI15fg7ERrK9qLZxInSR2hdDs qEr3YJsUa1fGTDrOn+cJrIaEVlh+OQRavetIwz8lsk07+uwyroOCV6yQXyTCtyAESDl9 fd2KQ2pwd9/l8Sk8FabCglSpFb9p41VOFVaBQX5hnY2yM5fcDyro8eOt3dUYkW2O86+d uYqQ== 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=2GN+MvcO7t1KGh9r9uIlR8xI7eTaNsnhCCgAl+G54b4=; b=C3wJ3Y2c0RfOseta2658t8e+T9oM5oCGfueWY6gNr0dDmOu/XjMg4XDv2VB25XouuZ c3XrDSH9LL/WnvtyxARB3YFT88YHmeQawNRJIh6kyVu1vWlYqsSCmMfJgrEeawPgcVr0 QE06guqXZ5EzJajTZ5G38Hn2Raa74kp3HHpbSHXySVcfR2lPLxm7MTzJTtBOIIR++sDU Wl3nZhh07I4HAAr6dEIW/NWPHjMiVJGwoSnvp+F7CsDNT4nxeRFmhVpIEHkWdvGPNAUF L3ERd2heIH/jrFDBwHelRpfthNMDCglezq2uAI9VXIXyqu5ohwYnpfdULyoBXT9QvGfi cbwQ== X-Gm-Message-State: AJaThX6UGpBF9LGHKEANLmtyGCdsOQ+yVfF8HeAGO4oDECMeaHkl3e4S 3wOlKJuAL3wmCndbU9Z3XDylECngKx8mBY6As9g= X-Google-Smtp-Source: ABhQp+Q5zdc4+TA24FUZDqnXSsZvUwu2uVpuKV5fatAdpjadND65E2HehuzubCyPIb3gLAiy1Pe76qk9IkbSOvWdE0I= X-Received: by 10.31.107.129 with SMTP id k1mr13204803vki.159.1510041841937; Tue, 07 Nov 2017 00:04:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Tue, 7 Nov 2017 00:03:31 -0800 (PST) In-Reply-To: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> From: Mark Smith Date: Tue, 7 Nov 2017 19:03:31 +1100 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" , "spring@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 08:04:05 -0000 Hi Gunter, On 7 November 2017 at 17:56, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Mark, > > The flow label of the original packet is untouched. It is never manipulat= ed in this proposal. The flow label that is set in this proposal is done at= the SRv6 tunnel-head end which imposes the SRv6 encapsulation header. It i= s this encapsulation header which has the flow label which is used in this = draft. > So basically, it is just the SRv6 tunnel outer encap header which is used= for alternate packet marking. And this is set only one time by the origina= l SRv6 tunnel head-end router (which is the source address of the IPv6 SRv6= tunnel...). This outer SRv6 header is removed when the packet exits the SR= v6 domain, and the original flow label appears again untouched. This does n= ot break any RFC at all because all because the original flow-label of the = original IPv6 packet is never touched. > > So, in this proposal there is no device which is changing flow-labels at = all. It is only during the imposing of the SRv6 outer header, that the flow= label field is set once for Alternate marking purposes inside the outer SR= v6 tunnel header. > > Hope it clarifies? > It does, although it seems to be contrary to quite a lot of the introduction text: "The flow label is an immutable field recommended to contain a pseudo- random value [RFC6437]. However, in most packets it has the default value of zero, although some TCP/IP stacks do set it according to [RFC6437]. [RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used in controlled environment,..." "Based on these considerations, it is allowed to use the flow label field in a managed domain, assuming when a packet leaves the domain, the original flow label value MUST be restored." and the later reference to "[I-D.voyer-6man-extension-header-insertion]" all seems to be setting up a case to justify modifying the original packet's flow label value and then restoring it using the original value that has been somehow sent or signalled to the network egress. As you've said, when tunnelling, the original packet and its flow label value is entirely preserved, so there doesn't need to be any of the above text. Even the text about hosts not setting the FL value isn't really necessary, as tunnel end-points, as a function at the IPv6 layer, are hosts that originate packets, so they can set the FL value to what ever they like because they're originating the (tunnel) packet. I think it might be better to avoid using two of the FL bits to encode the marking method, as that also deviates from RFC6437 (I seem to remember we also thought about using some bits in the FL to encode something during that time, and also abandoned it.) I'm not across the Alternate Marking Method work, so this might be a dumb question or suggestion. Within a measurement domain, is there ever going to be a mix of single and double marking, such that it needs to be encoded per-packet? If a domain can only support one of them at any one time, then I think that could be encoded in the configuration of the SRv6 tunnel end points, rather than encoding it in a couple of the FL bits. Also, there is now an IPv6 Performance and Diagnostics Destination Option which may be a IPv6 conventional way of encoding this marking or measurement information in the outer IPv6 tunnel header (i.e. [Outer IPv6 HDR][PDM][Inner/Original IPv6 Packet]) "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option" https://tools.ietf.org/html/rfc8250 Regards, Mark. > G/ > > > > -----Original Message----- > From: Mark Smith [mailto:markzzzsmith@gmail.com] > Sent: Tuesday, November 7, 2017 06:16 > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > Cc: v6ops@ietf.org; spring@ietf.org > Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spri= ng-flow-label-alt-mark-01.txt > > On 7 November 2017 at 02:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: >> If any feedback or comments (preferably constructive), then please >> have the discussion including SPRING WG in cc >> > > So this draft, similar to the IPv6 EH insertion draft, doesn't answer the= fundamental question of why. > > What technical and engineering reasons justify reusing the flow label fie= ld, contrary to its specification? What alternatives were considered that d= on't violate the the flow label specification, and why are their drawbacks = so significant that they justify ignoring the flow label specification? Use= of IPv6 fields can be novel, however the novelty has to fit within the spe= cifications to ensure interoperability. > > "[RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used > in controlled environment," > > I'm sure it doesn't. During the original discussions that resulted in RFC= 6437, I suggested the idea of Flow Label domains similar to DSCP domains. I= t was ignored for valid reasons. This is the discussion mentioned in the fi= rst paragraph of appendix A in RFC6436. > > "A model was discussed in an earlier version of this document which > defined a notion of 'flow label domain' analogous to a differentiated > services domain [RFC2474]. This model would have encouraged local > usage of the flow label as an alternative to any form of generic use, > but it required complex rules for the behavior of domain boundary > routers, and proved controversial in discussion." > > > Here's what the flow label specification RFC says, > > "Once set to a non-zero value, the Flow Label is expected to be > delivered unchanged to the destination node(s). A forwarding node > MUST either leave a non-zero flow label value unchanged or change it > only for compelling operational security reasons as described in > Section 6.1" > > I don't think the use in this draft is a "compelling operational security= reason". > > A network can have a number of egress points. To be able to restore flow = label values upon egress, either all of the flow label restoration state fo= r all in-flight packets' flow label values will have to be kept synchronise= d at all of the egress points, or kept synchronised in accordance with wher= e the routing protocol determines is the current egress point for the packe= t. > > In this latter case, while in flight, the egress point could change, mean= ing the packet's egress path changes, and there then occurs a race between = when the packet reaches the exit point and the flow label restoration state= for that packet reaches that egress point so that it can be restored. > > So are packets going to be held/delayed upon ingress such that they can n= ever reach the egress point before their original flow label value informat= ion reaches that egress point first? If they're not, then there is no assur= ance that the original flow label value can be restored, and the domain isn= 't closed anymore. The modified packet leaves the "closed domain" with the = modification unrestored. > > > "The IPv6 protocol includes a flow label in every packet > header, but this field is, according to [RFC6294], not used in > practice." > > RFC6294 was published in 2011, 6 years ago. Implementations have changed = since then. > > The Linux kernel is setting flow label values per RFC6437 per Tom Herbert= 's Linux kernel patch in the order of 2 years ago. > > Random flow labels look to be also being set by Mac OS X around the same = time (July 2015) - > > https://www.ietf.org/mail-archive/web/ipv6/current/msg22820.html > > Windows was the major hold out - the latest Windows 10 Creater Update is = now setting Flow Labels. > > https://www.ietf.org/mail-archive/web/ipv6/current/msg22820.html > > > It seems people are starting to believe "closed domains" can be used to j= ustify modifying packets in flight, in any way they'd like to modify them. = In theory and in specifications, the modifications are guaranteed to be rev= ersed at egress, in practice, contrary to specifications, implementations a= nd network operations are not guaranteed and perfect. The reversal may not = occur at egress due to implementation bugs, partial device failures or oper= ator configuration error or omission. These sorts of in-flight changes are = not conservative, making them contrary to the Robustness Principle. > > As shown by RFC1918 address and route leaks, "closed domains" attached to= the Internet aren't guaranteed to be closed. A closed domain network can o= nly be truly closed off from the Internet if it is completely isolated with= an air gap. > > > Regards, > Mark. > >> G/ >> >> -----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 >> >> >> 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 I= ETF repository. >> >> Name: draft-fioccola-spring-flow-label-alt-mark >> Revision: 01 >> Title: Using the IPv6 Flow Label for Performance Measurement wi= th 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-spri= ng-flow-label-alt-mark-01.txt >> Status: https://datatracker.ietf.org/doc/draft-fioccola-spring-f= low-label-alt-mark/ >> Htmlized: https://tools.ietf.org/html/draft-fioccola-spring-flow-l= abel-alt-mark-01 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-fioccola-spr= ing-flow-label-alt-mark-01 >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-fioccola-sprin= g-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 submis= sion 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 From nobody Tue Nov 7 00:23:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6495613FADD; Tue, 7 Nov 2017 00:23:38 -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 dWlY5mC3v3Vs; Tue, 7 Nov 2017 00:23:35 -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 7874E13FAD4; Tue, 7 Nov 2017 00:23:34 -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=QYjXJIahtZPjJwNwF3sH6Ma9iHz0z1QNJlKE/uh3y5Y=; b=dgJH/95RMkC0v9Vlpm0S/uXAQktBb2NKBIOFgghANJLPDFkMxoHIa8v28aIrKMJQ0VVGqdATTtiLK25ejdFnF7xBjjfFOcFUqGOBVDR9wmq0DmTrtRz3KTCXJ4Lp144rJW+eLOI8Pw7Z3v7ISjRhaZ6gJ44v9L1xOIi/6wRhuvQ= Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB2834.eurprd07.prod.outlook.com (10.168.155.137) 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 08:23:27 +0000 Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 08:23:27 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Mark Smith CC: "v6ops@ietf.org" , "spring@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYwgADfc4CAABjTgIAAFhKAgAABz8A= Date: Tue, 7 Nov 2017 08:23:27 +0000 Message-ID: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [2a02:1810:4d67:a00:e169:dba9:b151:110c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2834; 6:NCTM0wThxzFDOnb1rWr7ieJ0iiLQkQv47WnNVQDgu/Fotw6xFfGCyOLIFI6D/l8gN987QwKHU9Pf0oj3bnYEgzgbdNRPxcgbkb/7mbIaQK1VfKIg/UdJek5LRqRDBqlgrdCGIaFVtiqx6OzXOfY5P2tf6yDEDuMNy1RlV0ClY14DDB6FJGPIZqPoYm7FFyevHBErWzfIuzmZ+D+bj5LPznYwOE2Ko8BjN0UJBBtV3Kj1LgstqL1ctbRdSZz2+KinlXCHIRu8zuHO9q8PTtdpzhrOF4FhWpd9+ySRIEl2eUxlWAIVc0mOxzXsdtMvSc1FpVLIOnGIFToYVg7+QLSO6V50S/4DeDeIrPjd+dvM+RA=; 5:9ps4JQVNyLwgrWKiS8sXPFVcuIRxAvIHbRwS00xxEknl/U3P8bzI8jtqdH7oJQasg012Cp0dobiyAyJZyYzt2m+Ba22I4Pz7Zo1nC4Beq7YsdOgtJsZI+q/bmJ+tCjlDyOLEoyPBtSMgt++HFEAvPPYU1VbQHk545iKWuLDn5D0=; 24:xfvWVwpYjCPb/YnhCn67Dr69q3bGoyJZT06VbK9hbYo1N3NIMW99tKXSktDVULKtDC4kbTRn0FFBwTsOW4c+rVBJqrEzH2yiyPNjIWR4QFw=; 7:eRbGAcSza50LTixZMBRr9ySEKYbc3L4qztTrjbyphSae5JsWzh5A8ak/KtyNnC8O6A29tctvDypnEAEWcfMq3WXE4rxn0qk9BdSrpJCZoP3KLSK1oXHpRvXBjjC2ssc8cO5O9meHR5RCVJLCEd5XpxDTSceBJm+FJFnYnquhddZkN505svWsI2cVeUZH6JsVN6Bj/Rm49UhC/Pmu066GoYVIpBX7Nye7K91BN2ow2nj2IzMKqOX0hwGKdinckbRZ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f68d9258-a5de-4001-7e1c-08d525b8d27c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM5PR0701MB2834; x-ms-traffictypediagnostic: AM5PR0701MB2834: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(82608151540597)(43073073696351)(17755550239193); 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)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2834; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2834; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(189002)(199003)(13464003)(51444003)(24454002)(377424004)(93886005)(7696004)(3280700002)(966005)(2950100002)(230783001)(6436002)(54906003)(2906002)(6506006)(6916009)(14454004)(5250100002)(3660700001)(316002)(5660300001)(25786009)(86362001)(53546010)(5890100001)(4326008)(74316002)(68736007)(9686003)(6306002)(106356001)(6246003)(99286004)(4001150100001)(478600001)(33656002)(1411001)(102836003)(54356999)(305945005)(55016002)(81156014)(97736004)(39060400002)(8676002)(53936002)(7736002)(105586002)(76176999)(229853002)(8936002)(15650500001)(50986999)(189998001)(561944003)(6116002)(101416001)(81166006)(2900100001)(437434002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2834; 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: f68d9258-a5de-4001-7e1c-08d525b8d27c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 08:23:27.6971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2834 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 08:23:38 -0000 TWFyaywNCg0KWWVhaC4uLiB5b3UgbWF5IGJlIHJpZ2h0Li4uIHdlIGFkZGVkIHRoZSBpbnRybyBw YXJ0IHRvIHN0YXJ0IHRoZSBkcmFmdCBiZWNhdXNlIG1lbnRpb25pbmcgdGhlIGNvbnN0cnVjdGlv biAidXNpbmcgRmxvdy1MYWJlbCIgc2VlbXMgdG8gaGF2ZSB0b3hpYyBlbWFpbCBzdG9ybSBlZmZl Y3Qgb24gZW1haWwgbGlzdHMgYXJvdW5kIHY2LiBIZW5jZSB0aGUgZGlzY2xhaW1lcnMgb24gZmxv dy1sYWJlbCB1c2FnZSBhdCB0aGUgc3RhcnQgb2YgdGhlIHRleHQuIE1heWJlIGl0IGlzIHdyb25n bHkgcGxhY2VkIGFuZCBnaXZlcyB0aGUgd3JvbmcgaW1wcmVzc2lvbiBpbmRlZWQuLi4gaXQgaXMg Zm9yIHN1cmUgbm90IHRoZSBpbnRlbnQuLi4gSXQgaXMgb3VyIGludGVudCB0byBzZXQgZmxvdy1s YWJlbCBvbiB0aGUgb3V0ZXIgdHVubmVsIGhlYWRlciwgYW5kIHRoaXMgaXMgZG9uZSBieSB0aGUg cm91dGVyIHdoaWNoIGlzIGltcG9zaW5nIHRoZSBJUHY2IHR1bm5lbCBvdXRlciBoZWFkZXIsIGJ1 dCB3ZSBhcmUgbm90IGZpZGRsaW5nIG9uIHRoZSBmbHkgd2l0aCB0cmFuc2l0IGZsb3ctbGFiZWxz IGF0IGFsbC4gVGhpcyBzZWVtcyBub3QgdG8gYnJlYWsgYW55IElQdjYgcnVsZXMgSSB0aGluay4N Cg0KSG93ZXZlciwgYXMgeW91IHBvaW50IG91dCB0aGUgY2FzZSBvZiBTUnY2IEVIIGluc2VydCwg aXMgYSBkaWZmZXJlbnQgc3RvcnkgYW5kIHJlcXVpcmVzIGEgYml0IG1vcmUgdGhvdWdodC4gSXQg aXMgcG9zc2libGUgYWxzbywgYnV0IG5lZWRzIHRvIHVzZSB0aGUgU1J2NiBPcGFxdWUgdmFsdWUt Y29udGFpbmVycyB0byBjYXJyeSB0aGUgb3JpZ2luYWwgRmxvdy1sYWJlbCBhY3Jvc3MgdGhlIGRv bWFpbiB0byByZWNvbnN0cnVjdCB0aGUgb3JpZ2luYWwgZmxvdy1sYWJlbCB2YWx1ZS4gTmV2ZXJ0 aGVsZXNzLCBSRkM4MjAwIHNlZW1zIHJhdGhlciByZXN0cmljdGl2ZSBvbiBFSCBpbnNlcnRpb24s IGFuZCBoZW5jZSB3ZSBjb252ZW5pZW50bHkgYXNzdW1lZCB0aGF0IGNoYW5jZXMgYXJlIGxvdyBm b3IgaXQgdG8gYmVjb21lIHJlYWxpdHkgZHVlIHRvIElQdjYgc3BlY2lmaWNhdGlvbiBjb21wbGV4 aXRpZXMgYW5kIHdlIGRpc3JlZ2FyZGVkIEVIIGluamVjdC4NCg0KRy8NCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFyayBTbWl0aCBbbWFpbHRvOm1hcmt6enpzbWl0aEBn bWFpbC5jb21dIA0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgNywgMjAxNyAwOTowNA0KVG86IFZh biBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtIEJFL0FudHdlcnApIDxndW50ZXIudmFuX2RlX3Zl bGRlQG5va2lhLmNvbT4NCkNjOiB2Nm9wc0BpZXRmLm9yZzsgc3ByaW5nQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3Y2b3BzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1m aW9jY29sYS1zcHJpbmctZmxvdy1sYWJlbC1hbHQtbWFyay0wMS50eHQNCg0KSGkgR3VudGVyLA0K DQpPbiA3IE5vdmVtYmVyIDIwMTcgYXQgMTc6NTYsIFZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tp YSAtIEJFL0FudHdlcnApIDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4gd3JvdGU6DQo+ IEhpIE1hcmssDQo+DQo+IFRoZSBmbG93IGxhYmVsIG9mIHRoZSBvcmlnaW5hbCBwYWNrZXQgaXMg dW50b3VjaGVkLiBJdCBpcyBuZXZlciBtYW5pcHVsYXRlZCBpbiB0aGlzIHByb3Bvc2FsLiBUaGUg ZmxvdyBsYWJlbCB0aGF0IGlzIHNldCBpbiB0aGlzIHByb3Bvc2FsIGlzIGRvbmUgYXQgdGhlIFNS djYgdHVubmVsLWhlYWQgZW5kIHdoaWNoIGltcG9zZXMgdGhlIFNSdjYgZW5jYXBzdWxhdGlvbiBo ZWFkZXIuIEl0IGlzIHRoaXMgZW5jYXBzdWxhdGlvbiBoZWFkZXIgd2hpY2ggaGFzIHRoZSBmbG93 IGxhYmVsIHdoaWNoIGlzIHVzZWQgaW4gdGhpcyBkcmFmdC4NCj4gU28gYmFzaWNhbGx5LCBpdCBp cyBqdXN0IHRoZSBTUnY2IHR1bm5lbCBvdXRlciBlbmNhcCBoZWFkZXIgd2hpY2ggaXMgdXNlZCBm b3IgYWx0ZXJuYXRlIHBhY2tldCBtYXJraW5nLiBBbmQgdGhpcyBpcyBzZXQgb25seSBvbmUgdGlt ZSBieSB0aGUgb3JpZ2luYWwgU1J2NiB0dW5uZWwgaGVhZC1lbmQgcm91dGVyICh3aGljaCBpcyB0 aGUgc291cmNlIGFkZHJlc3Mgb2YgdGhlIElQdjYgU1J2NiB0dW5uZWwuLi4pLiBUaGlzIG91dGVy IFNSdjYgaGVhZGVyIGlzIHJlbW92ZWQgd2hlbiB0aGUgcGFja2V0IGV4aXRzIHRoZSBTUnY2IGRv bWFpbiwgYW5kIHRoZSBvcmlnaW5hbCBmbG93IGxhYmVsIGFwcGVhcnMgYWdhaW4gdW50b3VjaGVk LiBUaGlzIGRvZXMgbm90IGJyZWFrIGFueSBSRkMgYXQgYWxsIGJlY2F1c2UgYWxsIGJlY2F1c2Ug dGhlIG9yaWdpbmFsIGZsb3ctbGFiZWwgb2YgdGhlIG9yaWdpbmFsIElQdjYgcGFja2V0IGlzIG5l dmVyIHRvdWNoZWQuDQo+DQo+IFNvLCBpbiB0aGlzIHByb3Bvc2FsIHRoZXJlIGlzIG5vIGRldmlj ZSB3aGljaCBpcyBjaGFuZ2luZyBmbG93LWxhYmVscyBhdCBhbGwuIEl0IGlzIG9ubHkgZHVyaW5n IHRoZSBpbXBvc2luZyBvZiB0aGUgU1J2NiBvdXRlciBoZWFkZXIsIHRoYXQgdGhlIGZsb3cgbGFi ZWwgZmllbGQgaXMgc2V0IG9uY2UgZm9yIEFsdGVybmF0ZSBtYXJraW5nIHB1cnBvc2VzIGluc2lk ZSB0aGUgb3V0ZXIgU1J2NiB0dW5uZWwgaGVhZGVyLg0KPg0KPiBIb3BlIGl0IGNsYXJpZmllcz8N Cj4NCg0KSXQgZG9lcywgYWx0aG91Z2ggaXQgc2VlbXMgdG8gYmUgY29udHJhcnkgdG8gcXVpdGUg YSBsb3Qgb2YgdGhlIGludHJvZHVjdGlvbiB0ZXh0Og0KDQoNCiJUaGUgZmxvdyBsYWJlbCBpcyBh biBpbW11dGFibGUgZmllbGQgcmVjb21tZW5kZWQgdG8gY29udGFpbiBhIHBzZXVkby0NCiAgIHJh bmRvbSB2YWx1ZSBbUkZDNjQzN10uICBIb3dldmVyLCBpbiBtb3N0IHBhY2tldHMgaXQgaGFzIHRo ZSBkZWZhdWx0DQogICB2YWx1ZSBvZiB6ZXJvLCBhbHRob3VnaCBzb21lIFRDUC9JUCBzdGFja3Mg ZG8gc2V0IGl0IGFjY29yZGluZyB0bw0KICAgW1JGQzY0MzddLg0KDQogICBbUkZDNjQzNl0gYW5k IFtSRkM2NDM3XSBvcGVuIHRoZSBkb29yIGZvciBJUHY2IEZsb3cgTGFiZWwgdG8gYmUgdXNlZA0K ICAgaW4gY29udHJvbGxlZCBlbnZpcm9ubWVudCwuLi4iDQoNCiJCYXNlZCBvbiB0aGVzZSBjb25z aWRlcmF0aW9ucywgaXQgaXMgYWxsb3dlZCB0byB1c2UgdGhlIGZsb3cgbGFiZWwNCiAgIGZpZWxk IGluIGEgbWFuYWdlZCBkb21haW4sIGFzc3VtaW5nIHdoZW4gYSBwYWNrZXQgbGVhdmVzIHRoZSBk b21haW4sDQogICB0aGUgb3JpZ2luYWwgZmxvdyBsYWJlbCB2YWx1ZSBNVVNUIGJlIHJlc3RvcmVk LiINCg0KYW5kIHRoZSBsYXRlciByZWZlcmVuY2UgdG8NCiJbSS1ELnZveWVyLTZtYW4tZXh0ZW5z aW9uLWhlYWRlci1pbnNlcnRpb25dIiBhbGwgc2VlbXMgdG8gYmUgc2V0dGluZyB1cCBhIGNhc2Ug dG8ganVzdGlmeSBtb2RpZnlpbmcgdGhlIG9yaWdpbmFsIHBhY2tldCdzIGZsb3cgbGFiZWwgdmFs dWUgYW5kIHRoZW4gcmVzdG9yaW5nIGl0IHVzaW5nIHRoZSBvcmlnaW5hbCB2YWx1ZSB0aGF0IGhh cyBiZWVuIHNvbWVob3cgc2VudCBvciBzaWduYWxsZWQgdG8gdGhlIG5ldHdvcmsgZWdyZXNzLg0K DQpBcyB5b3UndmUgc2FpZCwgd2hlbiB0dW5uZWxsaW5nLCB0aGUgb3JpZ2luYWwgcGFja2V0IGFu ZCBpdHMgZmxvdyBsYWJlbCB2YWx1ZSBpcyBlbnRpcmVseSBwcmVzZXJ2ZWQsIHNvIHRoZXJlIGRv ZXNuJ3QgbmVlZCB0byBiZSBhbnkgb2YgdGhlIGFib3ZlIHRleHQuIEV2ZW4gdGhlIHRleHQgYWJv dXQgaG9zdHMgbm90IHNldHRpbmcgdGhlIEZMIHZhbHVlIGlzbid0IHJlYWxseSBuZWNlc3Nhcnks IGFzIHR1bm5lbCBlbmQtcG9pbnRzLCBhcyBhIGZ1bmN0aW9uIGF0IHRoZQ0KSVB2NiBsYXllciwg YXJlIGhvc3RzIHRoYXQgb3JpZ2luYXRlIHBhY2tldHMsIHNvIHRoZXkgY2FuIHNldCB0aGUgRkwg dmFsdWUgdG8gd2hhdCBldmVyIHRoZXkgbGlrZSBiZWNhdXNlIHRoZXkncmUgb3JpZ2luYXRpbmcg dGhlICh0dW5uZWwpIHBhY2tldC4NCg0KDQpJIHRoaW5rIGl0IG1pZ2h0IGJlIGJldHRlciB0byBh dm9pZCB1c2luZyB0d28gb2YgdGhlIEZMIGJpdHMgdG8gZW5jb2RlIHRoZSBtYXJraW5nIG1ldGhv ZCwgYXMgdGhhdCBhbHNvIGRldmlhdGVzIGZyb20gUkZDNjQzNyAoSSBzZWVtIHRvIHJlbWVtYmVy IHdlIGFsc28gdGhvdWdodCBhYm91dCB1c2luZyBzb21lIGJpdHMgaW4gdGhlIEZMIHRvIGVuY29k ZSBzb21ldGhpbmcgZHVyaW5nIHRoYXQgdGltZSwgYW5kIGFsc28gYWJhbmRvbmVkIGl0LikNCg0K SSdtIG5vdCBhY3Jvc3MgdGhlIEFsdGVybmF0ZSBNYXJraW5nIE1ldGhvZCB3b3JrLCBzbyB0aGlz IG1pZ2h0IGJlIGEgZHVtYiBxdWVzdGlvbiBvciBzdWdnZXN0aW9uLiBXaXRoaW4gYSBtZWFzdXJl bWVudCBkb21haW4sIGlzIHRoZXJlIGV2ZXIgZ29pbmcgdG8gYmUgYSBtaXggb2Ygc2luZ2xlIGFu ZCBkb3VibGUgbWFya2luZywgc3VjaCB0aGF0IGl0IG5lZWRzIHRvIGJlIGVuY29kZWQgcGVyLXBh Y2tldD8gSWYgYSBkb21haW4gY2FuIG9ubHkgc3VwcG9ydCBvbmUgb2YgdGhlbSBhdCBhbnkgb25l IHRpbWUsIHRoZW4gSSB0aGluayB0aGF0IGNvdWxkIGJlIGVuY29kZWQgaW4gdGhlIGNvbmZpZ3Vy YXRpb24gb2YgdGhlIFNSdjYgdHVubmVsIGVuZCBwb2ludHMsIHJhdGhlciB0aGFuIGVuY29kaW5n IGl0IGluIGEgY291cGxlIG9mIHRoZSBGTCBiaXRzLg0KDQpBbHNvLCB0aGVyZSBpcyBub3cgYW4g SVB2NiBQZXJmb3JtYW5jZSBhbmQgRGlhZ25vc3RpY3MgRGVzdGluYXRpb24gT3B0aW9uIHdoaWNo IG1heSBiZSBhIElQdjYgY29udmVudGlvbmFsIHdheSBvZiBlbmNvZGluZyB0aGlzIG1hcmtpbmcg b3IgbWVhc3VyZW1lbnQgaW5mb3JtYXRpb24gaW4gdGhlIG91dGVyIElQdjYgdHVubmVsIGhlYWRl ciAoaS5lLg0KW091dGVyIElQdjYgSERSXVtQRE1dW0lubmVyL09yaWdpbmFsIElQdjYgUGFja2V0 XSkNCg0KIklQdjYgUGVyZm9ybWFuY2UgYW5kIERpYWdub3N0aWMgTWV0cmljcyAoUERNKSBEZXN0 aW5hdGlvbiBPcHRpb24iDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODI1MA0KDQpS ZWdhcmRzLA0KTWFyay4NCg0KDQo+IEcvDQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IE1hcmsgU21pdGggW21haWx0bzptYXJrenp6c21pdGhAZ21haWwuY29t XQ0KPiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciA3LCAyMDE3IDA2OjE2DQo+IFRvOiBWYW4gRGUg VmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKSANCj4gPGd1bnRlci52YW5fZGVfdmVs ZGVAbm9raWEuY29tPg0KPiBDYzogdjZvcHNAaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW3Y2b3BzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4g ZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0LW1hcmstMDEudHh0DQo+DQo+IE9u IDcgTm92ZW1iZXIgMjAxNyBhdCAwMjo1OSwgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0g QkUvQW50d2VycCkgPGd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tPiB3cm90ZToNCj4+IElm IGFueSBmZWVkYmFjayBvciBjb21tZW50cyAocHJlZmVyYWJseSBjb25zdHJ1Y3RpdmUpLCB0aGVu IHBsZWFzZSANCj4+IGhhdmUgdGhlIGRpc2N1c3Npb24gaW5jbHVkaW5nIFNQUklORyBXRyBpbiBj Yw0KPj4NCj4NCj4gU28gdGhpcyBkcmFmdCwgc2ltaWxhciB0byB0aGUgSVB2NiBFSCBpbnNlcnRp b24gZHJhZnQsIGRvZXNuJ3QgYW5zd2VyIHRoZSBmdW5kYW1lbnRhbCBxdWVzdGlvbiBvZiB3aHku DQo+DQo+IFdoYXQgdGVjaG5pY2FsIGFuZCBlbmdpbmVlcmluZyByZWFzb25zIGp1c3RpZnkgcmV1 c2luZyB0aGUgZmxvdyBsYWJlbCBmaWVsZCwgY29udHJhcnkgdG8gaXRzIHNwZWNpZmljYXRpb24/ IFdoYXQgYWx0ZXJuYXRpdmVzIHdlcmUgY29uc2lkZXJlZCB0aGF0IGRvbid0IHZpb2xhdGUgdGhl IHRoZSBmbG93IGxhYmVsIHNwZWNpZmljYXRpb24sIGFuZCB3aHkgYXJlIHRoZWlyIGRyYXdiYWNr cyBzbyBzaWduaWZpY2FudCB0aGF0IHRoZXkganVzdGlmeSBpZ25vcmluZyB0aGUgZmxvdyBsYWJl bCBzcGVjaWZpY2F0aW9uPyBVc2Ugb2YgSVB2NiBmaWVsZHMgY2FuIGJlIG5vdmVsLCBob3dldmVy IHRoZSBub3ZlbHR5IGhhcyB0byBmaXQgd2l0aGluIHRoZSBzcGVjaWZpY2F0aW9ucyB0byBlbnN1 cmUgaW50ZXJvcGVyYWJpbGl0eS4NCj4NCj4gIltSRkM2NDM2XSBhbmQgW1JGQzY0MzddIG9wZW4g dGhlIGRvb3IgZm9yIElQdjYgRmxvdyBMYWJlbCB0byBiZSB1c2VkDQo+ICAgIGluIGNvbnRyb2xs ZWQgZW52aXJvbm1lbnQsIg0KPg0KPiBJJ20gc3VyZSBpdCBkb2Vzbid0LiBEdXJpbmcgdGhlIG9y aWdpbmFsIGRpc2N1c3Npb25zIHRoYXQgcmVzdWx0ZWQgaW4gUkZDNjQzNywgSSBzdWdnZXN0ZWQg dGhlIGlkZWEgb2YgRmxvdyBMYWJlbCBkb21haW5zIHNpbWlsYXIgdG8gRFNDUCBkb21haW5zLiBJ dCB3YXMgaWdub3JlZCBmb3IgdmFsaWQgcmVhc29ucy4gVGhpcyBpcyB0aGUgZGlzY3Vzc2lvbiBt ZW50aW9uZWQgaW4gdGhlIGZpcnN0IHBhcmFncmFwaCBvZiBhcHBlbmRpeCBBIGluIFJGQzY0MzYu DQo+DQo+ICJBIG1vZGVsIHdhcyBkaXNjdXNzZWQgaW4gYW4gZWFybGllciB2ZXJzaW9uIG9mIHRo aXMgZG9jdW1lbnQgd2hpY2gNCj4gICAgZGVmaW5lZCBhIG5vdGlvbiBvZiAnZmxvdyBsYWJlbCBk b21haW4nIGFuYWxvZ291cyB0byBhIGRpZmZlcmVudGlhdGVkDQo+ICAgIHNlcnZpY2VzIGRvbWFp biBbUkZDMjQ3NF0uICBUaGlzIG1vZGVsIHdvdWxkIGhhdmUgZW5jb3VyYWdlZCBsb2NhbA0KPiAg ICB1c2FnZSBvZiB0aGUgZmxvdyBsYWJlbCBhcyBhbiBhbHRlcm5hdGl2ZSB0byBhbnkgZm9ybSBv ZiBnZW5lcmljIHVzZSwNCj4gICAgYnV0IGl0IHJlcXVpcmVkIGNvbXBsZXggcnVsZXMgZm9yIHRo ZSBiZWhhdmlvciBvZiBkb21haW4gYm91bmRhcnkNCj4gICAgcm91dGVycywgYW5kIHByb3ZlZCBj b250cm92ZXJzaWFsIGluIGRpc2N1c3Npb24uIg0KPg0KPg0KPiBIZXJlJ3Mgd2hhdCB0aGUgZmxv dyBsYWJlbCBzcGVjaWZpY2F0aW9uIFJGQyBzYXlzLA0KPg0KPiAiT25jZSBzZXQgdG8gYSBub24t emVybyB2YWx1ZSwgdGhlIEZsb3cgTGFiZWwgaXMgZXhwZWN0ZWQgdG8gYmUNCj4gICAgZGVsaXZl cmVkIHVuY2hhbmdlZCB0byB0aGUgZGVzdGluYXRpb24gbm9kZShzKS4gIEEgZm9yd2FyZGluZyBu b2RlDQo+ICAgIE1VU1QgZWl0aGVyIGxlYXZlIGEgbm9uLXplcm8gZmxvdyBsYWJlbCB2YWx1ZSB1 bmNoYW5nZWQgb3IgY2hhbmdlIGl0DQo+ICAgIG9ubHkgZm9yIGNvbXBlbGxpbmcgb3BlcmF0aW9u YWwgc2VjdXJpdHkgcmVhc29ucyBhcyBkZXNjcmliZWQgaW4NCj4gICAgU2VjdGlvbiA2LjEiDQo+ DQo+IEkgZG9uJ3QgdGhpbmsgdGhlIHVzZSBpbiB0aGlzIGRyYWZ0IGlzIGEgImNvbXBlbGxpbmcg b3BlcmF0aW9uYWwgc2VjdXJpdHkgcmVhc29uIi4NCj4NCj4gQSBuZXR3b3JrIGNhbiBoYXZlIGEg bnVtYmVyIG9mIGVncmVzcyBwb2ludHMuIFRvIGJlIGFibGUgdG8gcmVzdG9yZSBmbG93IGxhYmVs IHZhbHVlcyB1cG9uIGVncmVzcywgZWl0aGVyIGFsbCBvZiB0aGUgZmxvdyBsYWJlbCByZXN0b3Jh dGlvbiBzdGF0ZSBmb3IgYWxsIGluLWZsaWdodCBwYWNrZXRzJyBmbG93IGxhYmVsIHZhbHVlcyB3 aWxsIGhhdmUgdG8gYmUga2VwdCBzeW5jaHJvbmlzZWQgYXQgYWxsIG9mIHRoZSBlZ3Jlc3MgcG9p bnRzLCBvciBrZXB0IHN5bmNocm9uaXNlZCBpbiBhY2NvcmRhbmNlIHdpdGggd2hlcmUgdGhlIHJv dXRpbmcgcHJvdG9jb2wgZGV0ZXJtaW5lcyBpcyB0aGUgY3VycmVudCBlZ3Jlc3MgcG9pbnQgZm9y IHRoZSBwYWNrZXQuDQo+DQo+IEluIHRoaXMgbGF0dGVyIGNhc2UsIHdoaWxlIGluIGZsaWdodCwg dGhlIGVncmVzcyBwb2ludCBjb3VsZCBjaGFuZ2UsIG1lYW5pbmcgdGhlIHBhY2tldCdzIGVncmVz cyBwYXRoIGNoYW5nZXMsIGFuZCB0aGVyZSB0aGVuIG9jY3VycyBhIHJhY2UgYmV0d2VlbiB3aGVu IHRoZSBwYWNrZXQgcmVhY2hlcyB0aGUgZXhpdCBwb2ludCBhbmQgdGhlIGZsb3cgbGFiZWwgcmVz dG9yYXRpb24gc3RhdGUgZm9yIHRoYXQgcGFja2V0IHJlYWNoZXMgdGhhdCBlZ3Jlc3MgcG9pbnQg c28gdGhhdCBpdCBjYW4gYmUgcmVzdG9yZWQuDQo+DQo+IFNvIGFyZSBwYWNrZXRzIGdvaW5nIHRv IGJlIGhlbGQvZGVsYXllZCB1cG9uIGluZ3Jlc3Mgc3VjaCB0aGF0IHRoZXkgY2FuIG5ldmVyIHJl YWNoIHRoZSBlZ3Jlc3MgcG9pbnQgYmVmb3JlIHRoZWlyIG9yaWdpbmFsIGZsb3cgbGFiZWwgdmFs dWUgaW5mb3JtYXRpb24gcmVhY2hlcyB0aGF0IGVncmVzcyBwb2ludCBmaXJzdD8gSWYgdGhleSdy ZSBub3QsIHRoZW4gdGhlcmUgaXMgbm8gYXNzdXJhbmNlIHRoYXQgdGhlIG9yaWdpbmFsIGZsb3cg bGFiZWwgdmFsdWUgY2FuIGJlIHJlc3RvcmVkLCBhbmQgdGhlIGRvbWFpbiBpc24ndCBjbG9zZWQg YW55bW9yZS4gVGhlIG1vZGlmaWVkIHBhY2tldCBsZWF2ZXMgdGhlICJjbG9zZWQgZG9tYWluIiB3 aXRoIHRoZSBtb2RpZmljYXRpb24gdW5yZXN0b3JlZC4NCj4NCj4NCj4gIlRoZSBJUHY2IHByb3Rv Y29sIGluY2x1ZGVzIGEgZmxvdyBsYWJlbCBpbiBldmVyeSBwYWNrZXQNCj4gICAgaGVhZGVyLCBi dXQgdGhpcyBmaWVsZCBpcywgYWNjb3JkaW5nIHRvIFtSRkM2Mjk0XSwgbm90IHVzZWQgaW4NCj4g ICAgcHJhY3RpY2UuIg0KPg0KPiBSRkM2Mjk0IHdhcyBwdWJsaXNoZWQgaW4gMjAxMSwgNiB5ZWFy cyBhZ28uIEltcGxlbWVudGF0aW9ucyBoYXZlIGNoYW5nZWQgc2luY2UgdGhlbi4NCj4NCj4gVGhl IExpbnV4IGtlcm5lbCBpcyBzZXR0aW5nIGZsb3cgbGFiZWwgdmFsdWVzIHBlciBSRkM2NDM3IHBl ciBUb20gSGVyYmVydCdzIExpbnV4IGtlcm5lbCBwYXRjaCBpbiB0aGUgb3JkZXIgb2YgMiB5ZWFy cyBhZ28uDQo+DQo+IFJhbmRvbSBmbG93IGxhYmVscyBsb29rIHRvIGJlIGFsc28gYmVpbmcgc2V0 IGJ5IE1hYyBPUyBYIGFyb3VuZCB0aGUgDQo+IHNhbWUgdGltZSAoSnVseSAyMDE1KSAtDQo+DQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaXB2Ni9jdXJyZW50L21zZzIy ODIwLmh0bWwNCj4NCj4gV2luZG93cyB3YXMgdGhlIG1ham9yIGhvbGQgb3V0IC0gdGhlIGxhdGVz dCBXaW5kb3dzIDEwIENyZWF0ZXIgVXBkYXRlIGlzIG5vdyBzZXR0aW5nIEZsb3cgTGFiZWxzLg0K Pg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lwdjYvY3VycmVudC9t c2cyMjgyMC5odG1sDQo+DQo+DQo+IEl0IHNlZW1zIHBlb3BsZSBhcmUgc3RhcnRpbmcgdG8gYmVs aWV2ZSAiY2xvc2VkIGRvbWFpbnMiIGNhbiBiZSB1c2VkIHRvIGp1c3RpZnkgbW9kaWZ5aW5nIHBh Y2tldHMgaW4gZmxpZ2h0LCBpbiBhbnkgd2F5IHRoZXknZCBsaWtlIHRvIG1vZGlmeSB0aGVtLiBJ biB0aGVvcnkgYW5kIGluIHNwZWNpZmljYXRpb25zLCB0aGUgbW9kaWZpY2F0aW9ucyBhcmUgZ3Vh cmFudGVlZCB0byBiZSByZXZlcnNlZCBhdCBlZ3Jlc3MsIGluIHByYWN0aWNlLCBjb250cmFyeSB0 byBzcGVjaWZpY2F0aW9ucywgaW1wbGVtZW50YXRpb25zIGFuZCBuZXR3b3JrIG9wZXJhdGlvbnMg YXJlIG5vdCBndWFyYW50ZWVkIGFuZCBwZXJmZWN0LiBUaGUgcmV2ZXJzYWwgbWF5IG5vdCBvY2N1 ciBhdCBlZ3Jlc3MgZHVlIHRvIGltcGxlbWVudGF0aW9uIGJ1Z3MsIHBhcnRpYWwgZGV2aWNlIGZh aWx1cmVzIG9yIG9wZXJhdG9yIGNvbmZpZ3VyYXRpb24gZXJyb3Igb3Igb21pc3Npb24uIFRoZXNl IHNvcnRzIG9mIGluLWZsaWdodCBjaGFuZ2VzIGFyZSBub3QgY29uc2VydmF0aXZlLCBtYWtpbmcg dGhlbSBjb250cmFyeSB0byB0aGUgUm9idXN0bmVzcyBQcmluY2lwbGUuDQo+DQo+IEFzIHNob3du IGJ5IFJGQzE5MTggYWRkcmVzcyBhbmQgcm91dGUgbGVha3MsICJjbG9zZWQgZG9tYWlucyIgYXR0 YWNoZWQgdG8gdGhlIEludGVybmV0IGFyZW4ndCBndWFyYW50ZWVkIHRvIGJlIGNsb3NlZC4gQSBj bG9zZWQgZG9tYWluIG5ldHdvcmsgY2FuIG9ubHkgYmUgdHJ1bHkgY2xvc2VkIG9mZiBmcm9tIHRo ZSBJbnRlcm5ldCBpZiBpdCBpcyBjb21wbGV0ZWx5IGlzb2xhdGVkIHdpdGggYW4gYWlyIGdhcC4N Cj4NCj4NCj4gUmVnYXJkcywNCj4gTWFyay4NCj4NCj4+IEcvDQo+Pg0KPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI2 LCAyMDE3IDE2OjM1DQo+PiBUbzogR2l1c2VwcGUgRmlvY2NvbGEgPGdpdXNlcHBlLmZpb2Njb2xh QHRlbGVjb21pdGFsaWEuaXQ+OyBWYW4gRGUgDQo+PiBWZWxkZSwgR3VudGVyIChOb2tpYSAtIEJF L0FudHdlcnApIDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT47IA0KPj4gTXVsZXksIFBy YXZlZW4gKE5va2lhIC0gVVMvTW91bnRhaW4gVmlldykgPHByYXZlZW4ubXVsZXlAbm9raWEuY29t PjsgDQo+PiBNYXVybyBDb2NpZ2xpbyA8bWF1cm8uY29jaWdsaW9AdGVsZWNvbWl0YWxpYS5pdD4N Cj4+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+PiBkcmFmdC1maW9j Y29sYS1zcHJpbmctZmxvdy1sYWJlbC1hbHQtbWFyay0wMS50eHQNCj4+DQo+Pg0KPj4gQSBuZXcg dmVyc2lvbiBvZiBJLUQsIA0KPj4gZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0 LW1hcmstMDEudHh0DQo+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEdpdXNl cHBlIEZpb2Njb2xhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4+DQo+PiBO YW1lOiAgICAgICAgICAgZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0LW1hcmsN Cj4+IFJldmlzaW9uOiAgICAgICAwMQ0KPj4gVGl0bGU6ICAgICAgICAgIFVzaW5nIHRoZSBJUHY2 IEZsb3cgTGFiZWwgZm9yIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IHdpdGggQWx0ZXJuYXRlIE1h cmtpbmcgTWV0aG9kIGluIFNlZ21lbnQgUm91dGluZw0KPj4gRG9jdW1lbnQgZGF0ZTogIDIwMTct MTAtMjYNCj4+IEdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+IFBhZ2Vz OiAgICAgICAgICA4DQo+PiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJrLTAx LnR4dA0KPj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJrLw0KPj4gSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1maW9jY29sYS1zcHJpbmct Zmxvdy1sYWJlbC1hbHQtbWFyay0wMQ0KPj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwt YWx0LW1hcmstMDENCj4+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0LW1hcmstMDENCj4+ DQo+PiBBYnN0cmFjdDoNCj4+ICAgIFtSRkM2Mjk0XSBtYWtlcyBhIHN1cnZleSBvZiBQcm9wb3Nl ZCBVc2UgQ2FzZXMgZm9yIHRoZSBJUHY2IEZsb3cNCj4+ICAgIExhYmVsLiAgVGhlIElQdjYgcHJv dG9jb2wgaW5jbHVkZXMgYSBmbG93IGxhYmVsIGluIGV2ZXJ5IHBhY2tldA0KPj4gICAgaGVhZGVy LCBidXQgdGhpcyBmaWVsZCBpcywgYWNjb3JkaW5nIHRvIFtSRkM2Mjk0XSwgbm90IHVzZWQgaW4N Cj4+ICAgIHByYWN0aWNlLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRoZSBhbHRlcm5h dGUgbWFya2luZyBtZXRob2QNCj4+ICAgIGNhbiBiZSB1c2VkIGFzIHRoZSBwYXNzaXZlIHBlcmZv cm1hbmNlIG1lYXN1cmVtZW50IG1ldGhvZCBpbiBhIElQdjYNCj4+ICAgIGRvbWFpbi4NCj4+DQo+ Pg0KPj4NCj4+DQo+Pg0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4NCj4+ IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IHY2b3BzIG1haWxpbmcgbGlzdA0KPj4gdjZvcHNAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Tue Nov 7 03:59:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E88D13FE31; Tue, 7 Nov 2017 03: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, 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 slOCdV7x7zdx; Tue, 7 Nov 2017 03:59:17 -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 C688813FE34; Tue, 7 Nov 2017 03:59:16 -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 C77F080309; Tue, 7 Nov 2017 12:59:12 +0100 (CET) To: Mark Smith , "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" , "spring@ietf.org" References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> From: Fernando Gont Message-ID: <76b93707-d269-5541-99f1-7a5679d0d72d@gont.com.ar> Date: Tue, 7 Nov 2017 08:17: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: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 11:59:19 -0000 On 11/07/2017 05:03 AM, Mark Smith wrote: > Hi Gunter, > > On 7 November 2017 at 17:56, Van De Velde, Gunter (Nokia - BE/Antwerp) > wrote: >> Hi Mark, >> >> The flow label of the original packet is untouched. It is never manipulated in this proposal. The flow label that is set in this proposal is done at the SRv6 tunnel-head end which imposes the SRv6 encapsulation header. It is this encapsulation header which has the flow label which is used in this draft. >> So basically, it is just the SRv6 tunnel outer encap header which is used for alternate packet marking. And this is set only one time by the original SRv6 tunnel head-end router (which is the source address of the IPv6 SRv6 tunnel...). This outer SRv6 header is removed when the packet exits the SRv6 domain, and the original flow label appears again untouched. This does not break any RFC at all because all because the original flow-label of the original IPv6 packet is never touched. >> >> So, in this proposal there is no device which is changing flow-labels at all. It is only during the imposing of the SRv6 outer header, that the flow label field is set once for Alternate marking purposes inside the outer SRv6 tunnel header. >> >> Hope it clarifies? >> > > It does, although it seems to be contrary to quite a lot of the > introduction text: > > > "The flow label is an immutable field recommended to contain a pseudo- > random value [RFC6437]. However, in most packets it has the default > value of zero, although some TCP/IP stacks do set it according to > [RFC6437]. > > [RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used > in controlled environment,..." > > "Based on these considerations, it is allowed to use the flow label > field in a managed domain, assuming when a packet leaves the domain, > the original flow label value MUST be restored." Maybe this comes from the time when SR considered header insertion? Anyway, I agree that the text should be modified in this respect, since, as Gunter noted, there's no FL being modified, since it's a new (encapsulating) packet. FWIW, I also think that references to header insertion should be eliminated (including pointers to individual submissions that propose that), since RFC8200 does not allow it. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Tue Nov 7 03:59:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD94E13FE48; Tue, 7 Nov 2017 03:59:36 -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 TOn74Fl55iuV; Tue, 7 Nov 2017 03:59:30 -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 03D1B13FE42; Tue, 7 Nov 2017 03:59:29 -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 CA8BC80309; Tue, 7 Nov 2017 12:59:25 +0100 (CET) To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Mark Smith Cc: "v6ops@ietf.org" , "spring@ietf.org" References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> From: Fernando Gont Message-ID: Date: Tue, 7 Nov 2017 08:21:01 -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: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 11:59:37 -0000 On 11/07/2017 05:23 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Mark, > > Yeah... you may be right... we added the intro part to start the draft because mentioning the construction "using Flow-Label" seems to have toxic email storm effect on email lists around v6. Hence the disclaimers on flow-label usage at the start of the text. Maybe it is wrongly placed and gives the wrong impression indeed... it is for sure not the intent... It is our intent to set flow-label on the outer tunnel header, and this is done by the router which is imposing the IPv6 tunnel outer header, but we are not fiddling on the fly with transit flow-labels at all. This seems not to break any IPv6 rules I think. My take: Make that as explicit as here, and I bet there will be no need to discuss further 8fingers crossed :-) ). > However, as you point out the case of SRv6 EH insert, is a different story and requires a bit more thought. It is possible also, but needs to use the SRv6 Opaque value-containers to carry the original Flow-label across the domain to reconstruct the original flow-label value. Nevertheless, RFC8200 seems rather restrictive on EH insertion, and hence we conveniently assumed that chances are low for it to become reality due to IPv6 specification complexities and we disregarded EH inject. Same here: If EH insertion is not allowed, it shouldn't even be mentioned. If eventually it is allowed, a new (possibly updating this one) doc could address the topic. Thanks! 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 Tue Nov 7 06:23:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3336913FE40; Tue, 7 Nov 2017 06:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_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=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOVpj6PDFPFY; Tue, 7 Nov 2017 06:23:16 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C031C13FDD1; Tue, 7 Nov 2017 06:23:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A732F5C460C; Tue, 7 Nov 2017 06:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1510064596; bh=OkxKCXyFM7F+dUdIXCC1v7hdzW9aiCrdrJYdkdB+6VA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BtFCCmd5Ajro2pZf7uhwnLC1WDNnHLerVz1cBPvqSmhcSHuynUxHr0NkLNaAxowLW 2scqJuEMHmz6f0wMZW77KpypyzhhNDuQHq/ERWIh+YeEqHLBB1iK2kLY3B6WSoCAe4 UlO6LkJ5afI2A34PjwvIplQJZfHSZwl3yJbOwXSg= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id A16065C4605; Tue, 7 Nov 2017 06:23:15 -0800 (PST) To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Mark Smith Cc: "v6ops@ietf.org" , "spring@ietf.org" References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <38d33b00-04ee-a3be-a0c3-8377c90458cc@joelhalpern.com> Date: Tue, 7 Nov 2017 09:23:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; 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 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 14:23:19 -0000 Is there an implicit assumption that ALL traffic in a domain will be using SRv6 encapulating headers? If not, then how will devices know whether they can mark the "ecn bits" of the flow label" on a particular packet? If you are assuming complete deployment, how is that practical for operational networks? Yours, Joel On 11/7/17 3:23 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Mark, > > Yeah... you may be right... we added the intro part to start the draft because mentioning the construction "using Flow-Label" seems to have toxic email storm effect on email lists around v6. Hence the disclaimers on flow-label usage at the start of the text. Maybe it is wrongly placed and gives the wrong impression indeed... it is for sure not the intent... It is our intent to set flow-label on the outer tunnel header, and this is done by the router which is imposing the IPv6 tunnel outer header, but we are not fiddling on the fly with transit flow-labels at all. This seems not to break any IPv6 rules I think. > > However, as you point out the case of SRv6 EH insert, is a different story and requires a bit more thought. It is possible also, but needs to use the SRv6 Opaque value-containers to carry the original Flow-label across the domain to reconstruct the original flow-label value. Nevertheless, RFC8200 seems rather restrictive on EH insertion, and hence we conveniently assumed that chances are low for it to become reality due to IPv6 specification complexities and we disregarded EH inject. > > G/ > > > -----Original Message----- > From: Mark Smith [mailto:markzzzsmith@gmail.com] > Sent: Tuesday, November 7, 2017 09:04 > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > Cc: v6ops@ietf.org; spring@ietf.org > Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt > > Hi Gunter, > > On 7 November 2017 at 17:56, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: >> Hi Mark, >> >> The flow label of the original packet is untouched. It is never manipulated in this proposal. The flow label that is set in this proposal is done at the SRv6 tunnel-head end which imposes the SRv6 encapsulation header. It is this encapsulation header which has the flow label which is used in this draft. >> So basically, it is just the SRv6 tunnel outer encap header which is used for alternate packet marking. And this is set only one time by the original SRv6 tunnel head-end router (which is the source address of the IPv6 SRv6 tunnel...). This outer SRv6 header is removed when the packet exits the SRv6 domain, and the original flow label appears again untouched. This does not break any RFC at all because all because the original flow-label of the original IPv6 packet is never touched. >> >> So, in this proposal there is no device which is changing flow-labels at all. It is only during the imposing of the SRv6 outer header, that the flow label field is set once for Alternate marking purposes inside the outer SRv6 tunnel header. >> >> Hope it clarifies? >> > > It does, although it seems to be contrary to quite a lot of the introduction text: > > > "The flow label is an immutable field recommended to contain a pseudo- > random value [RFC6437]. However, in most packets it has the default > value of zero, although some TCP/IP stacks do set it according to > [RFC6437]. > > [RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used > in controlled environment,..." > > "Based on these considerations, it is allowed to use the flow label > field in a managed domain, assuming when a packet leaves the domain, > the original flow label value MUST be restored." > > and the later reference to > "[I-D.voyer-6man-extension-header-insertion]" all seems to be setting up a case to justify modifying the original packet's flow label value and then restoring it using the original value that has been somehow sent or signalled to the network egress. > > As you've said, when tunnelling, the original packet and its flow label value is entirely preserved, so there doesn't need to be any of the above text. Even the text about hosts not setting the FL value isn't really necessary, as tunnel end-points, as a function at the > IPv6 layer, are hosts that originate packets, so they can set the FL value to what ever they like because they're originating the (tunnel) packet. > > > I think it might be better to avoid using two of the FL bits to encode the marking method, as that also deviates from RFC6437 (I seem to remember we also thought about using some bits in the FL to encode something during that time, and also abandoned it.) > > I'm not across the Alternate Marking Method work, so this might be a dumb question or suggestion. Within a measurement domain, is there ever going to be a mix of single and double marking, such that it needs to be encoded per-packet? If a domain can only support one of them at any one time, then I think that could be encoded in the configuration of the SRv6 tunnel end points, rather than encoding it in a couple of the FL bits. > > Also, there is now an IPv6 Performance and Diagnostics Destination Option which may be a IPv6 conventional way of encoding this marking or measurement information in the outer IPv6 tunnel header (i.e. > [Outer IPv6 HDR][PDM][Inner/Original IPv6 Packet]) > > "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option" > https://tools.ietf.org/html/rfc8250 > > Regards, > Mark. > > >> G/ >> >> >> >> -----Original Message----- >> From: Mark Smith [mailto:markzzzsmith@gmail.com] >> Sent: Tuesday, November 7, 2017 06:16 >> To: Van De Velde, Gunter (Nokia - BE/Antwerp) >> >> Cc: v6ops@ietf.org; spring@ietf.org >> Subject: Re: [v6ops] FW: New Version Notification for >> draft-fioccola-spring-flow-label-alt-mark-01.txt >> >> On 7 November 2017 at 02:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: >>> If any feedback or comments (preferably constructive), then please >>> have the discussion including SPRING WG in cc >>> >> >> So this draft, similar to the IPv6 EH insertion draft, doesn't answer the fundamental question of why. >> >> What technical and engineering reasons justify reusing the flow label field, contrary to its specification? What alternatives were considered that don't violate the the flow label specification, and why are their drawbacks so significant that they justify ignoring the flow label specification? Use of IPv6 fields can be novel, however the novelty has to fit within the specifications to ensure interoperability. >> >> "[RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used >> in controlled environment," >> >> I'm sure it doesn't. During the original discussions that resulted in RFC6437, I suggested the idea of Flow Label domains similar to DSCP domains. It was ignored for valid reasons. This is the discussion mentioned in the first paragraph of appendix A in RFC6436. >> >> "A model was discussed in an earlier version of this document which >> defined a notion of 'flow label domain' analogous to a differentiated >> services domain [RFC2474]. This model would have encouraged local >> usage of the flow label as an alternative to any form of generic use, >> but it required complex rules for the behavior of domain boundary >> routers, and proved controversial in discussion." >> >> >> Here's what the flow label specification RFC says, >> >> "Once set to a non-zero value, the Flow Label is expected to be >> delivered unchanged to the destination node(s). A forwarding node >> MUST either leave a non-zero flow label value unchanged or change it >> only for compelling operational security reasons as described in >> Section 6.1" >> >> I don't think the use in this draft is a "compelling operational security reason". >> >> A network can have a number of egress points. To be able to restore flow label values upon egress, either all of the flow label restoration state for all in-flight packets' flow label values will have to be kept synchronised at all of the egress points, or kept synchronised in accordance with where the routing protocol determines is the current egress point for the packet. >> >> In this latter case, while in flight, the egress point could change, meaning the packet's egress path changes, and there then occurs a race between when the packet reaches the exit point and the flow label restoration state for that packet reaches that egress point so that it can be restored. >> >> So are packets going to be held/delayed upon ingress such that they can never reach the egress point before their original flow label value information reaches that egress point first? If they're not, then there is no assurance that the original flow label value can be restored, and the domain isn't closed anymore. The modified packet leaves the "closed domain" with the modification unrestored. >> >> >> "The IPv6 protocol includes a flow label in every packet >> header, but this field is, according to [RFC6294], not used in >> practice." >> >> RFC6294 was published in 2011, 6 years ago. Implementations have changed since then. >> >> The Linux kernel is setting flow label values per RFC6437 per Tom Herbert's Linux kernel patch in the order of 2 years ago. >> >> Random flow labels look to be also being set by Mac OS X around the >> same time (July 2015) - >> >> https://www.ietf.org/mail-archive/web/ipv6/current/msg22820.html >> >> Windows was the major hold out - the latest Windows 10 Creater Update is now setting Flow Labels. >> >> https://www.ietf.org/mail-archive/web/ipv6/current/msg22820.html >> >> >> It seems people are starting to believe "closed domains" can be used to justify modifying packets in flight, in any way they'd like to modify them. In theory and in specifications, the modifications are guaranteed to be reversed at egress, in practice, contrary to specifications, implementations and network operations are not guaranteed and perfect. The reversal may not occur at egress due to implementation bugs, partial device failures or operator configuration error or omission. These sorts of in-flight changes are not conservative, making them contrary to the Robustness Principle. >> >> As shown by RFC1918 address and route leaks, "closed domains" attached to the Internet aren't guaranteed to be closed. A closed domain network can only be truly closed off from the Internet if it is completely isolated with an air gap. >> >> >> Regards, >> Mark. >> >>> G/ >>> >>> -----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 >>> >>> >>> 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-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=draft-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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue Nov 7 07:23:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC79E13FDC2 for ; Tue, 7 Nov 2017 07:23:35 -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 36seWW17pTtg for ; Tue, 7 Nov 2017 07:23:34 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 44BCB13FF4A for ; Tue, 7 Nov 2017 07:16:17 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id x195so10037252qkb.12 for ; Tue, 07 Nov 2017 07:16:17 -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=8DlpxPZmXOXNR8CfL32trqMWby+lpqF1mLB1Ba0ySn4=; b=RHbohig+bbV0wX4NfBvcHi/HZi/wFmxVPNTWUb43niqxqeaZ7Qe64TYCy9NzzqZp7X cECuL7bd7hYQX/rOUZhbcvoSOOfEuURoDWvotFgqyiSR2T84WQrFRAIfoDNGbZ80sYPu hvHHEcFMSDMbLQHfsmVGPrRoyiXalRQPsc1rzxb96pq6C6DcEz/l/Gx47a9W15OWtD7V Po3gH0C1dFl/ZMwP1e5bRmWzQx7Fs72T4+w7SkEVCe2ScLwBqKai4hqYjgCdhHZuKJcr uAlFroN/DUS//UDf9QgAPU8XyIJoDAaMGli7HbDC0OCpF4jCN75VMEDxDw7cHOizbXNP MVPg== 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=8DlpxPZmXOXNR8CfL32trqMWby+lpqF1mLB1Ba0ySn4=; b=kjsJ9O7KwUZ462xcpf+Y36vLrkFmFPa8nLtRO70ylXU2MwqxFsv1C3NFRDy4AfhodB s7y2FkvZig3gSXZaJ+tc6qm79LQLOq6Rh2xBstIjYOjjq2fEhubnr83xukK/KAcE+HW3 KgvEXzvPTl6BHWzclnHF2et/Q4PXCxgpWzdqI7QTXn6YD0S2T0oruTQ3kXq8c+e4gYBy UdqnLvZ0YxYMq+z+LfperFa53F22fWnG5kSPZ+JXrrVYCcSMih2Au1XEQZi+lxBYEbBV tQd+0iihDQKYvoEx0gCsZMcjUeCuMxeQ7xkXQP3mCYaVZfSDhewgizYRw/Tf8FWFaAeo Unjg== X-Gm-Message-State: AMCzsaV9bE45HJQbUha3hlGVRyZ7o3pxty7TDttE0dBiSYbifH31Z35H x7jeWDimTBUDbjUXWc9JllWkU0Qm/sfRjTrRYeF0bw== X-Google-Smtp-Source: ABhQp+QQfLL1nWHErkpFjRjK56XiCdYWPWgBsHJqqMZuAQd55bjcRG1Y+C5hfHw4i9j9f2D9Uz3oEMc6xIMfJApX2qw= X-Received: by 10.55.89.65 with SMTP id n62mr25818465qkb.51.1510067776316; Tue, 07 Nov 2017 07:16:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Tue, 7 Nov 2017 07:16:15 -0800 (PST) In-Reply-To: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Tue, 7 Nov 2017 07:16:15 -0800 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 15:23:36 -0000 On Mon, Nov 6, 2017 at 10:44 PM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Tom, > > --> > From section 1: > > "Based on these considerations, it is allowed to use the flow label field in a managed domain, assuming when a packet leaves the domain, the original flow label value MUST be restored." > > In this proposal, if two bits are overwritten by an intermediate node, how are their original values restored when leaving the domain? > --> > > GV> Because the field that are being fiddled with are on the IPv6 SRv6 outer encapsulation header. When the original packet leaves the controlled domain, then that header is removed again, and the original IPv6 packet with original headers appear again. > Gunter, If the measurements are always coincident with the use of SRv6 then why not put the measurement information in the SR EH or some other EH (hop-by-hop or est opt maybe) used only in the controlled domain? This also could be more flexible since the algorithm wouldn't be constrained to just two bits of data. Tom From nobody Tue Nov 7 07:45:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCD81334E6 for ; Tue, 7 Nov 2017 07:45:55 -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 391357cLAi2e for ; Tue, 7 Nov 2017 07:45:53 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0117.outbound.protection.outlook.com [104.47.1.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD20113FEE9 for ; Tue, 7 Nov 2017 07:26:32 -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=vPkZIsFqIsDzG4vHoC2iYXk6Jnvg3pO+8TBha+CI0W4=; b=Szq097hvjdPlfBfEJ7qUBvL+VV12Gujmbo6t2LFmU19wswZ2QLD1MIfuDPNWB9+VVzcf3S2OHtkH9LnGIj0rzwF03Q8wCEJa6YvlQ/xIrAyH9ev8Lzn5L1EdmJ4/DdAFO7OtmneZXiM39RudfsgYLJYO/XUF8/h7xppn5pkaRcg= 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_P256) id 15.20.218.6; Tue, 7 Nov 2017 15:26:30 +0000 Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 15:26:30 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Tom Herbert CC: "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYwgACbq4CAAFvKQIAAj8qAgAACmRA= Date: Tue, 7 Nov 2017 15:26:30 +0000 Message-ID: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2a02:1810:4d67:a00:e169:dba9:b151:110c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2835; 6:hHwcy9QgkYtqkj+uGOLNx7WkTZYabApg8WbqUR8wN7KAQx9+Bedulx/vYbYMtWIa2NurqKwKQadKabNgQaTEiII1Wi6YxjOm752NTIUDeet0Dq8EzbtboX2GmNSoVp3MTEKglM/b1cohvU/jobJXbzYf3aCbCE5GoUdPpR0LLis6b7wIjiKpOUbibZrddP+bcRa0C+PrQclgbva/I5FKh6aH3k5DqARyaIEQ2zI6OCNkNkFGigGjV7vTGSMKO8vYnGAQVRXEUzq8Mk7kC+zG9EkFFY9i07SfYTo3IUszE4oGJhVN/yLFhZDU/lVhwsvpzbyibSvCe0CoLszfMAptLJFJpIbt6fMl7zDC8IFB6B0=; 5:B+pmWP4LIATnoSLJjDbUaCNGVeuhEs98NTi3f/B3N6pNzr8pJ098uzrkKZwkBnfrd6ZKAk/scofWyLk3zXYGWeQ3xxOx6jD1WWpxBukMZ1ra7sW0Oj76vp/MVfaUj64KiFml3QiXlPl/pc0LmxUcYbyF3xeEhPrBVRXQEbVi4+Q=; 24:YQ6tZcCRLANOYsZMOR2jdAX7lzDdcwtUaz9G9/fgk1m/MY1Dcm0rQnj7+z8u/nFUsv8Sx59DVtkhJFC3aFXMFlsWQqA1dDj3rZgxzS0+8lI=; 7:Kfmm2Jyc6lwUbNpU/HhGBfPck6lc5rEDhlrq2sHw1AyZChRWU2z3dwGlgY2Ifjo1iPHeRlbkg3nE0PPdDygLZVe8pGMKtO1POUvZdq2ssjOetDORrGeFsa3WAMm5a4JmGJFn9qBC1feaoBYTTgWdKHHRto0uLHo1D4Ky1HvuTrZjEuVUJT9MJMopJYSA8OTphwu3cguK5H7LgLtkWmy6/fhTFgu4+7KwhrHuPyVUz3mCd54a+mt3pBXA3wya3w61 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ac182780-042d-44d3-f0ab-08d525f3eb90 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603249); SRVR:AM5PR0701MB2835; x-ms-traffictypediagnostic: AM5PR0701MB2835: x-exchange-antispam-report-test: UriScan:(82608151540597); 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)(100000703101)(100105400095)(3231021)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(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: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(13464003)(199003)(189002)(24454002)(2950100002)(7736002)(105586002)(305945005)(4326008)(74316002)(561944003)(478600001)(6916009)(101416001)(86362001)(14454004)(2900100001)(25786009)(106356001)(93886005)(2906002)(5660300001)(53546010)(81166006)(33656002)(8936002)(7696004)(8676002)(99286004)(97736004)(230783001)(6436002)(9686003)(81156014)(3280700002)(316002)(5250100002)(3660700001)(6246003)(6506006)(68736007)(6116002)(15650500001)(229853002)(76176999)(50986999)(54356999)(189998001)(55016002)(53936002)(102836003); 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: ac182780-042d-44d3-f0ab-08d525f3eb90 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 15:26:30.1124 (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: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 15:45:55 -0000 QSB0cmFuc2l0IHJvdXRlciBkb2VzIG5vdCBsb29rIGF0IEVIcyBpZiBpdCBpcyBub3QgY29uZmln dXJlZCBmb3IgdGhlIElQdjYgRGVzdGluYXRpb24gYWRkcmVzcy4uIHNvIGl0cyBub3QgdXNhYmxl IGluIHRoYXQgY2FzZS4NCg0KRy8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0gDQpTZW50OiBUdWVzZGF5 LCBOb3ZlbWJlciA3LCAyMDE3IDE2OjE2DQpUbzogVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lh IC0gQkUvQW50d2VycCkgPGd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tPg0KQ2M6IHY2b3Bz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1maW9jY29sYS1zcHJpbmctZmxvdy1sYWJlbC1hbHQtbWFyay0wMS50eHQN Cg0KT24gTW9uLCBOb3YgNiwgMjAxNyBhdCAxMDo0NCBQTSwgVmFuIERlIFZlbGRlLCBHdW50ZXIg KE5va2lhIC0NCkJFL0FudHdlcnApIDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4gd3Jv dGU6DQo+IEhpIFRvbSwNCj4NCj4gLS0+DQo+IEZyb20gc2VjdGlvbiAxOg0KPg0KPiAiQmFzZWQg b24gdGhlc2UgY29uc2lkZXJhdGlvbnMsIGl0IGlzIGFsbG93ZWQgdG8gdXNlIHRoZSBmbG93IGxh YmVsIGZpZWxkIGluIGEgbWFuYWdlZCBkb21haW4sIGFzc3VtaW5nIHdoZW4gYSBwYWNrZXQgbGVh dmVzIHRoZSBkb21haW4sIHRoZSBvcmlnaW5hbCBmbG93IGxhYmVsIHZhbHVlIE1VU1QgYmUgcmVz dG9yZWQuIg0KPg0KPiBJbiB0aGlzIHByb3Bvc2FsLCBpZiB0d28gYml0cyBhcmUgb3ZlcndyaXR0 ZW4gYnkgYW4gaW50ZXJtZWRpYXRlIG5vZGUsIGhvdyBhcmUgdGhlaXIgb3JpZ2luYWwgdmFsdWVz IHJlc3RvcmVkIHdoZW4gbGVhdmluZyB0aGUgZG9tYWluPw0KPiAtLT4NCj4NCj4gR1Y+ICBCZWNh dXNlIHRoZSBmaWVsZCB0aGF0IGFyZSBiZWluZyBmaWRkbGVkIHdpdGggYXJlIG9uIHRoZSBJUHY2 IFNSdjYgb3V0ZXIgZW5jYXBzdWxhdGlvbiBoZWFkZXIuIFdoZW4gdGhlIG9yaWdpbmFsIHBhY2tl dCBsZWF2ZXMgdGhlIGNvbnRyb2xsZWQgZG9tYWluLCB0aGVuIHRoYXQgaGVhZGVyIGlzIHJlbW92 ZWQgYWdhaW4sIGFuZCB0aGUgb3JpZ2luYWwgSVB2NiBwYWNrZXQgd2l0aCBvcmlnaW5hbCBoZWFk ZXJzIGFwcGVhciBhZ2Fpbi4NCj4NCkd1bnRlciwNCg0KSWYgdGhlIG1lYXN1cmVtZW50cyBhcmUg YWx3YXlzIGNvaW5jaWRlbnQgd2l0aCB0aGUgdXNlIG9mIFNSdjYgdGhlbiB3aHkgbm90IHB1dCB0 aGUgbWVhc3VyZW1lbnQgaW5mb3JtYXRpb24gaW4gdGhlIFNSIEVIIG9yIHNvbWUgb3RoZXIgRUgg KGhvcC1ieS1ob3Agb3IgZXN0IG9wdCBtYXliZSkgdXNlZCBvbmx5IGluIHRoZSBjb250cm9sbGVk IGRvbWFpbj8gVGhpcyBhbHNvIGNvdWxkIGJlIG1vcmUgZmxleGlibGUgc2luY2UgdGhlIGFsZ29y aXRobSB3b3VsZG4ndCBiZSBjb25zdHJhaW5lZCB0byBqdXN0IHR3byBiaXRzIG9mIGRhdGEuDQoN ClRvbQ0K From nobody Tue Nov 7 08:38:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E7A133258; Tue, 7 Nov 2017 08:38:09 -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, 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 3bcLi3JvisR9; Tue, 7 Nov 2017 08:38:01 -0800 (PST) Received: from mx04.telecomitalia.it (mx04.telecomitalia.it [217.169.121.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE3B133402; Tue, 7 Nov 2017 08:35:05 -0800 (PST) X-AuditID: d9a97918-07fff70000003d1a-f1-5a01e0b76e16 Received: from TELMBXA02RM001.telecomitalia.local ( [10.14.252.26]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx04.telecomitalia.it () with SMTP id A9.66.15642.7B0E10A5; Tue, 7 Nov 2017 17:35:03 +0100 (CET) From: Fioccola Giuseppe To: "Joel M. Halpern" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Mark Smith CC: "v6ops@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTV6HH04AD4XdL6EiiAOiUFI8VoKMI590AgAAttZA= Date: Tue, 7 Nov 2017 16:35:02 +0000 Message-ID: <629ed42009b0416894f80d1427e8ca20@TELMBXB02RM001.telecomitalia.local> References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <38d33b00-04ee-a3be-a0c3-8377c90458cc@joelhalpern.com> In-Reply-To: <38d33b00-04ee-a3be-a0c3-8377c90458cc@joelhalpern.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.244] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBKsWRmVeSWpSXmKPExsXCxfdHSnf7A8Yog20PuSzeLv7BaPHx1Bsm i51HjrJbHL/wm9Hi9LG9zA6sHjtn3WX3WLLkJ5PHuSnfGT3u3rrEFMAS1cBok5iXl1+SWJKq kJJanGyr5JJZnJyTmJmbWqQQkpqTmpyfq6SQmWKrZKykUJCTmJyam5pXYquUWFCQmpeiZMel gAFsgMoy8xRS85LzUzLz0m2VPIP9dS0sTC11DZXsAktTi0vyFXJTi4sT09Mz8xVSE9YLZvyZ lVfwu7iio/UkUwPj69guRk4OCQETiXOP3jCD2EICU5gkmj9xgNhsAjYSB1+dYOti5OIQEVjI KPF211t2kASzgJfEwY4WsAZhgQKJTc9OsnYxcgAVFUn0NjBBmFYS8xemglSwCKhIbLpymgnE 5hUIlDi/+z0ryEghgZksEu9v/AAbySngLNHavxOsiFFAVmLC7kWMEKvEJV5MP8EOcaeAxJI9 55khbFGJl4//sULYBhJbl+5jgbAVJXpezoGyZSQWHpnMCjFHT+LG1ClsELa2xLKFr5khDhKU ODnzCcsERrFZSNbNQtIyC0nLLCQtCxhZVjGK5lYYmOiVQGIvsyQxJzNRL7NkEyMwudxcWSmx g7F7rfMhRgEORiUe3h/nGKOEWBPLiitzDzFKcDArifBuV2eIEuJNSaysSi3Kjy8qzUktPsTo AwyyicxSosn5wMSXVxJvaGJhaWhsYWFkaGFmikNYSZz34T2g8QLpwOSVnZpakFoEM46Jg1Oq gZFt2dvq4rv2J94ab0xpKNK487x4zX255qPHHP9P+Rm5j1Fg5ccMYbtDLS1Gs274ZT9vj0/1 CrdwfN6rL3njZpLr6yRfViupBeWhdfef+zI9yrhctMuZI0t1o8+nFVtEpTyV97aWRQbcYSja Y7HpvBZPTHjLLwn1d9fqYmM2Kcy+UDw3p7j6hhJLcUaioRZzUXEiAK0XgSpbAwAA Archived-At: Subject: [v6ops] R: [spring] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 16:38:10 -0000 Hi Joel, Thanks for your comments. See my answers inline tagged as [GF]. Best Regards, Giuseppe -----Messaggio originale----- Da: spring [mailto:spring-bounces@ietf.org] Per conto di Joel M. Halpern Inviato: marted=EC 7 novembre 2017 15:23 A: Van De Velde, Gunter (Nokia - BE/Antwerp); Mark Smith Cc: v6ops@ietf.org; spring@ietf.org Oggetto: Re: [spring] [v6ops] FW: New Version Notification for draft-fioccol= a-spring-flow-label-alt-mark-01.txt Is there an implicit assumption that ALL traffic in a domain will be using S= Rv6 encapulating headers? [GF]: not only, the document considers also IPv6 tunneled packets. If not, then how will devices know whether they can mark the "ecn bits" of the flow label" on a particular packet? [GF]: The devices can be instructed on how to select the flow to be monitore= d. A packet flow can be defined by a set of selection rules used to match a= subset of the packets. These rules specify a set of headers fields: Identif= ication Fields (e.g. TCP 5-tuple). Once the flow has been identified, It can= be marked and monitored. If you are assuming complete deployment, how is that practical for operation= al networks? [GF]: Agree, the management aspects of the alternate marking applications ha= ve to be well defined and we are working on it in a new coming companion dra= ft for alternate marking foundation document. Yours, Joel On 11/7/17 3:23 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Mark, > > Yeah... you may be right... we added the intro part to start the draft bec= ause mentioning the construction "using Flow-Label" seems to have toxic emai= l storm effect on email lists around v6. Hence the disclaimers on flow-label= usage at the start of the text. Maybe it is wrongly placed and gives the wr= ong impression indeed... it is for sure not the intent... It is our intent t= o set flow-label on the outer tunnel header, and this is done by the router= which is imposing the IPv6 tunnel outer header, but we are not fiddling on= the fly with transit flow-labels at all. This seems not to break any IPv6 r= ules I think. > > However, as you point out the case of SRv6 EH insert, is a different story= and requires a bit more thought. It is possible also, but needs to use the= SRv6 Opaque value-containers to carry the original Flow-label across the do= main to reconstruct the original flow-label value. Nevertheless, RFC8200 see= ms rather restrictive on EH insertion, and hence we conveniently assumed tha= t chances are low for it to become reality due to IPv6 specification complex= ities and we disregarded EH inject. > > G/ > > > -----Original Message----- > From: Mark Smith [mailto:markzzzsmith@gmail.com] > Sent: Tuesday, November 7, 2017 09:04 > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > > Cc: v6ops@ietf.org; spring@ietf.org > Subject: Re: [v6ops] FW: New Version Notification for > draft-fioccola-spring-flow-label-alt-mark-01.txt > > Hi Gunter, > > On 7 November 2017 at 17:56, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: >> Hi Mark, >> >> The flow label of the original packet is untouched. It is never manipulat= ed in this proposal. The flow label that is set in this proposal is done at= the SRv6 tunnel-head end which imposes the SRv6 encapsulation header. It is= this encapsulation header which has the flow label which is used in this dr= aft. >> So basically, it is just the SRv6 tunnel outer encap header which is used= for alternate packet marking. And this is set only one time by the original= SRv6 tunnel head-end router (which is the source address of the IPv6 SRv6 t= unnel...). This outer SRv6 header is removed when the packet exits the SRv6= domain, and the original flow label appears again untouched. This does not= break any RFC at all because all because the original flow-label of the ori= ginal IPv6 packet is never touched. >> >> So, in this proposal there is no device which is changing flow-labels at= all. It is only during the imposing of the SRv6 outer header, that the flow= label field is set once for Alternate marking purposes inside the outer SRv= 6 tunnel header. >> >> Hope it clarifies? >> > > It does, although it seems to be contrary to quite a lot of the introducti= on text: > > > "The flow label is an immutable field recommended to contain a pseudo- > random value [RFC6437]. However, in most packets it has the default > value of zero, although some TCP/IP stacks do set it according to > [RFC6437]. > > [RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used > in controlled environment,..." > > "Based on these considerations, it is allowed to use the flow label > field in a managed domain, assuming when a packet leaves the domain, > the original flow label value MUST be restored." > > and the later reference to > "[I-D.voyer-6man-extension-header-insertion]" all seems to be setting up a= case to justify modifying the original packet's flow label value and then r= estoring it using the original value that has been somehow sent or signalled= to the network egress. > > As you've said, when tunnelling, the original packet and its flow > label value is entirely preserved, so there doesn't need to be any of > the above text. Even the text about hosts not setting the FL value > isn't really necessary, as tunnel end-points, as a function at the > IPv6 layer, are hosts that originate packets, so they can set the FL value= to what ever they like because they're originating the (tunnel) packet. > > > I think it might be better to avoid using two of the FL bits to encode > the marking method, as that also deviates from RFC6437 (I seem to > remember we also thought about using some bits in the FL to encode > something during that time, and also abandoned it.) > > I'm not across the Alternate Marking Method work, so this might be a dumb= question or suggestion. Within a measurement domain, is there ever going to= be a mix of single and double marking, such that it needs to be encoded per= -packet? If a domain can only support one of them at any one time, then I th= ink that could be encoded in the configuration of the SRv6 tunnel end points= , rather than encoding it in a couple of the FL bits. > > Also, there is now an IPv6 Performance and Diagnostics Destination Option= which may be a IPv6 conventional way of encoding this marking or measuremen= t information in the outer IPv6 tunnel header (i.e. > [Outer IPv6 HDR][PDM][Inner/Original IPv6 Packet]) > > "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option" > https://tools.ietf.org/html/rfc8250 > > Regards, > Mark. > > >> G/ >> >> >> >> -----Original Message----- >> From: Mark Smith [mailto:markzzzsmith@gmail.com] >> Sent: Tuesday, November 7, 2017 06:16 >> To: Van De Velde, Gunter (Nokia - BE/Antwerp) >> >> Cc: v6ops@ietf.org; spring@ietf.org >> Subject: Re: [v6ops] FW: New Version Notification for >> draft-fioccola-spring-flow-label-alt-mark-01.txt >> >> On 7 November 2017 at 02:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: >>> If any feedback or comments (preferably constructive), then please >>> have the discussion including SPRING WG in cc >>> >> >> So this draft, similar to the IPv6 EH insertion draft, doesn't answer the= fundamental question of why. >> >> What technical and engineering reasons justify reusing the flow label fie= ld, contrary to its specification? What alternatives were considered that do= n't violate the the flow label specification, and why are their drawbacks so= significant that they justify ignoring the flow label specification? Use of= IPv6 fields can be novel, however the novelty has to fit within the specifi= cations to ensure interoperability. >> >> "[RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used >> in controlled environment," >> >> I'm sure it doesn't. During the original discussions that resulted in RFC= 6437, I suggested the idea of Flow Label domains similar to DSCP domains. It= was ignored for valid reasons. This is the discussion mentioned in the firs= t paragraph of appendix A in RFC6436. >> >> "A model was discussed in an earlier version of this document which >> defined a notion of 'flow label domain' analogous to a differentiated >> services domain [RFC2474]. This model would have encouraged local >> usage of the flow label as an alternative to any form of generic use, >> but it required complex rules for the behavior of domain boundary >> routers, and proved controversial in discussion." >> >> >> Here's what the flow label specification RFC says, >> >> "Once set to a non-zero value, the Flow Label is expected to be >> delivered unchanged to the destination node(s). A forwarding node >> MUST either leave a non-zero flow label value unchanged or change it >> only for compelling operational security reasons as described in >> Section 6.1" >> >> I don't think the use in this draft is a "compelling operational security= reason". >> >> A network can have a number of egress points. To be able to restore flow= label values upon egress, either all of the flow label restoration state fo= r all in-flight packets' flow label values will have to be kept synchronised= at all of the egress points, or kept synchronised in accordance with where= the routing protocol determines is the current egress point for the packet. >> >> In this latter case, while in flight, the egress point could change, mean= ing the packet's egress path changes, and there then occurs a race between w= hen the packet reaches the exit point and the flow label restoration state f= or that packet reaches that egress point so that it can be restored. >> >> So are packets going to be held/delayed upon ingress such that they can n= ever reach the egress point before their original flow label value informati= on reaches that egress point first? If they're not, then there is no assuran= ce that the original flow label value can be restored, and the domain isn't= closed anymore. The modified packet leaves the "closed domain" with the mod= ification unrestored. >> >> >> "The IPv6 protocol includes a flow label in every packet >> header, but this field is, according to [RFC6294], not used in >> practice." >> >> RFC6294 was published in 2011, 6 years ago. Implementations have changed= since then. >> >> The Linux kernel is setting flow label values per RFC6437 per Tom Herbert= 's Linux kernel patch in the order of 2 years ago. >> >> Random flow labels look to be also being set by Mac OS X around the >> same time (July 2015) - >> >> https://www.ietf.org/mail-archive/web/ipv6/current/msg22820.html >> >> Windows was the major hold out - the latest Windows 10 Creater Update is= now setting Flow Labels. >> >> https://www.ietf.org/mail-archive/web/ipv6/current/msg22820.html >> >> >> It seems people are starting to believe "closed domains" can be used to j= ustify modifying packets in flight, in any way they'd like to modify them. I= n theory and in specifications, the modifications are guaranteed to be rever= sed at egress, in practice, contrary to specifications, implementations and= network operations are not guaranteed and perfect. The reversal may not occ= ur at egress due to implementation bugs, partial device failures or operator= configuration error or omission. These sorts of in-flight changes are not c= onservative, making them contrary to the Robustness Principle. >> >> As shown by RFC1918 address and route leaks, "closed domains" attached to= the Internet aren't guaranteed to be closed. A closed domain network can on= ly be truly closed off from the Internet if it is completely isolated with a= n air gap. >> >> >> Regards, >> Mark. >> >>> G/ >>> >>> -----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 >>> >>> >>> 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 I= ETF repository. >>> >>> Name: draft-fioccola-spring-flow-label-alt-mark >>> Revision: 01 >>> Title: Using the IPv6 Flow Label for Performance Measurement wi= th 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-spri= ng-flow-label-alt-mark-01.txt >>> Status: https://datatracker.ietf.org/doc/draft-fioccola-spring-f= low-label-alt-mark/ >>> Htmlized: https://tools.ietf.org/html/draft-fioccola-spring-flow-l= abel-alt-mark-01 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-fioccola-spr= ing-flow-label-alt-mark-01 >>> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-fioccola-sprin= g-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 submis= sion 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 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, please delete this message and any attachments and advise the sender= by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non =E8 necessario. From nobody Tue Nov 7 08:58:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F1813292E for ; Tue, 7 Nov 2017 08:58: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, 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 I6PoZM-eZzmx for ; Tue, 7 Nov 2017 08:58:37 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18230132025 for ; Tue, 7 Nov 2017 08:58:36 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id n61so16042578qte.10 for ; Tue, 07 Nov 2017 08:58:36 -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=QpPEfs4FjfUSBqB2db04GYAIAxpSQhZC1UcPNXabNes=; b=oNNNkx0zPCsjmYdlMkc639hm02Wxrhcz5EUnYZSccdp++n2vRRvJzexRDc2y6V6lRo PlMIk1oKc8nDqBALb6n2RGplOZJ6jRhNhvhYtJo6QRg2qx27xod7JPm/Jjj4h/XDEbcS skgt1rieqxz3phKpTCeCSUX6dXnSH7FPBT60c+unvFpoteG2L4rxErm/TLaRbal6j69l IO7j1Cznq7NtNg1cnu7NJsMZnokrtNV9rm2vCrtQ+hcwW8BPysBWXUDiEUWuqSW8soFh oUfOYSFKYzs/BGBwTj0YYJTpMFLaxpRIy7vtBnl2INEAFb0aKYYC6S+0DG9eZosDmrZP qDAg== 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=QpPEfs4FjfUSBqB2db04GYAIAxpSQhZC1UcPNXabNes=; b=Bcjq2B+HgUn1qnA1mn6XV5GNNx+318Z7qoXZ1qtluo5yetFl8hkLQV7btE2PUPTeLt mPxSZocKrClFwXN3CGWc+k3UtBw2qmbQenfofd0+1aKyRAQX5D9FMb/Q+ilUR3HoncIO oyOgv9HC4zMIfczzMSeOcuo9CRNcLBXIcDJL3RhE+XKLdd/89HiUC5A8iUruL1jetXCE aV6k8LgUXWjMXTEUZvZZml+MCqVnUPJdkfOGO8bNM/7Sax/e+mGoGAcLDF5/qi2Ns7xj hfncyIyrrqosXIqqnIqPCdI/pdi0rrYAfSKHMe8trR1/0Szd1HLk3MThU5MEQ6FDECZp CH/A== X-Gm-Message-State: AMCzsaXv8kl/6U1IRaSONKb7h12eTp2/cCUh/LMN8IoTRmLN6Q974N6v ON31/aXJmVHihSFTf74PBEax172359IRkcI/XYiGXA== X-Google-Smtp-Source: ABhQp+T9ZXwsFIfJ/BvG7Tn0E/Vbxo4yuTka2reYfiF9XoMGRY4U5RnKlZ2oUT6TMKir5mT3fCOya5AVyxYBQjHlvDw= X-Received: by 10.237.35.58 with SMTP id h55mr28461815qtc.108.1510073916050; Tue, 07 Nov 2017 08:58:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Tue, 7 Nov 2017 08:58:35 -0800 (PST) In-Reply-To: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Tue, 7 Nov 2017 08:58:35 -0800 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 16:58:39 -0000 On Tue, Nov 7, 2017 at 7:26 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > A transit router does not look at EHs if it is not configured for the IPv= 6 Destination address.. so its not usable in that case. > They do look at hop-by-hop options. Previously it was required that all nodes in the path must process them, but that was relaxed a bit in RFC8200. If they are only used for tunneling across a controlled domain then the typical concern that intermediate nodes don't properly handle hop-by-hop options can be addressed. Tom > G/ > > -----Original Message----- > From: Tom Herbert [mailto:tom@herbertland.com] > Sent: Tuesday, November 7, 2017 16:16 > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spri= ng-flow-label-alt-mark-01.txt > > On Mon, Nov 6, 2017 at 10:44 PM, Van De Velde, Gunter (Nokia - > BE/Antwerp) wrote: >> Hi Tom, >> >> --> >> From section 1: >> >> "Based on these considerations, it is allowed to use the flow label fiel= d in a managed domain, assuming when a packet leaves the domain, the origin= al flow label value MUST be restored." >> >> In this proposal, if two bits are overwritten by an intermediate node, h= ow are their original values restored when leaving the domain? >> --> >> >> GV> Because the field that are being fiddled with are on the IPv6 SRv6 = outer encapsulation header. When the original packet leaves the controlled = domain, then that header is removed again, and the original IPv6 packet wit= h original headers appear again. >> > Gunter, > > If the measurements are always coincident with the use of SRv6 then why n= ot put the measurement information in the SR EH or some other EH (hop-by-ho= p or est opt maybe) used only in the controlled domain? This also could be = more flexible since the algorithm wouldn't be constrained to just two bits = of data. > > Tom From nobody Tue Nov 7 09:13:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EA7133248 for ; Tue, 7 Nov 2017 09:13:42 -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 y11-xDCxL9qr for ; Tue, 7 Nov 2017 09:13:40 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10098.outbound.protection.outlook.com [40.107.1.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF22F133090 for ; Tue, 7 Nov 2017 09:13:39 -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=jeusrVF6eMAla9ALv1piVngE+x3d9XfGYND18QdDuOo=; b=KLyL6DT9PDxdyE7MXI20U8vhyaakd3tBdQBshAvC5P7Yf6+EWFXnXlARHpMswx7NASpa8GGmrvhSoR1xqWanL1+lES58VxUUykO0wNEVp4m1FjjEttnBZgseogh7A1lU/2GLODVXBg8epBPdS/QpJkJdXbNIe3elqfMQzVt+6Fc= Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB2834.eurprd07.prod.outlook.com (10.168.155.137) 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 17:13:37 +0000 Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 17:13:37 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Tom Herbert CC: "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYwgACbq4CAAFvKQIAAj8qAgAACmRCAABn/gIAABDIA Date: Tue, 7 Nov 2017 17:13:37 +0000 Message-ID: <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [81.242.22.169] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2834; 6:rXJtlHc1uJ9idy2COVUVm5De0kZuA3TWbtwnI5WXJ8c+Yh/eDwWUUF+6l8OxvX92rpjw+exTgN79RxEIeqMTdxW4WdIZZGBMa0echu5iDeFnHb7lTvHg7oLOeugwkL3tunQ5vVwq4nTAmYL83sfnyX5BxpS8V3TlxKmXlC7SOmNiLOXKo3yS0cFlYlAdeOlFqmxF+Bh+7soxxmrnawDSiCsKllCUGFAlavuR0veIdc+Z6jMkJNDXex6UxRt5hAEK4WqkzFoiOEXdJdlpsTn+Rp9lUDewdDdDAbA/HoZKzZ7PMoVuQCQYGB6TtS00jLdfvCyfdt6AiKT9LTdeGNO9c4PTPcovXOpoFoFAPSNTuII=; 5:Mwa1HyUu4fz+Kqq/OButj0FXQg6IvDGTRe63SYTgdqOR+mO3XTX2RCawrCJnhUKHcKLZl7jKg1qgP3l5xN44JCzQlsRG9NBLK3/8rsSh6UDdbqxmcTQbJpzLnnjVwTAaTSoHjc607p6yv/O4IlSJB2CSaT1lw67FISjOTm8T1Bw=; 24:rsDuuibyHjq8065rW4UsIzvUADlHglJMhPTjQ7yL6U/14FX6910MpweqfT3DHaqHnSXHlYobeCAYoMUQQbBgot+F2zGd+Pgzs5yG4dD1NKI=; 7:Gn2bhWj1pBiH201vjvR4zczKoP4vdm2ByMf1dI8CHY0WrD5lN/Z8+7OltORhO/IrETQNx9d89fggzeFYp8osd17hfZhrrnPqdz6YmskkKqz4w5S8DsBszNeGbugixOA/gqjeWTnRiRXzvfs+rAi6OMv8C3YHNB6ogpUGhn1RTyjt6EXuY3zJKnGZfMg42RgJeNOsEmhmzHXWSKP15ZkHj7pach4J/Xl1NeIk5xAwZjbIQXb+W8qBr4ofmUFwsjrm x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 815ef1fa-d579-4d43-da64-08d52602e27f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM5PR0701MB2834; x-ms-traffictypediagnostic: AM5PR0701MB2834: x-exchange-antispam-report-test: UriScan:(82608151540597); 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)(100000703101)(100105400095)(3231021)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2834; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2834; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(24454002)(189002)(13464003)(199003)(305945005)(478600001)(102836003)(54356999)(81156014)(97736004)(6512007)(6246003)(99286004)(106356001)(82746002)(3846002)(76176999)(101416001)(50986999)(81166006)(189998001)(561944003)(53936002)(8676002)(15650500001)(2900100001)(33656002)(8936002)(6116002)(229853002)(6486002)(36756003)(6506006)(93886005)(3280700002)(105586002)(7736002)(2906002)(83716003)(230783001)(6436002)(2950100002)(86362001)(25786009)(53546010)(68736007)(66066001)(4326008)(5250100002)(14454004)(6916009)(5660300001)(316002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2834; 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: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 815ef1fa-d579-4d43-da64-08d52602e27f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 17:13:37.3363 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2834 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 17:13:42 -0000 VG8gbWUgaXQgc2VlbXMgdGhhdCBsb29raW5nIGF0IEZMIGlzIG11Y2ggZWFzaWVyIGZvciBhIEhX IGJhc2VkIHJvdXRlciB0aGVuIGxvb2tpbmcgYXQgRUhzIGluIGEgaG9wLWJ5LWhvcCBmYXNoaW9u 4oCmDQoNCkcvDQoNCk9uIDA3LzExLzIwMTcsIDE3OjU4LCAiVG9tIEhlcmJlcnQiIDx0b21AaGVy YmVydGxhbmQuY29tPiB3cm90ZToNCg0KICAgIE9uIFR1ZSwgTm92IDcsIDIwMTcgYXQgNzoyNiBB TSwgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0NCiAgICBCRS9BbnR3ZXJwKSA8Z3VudGVy LnZhbl9kZV92ZWxkZUBub2tpYS5jb20+IHdyb3RlOg0KICAgID4gQSB0cmFuc2l0IHJvdXRlciBk b2VzIG5vdCBsb29rIGF0IEVIcyBpZiBpdCBpcyBub3QgY29uZmlndXJlZCBmb3IgdGhlIElQdjYg RGVzdGluYXRpb24gYWRkcmVzcy4uIHNvIGl0cyBub3QgdXNhYmxlIGluIHRoYXQgY2FzZS4NCiAg ICA+DQogICAgVGhleSBkbyBsb29rIGF0IGhvcC1ieS1ob3Agb3B0aW9ucy4gUHJldmlvdXNseSBp dCB3YXMgcmVxdWlyZWQgdGhhdA0KICAgIGFsbCBub2RlcyBpbiB0aGUgcGF0aCBtdXN0IHByb2Nl c3MgdGhlbSwgYnV0IHRoYXQgd2FzIHJlbGF4ZWQgYSBiaXQgaW4NCiAgICBSRkM4MjAwLiBJZiB0 aGV5IGFyZSBvbmx5IHVzZWQgZm9yIHR1bm5lbGluZyBhY3Jvc3MgYSBjb250cm9sbGVkDQogICAg ZG9tYWluIHRoZW4gdGhlIHR5cGljYWwgY29uY2VybiB0aGF0IGludGVybWVkaWF0ZSBub2RlcyBk b24ndCBwcm9wZXJseQ0KICAgIGhhbmRsZSBob3AtYnktaG9wIG9wdGlvbnMgY2FuIGJlIGFkZHJl c3NlZC4NCiAgICANCiAgICBUb20NCiAgICANCiAgICA+IEcvDQogICAgPg0KICAgID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICA+IEZyb206IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9t QGhlcmJlcnRsYW5kLmNvbV0NCiAgICA+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDcsIDIwMTcg MTY6MTYNCiAgICA+IFRvOiBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJw KSA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+DQogICAgPiBDYzogdjZvcHNAaWV0Zi5v cmcNCiAgICA+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJrLTAxLnR4dA0K ICAgID4NCiAgICA+IE9uIE1vbiwgTm92IDYsIDIwMTcgYXQgMTA6NDQgUE0sIFZhbiBEZSBWZWxk ZSwgR3VudGVyIChOb2tpYSAtDQogICAgPiBCRS9BbnR3ZXJwKSA8Z3VudGVyLnZhbl9kZV92ZWxk ZUBub2tpYS5jb20+IHdyb3RlOg0KICAgID4+IEhpIFRvbSwNCiAgICA+Pg0KICAgID4+IC0tPg0K ICAgID4+IEZyb20gc2VjdGlvbiAxOg0KICAgID4+DQogICAgPj4gIkJhc2VkIG9uIHRoZXNlIGNv bnNpZGVyYXRpb25zLCBpdCBpcyBhbGxvd2VkIHRvIHVzZSB0aGUgZmxvdyBsYWJlbCBmaWVsZCBp biBhIG1hbmFnZWQgZG9tYWluLCBhc3N1bWluZyB3aGVuIGEgcGFja2V0IGxlYXZlcyB0aGUgZG9t YWluLCB0aGUgb3JpZ2luYWwgZmxvdyBsYWJlbCB2YWx1ZSBNVVNUIGJlIHJlc3RvcmVkLiINCiAg ICA+Pg0KICAgID4+IEluIHRoaXMgcHJvcG9zYWwsIGlmIHR3byBiaXRzIGFyZSBvdmVyd3JpdHRl biBieSBhbiBpbnRlcm1lZGlhdGUgbm9kZSwgaG93IGFyZSB0aGVpciBvcmlnaW5hbCB2YWx1ZXMg cmVzdG9yZWQgd2hlbiBsZWF2aW5nIHRoZSBkb21haW4/DQogICAgPj4gLS0+DQogICAgPj4NCiAg ICA+PiBHVj4gIEJlY2F1c2UgdGhlIGZpZWxkIHRoYXQgYXJlIGJlaW5nIGZpZGRsZWQgd2l0aCBh cmUgb24gdGhlIElQdjYgU1J2NiBvdXRlciBlbmNhcHN1bGF0aW9uIGhlYWRlci4gV2hlbiB0aGUg b3JpZ2luYWwgcGFja2V0IGxlYXZlcyB0aGUgY29udHJvbGxlZCBkb21haW4sIHRoZW4gdGhhdCBo ZWFkZXIgaXMgcmVtb3ZlZCBhZ2FpbiwgYW5kIHRoZSBvcmlnaW5hbCBJUHY2IHBhY2tldCB3aXRo IG9yaWdpbmFsIGhlYWRlcnMgYXBwZWFyIGFnYWluLg0KICAgID4+DQogICAgPiBHdW50ZXIsDQog ICAgPg0KICAgID4gSWYgdGhlIG1lYXN1cmVtZW50cyBhcmUgYWx3YXlzIGNvaW5jaWRlbnQgd2l0 aCB0aGUgdXNlIG9mIFNSdjYgdGhlbiB3aHkgbm90IHB1dCB0aGUgbWVhc3VyZW1lbnQgaW5mb3Jt YXRpb24gaW4gdGhlIFNSIEVIIG9yIHNvbWUgb3RoZXIgRUggKGhvcC1ieS1ob3Agb3IgZXN0IG9w dCBtYXliZSkgdXNlZCBvbmx5IGluIHRoZSBjb250cm9sbGVkIGRvbWFpbj8gVGhpcyBhbHNvIGNv dWxkIGJlIG1vcmUgZmxleGlibGUgc2luY2UgdGhlIGFsZ29yaXRobSB3b3VsZG4ndCBiZSBjb25z dHJhaW5lZCB0byBqdXN0IHR3byBiaXRzIG9mIGRhdGEuDQogICAgPg0KICAgID4gVG9tDQogICAg DQoNCg== From nobody Tue Nov 7 10:14:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF859126B6D for ; Tue, 7 Nov 2017 10:14:56 -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 2KJN_ByTH2W2 for ; Tue, 7 Nov 2017 10:14:55 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 A63ED13319D for ; Tue, 7 Nov 2017 10:14:52 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id 8so167897qtv.1 for ; Tue, 07 Nov 2017 10:14:52 -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=5eWRKdhP8doibDno8bun4TPv1nPfIz6Wd/fwc0uR6gY=; b=j2hS0x8cLJtXPym48sCyi4PVsNW4mrATEvwiqW64VbFeFE0MxSEbPzH36ijkfYoSWv OGPVqqTE2z4nLErQSZanYOnHVNYt0pgMIdV2qk7UxB6U4/VPFjJexUCakrmX9qSPCzNW CFnTqB1YCvGI2K3/BLCbmzdBMI91Yqw9hgkDXwqK+6mMNbztQcXlwMdHhOf1pUFBZmfK XUMLOXNd97TwP3E9BDjkUvDBzze0Lj4Bnrhxh3u3MteiRENtnSmBK95hCagGi2teFpim KSkuBNmc4j2vETWMB64slByfGROco6EIrldBCJjoqyAn0ZIRSgILqzLmfn7yANOvOlOE giZQ== 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=5eWRKdhP8doibDno8bun4TPv1nPfIz6Wd/fwc0uR6gY=; b=j/q6iFO2xdmthV56XGTXAt+c8T1d1S6YTJwI5RrJKGM5JDFVmF3umkW06wEYso3564 N/1qrA2klShqNmwCkrsprOcat3ZTzV9i3DtOsvBLkD7N+1n0ql/8dCywXlQ/lryueCob lfLr1frz0njy3QVe0OyPNLf4PNS2bq0A9E6q2zM6JwrQwmZMXMm90bHHnSvU3m6f2/Lt SIoLVATQrczoUsX4gSuVkwfIkWFvrYfXVHwemdEWaI3zgowECJlkG+k5QD+TuxP6oAWa ZkDj2vRC3xO8QKvseEanXTI8uoRp6wTh4077jQ+9EaU2/K2NmnCMyWlYlkB81yT9yvCt 6MIQ== X-Gm-Message-State: AMCzsaWFHGnRfmmt7gNSLaFIBIq7jc9Vrl6Ge0RVXOu+IX5lLmAtXU5L ArHjbT5opk1RSgWYjSGruxhavdBXh3tRORdZrBDSpw== X-Google-Smtp-Source: ABhQp+SEMhrzikpBMK73s7kOuWGkeFcfZiSjJPe4kDAc3yXUNE4nrzhZgx6DzhTuGuLc/Y7uMkJaHpjaRdQGbUfNWJE= X-Received: by 10.200.55.101 with SMTP id p34mr30287791qtb.27.1510078491744; Tue, 07 Nov 2017 10:14:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Tue, 7 Nov 2017 10:14:51 -0800 (PST) In-Reply-To: <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> From: Tom Herbert Date: Tue, 7 Nov 2017 10:14:51 -0800 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 18:14:58 -0000 On Tue, Nov 7, 2017 at 9:13 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > To me it seems that looking at FL is much easier for a HW based router th= en looking at EHs in a hop-by-hop fashion=E2=80=A6 Easier for whom? Repurposing bits in the IP header even for a narrow use case in a closed system doesn't seem particularly easy to standardize or deploy. As Mark pointed out there's a lot of complexity around ensuring that the system really is closed and all required behavior is maintained. Another obvious question with this approach is does it mean that flow label bits are now fair game to be defined for even more purposes? Latency measurement isn't be the only potential use case. For instance, I know there's a lot of people that want hosts to mark packets with a "retransmitted" bit so that routers can keep stats for tracked flows. IMO, if using flow bits like this is the right answer then there should be a generic protocol specification that defines the operation and how bits are allocated for all the potential uses. Tom > > G/ > > On 07/11/2017, 17:58, "Tom Herbert" wrote: > > On Tue, Nov 7, 2017 at 7:26 AM, Van De Velde, Gunter (Nokia - > BE/Antwerp) wrote: > > A transit router does not look at EHs if it is not configured for t= he IPv6 Destination address.. so its not usable in that case. > > > They do look at hop-by-hop options. Previously it was required that > all nodes in the path must process them, but that was relaxed a bit i= n > RFC8200. If they are only used for tunneling across a controlled > domain then the typical concern that intermediate nodes don't properl= y > handle hop-by-hop options can be addressed. > > Tom > > > G/ > > > > -----Original Message----- > > From: Tom Herbert [mailto:tom@herbertland.com] > > Sent: Tuesday, November 7, 2017 16:16 > > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > > Cc: v6ops@ietf.org > > Subject: Re: [v6ops] FW: New Version Notification for draft-fioccol= a-spring-flow-label-alt-mark-01.txt > > > > On Mon, Nov 6, 2017 at 10:44 PM, Van De Velde, Gunter (Nokia - > > BE/Antwerp) wrote: > >> Hi Tom, > >> > >> --> > >> From section 1: > >> > >> "Based on these considerations, it is allowed to use the flow labe= l field in a managed domain, assuming when a packet leaves the domain, the = original flow label value MUST be restored." > >> > >> In this proposal, if two bits are overwritten by an intermediate n= ode, how are their original values restored when leaving the domain? > >> --> > >> > >> GV> Because the field that are being fiddled with are on the IPv6= SRv6 outer encapsulation header. When the original packet leaves the contr= olled domain, then that header is removed again, and the original IPv6 pack= et with original headers appear again. > >> > > Gunter, > > > > If the measurements are always coincident with the use of SRv6 then= why not put the measurement information in the SR EH or some other EH (hop= -by-hop or est opt maybe) used only in the controlled domain? This also cou= ld be more flexible since the algorithm wouldn't be constrained to just two= bits of data. > > > > Tom > > From nobody Tue Nov 7 11:53:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33DF13305F for ; Tue, 7 Nov 2017 11:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 KFd91v__zPf6 for ; Tue, 7 Nov 2017 11:53:33 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0137.outbound.protection.outlook.com [104.47.1.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E1212711A for ; Tue, 7 Nov 2017 11:53:32 -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=JiLpmt041ImAlTWPMlsZ6ZvMb9RR5dfADcpEyhh5+tA=; b=Z7Ls7UiSCUL+GCweLqpvnM+ej+p1U+CAMDUhNcqt2Ag8862oz8oPZCF8uGZgka1jeuF9VECSYg892fSWDLcPDbVCVfSWu9q1HCRCxTBs0c8aArcCC0QhAK+62ipp3gG50YyEH9fdthbYYuaS0n4R/ZXRwnHXS17OlBU7+cTESzw= Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) by AM5PR0701MB2836.eurprd07.prod.outlook.com (10.168.155.139) 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:53:30 +0000 Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 19:53:30 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Tom Herbert CC: "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYwgACbq4CAAFvKQIAAj8qAgAACmRCAABn/gIAABDIAgAARHYCAABuOgA== Date: Tue, 7 Nov 2017 19:53:30 +0000 Message-ID: <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [81.242.22.169] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2836; 6:9bntV1KsigY8EG6T24Mmkmw3LMt5HV/5T0jpzrmWkjti0zIjLqbpaKrbjYp7cYDQsLYAixWJ/p4ik41mBebiX/61vXDuH7VCt6L0ezIBamR6v0EjDkD+eiCPvjRvVNlHmgzbuMRpm56MvQOH2GmtyHWxvYTZPLHCOjPyHkFPdYmbQ4kXz0rQcsr3OvbMi07zVKwAQjBoppUygklNCFMf6ZIHwSRi6VpGKlKfy9YPaD7kBO6j4q6Qrl+8ylUnFUq9I9zYJ3l5dcKuy9kJ3NhVHHAmm74ZSvs6yZgSb9arUmuc/PduK6HXJbL/3DplUbjY55xgl7y348xu5KHJJemsk+nJ41y449JhTXaQ2UjZ3qE=; 5:GcNyIqDvHbUnt/nA8L4GNw0iw80ae3w3WqVyjIEyZfQO5sGNGyPke4eg3Tr/DmB/QHDNh0EbKG+aoY8Vx5oZfAAMuqhZDdHqasj9ufaMaixSnMp5Cd2c8kv+U8B6GflHu4r/O9RKWrilxjreS9VSpWqMfwTanVp6/Hv55+3p2AA=; 24:dfP0P/rN/l/6qwr8xOYnIrAVRF9c2OtbH87g4Q+KBswzVDaI0rjrrEwTc74tk8V8c2yiC1MHSkBvuBJgQAjNrjpW7IgAA9GaSNp892em8Dw=; 7:ykavm2v/XYbN4dzj+RvRGknkca5xo+K8WWKiOZWU5TrX5tnfAR980pn5jsMTQKEV/IjtKRAph3QRzlLq8+VKH/MshCqnszZRIsH3AE2YFsGuyZhFAizSBfzdMHWe5TOpIHRist5rofUAKa9jxbWrwGbSs/HHUAlJpYUwzfuF5MH+zmRf+3w4DvDoi7ifka8RvuscmSz72DhVmoMioNOlr0Egz2cqW74p7wXI3S2qJJoUi6z5Ii5YEz6G+NEOEF3G x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 05271d6e-7029-4a19-5bac-08d526193874 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:AM5PR0701MB2836; x-ms-traffictypediagnostic: AM5PR0701MB2836: x-exchange-antispam-report-test: UriScan:(82608151540597)(17755550239193); 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)(3002001)(3231021)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2836; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2836; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(24454002)(189002)(13464003)(199003)(68736007)(6512007)(230783001)(83716003)(189998001)(99286004)(82746002)(2906002)(6436002)(106356001)(105586002)(3660700001)(3280700002)(53936002)(6246003)(3846002)(6116002)(229853002)(14454004)(102836003)(50986999)(2900100001)(36756003)(15650500001)(4326008)(53546010)(76176999)(6916009)(86362001)(2950100002)(561944003)(54356999)(316002)(6486002)(7736002)(81166006)(81156014)(8676002)(33656002)(5250100002)(6506006)(25786009)(305945005)(478600001)(8936002)(97736004)(5660300001)(66066001)(101416001)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2836; 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: text/plain; charset="utf-8" Content-ID: <3C8B5707F1852B4398B3B1A75CCCF077@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 05271d6e-7029-4a19-5bac-08d526193874 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 19:53:30.4887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2836 Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 19:53:36 -0000 SGkgVG9tLA0KDQpUaGUgY2xvc2VkIHN5c3RlbSBoZXJlIGlzIGRlZmluZWQgYnkgdGhlIFNSdjYg dHVubmVsc+KApiBUaGUgZmxvdy1sYWJlbCBpcyBzZXQg4oCcb25seeKAnSBieSB0aGUgdHVubmVs IGhlYWQtZW5kIHJvdXRlciDigJxvbiB0aGUgb3V0ZXIgSVB2NiBoZWFkZXLigJ0uIFRoZSB0dW5u ZWwgaGVhZC1lbmQgcm91dGVyIGNhbiBkbyB0aGlzIGJlY2F1c2UgaXQgaXMgdGhlIGRldmljZSB0 aGF0IGNyZWF0ZWQgdGhlIG91dGVyIElQIGhlYWRlci4NClRoZSBvcmlnaW5hbCBJUHY2IHBhY2tl dCBpcyByaWRpbmcgaW5zaWRlIHRoZSB0dW5uZWwsIGFuZCBhcyByZXN1bHQgdGhlIG9yaWdpbmFs IGZsb3cgbGFiZWwgYW5kIG9yaWdpbmFsIElQdjYgaGVhZGVyIGlzIGxlZnQgdW50b3VjaGVkLiBU aGUgY2xvc2VkIHN5c3RlbSBpcyB0aGUgbmV0d29yayBiZXR3ZWVuIHRoZSB0dW5uZWwgaGVhZC1l bmQgKD13aGVyZSB0aGUgDQpvdXRlciBJUHY2IGhlYWRlciBpcyBhZGRlZCkgYW5kIHRoZSB0dW5u ZWwgdGFpbC1lbmQgKD13aGVyZSB0aGUgb3V0ZXIgaGVhZGVyIGlzIHJlbW92ZWQpLiBUaGlzIHR5 cGUgb2YgY2xvc2VkIHN5c3RlbSBpcyBlYXN5IHRvIGRlcGxveeKApiB0YWtlIGZvciBleGFtcGxl IGEgTVBMUy9WUE4gYmFja2JvbmXigKYuIE9yIGEgVnhMQU4gbmV0d29ya+KApiBUaGUgU1J2NiBu ZXR3b3JrIGlzIHNvbWV0aGluZyBvZiBzaW1pbGFyIHNpbXBsaWNpdHkuDQoNClRoZSBJUHY2IGRl dmljZSB0aGF0IGdlbmVyYXRlcyBhbiBJUHY2IHBhY2tldCBjYW4gc2V0IHRoZSBmbG93IGxhYmVs LCBhbmQgdGhhdCBpcyB3aGF0IGRldmljZXMgaGF2ZSBiZWVuIGRvaW5nIGFsbCB0aGUgdGltZS4g VGhpcyBkcmFmdCBwcm9wb3NlcyBub3RoaW5nIG5ldyBmcm9tIHRoYXQgcGVyc3BlY3RpdmUuIA0K DQpXaHkgZG8geW91IHNheSDigJhyZXB1cnBvc2luZ+KAmSB0aGUgYml0cz8gTm90aGluZyBpcyBy ZXB1cnBvc2VkLiBUaGlzIHByb3Bvc2FsIGlzIHJlc3BlY3RpbmcgUkZDNjQzNy4gSW4gb3VyIGlu Zm9ybWF0aW9uYWwgcHJvcG9zYWwgdGhlIGZsb3ctbGFiZWwganVzdCByZW1haW5zIGZsb3ctbGFi ZWwuIFJvdXRlcnMgY2FuIGJlIG1hZGUgdG8gbWF0Y2ggdXBvbiBmbG93LWxhYmVsIHZhbHVlcyBl YXNpbHkuIEkga25vdyBteSBOb2tpYSBwcm9kdWN0cyBjYW4gZG8gdGhhdCB2ZXJ5IGVhc2lseSwg YmVjYXVzZSB0aGUgZmxvdy1sYWJlbCBpcyBhbHdheXMgZm91bmQgYXQgdGhlIHNhbWUgcGxhY2Ug aW4gdGhlIElQdjYgaGVhZGVyLiBIb3dldmVyLCBjaGVja2luZyBvbiBFSHMgaXMgYSBmZXcgZGlt ZW5zaW9ucyBtb3JlIGNvbXBsaWNhdGVkLiBXaGVuIEkgbXVzdCBtYWtlIG15IHJvdXRlciBtYXRj aCBmb3IgY29udGVudCBpbiBFSHMsIHRoZW4gZmlyc3QgaXQgbXVzdCBjaGVjayBpZiB0aGUgcmVs ZXZhbnQgRUggaXMgaW5zZXJ0ZWQsIHRoZW4gdGhlIGNvcnJlc3BvbmRpbmcgRUggbXVzdCBiZSBp ZGVudGlmaWVkIGFuZCB0aGVuIHRoZSBjb250ZW50IGhhcyB0byBiZSBjaGVja2Vk4oCmIFRoaXMg RUggY2hlY2tpbmcgaXMgbm9uLXRyaXZpYWwgYXMgcmVzdWx04oCmIEZvciBhIEhXIGJhc2VkIHJv dXRlciAobXkgTm9raWEgcm91dGVyIGZvciBleGFtcGxlKSB0aGUgY2hlY2tpbmcgb2YgZmxvdy1s YWJlbCBpcyBhcyBzaW1wbGUgYXMgY2hlY2tpbmcgZm9yIGEgRFNDUCB2YWx1ZSBiZWNhdXNlIHRo ZSBvcGVyYXRpb24gaW52b2x2ZWQgaXMgZXhhY3RseSB0aGUgc2FtZS4NCg0KVG9tLCBpZiB5b3Vy IGFkZGl0aW9uYWwgc3VnZ2VzdGlvbnMgZm9yIHVzaW5nIGZsb3cgbGFiZWxzIGlzIHJlc3BlY3Rp bmcgUkZDNjQzNyB0aGVuIHdoYXQgc3RvcHMgeW91IGZyb20gZG9jdW1lbnRpbmcgdGhvc2UgdGhv dWdodHM/IFRoZSBhbHRlcm5hdGUgbWFya2luZyBwcmluY2lwbGUgZG9jdW1lbnRlZCBpbiB0aGlz IGRyYWZ0IGZvciBTUnY2IGlzIHNvbWV0aGluZyB0aGF0IGlzIGRyaXZlbiBieSBvcGVyYXRvciB0 aGVtc2VsdmVzLCBhbmQgaXMgYmFzZWQgdXBvbiByZWFsIG9wZXJhdG9yIHJlcXVpcmVtZW50LiBG ZWVsIGZyZWUgdG8gZnVydGhlciBkaXNjdXNzIHdpdGggdGhlIFRlbGVrb20gSXRhbGlhIGNvLWF1 dGhvcnMgKEd1aXNlcHBlIGFuZCBNYXVybykgb24gVEkgbmVlZHMgZm9yIHN1Y2ggcGFzc2l2ZSBt ZWFzdXJlbWVudCBtZWNoYW5pc20gKGxvc3MsIGxhdGVuY3ksIGppdHRlciwgZXRjKS4gDQoNCkcv DQoNCg0KDQpPbiAwNy8xMS8yMDE3LCAxOToxNCwgIlRvbSBIZXJiZXJ0IiA8dG9tQGhlcmJlcnRs YW5kLmNvbT4gd3JvdGU6DQoNCiAgICBPbiBUdWUsIE5vdiA3LCAyMDE3IGF0IDk6MTMgQU0sIFZh biBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtDQogICAgQkUvQW50d2VycCkgPGd1bnRlci52YW5f ZGVfdmVsZGVAbm9raWEuY29tPiB3cm90ZToNCiAgICA+IFRvIG1lIGl0IHNlZW1zIHRoYXQgbG9v a2luZyBhdCBGTCBpcyBtdWNoIGVhc2llciBmb3IgYSBIVyBiYXNlZCByb3V0ZXIgdGhlbiBsb29r aW5nIGF0IEVIcyBpbiBhIGhvcC1ieS1ob3AgZmFzaGlvbuKApg0KICAgIA0KICAgIEVhc2llciBm b3Igd2hvbT8gUmVwdXJwb3NpbmcgYml0cyBpbiB0aGUgSVAgaGVhZGVyIGV2ZW4gZm9yIGEgbmFy cm93DQogICAgdXNlIGNhc2UgaW4gYSBjbG9zZWQgc3lzdGVtIGRvZXNuJ3Qgc2VlbSBwYXJ0aWN1 bGFybHkgZWFzeSB0bw0KICAgIHN0YW5kYXJkaXplIG9yIGRlcGxveS4gQXMgTWFyayBwb2ludGVk IG91dCB0aGVyZSdzIGEgbG90IG9mIGNvbXBsZXhpdHkNCiAgICBhcm91bmQgZW5zdXJpbmcgdGhh dCB0aGUgc3lzdGVtIHJlYWxseSBpcyBjbG9zZWQgYW5kIGFsbCByZXF1aXJlZA0KICAgIGJlaGF2 aW9yIGlzIG1haW50YWluZWQuDQogICAgDQogICAgQW5vdGhlciBvYnZpb3VzIHF1ZXN0aW9uIHdp dGggdGhpcyBhcHByb2FjaCBpcyBkb2VzIGl0IG1lYW4gdGhhdCBmbG93DQogICAgbGFiZWwgYml0 cyBhcmUgbm93IGZhaXIgZ2FtZSB0byBiZSBkZWZpbmVkIGZvciBldmVuIG1vcmUgcHVycG9zZXM/ DQogICAgTGF0ZW5jeSBtZWFzdXJlbWVudCBpc24ndCBiZSB0aGUgb25seSBwb3RlbnRpYWwgdXNl IGNhc2UuIEZvcg0KICAgIGluc3RhbmNlLCBJIGtub3cgdGhlcmUncyBhIGxvdCBvZiBwZW9wbGUg dGhhdCB3YW50IGhvc3RzIHRvIG1hcmsNCiAgICBwYWNrZXRzIHdpdGggYSAicmV0cmFuc21pdHRl ZCIgYml0IHNvIHRoYXQgcm91dGVycyBjYW4ga2VlcCBzdGF0cyBmb3INCiAgICB0cmFja2VkIGZs b3dzLiBJTU8sIGlmIHVzaW5nIGZsb3cgYml0cyBsaWtlIHRoaXMgaXMgdGhlIHJpZ2h0IGFuc3dl cg0KICAgIHRoZW4gdGhlcmUgc2hvdWxkIGJlIGEgZ2VuZXJpYyBwcm90b2NvbCBzcGVjaWZpY2F0 aW9uIHRoYXQgZGVmaW5lcyB0aGUNCiAgICBvcGVyYXRpb24gYW5kIGhvdyBiaXRzIGFyZSBhbGxv Y2F0ZWQgZm9yIGFsbCB0aGUgcG90ZW50aWFsIHVzZXMuDQogICAgDQogICAgVG9tDQogICAgDQog ICAgPg0KICAgID4gRy8NCiAgICA+DQogICAgPiBPbiAwNy8xMS8yMDE3LCAxNzo1OCwgIlRvbSBI ZXJiZXJ0IiA8dG9tQGhlcmJlcnRsYW5kLmNvbT4gd3JvdGU6DQogICAgPg0KICAgID4gICAgIE9u IFR1ZSwgTm92IDcsIDIwMTcgYXQgNzoyNiBBTSwgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lh IC0NCiAgICA+ICAgICBCRS9BbnR3ZXJwKSA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+ IHdyb3RlOg0KICAgID4gICAgID4gQSB0cmFuc2l0IHJvdXRlciBkb2VzIG5vdCBsb29rIGF0IEVI cyBpZiBpdCBpcyBub3QgY29uZmlndXJlZCBmb3IgdGhlIElQdjYgRGVzdGluYXRpb24gYWRkcmVz cy4uIHNvIGl0cyBub3QgdXNhYmxlIGluIHRoYXQgY2FzZS4NCiAgICA+ICAgICA+DQogICAgPiAg ICAgVGhleSBkbyBsb29rIGF0IGhvcC1ieS1ob3Agb3B0aW9ucy4gUHJldmlvdXNseSBpdCB3YXMg cmVxdWlyZWQgdGhhdA0KICAgID4gICAgIGFsbCBub2RlcyBpbiB0aGUgcGF0aCBtdXN0IHByb2Nl c3MgdGhlbSwgYnV0IHRoYXQgd2FzIHJlbGF4ZWQgYSBiaXQgaW4NCiAgICA+ICAgICBSRkM4MjAw LiBJZiB0aGV5IGFyZSBvbmx5IHVzZWQgZm9yIHR1bm5lbGluZyBhY3Jvc3MgYSBjb250cm9sbGVk DQogICAgPiAgICAgZG9tYWluIHRoZW4gdGhlIHR5cGljYWwgY29uY2VybiB0aGF0IGludGVybWVk aWF0ZSBub2RlcyBkb24ndCBwcm9wZXJseQ0KICAgID4gICAgIGhhbmRsZSBob3AtYnktaG9wIG9w dGlvbnMgY2FuIGJlIGFkZHJlc3NlZC4NCiAgICA+DQogICAgPiAgICAgVG9tDQogICAgPg0KICAg ID4gICAgID4gRy8NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KICAgID4gICAgID4gRnJvbTogVG9tIEhlcmJlcnQgW21haWx0bzp0b21AaGVyYmVy dGxhbmQuY29tXQ0KICAgID4gICAgID4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgNywgMjAxNyAx NjoxNg0KICAgID4gICAgID4gVG86IFZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtIEJFL0Fu dHdlcnApIDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4NCiAgICA+ICAgICA+IENjOiB2 Nm9wc0BpZXRmLm9yZw0KICAgID4gICAgID4gU3ViamVjdDogUmU6IFt2Nm9wc10gRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwt YWx0LW1hcmstMDEudHh0DQogICAgPiAgICAgPg0KICAgID4gICAgID4gT24gTW9uLCBOb3YgNiwg MjAxNyBhdCAxMDo0NCBQTSwgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0NCiAgICA+ICAg ICA+IEJFL0FudHdlcnApIDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4gd3JvdGU6DQog ICAgPiAgICAgPj4gSGkgVG9tLA0KICAgID4gICAgID4+DQogICAgPiAgICAgPj4gLS0+DQogICAg PiAgICAgPj4gRnJvbSBzZWN0aW9uIDE6DQogICAgPiAgICAgPj4NCiAgICA+ICAgICA+PiAiQmFz ZWQgb24gdGhlc2UgY29uc2lkZXJhdGlvbnMsIGl0IGlzIGFsbG93ZWQgdG8gdXNlIHRoZSBmbG93 IGxhYmVsIGZpZWxkIGluIGEgbWFuYWdlZCBkb21haW4sIGFzc3VtaW5nIHdoZW4gYSBwYWNrZXQg bGVhdmVzIHRoZSBkb21haW4sIHRoZSBvcmlnaW5hbCBmbG93IGxhYmVsIHZhbHVlIE1VU1QgYmUg cmVzdG9yZWQuIg0KICAgID4gICAgID4+DQogICAgPiAgICAgPj4gSW4gdGhpcyBwcm9wb3NhbCwg aWYgdHdvIGJpdHMgYXJlIG92ZXJ3cml0dGVuIGJ5IGFuIGludGVybWVkaWF0ZSBub2RlLCBob3cg YXJlIHRoZWlyIG9yaWdpbmFsIHZhbHVlcyByZXN0b3JlZCB3aGVuIGxlYXZpbmcgdGhlIGRvbWFp bj8NCiAgICA+ICAgICA+PiAtLT4NCiAgICA+ICAgICA+Pg0KICAgID4gICAgID4+IEdWPiAgQmVj YXVzZSB0aGUgZmllbGQgdGhhdCBhcmUgYmVpbmcgZmlkZGxlZCB3aXRoIGFyZSBvbiB0aGUgSVB2 NiBTUnY2IG91dGVyIGVuY2Fwc3VsYXRpb24gaGVhZGVyLiBXaGVuIHRoZSBvcmlnaW5hbCBwYWNr ZXQgbGVhdmVzIHRoZSBjb250cm9sbGVkIGRvbWFpbiwgdGhlbiB0aGF0IGhlYWRlciBpcyByZW1v dmVkIGFnYWluLCBhbmQgdGhlIG9yaWdpbmFsIElQdjYgcGFja2V0IHdpdGggb3JpZ2luYWwgaGVh ZGVycyBhcHBlYXIgYWdhaW4uDQogICAgPiAgICAgPj4NCiAgICA+ICAgICA+IEd1bnRlciwNCiAg ICA+ICAgICA+DQogICAgPiAgICAgPiBJZiB0aGUgbWVhc3VyZW1lbnRzIGFyZSBhbHdheXMgY29p bmNpZGVudCB3aXRoIHRoZSB1c2Ugb2YgU1J2NiB0aGVuIHdoeSBub3QgcHV0IHRoZSBtZWFzdXJl bWVudCBpbmZvcm1hdGlvbiBpbiB0aGUgU1IgRUggb3Igc29tZSBvdGhlciBFSCAoaG9wLWJ5LWhv cCBvciBlc3Qgb3B0IG1heWJlKSB1c2VkIG9ubHkgaW4gdGhlIGNvbnRyb2xsZWQgZG9tYWluPyBU aGlzIGFsc28gY291bGQgYmUgbW9yZSBmbGV4aWJsZSBzaW5jZSB0aGUgYWxnb3JpdGhtIHdvdWxk bid0IGJlIGNvbnN0cmFpbmVkIHRvIGp1c3QgdHdvIGJpdHMgb2YgZGF0YS4NCiAgICA+ICAgICA+ DQogICAgPiAgICAgPiBUb20NCiAgICA+DQogICAgPg0KICAgIA0KDQo= From nobody Tue Nov 7 12:00:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3A713321A for ; Tue, 7 Nov 2017 12:00:27 -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 djQaoOBtqnZx for ; Tue, 7 Nov 2017 12:00:25 -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 C45FF1331E1 for ; Tue, 7 Nov 2017 12:00:23 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id CA3CA42287 for ; Tue, 7 Nov 2017 21:00:21 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id B8CC441B8F; Tue, 7 Nov 2017 21:00:21 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id B53934053E; Tue, 7 Nov 2017 21:00:21 +0100 (CET) Date: Tue, 7 Nov 2017 21:00:21 +0100 From: Gert Doering To: Mark Smith Cc: Ole Troan , v6ops list Message-ID: <20171107200021.GX45648@Space.Net> References: <150860492012.3131.14623048904955800548.idtracker@ietfa.amsl.com> <0EAB4149-AFE9-4770-8242-6D8E05889091@consulintel.es> <66E223E7-73B5-49BA-AA40-5AA632F3F755@consulintel.es> <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 20:00:27 -0000 Hi, On Tue, Nov 07, 2017 at 06:15:11PM +1100, Mark Smith wrote: > If the optimisation causes issues that have to be worked around > somewhere else, and the optimisation doesn't provide an obvious > benefit, is it really a useful and worth while optimsation? people point routing towards p2p *links* and not "next-hops" because they do not care, and do not *want* to care what the neighbouring IP address is. "ipv6 route 2001:db8::/48 serial3" is legit and useful. Starting to do ND for every single address in that /48 would be totally the wrong way to do. The fact that there is no link layer resolution on p2p links is a plus, trying to make it "look like ethernet" would be a major drawback (and I strongly defute any claim that "the generalization of ARP into IPv6 ND is a *good thing*" - L2 resolution using a routable protocol and relying on implementations to ensure that it's then "not routed" or "properly filtered of TTL is not 255" was just plain stupid) 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 7 12:16:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919BB13202D for ; Tue, 7 Nov 2017 12:16:00 -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 9GT11tp6ii7p for ; Tue, 7 Nov 2017 12:15:59 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d: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 84F4D133158 for ; Tue, 7 Nov 2017 12:15:58 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id n66so609120qki.8 for ; Tue, 07 Nov 2017 12:15:58 -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=anH4Vug0V48Ial65L3/myZjWtT/+siY+jH46v9XjB4Y=; b=AO/JsLj7UjlLlD/GcKvBjUQ9z9gWgBOPImhCjlEI+/FXI56D0jqXQUE+ZRclNPHN5c 5MgIJGDmyEPnPoHO9lwOime5w5w/FFAH/Ao4AezIfGcb4zVEBdpPPXfKmy2c9m80j1Fc VfQZ96j3TnJUJr+UL8U3xJ4ueRB0IgNMi58q90wqMHqi7Z9m1z7gdDIUQ9vJMGr3NbsL KKj6vXhCI6tMr0WCravx1FYJKe36zPkLahEWuCAo6XNTz5aqlUL/kkBgf1NcrthMcdsT Bey9ZcAIUO0FuwP2cFl4ysVfhTpXOwnJoBSLzIBM+/0kJQlFc3mvwQeBWJFi79ySlfN5 t4JA== 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=anH4Vug0V48Ial65L3/myZjWtT/+siY+jH46v9XjB4Y=; b=dmcwfGzIB/chTw+KJZ7j203RNqq/8S14tlSVP5jdeR8jX3kCaC64vBCnljd6kAWy0e zwRGUufVK/13blcPJpH/aujBfHFku+I1fZoy/SF5whMRFKcvo4h4jCcTipPeVN9BGQed zKM832meuA0VVX5t8UFv3uEFzbPM3qpDjb9duXFrX6sPbmBefHh4DRY8y7jW1yNNYnKP qoCXv4noVn5eeR+xLr7difHMlnaWhhT1K+LrJs7e0Qt51sVHzmvISEkRG/gmrD73PPH9 dlPF6kUo5gG0gI1FDwfax9qecr/zTwx3Z8zrdOSdqisp8ueV1LeyY1JDhN7moa0f/RGH xe8g== X-Gm-Message-State: AJaThX5/EZlVvSAQntc2hHOh4XpUApWgOuz8DF1ll0DM/EJCmObxC7Km KI7M/X2rzWuRa1JrDFGVM+9ouEKr51NQIL++6NyMGg== X-Google-Smtp-Source: ABhQp+QPV+1/eODgqAWic18jcF9eWSd4UAITcDnVxYveeBY/k0nASDKXZtWxKNGk6t4YqatSRZnUaQFFbv+LqMZc31Y= X-Received: by 10.55.132.133 with SMTP id g127mr29979193qkd.72.1510085757329; Tue, 07 Nov 2017 12:15:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Tue, 7 Nov 2017 12:15:56 -0800 (PST) In-Reply-To: <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> From: Tom Herbert Date: Tue, 7 Nov 2017 12:15:56 -0800 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 20:16:01 -0000 On Tue, Nov 7, 2017 at 11:53 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Tom, > > The closed system here is defined by the SRv6 tunnels=E2=80=A6 The flow-l= abel is set =E2=80=9Conly=E2=80=9D by the tunnel head-end router =E2=80=9Co= n the outer IPv6 header=E2=80=9D. The tunnel head-end router can do this be= cause it is the device that created the outer IP header. > The original IPv6 packet is riding inside the tunnel, and as result the o= riginal flow label and original IPv6 header is left untouched. The closed s= ystem is the network between the tunnel head-end (=3Dwhere the > outer IPv6 header is added) and the tunnel tail-end (=3Dwhere the outer h= eader is removed). This type of closed system is easy to deploy=E2=80=A6 ta= ke for example a MPLS/VPN backbone=E2=80=A6. Or a VxLAN network=E2=80=A6 Th= e SRv6 network is something of similar simplicity. > > The IPv6 device that generates an IPv6 packet can set the flow label, and= that is what devices have been doing all the time. This draft proposes not= hing new from that perspective. > Gunter, I believe section 3 imposes new requirements on flow label usage. Specifica= lly: "The methodology SHOULD be used within a controlled domain where the load-balancing based on flow label is disabled. Otherwise, the network element MUST mask the Mark Field (MF), so it will not change hashing calculation for the same flow because only 18 bits + 2 zeros are used for the entropy." This implies that the proposal is not compatible with the canonical use of flow label for ECMP. If option one is selected then the only use of the flow label is to express the MF bits the whole flow label has been repurposed and we lose the value of flow hashing. Option 2 requires an implementation change to routers function, and as I pointed, there would likely be other uses of bits so this really should be defined as a configurable mask. As I said before, neither of these options seem desirable. Tom From nobody Tue Nov 7 12:37:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD14126D85 for ; Tue, 7 Nov 2017 12:37:23 -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_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=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 z2_urmDkJh5W for ; Tue, 7 Nov 2017 12:37:20 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0113.outbound.protection.outlook.com [104.47.0.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 4047F126D73 for ; Tue, 7 Nov 2017 12:37:20 -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=L1MNhq9eDAImhURp1RCg64Sprdv/pio8i6mJqm6GeCA=; b=sDjXkAQevbTXSHmLDB2INihgeqN8xq0xBV+c98Gez+djaEsWRDk0vLGFbCcN1igbcRbyVKL/lXIg0jQPpbGBRnBIFOe3vxRUA0jDnl2VOruBsVm2O9bE9TBeNanHXsGEwKzqpS/wuyy0bxdl7Nax4FEFJ5Dnyluk9r2Isr6V5Uw= 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_P256) id 15.20.218.6; Tue, 7 Nov 2017 20:37:17 +0000 Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004%14]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 20:37:17 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Tom Herbert CC: "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYwgACbq4CAAFvKQIAAj8qAgAACmRCAABn/gIAABDIAgAARHYCAABuOgIAABkYAgAAF9gA= Date: Tue, 7 Nov 2017 20:37:17 +0000 Message-ID: <008938C4-0861-4BF1-A265-6EE323742B19@nokia.com> References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.242.22.169] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2833; 6:oBXEVtYCdOxsKz+CIjdGzgT55+nBfda7psPO+5xJZHK+Hv+RVUXc+LoS70KvBXkEooo6McXbPOsbgfqUd962c9yc+0tDihPnbrSF39x0HcxvW/9j8+YuNstH0S2Df0j3Q4iFs4nMr6RnlpfyhA0WLB8T5iHgkW0yiOScXFzWAKmv5P1QXZkUtxMEG3dF2zTwEFiWdNFlCmSkvnVPqpmSN9Pb3oPC9ESOheZVPBMpzbu5Lam/66B+Qw2qRwieUL7w9XD6yQ1li0/bY+XhAE6tFKHMvGwtI4vsuYuaOw3olgYHGES+rVtDVuJing+Hw7O+1JrNye28tG59EX0T3l7h3dw2Tfs+onlXglh3xseMXDg=; 5:cddIHQr8bvAvEUIYD2HaWFAWY/SpFFwL2yl/rF1PIT60TF1vF4yws9VGVrOXLiZlpFbxPcH7JvUYWuyOrwXVUWzVgP5i7fm/oC+/F0P5rjZltHmLeFq3yPqlHT5oePJYnx3G6MS/vvjw5NL8+tPcXI0tqxO1yAVjmC2tYyYYKBk=; 24:1l0GYdwM0QglteqpzbSS2Iwd25Px+Rmbv5Wwm1ZXv7DOQhoNV2L0lQ0A3xyZT+xgVKtuG6ZmCGOgMIKAw4dNArrxvowwGBt6NlGLdPRekuM=; 7:jhGZtjVgnbvVYS9ZNx8U7nmNPNxs88yeMpW935uBaiD5Or1oyJzRPRkDeMRT8MkH+kGSQ64aufs84XftEcDLde/tLRfL1ZPw0w6hNjQhl7hBMFsqUKHl7AsQ9s0yt+STrtO/Dcz47ekAKKbiedzEJTIrh+B+yLJrqaj50zRdQ+4hVZS3ODy76TiFYHaVn+ccnFHQYL5lcJaLFJfMWsPr6NK6Ii+yFuelvC5gIUUGGHj893+ocPWgdGK4G6MIF3Ec x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ce4489f1-75d8-4063-5add-08d5261f563f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603249); SRVR:AM5PR0701MB2833; x-ms-traffictypediagnostic: AM5PR0701MB2833: x-exchange-antispam-report-test: UriScan:(82608151540597)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3231021)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(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: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(199003)(189002)(24454002)(50986999)(82746002)(5250100002)(5890100001)(76176999)(97736004)(102836003)(6116002)(3846002)(83716003)(4326008)(36756003)(86362001)(53936002)(561944003)(6246003)(101416001)(66066001)(478600001)(6512007)(2900100001)(54356999)(6916009)(105586002)(106356001)(25786009)(230783001)(53546010)(33656002)(14454004)(99286004)(5660300001)(2950100002)(68736007)(316002)(8936002)(7736002)(93886005)(305945005)(3280700002)(81166006)(229853002)(8676002)(81156014)(2906002)(6506006)(6486002)(189998001)(3660700001)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2833; 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="utf-8" Content-ID: <671E5FF09E69E24F9591084DBC24CC01@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce4489f1-75d8-4063-5add-08d5261f563f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 20:37:17.4689 (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: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 20:37:23 -0000 SW4gdGhpcyBjYXNlLCB0aGUgY29udHJvbGxlZCBkb21haW4gcmVmbGVjdHMgdG8gdGhlIGZhY3Qg dGhhdCBpdCBpcyBvcGVyYXRvciBjaG9pY2UgdGhhdCBncmFicyBjb250cm9sIG9mIHBhY2tldCBo YW5kbGluZyB3aXRoaW4gaXRzIG93biBuZXR3b3JrLg0KVGhlIG9wZXJhdG9yIGFkZHMgdGhyb3Vn aCBwb2xpY3kgdGhlIG91dGVyIFNSdjYgaGVhZGVyLiBUaGUgb3BlcmF0b3IgaGFzIGluIGZhY3Qg dGhlbiB0aHJlZSBvcHRpb25zIHJlZ2FyZGluZyBmbG93IGxhYmVsOg0KDQoxKSBKdXN0IGRvIG5v dCBkbyBhbnl0aGluZyB3aXRoIEZsb3ctbGFiZWwgKGxlYXZlIGl0IGRlZmF1bHQpDQoyKSBBbHRl cm5hdGUgbWFya2luZyBvbmx5IGFuZCBOTyB1c2FnZSBvZiBlbnRyb3B5IA0KMykgQWx0ZXJuYXRl IG1hcmtpbmcgYW5kIGVudHJvcHkgKGluIHRoaXMgY2FzZSB0aGUgZW50cm9weSBTSE9VTEQgYmUg YmFzZWQgdXBvbiAxOCBiaXRzIGluc3RlYWQgb2YgMjAgYml0cyBiZWNhdXNlIG90aGVyd2lzZSBw YXRocyBtYXkgYmUgY2hhbmdlZCB3aGVuIHRoZSBtYXJraW5nIGNoYW5nZXMgKGUuZy4gcGVyaW9k cyBvZiA1IG1pbnV0ZXMgcGVyIG1hcmtpbmcgcGVyaW9kKSDigKYuIFRoaXMgaXMgaG93ZXZlciBu b3QgYSBNVVNUIGJlY2F1c2Ugc29tZSBvcGVyYXRvcnMgZG8gbm90IGNhcmUgaWYgYmVjYXVzZSBv ZiBtYXJraW5nIGNoYW5nZS4NCg0KRndpdyByaWdodCBub3csIG1vc3QgdmVuZG9ycyBhbGxvdyBh IHdpZGUgYnJlYXRoIG9mIG9wdGlvbnMgZm9yIGVudHJvcHkgaGFzaGluZyB1cG9uIGFuIElQIGhl YWRlcuKApiBhbmQgbWFueSBvZiB0aGUgY29tYmluYXRpb25zIGRvIG5vdCBoYXZlIGEgZm9ybWFs IFJGQyBhdHRhY2hlZCBmb3IgdGhhdCBvcGVyYXRpb24gYXQgYWxsLiBUaGlzIGhhc2ggdXBvbiAx OCBiaXRzIG9mIGZsb3cgbGFiZWwgd291bGQganVzdCBiZSBhbm90aGVyIGZsYXZvdXIgb2YgZW50 cm9weSB0aGF0IG9wZXJhdG9yIGNhbiBlbmFibGUgdXBvbiB0aGUgcm91dGVyIOKApiBpdCBpcyBu b3QgaGFyZCAuLi4gSSBhcyB2ZW5kb3IgY2FuIGRlbGl2ZXIgdGhpcyBhbmQgSSBuZWVkIG5vIHN0 YW5kYXJkIGZvciB0aGlzIGJlY2F1c2UgaXQgaXMgbm9kYWwgYmVoYXZpb3Vy4oCmIEFuIGVtYm9k aW1lbnQgb2YgYW4gaW1wcm92ZWQgaGFzaCB1cG9uIHRoZSBmbG93LWxhYmVsIGNvdWxkIGluZGVl ZCBtYWtlIHVzZSBvZiB3aWxkLWNhcmRzIOKApiBBIHdpbGRjYXJkIG1hdGNoIHVwb24gZmxvdy1s YWJlbCBmb3IgZW50cm9weSBjb3VsZCBiZSBhbm90aGVyIHByb3Bvc2FsIHRvIHBvdGVudGlhbGx5 IGhhdmUgbmV3IGZsb3ctbGFiZWwgZmllbGQgdXNhZ2XigKYgaG93ZXZlciwgaXQgY29tZXMgYXQg YSBjb3N04oCmIGVhY2ggYml0IHRoYXQgaXMgcmVtb3ZlZCBmcm9tIHRoZSBlbnRyb3B5IGhhc2gg LCByZXN1bHRzIGlzIExFU1MgZW50cm9weSwgd2hpY2ggaXMgdW5kZXNpcmFibGUgYWxzby4gQWxz byBhZHZhbmNlZCB3aWxkLWNhcmQgYmFzZWQgaGFzaCBmb3IgZW50cm9weSB1cG9uIGZsb3ctbGFi ZWwgZ29lcyBiZXlvbmQgdGhlIG5lZWQgZm9yIEFsdGVybmF0ZSBtYXJraW5nIHdpdGhpbiB0aGUg b3BlcmF0b3IgY29udHJvbGxlZCBkb21haW4sIGhlbmNlIHdlIHNlZSBubyBuZWVkIGZvciBzdWNo IHR5cGUgb2Ygd2lsZCBjYXJkIGJhc2VkIGhhc2jigKYNCg0KRy8NCg0KT24gMDcvMTEvMjAxNywg MjE6MTUsICJUb20gSGVyYmVydCIgPHRvbUBoZXJiZXJ0bGFuZC5jb20+IHdyb3RlOg0KDQogICAg T24gVHVlLCBOb3YgNywgMjAxNyBhdCAxMTo1MyBBTSwgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5v a2lhIC0NCiAgICBCRS9BbnR3ZXJwKSA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+IHdy b3RlOg0KICAgID4gSGkgVG9tLA0KICAgID4NCiAgICA+IFRoZSBjbG9zZWQgc3lzdGVtIGhlcmUg aXMgZGVmaW5lZCBieSB0aGUgU1J2NiB0dW5uZWxz4oCmIFRoZSBmbG93LWxhYmVsIGlzIHNldCDi gJxvbmx54oCdIGJ5IHRoZSB0dW5uZWwgaGVhZC1lbmQgcm91dGVyIOKAnG9uIHRoZSBvdXRlciBJ UHY2IGhlYWRlcuKAnS4gVGhlIHR1bm5lbCBoZWFkLWVuZCByb3V0ZXIgY2FuIGRvIHRoaXMgYmVj YXVzZSBpdCBpcyB0aGUgZGV2aWNlIHRoYXQgY3JlYXRlZCB0aGUgb3V0ZXIgSVAgaGVhZGVyLg0K ICAgID4gVGhlIG9yaWdpbmFsIElQdjYgcGFja2V0IGlzIHJpZGluZyBpbnNpZGUgdGhlIHR1bm5l bCwgYW5kIGFzIHJlc3VsdCB0aGUgb3JpZ2luYWwgZmxvdyBsYWJlbCBhbmQgb3JpZ2luYWwgSVB2 NiBoZWFkZXIgaXMgbGVmdCB1bnRvdWNoZWQuIFRoZSBjbG9zZWQgc3lzdGVtIGlzIHRoZSBuZXR3 b3JrIGJldHdlZW4gdGhlIHR1bm5lbCBoZWFkLWVuZCAoPXdoZXJlIHRoZQ0KICAgID4gb3V0ZXIg SVB2NiBoZWFkZXIgaXMgYWRkZWQpIGFuZCB0aGUgdHVubmVsIHRhaWwtZW5kICg9d2hlcmUgdGhl IG91dGVyIGhlYWRlciBpcyByZW1vdmVkKS4gVGhpcyB0eXBlIG9mIGNsb3NlZCBzeXN0ZW0gaXMg ZWFzeSB0byBkZXBsb3nigKYgdGFrZSBmb3IgZXhhbXBsZSBhIE1QTFMvVlBOIGJhY2tib25l4oCm LiBPciBhIFZ4TEFOIG5ldHdvcmvigKYgVGhlIFNSdjYgbmV0d29yayBpcyBzb21ldGhpbmcgb2Yg c2ltaWxhciBzaW1wbGljaXR5Lg0KICAgID4NCiAgICA+IFRoZSBJUHY2IGRldmljZSB0aGF0IGdl bmVyYXRlcyBhbiBJUHY2IHBhY2tldCBjYW4gc2V0IHRoZSBmbG93IGxhYmVsLCBhbmQgdGhhdCBp cyB3aGF0IGRldmljZXMgaGF2ZSBiZWVuIGRvaW5nIGFsbCB0aGUgdGltZS4gVGhpcyBkcmFmdCBw cm9wb3NlcyBub3RoaW5nIG5ldyBmcm9tIHRoYXQgcGVyc3BlY3RpdmUuDQogICAgPg0KICAgIEd1 bnRlciwNCiAgICANCiAgICBJIGJlbGlldmUgc2VjdGlvbiAzIGltcG9zZXMgbmV3IHJlcXVpcmVt ZW50cyBvbiBmbG93IGxhYmVsIHVzYWdlLiBTcGVjaWZpY2FsbHk6DQogICAgDQogICAgIlRoZSBt ZXRob2RvbG9neSBTSE9VTEQgYmUgdXNlZCB3aXRoaW4gYSBjb250cm9sbGVkIGRvbWFpbiB3aGVy ZSB0aGUNCiAgICBsb2FkLWJhbGFuY2luZyBiYXNlZCBvbiBmbG93IGxhYmVsIGlzIGRpc2FibGVk LiAgT3RoZXJ3aXNlLCB0aGUNCiAgICBuZXR3b3JrIGVsZW1lbnQgTVVTVCBtYXNrIHRoZSBNYXJr IEZpZWxkIChNRiksIHNvIGl0IHdpbGwgbm90IGNoYW5nZQ0KICAgIGhhc2hpbmcgY2FsY3VsYXRp b24gZm9yIHRoZSBzYW1lIGZsb3cgYmVjYXVzZSBvbmx5IDE4IGJpdHMgKyAyIHplcm9zDQogICAg YXJlIHVzZWQgZm9yIHRoZSBlbnRyb3B5LiINCiAgICANCiAgICBUaGlzIGltcGxpZXMgdGhhdCB0 aGUgcHJvcG9zYWwgaXMgbm90IGNvbXBhdGlibGUgd2l0aCB0aGUgY2Fub25pY2FsDQogICAgdXNl IG9mIGZsb3cgbGFiZWwgZm9yIEVDTVAuIElmIG9wdGlvbiBvbmUgaXMgc2VsZWN0ZWQgdGhlbiB0 aGUgb25seQ0KICAgIHVzZSBvZiB0aGUgZmxvdyBsYWJlbCBpcyB0byBleHByZXNzIHRoZSBNRiBi aXRzIHRoZSB3aG9sZSBmbG93IGxhYmVsDQogICAgaGFzIGJlZW4gcmVwdXJwb3NlZCBhbmQgd2Ug bG9zZSB0aGUgdmFsdWUgb2YgZmxvdyBoYXNoaW5nLiBPcHRpb24gMg0KICAgIHJlcXVpcmVzIGFu IGltcGxlbWVudGF0aW9uIGNoYW5nZSB0byByb3V0ZXJzIGZ1bmN0aW9uLCBhbmQgYXMgSQ0KICAg IHBvaW50ZWQsIHRoZXJlIHdvdWxkIGxpa2VseSBiZSBvdGhlciB1c2VzIG9mIGJpdHMgc28gdGhp cyByZWFsbHkNCiAgICBzaG91bGQgYmUgZGVmaW5lZCBhcyBhIGNvbmZpZ3VyYWJsZSBtYXNrLiBB cyBJIHNhaWQgYmVmb3JlLCBuZWl0aGVyIG9mDQogICAgdGhlc2Ugb3B0aW9ucyBzZWVtIGRlc2ly YWJsZS4NCiAgICANCiAgICBUb20NCiAgICANCg0K From nobody Tue Nov 7 14:28:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12BA12944A for ; Tue, 7 Nov 2017 14:28:29 -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 WM4InmCz6pbt for ; Tue, 7 Nov 2017 14:28:28 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d: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 A85F912942F for ; Tue, 7 Nov 2017 14:28:27 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id q83so1058134qke.6 for ; Tue, 07 Nov 2017 14:28:27 -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=yySYM7yHoL1GFncE0WzvE9Z1TOl4J1su9w84mb+PN5c=; b=GKl/lLYa5vBn5GHHBugVEb515Hr2yA3FnnSQ+SqqjFRWhbwEp9Ag0LgEqpFlCdoLJg BvlBO6X1SPUi7gr7dxtxFB5uXIpXBXUelcLgxnck1bWfKOZv9Q4/LnligstDL5s0Cny5 KWtP5TNlTBbgolreE3dVfCa5wQSScVMKQy2AxflNuuvmqI5wcJAXnrT62McsV/UFVYYr WhsCbcVh7YprabYPV1vbZCSDhgfL2yauRJcG/Gw02qJD99FnzJ6aDLW8UhwafyPAz6XJ c8nBAv3lQ4rDT0inwE5hMQMbtHLd41CIyKS+agpmKiu4IyNhg9DaN9QkmampSCkac21v aLAg== 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=yySYM7yHoL1GFncE0WzvE9Z1TOl4J1su9w84mb+PN5c=; b=lFfla5AyOVLmEuGGxd8jvGg13ZwV3tydeL2eClQAUX3WZCMSW2nKOTbr+NN0nwoO2S ZJ2pdkCZRogP0jOvoOIAHEpSfVurukV++p/8u/Z0EeqzAk3jGJCsmpcD8rPYpKaIyROB ng2yDdpFDG07qHjDYQK/5EJxkerZH5r73CEQBk67Nk6HaowB4ChOWriDodUVnIgYQwvG lF0Hxmt6rOOGAeC2CKc2xXnLXKP5+QVS6HttX7WWfrpw3WqpD67Ogg+l/NFdpUaF85f3 yhW5I36hBR/z/8G7EJ5v1pWzuFfSjKgALafSpZEEODFhIOnHb2OHmTnj+siTTBXfsvM7 /sAA== X-Gm-Message-State: AJaThX4/t7TkBrVr7gqpd6Kpujp4jgIOsl844FdaJtARXPJyIG3KZpuM lWl81GLgFc/DN6QH7kcYV7lIPGrJG7RhALj+9rVRzA== X-Google-Smtp-Source: AGs4zManDHFOg/YcBGX9QeLS/Q91y2snhcI6zc624ZEcvM37ImcaWoPIBEEPAZh5z02YLQi2u+lvP8rZmqr9foPog+4= X-Received: by 10.55.102.131 with SMTP id a125mr405889qkc.345.1510093706640; Tue, 07 Nov 2017 14:28:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Tue, 7 Nov 2017 14:28:25 -0800 (PST) In-Reply-To: <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> From: Tom Herbert Date: Tue, 7 Nov 2017 14:28:25 -0800 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 22:28:30 -0000 On Tue, Nov 7, 2017 at 11:53 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > Hi Tom, > > The closed system here is defined by the SRv6 tunnels=E2=80=A6 The flow-l= abel is set =E2=80=9Conly=E2=80=9D by the tunnel head-end router =E2=80=9Co= n the outer IPv6 header=E2=80=9D. The tunnel head-end router can do this be= cause it is the device that created the outer IP header. > The original IPv6 packet is riding inside the tunnel, and as result the o= riginal flow label and original IPv6 header is left untouched. The closed s= ystem is the network between the tunnel head-end (=3Dwhere the > outer IPv6 header is added) and the tunnel tail-end (=3Dwhere the outer h= eader is removed). This type of closed system is easy to deploy=E2=80=A6 ta= ke for example a MPLS/VPN backbone=E2=80=A6. Or a VxLAN network=E2=80=A6 Th= e SRv6 network is something of similar simplicity. > > The IPv6 device that generates an IPv6 packet can set the flow label, and= that is what devices have been doing all the time. This draft proposes not= hing new from that perspective. > > Why do you say =E2=80=98repurposing=E2=80=99 the bits? Nothing is repurpo= sed. This proposal is respecting RFC6437. In our informational proposal the= flow-label just remains flow-label. Routers can be made to match upon flow= -label values easily. I know my Nokia products can do that very easily, bec= ause the flow-label is always found at the same place in the IPv6 header. H= owever, checking on EHs is a few dimensions more complicated. When I must m= ake my router match for content in EHs, then first it must check if the rel= evant EH is inserted, then the corresponding EH must be identified and then= the content has to be checked=E2=80=A6 This EH checking is non-trivial as = result=E2=80=A6 For a HW based router (my Nokia router for example) the che= cking of flow-label is as simple as checking for a DSCP value because the o= peration involved is exactly the same. I don't believe the EH processing needs to be complicated. In this case the assumption is that network operator is inserting the headers so the HBH EH with a latency measurement option could be implemented to always be in the same position, have the same length, and only set with one option for latency. The router processingcan be optimized to handle this case. Existence and verification of the EH can all be done with simple checks and TCAM could be used to match the common header pattern. The IP header and extension header should fit well within the parsing buffer of typical routers. > > Tom, if your additional suggestions for using flow labels is respecting R= FC6437 then what stops you from documenting those thoughts? The alternate m= arking principle documented in this draft for SRv6 is something that is dri= ven by operator themselves, and is based upon real operator requirement. Fe= el free to further discuss with the Telekom Italia co-authors (Guiseppe and= Mauro) on TI needs for such passive measurement mechanism (loss, latency, = jitter, etc). The fact that operators want passive latency measurements is not the same as saying that applying a format to the flow label is a requirement. It is the mechanism of this proposal this is in question. Tom > > G/ > > > > On 07/11/2017, 19:14, "Tom Herbert" wrote: > > On Tue, Nov 7, 2017 at 9:13 AM, Van De Velde, Gunter (Nokia - > BE/Antwerp) wrote: > > To me it seems that looking at FL is much easier for a HW based rou= ter then looking at EHs in a hop-by-hop fashion=E2=80=A6 > > Easier for whom? Repurposing bits in the IP header even for a narrow > use case in a closed system doesn't seem particularly easy to > standardize or deploy. As Mark pointed out there's a lot of complexit= y > around ensuring that the system really is closed and all required > behavior is maintained. > > Another obvious question with this approach is does it mean that flow > label bits are now fair game to be defined for even more purposes? > Latency measurement isn't be the only potential use case. For > instance, I know there's a lot of people that want hosts to mark > packets with a "retransmitted" bit so that routers can keep stats for > tracked flows. IMO, if using flow bits like this is the right answer > then there should be a generic protocol specification that defines th= e > operation and how bits are allocated for all the potential uses. > > Tom > > > > > G/ > > > > On 07/11/2017, 17:58, "Tom Herbert" wrote: > > > > On Tue, Nov 7, 2017 at 7:26 AM, Van De Velde, Gunter (Nokia - > > BE/Antwerp) wrote: > > > A transit router does not look at EHs if it is not configured= for the IPv6 Destination address.. so its not usable in that case. > > > > > They do look at hop-by-hop options. Previously it was required = that > > all nodes in the path must process them, but that was relaxed a= bit in > > RFC8200. If they are only used for tunneling across a controlle= d > > domain then the typical concern that intermediate nodes don't p= roperly > > handle hop-by-hop options can be addressed. > > > > Tom > > > > > G/ > > > > > > -----Original Message----- > > > From: Tom Herbert [mailto:tom@herbertland.com] > > > Sent: Tuesday, November 7, 2017 16:16 > > > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > > > Cc: v6ops@ietf.org > > > Subject: Re: [v6ops] FW: New Version Notification for draft-f= ioccola-spring-flow-label-alt-mark-01.txt > > > > > > On Mon, Nov 6, 2017 at 10:44 PM, Van De Velde, Gunter (Nokia = - > > > BE/Antwerp) wrote: > > >> Hi Tom, > > >> > > >> --> > > >> From section 1: > > >> > > >> "Based on these considerations, it is allowed to use the flo= w label field in a managed domain, assuming when a packet leaves the domain= , the original flow label value MUST be restored." > > >> > > >> In this proposal, if two bits are overwritten by an intermed= iate node, how are their original values restored when leaving the domain? > > >> --> > > >> > > >> GV> Because the field that are being fiddled with are on th= e IPv6 SRv6 outer encapsulation header. When the original packet leaves the= controlled domain, then that header is removed again, and the original IPv= 6 packet with original headers appear again. > > >> > > > Gunter, > > > > > > If the measurements are always coincident with the use of SRv= 6 then why not put the measurement information in the SR EH or some other E= H (hop-by-hop or est opt maybe) used only in the controlled domain? This al= so could be more flexible since the algorithm wouldn't be constrained to ju= st two bits of data. > > > > > > Tom > > > > > > From nobody Tue Nov 7 21:05:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF53412EBAE for ; Tue, 7 Nov 2017 21:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY2aAD9eal2A for ; Tue, 7 Nov 2017 21:05:20 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0108.outbound.protection.outlook.com [104.47.0.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 C2A92129422 for ; Tue, 7 Nov 2017 21:05:19 -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=dX9kpd4/7eJU8WTgu3cure04/3TgkNqWMTMTAwxHBFk=; b=YWl4/eQTnvP9Y7Hp9NOAVKFSWfjGHiNL/9exk6Lz3UoLSwsJj/SxzQ5Vt3dmTysR+JU3XQ7QmV6HO2YvAshrC82Igz+bqFAJOfHB3AYV4kAiK4SLghQ0cvYpIdWMNgQQCaSYV9DYK39X2auVZ3wPoZju0OS/8/B+GxxFcJAgPKI= 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_P256) id 15.20.218.6; Wed, 8 Nov 2017 05:05:16 +0000 Received: from AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004]) by AM5PR0701MB2836.eurprd07.prod.outlook.com ([fe80::f00a:2571:e709:3004%14]) with mapi id 15.20.0218.005; Wed, 8 Nov 2017 05:05:16 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Tom Herbert CC: "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYwgACbq4CAAFvKQIAAj8qAgAACmRCAABn/gIAABDIAgAARHYCAABuOgIAAK0qAgABp9BA= Date: Wed, 8 Nov 2017 05:05:16 +0000 Message-ID: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.242.22.169] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2835; 6:tnmSSsl6s3Zfa6CFVDFOGosJGk495cUhGJOYio5nVMSPbmafOYK9zZ4OpEnxaAdx28rQMfMr/zuu6Ovn8eDC+k2aHjJzTCvqe2+AGe8fJP98HOmUBaAbdi48QWjPUMjg0ILhXMyyHAivhcCwe/ICj41mbncpKkkwXmGzvhm6dNc0+9GOM/uaVx3bWpb1yJDtKShONUfwij5JN75dHSwIdc0kOZZ6nS/Awd4cyKC6OT0zht4X1NkwYBfisLsVKxYZT37J4rClWIE2pUmsjb4EU5iPiPNICygaQq337r7L4s/DRmX65p/noQJO764hZknI0IL05tBDG2B+ZRJ2I3u7020OerY8B9VQMo/AtO3JObk=; 5:6jgKPw81BrKUebinU88VgwdQ+Nnwf5y0G4GqdI9xHjtKOYkGoFfExfkJtJ79zU5l0olJzoiCuwiWPQXRpwr6BpPETcjOaZ9eTfL5x0NfG6B6FeW+hVEdPgXKe7SKhD/SMmDTM6Y/waE+PuMhhoYaRFWYxMtm+738S2DOBU2VrS4=; 24:r/x4rEesiNxH/ZXpqjnqi3o7wl/w62zII0homgz4yV3m7TTOXUIaCIKrga5UnbOzrqIoj4/0uTkz4zBMGHa6/S5SR0ojocHA0IJJf7mSPV0=; 7:3JvgmxPG/YqRGSWlHtRIEr6dCqBUhJvRWoz9Q5IomJ89XF+kXpcSfKUtW7MgmP8ElfiFUYQ4VvJK7mq8QsXdYUYcWcsh49RaLnsISSZKBrfuyQWypunN2E32r/zOFkK7JO+8hbl3S5h+spi8fUFkMlSjMTeBDihQcbidwpvtwwDbddkaY89AGfBn4JDMuDw4rND9n+XN3PrO8LSm9KPDgNZs/VNec8RzKemfQTdojH4moZO3qlR8PRGRuAjcD0y+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4af1a477-fce8-4d87-59c7-08d526664d4f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603249); SRVR:AM5PR0701MB2835; x-ms-traffictypediagnostic: AM5PR0701MB2835: x-exchange-antispam-report-test: UriScan:(82608151540597)(17755550239193); 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)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3231021)(6055026)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(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: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(189002)(199003)(24454002)(13464003)(6246003)(9686003)(68736007)(6506006)(3280700002)(5250100002)(316002)(3660700001)(230783001)(97736004)(81156014)(99286004)(6436002)(53936002)(3846002)(102836003)(55016002)(229853002)(6116002)(50986999)(189998001)(54356999)(76176999)(6916009)(101416001)(74316002)(561944003)(7736002)(478600001)(2900100001)(86362001)(14454004)(15650500001)(105586002)(2950100002)(4326008)(305945005)(33656002)(66066001)(81166006)(53546010)(8676002)(7696004)(25786009)(8936002)(106356001)(93886005)(5660300001)(2906002); 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) 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4af1a477-fce8-4d87-59c7-08d526664d4f X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 05:05:16.6952 (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: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 05:05:23 -0000 VGhlcmUgZmV3IG90aGVyIGRyYXdiYWNrcyB0aGF0IHdlIGNvbnNpZGVyZWQgd2hlbiB3ZSBzZWxl Y3RlZCB0byB1c2UgRmxvdy1sYWJlbCBpbnN0ZWFkIG9mIGFuIEVIIHNvbHV0aW9uIGZvciBTUnY2 IGFsdGVybmF0ZSBtYXJraW5nOg0KDQoqIGVhc2llciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGJl Y2F1c2Ugbm90aGluZyBicmVha3MgaWYgYSB0cmFuc2l0IHJvdXRlciBkb2VzIG5vdCBoYXZlIHRo ZSBjYXBhYmlsaXR5IG9mIHVuZGVyc3RhbmRpbmcgdGhlIEZsb3cgbGFiZWwgY29udGV4dC4uLiBp biB0aGF0IGNhc2UgdGhlIGZsb3ctbGFiZWwgaW4gdGhlIG91dGVyIHR1bm5lbCBoZWFkZXIgaXMg anVzdCBhIGZsb3ctbGFiZWwNCiogSGF2aW5nIGEgSGJIIEVIIHNlZW1zIGxlc3MgYmFja3dhcmQg Y29tcGF0aWJsZSwgYW5kIHdpbGwgYmUgbGVzcyBlYXN5IHRvIHVzZSB1bmxlc3MgQUxMIHJvdXRl cnMgaW4gdGhlIGRvbWFpbiBzdXBwb3J0IHRoZXNlIHR5cGUgb2YgaGVhZGVycyBpbiB0aGUgZmFz dC1wYXRoLi4uIGl0IGp1c3Qgc2VlbXMgY29tcGxleCBiZWNhdXNlIG9mIGFsbCB0aGUgaWYtdGhl bi1idXQgaW52b2x2ZWQgdG8gaW1wbGVtZW50LCB1c2UgYW5kIG9wZXJhdGUuLi4NCiogRm9yIEhX IGJhc2VkIHJvdXRlcnMgKGkuZS4gaW4gTm9raWEgY2FzZSBoYXZpbmcgdXNlci1wbGFuZSBzd2l0 Y2hpbmcgY2FwYWJpbGl0eSBzY2FsZSBvZiAyLjhUIHBlciBOUFUpIHRoZSBzdXBwb3J0IG5lYXJs eSBjb21lcyBmb3IgZnJlZSBhcyBzdXBwb3J0IGlzIGFscmVhZHkgdGhlcmUuLi4gbm90aGluZyBl eHRyYSBpcyBuZWVkZWQgZnJvbSBhIG5vZGFsIHBlcnNwZWN0aXZlDQoqIExlc3MgYml0cyBvbiB0 aGUgd2lyZS4uLiBnb2luZyBTUnY2IGhhcyBhbHJlYWR5IGEgc2lnbmlmaWNhbnQgYml0cy1vbi13 aXJlIHRheCBiZWNhdXNlIG9mIHRoZSBvdXRlciBJUHY2IGhlYWRlciBhbmQgdGhlIFNSdjYgRUgg YW5kIGFsbCB0aGUgc291cmNlIHJvdXRpbmcgaGVhZGVycw0KDQpTbywgaW5kZWVkIGEgbmV3IHR5 cGUgb2YgRUggbWF5IGJlIGEgc29sdXRpb24gc3BhY2UgcHJvcG9zYWwsIGhvd2V2ZXIsIEkgZG8g bm90IHRoaW5rIGl0IGlzIGFzIHByYWdtYXRpYyBhcyB1c2luZyB0aGUgZmxvdy1sYWJlbCBpbiB0 aGUgb3V0ZXIgSVB2NiBTUnY2IGhlYWRlciBiZWNhdXNlIG9mIGFsbCB0aGUgYmVuZWZpdHMgZmxv dy1sYWJlbCB1c2FnZSBnaXZlcy4gVGhlIEZsb3ctbGFiZWwgcHJvcG9zYWwsIGlzIGJhc2ljYWxs eSBzb21ldGhpbmcgdGhhdCByb3V0ZXJzIGNhbiBkbyByaWdodCBub3csICBhbmQgaXQgZG9lcyBu b3QgYnJlYWsgYW55IElQdjYgcnVsZXMgYW5kIGlzIGV4cGVjdGVkIHRvIGJlIHN1cHBvcnRlZCBp biBsaW5lLXJhdGUgYnkgdGhlIGZhc3QgcGF0aCBzd2l0Y2hpbmcgb2Ygcm91dGVycyBieSBkZWZh dWx0Lg0KDQpJbmRlZWQgc2hlIHNvbHV0aW9uIHByb3Bvc2VkIGluIHRoZSBkcmFmdCwgaXMgZm9y IHRoZSBtb21lbnQgYXNzdW1lZCB0byBiZSBleGNsdXNpdmUgZnJvbSBvdGhlciB1c2FnZXMgKHdp dGggZXhjZXB0aW9uIG9mIGVudHJvcHkpIG9mIHRoZSBmbG93LWxhYmVsIGluIHRoZSBjb250cm9s bGVkIG9wZXJhdG9yIGRvbWFpbi4uLiBpdCBkb2VzIG5vdCBuZWNlc3NhcnkgaGF2ZSB0byBiZSBl eGNsdXNpdmUsIGJ1dCBpdCBzZWVtcyB0aGUgbW9zdCBwcmFnbWF0aWMuIEN1cnJlbnRseSwgb3Bl cmF0b3IgdHJhZGl0aW9uYWxseSBkbyBub3QgdXNlIGZsb3ctbGFiZWwgYXQgYWxsLCBoZW5jZSB0 aGUgYWJvdmUgYXNzdW1wdGlvbiBzZWVtcyByZWFzb25hYmxlLiANCg0KRy8gDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9tQGhlcmJl cnRsYW5kLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciA3LCAyMDE3IDIzOjI4DQpUbzog VmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkgPGd1bnRlci52YW5fZGVf dmVsZGVAbm9raWEuY29tPg0KQ2M6IHY2b3BzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3Bz XSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1maW9jY29sYS1zcHJpbmct Zmxvdy1sYWJlbC1hbHQtbWFyay0wMS50eHQNCg0KT24gVHVlLCBOb3YgNywgMjAxNyBhdCAxMTo1 MyBBTSwgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0NCkJFL0FudHdlcnApIDxndW50ZXIu dmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4gd3JvdGU6DQo+IEhpIFRvbSwNCj4NCj4gVGhlIGNsb3Nl ZCBzeXN0ZW0gaGVyZSBpcyBkZWZpbmVkIGJ5IHRoZSBTUnY2IHR1bm5lbHPigKYgVGhlIGZsb3ct bGFiZWwgaXMgc2V0IOKAnG9ubHnigJ0gYnkgdGhlIHR1bm5lbCBoZWFkLWVuZCByb3V0ZXIg4oCc b24gdGhlIG91dGVyIElQdjYgaGVhZGVy4oCdLiBUaGUgdHVubmVsIGhlYWQtZW5kIHJvdXRlciBj YW4gZG8gdGhpcyBiZWNhdXNlIGl0IGlzIHRoZSBkZXZpY2UgdGhhdCBjcmVhdGVkIHRoZSBvdXRl ciBJUCBoZWFkZXIuDQo+IFRoZSBvcmlnaW5hbCBJUHY2IHBhY2tldCBpcyByaWRpbmcgaW5zaWRl IHRoZSB0dW5uZWwsIGFuZCBhcyByZXN1bHQgDQo+IHRoZSBvcmlnaW5hbCBmbG93IGxhYmVsIGFu ZCBvcmlnaW5hbCBJUHY2IGhlYWRlciBpcyBsZWZ0IHVudG91Y2hlZC4gVGhlIGNsb3NlZCBzeXN0 ZW0gaXMgdGhlIG5ldHdvcmsgYmV0d2VlbiB0aGUgdHVubmVsIGhlYWQtZW5kICg9d2hlcmUgdGhl IG91dGVyIElQdjYgaGVhZGVyIGlzIGFkZGVkKSBhbmQgdGhlIHR1bm5lbCB0YWlsLWVuZCAoPXdo ZXJlIHRoZSBvdXRlciBoZWFkZXIgaXMgcmVtb3ZlZCkuIFRoaXMgdHlwZSBvZiBjbG9zZWQgc3lz dGVtIGlzIGVhc3kgdG8gZGVwbG954oCmIHRha2UgZm9yIGV4YW1wbGUgYSBNUExTL1ZQTiBiYWNr Ym9uZeKApi4gT3IgYSBWeExBTiBuZXR3b3Jr4oCmIFRoZSBTUnY2IG5ldHdvcmsgaXMgc29tZXRo aW5nIG9mIHNpbWlsYXIgc2ltcGxpY2l0eS4NCj4NCj4gVGhlIElQdjYgZGV2aWNlIHRoYXQgZ2Vu ZXJhdGVzIGFuIElQdjYgcGFja2V0IGNhbiBzZXQgdGhlIGZsb3cgbGFiZWwsIGFuZCB0aGF0IGlz IHdoYXQgZGV2aWNlcyBoYXZlIGJlZW4gZG9pbmcgYWxsIHRoZSB0aW1lLiBUaGlzIGRyYWZ0IHBy b3Bvc2VzIG5vdGhpbmcgbmV3IGZyb20gdGhhdCBwZXJzcGVjdGl2ZS4NCj4NCj4gV2h5IGRvIHlv dSBzYXkg4oCYcmVwdXJwb3NpbmfigJkgdGhlIGJpdHM/IE5vdGhpbmcgaXMgcmVwdXJwb3NlZC4g VGhpcyBwcm9wb3NhbCBpcyByZXNwZWN0aW5nIFJGQzY0MzcuIEluIG91ciBpbmZvcm1hdGlvbmFs IHByb3Bvc2FsIHRoZSBmbG93LWxhYmVsIGp1c3QgcmVtYWlucyBmbG93LWxhYmVsLiBSb3V0ZXJz IGNhbiBiZSBtYWRlIHRvIG1hdGNoIHVwb24gZmxvdy1sYWJlbCB2YWx1ZXMgZWFzaWx5LiBJIGtu b3cgbXkgTm9raWEgcHJvZHVjdHMgY2FuIGRvIHRoYXQgdmVyeSBlYXNpbHksIGJlY2F1c2UgdGhl IGZsb3ctbGFiZWwgaXMgYWx3YXlzIGZvdW5kIGF0IHRoZSBzYW1lIHBsYWNlIGluIHRoZSBJUHY2 IGhlYWRlci4gSG93ZXZlciwgY2hlY2tpbmcgb24gRUhzIGlzIGEgZmV3IGRpbWVuc2lvbnMgbW9y ZSBjb21wbGljYXRlZC4gV2hlbiBJIG11c3QgbWFrZSBteSByb3V0ZXIgbWF0Y2ggZm9yIGNvbnRl bnQgaW4gRUhzLCB0aGVuIGZpcnN0IGl0IG11c3QgY2hlY2sgaWYgdGhlIHJlbGV2YW50IEVIIGlz IGluc2VydGVkLCB0aGVuIHRoZSBjb3JyZXNwb25kaW5nIEVIIG11c3QgYmUgaWRlbnRpZmllZCBh bmQgdGhlbiB0aGUgY29udGVudCBoYXMgdG8gYmUgY2hlY2tlZOKApiBUaGlzIEVIIGNoZWNraW5n IGlzIG5vbi10cml2aWFsIGFzIHJlc3VsdOKApiBGb3IgYSBIVyBiYXNlZCByb3V0ZXIgKG15IE5v a2lhIHJvdXRlciBmb3IgZXhhbXBsZSkgdGhlIGNoZWNraW5nIG9mIGZsb3ctbGFiZWwgaXMgYXMg c2ltcGxlIGFzIGNoZWNraW5nIGZvciBhIERTQ1AgdmFsdWUgYmVjYXVzZSB0aGUgb3BlcmF0aW9u IGludm9sdmVkIGlzIGV4YWN0bHkgdGhlIHNhbWUuDQoNCkkgZG9uJ3QgYmVsaWV2ZSB0aGUgRUgg cHJvY2Vzc2luZyBuZWVkcyB0byBiZSBjb21wbGljYXRlZC4gSW4gdGhpcyBjYXNlIHRoZSBhc3N1 bXB0aW9uIGlzIHRoYXQgbmV0d29yayBvcGVyYXRvciBpcyBpbnNlcnRpbmcgdGhlIGhlYWRlcnMg c28gdGhlIEhCSCBFSCB3aXRoIGEgbGF0ZW5jeSBtZWFzdXJlbWVudCBvcHRpb24gY291bGQgYmUg aW1wbGVtZW50ZWQgdG8gYWx3YXlzIGJlIGluIHRoZSBzYW1lIHBvc2l0aW9uLCBoYXZlIHRoZSBz YW1lIGxlbmd0aCwgYW5kIG9ubHkgc2V0IHdpdGggb25lIG9wdGlvbiBmb3IgbGF0ZW5jeS4gVGhl IHJvdXRlciBwcm9jZXNzaW5nY2FuIGJlIG9wdGltaXplZCB0byBoYW5kbGUgdGhpcyBjYXNlLiBF eGlzdGVuY2UgYW5kIHZlcmlmaWNhdGlvbiBvZiB0aGUgRUggY2FuIGFsbCBiZSBkb25lIHdpdGgg c2ltcGxlIGNoZWNrcyBhbmQgVENBTSBjb3VsZCBiZSB1c2VkIHRvIG1hdGNoIHRoZSBjb21tb24g aGVhZGVyIHBhdHRlcm4uIFRoZSBJUCBoZWFkZXIgYW5kIGV4dGVuc2lvbiBoZWFkZXIgc2hvdWxk IGZpdCB3ZWxsIHdpdGhpbiB0aGUgcGFyc2luZyBidWZmZXIgb2YgdHlwaWNhbCByb3V0ZXJzLg0K DQo+DQo+IFRvbSwgaWYgeW91ciBhZGRpdGlvbmFsIHN1Z2dlc3Rpb25zIGZvciB1c2luZyBmbG93 IGxhYmVscyBpcyByZXNwZWN0aW5nIFJGQzY0MzcgdGhlbiB3aGF0IHN0b3BzIHlvdSBmcm9tIGRv Y3VtZW50aW5nIHRob3NlIHRob3VnaHRzPyBUaGUgYWx0ZXJuYXRlIG1hcmtpbmcgcHJpbmNpcGxl IGRvY3VtZW50ZWQgaW4gdGhpcyBkcmFmdCBmb3IgU1J2NiBpcyBzb21ldGhpbmcgdGhhdCBpcyBk cml2ZW4gYnkgb3BlcmF0b3IgdGhlbXNlbHZlcywgYW5kIGlzIGJhc2VkIHVwb24gcmVhbCBvcGVy YXRvciByZXF1aXJlbWVudC4gRmVlbCBmcmVlIHRvIGZ1cnRoZXIgZGlzY3VzcyB3aXRoIHRoZSBU ZWxla29tIEl0YWxpYSBjby1hdXRob3JzIChHdWlzZXBwZSBhbmQgTWF1cm8pIG9uIFRJIG5lZWRz IGZvciBzdWNoIHBhc3NpdmUgbWVhc3VyZW1lbnQgbWVjaGFuaXNtIChsb3NzLCBsYXRlbmN5LCBq aXR0ZXIsIGV0YykuDQoNClRoZSBmYWN0IHRoYXQgb3BlcmF0b3JzIHdhbnQgcGFzc2l2ZSBsYXRl bmN5IG1lYXN1cmVtZW50cyBpcyBub3QgdGhlIHNhbWUgYXMgc2F5aW5nIHRoYXQgYXBwbHlpbmcg YSBmb3JtYXQgdG8gdGhlIGZsb3cgbGFiZWwgaXMgYSByZXF1aXJlbWVudC4gSXQgaXMgdGhlIG1l Y2hhbmlzbSBvZiB0aGlzIHByb3Bvc2FsIHRoaXMgaXMgaW4gcXVlc3Rpb24uDQoNClRvbQ0KDQoN Cj4NCj4gRy8NCj4NCj4NCj4NCj4gT24gMDcvMTEvMjAxNywgMTk6MTQsICJUb20gSGVyYmVydCIg PHRvbUBoZXJiZXJ0bGFuZC5jb20+IHdyb3RlOg0KPg0KPiAgICAgT24gVHVlLCBOb3YgNywgMjAx NyBhdCA5OjEzIEFNLCBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLQ0KPiAgICAgQkUvQW50 d2VycCkgPGd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tPiB3cm90ZToNCj4gICAgID4gVG8g bWUgaXQgc2VlbXMgdGhhdCBsb29raW5nIGF0IEZMIGlzIG11Y2ggZWFzaWVyIGZvciBhIEhXIGJh c2VkIA0KPiByb3V0ZXIgdGhlbiBsb29raW5nIGF0IEVIcyBpbiBhIGhvcC1ieS1ob3AgZmFzaGlv buKApg0KPg0KPiAgICAgRWFzaWVyIGZvciB3aG9tPyBSZXB1cnBvc2luZyBiaXRzIGluIHRoZSBJ UCBoZWFkZXIgZXZlbiBmb3IgYSBuYXJyb3cNCj4gICAgIHVzZSBjYXNlIGluIGEgY2xvc2VkIHN5 c3RlbSBkb2Vzbid0IHNlZW0gcGFydGljdWxhcmx5IGVhc3kgdG8NCj4gICAgIHN0YW5kYXJkaXpl IG9yIGRlcGxveS4gQXMgTWFyayBwb2ludGVkIG91dCB0aGVyZSdzIGEgbG90IG9mIGNvbXBsZXhp dHkNCj4gICAgIGFyb3VuZCBlbnN1cmluZyB0aGF0IHRoZSBzeXN0ZW0gcmVhbGx5IGlzIGNsb3Nl ZCBhbmQgYWxsIHJlcXVpcmVkDQo+ICAgICBiZWhhdmlvciBpcyBtYWludGFpbmVkLg0KPg0KPiAg ICAgQW5vdGhlciBvYnZpb3VzIHF1ZXN0aW9uIHdpdGggdGhpcyBhcHByb2FjaCBpcyBkb2VzIGl0 IG1lYW4gdGhhdCBmbG93DQo+ICAgICBsYWJlbCBiaXRzIGFyZSBub3cgZmFpciBnYW1lIHRvIGJl IGRlZmluZWQgZm9yIGV2ZW4gbW9yZSBwdXJwb3Nlcz8NCj4gICAgIExhdGVuY3kgbWVhc3VyZW1l bnQgaXNuJ3QgYmUgdGhlIG9ubHkgcG90ZW50aWFsIHVzZSBjYXNlLiBGb3INCj4gICAgIGluc3Rh bmNlLCBJIGtub3cgdGhlcmUncyBhIGxvdCBvZiBwZW9wbGUgdGhhdCB3YW50IGhvc3RzIHRvIG1h cmsNCj4gICAgIHBhY2tldHMgd2l0aCBhICJyZXRyYW5zbWl0dGVkIiBiaXQgc28gdGhhdCByb3V0 ZXJzIGNhbiBrZWVwIHN0YXRzIGZvcg0KPiAgICAgdHJhY2tlZCBmbG93cy4gSU1PLCBpZiB1c2lu ZyBmbG93IGJpdHMgbGlrZSB0aGlzIGlzIHRoZSByaWdodCBhbnN3ZXINCj4gICAgIHRoZW4gdGhl cmUgc2hvdWxkIGJlIGEgZ2VuZXJpYyBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIHRoYXQgZGVmaW5l cyB0aGUNCj4gICAgIG9wZXJhdGlvbiBhbmQgaG93IGJpdHMgYXJlIGFsbG9jYXRlZCBmb3IgYWxs IHRoZSBwb3RlbnRpYWwgdXNlcy4NCj4NCj4gICAgIFRvbQ0KPg0KPiAgICAgPg0KPiAgICAgPiBH Lw0KPiAgICAgPg0KPiAgICAgPiBPbiAwNy8xMS8yMDE3LCAxNzo1OCwgIlRvbSBIZXJiZXJ0IiA8 dG9tQGhlcmJlcnRsYW5kLmNvbT4gd3JvdGU6DQo+ICAgICA+DQo+ICAgICA+ICAgICBPbiBUdWUs IE5vdiA3LCAyMDE3IGF0IDc6MjYgQU0sIFZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtDQo+ ICAgICA+ICAgICBCRS9BbnR3ZXJwKSA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+IHdy b3RlOg0KPiAgICAgPiAgICAgPiBBIHRyYW5zaXQgcm91dGVyIGRvZXMgbm90IGxvb2sgYXQgRUhz IGlmIGl0IGlzIG5vdCBjb25maWd1cmVkIGZvciB0aGUgSVB2NiBEZXN0aW5hdGlvbiBhZGRyZXNz Li4gc28gaXRzIG5vdCB1c2FibGUgaW4gdGhhdCBjYXNlLg0KPiAgICAgPiAgICAgPg0KPiAgICAg PiAgICAgVGhleSBkbyBsb29rIGF0IGhvcC1ieS1ob3Agb3B0aW9ucy4gUHJldmlvdXNseSBpdCB3 YXMgcmVxdWlyZWQgdGhhdA0KPiAgICAgPiAgICAgYWxsIG5vZGVzIGluIHRoZSBwYXRoIG11c3Qg cHJvY2VzcyB0aGVtLCBidXQgdGhhdCB3YXMgcmVsYXhlZCBhIGJpdCBpbg0KPiAgICAgPiAgICAg UkZDODIwMC4gSWYgdGhleSBhcmUgb25seSB1c2VkIGZvciB0dW5uZWxpbmcgYWNyb3NzIGEgY29u dHJvbGxlZA0KPiAgICAgPiAgICAgZG9tYWluIHRoZW4gdGhlIHR5cGljYWwgY29uY2VybiB0aGF0 IGludGVybWVkaWF0ZSBub2RlcyBkb24ndCBwcm9wZXJseQ0KPiAgICAgPiAgICAgaGFuZGxlIGhv cC1ieS1ob3Agb3B0aW9ucyBjYW4gYmUgYWRkcmVzc2VkLg0KPiAgICAgPg0KPiAgICAgPiAgICAg VG9tDQo+ICAgICA+DQo+ICAgICA+ICAgICA+IEcvDQo+ICAgICA+ICAgICA+DQo+ICAgICA+ICAg ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICA+ICAgICA+IEZyb206IFRvbSBI ZXJiZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gICAgID4gICAgID4gU2VudDog VHVlc2RheSwgTm92ZW1iZXIgNywgMjAxNyAxNjoxNg0KPiAgICAgPiAgICAgPiBUbzogVmFuIERl IFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkgPGd1bnRlci52YW5fZGVfdmVsZGVA bm9raWEuY29tPg0KPiAgICAgPiAgICAgPiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gICAgID4gICAg ID4gU3ViamVjdDogUmU6IFt2Nm9wc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0LW1hcmstMDEudHh0DQo+ICAgICA+ ICAgICA+DQo+ICAgICA+ICAgICA+IE9uIE1vbiwgTm92IDYsIDIwMTcgYXQgMTA6NDQgUE0sIFZh biBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtDQo+ICAgICA+ICAgICA+IEJFL0FudHdlcnApIDxn dW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4gd3JvdGU6DQo+ICAgICA+ICAgICA+PiBIaSBU b20sDQo+ICAgICA+ICAgICA+Pg0KPiAgICAgPiAgICAgPj4gLS0+DQo+ICAgICA+ICAgICA+PiBG cm9tIHNlY3Rpb24gMToNCj4gICAgID4gICAgID4+DQo+ICAgICA+ICAgICA+PiAiQmFzZWQgb24g dGhlc2UgY29uc2lkZXJhdGlvbnMsIGl0IGlzIGFsbG93ZWQgdG8gdXNlIHRoZSBmbG93IGxhYmVs IGZpZWxkIGluIGEgbWFuYWdlZCBkb21haW4sIGFzc3VtaW5nIHdoZW4gYSBwYWNrZXQgbGVhdmVz IHRoZSBkb21haW4sIHRoZSBvcmlnaW5hbCBmbG93IGxhYmVsIHZhbHVlIE1VU1QgYmUgcmVzdG9y ZWQuIg0KPiAgICAgPiAgICAgPj4NCj4gICAgID4gICAgID4+IEluIHRoaXMgcHJvcG9zYWwsIGlm IHR3byBiaXRzIGFyZSBvdmVyd3JpdHRlbiBieSBhbiBpbnRlcm1lZGlhdGUgbm9kZSwgaG93IGFy ZSB0aGVpciBvcmlnaW5hbCB2YWx1ZXMgcmVzdG9yZWQgd2hlbiBsZWF2aW5nIHRoZSBkb21haW4/ DQo+ICAgICA+ICAgICA+PiAtLT4NCj4gICAgID4gICAgID4+DQo+ICAgICA+ICAgICA+PiBHVj4g IEJlY2F1c2UgdGhlIGZpZWxkIHRoYXQgYXJlIGJlaW5nIGZpZGRsZWQgd2l0aCBhcmUgb24gdGhl IElQdjYgU1J2NiBvdXRlciBlbmNhcHN1bGF0aW9uIGhlYWRlci4gV2hlbiB0aGUgb3JpZ2luYWwg cGFja2V0IGxlYXZlcyB0aGUgY29udHJvbGxlZCBkb21haW4sIHRoZW4gdGhhdCBoZWFkZXIgaXMg cmVtb3ZlZCBhZ2FpbiwgYW5kIHRoZSBvcmlnaW5hbCBJUHY2IHBhY2tldCB3aXRoIG9yaWdpbmFs IGhlYWRlcnMgYXBwZWFyIGFnYWluLg0KPiAgICAgPiAgICAgPj4NCj4gICAgID4gICAgID4gR3Vu dGVyLA0KPiAgICAgPiAgICAgPg0KPiAgICAgPiAgICAgPiBJZiB0aGUgbWVhc3VyZW1lbnRzIGFy ZSBhbHdheXMgY29pbmNpZGVudCB3aXRoIHRoZSB1c2Ugb2YgU1J2NiB0aGVuIHdoeSBub3QgcHV0 IHRoZSBtZWFzdXJlbWVudCBpbmZvcm1hdGlvbiBpbiB0aGUgU1IgRUggb3Igc29tZSBvdGhlciBF SCAoaG9wLWJ5LWhvcCBvciBlc3Qgb3B0IG1heWJlKSB1c2VkIG9ubHkgaW4gdGhlIGNvbnRyb2xs ZWQgZG9tYWluPyBUaGlzIGFsc28gY291bGQgYmUgbW9yZSBmbGV4aWJsZSBzaW5jZSB0aGUgYWxn b3JpdGhtIHdvdWxkbid0IGJlIGNvbnN0cmFpbmVkIHRvIGp1c3QgdHdvIGJpdHMgb2YgZGF0YS4N Cj4gICAgID4gICAgID4NCj4gICAgID4gICAgID4gVG9tDQo+ICAgICA+DQo+ICAgICA+DQo+DQo+ DQo= From nobody Tue Nov 7 23:13:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627A41314E5 for ; Tue, 7 Nov 2017 23:13:26 -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 wNG2EnmgGUb7 for ; Tue, 7 Nov 2017 23:13:25 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 1E854131597 for ; Tue, 7 Nov 2017 23:12:44 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id e46so1229911uaa.4 for ; Tue, 07 Nov 2017 23:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UzSjPDZtnZiVDDAhbaTWYaVFZ54/4NhI1qYsLda1tco=; b=bBrYHMJpMxo0MBfHtH8lk6cgO7xqlxIVbF/FDoE/8/Pq8rl+R64WFpU7Jnl8/S6FIw SfEp3xnUBzXwg9WYenxE1MO4WvQzDDaTj/4vDT459EHLz3JsQJf4Vl8HPJI/QAXPG7OV HFzBNvluG6SQP68sdvdUUdOLFSwT9GnqNAqhjtlLnSA3taEf1Lka0nlW/T9b251wdzlI miYV4/iknJ4k8pN9KTyVug8y5PIb2RTsILfBb9SVtxM060d1SmubS1i38S1nCrxqwnh9 /zQB7RYh+f2TEDDDZzmH/V/dGbDRfmqo6s9TIXyrmnyLLdMg6SBh58JQMha0GiHwvbU3 5rbQ== 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=UzSjPDZtnZiVDDAhbaTWYaVFZ54/4NhI1qYsLda1tco=; b=ATwre7OSkijYxKA4brGmIgEJrPEgLKDeh48RhUS/YL8mXBoOMhSZrocD0IwIPS8jrT BepYpt9oG1XNfH39Gix17cHzMUBTajUTU5v79RSyJTsFd8oAjs+Fw1261HOkQmKrtRq3 p/rj3iKLEEggUpkoCe5TnCTeagSbv8usm99cax0hGHMPtxNUU68P0tiAkRODGEIcBeRy pUvxaSpm23FRT0abfuD8ceNU2sB2Hyln3KKP4j83McihHFYjM6Br9wzwBQ8iMYqtJalx apO5ozz2az4v7UNrKzTVm+jKoP2iEJ1fSg+iZTJDh/fGKLFinSxNf/KDcF/Y0xzpYMmS ecPQ== X-Gm-Message-State: AJaThX5qnJmYrP3D2juzaTLqCeI+F3LlQvnp/j0GPyahi4viKUl0mKV8 8eMp57luwVwCLcPzKqwRF2X1+WS1TRW/AOdmZsY= X-Google-Smtp-Source: ABhQp+QFuhOmM+4flyD2OAmSZsyoY0J7OsqKjDuyrLP2q2QRgLZK3AN7Novb+sP15mVR83eNXVSivuogiO78KBNwT5I= X-Received: by 10.176.9.75 with SMTP id c11mr1207585uah.33.1510125163092; Tue, 07 Nov 2017 23:12:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Tue, 7 Nov 2017 23:12:42 -0800 (PST) Received: by 10.159.52.221 with HTTP; Tue, 7 Nov 2017 23:12:42 -0800 (PST) In-Reply-To: <20171107200021.GX45648@Space.Net> References: <150860492012.3131.14623048904955800548.idtracker@ietfa.amsl.com> <0EAB4149-AFE9-4770-8242-6D8E05889091@consulintel.es> <66E223E7-73B5-49BA-AA40-5AA632F3F755@consulintel.es> <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> <20171107200021.GX45648@Space.Net> From: Mark Smith Date: Wed, 8 Nov 2017 18:12:42 +1100 Message-ID: To: Gert Doering Cc: Ole Troan , v6ops list Content-Type: multipart/alternative; boundary="f403043ec134e9a208055d736904" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 07:13:26 -0000 --f403043ec134e9a208055d736904 Content-Type: text/plain; charset="UTF-8" On 8 Nov. 2017 7:00 am, "Gert Doering" wrote: Hi, On Tue, Nov 07, 2017 at 06:15:11PM +1100, Mark Smith wrote: > If the optimisation causes issues that have to be worked around > somewhere else, and the optimisation doesn't provide an obvious > benefit, is it really a useful and worth while optimsation? people point routing towards p2p *links* and not "next-hops" because they do not care, and do not *want* to care what the neighbouring IP address is. "ipv6 route 2001:db8::/48 serial3" is legit and useful. Starting to do ND for every single address in that /48 would be totally the wrong way to do. The fact that there is no link layer resolution on p2p links is a plus, trying to make it "look like ethernet" would be a major drawback (and I strongly defute any claim that "the generalization of ARP into IPv6 ND is a *good thing*" It already happened. - L2 resolution using a routable protocol and relying on implementations to ensure that it's then "not routed" or "properly filtered of TTL is not 255" was just plain stupid) Just plain stupid is thinking you always know best. 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 --f403043ec134e9a208055d736904 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 8 Nov. 2017 7:00 am, "Gert Doering" <gert@space.net> wrote:
Hi,

On Tue, Nov 07, 2017 at 06:15:11PM +1100, Mark Smith wrote:
>=C2=A0 If the optimisation causes issues that have to be worked around<= br> > somewhere else, and the optimisation doesn't provide an obvious > benefit, is it really a useful and worth while optimsation?

people point routing towards p2p *links* and not "next-hops"= ; because
they do not care, and do not *want* to care what the neighbouring IP
address is.

"ipv6 route 2001:db8::/48 serial3"

is legit and useful.=C2=A0 Starting to do ND for every single address in th= at
/48 would be totally the wrong way to do.

The fact that there is no link layer resolution on p2p links is a plus,
trying to make it "look like ethernet" would be a major drawback = (and
I strongly defute any claim that "the generalization of ARP into IPv6<= br> ND is a *good thing*"
=
It already happened.
- L2 resolution using a routable protocol and= relying
on implementations to ensure that it's then "not routed" or &= quot;properly
filtered of TTL is not 255" was just plain stupid)

Just plain stu= pid is thinking you always know best.



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

SpaceNet AG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Aufsichtsratsvo= rs.: A. Grundner-Culemann
D-80807 Muenchen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0HRB: 136055 (AG Muenchen)
Tel: = +49 (0)89/32356-444=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USt-IdNr.: = DE813185279

--f403043ec134e9a208055d736904-- From nobody Tue Nov 7 23:53:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1CC131625 for ; Tue, 7 Nov 2017 23:53:09 -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 aRwMv1BeLXQO for ; Tue, 7 Nov 2017 23:53:07 -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 4648E131546 for ; Tue, 7 Nov 2017 23:53:07 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id q1so1579219ywh.5 for ; Tue, 07 Nov 2017 23:53:07 -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=ebaND4utqmxbJIlFBaRHPHYu2VEXGLhzm8Z3HqOKyVA=; b=ACNdhJweA8ESE6GvP4KS/WsVd9ePP3zPsk8Np07ACKdZ8Cklez5FYVM5W11792OfEo bPjNefSontuY5fGnHtF/JEmVWeN58JztQnBiqUzH6sfB9KHnwd8yyru0JeFjz4Vqk02s u43Pyqu3xe/Y94bm9Q6Z254lUWbUgPNJxB2rjqdkGakOieGNFUUWA18dY2wtEg4T9fJ3 CiaUpOxsfMGSv8+xfRXcrZhwS2rUGAlLJa4B0vJ2GqA5CNTgdIZ74audf95cKRvG/fXX oP2Nx04wXq8vIbF8WDuGr7mq3Ths1sJ+Bn8r7FaIpkY8tAUKvIJtHRFHHFykOVLfVWfu CzcA== 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=ebaND4utqmxbJIlFBaRHPHYu2VEXGLhzm8Z3HqOKyVA=; b=CkJhHmOiWU/OtLb5c1aCNor3O5w5juyw+AfOkD8gByqy97VUAauhWapf2J59LueFz6 HOpWODD/ufnztQku1mejvioJ5j1XubEwwonZHjkKJlrcjOmA7ez+/Nso22fEXc7Ul28z 3VbDA0j95XgFg9lpCIfaLkw8AzQYiorSGpNeZ46nAaQ43yiGIk1RjANs8+A7YOVyPPfH uFX5hsG9XZNqXwgmgkxYGy9uaqf+DnB0V3uGMNjzm1UNePZUKpK5g/nUHWNiNZfAxvkP 2efBDfnH4BbhX0reNCwun2W26k9Cwx+RU2UNM2EEZ5Ih7mf16lKE5woSGimjXqLeH0tY ZIWg== X-Gm-Message-State: AJaThX7sxq+eht4ZqwweB2yq+EAhj9eGKfxyKLHOf/W35EWC5/QOjQre h8+pCOn8zCRSuN7BdXP8+YeuPYPxUkNeqhttZ4IkO6rKL0k= X-Google-Smtp-Source: ABhQp+RjFBkBBEWQogosZ/GpfBgihEIRAau8YrOo2Fg+S9+9BEetBFiriGJ7s1X9AYqWuQmRglqWZR8g639+YNbCjSU= X-Received: by 10.37.63.4 with SMTP id m4mr882140yba.15.1510127586135; Tue, 07 Nov 2017 23:53:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.130.80 with HTTP; Tue, 7 Nov 2017 23:52:45 -0800 (PST) In-Reply-To: References: <150860492012.3131.14623048904955800548.idtracker@ietfa.amsl.com> <0EAB4149-AFE9-4770-8242-6D8E05889091@consulintel.es> <66E223E7-73B5-49BA-AA40-5AA632F3F755@consulintel.es> <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> <20171107200021.GX45648@Space.Net> From: Erik Kline Date: Wed, 8 Nov 2017 16:52:45 +0900 Message-ID: To: Mark Smith Cc: Gert Doering , v6ops list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114bdaba5f2f4b055d73fa32" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 07:53:09 -0000 --001a114bdaba5f2f4b055d73fa32 Content-Type: text/plain; charset="UTF-8" On 8 November 2017 at 16:12, Mark Smith wrote: > > > On 8 Nov. 2017 7:00 am, "Gert Doering" wrote: > > Hi, > > On Tue, Nov 07, 2017 at 06:15:11PM +1100, Mark Smith wrote: >> If the optimisation causes issues that have to be worked around >> somewhere else, and the optimisation doesn't provide an obvious >> benefit, is it really a useful and worth while optimsation? > > people point routing towards p2p *links* and not "next-hops" because > they do not care, and do not *want* to care what the neighbouring IP > address is. > > "ipv6 route 2001:db8::/48 serial3" > > is legit and useful. Starting to do ND for every single address in that > /48 would be totally the wrong way to do. > > The fact that there is no link layer resolution on p2p links is a plus, > trying to make it "look like ethernet" would be a major drawback (and > I strongly defute any claim that "the generalization of ARP into IPv6 > ND is a *good thing*" > > > It already happened. I'm not sure what is meant by the claims here, but in case it helps: Linux's ARP neighbor reachability statemachine entirely reuses/shares the IPv6 ND neighbor reachability statemachine (i.e. all of the IPv6 NUD state transitions are also made by the (same) code monitoring IPv4 neighbors). > - L2 resolution using a routable protocol and relying > on implementations to ensure that it's then "not routed" or "properly > filtered of TTL is not 255" was just plain stupid) > > > Just plain stupid is thinking you always know best. > > > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a114bdaba5f2f4b055d73fa32 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 BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgcX3Zp2/wJxtTEG5OrbCozHf9lEo+O0pK jUGOySs0qCkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTA4 MDc1MzA2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAJvZX7smhD1XXlIWabXrmihFs56FudN1J/vAySLM+uO3s1wu2Epv 33d9CpBo6aLsvzAWgs2C3THEQpKM0ejHC+7qXAkPJ8/xnDvQ0y9zxxcxTzxAWpOckwrT2IQ42HGh rgcbwb6ZGj9e7+3RAQKDSy3OIr+rKKFqq7MehNnZcJXasBSn+NOrGLZBSmo0a0ZtfpOBmbQBUZUE 01+iS37yq5H9WwUavgjyR9WdZBffnE8XwFWjD0echmCVF+rEbTPGQjTLeDsg4smoGWfypovCDnPL LDsXXAG13N8XVWKqQd2A6sfBVVhLEZoJdrlyaszmSW6w2LkulGwrriSQ00F+cgw= --001a114bdaba5f2f4b055d73fa32-- From nobody Tue Nov 7 23:57:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F4053131568 for ; Tue, 7 Nov 2017 23:57:24 -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 SVBcncQDid2O for ; Tue, 7 Nov 2017 23:57:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C43412EC91 for ; Tue, 7 Nov 2017 23:57:22 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZJ74624; Wed, 08 Nov 2017 07:57:20 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 8 Nov 2017 07:57:19 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.148]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Wed, 8 Nov 2017 15:57:16 +0800 From: Xuxiaohu To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Tom Herbert CC: "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYwgAAVj4CAAFyIAIAAjwyAgAAC3QCAABm6gIAABDSAgAARG4CAABuQAIAABkUAgAAF94CAAT/wQA== Date: Wed, 8 Nov 2017 07:57:15 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE30477C89@NKGEML515-MBS.china.huawei.com> References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> <008938C4-0861-4BF1-A265-6EE323742B19@nokia.com> In-Reply-To: <008938C4-0861-4BF1-A265-6EE323742B19@nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5A02B8E0.011A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0a86a136a37f236bc7374f9de6069f01 Archived-At: Subject: [v6ops] =?utf-8?b?562U5aSNOiAgRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh?= =?utf-8?q?tion_for_draft-fioccola-spring-flow-label-alt-mark-01=2Etxt?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 07:57:25 -0000 DQoNCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bkuro6IHY2b3BzIFttYWlsdG86 djZvcHMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFZhbiBEZSBWZWxkZSwgR3VudGVyDQo+IChO b2tpYSAtIEJFL0FudHdlcnApDQo+IOWPkemAgeaXtumXtDogMjAxN+W5tDEx5pyIOOaXpSA0OjM3 DQo+IOaUtuS7tuS6ujogVG9tIEhlcmJlcnQNCj4g5oqE6YCBOiB2Nm9wc0BpZXRmLm9yZw0KPiDk uLvpopg6IFJlOiBbdjZvcHNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+IGRy YWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJrLTAxLnR4dA0KPiANCj4gSW4g dGhpcyBjYXNlLCB0aGUgY29udHJvbGxlZCBkb21haW4gcmVmbGVjdHMgdG8gdGhlIGZhY3QgdGhh dCBpdCBpcyBvcGVyYXRvciBjaG9pY2UNCj4gdGhhdCBncmFicyBjb250cm9sIG9mIHBhY2tldCBo YW5kbGluZyB3aXRoaW4gaXRzIG93biBuZXR3b3JrLg0KPiBUaGUgb3BlcmF0b3IgYWRkcyB0aHJv dWdoIHBvbGljeSB0aGUgb3V0ZXIgU1J2NiBoZWFkZXIuIFRoZSBvcGVyYXRvciBoYXMgaW4NCj4g ZmFjdCB0aGVuIHRocmVlIG9wdGlvbnMgcmVnYXJkaW5nIGZsb3cgbGFiZWw6DQo+IA0KPiAxKSBK dXN0IGRvIG5vdCBkbyBhbnl0aGluZyB3aXRoIEZsb3ctbGFiZWwgKGxlYXZlIGl0IGRlZmF1bHQp DQo+IDIpIEFsdGVybmF0ZSBtYXJraW5nIG9ubHkgYW5kIE5PIHVzYWdlIG9mIGVudHJvcHkNCj4g MykgQWx0ZXJuYXRlIG1hcmtpbmcgYW5kIGVudHJvcHkgKGluIHRoaXMgY2FzZSB0aGUgZW50cm9w eSBTSE9VTEQgYmUgYmFzZWQNCj4gdXBvbiAxOCBiaXRzIGluc3RlYWQgb2YgMjAgYml0cyBiZWNh dXNlIG90aGVyd2lzZSBwYXRocyBtYXkgYmUgY2hhbmdlZCB3aGVuDQo+IHRoZSBtYXJraW5nIGNo YW5nZXMgKGUuZy4gcGVyaW9kcyBvZiA1IG1pbnV0ZXMgcGVyIG1hcmtpbmcgcGVyaW9kKSDigKYu IFRoaXMgaXMNCj4gaG93ZXZlciBub3QgYSBNVVNUIGJlY2F1c2Ugc29tZSBvcGVyYXRvcnMgZG8g bm90IGNhcmUgaWYgYmVjYXVzZSBvZiBtYXJraW5nDQo+IGNoYW5nZS4NCg0KSW4gb3B0aW9uIDMs IGl0IHdvdWxkIHJlcXVpcmUgYSBmZXcgY2hhbmdlcyB0byB0aGUgUkZDNjQzNy1jb21wYXRpYmxl IGJlaGF2aW9ycyBvZiBpbnRlcm1lZGlhdGUgcm91dGVycyB3aXRoaW4gYSBjb250cm9sbGVkIG5l dHdvcmsgZG9tYWluLiBIZW5jZSBpdCBzZWVtcyBiZXR0ZXIgYW5kIHNhZmVyIHRvIGRpc2FibGUg dGhlIEZMLWJhc2VkIGxvYWQtYmFsYW5jaW5nIG1lY2hhbmlzbSBpbiB0aGlzIHNwZWNpYWwgY2Fz ZSwgZXNwZWNpYWxseSB3aGVuIHRoZSBleGlzdGluZyBsb2FkLWJhbGFuY2luZyBtZWNoYW5pc20g KGUuZy4sIGZpdmUtdHVwbGUtYmFzZWQgTEIpIGlzIGdvb2QgZW5vdWdoLCBJTUhPLiANCg0KQmVz dCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gRndpdyByaWdodCBub3csIG1vc3QgdmVuZG9ycyBhbGxv dyBhIHdpZGUgYnJlYXRoIG9mIG9wdGlvbnMgZm9yIGVudHJvcHkNCj4gaGFzaGluZyB1cG9uIGFu IElQIGhlYWRlcuKApiBhbmQgbWFueSBvZiB0aGUgY29tYmluYXRpb25zIGRvIG5vdCBoYXZlIGEN Cj4gZm9ybWFsIFJGQyBhdHRhY2hlZCBmb3IgdGhhdCBvcGVyYXRpb24gYXQgYWxsLiBUaGlzIGhh c2ggdXBvbiAxOCBiaXRzIG9mIGZsb3cNCj4gbGFiZWwgd291bGQganVzdCBiZSBhbm90aGVyIGZs YXZvdXIgb2YgZW50cm9weSB0aGF0IG9wZXJhdG9yIGNhbiBlbmFibGUgdXBvbg0KPiB0aGUgcm91 dGVyIOKApiBpdCBpcyBub3QgaGFyZCAuLi4gSSBhcyB2ZW5kb3IgY2FuIGRlbGl2ZXIgdGhpcyBh bmQgSSBuZWVkIG5vIHN0YW5kYXJkDQo+IGZvciB0aGlzIGJlY2F1c2UgaXQgaXMgbm9kYWwgYmVo YXZpb3Vy4oCmIEFuIGVtYm9kaW1lbnQgb2YgYW4gaW1wcm92ZWQgaGFzaA0KPiB1cG9uIHRoZSBm bG93LWxhYmVsIGNvdWxkIGluZGVlZCBtYWtlIHVzZSBvZiB3aWxkLWNhcmRzIOKApiBBIHdpbGRj YXJkIG1hdGNoDQo+IHVwb24gZmxvdy1sYWJlbCBmb3IgZW50cm9weSBjb3VsZCBiZSBhbm90aGVy IHByb3Bvc2FsIHRvIHBvdGVudGlhbGx5IGhhdmUgbmV3DQo+IGZsb3ctbGFiZWwgZmllbGQgdXNh Z2XigKYgaG93ZXZlciwgaXQgY29tZXMgYXQgYSBjb3N04oCmIGVhY2ggYml0IHRoYXQgaXMgcmVt b3ZlZA0KPiBmcm9tIHRoZSBlbnRyb3B5IGhhc2ggLCByZXN1bHRzIGlzIExFU1MgZW50cm9weSwg d2hpY2ggaXMgdW5kZXNpcmFibGUgYWxzby4gQWxzbw0KPiBhZHZhbmNlZCB3aWxkLWNhcmQgYmFz ZWQgaGFzaCBmb3IgZW50cm9weSB1cG9uIGZsb3ctbGFiZWwgZ29lcyBiZXlvbmQgdGhlDQo+IG5l ZWQgZm9yIEFsdGVybmF0ZSBtYXJraW5nIHdpdGhpbiB0aGUgb3BlcmF0b3IgY29udHJvbGxlZCBk b21haW4sIGhlbmNlIHdlDQo+IHNlZSBubyBuZWVkIGZvciBzdWNoIHR5cGUgb2Ygd2lsZCBjYXJk IGJhc2VkIGhhc2jigKYNCj4gDQo+IEcvDQo+IA0KPiBPbiAwNy8xMS8yMDE3LCAyMToxNSwgIlRv bSBIZXJiZXJ0IiA8dG9tQGhlcmJlcnRsYW5kLmNvbT4gd3JvdGU6DQo+IA0KPiAgICAgT24gVHVl LCBOb3YgNywgMjAxNyBhdCAxMTo1MyBBTSwgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0N Cj4gICAgIEJFL0FudHdlcnApIDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4gd3JvdGU6 DQo+ICAgICA+IEhpIFRvbSwNCj4gICAgID4NCj4gICAgID4gVGhlIGNsb3NlZCBzeXN0ZW0gaGVy ZSBpcyBkZWZpbmVkIGJ5IHRoZSBTUnY2IHR1bm5lbHPigKYgVGhlIGZsb3ctbGFiZWwgaXMNCj4g c2V0IOKAnG9ubHnigJ0gYnkgdGhlIHR1bm5lbCBoZWFkLWVuZCByb3V0ZXIg4oCcb24gdGhlIG91 dGVyIElQdjYgaGVhZGVy4oCdLiBUaGUNCj4gdHVubmVsIGhlYWQtZW5kIHJvdXRlciBjYW4gZG8g dGhpcyBiZWNhdXNlIGl0IGlzIHRoZSBkZXZpY2UgdGhhdCBjcmVhdGVkIHRoZQ0KPiBvdXRlciBJ UCBoZWFkZXIuDQo+ICAgICA+IFRoZSBvcmlnaW5hbCBJUHY2IHBhY2tldCBpcyByaWRpbmcgaW5z aWRlIHRoZSB0dW5uZWwsIGFuZCBhcyByZXN1bHQgdGhlDQo+IG9yaWdpbmFsIGZsb3cgbGFiZWwg YW5kIG9yaWdpbmFsIElQdjYgaGVhZGVyIGlzIGxlZnQgdW50b3VjaGVkLiBUaGUgY2xvc2VkIHN5 c3RlbQ0KPiBpcyB0aGUgbmV0d29yayBiZXR3ZWVuIHRoZSB0dW5uZWwgaGVhZC1lbmQgKD13aGVy ZSB0aGUNCj4gICAgID4gb3V0ZXIgSVB2NiBoZWFkZXIgaXMgYWRkZWQpIGFuZCB0aGUgdHVubmVs IHRhaWwtZW5kICg9d2hlcmUgdGhlIG91dGVyDQo+IGhlYWRlciBpcyByZW1vdmVkKS4gVGhpcyB0 eXBlIG9mIGNsb3NlZCBzeXN0ZW0gaXMgZWFzeSB0byBkZXBsb3nigKYgdGFrZSBmb3INCj4gZXhh bXBsZSBhIE1QTFMvVlBOIGJhY2tib25l4oCmLiBPciBhIFZ4TEFOIG5ldHdvcmvigKYgVGhlIFNS djYgbmV0d29yayBpcw0KPiBzb21ldGhpbmcgb2Ygc2ltaWxhciBzaW1wbGljaXR5Lg0KPiAgICAg Pg0KPiAgICAgPiBUaGUgSVB2NiBkZXZpY2UgdGhhdCBnZW5lcmF0ZXMgYW4gSVB2NiBwYWNrZXQg Y2FuIHNldCB0aGUgZmxvdyBsYWJlbCwgYW5kDQo+IHRoYXQgaXMgd2hhdCBkZXZpY2VzIGhhdmUg YmVlbiBkb2luZyBhbGwgdGhlIHRpbWUuIFRoaXMgZHJhZnQgcHJvcG9zZXMgbm90aGluZw0KPiBu ZXcgZnJvbSB0aGF0IHBlcnNwZWN0aXZlLg0KPiAgICAgPg0KPiAgICAgR3VudGVyLA0KPiANCj4g ICAgIEkgYmVsaWV2ZSBzZWN0aW9uIDMgaW1wb3NlcyBuZXcgcmVxdWlyZW1lbnRzIG9uIGZsb3cg bGFiZWwgdXNhZ2UuDQo+IFNwZWNpZmljYWxseToNCj4gDQo+ICAgICAiVGhlIG1ldGhvZG9sb2d5 IFNIT1VMRCBiZSB1c2VkIHdpdGhpbiBhIGNvbnRyb2xsZWQgZG9tYWluIHdoZXJlIHRoZQ0KPiAg ICAgbG9hZC1iYWxhbmNpbmcgYmFzZWQgb24gZmxvdyBsYWJlbCBpcyBkaXNhYmxlZC4gIE90aGVy d2lzZSwgdGhlDQo+ICAgICBuZXR3b3JrIGVsZW1lbnQgTVVTVCBtYXNrIHRoZSBNYXJrIEZpZWxk IChNRiksIHNvIGl0IHdpbGwgbm90IGNoYW5nZQ0KPiAgICAgaGFzaGluZyBjYWxjdWxhdGlvbiBm b3IgdGhlIHNhbWUgZmxvdyBiZWNhdXNlIG9ubHkgMTggYml0cyArIDIgemVyb3MNCj4gICAgIGFy ZSB1c2VkIGZvciB0aGUgZW50cm9weS4iDQo+IA0KPiAgICAgVGhpcyBpbXBsaWVzIHRoYXQgdGhl IHByb3Bvc2FsIGlzIG5vdCBjb21wYXRpYmxlIHdpdGggdGhlIGNhbm9uaWNhbA0KPiAgICAgdXNl IG9mIGZsb3cgbGFiZWwgZm9yIEVDTVAuIElmIG9wdGlvbiBvbmUgaXMgc2VsZWN0ZWQgdGhlbiB0 aGUgb25seQ0KPiAgICAgdXNlIG9mIHRoZSBmbG93IGxhYmVsIGlzIHRvIGV4cHJlc3MgdGhlIE1G IGJpdHMgdGhlIHdob2xlIGZsb3cgbGFiZWwNCj4gICAgIGhhcyBiZWVuIHJlcHVycG9zZWQgYW5k IHdlIGxvc2UgdGhlIHZhbHVlIG9mIGZsb3cgaGFzaGluZy4gT3B0aW9uIDINCj4gICAgIHJlcXVp cmVzIGFuIGltcGxlbWVudGF0aW9uIGNoYW5nZSB0byByb3V0ZXJzIGZ1bmN0aW9uLCBhbmQgYXMg SQ0KPiAgICAgcG9pbnRlZCwgdGhlcmUgd291bGQgbGlrZWx5IGJlIG90aGVyIHVzZXMgb2YgYml0 cyBzbyB0aGlzIHJlYWxseQ0KPiAgICAgc2hvdWxkIGJlIGRlZmluZWQgYXMgYSBjb25maWd1cmFi bGUgbWFzay4gQXMgSSBzYWlkIGJlZm9yZSwgbmVpdGhlciBvZg0KPiAgICAgdGhlc2Ugb3B0aW9u cyBzZWVtIGRlc2lyYWJsZS4NCj4gDQo+ICAgICBUb20NCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QN Cj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wcw0K From nobody Wed Nov 8 02:31:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076E91319A0 for ; Wed, 8 Nov 2017 02:31:33 -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 s5nr1gJKA_HL for ; Wed, 8 Nov 2017 02:31:31 -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 E297913199E for ; Wed, 8 Nov 2017 02:31:30 -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 vA89VDH0066794 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Nov 2017 09:31:14 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: <5A02DCF8.5060903@foobar.org> Date: Wed, 08 Nov 2017 10:31:20 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.20 (Macintosh/20171012) MIME-Version: 1.0 To: Mark Smith CC: v6ops list References: <150860492012.3131.14623048904955800548.idtracker@ietfa.amsl.com> <0EAB4149-AFE9-4770-8242-6D8E05889091@consulintel.es> <66E223E7-73B5-49BA-AA40-5AA632F3F755@consulintel.es> <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> <20171107200021.GX45648@Space.Net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 10:31:33 -0000 Mark Smith wrote: > On 8 Nov. 2017 7:00 am, "Gert Doering" wrote: > - L2 resolution using a routable protocol and relying > on implementations to ensure that it's then "not routed" or "properly > filtered of TTL is not 255" was just plain stupid) > > Just plain stupid is thinking you always know best. Perhaps v6ops is not the best place for dismissive personal comments? Gert has sound technical reasons for making the statement that he did, namely that there are no particular advantages conferred by using icmpv6 + multicast as the on-wire protocol for v6 layer 2 resolution, but there are significant complications associated with doing so. In addition to what he mentioned above, these complications also include the requirements for: functional multicast support on layer 2 devices; having to inspect either multiple locations or across a very wide bitmask in a frame in order to determine whether the frame is a legitimate nd packet; and for lumping multiple types of functionality into the icmpv6, making line-wire frame filtering cumbersome and troublesome to get right. You are, of course, welcome to disagree with these opinions, but it would be helpful if the conversation could remain civil in the process. Nick From nobody Wed Nov 8 05:20:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B504A1252BA for ; Wed, 8 Nov 2017 05:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_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 6Gr-9zatYxNM for ; Wed, 8 Nov 2017 05:20:28 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 063B71250B8 for ; Wed, 8 Nov 2017 05:20:28 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id k195so1668681vke.10 for ; Wed, 08 Nov 2017 05:20: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; bh=BvQuESzGdSq/lJAeswnUslTg26c7gB29BxMGoatCyGM=; b=Jig9tr+5ifEQ9BATxnBRlOmP7MuD0V5eNy6LtDRClXUVujwoPTbPfOwvorTjs3fQhw 6Xw2323kQ2qr0ttIM1S79nkRi/tOZmKFLsvPRiBfKCxrFiC+MpA3QHEuG7aj61GlPGUm IeTaJ3uwhUaAUc9yfpz8A/ShOWDEHMKedYqw6l0zZxuw1/jj5+ggm1Bc/KgqP7lP6/20 OygZNgMo9la3+zecwUoU2akV2/f3vyN3W91idQ0IzmUZwJgt4n6nlPATrgR5zaEq/SPM giM24piNbukq3WGYa9PuFeBoA6z/8kXI6A1I59j7uZkiUs5104OkuQPUr9+5CRtHPhl2 aKpg== 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=BvQuESzGdSq/lJAeswnUslTg26c7gB29BxMGoatCyGM=; b=FmTi2CMM/xsJ/l5teVln0wENPxqVbmnQWPmX3JxVPgn/1jC3E8mh1Xe/ddA/4JgEwY xIhsqqnUyWiw49xL8IfyDDq3qslW6hrXb+QWvhCFpeGgwqv453pAbOaWKNS7klwUz9M2 w/rK+aNjVwLk8LIc3DnK58GK2SHb45CmQu/8vMyK9tkgILh3KdwSXZSjngK+fi1JDp0M 0tDnb4jUTScP1LN82d9WyA/CALwGxYhXJYetABOHCuOz9BC4ic2H0mZOZq7a9szQPPaJ ktkpLAgWienx1utBTPGfC8aMeP3uPtxfdNhi5MVwvd5/0x0aI44KhBLKtsiVzGTg7oFM R0IA== X-Gm-Message-State: AJaThX5fx3/9+p4BlTb/O4o+isJ+u880s49FS7BFdiat+NfhUnTTR3Vd 79xnKGXPop7Oaf0z6Kvu2cxlpO/8t3TSxRD5ke4= X-Google-Smtp-Source: ABhQp+SKkh75r1dTVL+8iO1xF376zwdZ/5n24/CE5MCY+VimZ+AFHMPQY+TGYnM+8f88182JFgPqdKk7opcHNSfA03Y= X-Received: by 10.31.165.214 with SMTP id o205mr367108vke.147.1510147226948; Wed, 08 Nov 2017 05:20:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Wed, 8 Nov 2017 05:20:26 -0800 (PST) Received: by 10.159.52.221 with HTTP; Wed, 8 Nov 2017 05:20:26 -0800 (PST) In-Reply-To: <5A02DCF8.5060903@foobar.org> References: <150860492012.3131.14623048904955800548.idtracker@ietfa.amsl.com> <0EAB4149-AFE9-4770-8242-6D8E05889091@consulintel.es> <66E223E7-73B5-49BA-AA40-5AA632F3F755@consulintel.es> <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> <20171107200021.GX45648@Space.Net> <5A02DCF8.5060903@foobar.org> From: Mark Smith Date: Thu, 9 Nov 2017 00:20:26 +1100 Message-ID: To: Nick Hilliard Cc: v6ops list Content-Type: multipart/alternative; boundary="001a11415eee0558a5055d788d1e" Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:20:30 -0000 --001a11415eee0558a5055d788d1e Content-Type: text/plain; charset="UTF-8" Gert provided no reasons for his assertions other than popularity, which is really just an appeal to authority. You have provided some of the arguments he should have. Furthermore, he chose to use perjoritive and dismissive terms such as "totally wrong" and "plain stupid". I rarely and try to rarely dismiss arguments I disagree using absolutes and perjoritives such as those Gert used. I've been disagreeing with Ole, yet you'll find that I have not dismissed Ole's position the way Gert dismissed mine. Ole has also been respectful in his responses to me, even though he has been disagreeing. Regards, Mark. On 8 Nov 2017 9:31 pm, "Nick Hilliard" wrote: Mark Smith wrote: > On 8 Nov. 2017 7:00 am, "Gert Doering" wrote: > - L2 resolution using a routable protocol and relying > on implementations to ensure that it's then "not routed" or "properly > filtered of TTL is not 255" was just plain stupid) > > Just plain stupid is thinking you always know best. Perhaps v6ops is not the best place for dismissive personal comments? Gert has sound technical reasons for making the statement that he did, namely that there are no particular advantages conferred by using icmpv6 + multicast as the on-wire protocol for v6 layer 2 resolution, but there are significant complications associated with doing so. In addition to what he mentioned above, these complications also include the requirements for: functional multicast support on layer 2 devices; having to inspect either multiple locations or across a very wide bitmask in a frame in order to determine whether the frame is a legitimate nd packet; and for lumping multiple types of functionality into the icmpv6, making line-wire frame filtering cumbersome and troublesome to get right. You are, of course, welcome to disagree with these opinions, but it would be helpful if the conversation could remain civil in the process. Nick --001a11415eee0558a5055d788d1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Gert provided no reasons for his assertions other th= an popularity, which is really just an appeal to authority. You have provid= ed some of the arguments he should have.

<= div dir=3D"auto">Furthermore, he chose to use perjoritive and dismissive te= rms such as "totally wrong" and "plain stupid".

I rarely and try to rarely dism= iss arguments I disagree using absolutes and perjoritives such as those Ger= t used. I've been disagreeing with Ole, yet you'll find that I have= not dismissed Ole's position the way Gert dismissed mine. Ole has also= been respectful in his responses to me, even though he has been disagreein= g.


Regards,
Mark.


On 8 Nov 2017 9:31 pm, "Nick Hilliard" <nick@foobar.org> wrote:
Mark Smith wr= ote:
> On 8 Nov. 2017 7:00 am, "Gert Doering" <gert@space.net> wrote:
>=C2=A0 =C2=A0 =C2=A0- L2 resolution us= ing a routable protocol and relying
>=C2=A0 =C2=A0 =C2=A0on implementations to ensure that it's then &qu= ot;not routed" or "properly
>=C2=A0 =C2=A0 =C2=A0filtered of TTL is not 255" was just plain stu= pid)
>
> Just plain stupid is thinking you always know best.

Perhaps v6ops is not the best place for dismissive personal comments?=

Gert has sound technical reasons for making the statement that he did,
namely that there are no particular advantages conferred by using icmpv6 + multicast as the on-wire protocol for v6 layer 2 resolution, but there are significant complications associated with doing so.=C2=A0 In addition t= o
what he mentioned above, these complications also include the
requirements for: functional multicast support on layer 2 devices;
having to inspect either multiple locations or across a very wide
bitmask in a frame in order to determine whether the frame is a
legitimate nd packet; and for lumping multiple types of functionality
into the icmpv6, making line-wire frame filtering cumbersome and
troublesome to get right.

You are, of course, welcome to disagree with these opinions, but it
would be helpful if the conversation could remain civil in the process.

Nick


--001a11415eee0558a5055d788d1e-- From nobody Wed Nov 8 05:25:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788B9126BFD for ; Wed, 8 Nov 2017 05:25: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, 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 f2qK6TXU6HVn for ; Wed, 8 Nov 2017 05:25:34 -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 873471267BB for ; Wed, 8 Nov 2017 05:25:34 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6350D449D5 for ; Wed, 8 Nov 2017 14:25:32 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 40090449D2; Wed, 8 Nov 2017 14:25:32 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 3164F6D7CC; Wed, 8 Nov 2017 14:25:32 +0100 (CET) Date: Wed, 8 Nov 2017 14:25:32 +0100 From: Gert Doering To: Mark Smith Cc: Nick Hilliard , v6ops list Message-ID: <20171108132532.GJ45648@Space.Net> References: <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> <20171107200021.GX45648@Space.Net> <5A02DCF8.5060903@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:25:36 -0000 Hi, On Thu, Nov 09, 2017 at 12:20:26AM +1100, Mark Smith wrote: > Gert provided no reasons for his assertions other than popularity, which is > really just an appeal to authority. You have provided some of the arguments > he should have. Since we're in v6*ops*, it should not be necessary to repeat the shortcomings of ND ad nauseam. I was referring to your claim that "make every link look the same" was a good decision, and that ND is better than ARP, which the last 20 years have shown to not be. > Furthermore, he chose to use perjoritive and dismissive terms such as > "totally wrong" and "plain stupid". Obviously it's easier in hindsight, but from 2017's point of view, yes indeed, some early design decisions of IPv6 have not been smart, and that is plainly visible. So, yes, plain stupid. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Nov 8 05:32:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9D0126579 for ; Wed, 8 Nov 2017 05:32: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 22qpXNauJPd3 for ; Wed, 8 Nov 2017 05:32:05 -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 924441201F2 for ; Wed, 8 Nov 2017 05:32:05 -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 vA8CVshg090304 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Nov 2017 12:31:55 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: <5A030751.8030707@foobar.org> Date: Wed, 08 Nov 2017 13:32:01 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.20 (Macintosh/20171012) MIME-Version: 1.0 To: Mark Smith CC: v6ops list References: <150860492012.3131.14623048904955800548.idtracker@ietfa.amsl.com> <0EAB4149-AFE9-4770-8242-6D8E05889091@consulintel.es> <66E223E7-73B5-49BA-AA40-5AA632F3F755@consulintel.es> <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> <20171107200021.GX45648@Space.Net> <5A02DCF8.5060903@foobar.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:32:13 -0000 Mark Smith wrote: > Gert provided no reasons for his assertions other than popularity, which > is really just an appeal to authority. You have provided some of the > arguments he should have. This isn't the first time this topic has come up. In fact, it's been discussed to death over the years, and Gert has talked about it on many occasions before. > Furthermore, he chose to use perjoritive and dismissive terms such as > "totally wrong" and "plain stupid". Those comments were made about the decision and the protocol rather than "thinking you always know best", which is a comment made about a person. Making pejorative comments about a person is not generally considered acceptable in the context of working groups, IETF or otherwise. Nick From nobody Wed Nov 8 05:49:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FFC126CD6 for ; Wed, 8 Nov 2017 05:49: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] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkV3z4XzqiyI for ; Wed, 8 Nov 2017 05:49:06 -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 7008B126E3A for ; Wed, 8 Nov 2017 05:49:05 -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 m1eCQj1-0000GFC; Wed, 8 Nov 2017 14:49:03 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> <20171107200021.GX45648@Space.Net> <5A02DCF8.5060903@foobar.org> <20171108132532.GJ45648@Space.Net> In-reply-to: Your message of "Wed, 8 Nov 2017 14:25:32 +0100 ." <20171108132532.GJ45648@Space.Net> Date: Wed, 08 Nov 2017 14:49:02 +0100 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:49:08 -0000 >Since we're in v6*ops*, it should not be necessary to repeat the >shortcomings of ND ad nauseam. I was referring to your claim that >"make every link look the same" was a good decision, and that ND is >better than ARP, which the last 20 years have shown to not be. This (ND and p2p links) is a confusing subject. When I first read the ND specs, I found it a ridiculous approach compared to ARP. However, if you jump through all the hoops, it seems to work as well as ARP. No real issue there. Other then just too much complexity. On point-to-point links the situation is different. Obviously, there is no need for link layer address resolution. However, ND also provides neighbor reachability information. On a 'normal' p2p link that should be redundant. The routing protocol should take care of that. However, for example, the CPE spec defines the upstream interface of a CPE to be a host. And as a final bit of complexity, I found that on quite a few links I had to disable ND because to other side doesn't want to play along. So one way forword is to specify that for p2p links, certainly between two routers, ND should be disabled. From nobody Wed Nov 8 05:59:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 035CA12704A for ; Wed, 8 Nov 2017 05:59:21 -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 FAHx4mWAExe5 for ; Wed, 8 Nov 2017 05:59:19 -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 BCF89126D74 for ; Wed, 8 Nov 2017 05:59:18 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id B7AC74238B for ; Wed, 8 Nov 2017 14:59:16 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id A70E1422A9; Wed, 8 Nov 2017 14:59:16 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 96CBE6D8A1; Wed, 8 Nov 2017 14:59:16 +0100 (CET) Date: Wed, 8 Nov 2017 14:59:16 +0100 From: Gert Doering To: Philip Homburg Cc: v6ops@ietf.org, Gert Doering Message-ID: <20171108135916.GK45648@Space.Net> References: <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> <20171107200021.GX45648@Space.Net> <5A02DCF8.5060903@foobar.org> <20171108132532.GJ45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ewEwBIBtLBQk55E3" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:59:21 -0000 --ewEwBIBtLBQk55E3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Nov 08, 2017 at 02:49:02PM +0100, Philip Homburg wrote: > >Since we're in v6*ops*, it should not be necessary to repeat the=20 > >shortcomings of ND ad nauseam. I was referring to your claim that > >"make every link look the same" was a good decision, and that ND is > >better than ARP, which the last 20 years have shown to not be. >=20 > This (ND and p2p links) is a confusing subject.=20 >=20 > When I first read the ND specs, I found it a ridiculous approach compared= to > ARP. However, if you jump through all the hoops, it seems to work as well= as=20 > ARP. No real issue there. Other then just too much complexity. Then, after 10 years of "ok, it seems to work", you get a router vendor advisory that control-plane rate-limiting for ND does not work right (garbage drowning out expected packets in the rate-limited queue from "fast forwarding hardware" towards the CPU). Then you notice that these are packets that have an on-link-only role, but can be nicely sent=20 off-link, and receivers are expected to do TTL validation on receipt, instead of "just using a protocol that *cannot* be sent off-link". And *then* you figure out that for a single protocol on a single link you need to maintain multiple lines of ACL because source and destionation addresses can be lots of interesting combinations of ::, link-local and global addresses. (And after that, you notice that one of the more widespread router vendors out there happily forwards packets with a link-local source and an off-link global destination, so not even the "we only permit=20 ::, LLA or on-link source" ACL rule will be able to catch all the garbage) Up to that point, I also thought "yeah, a bit complicated, but seems to=20 work okayish, as long as you remember to permit ND through your interface= =20 ACLs"... (well, except for the state exhaustion attacks, the multicast, and all that). Good work. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --ewEwBIBtLBQk55E3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAloDDbEACgkQ31bAZeTO f8UC5A/+JlUGq1YN0Q3zI83e5ysjjmsSwEBJ3AM1+KbMwzkh84PxXge45pvHo7XA sZBK6mZvMdvSs9MMXrI7GDBLmlK9fSdwvvoRD1DXSIjseOU7z5EVTYNe9FnkIVzd smmCw1UnjiLt65d3sf9HLdcwjbeWGNTPiIUaa4adHMpbHQc73K6dw5SkJ+QS+5Dn 4Xi8d1G4Kp9aJ/QLCD5eQza4BL2MoNcEtQUWNHOIEJMJj/pM8MAGJERdm+kwGHji NBkv5hRbh3oi3c+oiM0aWO99M6a4RfXlWmbVYLrC0JO4aX6zPPHX571aZqy0nic8 TIvpoQ4UvASxRzhPVIfNgnjcXhNBNP5rYe6jHXnTFEBime6f7qPH9/P9nDp8xnXP yHhNNUqZhXtz+dYDD520hOg7EIbj0ylrTdYvDrU062YtQaEinrlf2Kwg3BCfU7uv toO04fzws8EinBCPlgpPB622fH7YCf2VmT4tgJH+hSqdNU9pwaGvF8eIJDHhuwC4 Ur2mLWWi57d2AuQXeDnHLR5XqEWFGTuxwz4W3KDhkd9fMlsBo+m1f0GOEbRortFz 4w+H5JY7qFpO0DxZsRI8gsvtclmfYTUUpO0HPHKdNY2Tv7Z7hOuHu2hdqxMppm27 etKFacaBr5dULS0gmU7+InN8mQvvKVWomKC2Jds3saCwFuRoHFg= =x7bu -----END PGP SIGNATURE----- --ewEwBIBtLBQk55E3-- From nobody Wed Nov 8 06:25:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADFA12711E for ; Wed, 8 Nov 2017 06:25:13 -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 X8dxpsRs5u7q for ; Wed, 8 Nov 2017 06:25:12 -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 F255F12708C for ; Wed, 8 Nov 2017 06:25:11 -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 m1eCRHx-0000FbC; Wed, 8 Nov 2017 15:25:09 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> <20171107200021.GX45648@Space.Net> <5A02DCF8.5060903@foobar.org> <20171108132532.GJ45648@Space.Net> <20171108135916.GK45648@Space.Net> In-reply-to: Your message of "Wed, 8 Nov 2017 14:59:16 +0100 ." <20171108135916.GK45648@Space.Net> Date: Wed, 08 Nov 2017 15:25:09 +0100 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 14:25:13 -0000 >Up to that point, I also thought "yeah, a bit complicated, but seems to >work okayish, as long as you remember to permit ND through your interface >ACLs"... (well, except for the state exhaustion attacks, the multicast, >and all that). Comes with built-in job security. From nobody Wed Nov 8 06:52:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F871270A7 for ; Wed, 8 Nov 2017 06:52:20 -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 h9AJfrw-0oyy for ; Wed, 8 Nov 2017 06:52:19 -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 E4D5B12706D for ; Wed, 8 Nov 2017 06:52:18 -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 vA8Dq8tN001049 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Nov 2017 13:52:08 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: <5A031A1E.3070405@foobar.org> Date: Wed, 08 Nov 2017 14:52:14 +0000 From: Nick Hilliard User-Agent: Postbox 5.0.20 (Macintosh/20171012) MIME-Version: 1.0 To: Philip Homburg CC: v6ops@ietf.org References: <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> <20171107200021.GX45648@Space.Net> <5A02DCF8.5060903@foobar.org> <20171108132532.GJ45648@Space.Net> <20171108135916.GK45648@Space.Net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 14:52:21 -0000 Philip Homburg wrote: >> Up to that point, I also thought "yeah, a bit complicated, but seems to >> work okayish, as long as you remember to permit ND through your interface >> ACLs"... (well, except for the state exhaustion attacks, the multicast, >> and all that). > > Comes with built-in job security. I'd happily trade job security for protocol simplicity. There are plenty of other interesting problems in life. Nick From nobody Wed Nov 8 06:58:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D793912706D for ; Wed, 8 Nov 2017 06:58: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] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAI56e_vwY2q for ; Wed, 8 Nov 2017 06:58: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 B5646126557 for ; Wed, 8 Nov 2017 06:58: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 m1eCRo5-0000EoC; Wed, 8 Nov 2017 15:58:21 +0100 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <553EFFEF-BB82-4F63-B80E-9E84BB9A903A@employees.org> <20171107200021.GX45648@Space.Net> <5A02DCF8.5060903@foobar.org> <20171108132532.GJ45648@Space.Net> <20171108135916.GK45648@Space.Net> <5A031A1E.3070405@foobar.org> In-reply-to: Your message of "Wed, 08 Nov 2017 14:52:14 +0000 ." <5A031A1E.3070405@foobar.org> Date: Wed, 08 Nov 2017 15:58:21 +0100 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 14:58:33 -0000 >> Comes with built-in job security. > >I'd happily trade job security for protocol simplicity. There are >plenty of other interesting problems in life. Even on day one, it was already clear that ND was a lot more complex than ARP. Then we discovered how complex it really was. And due to the dislike of DHCPv6, it will get even more complex. But I guess it is bit too late to propose that we dump the whole mess and go back to ARP and DHCP. From nobody Wed Nov 8 07:33:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6F312783A for ; Wed, 8 Nov 2017 07:33:44 -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 0RFxmgHxD_36 for ; Wed, 8 Nov 2017 07:33:43 -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 49974127775 for ; Wed, 8 Nov 2017 07:33:43 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id q83so3781583qke.6 for ; Wed, 08 Nov 2017 07:33:43 -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=51AF/Kh82LFWEZ2+Jsyxf9xoyl2oJ75hMqMoeMPDomg=; b=rBQZHtl3A3Rxv5ospChctuh4WgkusG3CoeYxSsypfodSKQqeFFMTzcFdTX2OP8GgHj sKxIAUIpQUixhp3M2z03i31MgCpmt8/C9LBiYEjq18yOGAIzDfsl8Q3kd0KWuC2DVV3/ Nqd9YjzrynOcrJDmfnppdkRanPpumPeiPG0b/dYSmJ57L6lzvLd4XrpYZly6AAo2uP/u BB/xjyB2GI6/hxrJiuD7uHrX49wr0RqOVkFaTLSeHqo9ueUZBTOpMFELZFqq8OktlmPc ILQymU1CjXmd3u2Hbtq8riiu4ARe3ZKHcolaTKW88oa49am0Arwu4aH7bbRBKm78HqNK XhCA== 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=51AF/Kh82LFWEZ2+Jsyxf9xoyl2oJ75hMqMoeMPDomg=; b=myRBNHTDAbxEb6COGWsSbZ/js+QTXikme1f9nuO0hO0wq3EEB2IK25STkdE+Jq4IUU 210PaNbu8gMgEE+x5sBCGKl5590Hc9MOyPOMFegiXgJefES4VW68ICglFcR5ru7Tuxn5 FCakyBmqKJ7COetUqQ7ZV5/XL/5YYv5qzhLx3CGmEPgvOwPhoLeBFgQTSShDCW2XvnF8 swSU9vZLvFYreOHMzc0B79WgCiXAjxklXLn4IJf6soZccYhmtyly9iHnAvD0+GnpQcMS Ab3mfbYkPJUyxC1fSpCpJWwfqW+BR6wRyNIKgfWITCkdpy19onB8d82kjqvZyfvPEJsu plmg== X-Gm-Message-State: AJaThX7U6wI58kBVJzRcqpj7TIFg+Qp6Ju1V4w8xWOUHsv7PLbQ32eH5 D4u+yyqshgrasLSv8DrRXd5ZzyqQxBh4FqrzWXiVJQ== X-Google-Smtp-Source: AGs4zMYeRtiYg7DDLCDFuLNCkJEbiOIdO4cjhwPOpPLaJmUEP4HasJQneQKi7hNmmN15uctEkV5z3bPFF1X0LzcFWHg= X-Received: by 10.55.89.65 with SMTP id n62mr1264658qkb.51.1510155222393; Wed, 08 Nov 2017 07:33:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.43.239 with HTTP; Wed, 8 Nov 2017 07:33:41 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE30477C89@NKGEML515-MBS.china.huawei.com> References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> <008938C4-0861-4BF1-A265-6EE323742B19@nokia.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE30477C89@NKGEML515-MBS.china.huawei.com> From: Tom Herbert Date: Wed, 8 Nov 2017 07:33:41 -0800 Message-ID: To: Xuxiaohu Cc: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?b?562U5aSNOiAgRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh?= =?utf-8?q?tion_for_draft-fioccola-spring-flow-label-alt-mark-01=2Etxt?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 15:33:44 -0000 On Tue, Nov 7, 2017 at 11:57 PM, Xuxiaohu wrote: > > >> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> =E5=8F=91=E4=BB=B6=E4=BA=BA: v6ops [mailto:v6ops-bounces@ietf.org] =E4= =BB=A3=E8=A1=A8 Van De Velde, Gunter >> (Nokia - BE/Antwerp) >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B411=E6=9C=888=E6=97=A5= 4:37 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: Tom Herbert >> =E6=8A=84=E9=80=81: v6ops@ietf.org >> =E4=B8=BB=E9=A2=98: Re: [v6ops] FW: New Version Notification for >> draft-fioccola-spring-flow-label-alt-mark-01.txt >> >> In this case, the controlled domain reflects to the fact that it is oper= ator choice >> that grabs control of packet handling within its own network. >> The operator adds through policy the outer SRv6 header. The operator has= in >> fact then three options regarding flow label: >> >> 1) Just do not do anything with Flow-label (leave it default) >> 2) Alternate marking only and NO usage of entropy >> 3) Alternate marking and entropy (in this case the entropy SHOULD be bas= ed >> upon 18 bits instead of 20 bits because otherwise paths may be changed w= hen >> the marking changes (e.g. periods of 5 minutes per marking period) =E2= =80=A6. This is >> however not a MUST because some operators do not care if because of mark= ing >> change. > > In option 3, it would require a few changes to the RFC6437-compatible beh= aviors of intermediate routers within a controlled network domain. Hence it= seems better and safer to disable the FL-based load-balancing mechanism in= this special case, especially when the existing load-balancing mechanism (= e.g., five-tuple-based LB) is good enough, IMHO. > Five-tuple hash requires parsing into the transport layer to get the ports. In the proposed use case there will be extension headers (at least a routing header) so routers would need to parse over those. It's unlikely that such parsing is consistently implemented and besides that the whole point of using the flow label for ECMP is to obviate the need for routers to perform DPI. Tom From nobody Wed Nov 8 08:16:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9863127B73 for ; Wed, 8 Nov 2017 08:16:46 -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 QtHzNGXWt9ax for ; Wed, 8 Nov 2017 08:16:40 -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 C268D1273E2 for ; Wed, 8 Nov 2017 08:16:40 -0800 (PST) Received: from mb.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id vA8GGVbn098330 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 8 Nov 2017 16:16:32 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mb.local To: Tom Herbert , Xuxiaohu Cc: "v6ops@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> <008938C4-0861-4BF1-A265-6EE323742B19@nokia.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE30477C89@NKGEML515-MBS.china.huawei.com> From: joel jaeggli Message-ID: <199d8e92-a307-161b-175d-c1a762a0bef1@bogus.com> Date: Wed, 8 Nov 2017 08:16:26 -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: Subject: Re: [v6ops] =?utf-8?b?562U5aSNOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0?= =?utf-8?q?ion_for_draft-fioccola-spring-flow-label-alt-mark-01=2Etxt?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 16:16:46 -0000 On 11/8/17 07:33, Tom Herbert wrote: > On Tue, Nov 7, 2017 at 11:57 PM, Xuxiaohu wrote: >> >> >>> -----邮件原件----- >>> 发件人: v6ops [mailto:v6ops-bounces@ietf.org] 代表 Van De Velde, Gunter >>> (Nokia - BE/Antwerp) >>> 发送时间: 2017年11月8日 4:37 >>> 收件人: Tom Herbert >>> 抄送: v6ops@ietf.org >>> 主题: Re: [v6ops] FW: New Version Notification for >>> draft-fioccola-spring-flow-label-alt-mark-01.txt >>> >>> In this case, the controlled domain reflects to the fact that it is operator choice >>> that grabs control of packet handling within its own network. >>> The operator adds through policy the outer SRv6 header. The operator has in >>> fact then three options regarding flow label: >>> >>> 1) Just do not do anything with Flow-label (leave it default) >>> 2) Alternate marking only and NO usage of entropy >>> 3) Alternate marking and entropy (in this case the entropy SHOULD be based >>> upon 18 bits instead of 20 bits because otherwise paths may be changed when >>> the marking changes (e.g. periods of 5 minutes per marking period) …. This is >>> however not a MUST because some operators do not care if because of marking >>> change. >> >> In option 3, it would require a few changes to the RFC6437-compatible behaviors of intermediate routers within a controlled network domain. Hence it seems better and safer to disable the FL-based load-balancing mechanism in this special case, especially when the existing load-balancing mechanism (e.g., five-tuple-based LB) is good enough, IMHO. >> > Five-tuple hash requires parsing into the transport layer to get the > ports. In the proposed use case there will be extension headers (at > least a routing header) so routers would need to parse over those. > It's unlikely that such parsing is consistently implemented and > besides that the whole point of using the flow label for ECMP is to > obviate the need for routers to perform DPI. The flow label is unprotected in the header which makes it hard to use to hash to stateful endpoints. it would be helpful if nothng ever changed it or did so consistently but in fact devices that do so exist. > Tom > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Nov 8 09:25:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA4C12943B for ; Wed, 8 Nov 2017 09:25:39 -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 xTL5AxMk-44L for ; Wed, 8 Nov 2017 09:25:37 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d: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 D4E0A129435 for ; Wed, 8 Nov 2017 09:25:33 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id o6so4288815qkh.3 for ; Wed, 08 Nov 2017 09:25:33 -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=ZBXBoL+1eiOVSAN8He36h+x+h8JpWXFWF9jGDWaBjMA=; b=QN0xNCLvCZwy2zw704uGti77+1jO0EinRnj6wylCBvIQwvZSbAx4/VOTfnP4Mi0L7z jMOSNj0fyGU+Mxb6GiV+W5kNeROLdLCdbh8Ghifn1L+AjvRSKsU0FN4o9KFGWMrjjNcK JZdSXTYm7plshSVSEl+VDHIPt9utFcWf1BNDYW+jRvggOLWvysFRHh7mne6m5dysR1yN ue0rtA/qZBjo5FTQK9nEVo+UCZtOT/YVWVF346D9FAQZZJ5li6nrdGidnY8IQdtrTBqm JxcEPOZrd8ZHmW/nnyQQM+OE8L6mMjCPqNE0DyeUrcyg/DfzPC23DZrEphuVY4VwNd5s QUSw== 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=ZBXBoL+1eiOVSAN8He36h+x+h8JpWXFWF9jGDWaBjMA=; b=pJmgUM1NHD9GXzJ8qFVtKmyp7iscR/AhDkIOOgzXJBqcKh4kIc4PYDId9WsR4qPB0Y aeaVPA4yYZBWwHP+0POtByhJgF0uzanz4g7oxkkktM2n7iH5BN7tysPa1E7WBPJCKPbV QAbI4iWSRA87vrmsFTHTPgayRZT/lyHgq+tJECqQweM+z/6lBaZ1H5dVRTFMcEoevvSp sXEj0fxyEewjB4fivM+/VN+8KaR6taVRPEtICctuXPSwWJBs3sWjY2UqPipHu+nW/ChC IP2YezKv7s7mAI+5Pd0p8ZR4T2i83G8LSz5W2Rbf3GJf527bXNLpjLsqcbsf+Fs5lkMJ Wx7w== X-Gm-Message-State: AJaThX6p2+sJIHHUWm14gHld1Fy80jJ7LI5o8Jb2n5IuqhCVBl2XU/5l BZzakeG/NY4hzxADIYO7Nc7k4ftuNeezBAhHdV+cnA== X-Google-Smtp-Source: AGs4zMaWPlZA4bTSmu/sjBiO2M8tb30eGYIBoZpjdRfTOKp0gS7VB3E1pBKwlycHkNrLrMy+GCZ03LR6H3U0i/S7Xmo= X-Received: by 10.55.106.132 with SMTP id f126mr1848552qkc.295.1510161932947; Wed, 08 Nov 2017 09:25:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Wed, 8 Nov 2017 09:25:32 -0800 (PST) In-Reply-To: <199d8e92-a307-161b-175d-c1a762a0bef1@bogus.com> References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> <008938C4-0861-4BF1-A265-6EE323742B19@nokia.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE30477C89@NKGEML515-MBS.china.huawei.com> <199d8e92-a307-161b-175d-c1a762a0bef1@bogus.com> From: Tom Herbert Date: Wed, 8 Nov 2017 09:25:32 -0800 Message-ID: To: joel jaeggli Cc: Xuxiaohu , "v6ops@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?b?562U5aSNOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0?= =?utf-8?q?ion_for_draft-fioccola-spring-flow-label-alt-mark-01=2Etxt?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 17:25:39 -0000 On Wed, Nov 8, 2017 at 8:16 AM, joel jaeggli wrote: > On 11/8/17 07:33, Tom Herbert wrote: >> On Tue, Nov 7, 2017 at 11:57 PM, Xuxiaohu wrote: >>> >>> >>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: v6ops [mailto:v6ops-bounces@ietf.org] =E4= =BB=A3=E8=A1=A8 Van De Velde, Gunter >>>> (Nokia - BE/Antwerp) >>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B411=E6=9C=888=E6=97= =A5 4:37 >>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Tom Herbert >>>> =E6=8A=84=E9=80=81: v6ops@ietf.org >>>> =E4=B8=BB=E9=A2=98: Re: [v6ops] FW: New Version Notification for >>>> draft-fioccola-spring-flow-label-alt-mark-01.txt >>>> >>>> In this case, the controlled domain reflects to the fact that it is op= erator choice >>>> that grabs control of packet handling within its own network. >>>> The operator adds through policy the outer SRv6 header. The operator h= as in >>>> fact then three options regarding flow label: >>>> >>>> 1) Just do not do anything with Flow-label (leave it default) >>>> 2) Alternate marking only and NO usage of entropy >>>> 3) Alternate marking and entropy (in this case the entropy SHOULD be b= ased >>>> upon 18 bits instead of 20 bits because otherwise paths may be changed= when >>>> the marking changes (e.g. periods of 5 minutes per marking period) =E2= =80=A6. This is >>>> however not a MUST because some operators do not care if because of ma= rking >>>> change. >>> >>> In option 3, it would require a few changes to the RFC6437-compatible b= ehaviors of intermediate routers within a controlled network domain. Hence = it seems better and safer to disable the FL-based load-balancing mechanism = in this special case, especially when the existing load-balancing mechanism= (e.g., five-tuple-based LB) is good enough, IMHO. >>> >> Five-tuple hash requires parsing into the transport layer to get the >> ports. In the proposed use case there will be extension headers (at >> least a routing header) so routers would need to parse over those. >> It's unlikely that such parsing is consistently implemented and >> besides that the whole point of using the flow label for ECMP is to >> obviate the need for routers to perform DPI. > > The flow label is unprotected in the header which makes it hard to use > to hash to stateful endpoints. it would be helpful if nothng ever > changed it or did so consistently but in fact devices that do so exist. > Joel, The problem isn't at stateful endpoints, it's with middleboxes that maintain flow state. The result of a flow label change at an endpoint is OOO packets which any transport protocol is expected to gracefully handle. A middlebox that maintains state expects all packets of the flow to got through it, so if there is a flow label change (or other routing change) packets for the flow may bypass the device (like a firewall or NAT) with the flow state. It's likely they're forwarded through a peer device that doesn't have any state for the flow and so dropped packets ensue. This has created an implicit requirement on network architecture that all packets of a flow need to follow the same path. From a host perspective there are good reasons to change the flow label, for instance we can modulate the the flow label for a failing connection as a form of source routing to try for a better route through the network. However, from a practical perspective I suppose the recommendation should be that by default the flow label should be constant for the lifetime of the flow. Tom From nobody Wed Nov 8 10:16:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0EE1294CF for ; Wed, 8 Nov 2017 10:16:55 -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 D3C4J47MhuIY for ; Wed, 8 Nov 2017 10:16:54 -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 552E7120724 for ; Wed, 8 Nov 2017 10:16:54 -0800 (PST) Received: from mb.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id vA8IGmoe099150 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 8 Nov 2017 18:16:48 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mb.local To: Tom Herbert Cc: Xuxiaohu , "v6ops@ietf.org" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> <008938C4-0861-4BF1-A265-6EE323742B19@nokia.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE30477C89@NKGEML515-MBS.china.huawei.com> <199d8e92-a307-161b-175d-c1a762a0bef1@bogus.com> From: joel jaeggli Message-ID: <3caffe52-7ace-8871-2585-bdb02a69ad56@bogus.com> Date: Wed, 8 Nov 2017 10:16:43 -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: Subject: Re: [v6ops] =?utf-8?b?562U5aSNOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0?= =?utf-8?q?ion_for_draft-fioccola-spring-flow-label-alt-mark-01=2Etxt?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 18:16:55 -0000 On 11/8/17 09:25, Tom Herbert wrote: > On Wed, Nov 8, 2017 at 8:16 AM, joel jaeggli wrote: >> On 11/8/17 07:33, Tom Herbert wrote: >>> On Tue, Nov 7, 2017 at 11:57 PM, Xuxiaohu wrote: >>>> >>>> >>>>> -----邮件原件----- >>>>> 发件人: v6ops [mailto:v6ops-bounces@ietf.org] 代表 Van De Velde, Gunter >>>>> (Nokia - BE/Antwerp) >>>>> 发送时间: 2017年11月8日 4:37 >>>>> 收件人: Tom Herbert >>>>> 抄送: v6ops@ietf.org >>>>> 主题: Re: [v6ops] FW: New Version Notification for >>>>> draft-fioccola-spring-flow-label-alt-mark-01.txt >>>>> >>>>> In this case, the controlled domain reflects to the fact that it is operator choice >>>>> that grabs control of packet handling within its own network. >>>>> The operator adds through policy the outer SRv6 header. The operator has in >>>>> fact then three options regarding flow label: >>>>> >>>>> 1) Just do not do anything with Flow-label (leave it default) >>>>> 2) Alternate marking only and NO usage of entropy >>>>> 3) Alternate marking and entropy (in this case the entropy SHOULD be based >>>>> upon 18 bits instead of 20 bits because otherwise paths may be changed when >>>>> the marking changes (e.g. periods of 5 minutes per marking period) …. This is >>>>> however not a MUST because some operators do not care if because of marking >>>>> change. >>>> >>>> In option 3, it would require a few changes to the RFC6437-compatible behaviors of intermediate routers within a controlled network domain. Hence it seems better and safer to disable the FL-based load-balancing mechanism in this special case, especially when the existing load-balancing mechanism (e.g., five-tuple-based LB) is good enough, IMHO. >>>> >>> Five-tuple hash requires parsing into the transport layer to get the >>> ports. In the proposed use case there will be extension headers (at >>> least a routing header) so routers would need to parse over those. >>> It's unlikely that such parsing is consistently implemented and >>> besides that the whole point of using the flow label for ECMP is to >>> obviate the need for routers to perform DPI. >> >> The flow label is unprotected in the header which makes it hard to use >> to hash to stateful endpoints. it would be helpful if nothng ever >> changed it or did so consistently but in fact devices that do so exist. >> > Joel, > > The problem isn't at stateful endpoints, it's with middleboxes that > maintain flow state. The result of a flow label change at an endpoint > is OOO packets which any transport protocol is expected to gracefully > handle. A middlebox that maintains state expects all packets of the > flow to got through it, so if there is a flow label change (or other > routing change) packets for the flow may bypass the device (like a > firewall or NAT) with the flow state. It's likely they're forwarded > through a peer device that doesn't have any state for the flow and so > dropped packets ensue. > > This has created an implicit requirement on network architecture that > all packets of a flow need to follow the same path. From a host > perspective there are good reasons to change the flow label, for > instance we can modulate the the flow label for a failing connection > as a form of source routing to try for a better route through the > network. However, from a practical perspective I suppose the > recommendation should be that by default the flow label should be > constant for the lifetime of the flow. 6437 says Once set to a non-zero value, the Flow Label is expected to be delivered unchanged to the destination node(s). A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1. Disgusting get out of jail-free card not-withstanding that's unequivical. If It changes I cannnot use it for hashing in my load balancer function. > Tom > From nobody Wed Nov 8 11:10:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF149129B4D for ; Wed, 8 Nov 2017 11:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJUQIZ2FR_jA for ; Wed, 8 Nov 2017 11:10:27 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0112.outbound.protection.outlook.com [104.47.1.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E5D129AD8 for ; Wed, 8 Nov 2017 11:10:26 -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=5RsTKMXv3DVl8LqloYzBw0koLUSPSQVVkpd3/0Hjgf0=; b=b962MCSAhbvwQJqlMZi4z66z6Xgox1ti3em4IYdeQh6K/Ks7XQqmA1YqHfWEh8qilv4pXEzX8WnZEDUlPbMUJNvCNff55vxYHgMFov8ChA5/Jcg+CtEfy75XH3UslNkUguxvQdnEkXmZUOMP6qBb/1i/iRWQw7njPrt8WCHW74w= Received: from HE1PR0701MB2843.eurprd07.prod.outlook.com (10.168.91.145) by HE1PR0701MB2842.eurprd07.prod.outlook.com (10.168.91.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.6; Wed, 8 Nov 2017 19:10:24 +0000 Received: from HE1PR0701MB2843.eurprd07.prod.outlook.com ([fe80::7412:82cf:e4d1:dc2f]) by HE1PR0701MB2843.eurprd07.prod.outlook.com ([fe80::7412:82cf:e4d1:dc2f%17]) with mapi id 15.20.0218.005; Wed, 8 Nov 2017 19:10:24 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: joel jaeggli , Tom Herbert CC: Xuxiaohu , "v6ops@ietf.org" Thread-Topic: =?utf-8?B?W3Y2b3BzXSDnrZTlpI06IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?B?Zm9yIGRyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1tYXJr?= =?utf-8?Q?-01.txt?= Thread-Index: AQHTWKz4UIpTFO1YbUifgQUrDN0NQaMKu84AgAAOTYCAAADA8A== Date: Wed, 8 Nov 2017 19:10:24 +0000 Message-ID: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> <008938C4-0861-4BF1-A265-6EE323742B19@nokia.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE30477C89@NKGEML515-MBS.china.huawei.com> <199d8e92-a307-161b-175d-c1a762a0bef1@bogus.com> <3caffe52-7ace-8871-2585-bdb02a69ad56@bogus.com> In-Reply-To: <3caffe52-7ace-8871-2585-bdb02a69ad56@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [81.242.22.169] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0701MB2842; 6:VM6wDBU1uyFgVzuM8rLcxTcWzR7UOwrsJdLhptRwKHFu4IqCBM3vXhP6ByrFJW6CUVUlxqtS6c7brlvpMu6SDKG874pcGq/bf9VFGt5lN6RvTtV6DAMFlSE+v+iWHlbOXGTGHxlI1svfeLjCAAnml9WeQqMgfYT4l0xLFZ20Lw8E2at7u7hy308TF0PbJTaPXLcSuJtIKvqc0Z6d3C/w1lInw/CmomkFFdk2dGzUKJJ+Pp542jaWA9FI/js9PK37XgRK839byqOwsLENYAb9hR7LaGjFxYWI3Zep8B+/7Lc4Fq/zN/MBKYmMR+5+A2/EPromjXOY6Oj/2I3dGkb4jVvkoTttT8J+2Xl02asfHAU=; 5:XQkOMXhtOvOhmVPJYsNQYRy3hY9koZKwrfvkjiiTTehgonBxS2ecE5evP0xqTLU2NRSQR2FOrRaeAR4BA+NxU+zuc78S3VuqV/EfHyaSlxv23KC7m0TfZ4KDCJCWps/nAjZb7vJpgEmCvsbXpBb1oCdbq9TbJtc+JaPh9efGYMk=; 24:UQ7P943WfGbdthk1BDJRbd/8oKzUZgZ9J7l5+KnvZlp2N8j2fBD3aywzN9UqpaCQ21QeV2XyYrkCAsUkBP24pFX6Of3niB5ruGxP+R+d5E4=; 7:bsa340M0jBa6tyU8F9LQ93S7ynd/KGbntV1+58Xb0ysu37DTRh8F82mrzQqprLlWsIJfq//6mr2Xd4Sx5MrHEk27f8APsQdOcmLxjbgT4tUldP6Y0KTNhfjflZ0g1mKVy1DSoXvJg7ETQ86pK9KpjuBugfYiDISEDv0R7y1kF1zzLslqEcgRZim4owIvfSep5D46UzD5SP9RBcptEsoBDKkE+ugzEmyZbVvod31MLTNVvJyxsR3jdkfYHqbdHlKO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 21d168d4-c7f6-4dbd-4656-08d526dc5d55 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:HE1PR0701MB2842; x-ms-traffictypediagnostic: HE1PR0701MB2842: x-exchange-antispam-report-test: UriScan:(192374486261705)(50582790962513)(82608151540597)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(3231021)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB2842; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB2842; x-forefront-prvs: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(13464003)(189002)(199003)(24454002)(5250100002)(230783001)(7736002)(68736007)(53546010)(2900100001)(305945005)(99286004)(25786009)(93886005)(6436002)(7696004)(316002)(5660300001)(54906003)(4326008)(97736004)(110136005)(2950100002)(86362001)(229853002)(6506006)(3846002)(2906002)(189998001)(9686003)(76176999)(478600001)(81156014)(81166006)(54356999)(50986999)(3660700001)(33656002)(3280700002)(8936002)(106356001)(53936002)(74316002)(55016002)(6116002)(14454004)(561944003)(102836003)(101416001)(105586002)(66066001)(15650500001)(6246003)(224303003); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2842; H:HE1PR0701MB2843.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21d168d4-c7f6-4dbd-4656-08d526dc5d55 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 19:10:24.1760 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2842 Archived-At: Subject: Re: [v6ops] =?utf-8?b?562U5aSNOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0?= =?utf-8?q?ion_for_draft-fioccola-spring-flow-label-alt-mark-01=2Etxt?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 19:10:30 -0000 V2hpbGUgYW4gaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiwgaXQgaGFzIGxpdHRsZSB0byBkbyB3aXRo IHRoZSBjdXJyZW50IHByb3Bvc2FsIGFuZCB1c2UtY2FzZSBzY2VuYXJpby4NClRoZSBzb2x1dGlv biBpcyBub3QgdXNlZCBvbiB0aGUgSW50ZXJuZXQsIGJ1dCBpbiBhIDEwMCUgb3BlcmF0b3IgY29u dHJvbGxlZCBlbnZpcm9ubWVudC4NCg0KSW4gdGhlIGN1cnJlbnQgcHJvcG9zYWwgdGhlcmUgaXMg bm8gbWlkZGxld2FyZSBmaWRkbGluZyBlbi1yb3V0ZSB3aXRoIHRoZSBvcmlnaW5hbCBmbG93LWxh YmVsIGF0IGFsbC4gDQpUaGUgb3JpZ2luYWwgcGFja2V0IGZsb3ctbGFiZWwgcmVtYWlucyB1bmNo YW5nZWQgYW5kIGlzIGNhcnJpZWQgSU5TSURFIHRoZSB0dW5uZWwgYXMgbm9ybWFsIHR1bm5lbCBw YXlsb2FkLg0KDQpLZWVwIGluIG1pbmQgdGhhdCB0aGUgb3BlcmF0b3IgaXMgdGhlIGJpZyBib3Nz IGluc2lkZSB0aGUgbmV0d29yayBpdCBjb250cm9scy4gVGhlIG9wZXJhdG9yIGtub3dzIGhvdyB0 aGUgbmV0d29yayBsb29rcyBsaWtlLiBUaGUgb3BlcmF0b3Iga25vd3MgaG93IHRvIG9yY2hlc3Ry YXRlIGFuZCBjb25zdW1lIHRoZSBhdmFpbGFibGUgYmFuZHdpZHRoLiBUaGUgb3BlcmF0b3Iga25v d3MgaG93IGFsbCB0cmFmZmljIG11c3QgZmxvdyB3aXRoaW4gaXRzIG5ldHdvcmsuIFRoZSBvcGVy YXRvciBjYW4gYXJjaGl0ZWN0IHRocm91Z2ggSVB2NiBzZWdtZW50IHJvdXRpbmcgdG8gYXZvaWQg Y2VydGFpbiBGaXJld2FsbHMgb3IgTG9hZC1iYWxhbmNlcnMgb3Igb3RoZXIgbWlkZGxld2FyZSBp ZiBwYXJ0aWN1bGFyIG1pZGRsZXdhcmUgZG9lcyBub3Qgc3VwcG9ydCByZXF1aXJlZCBmZWF0dXJl cy4gVGhlIG9wZXJhdG9yIGlzIHRoZSBzaW5nbGUgYXV0aG9yaXR5IHdpdGhpbiB0aGUgbmV0d29y ay4gSXQgaXMgbm90IHRoZSByb2xlIG9mIElFVEYgdG8gZGljdGF0ZSBmdW5jdGlvbmFsaXR5IGFu IG9wZXJhdG9yIHdhbnRzIHRvIHVzZSBvciBub3QgdXNlLiANCg0KVGhhdCBiZWluZyBzYWlkLCBp dCBpcyBmb3Igc29tZSBvcGVyYXRvcnMgcGVyZmVjdGx5IGZpbmUgdG8gbGl2ZSB3aXRoIGVudHJv cHkgZ2VuZXJhdGVkIGJ5IDE4IGJpdHMsIGluc3RlYWQgb2YgMjAgYml0cywgDQpBc3N1bWluZyBp dCBwcm92aWRlcyBhZHZhbmNlZCBtZWFzdXJlbWVudCBjYXBhYmlsaXRpZXMgYW5kIGRvZXMgbm90 IGJyZWFrIGFueSBSRkNzLiBJdCBpcyBmb3Igcm91dGVycyBhIHJlYXNvbmFibGUgc29sdXRpb24g dG8gZ2VuZXJhdGUgZW50cm9weSBiYXNlZCB1cG9uIDE4IGJpdHMgaW5zdGVhZCBvZiBvbiAyMCBm bG93LWxhYmVsIGJpdHMuIA0KDQpHLw0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGpvZWwgamFlZ2dsaSBbbWFpbHRvOmpvZWxqYUBib2d1cy5jb21dIA0KU2Vu dDogV2VkbmVzZGF5LCBOb3ZlbWJlciA4LCAyMDE3IDE5OjE3DQpUbzogVG9tIEhlcmJlcnQgPHRv bUBoZXJiZXJ0bGFuZC5jb20+DQpDYzogWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+OyB2 Nm9wc0BpZXRmLm9yZzsgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkg PGd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tPg0KU3ViamVjdDogUmU6IFt2Nm9wc10g562U 5aSNOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1maW9jY29sYS1zcHJp bmctZmxvdy1sYWJlbC1hbHQtbWFyay0wMS50eHQNCg0KT24gMTEvOC8xNyAwOToyNSwgVG9tIEhl cmJlcnQgd3JvdGU6DQo+IE9uIFdlZCwgTm92IDgsIDIwMTcgYXQgODoxNiBBTSwgam9lbCBqYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPiB3cm90ZToNCj4+IE9uIDExLzgvMTcgMDc6MzMsIFRvbSBI ZXJiZXJ0IHdyb3RlOg0KPj4+IE9uIFR1ZSwgTm92IDcsIDIwMTcgYXQgMTE6NTcgUE0sIFh1eGlh b2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4+Pj4NCj4+Pj4NCj4+Pj4+IC0tLS0t 6YKu5Lu25Y6f5Lu2LS0tLS0NCj4+Pj4+IOWPkeS7tuS6ujogdjZvcHMgW21haWx0bzp2Nm9wcy1i b3VuY2VzQGlldGYub3JnXSDku6PooaggVmFuIERlIFZlbGRlLCBHdW50ZXIgDQo+Pj4+PiAoTm9r aWEgLSBCRS9BbnR3ZXJwKQ0KPj4+Pj4g5Y+R6YCB5pe26Ze0OiAyMDE35bm0MTHmnIg45pelIDQ6 MzcNCj4+Pj4+IOaUtuS7tuS6ujogVG9tIEhlcmJlcnQNCj4+Pj4+IOaKhOmAgTogdjZvcHNAaWV0 Zi5vcmcNCj4+Pj4+IOS4u+mimDogUmU6IFt2Nm9wc10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgDQo+Pj4+PiBkcmFmdC1maW9jY29sYS1zcHJpbmctZmxvdy1sYWJlbC1hbHQtbWFy ay0wMS50eHQNCj4+Pj4+DQo+Pj4+PiBJbiB0aGlzIGNhc2UsIHRoZSBjb250cm9sbGVkIGRvbWFp biByZWZsZWN0cyB0byB0aGUgZmFjdCB0aGF0IGl0IA0KPj4+Pj4gaXMgb3BlcmF0b3IgY2hvaWNl IHRoYXQgZ3JhYnMgY29udHJvbCBvZiBwYWNrZXQgaGFuZGxpbmcgd2l0aGluIGl0cyBvd24gbmV0 d29yay4NCj4+Pj4+IFRoZSBvcGVyYXRvciBhZGRzIHRocm91Z2ggcG9saWN5IHRoZSBvdXRlciBT UnY2IGhlYWRlci4gVGhlIA0KPj4+Pj4gb3BlcmF0b3IgaGFzIGluIGZhY3QgdGhlbiB0aHJlZSBv cHRpb25zIHJlZ2FyZGluZyBmbG93IGxhYmVsOg0KPj4+Pj4NCj4+Pj4+IDEpIEp1c3QgZG8gbm90 IGRvIGFueXRoaW5nIHdpdGggRmxvdy1sYWJlbCAobGVhdmUgaXQgZGVmYXVsdCkNCj4+Pj4+IDIp IEFsdGVybmF0ZSBtYXJraW5nIG9ubHkgYW5kIE5PIHVzYWdlIG9mIGVudHJvcHkNCj4+Pj4+IDMp IEFsdGVybmF0ZSBtYXJraW5nIGFuZCBlbnRyb3B5IChpbiB0aGlzIGNhc2UgdGhlIGVudHJvcHkg U0hPVUxEIA0KPj4+Pj4gYmUgYmFzZWQgdXBvbiAxOCBiaXRzIGluc3RlYWQgb2YgMjAgYml0cyBi ZWNhdXNlIG90aGVyd2lzZSBwYXRocyANCj4+Pj4+IG1heSBiZSBjaGFuZ2VkIHdoZW4gdGhlIG1h cmtpbmcgY2hhbmdlcyAoZS5nLiBwZXJpb2RzIG9mIDUgbWludXRlcyANCj4+Pj4+IHBlciBtYXJr aW5nIHBlcmlvZCkg4oCmLiBUaGlzIGlzIGhvd2V2ZXIgbm90IGEgTVVTVCBiZWNhdXNlIHNvbWUg DQo+Pj4+PiBvcGVyYXRvcnMgZG8gbm90IGNhcmUgaWYgYmVjYXVzZSBvZiBtYXJraW5nIGNoYW5n ZS4NCj4+Pj4NCj4+Pj4gSW4gb3B0aW9uIDMsIGl0IHdvdWxkIHJlcXVpcmUgYSBmZXcgY2hhbmdl cyB0byB0aGUgUkZDNjQzNy1jb21wYXRpYmxlIGJlaGF2aW9ycyBvZiBpbnRlcm1lZGlhdGUgcm91 dGVycyB3aXRoaW4gYSBjb250cm9sbGVkIG5ldHdvcmsgZG9tYWluLiBIZW5jZSBpdCBzZWVtcyBi ZXR0ZXIgYW5kIHNhZmVyIHRvIGRpc2FibGUgdGhlIEZMLWJhc2VkIGxvYWQtYmFsYW5jaW5nIG1l Y2hhbmlzbSBpbiB0aGlzIHNwZWNpYWwgY2FzZSwgZXNwZWNpYWxseSB3aGVuIHRoZSBleGlzdGlu ZyBsb2FkLWJhbGFuY2luZyBtZWNoYW5pc20gKGUuZy4sIGZpdmUtdHVwbGUtYmFzZWQgTEIpIGlz IGdvb2QgZW5vdWdoLCBJTUhPLg0KPj4+Pg0KPj4+IEZpdmUtdHVwbGUgaGFzaCByZXF1aXJlcyBw YXJzaW5nIGludG8gdGhlIHRyYW5zcG9ydCBsYXllciB0byBnZXQgdGhlIA0KPj4+IHBvcnRzLiBJ biB0aGUgcHJvcG9zZWQgdXNlIGNhc2UgdGhlcmUgd2lsbCBiZSBleHRlbnNpb24gaGVhZGVycyAo YXQgDQo+Pj4gbGVhc3QgYSByb3V0aW5nIGhlYWRlcikgc28gcm91dGVycyB3b3VsZCBuZWVkIHRv IHBhcnNlIG92ZXIgdGhvc2UuDQo+Pj4gSXQncyB1bmxpa2VseSB0aGF0IHN1Y2ggcGFyc2luZyBp cyBjb25zaXN0ZW50bHkgaW1wbGVtZW50ZWQgYW5kIA0KPj4+IGJlc2lkZXMgdGhhdCB0aGUgd2hv bGUgcG9pbnQgb2YgdXNpbmcgdGhlIGZsb3cgbGFiZWwgZm9yIEVDTVAgaXMgdG8gDQo+Pj4gb2J2 aWF0ZSB0aGUgbmVlZCBmb3Igcm91dGVycyB0byBwZXJmb3JtIERQSS4NCj4+DQo+PiBUaGUgZmxv dyBsYWJlbCBpcyB1bnByb3RlY3RlZCBpbiB0aGUgaGVhZGVyIHdoaWNoIG1ha2VzIGl0IGhhcmQg dG8gDQo+PiB1c2UgdG8gaGFzaCB0byBzdGF0ZWZ1bCBlbmRwb2ludHMuIGl0IHdvdWxkIGJlIGhl bHBmdWwgaWYgbm90aG5nIGV2ZXIgDQo+PiBjaGFuZ2VkIGl0IG9yIGRpZCBzbyBjb25zaXN0ZW50 bHkgYnV0IGluIGZhY3QgZGV2aWNlcyB0aGF0IGRvIHNvIGV4aXN0Lg0KPj4NCj4gSm9lbCwNCj4g DQo+IFRoZSBwcm9ibGVtIGlzbid0IGF0IHN0YXRlZnVsIGVuZHBvaW50cywgaXQncyB3aXRoIG1p ZGRsZWJveGVzIHRoYXQgDQo+IG1haW50YWluIGZsb3cgc3RhdGUuIFRoZSByZXN1bHQgb2YgYSBm bG93IGxhYmVsIGNoYW5nZSBhdCBhbiBlbmRwb2ludCANCj4gaXMgT09PIHBhY2tldHMgd2hpY2gg YW55IHRyYW5zcG9ydCBwcm90b2NvbCBpcyBleHBlY3RlZCB0byBncmFjZWZ1bGx5IA0KPiBoYW5k bGUuIEEgbWlkZGxlYm94IHRoYXQgbWFpbnRhaW5zIHN0YXRlIGV4cGVjdHMgYWxsIHBhY2tldHMg b2YgdGhlIA0KPiBmbG93IHRvIGdvdCB0aHJvdWdoIGl0LCBzbyBpZiB0aGVyZSBpcyBhIGZsb3cg bGFiZWwgY2hhbmdlIChvciBvdGhlciANCj4gcm91dGluZyBjaGFuZ2UpIHBhY2tldHMgZm9yIHRo ZSBmbG93IG1heSBieXBhc3MgdGhlIGRldmljZSAobGlrZSBhIA0KPiBmaXJld2FsbCBvciBOQVQp IHdpdGggdGhlIGZsb3cgc3RhdGUuIEl0J3MgbGlrZWx5IHRoZXkncmUgZm9yd2FyZGVkIA0KPiB0 aHJvdWdoIGEgcGVlciBkZXZpY2UgdGhhdCBkb2Vzbid0IGhhdmUgYW55IHN0YXRlIGZvciB0aGUg ZmxvdyBhbmQgc28gDQo+IGRyb3BwZWQgcGFja2V0cyBlbnN1ZS4NCj4gDQo+IFRoaXMgaGFzIGNy ZWF0ZWQgYW4gaW1wbGljaXQgcmVxdWlyZW1lbnQgb24gbmV0d29yayBhcmNoaXRlY3R1cmUgdGhh dCANCj4gYWxsIHBhY2tldHMgb2YgYSBmbG93IG5lZWQgdG8gZm9sbG93IHRoZSBzYW1lIHBhdGgu IEZyb20gYSBob3N0IA0KPiBwZXJzcGVjdGl2ZSB0aGVyZSBhcmUgZ29vZCByZWFzb25zIHRvIGNo YW5nZSB0aGUgZmxvdyBsYWJlbCwgZm9yIA0KPiBpbnN0YW5jZSB3ZSBjYW4gbW9kdWxhdGUgdGhl IHRoZSBmbG93IGxhYmVsIGZvciBhIGZhaWxpbmcgY29ubmVjdGlvbiANCj4gYXMgYSBmb3JtIG9m IHNvdXJjZSByb3V0aW5nIHRvIHRyeSBmb3IgYSBiZXR0ZXIgcm91dGUgdGhyb3VnaCB0aGUgDQo+ IG5ldHdvcmsuIEhvd2V2ZXIsIGZyb20gYSBwcmFjdGljYWwgcGVyc3BlY3RpdmUgSSBzdXBwb3Nl IHRoZSANCj4gcmVjb21tZW5kYXRpb24gc2hvdWxkIGJlIHRoYXQgYnkgZGVmYXVsdCB0aGUgZmxv dyBsYWJlbCBzaG91bGQgYmUgDQo+IGNvbnN0YW50IGZvciB0aGUgbGlmZXRpbWUgb2YgdGhlIGZs b3cuDQoNCjY0Mzcgc2F5cw0KDQogICBPbmNlIHNldCB0byBhIG5vbi16ZXJvIHZhbHVlLCB0aGUg RmxvdyBMYWJlbCBpcyBleHBlY3RlZCB0byBiZQ0KICAgZGVsaXZlcmVkIHVuY2hhbmdlZCB0byB0 aGUgZGVzdGluYXRpb24gbm9kZShzKS4gIEEgZm9yd2FyZGluZyBub2RlDQogICBNVVNUIGVpdGhl ciBsZWF2ZSBhIG5vbi16ZXJvIGZsb3cgbGFiZWwgdmFsdWUgdW5jaGFuZ2VkIG9yIGNoYW5nZSBp dA0KICAgb25seSBmb3IgY29tcGVsbGluZyBvcGVyYXRpb25hbCBzZWN1cml0eSByZWFzb25zIGFz IGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiA2LjEuDQoNCkRpc2d1c3RpbmcgZ2V0IG91dCBvZiBq YWlsLWZyZWUgY2FyZCBub3Qtd2l0aHN0YW5kaW5nIHRoYXQncyB1bmVxdWl2aWNhbC4gSWYgSXQg Y2hhbmdlcyBJIGNhbm5ub3QgdXNlIGl0IGZvciBoYXNoaW5nIGluIG15IGxvYWQgYmFsYW5jZXIg ZnVuY3Rpb24uDQoNCj4gVG9tDQo+IA0KDQo= From nobody Wed Nov 8 11:30:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39206129B59 for ; Wed, 8 Nov 2017 11:30:50 -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 DGB2TFHWcnNG for ; Wed, 8 Nov 2017 11:30:45 -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 26F0D129B57 for ; Wed, 8 Nov 2017 11:30:44 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id A922C411A3 for ; Wed, 8 Nov 2017 20:30:42 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 99F01411A0; Wed, 8 Nov 2017 20:30:42 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 8BE406E1A0; Wed, 8 Nov 2017 20:30:42 +0100 (CET) Date: Wed, 8 Nov 2017 20:30:42 +0100 From: Gert Doering To: Philip Homburg Cc: v6ops@ietf.org Message-ID: <20171108193042.GQ45648@Space.Net> References: <20171107200021.GX45648@Space.Net> <5A02DCF8.5060903@foobar.org> <20171108132532.GJ45648@Space.Net> <20171108135916.GK45648@Space.Net> <5A031A1E.3070405@foobar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-p2p-from-customer-prefix-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 19:30:54 -0000 Hi, On Wed, Nov 08, 2017 at 03:58:21PM +0100, Philip Homburg wrote: > But I guess it is bit too late to propose that we dump the whole mess and > go back to ARP and DHCP. Propose, we can... succeed, unlikely. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Nov 8 11:35:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FB6129B70 for ; Wed, 8 Nov 2017 11:35:18 -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 2c49cwPPjhlF for ; Wed, 8 Nov 2017 11:35:16 -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 7755B129B71 for ; Wed, 8 Nov 2017 11:35:16 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id b79so2455182pfk.5 for ; Wed, 08 Nov 2017 11:35:16 -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=oSDYnEOoC11G30KOzTv2o2e9itywI4UcqysIA3Y7S+o=; b=k0BmEA0el3PIR9SPKtQ1r2K0JnzJD8shpgSXX3xBQl8R78La9dytleIAVCkmcNLXZt HvlZZv5wrrw8ZtENJPx6eB54nHSqUVAvYov0dEdwpw6Jyj1NCwrKXhhVzArmIECeJ8CM MJUOrMhT9vWQVMb0GqYyQQj8kcM02zaTS+M/tEoRYYNFUk29bsUeQEo5V+JjH2si2TyG 9H74TKSmtt51cOtbDqmoQVmlxMn4w6+ZjLSJS/kn6LqcULaMoeGLU4xD3U5MMTPoinuD pECg/0JFeu9xjPVnwcsnrDDW4bQNoraSjpJJMOrUECT5PusN2zcJj/mIws6+NtFOx9Ix 4Jvg== 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=oSDYnEOoC11G30KOzTv2o2e9itywI4UcqysIA3Y7S+o=; b=G/aD8063lbTQjPjILSkOtrIdFzu6TQnKc5K84b0oqlpst+OZ3Jp+uq64YGhLyY6Mos KZNCPiMDrDemHpSpQR+8WTSCkb5SDXy6WpO0BKEUNq6rLPsParcSkcZsgZp7ba1eCanr AfY4QEG6Z0ggTtNI14wSnNc6YvbMokemgm/6calQZIcLlEmOKRWtjVdTtW6YLkjrKIQz aULGyB8sm1WtbaljcQ/wT5I+6m2WiQKP/KDAUisZbTtOm96Kme7y+oltKN49ipIdJa4S 5GBZSEtfTMwMCIQTGL86w+tqY0ef3SMcH6dAHAh+kvCz8FtTFRt/f7ZJv5MxiLUbl19e pCcg== X-Gm-Message-State: AJaThX5jg14EEb53pkc2lYjFZINvvzDi2Wm6ntwgPTcWWCBMqszJpPON CGTbUeloM1ek5iRgeM3M9BjYkg== X-Google-Smtp-Source: ABhQp+ROFa3B5wNdisjP4dPrZfwwzu3THE9mjMSCBi/17NpkwSlgKWJue7vp1/t4cvJQFIHXiNf18g== X-Received: by 10.84.233.8 with SMTP id j8mr1401699plk.311.1510169715585; Wed, 08 Nov 2017 11:35:15 -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 b10sm10231835pfk.20.2017.11.08.11.35.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 11:35:14 -0800 (PST) To: v6ops@ietf.org References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> <008938C4-0861-4BF1-A265-6EE323742B19@nokia.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE30477C89@NKGEML515-MBS.china.huawei.com> <199d8e92-a307-161b-175d-c1a762a0bef1@bogus.com> <3caffe52-7ace-8871-2585-bdb02a69ad56@bogus.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 9 Nov 2017 08:35:17 +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: <3caffe52-7ace-8871-2585-bdb02a69ad56@bogus.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?b?562U5aSNOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0?= =?utf-8?q?ion_for_draft-fioccola-spring-flow-label-alt-mark-01=2Etxt?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 19:35:18 -0000 On 09/11/2017 07:16, joel jaeggli wrote: > On 11/8/17 09:25, Tom Herbert wrote: >> On Wed, Nov 8, 2017 at 8:16 AM, joel jaeggli wrote:= >>> On 11/8/17 07:33, Tom Herbert wrote: >>>> On Tue, Nov 7, 2017 at 11:57 PM, Xuxiaohu wrot= e: >>>>> >>>>> >>>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: v6ops [mailto:v6ops-bounces@ietf.org]= =E4=BB=A3=E8=A1=A8 Van De Velde, Gunter >>>>>> (Nokia - BE/Antwerp) >>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2017=E5=B9=B411=E6=9C=888=E6= =97=A5 4:37 >>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Tom Herbert >>>>>> =E6=8A=84=E9=80=81: v6ops@ietf.org >>>>>> =E4=B8=BB=E9=A2=98: Re: [v6ops] FW: New Version Notification for >>>>>> draft-fioccola-spring-flow-label-alt-mark-01.txt >>>>>> >>>>>> In this case, the controlled domain reflects to the fact that it i= s operator choice >>>>>> that grabs control of packet handling within its own network. >>>>>> The operator adds through policy the outer SRv6 header. The operat= or has in >>>>>> fact then three options regarding flow label: >>>>>> >>>>>> 1) Just do not do anything with Flow-label (leave it default) >>>>>> 2) Alternate marking only and NO usage of entropy >>>>>> 3) Alternate marking and entropy (in this case the entropy SHOULD = be based >>>>>> upon 18 bits instead of 20 bits because otherwise paths may be cha= nged when >>>>>> the marking changes (e.g. periods of 5 minutes per marking period)= =E2=80=A6. This is >>>>>> however not a MUST because some operators do not care if because o= f marking >>>>>> change. >>>>> >>>>> In option 3, it would require a few changes to the RFC6437-compatib= le behaviors of intermediate routers within a controlled network domain. = Hence it seems better and safer to disable the FL-based load-balancing me= chanism in this special case, especially when the existing load-balancing= mechanism (e.g., five-tuple-based LB) is good enough, IMHO. >>>>> >>>> Five-tuple hash requires parsing into the transport layer to get the= >>>> ports. In the proposed use case there will be extension headers (at >>>> least a routing header) so routers would need to parse over those. >>>> It's unlikely that such parsing is consistently implemented and >>>> besides that the whole point of using the flow label for ECMP is to >>>> obviate the need for routers to perform DPI. >>> >>> The flow label is unprotected in the header which makes it hard to us= e >>> to hash to stateful endpoints. it would be helpful if nothng ever >>> changed it or did so consistently but in fact devices that do so exis= t. >>> >> Joel, >> >> The problem isn't at stateful endpoints, it's with middleboxes that >> maintain flow state. The result of a flow label change at an endpoint >> is OOO packets which any transport protocol is expected to gracefully >> handle. A middlebox that maintains state expects all packets of the >> flow to got through it, so if there is a flow label change (or other >> routing change) packets for the flow may bypass the device (like a >> firewall or NAT) with the flow state. It's likely they're forwarded >> through a peer device that doesn't have any state for the flow and so >> dropped packets ensue. >> >> This has created an implicit requirement on network architecture that >> all packets of a flow need to follow the same path. From a host >> perspective there are good reasons to change the flow label, for >> instance we can modulate the the flow label for a failing connection >> as a form of source routing to try for a better route through the >> network. However, from a practical perspective I suppose the >> recommendation should be that by default the flow label should be >> constant for the lifetime of the flow. >=20 > 6437 says >=20 > Once set to a non-zero value, the Flow Label is expected to be > delivered unchanged to the destination node(s). A forwarding node > MUST either leave a non-zero flow label value unchanged or change it= > only for compelling operational security reasons as described in > Section 6.1. >=20 > Disgusting get out of jail-free card not-withstanding that's > unequivical. If It changes I cannnot use it for hashing in my load > balancer function. Sure. But if a local domain chooses to restrict itself to hashing 18 bits that's its privilege; we don't specify the hash algorithm. And if the packet is forwarded outside the local domain, the other two bits need to be set to consistent values for use on the outside. I think the draft meets those conditions. Brian From nobody Wed Nov 8 16:16:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 18:58:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B4C129B16 for ; Wed, 8 Nov 2017 18:58:39 -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 QtK4qEGN_HCq for ; Wed, 8 Nov 2017 18:58:37 -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 97CE7129AA8 for ; Wed, 8 Nov 2017 18:58:34 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id 72so9445931itl.5 for ; 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=psvKmrqlru5W5tHPE0dVSdZpiLDt6ltCHmMQ+QzAs0i8ucy0PExax4ZyGchLnTUNm7 n/YGBAdfewv4g8cI0ONdDe9GFpARA0SzDkDc5zTi2zfL8AJXF1m4Zz7OIMxy56fuLFrn zS2SFZK55kFLs0AuKvCb2rpy7zzLYm7dWLu281D+9JNybrJzlZkC9T6iwyME1Q+XBKdO nzv2BMTenMtcv4NziUSei1BZ7rOLYUZR3twcHi8o/YijLyVBAnNWX93BRMbgo1cR4JAG bTn6KACUFiNdXqxvZt+jcbyPVU4p98IXBfKjab2AZ5cwqvqddmU0m7gYfu6yBDCJYMbY XEdg== X-Gm-Message-State: AJaThX4BS0elgU5NoIz8nXj04kea69d9lTh9L+6sv51auhe+nqdG+4mx sBQH/CgzrdEncnT+nM92ioHqCAZoM9+KpdjyNWe0zw== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 02:58:39 -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:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CF4120713 for ; Wed, 8 Nov 2017 19:03:12 -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 WSCHSg50yVnO for ; Wed, 8 Nov 2017 19:03:11 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 1DB4F129467 for ; Wed, 8 Nov 2017 19:03:08 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id t11so4123304ywg.12 for ; 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=j//aY5/Er09DGSMKp66CHnK18tSRxpJCZh0z1sR/8+A=; b=gunb3gmREMuHQW/9WPS/8M3bWfFc4Wtym+iVVfI2EZFh7vFk4y9jVGwfhx7PCtrriB 2uheCoWLu+jnBZl/zTU1ul6MDj+UqK8vbs699xl8QLin3Ce0pj446MQutj7TaoD4lLFC TxQYDXtsdNMI4YvMJTDOP91sw7oRWMCiZYc1qKoKTjr1FihUiD9cQEf/dMfVlNvXF10P QNKyu7yf72Kt3MB1sYZ3FK7+HMNAJMo499P3XeSY8oWdEjNPe5OB8Nim1R+K48XhP5ne goaXJPGmnMS0ehSOIDLijGByRS0NgYzQeSl6P+wABUeYlsBIE77D04M+umYQ0Yo2dBQW ypxw== 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=j//aY5/Er09DGSMKp66CHnK18tSRxpJCZh0z1sR/8+A=; b=Vbld+IxcOjNZm7OT/7m1wNJl3ZLpbWtA92Naqt1HQCrVncSi4Je8HEW8C0NZmEvl1p 84nUmWKUhj+oFsuU1DxmNWZsxmO8NI4Dgps7iPF2VRTdIJp+enm5bixVVvRSn11yWN2g 2QXjrEzJJv7qEH/J0k5Xur+ZVnBwbXIeY9PdsrBtlInQ/umCD43PKlrViI9ubgQMRbx5 Gwhv13feZKa3W93HHJm72fC4uXMNl+i0cUPwlrMXSKkqafy2dgPB9cZLW/7SmXNHmS++ qjSYhkzWuhaplepKzC4QCzKhaNsK270SKzfizNTZHjUCbpk/XMtEdYlJ/uoFRUVTEWdo DmMg== X-Gm-Message-State: AJaThX4fZrCItKWJkPaG/o3+94Vj6cbQB8XuGgaSVaPDw7K5MseH/WVU H63qrLv0HdjTuu5k1fmIomE9OBJUScBTERxdBgeWdg== 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: 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="001a1149152c24efee055d840b3a" Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 03:03:12 -0000 --001a1149152c24efee055d840b3a 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). --001a1149152c24efee055d840b3a 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= --001a1149152c24efee055d840b3a-- From nobody Thu Nov 9 09:35:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:56:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB905126DFE for ; Thu, 9 Nov 2017 10:56:39 -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 fZCgScAgdmv4 for ; Thu, 9 Nov 2017 10:56:37 -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 82BF4126B6D for ; Thu, 9 Nov 2017 10:56:37 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id r68so19799710wmr.3 for ; Thu, 09 Nov 2017 10:56:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=KmhmrtDit8qBeZ3KdZX1QCfkl0NjxCq8To/ATTCGZmQ=; b=ejZ/jbBlipQdhc9Hs/3cpezod6VXUp1vy4wAIHy+3HREGAzVQGvg/g+QIOK86iIxkl gUOgSNyq8e9tSDY4RCp8yVZLur4SqfRogGDUHoiZ4tgNQvgpO7n41XSpwV0NoogMlbNv WqXaOLQwWPITAKj/WFWeLGsY5e1ipVFCMPaB588Wvdt9DejhYoG98UWTZlaOVUF9pAlq g63PizXbHJgFQs3y9uP+L7CNQm6i2dMlJ1OGUqRZQXz29UdeNztvwT/dtG0ZTxfVudz+ gYV281MmZH3vEaJXzCoKEzpQiC2Aj9HtzBtKKrtXCNi3PQ+2IwnpAJ2zdT7GCg4xY9L2 0Vkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=KmhmrtDit8qBeZ3KdZX1QCfkl0NjxCq8To/ATTCGZmQ=; b=giIoEf/Vk4J6Sm79D79bSqzlPiz8hFGXvytCMAm0ju59NjgGQz5wiu5Q3sElwtbYJs JQypOwp9GZQM7Ox8hYOWp/RyGl+uCsXgIlRNcoBTG9c2b1Vqk+D7xsvCoqCYhMZ4xVKp QR3wQRu2isYGs6jGZQZ1uIqd0UPg5PmF4CeMnGOKa+nTVTQDjpWvJrRbTaIs97MXB+eb Mq7ltp5QiJG2iahfta17ooTiHpYbaaw6d+n2cEgFtIHy0OK53grClfCQvTNzd0IQ79Y1 jmLw3TsCTUBff723GjyyfLDix5vBwcRfl8SiqTd2SFmK/xClygYzeVwcB+H6ozB5iM1u lVlQ== X-Gm-Message-State: AJaThX6S16ltPXYykig0FZa7Gg4IcREXlkxZIJxIYERgfOO4XGFF+vWX AC0jInyU0tq24K9g3+R6CLOEPtcz X-Google-Smtp-Source: AGs4zMaOytamwzgt+P+hxPorN0us1YhmUoR8dedzrq0F1cfWzr2Va7kJEhnZLc1y6yEZra7o+nOwww== X-Received: by 10.28.214.134 with SMTP id n128mr728092wmg.59.1510253795875; Thu, 09 Nov 2017 10:56:35 -0800 (PST) Received: from MacBook-Pro.local ([41.136.226.81]) by smtp.gmail.com with ESMTPSA id m8sm6299334wrg.55.2017.11.09.10.56.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 10:56:35 -0800 (PST) To: v6ops@ietf.org References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> From: Stephen Honlue Message-ID: <5ce59980-c2a7-346b-d495-5531fa205dcf@gmail.com> Date: Thu, 9 Nov 2017 18:56:33 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> Content-Type: multipart/alternative; boundary="------------B7514E0DFF726B140B71CCC9" Content-Language: en-US Archived-At: Subject: [v6ops] Why not use the L-flag?: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 18:56:40 -0000 This is a multi-part message in MIME format. --------------B7514E0DFF726B140B71CCC9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all, I went through the draft: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13 I noticed that the only valid intend of the draft is EU isolation, and I know this is achievable using the L-flag set to 0 as described inRFC 4861 Page 29. Assuming the WG is ok with this draft, what happens to the rest of say [(2^64) - 1] IPs at the host level, considering that the EU needs only one IP. Am I missing something? --- Musa --------------B7514E0DFF726B140B71CCC9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi all,

I went through the draft: https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13

I noticed that the only valid intend of the draft is EU isolation, and I know this is achievable using the L-flag set to 0 as described in RFC 4861 Page 29.

Assuming the WG is ok with this draft, what happens to the rest of say [(2^64) - 1] IPs at the host level, considering that the EU needs only one IP.

Am I missing something? 

---

Musa

--------------B7514E0DFF726B140B71CCC9-- From nobody Thu Nov 9 11:14:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31609129548 for ; Thu, 9 Nov 2017 11:14:20 -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 bdBTMD9QQD9C for ; Thu, 9 Nov 2017 11:14:19 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 C58221294F8 for ; Thu, 9 Nov 2017 11:14:18 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id q18so4139347uaa.0 for ; Thu, 09 Nov 2017 11:14:18 -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=nCyiLbRbULryk1gSMjAqC58TPYrKfcQEJoyFTBXTbLc=; b=foIkzXYicCPM75GizRcxxFRupFifLkzsSSlNAYYTELifWWoQiRzL5KrwYmqVUwVJ7V LgTKU3VCj3zg+IkCeVivX0w+ShtqDDrvqwsnCW9lZWPPrbHfpDxM4oqDw7ityzc7gApN 0UIkBseWmO0Rg5UnO/FngQz5kqWOr5aSv/Q0QRd3sKEiQ1mQI9hgluyOe4m0ttgFyI/5 4oUCiiqHOVNWZggJjh6jbPJomwvsW7LJDLJoOW+nQK7j3vwaYgNdkKZy7pM8fkvPxQa4 roo/Ny5z7bOosMCOZN3UzTUIP8HIpzcQ6fwKRwmx3pi07O5Gz5z7yVa9fIvUzByDlNTw IJoA== 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=nCyiLbRbULryk1gSMjAqC58TPYrKfcQEJoyFTBXTbLc=; b=NETrC4oYDHvsj2kYNvtGm9ewm8kkQ7/pZlQEgB2Z2MMaBBlvKDViy2p8QpPGfGIwSe ABML8Nysdgt9y7nXWdooxUCBrvnKHJW5Ktz10+fnYxcuCcMhFvN455Il/4dBWnNsqo0E 0B1nhzgqMC7poHU6f0CT5uXhj/Wb/p+vGOXVVigRBx692PD0u9sWVz0HadEnvLve52JU xktPefzrgU6oolI2JppfuEKz6jDYvY0DyXjFhHEWbu4OCoS+Qxlhcr5AzMP6KTtPqTLd PLvKSDIF9nBWkV0DovGyZGy+XbjMgGXq1HWQ0NhEksYlAMHT7o94JqkTN7Jt724t+Cj+ mTWg== X-Gm-Message-State: AJaThX7fLazVXNjXxa4PFFSVZFfl7L46LA0eVTGUiinT/3aCOohpvF1H /mqFvVJx6tyXAZCyXHqRW+lI+xH2yrh38hDSfMqN1Q== X-Google-Smtp-Source: AGs4zMZZHWYWbV6Qj+sqn9bgyFnQpxQ6W+JGeCu2tVQsArpN4x4OO6QUkK+DPC93R0ARuzw1HA5c1rj3D67M5sZFW3M= X-Received: by 10.176.74.15 with SMTP id q15mr1393356uae.120.1510254857711; Thu, 09 Nov 2017 11:14:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Thu, 9 Nov 2017 11:13:47 -0800 (PST) In-Reply-To: <5ce59980-c2a7-346b-d495-5531fa205dcf@gmail.com> References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> <5ce59980-c2a7-346b-d495-5531fa205dcf@gmail.com> From: Mark Smith Date: Fri, 10 Nov 2017 06:13:47 +1100 Message-ID: To: Stephen Honlue Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Why not use the L-flag?: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 19:14:20 -0000 On 10 November 2017 at 05:56, Stephen Honlue wrote: > Hi all, > > I went through the draft: > https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-13 > > I noticed that the only valid intend of the draft is EU isolation, and I > know this is achievable using the L-flag set to 0 as described in RFC 4861 > Page 29. > The host is given the whole prefix, so all of the addresses are present on the host itself. The L-bit is for the situation when a prefix is shared between a number of host on a link, and the host is being instructed on how to reach other addresses in the prefix - directly across a the link, or via a default router. > Assuming the WG is ok with this draft, what happens to the rest of say > [(2^64) - 1] IPs at the host level, considering that the EU needs only one > IP. > This is the fundamental thing about this. A host is being given many addresses (effectively as many as it wants), by giving it a whole prefix to use as it likes. This is "bulk" host address assignment rather than individual host address assignment. We think it is a good idea that hosts aren't constrained in terms of addresses as there is no need for them to be in IPv6. Fundamentally, if an IPv6 host can't get an address, then the fundamental goal of IPv6 - providing more addresses - hasn't been achieved. Here's the BCP making that recommendation: Host Address Availability Recommendations https://tools.ietf.org/html/rfc7934 Regards, Mark. > Am I missing something? > > --- > > Musa > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Nov 9 11:35:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556F5129A8F for ; Thu, 9 Nov 2017 11:34:58 -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 6v4solBIHIZh for ; Thu, 9 Nov 2017 11:34:55 -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 9271F129AD3 for ; Thu, 9 Nov 2017 11:34:55 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id t139so19999079wmt.1 for ; Thu, 09 Nov 2017 11:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=LdXIHdbJk3rXjBJp3ahsRTUGZNub7PlP9kz9Z+DuczI=; b=g9bK/kFKlg3YP79Mu7VpURoS7WwUirDtCEahk87qAs8HriTbTw1wt4IjARWtWE+qfs NdECY8SaKOX6nNrZBqkzbHfuFEPU/h5IoIECy/Yh213JUG1QM4nS22bkPLRGMCfNDZeg s8O/qH3DyPN3owLjr0wOncD6HgSswXOcEy6Qn/+GGKZD367uTL2s/YCVIMZO1EP6hBD8 iefcLoCN7LF6dH4NOx++t9PMmWYCxHv2n6XJDMoSsWcWItUgW6MTnC8S8uDbLTgufBIj 3W+pKlH9l0x5irJElnWvwZhY/LDMGZnhVEMssPus6INl6A7EG8vCYdTr1EOZkf9KAg1/ 3rsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=LdXIHdbJk3rXjBJp3ahsRTUGZNub7PlP9kz9Z+DuczI=; b=APq6vBxbkzo63Czw0lH2I0WrtsJVAzXu/odmZOhvOlt5tCwlpnNyeGyQPaEjT3H9nX An63888E3Uo3JhPwTh3cAN1e/TIlhccSc24HCxbiU+4nh2i3Bo1I60HnSuxOLnsnVCcr WLZyxV2I1BXj/2pVr2wXJImy/95ASQVad3CMtQ/fiLo/3gMEBgIKbAqpoIxA4BHhumZH 3364ZPyH1d/nrwY1N0+i8jss1t283yX32kKpiiljH66CTg8Z6j4P3tvBrk7RQj5L5uu7 F65xqAMmbB1iBv4lVOKlvMUCJijtGDTLCvp6+EmTgi4VSi0OJkiThTtUqkwW+3/Mh3df s7BQ== X-Gm-Message-State: AJaThX6IjESizln9KeEwfhiVD1v7sjtNzvriCLK9Bpp/XxwztKIBUZN1 9Nj/aAkgfGrtzjBCCI+RUoORpreQ X-Google-Smtp-Source: AGs4zMYaMq5GJO/FtQcaigey/wmGhZKPLacaUGc7XVGzTGlJTDZZD0Qdx1eZmE/mCMzQ5MfE+ZlEmg== X-Received: by 10.28.152.5 with SMTP id a5mr756488wme.131.1510256093926; Thu, 09 Nov 2017 11:34:53 -0800 (PST) Received: from MacBook-Pro.local ([41.136.226.81]) by smtp.gmail.com with ESMTPSA id u4sm8010115wre.1.2017.11.09.11.34.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 11:34:53 -0800 (PST) To: Mark Smith Cc: v6ops list References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> <5ce59980-c2a7-346b-d495-5531fa205dcf@gmail.com> From: Stephen Honlue Message-ID: <7ccfb7ca-6850-b110-597b-ef3a1bb8715c@gmail.com> Date: Thu, 9 Nov 2017 19:34:44 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; 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 Archived-At: Subject: Re: [v6ops] Why not use the L-flag?: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 19:34:58 -0000 On 09/11/2017 19:13, Mark Smith wrote: > On 10 November 2017 at 05:56, Stephen Honlue wrote: > > The L-bit is for the situation when a prefix is shared between a > number of host on a link, and the host is being instructed on how to > reach other addresses in the prefix - directly across a the link, or > via a default router. The provider managed shared network is nothing but a link. And if a prefix is sent on that link with the L-bit set to 0, we already get the devise isolation intended to be provided by this draft. > Here's the BCP making that recommendation: > > > Host Address Availability Recommendations > https://tools.ietf.org/html/rfc7934 Thanks for sharing. > > > Regards, > Mark. > > > > > > > >> Am I missing something? >> >> --- >> >> Musa >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> From nobody Thu Nov 9 11:42:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8486129B09 for ; Thu, 9 Nov 2017 11:42:02 -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 N5Dnj25nrYel for ; Thu, 9 Nov 2017 11:42:00 -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 6594B129AEA for ; Thu, 9 Nov 2017 11:41:57 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id s11so62290pgc.5 for ; Thu, 09 Nov 2017 11:41:57 -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=okylOGxxhzbYAobZh2G/cNdBYbOGiK8HJlvpSuSGUZY=; b=TSQnAviay5RlOF1L6XBc5HZ589+p0G0r/lT3YWf1N6cm1KfUFqqUnka6gHMdgeHvsn iKBbjD0RCf2rNE2+zkVrQlBwY3q4C74i255kpLLzQyIv3hqANf9eVkPg0nmepNslFTxC +vxmES2JhyzGv37Jtnm323reAXAllZCD98rZ+CbEe54ZTT6aFdiwcL1t4wv1ykyUxOcF vHaJ1tjgablo/KSmW12YKnKOJQvgCBLcc9QK8/zDXgtsdmR3MZfnuLFjgj2kybAxU2Ls CkCBPmHgS+i8+S5BRvX2Anemw8xiqOVNkVdkfGEe2dt6lDuP1FZNgu1X1BBOWV2abwON BGeA== 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=okylOGxxhzbYAobZh2G/cNdBYbOGiK8HJlvpSuSGUZY=; b=TZNR4LqPAqOI2VLJG7R2FNpT3NyWwBAIMZvuHF4C/7HItpeZKqNb9VqEb6Suf1Fs8E GEYjdIJybzu0716dOUM17vAWhxin/An1NF6BTLkhOORiF1fDdek7bULjMBAA/h6Qh50o Oqzcjez0QxxcMvZbwtSbbfHK37EYSvFHi3Il8TIL/yXnAYSfrybUIAb7PoHVK68eq/eT 6iybAa7HvTRjAlOZ3a0IlJKwHAeRC+hJH1jrY2A385k1WSBTeSxSdGALPPLkPWY63Yqh e7Yi+fuSDsXDvJD3tSuCQuWddTp3aP/vHwCa4kY06/IZ/fujfUdmf832QaMA5H0imziR nO9g== X-Gm-Message-State: AJaThX5DrBFBkUhwNuN6LGv+s5QlXfuMr9nV0iejuJFGxINK3YA6oRxu h5weE21GGnSaGoonThb1kfjCCA== X-Google-Smtp-Source: ABhQp+SWpdJcTLfy/7DpcOAX23vYEfGGw/ZRBefc2tiKs1J0QhBVK3sDofiasIbxB9Gd6SW4ZXVcXg== X-Received: by 10.101.64.4 with SMTP id f4mr1436052pgp.301.1510256516406; Thu, 09 Nov 2017 11:41:56 -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 132sm9003204pga.80.2017.11.09.11.41.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 11:41:55 -0800 (PST) To: v6ops@ietf.org References: <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> Date: Fri, 10 Nov 2017 08:42: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: <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 19:42:03 -0000 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, > From nobody Thu Nov 9 11:49:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A8F1294F0 for ; Thu, 9 Nov 2017 11:49:48 -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 d50VEEyy2U4G for ; Thu, 9 Nov 2017 11:49:47 -0800 (PST) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::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 04ED0126B71 for ; Thu, 9 Nov 2017 11:49:47 -0800 (PST) Received: by mail-vk0-x244.google.com with SMTP id k123so4746368vkb.3 for ; Thu, 09 Nov 2017 11:49:46 -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=opjDK40EOQIWWV24WMBTjEysuYaBPkhTy0v+rYe5+R0=; b=Arms35Bg+welXEJxWobZ61nQL8kCPwIxjOVqdicIcmoMJUfUDD8wH5PwxESwOt/wos RgNEL6jqHzTEWitICEQP2N9OUm9YArRDEYBWmXDFpobhdACAnOk5cAag37F1g1hLM7Zx VdaN3H/67TazkPTUgPuR6wsJ8MhQXbSAXsIvnGpU3ZTWVZ1DljCiiTkixtlRr2pUqhyq pSv6DPgA1ZfDNlZZlbqb9xbBV6k7N6EZMBVew5GkzUj1BJxJ58kqriWjL5jXzItNB8by Cr3/CTyFKVJAWa0dcxKFscAGScJQLh9HShzHaeIoXj/okhMBF/nQ5OMiW0w/yuueWEWw cN/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=opjDK40EOQIWWV24WMBTjEysuYaBPkhTy0v+rYe5+R0=; b=tUGAeCURjgCIy2Xp8mChUbhAQwqMTIvGXw9Tas6k3MDjtW2yVm0SyKkgq6/ISG4AFU BY3hzeag6UXZt6BMy4axNf2QcIcSsVLT0hz3s4o8ALw65t6W/bF4+i/7us/Dif3suitW f3dQQ90pSEihAaiFgHDWhEFLdX0/myFxUmtctFGFA8Y1pqM+l+cyB3bu8QmY6TnJ7CNW oSjQ89WzcPPFEnAUSpoPH17ncg0K2hlXKX/qvKSVcrc3sIK21pHJyuBpDDfmF1nhvF1K iBYiy3LQA+bM20a4Xt85UG0ZzdRv35xAz2VkQoCvtiJe8Ol3VpkzyfAwSAtTWtfhIav6 6GXg== X-Gm-Message-State: AJaThX5r8nInUllDXWumMs3bRC29lOGdwC03mMIC6JLYA0iCo416MqNI gcGaXsOHq1CjSOvFqCHXMDpsQuzEFngvh3/RcCw= X-Google-Smtp-Source: AGs4zMbcj5FdHPSehRcQLE1rnw+r/swiC6NDpgFih2UbuOvMyb/F34YV/Pu0X4TjgwlQTyXDAl+sFytemnZ+L/i/kVU= X-Received: by 10.31.177.134 with SMTP id a128mr1398300vkf.93.1510256986021; Thu, 09 Nov 2017 11:49:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Thu, 9 Nov 2017 11:49:15 -0800 (PST) In-Reply-To: <7ccfb7ca-6850-b110-597b-ef3a1bb8715c@gmail.com> References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> <5ce59980-c2a7-346b-d495-5531fa205dcf@gmail.com> <7ccfb7ca-6850-b110-597b-ef3a1bb8715c@gmail.com> From: Mark Smith Date: Fri, 10 Nov 2017 06:49:15 +1100 Message-ID: To: Stephen Honlue Cc: v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Why not use the L-flag?: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 19:49:48 -0000 On 10 November 2017 at 06:34, Stephen Honlue wrote: > On 09/11/2017 19:13, Mark Smith wrote: > >> On 10 November 2017 at 05:56, Stephen Honlue wrote: >> >> The L-bit is for the situation when a prefix is shared between a >> number of host on a link, and the host is being instructed on how to >> reach other addresses in the prefix - directly across a the link, or >> via a default router. > The provider managed shared network is nothing but a link. And if a > prefix is sent on that link with the L-bit set to 0, we already get the > devise isolation intended to be provided by this draft. The prefix is not sent "on the link" (sent to all hosts on the link), it is sent specifically to an individual host via a unicast RA. Each host has its own unique prefix. >> Here's the BCP making that recommendation: >> >> >> Host Address Availability Recommendations >> https://tools.ietf.org/html/rfc7934 > Thanks for sharing. >> >> >> Regards, >> Mark. >> >> >> >> >> >> >> >>> Am I missing something? >>> >>> --- >>> >>> Musa >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> > From nobody Thu Nov 9 12:33:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F238D129B2E for ; Thu, 9 Nov 2017 12:33: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, 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 q4h8GTvusZh9 for ; Thu, 9 Nov 2017 12:33:47 -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 833F4129B62 for ; Thu, 9 Nov 2017 12:33:47 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id p9so5625218pgc.8 for ; Thu, 09 Nov 2017 12:33:47 -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=3k2csJ1xzIDYkkg1Md5F5wjK5oomrvZK9zOKoHZX/oY=; b=hUlMErM9JUQwAVdBKuibBz5EWi4qyxndDabbN4O0ncX1sR3V/sqUNtibx0+8TBdJ0n 0QFf3kCnls5SBSfl0hvvpjr6HExPm3PX263uDgvMaMPYcYP5IXaok8c9pWHZcJzhlDzW AvABDHJiZVkJuH/a1QJFYu9EckKGMuBm2QbC/1dW41TdqbHywucg9caXIrl+bAHJfrmv srP1/hse5aShk9N8JdR27FEEK26j0Lzo3gFtoq4D3iaSqHxUr2nb4V2XwE4CRzV4BduA H8bGBZFCwGvwDteKy3dSRmFn1LroSN4i7MWZlwhJohGUY9P26U2Q4ajUnMUO0oKT1Q8H P6AQ== 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=3k2csJ1xzIDYkkg1Md5F5wjK5oomrvZK9zOKoHZX/oY=; b=btPSVc6vyp7i3PB346mY3pB+wy4WBxrk+0s+0IhlNf60yYeomo+/TyflSIqdUm+y4O 2tyc/6qQIKdATExTIYUuqVymHt4e9dN+iB+Nu3lKDZ0dG+mN1SmAhImv0tz/N4m5Z4Lb HH2AcpBXtYsXSxhYoc8NawuZe5KftBXeEGtH8WGRxxWqYpqIe7W3P5OIpsR77godUxV/ AppqObUMqkTP6KseEf5tSh5W/8Vx27A/b0NOpjIMZpeWBZ0YuJTSlNBt/mrf6ALaOq5V S3VH3v3WsZgr/1idOobVWADQ5cMt696EGpPnuS2DhaDFHC2GLPI+9Oh+h3NiaqstHtbp Ln3w== X-Gm-Message-State: AJaThX51KgdUTtOR3RDl6X2KepzS8eH3DFHdvC16JNi11GnSG4NtmJop jbW/K9scY/2wtv1wFPUPGf62mA== X-Google-Smtp-Source: ABhQp+TAmpywpAr1UdORZGCwEYzF8yZJZy05Roaz5e4dNoCyzdFrPw9jQR0S6on1w1SrDA1DOrJdDQ== X-Received: by 10.98.209.8 with SMTP id z8mr1698542pfg.184.1510259626636; Thu, 09 Nov 2017 12:33:46 -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 n29sm13328674pgd.74.2017.11.09.12.33.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 12:33:45 -0800 (PST) To: Mark Smith , Stephen Honlue Cc: v6ops list References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> <5ce59980-c2a7-346b-d495-5531fa205dcf@gmail.com> <7ccfb7ca-6850-b110-597b-ef3a1bb8715c@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <2a95c81c-6627-8475-a554-062b9cb930f1@gmail.com> Date: Fri, 10 Nov 2017 09:33: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: 7bit Archived-At: Subject: Re: [v6ops] Why not use the L-flag?: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 20:33:49 -0000 On 10/11/2017 08:49, Mark Smith wrote: > On 10 November 2017 at 06:34, Stephen Honlue wrote: >> On 09/11/2017 19:13, Mark Smith wrote: >> >>> On 10 November 2017 at 05:56, Stephen Honlue wrote: >>> >>> The L-bit is for the situation when a prefix is shared between a >>> number of host on a link, and the host is being instructed on how to >>> reach other addresses in the prefix - directly across a the link, or >>> via a default router. >> The provider managed shared network is nothing but a link. As was discussed earlier, whether it's physically a point-to-point link from the switch port**, or actually a shared medium like Wi-Fi or traditional Ethernet, is an open question. By using the unicast link-layer address, this operational mechanism will work in either case. ** Of course, there could be a point-to-point link from the switch, which is also the router, but with a dumb Ethernet switch at the far end, converting the point-to-point link back into a shared medium. This operational mechanism will work in that case too. Given the nature of Ethernet, that is a necessary property. The L bit is not enough. >> And if a >> prefix is sent on that link with the L-bit set to 0, we already get the >> devise isolation intended to be provided by this draft. > > The prefix is not sent "on the link" (sent to all hosts on the link), > it is sent specifically to an individual host via a unicast RA. Each > host has its own unique prefix. Exactly, regardless of how the packets actually reach it. Brian > >>> Here's the BCP making that recommendation: >>> >>> >>> Host Address Availability Recommendations >>> https://tools.ietf.org/html/rfc7934 >> Thanks for sharing. >>> >>> >>> Regards, >>> Mark. >>> >>> >>> >>> >>> >>> >>> >>>> Am I missing something? >>>> >>>> --- >>>> >>>> Musa >>>> >>>> >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Nov 9 12:36:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD481293D6 for ; Thu, 9 Nov 2017 15:01: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 kgW6_SatYJpp for ; Thu, 9 Nov 2017 15:01:18 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A596128DF2 for ; Thu, 9 Nov 2017 15:01:18 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id l32so6713228ywh.13 for ; 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=qdCzUHckr93+eZBd3Y2heBgY/xAAHvPoYauGF3zYpk395sTSBI4hLNWCR2hnMw2w// 10RFV7XE8P6+ZoiPSD7fUg/FLSt5bd71wPGMOwjV4Y9akruTD4zfVdiptP2j836+Fwpw zHOINBO883mqSv1L3Px+k/q7fS8LRvR7qCBLSUTFgcxo0e/FJLd723srYrKWMrlDQ8b4 5iZ5zJdQHjI/zXxbrhqdEB+xI4ZTzOkAJ/MEi2LKq/VTnGbd6++a4TXoRlHvBquMvgGN bQsUBrf3BtODrY4CZj6kYGsE7PSoOimG6cCWhyHtSokgU7wZ0itqDBAXcXlBWzVZFcXd Vbsw== X-Gm-Message-State: AJaThX6lIfE0wYbpwp9dqDbDJClGvVw4LqMqnyXi2V86cOqTe8rEIpld FjciWraIgjrHOY49z7idvhf+5Q== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 23:01:21 -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:25:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA52D1294CF for ; Thu, 9 Nov 2017 16:25:06 -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 9RWmFGvws_01 for ; Thu, 9 Nov 2017 16:25:05 -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 98E7A127076 for ; Thu, 9 Nov 2017 16:25:05 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id l19so3505968pgo.2 for ; Thu, 09 Nov 2017 16:25: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=90NByLkFaCtJ4PmD9aDQPk7J8o18j0Z3SSAq5YvHXyY=; b=VXzDkg35CerXTT0c46MxN8ZaP7+j2sNxhh7mKKn7glkKDtCrAuc2nbSgXuRag2YnRm rVjADpfMNmxrosLhKammt1NrpaQxQYAVGYuP5qe9jRsLE6fnjI5zz1esSPzWuOIntJ2c /rIxLxfD12/l0Tewi3scvq0H8mXBgk/TBvlHLoGOwA7DF6sYz56UaBBqY8mtPGEILWgq 97GJoNC+fRqK+IpjuFpqn3mtASW3CoqjJx2HThCUWbO0xPCIz634ZCnhlEUCbf8VZ1/g WjZFmY0qEUbvhc2+Q8UEVbzh7j3EH0KbNjVp644OUpkPATtxHy8d49rzpxNzvhnSAUnJ ydLQ== 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=90NByLkFaCtJ4PmD9aDQPk7J8o18j0Z3SSAq5YvHXyY=; b=tCtm96oGj7atdBgXmDvgp2DgIWCjiLxQOIhYH+ho6go8zCD/7fB/qhFD4LizZPouQy R33D97NyTua+WliHiNjeKM94FJ9JCMwX473XyhohYiOOEIRq7HLVjJ9R0MKEdOYGWzIW 1MKN96gK4jqDsnqo8KVczHIKYFT8YhZR4QccKjuYBZstcvDggTp3hWu5RPEUc4Fowf4p 1sDSSbg7/LbPNS/a6yKoifSTERS/KZQtHs3HfHF/V0z6IOocRLmMPJvdvUg1h50MD68J 6YC0GWtHq289vx1AKGwn/2HSdM2dVEohsk7iPIGBCQJ+BJoCF8ENg36pMM7J65wkLDiO UXGg== X-Gm-Message-State: AJaThX66smHjW9YAGZxD+Q0pjrKy8+LIbf+8IKiV1l0yaFGDaXWUVuug hJs2x7eAIfVIyiV5mhVzjOQ= X-Google-Smtp-Source: ABhQp+T0H04mqXq+fCbFV/5Z9DccNdDgQnhpb919Df/w4Cy3CcqhD6Npo1EyHnTZsXiFfWLsqjYriA== X-Received: by 10.98.89.6 with SMTP id n6mr2227518pfb.89.1510273505191; Thu, 09 Nov 2017 16:25:05 -0800 (PST) Received: from [59.29.43.171] ([59.29.43.171]) by smtp.gmail.com with ESMTPSA id v14sm15389118pfd.153.2017.11.09.16.25.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 16:25:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: DY Kim In-Reply-To: <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> Date: Fri, 10 Nov 2017 09:25:01 +0900 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5A10C4D0-CAFD-4E33-93B8-B7F7D8AB0B07@gmail.com> References: <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 00:25:07 -0000 Curious. What does LL here stand for, link-layer or link-local? --- DY > On 10 Nov 2017, at 04:42, Brian E Carpenter = wrote: >=20 > We are talking about sending packets with > a LL multicast destination address to a unicast LL address. From nobody Thu Nov 9 16:35:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEC41292F4 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.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 MBsOSKKky18f for ; Thu, 9 Nov 2017 16:35:33 -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 D81461288B8 for ; Thu, 9 Nov 2017 16:35:32 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id r127so12904382itb.5 for ; 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=b/xVmnoejimFuJ3TLnbSH0xlO8j66lVktciL7+pkp1EFdjKnAl/PcmbbwDqPFKNIA7 64iUoFTTpmGkKLXaODZgQArotdyp3sY3jWow9giLOouI8MyawlwM6xvKagejDxKesLRj XezuL3ad26x/BhRtL5CfJYw5dkUIHnbd11vyFsS31FBcJDYy61MXAE/s3F3+FYjeT43Q K3eS65bgtXQQIqBw1WU4xyJ9VZaNp7mLDNnptA9A3rfr3t0HNW/jMl8tS0MWNlOFPo/s M1LkdoCnhm2SlDVCZiZ328hSXtLIzpDUWsZ5toQd9hyXPLk6X5J4EGkqQ1XwWtwMxhDT Tnlg== X-Gm-Message-State: AJaThX4XuW11NqkYIIWdty5GexagMVxxRCkaqRXx/mYEls0+Vhw2PASa ORe96ZWavXvqdj+SbLK71KLvwDOyyj8g8LUJbNSZlg== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 17:20:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B2E1293D9 for ; Thu, 9 Nov 2017 17: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, 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 qLPrcP_3_BD4 for ; Thu, 9 Nov 2017 17:20:07 -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 214A2127201 for ; Thu, 9 Nov 2017 17:20:07 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id i5so5583586pfe.6 for ; Thu, 09 Nov 2017 17:20:07 -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=Z5lo0Lg8ljpcSV9cAZxeSL/6VOSZNmdjCcRKAb+/0/U=; b=SyCfgK9w0/4UvKMam7XhfCkd1L3tZLsMiAZQPwPWkuC+/OugzVY8Hwaftfgk2nTfcV dKQ6ifhIzvEn+mEPWsY1gD82jSHbl/PORp7l0miqkxnAB7jaWzS/p8ri7lcaTM4uE2Bd JWF9CcCKPXPShtdX7nsM6t9P5rGRsbuxb+8YgAds8vRL5MIEMtsL2AMVg+c0Pvn6KdxG y6XyvQfC7RDoXluL9dYUfeJRFVbKay1+Nd8ODMZ1nnyfVXgdtE51CkJm/FDJw6sDYIpg +NvHEduKPB3jJhNcfYeqrWqzAWZst/dktWv2i8dTAH02r7V0+MDONn5sKmP3t1+KF3Y7 373A== 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=Z5lo0Lg8ljpcSV9cAZxeSL/6VOSZNmdjCcRKAb+/0/U=; b=ngAXCIjOdMUoFY9Iu9qf9NhfMEmCSZy6N1T2SZjvfVDsyk0lno4itlhVHv23NBRYFG fhnXFXV8b2tCx2MWUW8Z9fuUolxSVSyANs1h6smKGaVNuH04UglAV41ilqdoHx7zVECg 7qb0U/h2JLdk6ADnxFrMMScA0brV2y0hRcr4DmfPImN7eHrjsX1rcIP6kPfcr/h/3ZnK x2oItXvc01Zd45z7KXvmBzZ21+ekh1hqNFTSVjHN5dsqBW+DWtkf6wp/8pUL+lh4//jJ HL7rNu2BVO0hWz8fDmsBGQMrtlOWNDUJpLOMqLlitfmC62XsO9Y+xvFZcioL6ivr0mOJ M2fg== X-Gm-Message-State: AJaThX77KkUb14k5RhwuPzH+iXY6QrQF882RoDvkpHAlltkHzILA6k95 MwJZZySraXbjdRBajDMmYZfxiQ== X-Google-Smtp-Source: ABhQp+RQwqmlGcbdfWP6GQRyWXkPDmXc7aCKnpCaSLzaXV5BoECYg9NDHNd8n+YhyRakgTenTgwgkg== X-Received: by 10.99.2.23 with SMTP id 23mr2237238pgc.99.1510276806164; Thu, 09 Nov 2017 17:20: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 t80sm6164869pfi.98.2017.11.09.17.20.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 17:20:04 -0800 (PST) To: DY Kim Cc: v6ops@ietf.org References: <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> <5A10C4D0-CAFD-4E33-93B8-B7F7D8AB0B07@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5a308d2a-bd56-6e9d-e3d6-6e9a8959b9b9@gmail.com> Date: Fri, 10 Nov 2017 14:20:08 +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: <5A10C4D0-CAFD-4E33-93B8-B7F7D8AB0B07@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 01:20:08 -0000 On 10/11/2017 13:25, DY Kim wrote: > Curious. > > What does LL here stand for, link-layer or link-local? I was thinking "link-layer", but I'm sorry about the ambiguity. Brian > > --- > DY > >> On 10 Nov 2017, at 04:42, Brian E Carpenter wrote: >> >> We are talking about sending packets with >> a LL multicast destination address to a unicast LL address. > > . > From nobody Thu Nov 9 17:22:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AF01292D3 for ; Thu, 9 Nov 2017 17:22:22 -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 fiWw6LcBWYFt for ; Thu, 9 Nov 2017 17:22:21 -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 90B5112426E for ; Thu, 9 Nov 2017 17:22:21 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id s75so6192014pgs.0 for ; Thu, 09 Nov 2017 17:22:21 -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=H5laAvMkrZyrW3+rixbg/P6lePmUAxfeFRIT8rzchso=; b=T+vG1UgEv4sRXDpHjIKDE2kNC9IEMzQOrI20KaH2wBxOILdGFku/wLmK3DER4TRAZg 20N5Af6oKIxhycsHrBDtFzV9zozp5VsNXY5EsCHOxShnO1eFTMrQ47yfVNaiwVDaS7Sc PZDlOJe//3W5S0PKgqt0+EaOYOayIoHcVs1Aq1AJHIFNzIeGD+I5P5NWejRPkqpQ8vXC ED58gJ7gAgGYAbPxYxlDBxqRy43GvACTaZBRMEqOP/EROEKEFWMG6nxBEfCAmI6ib5ip qfR3MjhRBseIobcb0NU5INUwG07X0quokeJB/JASLLrWzJfn4CiwMfajnZGDUoyoLCIf xnwQ== 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=H5laAvMkrZyrW3+rixbg/P6lePmUAxfeFRIT8rzchso=; b=jbkT137ANZFh9Q+b+E+syuA7BAPzK8IVC5VIvXvAvLVLausGefLLRZf0N5HJ3kiOYI Th9NatWkaH+/rGQcyYUWNCkBFoZ5iccwT8BDlXu023zoxCr83cGmqEvWypV6a/ZcCqY/ 8pS6qRSna0t0oCMm7It3nNEUu8R9Z4OtLCZ6xWtazLQyRxQ57X2XAc+i46voitMe+OEu otOvvyduAWVhQhwI/tlBjMXrGBZX3hh1ULw9QpBUUQdRDGfsRV3r0ANiYhjX88PlfzKj Nq1pbzz4ZOD86aiD8aRdWCd9IGSgoKAHcJ0VtfagEmok0vW0N0Y1omRXQzxv+QjZrByP pE9Q== X-Gm-Message-State: AJaThX7KVSuPyMqVkw0a+GDaoWEbJ2Fl9IiD5JpEiGMLRac7P1S8FZOR vbf3a9ta9phvrSMNDXeNyS4= X-Google-Smtp-Source: ABhQp+RIpeW+5VGq4iL3fCKCfIXd7yxNuKiDI7Tj0nb5JR1pDkNfJWtkkIxbt/zvyGWRn+W4fpGPJA== X-Received: by 10.84.176.65 with SMTP id u59mr2336296plb.21.1510276941111; Thu, 09 Nov 2017 17:22:21 -0800 (PST) Received: from [172.30.1.28] ([119.205.179.11]) by smtp.gmail.com with ESMTPSA id v9sm5526688pfg.85.2017.11.09.17.22.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Nov 2017 17:22:20 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dae Young Kim In-Reply-To: <5a308d2a-bd56-6e9d-e3d6-6e9a8959b9b9@gmail.com> Date: Fri, 10 Nov 2017 10:22:16 +0900 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <878DA766-C9F2-43B2-A07A-8CA2AAB39B74@gmail.com> References: <9d154133-a1de-7774-1589-c7069bf279ee@si6networks.com> <0b45890d-ea4a-47b8-a650-ceb72b066df8@gmail.com> <5A10C4D0-CAFD-4E33-93B8-B7F7D8AB0B07@gmail.com> <5a308d2a-bd56-6e9d-e3d6-6e9a8959b9b9@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 01:22:23 -0000 For this usual ambiguity, I thought like, use L2 for link-layer LL for link-local =E2=80=A6 :-) =E2=80=94=E2=80=94 DY > On 10 Nov 2017, at 10:20 AM, Brian E Carpenter = wrote: >=20 > I was thinking "link-layer", but I'm sorry about the ambiguity. From nobody Thu Nov 9 20:12:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AB8129744 for ; Thu, 9 Nov 2017 20:45:38 -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 5Rk4YVIjFJ1S for ; Thu, 9 Nov 2017 20:45:37 -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 46FC4129A9C for ; Thu, 9 Nov 2017 20:45:36 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id r127so160480itb.5 for ; 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=SEvQsvH/KA9Lhx2Vs7Y/kIV4uj9JcOd0fUCXUCs103+Kj3yYDg3zFdTTCDlFSisJGc Iou+LRqSay7DN71y4RfAac7DooYoo7SK0V5Q2/VCzHLoADC0CRp8aZ5PNeCGyQ8EZrqo t5YgVUE5IFZgVgWgmMUsAnB5Jv2pzKpc6CygV71AS8M1EszyInLwU9oUtalD1WD2I5MH vEF87/wJDEWZPb2+ySpvjEGlVGT8QttpIrM0x8uQ98fQvDb+Sp2GS2urq86d1RRp5nrK udDSxghHelFC07taJflMINZD2YDUOB822qRqyeC5UTwGBJSZI7xOmezEArDkIMG+ptnJ YTUQ== X-Gm-Message-State: AJaThX4oYz8V/zOjSRWaJQMS2gZg/D0GuX+Z8cY1SyPRsMGXxkcHpDZe hz/xXi206+3FhXR/QGSuUUrssaDL8DCFcDTn3X8J0Q== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B15212EB04 for ; Thu, 9 Nov 2017 21:57:41 -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=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 DVSnT778zKxD for ; 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 D881C12946E for ; Thu, 9 Nov 2017 21:57:39 -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 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 05:57:41 -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 09:59:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D974512EC9A for ; Fri, 10 Nov 2017 09:59: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, 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=plonka-us.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 lTHgE9o9glJM for ; Fri, 10 Nov 2017 09:59:39 -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 5B3CE12EC97 for ; Fri, 10 Nov 2017 09:59:39 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id b49so5485456otj.5 for ; Fri, 10 Nov 2017 09:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=plonka-us.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=vJCTtGeY77DIIFiy1OO7DroVwXmHp5ttuWUBIBpr04Y=; b=ejObSbvUckgiPJNqWJRmQkojOw/bFDHJ8cmOP1Xkk4ArFlgDsC9RARZ3m5enwxESiz lsOv1XvmCsr8CyrH9OcKBFEv/ZEy1I0teujl7lqwi4KIFcMlx+E2UIJgeghD84QMNe+Q AWd1zjX9Flm8KfnoWQ6yYyKZWaR1h6CrwZKpwCqazX9tvPdSbKVMAIcLcZty887dmMp8 /ppFd2/g/D0VVJtDjYccKcecfZgengZQ+2KzhG5wxjSsVVXe8s8WVGMXhq9KSW24O4qb PIW9WlwNgNRjmY5fOHQErS/wc5FBsxnM9RDW2MElBuuo36Qu+XmB9QAQdBMkx9jNKEK/ pgiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vJCTtGeY77DIIFiy1OO7DroVwXmHp5ttuWUBIBpr04Y=; b=F1AFmFDoSvmhzwUNqwBUnTqnWKYNx14zPDL7sV0cj9i/KzLn6zA3F7mK0+dx7DqGz4 rKr8Bk5kdDoOeBumBLQJCs6Wue5xmk80KTR9qasuGKiQOK/DWxZCoVCl0Lryb6T+xK+X 3kmnMJz6Q89DgW8nNqaQhRwBG5YQJM6PFgUUAAywRB6s9QSZzCJOYYUS6LuDpqHaMJjK wypS+YdiSMuZ35pObR+5pMPtGoAR7kjdUh9wjuaj3gxgiqYAxN9fSXoYipI4c/81mwcG 8opWmPJ5DCXSUcvh3xC9HljHxAZffLmX4aIOg3nv1hP+mE/knGe3RaCZ0/rz8s/6A9AZ jkRw== X-Gm-Message-State: AJaThX6yRI6I4MACDKlHKExeAk+1hBlwzQ55gYV/+x7H8V5Y1xvQhGZ2 Wedz+V8u1Bj/Zlp4Ah/9Mj+Y3IlUWts+gR+fP2PWHNAQ X-Google-Smtp-Source: AGs4zMZcO10c+CXhrpcewPgJRdTX0OfrSRWIP0ygXVV44XFSCdHztkS0SNskRz76NRvYIxOhD9sCtPPpVL7QUOfOVA4= X-Received: by 10.157.92.135 with SMTP id a7mr725418oti.286.1510336778346; Fri, 10 Nov 2017 09:59:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.117.19 with HTTP; Fri, 10 Nov 2017 09:59:37 -0800 (PST) From: Dave Plonka Date: Fri, 10 Nov 2017 11:59:37 -0600 Message-ID: To: v6ops@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] Active IPv6 WWW Clients measurements update, MAPRG, Monday IETF 100 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 17:59:41 -0000 v6ops folks, On Monday, Nov 15, 15:50-17:20 (room: Padang), the Measurement and Analysis for Protocols Research Group (MAPRG) meeting will include a short update: "A Continuing Study of the Active IPv6 WWW Client Address Space" https://datatracker.ietf.org/meeting/100/materials/agenda-100-maprg/ (slides will be linked in the agenda) This is the latest of ~4 year measurements including initial results of applying the new IPv6 host counting technique, introduced in the previous MAPRG meeting: "kIP: a Measured Approach to IPv6 Address Anonymization" YouTube: https://www.youtube.com/watch?v=qYtaKuzXaiM#t=59m55s slides: https://www.ietf.org/proceedings/99/slides/slides-99-maprg-kip-a-measured-approach-to-ipv6-address-anonymization-03.pdf Thanks, Dave -- dave@plonka.us http://www.cs.wisc.edu/~plonka/ From nobody Fri Nov 10 10:35:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C053128DE5 for ; Fri, 10 Nov 2017 10:35:25 -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 n-voAs6gQm91 for ; Fri, 10 Nov 2017 10:35:23 -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 17F10128AB0 for ; Fri, 10 Nov 2017 10:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510338921; x=1510943721; 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=i13kDJ3qhmtRU2qAwhXG9atwA BE1XrhfyJgAXdmTtto=; b=FhdxhAGGjf6QUwZVdpTw/IlyNJ3N98Fe3ZVAylVgu DPOWU9ZPg5nVHC+JFFf7iHSRQSBo7u+A8F8IpXjThcwxvLNEhT+WOyN0Gxd9vbdP QGysc/RVKUMyCixy7jxr0mYP27hg+S3SNPanvj0ZOD+hmXRtfg1V/SI33ENW9ErA Es= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=qG6dJT69X9ZKTgOneoHCZn6CNyZGOJ6TPjZCvrFdjZ5RsPS0moZ9t6IU0NKW 1SNpMUsgpX+BwkV6FG1TyqsLBoxcewwQjebWwwQ95OVDLUXdAbqCSFo3I unIkWcoBir4Q9COU0gFGrDSBOS7wYaAFuBqsPr4J5/3f8a2zz+QxN8=; X-MDAV-Processed: mail.consulintel.es, Fri, 10 Nov 2017 19:35:21 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 10 Nov 2017 19:35:19 +0100 Received: from [172.20.10.4] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005620510.msg for ; Fri, 10 Nov 2017 19:35: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:171110:md50005620510::xGkeWpbiMIHUUVqL:00000TEI X-Return-Path: prvs=1487d702ab=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Fri, 10 Nov 2017 18:34:45 +0000 From: JORDI PALET MARTINEZ To: CC: Message-ID: <30851410-D40B-4EB5-BC26-1B0003846717@consulintel.es> Thread-Topic: comment on draft-palet-v6ops-464xlat-deployment-00 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] comment on draft-palet-v6ops-464xlat-deployment-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 18:35:25 -0000 Hi Erik, Boarding to the plane right now =E2=80=A6 so reading too quickly, however i= f I understood your point correctly, I think you=E2=80=99re right with that= recommendation. Let=E2=80=99s see what other folks in the list (v6ops in copy) believe. Thanks! Regards, Jordi =20 -----Mensaje original----- De: en nombre de Erik Nygren Responder a: Fecha: viernes, 10 de noviembre de 2017, 16:27 Para: Jordi Palet Martinez Asunto: comment on draft-palet-v6ops-464xlat-deployment-00 Would it make sense to call out in draft-palet-v6ops-464xlat-deployment= -00 =20 that even if DNS64 isn't in-use that explicitly returning the NAT64 pre= fix as part =20 of a AAAA response to "ipv4only.arpa" is strongly recommended (or requi= red)? =20 =20 Erik =20 =20 [happy to post to list, and also feel free to CC to list.] =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 10 11:53:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAFA1294B2 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=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 8zDdvjCtDGZO for ; Fri, 10 Nov 2017 13:25:30 -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 12DC51294CC for ; 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 0D5BC728 for ; 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 PZvpnXDLgFtV for ; Fri, 10 Nov 2017 15:25:27 -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 9E730240 for ; Fri, 10 Nov 2017 15:25:27 -0600 (CST) Received: by mail-lf0-f69.google.com with SMTP id m74so957253lfg.6 for ; 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=JzDujeM0/fhn2DdSs+Wpxxpyfq7lOo1fltbOmq/ArpXt1oLsBUVhwhvWSuQ/iM0r8C g9aKN+69D9JDKK2oTQ0cZHfbVndUYlpkUGbvFesEMZaS86p75sXkr2f2+ey3UG3lJPdh 43lUsVsTz85NAM+Kqiy12ByToRfA85Sw0tQtGwbpeFmuzMYIBufFL7gP7PliQG+Ma0OG yC48i23VR1Ulb1mDcy8OBaZZg+sw96R/bTYY1ia+TtC+oiccyAaQgGKPxsA31Ilm/oBg eAP1nZ8AcTt+6EhHsr3WgtrScohUOfh3KdYTjAuHUHPAVs58xwN74+XG7obUBv/7Q8pt J0CQ== X-Gm-Message-State: AJaThX6gISCF57F+AKqpn7E9Jarm+Didp9vz/wXshb1PS8HEKrkynyjg StMopzpESj7QBg8GYosAO8LPoauhiNkQlZk4TQuyxpZtaGpG0M4Tx4zBDc8aYwXt8evg0HeF0j5 yeotRucS4G704g8Ky5Roa31ap/w== X-Received: by 10.25.37.201 with SMTP id l192mr562673lfl.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: To: Fernando Gont Cc: Brian E Carpenter , V6 Ops List , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="001a114106701d13d6055da78f01" Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 21:25:32 -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:45:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B89C21294BF for ; Fri, 10 Nov 2017 13:58: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, 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 JBSy-BHCY_rJ for ; Fri, 10 Nov 2017 13:58:43 -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 997681271DF for ; Fri, 10 Nov 2017 13:58:41 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id 189so15018891iow.10 for ; 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=Q5MDe2S5nUMwpXUYwR1HksLbxvGIZ+tP3qJnaf7poUXbRU3r/Dlfw3nTTyQdA7toVw dueeWrnMMKkGvhPBinZ29XtA+9aOhxTEgpcSenzM44E+CvANOBxIhDEZXfWr1trHSa6f 40hg58u/kTQW0/4K5jPF+eXvJygaVWDj3H/qZa9sOAC6U8d8UmDxORRaPW5lvDXDpT+V DZHMo6kRELBfhqmidbZNWakI1otU3pryVaiSSikEEMzfy1ggrQCElj+wsFjeuHoLMvW0 NlRyGujBwHpj274j6RchxQgdinfP7z3Rw+0qvR1AXheEpDfE/lzmSd2THh5P0D6KFJpI +SrQ== X-Gm-Message-State: AJaThX50CYi/atnU1qJjnrQ9r8ndokIWy675KF8OEdX5pwLPmKWY4e92 d+BE7eQwnsBLczE+9nia7XFQNA== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 02:36:00 -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:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33998128DF6 for ; Fri, 10 Nov 2017 18:45: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 lQn47YW6NyiZ for ; Fri, 10 Nov 2017 18:45:16 -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 398C4129353 for ; Fri, 10 Nov 2017 18:45:14 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id g6so8728399pgn.6 for ; 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=fKhaW00vnbaQ41eEjXyt7R6oc2if3Yow8ALpGqhDeY8uoTR9E51j1UIpkN3JtVx2aj min6eaJecgatS+Y2xgMVRWNDiN5E7eTRAwlrwDV+EsebbMH8K+jpbDcmunbNZGlLwGnt L2cGOPknmXgCFkLEfezk0LjHZdrWxBs3l1Gsiet56MG71YFiDBmP9arsQdDhheChcF1Y y2NaUSHIq3Kjwa9+4gfH1udAfwMNchrRZj8o7hx08HgJ5Z1/YVxY72wjd93nSkahMMxx qWQQae6JibOo3rhJY1dB01wACyg8Jssa354gGYO8+KSly9EYg+mV4ZXH1quuNyyPedEz FZtA== X-Gm-Message-State: AJaThX6hSTe35MIq4Rg9QoUvFTn+YtgyFug8q2HmJGSoWOq3W7HR+hQs TingTfAa2ctlltonEg7eCg8HiQ== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 02:45:17 -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:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DAD128D6F for ; Fri, 10 Nov 2017 19:18: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, 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 spHRfl6HjDSh for ; Fri, 10 Nov 2017 19:18:07 -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 02C9A128D19 for ; Fri, 10 Nov 2017 19:18:05 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id b85so7977731pfj.13 for ; 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=GTk39npRUJ/hJMb2QHy751p4ix5xdAd+k6KqLE07X3j1KxEdPamOG1lfAEilWVjPOR rTYDsc+zfWEpkfWiv3uzZxsChx+/YjphrR9z0Gd/CzDkVISCIYAik0K2Apdc0j3JsZmy qjVlpqnGFfOewEam1HWdLU/IKpPPCra0Tg2mM51wHiTUqpKfqLhCQwc98O/yV4lfgk14 LhW+VH3wQ026kGekDEFwlIrAs9GbNPzWoBjAM4spvoGcYLtTiHzgpwfjBPb2apDoh42o JPJ0QgVbrDe4gAvGZFt8zApSWaE8fwCZf5mIDB/wGvTcAI+iCJdeMW1/7KZNeYR61T9p 64dA== X-Gm-Message-State: AJaThX7eFdcmLBXq/e/8VQOIc53wHD0QvKJkn0OnskPRkpoish2U5V/I TTVDlIt2JU7Ct44/xV3cvuAWBA== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 03:18:09 -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:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E991293D9 for ; Fri, 10 Nov 2017 19:19:17 -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 7pvR_GkeN7h3 for ; Fri, 10 Nov 2017 19:19:16 -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 72DC8129353 for ; Fri, 10 Nov 2017 19:19:15 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id p9so8760153pgc.8 for ; 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=o8hssuLCSQjqdzKFWlhLGSJdZbPmhFDwaxM0qYHxtQ16Rej2G5iftJjsxX5CVHyyP8 Epz9PIGAcKTDKySo7FcTDtRjT5huOIhmVPu3Ulfb+zCY/+rrMipiVzW+Nqi8kLlWuCF0 tuNI5S49gliwUnvRUYIgdQG1aP+H/cE2H0KTPTghS49OcUm+RDXlJtOtgEb53a6zTy5u xCwiQfy93d1ZsRv8eC1oKapJT795SLk/Vw+P/HJktuXuDhIXKoybx9fcwBHgyAtA2iLI w0Uee4/sJChUyh/MtGo/IkIpPlNFn7LIWAymwIkggmZdITBXvHl5XK549PhqMc2677zL jusA== X-Gm-Message-State: AJaThX7G13W3wwjOpiBDOcRpy0Vkf/+o3/3L3i0iBuqZuKDAuYLGqug5 FPtXWs/Sgh3+LL/ZglaaADrMHw== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264391293F3 for ; Fri, 10 Nov 2017 20:01:13 -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 RvycylRw8WRX for ; Fri, 10 Nov 2017 20:01:11 -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 2870D12943D for ; Fri, 10 Nov 2017 20:00:13 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id o7so8814787pgc.4 for ; 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=uWeN+jJoUa0x2nrBh0aWCeW4Y6UchOpjd8szrQW9gUIFUUylU7PoRE6w8cUQCbKYCz Fy6SsgjKGYnNeQj2pEO2f+b0mZimLW7qRHbHM6hySXaCu3//aObK3ZkLIGLimKE5EoDP REyEOuHO/lEYVXQfe+jyxbHQ9JvMbbH8BHdlGIxUcWqIvHsg3DHGKcV9iP0NXQ55Dydn VIFCTHKA2QBJXNR1YoflFDiYIm5+mO8SuPFerPzB9BF+myKwdIkD8TtKFcCVKYxfGamy g4WRBpb4E6XaD8kdU1PYIwJbtVwfiU1/4Utg0Nao/g6O4e7FYaEicDEJAj4MFaFvZ0Dx uoaA== X-Gm-Message-State: AJaThX60G9eP6F143Qs4gCh0nwOe5J6CGs5QzMegE6neK7jjMDPGSKDw LosfEsVBi3cW0hqg8JZwhbRIFg== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 04:01:13 -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:14:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 Sat Nov 11 01:35:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F61129449 for ; Sat, 11 Nov 2017 01:35:01 -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=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 QtV6TM0yv3EG for ; Sat, 11 Nov 2017 01:34:58 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD5F129462 for ; Sat, 11 Nov 2017 01:34:58 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id p96so10470124wrb.7 for ; 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=PmGFy3Ok2MzUjvgLrJal6ogWcz9en/Hgb6ceHLWbYLMIY8SLveKFQAthMGVy3Z7TP9 +S0UY2mjm/nEMBFbqDvfdx9/cgO23Tg3JCXa9Jr/Wv5i4XZfNw4sMDCTBlEgG/H6A3oP WntKt2QRx9y9uTk3IqT7oLqp4EetsA0qlU9bF7ZQXL3Fc1rD4TdsfeufQud5rk6vQHfd tIsOroQ2S8cKnaDZh6E/rN9M7lGsPIUGvU5TGAD8nWsRUEphDSRzJ+2yBhgJ510l7SOs UZcBh6SFNVTSX6KnL2V2lQmcMaZfmw06LbOcoAgIH5ZK8FUN7AErr+59hDJGNBbN8wuC bu1A== X-Gm-Message-State: AJaThX4mbnqdP0YoGFQf5rxROVcynSehlvqEn+z1EKBQsgvIQkx/Pc/z XRD7Ud5Ykw2CBTfEABSdpObUkzjK2LhVZktFYSiTSFmKAVk= 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 17:23:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174F31271FD for ; Sat, 11 Nov 2017 17:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_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 AbNX4NkEJr1p for ; Sat, 11 Nov 2017 17:23:45 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3399B1252BA for ; Sat, 11 Nov 2017 17:23:45 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id q80so2401523vkf.2 for ; Sat, 11 Nov 2017 17:23:45 -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=7dmVDmh7Vnq9AcNtSlaSdo3+A9SMYRFTtNatxDhZMSs=; b=eiH9yJAUkX2VF5I3rcw4s3nFcMPWjyHxct3pvH387GuSGkdqQuja9k98aZTTkY5nlT QG28w/az2mBCAqYqvNQdjhgFR1DUcb14RBEe2imD2W2ZjbFog/wMw67UM3XaPWdBex7g WzxQu2Ai4dVCcBD0q4PwvyYjyEwdpg9ssm9DFWnqAbHsbnR8ssiglmR/0Ac+eGlkbccV YLdE6rrP+AzMW59/aefZozma4XvqlKlPMh1xASrVIXTqkh7F2UG3PP/Viy1HyjxK7rQL 7wLgEWeDOCup94uBTA0L6ptUXZyq1o3Ok0QSaOSPz0tayjHASsV433aNJB5ENpSg8gAs /pjQ== 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=7dmVDmh7Vnq9AcNtSlaSdo3+A9SMYRFTtNatxDhZMSs=; b=UFMu/HpQNL/3litzp7M+9U5+b88vHXozwIZsG4mNCE8EUhd3BcDgtVE81WJkgmh93o L1HbrcVWdQBRGIzSPpftrChJKZPZ7q9VSSQl9KPICn0faKjx1NzMSXgBXhvi0CE4449O BcAZKTWf+mBcks4z4GRpZlhDAqJZSvFcCo4ZHv1H8xIqNRGbUg+Hgw4glig/F808kokO 1FHidYZgcDqgIqQsy1d3lXlI6ewXVEFKaLPwtXNeKi2zIo+WCCt+rgONWaAm3MeTAJUq KuHGVabNUiu4oA257pJ6wGq1W07BvgerrmI24RJ5ojKP2WL1njZQXQt6uBvQ5OoKC/Xv 8gPg== X-Gm-Message-State: AJaThX7cEvx8ar7ZvtslMTIbwys5JKURsS/l7EgT4xrXuCtSFgWhuB6j 7hFV3/PYfXWylXuZ9idO5l0z1kn5ZxvK60RqtpM= X-Google-Smtp-Source: AGs4zMZ5RFe4A+fcKS1fRohxd4b6ig9nbgCVFW4Ixe+Fl+LJcs2c7oSXG/OqtSrAetw4uSxouhshTDiQrGLd0wZNLLs= X-Received: by 10.31.165.214 with SMTP id o205mr3813677vke.147.1510449824078; Sat, 11 Nov 2017 17:23:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Sat, 11 Nov 2017 17:23:13 -0800 (PST) In-Reply-To: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> From: Mark Smith Date: Sun, 12 Nov 2017 12:23:13 +1100 Message-ID: To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" Cc: Tom Herbert , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 01:23:48 -0000 Hi Gunter, On 8 November 2017 at 16:05, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: > There few other drawbacks that we considered when we selected to use Flow= -label instead of an EH solution for SRv6 alternate marking: > > * easier backward compatibility because nothing breaks if a transit route= r does not have the capability of understanding the Flow label context... i= n that case the flow-label in the outer tunnel header is just a flow-label > * Having a HbH EH seems less backward compatible, and will be less easy t= o use unless ALL routers in the domain support these type of headers in the= fast-path... it just seems complex because of all the if-then-but involved= to implement, use and operate... I think that is an advantage of using destination addresses to encode this processing. In addition to identifying a host, I think in IP a destination address is also and more fundamentally identifying an exit point from the forwarding domain. It indicates where processing for forwarding to the DA stops, and where other more complex processing of the packet is to occur, using information past the fixed IP header, and likely in the payload. Processing of the IPv6 Routing Header EH, or information in the payload e.g. transport and further upper layer processing are examples. Using the DA to encode this more complex processing means that it is easy to retrofit into existing devices and models. There is no need to replace existing IPv6 forwarding devices, because they already support DA based forwarding. An SR box with the DA could be hung off the side of an existing router, do its magic, and then resubmit the newly SR processed packet back into the conventional forwarding domain, to be forwarded onto the next SR box that owns the specified DA (Inspired by how Ipsilon Networks added IP forwarding to ATM networks). > * For HW based routers (i.e. in Nokia case having user-plane switching ca= pability scale of 2.8T per NPU) the support nearly comes for free as suppor= t is already there... nothing extra is needed from a nodal perspective > * Less bits on the wire... going SRv6 has already a significant bits-on-w= ire tax because of the outer IPv6 header and the SRv6 EH and all the source= routing headers > "Scrounging" bits from other fields because the SRv6 header has become large seems to be trying to avoid fixing the problem where it is caused. I'd guess a lot of this size has come from the use of 128 bit IPv6 addresses to identify segments. I think a question is do they really need to be that large? I thought about per-packet overhead in the context of IPv6 tunnelling a few years ago. It occurred to me that if tunnel end-points were identified using /64s rather than /128s, then the IID parts of the outer IPv6 source and destination addresses could be used for something else. If those other things came from the inner packet, then they could be removed from the inner packet, reducing the effective tunnelling overhead. I wrote up some of those ideas in "Enhancing Virtual Network Encapsulation with IPv6" (https://tools.ietf.org/html/draft-smith-enhance-vne-with-ipv6-07). More recently I took the next step and developed a tunnelling method, although the savings weren't quite as high as I'd hoped due to the 8 octet minimum size requirement of an Extension Header - "Skinny IPv6 in IPv6 Tunnelling" (https://tools.ietf.org/html/draft-smith-skinny-ipv6-in-ipv6-tunnelling-00) IPv6 networks have a lot of /64s. In this draft's scenario, ULA addressing should be being used for the outer header addressing to minimise leaking. ULA /48s have 65K /64s, and if that isn't enough, multiple ULA /48 prefixes can be used to generate more /64s. It would be a significant change to SR at this time I'd suspect, however I think using /64s as Segment IDs rather than /128s would make a significant SRH size overhead saving, avoiding the need to try to leverage other non-SR fields, such as the Flow Label, for SR or related information. Regards, Mark. > So, indeed a new type of EH may be a solution space proposal, however, I = do not think it is as pragmatic as using the flow-label in the outer IPv6 S= Rv6 header because of all the benefits flow-label usage gives. The Flow-lab= el proposal, is basically something that routers can do right now, and it = does not break any IPv6 rules and is expected to be supported in line-rate = by the fast path switching of routers by default. > > Indeed she solution proposed in the draft, is for the moment assumed to b= e exclusive from other usages (with exception of entropy) of the flow-label= in the controlled operator domain... it does not necessary have to be excl= usive, but it seems the most pragmatic. Currently, operator traditionally d= o not use flow-label at all, hence the above assumption seems reasonable. > > G/ > > > -----Original Message----- > From: Tom Herbert [mailto:tom@herbertland.com] > Sent: Tuesday, November 7, 2017 23:28 > To: Van De Velde, Gunter (Nokia - BE/Antwerp) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spri= ng-flow-label-alt-mark-01.txt > > On Tue, Nov 7, 2017 at 11:53 AM, Van De Velde, Gunter (Nokia - > BE/Antwerp) wrote: >> Hi Tom, >> >> The closed system here is defined by the SRv6 tunnels=E2=80=A6 The flow-= label is set =E2=80=9Conly=E2=80=9D by the tunnel head-end router =E2=80=9C= on the outer IPv6 header=E2=80=9D. The tunnel head-end router can do this b= ecause it is the device that created the outer IP header. >> The original IPv6 packet is riding inside the tunnel, and as result >> the original flow label and original IPv6 header is left untouched. The = closed system is the network between the tunnel head-end (=3Dwhere the oute= r IPv6 header is added) and the tunnel tail-end (=3Dwhere the outer header = is removed). This type of closed system is easy to deploy=E2=80=A6 take for= example a MPLS/VPN backbone=E2=80=A6. Or a VxLAN network=E2=80=A6 The SRv6= network is something of similar simplicity. >> >> The IPv6 device that generates an IPv6 packet can set the flow label, an= d that is what devices have been doing all the time. This draft proposes no= thing new from that perspective. >> >> Why do you say =E2=80=98repurposing=E2=80=99 the bits? Nothing is repurp= osed. This proposal is respecting RFC6437. In our informational proposal th= e flow-label just remains flow-label. Routers can be made to match upon flo= w-label values easily. I know my Nokia products can do that very easily, be= cause the flow-label is always found at the same place in the IPv6 header. = However, checking on EHs is a few dimensions more complicated. When I must = make my router match for content in EHs, then first it must check if the re= levant EH is inserted, then the corresponding EH must be identified and the= n the content has to be checked=E2=80=A6 This EH checking is non-trivial as= result=E2=80=A6 For a HW based router (my Nokia router for example) the ch= ecking of flow-label is as simple as checking for a DSCP value because the = operation involved is exactly the same. > > I don't believe the EH processing needs to be complicated. In this case t= he assumption is that network operator is inserting the headers so the HBH = EH with a latency measurement option could be implemented to always be in t= he same position, have the same length, and only set with one option for la= tency. The router processingcan be optimized to handle this case. Existence= and verification of the EH can all be done with simple checks and TCAM cou= ld be used to match the common header pattern. The IP header and extension = header should fit well within the parsing buffer of typical routers. > >> >> Tom, if your additional suggestions for using flow labels is respecting = RFC6437 then what stops you from documenting those thoughts? The alternate = marking principle documented in this draft for SRv6 is something that is dr= iven by operator themselves, and is based upon real operator requirement. F= eel free to further discuss with the Telekom Italia co-authors (Guiseppe an= d Mauro) on TI needs for such passive measurement mechanism (loss, latency,= jitter, etc). > > The fact that operators want passive latency measurements is not the same= as saying that applying a format to the flow label is a requirement. It is= the mechanism of this proposal this is in question. > > Tom > > >> >> G/ >> >> >> >> On 07/11/2017, 19:14, "Tom Herbert" wrote: >> >> On Tue, Nov 7, 2017 at 9:13 AM, Van De Velde, Gunter (Nokia - >> BE/Antwerp) wrote: >> > To me it seems that looking at FL is much easier for a HW based >> router then looking at EHs in a hop-by-hop fashion=E2=80=A6 >> >> Easier for whom? Repurposing bits in the IP header even for a narrow >> use case in a closed system doesn't seem particularly easy to >> standardize or deploy. As Mark pointed out there's a lot of complexi= ty >> around ensuring that the system really is closed and all required >> behavior is maintained. >> >> Another obvious question with this approach is does it mean that flo= w >> label bits are now fair game to be defined for even more purposes? >> Latency measurement isn't be the only potential use case. For >> instance, I know there's a lot of people that want hosts to mark >> packets with a "retransmitted" bit so that routers can keep stats fo= r >> tracked flows. IMO, if using flow bits like this is the right answer >> then there should be a generic protocol specification that defines t= he >> operation and how bits are allocated for all the potential uses. >> >> Tom >> >> > >> > G/ >> > >> > On 07/11/2017, 17:58, "Tom Herbert" wrote: >> > >> > On Tue, Nov 7, 2017 at 7:26 AM, Van De Velde, Gunter (Nokia - >> > BE/Antwerp) wrote: >> > > A transit router does not look at EHs if it is not configure= d for the IPv6 Destination address.. so its not usable in that case. >> > > >> > They do look at hop-by-hop options. Previously it was required= that >> > all nodes in the path must process them, but that was relaxed = a bit in >> > RFC8200. If they are only used for tunneling across a controll= ed >> > domain then the typical concern that intermediate nodes don't = properly >> > handle hop-by-hop options can be addressed. >> > >> > Tom >> > >> > > G/ >> > > >> > > -----Original Message----- >> > > From: Tom Herbert [mailto:tom@herbertland.com] >> > > Sent: Tuesday, November 7, 2017 16:16 >> > > To: Van De Velde, Gunter (Nokia - BE/Antwerp) >> > > Cc: v6ops@ietf.org >> > > Subject: Re: [v6ops] FW: New Version Notification for draft-= fioccola-spring-flow-label-alt-mark-01.txt >> > > >> > > On Mon, Nov 6, 2017 at 10:44 PM, Van De Velde, Gunter (Nokia= - >> > > BE/Antwerp) wrote: >> > >> Hi Tom, >> > >> >> > >> --> >> > >> From section 1: >> > >> >> > >> "Based on these considerations, it is allowed to use the fl= ow label field in a managed domain, assuming when a packet leaves the domai= n, the original flow label value MUST be restored." >> > >> >> > >> In this proposal, if two bits are overwritten by an interme= diate node, how are their original values restored when leaving the domain? >> > >> --> >> > >> >> > >> GV> Because the field that are being fiddled with are on t= he IPv6 SRv6 outer encapsulation header. When the original packet leaves th= e controlled domain, then that header is removed again, and the original IP= v6 packet with original headers appear again. >> > >> >> > > Gunter, >> > > >> > > If the measurements are always coincident with the use of SR= v6 then why not put the measurement information in the SR EH or some other = EH (hop-by-hop or est opt maybe) used only in the controlled domain? This a= lso could be more flexible since the algorithm wouldn't be constrained to j= ust two bits of data. >> > > >> > > Tom >> > >> > >> >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Nov 11 17:54:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:33:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BDC124BFA for ; Sat, 11 Nov 2017 18:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM20sLUwZ_Ih for ; Sat, 11 Nov 2017 18:32:56 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0111.outbound.protection.outlook.com [104.47.2.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6867E128B90 for ; Sat, 11 Nov 2017 18:32:55 -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=Fr7NUNrPLHb0nh3w8vHIycLtN1QQ7Pe6lpIbuIG1/gY=; b=DbX6sRRideOHmx9NIJUImgi48rDIZGhnIIe+s0WILyXAcM8j2zekX2QAkg7qUWKagH1l9scg/+2T7dk4ERPW4BKSxGjijaN9ZJlLHEDoLOvjHPvPmzuXVL+qzuU5yzO7TJ/IwZ34l8KN+xGqXk+BEcfs0m3kEz7VVYiTpo0KqEA= 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; Sun, 12 Nov 2017 02:32:52 +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; Sun, 12 Nov 2017 02:32:52 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Mark Smith CC: Tom Herbert , "v6ops@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYwgACbq4CAAFvKQIAAj8qAgAACmRCAABn/gIAABDIAgAARHYCAABuOgIAAK0qAgABp9BCABhA2gIAAEcfQ Date: Sun, 12 Nov 2017 02:32:52 +0000 Message-ID: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [203.116.99.163] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2835; 6:YqSpW5lHYe0tFI+K8EEyFWq8fLrqrqPjRPkr/tsYTYm0URIHYbfbLy0DfLcV7rhgQHPjwgKgAnfxHlHR9RPmVbNB2/SVHq98lcff6KAgmC6akrJ2Jyr8gzb28hBkgs0LN6SeTWMQwx2f4Iruf8Lu6jXUD7sfyvVBrhX0SXbVqi7gneN4BMxVEIJUDL3oB75sQzB07Eow3P5TswpXCKqEfujeWPLOVrPDSS2s9g7RcV5/3eWJ39Vm4M6480f2tmMqhfcgTvNE0ISWoy0G+03GQ3PZWL12ooIc1/vwiz11jxFira1gMNf6qvGeN3eepxp5NZ3H19Q0i16YLv3a89PO2uggZsHw8mAlJTm/YcNHfZY=; 5:msg5qmSkB/61mw2yN8OpQL1gt5Lw5Wv36asakU0fyDDtlVgFpSGeeV9KmNK+v2zWu35gXF43vi07jRiDy64vMZO5UwCWNYvwsKRyuEWXDPukh7UGgchxaS62kOiTANXc4brq1ckr7nbSAnkwmLZ55BhcEntd2pecaSQ5sNgkn7k=; 24:PVzFnvoEIu7+xzJssmD+NV566dTBg8xTmiterqslTBCYmG8CGbvV7+olmvwrfv/3DD/e06Drc6E28bejyWejsHe0cbhu78eNZkdyu8DD5no=; 7:cV0JpP/fLfEcUKaAO5B2yDHoQF/43EnI+vFRqHIoc9+8oe5nago+iyknM9uy8ahUQXy7dHFEe/zBUlfhx5DiG5qHMCAYbUCzchsQHzlx+osk8InNlu+PgXqSiG59w2s72+JaEAjL4T9DVmxjT3BHv/eAkq7U453AGd5N2Sy3hL3jyA43597U+Iqn1aSLdS0JEqIcBIxuQPhKV00Cc3TSekhu0dyBol5BzLF4bLpjaNJIL00sUmDQTICi4brjC7Zv x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 28bf2fa4-f4e2-4a61-4015-08d52975aca0 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:(82608151540597)(788757137089)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3231022)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(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: 0489CFBAC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(13464003)(199003)(51444003)(189002)(24454002)(50986999)(54356999)(7696004)(25786009)(101416001)(2900100001)(8936002)(4326008)(105586002)(5250100002)(76176999)(68736007)(93886005)(106356001)(102836003)(6116002)(33656002)(229853002)(5660300001)(966005)(3846002)(15650500001)(1411001)(561944003)(8676002)(6436002)(2906002)(6306002)(6506006)(66066001)(97736004)(53936002)(54906003)(9686003)(99286004)(55016002)(6916009)(86362001)(53546010)(7736002)(39060400002)(81156014)(230783001)(3660700001)(74316002)(6246003)(189998001)(3280700002)(2950100002)(305945005)(81166006)(14454004)(316002)(478600001); 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 28bf2fa4-f4e2-4a61-4015-08d52975aca0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2017 02:32:52.6107 (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: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 02:32:59 -0000 SW4gU1J2NiB3ZSBoYWQgc2ltaWxhciBvbiB0aGUgcmVhbGl0eSBvZiB0aGUgbmVlZCBvZiAxMjgg Yml0cyB2cyA2NCBiaXRzIGluc2lkZSB0aGUgU1JIIGhlYWRlci4uLi4gSXQgd2FzIHN0cm9uZ2x5 IG9wcG9zZWQgYnkgdGhlIGVkaXRvcnMgb2YgdGhlIFNSdjYgZGF0YXBsYW5lIGRyYWZ0LiBSZWFz b24gd2FzIHRoYXQgaXQgZGlkIG5vdCBwcm92aWRlcyB0aGUgc2FtZSBjYXBhYmlsaXR5IG9mIHVu aXF1ZWx5IGlkZW50aWZ5aW5nIGEgc2luZ2xlIHN5c3RlbS4NCg0KSSB0aGluayBpdCBpcyBhIGdv b2QgcXVlc3Rpb24gdG8gYXNrIGFuZCBhIHZhbGlkIG9wdGltaXphdGlvbiBmb3IgYSByYW5nZSBv ZiB1c2UtY2FzZXMuIFF1ZXN0aW9uIGlzIGlmIHRoZSB1c2UtY2FzZXMgYXJlIHN0cm9uZyBlbm91 Z2ggdG8ganVzdGlmeSB0aGUgcGVyY2VpdmVkIGJlbmVmaXRzIG9mIDEyOCBiaXRzIHZzIDY0IGJp dHMuIFRoaXMgaXMgYSBkaXNjdXNzaW9uIHRvIGhhdmUgaW4gU1BSSU5HIHdnIGlmIHRoYXQgaXMg c29tZXRoaW5nIHRoYXQgaXMgZm91bmQgd29ydGh5IGEgZGlzY3Vzc2lvbg0KDQpHLw0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJrIFNtaXRoIFttYWlsdG86bWFya3p6 enNtaXRoQGdtYWlsLmNvbV0gDQpTZW50OiBTdW5kYXksIE5vdmVtYmVyIDEyLCAyMDE3IDA5OjIz DQpUbzogVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkgPGd1bnRlci52 YW5fZGVfdmVsZGVAbm9raWEuY29tPg0KQ2M6IFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVydGxhbmQu Y29tPjsgdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIEZXOiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFsdC1t YXJrLTAxLnR4dA0KDQpIaSBHdW50ZXIsDQoNCk9uIDggTm92ZW1iZXIgMjAxNyBhdCAxNjowNSwg VmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkgPGd1bnRlci52YW5fZGVf dmVsZGVAbm9raWEuY29tPiB3cm90ZToNCj4gVGhlcmUgZmV3IG90aGVyIGRyYXdiYWNrcyB0aGF0 IHdlIGNvbnNpZGVyZWQgd2hlbiB3ZSBzZWxlY3RlZCB0byB1c2UgRmxvdy1sYWJlbCBpbnN0ZWFk IG9mIGFuIEVIIHNvbHV0aW9uIGZvciBTUnY2IGFsdGVybmF0ZSBtYXJraW5nOg0KPg0KPiAqIGVh c2llciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGJlY2F1c2Ugbm90aGluZyBicmVha3MgaWYgYSB0 cmFuc2l0IA0KPiByb3V0ZXIgZG9lcyBub3QgaGF2ZSB0aGUgY2FwYWJpbGl0eSBvZiB1bmRlcnN0 YW5kaW5nIHRoZSBGbG93IGxhYmVsIA0KPiBjb250ZXh0Li4uIGluIHRoYXQgY2FzZSB0aGUgZmxv dy1sYWJlbCBpbiB0aGUgb3V0ZXIgdHVubmVsIGhlYWRlciBpcyANCj4ganVzdCBhIGZsb3ctbGFi ZWwNCj4gKiBIYXZpbmcgYSBIYkggRUggc2VlbXMgbGVzcyBiYWNrd2FyZCBjb21wYXRpYmxlLCBh bmQgd2lsbCBiZSBsZXNzIGVhc3kgdG8gdXNlIHVubGVzcyBBTEwgcm91dGVycyBpbiB0aGUgZG9t YWluIHN1cHBvcnQgdGhlc2UgdHlwZSBvZiBoZWFkZXJzIGluIHRoZSBmYXN0LXBhdGguLi4gaXQg anVzdCBzZWVtcyBjb21wbGV4IGJlY2F1c2Ugb2YgYWxsIHRoZSBpZi10aGVuLWJ1dCBpbnZvbHZl ZCB0byBpbXBsZW1lbnQsIHVzZSBhbmQgb3BlcmF0ZS4uLg0KDQpJIHRoaW5rIHRoYXQgaXMgYW4g YWR2YW50YWdlIG9mIHVzaW5nIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyB0byBlbmNvZGUgdGhpcyBw cm9jZXNzaW5nLg0KDQpJbiBhZGRpdGlvbiB0byBpZGVudGlmeWluZyBhIGhvc3QsIEkgdGhpbmsg aW4gSVAgYSBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIGFsc28gYW5kIG1vcmUgZnVuZGFtZW50YWxs eSBpZGVudGlmeWluZyBhbiBleGl0IHBvaW50IGZyb20gdGhlIGZvcndhcmRpbmcgZG9tYWluLiBJ dCBpbmRpY2F0ZXMgd2hlcmUgcHJvY2Vzc2luZyBmb3IgZm9yd2FyZGluZyB0byB0aGUgREEgc3Rv cHMsIGFuZCB3aGVyZSBvdGhlciBtb3JlIGNvbXBsZXggcHJvY2Vzc2luZyBvZiB0aGUgcGFja2V0 IGlzIHRvIG9jY3VyLCB1c2luZyBpbmZvcm1hdGlvbiBwYXN0IHRoZSBmaXhlZCBJUCBoZWFkZXIs IGFuZCBsaWtlbHkgaW4gdGhlIHBheWxvYWQuIFByb2Nlc3Npbmcgb2YgdGhlIElQdjYgUm91dGlu ZyBIZWFkZXIgRUgsIG9yIGluZm9ybWF0aW9uIGluIHRoZSBwYXlsb2FkIGUuZy4gdHJhbnNwb3J0 IGFuZCBmdXJ0aGVyIHVwcGVyIGxheWVyIHByb2Nlc3NpbmcgYXJlIGV4YW1wbGVzLg0KDQpVc2lu ZyB0aGUgREEgdG8gZW5jb2RlIHRoaXMgbW9yZSBjb21wbGV4IHByb2Nlc3NpbmcgbWVhbnMgdGhh dCBpdCBpcyBlYXN5IHRvIHJldHJvZml0IGludG8gZXhpc3RpbmcgZGV2aWNlcyBhbmQgbW9kZWxz LiBUaGVyZSBpcyBubyBuZWVkIHRvIHJlcGxhY2UgZXhpc3RpbmcgSVB2NiBmb3J3YXJkaW5nIGRl dmljZXMsIGJlY2F1c2UgdGhleSBhbHJlYWR5IHN1cHBvcnQgREEgYmFzZWQgZm9yd2FyZGluZy4g QW4gU1IgYm94IHdpdGggdGhlIERBIGNvdWxkIGJlIGh1bmcgb2ZmIHRoZSBzaWRlIG9mIGFuIGV4 aXN0aW5nIHJvdXRlciwgZG8gaXRzIG1hZ2ljLCBhbmQgdGhlbiByZXN1Ym1pdCB0aGUgbmV3bHkg U1IgcHJvY2Vzc2VkIHBhY2tldCBiYWNrIGludG8gdGhlIGNvbnZlbnRpb25hbCBmb3J3YXJkaW5n IGRvbWFpbiwgdG8gYmUgZm9yd2FyZGVkIG9udG8gdGhlIG5leHQgU1IgYm94IHRoYXQgb3ducyB0 aGUgc3BlY2lmaWVkIERBIChJbnNwaXJlZCBieSBob3cgSXBzaWxvbiBOZXR3b3JrcyBhZGRlZCBJ UCBmb3J3YXJkaW5nIHRvIEFUTSBuZXR3b3JrcykuDQoNCg0KPiAqIEZvciBIVyBiYXNlZCByb3V0 ZXJzIChpLmUuIGluIE5va2lhIGNhc2UgaGF2aW5nIHVzZXItcGxhbmUgc3dpdGNoaW5nIA0KPiBj YXBhYmlsaXR5IHNjYWxlIG9mIDIuOFQgcGVyIE5QVSkgdGhlIHN1cHBvcnQgbmVhcmx5IGNvbWVz IGZvciBmcmVlIGFzIA0KPiBzdXBwb3J0IGlzIGFscmVhZHkgdGhlcmUuLi4gbm90aGluZyBleHRy YSBpcyBuZWVkZWQgZnJvbSBhIG5vZGFsIA0KPiBwZXJzcGVjdGl2ZQ0KPiAqIExlc3MgYml0cyBv biB0aGUgd2lyZS4uLiBnb2luZyBTUnY2IGhhcyBhbHJlYWR5IGEgc2lnbmlmaWNhbnQgDQo+IGJp dHMtb24td2lyZSB0YXggYmVjYXVzZSBvZiB0aGUgb3V0ZXIgSVB2NiBoZWFkZXIgYW5kIHRoZSBT UnY2IEVIIGFuZCANCj4gYWxsIHRoZSBzb3VyY2Ugcm91dGluZyBoZWFkZXJzDQo+DQoNCiJTY3Jv dW5naW5nIiBiaXRzIGZyb20gb3RoZXIgZmllbGRzIGJlY2F1c2UgdGhlIFNSdjYgaGVhZGVyIGhh cyBiZWNvbWUgbGFyZ2Ugc2VlbXMgdG8gYmUgdHJ5aW5nIHRvIGF2b2lkIGZpeGluZyB0aGUgcHJv YmxlbSB3aGVyZSBpdCBpcyBjYXVzZWQuDQoNCkknZCBndWVzcyBhIGxvdCBvZiB0aGlzIHNpemUg aGFzIGNvbWUgZnJvbSB0aGUgdXNlIG9mIDEyOCBiaXQgSVB2NiBhZGRyZXNzZXMgdG8gaWRlbnRp Znkgc2VnbWVudHMuIEkgdGhpbmsgYSBxdWVzdGlvbiBpcyBkbyB0aGV5IHJlYWxseSBuZWVkIHRv IGJlIHRoYXQgbGFyZ2U/DQoNCkkgdGhvdWdodCBhYm91dCBwZXItcGFja2V0IG92ZXJoZWFkIGlu IHRoZSBjb250ZXh0IG9mIElQdjYgdHVubmVsbGluZyBhIGZldyB5ZWFycyBhZ28uIEl0IG9jY3Vy cmVkIHRvIG1lIHRoYXQgaWYgdHVubmVsIGVuZC1wb2ludHMgd2VyZSBpZGVudGlmaWVkIHVzaW5n IC82NHMgcmF0aGVyIHRoYW4gLzEyOHMsIHRoZW4gdGhlIElJRCBwYXJ0cyBvZiB0aGUgb3V0ZXIg SVB2NiBzb3VyY2UgYW5kIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyBjb3VsZCBiZSB1c2VkIGZvciBz b21ldGhpbmcgZWxzZS4gSWYgdGhvc2Ugb3RoZXIgdGhpbmdzIGNhbWUgZnJvbSB0aGUgaW5uZXIg cGFja2V0LCB0aGVuIHRoZXkgY291bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBpbm5lciBwYWNrZXQs IHJlZHVjaW5nIHRoZSBlZmZlY3RpdmUgdHVubmVsbGluZyBvdmVyaGVhZC4NCg0KSSB3cm90ZSB1 cCBzb21lIG9mIHRob3NlIGlkZWFzIGluICJFbmhhbmNpbmcgVmlydHVhbCBOZXR3b3JrIEVuY2Fw c3VsYXRpb24gd2l0aCBJUHY2Ig0KKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z bWl0aC1lbmhhbmNlLXZuZS13aXRoLWlwdjYtMDcpLg0KTW9yZSByZWNlbnRseSBJIHRvb2sgdGhl IG5leHQgc3RlcCBhbmQgZGV2ZWxvcGVkIGEgdHVubmVsbGluZyBtZXRob2QsIGFsdGhvdWdoIHRo ZSBzYXZpbmdzIHdlcmVuJ3QgcXVpdGUgYXMgaGlnaCBhcyBJJ2QgaG9wZWQgZHVlIHRvIHRoZSA4 IG9jdGV0IG1pbmltdW0gc2l6ZSByZXF1aXJlbWVudCBvZiBhbiBFeHRlbnNpb24gSGVhZGVyIC0g IlNraW5ueSBJUHY2IGluIElQdjYgVHVubmVsbGluZyINCihodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtc21pdGgtc2tpbm55LWlwdjYtaW4taXB2Ni10dW5uZWxsaW5nLTAwKQ0KDQpJ UHY2IG5ldHdvcmtzIGhhdmUgYSBsb3Qgb2YgLzY0cy4gSW4gdGhpcyBkcmFmdCdzIHNjZW5hcmlv LCBVTEEgYWRkcmVzc2luZyBzaG91bGQgYmUgYmVpbmcgdXNlZCBmb3IgdGhlIG91dGVyIGhlYWRl ciBhZGRyZXNzaW5nIHRvIG1pbmltaXNlIGxlYWtpbmcuIFVMQSAvNDhzIGhhdmUgNjVLIC82NHMs IGFuZCBpZiB0aGF0IGlzbid0IGVub3VnaCwgbXVsdGlwbGUgVUxBIC80OCBwcmVmaXhlcyBjYW4g YmUgdXNlZCB0byBnZW5lcmF0ZSBtb3JlIC82NHMuDQoNCkl0IHdvdWxkIGJlIGEgc2lnbmlmaWNh bnQgY2hhbmdlIHRvIFNSIGF0IHRoaXMgdGltZSBJJ2Qgc3VzcGVjdCwgaG93ZXZlciBJIHRoaW5r IHVzaW5nIC82NHMgYXMgU2VnbWVudCBJRHMgcmF0aGVyIHRoYW4gLzEyOHMgd291bGQgbWFrZSBh IHNpZ25pZmljYW50IFNSSCBzaXplIG92ZXJoZWFkIHNhdmluZywgYXZvaWRpbmcgdGhlIG5lZWQg dG8gdHJ5IHRvIGxldmVyYWdlIG90aGVyIG5vbi1TUiBmaWVsZHMsIHN1Y2ggYXMgdGhlIEZsb3cg TGFiZWwsICBmb3IgU1Igb3IgcmVsYXRlZCBpbmZvcm1hdGlvbi4NCg0KUmVnYXJkcywNCk1hcmsu DQoNCg0KPiBTbywgaW5kZWVkIGEgbmV3IHR5cGUgb2YgRUggbWF5IGJlIGEgc29sdXRpb24gc3Bh Y2UgcHJvcG9zYWwsIGhvd2V2ZXIsIEkgZG8gbm90IHRoaW5rIGl0IGlzIGFzIHByYWdtYXRpYyBh cyB1c2luZyB0aGUgZmxvdy1sYWJlbCBpbiB0aGUgb3V0ZXIgSVB2NiBTUnY2IGhlYWRlciBiZWNh dXNlIG9mIGFsbCB0aGUgYmVuZWZpdHMgZmxvdy1sYWJlbCB1c2FnZSBnaXZlcy4gVGhlIEZsb3ct bGFiZWwgcHJvcG9zYWwsIGlzIGJhc2ljYWxseSBzb21ldGhpbmcgdGhhdCByb3V0ZXJzIGNhbiBk byByaWdodCBub3csICBhbmQgaXQgZG9lcyBub3QgYnJlYWsgYW55IElQdjYgcnVsZXMgYW5kIGlz IGV4cGVjdGVkIHRvIGJlIHN1cHBvcnRlZCBpbiBsaW5lLXJhdGUgYnkgdGhlIGZhc3QgcGF0aCBz d2l0Y2hpbmcgb2Ygcm91dGVycyBieSBkZWZhdWx0Lg0KPg0KPiBJbmRlZWQgc2hlIHNvbHV0aW9u IHByb3Bvc2VkIGluIHRoZSBkcmFmdCwgaXMgZm9yIHRoZSBtb21lbnQgYXNzdW1lZCB0byBiZSBl eGNsdXNpdmUgZnJvbSBvdGhlciB1c2FnZXMgKHdpdGggZXhjZXB0aW9uIG9mIGVudHJvcHkpIG9m IHRoZSBmbG93LWxhYmVsIGluIHRoZSBjb250cm9sbGVkIG9wZXJhdG9yIGRvbWFpbi4uLiBpdCBk b2VzIG5vdCBuZWNlc3NhcnkgaGF2ZSB0byBiZSBleGNsdXNpdmUsIGJ1dCBpdCBzZWVtcyB0aGUg bW9zdCBwcmFnbWF0aWMuIEN1cnJlbnRseSwgb3BlcmF0b3IgdHJhZGl0aW9uYWxseSBkbyBub3Qg dXNlIGZsb3ctbGFiZWwgYXQgYWxsLCBoZW5jZSB0aGUgYWJvdmUgYXNzdW1wdGlvbiBzZWVtcyBy ZWFzb25hYmxlLg0KPg0KPiBHLw0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb21dDQo+IFNlbnQ6 IFR1ZXNkYXksIE5vdmVtYmVyIDcsIDIwMTcgMjM6MjgNCj4gVG86IFZhbiBEZSBWZWxkZSwgR3Vu dGVyIChOb2tpYSAtIEJFL0FudHdlcnApIA0KPiA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5j b20+DQo+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBGVzogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ct bGFiZWwtYWx0LW1hcmstMDEudHh0DQo+DQo+IE9uIFR1ZSwgTm92IDcsIDIwMTcgYXQgMTE6NTMg QU0sIFZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtDQo+IEJFL0FudHdlcnApIDxndW50ZXIu dmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4gd3JvdGU6DQo+PiBIaSBUb20sDQo+Pg0KPj4gVGhlIGNs b3NlZCBzeXN0ZW0gaGVyZSBpcyBkZWZpbmVkIGJ5IHRoZSBTUnY2IHR1bm5lbHPigKYgVGhlIGZs b3ctbGFiZWwgaXMgc2V0IOKAnG9ubHnigJ0gYnkgdGhlIHR1bm5lbCBoZWFkLWVuZCByb3V0ZXIg 4oCcb24gdGhlIG91dGVyIElQdjYgaGVhZGVy4oCdLiBUaGUgdHVubmVsIGhlYWQtZW5kIHJvdXRl ciBjYW4gZG8gdGhpcyBiZWNhdXNlIGl0IGlzIHRoZSBkZXZpY2UgdGhhdCBjcmVhdGVkIHRoZSBv dXRlciBJUCBoZWFkZXIuDQo+PiBUaGUgb3JpZ2luYWwgSVB2NiBwYWNrZXQgaXMgcmlkaW5nIGlu c2lkZSB0aGUgdHVubmVsLCBhbmQgYXMgcmVzdWx0IA0KPj4gdGhlIG9yaWdpbmFsIGZsb3cgbGFi ZWwgYW5kIG9yaWdpbmFsIElQdjYgaGVhZGVyIGlzIGxlZnQgdW50b3VjaGVkLiBUaGUgY2xvc2Vk IHN5c3RlbSBpcyB0aGUgbmV0d29yayBiZXR3ZWVuIHRoZSB0dW5uZWwgaGVhZC1lbmQgKD13aGVy ZSB0aGUgb3V0ZXIgSVB2NiBoZWFkZXIgaXMgYWRkZWQpIGFuZCB0aGUgdHVubmVsIHRhaWwtZW5k ICg9d2hlcmUgdGhlIG91dGVyIGhlYWRlciBpcyByZW1vdmVkKS4gVGhpcyB0eXBlIG9mIGNsb3Nl ZCBzeXN0ZW0gaXMgZWFzeSB0byBkZXBsb3nigKYgdGFrZSBmb3IgZXhhbXBsZSBhIE1QTFMvVlBO IGJhY2tib25l4oCmLiBPciBhIFZ4TEFOIG5ldHdvcmvigKYgVGhlIFNSdjYgbmV0d29yayBpcyBz b21ldGhpbmcgb2Ygc2ltaWxhciBzaW1wbGljaXR5Lg0KPj4NCj4+IFRoZSBJUHY2IGRldmljZSB0 aGF0IGdlbmVyYXRlcyBhbiBJUHY2IHBhY2tldCBjYW4gc2V0IHRoZSBmbG93IGxhYmVsLCBhbmQg dGhhdCBpcyB3aGF0IGRldmljZXMgaGF2ZSBiZWVuIGRvaW5nIGFsbCB0aGUgdGltZS4gVGhpcyBk cmFmdCBwcm9wb3NlcyBub3RoaW5nIG5ldyBmcm9tIHRoYXQgcGVyc3BlY3RpdmUuDQo+Pg0KPj4g V2h5IGRvIHlvdSBzYXkg4oCYcmVwdXJwb3NpbmfigJkgdGhlIGJpdHM/IE5vdGhpbmcgaXMgcmVw dXJwb3NlZC4gVGhpcyBwcm9wb3NhbCBpcyByZXNwZWN0aW5nIFJGQzY0MzcuIEluIG91ciBpbmZv cm1hdGlvbmFsIHByb3Bvc2FsIHRoZSBmbG93LWxhYmVsIGp1c3QgcmVtYWlucyBmbG93LWxhYmVs LiBSb3V0ZXJzIGNhbiBiZSBtYWRlIHRvIG1hdGNoIHVwb24gZmxvdy1sYWJlbCB2YWx1ZXMgZWFz aWx5LiBJIGtub3cgbXkgTm9raWEgcHJvZHVjdHMgY2FuIGRvIHRoYXQgdmVyeSBlYXNpbHksIGJl Y2F1c2UgdGhlIGZsb3ctbGFiZWwgaXMgYWx3YXlzIGZvdW5kIGF0IHRoZSBzYW1lIHBsYWNlIGlu IHRoZSBJUHY2IGhlYWRlci4gSG93ZXZlciwgY2hlY2tpbmcgb24gRUhzIGlzIGEgZmV3IGRpbWVu c2lvbnMgbW9yZSBjb21wbGljYXRlZC4gV2hlbiBJIG11c3QgbWFrZSBteSByb3V0ZXIgbWF0Y2gg Zm9yIGNvbnRlbnQgaW4gRUhzLCB0aGVuIGZpcnN0IGl0IG11c3QgY2hlY2sgaWYgdGhlIHJlbGV2 YW50IEVIIGlzIGluc2VydGVkLCB0aGVuIHRoZSBjb3JyZXNwb25kaW5nIEVIIG11c3QgYmUgaWRl bnRpZmllZCBhbmQgdGhlbiB0aGUgY29udGVudCBoYXMgdG8gYmUgY2hlY2tlZOKApiBUaGlzIEVI IGNoZWNraW5nIGlzIG5vbi10cml2aWFsIGFzIHJlc3VsdOKApiBGb3IgYSBIVyBiYXNlZCByb3V0 ZXIgKG15IE5va2lhIHJvdXRlciBmb3IgZXhhbXBsZSkgdGhlIGNoZWNraW5nIG9mIGZsb3ctbGFi ZWwgaXMgYXMgc2ltcGxlIGFzIGNoZWNraW5nIGZvciBhIERTQ1AgdmFsdWUgYmVjYXVzZSB0aGUg b3BlcmF0aW9uIGludm9sdmVkIGlzIGV4YWN0bHkgdGhlIHNhbWUuDQo+DQo+IEkgZG9uJ3QgYmVs aWV2ZSB0aGUgRUggcHJvY2Vzc2luZyBuZWVkcyB0byBiZSBjb21wbGljYXRlZC4gSW4gdGhpcyBj YXNlIHRoZSBhc3N1bXB0aW9uIGlzIHRoYXQgbmV0d29yayBvcGVyYXRvciBpcyBpbnNlcnRpbmcg dGhlIGhlYWRlcnMgc28gdGhlIEhCSCBFSCB3aXRoIGEgbGF0ZW5jeSBtZWFzdXJlbWVudCBvcHRp b24gY291bGQgYmUgaW1wbGVtZW50ZWQgdG8gYWx3YXlzIGJlIGluIHRoZSBzYW1lIHBvc2l0aW9u LCBoYXZlIHRoZSBzYW1lIGxlbmd0aCwgYW5kIG9ubHkgc2V0IHdpdGggb25lIG9wdGlvbiBmb3Ig bGF0ZW5jeS4gVGhlIHJvdXRlciBwcm9jZXNzaW5nY2FuIGJlIG9wdGltaXplZCB0byBoYW5kbGUg dGhpcyBjYXNlLiBFeGlzdGVuY2UgYW5kIHZlcmlmaWNhdGlvbiBvZiB0aGUgRUggY2FuIGFsbCBi ZSBkb25lIHdpdGggc2ltcGxlIGNoZWNrcyBhbmQgVENBTSBjb3VsZCBiZSB1c2VkIHRvIG1hdGNo IHRoZSBjb21tb24gaGVhZGVyIHBhdHRlcm4uIFRoZSBJUCBoZWFkZXIgYW5kIGV4dGVuc2lvbiBo ZWFkZXIgc2hvdWxkIGZpdCB3ZWxsIHdpdGhpbiB0aGUgcGFyc2luZyBidWZmZXIgb2YgdHlwaWNh bCByb3V0ZXJzLg0KPg0KPj4NCj4+IFRvbSwgaWYgeW91ciBhZGRpdGlvbmFsIHN1Z2dlc3Rpb25z IGZvciB1c2luZyBmbG93IGxhYmVscyBpcyByZXNwZWN0aW5nIFJGQzY0MzcgdGhlbiB3aGF0IHN0 b3BzIHlvdSBmcm9tIGRvY3VtZW50aW5nIHRob3NlIHRob3VnaHRzPyBUaGUgYWx0ZXJuYXRlIG1h cmtpbmcgcHJpbmNpcGxlIGRvY3VtZW50ZWQgaW4gdGhpcyBkcmFmdCBmb3IgU1J2NiBpcyBzb21l dGhpbmcgdGhhdCBpcyBkcml2ZW4gYnkgb3BlcmF0b3IgdGhlbXNlbHZlcywgYW5kIGlzIGJhc2Vk IHVwb24gcmVhbCBvcGVyYXRvciByZXF1aXJlbWVudC4gRmVlbCBmcmVlIHRvIGZ1cnRoZXIgZGlz Y3VzcyB3aXRoIHRoZSBUZWxla29tIEl0YWxpYSBjby1hdXRob3JzIChHdWlzZXBwZSBhbmQgTWF1 cm8pIG9uIFRJIG5lZWRzIGZvciBzdWNoIHBhc3NpdmUgbWVhc3VyZW1lbnQgbWVjaGFuaXNtIChs b3NzLCBsYXRlbmN5LCBqaXR0ZXIsIGV0YykuDQo+DQo+IFRoZSBmYWN0IHRoYXQgb3BlcmF0b3Jz IHdhbnQgcGFzc2l2ZSBsYXRlbmN5IG1lYXN1cmVtZW50cyBpcyBub3QgdGhlIHNhbWUgYXMgc2F5 aW5nIHRoYXQgYXBwbHlpbmcgYSBmb3JtYXQgdG8gdGhlIGZsb3cgbGFiZWwgaXMgYSByZXF1aXJl bWVudC4gSXQgaXMgdGhlIG1lY2hhbmlzbSBvZiB0aGlzIHByb3Bvc2FsIHRoaXMgaXMgaW4gcXVl c3Rpb24uDQo+DQo+IFRvbQ0KPg0KPg0KPj4NCj4+IEcvDQo+Pg0KPj4NCj4+DQo+PiBPbiAwNy8x MS8yMDE3LCAxOToxNCwgIlRvbSBIZXJiZXJ0IiA8dG9tQGhlcmJlcnRsYW5kLmNvbT4gd3JvdGU6 DQo+Pg0KPj4gICAgIE9uIFR1ZSwgTm92IDcsIDIwMTcgYXQgOToxMyBBTSwgVmFuIERlIFZlbGRl LCBHdW50ZXIgKE5va2lhIC0NCj4+ICAgICBCRS9BbnR3ZXJwKSA8Z3VudGVyLnZhbl9kZV92ZWxk ZUBub2tpYS5jb20+IHdyb3RlOg0KPj4gICAgID4gVG8gbWUgaXQgc2VlbXMgdGhhdCBsb29raW5n IGF0IEZMIGlzIG11Y2ggZWFzaWVyIGZvciBhIEhXIGJhc2VkIA0KPj4gcm91dGVyIHRoZW4gbG9v a2luZyBhdCBFSHMgaW4gYSBob3AtYnktaG9wIGZhc2hpb27igKYNCj4+DQo+PiAgICAgRWFzaWVy IGZvciB3aG9tPyBSZXB1cnBvc2luZyBiaXRzIGluIHRoZSBJUCBoZWFkZXIgZXZlbiBmb3IgYSBu YXJyb3cNCj4+ICAgICB1c2UgY2FzZSBpbiBhIGNsb3NlZCBzeXN0ZW0gZG9lc24ndCBzZWVtIHBh cnRpY3VsYXJseSBlYXN5IHRvDQo+PiAgICAgc3RhbmRhcmRpemUgb3IgZGVwbG95LiBBcyBNYXJr IHBvaW50ZWQgb3V0IHRoZXJlJ3MgYSBsb3Qgb2YgY29tcGxleGl0eQ0KPj4gICAgIGFyb3VuZCBl bnN1cmluZyB0aGF0IHRoZSBzeXN0ZW0gcmVhbGx5IGlzIGNsb3NlZCBhbmQgYWxsIHJlcXVpcmVk DQo+PiAgICAgYmVoYXZpb3IgaXMgbWFpbnRhaW5lZC4NCj4+DQo+PiAgICAgQW5vdGhlciBvYnZp b3VzIHF1ZXN0aW9uIHdpdGggdGhpcyBhcHByb2FjaCBpcyBkb2VzIGl0IG1lYW4gdGhhdCBmbG93 DQo+PiAgICAgbGFiZWwgYml0cyBhcmUgbm93IGZhaXIgZ2FtZSB0byBiZSBkZWZpbmVkIGZvciBl dmVuIG1vcmUgcHVycG9zZXM/DQo+PiAgICAgTGF0ZW5jeSBtZWFzdXJlbWVudCBpc24ndCBiZSB0 aGUgb25seSBwb3RlbnRpYWwgdXNlIGNhc2UuIEZvcg0KPj4gICAgIGluc3RhbmNlLCBJIGtub3cg dGhlcmUncyBhIGxvdCBvZiBwZW9wbGUgdGhhdCB3YW50IGhvc3RzIHRvIG1hcmsNCj4+ICAgICBw YWNrZXRzIHdpdGggYSAicmV0cmFuc21pdHRlZCIgYml0IHNvIHRoYXQgcm91dGVycyBjYW4ga2Vl cCBzdGF0cyBmb3INCj4+ICAgICB0cmFja2VkIGZsb3dzLiBJTU8sIGlmIHVzaW5nIGZsb3cgYml0 cyBsaWtlIHRoaXMgaXMgdGhlIHJpZ2h0IGFuc3dlcg0KPj4gICAgIHRoZW4gdGhlcmUgc2hvdWxk IGJlIGEgZ2VuZXJpYyBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIHRoYXQgZGVmaW5lcyB0aGUNCj4+ ICAgICBvcGVyYXRpb24gYW5kIGhvdyBiaXRzIGFyZSBhbGxvY2F0ZWQgZm9yIGFsbCB0aGUgcG90 ZW50aWFsIHVzZXMuDQo+Pg0KPj4gICAgIFRvbQ0KPj4NCj4+ICAgICA+DQo+PiAgICAgPiBHLw0K Pj4gICAgID4NCj4+ICAgICA+IE9uIDA3LzExLzIwMTcsIDE3OjU4LCAiVG9tIEhlcmJlcnQiIDx0 b21AaGVyYmVydGxhbmQuY29tPiB3cm90ZToNCj4+ICAgICA+DQo+PiAgICAgPiAgICAgT24gVHVl LCBOb3YgNywgMjAxNyBhdCA3OjI2IEFNLCBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLQ0K Pj4gICAgID4gICAgIEJFL0FudHdlcnApIDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lhLmNvbT4g d3JvdGU6DQo+PiAgICAgPiAgICAgPiBBIHRyYW5zaXQgcm91dGVyIGRvZXMgbm90IGxvb2sgYXQg RUhzIGlmIGl0IGlzIG5vdCBjb25maWd1cmVkIGZvciB0aGUgSVB2NiBEZXN0aW5hdGlvbiBhZGRy ZXNzLi4gc28gaXRzIG5vdCB1c2FibGUgaW4gdGhhdCBjYXNlLg0KPj4gICAgID4gICAgID4NCj4+ ICAgICA+ICAgICBUaGV5IGRvIGxvb2sgYXQgaG9wLWJ5LWhvcCBvcHRpb25zLiBQcmV2aW91c2x5 IGl0IHdhcyByZXF1aXJlZCB0aGF0DQo+PiAgICAgPiAgICAgYWxsIG5vZGVzIGluIHRoZSBwYXRo IG11c3QgcHJvY2VzcyB0aGVtLCBidXQgdGhhdCB3YXMgcmVsYXhlZCBhIGJpdCBpbg0KPj4gICAg ID4gICAgIFJGQzgyMDAuIElmIHRoZXkgYXJlIG9ubHkgdXNlZCBmb3IgdHVubmVsaW5nIGFjcm9z cyBhIGNvbnRyb2xsZWQNCj4+ICAgICA+ICAgICBkb21haW4gdGhlbiB0aGUgdHlwaWNhbCBjb25j ZXJuIHRoYXQgaW50ZXJtZWRpYXRlIG5vZGVzIGRvbid0IHByb3Blcmx5DQo+PiAgICAgPiAgICAg aGFuZGxlIGhvcC1ieS1ob3Agb3B0aW9ucyBjYW4gYmUgYWRkcmVzc2VkLg0KPj4gICAgID4NCj4+ ICAgICA+ICAgICBUb20NCj4+ICAgICA+DQo+PiAgICAgPiAgICAgPiBHLw0KPj4gICAgID4gICAg ID4NCj4+ICAgICA+ICAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiAgICAgPiAg ICAgPiBGcm9tOiBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb21dDQo+PiAg ICAgPiAgICAgPiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciA3LCAyMDE3IDE2OjE2DQo+PiAgICAg PiAgICAgPiBUbzogVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkgPGd1 bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tPg0KPj4gICAgID4gICAgID4gQ2M6IHY2b3BzQGll dGYub3JnDQo+PiAgICAgPiAgICAgPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1maW9jY29sYS1zcHJpbmctZmxvdy1sYWJlbC1hbHQt bWFyay0wMS50eHQNCj4+ICAgICA+ICAgICA+DQo+PiAgICAgPiAgICAgPiBPbiBNb24sIE5vdiA2 LCAyMDE3IGF0IDEwOjQ0IFBNLCBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLQ0KPj4gICAg ID4gICAgID4gQkUvQW50d2VycCkgPGd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29tPiB3cm90 ZToNCj4+ICAgICA+ICAgICA+PiBIaSBUb20sDQo+PiAgICAgPiAgICAgPj4NCj4+ICAgICA+ICAg ICA+PiAtLT4NCj4+ICAgICA+ICAgICA+PiBGcm9tIHNlY3Rpb24gMToNCj4+ICAgICA+ICAgICA+ Pg0KPj4gICAgID4gICAgID4+ICJCYXNlZCBvbiB0aGVzZSBjb25zaWRlcmF0aW9ucywgaXQgaXMg YWxsb3dlZCB0byB1c2UgdGhlIGZsb3cgbGFiZWwgZmllbGQgaW4gYSBtYW5hZ2VkIGRvbWFpbiwg YXNzdW1pbmcgd2hlbiBhIHBhY2tldCBsZWF2ZXMgdGhlIGRvbWFpbiwgdGhlIG9yaWdpbmFsIGZs b3cgbGFiZWwgdmFsdWUgTVVTVCBiZSByZXN0b3JlZC4iDQo+PiAgICAgPiAgICAgPj4NCj4+ICAg ICA+ICAgICA+PiBJbiB0aGlzIHByb3Bvc2FsLCBpZiB0d28gYml0cyBhcmUgb3ZlcndyaXR0ZW4g YnkgYW4gaW50ZXJtZWRpYXRlIG5vZGUsIGhvdyBhcmUgdGhlaXIgb3JpZ2luYWwgdmFsdWVzIHJl c3RvcmVkIHdoZW4gbGVhdmluZyB0aGUgZG9tYWluPw0KPj4gICAgID4gICAgID4+IC0tPg0KPj4g ICAgID4gICAgID4+DQo+PiAgICAgPiAgICAgPj4gR1Y+ICBCZWNhdXNlIHRoZSBmaWVsZCB0aGF0 IGFyZSBiZWluZyBmaWRkbGVkIHdpdGggYXJlIG9uIHRoZSBJUHY2IFNSdjYgb3V0ZXIgZW5jYXBz dWxhdGlvbiBoZWFkZXIuIFdoZW4gdGhlIG9yaWdpbmFsIHBhY2tldCBsZWF2ZXMgdGhlIGNvbnRy b2xsZWQgZG9tYWluLCB0aGVuIHRoYXQgaGVhZGVyIGlzIHJlbW92ZWQgYWdhaW4sIGFuZCB0aGUg b3JpZ2luYWwgSVB2NiBwYWNrZXQgd2l0aCBvcmlnaW5hbCBoZWFkZXJzIGFwcGVhciBhZ2Fpbi4N Cj4+ICAgICA+ICAgICA+Pg0KPj4gICAgID4gICAgID4gR3VudGVyLA0KPj4gICAgID4gICAgID4N Cj4+ICAgICA+ICAgICA+IElmIHRoZSBtZWFzdXJlbWVudHMgYXJlIGFsd2F5cyBjb2luY2lkZW50 IHdpdGggdGhlIHVzZSBvZiBTUnY2IHRoZW4gd2h5IG5vdCBwdXQgdGhlIG1lYXN1cmVtZW50IGlu Zm9ybWF0aW9uIGluIHRoZSBTUiBFSCBvciBzb21lIG90aGVyIEVIIChob3AtYnktaG9wIG9yIGVz dCBvcHQgbWF5YmUpIHVzZWQgb25seSBpbiB0aGUgY29udHJvbGxlZCBkb21haW4/IFRoaXMgYWxz byBjb3VsZCBiZSBtb3JlIGZsZXhpYmxlIHNpbmNlIHRoZSBhbGdvcml0aG0gd291bGRuJ3QgYmUg Y29uc3RyYWluZWQgdG8ganVzdCB0d28gYml0cyBvZiBkYXRhLg0KPj4gICAgID4gICAgID4NCj4+ ICAgICA+ICAgICA+IFRvbQ0KPj4gICAgID4NCj4+ICAgICA+DQo+Pg0KPj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBs aXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCg== From nobody Sat Nov 11 23:42:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:11:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AC5129421 for ; Sun, 12 Nov 2017 04:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpxJmuePzI0M for ; Sun, 12 Nov 2017 04:10:59 -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 1435912940E for ; Sun, 12 Nov 2017 04:10: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 vACCAua2094916; Sun, 12 Nov 2017 13:10:56 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7728E20118C; Sun, 12 Nov 2017 13:10:56 +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 695F6200D2F; Sun, 12 Nov 2017 13:10:56 +0100 (CET) Received: from [132.166.84.98] ([132.166.84.98]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vACCAsgh010190; Sun, 12 Nov 2017 13:10:55 +0100 To: Mikael Abrahamsson Cc: v6ops@ietf.org References: <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> From: Alexandre Petrescu Message-ID: <40ec0857-30b1-8e7e-ec41-545d8f604d01@gmail.com> Date: Sun, 12 Nov 2017 13:10:53 +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: Subject: Re: [v6ops] GTP questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 12:11:01 -0000 Hi Mikael, Sorry for late reply. Le 29/09/2017 à 10:44, Mikael Abrahamsson a écrit : > On Fri, 29 Sep 2017, Alexandre Petrescu wrote: > >> I would like to ask whether by 3GPP specs the GTP packets can >> optionally be transported in IPv6 messages? >> >> 3GPP spec "GTP" Rel 15 of September 2017 says this: >>> UDP/IP is the only path protocol defined to transfer GTP >>> messages in the version 1 of GTP. A User Datagram Protocol (UDP) >>> compliant with IETF RFC 768 [13] shall be used. >> >> In practice, a packet capture on PGW shows an IPv6 DHCPv6-PD >> Solicit message, preceded by a GTP-U Header, which is itself >> preceded by a "GTPU Rx PDU" which is an IPv4 UDP packet. >> >> The UDPv4 port number that transports GTP packets is 2152, >> reserved at IANA and at that 3GPP spec. > > It's an implementation detail whether this is carried over IPv4 or > IPv6. UDP can be carried by both. If you read 29.060 it talks about > GTP over both IPv4 and IPv6: > > "If an IPv4/IPv6 capable SGSN received IPv4 GGSN addresses from the > old SGSN, it shall include IPv4 addresses in the fields SGSN Address > for Control Plane and SGSN Address for User Traffic and IPv6 > addresses in the fields Alternative SGSN Address for Control Plane > and Alternative SGSN Address for User Traffic. Otherwise, an > IPv4/IPv6 capable SGSN shall use only SGSN IPv6 addresses if it has > GGSN IPv6 addresses available. If the GGSN supports IPv6 below GTP, > it shall store and use the IPv6 SGSN addresses for communication > with the SGSN and ignore the IPv4 SGSN addresses. If the GGSN > supports only IPv4 below GTP, it shall store and use the IPv4 SGSN > addresses for communication with the SGSN and ignore the IPv6 SGSN > addresses. When active contexts are being redistributed due to load > sharing, G-PDUs that are in transit across the Gn-interface are in > an undetermined state and may be lost." > > "below GTP" seems to indicate what protocol GTP is run over. YEs, I can agree to read it that way, but it can be a little bit of a stretch. GTP Rel15 Sept. 2017 clearly says only RFC768. If it wanted to mean GTP/UDP/IPv6 it could have cited e.g. RFC6936. Hence the doubt. But yes, I agree with you that in largest part UDP works over IPv6 as over IPv4. > There is a lot more text in TS 29.060 regarding this, but interested > parties can read it and form their own opinion. I agree. > To me it's clear that 3GPP has done the work to try to achieve so you > can standards-based build a network with no IPv4 addresses used for > infrastructure. If this works in real life in shipping products, > that's a whole other question. I agree that real life in shipping products is a whole other question. I had some discussion with some people, and here are some of my deductions. If I am wrong, I carry the responsibility. Operator1 in hexagon country: the IPv6 is carried in GTP/UDP/IPv4 Operator2 in country voted out of EU: the IPv6 is carred in GTP/UDP/IPv4. Among other cellular operators that offer IPv6 to smartphones, I wonder about the following: Is T-Mobile USA carrying the smartphone's IPv6 inside GTP/UDP/IPv4? Or inside GTP/UDP/IPv6? Is Reliance JIO in India carrying the smartphone's IPv6 inside GTP/UDP/IPv4? Or inside GTP/UDP/IPv6? My gut feeling is that all do GTP/UDP/IPv4. My intention with this discussion is twofold: find an operator that does GTP/UDP/IPv6 and second to deduce something for the IPv6-only terminology draft. Alex From nobody Sun Nov 12 04:57:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 nobody Sun Nov 12 07:05:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A8B129458 for ; Sun, 12 Nov 2017 07:05:07 -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 pFCJuVyEmbBo for ; Sun, 12 Nov 2017 07:04:55 -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 AB1561200E5 for ; Sun, 12 Nov 2017 07:04:53 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id k191so3162093ywe.1 for ; Sun, 12 Nov 2017 07:04:53 -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=viN7NhWFZD/x0VYhyw/Yj7uH45xdyqkjadloaFWvEu0=; b=OqLdMYsHYUupZbwnz2gJ5ZaYWzSSR6YttXZ7bZP1rbgYJY8anDQ0cJRcjgBbQAO7AP Jru1nLeP3arZ0iLOG+c+tzUgWF7twvUQWTtbfSYLTvLvWgbOxAymxdrulLWtbHXvirS0 ruIugTOXgwarj9mA0188mjVGTjFE4+0YvOX8xxe3OzPhL1MCkpOYkQmnyeGiLjS7MFvG IwFQj4LacmKpi+eq3Chmtu8iz2wZ7WwMIz0XXh2yadrQuZNklBNt8L1DtP4NPvdxxhaA UdmIvrrnbBKSpfvh50VbB7DTZZLkseJkWzbzgjdqysrad/ggbaCAFG7YixzgMbttzzXn Ym5w== 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=viN7NhWFZD/x0VYhyw/Yj7uH45xdyqkjadloaFWvEu0=; b=ZdiS1h1f4F4SokjjAU6YX3+0Zi2fxseaKq6KNFN0fcnDIOPFIFP3Iv9xyhbXkYWue2 Vk8hPAmkD9ErF9Tj/LkbtaSYpY1FCoXLYrwy5rw/e0mytDUPEi1b67LY3UNaXYqDkJpl J+Wnah1/6+u9fHWY5aeq7VUmluHnBHarGjr5zFhskdf9Jm6yOqKg6ONh7aJj393o4HNj jnh193cuf4oJO/bbcA0Kk6RkJoz9YfMZJCtjD1Hfpi3XfQFvXiMNfBpalcjWtNIwHS+g zwnp6+B36/QWeHjyxtIBp8Zk0kWbB/W2egsffrYer4JIncM6g2QNirxQykN7ZtwgBBZD Wb4A== X-Gm-Message-State: AJaThX6Rn20HpbOGZIQ7lnaSCk3pDhnVYlu0koPZjQUpCOVI0cxJxGEg Bn2sYO6cu3lnmgURvlm0nkFlCkJPUFSSe2Je9FI= X-Google-Smtp-Source: AGs4zMZey2+XoH2c9dD1O7jeBTXnzMo3m8xDa1/X5hhy6QtEEwpoxT1tpm/k9jJGYX09XnEqBYuEhN/spJff+6/ZByQ= X-Received: by 10.129.65.69 with SMTP id f5mr4399360ywk.470.1510499092919; Sun, 12 Nov 2017 07:04:52 -0800 (PST) MIME-Version: 1.0 References: <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> <40ec0857-30b1-8e7e-ec41-545d8f604d01@gmail.com> In-Reply-To: <40ec0857-30b1-8e7e-ec41-545d8f604d01@gmail.com> From: Ca By Date: Sun, 12 Nov 2017 15:04:42 +0000 Message-ID: To: Alexandre Petrescu Cc: Mikael Abrahamsson , v6ops@ietf.org Content-Type: multipart/alternative; boundary="f403045e7670ddfb6e055dca79e7" Archived-At: Subject: Re: [v6ops] GTP questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 15:05:07 -0000 --f403045e7670ddfb6e055dca79e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 12, 2017 at 4:11 AM Alexandre Petrescu < alexandre.petrescu@gmail.com> wrote: > Hi Mikael, > > Sorry for late reply. > > Le 29/09/2017 =C3=A0 10:44, Mikael Abrahamsson a =C3=A9crit : > > On Fri, 29 Sep 2017, Alexandre Petrescu wrote: > > > >> I would like to ask whether by 3GPP specs the GTP packets can > >> optionally be transported in IPv6 messages? > >> > >> 3GPP spec "GTP" Rel 15 of September 2017 says this: > >>> UDP/IP is the only path protocol defined to transfer GTP > >>> messages in the version 1 of GTP. A User Datagram Protocol (UDP) > >>> compliant with IETF RFC 768 [13] shall be used. > >> > >> In practice, a packet capture on PGW shows an IPv6 DHCPv6-PD > >> Solicit message, preceded by a GTP-U Header, which is itself > >> preceded by a "GTPU Rx PDU" which is an IPv4 UDP packet. > >> > >> The UDPv4 port number that transports GTP packets is 2152, > >> reserved at IANA and at that 3GPP spec. > > > > It's an implementation detail whether this is carried over IPv4 or > > IPv6. UDP can be carried by both. If you read 29.060 it talks about > > GTP over both IPv4 and IPv6: > > > > "If an IPv4/IPv6 capable SGSN received IPv4 GGSN addresses from the > > old SGSN, it shall include IPv4 addresses in the fields SGSN Address > > for Control Plane and SGSN Address for User Traffic and IPv6 > > addresses in the fields Alternative SGSN Address for Control Plane > > and Alternative SGSN Address for User Traffic. Otherwise, an > > IPv4/IPv6 capable SGSN shall use only SGSN IPv6 addresses if it has > > GGSN IPv6 addresses available. If the GGSN supports IPv6 below GTP, > > it shall store and use the IPv6 SGSN addresses for communication > > with the SGSN and ignore the IPv4 SGSN addresses. If the GGSN > > supports only IPv4 below GTP, it shall store and use the IPv4 SGSN > > addresses for communication with the SGSN and ignore the IPv6 SGSN > > addresses. When active contexts are being redistributed due to load > > sharing, G-PDUs that are in transit across the Gn-interface are in > > an undetermined state and may be lost." > > > > "below GTP" seems to indicate what protocol GTP is run over. > > YEs, I can agree to read it that way, but it can be a little bit of a > stretch. GTP Rel15 Sept. 2017 clearly says only RFC768. If it wanted > to mean GTP/UDP/IPv6 it could have cited e.g. RFC6936. Hence the doubt. > > But yes, I agree with you that in largest part UDP works over IPv6 as > over IPv4. > > > There is a lot more text in TS 29.060 regarding this, but interested > > parties can read it and form their own opinion. > > I agree. > > > To me it's clear that 3GPP has done the work to try to achieve so you > > can standards-based build a network with no IPv4 addresses used for > > infrastructure. If this works in real life in shipping products, > > that's a whole other question. > > I agree that real life in shipping products is a whole other question. > > I had some discussion with some people, and here are some of my > deductions. If I am wrong, I carry the responsibility. > > Operator1 in hexagon country: the IPv6 is carried in GTP/UDP/IPv4 > Operator2 in country voted out of EU: the IPv6 is carred in GTP/UDP/IPv4. > > Among other cellular operators that offer IPv6 to smartphones, I wonder > about the following: > > Is T-Mobile USA carrying the smartphone's IPv6 inside GTP/UDP/IPv4? Or > inside GTP/UDP/IPv6? > > Is Reliance JIO in India carrying the smartphone's IPv6 inside > GTP/UDP/IPv4? Or inside GTP/UDP/IPv6? > > My gut feeling is that all do GTP/UDP/IPv4. > Your gut is correct, i do not know of any carrier using GTP with ipv6 transport. That said, i believe the GTP transport network operations is orthogonal to the network that the UE / customer traffic experiences. > My intention with this discussion is twofold: find an operator that does > GTP/UDP/IPv6 and second to deduce something for the IPv6-only > terminology draft. > > Alex > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f403045e7670ddfb6e055dca79e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Nov 12, 2017 = at 4:11 AM Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
Hi Mikael,

Sorry for late reply.

Le 29/09/2017 =C3=A0 10:44, Mikael Abrahamsson a =C3=A9crit :
> On Fri, 29 Sep 2017, Alexandre Petrescu wrote:
>
>> I would like to ask whether by 3GPP specs the GTP packets can
>> optionally be transported in IPv6 messages?
>>
>> 3GPP spec "GTP" Rel 15 of September 2017 says this:
>>> UDP/IP is the only path protocol defined to transfer GTP
>>> messages in the version 1 of GTP. A User Datagram Protocol (UD= P)
>>> compliant with IETF RFC 768 [13] shall be used.
>>
>> In practice, a packet capture on PGW shows an IPv6 DHCPv6-PD
>> Solicit message, preceded by a GTP-U Header, which is itself
>> preceded by a "GTPU Rx PDU" which is an IPv4 UDP packet.=
>>
>> The UDPv4 port number that transports GTP packets is 2152,
>> reserved at IANA and at that 3GPP spec.
>
> It's an implementation detail whether this is carried over IPv4 or=
> IPv6. UDP can be carried by both. If you read 29.060 it talks about > GTP over both IPv4 and IPv6:
>
> "If an IPv4/IPv6 capable SGSN received IPv4 GGSN addresses from t= he
> old SGSN, it shall include IPv4 addresses in the fields SGSN Address > for Control Plane and SGSN Address for User Traffic and IPv6
> addresses in the fields Alternative SGSN Address for Control Plane
> and Alternative SGSN Address for User Traffic. Otherwise, an
> IPv4/IPv6 capable SGSN shall use only SGSN IPv6 addresses if it has > GGSN IPv6 addresses available. If the GGSN supports IPv6 below GTP, > it shall store and use the IPv6 SGSN addresses for communication
> with the SGSN and ignore the IPv4 SGSN addresses. If the GGSN
> supports only IPv4 below GTP, it shall store and use the IPv4=C2=A0 SG= SN
> addresses for communication with the=C2=A0 SGSN and ignore the IPv6 SG= SN
> addresses. When active contexts are being redistributed due to load > sharing, G-PDUs that are in transit across the Gn-interface are in
> an undetermined state and may be lost."
>
> "below GTP" seems to indicate what protocol GTP is run over.=

YEs, I can agree to read it that way, but it can be a little bit of a
stretch.=C2=A0 GTP Rel15 Sept. 2017 clearly says only RFC768.=C2=A0 If it w= anted
to mean GTP/UDP/IPv6 it could have cited e.g. RFC6936.=C2=A0 Hence the doub= t.

But yes, I agree with you that in largest part UDP works over IPv6 as
over IPv4.

> There is a lot more text in TS 29.060 regarding this, but interested > parties can read it and form their own opinion.

I agree.

> To me it's clear that 3GPP has done the work to try to achieve so = you
> can standards-based build a network with no IPv4 addresses used for > infrastructure. If this works in real life in shipping products,
> that's a whole other question.

I agree that real life in shipping products is a whole other question.

I had some discussion with some people, and here are some of my
deductions.=C2=A0 If I am wrong, I carry the responsibility.

Operator1 in hexagon country: the IPv6 is carried in GTP/UDP/IPv4
Operator2 in country voted out of EU: the IPv6 is carred in GTP/UDP/IPv4.
Among other cellular operators that offer IPv6 to smartphones, I wonder
about the following:

Is T-Mobile USA carrying the smartphone's IPv6 inside GTP/UDP/IPv4?=C2= =A0 Or
inside GTP/UDP/IPv6?

Is Reliance JIO in India carrying the smartphone's IPv6 inside
GTP/UDP/IPv4?=C2=A0 Or inside GTP/UDP/IPv6?

My gut feeling is that all do GTP/UDP/IPv4.

Your gut is corr= ect, i do not know of any carrier using GTP with ipv6 transport.=C2=A0

That said, i believe the GTP= transport network operations is orthogonal to the network that the UE / cu= stomer traffic experiences.=C2=A0



My intention with this discussion is twofold: find an operator that does GTP/UDP/IPv6 and second to deduce something for the IPv6-only
terminology draft.

Alex

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--f403045e7670ddfb6e055dca79e7-- From nobody Sun Nov 12 18:08:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFD6127A91 for ; Sun, 12 Nov 2017 18:14:42 -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 1X_ocg3MRhZy for ; Sun, 12 Nov 2017 18:14:36 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4D612726E for ; Sun, 12 Nov 2017 18:14:35 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id m191so7617925itg.2 for ; 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=h9ka8yP6RM7kX0EeGTOxdXptatxgFxZRFEQqjEGNKG26K8NqS6C+qGrIyhUV2cxq0N RPUX+s6Yx8Pw34/3+dSuozgGRWpfe3Pma8Afg+UMjqBPLTL8MM0wb+5KwI8cn9KCAVKF yCZcntYApkzkgSnjoIBlN6j7HMrJgovJLQBqPgmUOsiiWT49/Bv6wBAHDFlrK9pKSPw5 4czvHb+kXXlvmVm0NdhxvE4rmsaoq7DuNSsDb5ytevxoIxYF6BmC35TdZ5sDVOSZuD4k 4bhNCwkU8gbBEXzwKIMDb2ELsd/AEwP7DDHFUve7MRps67RQPrq2e4dkjRVdsjc0jym5 q0YA== X-Gm-Message-State: AJaThX4jcbaTC4ob9tia8LssS4QdBnthPe3ZIelGfvGp7/yXAQsTjDeS JspsSQajmT+PS1OSOivPGifxUxYoGTKUi9HXSVJlfg== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:14:43 -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:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ECE126DFF for ; Sun, 12 Nov 2017 18:16:13 -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 P96-PWTkpdg8 for ; Sun, 12 Nov 2017 18:16: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 BB3CB127698 for ; Sun, 12 Nov 2017 18:16:10 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id x28so1919440ita.0 for ; 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=Q+DQzRP2DsaRHzDgzTcpQFrmQDK747IxPAE2bfPKp1Bqatr0Tb962N1HXBz32mrkkC 8duf3O+rhGcr0NGN35E7yOeuSQDlUMe+k35S7hzZ8D0+lciRJS3De4B3+zIqSj4a7CKg /0dl9JCUlNnv0ztSnXSnxT3Cxs6BrLRpje3Mr4o0+oOIr7JqYzKOeXfIV4U/yJyuFT5N FhRHEBjvr9g9gSlkMFBkrdVbPDfDV5k3eQ8ReaMrA192aEPVMRQCR8hChChqnnknwJlk xkM3jgxxVFKsZdoJvKtChQPiVpQKg6qTXeF1KNrLxVPFwdhzLDutKmwi09EDGIJAhMYP PXCg== X-Gm-Message-State: AJaThX6Am7L04xtrKbfpErqVQaBHRvsgSwfMfIy7zqs4sU1+pL+o5jGW 7xyDxvBVlWYSeheKLd8xKh8zgrISdklIhCw3EuzFPQ== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:16:14 -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:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26621274D0 for ; Sun, 12 Nov 2017 18:17: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, 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 DcaJbO-ms76X for ; Sun, 12 Nov 2017 18:17:18 -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 E24281243FE for ; Sun, 12 Nov 2017 18:17:18 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id 17so10787820pfn.12 for ; 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=NROriHpl6u2i8NRN5R+HkWGBWCn2eQlczwvl/F9WTwhhpxKIp/Ed630Z0wmAPIBX0F 65d2cjxWJx22jED4fVVbO/JEbUskrTDsPsvn8Iop5XuOjWcwtzzqFJl2tR3oihlSMmBK pafc3jebTghVBLgp6tTxOSGbBiNUOt+oua/GkUk1YACsGmB4E8BdNS+3dvm5PF3H4Bjm cpQn1v/IS30PFnPK33+zFwpNOPGwQUutzAAXViOQhF0RlTmW4qlsjmJKGZhggOhvxVfn z8/sJCxfZhpQoYZ0hEajC5aO9NvTRTIIca2fxdIiW/NnZfjK3+hET4W+1SOa6C9yVu4T 7k3Q== X-Gm-Message-State: AJaThX7ic/h06xYqX32fGxIK0bfBRkwa6xYs6c0ioOxMMXC2kmEtIeNp ZwXuGWBV17IOUjMhk5IlPKUmrQ== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:17:22 -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:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:44:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A405127B57 for ; Sun, 12 Nov 2017 18:44:37 -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 vhoeGDw3j-b5 for ; Sun, 12 Nov 2017 18:44:36 -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 D745812896F for ; Sun, 12 Nov 2017 18:44:04 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id a84so5934479pfl.0 for ; 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=IqA0EnnjkurFl7XBGsby1ut0julBBYjICxzxT3r8ib6iMpeYG7+JzIr7r9dVEYIYOA lHqMnrUlGysdE1ss+lBZGS+AAQgLguO44ezP9dueG8S9fzZJfoGIm14U6zQI/ZFFmqUw 95M47XGSdKVgHjkVkciDq+hWlkfWk2XhsSJ2FlYxx2OuM/FWxVZ63pzm4zLe8WHk3jBk JlljMK9UbuoxyKdQWBmH+T7r7bPjtUz44ywNSFRLODDr+Skqc4uwuSh5ypZvEtPAPOSH Gf9WqVuOERuo+EfecKnu35q+WRDmtsXW4Lku8UBbFSZiocs3NNXAsS9dDZniGRsV2xjS rDMQ== X-Gm-Message-State: AJaThX4H6Fk99NZ8skCdEqWAXq43tiMSSsLNoAIh369wObRkA9823V+K O+YM8PghXRfBbK1rpQJsem46dg== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:44:37 -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:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:53:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9E4128DE5 for ; Sun, 12 Nov 2017 18:56: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=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 rE7FhBzjhi4X for ; Sun, 12 Nov 2017 18:56:28 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DEF1126DFE for ; Sun, 12 Nov 2017 18:56:27 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id t10so10641690pgo.3 for ; 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=SqzdpiT0qKf/qCy1dNZKI6zAN02v6Dck+ClNmIu2vnn8lIxuA0hTKE+Rwklt+qoU0x Am+w3bIge0ZQpFg191a+FQFIkwifBXn8qxsPY6dPm8GaWsuxEF65Mm1ZH8t1V76yxf8y 659G08jjof/N53YeSWZeMhU5BAeBBa4UayZm2Ey7u2B+rTQB7/3u23/KNldxaxKN3A8v 5gD9id6bI+UWPKBCcPtBPY2kpvQiaHNOkEGUeHhtI2ACTsl5qbjHf5OwBGIRaO6m3jTw ijpUmd/3mMhEtnwkOCIpn+2RQMxY8buPMClx8Eg3KMTXcP/tBnzBfrRv/Xe9ZQtvEd0Y OHvw== X-Gm-Message-State: AJaThX5gB7v2QeoVrcmJAFTqfRd/L/ltiql5aZUq2dIrnddMnN0Jt574 ejdKmP8lpuQ8h8tGJbSVtIWeEw== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:24 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDD51293DA for ; Sun, 12 Nov 2017 19:27:43 -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 FZCPe7a_DTvX for ; Sun, 12 Nov 2017 19:27:42 -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 6B4DC129420 for ; Sun, 12 Nov 2017 19:27:26 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id g6so11717972pgn.6 for ; 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=UIOjBQmObRO7XkP1mZS9l+8GEkwcdODEeaKm9obh5TiV7hCzUO1uQ/roJty+RYEE1r 1niqCYbuBicffgnf1+eSXzIj1G7xbyvgqmjQEwIv56xUitEQdSiT3m7afluB24qyQtRY LPtyn+TD95i74nbnrGqtKBe9Iv+JFhLE41r+RpEZxnSEwDUHU0qKCzZcqEN3lRzklYgs DNfEmBrTPzNZpssgyFYwTN5+zJNfp8W9KpLmpKDKNzHciozJ1ypQinSQqwc9603eqM17 tCHO3P3HK5ViHyvblGcptcLOSByXlxoWi/1XpqNCtvk9cBT2XIhAknrCsIz7e10NJvIJ tr5Q== X-Gm-Message-State: AJaThX5oNUwDO5aWUE5sI1x8uTSQUD788BhveNfyynr6t2/pzG1ZT/rN vO9/H3fg+N9kjLmVBMXINWyV8w== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 03:27:44 -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 20:38:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 22:25:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:19:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47730128C82 for ; Sun, 12 Nov 2017 23:19: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.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 9GOfhS3J47Gw for ; Sun, 12 Nov 2017 23:19:35 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1CC812008A for ; Sun, 12 Nov 2017 23:19:35 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id r11so3119752uah.12 for ; Sun, 12 Nov 2017 23:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IMUMukxMaFsSREutUMrIPTh1Afl1NzhnPc50C+lSPXk=; b=jaxuLQNgRyfhJnuCf8pzhNq4K8j0TmPpgoeTQ+NebHu5bbqptsAkoBDih9U1d65i76 scTp1vYXSBHeSzcqGDvZIYgJiWtPNuA3IZ0OzWApqQRcFp7oFqf2+CUGi1N3tvJiJaec tMRgesTIFhfjV277FmPxr2qTJlq2XMyyzhuxlxrX0pjjbApQDJY94hgsGNU1ZrLElvwa G8wyGe9I3OtDgnqkLmiQfsPdDxHAKUN+YIG0ANuasb3fNW9R6llToCD0Kg+DgV+PXbfq xyiNoDypxHCqzerJ8ZV1DSDqx0RSYza9OTIcJiZjPLBrwSR8tIF2NIbq1cPZhW6FOmeR xwXQ== 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=IMUMukxMaFsSREutUMrIPTh1Afl1NzhnPc50C+lSPXk=; b=Ks7nEsr9z6jeReTQfulakt86vatwTS36z4Q7+OklcUh5yekKIlMmV/1XWNVhEd/Gkr KiiSOjwk5e9uxyBFGgJzahTX9gv3ksuMLqtx5N70YJ4Zb2jZSy1Obto46565BhQciMuO 23MIw8thhTfgg41tAvuHq0SyudtA/ZKVd+mjKmLfrJkSgc4Ry/iTg+mod1XPC9fXyd9M GyeAACvcvmNsfLd5kYgy8vhM+mKKyqChxksdLtpRq5ugsj5mIzsCLdltYotst+xRc8+J TKOMLHPly5con2M5s6ZCnZJXksIPWpLn9Wly4GAEMGwuvpTPMLnU92KocQz85zd3y25I Bj7Q== X-Gm-Message-State: AJaThX5ubEeH6sl2bduDKbQqIQCPijT9I6Owsefun05JUuRiWJk+jD5q TdNyLzPPfgA7kI9MjIdkkggPcUhSJu9PXTK2XDuAdYm2 X-Google-Smtp-Source: AGs4zMatCtdzRLuCJ8nmzrqkPs5VLLVI3JsA74pnvsNum4h8mGtCWhiB+alVyHVLGsRwW4A1XTLNYNMikWx2CS9T6hY= X-Received: by 10.176.1.104 with SMTP id 95mr4288433uak.165.1510557574732; Sun, 12 Nov 2017 23:19:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.91.2 with HTTP; Sun, 12 Nov 2017 23:19:34 -0800 (PST) X-Originating-IP: [2001:67c:370:1998:6d7a:c511:36ca:fff2] In-Reply-To: <1049A23A-BC67-43B3-B158-1366A92926CD@consulintel.es> References: <150937816403.7793.11085386578208067817.idtracker@ietfa.amsl.com> <1049A23A-BC67-43B3-B158-1366A92926CD@consulintel.es> From: George Michaelson Date: Mon, 13 Nov 2017 15:19:34 +0800 Message-ID: To: JORDI PALET MARTINEZ Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 07:19:38 -0000 If there is a functional barrier to any PDU which is IPv4 directly encoded, being forwarded: If there is a barrier to other non-IP packets such as ARP being forwarded, then in that sense, the link layer cannot and does not forward IPv4 and its an IPv6 only network. If the administrative decision has been made not to proffer ARP responses, DHCP, or any other mechanism to bootstrap IPv4 but no barrier is placed on its use, then I can stand up an IPv4 endpoint, and hand-configure it to talk to another on the layer 2 fabric and it works. I don't consider this to be an IPv6 only network, because bad actors can send functional IPv4 between themselves. If you forward broadcast packet types its even easier. If I tunnel IPv4 over IPv6 PDUs then its still an IPv6 only network. Encapsulation is not the same as raw forwarding. -G On Mon, Oct 30, 2017 at 11:44 PM, JORDI PALET MARTINEZ wrote: > Hi all, > > I just posted a new version for this document. > > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > > Comments welcome! > > Regards, > Jordi > > > > -----Mensaje original----- > De: > Responder a: > Fecha: lunes, 30 de octubre de 2017, 16:42 > Para: Jordi Palet Martinez , Jordi Martin= ez > Asunto: New Version Notification for draft-palet-v6ops-ipv6-only-03.txt > > > A new version of I-D, draft-palet-v6ops-ipv6-only-03.txt > has been successfully submitted by Jordi Palet Martinez and posted to= the > IETF repository. > > Name: draft-palet-v6ops-ipv6-only > Revision: 03 > Title: IPv6-only Terminology Definition > Document date: 2017-10-30 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet-drafts/draft-palet-v6op= s-ipv6-only-03.txt > Status: https://datatracker.ietf.org/doc/draft-palet-v6ops-ip= v6-only/ > Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-ipv6-on= ly-03 > Htmlized: https://datatracker.ietf.org/doc/html/draft-palet-v6o= ps-ipv6-only-03 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v6ops= -ipv6-only-03 > > Abstract: > This document defines the terminology regarding the usage of > expressions such as "IPv6-only", in order to avoid confusions when > using them in IETF and other documents, in reference to what is th= e > actual functionalities being used (not the actual protocol support= ). > > > > > Please note that it may take a couple of minutes from the time of sub= mission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Nov 12 23:52:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B610D126B6E for ; Mon, 13 Nov 2017 00:01: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=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 kbJBjBb9PhMc for ; Mon, 13 Nov 2017 00:01:14 -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 8F2921294D4 for ; Mon, 13 Nov 2017 00:00:58 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id n134so8903157itg.0 for ; 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=Rp9Pve/ZT1dDNdOM2VMJin4q2JfMBi+gt5hpOjGFXd/QHdZkaOUVpn0/+A/AKVzg/T K+oQtlBHYjklGISUZ2mt0/Lwm5ZzVA1bvy1SjHDB2Jtl3iJ+axRmccDVEBkmiW0Wm//g eCM5kqg8NCJOrpocccEi36+8R75mNcXqGfZr60I3nHzitytA9N7cvVsXydP2jIVH5vDz s2AnzjmXSHcbIPMeGS4wGVkyMhfkJgRK6pIjWpCzXqHfxG3rbI0HKhLUra7zzm2p5pNW 1gPfJFdhL4dCSoLF4tSBwOBkGO/m19XGyjbaMp7mt2DoT0OyzmRpi6AE92AYniz08LyE w5gQ== X-Gm-Message-State: AJaThX7BIZxi8gmy3S0TmG/EvEejx5sNq5+qGi+2CuIISUrlxDpfKcHv OnszSXpkgflDkXftOLqz6m7S3qUGyxlHCoVX5Dk73A== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 08:01:21 -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:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9D01294C8 for ; Mon, 13 Nov 2017 00:04: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, 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 5FqkoNsAt-rr for ; Mon, 13 Nov 2017 00:04:14 -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 84E21128891 for ; Mon, 13 Nov 2017 00:04:14 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id m88so4052503pfi.9 for ; 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=ErIWE3Y1b3RTXZmjICoQa7zUWsIOxoMx8uRsW1bkP3BGBetM+pGj0LQ324gkaNWJ3V HK1WSGkqsNJ6+7Zfiu6Ae1sX5zOMVx+fTfUzd7EMd7Kyx8uM3N2+UugyYNS/iw/kPLZM Gbft29NRu4S1N9fLzD1blXx7KSppP3q2xCQbI2m9vROh9caFbaSEXWmafooe//zRrGYb NS7/644pLM7rOTrNkGaiVqfzidrS3YML17fB21L3y1d7dXgms76CgE9RayqxhcMA36us R6bgPzG8FSxeqJylzrr7/PAtKaabnu6fy6OlSyGRHWXC9NK9Yzx5S3ObKEzI4G1gkB13 8wVQ== X-Gm-Message-State: AJaThX6TyppEXvTIlqER4vNAa8YoUNlm/5TuWAyMgaKMyeCsk+qkIqDp L5nkGH1gqDyxlT0NM7J57pSyKw== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 08:04:16 -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:15:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657BD12940F for ; Mon, 13 Nov 2017 00:17: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 zEYeLrdcvhDX for ; Mon, 13 Nov 2017 00:17:35 -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 D23B3124B09 for ; Mon, 13 Nov 2017 00:17:34 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id u132so8426032ita.0 for ; 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=BbyzE2vQmDd2lcSwNV8QMdxfFIXeXiIDodg6b1wFAaaWz5pkdvxlIqDIF2djE+qryW rnWKUX6jkrASP4sf+XTNNld/iTppd+vjgKUYxK/W+aoOPyRbXKcjfJWr/nO1f60+D3WT CtNsUmFv/MRCJYFgNgxL/G8gOPlJN2US79ZPTqaFR7hW/y9T/S03lf3UwJ6SFqJNzs/i ls4btWNXuGmVn1+18sWWqOU8ywElXzAAIb7E1UTeDqJiHYXfpy/bnfrQF2UCHby6JVrW P8YrimFllYoKRQOzuNa+hiFspY6pT0elQl+GOS9tJy8+Gh0b5QMSA4b9TP6V8kt+idg4 l6LQ== X-Gm-Message-State: AJaThX7f+3Z4P8YEm361FIgHU/btrcIjAtSMOqpU1y4bGOgmwM3J5LfF KiWSiNGMdszbkz3uXJs6XiITtDF2st4CkujpknSh+w== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 08:17:36 -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:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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)" 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B314C12947D 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=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 cJ71oDqvsZEe for ; Mon, 13 Nov 2017 00:25:11 -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 6D116126B6E for ; Mon, 13 Nov 2017 00:25:11 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id s2so12137282pge.10 for ; 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=RBUPja8y8lKoFbKnb7jaF8IuYRLDGGGnsQwk/rTuHbvefS3YNKWDqQ0mojQlLXiUEQ /+V7Eoqlner5XHHq6mMjlckZ5VqCgJ7ommF+Xu5+BTYRR9A0VfdgtF27/7/dfCP3X2h6 qu0IkB0CgEdmx1V76MDeKW3lDnQAviGfG3U3ARvmaH5XhXWsYSTFQBC3GsdxSiuYWZhB P5exmUxJDtqiyPfy1iBi8Sn5Aoxv0l0OfIuKWUKqViXSvSQGxLMR/nviPqxdf56h060l ES8u90tiHTOZ6jwcnpaUqJ4pXWom6ADotJEPSXb42tgRi8jLOeh/bxf8Hbn2ToQihMP6 +uBg== X-Gm-Message-State: AJaThX6MDieenfaU3OfSKfd7JseewBTfFVj4OqIor7XN6VxMZPoDHfnH Vit11E6nXCeZmNs/+IUh9wv3IA== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 08:25:13 -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:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF39129508 for ; Mon, 13 Nov 2017 00:30:35 -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 uyNB3iIZix58 for ; Mon, 13 Nov 2017 00:30:34 -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 32CAF129504 for ; Mon, 13 Nov 2017 00:30:34 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id 108so5565748uaf.2 for ; Mon, 13 Nov 2017 00:30:34 -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=AV96SveUcaTqaK7H9zIQdyapRZZeRuEwUHvl+WGeL28=; b=KIPd2lgVAne2NH7WQnv67z/Lo7GVT8+or5oiNB/npDZlg8nOF60gf/EMzifFWorUtS PUtoWH9WlGwBHnyzM/0Pk02wFvlaQS/9LeKuWLI8RIr6N6/+hTNyahDYmNlGu6JyOJ2J dkz9kPerLnKKdrmZn9iUlPyBaRYYxWZrsziV1vvBzveEEe8uJo+YbKGWMLlZDGh0+MM3 5zaDGPUR/sbVht7Iw2qCHc3Fy1E6qrYxp+ye8Uadrokhp80wlyFKaKGH3NWqRYvRMp1V afb1tQazDTjJToFSLotejCHGfdoqEQxfe4+/i2ualPT2rt4jH+Ip+Rfma7RROEPrO2X3 zbDQ== 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=AV96SveUcaTqaK7H9zIQdyapRZZeRuEwUHvl+WGeL28=; b=cSm8KdcwjOlIcz2vgIy2hkUlVL6EH6SO0r9OIgam7rEJpLRm8Z/g3JpMOzjPaplFBQ oENkI+Ps7bp0m6bMQPq8H0GHLHffH+t0O5RQlqo75Bp/G31VomL38xjFx4M6sLCjx3I3 xFq+9g3wtL8YeKM7XLnqzQcD0Li0tRtT5yI5sbMfsDCy6WvPYxObDufniUttoVhArfSR 3AUzqfPJSm+EpE2yIpVAyBbpHfiiNgLQ2lJu6HRTcbv/L4Ff20N2uXcHex2o+WXX2nya n7+UZvOktIX9M6kIpWbX5KUDWXDWKp8wpG9ONDnJNhgIdtz7q24cv5zPN/5FwqkxNIO0 cSHA== X-Gm-Message-State: AJaThX6h//GpEH9JCGmweTgr96AsHKsDq2TGL/HT4bY31ddP8Msl3pfJ ITntV0+u4bHWe9d+ZJaFmQ1g1AF6pySPHuR6hGw= X-Google-Smtp-Source: AGs4zMaWiCP9L2UqFvk7NTQrJPSBy4mrumIzPmt4XOqwBuAlQiiEhuy9sfjHtLehAxlUPI0KZGHq4m9PMwKUfB3mNeU= X-Received: by 10.176.71.78 with SMTP id i14mr7137870uac.13.1510561833191; Mon, 13 Nov 2017 00:30:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.52.221 with HTTP; Mon, 13 Nov 2017 00:30:32 -0800 (PST) Received: by 10.159.52.221 with HTTP; Mon, 13 Nov 2017 00:30:32 -0800 (PST) In-Reply-To: <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <89d4d29f-30ab-756d-b02c-cf460ef833ce@si6networks.com> <6ed75c9e-5f15-6207-4723-85d055a9768f@si6networks.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> From: Mark Smith Date: Mon, 13 Nov 2017 19:30:32 +1100 Message-ID: To: Ted Lemon Cc: Tom Herbert , v6ops list Content-Type: multipart/alternative; boundary="f403045f41727a8e3c055dd915f6" Archived-At: Subject: Re: [v6ops] Security: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 08:30:36 -0000 --f403045f41727a8e3c055dd915f6 Content-Type: text/plain; charset="UTF-8" On 29 Oct. 2017 09:20, "Ted Lemon" wrote: On Oct 28, 2017, at 5:59 PM, Tom Herbert wrote: Some of this has been touched upon in the IDEAS discussions, but nothing formalized yet (identifier-locator use implied to eliminate as much topology on address as possible). I could spin a draft specifically on one time use addresses and privacy (won't make cutoff though). The problem is that now you have a requirement for substantial infrastructure to manage the ID/locator separation. Would look a bit like Tor. Who's going to pay for it? Actually, I think multipathing e.g. MPTCP goes a long way to solving that problem. The 32 bit token generated and used by subflows to identify their peer is a temporary host ID that is independent of the locators/addresses of the host. My understanding is that in "original" ID/locator separation, the host ID was expected to be fixed and bound to a host across many transport layer connections. Perhaps that's what makes it a hard problem. Temporary, per application session host IDs are also better for privacy. Regards, Mark. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --f403045f41727a8e3c055dd915f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 29 Oct. 2017 09:20, "Ted Lemon" <mellon@fugue.com> wrote:
On Oct 28, 2017, at 5:59 PM, Tom Herbert <tom@herbertland.com> wrote:=
Some of this has been touc= hed upon in the IDEAS discussions, but nothing formalized yet (identifier-l= ocator use implied to eliminate as much topology on address as possible). I= could spin a draft specifically on one time use addresses and privacy (won= 't make cutoff though).

Th= e problem is that now you have a requirement for substantial infrastructure= to manage the ID/locator separation. =C2=A0 Would look a bit like Tor. =C2= =A0 Who's going to pay for it?

Actually, I think multipath= ing e.g. MPTCP goes a long way to solving that problem. The 32 bit token ge= nerated and used by subflows to identify their peer is a temporary host ID = that is independent of the locators/addresses of the host.

My understanding is that in "origin= al" ID/locator separation, the host ID was expected to be fixed and bo= und to a host across many transport layer connections. Perhaps that's w= hat makes it a hard problem.

Temporary, per application session host IDs are also better for privac= y.

Regards,
Mark.






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


--f403045f41727a8e3c055dd915f6-- From nobody Mon Nov 13 00:30:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 00:41:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C902E126DED for ; Mon, 13 Nov 2017 00:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=retevia.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MZqJhjE_gkm for ; Mon, 13 Nov 2017 00:41:15 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDD4126B6E for ; Mon, 13 Nov 2017 00:41:15 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 22D901406B0D for ; Mon, 13 Nov 2017 00:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=retevia.net; h=date :subject:from:to:message-id:mime-version:content-type; s= retevia.net; bh=6H6fNtCctajyfp9poSEdhDP7iSA=; b=cz2wTO9upnWCfN0Z sElihCEux2SZsMD4eOGDlN4YbnzHR4u12wXfNPtkdwCU3vbJ5c/zZxRWFd0lb+8x 8fSVrqmhcED3xRvEbDkDz5xNHqJLY8Or57AEDGF0dKgLAWtg4ArsJHpHweMvAisv JIayXNtf9KDKpg0phAG1ucXR98g= Received: from [31.133.128.134] (dhcp-8086.meeting.ietf.org [31.133.128.134]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (No client certificate requested) (Authenticated sender: Lee.Howard@retevia.net) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 1B8D71400930 for ; Mon, 13 Nov 2017 00:41:13 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Mon, 13 Nov 2017 16:41:09 +0800 From: Lee Howard To: Message-ID: Thread-Topic: "No IPv4" experiment Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3593436074_9074151" Archived-At: Subject: [v6ops] "No IPv4" experiment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 08:41:17 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3593436074_9074151 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I=E2=80=99ve heard some side channel conversation about the experiment. I hope people have opened tickets. Reminder: https://tickets.meeting.ietf.org/newticket What did people think of this experiment? Personally, I had some trouble. I like to stay logged in during the WG meeting so I can keep an eye on Jabber, and preview slides and documents. I was bounced off the NAT64 SSID several times, and automatically reconnected to =E2=80=98ietf=E2=80=99. =20 Lee --B_3593436074_9074151 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
I’ve heard some= side channel conversation about the experiment.

I hope people have opened tickets. R= eminder: https://t= ickets.meeting.ietf.org/newticket

What did people think of this experiment? =

Personal= ly, I had some trouble. I like to stay logged in during the WG meeting so I = can keep an eye on Jabber, and preview slides and documents. I was bounced o= ff the NAT64 SSID several times, and automatically reconnected to ‘iet= f’.  

Lee



--B_3593436074_9074151-- From nobody Mon Nov 13 00:57:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6262A129457 for ; Mon, 13 Nov 2017 00:57: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 aQT2zSf41fd1 for ; Mon, 13 Nov 2017 00:57:12 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F29D126CC4 for ; Mon, 13 Nov 2017 00:57:12 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id p9so12188579pgc.8 for ; Mon, 13 Nov 2017 00:57:12 -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=7HNtjFr3+zqqcApCfSpx9Kj0ToKTYifjX6XKjZwNwrI=; b=l2B5n+sNA2q0xcCm1CRUe/vl6Ovntc0UfXR41bJSlTEDgUMvNefz3NgIqKxJpUkA3A JPsGqWBVkYnj9i3C6So74LmF3uDzaRpHJdsJFsOZYXU7udXQGtORz1RPGVLZjou/fEgm tiF2Fqwm7oqVejjBBgOtePsFrfKEHMmZetpNoEnOnWB7Hn2mWqBIz4gonxYDaReE02EO rZ9GpioWsJJv7HEoKPLQca9ifsoM+mmneLgsAMK5v/Ax1viyFAdQ9LALgCDtcNMXKJqH PBtSQ4lBYHhyMHjn0pmcvi9k3jUfvFw2c5+Z9AIE5fuD51Qv3jaBjnxhCxJ+uZLrH+gO 2HWg== 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=7HNtjFr3+zqqcApCfSpx9Kj0ToKTYifjX6XKjZwNwrI=; b=mzWNefH1xblBKnrAdMuPH8hKq2E+pThd8+8MpnhlfugO/C0TtsP2CJlrRR3xPpbLAe 0bL9eL1e3KhT/zAjiNa0yBCMzNbtHWyGoEyLa4dDFx2LuJNph2sKMi0M8X/0MSBitpKu owp9yJmno3CoKW8vlhIr7Xtc1NCIYq+PYHaybNrSStVoCaS3URJznEzUkDIS9SMPcUDf GrlbX48OwQOR2X6hh18xP0EO4XMW5ge74Ol09aCVee13pIqX6CProoEiaXO1Dhj/NSRO DcddzTso0Ve9Z/MaJigBQGreJPCAWFi8+e34u1CdfULD4ePgfLEbO/qdb6Zfx1EaSMgg S/cQ== X-Gm-Message-State: AJaThX4c74kFYL7ZeXvzekgwLaK+j+FeGnA+HeAB0tqVjGKR/hcg9MVS CV28ptz87tXi2P7VvVm7Db4= X-Google-Smtp-Source: AGs4zMbYEdIQ1I39w4XunTUejxGGkgX1fwIyWDT03EMzCzGgAM55BWP/g8EoNhySwyTNRXyZBB4b0Q== X-Received: by 10.99.152.68 with SMTP id l4mr8141388pgo.208.1510563431717; Mon, 13 Nov 2017 00:57:11 -0800 (PST) Received: from ?IPv6:2001:67c:370:1998:9c78:a1b3:a8c8:8ef4? ([2001:67c:370:1998:9c78:a1b3:a8c8:8ef4]) by smtp.gmail.com with ESMTPSA id l22sm36314215pfk.45.2017.11.13.00.57.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 00:57:10 -0800 (PST) From: Fred Baker Message-Id: <9D8E929C-E640-42F5-961C-ECF05B2D20EB@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E0507CDA-AED1-40D3-A1B7-019C16B52FC0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.11\)) Date: Mon, 13 Nov 2017 16:57:09 +0800 In-Reply-To: Cc: v6ops@ietf.org To: Lee Howard References: X-Mailer: Apple Mail (2.3445.5.11) Archived-At: Subject: Re: [v6ops] "No IPv4" experiment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 08:57:13 -0000 --Apple-Mail=_E0507CDA-AED1-40D3-A1B7-019C16B52FC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 13, 2017, at 4:41 PM, Lee Howard = wrote: >=20 > What did people think of this experiment? >=20 > Personally, I had some trouble. Personally, I have been on NAT64 since arriving on Friday, and have had = no issues. --Apple-Mail=_E0507CDA-AED1-40D3-A1B7-019C16B52FC0 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+AFAloJXmUACgkQEhdRnd2G P+CnJQ//RFBBnP4vLV6W7DUthawyOVUmyKKAnjqgSV+MfFrOViZ6ocGX74LkIt2d OfnDeA8av6ifhMQv5M24sTo6iugg/m9VyXptYnLkz3FjAnCU9mfT3FQIrxm69P2c o5L9h41OsS2Z7X6mCq3W7AveqnD8RFZ96o0o77uGMD5RzfClWl29maZucUOtHq96 30vYW7uPf/1PTCFbbzDZB8PEjruXPYx6dQQbYzbDwRHsv7kNakDpZQVOKp+Was/A dcCrV8UkvpH9ecK4CHGrDGev4ajeuXEi46+NJZoNQ1AvSjfH9CDy93FGJ/ZFodZj 3B7WwbwAA8Wah5zZzGARk/CW+qgNWCehx9EF2TTj+fybbvLs+G41PkmGz2doEYX+ DNPQgdQYAlKed7CWuA5WcJ0SN4bplnF+9lEpQ83MaXkQYvmVwI4Gy0LybgHko4Ar p17wWW8rS37pQRB/LTFARHVqIkTkEuOKbJIQ95cGBpF81RknkV1y5hZItaycSIeX Mhmn1dDHgxxwEIi8R4oIR+sEppLCckGLYahOrFN6mfn+Nm1vhba2urIK05gai9sC FO5UIYWj6xizlDiZFAf4edQ/T+RJgPyAf+5hHrKIImzwBpCnMyM/2RnIjU8aCazh ycbMIiIAv1hKYD0VP9pXfYb3AglZHs5pq7Ok7BdxtCKvDmXaIw8= =jiNU -----END PGP SIGNATURE----- --Apple-Mail=_E0507CDA-AED1-40D3-A1B7-019C16B52FC0-- From nobody Mon Nov 13 01:00:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AD61294F7 for ; Mon, 13 Nov 2017 01:00:00 -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 u16j0eYrmQSf for ; Mon, 13 Nov 2017 00:59:59 -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 D56EC126CC4 for ; Mon, 13 Nov 2017 00:59:58 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id m191so6478562itg.1 for ; Mon, 13 Nov 2017 00:59:58 -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=qbn4ZmdT+imh6d8A38Qe72UfLfDHDv+Rr2OUtmQFNbY=; b=Cw90KIqdo/Six6qDnXGUIaBJ5RCDgqt644HtgbdCxgFQbqGekvAOHVY+53U7H3cdbe I00QLYhMSthXOuWwN2eTXPgUTqvZ1ruDnCDxFE3uKAoCcz75WQvyLIKM5uJQPIU4TbpU Q9nbvQsobOoYfkOKwsKq25f15g5NANTCUSb+F/xtI4dG97xv8Wg0IC7HhhDU9TX15+dp QfSeYroUyOqzv7ax1YVrZjMQaVbTvKfle6x0hpN1r6OCPPiP8u2p4FmehQYvx5EUpD+b +j9Tk/ZT7WkH0RVxGj2mJVPGZVWOcgiLGPg8WvCbbsG8D1Jj/abCngCokwv63Pck6S4b Bvzg== 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=qbn4ZmdT+imh6d8A38Qe72UfLfDHDv+Rr2OUtmQFNbY=; b=uFrv9DAyDLhps3S7IIZUpUS/b/zgdvBpC7ZBXYSUrmgkpio1PYnWtZS9osuu4V8rFo EzNZ0iczDfvECiIt6XCwSaODnfDM+p9pSpBrbWMyXb7f1Ol2MlIhbWREYyJi2gtcO3Kf jmAespIpkUt/rILlOBdEN3g42+UTocfYXQQlXPdxxdCHL13x4YeadGasR+6KBOKfJPUk mVX7NQSyPc4nmPOV0Kh8JjsJbGzsxPb+nlTW3Sgcforh+bhPx7ioVrp7mbMLF614+3Qv V4pHP2qIUmg9979GnpCqnSlwgoKlEgtGmI6/9P6FWM9Gf6BdqlDBlgekEO5GQgr3mdKj 5EmQ== X-Gm-Message-State: AJaThX6zvdJU5fP+K3rn35YO4v5q2JvLVHkYZjfkn84Qbbet0dcj4xlv DkwfyUgArktggfbAj0wrr7c8d+Nf X-Google-Smtp-Source: AGs4zMY1gi/QcEg3fXG4pKvTnckoDPDhuJpm7oF4IYW2m/beJGcLsMl1JRWjd24W74whajf+IDH9QQ== X-Received: by 10.36.188.6 with SMTP id n6mr10486125ite.116.1510563597927; Mon, 13 Nov 2017 00:59:57 -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 196sm7362129ioe.66.2017.11.13.00.59.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 00:59:57 -0800 (PST) To: Lee Howard , v6ops@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <05c03957-fcb7-f8fe-dd84-0f111d56744a@gmail.com> Date: Mon, 13 Nov 2017 21:59: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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] "No IPv4" experiment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:00:00 -0000 On 13/11/2017 21:41, Lee Howard wrote: > I=E2=80=99ve heard some side channel conversation about the experiment.= >=20 > I hope people have opened tickets. Reminder: > https://tickets.meeting.ietf.org/newticket >=20 > What did people think of this experiment? >=20 > Personally, I had some trouble. I like to stay logged in during the WG > meeting so I can keep an eye on Jabber, and preview slides and document= s. I > was bounced off the NAT64 SSID several times, and automatically reconne= cted > to =E2=80=98ietf=E2=80=99. =20 It's been stable for me; you have a WiFi problem I think, not a NAT64 problem. I've seen two of the predicted problems (corporate VLAN fails, literal IPv4 addresses fail) but otherwise so far, so good. My tickets are at https://tickets.meeting.ietf.org/ticket/1170 https://tickets.meeting.ietf.org/ticket/1168 https://tickets.meeting.ietf.org/ticket/1159 Brian From nobody Mon Nov 13 01:04:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6074712950B for ; Mon, 13 Nov 2017 01:04: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=NEMNc6J/; dkim=pass (1024-bit key) header.d=yitter.info header.b=hpM9gSAS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysQt9pCxkF2o for ; Mon, 13 Nov 2017 01:04:45 -0800 (PST) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278AB129505 for ; Mon, 13 Nov 2017 01:04:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 2A5E8BF56B for ; Mon, 13 Nov 2017 09:04:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510563854; bh=Ve2X86UMDaVOUIP5hYWugx8H94vtX/zkvohoyEPN7Yg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NEMNc6J/TrubqbRY9hN9AEXEhRQRlpDfGxHNjWNBLAb4fhvVHQOEmc8JRl/DLPgq2 WDdYrrqVhJ1XBJyBDd0/7iBnxrlscSeYnRqbDwW+31/sXmcDJ4ov464i2u/6EjIii+ vjjrvoDMVU0Qocqcq3nsarHNG5ct79WrABZEWuRo= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrFCU6s1Jsti for ; Mon, 13 Nov 2017 09:04:12 +0000 (UTC) Date: Mon, 13 Nov 2017 04:04:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1510563852; bh=Ve2X86UMDaVOUIP5hYWugx8H94vtX/zkvohoyEPN7Yg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=hpM9gSASZe2Yuo1HZrLtB4NMNEeiAGFGxfVO8Cvmh/uEth0CtiQA/6KMdIZTe1w7y 5ce25j2MMxrSCWRRRMxHirLhLVgZQ5pxBHN4azs9r0Scg7JVDSUAdUcZETNr/EjEdc IRq3m3KdCV/+NcbHT9m+4HsIQFuZ8rXNq6BLBLhc= From: Andrew Sullivan To: v6ops@ietf.org Message-ID: <20171113090404.qgl2lexo7gdrttdu@mx4.yitter.info> References: <05c03957-fcb7-f8fe-dd84-0f111d56744a@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05c03957-fcb7-f8fe-dd84-0f111d56744a@gmail.com> Archived-At: Subject: Re: [v6ops] "No IPv4" experiment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:04:46 -0000 On Mon, Nov 13, 2017 at 09:59:53PM +1300, Brian E Carpenter wrote: > It's been stable for me; you have a WiFi problem I think, not a NAT64 > problem. I've had a lot of transient failures with the DNS server on 2001:67c:370:229::7 when using NAT64, and that looks like an outage. I haven't managed to get something reproducible enough for opening a ticket. But the interaction of NAT64 and DNS64 means that the whole deal is really susceptible to DNS timeout problems. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Nov 13 01:04:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48B112952E for ; Mon, 13 Nov 2017 01:04: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, 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 DRIOrY6PqOA8 for ; Mon, 13 Nov 2017 01:04:49 -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 3F39112952D for ; Mon, 13 Nov 2017 01:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510563887; x=1511168687; 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=HElmIRdOhH6e7WVOr2U1MU7I6 htJg+5aGjrovQK1tIc=; b=eAva9FOZGaLUD4fYkycOmszSoPiUfdY9Vq0RuqSvl 3KyDB7GFCvQ28BNxGoFew0o7MAIDZn+5U4oFQheayhO+pL/mIhP1G5u6rcWek7uc EgZ1iaxDq+PjyOHItCkoI3Oqd2UjTewHdgCpDbYRVzSS6obO/h7bElFDPNDwApnl uw= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=cC0uv4KZnRQTT/LLmPtLApI8hKjBbIOFiObpZ6PjuTbJLjREH0NkoVKH7GHy wxeqzEUaIkxKxL9+aDE/yqwb3bLseA7dqXpcJrE6aKEmb5CrCl07G6yRx 7J644rLF0enq2SoZc4R6AZaOm3x0/USX1ITh3SQt8obazwvCDFI1ZI=; X-MDAV-Processed: mail.consulintel.es, Mon, 13 Nov 2017 10:04:47 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 13 Nov 2017 10:04:46 +0100 Received: from [31.133.128.227] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005622402.msg for ; Mon, 13 Nov 2017 10:04:46 +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:md50005622402::rmAKWV70OLCOuMPq:00000qld X-Return-Path: prvs=149031125e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Mon, 13 Nov 2017 17:04:34 +0800 From: JORDI PALET MARTINEZ To: Message-ID: <14C03A8B-4922-4B9C-A1F8-F2122340459D@consulintel.es> Thread-Topic: [v6ops] "No IPv4" experiment References: <9D8E929C-E640-42F5-961C-ECF05B2D20EB@gmail.com> In-Reply-To: <9D8E929C-E640-42F5-961C-ECF05B2D20EB@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] "No IPv4" experiment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:04:57 -0000 I=E2=80=99d troubles as well, my VPN was connecting and disconnecting, and = most of the time didn=E2=80=99t wanted to connect, so it was really disturb= ing and I give up after 30 minutes, not being able to send/receive emails, = and not doing my work. I still believe IETF network must never be used for experimenting. We want = to duplicate what is real in customer networks (dual-stack with private add= resses, unfortunately for a while). It surprised me, because during the hackathon, I tested the same VPN (OpenV= PN to the same server, which actually is a LEDE router) and it always worke= d. It may be a specific implementation problem of the NAT64 used in the IETF n= etwork (in the hackathon we used VPP-NAT64), or some WiFi problem in that r= oom, so I will try again during the week. Regards, Jordi =20 -----Mensaje original----- De: v6ops en nombre de Fred Baker Responder a: Fecha: lunes, 13 de noviembre de 2017, 16:57 Para: Lee Howard CC: Asunto: Re: [v6ops] "No IPv4" experiment =20 =20 > On Nov 13, 2017, at 4:41 PM, Lee Howard wrot= e: >=20 > What did people think of this experiment? >=20 > Personally, I had some trouble. =20 Personally, I have been on NAT64 since arriving on Friday, and have had= no issues. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Nov 13 01:49:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033B4128AB0 for ; Mon, 13 Nov 2017 01:49:18 -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 uyNboyT7HPYP for ; Mon, 13 Nov 2017 01:49:14 -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 8A5A612762F for ; Mon, 13 Nov 2017 01:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1510566552; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=X8esCptYSarXUsV64/nFLGs9zwh5Jl8iH9gelPq1UEY=; b=VEF9Ws8kpHAmtXeRuzwfEVfgbocc4P/m3YDjO1L0hoeDVCDCHz2vJ1EVHA6CzJXvwEbrdqY+yqg/TBzAiSVhuGUFGTJLEwx+BPqNVBfs3+59UmNhHtXCsgmI6vd6WoJrhM7SG5ubLt8rKf6DK80dWM8+tiERq6aZXqfDdDzMzVM= Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03lp0087.outbound.protection.outlook.com [94.245.120.87]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-45-wyBtfx16PPmWGIcx8ED86g-1; Mon, 13 Nov 2017 09:49:08 +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 09:49:08 +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 09:49:07 +0000 From: Tim Chown To: "jordi.palet@consulintel.es" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] "No IPv4" experiment Thread-Index: AQHTXFs6WhUnmyRCaUu9ZLZPg5L49qMSAg+AgAACEwCAAAxygA== Date: Mon, 13 Nov 2017 09:49:07 +0000 Message-ID: <4F89F675-3CCB-4BF7-A193-C6630D6C8DD6@jisc.ac.uk> References: <9D8E929C-E640-42F5-961C-ECF05B2D20EB@gmail.com> <14C03A8B-4922-4B9C-A1F8-F2122340459D@consulintel.es> In-Reply-To: <14C03A8B-4922-4B9C-A1F8-F2122340459D@consulintel.es> 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:bce0:db9:66af:3b52] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1137; 20:UYdEl4JZhFeVdgoupc/5GyeeW07MzHjMSrCej7Ww45dlC/d8WYChbyRlxckKcTymsXgTjo7HX6OYD2dlJWvR2aJQNO7HqCnmno+Dm272O4KWxaHBTsVxhcyIKKtylgYXHCMX+HajVwXEmZNuMS26YHVKEeUb8CKdrwYlJUinUYM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ccd49860-4514-4c4c-828d-08d52a7bc8b8 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)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(3231022)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(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)(52024003)(199003)(59124004)(189002)(24454002)(76176999)(966005)(81156014)(72206003)(36756003)(786003)(81166006)(53546010)(478600001)(6486002)(99286004)(7736002)(106356001)(4326008)(86362001)(82746002)(8936002)(5660300001)(316002)(83716003)(101416001)(25786009)(14454004)(105586002)(33656002)(189998001)(50986999)(8676002)(50226002)(6506006)(6246003)(53386004)(5640700003)(3660700001)(3280700002)(5250100002)(6436002)(2906002)(2900100001)(2501003)(74482002)(5890100001)(229853002)(2950100002)(102836003)(6116002)(6512007)(305945005)(97736004)(6306002)(68736007)(42882006)(6916009)(2351001)(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: <72D79BB3B8D4834A82ECDFC1CCE720E2@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: ccd49860-4514-4c4c-828d-08d52a7bc8b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 09:49:07.9047 (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: wyBtfx16PPmWGIcx8ED86g-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] "No IPv4" experiment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 09:49:18 -0000 VGhlcmUgaXMgYSBsaXN0IG9mIE5BVDY0IHRpY2tldHMgYXQgaHR0cHM6Ly90aWNrZXRzLm1lZXRp bmcuaWV0Zi5vcmcvd2lraS9uYXQ2NA0KDQpUaW0gDQoNCj4gT24gMTMgTm92IDIwMTcsIGF0IDA5 OjA0LCBKT1JESSBQQUxFVCBNQVJUSU5FWiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+IHdy b3RlOg0KPiANCj4gSeKAmWQgdHJvdWJsZXMgYXMgd2VsbCwgbXkgVlBOIHdhcyBjb25uZWN0aW5n IGFuZCBkaXNjb25uZWN0aW5nLCBhbmQgbW9zdCBvZiB0aGUgdGltZSBkaWRu4oCZdCB3YW50ZWQg dG8gY29ubmVjdCwgc28gaXQgd2FzIHJlYWxseSBkaXN0dXJiaW5nIGFuZCBJIGdpdmUgdXAgYWZ0 ZXIgMzAgbWludXRlcywgbm90IGJlaW5nIGFibGUgdG8gc2VuZC9yZWNlaXZlIGVtYWlscywgYW5k IG5vdCBkb2luZyBteSB3b3JrLg0KPiANCj4gSSBzdGlsbCBiZWxpZXZlIElFVEYgbmV0d29yayBt dXN0IG5ldmVyIGJlIHVzZWQgZm9yIGV4cGVyaW1lbnRpbmcuIFdlIHdhbnQgdG8gZHVwbGljYXRl IHdoYXQgaXMgcmVhbCBpbiBjdXN0b21lciBuZXR3b3JrcyAoZHVhbC1zdGFjayB3aXRoIHByaXZh dGUgYWRkcmVzc2VzLCB1bmZvcnR1bmF0ZWx5IGZvciBhIHdoaWxlKS4NCj4gDQo+IEl0IHN1cnBy aXNlZCBtZSwgYmVjYXVzZSBkdXJpbmcgdGhlIGhhY2thdGhvbiwgSSB0ZXN0ZWQgdGhlIHNhbWUg VlBOIChPcGVuVlBOIHRvIHRoZSBzYW1lIHNlcnZlciwgd2hpY2ggYWN0dWFsbHkgaXMgYSBMRURF IHJvdXRlcikgYW5kIGl0IGFsd2F5cyB3b3JrZWQuDQo+IA0KPiBJdCBtYXkgYmUgYSBzcGVjaWZp YyBpbXBsZW1lbnRhdGlvbiBwcm9ibGVtIG9mIHRoZSBOQVQ2NCB1c2VkIGluIHRoZSBJRVRGIG5l dHdvcmsgKGluIHRoZSBoYWNrYXRob24gd2UgdXNlZCBWUFAtTkFUNjQpLCBvciBzb21lIFdpRmkg cHJvYmxlbSBpbiB0aGF0IHJvb20sIHNvIEkgd2lsbCB0cnkgYWdhaW4gZHVyaW5nIHRoZSB3ZWVr Lg0KPiANCj4gUmVnYXJkcywNCj4gSm9yZGkNCj4gDQo+IA0KPiAtLS0tLU1lbnNhamUgb3JpZ2lu YWwtLS0tLQ0KPiBEZTogdjZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IGVuIG5vbWJyZSBk ZSBGcmVkIEJha2VyIDxmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+DQo+IFJlc3BvbmRlciBhOiA8 ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPg0KPiBGZWNoYTogbHVuZXMsIDEzIGRlIG5vdmllbWJy ZSBkZSAyMDE3LCAxNjo1Nw0KPiBQYXJhOiBMZWUgSG93YXJkIDxMZWUuSG93YXJkQHJldGV2aWEu bmV0Pg0KPiBDQzogPHY2b3BzQGlldGYub3JnPg0KPiBBc3VudG86IFJlOiBbdjZvcHNdICJObyBJ UHY0IiBleHBlcmltZW50DQo+IA0KPiANCj4gDQo+PiBPbiBOb3YgMTMsIDIwMTcsIGF0IDQ6NDEg UE0sIExlZSBIb3dhcmQgPExlZS5Ib3dhcmRAcmV0ZXZpYS5uZXQ+IHdyb3RlOg0KPj4gDQo+PiBX aGF0IGRpZCBwZW9wbGUgdGhpbmsgb2YgdGhpcyBleHBlcmltZW50Pw0KPj4gDQo+PiBQZXJzb25h bGx5LCBJIGhhZCBzb21lIHRyb3VibGUuDQo+IA0KPiAgICBQZXJzb25hbGx5LCBJIGhhdmUgYmVl biBvbiBOQVQ2NCBzaW5jZSBhcnJpdmluZyBvbiBGcmlkYXksIGFuZCBoYXZlIGhhZCBubyBpc3N1 ZXMuDQo+ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KPiAgICB2Nm9wc0BpZXRmLm9yZw0KPiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0KPiANCj4gDQo+IA0K PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IElQdjQg aXMgb3Zlcg0KPiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cDov L3d3dy5jb25zdWxpbnRlbC5lcw0KPiBUaGUgSVB2NiBDb21wYW55DQo+IA0KPiBUaGlzIGVsZWN0 cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdl ZCBvciBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3Ig dGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1 cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0 cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVu IGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55IGRpc2Nsb3N1 cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMg aW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMs IGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9m ZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3Jt IGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KPiANCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBt YWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Mon Nov 13 02:00:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB06129505 for ; Mon, 13 Nov 2017 02:01:32 -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 gsmBcsgtraCO for ; Mon, 13 Nov 2017 02:01:26 -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 95D1E128B38 for ; Mon, 13 Nov 2017 02:01:26 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id s75so12316607pgs.0 for ; 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=I8nIiXeDl63xhcUy3NbEYhc6DmjqplQJQMglC79wqgOkBlHXiWKRiLIhdbauQ1Urha yLz74LK/1uW4ZkiTlcHbp9ekWAzL1PnE/JUpvgUDUE21DjL7xTPEDKBX3JzYhBzN0baa gJDpDDKeHE9VJ/zZTYKUi44afaJWZP17cs4Tkj+Ii7WOLmqOii0fq+n7M7a9dl15sbgz +y322bpRI058GaYr3ipg4iBha+MCp0fkxO3UerH/Toz6frHuhuu0np6O5KJLAUeQVpvs jkbNPeWSPCsoYsxirFUPIXXyYhW0llAdmRs5IZv/LgrlJlD0arGI3tuXFuSt2wMApLB4 G3Fw== X-Gm-Message-State: AJaThX4QuAzvKXOoTK2KK1h7iYjnYhgGYDZaLT0Co0CWk8BFBI/PIil+ +veVGHutvo8Z/segmlV1c0Wl5w== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 10:01:33 -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:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D81B128D40 for ; Mon, 13 Nov 2017 03:14:33 -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 rT9eGaWEHUPT for ; Mon, 13 Nov 2017 03:14:31 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6406C124BFA for ; Mon, 13 Nov 2017 03:14:31 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id x28so3237257ita.0 for ; 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=nVZ2l+gLOZm2u98UJ2IdjbXKKbcpU0AkOtUk0I28Z/y2h3rnC/2tzNNa+0isIqsEk4 y39VO44TAePLhgIBn9vZ287BaV0fNwJpzBkuJgWJt0KyUjxD9NyGAYiaBTTQzqUHsYqN vmaNYtYG2R5SJCT7wmQLyT6i61l8mIo5LwXjviOYZxTWeWAjrZLMGcIGSFVBbSp5uKiz 8sUfBI5on0GMaXjjgyx7xE6FcqMu0O9iLZ+XAb6cm+SzMs0wBGtHHsDopoXVmthT5tfk xolLEEGFIHQdtszuk6CyEvvErdDBiuJ1nnTh2pOtUJUPG/m3Op5QEeBW5Vh5FRnzQniN SYJw== X-Gm-Message-State: AJaThX6zrmNtXIideDi+DSFaOvMa1tN60cCfBMnHCMCO08h+iEZUAIke OfvhNZuhHs5pJWeCKxVDNPtyOe/VY3xYzAlELC5A6A== 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: To: Fernando Gont Cc: Ole Troan , "v6ops@ietf.org WG" , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="001a1145e92ad273fe055ddb5f84" Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:56:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:10:11 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:12:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9774912955A for ; Mon, 13 Nov 2017 05:12:52 -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 eawJFA_EaZC1 for ; Mon, 13 Nov 2017 05:12:51 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CCE129418 for ; Mon, 13 Nov 2017 05:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15885; q=dns/txt; s=iport; t=1510578770; x=1511788370; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2pn1PoNgplb9Rc48cLzWrRtTvmepimd1hGkdJlwOUgk=; b=N52zUmlrskh7jRbk45VhavOB42ofrE9xy4IavIW78Dw0Hi0zUrpo6t8n RhvIj90wqQymWvk3Czfg+TVU+A/0Ln9zq2BQWoGbVj4JPoRSAHJy8Eo4t hlc27qmELlrB0L/Z4jgjO1p3guHS1Yryq3TZXFfj/KPQOb95n3RVl8NK4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAAARmQla/4kNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM1ZG4ng36KH48pgVcmiFeIMYVIEIIBChgBCoUYAhqEPj8YAQE?= =?us-ascii?q?BAQEBAQEBayiFHgEBAQECAQEBIUQHCwULAgEIDgonAwICAh8GCxQRAgQKBAUZi?= =?us-ascii?q?SVMAw0IEKtogieBQoVuDYNJAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDNIIHgVW?= =?us-ascii?q?BaAEpC4J2gmuBcFOCfjGCMgWZFIhZPQKQCYR5ghWDZYYnhyGNIohVAhEZAYE4A?= =?us-ascii?q?R84gXJ6FUktAYI2glwcgWd3iGEBAQE?= X-IronPort-AV: E=Sophos;i="5.44,389,1505779200"; d="scan'208,217";a="313796362" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2017 13:12:49 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vADDCnBs026223 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2017 13:12:49 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:12:49 -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:12:48 -0600 From: "Rajiv Asati (rajiva)" To: Ca By CC: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] GTP questions Thread-Index: AQHTW69jkWWsWc8t/kq0Wf5AaxZO16MRPFkAgAEOfVI= Date: Mon, 13 Nov 2017 13:12:48 +0000 Message-ID: <05D2842E-AD51-450F-9124-6E3ABBA6D450@cisco.com> References: <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> <40ec0857-30b1-8e7e-ec41-545d8f604d01@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 Content-Type: multipart/alternative; boundary="_000_05D2842EAD51450F91246E3ABBA6D450ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] GTP questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 13:12:53 -0000 --_000_05D2842EAD51450F91246E3ABBA6D450ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxzIHNlZSBpbmxpbmUsDQoNCg0KT24gTm92IDEyLCAyMDE3LCBhdCAxMDowNSBBTSwgQ2EgQnkg PGNiLmxpc3Q2QGdtYWlsLmNvbTxtYWlsdG86Y2IubGlzdDZAZ21haWwuY29tPj4gd3JvdGU6DQoN Cg0KT24gU3VuLCBOb3YgMTIsIDIwMTcgYXQgNDoxMSBBTSBBbGV4YW5kcmUgUGV0cmVzY3UgPGFs ZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb208bWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFp bC5jb20+PiB3cm90ZToNCkhpIE1pa2FlbCwNCg0KU29ycnkgZm9yIGxhdGUgcmVwbHkuDQoNCkxl IDI5LzA5LzIwMTcgw6AgMTA6NDQsIE1pa2FlbCBBYnJhaGFtc3NvbiBhIMOpY3JpdCA6DQo+IE9u IEZyaSwgMjkgU2VwIDIwMTcsIEFsZXhhbmRyZSBQZXRyZXNjdSB3cm90ZToNCj4NCj4+IEkgd291 bGQgbGlrZSB0byBhc2sgd2hldGhlciBieSAzR1BQIHNwZWNzIHRoZSBHVFAgcGFja2V0cyBjYW4N Cj4+IG9wdGlvbmFsbHkgYmUgdHJhbnNwb3J0ZWQgaW4gSVB2NiBtZXNzYWdlcz8NCj4+DQo+PiAz R1BQIHNwZWMgIkdUUCIgUmVsIDE1IG9mIFNlcHRlbWJlciAyMDE3IHNheXMgdGhpczoNCj4+PiBV RFAvSVAgaXMgdGhlIG9ubHkgcGF0aCBwcm90b2NvbCBkZWZpbmVkIHRvIHRyYW5zZmVyIEdUUA0K Pj4+IG1lc3NhZ2VzIGluIHRoZSB2ZXJzaW9uIDEgb2YgR1RQLiBBIFVzZXIgRGF0YWdyYW0gUHJv dG9jb2wgKFVEUCkNCj4+PiBjb21wbGlhbnQgd2l0aCBJRVRGIFJGQyA3NjggWzEzXSBzaGFsbCBi ZSB1c2VkLg0KPj4NCj4+IEluIHByYWN0aWNlLCBhIHBhY2tldCBjYXB0dXJlIG9uIFBHVyBzaG93 cyBhbiBJUHY2IERIQ1B2Ni1QRA0KPj4gU29saWNpdCBtZXNzYWdlLCBwcmVjZWRlZCBieSBhIEdU UC1VIEhlYWRlciwgd2hpY2ggaXMgaXRzZWxmDQo+PiBwcmVjZWRlZCBieSBhICJHVFBVIFJ4IFBE VSIgd2hpY2ggaXMgYW4gSVB2NCBVRFAgcGFja2V0Lg0KPj4NCj4+IFRoZSBVRFB2NCBwb3J0IG51 bWJlciB0aGF0IHRyYW5zcG9ydHMgR1RQIHBhY2tldHMgaXMgMjE1MiwNCj4+IHJlc2VydmVkIGF0 IElBTkEgYW5kIGF0IHRoYXQgM0dQUCBzcGVjLg0KPg0KPiBJdCdzIGFuIGltcGxlbWVudGF0aW9u IGRldGFpbCB3aGV0aGVyIHRoaXMgaXMgY2FycmllZCBvdmVyIElQdjQgb3INCj4gSVB2Ni4gVURQ IGNhbiBiZSBjYXJyaWVkIGJ5IGJvdGguIElmIHlvdSByZWFkIDI5LjA2MCBpdCB0YWxrcyBhYm91 dA0KPiBHVFAgb3ZlciBib3RoIElQdjQgYW5kIElQdjY6DQo+DQo+ICJJZiBhbiBJUHY0L0lQdjYg Y2FwYWJsZSBTR1NOIHJlY2VpdmVkIElQdjQgR0dTTiBhZGRyZXNzZXMgZnJvbSB0aGUNCj4gb2xk IFNHU04sIGl0IHNoYWxsIGluY2x1ZGUgSVB2NCBhZGRyZXNzZXMgaW4gdGhlIGZpZWxkcyBTR1NO IEFkZHJlc3MNCj4gZm9yIENvbnRyb2wgUGxhbmUgYW5kIFNHU04gQWRkcmVzcyBmb3IgVXNlciBU cmFmZmljIGFuZCBJUHY2DQo+IGFkZHJlc3NlcyBpbiB0aGUgZmllbGRzIEFsdGVybmF0aXZlIFNH U04gQWRkcmVzcyBmb3IgQ29udHJvbCBQbGFuZQ0KPiBhbmQgQWx0ZXJuYXRpdmUgU0dTTiBBZGRy ZXNzIGZvciBVc2VyIFRyYWZmaWMuIE90aGVyd2lzZSwgYW4NCj4gSVB2NC9JUHY2IGNhcGFibGUg U0dTTiBzaGFsbCB1c2Ugb25seSBTR1NOIElQdjYgYWRkcmVzc2VzIGlmIGl0IGhhcw0KPiBHR1NO IElQdjYgYWRkcmVzc2VzIGF2YWlsYWJsZS4gSWYgdGhlIEdHU04gc3VwcG9ydHMgSVB2NiBiZWxv dyBHVFAsDQo+IGl0IHNoYWxsIHN0b3JlIGFuZCB1c2UgdGhlIElQdjYgU0dTTiBhZGRyZXNzZXMg Zm9yIGNvbW11bmljYXRpb24NCj4gd2l0aCB0aGUgU0dTTiBhbmQgaWdub3JlIHRoZSBJUHY0IFNH U04gYWRkcmVzc2VzLiBJZiB0aGUgR0dTTg0KPiBzdXBwb3J0cyBvbmx5IElQdjQgYmVsb3cgR1RQ LCBpdCBzaGFsbCBzdG9yZSBhbmQgdXNlIHRoZSBJUHY0ICBTR1NODQo+IGFkZHJlc3NlcyBmb3Ig Y29tbXVuaWNhdGlvbiB3aXRoIHRoZSAgU0dTTiBhbmQgaWdub3JlIHRoZSBJUHY2IFNHU04NCj4g YWRkcmVzc2VzLiBXaGVuIGFjdGl2ZSBjb250ZXh0cyBhcmUgYmVpbmcgcmVkaXN0cmlidXRlZCBk dWUgdG8gbG9hZA0KPiBzaGFyaW5nLCBHLVBEVXMgdGhhdCBhcmUgaW4gdHJhbnNpdCBhY3Jvc3Mg dGhlIEduLWludGVyZmFjZSBhcmUgaW4NCj4gYW4gdW5kZXRlcm1pbmVkIHN0YXRlIGFuZCBtYXkg YmUgbG9zdC4iDQo+DQo+ICJiZWxvdyBHVFAiIHNlZW1zIHRvIGluZGljYXRlIHdoYXQgcHJvdG9j b2wgR1RQIGlzIHJ1biBvdmVyLg0KDQpZRXMsIEkgY2FuIGFncmVlIHRvIHJlYWQgaXQgdGhhdCB3 YXksIGJ1dCBpdCBjYW4gYmUgYSBsaXR0bGUgYml0IG9mIGENCnN0cmV0Y2guICBHVFAgUmVsMTUg U2VwdC4gMjAxNyBjbGVhcmx5IHNheXMgb25seSBSRkM3NjguICBJZiBpdCB3YW50ZWQNCnRvIG1l YW4gR1RQL1VEUC9JUHY2IGl0IGNvdWxkIGhhdmUgY2l0ZWQgZS5nLiBSRkM2OTM2LiAgSGVuY2Ug dGhlIGRvdWJ0Lg0KDQpCdXQgeWVzLCBJIGFncmVlIHdpdGggeW91IHRoYXQgaW4gbGFyZ2VzdCBw YXJ0IFVEUCB3b3JrcyBvdmVyIElQdjYgYXMNCm92ZXIgSVB2NC4NCg0KPiBUaGVyZSBpcyBhIGxv dCBtb3JlIHRleHQgaW4gVFMgMjkuMDYwIHJlZ2FyZGluZyB0aGlzLCBidXQgaW50ZXJlc3RlZA0K PiBwYXJ0aWVzIGNhbiByZWFkIGl0IGFuZCBmb3JtIHRoZWlyIG93biBvcGluaW9uLg0KDQpJIGFn cmVlLg0KDQo+IFRvIG1lIGl0J3MgY2xlYXIgdGhhdCAzR1BQIGhhcyBkb25lIHRoZSB3b3JrIHRv IHRyeSB0byBhY2hpZXZlIHNvIHlvdQ0KPiBjYW4gc3RhbmRhcmRzLWJhc2VkIGJ1aWxkIGEgbmV0 d29yayB3aXRoIG5vIElQdjQgYWRkcmVzc2VzIHVzZWQgZm9yDQo+IGluZnJhc3RydWN0dXJlLiBJ ZiB0aGlzIHdvcmtzIGluIHJlYWwgbGlmZSBpbiBzaGlwcGluZyBwcm9kdWN0cywNCj4gdGhhdCdz IGEgd2hvbGUgb3RoZXIgcXVlc3Rpb24uDQoNCkkgYWdyZWUgdGhhdCByZWFsIGxpZmUgaW4gc2hp cHBpbmcgcHJvZHVjdHMgaXMgYSB3aG9sZSBvdGhlciBxdWVzdGlvbi4NCg0KSSBoYWQgc29tZSBk aXNjdXNzaW9uIHdpdGggc29tZSBwZW9wbGUsIGFuZCBoZXJlIGFyZSBzb21lIG9mIG15DQpkZWR1 Y3Rpb25zLiAgSWYgSSBhbSB3cm9uZywgSSBjYXJyeSB0aGUgcmVzcG9uc2liaWxpdHkuDQoNCk9w ZXJhdG9yMSBpbiBoZXhhZ29uIGNvdW50cnk6IHRoZSBJUHY2IGlzIGNhcnJpZWQgaW4gR1RQL1VE UC9JUHY0DQpPcGVyYXRvcjIgaW4gY291bnRyeSB2b3RlZCBvdXQgb2YgRVU6IHRoZSBJUHY2IGlz IGNhcnJlZCBpbiBHVFAvVURQL0lQdjQuDQoNCkFtb25nIG90aGVyIGNlbGx1bGFyIG9wZXJhdG9y cyB0aGF0IG9mZmVyIElQdjYgdG8gc21hcnRwaG9uZXMsIEkgd29uZGVyDQphYm91dCB0aGUgZm9s bG93aW5nOg0KDQpJcyBULU1vYmlsZSBVU0EgY2FycnlpbmcgdGhlIHNtYXJ0cGhvbmUncyBJUHY2 IGluc2lkZSBHVFAvVURQL0lQdjQ/ICBPcg0KaW5zaWRlIEdUUC9VRFAvSVB2Nj8NCg0KSXMgUmVs aWFuY2UgSklPIGluIEluZGlhIGNhcnJ5aW5nIHRoZSBzbWFydHBob25lJ3MgSVB2NiBpbnNpZGUN CkdUUC9VRFAvSVB2ND8gIE9yIGluc2lkZSBHVFAvVURQL0lQdjY/DQoNCkxhdHRlci4gSG9wZWZ1 bGx5LCBtb3JlIGRldGFpbHMgd2lsbCBnZXQgZGlzY3Vzc2VkIGF0IHRoZSBuZXh0IHY2IHdvcmxk IENvbmdyZXNzIGluIFBhcmlzLg0KDQoNCk15IGd1dCBmZWVsaW5nIGlzIHRoYXQgYWxsIGRvIEdU UC9VRFAvSVB2NC4NCg0KWW91ciBndXQgaXMgY29ycmVjdCwgaSBkbyBub3Qga25vdyBvZiBhbnkg Y2FycmllciB1c2luZyBHVFAgd2l0aCBpcHY2IHRyYW5zcG9ydC4NCg0KVGhhdCBzYWlkLCBpIGJl bGlldmUgdGhlIEdUUCB0cmFuc3BvcnQgbmV0d29yayBvcGVyYXRpb25zIGlzIG9ydGhvZ29uYWwg dG8gdGhlIG5ldHdvcmsgdGhhdCB0aGUgVUUgLyBjdXN0b21lciB0cmFmZmljIGV4cGVyaWVuY2Vz Lg0KDQorMS4NCg0KDQoNCk15IGludGVudGlvbiB3aXRoIHRoaXMgZGlzY3Vzc2lvbiBpcyB0d29m b2xkOiBmaW5kIGFuIG9wZXJhdG9yIHRoYXQgZG9lcw0KR1RQL1VEUC9JUHY2IGFuZCBzZWNvbmQg dG8gZGVkdWNlIHNvbWV0aGluZyBmb3IgdGhlIElQdjYtb25seQ0KdGVybWlub2xvZ3kgZHJhZnQu DQoNCkhvdyBkbyBlaXRoZXIgaGVscCBvdXQgPw0KDQoNCkFsZXgNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZv cHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby92Nm9wcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8bWFpbHRv OnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92 Nm9wcw0K --_000_05D2842EAD51450F91246E3ABBA6D450ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjxzcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXY+UGxzIHNlZSBpbmxpbmUsPGJyPg0KPGRpdiBp ZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KT24gTm92IDEyLCAyMDE3LCBhdCAxMDowNSBBTSwgQ2EgQnkgJmx0OzxhIGhyZWY9Im1h aWx0bzpjYi5saXN0NkBnbWFpbC5jb20iPmNiLmxpc3Q2QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRp dj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0iYXV0byI+T24gU3Vu LCBOb3YgMTIsIDIwMTcgYXQgNDoxMSBBTSBBbGV4YW5kcmUgUGV0cmVzY3UgJmx0OzxhIGhyZWY9 Im1haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tIj5hbGV4YW5kcmUucGV0cmVzY3VA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2Nj YyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkhpIE1pa2FlbCw8YnI+DQo8YnI+DQpTb3JyeSBm b3IgbGF0ZSByZXBseS48YnI+DQo8YnI+DQpMZSAyOS8wOS8yMDE3IMOgIDEwOjQ0LCBNaWthZWwg QWJyYWhhbXNzb24gYSDDqWNyaXQgOjxicj4NCiZndDsgT24gRnJpLCAyOSBTZXAgMjAxNywgQWxl eGFuZHJlIFBldHJlc2N1IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBJIHdvdWxkIGxp a2UgdG8gYXNrIHdoZXRoZXIgYnkgM0dQUCBzcGVjcyB0aGUgR1RQIHBhY2tldHMgY2FuPGJyPg0K Jmd0OyZndDsgb3B0aW9uYWxseSBiZSB0cmFuc3BvcnRlZCBpbiBJUHY2IG1lc3NhZ2VzPzxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgM0dQUCBzcGVjICZxdW90O0dUUCZxdW90OyBSZWwgMTUg b2YgU2VwdGVtYmVyIDIwMTcgc2F5cyB0aGlzOjxicj4NCiZndDsmZ3Q7Jmd0OyBVRFAvSVAgaXMg dGhlIG9ubHkgcGF0aCBwcm90b2NvbCBkZWZpbmVkIHRvIHRyYW5zZmVyIEdUUDxicj4NCiZndDsm Z3Q7Jmd0OyBtZXNzYWdlcyBpbiB0aGUgdmVyc2lvbiAxIG9mIEdUUC4gQSBVc2VyIERhdGFncmFt IFByb3RvY29sIChVRFApPGJyPg0KJmd0OyZndDsmZ3Q7IGNvbXBsaWFudCB3aXRoIElFVEYgUkZD IDc2OCBbMTNdIHNoYWxsIGJlIHVzZWQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJbiBw cmFjdGljZSwgYSBwYWNrZXQgY2FwdHVyZSBvbiBQR1cgc2hvd3MgYW4gSVB2NiBESENQdjYtUEQ8 YnI+DQomZ3Q7Jmd0OyBTb2xpY2l0IG1lc3NhZ2UsIHByZWNlZGVkIGJ5IGEgR1RQLVUgSGVhZGVy LCB3aGljaCBpcyBpdHNlbGY8YnI+DQomZ3Q7Jmd0OyBwcmVjZWRlZCBieSBhICZxdW90O0dUUFUg UnggUERVJnF1b3Q7IHdoaWNoIGlzIGFuIElQdjQgVURQIHBhY2tldC48YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IFRoZSBVRFB2NCBwb3J0IG51bWJlciB0aGF0IHRyYW5zcG9ydHMgR1RQIHBh Y2tldHMgaXMgMjE1Miw8YnI+DQomZ3Q7Jmd0OyByZXNlcnZlZCBhdCBJQU5BIGFuZCBhdCB0aGF0 IDNHUFAgc3BlYy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCdzIGFuIGltcGxlbWVudGF0aW9uIGRl dGFpbCB3aGV0aGVyIHRoaXMgaXMgY2FycmllZCBvdmVyIElQdjQgb3I8YnI+DQomZ3Q7IElQdjYu IFVEUCBjYW4gYmUgY2FycmllZCBieSBib3RoLiBJZiB5b3UgcmVhZCAyOS4wNjAgaXQgdGFsa3Mg YWJvdXQ8YnI+DQomZ3Q7IEdUUCBvdmVyIGJvdGggSVB2NCBhbmQgSVB2Njo8YnI+DQomZ3Q7PGJy Pg0KJmd0OyAmcXVvdDtJZiBhbiBJUHY0L0lQdjYgY2FwYWJsZSBTR1NOIHJlY2VpdmVkIElQdjQg R0dTTiBhZGRyZXNzZXMgZnJvbSB0aGU8YnI+DQomZ3Q7IG9sZCBTR1NOLCBpdCBzaGFsbCBpbmNs dWRlIElQdjQgYWRkcmVzc2VzIGluIHRoZSBmaWVsZHMgU0dTTiBBZGRyZXNzPGJyPg0KJmd0OyBm b3IgQ29udHJvbCBQbGFuZSBhbmQgU0dTTiBBZGRyZXNzIGZvciBVc2VyIFRyYWZmaWMgYW5kIElQ djY8YnI+DQomZ3Q7IGFkZHJlc3NlcyBpbiB0aGUgZmllbGRzIEFsdGVybmF0aXZlIFNHU04gQWRk cmVzcyBmb3IgQ29udHJvbCBQbGFuZTxicj4NCiZndDsgYW5kIEFsdGVybmF0aXZlIFNHU04gQWRk cmVzcyBmb3IgVXNlciBUcmFmZmljLiBPdGhlcndpc2UsIGFuPGJyPg0KJmd0OyBJUHY0L0lQdjYg Y2FwYWJsZSBTR1NOIHNoYWxsIHVzZSBvbmx5IFNHU04gSVB2NiBhZGRyZXNzZXMgaWYgaXQgaGFz PGJyPg0KJmd0OyBHR1NOIElQdjYgYWRkcmVzc2VzIGF2YWlsYWJsZS4gSWYgdGhlIEdHU04gc3Vw cG9ydHMgSVB2NiBiZWxvdyBHVFAsPGJyPg0KJmd0OyBpdCBzaGFsbCBzdG9yZSBhbmQgdXNlIHRo ZSBJUHY2IFNHU04gYWRkcmVzc2VzIGZvciBjb21tdW5pY2F0aW9uPGJyPg0KJmd0OyB3aXRoIHRo ZSBTR1NOIGFuZCBpZ25vcmUgdGhlIElQdjQgU0dTTiBhZGRyZXNzZXMuIElmIHRoZSBHR1NOPGJy Pg0KJmd0OyBzdXBwb3J0cyBvbmx5IElQdjQgYmVsb3cgR1RQLCBpdCBzaGFsbCBzdG9yZSBhbmQg dXNlIHRoZSBJUHY0Jm5ic3A7IFNHU048YnI+DQomZ3Q7IGFkZHJlc3NlcyBmb3IgY29tbXVuaWNh dGlvbiB3aXRoIHRoZSZuYnNwOyBTR1NOIGFuZCBpZ25vcmUgdGhlIElQdjYgU0dTTjxicj4NCiZn dDsgYWRkcmVzc2VzLiBXaGVuIGFjdGl2ZSBjb250ZXh0cyBhcmUgYmVpbmcgcmVkaXN0cmlidXRl ZCBkdWUgdG8gbG9hZDxicj4NCiZndDsgc2hhcmluZywgRy1QRFVzIHRoYXQgYXJlIGluIHRyYW5z aXQgYWNyb3NzIHRoZSBHbi1pbnRlcmZhY2UgYXJlIGluPGJyPg0KJmd0OyBhbiB1bmRldGVybWlu ZWQgc3RhdGUgYW5kIG1heSBiZSBsb3N0LiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZxdW90 O2JlbG93IEdUUCZxdW90OyBzZWVtcyB0byBpbmRpY2F0ZSB3aGF0IHByb3RvY29sIEdUUCBpcyBy dW4gb3Zlci48YnI+DQo8YnI+DQpZRXMsIEkgY2FuIGFncmVlIHRvIHJlYWQgaXQgdGhhdCB3YXks IGJ1dCBpdCBjYW4gYmUgYSBsaXR0bGUgYml0IG9mIGE8YnI+DQpzdHJldGNoLiZuYnNwOyBHVFAg UmVsMTUgU2VwdC4gMjAxNyBjbGVhcmx5IHNheXMgb25seSBSRkM3NjguJm5ic3A7IElmIGl0IHdh bnRlZDxicj4NCnRvIG1lYW4gR1RQL1VEUC9JUHY2IGl0IGNvdWxkIGhhdmUgY2l0ZWQgZS5nLiBS RkM2OTM2LiZuYnNwOyBIZW5jZSB0aGUgZG91YnQuPGJyPg0KPGJyPg0KQnV0IHllcywgSSBhZ3Jl ZSB3aXRoIHlvdSB0aGF0IGluIGxhcmdlc3QgcGFydCBVRFAgd29ya3Mgb3ZlciBJUHY2IGFzPGJy Pg0Kb3ZlciBJUHY0Ljxicj4NCjxicj4NCiZndDsgVGhlcmUgaXMgYSBsb3QgbW9yZSB0ZXh0IGlu IFRTIDI5LjA2MCByZWdhcmRpbmcgdGhpcywgYnV0IGludGVyZXN0ZWQ8YnI+DQomZ3Q7IHBhcnRp ZXMgY2FuIHJlYWQgaXQgYW5kIGZvcm0gdGhlaXIgb3duIG9waW5pb24uPGJyPg0KPGJyPg0KSSBh Z3JlZS48YnI+DQo8YnI+DQomZ3Q7IFRvIG1lIGl0J3MgY2xlYXIgdGhhdCAzR1BQIGhhcyBkb25l IHRoZSB3b3JrIHRvIHRyeSB0byBhY2hpZXZlIHNvIHlvdTxicj4NCiZndDsgY2FuIHN0YW5kYXJk cy1iYXNlZCBidWlsZCBhIG5ldHdvcmsgd2l0aCBubyBJUHY0IGFkZHJlc3NlcyB1c2VkIGZvcjxi cj4NCiZndDsgaW5mcmFzdHJ1Y3R1cmUuIElmIHRoaXMgd29ya3MgaW4gcmVhbCBsaWZlIGluIHNo aXBwaW5nIHByb2R1Y3RzLDxicj4NCiZndDsgdGhhdCdzIGEgd2hvbGUgb3RoZXIgcXVlc3Rpb24u PGJyPg0KPGJyPg0KSSBhZ3JlZSB0aGF0IHJlYWwgbGlmZSBpbiBzaGlwcGluZyBwcm9kdWN0cyBp cyBhIHdob2xlIG90aGVyIHF1ZXN0aW9uLjxicj4NCjxicj4NCkkgaGFkIHNvbWUgZGlzY3Vzc2lv biB3aXRoIHNvbWUgcGVvcGxlLCBhbmQgaGVyZSBhcmUgc29tZSBvZiBteTxicj4NCmRlZHVjdGlv bnMuJm5ic3A7IElmIEkgYW0gd3JvbmcsIEkgY2FycnkgdGhlIHJlc3BvbnNpYmlsaXR5Ljxicj4N Cjxicj4NCk9wZXJhdG9yMSBpbiBoZXhhZ29uIGNvdW50cnk6IHRoZSBJUHY2IGlzIGNhcnJpZWQg aW4gR1RQL1VEUC9JUHY0PGJyPg0KT3BlcmF0b3IyIGluIGNvdW50cnkgdm90ZWQgb3V0IG9mIEVV OiB0aGUgSVB2NiBpcyBjYXJyZWQgaW4gR1RQL1VEUC9JUHY0Ljxicj4NCjxicj4NCkFtb25nIG90 aGVyIGNlbGx1bGFyIG9wZXJhdG9ycyB0aGF0IG9mZmVyIElQdjYgdG8gc21hcnRwaG9uZXMsIEkg d29uZGVyPGJyPg0KYWJvdXQgdGhlIGZvbGxvd2luZzo8YnI+DQo8YnI+DQpJcyBULU1vYmlsZSBV U0EgY2FycnlpbmcgdGhlIHNtYXJ0cGhvbmUncyBJUHY2IGluc2lkZSBHVFAvVURQL0lQdjQ/Jm5i c3A7IE9yPGJyPg0KaW5zaWRlIEdUUC9VRFAvSVB2Nj88YnI+DQo8YnI+DQpJcyBSZWxpYW5jZSBK SU8gaW4gSW5kaWEgY2FycnlpbmcgdGhlIHNtYXJ0cGhvbmUncyBJUHY2IGluc2lkZTxicj4NCkdU UC9VRFAvSVB2ND8mbmJzcDsgT3IgaW5zaWRlIEdUUC9VRFAvSVB2Nj88YnI+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwv ZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwg MjU1LCAwKTsiPkxhdHRlci4gSG9wZWZ1bGx5LCBtb3JlIGRldGFpbHMgd2lsbCBnZXQgZGlzY3Vz c2VkIGF0IHRoZSBuZXh0IHY2IHdvcmxkIENvbmdyZXNzIGluIFBhcmlzLiAmbmJzcDs8L3NwYW4+ PC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2Pg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGlu Zy1sZWZ0OjFleCI+DQo8YnI+DQpNeSBndXQgZmVlbGluZyBpcyB0aGF0IGFsbCBkbyBHVFAvVURQ L0lQdjQuPGJyPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBkaXI9ImF1dG8iPjxicj4NCjwvZGl2Pg0K PGRpdiBkaXI9ImF1dG8iPllvdXIgZ3V0IGlzIGNvcnJlY3QsIGkgZG8gbm90IGtub3cgb2YgYW55 IGNhcnJpZXIgdXNpbmcgR1RQIHdpdGggaXB2NiB0cmFuc3BvcnQuJm5ic3A7PC9kaXY+DQo8ZGl2 IGRpcj0iYXV0byI+PGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byI+VGhhdCBzYWlkLCBpIGJl bGlldmUgdGhlIEdUUCB0cmFuc3BvcnQgbmV0d29yayBvcGVyYXRpb25zIGlzIG9ydGhvZ29uYWwg dG8gdGhlIG5ldHdvcmsgdGhhdCB0aGUgVUUgLyBjdXN0b21lciB0cmFmZmljIGV4cGVyaWVuY2Vz LiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+JiM0MzsxLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s aWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQpNeSBpbnRlbnRpb24gd2l0aCB0aGlzIGRpc2N1 c3Npb24gaXMgdHdvZm9sZDogZmluZCBhbiBvcGVyYXRvciB0aGF0IGRvZXM8YnI+DQpHVFAvVURQ L0lQdjYgYW5kIHNlY29uZCB0byBkZWR1Y2Ugc29tZXRoaW5nIGZvciB0aGUgSVB2Ni1vbmx5PGJy Pg0KdGVybWlub2xvZ3kgZHJhZnQuPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SG93IGRvIGVp dGhlciBoZWxwIG91dCA/PC9kaXY+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQpBbGV4PGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2Nm9wcyBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxicj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj52Nm9wcyBtYWlsaW5nIGxp c3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9w c0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wczwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_05D2842EAD51450F91246E3ABBA6D450ciscocom_-- From nobody Mon Nov 13 05:20:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0170E129577 for ; Mon, 13 Nov 2017 05:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 smMFgP7cNsw7 for ; Mon, 13 Nov 2017 05:22:22 -0800 (PST) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::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 2CC09129572 for ; Mon, 13 Nov 2017 05:22:12 -0800 (PST) Received: by mail-oi0-x244.google.com with SMTP id a132so11178240oih.11 for ; 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=gYjvCphHikvAWUzUDBJkajFOPnd36/8YwgyPpm9gGrurfAxAz3V44LwVxciZP+EZE7 oOG0kRNpX8uCeoDHydN47AD5vooTD8Iflkmhj4E+4aKeuhIOORc5CrkCAwHc0KTmPHXm +CxstRMKqBjhH2d5r51jyxg4SvQpkolNe5JRdoBXvd4BIekhfO6xqrQIkGY4tHF9BMWC NXchQTcTLI3rfiHyAcAiVvlvkTEr6H4zPloYrORz2l2G40HW72BFtUfDsXg0QGP4FSOx Tl3TPVaNw1JFbpnKtT/JNXVfYr1IAvysEsVtx/2ehtFNj9VAOPU1ZgWmehaEp0WMNBai WnQA== X-Gm-Message-State: AJaThX59aAMkh8MRmAgUrGBaBVDXTh67Yn2faBOsb2Z6X4VM/jCWKFzc nItBO/3Eu1FNQ3LJH2bUrGkC802HHvz0rMzHPzXF1Q== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 13:22:24 -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:34:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95581243F3 for ; Mon, 13 Nov 2017 05:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Usjc8mA4qg9C for ; Mon, 13 Nov 2017 05:34:26 -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 03EA2129562 for ; Mon, 13 Nov 2017 05:34:23 -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 vADDYILk172728; Mon, 13 Nov 2017 14:34:18 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 419562050D6; Mon, 13 Nov 2017 14:34:18 +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 319AA205086; Mon, 13 Nov 2017 14:34:18 +0100 (CET) Received: from [132.166.85.85] ([132.166.85.85]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vADDYFvb013547; Mon, 13 Nov 2017 14:34:16 +0100 To: "Rajiv Asati (rajiva)" , Ca By Cc: "v6ops@ietf.org" References: <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org> <20170928030630.DD2D08867238@rock.dv.isc.org> <20170928074105.BCB99886E538@rock.dv.isc.org> <20170928081527.21D9F886EF0C@rock.dv.isc.org> <40ec0857-30b1-8e7e-ec41-545d8f604d01@gmail.com> <05D2842E-AD51-450F-9124-6E3ABBA6D450@cisco.com> From: Alexandre Petrescu Message-ID: <59fbcf3a-a8da-a468-04c4-2a64b2b45383@gmail.com> Date: Mon, 13 Nov 2017 14:34:14 +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: <05D2842E-AD51-450F-9124-6E3ABBA6D450@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] GTP questions X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 13:34:29 -0000 Le 13/11/2017 à 14:12, Rajiv Asati (rajiva) a écrit : > Pls see inline, > > > On Nov 12, 2017, at 10:05 AM, Ca By > wrote: > >> >> On Sun, Nov 12, 2017 at 4:11 AM Alexandre Petrescu >> > >> wrote: >> >> Hi Mikael, >> >> Sorry for late reply. >> >> Le 29/09/2017 à 10:44, Mikael Abrahamsson a écrit : >> > On Fri, 29 Sep 2017, Alexandre Petrescu wrote: >> > >> >> I would like to ask whether by 3GPP specs the GTP packets can >> >> optionally be transported in IPv6 messages? >> >> >> >> 3GPP spec "GTP" Rel 15 of September 2017 says this: >> >>> UDP/IP is the only path protocol defined to transfer GTP >> >>> messages in the version 1 of GTP. A User Datagram Protocol (UDP) >> >>> compliant with IETF RFC 768 [13] shall be used. >> >> >> >> In practice, a packet capture on PGW shows an IPv6 DHCPv6-PD >> >> Solicit message, preceded by a GTP-U Header, which is itself >> >> preceded by a "GTPU Rx PDU" which is an IPv4 UDP packet. >> >> >> >> The UDPv4 port number that transports GTP packets is 2152, >> >> reserved at IANA and at that 3GPP spec. >> > >> > It's an implementation detail whether this is carried over IPv4 or >> > IPv6. UDP can be carried by both. If you read 29.060 it talks about >> > GTP over both IPv4 and IPv6: >> > >> > "If an IPv4/IPv6 capable SGSN received IPv4 GGSN addresses from the >> > old SGSN, it shall include IPv4 addresses in the fields SGSN Address >> > for Control Plane and SGSN Address for User Traffic and IPv6 >> > addresses in the fields Alternative SGSN Address for Control Plane >> > and Alternative SGSN Address for User Traffic. Otherwise, an >> > IPv4/IPv6 capable SGSN shall use only SGSN IPv6 addresses if it has >> > GGSN IPv6 addresses available. If the GGSN supports IPv6 below GTP, >> > it shall store and use the IPv6 SGSN addresses for communication >> > with the SGSN and ignore the IPv4 SGSN addresses. If the GGSN >> > supports only IPv4 below GTP, it shall store and use the IPv4  SGSN >> > addresses for communication with the  SGSN and ignore the IPv6 SGSN >> > addresses. When active contexts are being redistributed due to load >> > sharing, G-PDUs that are in transit across the Gn-interface are in >> > an undetermined state and may be lost." >> > >> > "below GTP" seems to indicate what protocol GTP is run over. >> >> YEs, I can agree to read it that way, but it can be a little bit of a >> stretch.  GTP Rel15 Sept. 2017 clearly says only RFC768.  If it wanted >> to mean GTP/UDP/IPv6 it could have cited e.g. RFC6936.  Hence the >> doubt. >> >> But yes, I agree with you that in largest part UDP works over IPv6 as >> over IPv4. >> >> > There is a lot more text in TS 29.060 regarding this, but interested >> > parties can read it and form their own opinion. >> >> I agree. >> >> > To me it's clear that 3GPP has done the work to try to achieve >> so you >> > can standards-based build a network with no IPv4 addresses used for >> > infrastructure. If this works in real life in shipping products, >> > that's a whole other question. >> >> I agree that real life in shipping products is a whole other question. >> >> I had some discussion with some people, and here are some of my >> deductions.  If I am wrong, I carry the responsibility. >> >> Operator1 in hexagon country: the IPv6 is carried in GTP/UDP/IPv4 >> Operator2 in country voted out of EU: the IPv6 is carred in >> GTP/UDP/IPv4. >> >> Among other cellular operators that offer IPv6 to smartphones, I >> wonder >> about the following: >> >> Is T-Mobile USA carrying the smartphone's IPv6 inside >> GTP/UDP/IPv4?  Or >> inside GTP/UDP/IPv6? >> >> Is Reliance JIO in India carrying the smartphone's IPv6 inside >> GTP/UDP/IPv4?  Or inside GTP/UDP/IPv6? >> > > Latter. Hopefully, more details will get discussed at the next v6 world > Congress in Paris. That would be a first time a cellular network operator transports smartphone's IPv6 traffic into GTP-IPv6. All the others transport smartphone's IPv6 traffic into GTP-IPv4. GTP is a an UDP/IPv4 protocol and example packets look like this. It comes from the smartphone and is captured on PGW: > INBOUND>>>>> 15:47:48:883 Eventid:142004(3) > GTPU Rx PDU, from [IPv4-address]:2152 to [IPv4-address-2]:2152 (129) > TEID: 0x80072183, Message type: GTP_TPDU_MSG (0xFF) > Sequence Number:: NA > GTP HEADER FOLLOWS: > [snip] > GTP HEADER ENDS. > Payload protocol: IPv6 > PROTOCOL PAYLOAD FOLLOWS: > fe80::b9d9:c10a:2c2d:3c3b.546 > ff02::2.546: [udp sum ok] > IPv6 Header Follows: > [snip] > PROTOCOL PAYLOAD ENDS. A fictitious GTP as UDP/IPv6 packet would look like this, remark the IPv6 addresses 'from' and 'to' in the second line below: > INBOUND>>>>> 15:47:48:883 Eventid:142004(3) > GTPU Rx PDU, from [IPv6-address]:2152 to [IPv6-address-2]:2152 (129) > TEID: 0x80072183, Message type: GTP_TPDU_MSG (0xFF) > Sequence Number:: NA > GTP HEADER FOLLOWS: > [snip] > GTP HEADER ENDS. > Payload protocol: IPv6 > PROTOCOL PAYLOAD FOLLOWS: > fe80::b9d9:c10a:2c2d:3c3b.546 > ff02::2.546: [udp sum ok] > IPv6 Header Follows: > [snip] > PROTOCOL PAYLOAD ENDS. Does such packet exist. Why waiting the next v6 world Congress in Paris to see that. > >> >> My gut feeling is that all do GTP/UDP/IPv4. >> >> >> Your gut is correct, i do not know of any carrier using GTP with ipv6 >> transport. >> >> That said, i believe the GTP transport network operations is >> orthogonal to the network that the UE / customer traffic experiences. > > +1. > > >> >> My intention with this discussion is twofold: find an operator >> that does >> GTP/UDP/IPv6 and second to deduce something for the IPv6-only >> terminology draft. >> > > How do either help out ? Well, it would prove me wrong when I am saying there is no such thing as an IPv6-only core network in a cellular network. Also, a well-defined term "IPv6-only" helps me when I approach parties proposing them "IPv6". Sometimes they seem scared of the "IPv6" word, so I reassure them it is _not_ "IPv6-only", but it is "IPv6-only" together with "IPv4". Or I may just say "IP". Ther term "dual stack" is not well understood: some times it means IPv4 side-by-side with IPv6 in the same computer, whereas other times it means a particular translation mechanism between IPv6 and IPv4 including some DNS features ("DS Lite", and others). "IPv6-only" together with "IPv4" would mean something like it works ok for everyone without any translation, tunnelling or DNS combinations. Then there is also this "native" term that would need to be clarified. And also this level: encapsulated IPv6 in IPv4 does not mean "IPv6-only" and does not mean '"IPv6-only" together with IPv4.' Just some thoughts. Alex > >> >> Alex >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Nov 13 05:35:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A154129577 for ; Mon, 13 Nov 2017 05:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=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 BNcJyowsBn9m for ; Mon, 13 Nov 2017 05:35:17 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B683F129562 for ; Mon, 13 Nov 2017 05:35:17 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id a75so5600913oib.1 for ; 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=t6Mw2XEowZk4KSsfec8uFCcdYYQrT+k7QIHk6FODTbtm33tB8a/juSQA89JKbqRfrS j5jF6wfWjUnjeZMv8LlKOw802MWBpqR+BG7+JAoqTQ70w3BX4kSHO4oocW7ZBBj4EGHu rtAMDc7+O9r8LhKJ7TIw/cjzlQ836MQHHnJlDA5DgRQA3knkv1PCrrck+peyTtNnXDGw WuyunnbhD5nPRx/XO5yjvLMCXoIQhJ/P1dUrcNTmpXcVL1/OqcSgTV5zWG0rEcKjTy85 CXS9FiIaTTx0WQkoL10DpOtuBmhN4mn9/gUxvJXu1/kLYZQ9LEJIs8VH7tgizrCQehhu jQPg== X-Gm-Message-State: AJaThX4aG2pA77d2WHKT0YLnG6sULQ/BUowANVjhtNIbOGgSYj2plYZt oa2bBZ0qZlkZY/Jn7IbYiOAbIo9KUlEX4096VzmARg== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 13:35:20 -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:56:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368831296CF for ; Mon, 13 Nov 2017 06:17:14 -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 Ogamb-wPbHKr for ; Mon, 13 Nov 2017 06:17:12 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49A51294D2 for ; Mon, 13 Nov 2017 06:17:10 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id o23so2879466otd.1 for ; 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=gKUFtN0uLDHODZyrlG8xessVRAlHR1l2SpvKFb8h8cij6hRFUuE6kNLBpdX6V3QKo8 OjotqaAYpgh4OXAswEzSfTzWkLSUPoKmyPVSWe9S+oE3L8aGA7jNlXMWdkZCFNEoNCbb Ubg5qyr+BAC3JTWxf0sNUhdS2uirK1nyiO1KWHuFAQ7ztRB2P6+4R/CKeTjZ84ZbpNeu dkQ4LoF02zTy6uvBQD5VYwhzChA1BosfxTNk7t35IrWYRNte4PpadefADnRirnLEDi/3 J6XJL4rzkDolWGZH4iObQLa9eYsM1mGXMU/MmStuKsMfs9ZLbjMMGGrH9UzYkjbz9yrx YblQ== X-Gm-Message-State: AJaThX6vcC57TrnB8G1X4KPsSffngP6qZDqhKrSnArWZ0p/BbOVomfDq WLJlPTXPspUIk9u4ag3dWMlUmQZADbuWIUZ71Cnn9A== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 14:17:14 -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:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17A0129601 for ; Mon, 13 Nov 2017 06:23: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, 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 RrM6bPEFlRUg 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 6235F1288B8 for ; Mon, 13 Nov 2017 06:23:58 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id u10so6389469otc.12 for ; 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=K7FcG3cOIxqKMRs1qqAACy3QcNvTN3DPtDdKDY1xMn8ZUiZmi8ZlnIOAsTLi17+Nis sB3BhPYKnaq+/hCCF5AVnDt9/31HMPAiVOalIqRWOIzCEZMWMameZv7LK9RAyitvqpo0 HQdHwBb3JSoU9O7KYsj7v/FnbZczjkv0JiNnoD89LWZbIdfMIYijmuULrJpCiRsAd/wv 0bLeDB5uHaBFDplQaxPw/xQ28cUH93IZ0ODjaZiFYZl76tV/T7YGglg5sowC8BLa1nZr V1GwURszt9t3YU4f4T95nx6rBRE04k04fmiBGYHmAw3g59mo3zMKJqiwU1pQknQ54t4/ ZiuA== X-Gm-Message-State: AJaThX7aFksWfIHvBekogb026v37plFUidkk700PVxASPkT/iDqhso+9 L4tt7L/LoLuVTUEHq6JNNReyMJ1KoO7/1jKt6rKJfw== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 14:23:59 -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:32 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42473129ABD for ; Mon, 13 Nov 2017 06:31:46 -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=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 llemC2bNIx8w for ; Mon, 13 Nov 2017 06:31:43 -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 B9B5F129A84 for ; Mon, 13 Nov 2017 06:31:19 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id 72so9603284itl.5 for ; 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=pkhcwMuea4UqEII70k4dotu5ZdFQuhvcTCRcrzKiraohRF8JYSp4LB9B7uET+9fBHC MmVeMW+nMIq+T29nfV5+M/RciHBl6rpHUkJ0qhWmFyYyudJvXYlLg2dUprY4ZqDhUh0A v2LHZYR3j6hqeCe0z701DjsEsRaKcZK+XsRLatJtMPae4qx7AWWKrbMMIHAMuisTCYEz qJiZyiZYPLOurTwqzWaYvgCoQJZ++JO9qenx+0ua/Hyjw4eg67//423BQkPXExHcdmrV FBpvx3ck67ZHOKkvPZFyLHxTl5ZmMdHZRJrAgwf/AiyU1MqEQ5IT1mCubX4fg52acj3s omlA== X-Gm-Message-State: AJaThX53KpRmxpCm5K/fptEtbO3Y88vxeLAWVFIUV6Ffd9HSDeRAzg6D 509f8yfmvYsr7INIbWn12kpW6kQpOf9ndHgmXwEaZQ== 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: To: Fernando Gont Cc: Victor Kuarsingh , IPv6 Ops WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="001a11448c12aac329055dde1fd8" Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 14:31:46 -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:51 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C88C129A84 for ; Mon, 13 Nov 2017 06:56:17 -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=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 xZSfkpGWnN0P for ; Mon, 13 Nov 2017 06:56:14 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653EB129A96 for ; Mon, 13 Nov 2017 06:56:14 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id n16so2336468oig.3 for ; 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=OWiOtcTZf7qI7vadUKmcw/7n4spnKiIjzv8/hqQqnyduntzNtgRwi+QhLjrdIWvO/F Qp7LXZ3LNp+nBa1DGKtQZYccEzOBszMZjNa9Kp3ruXunfy43iAcPjAZzsO/V3Ye14zsx VWev67i/7mfVKQoys1aCP9MlR8b57mkNo+vxAGEr1diQolvaGUDoGWDp/AMW9mS+F2WR xaAM5yDeJh3GnNR68CMJhaANSo9U1hN+W7+eHO/R4KIUVsr+TbHhZFmLkEZ6fDDhe14b hiUAKNCQVYY8hW9kKRu8huxY982q9uJL6++tR1hxrMRDR3iCxIUulpw0RfiGce/auVXb 73Zg== X-Gm-Message-State: AJaThX6JY9qdS924GO1KZGOZlWFDyXN7Fvin/sxkqu3aGw+USHFds9nG S9O7CvvwuJt7618cJPAS2LD5pUJ3BowM/sJyACvX1Fdp 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:58:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BF21289B5 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: -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 uuivqsfUmfPm for ; Mon, 13 Nov 2017 06:57:57 -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 4F716129AB7 for ; Mon, 13 Nov 2017 06:57:52 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id m191so9631407itg.2 for ; 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=FAnEYT4I9DoGeOYvtdvv6S0cjyKiRjzYCFADtn/+4G0bjM4QG16TTnQEzacldJJ8yX 7WakRr77l/xw7GGnbBRvhc0J/eBtT0h0FQZDskWP1E/UPQxHISzAoF9nMVTJ7FXvJXxn HhKooWz2gDvusgTU/ZNlZ2ugcyd71svG8c7uGKoxwzUMlFL+eW6cC5C2qqeugju/627X /i2Ngke4MOR9f7p2yRSMHh9zcm8Dg7608pG3BevQPpwGuDFS6X369NUIp1dVDUf/cPda /ABliK57dTiVLbdv6ZXdVTx48bA8vbJfa8P0ju0jX3QnLWOwM1pJ2m/YV5RZwWzDeOqX fFow== X-Gm-Message-State: AJaThX6lOGMhAzYucNK01SM4cJjHd6lJ3gjP8VNmyOHEkF3tbdU2kjD+ rE/KjDruAAu4LOItpYwmXXUgXVx5/xRx91jyDrnyJQ== 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: To: Fernando Gont Cc: Victor Kuarsingh , IPv6 Ops WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="001a11448c1297fd95055dde7e92" Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670A812945B for ; Mon, 13 Nov 2017 07:14:16 -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 cjoeHqyMn9ra for ; Mon, 13 Nov 2017 07:14:15 -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 459ED129421 for ; Mon, 13 Nov 2017 07:14:15 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id u132so9802297ita.0 for ; 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=CRlNbEsZaLz4WLOKlWrPyeHtqU6D3ZOs2KBFi2fQYk4nIr4cOXGPKWOq91zsW4Htfu 5NlTMpsENgXNiYTma2EPSq2K95qmKxDLxIp5zUa9WaFO3xErWS0wAjk0VRXwWUsTQ4rQ LRKybAlJ68TL2keR6daJj/x9q/sxU24pgT+k64PtzcEbVOGkHPB3V0nhgPpIbSN75Sjw OMRd3Q2WrkxmV7s9mNKh9zohGMDIwNiGqkh/WsaS1Y8WxbZa/TJA1muLbe6zsPnbX3ei oMZw6PAvyzx85vmhgHdPC1ja1/S0fpd+R6nd0cQdWSkrg6EhuGLeJwwROcoN8f2XwSE4 tvJw== X-Gm-Message-State: AJaThX5RBmET56wobedz3fX3pRfgo1n8PESCslMU6YGrLTwfGfBzgzgx FFnoR3r5Wdm2MuOVyV1KKPGKTY7tUqDPIpHzd7nZ7Q== 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: To: Nick Hilliard Cc: Fernando Gont , "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a1144d01e29d959055ddeb9f5" Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:14:16 -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:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:34:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B62129AE9 for ; Mon, 13 Nov 2017 07:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op-dPo8DmJMA for ; Mon, 13 Nov 2017 07:34:01 -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 E96B9129454 for ; 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 6FEA519F for ; 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 VeMgMSZabXSm for ; 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 F184C948 for ; Mon, 13 Nov 2017 09:33:58 -0600 (CST) Received: by mail-lf0-f69.google.com with SMTP id o2so4310327lfe.10 for ; 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=SK7W5i09IHi+ApvyJv3Ivs1fbHY3259hXwnwy9+CNFiZ7kHgaJHQlliyngTVxWUxIr quuuRuIjixXwTEVQt5Ic831mQiK4pyYSNzfbyCU9/UBdywdDP5HEjSbYCB6pbbRZoiMW /U4CCvxZLnDp+/c8UfFAbXnC65UelM4KBn9B/HTmz8qX/jp562dx5j09cSH9IhIwoxGu l24CcKt876NE6sbSUz1zYHLApq2zG3cxdvO/Rc6ujczTYi6/k/2ValMOpRbVuAbSLWQj jJ05G0Jbhb5XDT/aShEtXOKARQB22RgzibXKFsi0S8KxQoHeq1lJr1ZiuJKRr/BlhpL2 4tCg== X-Gm-Message-State: AJaThX5+yzDc1wrs4U99GlBfbPyqzAmTCFonOtyZtrjxWvHBFTnKGFeJ 1KbfDaQUEqGe5xw2ZbSrWwD5LebGRFt3iJxT0un81rkqG178UxB7NgSbyGdns+ELlPreX3uJ2Ht tb+j1ASMLlpRNAH1BKZVN+cTZ9w== X-Received: by 10.46.20.79 with SMTP id 15mr3296375lju.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: To: Fernando Gont Cc: Ted Lemon , IPv6 Ops WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="f403045fbe34a7c4ae055ddefff9" Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:36:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:47:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5AF129449 for ; Mon, 13 Nov 2017 07:46: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=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 t47yl0MW6hUI for ; Mon, 13 Nov 2017 07:46: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 CF3841205F1 for ; Mon, 13 Nov 2017 07:46:53 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id g73so5496094ioj.8 for ; 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=GolJVTnsgdv4cvZqJEd5+hgeAsjNmOdC0WDKvrnQpgZzGCyPsM47DBeDyzx4Y5tVtq JD33Rj7vkpXQebl6B8XVKK4iPyNEzP1lmoxcJYtABb34KMDBesgqs8S1N6TgdKMb+cso JdwO2f25nx/Gs/L2JaoHMl+28vfj0ow+wV6DYVH1R9cw449+MQLZh5C7jdosdhkW20J2 lKCEXbxESwSgR2zl+LoVrYOe7p6W2YzTCqh1Y0DIz/Y4v7prdypp0xw6flK/1BVr6ji5 n/t5nYRg2m38gBjAcuOYfwGsBwRV1UI0JClrqhJZyo2FiIDqxZzVttFnKPfY0Ty88izo diQA== X-Gm-Message-State: AJaThX5w/S9zjJLpXPBtGCDs6gx+FF+l/nIBwwkzRcQFIZQyfKMKmynI AdvP7GNO6khS/42TwWLDO1MKNhTBJx2cizFObALzfw== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 15:46:56 -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:28 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 08:44:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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)" 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84593129B14 for ; Mon, 13 Nov 2017 09:09: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 jw4EYY_8kZgI for ; Mon, 13 Nov 2017 09:09:13 -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 4161212009C for ; Mon, 13 Nov 2017 09:09:13 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id p186so21370263ioe.12 for ; 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=oSeKCn5wpdhE+dadQ/W3zREWFu5JavWJ+R0A5FCdx6/rQhM8u9L8odBfd5CuowXlE1 thVxbMFlHvPaGd15AsnJa/fD++dj9/ZkgkC7GlcUIgNOatIl5YzUZvupTyya+FQBoY8Q oGFLlc8m8pUeMILOz7fgM9kgykU2hhA7G6FK6K9K82uwjYqRPibkj2ExoaDlA5VZ2rd5 T09Gc8cCiV1ayNKLD/w1kPW4r4lW9OsO0y9HwI8oomzS09sOO0fizJi2OaYWa+pEDMVe AP08zpO6uOeyiPUeiamGlKhGeYmJbQLcTlh0hFDIsnyvQhDLxFhbn+qRpmHCd7CyIdbR rwzg== X-Gm-Message-State: AJaThX5pmolkgOl6udZuDQXYo67qlPwxGU72dMav9qXtTAq/y6AMXHnJ ATOxMoqmgUTaqA2Lv1HLLO/CdQCB562iASu8RKU7cw== 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: To: Nick Hilliard Cc: "6man@ietf.org" <6man@ietf.org>, "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a11445e9e50e808055de05403" Archived-At: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 17:09:14 -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 11:03:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93A0129B57 for ; Mon, 13 Nov 2017 11:03: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, 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 Pam7y7CdJt3B for ; Mon, 13 Nov 2017 11:03:21 -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 81A11129B50 for ; Mon, 13 Nov 2017 11:03:21 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id n134so7017678itg.1 for ; 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=rtcFmjhkhi8RzJEjeY380aa/PTcKFWcIRPuI7/kP8IdXONAelqEb52vkwlNx4IzjQ+ cH4WLk+yFX0b4j0l51prDsFRr9Wtsyjn6hHOL2IK7im+kfh17VKoPFUSMIz8yQ2Vvupl xxxVgBw2/pkw/C533TuWy0SGIhp9c0daAORgMdO9uqErlSQthc/lKQZu1DMReWi9BKJ5 nR7TTuaaAPFUKyoCkxfbdrx2D3TstVl6pG8Sh11HQqkMUr7diUnqxFkrj3wO5J+Fec79 0ZESxbB6qpdqvweXjVCwgSz/2t/5AZxSHBW61J/OmcRTphHATrEWyP5Hvn2/yreaTQPJ PRtQ== X-Gm-Message-State: AJaThX7bn7t/3P4ZITzKgKbXo78jb2wN6xSGYFSvKwjyn2b3eAwuM14T 8Yfi1raS319rJNbHrzr+RAJgLA== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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:42:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07377129B56 for ; Mon, 13 Nov 2017 11:42:28 -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 z64QsiHx5__V for ; Mon, 13 Nov 2017 11:42:27 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 C3662129B50 for ; Mon, 13 Nov 2017 11:42:26 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id a194so19072598qkc.9 for ; Mon, 13 Nov 2017 11:42:26 -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=j05Na+o7PsAuwfGb6f9UtGiajoKe0PS3X8tYndvxY6c=; b=Ne0yWLBOaE/USm8flxkE5gfGBho4NAqiuyq7Mxl4JKi2b4cGFpzyu2X7nLrrNx/U9b YOKfZIy2Hd5KRlKxHz/aDkIokBeY29mrOTgA87kRI5bnVwOghaHwvI4QASGb1a62ihmI JxRZgcYF2aJvjuRALo5PAjlA4//KQSa04MGee16lJCzQzB245aEE09XcYorTrZy7tqES 9OF6jINmFuPasgLwLYtFOarPRNs33zwxOganDEQVlvK1/oWSnWZ15NzKRHtmzR1CT5as 6cp9e8p09aSPSrioTNAoMfDd3pzz6fqd0MqDRpbcmkg0FrBhR9uDsAurJDcW4j2Gmwgx pXFg== 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=j05Na+o7PsAuwfGb6f9UtGiajoKe0PS3X8tYndvxY6c=; b=WFA5LotDfBYgIVvhkk16iFctD3USG7RVFwSCnU9faSTC7GEi202fUx7tqUXN+Xi93V AAqn1YVtAz0aot67n56kX1RfrlXib52kBOZsh/Q2LRUIr1BoZ36b76n5bLawQM4yzDJJ Uon+evoLhdesHHp8Zeg9dNPHpLDTw6kqKsBxe725t71ZqFG6jDQ9Pgs1ZL8bCUFCdrZ2 Dg4c0h6N3l6BKUk6UaiM6ENcXnBSUeFdIcUGMWAfVyDgdvt40buFgPdqs6MUixGi7TEA UpcrPYaI05kvbR6TnrhqRwGXiuHJPsn3SnGaGcaoC/0FgbNxbjTnhuZiTwi40MeG6ZTw Vs5Q== X-Gm-Message-State: AJaThX75v+qhKqO+deSid+OqWX832rKRIUvPXpj1Uo3T2ifqTQGI5rlW 82uio/ziEKAzgDY3NvLWo07bzaBtHdq1O+phWkqzog== X-Google-Smtp-Source: AGs4zMYQDL8NMv5eP5STzT8aLycGxjUHI2e3XZ1+U0ClbU53sbL4DGQcpG3eQ+JTmjDlguLzT3YsCy+PXYPUWJrzg2E= X-Received: by 10.55.106.132 with SMTP id f126mr14985292qkc.295.1510602145863; Mon, 13 Nov 2017 11:42:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Mon, 13 Nov 2017 11:42:25 -0800 (PST) In-Reply-To: References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <89d4d29f-30ab-756d-b02c-cf460ef833ce@si6networks.com> <6ed75c9e-5f15-6207-4723-85d055a9768f@si6networks.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> From: Tom Herbert Date: Mon, 13 Nov 2017 11:42:25 -0800 Message-ID: To: Mark Smith Cc: Ted Lemon , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Security: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 19:42:28 -0000 On Mon, Nov 13, 2017 at 12:30 AM, Mark Smith wrote: > > > On 29 Oct. 2017 09:20, "Ted Lemon" wrote: > > On Oct 28, 2017, at 5:59 PM, Tom Herbert wrote: > > Some of this has been touched upon in the IDEAS discussions, but nothing > formalized yet (identifier-locator use implied to eliminate as much topology > on address as possible). I could spin a draft specifically on one time use > addresses and privacy (won't make cutoff though). > > > The problem is that now you have a requirement for substantial > infrastructure to manage the ID/locator separation. Would look a bit like > Tor. Who's going to pay for it? > > > Actually, I think multipathing e.g. MPTCP goes a long way to solving that > problem. The 32 bit token generated and used by subflows to identify their > peer is a temporary host ID that is independent of the locators/addresses of > the host. > > My understanding is that in "original" ID/locator separation, the host ID > was expected to be fixed and bound to a host across many transport layer > connections. Perhaps that's what makes it a hard problem. > Mark, The idea of single use addresses is that a host can be assigned many identifiers from which it can create a unique source address for each connection. It is up to the infrastructure to direct packets for each addresses to the right end host. It's true this is potentially a lot of state for the infrastructure to manage, but the total number of state entries would be no more than the number of NAT entries if that were in use today so I don't believe it is impractical. > Temporary, per application session host IDs are also better for privacy. > MPTCP can also leverage this as a means to effectively change the source address of an existing connection in order to benefit privacy for long lived connections. Tom From nobody Mon Nov 13 11:43:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 16:43:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: [v6ops] DHCPv6 PD route injection (was: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:40:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C09129413 for ; Mon, 13 Nov 2017 17:40: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=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 j4mpVqH7C8DM for ; Mon, 13 Nov 2017 17:40:13 -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 EFB71127275 for ; Mon, 13 Nov 2017 17:40:12 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id a84so8299797pfl.0 for ; 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=QXHK1FX7CJXyXQAgt9XGzCLyaarv2JRZ+vb3VUBu2qE+VXmhtqSMuwowTa57TNa+9Z XRpAI46cAkUH/WSbJ2jBjJIRwPoi+ub5yId40nngdUWGNdYxqSkKSJrdj5SiMOLQO7af AGal6ppFN/GSR9zvj0fwQFRq7BenJlvQCr0a/3OX276K9OHk2Vwi2vIyt82pHtK14oib MoyiELwP9QZf5B9vXW/xkBsXIcJU1SF1zMlIIOLwWX/TM7LnzR4vyMNqBUKKkJ5fb7nR 2EMjuWkoNBHBslU8S+jUdufjlBSDteWecM8UQysgd4JP0CAVZ2/qmt/JQ/ycXAt3ckMv n5Qg== X-Gm-Message-State: AJaThX4ZFLoUcCz9DYTSrCA/s/yZgPNr2TVfeRXdREltq9kCMB4H+swl UKK2HCqm+lhrry+ueMCLhEqoPtBz7B8= 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:40:15 -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:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A795D1205F0 for ; Mon, 13 Nov 2017 17:42: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, 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 rOM3VSKs3TGg for ; Mon, 13 Nov 2017 17:42:28 -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 49CB6127010 for ; Mon, 13 Nov 2017 17:42:28 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id j28so10881382pfk.8 for ; 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=EA0Bwv6M3/ueF6TBWlOzgO545UgZvjW5EAf/gZEcLowN0ZnRMNOgPOTOEttaaowaXj 11pqLF1Wkn9ghHZlKnekJOKo+ey8Sf4YtEMcEIDiCtS7FuK4rTdX93grahtVL2VIQvcD CxaGjTloCgJorv6vrTmAgPGoofFVH+WncQOC6uMNADRBZ9SGqb/BrES5DeNnZCAmhmyP 7KXq7G0jwaMvoLWZgHOQaBnBhCiRrMgFdB+N5IRRjN5IYY4D7OoghpOSA3cvSH9Tjfr8 w+OvmqmlbUYtm5ctuYYxANAA36ocLzkfwE0x2+SDgezoPOZvv1DUP5FF0tACkBWV95p4 myeA== X-Gm-Message-State: AJaThX6fg76iGY5aysbcJbeOCkG6oYfc3PaYTyqXSm6JxJuBeCWghMV0 Jg/mjzuRKyULe+g/4wg+ul9ppg== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EEF1205F0 for ; Mon, 13 Nov 2017 17:45: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, 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 PlC2GwDaDP6k for ; Mon, 13 Nov 2017 17:45:41 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513771270A3 for ; Mon, 13 Nov 2017 17:45:41 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id o7so14117010pgc.4 for ; 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=nXer6Tec1gyJW0+/S+vgGpg6SaW2vI1/HarhT63gjJB+/adtzemwrOyCB6cKkbOlK1 OIj3tyj/uZCgeq6cNYUlf5jCvQJImUQORvzriBoJuTKtxBa7zYGGgQGBDen8F7N7AquR GJTo23zM1jPdYzjtL6vpWJGPC9J8ybzE4zBX5N01fGtm6a4vAb/f9tvDCKQxtCPK4yqu 6UxQL+ibEzCEGIq2i8B4cRmlB7fi8w8H+2Npq3YmcS/E7zyzzFLYm4xpsfhJYrJMFDFg gwhMtVWu5kqzrpZpnKiON059b3iMutrj/5XwmDoNtRZa0G66CgkxKWLBGT4ErqftdfIa MNYw== X-Gm-Message-State: AJaThX7bZ1TAcLyEpaeIgobrwbvqrhy+TFhZk/5YVU0gr/YlD3bSmi9G vmBL4Szuax6iEJSPjQqjS8+Wkg== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BF91201F2 for ; Mon, 13 Nov 2017 17:48:03 -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 67bJ28hox9TE for ; Mon, 13 Nov 2017 17:48:02 -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 1D66A129463 for ; Mon, 13 Nov 2017 17:47:33 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id i15so2896997pfa.3 for ; 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=UoRMkyi7uHT5EL+DBK8Rh/C77oTGxLCvqmj9fx4VO0USdVjP48zVQCXMgI+pj9y2jA +ZSJo4mZHezryyj+deX6m46NjnqMJJCX1lH5g7glygk9mTF8Ur+hfQk98AhIZdwcg67a kifW6VsNYZHAml/Iq4HT8sJv6xkOhoLTa10Y+mZEPLgyziuKtdeWIqXHj5MecicHo6Vz t+bnwCLzcujLMHovvejV+fPCmD80ZDOijPyr+vKIIjT+6shM8cs+RuHprFpOX2Uc5DPm 0NiWY6bXKtYZkoMmDPIpHWNmopaxxQ1dODJLccxGua+1LNOtd3OcNPx3onqK6kujX1Ee GnuA== X-Gm-Message-State: AJaThX7kB6mpQnCtzkru1RwfC1hxIBCd1mcsVurgcYmf6j3qB3e044Qe G35r45lLaSoLNgFLqjQZ2itQvA== 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:48:03 -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:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0579129584 for ; Mon, 13 Nov 2017 17:49:29 -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 sDnunnjUCvGg for ; Mon, 13 Nov 2017 17:49:28 -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 30A63129576 for ; Mon, 13 Nov 2017 17:49:28 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id p186so22757570ioe.12 for ; 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=S+cNTnIHH4O6y6S6aBGjMOYh3Uv3I902iLiuYqDxC5YfGgBcMvPDwG3gbL5a7X0xdd L2OUXVn7PShgVgHYOYFgNCqCIaoFQcHza3NRObIlUNVFMn004lXOa4opR4aFaMwciKJT bUcdwpQ4rQaKa/QTF3EftM/spM0+7GLpjNwptqgluW5Bcth1EFL+Zz4dtqyjeR/Yg/22 06xFiq5HF7MJAo4HjtJcbRDJQq6KhpEItgMw6LsQ9rPoDL5vn75HI3o7t8yw4yYfMw0N EOtix3bfIE5fIFf9hUNCtyYb0KIvuo8ZydSkfPNxYD/vKC6UU4Pk+omwCEhM2q8F1l1Z Ltgg== X-Gm-Message-State: AJaThX6F8SaC7eSYxXUDh2JHd7utpl9Y36ohpAc+RYXxH9MwgtkXc0w2 5AkHHcrtJJ0SThJYs7AKU3VJxaw1iyA= 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 01:49:30 -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:58:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:09:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:29:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60D912711E for ; Mon, 13 Nov 2017 18:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 OWkZUjgOyKUU for ; Mon, 13 Nov 2017 18:29:55 -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 E157512711A for ; Mon, 13 Nov 2017 18:29:54 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id n89so13291271pfk.11 for ; Mon, 13 Nov 2017 18:29:54 -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=UjbUMOSp4x0ARf9PZ5ConUEOmB/kX2HJw0R71d38oyc=; b=zkAf3rwZTf9aG8VKaSNxNlJTmxuTeBevsNHckS/eSCIY+GwXLNN91dap3wZlSr0WTs vMvPjTCTNbf1c0Cx1b1US0o3289sU9n7YWIyE8DzRDRXXpEjW5RARGCP4aUTwahoPtoo hLePFa6fK6FzjdMC5iGyfcvV9fvDQY00JLPAtCd9ZjUjxo0W31gLgiAd6hs41bTbauqb uIWG63jgOW6t+C7QJ+jHDDdXdghXPX5Xa2pA6LRIauYNnPHC64WFbgD3ejfj8ILAZfH1 ff/4GPnjO0y7Tw/Exwj1RL8otC+QjDqbbUdkdnhqQBpQ3B06f5gBja2HTS2TBrPKUQg6 retw== 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=UjbUMOSp4x0ARf9PZ5ConUEOmB/kX2HJw0R71d38oyc=; b=WDUAI2mofbqbgw+Hy+2DNc9LVfO1LtoF8gWnWGqcqTGZCNv4HGCEIQo3aJPjbB2IYh BnYhLEs7bQAHx7wLysLFXHUNCXDZen9/4gAmbSyR/Ej80heoee7wqRF9Pofuc8Kf/5QV UnSBsGyfLxNRklJLGxz5uoxVKTQYIFrvsKQ4a8FwUdRefy2wWTDRvpgJ7fx/VCBy8hr9 qfGxioONgfjX/6IppMDQa31ZbUwJ4MyV10nrvcQQe/92kXFX3vHuNJc/9Duh0mv4X9xB 0PBtVOMx6OU4TVVivou8SKtuqCKuEZg/mxMZImDga7uku6twlWAiKoIM4m0rbBVUKatn XQuQ== X-Gm-Message-State: AJaThX7UUxTV7IVf4yuFc0LxUERxXl+a+Ss9szZ6BLN3oVlmgH1MfBig KP7EZInlHtuZuGpEw9C3ZDV1Vw== X-Google-Smtp-Source: AGs4zMbVVTs99XCYyURZzknVvpdXVTuKbQxsxA+u6zFjHIL3pCFlD0Tk7exAWjw92HFyPHQmU43LvA== X-Received: by 10.101.97.130 with SMTP id c2mr10906444pgv.101.1510626594359; Mon, 13 Nov 2017 18:29:54 -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 h185sm27773833pgc.55.2017.11.13.18.29.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 18:29:53 -0800 (PST) From: Ted Lemon Message-Id: <544F646A-2A40-435B-A9E0-646B85D96EC0@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_55D18960-AE9B-4C08-837F-24EF5E29E507" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 14 Nov 2017 10:29:51 +0800 In-Reply-To: Cc: Mark Smith , v6ops list To: Tom Herbert References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <89d4d29f-30ab-756d-b02c-cf460ef833ce@si6networks.com> <6ed75c9e-5f15-6207-4723-85d055a9768f@si6networks.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Security: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:29:57 -0000 --Apple-Mail=_55D18960-AE9B-4C08-837F-24EF5E29E507 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 14, 2017, at 3:42 AM, Tom Herbert wrote: > The idea of single use addresses is that a host can be assigned many > identifiers from which it can create a unique source address for each > connection. It is up to the infrastructure to direct packets for each > addresses to the right end host. It's true this is potentially a lot > of state for the infrastructure to manage, but the total number of > state entries would be no more than the number of NAT entries if that > were in use today so I don't believe it is impractical. The problem is that the goal for doing this would be to obscure, as much = as possible, the identify associated with a particular flow. In order = to do this, it has to be the case that the locater used to route that = flow reveals as little as possible to the remote endpoint of the flow: = that is, that if I connect to you, in principle the return address you = see is as unspecific as possible. In order for that to work, the mapping has to be as high in the network = hierarchy as possible. If the point in the network hierarchy where the = mapping occurs is, say, in my home gateway, then not much obscuration of = identity is being accomplished. Perhaps the remote endpoint does not = know who in my home connected, but it knows someone in my home did. If you do the mapping one level up, at the ISP's local data center, then = now all the remote endpoint knows is that someone in, say, Brattleboro = (the town where I live), who is a Comcast customer, connected. If you = do the mapping another level up, then all the remote endpoint knows is = that someone in, say, New England, who is a Comcast customer, connected. = And so on. Of course, the higher up in the hierarchy that you do the mapping, the = easier it is to monitor below the mapping point, since our adversary may = not be on the remote endpoint. In the case of government surveillance = or ISP monetization of search traffic, if the mapping occurs at the top = of the ISP, and the monitoring occurs within the ISP's network, then a = fairly specific identity is available to the adversary. This is why Tor does multiple layers of mapping, on multiple routers. = In order to get a similar degree of obfuscation, a similar mapping = process would be required. This requires substantial infrastructure, = and is in no way analogous to the cost of network address translation, = even CGN. These translators ideally need to be under the control of a = variety of entities, such that no one entity can reveal the identity of = the protected endpoint. This is why I made the original comment, "who pays for this?" There's = no reason in principle why something like this couldn't be set up, but = to be available to every end user, a rather massive cost would have to = be absorbed by someone. Who would that be? --Apple-Mail=_55D18960-AE9B-4C08-837F-24EF5E29E507 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Nov 14, 2017, at 3:42 AM, Tom Herbert <tom@herbertland.com>= wrote:
The idea of single = use addresses is that a host can be assigned many
identifiers from which it can create a unique = source address for each
connection. It is = up to the infrastructure to direct packets for each
addresses to the right end host. It's true this = is potentially a lot
of state for the = infrastructure to manage, but the total number of
state entries would be no more than the number = of NAT entries if that
were in use today = so I don't believe it is impractical.

The problem is that the goal for doing this = would be to obscure, as much as possible, the identify associated with a = particular flow.   In order to do this, it has to be the case that = the locater used to route that flow reveals as little as possible to the = remote endpoint of the flow: that is, that if I connect to you, in = principle the return address you see is as unspecific as = possible.

In = order for that to work, the mapping has to be as high in the network = hierarchy as possible.   If the point in the network hierarchy = where the mapping occurs is, say, in my home gateway, then not much = obscuration of identity is being accomplished.   Perhaps the remote = endpoint does not know who in my home connected, but = it knows someone in my home did.

If you do the mapping = one level up, at the ISP's local data center, then now all the remote = endpoint knows is that someone in, say, Brattleboro (the town where I = live), who is a Comcast customer, connected.   If you do the = mapping another level up, then all the remote endpoint knows is that = someone in, say, New England, who is a Comcast customer, connected. =   And so on.

Of course, the higher up in the hierarchy that you do the = mapping, the easier it is to monitor below the mapping point, since our = adversary may not be on the remote endpoint.   In the case of = government surveillance or ISP monetization of search traffic, if the = mapping occurs at the top of the ISP, and the monitoring occurs within = the ISP's network, then a fairly specific identity is available to the = adversary.

This = is why Tor does multiple layers of mapping, on multiple routers.   = In order to get a similar degree of obfuscation, a similar mapping = process would be required.   This requires substantial = infrastructure, and is in no way analogous to the cost of network = address translation, even CGN.   These translators ideally need to = be under the control of a variety of entities, such that no one entity = can reveal the identity of the protected endpoint.

This is why I made the = original comment, "who pays for this?"   There's no reason in = principle why something like this couldn't be set up, but to be = available to every end user, a rather massive cost would have to be = absorbed by someone.   Who would that = be?

= --Apple-Mail=_55D18960-AE9B-4C08-837F-24EF5E29E507-- From nobody Mon Nov 13 18:41:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBB0127735 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWxtjPyHF98l for ; Mon, 13 Nov 2017 18:41:43 -0800 (PST) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5546D1275AB for ; Mon, 13 Nov 2017 18:41:43 -0800 (PST) Received: by mail-wr0-x22a.google.com with SMTP id l22so16162362wrc.11 for ; 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=S2Ti8xXub1eiDydVNgT39w+T2RcGBSwtasLkxlrrW1bRBoE8bhqnVfW1hrFsSsSc2I lHfc0VlsXIq/ZXnHct4J8docTKKvXZKoFQqhoqYfQzg//bCFQwv9qN8NhF7o/B5YCxky zrSoIXeTHSJhLWcMt1RWt3r0qN5xuJK3Q1UlhOhZZVy45jZMo6snqwR3bcd1Z6VCGdYR Z38XzCQ18PkRztoKpufZLd0rKqdgKRqUhhtl2+U0qTVA8UeRsNjZw35lqbOMccv2EiB6 9jIrS4g7pJAO5lOYJY6yVV34P7kCEF825vaiJSADe/eYfCE7NDejuuMidUfwEYrDSN3C Fu8A== X-Gm-Message-State: AJaThX6h+CdpfonDIeAvOQWgqTVdVzcFBr/N6ahSSTonER8tOJGceYbn 7hCD4HZ7po1KpNlOTdh5OR4CBoq/FXIuwtPYzSCZCg== 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:41:46 -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:57:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57C41286B1 for ; Mon, 13 Nov 2017 18:57: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 HBOslGlLxCNm for ; Mon, 13 Nov 2017 18:57:54 -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 E6C93127342 for ; Mon, 13 Nov 2017 18:57:53 -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 vAE2vqGU004538 for ; Tue, 14 Nov 2017 03:57:52 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 040AF200BEB for ; Tue, 14 Nov 2017 03:57:52 +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 EEC422007F8 for ; Tue, 14 Nov 2017 03:57:51 +0100 (CET) Received: from [132.166.84.11] ([132.166.84.11]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAE2vofH026748 for ; Tue, 14 Nov 2017 03:57:51 +0100 To: v6ops@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> <862687c9-c107-53a8-288a-29049097b0e1@acm.org> From: Alexandre Petrescu Message-ID: Date: Tue, 14 Nov 2017 03:57:49 +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: Subject: Re: [v6ops] DHCPv6 PD route injection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 02:57:57 -0000 Le 14/11/2017 01:57, Ole Troan a crit : > > >> On 14 Nov 2017, at 03:43, Mark Smith >> wrote: >> >> >> 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. > > 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. I am not sure whether this is an open invitation, or aimed at your conversation peer. But I am interested in this problem. We wrote a draft earlier: draft-petrescu-relay-route-pd-problem-00.txt I wonder whether an operator looks at setting a relay on SGW or on PGW. In a cellular network, there is an interesting point to note in that the PGW does not have an IP address, is a DHCP server and when it sets forwarding it actually sets things about GTP. Alex > > Best regards, Ole > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Nov 13 18:59:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:15:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9317E124217 for ; Mon, 13 Nov 2017 19:15:12 -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 q2HgAixm929o for ; Mon, 13 Nov 2017 19:15:10 -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 B2B44129ACD for ; Mon, 13 Nov 2017 19:15:10 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5C9EAB2; Tue, 14 Nov 2017 04:15:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1510629308; bh=qn8v2p6mja2lZfC5zlaOZ4XJy5/31Dc6eFceFUhsbGY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=LyV2VF8hYuC1RST+UKpIhr98Pu0FxrTaxab+/YxzvPPuPpgAvE9cHJQWKSDZWaZVR vv1p5GshgUqb+HkFp3F2CdOr43VjhvuPEKJoj4qpJyHQtl0E5v1X+YH/IbLMJsnUB/ vAq5j0cc9X5sJbtHFcnNMn3uGuansWNE29bU/KN8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 5A204AF; Tue, 14 Nov 2017 04:15:08 +0100 (CET) Date: Tue, 14 Nov 2017 04:15:08 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <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> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] DHCPv6 PD route injection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:15:12 -0000 On Tue, 14 Nov 2017, Alexandre Petrescu wrote: > In a cellular network, there is an interesting point to note in that the > PGW does not have an IP address, is a DHCP server and when it sets > forwarding it actually sets things about GTP. The PGW has a link-local address, so your above statement is not correct. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Nov 13 19:17:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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)" 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: Subject: Re: [v6ops] DHCPv6 PD route injection (was: Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:21:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0881B124BE8 for ; Mon, 13 Nov 2017 19:21:28 -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 Xaq3pjrNuDpW for ; Mon, 13 Nov 2017 19:21:26 -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 C9A621242F7 for ; Mon, 13 Nov 2017 19:21:25 -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 vAE3LOqJ023942; Tue, 14 Nov 2017 04:21:24 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0AEB1200E60; Tue, 14 Nov 2017 04:21:24 +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 E85C0200C37; Tue, 14 Nov 2017 04:21:23 +0100 (CET) Received: from [132.166.84.11] ([132.166.84.11]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAE3LMsG010732; Tue, 14 Nov 2017 04:21:23 +0100 To: Mikael Abrahamsson Cc: v6ops@ietf.org References: <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <862687c9-c107-53a8-288a-29049097b0e1@acm.org> From: Alexandre Petrescu Message-ID: Date: Tue, 14 Nov 2017 04:21:21 +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: Subject: Re: [v6ops] DHCPv6 PD route injection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:21:28 -0000 Le 14/11/2017 à 04:15, Mikael Abrahamsson a écrit : > On Tue, 14 Nov 2017, Alexandre Petrescu wrote: > >> In a cellular network, there is an interesting point to note in that >> the PGW does not have an IP address, is a DHCP server and when it sets >> forwarding it actually sets things about GTP. > > The PGW has a link-local address, so your above statement is not correct. I agree, I meant PGW had no GUA. Alex > From nobody Mon Nov 13 19:23:01 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: [v6ops] Upleveling discussion (was Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 19:30:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B057112955F for ; Mon, 13 Nov 2017 19:30: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 lK4_3Q-QPkoK for ; Mon, 13 Nov 2017 19:30: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 291E712945C for ; Mon, 13 Nov 2017 19:30:31 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 69A16B2; Tue, 14 Nov 2017 04:30:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1510630229; bh=eXeS0g0VbgLaCCbpxwXBXnFcVeEjfFYFk5tTWoMb7p0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=VBQNpXulClulQ+8jQbcfGOy8A5v9ymoGIr7BrcsSLjzlFFRn5E0zObiGgIqiZuD90 HUKbWcLvHvt+t949i3DYlKw60GrNjnOuUYFqBfJ2FcCxuoujB4g0PpLEaSGv+iuefy lAGFdPnlLTxROchiIxGEfKEXCMiGkt9wcOoA0LeA= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 66243AF; Tue, 14 Nov 2017 04:30:29 +0100 (CET) Date: Tue, 14 Nov 2017 04:30:29 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <862687c9-c107-53a8-288a-29049097b0e1@acm.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-1560402265-1510630229=:16389" Archived-At: Subject: Re: [v6ops] DHCPv6 PD route injection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:30:51 -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-1560402265-1510630229=:16389 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 14 Nov 2017, Alexandre Petrescu wrote: > > > Le 14/11/2017 à 04:15, Mikael Abrahamsson a écrit : >> On Tue, 14 Nov 2017, Alexandre Petrescu wrote: >> >>> In a cellular network, there is an interesting point to note in that the >>> PGW does not have an IP address, is a DHCP server and when it sets >>> forwarding it actually sets things about GTP. >> >> The PGW has a link-local address, so your above statement is not correct. > > I agree, I meant PGW had no GUA. So what is "interesting" about this situation? -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1560402265-1510630229=:16389-- From nobody Mon Nov 13 19:38:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D078124B17 for ; Mon, 13 Nov 2017 19:38:29 -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 6BlqnJCxB8-8 for ; Mon, 13 Nov 2017 19:38:27 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d: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 A7D5A1242EA for ; Mon, 13 Nov 2017 19:38:27 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id p7so22475856qkd.7 for ; Mon, 13 Nov 2017 19:38:27 -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=ZlXVioKV1r/MIw0XPHEn1Jmq5iVhuhy6/gK/XYqGjqw=; b=KiVFpvMx2bJBgWCmbBiasGUcmcs2av+CRu17ohDG2JRSwkv9BWgenfX7rLv5Z4lgx+ fMTnM9iaN69UwlQKCfhG+tV63851WAoP5oDTjy3AKNNnpaJLUpgAzURy4Xux5t7VqPBI oZXmEOC1GF0CslV3bWuPB0T049AiT/sYcGP9Qz1CkShkLfJM7Yv0+qXhTZO3OVpSxFXd X90XND3eFFYppvKdEvlmHBBwgDIkDpqSQLZrtSLYZcy6qIoyvnmIRsOJuHI/OPc7f28m fyFwxVCaCxYdHXNHPXVu9iVOsqA93wwo/q19CpgnLZkwlLaVWaLZsU+iN2fsWIiMcaw3 HEjA== 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=ZlXVioKV1r/MIw0XPHEn1Jmq5iVhuhy6/gK/XYqGjqw=; b=a44Q0cSGGsqZ1JJi5lWM9I/oIyCMrG4/uNQal8VIyjF6DtNXnjB2AlR281FO6v+Zig PSjMVWFTBavmqwudMLM6YXZr1SwOEGa4P2IELUP3nqTnh+rQ/DP/UJuMbgjwXYeLi38s PVOyQksKm8+TDWchAMnjv5jYweq9i2kAwNcziQ0QP4khgzFzYEoHpUoBoohLw9n7rtYV nr7TJld/v3xT0oBlqxifJbaJaK84cpnyDqiGROYHsLWh9XZqX2ifyDGks81rzYEl+mlP EnLWlJnmU8OmS7a1WHSnb7WLoj4FO/xCnKcEchN3MaBqiQ3csDQRs6X6Og14H5IFbh84 GEuA== X-Gm-Message-State: AJaThX5kkWOTFZM9vjnD76616Q+WTnb4dPdDWotaEjKGdDhdYM8o0jc2 kgKzYygFEu73F4tlL3pCvVKjqN8gwMGMDN1QzI3S7g== X-Google-Smtp-Source: AGs4zMZDzCiy+G0AxI2my+AR/vcTyBP3+V2RtFXDH7Ck+/tclStzxle0vw/S6dvggqZyjcc8T3Lj1t5mdtZJTRq9jZU= X-Received: by 10.55.106.132 with SMTP id f126mr16621930qkc.295.1510630706688; Mon, 13 Nov 2017 19:38:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Mon, 13 Nov 2017 19:38:26 -0800 (PST) In-Reply-To: <544F646A-2A40-435B-A9E0-646B85D96EC0@fugue.com> References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <89d4d29f-30ab-756d-b02c-cf460ef833ce@si6networks.com> <6ed75c9e-5f15-6207-4723-85d055a9768f@si6networks.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> <544F646A-2A40-435B-A9E0-646B85D96EC0@fugue.com> From: Tom Herbert Date: Mon, 13 Nov 2017 19:38:26 -0800 Message-ID: To: Ted Lemon Cc: Mark Smith , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Security: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:38:29 -0000 On Mon, Nov 13, 2017 at 6:29 PM, Ted Lemon wrote: > On Nov 14, 2017, at 3:42 AM, Tom Herbert wrote: > > The idea of single use addresses is that a host can be assigned many > identifiers from which it can create a unique source address for each > connection. It is up to the infrastructure to direct packets for each > addresses to the right end host. It's true this is potentially a lot > of state for the infrastructure to manage, but the total number of > state entries would be no more than the number of NAT entries if that > were in use today so I don't believe it is impractical. > > > The problem is that the goal for doing this would be to obscure, as much as > possible, the identify associated with a particular flow. In order to do > this, it has to be the case that the locater used to route that flow reveals > as little as possible to the remote endpoint of the flow: that is, that if I > connect to you, in principle the return address you see is as unspecific as > possible. > Hi Ted, I don't believe that locators should be visible outside of the network infrastructure since they do tend to reveal specific location especially as would the case of mobile networks. The outside world should only see an eternally visible that contains the prefix of the provider and an identifier without any more specific topology information. A third party should only be able to deduce the provider and nothing more more from just the address. > In order for that to work, the mapping has to be as high in the network > hierarchy as possible. If the point in the network hierarchy where the > mapping occurs is, say, in my home gateway, then not much obscuration of > identity is being accomplished. Perhaps the remote endpoint does not know > who in my home connected, but it knows someone in my home did. > The identifier space would be at least 64 bits, so the home gateway can get multiple addresses from the provider and hand them to local devices. Given two connections, from the home network they would have completely different source addresses except for the common network provider prefix. > If you do the mapping one level up, at the ISP's local data center, then now > all the remote endpoint knows is that someone in, say, Brattleboro (the town > where I live), who is a Comcast customer, connected. If you do the mapping > another level up, then all the remote endpoint knows is that someone in, > say, New England, who is a Comcast customer, connected. And so on. > As I said above customers don't see locators. It's analogous to networks tunneling customers packets over their infrastructure without knowledge. > Of course, the higher up in the hierarchy that you do the mapping, the > easier it is to monitor below the mapping point, since our adversary may not > be on the remote endpoint. In the case of government surveillance or ISP > monetization of search traffic, if the mapping occurs at the top of the ISP, > and the monitoring occurs within the ISP's network, then a fairly specific > identity is available to the adversary. > > This is why Tor does multiple layers of mapping, on multiple routers. In > order to get a similar degree of obfuscation, a similar mapping process > would be required. This requires substantial infrastructure, and is in no > way analogous to the cost of network address translation, even CGN. These > translators ideally need to be under the control of a variety of entities, > such that no one entity can reveal the identity of the protected endpoint. > > This is why I made the original comment, "who pays for this?" There's no > reason in principle why something like this couldn't be set up, but to be > available to every end user, a rather massive cost would have to be absorbed > by someone. Who would that be? There's already significant deployment of identifier/locator split in network virtualization. Mobile networks are an emerging use case, identifier-locator split provides a mechanism for mobility (moving devices ant its addresses from on point of attachment to another). The notion of single use addresses is enabled by identifier-locator split as one possible use case. Tom From nobody Mon Nov 13 19:46:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEA5127A90 for ; Mon, 13 Nov 2017 19:46: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 RaqqfrI2r5_0 for ; Mon, 13 Nov 2017 19:46:42 -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 4D9C11242EA for ; Mon, 13 Nov 2017 19:46:42 -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 vAE3kevP144523; Tue, 14 Nov 2017 04:46:40 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F4120200EB6; Tue, 14 Nov 2017 04:46:39 +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 E69C3200C37; Tue, 14 Nov 2017 04:46:39 +0100 (CET) Received: from [132.166.84.11] ([132.166.84.11]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAE3kcc7029410; Tue, 14 Nov 2017 04:46:39 +0100 To: Mikael Abrahamsson Cc: v6ops@ietf.org References: <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <862687c9-c107-53a8-288a-29049097b0e1@acm.org> From: Alexandre Petrescu Message-ID: <6a7622ee-3517-b874-5ab9-80a7bff865ea@gmail.com> Date: Tue, 14 Nov 2017 04:46:37 +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: Subject: Re: [v6ops] DHCPv6 PD route injection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:46:44 -0000 Le 14/11/2017 à 04:30, Mikael Abrahamsson a écrit : > On Tue, 14 Nov 2017, Alexandre Petrescu wrote: > >> >> >> Le 14/11/2017 à 04:15, Mikael Abrahamsson a écrit : >>> On Tue, 14 Nov 2017, Alexandre Petrescu wrote: >>> >>>> In a cellular network, there is an interesting point to note in that >>>> the PGW does not have an IP address, is a DHCP server and when it >>>> sets forwarding it actually sets things about GTP. >>> >>> The PGW has a link-local address, so your above statement is not >>> correct. >> >> I agree, I meant PGW had no GUA. > > So what is "interesting" about this situation? Well, there is no Relay, so one would think there is no need for 'route injection'. There is what can be assimilated to 'route insertion' in that the Server (PGW) does relate the GTP tunnel to the prefix it allocated, in its local table, without sending 'route updates' in the network. There is a need to send route updates only if there is a Relay. When there is a Relay the Server has a GUA. This makes wonder whether in cellular networks the PGW needs to do route injection (route updates) during DHCPv6-PD. Alex > From nobody Mon Nov 13 20:24:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E97126E64 for ; Mon, 13 Nov 2017 20:24:08 -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 spXCUMXrjrI8 for ; Mon, 13 Nov 2017 20:24:06 -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 0C7C51271DF for ; Mon, 13 Nov 2017 20:24:06 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id d66so23059679ioe.5 for ; 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=TnLohCaCKehdMavK9rDRIFDBNDfOWCaPtysu7pOcRhW7Dlj830BRWm8IOdRTGChh0w 3fRO0FY6THyaoPxdbCk9GUT/HzIc7IAxDyaBEljEZPyR4BdLBIEMtp/Me36OiehHH8Mm Y2F+Okyv5VPOEpW8Wp7BXIHdgvCStWjHFGDznYe8i/nAW1VXxCt2l+PzRIBKRq7wbBfc 5YuxeJ21eL9nFkDAdS/9K2iI78TGftKQsVN89x9QFX6TWcpb/ybkaXBxEwLWwoMoZ8PF U/Fil1e4Zfji/w56Tl/CNPZsFcz+b997tolt2h953UdcYwspmYjQ2LkISAWgAhp+1QL5 E38w== X-Gm-Message-State: AJaThX6yzQn26O+XFuipRytemRs/ZNDZxpnhEIof+gcuanwO/UBP2pB6 EPnYJ6zyj5npoZ0jwFIRkQpZrpB/3YDs0VxJE15fNBwW 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 21:00:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95713128AA1 for ; Mon, 13 Nov 2017 21:00:14 -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 VYniksFsbucx for ; Mon, 13 Nov 2017 21:00:12 -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 953AC1286C7 for ; Mon, 13 Nov 2017 21:00:12 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 46C96B2; Tue, 14 Nov 2017 06:00:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1510635610; bh=UAlrxxmevn/R9O0I22u03ardq1RhdUHjwXNdw68mnbM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=emwUKcjW1chvBpdT+Njw/zMLrCc7iVNUv2CUJ6w5RcAI/alxmjsY2aldrWxSAbMOL 75MmERUrKv76elDMZp7InNE0xlF9pgEDGlw4kkzCWtePFsu9/ziNa9PeC4XctNQO49 JLoB3Jaq1UvfWG8hiDJql1O57YpKp6PITAYYfqG0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 40218AF; Tue, 14 Nov 2017 06:00:10 +0100 (CET) Date: Tue, 14 Nov 2017 06:00:10 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: <6a7622ee-3517-b874-5ab9-80a7bff865ea@gmail.com> Message-ID: References: <207f040a-7fe2-9434-e7a5-f546b26fdf63@strayalpha.com> <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <862687c9-c107-53a8-288a-29049097b0e1@acm.org> <6a7622ee-3517-b874-5ab9-80a7bff865ea@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] DHCPv6 PD route injection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 05:00:14 -0000 On Tue, 14 Nov 2017, Alexandre Petrescu wrote: > There is a need to send route updates only if there is a Relay. When > there is a Relay the Server has a GUA. Commonly, but not necessarily, and also irrelevant to the problem at hand. > This makes wonder whether in cellular networks the PGW needs to do route > injection (route updates) during DHCPv6-PD. It needs to install the delegated prefix into its RIB/FIB. If it needs to tell anyone else about it is a different problem, and it depends on the setup. If there is a covering larger prefix statically routed to it then it doesn't need to tell anyone else. There is no requirement for the PGW to use a routing protocol, but nothing in the architecture that precludes it from doing so. PGW is a router, and in this case for PD it can be either a relay or a DHCPv6 server, perhaps with a diameter backend. Depends on how you define it, is a DHCPv6-PD delegating router asking Diameter what prefix to assign, actually a relay or a server? I don't think it matters anyway, it ends up the same thing. Nontheless, there is no fundamentally different about this, to any other situation with a PPPoE terminating BNG for instance. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Nov 13 21:53:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059631293E1 for ; Mon, 13 Nov 2017 21: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, 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 Ak9pGmihnIMa for ; Mon, 13 Nov 2017 21:53:51 -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 6D9F2128D69 for ; Mon, 13 Nov 2017 21:53:51 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id l24so1214617pfj.6 for ; Mon, 13 Nov 2017 21:53:51 -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=ytoFuupYvpcl0iWHlUfEzSimL85Zw8WbJ14Dl+CJPmY=; b=Q1XCaNuqnb5cqB9Xf09TVzSB0lUDf+ld/uSEj2i36UFn9/7Bn/uZvGiga5NEdnMnZ7 m1Hl0jEX/8aRGOcZeftgR3UAsojMD+ygJwROkudR+a+dPjN34F4COCk6x9s8mBDEHtUf g79unt+Lm9wQs7iaubc87FLbIiDh1T9rNPcbuAwLy+gTbxb/1IEfyVsll6283Gj6WWeJ PVwCHSfzzIVC2zXdDzlb1AEFe1uahyYzL5bSmWMBPgVeugbdHE9yw7scpPjHzz1MKNDe VMRaGJDoPK2e6ARjACXSovW9Oc4HgvGdWhR+SGbqkv21gwC0y6yZ1DW+IoKN9GKlf+r/ nyIg== 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=ytoFuupYvpcl0iWHlUfEzSimL85Zw8WbJ14Dl+CJPmY=; b=F/BguFXVC5SmjrFETOA0R8WkQDzZLF9LF4wmSwXRxI1PsxIyUH8w1B880jMMkopAMF /gyxpQCVv4PtSoF86PgAVisE/X/600SkJsaMKnnPJvk3iGaHPycb2OTjksNcu2sAmxMN o8p/qx4KnvrWMzCOxvWbeOClTpj6a4SzvGEQxsncuCCkyuuWCoQe+2L8lZ/rBar9Gpqp Zey4N3CzoecXxD6MLiln3DNdFCIYacviCO8aVfHqvfgJSPF0yMjOZr5AtQTtt9usDBfJ pBoz9fywrkXhtl2bUXywr3GbtKDMEPhN9+/h/2Re8kYcojBV0jDJnRt4HZXaj/utjbNQ 5O1A== X-Gm-Message-State: AJaThX53KGPczl9NKK1Fiuea76XEt+Mk5clnHrbphXvp7Z6DSu0KWAhd QqgKHHNTZQdd6CZvXj9O9Mpt4dwuNW4= X-Google-Smtp-Source: AGs4zMYPbBBw9RvD/ckggRGoY6daPvCQrwu+AlX2NjiFVb4LowPrZK6YGARpdx+hYkdOzRpmo4+WGA== X-Received: by 10.84.131.6 with SMTP id 6mr11529679pld.100.1510638831034; Mon, 13 Nov 2017 21:53:51 -0800 (PST) Received: from ?IPv6:2001:67c:370:1998:b5e8:98bd:11cb:8596? ([2001:67c:370:1998:b5e8:98bd:11cb:8596]) by smtp.gmail.com with ESMTPSA id 9sm15293933pge.74.2017.11.13.21.53.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 21:53:50 -0800 (PST) From: Ted Lemon Message-Id: <1B12392C-D39C-434B-8114-A38061782B9C@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FD8C4247-A726-4E7C-B702-E6E28E21D4C0" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 14 Nov 2017 13:53:47 +0800 In-Reply-To: Cc: Mark Smith , v6ops list To: Tom Herbert References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <89d4d29f-30ab-756d-b02c-cf460ef833ce@si6networks.com> <6ed75c9e-5f15-6207-4723-85d055a9768f@si6networks.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> <544F646A-2A40-435B-A9E0-646B85D96EC0@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] Security: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 05:53:53 -0000 --Apple-Mail=_FD8C4247-A726-4E7C-B702-E6E28E21D4C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 14, 2017, at 11:38 AM, Tom Herbert wrote: > There's already significant deployment of identifier/locator split in > network virtualization. Mobile networks are an emerging use case, > identifier-locator split provides a mechanism for mobility (moving > devices ant its addresses from on point of attachment to another). The > notion of single use addresses is enabled by identifier-locator split > as one possible use case. It makes sense to do this in mobile because you want the handset to be = able to move without breaking connections, so that's an example of "who = pays." But in this case are these mobile providers currently doing = one-locator-per-connection, or are they currently doing = one-locator-per-host? --Apple-Mail=_FD8C4247-A726-4E7C-B702-E6E28E21D4C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Nov 14, 2017, at 11:38 AM, Tom Herbert <tom@herbertland.com>= wrote:
There's already = significant deployment of identifier/locator split in
network virtualization. Mobile networks are an = emerging use case,
identifier-locator = split provides a mechanism for mobility (moving
devices ant its addresses from on point of = attachment to another). The
notion of single = use addresses is enabled by identifier-locator split
as one possible use = case.

It = makes sense to do this in mobile because you want the handset to be able = to move without breaking connections, so that's an example of "who = pays."   But in this case are these mobile providers currently doing one-locator-per-connection, or are they = currently doing one-locator-per-host?


= --Apple-Mail=_FD8C4247-A726-4E7C-B702-E6E28E21D4C0-- From nobody Mon Nov 13 22:48:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF6E129453 for ; Mon, 13 Nov 2017 22:48:10 -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 bLoHAss5Z6Lc for ; Mon, 13 Nov 2017 22:48:05 -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 B467D1292FD for ; Mon, 13 Nov 2017 22:48:04 -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 vAE6m2HZ187012; Tue, 14 Nov 2017 07:48:02 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6E82720131C; Tue, 14 Nov 2017 07:48:02 +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 61011200CEC; Tue, 14 Nov 2017 07:48:02 +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 vAE6m03H014253; Tue, 14 Nov 2017 07:48:01 +0100 To: Mikael Abrahamsson Cc: v6ops@ietf.org References: <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <862687c9-c107-53a8-288a-29049097b0e1@acm.org> <6a7622ee-3517-b874-5ab9-80a7bff865ea@gmail.com> From: Alexandre Petrescu Message-ID: <450c4ff4-1da2-5516-9f83-0ee0571d222d@gmail.com> Date: Tue, 14 Nov 2017 07:47:18 +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: Subject: Re: [v6ops] DHCPv6 PD route injection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 06:48:10 -0000 Le 14/11/2017 à 06:00, Mikael Abrahamsson a écrit : > On Tue, 14 Nov 2017, Alexandre Petrescu wrote: > >> There is a need to send route updates only if there is a Relay. >> When there is a Relay the Server has a GUA. > > Commonly, but not necessarily, It is very necessary for the Server to put its GUA in the Advertise it sends to the Client through a Relay. Because LL-addressed packets dont get through Relays. > and also irrelevant to the problem at hand. I think the routing injection problem is at Relay. If there is no Relay there is no route injection problem. >> This makes wonder whether in cellular networks the PGW needs to do >> route injection (route updates) during DHCPv6-PD. > > It needs to install the delegated prefix into its RIB/FIB > > If it needs to tell anyone else about it is a different problem, and > it depends on the setup. If there is a covering larger prefix > statically routed to it then it doesn't need to tell anyone else. > There is no requirement for the PGW to use a routing protocol, but > nothing in the architecture that precludes it from doing so. Agreed both points. > PGW is a router, and in this case for PD it can be either a relay or > a DHCPv6 server, perhaps with a diameter backend. Depends on how you > define it, is a DHCPv6-PD delegating router asking Diameter what > prefix to assign, actually a relay or a server? I don't think it > matters anyway, it ends up the same thing. > > Nontheless, there is no fundamentally different about this, to any > other situation with a PPPoE terminating BNG for instance. Well, is the BNG the equivalent of a PGW? Alex > From nobody Mon Nov 13 22:51:48 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89367127735 for ; Mon, 13 Nov 2017 22:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 OTKpaCZnozqz for ; Mon, 13 Nov 2017 22:51:45 -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 8D28B126C25 for ; Mon, 13 Nov 2017 22:51:45 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 21B07B2; Tue, 14 Nov 2017 07:51:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1510642303; bh=iB8ynUXVdkzMo7/R0oe9kfYzpS7mum5encIfIpCpaHM=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=lpbi3KiRCHCnRRDztM6JAItpHfMWgBaGk82CC94ZS+xG+0xsD8IxIH7gMI3KjmLF6 iJM6iPy8axFbY03QF7ScO8rLkZFtkbz/NFkyEZBvIVvuUAYlKbNUbKLEQE0GmJvX0C 3pQDtKfiXLzh5ThMikTerU5jYzN4itJ5Wwlc7pa4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 08741AF; Tue, 14 Nov 2017 07:51:43 +0100 (CET) Date: Tue, 14 Nov 2017 07:51:43 +0100 (CET) From: Mikael Abrahamsson To: Alexandre Petrescu cc: v6ops@ietf.org In-Reply-To: <450c4ff4-1da2-5516-9f83-0ee0571d222d@gmail.com> Message-ID: References: <8ca59610-2d25-2be4-9d2c-9b1a75fd3ace@si6networks.com> <862687c9-c107-53a8-288a-29049097b0e1@acm.org> <6a7622ee-3517-b874-5ab9-80a7bff865ea@gmail.com> <450c4ff4-1da2-5516-9f83-0ee0571d222d@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] DHCPv6 PD route injection X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 06:51:47 -0000 On Tue, 14 Nov 2017, Alexandre Petrescu wrote: > Well, is the BNG the equivalent of a PGW? No. It's similar to a PGW but for PPPoE, typically used for *DSL, PON etc. So it's just a fancy word for "router" with some added functions. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Nov 14 00:34:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] Upleveling discussion (was Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 02:08:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Upleveling discussion (was Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 07:38:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FA8128D0F for ; Tue, 14 Nov 2017 07:38:13 -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 JxVvIrrWFkqF for ; Tue, 14 Nov 2017 07:38:11 -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 9EEAE128BC8 for ; Tue, 14 Nov 2017 07:38:11 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 24E92A80 for ; Tue, 14 Nov 2017 15:38:11 +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 Xod2kuYZpoT7 for ; Tue, 14 Nov 2017 09:38:10 -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-p8.oit.umn.edu (Postfix) with ESMTPS id 68D6BDE6 for ; Tue, 14 Nov 2017 09:36:21 -0600 (CST) Received: by mail-lf0-f72.google.com with SMTP id j204so5157824lfe.8 for ; 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=ABLMvgbEx/KiDht8SYngwMnVsLcK5ep4421WWk0Cg14hj2ZCLRkLOz8pmyx8+nZ1ZO uFiu3iKpB2hup+MNUG4Pj79kCr1DN4CfN3Yx2P6pZaCMvfh0CBlGTn51WzVl2T6dtTK9 nm7Gqv8KtCXE//dPtAe03g9q06wI5EsaUwTtTUi+1IqPePUSdccB/4cCr2XaG0xRL4VD E1Xsn71g6ToumIvxyb6njNjaoqx/4TfUcXcNcuKyQHB2pBkcHHZReUqPcE+3ZOTw1ToD +7h4U5fJyvgov0EJcZrMTjGkGuQaj0uVhmGoNxuyYy9Vr3kjQflyVy12nGn00t5QSwrH hu3w== X-Gm-Message-State: AJaThX5v5rRVkB1I8wQfXXT0nBZWZWvAK91o4GUU9HbZwWIemr1bjhcO LIURv04nSg3YgwYWAG7rNVNcNLDkXOM4FN8qpfVMZJzpTjp/e1nDX3TmfqXEHvzpRgvRU8BjuQy q3N7hjii8K0bDi+067fC8kz+0iQ== X-Received: by 10.25.104.19 with SMTP id d19mr3568158lfc.155.1510673779394; 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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 15:38:14 -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:47:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BD6128B93 for ; Tue, 14 Nov 2017 07:47:56 -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 bQPjYItMDCmt for ; Tue, 14 Nov 2017 07:47:55 -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 6B0061289B0 for ; Tue, 14 Nov 2017 07:47:55 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 45933C49 for ; 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 K6O1fQzEjPh7 for ; 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 6DC87BCE for ; Tue, 14 Nov 2017 09:37:15 -0600 (CST) Received: by mail-lf0-f71.google.com with SMTP id s16so5136943lfs.22 for ; 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=pL6JwRFEkcDdO/dH0QbtvrGwM9Q0nh1lhgJgOlqyif2n73jiHb0vGovOS/B3BnB2X7 syT6dGpCOFupKS8KUcypfJMdTNd3EiMVmensw7nqAVTGKmRqoM7aqg/GAN0awfxaysQh CRL2P06IJbbfWpB5B118OoSCiT0fOv7h0OuIP5NZSmYtraxcAMvx1hFAe+MG7GhSpy0R mGv8/tK6Nx8L3lr/6l99pDMShcJNyU1oiDn8OYydIsNehp4SqwdqUHLuAMQgzfm+osDt h6xceaL3cCVz/787RWFHegcJVOqueWNse2T492CKm2bpcsBEVy9ogwRCvy1WqTuBtkOb IqBg== X-Gm-Message-State: AJaThX777x7AXf7SISs+4GOgxXYm6On8fEwQTSOuLMu8Mjsx98WJYj47 kj6gOdYpS2fbIJ5krYare1nElWqC4cttkuUpXH8YWh1hXqqofy5+kMwOph5Fl31PhnhzqignnpU SUx//8B/D1vIUbofweIZ9+6JGQw== X-Received: by 10.25.15.161 with SMTP id 33mr5056639lfp.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: 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: Subject: Re: [v6ops] Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 15:47:56 -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:48:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8181293E3 for ; Tue, 14 Nov 2017 08:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6f9hTP1KNLs6 for ; Tue, 14 Nov 2017 08:47:56 -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 8AE761293D8 for ; Tue, 14 Nov 2017 08:47:56 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id b5so8033810itc.3 for ; Tue, 14 Nov 2017 08:47:56 -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=JJJZdeDtW5OByUzjfA0zqTk6zHaH37p9pIUubH99EOs=; b=nWbtD5eAHDnxVi4BKUSBdGTlUL/Hx/TuSQ8nBFd0gLXnq0cOCJBoyN3WT4cLSVuRUA Ms7S/RqNo7rri8UrjSgh6GpuZFHLOTpOw13yvgtR9LOyYnjq5CjP44IoT/xzPxZ7gEqA dbFWQvi0bwvawNiS9glXSAsGYCGKv4RdSgfQySMbxehu31hLbLG/C372PvWOzS+8J2tB GLgZ9A5/5ktz11JS4TdjVBiZkT/qKVkOfQQfp48e69AT87OPNNaaVtipmz/jgU2jITsI WG9RK8G/+t/MYQ5lSY0EOCmIFYkZtzofacnXmfz7s6FDdCQvMBna5l8iDJAinMyBKKOj FErw== 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=JJJZdeDtW5OByUzjfA0zqTk6zHaH37p9pIUubH99EOs=; b=WMK5uyuhNzyz/oB9DGMxhg5cPPXllwqZYmQslF0tnofiVKHEOdZ80uSxJHVo978DQU wE3kIhXuSjB4zEb/1J96VxM5F94QSCWBFmivZJAVXvgwEwShRCxM/Sj2q9Br1J/p28Pi ruefI8TGeqNuweyDyXC+ASXkUgaioIvBCwqQsor62/Ma70C7bWWjQXykDxIBWviPqzdA NkPpH3FuklWGCJfd6rqMpz9xeVMhn9kEK0Ps+hBXA6XvtIFmAShuJI5i/uWlXZm5dkuI 5FIWG+qDNBrf50VYxTrob3BaPp+Q74fwJIXLbs5M2tq0F3HHg2F/qslh74zqwON+3iS4 96Eg== X-Gm-Message-State: AJaThX6mBVPkgq4p5rQZBb8xqV8I2iVP/Kh9Ctq4obnqbNwLe2xA4d7g VpgybB4X0DdSk615NdKgm/rlhNNYj8QrYZVNx41loooq X-Google-Smtp-Source: AGs4zMbE1PQpLEHrGHD7sT47EBhLTJcHtktV5iqMIJeU0biEtgcq1jaCRap1FFtQcrLPalQvL5WOLKFl4eBKuEiqXgY= X-Received: by 10.36.73.9 with SMTP id z9mr2393337ita.88.1510678075590; Tue, 14 Nov 2017 08:47:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.82.19 with HTTP; Tue, 14 Nov 2017 08:47:34 -0800 (PST) In-Reply-To: <1B12392C-D39C-434B-8114-A38061782B9C@fugue.com> References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <89d4d29f-30ab-756d-b02c-cf460ef833ce@si6networks.com> <6ed75c9e-5f15-6207-4723-85d055a9768f@si6networks.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> <544F646A-2A40-435B-A9E0-646B85D96EC0@fugue.com> <1B12392C-D39C-434B-8114-A38061782B9C@fugue.com> From: Lorenzo Colitti Date: Wed, 15 Nov 2017 00:47:34 +0800 Message-ID: To: Ted Lemon Cc: Tom Herbert , v6ops list Content-Type: multipart/alternative; boundary="001a11c14e82119fb8055df42636" Archived-At: Subject: Re: [v6ops] Security: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 16:48:03 -0000 --001a11c14e82119fb8055df42636 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 14, 2017 at 1:53 PM, Ted Lemon wrote: > It makes sense to do this in mobile because you want the handset to be > able to move without breaking connections, so that's an example of "who > pays." But in this case are these mobile providers *currently* doing > one-locator-per-connection, or are they *currently *doing > one-locator-per-host? > Currently all mobile providers provide a /64 per host and that can't be done with identifier/locator split. --001a11c14e82119fb8055df42636 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 14, 2017 at 1:53 PM, Ted Lemon <mellon@fugue.com> wro= te:
<= div>It makes sense to do this in mobile because you want the handset to be = able to move without breaking connections, so that's an example of &quo= t;who pays." =C2=A0 But in this case are these mobile providers cur= rently doing one-locator-per-connection, or are they currently d= oing one-locator-per-host?

Curr= ently all mobile providers provide a /64 per host and that can't be don= e with identifier/locator split.
--001a11c14e82119fb8055df42636-- From nobody Tue Nov 14 08:59:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811FE126DD9 for ; Tue, 14 Nov 2017 08:59: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, 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 hWjqfz_iII88 for ; Tue, 14 Nov 2017 08:59:31 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235A71200F1 for ; Tue, 14 Nov 2017 08:59:31 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id r39so10377831qtr.13 for ; Tue, 14 Nov 2017 08:59:31 -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=M/58wj02eFvl6nKt6ADSNYQVpolJswpNNZ0xsfaIZmA=; b=J0O7mMgzd4g1HSCJEQpy/hLR/irEys6lZ7njLzVBtNajtplmue2qdf2VfM1vDlu1od 11F3kdZkaMmF+cD/6gOC4YLjr4EirxrDCPbaTnmcMW+BNioF2dg3z3jcs1qJX2wnYkcK v33hwE0+lQ9nwPI09maIY6/dasZdfR4gQY63x01042XUzVrLUfwyVyxYgNliryE5HFYP XcuDLod4JNmSi07UrhT8DhDK4W2Hqe5+by9SOZOEsvoDC6BCC7098x6Co9UJ4Z2RQRRs 9FTynM7iMFaSPqIS51FY+oa8zaXgsuEesgvkkM1q9YMriZRtrCPzLeyIoLESawBE+Row Qpsw== 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=M/58wj02eFvl6nKt6ADSNYQVpolJswpNNZ0xsfaIZmA=; b=SZn6JJ5+pH7+etdgR/S1TBt73O0uQid85f1L3psX2PQnr+Y0EKlfOpVQ6RJnq2M83w 3TGNTc6vO5p8RNpfD95e4TNiAKILeohCkDIa/vv7HUzauX4/YvcVpDgeFB3yD8izQPmi VRqz9j65v0bbuebvQy63/009I5QVOH21Tb67sCIUXC1W4nKmEauq+Oa/SILyc0Rxb8fL BzI/ZTW16hT7UMKy2csLQj2f4GgBsEtDnbZhniHsC/lBASg0yEpMjwXUbjl+jYg+Tgtg m9as04RgJj/RN7Q/5AaRDUv8rkzjb4jLs+C1sBurymd4D5I4gXSPl1j6YWIDUutD4Qwm Xfjw== X-Gm-Message-State: AJaThX50eSSglcpF/x3ro8Xnls11PPUsZmT2cvy2ZxZ5tF8mv88ym/5q 91oH9tjxuugOrciDFdKoML3C6bkIC5mt+L2FooRUaQ== X-Google-Smtp-Source: AGs4zMbe7p2pbZ5KMtKue9YOvf9QDSrCLCoHkWIhkGwiVXOnmj9dxBv4SQDXDnLL93hhKaV/E1zJKxUG5XM+ovzKpjs= X-Received: by 10.237.35.58 with SMTP id h55mr20275873qtc.108.1510678770210; Tue, 14 Nov 2017 08:59:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.54.4 with HTTP; Tue, 14 Nov 2017 08:59:29 -0800 (PST) In-Reply-To: References: <87738DE8-328D-4829-9E13-6EAC641A91E2@gmail.com> <89d4d29f-30ab-756d-b02c-cf460ef833ce@si6networks.com> <6ed75c9e-5f15-6207-4723-85d055a9768f@si6networks.com> <9766EB28-9160-48CA-B062-BF244821E834@gmail.com> <7F9BA983-C3EC-442D-B0B7-655D314B766C@gmail.com> <406D79DC-F93E-4111-80AC-D7C22E42EC01@gmail.com> <544F646A-2A40-435B-A9E0-646B85D96EC0@fugue.com> <1B12392C-D39C-434B-8114-A38061782B9C@fugue.com> From: Tom Herbert Date: Tue, 14 Nov 2017 08:59:29 -0800 Message-ID: To: Lorenzo Colitti Cc: Ted Lemon , v6ops list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Security: Unique IPv6 Prefix per Host X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 16:59:32 -0000 On Tue, Nov 14, 2017 at 8:47 AM, Lorenzo Colitti wrote: > On Tue, Nov 14, 2017 at 1:53 PM, Ted Lemon wrote: >> >> It makes sense to do this in mobile because you want the handset to be >> able to move without breaking connections, so that's an example of "who >> pays." But in this case are these mobile providers currently doing >> one-locator-per-connection, or are they currently doing >> one-locator-per-host? > > > Currently all mobile providers provide a /64 per host and that can't be done > with identifier/locator split. Lorenzo, Identifier/locator split can route /64 per host. This is already done via encapsulation, but I do think we have a solution for ILA without needing encapsulation. However, if privacy is the top goal then you really want single use addresses, /128s per connection. This achieves a similar effect for privacy that NAT gives without having the ugliness of NAT. Tom From nobody Tue Nov 14 10:28:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050BD12704A for ; Tue, 14 Nov 2017 10:28: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=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 bAys2iJMCFvQ for ; Tue, 14 Nov 2017 10:28:46 -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 3F2F4127076 for ; Tue, 14 Nov 2017 10:28:46 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id x63so13209294ioe.6 for ; Tue, 14 Nov 2017 10:28: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=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=e0jVmqh/QGQip1zcJMQLNpNMf5zXAMct7aRH+CPNOk+jiITjfd+zn458SnF2M5oYTG frBpZ944uGK0zgS0K9ZmQhnPARbgc5At33keoShkruBtUVEq1FM9TDjl83hrXDN8j0Mk xLsEOZe98WcYxZo34BhWAaiYHgk0SEw8/RaAkz4Edec2ddkhHwVZmoluEAEX0a+ISBiP XkBBLPq/7cgZs74rKbTF4pIeVRbPrc+5/lHD3oLEe4d/WUrTZSuvN0ioPK64ja8duetq 5RHugROpSzXWZ3S8N+8bb93S7WxXVP/E6eaUSeRqXt9A7X234CEsuFz4COT5Q9W/hQWO FTKQ== X-Gm-Message-State: AJaThX7ckAcvaFpXcxUqxLtKa0jw1SiM2pcNNXkyOCQpIENhORFQl0Mz MjCn36YWB0QKWNN4/Wa/WFiNdg== 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\)) 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: Subject: Re: [v6ops] Upleveling discussion (was Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 18:28:48 -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:50 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBF1127599 for ; Tue, 14 Nov 2017 12:16:43 -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 FIUeD3GymsdU 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 0FD16127876 for ; Tue, 14 Nov 2017 12:16:40 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 676D24119F for ; 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> 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: Subject: Re: [v6ops] Upleveling discussion (was Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 23:41:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9785129426 for ; Tue, 14 Nov 2017 23:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 3tdBQEWeTnRQ for ; Tue, 14 Nov 2017 23:41:36 -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 1A01D127444 for ; Tue, 14 Nov 2017 23:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510731694; x=1511336494; 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=fWW4VJIQkDUTQCk/RtmZqYMMh uRUIjXDbob5vNrnI2A=; b=l++lJnXHJiK0S1bHkcFS3IoY3dZOh0rKxBd9UX0e6 PBTOMDKi+uEQNdm9mZgP97vree/8QOBufVCi3ROpt/ArFdVDcti26IU8bhPuGeKU vU2k/Dii04iylfnnYYxmejzVbqEj1hAKGy36CEMIbwYoEmQcFm4BgUuSc8i+4Zzq EE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=gX1ew9u4YIkYFkpBXykgdimyhWoFrqKw+8l6EU07A4evPRfejOnJfr+xh3yz WxpqRQyV2F2Rp1nHZsHB8W8eldkL5LDNPSRKlkgebOQkS5m5TrT0G0yNT fKGGq+4TXgeSOTR3TJ6H8UzutoWfaS/QrEsXMlQUm55RcxbTxEG3Ic=; X-MDAV-Processed: mail.consulintel.es, Wed, 15 Nov 2017 08:41:34 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 15 Nov 2017 08:41:33 +0100 Received: from [31.133.140.255] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005624241.msg for ; Wed, 15 Nov 2017 08:41:33 +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:md50005624241::k06WW94SqhJwcI/D:000042s7 X-Return-Path: prvs=1492ded23e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Wed, 15 Nov 2017 15:41:15 +0800 From: JORDI PALET MARTINEZ To: "" Message-ID: <2A34A2BA-83D8-4CBB-B11F-8FFCFC5373F1@consulintel.es> Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-03.txt References: <150937816403.7793.11085386578208067817.idtracker@ietfa.amsl.com> <1049A23A-BC67-43B3-B158-1366A92926CD@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 07:41:38 -0000 Hi George, I think we mostly agree =E2=80=A6 may be the way I=E2=80=99m saying it in t= he document is not the best =E2=80=A6 but this is my thinking on this. If we have an IPv6-only access link, even if there is no any =E2=80=9Cfilte= ring=E2=80=9D that avoids IPv4 traffic, because the ISP side will not forwa= rd it, even if the user CE sends IPv4 traffic natively, will not =E2=80=9Cw= ork=E2=80=9D. If that traffic is encapsulated or translated via IPv6, then = is still =E2=80=9Cfrom the perspective=E2=80=9D of the network operator, an= IPv6-only access link. Regards, Jordi =20 -----Mensaje original----- De: George Michaelson Responder a: Fecha: lunes, 13 de noviembre de 2017, 15:19 Para: JORDI PALET MARTINEZ CC: "" Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-onl= y-03.txt If there is a functional barrier to any PDU which is IPv4 directly encoded, being forwarded: If there is a barrier to other non-IP packets such as ARP being forwarded, then in that sense, the link layer cannot and does not forward IPv4 and its an IPv6 only network. =20 If the administrative decision has been made not to proffer ARP responses, DHCP, or any other mechanism to bootstrap IPv4 but no barrier is placed on its use, then I can stand up an IPv4 endpoint, and hand-configure it to talk to another on the layer 2 fabric and it works. I don't consider this to be an IPv6 only network, because bad actors can send functional IPv4 between themselves. If you forward broadcast packet types its even easier. =20 If I tunnel IPv4 over IPv6 PDUs then its still an IPv6 only network. Encapsulation is not the same as raw forwarding. =20 =20 -G =20 On Mon, Oct 30, 2017 at 11:44 PM, JORDI PALET MARTINEZ wrote: > Hi all, > > I just posted a new version for this document. > > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > > Comments welcome! > > Regards, > Jordi > > > > -----Mensaje original----- > De: > Responder a: > Fecha: lunes, 30 de octubre de 2017, 16:42 > Para: Jordi Palet Martinez , Jordi Ma= rtinez > Asunto: New Version Notification for draft-palet-v6ops-ipv6-only-03.t= xt > > > A new version of I-D, draft-palet-v6ops-ipv6-only-03.txt > has been successfully submitted by Jordi Palet Martinez and poste= d to the > IETF repository. > > Name: draft-palet-v6ops-ipv6-only > Revision: 03 > Title: IPv6-only Terminology Definition > Document date: 2017-10-30 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet-drafts/draft-palet-= v6ops-ipv6-only-03.txt > Status: https://datatracker.ietf.org/doc/draft-palet-v6op= s-ipv6-only/ > Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-ipv= 6-only-03 > Htmlized: https://datatracker.ietf.org/doc/html/draft-palet= -v6ops-ipv6-only-03 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet-v= 6ops-ipv6-only-03 > > Abstract: > This document defines the terminology regarding the usage of > expressions such as "IPv6-only", in order to avoid confusions = when > using them in IETF and other documents, in reference to what i= s the > actual functionalities being used (not the actual protocol sup= port). > > > > > 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.o= rg. > > The IETF Secretariat > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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:56:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D28127B52 for ; Tue, 14 Nov 2017 23:56:07 -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 CdNDR7C1366u for ; Tue, 14 Nov 2017 23:56:05 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0135.outbound.protection.outlook.com [104.47.1.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59FAE124BE8 for ; Tue, 14 Nov 2017 23:56:04 -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=8SqukSmWm/3c5npnoP1VvQCMPcpSxsx4lxCzv+KGdrU=; b=eQMWxd9/vF2hnpJ7mSk88FnZhGDjAbB7jubFW88V7nMQrXr8ifqB+c/GInBpyMZZZG8sR22hGlSHct+O3vmgIV7cqKqsxAg9WZJbgMEULS9makXZcGSTJ6ZeoymKO337tAJtcyasYBPzFeBaFjcGR/nq/vZ048ZLDQFc1AQq6oA= 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; Wed, 15 Nov 2017 07:56:01 +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; Wed, 15 Nov 2017 07:56:00 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Mark Smith CC: "v6ops@ietf.org" , Fioccola Giuseppe Thread-Topic: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt Thread-Index: AQHTTmeRESxsl+URyUeOdsxqrIbtv6MHkqYwgACbq4CAAFvKQIAAj8qAgAACmRCAABn/gIAABDIAgAARHYCAABuOgIAAK0qAgABp9BCABhA2gIAAEcfQgAUM76A= Date: Wed, 15 Nov 2017 07:56:00 +0000 Message-ID: References: <150902848277.24072.5918643353810761226.idtracker@ietfa.amsl.com> <1089D217-18B5-4439-8516-FC36687A2CFE@nokia.com> <9CB80455-11ED-4E3A-B6EB-0CCEBDE92EC4@nokia.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:48fd:5fa4:12b8:f019] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2835; 6://YAXigU4Msx/Ehc84BIiNv28QSVVPZt1MSwKSQtJp7wOCVA0hELMHn7g6kuCrynvWiIULk7xh5kuRWLnMuUtOsbC86uW6JnCn/uxeJNt2pn4k4R1I7kH3XK2hHWFkBSFtf+DZpqwI2zWca22b9py9enzeMCyl6miW/4S87kX6Waw17ILdvnQud7H4ZsLUqY7d5DF2O50xfJs5rOVQReb5i7dxAfib+ZdN2DDLGLEob/W/coG9f+gUqse1cEtJKRZvGMLGbkUSkUbv28DvggHayBFtL36WKI5ZjY+5fjw+9ROKOczEYtsg6+pMpZXTfQWqjbixNr8+H7ahqQfIHOPmUzV74xLCdt6M385i7a/NY=; 5:pidwYUn/VINbBjLf7KCI5lR8d0h6c+qxYqpud7oDK5fmo48g+BHorMTHhhhEvBRq80ya9NQvOIqh0InJqPgtFodLSRNpj15ZXeh48ryoFkj8LFBJx+zsmOcN06jb4qqgaxHpOgxGCwJK676o4eylo1HKjh/wZ61Tpf5z9eAAppQ=; 24:nOUoMKjHqblcz+4pnLNGPCypJmzlq5ZX4Wp7RaCLbr8e1/+ED+TL5sBG865p3XbzIC+Es+b3hZw92+Rp6J8aUbISAu3jhm1B6KLYM3mwkVU=; 7:9fUqy00/OqCFxzlgFuKP0OPzF6LaZSBM20hehVjgKMItZblL5MZsFxusSn+hzR5pM/6bdH65sKMAgf8xFDPUoRcIWguANazcN/Bi0UJCbvruPb+orIoBgGihejXLUINzCFBiQL5czgcNKw3RQ10OJNxPXIJS1tU9h4rM4noQRQvxwZBR68krQBzMxpMxxuMmA64ANTnRDeOWvHiHgB2uv6ap5tuWouC0sc+ibsFeOiPuu7+OXkeMQ2Lmbg6TYU8D x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(346002)(39860400002)(376002)(53754006)(51444003)(24454002)(51914003)(199003)(189002)(13464003)(101416001)(561944003)(8936002)(189998001)(316002)(966005)(53546010)(7736002)(76176999)(50986999)(99286004)(305945005)(74316002)(110136005)(6306002)(6246003)(55016002)(97736004)(53936002)(54356999)(9686003)(39060400002)(93886005)(33656002)(54906003)(14454004)(68736007)(105586002)(86362001)(106356001)(81156014)(15650500001)(5660300001)(81166006)(25786009)(6436002)(8676002)(478600001)(2906002)(3660700001)(3280700002)(5250100002)(2900100001)(6506006)(229853002)(4326008)(230783001)(7696004)(2950100002)(6116002)(102836003); 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; x-ms-office365-filtering-correlation-id: 325ade15-87ed-4ca6-7920-08d52bfe4fe1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(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)(788757137089)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(3231022)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(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: 0492FD61DD received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 325ade15-87ed-4ca6-7920-08d52bfe4fe1 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 07:56:00.3251 (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: Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 07:56:08 -0000 SGkgQWxsLA0KDQpCYXNlZCB1cG9uIHRoZSBmZWVkYmFjayBpbiB2Nm9wcywgdGhlIGF1dGhvcnMg cmVhY2hlZCByZWFsaXphdGlvbiB0aGF0IHRoZSBwcm9wb3NlZCBtZXRob2QgaGFzIGEgbW9yZSBn ZW5lcmFsIGFsdGVybmF0ZSBtYXJraW5nIGFwcGxpY2FiaWxpdHkgd2l0aCBpcHY2IHR1bm5lbHMu IFRoaXMgYmVjYXVzZSBTUnY2IGNhbiBiZSBzZWVuIGFzIGEgd2VsbCBkb2N1bWVudGVkIHVzZSBj YXNlIHNjZW5hcmlvIG9mIElQdjYgdHVubmVsIGVuY2Fwc3VsYXRpb24uIA0KDQpIZW5jZSwgdGhl IGF1dGhvcnMgd2lsbCByZXNwaW4gdGhlIGRyYWZ0IGRyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93 LWxhYmVsLWFsdC1tYXJrLTAxIGludG8gYSBuZXcgdjZvcHMgZHJhZnQgY3JlYXRpbmcgYSBtb3Jl IGdlbmVyYWwgSVB2NiB0dW5uZWwgYXBwcm9hY2guIFRoZSBjb250cm9sbGVkIGRvbWFpbiBmb3Ig bWFya2luZyBpbiB0aGF0IGNhc2UgaXMgY29udGFpbmVkIGJldHdlZW4gdHVubmVsIGhlYWQgYW5k IHRhaWwgZW5kLg0KKGFuZCBTUnY2IHdpbGwgYmUgdHJhdmVsaW5nIHdpdGhpbiB0aGUgdjYgZW5j YXAgdHVubmVsIGFzIHBheWxvYWQpDQoNClRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIGZvcm0gYWxs LA0KRy8NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdjZvcHMgW21haWx0 bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVmFuIERlIFZlbGRlLCBHdW50 ZXIgKE5va2lhIC0gQkUvQW50d2VycCkNClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMTIsIDIwMTcg MTA6MzMNClRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPg0KQ2M6IHY2b3Bz QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1maW9jY29sYS1zcHJpbmctZmxvdy1sYWJlbC1hbHQtbWFyay0wMS50eHQN Cg0KSW4gU1J2NiB3ZSBoYWQgc2ltaWxhciBvbiB0aGUgcmVhbGl0eSBvZiB0aGUgbmVlZCBvZiAx MjggYml0cyB2cyA2NCBiaXRzIGluc2lkZSB0aGUgU1JIIGhlYWRlci4uLi4gSXQgd2FzIHN0cm9u Z2x5IG9wcG9zZWQgYnkgdGhlIGVkaXRvcnMgb2YgdGhlIFNSdjYgZGF0YXBsYW5lIGRyYWZ0LiBS ZWFzb24gd2FzIHRoYXQgaXQgZGlkIG5vdCBwcm92aWRlcyB0aGUgc2FtZSBjYXBhYmlsaXR5IG9m IHVuaXF1ZWx5IGlkZW50aWZ5aW5nIGEgc2luZ2xlIHN5c3RlbS4NCg0KSSB0aGluayBpdCBpcyBh IGdvb2QgcXVlc3Rpb24gdG8gYXNrIGFuZCBhIHZhbGlkIG9wdGltaXphdGlvbiBmb3IgYSByYW5n ZSBvZiB1c2UtY2FzZXMuIFF1ZXN0aW9uIGlzIGlmIHRoZSB1c2UtY2FzZXMgYXJlIHN0cm9uZyBl bm91Z2ggdG8ganVzdGlmeSB0aGUgcGVyY2VpdmVkIGJlbmVmaXRzIG9mIDEyOCBiaXRzIHZzIDY0 IGJpdHMuIFRoaXMgaXMgYSBkaXNjdXNzaW9uIHRvIGhhdmUgaW4gU1BSSU5HIHdnIGlmIHRoYXQg aXMgc29tZXRoaW5nIHRoYXQgaXMgZm91bmQgd29ydGh5IGEgZGlzY3Vzc2lvbg0KDQpHLw0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJrIFNtaXRoIFttYWlsdG86bWFy a3p6enNtaXRoQGdtYWlsLmNvbV0NClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIgMTIsIDIwMTcgMDk6 MjMNClRvOiBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8Z3VudGVy LnZhbl9kZV92ZWxkZUBub2tpYS5jb20+DQpDYzogVG9tIEhlcmJlcnQgPHRvbUBoZXJiZXJ0bGFu ZC5jb20+OyB2Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10gRlc6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZmlvY2NvbGEtc3ByaW5nLWZsb3ctbGFiZWwtYWx0 LW1hcmstMDEudHh0DQoNCkhpIEd1bnRlciwNCg0KT24gOCBOb3ZlbWJlciAyMDE3IGF0IDE2OjA1 LCBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8Z3VudGVyLnZhbl9k ZV92ZWxkZUBub2tpYS5jb20+IHdyb3RlOg0KPiBUaGVyZSBmZXcgb3RoZXIgZHJhd2JhY2tzIHRo YXQgd2UgY29uc2lkZXJlZCB3aGVuIHdlIHNlbGVjdGVkIHRvIHVzZSBGbG93LWxhYmVsIGluc3Rl YWQgb2YgYW4gRUggc29sdXRpb24gZm9yIFNSdjYgYWx0ZXJuYXRlIG1hcmtpbmc6DQo+DQo+ICog ZWFzaWVyIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgYmVjYXVzZSBub3RoaW5nIGJyZWFrcyBpZiBh IHRyYW5zaXQgDQo+IHJvdXRlciBkb2VzIG5vdCBoYXZlIHRoZSBjYXBhYmlsaXR5IG9mIHVuZGVy c3RhbmRpbmcgdGhlIEZsb3cgbGFiZWwgDQo+IGNvbnRleHQuLi4gaW4gdGhhdCBjYXNlIHRoZSBm bG93LWxhYmVsIGluIHRoZSBvdXRlciB0dW5uZWwgaGVhZGVyIGlzIA0KPiBqdXN0IGEgZmxvdy1s YWJlbA0KPiAqIEhhdmluZyBhIEhiSCBFSCBzZWVtcyBsZXNzIGJhY2t3YXJkIGNvbXBhdGlibGUs IGFuZCB3aWxsIGJlIGxlc3MgZWFzeSB0byB1c2UgdW5sZXNzIEFMTCByb3V0ZXJzIGluIHRoZSBk b21haW4gc3VwcG9ydCB0aGVzZSB0eXBlIG9mIGhlYWRlcnMgaW4gdGhlIGZhc3QtcGF0aC4uLiBp dCBqdXN0IHNlZW1zIGNvbXBsZXggYmVjYXVzZSBvZiBhbGwgdGhlIGlmLXRoZW4tYnV0IGludm9s dmVkIHRvIGltcGxlbWVudCwgdXNlIGFuZCBvcGVyYXRlLi4uDQoNCkkgdGhpbmsgdGhhdCBpcyBh biBhZHZhbnRhZ2Ugb2YgdXNpbmcgZGVzdGluYXRpb24gYWRkcmVzc2VzIHRvIGVuY29kZSB0aGlz IHByb2Nlc3NpbmcuDQoNCkluIGFkZGl0aW9uIHRvIGlkZW50aWZ5aW5nIGEgaG9zdCwgSSB0aGlu ayBpbiBJUCBhIGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgYWxzbyBhbmQgbW9yZSBmdW5kYW1lbnRh bGx5IGlkZW50aWZ5aW5nIGFuIGV4aXQgcG9pbnQgZnJvbSB0aGUgZm9yd2FyZGluZyBkb21haW4u IEl0IGluZGljYXRlcyB3aGVyZSBwcm9jZXNzaW5nIGZvciBmb3J3YXJkaW5nIHRvIHRoZSBEQSBz dG9wcywgYW5kIHdoZXJlIG90aGVyIG1vcmUgY29tcGxleCBwcm9jZXNzaW5nIG9mIHRoZSBwYWNr ZXQgaXMgdG8gb2NjdXIsIHVzaW5nIGluZm9ybWF0aW9uIHBhc3QgdGhlIGZpeGVkIElQIGhlYWRl ciwgYW5kIGxpa2VseSBpbiB0aGUgcGF5bG9hZC4gUHJvY2Vzc2luZyBvZiB0aGUgSVB2NiBSb3V0 aW5nIEhlYWRlciBFSCwgb3IgaW5mb3JtYXRpb24gaW4gdGhlIHBheWxvYWQgZS5nLiB0cmFuc3Bv cnQgYW5kIGZ1cnRoZXIgdXBwZXIgbGF5ZXIgcHJvY2Vzc2luZyBhcmUgZXhhbXBsZXMuDQoNClVz aW5nIHRoZSBEQSB0byBlbmNvZGUgdGhpcyBtb3JlIGNvbXBsZXggcHJvY2Vzc2luZyBtZWFucyB0 aGF0IGl0IGlzIGVhc3kgdG8gcmV0cm9maXQgaW50byBleGlzdGluZyBkZXZpY2VzIGFuZCBtb2Rl bHMuIFRoZXJlIGlzIG5vIG5lZWQgdG8gcmVwbGFjZSBleGlzdGluZyBJUHY2IGZvcndhcmRpbmcg ZGV2aWNlcywgYmVjYXVzZSB0aGV5IGFscmVhZHkgc3VwcG9ydCBEQSBiYXNlZCBmb3J3YXJkaW5n LiBBbiBTUiBib3ggd2l0aCB0aGUgREEgY291bGQgYmUgaHVuZyBvZmYgdGhlIHNpZGUgb2YgYW4g ZXhpc3Rpbmcgcm91dGVyLCBkbyBpdHMgbWFnaWMsIGFuZCB0aGVuIHJlc3VibWl0IHRoZSBuZXds eSBTUiBwcm9jZXNzZWQgcGFja2V0IGJhY2sgaW50byB0aGUgY29udmVudGlvbmFsIGZvcndhcmRp bmcgZG9tYWluLCB0byBiZSBmb3J3YXJkZWQgb250byB0aGUgbmV4dCBTUiBib3ggdGhhdCBvd25z IHRoZSBzcGVjaWZpZWQgREEgKEluc3BpcmVkIGJ5IGhvdyBJcHNpbG9uIE5ldHdvcmtzIGFkZGVk IElQIGZvcndhcmRpbmcgdG8gQVRNIG5ldHdvcmtzKS4NCg0KDQo+ICogRm9yIEhXIGJhc2VkIHJv dXRlcnMgKGkuZS4gaW4gTm9raWEgY2FzZSBoYXZpbmcgdXNlci1wbGFuZSBzd2l0Y2hpbmcgDQo+ IGNhcGFiaWxpdHkgc2NhbGUgb2YgMi44VCBwZXIgTlBVKSB0aGUgc3VwcG9ydCBuZWFybHkgY29t ZXMgZm9yIGZyZWUgYXMgDQo+IHN1cHBvcnQgaXMgYWxyZWFkeSB0aGVyZS4uLiBub3RoaW5nIGV4 dHJhIGlzIG5lZWRlZCBmcm9tIGEgbm9kYWwgDQo+IHBlcnNwZWN0aXZlDQo+ICogTGVzcyBiaXRz IG9uIHRoZSB3aXJlLi4uIGdvaW5nIFNSdjYgaGFzIGFscmVhZHkgYSBzaWduaWZpY2FudCANCj4g Yml0cy1vbi13aXJlIHRheCBiZWNhdXNlIG9mIHRoZSBvdXRlciBJUHY2IGhlYWRlciBhbmQgdGhl IFNSdjYgRUggYW5kIA0KPiBhbGwgdGhlIHNvdXJjZSByb3V0aW5nIGhlYWRlcnMNCj4NCg0KIlNj cm91bmdpbmciIGJpdHMgZnJvbSBvdGhlciBmaWVsZHMgYmVjYXVzZSB0aGUgU1J2NiBoZWFkZXIg aGFzIGJlY29tZSBsYXJnZSBzZWVtcyB0byBiZSB0cnlpbmcgdG8gYXZvaWQgZml4aW5nIHRoZSBw cm9ibGVtIHdoZXJlIGl0IGlzIGNhdXNlZC4NCg0KSSdkIGd1ZXNzIGEgbG90IG9mIHRoaXMgc2l6 ZSBoYXMgY29tZSBmcm9tIHRoZSB1c2Ugb2YgMTI4IGJpdCBJUHY2IGFkZHJlc3NlcyB0byBpZGVu dGlmeSBzZWdtZW50cy4gSSB0aGluayBhIHF1ZXN0aW9uIGlzIGRvIHRoZXkgcmVhbGx5IG5lZWQg dG8gYmUgdGhhdCBsYXJnZT8NCg0KSSB0aG91Z2h0IGFib3V0IHBlci1wYWNrZXQgb3ZlcmhlYWQg aW4gdGhlIGNvbnRleHQgb2YgSVB2NiB0dW5uZWxsaW5nIGEgZmV3IHllYXJzIGFnby4gSXQgb2Nj dXJyZWQgdG8gbWUgdGhhdCBpZiB0dW5uZWwgZW5kLXBvaW50cyB3ZXJlIGlkZW50aWZpZWQgdXNp bmcgLzY0cyByYXRoZXIgdGhhbiAvMTI4cywgdGhlbiB0aGUgSUlEIHBhcnRzIG9mIHRoZSBvdXRl ciBJUHY2IHNvdXJjZSBhbmQgZGVzdGluYXRpb24gYWRkcmVzc2VzIGNvdWxkIGJlIHVzZWQgZm9y IHNvbWV0aGluZyBlbHNlLiBJZiB0aG9zZSBvdGhlciB0aGluZ3MgY2FtZSBmcm9tIHRoZSBpbm5l ciBwYWNrZXQsIHRoZW4gdGhleSBjb3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIGlubmVyIHBhY2tl dCwgcmVkdWNpbmcgdGhlIGVmZmVjdGl2ZSB0dW5uZWxsaW5nIG92ZXJoZWFkLg0KDQpJIHdyb3Rl IHVwIHNvbWUgb2YgdGhvc2UgaWRlYXMgaW4gIkVuaGFuY2luZyBWaXJ0dWFsIE5ldHdvcmsgRW5j YXBzdWxhdGlvbiB3aXRoIElQdjYiDQooaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXNtaXRoLWVuaGFuY2Utdm5lLXdpdGgtaXB2Ni0wNykuDQpNb3JlIHJlY2VudGx5IEkgdG9vayB0 aGUgbmV4dCBzdGVwIGFuZCBkZXZlbG9wZWQgYSB0dW5uZWxsaW5nIG1ldGhvZCwgYWx0aG91Z2gg dGhlIHNhdmluZ3Mgd2VyZW4ndCBxdWl0ZSBhcyBoaWdoIGFzIEknZCBob3BlZCBkdWUgdG8gdGhl IDggb2N0ZXQgbWluaW11bSBzaXplIHJlcXVpcmVtZW50IG9mIGFuIEV4dGVuc2lvbiBIZWFkZXIg LSAiU2tpbm55IElQdjYgaW4gSVB2NiBUdW5uZWxsaW5nIg0KKGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zbWl0aC1za2lubnktaXB2Ni1pbi1pcHY2LXR1bm5lbGxpbmctMDApDQoN CklQdjYgbmV0d29ya3MgaGF2ZSBhIGxvdCBvZiAvNjRzLiBJbiB0aGlzIGRyYWZ0J3Mgc2NlbmFy aW8sIFVMQSBhZGRyZXNzaW5nIHNob3VsZCBiZSBiZWluZyB1c2VkIGZvciB0aGUgb3V0ZXIgaGVh ZGVyIGFkZHJlc3NpbmcgdG8gbWluaW1pc2UgbGVha2luZy4gVUxBIC80OHMgaGF2ZSA2NUsgLzY0 cywgYW5kIGlmIHRoYXQgaXNuJ3QgZW5vdWdoLCBtdWx0aXBsZSBVTEEgLzQ4IHByZWZpeGVzIGNh biBiZSB1c2VkIHRvIGdlbmVyYXRlIG1vcmUgLzY0cy4NCg0KSXQgd291bGQgYmUgYSBzaWduaWZp Y2FudCBjaGFuZ2UgdG8gU1IgYXQgdGhpcyB0aW1lIEknZCBzdXNwZWN0LCBob3dldmVyIEkgdGhp bmsgdXNpbmcgLzY0cyBhcyBTZWdtZW50IElEcyByYXRoZXIgdGhhbiAvMTI4cyB3b3VsZCBtYWtl IGEgc2lnbmlmaWNhbnQgU1JIIHNpemUgb3ZlcmhlYWQgc2F2aW5nLCBhdm9pZGluZyB0aGUgbmVl ZCB0byB0cnkgdG8gbGV2ZXJhZ2Ugb3RoZXIgbm9uLVNSIGZpZWxkcywgc3VjaCBhcyB0aGUgRmxv dyBMYWJlbCwgIGZvciBTUiBvciByZWxhdGVkIGluZm9ybWF0aW9uLg0KDQpSZWdhcmRzLA0KTWFy ay4NCg0KDQo+IFNvLCBpbmRlZWQgYSBuZXcgdHlwZSBvZiBFSCBtYXkgYmUgYSBzb2x1dGlvbiBz cGFjZSBwcm9wb3NhbCwgaG93ZXZlciwgSSBkbyBub3QgdGhpbmsgaXQgaXMgYXMgcHJhZ21hdGlj IGFzIHVzaW5nIHRoZSBmbG93LWxhYmVsIGluIHRoZSBvdXRlciBJUHY2IFNSdjYgaGVhZGVyIGJl Y2F1c2Ugb2YgYWxsIHRoZSBiZW5lZml0cyBmbG93LWxhYmVsIHVzYWdlIGdpdmVzLiBUaGUgRmxv dy1sYWJlbCBwcm9wb3NhbCwgaXMgYmFzaWNhbGx5IHNvbWV0aGluZyB0aGF0IHJvdXRlcnMgY2Fu IGRvIHJpZ2h0IG5vdywgIGFuZCBpdCBkb2VzIG5vdCBicmVhayBhbnkgSVB2NiBydWxlcyBhbmQg aXMgZXhwZWN0ZWQgdG8gYmUgc3VwcG9ydGVkIGluIGxpbmUtcmF0ZSBieSB0aGUgZmFzdCBwYXRo IHN3aXRjaGluZyBvZiByb3V0ZXJzIGJ5IGRlZmF1bHQuDQo+DQo+IEluZGVlZCBzaGUgc29sdXRp b24gcHJvcG9zZWQgaW4gdGhlIGRyYWZ0LCBpcyBmb3IgdGhlIG1vbWVudCBhc3N1bWVkIHRvIGJl IGV4Y2x1c2l2ZSBmcm9tIG90aGVyIHVzYWdlcyAod2l0aCBleGNlcHRpb24gb2YgZW50cm9weSkg b2YgdGhlIGZsb3ctbGFiZWwgaW4gdGhlIGNvbnRyb2xsZWQgb3BlcmF0b3IgZG9tYWluLi4uIGl0 IGRvZXMgbm90IG5lY2Vzc2FyeSBoYXZlIHRvIGJlIGV4Y2x1c2l2ZSwgYnV0IGl0IHNlZW1zIHRo ZSBtb3N0IHByYWdtYXRpYy4gQ3VycmVudGx5LCBvcGVyYXRvciB0cmFkaXRpb25hbGx5IGRvIG5v dCB1c2UgZmxvdy1sYWJlbCBhdCBhbGwsIGhlbmNlIHRoZSBhYm92ZSBhc3N1bXB0aW9uIHNlZW1z IHJlYXNvbmFibGUuDQo+DQo+IEcvDQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4gU2Vu dDogVHVlc2RheSwgTm92ZW1iZXIgNywgMjAxNyAyMzoyOA0KPiBUbzogVmFuIERlIFZlbGRlLCBH dW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkgDQo+IDxndW50ZXIudmFuX2RlX3ZlbGRlQG5va2lh LmNvbT4NCj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEZXOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiBkcmFmdC1maW9jY29sYS1zcHJpbmctZmxv dy1sYWJlbC1hbHQtbWFyay0wMS50eHQNCj4NCj4gT24gVHVlLCBOb3YgNywgMjAxNyBhdCAxMTo1 MyBBTSwgVmFuIERlIFZlbGRlLCBHdW50ZXIgKE5va2lhIC0NCj4gQkUvQW50d2VycCkgPGd1bnRl ci52YW5fZGVfdmVsZGVAbm9raWEuY29tPiB3cm90ZToNCj4+IEhpIFRvbSwNCj4+DQo+PiBUaGUg Y2xvc2VkIHN5c3RlbSBoZXJlIGlzIGRlZmluZWQgYnkgdGhlIFNSdjYgdHVubmVsc+KApiBUaGUg Zmxvdy1sYWJlbCBpcyBzZXQg4oCcb25seeKAnSBieSB0aGUgdHVubmVsIGhlYWQtZW5kIHJvdXRl ciDigJxvbiB0aGUgb3V0ZXIgSVB2NiBoZWFkZXLigJ0uIFRoZSB0dW5uZWwgaGVhZC1lbmQgcm91 dGVyIGNhbiBkbyB0aGlzIGJlY2F1c2UgaXQgaXMgdGhlIGRldmljZSB0aGF0IGNyZWF0ZWQgdGhl IG91dGVyIElQIGhlYWRlci4NCj4+IFRoZSBvcmlnaW5hbCBJUHY2IHBhY2tldCBpcyByaWRpbmcg aW5zaWRlIHRoZSB0dW5uZWwsIGFuZCBhcyByZXN1bHQgDQo+PiB0aGUgb3JpZ2luYWwgZmxvdyBs YWJlbCBhbmQgb3JpZ2luYWwgSVB2NiBoZWFkZXIgaXMgbGVmdCB1bnRvdWNoZWQuIFRoZSBjbG9z ZWQgc3lzdGVtIGlzIHRoZSBuZXR3b3JrIGJldHdlZW4gdGhlIHR1bm5lbCBoZWFkLWVuZCAoPXdo ZXJlIHRoZSBvdXRlciBJUHY2IGhlYWRlciBpcyBhZGRlZCkgYW5kIHRoZSB0dW5uZWwgdGFpbC1l bmQgKD13aGVyZSB0aGUgb3V0ZXIgaGVhZGVyIGlzIHJlbW92ZWQpLiBUaGlzIHR5cGUgb2YgY2xv c2VkIHN5c3RlbSBpcyBlYXN5IHRvIGRlcGxveeKApiB0YWtlIGZvciBleGFtcGxlIGEgTVBMUy9W UE4gYmFja2JvbmXigKYuIE9yIGEgVnhMQU4gbmV0d29ya+KApiBUaGUgU1J2NiBuZXR3b3JrIGlz IHNvbWV0aGluZyBvZiBzaW1pbGFyIHNpbXBsaWNpdHkuDQo+Pg0KPj4gVGhlIElQdjYgZGV2aWNl IHRoYXQgZ2VuZXJhdGVzIGFuIElQdjYgcGFja2V0IGNhbiBzZXQgdGhlIGZsb3cgbGFiZWwsIGFu ZCB0aGF0IGlzIHdoYXQgZGV2aWNlcyBoYXZlIGJlZW4gZG9pbmcgYWxsIHRoZSB0aW1lLiBUaGlz IGRyYWZ0IHByb3Bvc2VzIG5vdGhpbmcgbmV3IGZyb20gdGhhdCBwZXJzcGVjdGl2ZS4NCj4+DQo+ PiBXaHkgZG8geW91IHNheSDigJhyZXB1cnBvc2luZ+KAmSB0aGUgYml0cz8gTm90aGluZyBpcyBy ZXB1cnBvc2VkLiBUaGlzIHByb3Bvc2FsIGlzIHJlc3BlY3RpbmcgUkZDNjQzNy4gSW4gb3VyIGlu Zm9ybWF0aW9uYWwgcHJvcG9zYWwgdGhlIGZsb3ctbGFiZWwganVzdCByZW1haW5zIGZsb3ctbGFi ZWwuIFJvdXRlcnMgY2FuIGJlIG1hZGUgdG8gbWF0Y2ggdXBvbiBmbG93LWxhYmVsIHZhbHVlcyBl YXNpbHkuIEkga25vdyBteSBOb2tpYSBwcm9kdWN0cyBjYW4gZG8gdGhhdCB2ZXJ5IGVhc2lseSwg YmVjYXVzZSB0aGUgZmxvdy1sYWJlbCBpcyBhbHdheXMgZm91bmQgYXQgdGhlIHNhbWUgcGxhY2Ug aW4gdGhlIElQdjYgaGVhZGVyLiBIb3dldmVyLCBjaGVja2luZyBvbiBFSHMgaXMgYSBmZXcgZGlt ZW5zaW9ucyBtb3JlIGNvbXBsaWNhdGVkLiBXaGVuIEkgbXVzdCBtYWtlIG15IHJvdXRlciBtYXRj aCBmb3IgY29udGVudCBpbiBFSHMsIHRoZW4gZmlyc3QgaXQgbXVzdCBjaGVjayBpZiB0aGUgcmVs ZXZhbnQgRUggaXMgaW5zZXJ0ZWQsIHRoZW4gdGhlIGNvcnJlc3BvbmRpbmcgRUggbXVzdCBiZSBp ZGVudGlmaWVkIGFuZCB0aGVuIHRoZSBjb250ZW50IGhhcyB0byBiZSBjaGVja2Vk4oCmIFRoaXMg RUggY2hlY2tpbmcgaXMgbm9uLXRyaXZpYWwgYXMgcmVzdWx04oCmIEZvciBhIEhXIGJhc2VkIHJv dXRlciAobXkgTm9raWEgcm91dGVyIGZvciBleGFtcGxlKSB0aGUgY2hlY2tpbmcgb2YgZmxvdy1s YWJlbCBpcyBhcyBzaW1wbGUgYXMgY2hlY2tpbmcgZm9yIGEgRFNDUCB2YWx1ZSBiZWNhdXNlIHRo ZSBvcGVyYXRpb24gaW52b2x2ZWQgaXMgZXhhY3RseSB0aGUgc2FtZS4NCj4NCj4gSSBkb24ndCBi ZWxpZXZlIHRoZSBFSCBwcm9jZXNzaW5nIG5lZWRzIHRvIGJlIGNvbXBsaWNhdGVkLiBJbiB0aGlz IGNhc2UgdGhlIGFzc3VtcHRpb24gaXMgdGhhdCBuZXR3b3JrIG9wZXJhdG9yIGlzIGluc2VydGlu ZyB0aGUgaGVhZGVycyBzbyB0aGUgSEJIIEVIIHdpdGggYSBsYXRlbmN5IG1lYXN1cmVtZW50IG9w dGlvbiBjb3VsZCBiZSBpbXBsZW1lbnRlZCB0byBhbHdheXMgYmUgaW4gdGhlIHNhbWUgcG9zaXRp b24sIGhhdmUgdGhlIHNhbWUgbGVuZ3RoLCBhbmQgb25seSBzZXQgd2l0aCBvbmUgb3B0aW9uIGZv ciBsYXRlbmN5LiBUaGUgcm91dGVyIHByb2Nlc3NpbmdjYW4gYmUgb3B0aW1pemVkIHRvIGhhbmRs ZSB0aGlzIGNhc2UuIEV4aXN0ZW5jZSBhbmQgdmVyaWZpY2F0aW9uIG9mIHRoZSBFSCBjYW4gYWxs IGJlIGRvbmUgd2l0aCBzaW1wbGUgY2hlY2tzIGFuZCBUQ0FNIGNvdWxkIGJlIHVzZWQgdG8gbWF0 Y2ggdGhlIGNvbW1vbiBoZWFkZXIgcGF0dGVybi4gVGhlIElQIGhlYWRlciBhbmQgZXh0ZW5zaW9u IGhlYWRlciBzaG91bGQgZml0IHdlbGwgd2l0aGluIHRoZSBwYXJzaW5nIGJ1ZmZlciBvZiB0eXBp Y2FsIHJvdXRlcnMuDQo+DQo+Pg0KPj4gVG9tLCBpZiB5b3VyIGFkZGl0aW9uYWwgc3VnZ2VzdGlv bnMgZm9yIHVzaW5nIGZsb3cgbGFiZWxzIGlzIHJlc3BlY3RpbmcgUkZDNjQzNyB0aGVuIHdoYXQg c3RvcHMgeW91IGZyb20gZG9jdW1lbnRpbmcgdGhvc2UgdGhvdWdodHM/IFRoZSBhbHRlcm5hdGUg bWFya2luZyBwcmluY2lwbGUgZG9jdW1lbnRlZCBpbiB0aGlzIGRyYWZ0IGZvciBTUnY2IGlzIHNv bWV0aGluZyB0aGF0IGlzIGRyaXZlbiBieSBvcGVyYXRvciB0aGVtc2VsdmVzLCBhbmQgaXMgYmFz ZWQgdXBvbiByZWFsIG9wZXJhdG9yIHJlcXVpcmVtZW50LiBGZWVsIGZyZWUgdG8gZnVydGhlciBk aXNjdXNzIHdpdGggdGhlIFRlbGVrb20gSXRhbGlhIGNvLWF1dGhvcnMgKEd1aXNlcHBlIGFuZCBN YXVybykgb24gVEkgbmVlZHMgZm9yIHN1Y2ggcGFzc2l2ZSBtZWFzdXJlbWVudCBtZWNoYW5pc20g KGxvc3MsIGxhdGVuY3ksIGppdHRlciwgZXRjKS4NCj4NCj4gVGhlIGZhY3QgdGhhdCBvcGVyYXRv cnMgd2FudCBwYXNzaXZlIGxhdGVuY3kgbWVhc3VyZW1lbnRzIGlzIG5vdCB0aGUgc2FtZSBhcyBz YXlpbmcgdGhhdCBhcHBseWluZyBhIGZvcm1hdCB0byB0aGUgZmxvdyBsYWJlbCBpcyBhIHJlcXVp cmVtZW50LiBJdCBpcyB0aGUgbWVjaGFuaXNtIG9mIHRoaXMgcHJvcG9zYWwgdGhpcyBpcyBpbiBx dWVzdGlvbi4NCj4NCj4gVG9tDQo+DQo+DQo+Pg0KPj4gRy8NCj4+DQo+Pg0KPj4NCj4+IE9uIDA3 LzExLzIwMTcsIDE5OjE0LCAiVG9tIEhlcmJlcnQiIDx0b21AaGVyYmVydGxhbmQuY29tPiB3cm90 ZToNCj4+DQo+PiAgICAgT24gVHVlLCBOb3YgNywgMjAxNyBhdCA5OjEzIEFNLCBWYW4gRGUgVmVs ZGUsIEd1bnRlciAoTm9raWEgLQ0KPj4gICAgIEJFL0FudHdlcnApIDxndW50ZXIudmFuX2RlX3Zl bGRlQG5va2lhLmNvbT4gd3JvdGU6DQo+PiAgICAgPiBUbyBtZSBpdCBzZWVtcyB0aGF0IGxvb2tp bmcgYXQgRkwgaXMgbXVjaCBlYXNpZXIgZm9yIGEgSFcgYmFzZWQgDQo+PiByb3V0ZXIgdGhlbiBs b29raW5nIGF0IEVIcyBpbiBhIGhvcC1ieS1ob3AgZmFzaGlvbuKApg0KPj4NCj4+ICAgICBFYXNp ZXIgZm9yIHdob20/IFJlcHVycG9zaW5nIGJpdHMgaW4gdGhlIElQIGhlYWRlciBldmVuIGZvciBh IG5hcnJvdw0KPj4gICAgIHVzZSBjYXNlIGluIGEgY2xvc2VkIHN5c3RlbSBkb2Vzbid0IHNlZW0g cGFydGljdWxhcmx5IGVhc3kgdG8NCj4+ICAgICBzdGFuZGFyZGl6ZSBvciBkZXBsb3kuIEFzIE1h cmsgcG9pbnRlZCBvdXQgdGhlcmUncyBhIGxvdCBvZiBjb21wbGV4aXR5DQo+PiAgICAgYXJvdW5k IGVuc3VyaW5nIHRoYXQgdGhlIHN5c3RlbSByZWFsbHkgaXMgY2xvc2VkIGFuZCBhbGwgcmVxdWly ZWQNCj4+ICAgICBiZWhhdmlvciBpcyBtYWludGFpbmVkLg0KPj4NCj4+ICAgICBBbm90aGVyIG9i dmlvdXMgcXVlc3Rpb24gd2l0aCB0aGlzIGFwcHJvYWNoIGlzIGRvZXMgaXQgbWVhbiB0aGF0IGZs b3cNCj4+ICAgICBsYWJlbCBiaXRzIGFyZSBub3cgZmFpciBnYW1lIHRvIGJlIGRlZmluZWQgZm9y IGV2ZW4gbW9yZSBwdXJwb3Nlcz8NCj4+ICAgICBMYXRlbmN5IG1lYXN1cmVtZW50IGlzbid0IGJl IHRoZSBvbmx5IHBvdGVudGlhbCB1c2UgY2FzZS4gRm9yDQo+PiAgICAgaW5zdGFuY2UsIEkga25v dyB0aGVyZSdzIGEgbG90IG9mIHBlb3BsZSB0aGF0IHdhbnQgaG9zdHMgdG8gbWFyaw0KPj4gICAg IHBhY2tldHMgd2l0aCBhICJyZXRyYW5zbWl0dGVkIiBiaXQgc28gdGhhdCByb3V0ZXJzIGNhbiBr ZWVwIHN0YXRzIGZvcg0KPj4gICAgIHRyYWNrZWQgZmxvd3MuIElNTywgaWYgdXNpbmcgZmxvdyBi aXRzIGxpa2UgdGhpcyBpcyB0aGUgcmlnaHQgYW5zd2VyDQo+PiAgICAgdGhlbiB0aGVyZSBzaG91 bGQgYmUgYSBnZW5lcmljIHByb3RvY29sIHNwZWNpZmljYXRpb24gdGhhdCBkZWZpbmVzIHRoZQ0K Pj4gICAgIG9wZXJhdGlvbiBhbmQgaG93IGJpdHMgYXJlIGFsbG9jYXRlZCBmb3IgYWxsIHRoZSBw b3RlbnRpYWwgdXNlcy4NCj4+DQo+PiAgICAgVG9tDQo+Pg0KPj4gICAgID4NCj4+ICAgICA+IEcv DQo+PiAgICAgPg0KPj4gICAgID4gT24gMDcvMTEvMjAxNywgMTc6NTgsICJUb20gSGVyYmVydCIg PHRvbUBoZXJiZXJ0bGFuZC5jb20+IHdyb3RlOg0KPj4gICAgID4NCj4+ICAgICA+ICAgICBPbiBU dWUsIE5vdiA3LCAyMDE3IGF0IDc6MjYgQU0sIFZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAt DQo+PiAgICAgPiAgICAgQkUvQW50d2VycCkgPGd1bnRlci52YW5fZGVfdmVsZGVAbm9raWEuY29t PiB3cm90ZToNCj4+ICAgICA+ICAgICA+IEEgdHJhbnNpdCByb3V0ZXIgZG9lcyBub3QgbG9vayBh dCBFSHMgaWYgaXQgaXMgbm90IGNvbmZpZ3VyZWQgZm9yIHRoZSBJUHY2IERlc3RpbmF0aW9uIGFk ZHJlc3MuLiBzbyBpdHMgbm90IHVzYWJsZSBpbiB0aGF0IGNhc2UuDQo+PiAgICAgPiAgICAgPg0K Pj4gICAgID4gICAgIFRoZXkgZG8gbG9vayBhdCBob3AtYnktaG9wIG9wdGlvbnMuIFByZXZpb3Vz bHkgaXQgd2FzIHJlcXVpcmVkIHRoYXQNCj4+ICAgICA+ICAgICBhbGwgbm9kZXMgaW4gdGhlIHBh dGggbXVzdCBwcm9jZXNzIHRoZW0sIGJ1dCB0aGF0IHdhcyByZWxheGVkIGEgYml0IGluDQo+PiAg ICAgPiAgICAgUkZDODIwMC4gSWYgdGhleSBhcmUgb25seSB1c2VkIGZvciB0dW5uZWxpbmcgYWNy b3NzIGEgY29udHJvbGxlZA0KPj4gICAgID4gICAgIGRvbWFpbiB0aGVuIHRoZSB0eXBpY2FsIGNv bmNlcm4gdGhhdCBpbnRlcm1lZGlhdGUgbm9kZXMgZG9uJ3QgcHJvcGVybHkNCj4+ICAgICA+ICAg ICBoYW5kbGUgaG9wLWJ5LWhvcCBvcHRpb25zIGNhbiBiZSBhZGRyZXNzZWQuDQo+PiAgICAgPg0K Pj4gICAgID4gICAgIFRvbQ0KPj4gICAgID4NCj4+ICAgICA+ICAgICA+IEcvDQo+PiAgICAgPiAg ICAgPg0KPj4gICAgID4gICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ICAgICA+ ICAgICA+IEZyb206IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbV0NCj4+ ICAgICA+ICAgICA+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDcsIDIwMTcgMTY6MTYNCj4+ICAg ICA+ICAgICA+IFRvOiBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8 Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+DQo+PiAgICAgPiAgICAgPiBDYzogdjZvcHNA aWV0Zi5vcmcNCj4+ICAgICA+ICAgICA+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEZXOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZpb2Njb2xhLXNwcmluZy1mbG93LWxhYmVsLWFs dC1tYXJrLTAxLnR4dA0KPj4gICAgID4gICAgID4NCj4+ICAgICA+ICAgICA+IE9uIE1vbiwgTm92 IDYsIDIwMTcgYXQgMTA6NDQgUE0sIFZhbiBEZSBWZWxkZSwgR3VudGVyIChOb2tpYSAtDQo+PiAg ICAgPiAgICAgPiBCRS9BbnR3ZXJwKSA8Z3VudGVyLnZhbl9kZV92ZWxkZUBub2tpYS5jb20+IHdy b3RlOg0KPj4gICAgID4gICAgID4+IEhpIFRvbSwNCj4+ICAgICA+ICAgICA+Pg0KPj4gICAgID4g ICAgID4+IC0tPg0KPj4gICAgID4gICAgID4+IEZyb20gc2VjdGlvbiAxOg0KPj4gICAgID4gICAg ID4+DQo+PiAgICAgPiAgICAgPj4gIkJhc2VkIG9uIHRoZXNlIGNvbnNpZGVyYXRpb25zLCBpdCBp cyBhbGxvd2VkIHRvIHVzZSB0aGUgZmxvdyBsYWJlbCBmaWVsZCBpbiBhIG1hbmFnZWQgZG9tYWlu LCBhc3N1bWluZyB3aGVuIGEgcGFja2V0IGxlYXZlcyB0aGUgZG9tYWluLCB0aGUgb3JpZ2luYWwg ZmxvdyBsYWJlbCB2YWx1ZSBNVVNUIGJlIHJlc3RvcmVkLiINCj4+ICAgICA+ICAgICA+Pg0KPj4g ICAgID4gICAgID4+IEluIHRoaXMgcHJvcG9zYWwsIGlmIHR3byBiaXRzIGFyZSBvdmVyd3JpdHRl biBieSBhbiBpbnRlcm1lZGlhdGUgbm9kZSwgaG93IGFyZSB0aGVpciBvcmlnaW5hbCB2YWx1ZXMg cmVzdG9yZWQgd2hlbiBsZWF2aW5nIHRoZSBkb21haW4/DQo+PiAgICAgPiAgICAgPj4gLS0+DQo+ PiAgICAgPiAgICAgPj4NCj4+ICAgICA+ICAgICA+PiBHVj4gIEJlY2F1c2UgdGhlIGZpZWxkIHRo YXQgYXJlIGJlaW5nIGZpZGRsZWQgd2l0aCBhcmUgb24gdGhlIElQdjYgU1J2NiBvdXRlciBlbmNh cHN1bGF0aW9uIGhlYWRlci4gV2hlbiB0aGUgb3JpZ2luYWwgcGFja2V0IGxlYXZlcyB0aGUgY29u dHJvbGxlZCBkb21haW4sIHRoZW4gdGhhdCBoZWFkZXIgaXMgcmVtb3ZlZCBhZ2FpbiwgYW5kIHRo ZSBvcmlnaW5hbCBJUHY2IHBhY2tldCB3aXRoIG9yaWdpbmFsIGhlYWRlcnMgYXBwZWFyIGFnYWlu Lg0KPj4gICAgID4gICAgID4+DQo+PiAgICAgPiAgICAgPiBHdW50ZXIsDQo+PiAgICAgPiAgICAg Pg0KPj4gICAgID4gICAgID4gSWYgdGhlIG1lYXN1cmVtZW50cyBhcmUgYWx3YXlzIGNvaW5jaWRl bnQgd2l0aCB0aGUgdXNlIG9mIFNSdjYgdGhlbiB3aHkgbm90IHB1dCB0aGUgbWVhc3VyZW1lbnQg aW5mb3JtYXRpb24gaW4gdGhlIFNSIEVIIG9yIHNvbWUgb3RoZXIgRUggKGhvcC1ieS1ob3Agb3Ig ZXN0IG9wdCBtYXliZSkgdXNlZCBvbmx5IGluIHRoZSBjb250cm9sbGVkIGRvbWFpbj8gVGhpcyBh bHNvIGNvdWxkIGJlIG1vcmUgZmxleGlibGUgc2luY2UgdGhlIGFsZ29yaXRobSB3b3VsZG4ndCBi ZSBjb25zdHJhaW5lZCB0byBqdXN0IHR3byBiaXRzIG9mIGRhdGEuDQo+PiAgICAgPiAgICAgPg0K Pj4gICAgID4gICAgID4gVG9tDQo+PiAgICAgPg0KPj4gICAgID4NCj4+DQo+Pg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5n IGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Tue Nov 14 23:59:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859591292FC for ; Tue, 14 Nov 2017 23:59: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, 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=algebras-org.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 i4GgFzrHj_KF for ; Tue, 14 Nov 2017 23:59:13 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 3F12C129553 for ; Tue, 14 Nov 2017 23:59:13 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id s28so9653105uag.4 for ; Tue, 14 Nov 2017 23:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CoVnvVU0kGFMMsSX/DgBhsepM40JHTAdu4e0TDSSyM0=; b=ZYrfbzVYZHSjqRkck+vJsls9MYXSs/4k4yF1yxYZ9b4i5E8tQB/7PNqXfJ5lG687E9 nvap0xEf4Ch1MtB0UE6aEVwHQbPlW9J++cWGaoz5wG+JlP3ibi+LaU6YrfdtjsQ5PhfF Ymzq6GWhygN3q7go8k82QTNRVdnnlFB35cQuLh+bbU952iwrbgx7lM3BmCfz1PtqAJKN ZIXuxj2wxV+uyttV6FyjrpcvdsZtLLDuGiNHJxm7ZAtv2ek1dYjhmKq3+QRv7wWf7uBr 1dAUaLtLWSq2dn6/DmsJ1MlpaaiL/qtDW4qko1J+U8JG0Eh9yiql4mduLO2oAaxu8/gi MbiQ== 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=CoVnvVU0kGFMMsSX/DgBhsepM40JHTAdu4e0TDSSyM0=; b=HS8EDxS1RkwDIQ4VZbMxSrQOvYNlRfhYzwS4lNtKK+3AGW/gqV7fblQgh/e9wmDi7O SlpcVoxQGZpkp/pac/pU+ZuhM85il1YLfRaIBxhxHCmsNzPquU60ZKvZhK/XCFNDphUv /cuLxvSYY9X0SuAgwB5kLou6RrB89RF+aKARZWtlJ9T6s/nnyQ8oZzUueLsVTrCNj+14 BF+kKvU+IpyzcKKYMuUm/EGHDls60J9wGyWvNsU59UZM4YiN96B0Lv4id1j8nPs/5Ptg HTn827+sMd0mjNH2QmjPANm8z4qQcicB5gtw8ZbmruWHPrdPkruMLOs/CiajRnQ4gUby 1oPQ== X-Gm-Message-State: AJaThX7hgzH7+qiODbo7CHSX+YX4oKSLqYYOu1U5qoyCKPYNfhacoRBK Bm0Payb7zdbn9VbK0D88Pb9Kx+/tRtpofFLNeuvyitw3 X-Google-Smtp-Source: AGs4zMbcV9Ajgb3O041a1Nei+BDBO8hQkpGgnzrdxjewuXibvVA+VUdu77fJuKwVOtg8Ar8S6mCV/15CNfCdX8mUMJQ= X-Received: by 10.159.52.25 with SMTP id q25mr13572858uab.94.1510732752082; Tue, 14 Nov 2017 23:59:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.91.2 with HTTP; Tue, 14 Nov 2017 23:59:11 -0800 (PST) X-Originating-IP: [2001:67c:1232:144:d066:3e10:8038:51fb] In-Reply-To: <2A34A2BA-83D8-4CBB-B11F-8FFCFC5373F1@consulintel.es> References: <150937816403.7793.11085386578208067817.idtracker@ietfa.amsl.com> <1049A23A-BC67-43B3-B158-1366A92926CD@consulintel.es> <2A34A2BA-83D8-4CBB-B11F-8FFCFC5373F1@consulintel.es> From: George Michaelson Date: Wed, 15 Nov 2017 15:59:11 +0800 Message-ID: To: JORDI PALET MARTINEZ Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 07:59:15 -0000 so you reply in the positive, about encap. I think yes, we agree. But what I don't think you've captured, is that a 'network' has a mix of L3 and L2 active and passive parts. if the L2 fabric is prepared to forward broadcast frames with ARP, and/or DHCP, and if two stations cooperate either using this, or hand-installed mapping of IP to MAC, then the network cannot be called IPv6 only, even if the network administrator says so: Its functionally passing IPv4 first class. To me, an IPv6 only network is one which does *not* forward frames which encode IPv4 protocol objects directly. Indirect (encapsulated) IPv4 is different, and it can still be IPv6 only, if these flow. Carrier networks, mobile networks, which can elect not to forward IPv4 PDUs inside the carrier system first class, can be IPv6 only. A managed switch, which does some kind of frame content check and drops V4 on entry on a port, can be IPv6 only, A PPP link which refuses V4 PPP encoded packets can be IPv6 only. An unmanged switch, or any broadcast medium which is willing to let edge stations assert IPv4, even without the network managers engagement, is not IPv6 only. And, calling it IPv6 only invites the inverse of the rogue-RA problem: Anyone can stand up a DHCP server, proffer default route and DNS services, and capture packets from your clients without you. -G On Wed, Nov 15, 2017 at 3:41 PM, JORDI PALET MARTINEZ wrote: > Hi George, > > I think we mostly agree =E2=80=A6 may be the way I=E2=80=99m saying it in= the document is not the best =E2=80=A6 but this is my thinking on this. > > If we have an IPv6-only access link, even if there is no any =E2=80=9Cfil= tering=E2=80=9D that avoids IPv4 traffic, because the ISP side will not for= ward it, even if the user CE sends IPv4 traffic natively, will not =E2=80= =9Cwork=E2=80=9D. If that traffic is encapsulated or translated via IPv6, t= hen is still =E2=80=9Cfrom the perspective=E2=80=9D of the network operator= , an IPv6-only access link. > > Regards, > Jordi > > > -----Mensaje original----- > De: George Michaelson > Responder a: > Fecha: lunes, 13 de noviembre de 2017, 15:19 > Para: JORDI PALET MARTINEZ > CC: "" > Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-o= nly-03.txt > > If there is a functional barrier to any PDU which is IPv4 directly > encoded, being forwarded: If there is a barrier to other non-IP > packets such as ARP being forwarded, then in that sense, the link > layer cannot and does not forward IPv4 and its an IPv6 only network. > > If the administrative decision has been made not to proffer ARP > responses, DHCP, or any other mechanism to bootstrap IPv4 but no > barrier is placed on its use, then I can stand up an IPv4 endpoint, > and hand-configure it to talk to another on the layer 2 fabric and it > works. I don't consider this to be an IPv6 only network, because bad > actors can send functional IPv4 between themselves. If you forward > broadcast packet types its even easier. > > If I tunnel IPv4 over IPv6 PDUs then its still an IPv6 only network. > Encapsulation is not the same as raw forwarding. > > > -G > > On Mon, Oct 30, 2017 at 11:44 PM, JORDI PALET MARTINEZ > wrote: > > Hi all, > > > > I just posted a new version for this document. > > > > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > > > > Comments welcome! > > > > Regards, > > Jordi > > > > > > > > -----Mensaje original----- > > De: > > Responder a: > > Fecha: lunes, 30 de octubre de 2017, 16:42 > > Para: Jordi Palet Martinez , Jordi = Martinez > > Asunto: New Version Notification for draft-palet-v6ops-ipv6-only-03= .txt > > > > > > A new version of I-D, draft-palet-v6ops-ipv6-only-03.txt > > has been successfully submitted by Jordi Palet Martinez and pos= ted to the > > IETF repository. > > > > Name: draft-palet-v6ops-ipv6-only > > Revision: 03 > > Title: IPv6-only Terminology Definition > > Document date: 2017-10-30 > > Group: Individual Submission > > Pages: 5 > > URL: https://www.ietf.org/internet-drafts/draft-pale= t-v6ops-ipv6-only-03.txt > > Status: https://datatracker.ietf.org/doc/draft-palet-v6= ops-ipv6-only/ > > Htmlized: https://tools.ietf.org/html/draft-palet-v6ops-i= pv6-only-03 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-pal= et-v6ops-ipv6-only-03 > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-palet= -v6ops-ipv6-only-03 > > > > Abstract: > > This document defines the terminology regarding the usage of > > expressions such as "IPv6-only", in order to avoid confusion= s when > > using them in IETF and other documents, in reference to what= is the > > actual functionalities being used (not the actual protocol s= upport). > > > > > > > > > > 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 > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privilege= d or confidential. The information is intended to be for the exclusive use = of the individual(s) named above and further non-explicilty authorized disc= losure, copying, distribution or use of the contents of this information, e= ven if partially, including attached files, is strictly prohibited and will= be considered a criminal offense. If you are not the intended recipient be= aware that any disclosure, copying, distribution or use of the contents of= this information, even if partially, including attached files, is strictly= prohibited, will be considered a criminal offense, so you must reply to th= e original sender to inform about this communication and delete it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Nov 15 00:31:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E726A126C0F for ; Wed, 15 Nov 2017 00:31: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, 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 rSIVwti5IKEx for ; Wed, 15 Nov 2017 00:31:24 -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 68FDD128B44 for ; Wed, 15 Nov 2017 00:31:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510734680; x=1511339480; 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=c8AmySiZnINPjlybGQtWe1KeH q9lzwMqnuJ7hQNEj4U=; b=aWy8ISai+Pa6X0SqQHkUIh6N2ZYite/JfIpmg6Bj6 ainK0aYsT94bt83JXurImIGXSxEPc1ft3IFPD0rtNj1XGSB3XbzbSEp8pSW8lCWc 6S5saQDIgLaAuIhf/smORf/kuPGwwVXfvhNi8d+Tc6wxB6X1H6HR9yYDX7ZfPEyE 0s= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=ovM8czDFOkDrqaFcEhnigxMQFc9xvNpge6CYhSBdO3JT8YbWBlffimDrXVh3 XMj5ghOZFQmOGyYdOqrYZrtBvdLfn1VNcExlSl1FnZXbZPLnn3MUTvY7w Zat9+OCD0qKYMC6PU0FQVMMMBaRFRavLcpgYgisHMazfChFA0cMDz8=; X-MDAV-Processed: mail.consulintel.es, Wed, 15 Nov 2017 09:31:18 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 15 Nov 2017 09:31:17 +0100 Received: from [31.133.140.255] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005624273.msg for ; Wed, 15 Nov 2017 09:31:16 +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:md50005624273::LtwpHOPdD+hJas6E:00005Q3H X-Return-Path: prvs=1492ded23e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Wed, 15 Nov 2017 16:31:00 +0800 From: JORDI PALET MARTINEZ To: "" Message-ID: Thread-Topic: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-03.txt References: <150937816403.7793.11085386578208067817.idtracker@ietfa.amsl.com> <1049A23A-BC67-43B3-B158-1366A92926CD@consulintel.es> <2A34A2BA-83D8-4CBB-B11F-8FFCFC5373F1@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-ipv6-only-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 08:31:26 -0000 so you reply in the positive, about encap. I think yes, we agree. =20 But what I don't think you've captured, is that a 'network' has a mix of L3 and L2 active and passive parts. if the L2 fabric is prepared to forward broadcast frames with ARP, and/or DHCP, and if two stations cooperate either using this, or hand-installed mapping of IP to MAC, then the network cannot be called IPv6 only, even if the network administrator says so: Its functionally passing IPv4 first class. [Jordi] I see that case mainly for the definition of an IPv6-only LAN. In t= he case of a WAN, even if the customer CE is sending IPv4 ARP/DHCP (even if= by mistake), the operator side, will ignore that, and from the perspective= of the terminology definition I=E2=80=99m trying to do, that=E2=80=99s wha= t matters to an operator for a given network (or network part): I=E2=80=99m= using or speaking or responding to IPv4 packets even in L2? If not, from t= he =E2=80=9Cusage perspective=E2=80=9D of the that network(part) is IPv6-on= ly. =20 To me, an IPv6 only network is one which does *not* forward frames which encode IPv4 protocol objects directly. Indirect (encapsulated) IPv4 is different, and it can still be IPv6 only, if these flow. =20 Carrier networks, mobile networks, which can elect not to forward IPv4 PDUs inside the carrier system first class, can be IPv6 only. =20 A managed switch, which does some kind of frame content check and drops V4 on entry on a port, can be IPv6 only, =20 A PPP link which refuses V4 PPP encoded packets can be IPv6 only. =20 An unmanged switch, or any broadcast medium which is willing to let edge stations assert IPv4, even without the network managers engagement, is not IPv6 only. And, calling it IPv6 only invites the inverse of the rogue-RA problem: Anyone can stand up a DHCP server, proffer default route and DNS services, and capture packets from your clients without you. [Jordi] I see the point, I think what I need to fix here in the terminology= , if that=E2=80=99s a problem or not for other hosts, in the case of a broa= dcast medium. =20 -G =20 On Wed, Nov 15, 2017 at 3:41 PM, JORDI PALET MARTINEZ wrote: > Hi George, > > I think we mostly agree =E2=80=A6 may be the way I=E2=80=99m saying i= t in the document is not the best =E2=80=A6 but this is my thinking on this= . > > If we have an IPv6-only access link, even if there is no any =E2=80= =9Cfiltering=E2=80=9D that avoids IPv4 traffic, because the ISP side will n= ot forward it, even if the user CE sends IPv4 traffic natively, will not = =E2=80=9Cwork=E2=80=9D. If that traffic is encapsulated or translated via I= Pv6, then is still =E2=80=9Cfrom the perspective=E2=80=9D of the network op= erator, an IPv6-only access link. > > Regards, > Jordi > > > -----Mensaje original----- > De: George Michaelson > Responder a: > Fecha: lunes, 13 de noviembre de 2017, 15:19 > Para: JORDI PALET MARTINEZ > CC: "" > Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-ip= v6-only-03.txt > > If there is a functional barrier to any PDU which is IPv4 directl= y > encoded, being forwarded: If there is a barrier to other non-IP > packets such as ARP being forwarded, then in that sense, the link > layer cannot and does not forward IPv4 and its an IPv6 only netwo= rk. > > If the administrative decision has been made not to proffer ARP > responses, DHCP, or any other mechanism to bootstrap IPv4 but no > barrier is placed on its use, then I can stand up an IPv4 endpoin= t, > and hand-configure it to talk to another on the layer 2 fabric an= d it > works. I don't consider this to be an IPv6 only network, because = bad > actors can send functional IPv4 between themselves. If you forwar= d > broadcast packet types its even easier. > > If I tunnel IPv4 over IPv6 PDUs then its still an IPv6 only netw= ork. > Encapsulation is not the same as raw forwarding. > > > -G > > On Mon, Oct 30, 2017 at 11:44 PM, JORDI PALET MARTINEZ > wrote: > > Hi all, > > > > I just posted a new version for this document. > > > > https://datatracker.ietf.org/doc/draft-palet-v6ops-ipv6-only/ > > > > Comments welcome! > > > > Regards, > > Jordi > > > > > > > > -----Mensaje original----- > > De: > > Responder a: > > Fecha: lunes, 30 de octubre de 2017, 16:42 > > Para: Jordi Palet Martinez , Jo= rdi Martinez > > Asunto: New Version Notification for draft-palet-v6ops-ipv6-onl= y-03.txt > > > > > > A new version of I-D, draft-palet-v6ops-ipv6-only-03.txt > > has been successfully submitted by Jordi Palet Martinez and= posted to the > > IETF repository. > > > > Name: draft-palet-v6ops-ipv6-only > > Revision: 03 > > Title: IPv6-only Terminology Definition > > Document date: 2017-10-30 > > Group: Individual Submission > > Pages: 5 > > URL: https://www.ietf.org/internet-drafts/draft-= palet-v6ops-ipv6-only-03.txt > > Status: https://datatracker.ietf.org/doc/draft-pale= t-v6ops-ipv6-only/ > > Htmlized: https://tools.ietf.org/html/draft-palet-v6o= ps-ipv6-only-03 > > Htmlized: https://datatracker.ietf.org/doc/html/draft= -palet-v6ops-ipv6-only-03 > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-p= alet-v6ops-ipv6-only-03 > > > > Abstract: > > This document defines the terminology regarding the usag= e of > > expressions such as "IPv6-only", in order to avoid confu= sions when > > using them in IETF and other documents, in reference to = what is the > > actual functionalities being used (not the actual protoc= ol support). > > > > > > > > > > Please note that it may take a couple of minutes from the t= ime of submission > > until the htmlized version and diff are available at tools.= ietf.org. > > > > The IETF Secretariat > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.consulintel.es > > The IPv6 Company > > > > This electronic message contains information which may be privi= leged or confidential. The information is intended to be for the exclusive = use of the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this informatio= n, even if partially, including attached files, is strictly prohibited and = will be considered a criminal offense. If you are not the intended recipien= t be aware that any disclosure, copying, distribution or use of the content= s of this information, even if partially, including attached files, is stri= ctly prohibited, will be considered a criminal offense, so you must reply t= o the original sender to inform about this communication and delete it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 18:19:39 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8396124F57 for ; Wed, 15 Nov 2017 18:19: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 fdYC2x-LXxSh for ; Wed, 15 Nov 2017 18:19:37 -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 3F672120227 for ; Wed, 15 Nov 2017 18:19:37 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id i15so8151808pfa.3 for ; Wed, 15 Nov 2017 18:19:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=PvCDMA9ow+61aBOxqJI/XErwURK66WJE+nowpeKsWXE=; b=hCjZZm1o2si+JloFhdy/7MeU7Jq5c0OSIGgEantkhGFpwU9K9DSmSjVVfIGSujQHbc u9NNrrDcbWrP5lcs5m6urB7+gFlcs+TWf0b9fZC0kygbtRIwl8UmcQfzDJ9a4nQHcbcs WvLuvP+f23/xGcPZ2iWFDPNDHZrCTLu/jYyJXuBmqQdNlO/0yABNy7L0Hd+c5xT2Lqwj 4odjhhTP1oPdh6QBtv5d0ADwag8A7g1+/Gii1E84KkEj/yF5wDi9MycLVlcfd4AhEjvt 3u8OMajEI8Gpm5JvHbFrS/GpRVSlLNcnD7MAYdhW6F+Z8V9jA9N66/1cWEKQEkZ/zb/c 3fkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=PvCDMA9ow+61aBOxqJI/XErwURK66WJE+nowpeKsWXE=; b=ifxzc3DmCuKsEfMJ4QTFMjJ+F+PW8QNoc6A2rMye4vKAZpQ2KpuoTxR/LmWX4OcdiW dBv2RucU0Q3BOAOn5W2ctNqn/CJzNhktWd+1+pMTbJSzXueSWpIQXw5B9qF8fCmEmLn1 CTa74sn5FB8TV5DW7I6Z1SwNuxGQJ/E9bkdOpGk+PTLiiMQjxXdBLI6C0zewrOuHPNmA RW/SpTIgcv9e4oY9p+1uDZi7apNZ4mT2qDuOzYQFcfYoEZUXKjXRjnkhMifOjf05Z2Hc X5vuhS8D8rag9XA7Fxb/wUjwRR3pYxifm04uVOZInPaOPxy9V5Khv5cVYaS6F11f1w71 cipA== X-Gm-Message-State: AJaThX4RLnS1SKfQpMgbijIG9WpmRNobLSS0S3ipj5KoBuIqGQaCEFFy gVlMPlJ4KBOty3tz6orCAsnbHYg0 X-Google-Smtp-Source: AGs4zMYo5BDW/h0nPDF+/kGNNhgi+Bh42MJulSY0Qqp8VrDqJZSeSbVg0Bonme2JZLdgB6Hi8CBRjg== X-Received: by 10.99.96.147 with SMTP id u141mr129142pgb.342.1510798776526; Wed, 15 Nov 2017 18:19:36 -0800 (PST) Received: from ?IPv6:2001:67c:370:1998:f9f5:d1e6:f963:45ba? ([2001:67c:370:1998:f9f5:d1e6:f963:45ba]) by smtp.gmail.com with ESMTPSA id 68sm30132pfk.162.2017.11.15.18.19.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 18:19:35 -0800 (PST) From: Fred Baker Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Thu, 16 Nov 2017 10:19:33 +0800 Message-Id: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> To: v6ops@ietf.org X-Mailer: iPhone Mail (15B150) Archived-At: Subject: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:19:39 -0000 At IETF 100, we discussed this document. The =E2=80=9Chum=E2=80=9D regarding= adoption was slightly in favor, but not clear. However, we had one comment t= hat IF it were adopted, it needs to be expanded to be an architectural docum= ent describing /64-to-the-host deployments. Shall we adopt it as a working group draft? Sent using a machine that autocorrects in interesting ways...= From nobody Wed Nov 15 18:30:41 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7DC126CC4 for ; Wed, 15 Nov 2017 18:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwM7RSYn2zz2 for ; Wed, 15 Nov 2017 18:30:37 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0137.outbound.protection.outlook.com [104.47.1.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A402B120227 for ; Wed, 15 Nov 2017 18:30: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=Sxz+HR7xqpy88t4uPqcc5WXeHRZHHUseQXtvdNdjOp4=; b=DwT8cOtUDIFp/BncWhBgHNWSBBPqRafWPAVJk/0+SRIzvi4sZqCunLY40PCJoOHKzz4T8XGAsDTanjkibJXgJzxa7HFRViNjPmJxEld2z8Qm7DPYCJFuOgTiUFRyzYkxa2mRCeTvtnDLY6hVVInIDWjg3tUuaf3tKY7aE95pbVU= 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; Thu, 16 Nov 2017 02:30: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.005; Thu, 16 Nov 2017 02:30:34 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AQHTXoFfbBaTujqFZECShuBca1gGBKMWRivQ Date: Thu, 16 Nov 2017 02:30:34 +0000 Message-ID: References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> In-Reply-To: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:128:11e0:2e42:1b70:a487] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2833; 6:9Bls8nXvxAlX+zg/HftAAM0hl1U00a5DQlFen6+PP8uSV9LDAbLfLyGMQzEKxLuOptfYUIz3RzF/QZjQ8pToKtUjXbdxIKlp7mIph+y7V+xhzzSKSyy2CYnAI76AON51d99U3Q0beUDTTHZR+muwOKv/YEaPdWcYN7SCUmFLtO31ZJsct2v+LN0XYuH1+iXIv8B2ruzEK9uoD4ag+h5oS5ejckC2kzpdj/lFjbRxPtu9YdndoaXxH/WrsnckeHngivcaNbMenn8HOC2j6S2vkmj9qFJeKc+lqEj+oURO68+Udv+l7qOUkzrFm8b23rjq0HO6fbWNCXsJWiloHfxoJZu4K6g++V7qx5AiM2otrSg=; 5:EHQISyCwd8weclOLewaCemjm+rhzbGvv5C7XzlLY95Xd8Kh/W2WtYUyDEj6Ns/QLXmiI4k8PnyXbkrHmIjcITrb6fI7au3nQ+rHdI5RYDnT1zwWxsAPOHdFKF0/n3OGT8bHvzAfRczfDNxkHw8glgDtDm/xg9LGRIT7Ycw4dQHA=; 24:boX38DD5H/y89CGJWs1LGP7y+oLGxWj95cdZZn8KYPzCA05mdeeFDmSUPKZhf5D5pScOkkgbt5HTKABZbHBDNQ39XJSVxFW+UrEk0AcbOos=; 7:sgEBmZQfzrMZG5HeQIQCtdXQDKQxTQViwUKGaN4LofrPCquQy7hHxt9i1wEaTCrcR1jHWjxZi2mzBvV9WQ6xrTQK2IYGNcT91bhUD15wCrmg48IzbDDE931sKvVxbOMRVc/zfSd+zlD0on6aK0WeWGd19sVUSmG1bJQmPIQR/0A3PeKlLHMZFSmI2EP8evikbQU4P1GsF0JyoxwUv68fqEMYxWwZGiGkki8c/OVVqJtsZdt9oLFdpEJVthAJLDSO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9c9167da-e03f-4943-086a-08d52c9a03d3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:AM5PR0701MB2833; x-ms-traffictypediagnostic: AM5PR0701MB2833: 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:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3231022)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(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: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(346002)(376002)(13464003)(51444003)(199003)(189002)(3280700002)(6246003)(53936002)(97736004)(81156014)(3660700001)(9686003)(5250100002)(55016002)(6306002)(81166006)(53546010)(6116002)(102836003)(6436002)(68736007)(6506006)(86362001)(229853002)(14454004)(2950100002)(8676002)(7736002)(110136005)(74316002)(7696004)(50986999)(305945005)(105586002)(2906002)(2900100001)(106356001)(230783001)(189998001)(316002)(966005)(2501003)(478600001)(99286004)(76176999)(101416001)(25786009)(39060400002)(33656002)(54356999)(5660300001)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2833; 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9c9167da-e03f-4943-086a-08d52c9a03d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 02:30:34.2290 (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: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:30:39 -0000 RG9lcyB0aGlzIG1lYW4gdGhhdCB0aGUgZG9jdW1lbnQgZGVzaXJlcyB0byBpbmNsdWRlIGFsbCB0 aGUgZHluYW1pY3Mgb2YgYWRkcmVzcyBhc3NpZ25tZW50IHN1YnNjcmliZXIgbWFuYWdlbWVudCB3 aGVuIFBEIGlzIHVzZWQ/IChpLmUuIHN1YnNjcmliZXIgdnMgYWRkcmVzcyBjb3JyZWxhdGlvbiBz dGF0ZSwgaWRlbnRpZmljYXRpb24gb2YgdGhlIHN1YnNjcmliZXIvaG9zdCwgZXRjLi4uKT8NCg0K SWYgdGhhdCBpcyBhIHllcywgdGhlbiB0aGlzIGlzIHNvbWV0aGluZyBJIHRoaW5rIHRoYXQgdGhp cyBlYXNpbHkgd2lsbCByZXN1bHQgaW4gYSB0b28gd2lkZSBzY29wZSBhbmQgYm9pbGluZyB0aGUg b2NlYW4uIEkgdGhpbmsgYmVmb3JlIGRlY2lkaW5nIHRvIGFkb3B0IG9yIG5vdCwgaXQgd291bGQg YmUgZ3JlYXQgdG8gdW5kZXJzdGFuZCB0aGUgZXhhY3Qgc2NvcGUgaW50ZW5kZWQuIChJIGtub3cg Zm9yIGEgZmFjdCB0aGF0IGNvbmZpZ3VyYXRpb24gZ3VpZGUgb2YgdmVuZG9ycyByZWdhcmRpbmcg c3Vic2NyaWJlciBtYW5hZ2VtZW50IHRlbmQgdG8gYmUgaHVnZSBhbmQgbGVuZ3RoeSAoKzEwMDAg cGFnZXMpIGRvY3VtZW50cykuIEkgd2FudCB0byBtYWtlIHN1cmUgdGhhdCB2Nm9wcyBwcm9ncmVz c2VzIHdpdGggYSBwcmFnbWF0aWMgZG9jdW1lbnQgb2YgdmFsdWUgdG8gb3BlcmF0b3JzIGFuZCBu b3QgYSBwdXJlIGFjYWRlbWljIGV4ZXJjaXNlLg0KDQpHLw0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgRnJlZCBCYWtlcg0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE2LCAyMDE3IDEw OjIwDQpUbzogdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFt2Nm9wc10gZHJhZnQtdGVtcGxpbi12 Nm9wcy1wZGhvc3QgYSB3b3JraW5nIGdyb3VwIGRyYWZ0Pw0KDQpBdCBJRVRGIDEwMCwgd2UgZGlz Y3Vzc2VkIHRoaXMgZG9jdW1lbnQuIFRoZSDigJxodW3igJ0gcmVnYXJkaW5nIGFkb3B0aW9uIHdh cyBzbGlnaHRseSBpbiBmYXZvciwgYnV0IG5vdCBjbGVhci4gSG93ZXZlciwgd2UgaGFkIG9uZSBj b21tZW50IHRoYXQgSUYgaXQgd2VyZSBhZG9wdGVkLCBpdCBuZWVkcyB0byBiZSBleHBhbmRlZCB0 byBiZSBhbiBhcmNoaXRlY3R1cmFsIGRvY3VtZW50IGRlc2NyaWJpbmcgLzY0LXRvLXRoZS1ob3N0 IGRlcGxveW1lbnRzLg0KDQpTaGFsbCB3ZSBhZG9wdCBpdCBhcyBhIHdvcmtpbmcgZ3JvdXAgZHJh ZnQ/DQoNClNlbnQgdXNpbmcgYSBtYWNoaW5lIHRoYXQgYXV0b2NvcnJlY3RzIGluIGludGVyZXN0 aW5nIHdheXMuLi4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Wed Nov 15 18:33:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC066129407 for ; Wed, 15 Nov 2017 18:33: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 Y72mQomc29n4 for ; Wed, 15 Nov 2017 18:33:46 -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 03C1D120227 for ; Wed, 15 Nov 2017 18:33:46 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id r62so5911891pfd.5 for ; Wed, 15 Nov 2017 18:33:45 -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=3fp321DqngRI0SkyW/zgq4RTi008BGwUpBiyHpfRVuQ=; b=lY6hNxiHCdBw3fRFW0FCRB2nOKFsYay7bnnCrBideRIyFUB8F0hEix2RETdrICiiAV ftHx3ma28GhzXmmlB/f6QJL2VToPI6IT4ib87bq27+bHasbwokigEcUmO+WY+luSZgfp zmhu3qHvUpwbRHsDp3bqbRAoMIH8YJNvVBehcTq6ZHyy9m5EgqkbMxda+ylY4ummAPCF CgMIsTMFn+XHXv7t2CxaeBlyT4BkuW24q+pEwTp2Ke531YejD2yl+W0naDSihoRJbFpC 122k2yrQTelG20U1VVqQ1qlay3OgleYT9PmGTdUNS2Yr9gkq1ukVsRbktsCPArfGpHMi lezw== 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=3fp321DqngRI0SkyW/zgq4RTi008BGwUpBiyHpfRVuQ=; b=RxAI9YnEKNc1Q2qCCCK5TcUYdfDbJWoZcrzXv9osNK25d00hEXJYV7ch5LbGEaJa3G u9iHQX2SIp2dN5pVtQYA6v4oCMYWeEXJcCYqtSLq4rfrCjfYWDHZNmQP+UF/ODtP9yY4 MLzjoa0y6iiIdh4bxbGtvg1xad0hDKWxUduBCo3/018ejLYtgGFuCjP39JixjNmT9FpT rF5Qk2SukNUn0chizbPBEqMIab/eodPjuNJ2+EFhjdHZ8qaW03tWxXAcK6yqGIMuriGJ FcrsAuBHknvUVzuLM+W4DXaGZyzeXi2l2T7qarPL5yoriD6hbZn0MsTprKUkHyh0iwuD gq1w== X-Gm-Message-State: AJaThX51Nyz6E+KGT8g+5Fxjyw9OOh/84zzIYu6YkypKt2U1Th+dg7mu X0wEjdYf3DwrGweGZZ6GnzQqwg== X-Google-Smtp-Source: AGs4zMZ2CTc8TrA2UPdON/yp7251ujh2n6JtLlmByZnpIUbwxbnx7MrsMmDvpnFdbaTA7k6IePn+ww== X-Received: by 10.101.92.202 with SMTP id b10mr174792pgt.164.1510799625444; Wed, 15 Nov 2017 18:33:45 -0800 (PST) Received: from ?IPv6:2001:67c:370:1998:47e:aeb1:c844:b165? ([2001:67c:370:1998:47e:aeb1:c844:b165]) by smtp.gmail.com with ESMTPSA id i11sm84406pfk.25.2017.11.15.18.33.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 18:33:45 -0800 (PST) From: Alexandre Petrescu X-Google-Original-From: Alexandre Petrescu To: v6ops@ietf.org References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> Message-ID: <2b8346d7-5822-7ecc-9520-cd8d85f38e57@gmail.com> Date: Thu, 16 Nov 2017 03:33: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: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:33:48 -0000 I support, under the condition that a few problems are fixed at various providers. This is not a problem at operator. With this draft most things happen in the end-user device; the operator may provide DHCPv6 service that could be tested; if the first condition is met (see first line of this message) then it's a success. Also, if this runs on VPN then there is really no problem to deploy it, and it seems some running code is there already. Alex Le 16/11/2017 à 03:19, Fred Baker a écrit : > At IETF 100, we discussed this document. The “hum” regarding adoption was slightly in favor, but not clear. However, we had one comment that IF it were adopted, it needs to be expanded to be an architectural document describing /64-to-the-host deployments. > > Shall we adopt it as a working group draft? > > Sent using a machine that autocorrects in interesting ways... > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Wed Nov 15 21:13:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C4B129470 for ; Wed, 15 Nov 2017 21:13: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] 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 hVszZzi85Au4 for ; Wed, 15 Nov 2017 21:12:59 -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 840011286B1 for ; Wed, 15 Nov 2017 21:12:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510809176; x=1511413976; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=tJ79j7VDkmG0c7fahidCHTzpRo3oRZiR8xQNFIfYlKY=; b=kcATeorUFiGCy /UTaCLsJc4rj669elR3BQeIh/q23RmBXf1qxfcpR0vHsoxu0KRvH3PUltlFifQ9z GP9BCrGBqfdQAbjHkW0GcrMwsoUj+fVHm2nmc8bVWImkA9dVo3Bz3ugOfGHHe2qf FwksPLuAb8e/X/dbHZkZU7C4vxvLJM= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=K7euCu02q5YahiMQFIKF1G42MsuVzMOBe3cuMMfjN5etDJoIiIF8GfHs3Ty7 R924/LX1yLREG0MLt95qEWoHfsDhBRZ4WtmKgg68ehlwdiYrzjXPvpua5 PTd6SKLgJRjZRiBlVD92Cb4XcrmebFeURVti/U0Lse4kHNozXSZSI4=; X-MDAV-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:12:56 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:12:56 +0100 Received: from [172.20.60.6] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005625225.msg for ; Thu, 16 Nov 2017 06:12:54 +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:171116:md50005625225::T7EiaJKcZlQnSp03:00002G2o X-Return-Path: prvs=1493446864=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Thu, 16 Nov 2017 13:12:41 +0800 From: JORDI PALET MARTINEZ To: Message-ID: <1DD923D6-32AB-4017-86A7-9FDD1F03BB8A@consulintel.es> Thread-Topic: next steps for draft-palet-v6ops-464xlat-deployment Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] next steps for draft-palet-v6ops-464xlat-deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:13:01 -0000 Hi, Before continuing with this work, I will like to make sure that the path I = understood in the WG meeting is the one we want. Instead of concentrating in 464XLAT, document how we can correctly deploy N= AT64 with/without DNS64 in such way that we don=E2=80=99t break DNSSEC. 464= XLAT is one possible scenario, but NAT64 alone as well. Is that the correct take on this? I think we can use most of the text of the current document, will see =E2= =80=A6 Anyone interested in co-authoring it? I will try to have a new version around end of this month, especially if a = possible co-author is pro-active enough ;-) Regards, Jordi =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Nov 15 21:26:13 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16D31201F2 for ; Wed, 15 Nov 2017 21:26: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] 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 NLdvNiZ7ingH for ; Wed, 15 Nov 2017 21:26:10 -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 60CDE1294DF for ; Wed, 15 Nov 2017 21:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510809967; x=1511414767; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=GcbJ2591z56YdyCRHwcJfJhA8Xa4MgBlxlz/YIFJI0Q=; b=kMaO0WVBkzZ0j DK97rB+FKmD3yoUJ3potjBGxXA3XjojbcmFbgi9EZfJiHi4ps0fWfUlze3H7hZo9 Gk2jgkAy+h978c8fo47KWQ8itdct3PRtaep42+7OFNfQs8WgnQKFqae3iYPVVZ/f rGAv0N2YSltQW/J5pUkijMUMMAMAKE= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=VWJVF5w6uMLMGL66pz8LieIglg0kboflLQWQrnL6j2cc+88NHsKth17EwMO2 U9vE09RAHD1psiWYaWIdgaVOqzeVl8psmdxX9daC+swJl5ysFbBEPCMYD TfrYe1QZoHdX78SrZHlq8BLOq+53VSBV5ZvG/buzh5nDZGsTtPJY4k=; X-MDAV-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:26:06 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:26:03 +0100 Received: from [172.20.60.6] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005625240.msg for ; Thu, 16 Nov 2017 06:26:03 +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:171116:md50005625240::/CulAqK5JfUDj/R4:00000dDz X-Return-Path: prvs=1493446864=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Thu, 16 Nov 2017 13:25:49 +0800 From: JORDI PALET MARTINEZ To: Message-ID: <97062078-9947-416C-9449-22F4F6FDEB97@consulintel.es> Thread-Topic: draft-palet-v6ops-rfc7084-bis-transition Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] draft-palet-v6ops-rfc7084-bis-transition X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:26:12 -0000 Same question for this document. I will continue working on it, Hans Liu from D-Link, agreed to co-author it= . Some of the points to consider: 1) Don=E2=80=99t repeat text from RFC7084, just reference to it (IPv6 on to= p of IPv4 transition part basically) 2) Make sure to state that this is needed in order to support, temporarily,= IPv4 devices in user LANs 3) Clarify possible scenarios for choosing one or the other mechanism 4) Clarify what is needed for the provisioning to =E2=80=9Cchoose=E2=80=9D = one or the other if the CE supports several and requirements to make sure t= hat the =E2=80=9Cchoosen=E2=80=9D one actually works (which is basically th= e way RFC7084 text is doing) I=E2=80=99m missing or misunderstanding anything? Regards, Jordi =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Nov 15 21:34:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE93A129470 for ; Wed, 15 Nov 2017 21:34: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] 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 bAaoqHC7unbh for ; Wed, 15 Nov 2017 21:34:37 -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 379D0127ABE for ; Wed, 15 Nov 2017 21:34:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510810475; x=1511415275; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=duYZEa3dOkVeqVkj0p/miTPeFJ6QbSZJ2330LRTUmCs=; b=j5hQFY30n7+NP CctjLG0o1dyqX/EwYkZcZYYMe9r+yY8pUd0jJLOBKIstEEDo25C904nGAhPDgTEB mjj4Ajkc0MRdRNyLSy8MVHraipaa8nZqsYVKTBAM0Yg18PH8asbCDtEkCQqWvE4Q OuH4+MWd6OENki5giSsBje/vAk2bTk= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=kF+lYN5k6oGwToi53YaHJOjdP+fltQKtbScBg0Q11BLF+nespT4o0YObedGi mZjoQ78kYLOUazjSKFHPHg3LU1XUymZvcNl534wTQyzAsCjXlx0pULAzP jrOHiupyOI6G1XrdXA90dk2rOuu2S3a0FzZ5U/Qv9sNQu23BXPykJI=; X-MDAV-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:34:35 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:34:34 +0100 Received: from [172.20.60.6] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005625279.msg for ; Thu, 16 Nov 2017 06:34:33 +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:171116:md50005625279::oKqxBYhWqVjOg+Ma:0000BMai X-Return-Path: prvs=1493446864=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Thu, 16 Nov 2017 13:34:24 +0800 From: JORDI PALET MARTINEZ To: Message-ID: <3546393F-6BDB-4E22-BC7D-60F114C0783E@consulintel.es> Thread-Topic: next steps with draft-palet-v6ops-p2p-from-customer-prefix Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:34:39 -0000 Again, regarding this document, my understanding is that the WG will prefer instead of documenting just this way of doing point-2-point links, the several options available, pros and cons and how. Is that correct? Anyone volunteering to co-author it? I think I will be able to have a new version around end of this month. Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From nobody Wed Nov 15 21:35:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE08129438 for ; Wed, 15 Nov 2017 21:35:12 -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 hCVgwjeoOQAq for ; Wed, 15 Nov 2017 21:35:10 -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 92ACE127ABE for ; Wed, 15 Nov 2017 21:35:10 -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 vAG5ZAPj019576; Wed, 15 Nov 2017 22:35:10 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vAG5Z4Ix019203 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 15 Nov 2017 22:35:04 -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, 15 Nov 2017 21:35:04 -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, 15 Nov 2017 21:35:04 -0800 From: "Templin, Fred L" To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AQHTXoFfbBaTujqFZECShuBca1gGBKMWRivQgAA01FA= Date: Thu, 16 Nov 2017 05:35:04 +0000 Message-ID: References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:35:13 -0000 SGkgR3VudGVyLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3Bz IFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZhbiBEZSBWZWxk ZSwgR3VudGVyIChOb2tpYSAtIEJFL0FudHdlcnApDQo+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1i ZXIgMTUsIDIwMTcgNjozMSBQTQ0KPiBUbzogRnJlZCBCYWtlciA8ZnJlZGJha2VyLmlldGZAZ21h aWwuY29tPjsgdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtdGVt cGxpbi12Nm9wcy1wZGhvc3QgYSB3b3JraW5nIGdyb3VwIGRyYWZ0Pw0KPiANCj4gRG9lcyB0aGlz IG1lYW4gdGhhdCB0aGUgZG9jdW1lbnQgZGVzaXJlcyB0byBpbmNsdWRlIGFsbCB0aGUgZHluYW1p Y3Mgb2YgYWRkcmVzcyBhc3NpZ25tZW50IHN1YnNjcmliZXIgbWFuYWdlbWVudCB3aGVuIFBEIGlz DQo+IHVzZWQ/IChpLmUuIHN1YnNjcmliZXIgdnMgYWRkcmVzcyBjb3JyZWxhdGlvbiBzdGF0ZSwg aWRlbnRpZmljYXRpb24gb2YgdGhlIHN1YnNjcmliZXIvaG9zdCwgZXRjLi4uKT8NCg0KVGhpcyBk cmFmdCBpcyBhYm91dCB3aGF0IGEgaG9zdCBjYW4gZG8gaW50ZXJuYWxseSB3aGVuIGl0IGdldHMg YSBwcmVmaXggZGVsZWdhdGlvbg0KdGhyb3VnaCB3aGF0ZXZlciBtZWFucy4gSXQgbGlzdHMgREhD UHY2IFBEIGFzIGFuIGV4YW1wbGUgUEQgc2VydmljZSwgYnV0IGRvZXMNCm5vdCBpbXBvc2UgYW55 IHNwZWNpYWwgcmVxdWlyZW1lbnRzIG9uIHRoZSBkZWxlZ2F0aW5nIHJvdXRlciBpbiB0aGUgb3Bl cmF0b3Incw0KbmV0d29yay4gVGhlIGhvc3QgaXMgcmVxdWlyZWQgdG8gcGFydGljaXBhdGUgaW4g dGhlIGNsaWVudC1zaWRlIHByZWZpeCBkZWxlZ2F0aW9uDQpjb250cm9sIG1lc3NhZ2luZyBzcGVj aWZpZWQgYnkgdGhlIHByZWZpeCBkZWxlZ2F0aW9uIHNlcnZpY2UsIGhvd2V2ZXIuDQoNClRoYW5r cyAtIEZyZWQNCg0KPiBJZiB0aGF0IGlzIGEgeWVzLCB0aGVuIHRoaXMgaXMgc29tZXRoaW5nIEkg dGhpbmsgdGhhdCB0aGlzIGVhc2lseSB3aWxsIHJlc3VsdCBpbiBhIHRvbyB3aWRlIHNjb3BlIGFu ZCBib2lsaW5nIHRoZSBvY2Vhbi4gSSB0aGluayBiZWZvcmUgZGVjaWRpbmcNCj4gdG8gYWRvcHQg b3Igbm90LCBpdCB3b3VsZCBiZSBncmVhdCB0byB1bmRlcnN0YW5kIHRoZSBleGFjdCBzY29wZSBp bnRlbmRlZC4gKEkga25vdyBmb3IgYSBmYWN0IHRoYXQgY29uZmlndXJhdGlvbiBndWlkZSBvZiB2 ZW5kb3JzDQo+IHJlZ2FyZGluZyBzdWJzY3JpYmVyIG1hbmFnZW1lbnQgdGVuZCB0byBiZSBodWdl IGFuZCBsZW5ndGh5ICgrMTAwMCBwYWdlcykgZG9jdW1lbnRzKS4gSSB3YW50IHRvIG1ha2Ugc3Vy ZSB0aGF0IHY2b3BzIHByb2dyZXNzZXMNCj4gd2l0aCBhIHByYWdtYXRpYyBkb2N1bWVudCBvZiB2 YWx1ZSB0byBvcGVyYXRvcnMgYW5kIG5vdCBhIHB1cmUgYWNhZGVtaWMgZXhlcmNpc2UuDQo+IA0K PiBHLw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdjZvcHMgW21h aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRnJlZCBCYWtlcg0KPiBT ZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTYsIDIwMTcgMTA6MjANCj4gVG86IHY2b3BzQGlldGYu b3JnDQo+IFN1YmplY3Q6IFt2Nm9wc10gZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QgYSB3b3Jr aW5nIGdyb3VwIGRyYWZ0Pw0KPiANCj4gQXQgSUVURiAxMDAsIHdlIGRpc2N1c3NlZCB0aGlzIGRv Y3VtZW50LiBUaGUg4oCcaHVt4oCdIHJlZ2FyZGluZyBhZG9wdGlvbiB3YXMgc2xpZ2h0bHkgaW4g ZmF2b3IsIGJ1dCBub3QgY2xlYXIuIEhvd2V2ZXIsIHdlIGhhZCBvbmUNCj4gY29tbWVudCB0aGF0 IElGIGl0IHdlcmUgYWRvcHRlZCwgaXQgbmVlZHMgdG8gYmUgZXhwYW5kZWQgdG8gYmUgYW4gYXJj aGl0ZWN0dXJhbCBkb2N1bWVudCBkZXNjcmliaW5nIC82NC10by10aGUtaG9zdCBkZXBsb3ltZW50 cy4NCj4gDQo+IFNoYWxsIHdlIGFkb3B0IGl0IGFzIGEgd29ya2luZyBncm91cCBkcmFmdD8NCj4g DQo+IFNlbnQgdXNpbmcgYSBtYWNoaW5lIHRoYXQgYXV0b2NvcnJlY3RzIGluIGludGVyZXN0aW5n IHdheXMuLi4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3Bz QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMN Cg== From nobody Wed Nov 15 21:39:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0CE127058 for ; Wed, 15 Nov 2017 21:39:03 -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 XqP73FZjG5vB for ; Wed, 15 Nov 2017 21:38:59 -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 B208212421A for ; Wed, 15 Nov 2017 21:38:59 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id n79so4048809ion.3 for ; Wed, 15 Nov 2017 21:38: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=eRYSM0b4idE4Q6PzNHXXZHtu2Y3PgIg8DHm+JAFMC6Y=; b=pLpA5fDRs83YsEUHdBbx0KqelXraMBNKgeTYDJIlg1Smc2IcoE95GiPzs5sYZitu0I 2sb9z2Hs1OrU8Mp20+PIHCuDAxarVd0mpfV29UKU7SeY8VkdF+KrMzuQGlkz+rB2K1h/ fgmN42molTq+bSE+psQtH7qk9ajFyo6Q4A2LeH1PASTdhLJmtzRpwjgl8ctQSmbQiVTO D0fBer1RIEKvoQOzFME9MLlpnMrNc8CKCvRVvzh1kOUGIoEbdf615n7Gh+/ycmhCQ7EL KQ3czGvHPjDD6Ad4IIbK/0Cg1RHoRVHcDL9mNUpnjXzF8YeIm56AQKqNSLxAXhBHsbqo xUOA== 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=eRYSM0b4idE4Q6PzNHXXZHtu2Y3PgIg8DHm+JAFMC6Y=; b=OgyALTvBkWItJmkn4EgBnn7ztB7MqxdSoIbSD/lJT3HGlM3Z00esyeymI5EqQwuE2k OyDhUFiI6tEdKGhg6pkD7N/ehWIcyyNQn1MJ3/vE9XdgpxXW2gRaGppw0iuhP7o8e5zq VyrZl5GxnlbZE1Owh3YWPNMWftsyZmPyejQPvUmmu7MrKzA43R2wTTg0hns7Pclz8LpS IE1pNt9LjuJZJ1qVEaXisuNY/z2mpbZmiVy33cHiLJZUac0Dgs2QCPAMsi5Eco7GBC/K uOirtu7jrFCBADO2jhnAP8OyNYu1kZjwqyMPSDn/kyzZO+1zTDQguUZE8Y0g+Z7aIGju xBcw== X-Gm-Message-State: AJaThX5J9guWQoyDaYBKi4t+ctv3sDqUOmbL4W3yEl3abQTxmlsmvDdx ZvEcDPNFfGNFxwn5dXCiVTBlOAnh76Khc5qu4wbuHXXd X-Google-Smtp-Source: AGs4zMbr/1gcEE2L1EDmPKGLfKr1ilxlyUH6JLp/Z/z9Czwj0xAvwzGQBTB8SZLIGopuCfwPGMDH5Nr7hq7nqRNLeX0= X-Received: by 10.107.174.206 with SMTP id n75mr475935ioo.43.1510810738537; Wed, 15 Nov 2017 21:38:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.9.141 with HTTP; Wed, 15 Nov 2017 21:38:37 -0800 (PST) In-Reply-To: <3546393F-6BDB-4E22-BC7D-60F114C0783E@consulintel.es> References: <3546393F-6BDB-4E22-BC7D-60F114C0783E@consulintel.es> From: Lorenzo Colitti Date: Thu, 16 Nov 2017 13:38:37 +0800 Message-ID: To: Jordi Palet Martinez Cc: "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a11445e9e653ea6055e130964" Archived-At: Subject: Re: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:39:03 -0000 --001a11445e9e653ea6055e130964 Content-Type: text/plain; charset="UTF-8" One difference between "this way" and the other ways is that at this point, the other ways are well-understood, but as far as I can tell, this way is undefined and undocumented. On Thu, Nov 16, 2017 at 1:34 PM, JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > Again, regarding this document, my understanding is that the WG will > prefer instead of documenting just this way of doing point-2-point links, > the several options available, pros and cons and how. > > Is that correct? > > Anyone volunteering to co-author it? > > I think I will be able to have a new version around end of this month. > > Regards, > Jordi > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a11445e9e653ea6055e130964 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One difference between "this way" and the other = ways is that at this point, the other ways are well-understood, but as far = as I can tell, this way is undefined and undocumented.

On Thu, Nov 16, 2017 at 1:34 PM,= JORDI PALET MARTINEZ <jordi.palet@consulintel.es> = wrote:
Again, regarding this document, my= understanding is that the WG will prefer instead of documenting just this = way of doing point-2-point links, the several options available, pros and c= ons and how.

Is that correct?

Anyone volunteering to co-author it?

I think I will be able to have a new version around end of this month.

Regards,
Jordi




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

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



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

--001a11445e9e653ea6055e130964-- From nobody Wed Nov 15 21:41:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D960B12741D for ; Wed, 15 Nov 2017 21:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYXCuUuyEokM for ; Wed, 15 Nov 2017 21:41:16 -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 DBED2126C2F for ; Wed, 15 Nov 2017 21:41:15 -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 vAG5fFQO019509; Wed, 15 Nov 2017 22:41:15 -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 vAG5fA7G019392 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 15 Nov 2017 22:41:10 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 21:41:09 -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, 15 Nov 2017 21:41:09 -0800 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AQHTXoNcbBaTujqFZECShuBca1gGBKMWfEzA Date: Thu, 16 Nov 2017 05:41:09 +0000 Message-ID: <1d91eecd524a42768cf7483e2f6bf1ff@XCH15-06-08.nw.nos.boeing.com> References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <2b8346d7-5822-7ecc-9520-cd8d85f38e57@gmail.com> In-Reply-To: <2b8346d7-5822-7ecc-9520-cd8d85f38e57@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:41:18 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyBb bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUgUGV0 cmVzY3UNCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyA2OjM0IFBNDQo+IFRv OiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC10ZW1wbGluLXY2 b3BzLXBkaG9zdCBhIHdvcmtpbmcgZ3JvdXAgZHJhZnQ/DQo+IA0KPiBJIHN1cHBvcnQsIHVuZGVy IHRoZSBjb25kaXRpb24gdGhhdCBhIGZldyBwcm9ibGVtcyBhcmUgZml4ZWQgYXQgdmFyaW91cw0K PiBwcm92aWRlcnMuDQo+IA0KPiBUaGlzIGlzIG5vdCBhIHByb2JsZW0gYXQgb3BlcmF0b3IuICBX aXRoIHRoaXMgZHJhZnQgbW9zdCB0aGluZ3MgaGFwcGVuDQo+IGluIHRoZSBlbmQtdXNlciBkZXZp Y2U7IHRoZSBvcGVyYXRvciBtYXkgcHJvdmlkZSBESENQdjYgc2VydmljZSB0aGF0DQo+IGNvdWxk IGJlIHRlc3RlZDsgaWYgdGhlIGZpcnN0IGNvbmRpdGlvbiBpcyBtZXQgKHNlZSBmaXJzdCBsaW5l IG9mIHRoaXMNCj4gbWVzc2FnZSkgdGhlbiBpdCdzIGEgc3VjY2Vzcy4NCg0KWWVzLCB0aGF0IGlz IHJpZ2h0LiBQRC1jYXBhYmxlIERIQ1B2NiBzZXJ2ZXJzIGhhdmUgYmVlbiBhdmFpbGFibGUgZm9y IGENCmxvbmcgdGltZSBhbmQgdGhlIG9uZXMgSSBoYXZlIHRlc3RlZCB3b3JrIGdyZWF0LiBCdXQs IGFzIHlvdSBzYXksIHRoaXMNCmRvY3VtZW50IGNvbmNlcm5zIHdoYXQgYSBob3N0IGRvZXMgd2l0 aCBhIGRlbGVnYXRlZCBwcmVmaXggb25jZSBpdA0KcmVjZWl2ZXMgb25lIGFuZCBub3Qgc28gbXVj aCBhYm91dCB0aGUgcHJlZml4IGRlbGVnYXRpb24gc2VydmljZSBpdHNlbGYuDQoNCj4gQWxzbywg aWYgdGhpcyBydW5zIG9uIFZQTiB0aGVuIHRoZXJlIGlzIHJlYWxseSBubyBwcm9ibGVtIHRvIGRl cGxveSBpdCwNCj4gYW5kIGl0IHNlZW1zIHNvbWUgcnVubmluZyBjb2RlIGlzIHRoZXJlIGFscmVh ZHkuDQoNClllcywgSSBoYXZlIGJlZW4gZG9pbmcgREhDUHY2IFBEIG92ZXIgVlBOIG9uIEFuZHJv aWQgZm9yIGEgbG9uZyB0aW1lLg0KVGhlIERIQ1B2NiBzZXJ2ZXIgcm9idXN0bHkgcHJvdmlkZXMg dGhlIHByZWZpeCBhbmQgc2V0cyB1cCB0aGUgcm91dGluZywNCmFuZCB0aGUgQW5kcm9pZCB1c2Vz IGl0IGZvciBtdWx0aS1hZGRyZXNzaW5nIG9uIHRoZSBWUE4gaW50ZXJmYWNlIGFjY29yZGluZw0K dG8gdGhlIHN0cm9uZyBlbmQgc3lzdGVtIChzdHJvbmcgaG9zdCkgbW9kZWwgcGVyIHRoaXMgZG9j dW1lbnQuDQoNClRoYW5rcyAtIEZyZWQNCg0KPiBBbGV4DQo+IA0KPiBMZSAxNi8xMS8yMDE3IMOg IDAzOjE5LCBGcmVkIEJha2VyIGEgw6ljcml0wqA6DQo+ID4gQXQgSUVURiAxMDAsIHdlIGRpc2N1 c3NlZCB0aGlzIGRvY3VtZW50LiBUaGUg4oCcaHVt4oCdIHJlZ2FyZGluZyBhZG9wdGlvbiB3YXMg c2xpZ2h0bHkgaW4gZmF2b3IsIGJ1dCBub3QgY2xlYXIuIEhvd2V2ZXIsIHdlIGhhZCBvbmUNCj4g Y29tbWVudCB0aGF0IElGIGl0IHdlcmUgYWRvcHRlZCwgaXQgbmVlZHMgdG8gYmUgZXhwYW5kZWQg dG8gYmUgYW4gYXJjaGl0ZWN0dXJhbCBkb2N1bWVudCBkZXNjcmliaW5nIC82NC10by10aGUtaG9z dCBkZXBsb3ltZW50cy4NCj4gPg0KPiA+IFNoYWxsIHdlIGFkb3B0IGl0IGFzIGEgd29ya2luZyBn cm91cCBkcmFmdD8NCj4gPg0KPiA+IFNlbnQgdXNpbmcgYSBtYWNoaW5lIHRoYXQgYXV0b2NvcnJl Y3RzIGluIGludGVyZXN0aW5nIHdheXMuLi4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+IHY2b3Bz QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Wed Nov 15 21:47:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027EE1294F4 for ; Wed, 15 Nov 2017 21:47: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] 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 ERKwjiv9-5Gh for ; Wed, 15 Nov 2017 21:47:48 -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 2A0061294EC for ; Wed, 15 Nov 2017 21:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510811266; x=1511416066; 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=4jWxx2E/+ukFtuUA99hBbyVHM 3uHeCaOtRDx07j07y8=; b=NNx7EKpCyf/mLeVVa5bfjhZnvnq7WD1czybwdMy8V lLRAhod45s+z9XOHe7RYz/hJC7dMpOweWKXPYMJfGp6ok/y8jEjHGno20hmApxL5 U56mvB0q6y/Ot2UBbm5wCtZYulLgrG8d8uJDO0BZXm1VRBKV0R/iqGD3fv63TfOZ DA= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=DrQVF20pjQwolirsWlPywngaZ2kA4a29AFRdbTaFN0KU29ES9YDqcbpH2XC7 jxDTJz9xONoWXBpz/IFbYF4im5sPeShRjFmY9wmuUJpQBndWgSGJ+LsX1 E6P22oxL5cKsvqnV4QiLZGONWC3dosV5kkMhXae/66zJdcIOpdX3eY=; X-MDAV-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:47:46 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:47:45 +0100 Received: from [172.20.60.6] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005625286.msg for ; Thu, 16 Nov 2017 06:47:44 +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:171116:md50005625286::c3rVFKLIX42YZV86:00000YDW X-Return-Path: prvs=1493446864=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Thu, 16 Nov 2017 13:47:30 +0800 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org WG" Message-ID: <93CDC8C3-E75E-4C9C-8845-C582EF68D68D@consulintel.es> Thread-Topic: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-prefix References: <3546393F-6BDB-4E22-BC7D-60F114C0783E@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:47:50 -0000 Exactly, and that=E2=80=99s was my rational for doing this document ;-) As explained in my actual document, RFC6603 provides a DHCPv6 option to all= ow a router to =E2=80=9Cnot-use=E2=80=9D that /64 in the LANs. Then RFC7084= include RFC6603 as a requirement. Also, RFC7849 requires using RFC6603 =E2= =80=A6 So, it is something required by several documents, but not never explicitly= described. Regards, Jordi =20 -----Mensaje original----- De: Lorenzo Colitti Responder a: Fecha: jueves, 16 de noviembre de 2017, 13:39 Para: Jordi Palet Martinez CC: "v6ops@ietf.org WG" Asunto: Re: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-pre= fix One difference between "this way" and the other ways is that at this po= int, the other ways are well-understood, but as far as I can tell, this way= is undefined and undocumented. =20 On Thu, Nov 16, 2017 at 1:34 PM, JORDI PALET MARTINEZ wrote: =20 Again, regarding this document, my understanding is that the WG will pr= efer instead of documenting just this way of doing point-2-point links, the= several options available, pros and cons and how. =20 Is that correct? =20 Anyone volunteering to co-author it? =20 I think I will be able to have a new version around end of this month. =20 Regards, Jordi =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Nov 15 21:50:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D756C1294EC for ; Wed, 15 Nov 2017 21:50: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] 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 VJuag7VTeTaH for ; Wed, 15 Nov 2017 21:50: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 83EAF127058 for ; Wed, 15 Nov 2017 21:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510811423; x=1511416223; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=tzpIn3XuNP/vA4ugfSRdz3tYAxdOr4Q4c8s+CT44e2c=; b=oeSDAh8M2yAhU /os43QncTSJKcYNrPBsrPPLUFrXoRBDsxis95hVLqPqYpDOLhxJFrfkn6Cp/HlIP P7QzDcp4P4zPgzQyfUcAyKpj+7daGrlFLs0C2mZMDQBGnAT5A7BHZAJ79O+J/oMb z01N/Z+AdbokWREgK7B+N/hZLRLKTg= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=R+mWBmy9PSX2MX5MEDQpHQpIc28O7rqym325TY+DeQm60z4xZJkhGfqbRih0 cpKuOSVK/q4KmnT8G/rgc4AEHaHQZS+VluVOU1h16LBjLPkLP+i8X0UjA jcR9ij6dbxPYXnAFWDb5bkKrWvMesi2kj1EkygTE8jytEHObTCMhj0=; X-MDAV-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:50:23 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:50:21 +0100 Received: from [172.20.60.6] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005625287.msg for ; Thu, 16 Nov 2017 06:50: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:171116:md50005625287::Aa4N+kJoVnhR3/lr:000021Jr X-Return-Path: prvs=1493446864=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Thu, 16 Nov 2017 13:50:16 +0800 From: JORDI PALET MARTINEZ To: Message-ID: <3ACE94D4-80D4-43FC-8C2A-120FFE038FE2@consulintel.es> Thread-Topic: regarding draft-palet-v6ops-ipv6-only Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] regarding draft-palet-v6ops-ipv6-only X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:50:30 -0000 >From what I got in the presentation, and also what has been discussed also = in 6man, I think it is clear that the fact that there is so much people arg= uing about this, demonstrates that there is a misunderstanding with termino= logy and we better fix it, so people is not messing around in each differen= t document with a different understanding. I=E2=80=99ve seen other WGs that have, as part of the charter or one of the= initial documents, a specific one for that. So, I still believe we need this. I will work on a new version, and will be nice if somebody want to co-autho= r it. May be tackle it from a different angle will help. Regards, Jordi =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Nov 15 21:56:08 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CE6129515 for ; Wed, 15 Nov 2017 21:56:06 -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 f_SWhqC_Tbb8 for ; Wed, 15 Nov 2017 21:56:05 -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 23CE61294F4 for ; Wed, 15 Nov 2017 21:56:05 -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 vAG5u4KC036132; Wed, 15 Nov 2017 22:56:04 -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 vAG5ttRW036081 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 15 Nov 2017 22:55:55 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 21:55:54 -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, 15 Nov 2017 21:55:54 -0800 From: "Templin, Fred L" To: Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AQHTXoFjbBaTujqFZECShuBca1gGBKMWf4dg Date: Thu, 16 Nov 2017 05:55:54 +0000 Message-ID: <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> In-Reply-To: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:56:07 -0000 SGkgRnJlZCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyBb bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGcmVkIEJha2VyDQo+ IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDIwMTcgNjoyMCBQTQ0KPiBUbzogdjZvcHNA aWV0Zi5vcmcNCj4gU3ViamVjdDogW3Y2b3BzXSBkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdCBh IHdvcmtpbmcgZ3JvdXAgZHJhZnQ/DQo+IA0KPiBBdCBJRVRGIDEwMCwgd2UgZGlzY3Vzc2VkIHRo aXMgZG9jdW1lbnQuIFRoZSDigJxodW3igJ0gcmVnYXJkaW5nIGFkb3B0aW9uIHdhcyBzbGlnaHRs eSBpbiBmYXZvciwgYnV0IG5vdCBjbGVhci4gSG93ZXZlciwgd2UgaGFkIG9uZQ0KPiBjb21tZW50 IHRoYXQgSUYgaXQgd2VyZSBhZG9wdGVkLCBpdCBuZWVkcyB0byBiZSBleHBhbmRlZCB0byBiZSBh biBhcmNoaXRlY3R1cmFsIGRvY3VtZW50IGRlc2NyaWJpbmcgLzY0LXRvLXRoZS1ob3N0IGRlcGxv eW1lbnRzLg0KDQpUaGUgd2F5IEkgdW5kZXJzdG9vZCB0aGUgY29tbWVudCB3YXMgdGhhdCB0aGUg ZHJhZnQgbmVlZHMgbW9yZSBzdXBwb3J0aW5nDQp0ZXh0IG9uIHRoZSByYXRpb25hbGUgZm9yIGRv aW5nIHdoYXQgdGhlIGRvY3VtZW50IGRlc2NyaWJlcyAoZS5nLiwgdGhlIGJlbmVmaXQNCmZvciBu b3QgaGF2aW5nIHRvIHBsYWNlIHRoZSB1cHN0cmVhbSBpbnRlcmZhY2UgaW4gcHJvbWlzY3VvdXMg bW9kZSwgZWZmaWNpZW5jaWVzDQpmb3Igbm90IGRvaW5nIGxpbmstc2NvcGVkIG11bHRpY2FzdGlu ZyBvdmVyIHRoZSB1cHN0cmVhbSBpbnRlcmZhY2UsIGF2b2lkaW5nDQpkaXN0dXJiYW5jZSBvZiBv dGhlciBub2RlcyBvbiB0aGUgdXBzdHJlYW0gbGluaywgZXRjLg0KDQpJIGRpZCBub3QgdGhpbmsg dGhlIGNvbW1lbnQgd2FzIGFza2luZyB0byBleHBhbmQgdGhlIGRvY3VtZW50IHRvIGNvdmVyIGFs bA0KbWV0aG9kcyBvZiBjb252ZXlpbmcgYSAvNjQgdG8gdGhlIGhvc3QgKGUuZy4sIHVuaXF1ZS1p cHY2LXByZWZpeC1wZXItaG9zdCwNCjNHUFAsIGV0Yy4pLiBUaGlzIGRvY3VtZW50IG9ubHkgY29u Y2VybnMgbWV0aG9kcyB0aGF0IG1lZXQgdGhlIGRlc2NyaXB0aW9uDQpvZiBwcmVmaXggZGVsZWdh dGlvbiBhcyBkZXNjcmliZWQgZm9yIGV4YW1wbGVzIHN1Y2ggYXMgREhDUHY2IFBELg0KDQpUaGFu a3MgLSBGcmVkDQoNCj4gU2hhbGwgd2UgYWRvcHQgaXQgYXMgYSB3b3JraW5nIGdyb3VwIGRyYWZ0 Pw0KPiANCj4gU2VudCB1c2luZyBhIG1hY2hpbmUgdGhhdCBhdXRvY29ycmVjdHMgaW4gaW50ZXJl c3Rpbmcgd2F5cy4uLg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Wed Nov 15 21:58:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141F91294DB for ; Wed, 15 Nov 2017 21:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQydNAQQX0NA for ; Wed, 15 Nov 2017 21:58:39 -0800 (PST) Received: from atl4mhob07.registeredsite.com (atl4mhob07.registeredsite.com [209.17.115.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71A2129510 for ; Wed, 15 Nov 2017 21:58:39 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob07.registeredsite.com (8.14.4/8.14.4) with ESMTP id vAG5wZ2a004893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Nov 2017 00:58:35 -0500 Received: (qmail 6838 invoked by uid 0); 16 Nov 2017 05:58:35 -0000 X-TCPREMOTEIP: 31.133.128.134 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?31.133.128.134?) (lee@asgard.org@31.133.128.134) by 0 with ESMTPA; 16 Nov 2017 05:58:34 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Thu, 16 Nov 2017 13:58:24 +0800 From: Lee Howard To: Lorenzo Colitti , Jordi Palet Martinez CC: "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-prefix References: <3546393F-6BDB-4E22-BC7D-60F114C0783E@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3593685511_12459349" Archived-At: Subject: Re: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:58:45 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3593685511_12459349 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable From: v6ops on behalf of Lorenzo Colitti Date: Thursday, November 16, 2017 at 1:38 PM To: Jordi Palet Martinez Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-prefix > One difference between "this way" and the other ways is that at this poin= t, > the other ways are well-understood, but as far as I can tell, this way is > undefined and undocumented. Is that an objection or a statement of support? The path from =E2=80=9Cundocument= ed=E2=80=9D to =E2=80=9Cdocumented=E2=80=9D is a document. v6ops is specifically chartered to document IPv6 operational experience. Sounds relevant. Lee >=20 > On Thu, Nov 16, 2017 at 1:34 PM, JORDI PALET MARTINEZ > wrote: >> Again, regarding this document, my understanding is that the WG will pre= fer >> instead of documenting just this way of doing point-2-point links, the >> several options available, pros and cons and how. >>=20 >> Is that correct? >>=20 >> Anyone volunteering to co-author it? >>=20 >> I think I will be able to have a new version around end of this month. >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >>=20 >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >>=20 >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the exclusive use of= the >> individual(s) named above and further non-explicilty authorized disclosu= re, >> copying, distribution or use of the contents of this information, even i= f >> 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 thi= s >> information, even if partially, including attached files, is strictly >> prohibited, will be considered a criminal offense, so you must reply to = the >> original sender to inform about this communication and delete it. >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops --B_3593685511_12459349 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable


From: v6ops <v6ops-bounces@ietf.org> on behalf of Lorenzo Colitti <= lorenzo@google.com>
Date: Thursday, November 16, 2017 at 1:38 PMTo: Jordi Palet Martinez <jordi.palet@consulintel.es>
<= span style=3D"font-weight:bold">Cc: "v= 6ops@ietf.org WG" <v6ops@ietf.org= >
Subject: Re: [v6ops] next ste= ps with draft-palet-v6ops-p2p-from-customer-prefix

<= blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4= df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
One difference = between "this way" and the other ways is that at this point, the other ways = are well-understood, but as far as I can tell, this way is undefined and und= ocumented.

Is that an objection= or a statement of support? The path from “undocumented” to R= 20;documented” is a document.

v6ops is specif= ically chartered to document IPv6 operational experience. Sounds relevant.

Lee



On Thu, Nov 16, 2017 at 1:34 PM,= JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
Again, regarding this document, my understanding= is that the WG will prefer instead of documenting just this way of doing po= int-2-point links, the several options available, pros and cons and how.
=
Is that correct?

Anyone volunteering to co-author it?

I think I will be able to have a new version around end of this month.
<= br> Regards,
Jordi




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

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the in= dividual(s) named above and further non-explicilty authorized disclosure, co= pying, distribution or use of the contents of this information, even if part= ially, including attached files, is strictly prohibited and will be consider= ed a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it.



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

_______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/= mailman/listinfo/v6ops
--B_3593685511_12459349-- From nobody Wed Nov 15 21:59:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEDA129511 for ; Wed, 15 Nov 2017 21:59: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] 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 HetvDcTniSG0 for ; Wed, 15 Nov 2017 21:59:06 -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 E36231294D8 for ; Wed, 15 Nov 2017 21:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510811942; x=1511416742; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: Mime-version:Content-type:Content-transfer-encoding:Reply-To; bh=J4ppccxlJKnfHmbO+KO5Sn6OEK7HG8UNGBsUUq2Xo/A=; b=UAzZ9982kzomz NdGY+XF/C1NyL1noaq5xh7MmN+oVPkrwWD8eMbGT4LywUhdvnDaW4erENtzfVK1S Wd9vr2QiNacFK4qVKQHBC31Lj+AlD+jsub82FDHp+gbK7wC4o2F/YnCvou4Dekv3 byc2FDyd/PuizOfoqOlqSgmOVERfpg= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=FnOEy260DjTGWKmJctBKRpORoFI1l4bWlOgaDT0Ufky5bLbQIyAcTjAMMvVZ wZ25aib+mqV5LHPtinTNO1vTt4XThWELWUSjwJJsTQSKvYN6Fapxx16rW +WMIZn0S4w6bugVq/5YVJJUcCiUnfBBcU9Aonm0L7VssNT7zT+cxqA=; X-MDAV-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:59:02 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 16 Nov 2017 06:59:01 +0100 Received: from [172.20.60.6] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005625291.msg for ; Thu, 16 Nov 2017 06:59:01 +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:171116:md50005625291::feL8KaXlc1tU7vv1:00006tal X-Return-Path: prvs=1493446864=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Thu, 16 Nov 2017 13:58:45 +0800 From: JORDI PALET MARTINEZ To: Message-ID: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> Thread-Topic: draft-palet-v6ops-he-reporting-00 Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:59:08 -0000 And last one =E2=80=A6 I=E2=80=99ve already talked with Carlos, the co-auth= or, in order to work on the path forward and how to make sure that security= /privacy are correctly taken into account in the document. Also, I think we got the clear message that the reporting should be done wi= th both IPv6 and IPv4 (as fallback by means of happy eyeballs). Does anyone have a suggestion about how to =E2=80=9Csecure=E2=80=9D syslog,= or an alternative way for doing the reporting? Anything else that we are missing in the document so we can improve it? Regards, Jordi =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Nov 15 22:00:33 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156B21294DB for ; Wed, 15 Nov 2017 22:00:31 -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 1wXvHQkivmyi for ; Wed, 15 Nov 2017 22:00:28 -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 B6C2F12741D for ; Wed, 15 Nov 2017 22:00:28 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id x28so4553749ita.0 for ; Wed, 15 Nov 2017 22:00: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=jsoJjyO92zkWCPw72hxkxA9XtveucLsUuEBwIQVzpIo=; b=R9SFa4fzUKSH33FN+crz8yxO3nR1dXIvSzYGeOBnd6ankToMG9M3P/Oyr+6L2FIfr7 udUQkkZoAsAYg6Lw6ItA4UZ4PsfKZioQPIZ2XdDKJ1rezHqndeI2cC83+GU4VzGkLJBu /ddzKSOESb3d/zWdSoLkHzNwYnHuvUqcXPtfMEPB5NiKjnh4JpLo4+V8dJ23aDayf75c Xi6R1ytSfJkj530JJjKDcLX1RAQMKctFHxqH+39HB7gZ5IMay5XprhIyhKqwkIanpvKf NHZD4SIIWEVhbXY8rSyPCobqi8Wjc+EDybqBV4JKKLQw74HS6iHDE3F1ejMahDhki1xp SOHg== 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=jsoJjyO92zkWCPw72hxkxA9XtveucLsUuEBwIQVzpIo=; b=SrnAVIQWuqgq5juBiYS5XJBn0sAXgS14o3qIdJzo9KN7+155BKQFDhwa+X+SskzNfF R41n/0Q8+YS1D2O7TZbn7kCgXoxehEnqlYhDp8O4ryXCT1uY90aRgM5s4chdevSQ9LdH OyDVOxUP0UpxU//OpjjkKLQeCaozwokWy47iBV8Az91/gLMtTv8GW/uBpj9iRhTD0aAV UiK6MjaT4dKmUpM3mdHfvy9efrVcJ6wvOqKK1GNM6T1dBuGiSThbx79cLWVg0sdMJbLp 4qTD/HiJZsh7HBXR1m54jzj/fsHk0iGhl+2BNNagKuyPDXHIEtElAbrKp/1uK4gbKbwz u+yw== X-Gm-Message-State: AJaThX4uxoyn4v5Fp/dg7oIpbcclfCW6K56XIbd1TDGX5acQBEVjOHBy FPscDbovkoY/9MVC4CnIbnUmP4kSRxasxaRIre/0Uqqt X-Google-Smtp-Source: AGs4zMY40jKL1pdh/mRAk54AFbgsMOAJ60xGlWfv8xOGq9bgwjhXaVADzZYUKW5YSiwiSdYrL3Q/CCD7s/zfcDYw0Q8= X-Received: by 10.36.74.83 with SMTP id k80mr930228itb.133.1510812027598; Wed, 15 Nov 2017 22:00:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.9.141 with HTTP; Wed, 15 Nov 2017 22:00:07 -0800 (PST) In-Reply-To: References: <3546393F-6BDB-4E22-BC7D-60F114C0783E@consulintel.es> From: Lorenzo Colitti Date: Thu, 16 Nov 2017 14:00:07 +0800 Message-ID: To: Lee Howard Cc: Jordi Palet Martinez , "v6ops@ietf.org WG" Content-Type: multipart/alternative; boundary="001a1145e92a3abe9f055e135656" Archived-At: Subject: Re: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 06:00:31 -0000 --001a1145e92a3abe9f055e135656 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Personally, I don't feel like I can state whether I support or don't support something that doesn't exist yet. On Thu, Nov 16, 2017 at 1:58 PM, Lee Howard wrote: > > > From: v6ops on behalf of Lorenzo Colitti < > lorenzo@google.com> > Date: Thursday, November 16, 2017 at 1:38 PM > To: Jordi Palet Martinez > Cc: "v6ops@ietf.org WG" > Subject: Re: [v6ops] next steps with draft-palet-v6ops-p2p-from- > customer-prefix > > One difference between "this way" and the other ways is that at this > point, the other ways are well-understood, but as far as I can tell, this > way is undefined and undocumented. > > > Is that an objection or a statement of support? The path from > =E2=80=9Cundocumented=E2=80=9D to =E2=80=9Cdocumented=E2=80=9D is a docum= ent. > > v6ops is specifically chartered to document IPv6 operational experience. > Sounds relevant. > > Lee > > > > On Thu, Nov 16, 2017 at 1:34 PM, JORDI PALET MARTINEZ < > jordi.palet@consulintel.es> wrote: > >> Again, regarding this document, my understanding is that the WG will >> prefer instead of documenting just this way of doing point-2-point links= , >> the several options available, pros and cons and how. >> >> Is that correct? >> >> Anyone volunteering to co-author it? >> >> I think I will be able to have a new version around end of this month. >> >> Regards, >> Jordi >> >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.consulintel.es >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the exclusive use of >> the individual(s) named above and further non-explicilty authorized >> disclosure, copying, distribution or use of the contents of this >> information, even if partially, including attached files, is strictly >> prohibited and will be considered a criminal offense. If you are not the >> intended recipient be aware that any disclosure, copying, distribution o= r >> use of the contents of this information, even if partially, including >> attached files, is strictly prohibited, will be considered a criminal >> offense, so you must reply to the original sender to inform about this >> communication and delete it. >> >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > > --001a1145e92a3abe9f055e135656 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Personally, I don't feel like I can state whether I su= pport or don't support something that doesn't exist yet.

On Thu, Nov 16, 2017 a= t 1:58 PM, Lee Howard <lee@asgard.org> wrote:


From: v6ops <v6ops-bounces@ietf.org>= on behalf of Lorenzo Colitti <lorenzo@google.com>
Date: Thursday, November 16, 2017 at 1:38 PM
To: Jordi Palet Martinez <jordi.palet@consulintel.es&g= t;
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] next steps with d= raft-palet-v6ops-p2p-from-customer-prefix

One difference between "this way" and the= other ways is that at this point, the other ways are well-understood, but = as far as I can tell, this way is undefined and undocumented.

Is that an objection or a statement = of support? The path from =E2=80=9Cundocumented=E2=80=9D to =E2=80=9Cdocume= nted=E2=80=9D is a document.

v6ops is specifically= chartered to document IPv6 operational experience. Sounds relevant.
<= span class=3D"HOEnZb">

Lee
=



On Thu, Nov 16, 2017 at 1:34 PM, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
Again, regarding this document, my understanding is that th= e WG will prefer instead of documenting just this way of doing point-2-poin= t links, the several options available, pros and cons and how.

Is that correct?

Anyone volunteering to co-author it?

I think I will be able to have a new version around end of this month.
<= br> Regards,
Jordi




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

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



_______________________________________________
v6ops mailing list
v= 6ops@ietf.org
https://www.ietf.org/mailman/li= stinfo/v6ops

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

--001a1145e92a3abe9f055e135656-- From nobody Wed Nov 15 23:07:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669B51293E0 for ; Wed, 15 Nov 2017 23:07:13 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAhHlNiToOsZ for ; Wed, 15 Nov 2017 23:07:11 -0800 (PST) Received: from atl4mhob06.registeredsite.com (atl4mhob06.registeredsite.com [209.17.115.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A5B126557 for ; Wed, 15 Nov 2017 23:07:11 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob06.registeredsite.com (8.14.4/8.14.4) with ESMTP id vAG777kw019146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Nov 2017 02:07:07 -0500 Received: (qmail 22365 invoked by uid 0); 16 Nov 2017 07:07:07 -0000 X-TCPREMOTEIP: 31.133.128.134 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?31.133.128.134?) (lee@asgard.org@31.133.128.134) by 0 with ESMTPA; 16 Nov 2017 07:07:05 -0000 User-Agent: Microsoft-MacOutlook/14.7.2.170228 Date: Thu, 16 Nov 2017 15:06:57 +0800 From: Lee Howard To: Lorenzo Colitti CC: Jordi Palet Martinez , "v6ops@ietf.org WG" Message-ID: Thread-Topic: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-prefix References: <3546393F-6BDB-4E22-BC7D-60F114C0783E@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3593689625_12671638" Archived-At: Subject: Re: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-prefix X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 07:07:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3593689625_12671638 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable From: Lorenzo Colitti Date: Thursday, November 16, 2017 at 2:00 PM To: Lee Howard Cc: Jordi Palet Martinez , "v6ops@ietf.org WG" Subject: Re: [v6ops] next steps with draft-palet-v6ops-p2p-from-customer-prefix > Personally, I don't feel like I can state whether I support or don't supp= ort > something that doesn't exist yet. I think Jordi=E2=80=99s question was, =E2=80=9CIs this work the WG should do?=E2=80=9D Not su= re whether you=E2=80=99re saying the document or the operational practice doesn=E2=80=99t = exist yet. If the document, then should we write one? If the practice, Jordi said it does exist. Lee >=20 > On Thu, Nov 16, 2017 at 1:58 PM, Lee Howard wrote: >>=20 >>=20 >> From: v6ops on behalf of Lorenzo Colitti >> >> Date: Thursday, November 16, 2017 at 1:38 PM >> To: Jordi Palet Martinez >> Cc: "v6ops@ietf.org WG" >> Subject: Re: [v6ops] next steps with >> draft-palet-v6ops-p2p-from-customer-prefix >>=20 >>> One difference between "this way" and the other ways is that at this po= int, >>> the other ways are well-understood, but as far as I can tell, this way = is >>> undefined and undocumented. >>=20 >> Is that an objection or a statement of support? The path from =E2=80=9Cundocum= ented=E2=80=9D >> to =E2=80=9Cdocumented=E2=80=9D is a document. >>=20 >> v6ops is specifically chartered to document IPv6 operational experience. >> Sounds relevant. >>=20 >> Lee >>=20 >>=20 >>>=20 >>> On Thu, Nov 16, 2017 at 1:34 PM, JORDI PALET MARTINEZ >>> wrote: >>>> Again, regarding this document, my understanding is that the WG will p= refer >>>> instead of documenting just this way of doing point-2-point links, the >>>> several options available, pros and cons and how. >>>>=20 >>>> Is that correct? >>>>=20 >>>> Anyone volunteering to co-author it? >>>>=20 >>>> I think I will be able to have a new version around end of this month. >>>>=20 >>>> Regards, >>>> Jordi >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> ********************************************** >>>> IPv4 is over >>>> Are you ready for the new Internet ? >>>> http://www.consulintel.es >>>> The IPv6 Company >>>>=20 >>>> This electronic message contains information which may be privileged o= r >>>> 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 t= he >>>> intended recipient be aware that any disclosure, copying, distribution= or >>>> use of the contents of this information, even if partially, including >>>> attached files, is strictly prohibited, will be considered a criminal >>>> offense, so you must reply to the original sender to inform about this >>>> communication and delete it. >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>> _______________________________________________ v6ops mailing list >>> v6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6ops >=20 --B_3593689625_12671638 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable


From: Lorenzo Colitti <lorenzo@google.com>
Date: Thursday, November 16, 2017 at 2:00 PM
To: Lee Howard <lee= @asgard.org>
Cc: Jordi Pale= t Martinez <jordi.palet@consu= lintel.es>, "v6ops@ietf.org WG" &= lt;v6ops@ietf.org>
Subject: Re: [v6ops] next steps with draft-palet-v6o= ps-p2p-from-customer-prefix

Personally, I don't feel like I can st= ate whether I support or don't support something that doesn't exist yet.

I think Jordi’s question was= , “Is this work the WG should do?” Not sure whether you’re= saying the document or the operational practice doesn’t exist yet. If= the document, then should we write one? If the practice, Jordi said it does= exist.

Lee


<= div class=3D"gmail_extra">
On Thu, Nov 16, 2017 at= 1:58 PM, Lee Howard <lee@asgard.org> wrote:


From: v6ops <v6ops-bounces@ietf.org> on behalf of Lorenzo Colitti <= lorenzo@google.com&g= t;
Date: Thursday, November 16, 20= 17 at 1:38 PM
To: Jordi Palet Mart= inez <jordi.p= alet@consulintel.es>
Cc: "<= a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] next steps with draf= t-palet-v6ops-p2p-from-customer-prefix
One difference between "this way" and the other ways is that at th= is point, the other ways are well-understood, but as far as I can tell, this= way is undefined and undocumented.
Is that an objection or a statement of support? The path from &#= 8220;undocumented” to “documented” is a document.

v6ops is specifically chartered to document IPv6 operationa= l experience. Sounds relevant.

Lee

=


On Thu, Nov 16, 2017 at 1:34 PM, JORDI PAL= ET MARTINEZ <jordi.palet@consulintel.es> wrote:
Again, regarding this document, my understanding is that t= he WG will prefer instead of documenting just this way of doing point-2-poin= t links, the several options available, pros and cons and how.

Is that correct?

Anyone volunteering to co-author it?

I think I will be able to have a new version around end of this month.
<= br> Regards,
Jordi




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

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the in= dividual(s) named above and further non-explicilty authorized disclosure, co= pying, distribution or use of the contents of this information, even if part= ially, including attached files, is strictly prohibited and will be consider= ed a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it.



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

_______________________________________________ v6ops mailing list v6ops@ietf.orghttps://www.iet= f.org/mailman/listinfo/v6ops

--B_3593689625_12671638-- From nobody Thu Nov 16 00:21:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF08126BFD for ; Thu, 16 Nov 2017 00:21: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 2ikafd9fcN_o for ; Thu, 16 Nov 2017 00:21:01 -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 57FD1129465 for ; Thu, 16 Nov 2017 00:21:01 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id t69so10111674pfg.4 for ; Thu, 16 Nov 2017 00:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9QIl0kFu+Wv1I83kdp73JhMRazr3GT4lfUfI3KVQ+08=; b=QhlOy8g865XArmPKpuC6UCz+wd4pF+YmfQSwRX3ptclaSCoBtsTKwtyB4hMUsXSq/W BKbZKXBvOF/BYPgJoyOduEyjuzO2w5oddswyq5w4KT4WJaDnFF445rShP3YVtdFQyFtD /ebnBjBvEMt/NVSHUq3/mufx3g4Ue1JGB018SywJ2LkWlIRoMXIKpDN7iAfJKZUMadqN 5bwv7zsXqYWLiHmUgstK49waIti5UWKJvYLFEEZW4TSqjPYoYW9RqXyEV4Tw0MsnSO/A 3WBpEBMf0OUonvdB/dJak89yUiZqUEhd8FxZnoRy9atea3jcwj9fcdhHbIpgKmRAXv3v xBjA== 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=9QIl0kFu+Wv1I83kdp73JhMRazr3GT4lfUfI3KVQ+08=; b=N+FAIsm8v5kbXfCNdJ+1TUGciAYDxU1s5eEYQkt5qnrc3tRjJ1sC573sfmior7P0oY 6rBzRbMyj9p2yFx55VVF3Fp5VgSkKLg8ZwHVLnIPUnjieuto+c8u2xN8dnR8CAFsF/F0 OuEsq8Jto4zZHUKBne3YCOko0t6BKDEQJ2k2sQzW1Uz5DsM0y/DXlqO8TnpnbAkzU7+i 2Tf5aqlY4K8lz0ya9VDo8Hbjr7lrqRW8Stno+U831nHjVTQTo8zeKaYPcTnHHKOeXXwe RqUXqf37i8c6V5VCT60tRk2ADv6h0iJiFfoOI5cYoctv8LzRPI/p2osZtLcxv2zoNGco h9ow== X-Gm-Message-State: AJaThX4nVFFJQRLVJCfBGqVUDrACNyf7Ukm+puTOPeH2ng4EswGhZvbP CV+sNypNxiKPaJSJ4/rNPhibwg== X-Google-Smtp-Source: AGs4zMZeX7XoSW5cgkZh1S54KyUhP7RyBrxIfWtxqpj5GaD8f15fuFOvng5AiYwZkjDoFXSbPjIQvg== X-Received: by 10.84.133.111 with SMTP id 102mr935981plf.136.1510820460597; Thu, 16 Nov 2017 00:21:00 -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 i21sm1918737pfj.136.2017.11.16.00.20.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 00:20:59 -0800 (PST) To: "Templin, Fred L" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Fred Baker , "v6ops@ietf.org" References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <43186ad6-dc2f-c9d8-2884-db4a097f142d@gmail.com> Date: Thu, 16 Nov 2017 21:21: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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 08:21:04 -0000 On 16/11/2017 18:35, Templin, Fred L wrote: > Hi Gunter, > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp) >> Sent: Wednesday, November 15, 2017 6:31 PM >> To: Fred Baker ; v6ops@ietf.org >> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >> >> Does this mean that the document desires to include all the dynamics of address assignment subscriber management when PD is >> used? (i.e. subscriber vs address correlation state, identification of the subscriber/host, etc...)? > > This draft is about what a host can do internally when it gets a prefix delegation What is a bit confusing is whether, having acquired a prefix, it's going to turn itself into a forwarding device. If so, surely there is nothing to say except that IPv6 router requirements apply. (Which does not mean it's going to run a routing protocol, since it can default route everything to its upstream. But things like redirects are covered by 6434(bis), which also mandates that routers must send RAs etc.) So I guess my point is: what is specific to a host about the discussion in this document? Just to take an example, in section 4: When the node receives the prefix, it can distribute the prefix to downstream networks and configure one or more addresses for itself on downstream interfaces. The node then acts as a router on behalf of its downstream networks and configures a default route via a neighbor on an upstream interface. So that is describing what a *router* does, not what a host does. If it's *not* going to be a forwarding device, I wonder what it's going to use the prefix for? Also in section 4: The node could instead (or in addition) use portions of the delegated prefix for its own multi-addressing purposes. In a first alternative, the node can assign as many addresses as it wants from the prefix to virtual interfaces. In that case, applications running on the node can use the addresses according to the weak end system model. Fair enough. But it's very confusing to mix the end host behaviours in with the router behaviours. And since a lot of the document is about router behaviours, the document title itself is confusing. (I don't agree with Lorenzo that the host/router distinction is confusing in itself.) I suggest (a) changing the title. Something like "IPv6 Prefix Delegation Models". (b) refactoring the contents to clearly separate the router-like and host-like behaviours. Also, perhaps, identify any points that would be better moved into 6434bis (or 6434ter). With those changes I'd be happy to see this as a WG draft. Brian From nobody Thu Nov 16 00:48:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8124E126CBF for ; Thu, 16 Nov 2017 00:48:04 -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 Pu-XbkQdf9hL for ; Thu, 16 Nov 2017 00:48:01 -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 9B9B2126BFD for ; Thu, 16 Nov 2017 00:48:01 -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 vAG8lxf0051535; Thu, 16 Nov 2017 01:48:00 -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 vAG8lreW051531 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 16 Nov 2017 01:47:53 -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, 16 Nov 2017 00:47: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; Thu, 16 Nov 2017 00:47:53 -0800 From: "Templin, Fred L" To: Brian E Carpenter , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AQHTXoFfbBaTujqFZECShuBca1gGBKMWRivQgAA01FCAALXIAP//fUyQ Date: Thu, 16 Nov 2017 08:47:53 +0000 Message-ID: <655879d9e7274da88ee2cd33a0202dd7@XCH15-06-08.nw.nos.boeing.com> References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <43186ad6-dc2f-c9d8-2884-db4a097f142d@gmail.com> In-Reply-To: <43186ad6-dc2f-c9d8-2884-db4a097f142d@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 08:48:04 -0000 QnJpYW4sIHRoYW5rIHlvdSBmb3IgeW91ciBjb25zdHJ1Y3RpdmUgaW5wdXQuIEJvYiBIaW5kZW4g YW5kIG90aGVycyBoYXZlIGFsc28NCmJlZW4gY29uc2lzdGVudGx5IHJlbWluZGluZyBtZSBhYm91 dCB0aGUgaG9zdC9yb3V0ZXIgZGlzdGluY3Rpb24gYW5kIEkgaGF2ZQ0Kbm90IGJlZW4gaWdub3Jp bmcgdGhlbSAtIEkganVzdCBkaWRuJ3Qga25vdyBob3cgdG8gc3BlYWsgdG8gdGhlIGRpc3RpbmN0 aW9uLg0KQnV0LCB5b3VyIGlucHV0IGdpdmVzIHNvbWUgdXNlZnVsIGNsdWVzLg0KDQpTb21lIGNv bW1lbnRzIGFuZCBxdWVzdGlvbnMgYmVsb3c6DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBn bWFpbC5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNiwgMjAxNyAxMjoyMSBBTQ0K PiBUbzogVGVtcGxpbiwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPjsgVmFuIERl IFZlbGRlLCBHdW50ZXIgKE5va2lhIC0gQkUvQW50d2VycCkNCj4gPGd1bnRlci52YW5fZGVfdmVs ZGVAbm9raWEuY29tPjsgRnJlZCBCYWtlciA8ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPjsgdjZv cHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtdGVtcGxpbi12Nm9wcy1w ZGhvc3QgYSB3b3JraW5nIGdyb3VwIGRyYWZ0Pw0KPiANCj4gT24gMTYvMTEvMjAxNyAxODozNSwg VGVtcGxpbiwgRnJlZCBMIHdyb3RlOg0KPiA+IEhpIEd1bnRlciwNCj4gPg0KPiA+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBWYW4gRGUgVmVsZGUsIEd1bnRlciAoTm9raWEgLSBC RS9BbnR3ZXJwKQ0KPiA+PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE1LCAyMDE3IDY6MzEg UE0NCj4gPj4gVG86IEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbT47IHY2b3Bz QGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LXRlbXBsaW4tdjZvcHMt cGRob3N0IGEgd29ya2luZyBncm91cCBkcmFmdD8NCj4gPj4NCj4gPj4gRG9lcyB0aGlzIG1lYW4g dGhhdCB0aGUgZG9jdW1lbnQgZGVzaXJlcyB0byBpbmNsdWRlIGFsbCB0aGUgZHluYW1pY3Mgb2Yg YWRkcmVzcyBhc3NpZ25tZW50IHN1YnNjcmliZXIgbWFuYWdlbWVudCB3aGVuIFBEIGlzDQo+ID4+ IHVzZWQ/IChpLmUuIHN1YnNjcmliZXIgdnMgYWRkcmVzcyBjb3JyZWxhdGlvbiBzdGF0ZSwgaWRl bnRpZmljYXRpb24gb2YgdGhlIHN1YnNjcmliZXIvaG9zdCwgZXRjLi4uKT8NCj4gPg0KPiA+IFRo aXMgZHJhZnQgaXMgYWJvdXQgd2hhdCBhIGhvc3QgY2FuIGRvIGludGVybmFsbHkgd2hlbiBpdCBn ZXRzIGEgcHJlZml4IGRlbGVnYXRpb24NCj4gDQo+IFdoYXQgaXMgYSBiaXQgY29uZnVzaW5nIGlz IHdoZXRoZXIsIGhhdmluZyBhY3F1aXJlZCBhIHByZWZpeCwgaXQncyBnb2luZw0KPiB0byB0dXJu IGl0c2VsZiBpbnRvIGEgZm9yd2FyZGluZyBkZXZpY2UuIElmIHNvLCBzdXJlbHkgdGhlcmUgaXMg bm90aGluZw0KPiB0byBzYXkgZXhjZXB0IHRoYXQgSVB2NiByb3V0ZXIgcmVxdWlyZW1lbnRzIGFw cGx5LiAoV2hpY2ggZG9lcyBub3QNCj4gbWVhbiBpdCdzIGdvaW5nIHRvIHJ1biBhIHJvdXRpbmcg cHJvdG9jb2wsIHNpbmNlIGl0IGNhbiBkZWZhdWx0IHJvdXRlDQo+IGV2ZXJ5dGhpbmcgdG8gaXRz IHVwc3RyZWFtLiBCdXQgdGhpbmdzIGxpa2UgcmVkaXJlY3RzIGFyZSBjb3ZlcmVkIGJ5DQo+IDY0 MzQoYmlzKSwgd2hpY2ggYWxzbyBtYW5kYXRlcyB0aGF0IHJvdXRlcnMgbXVzdCBzZW5kIFJBcyBl dGMuKQ0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgcm91dGVycyBvbmx5IHNlbmQgUkFzIG92 ZXIgYWR2ZXJ0aXNpbmcNCmludGVyZmFjZXMsIGFuZCBub2RlcyB0aGF0IHJlY2VpdmUgcHJlZml4 IGRlbGVnYXRpb25zIG92ZXIgYW4NCnVwc3RyZWFtIGludGVyZmFjZSB3b3VsZCBub3QgY29uZmln dXJlIHRoYXQgaW50ZXJmYWNlIGFzIGFuDQphZHZlcnRpc2luZyBpbnRlcmZhY2UuIFNvLCBJIGFn cmVlIHRoYXQgdGhlIGRlbGVnYXRpbmcgcm91dGVyDQp3b3VsZCBzZW5kIFJBcywgYnV0IHRoZSBy ZXF1ZXN0aW5nIHJvdXRlciB3b3VsZCBub3Qgc2VuZCBSQXMNCm92ZXIgdGhlIHVwc3RyZWFtIGlu dGVyZmFjZS4gQnV0LCBwZXJoYXBzIHlvdSBkaWQgbm90IG1lYW4gdG8NCmltcGx5IG90aGVyd2lz ZT8NCg0KPiBTbyBJIGd1ZXNzIG15IHBvaW50IGlzOiB3aGF0IGlzIHNwZWNpZmljIHRvIGEgaG9z dCBhYm91dCB0aGUgZGlzY3Vzc2lvbg0KPiBpbiB0aGlzIGRvY3VtZW50PyBKdXN0IHRvIHRha2Ug YW4gZXhhbXBsZSwgaW4gc2VjdGlvbiA0Og0KPiANCj4gICAgV2hlbiB0aGUgbm9kZSByZWNlaXZl cyB0aGUgcHJlZml4LCBpdCBjYW4gZGlzdHJpYnV0ZSB0aGUgcHJlZml4IHRvDQo+ICAgIGRvd25z dHJlYW0gbmV0d29ya3MgYW5kIGNvbmZpZ3VyZSBvbmUgb3IgbW9yZSBhZGRyZXNzZXMgZm9yIGl0 c2VsZiBvbg0KPiAgICBkb3duc3RyZWFtIGludGVyZmFjZXMuICBUaGUgbm9kZSB0aGVuIGFjdHMg YXMgYSByb3V0ZXIgb24gYmVoYWxmIG9mDQo+ICAgIGl0cyBkb3duc3RyZWFtIG5ldHdvcmtzIGFu ZCBjb25maWd1cmVzIGEgZGVmYXVsdCByb3V0ZSB2aWEgYSBuZWlnaGJvcg0KPiAgICBvbiBhbiB1 cHN0cmVhbSBpbnRlcmZhY2UuDQo+IA0KPiBTbyB0aGF0IGlzIGRlc2NyaWJpbmcgd2hhdCBhICpy b3V0ZXIqIGRvZXMsIG5vdCB3aGF0IGEgaG9zdCBkb2VzLg0KDQpZZXMuIEV2ZW4gdGhvdWdoIGl0 IG1heSBiZSBhICJob3N0LWxpa2UiIGRldmljZSBsaWtlIG15IGxhcHRvcCBvciBjZWxscGhvbmUN CmlmIGl0IGZvcndhcmRzIHBhY2tldHMgdGhhdCBhcmUgbm90IGV4cGxpY2l0bHkgYWRkcmVzc2Vk IHRvIGl0c2VsZiBpdCBpcyBhIHJvdXRlci4NCg0KPiBJZiBpdCdzICpub3QqIGdvaW5nIHRvIGJl IGEgZm9yd2FyZGluZyBkZXZpY2UsIEkgd29uZGVyIHdoYXQgaXQncw0KPiBnb2luZyB0byB1c2Ug dGhlIHByZWZpeCBmb3I/IEFsc28gaW4gc2VjdGlvbiA0Og0KPiANCj4gICAgVGhlIG5vZGUgY291 bGQgaW5zdGVhZCAob3IgaW4gYWRkaXRpb24pIHVzZSBwb3J0aW9ucyBvZiB0aGUgZGVsZWdhdGVk DQo+ICAgIHByZWZpeCBmb3IgaXRzIG93biBtdWx0aS1hZGRyZXNzaW5nIHB1cnBvc2VzLiAgSW4g YSBmaXJzdA0KPiAgICBhbHRlcm5hdGl2ZSwgdGhlIG5vZGUgY2FuIGFzc2lnbiBhcyBtYW55IGFk ZHJlc3NlcyBhcyBpdCB3YW50cyBmcm9tDQo+ICAgIHRoZSBwcmVmaXggdG8gdmlydHVhbCBpbnRl cmZhY2VzLiAgSW4gdGhhdCBjYXNlLCBhcHBsaWNhdGlvbnMgcnVubmluZw0KPiAgICBvbiB0aGUg bm9kZSBjYW4gdXNlIHRoZSBhZGRyZXNzZXMgYWNjb3JkaW5nIHRvIHRoZSB3ZWFrIGVuZCBzeXN0 ZW0NCj4gICAgbW9kZWwuDQo+IA0KPiBGYWlyIGVub3VnaC4gQnV0IGl0J3MgdmVyeSBjb25mdXNp bmcgdG8gbWl4IHRoZSBlbmQgaG9zdCBiZWhhdmlvdXJzDQo+IGluIHdpdGggdGhlIHJvdXRlciBi ZWhhdmlvdXJzLiBBbmQgc2luY2UgYSBsb3Qgb2YgdGhlIGRvY3VtZW50IGlzDQo+IGFib3V0IHJv dXRlciBiZWhhdmlvdXJzLCB0aGUgZG9jdW1lbnQgdGl0bGUgaXRzZWxmIGlzIGNvbmZ1c2luZy4N Cj4gKEkgZG9uJ3QgYWdyZWUgd2l0aCBMb3JlbnpvIHRoYXQgdGhlIGhvc3Qvcm91dGVyIGRpc3Rp bmN0aW9uIGlzDQo+IGNvbmZ1c2luZyBpbiBpdHNlbGYuKQ0KPiANCj4gSSBzdWdnZXN0DQo+IChh KSBjaGFuZ2luZyB0aGUgdGl0bGUuIFNvbWV0aGluZyBsaWtlICJJUHY2IFByZWZpeCBEZWxlZ2F0 aW9uIE1vZGVscyIuDQoNCk9LLg0KDQo+IChiKSByZWZhY3RvcmluZyB0aGUgY29udGVudHMgdG8g Y2xlYXJseSBzZXBhcmF0ZSB0aGUgcm91dGVyLWxpa2UNCj4gICAgIGFuZCBob3N0LWxpa2UgYmVo YXZpb3Vycy4NCg0KSSB0aGluayBJIGNhbiBkbyB0aGF0Lg0KDQo+IEFsc28sIHBlcmhhcHMsIGlk ZW50aWZ5IGFueSBwb2ludHMgdGhhdCB3b3VsZCBiZSBiZXR0ZXIgbW92ZWQNCj4gaW50byA2NDM0 YmlzIChvciA2NDM0dGVyKS4NCg0KQ2FuIHlvdSBnaXZlIHNvbWUgZXhhbXBsZXMgb2Ygd2hhdCBj b3VsZCBiZSBtb3ZlZCB0aGVyZT8NCg0KPiBXaXRoIHRob3NlIGNoYW5nZXMgSSdkIGJlIGhhcHB5 IHRvIHNlZSB0aGlzIGFzIGEgV0cgZHJhZnQuDQoNClRoYW5rcyBmb3IgcmFpc2luZyB0aGVzZSBw b2ludHMuDQoNCkZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0KPiAgICBCcmlhbg0K DQo= From nobody Thu Nov 16 01:01:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956C7124217 for ; Thu, 16 Nov 2017 01:01: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 S6bfDgh1V9hu for ; Thu, 16 Nov 2017 01:01:24 -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 D42F51293F3 for ; Thu, 16 Nov 2017 01:01:02 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id b5so5023396itc.3 for ; Thu, 16 Nov 2017 01:01:02 -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=1f1DwVNJs0uOyCXG2JhCPoNPLtDji/1zrHgaEUOdSZI=; b=UDVgnoXtAENyPfCBQg5ToRZ+qEuYbfcOGQVFLTcnz8GlQuDmYAmr/8jTL8D5iuo4Tv 8NjdCSMNbzzp0wvJuvfVsHDRYRBE9Nlz0iJ2tC2AF/zAGn7pEt6PMhCIUeouURqgYN6y zvPEH05M7ZcRmPG38g7ddjl5KfOU6Acm/7up6k5iKPcv45ka+gp7CA6/uqTEa5sovShC MXaFw253Q6YwadD1zA5v9P14ypFnwFftn/UhWEl0ho6v9SN7SH40vSaIYVvNVBM2Hryb Nzs3RwgnK43TDalh0k9NEQx5ehkG0GgovjCeiqwlz1A205uOq1Ai+GcO2/a0ZWHVQGlD uI+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:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=1f1DwVNJs0uOyCXG2JhCPoNPLtDji/1zrHgaEUOdSZI=; b=DWa5n8olykjOCcx+nd+m4plop2yCDhic96kZ2KpkVanmWMw+17LDoQGOPBIg9vSXE3 irHaQOp448F6Bieywo+pvvb/diY3iZ3aMT4WpJgYfssVSe7aVX21gE4jHh0yFXFEAR1A z/OIhe6DHFz87ZeOWNhh8i6QBqOPuX/H0+CE1KUk3vhya4X1/WD7nNwF7IhiPPK8gpXF ++htJtLmWsNlk3iIadpuna94hTnhZPJ1yFnv+VUYKJggCHvqLSv+nCyfvVevG4RalTc3 phSR/6IMSyFKjBaRiEHXRpfTxSEP6YakOUG5L6V40sdtYi2fC8i/obj7FbnWvhRznmXf /VRQ== X-Gm-Message-State: AJaThX50N7UiCF+qQZFihlP1XmOjUxG2aY+R7fyRsEnw7yJNhVep3HP7 PnqaJDuK3EjeikJMP8b9VUPMaw== X-Google-Smtp-Source: AGs4zMYTmRR5VCrOOADEsYyDLMa7vJS/uxEW8ROEmWVd1IT1ZlVgDY6B3Es87vZFU+foO+6a5/IVrA== X-Received: by 10.36.19.81 with SMTP id 78mr1415065itz.143.1510822861882; Thu, 16 Nov 2017 01:01: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 y197sm539131itc.39.2017.11.16.01.00.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 01:01:01 -0800 (PST) To: "Templin, Fred L" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Fred Baker , "v6ops@ietf.org" References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <43186ad6-dc2f-c9d8-2884-db4a097f142d@gmail.com> <655879d9e7274da88ee2cd33a0202dd7@XCH15-06-08.nw.nos.boeing.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Thu, 16 Nov 2017 22:01: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: <655879d9e7274da88ee2cd33a0202dd7@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 09:01:29 -0000 On 16/11/2017 21:47, Templin, Fred L wrote: > Brian, thank you for your constructive input. Bob Hinden and others have also > been consistently reminding me about the host/router distinction and I have > not been ignoring them - I just didn't know how to speak to the distinction. > But, your input gives some useful clues. > > Some comments and questions below: > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Thursday, November 16, 2017 12:21 AM >> To: Templin, Fred L ; Van De Velde, Gunter (Nokia - BE/Antwerp) >> ; Fred Baker ; v6ops@ietf.org >> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >> >> On 16/11/2017 18:35, Templin, Fred L wrote: >>> Hi Gunter, >>> >>>> -----Original Message----- >>>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp) >>>> Sent: Wednesday, November 15, 2017 6:31 PM >>>> To: Fred Baker ; v6ops@ietf.org >>>> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >>>> >>>> Does this mean that the document desires to include all the dynamics of address assignment subscriber management when PD is >>>> used? (i.e. subscriber vs address correlation state, identification of the subscriber/host, etc...)? >>> >>> This draft is about what a host can do internally when it gets a prefix delegation >> >> What is a bit confusing is whether, having acquired a prefix, it's going >> to turn itself into a forwarding device. If so, surely there is nothing >> to say except that IPv6 router requirements apply. (Which does not >> mean it's going to run a routing protocol, since it can default route >> everything to its upstream. But things like redirects are covered by >> 6434(bis), which also mandates that routers must send RAs etc.) > > My understanding is that routers only send RAs over advertising > interfaces, and nodes that receive prefix delegations over an > upstream interface would not configure that interface as an > advertising interface. So, I agree that the delegating router > would send RAs, but the requesting router would not send RAs > over the upstream interface. But, perhaps you did not mean to > imply otherwise? No, that sounds right. >> So I guess my point is: what is specific to a host about the discussion >> in this document? Just to take an example, in section 4: >> >> When the node receives the prefix, it can distribute the prefix to >> downstream networks and configure one or more addresses for itself on >> downstream interfaces. The node then acts as a router on behalf of >> its downstream networks and configures a default route via a neighbor >> on an upstream interface. >> >> So that is describing what a *router* does, not what a host does. > > Yes. Even though it may be a "host-like" device like my laptop or cellphone > if it forwards packets that are not explicitly addressed to itself it is a router. Exactly. >> If it's *not* going to be a forwarding device, I wonder what it's >> going to use the prefix for? Also in section 4: >> >> The node could instead (or in addition) use portions of the delegated >> prefix for its own multi-addressing purposes. In a first >> alternative, the node can assign as many addresses as it wants from >> the prefix to virtual interfaces. In that case, applications running >> on the node can use the addresses according to the weak end system >> model. >> >> Fair enough. But it's very confusing to mix the end host behaviours >> in with the router behaviours. And since a lot of the document is >> about router behaviours, the document title itself is confusing. >> (I don't agree with Lorenzo that the host/router distinction is >> confusing in itself.) >> >> I suggest >> (a) changing the title. Something like "IPv6 Prefix Delegation Models". > > OK. > >> (b) refactoring the contents to clearly separate the router-like >> and host-like behaviours. > > I think I can do that. > >> Also, perhaps, identify any points that would be better moved >> into 6434bis (or 6434ter). > > Can you give some examples of what could be moved there? Not really, that would require some close study. But if you have identified some behaviour that is in practice required, but is not already implicitly or explicitly covered in 6343bis, surely it belongs there? Brian >> With those changes I'd be happy to see this as a WG draft. > > Thanks for raising these points. > > Fred > fred.l.templin@boeing.com > >> Brian > From nobody Thu Nov 16 22:36:43 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1DA128D16 for ; Thu, 16 Nov 2017 22:36:37 -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 bzpKwRoDx-u2 for ; Thu, 16 Nov 2017 22:36:36 -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 1FF12128D0F for ; Thu, 16 Nov 2017 22:36:36 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id k66so1507433lfg.3 for ; Thu, 16 Nov 2017 22:36:36 -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=Wxg9ptJszD64w0oAPfXpmFlDc4DYJZjlKv1Bd356RDw=; b=TBgQM/r7qENYcfkj9QaIfQICujcSL7gOHLb+7NV0s/5F0Ys7P0VobaPFGr8HPOTMgf JCyQnd54CSxra5PjwjIwNSAH86UMiNcpoKEi98fUHzsfO5+xXA5Z3jAC/mp4dizcIyNM MsUYQb/3GaI6rvMdbd7swOKJiHrWw0ZZKw9Tu6CeF9I9DXBaFvB0HxHeqKBROufeVdJ0 +eXAd8lrQHJS+P9TKDq6LEd5ROzVXoADbhhKIznPu8NSwwPkWeOn6P9vAJxQHOPbvV7E t7/SA4w7y7hsPj1Hvyg4WKEvLdb18U0JvMecrvUziCwV8diW3LsRC/szmFzd3+/d5KmM 4W0Q== 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=Wxg9ptJszD64w0oAPfXpmFlDc4DYJZjlKv1Bd356RDw=; b=sVB2TN7RzBxP3Sx1E+L1juFoeYsjg6mBz45Io4xch4H8w94MUboO6pgL6e64p8e6v1 vwVIsGvxaXEkba52mrNQUEG55Cd/FQkDeg1KJTr9aeOJOta9pPKPXSd2O8l3EWUhjLRs +/VF5bw5dyIXwbdRFxje9jIpr8DwidlKOLCHZa4O833qFH1KFW4vpu/mNyUDw7OcLIaC CBdDfnie1OAKgCTK0CKei2dc3ibreOGK4feKZDU/kzrTYA4v1sRyA8pWf85oEQGvmx28 1PBQMXhRNth8MTsK7NhfBnV9I3YKOkEECUKnaxNgYKL8+vcrHhhLe6MNrFjy0jHFe5qx 1lwQ== X-Gm-Message-State: AJaThX7tuaGo3nMGzCiqHOLDB00+HW5TTfHD17IvrG7EdZTfzuIaoUe/ TbyuPO/owmbz2UGyDdlNHfnpgIP1aF3gqUX6T/Xg6Q== X-Google-Smtp-Source: AGs4zMYpj+29fAUaeNRVrz8wnuJe6wWO/HXWtTD1Bk/63hwNXWpX6zrjVsniah1QMVWgwcYHXLYKlj4379FmX385SoA= X-Received: by 10.25.20.167 with SMTP id 39mr491717lfu.67.1510900594341; Thu, 16 Nov 2017 22:36:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.205.2 with HTTP; Thu, 16 Nov 2017 22:36:13 -0800 (PST) In-Reply-To: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> From: Jen Linkova Date: Fri, 17 Nov 2017 17:36:13 +1100 Message-ID: To: Jordi Palet Martinez Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 06:36:38 -0000 On Thu, Nov 16, 2017 at 4:58 PM, JORDI PALET MARTINEZ wrote: > And last one =E2=80=A6 I=E2=80=99ve already talked with Carlos, the co-au= thor, in order to work on the path forward and how to make sure that securi= ty/privacy are correctly taken into account in the document. > Also, I think we got the clear message that the reporting should be done = with both IPv6 and IPv4 (as fallback by means of happy eyeballs). If it's syslog, it's UDP. How are you going to implement HE?? Using IPv6 does not sound very helpful as IPv6 might be broken. Using IPv4 introduces a significant risk of those logs to be sent to anyone who advertises that /24. I personally do not see much value in all that logging in general but it might be just me. However the solution currently proposed in the draft sounds very scary. --=20 SY, Jen Linkova aka Furry From nobody Thu Nov 16 22:50:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F00A128C84 for ; Thu, 16 Nov 2017 22:50:53 -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 bCF1FJ0ZGrtc for ; Thu, 16 Nov 2017 22:50:51 -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 E2DD21200E5 for ; Thu, 16 Nov 2017 22:50:50 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id y80so4358062wmd.0 for ; Thu, 16 Nov 2017 22:50: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=SCiYNSOooaMpab/KCswSTQklnl10vkYyJZ1AKZbzFxM=; b=B4NEsSMbtNtBj3sRAd9kg05A5pzuDR8kUL2gYz5t54LherJeXmUfu+PFfUE761LvP9 B9ypPWgF3+cmNVWmJpI97nSw44VaI65+JpCv3tklDexXRMy0zejqCWr1U/KcCHDZ0bsX m1+N0ej1VMVjS7ouPoYLFAnY8Has4bv2KG3yr+7Z5L2dJoF8ShQb2xvJOt4FlPp9Dvnn wSZR5nk9ILTIg+DLe/h+lT9Ub8PbDBlnHTD9z0yfK5YQ9Ntz/S2osAn/gaRJf8DAF//7 czmq1/5ZqiCcXmUN3u4KIZbG/6GT8Tf4LAPu69rOAtCMf0lBqxMMs6E1R5CzPJHst/ef OrSw== 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=SCiYNSOooaMpab/KCswSTQklnl10vkYyJZ1AKZbzFxM=; b=sMGA3eKlxvyLpERAlxSI9xbpfM2J2eKragJ2F+2daqJ+7lgujmM44Wq+fEyrnFjuQD bncPEuGSQ+Ummnj5Is27hOoyVrbAFgdrHXPtqXH2TcWaxEYnrxSfj6Ufbom7On2i8DkG UYwLm+bVvvOaYxgbUMC1fgcA4XJBSWVy4kEPfRH7qwQkAAohLS1eLFxulHlcWPO9UGBJ r18InI8kU5uHF2gocEBqFoXoeFKpJ9JPbov4jOWIRpy8iZH3Q5zDHo1WtT1RpnrXWLOQ Vp0LbzNSVObqqpIGja/XQl21VZLq2NRYA6MiM8uFC7bPOMw9MEy8H0vd41k8LGsYBSVx 3fHw== X-Gm-Message-State: AJaThX70nd1NbPOSsgUQH9VS6HYMDqw0c0W8pw+jzXlZBB2bQlo+ntg1 CobT/jq21SYfYTCKD6si7u8= X-Google-Smtp-Source: AGs4zMaY2SxIQVELdmrlJVeq02QLFWHNSVbe8GfqQtyM9+8fOsqEHN8126MKfmfM39inuIDZLRT3hw== X-Received: by 10.80.131.38 with SMTP id 35mr6070880edh.291.1510901449468; Thu, 16 Nov 2017 22:50:49 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:a193:4f26:3020:9483? ([2001:67c:1232:144:a193:4f26:3020:9483]) by smtp.gmail.com with ESMTPSA id a7sm2453296edd.19.2017.11.16.22.50.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 22:50:48 -0800 (PST) From: Fred Baker Message-Id: <7A1C581E-561A-4CD9-8B80-E6BAD3E39CEA@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_36661FF2-8F7D-4502-AA08-9DDEF9E2AB3F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 17 Nov 2017 14:50:43 +0800 In-Reply-To: Cc: "v6ops@ietf.org" , Jen Linkova To: JORDI PALET MARTINEZ References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 06:50:53 -0000 --Apple-Mail=_36661FF2-8F7D-4502-AA08-9DDEF9E2AB3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 SYSLOG was also identified in the session as a privacy risk (the system = is logging its own identity and the identity or address of its = destination). The more I think of it, I suspect it is also an effective = DDOS attack if there are any number of systems reporting. > On Nov 17, 2017, at 2:36 PM, Jen Linkova wrote: >=20 > On Thu, Nov 16, 2017 at 4:58 PM, JORDI PALET MARTINEZ > wrote: >> And last one =E2=80=A6 I=E2=80=99ve already talked with Carlos, the = co-author, in order to work on the path forward and how to make sure = that security/privacy are correctly taken into account in the document. >> Also, I think we got the clear message that the reporting should be = done with both IPv6 and IPv4 (as fallback by means of happy eyeballs). >=20 > If it's syslog, it's UDP. How are you going to implement HE?? > Using IPv6 does not sound very helpful as IPv6 might be broken. Using > IPv4 introduces a significant risk of those logs to be sent to anyone > who advertises that > /24. >=20 > I personally do not see much value in all that logging in general but > it might be just me. However the solution currently proposed in the > draft sounds very scary. >=20 > -- > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_36661FF2-8F7D-4502-AA08-9DDEF9E2AB3F 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+AFAloOhsMACgkQEhdRnd2G P+DrUg//ah/+Clmr1uWRMY90pAFMm9BI4qkWzLzSOcq8Hb/K5gp2N52f9P77V8qM oUJQ+nRvUDcaQ2vDIkBLAACHNwRKOHpEIE5e5O1BVSTGmBdTPIlUvbyjXy4A2NIb hEc7OpaYKiwIZEhX535R7sbNmLwcyaa7GMFNr3d/RXEeh8X+wfN0fLxNYeTc1/vP c8WkvG8bRc9nuOufnk+h9GNlpmqEinrMIMscEp4H4EDj5o3KRnrNs9Iu15AY7SvS 2kqL79o5rHC3PRfL7PE6i5IYcSdm24+9gZOJFmh939nFhXCIv8LMvEBGz8DAJm1K NA5Uj0RgnGB6nw1iuSkyL0INa7er6XQnEGNAV1mLMG4YdCgwyTJmpItynWx2S0uq zalZsGeu+GpnZa6dx2nmCIYxOXiW6LQBnwt7zvvN0ZZg7brlAZDGhbmSIfecN9FZ VqOo3mTcFf2lr/0GVQU7QYM7jBc0dtSqgzw6RF2T+o+crtTePnqZsRfs+db2xlZe u5qBmcvT6KpVPduTpkd8AM5HvX7jHDZuIqrBvZt6v3Psy9tZFR6FwAVvDMK53xWC iamJGKbw5E4cqtBTaawQptr1rh5xo/gTYsh4X57Ci3PNIyfmPSjsepNjlNj/um27 ZcWm6A4ce9GI3/A7Dzq1IWBjx04ST0ovu8BW8QvQHEuJ+lRnKkM= =AG/i -----END PGP SIGNATURE----- --Apple-Mail=_36661FF2-8F7D-4502-AA08-9DDEF9E2AB3F-- From nobody Thu Nov 16 22:54:26 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D919D128D0F for ; Thu, 16 Nov 2017 22:54:24 -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 iQqLBLI1xyL7 for ; Thu, 16 Nov 2017 22:54:23 -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 C01331200E5 for ; Thu, 16 Nov 2017 22:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510901661; x=1511506461; 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=W+OYBVR+QMKP/sfl+F9jQIni3 VASG1dU1DbRq+9NVsg=; b=GmokG10UKB0pXwuJl+ggSPBxMKG1S93dJG1PSB008 2R3hcCt4F5cGBSt0Rttf2dPeV9kTFv7bh+ri+WXANnhQcADE5Y7F1YGSdCOTFZ6O 3oyiQgXoibMKVWt2AMoBdjSIp+BywtR8J0LFNSvS3MNFFHyfYmP98dkBtbWKqGrl zQ= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=JlRVP7Y7m2UcR5yZ0asnpMotPuBi8DphkgUCNEujXuMy6qdRbr9+MxWKAbHA QExlerPJByL1G0OGBK4UxjnSR0Dd+eBZe9TSwL1Phngg0whICbj52G39y 8dc/m+EoCbhASQfSEWbN2FsTnmK9OV/k31DuelC1PmS0z4AzgQjivc=; X-MDAV-Processed: mail.consulintel.es, Fri, 17 Nov 2017 07:54:21 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 17 Nov 2017 07:54:20 +0100 Received: from [172.20.60.6] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005626460.msg for ; Fri, 17 Nov 2017 07:54:18 +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:md50005626460::V0wmvh518zLuxF/n:00001OZc X-Return-Path: prvs=1494ff0e50=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Fri, 17 Nov 2017 14:54:01 +0800 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-he-reporting-00 References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 06:54:25 -0000 I believe most of the problem, according to my experience is beyond the acc= ess link, so that will ensure the reporting. IF the access-link is broken, definitively that ISP has a bigger issue. Furthermore, when considering, initially this draft, I was looking to a lon= g term, when the access will be IPv6-only, that=E2=80=99s why for me make s= ense to look into IPv6 reporting only. However, if we still believe it make sense to do the reporting with dual-st= ack, and that syslog is not the best way to report, then we can either find= another solution (any other commonly used reporting way that is common in = networks), or if we believe syslog is the way, we can change it to TCP to a= llow dual-stack fall back with HE, right? Regards, Jordi =20 -----Mensaje original----- De: Jen Linkova Responder a: Fecha: viernes, 17 de noviembre de 2017, 14:36 Para: Jordi Palet Martinez CC: "v6ops@ietf.org" Asunto: Re: [v6ops] draft-palet-v6ops-he-reporting-00 On Thu, Nov 16, 2017 at 4:58 PM, JORDI PALET MARTINEZ wrote: > And last one =E2=80=A6 I=E2=80=99ve already talked with Carlos, the c= o-author, in order to work on the path forward and how to make sure that se= curity/privacy are correctly taken into account in the document. > Also, I think we got the clear message that the reporting should be d= one with both IPv6 and IPv4 (as fallback by means of happy eyeballs). =20 If it's syslog, it's UDP. How are you going to implement HE?? Using IPv6 does not sound very helpful as IPv6 might be broken. Using IPv4 introduces a significant risk of those logs to be sent to anyone who advertises that /24. =20 I personally do not see much value in all that logging in general but it might be just me. However the solution currently proposed in the draft sounds very scary. =20 --=20 SY, Jen Linkova aka Furry =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Nov 16 23:24:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D7B12773A for ; Thu, 16 Nov 2017 23:24:48 -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 hscgClL0vQMg for ; Thu, 16 Nov 2017 23:24:47 -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 1C92812741D for ; Thu, 16 Nov 2017 23:24:47 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id 15so1265273wrb.5 for ; Thu, 16 Nov 2017 23:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Y80flHCi5xUxtWw/7B7zSKzmABjG8slCKIEfHMFlkDQ=; b=yxou27PcQwaum3vHtm3/hlJrEllTnep5L01UMEWzawcNmvZ1yGi/9BlzSL2rf+29E0 lTteFFA6KlN+09TRHgB2Tc4EfBG4dLbwn8IXeU40NKP0fkZLD0NIR6sCLzM47bPmaS0h YDsFjl5K/BoLwapgq9kmjsHdITV0RK2ilt8UDf5HRNN51L0U+OPEt8dGLwN1da0jbe2W PSa47Ak/30ASUKHItAxbvz64kImGzZ5ax/6Bk8hUrgLVPnLSBaoIMAJyzPlZkBF2elVM 3yNs414qntGQAZfX0GskJ9iMDL2YQZyvCSnxQR0+Iak9rawEd3PkS0rmdf8R5e8qTSk6 Q0zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Y80flHCi5xUxtWw/7B7zSKzmABjG8slCKIEfHMFlkDQ=; b=MXOWwr2QMHhMswzZpzjcZp65pd5HjJRbu0zYYyE8U09++P4KWddG0unw1BmAGeVued D1FlUnkT04vvxkfXq59y+4/AKy9Xwslj184asjG8+79SLFIxQb2OybZSSJWYa/a1GjIc YfCSlhkwrZj1CDXm2oxNwY2zWUDP3ZHR7GA0bTSgVtyMeyh1bbcGwJAQ1LoztB8hEU/D jlvQnmaNwKQXUKbvSJHDKL2XK9JHvbvHZ0RO1jN2iYxnfMA5K99BCqXPJpdCBjP29TFx wCLlBUeEWMqij2FaIqUl1pIO+AWUFmdGDxtcgyF7sDHFHF4hucp7iYwvNpZQdBtync9S Ou6g== X-Gm-Message-State: AJaThX7kkGEWRkrk89Dup/Pbfnr87gKeDCn0dDjNZnxLxWF+x5dCxpPQ ysMfUl9KJbTIFrPoYy327ZEcEtIH6eS0fH1mGUz+DcED X-Google-Smtp-Source: AGs4zMZ0bu68+qeuVP5tcaQjb/oHtugKubvgVhyBfc4urAxgsulE5Y3hh4ppD+zp7MDw/ubryHMNkr1cJczXWjc2cC0= X-Received: by 10.223.133.242 with SMTP id 47mr3714813wru.170.1510903484962; Thu, 16 Nov 2017 23:24:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.149 with HTTP; Thu, 16 Nov 2017 23:24:04 -0800 (PST) From: Warren Kumari Date: Fri, 17 Nov 2017 15:24:04 +0800 Message-ID: To: IPv6 Operations Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [v6ops] draft-ietf-v6ops-unique-ipv6-prefix-per-host -> Informational. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 07:24:49 -0000 Hi all, As mentioned in the WG meeting, after reviewing the document (and much discussed text), talking to an author, Suresh, and the rest of the IESG, we will be reclassifying this as Informational and proceed with publication. Once again, I'd like to thank the working group for all of your discussion / feedback / enthusiasm, and sorry this has been somewhat painful. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Nov 16 23:46:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Upleveling discussion (was Re: Stateful SLAAC (draft-ietf-v6ops-unique-ipv6-prefix-per-host)) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: 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 Fri Nov 17 00:20:07 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD45E129413 for ; Fri, 17 Nov 2017 00:20:04 -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 YV5mJId3VFen for ; Fri, 17 Nov 2017 00:20:02 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3814E129404 for ; Fri, 17 Nov 2017 00:20:02 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id a132so1748759lfa.7 for ; Fri, 17 Nov 2017 00:20:02 -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=IyenfTiEBW8/VxGb6JrWNGYqYDdmieIk4VbjUoKONC0=; b=trzLZ3Oo1uogZRX1H1L4L3f1Ryd03O7qZviat0hRcpaym14VqkG9oV4+IoS3Og5smI uXG+TBvp69KgVErm0jRa4cNa+9fhlxyqjq0TRF7Xeib9zLrY1QuLrTYHZNzgI4RC/tRw a31rX5Dl01SSHxS2ewme6qtCcuYmfTT58CFIkR0aYtu865VN6a6WYZJA3ofpVUk+qe0N HslyLSa6ebbNqoZFgWGJ6hzIkqq/pLpP2rDnEP8SNBwe9gLoN/lmJ0RKKVkEiBs1j/f5 jl1Fwc2BbK1DPImMPO7uloWfeu/WG8hJqHgyew1QXGiMLeT0pSwsyog4GDb1CAz8MyJI 1tlg== 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=IyenfTiEBW8/VxGb6JrWNGYqYDdmieIk4VbjUoKONC0=; b=O22EV7ykoT9fnDSz4wVBBBJAmvD6slRZDU/Cu0i2FnMPVqbFm9PspT8O6h6tJcnonG n524d9XtJDtb+Bswa0nMtfCAQwh/4CdfRkb3fB8A5r8limlnlgarzPK0Zhm+gpnr1RJk AqbYpi4FqS6V0v35FFe9FObJs1jkQDeqQTcRhwvz1w6NJe5/cMCRu2DJjsKFUD1X3rgk uXiRrKzLj5IzqIGWl2pnUP76tib6y+xxRd5qvZhFuqOI4efMPzr6H19YU1U3J9DJvcu6 HCvjwCayj1gaIb0RN3B0X7hCHzHgMSjOtLhe0Wm+1SiYctF6kpfKla1yR0XgGIMxIuja 7odw== X-Gm-Message-State: AJaThX4P3SL0F3MTCL9/zu+Wy0v1rk1alfMynv48lU+WiJQ9xyZGhrws enM1ee2GxMAEVuXWLLxbN/Exi9HmdrXEofYaeUg= X-Google-Smtp-Source: AGs4zMYCBXA4B84V5dkEu+0htDr0cEv9XF7a+BM8711jkssimPSwzsNlV3ukVToL3IdikMcr6DqySWqEkf0J4vFtkf8= X-Received: by 10.46.64.194 with SMTP id r63mr465835lje.112.1510906800309; Fri, 17 Nov 2017 00:20:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.205.2 with HTTP; Fri, 17 Nov 2017 00:19:39 -0800 (PST) In-Reply-To: References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> From: Jen Linkova Date: Fri, 17 Nov 2017 19:19:39 +1100 Message-ID: To: Jordi Palet Martinez Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 08:20:05 -0000 On Fri, Nov 17, 2017 at 5:54 PM, JORDI PALET MARTINEZ wrote: > I believe most of the problem, according to my experience is beyond the a= ccess link, so that will ensure the reporting. Our experience may vary. I've been seeing exactly the opposite. If the issue is within the operator's domain then that operator (if they care) should be easily able to monitor it (actually the hardest part is to monitor the access, especially for ISPs but even for enterprises...) If the issue is beyond their controlled domain, it will be totally non-actionable alert with almost zero value. > IF the access-link is broken, definitively that ISP has a bigger issue. which you are not trying to solve, correct? > Furthermore, when considering, initially this draft, I was looking to a l= ong term, when the access will be IPv6-only, that=E2=80=99s why for me make= sense to look into IPv6 reporting only. I need more coffee...Why are we talking about happy eyeballs if the access is Ipv6-only? Or what do you mean by 'access; in this case? > However, if we still believe it make sense to do the reporting with dual-= stack, and that syslog is not the best way to report, then we can either fi= nd another solution (any other commonly used reporting way that is common i= n networks), or if we believe syslog is the way, we can change it to TCP to= allow dual-stack fall back with HE, right? I feel like we need to stop asking. 'how?' before 'should?' ;) > -----Mensaje original----- > De: Jen Linkova > Responder a: > Fecha: viernes, 17 de noviembre de 2017, 14:36 > Para: Jordi Palet Martinez > CC: "v6ops@ietf.org" > Asunto: Re: [v6ops] draft-palet-v6ops-he-reporting-00 > > On Thu, Nov 16, 2017 at 4:58 PM, JORDI PALET MARTINEZ > wrote: > > And last one =E2=80=A6 I=E2=80=99ve already talked with Carlos, the= co-author, in order to work on the path forward and how to make sure that = security/privacy are correctly taken into account in the document. > > Also, I think we got the clear message that the reporting should be= done with both IPv6 and IPv4 (as fallback by means of happy eyeballs). > > If it's syslog, it's UDP. How are you going to implement HE?? > Using IPv6 does not sound very helpful as IPv6 might be broken. Using > IPv4 introduces a significant risk of those logs to be sent to anyone > who advertises that > /24. > > I personally do not see much value in all that logging in general but > it might be just me. However the solution currently proposed in the > draft sounds very scary. > > -- > SY, Jen Linkova aka Furry > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the= individual(s) named above and further non-explicilty authorized disclosure= , copying, distribution or use of the contents of this information, even if= partially, including attached files, is strictly prohibited and will be co= nsidered a criminal offense. If you are not the intended recipient be aware= that any disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 SY, Jen Linkova aka Furry From nobody Fri Nov 17 12:00:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FBF12948B for ; Fri, 17 Nov 2017 12:00:29 -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 mhTkFe5v7N4R for ; Fri, 17 Nov 2017 12:00:26 -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 8AE24129417 for ; Fri, 17 Nov 2017 12:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1510948821; x=1511553621; 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=vOQLl+wOt5TBFBswnizqtF2pj jYkTxreBw0Sqf+PXh4=; b=IpMYrEB+Tcax5M91LAsZ0VKvy4lMTvcjDYlZ/fd/n OegC6fyF9kO6V9cFI1XwmI2a/HkPuHrZh9eDjTniprjB/2LKI1AdwGxvoz6o0eZV +GApxZE2H6YzJhMLggmrl4kzc/bc6RKz8SPZbXydQDKK4d4vvi9DEi2OYp2Y34O0 as= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=TpUN6gOGXm5UpzQmIohNzTNdE5tAe6qbZDvLaVWWKsBpo9l1eOZorPpw98B2 BgctlpMHmVhxOvgGZDeRHk/cIGIMOFTORx9xksMbNec461eDPc1v/hEzA Oh+8wyYLKDmxoJz5bJGCXprRCoXqB4RM2CL/zl7++2eNxRRD8hka3c=; X-MDAV-Processed: mail.consulintel.es, Fri, 17 Nov 2017 21:00:21 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 17 Nov 2017 21:00:20 +0100 Received: from [172.20.60.6] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005627613.msg for ; Fri, 17 Nov 2017 21:00:19 +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:md50005627613::PH4eiW/guXz8ziEN:000060sO X-Return-Path: prvs=1494ff0e50=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Sat, 18 Nov 2017 04:00:12 +0800 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-he-reporting-00 References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 20:00:29 -0000 Hi Jen, Below in-line =E2=80=A6 Saludos, Jordi =20 -----Mensaje original----- De: Jen Linkova Responder a: Fecha: viernes, 17 de noviembre de 2017, 16:20 Para: Jordi Palet Martinez CC: "v6ops@ietf.org" Asunto: Re: [v6ops] draft-palet-v6ops-he-reporting-00 On Fri, Nov 17, 2017 at 5:54 PM, JORDI PALET MARTINEZ wrote: > I believe most of the problem, according to my experience is beyond t= he access link, so that will ensure the reporting. =20 Our experience may vary. I've been seeing exactly the opposite. If the issue is within the operator's domain then that operator (if they care) should be easily able to monitor it (actually the hardest part is to monitor the access, especially for ISPs but even for enterprises...) If the issue is beyond their controlled domain, it will be totally non-actionable alert with almost zero value. [Jordi] The presenter from Cisco also agreed with me that the problem is mo= re often at the destination (sometimes at the transit). In general, at leas= t the cases and customers I=E2=80=99ve, monitoring all the internal network= is easy (even the access), the problem is to know if the path from any par= t in the internal network to a give destination is broken with IPv6, but st= ill works with IPv4. My guess: 1) IPv6 transit becomes slower than IPv4 -> = happy eyeballs fallback with may be few ms among them, typically is a tempo= rary problem. 2) Wrong configuration of some box (or setting up AAAA when I= Pv6 is broken), IPv6 almost never come back, or the extra delay in ms is to= o high, and this is not-so-temporary problem. =20 > IF the access-link is broken, definitively that ISP has a bigger issu= e. =20 which you are not trying to solve, correct? [Jordi] Exactly, no need to correct that, because in that case, typically n= either IPv4 or IPv6 will work =E2=80=A6 and as said, ISPs typically notice = if the (customer) access-link is broken. For example, in GPON, they know ev= en if there are losses in packets, or dB, etc., and they get immediate aler= ts for that. For the =E2=80=9Coverall=E2=80=9D IPv4 and IPv6 transit, they = also get immediate alerts if something is wrong. The problem is when there = is a problem to a specific destination or set of them (for example a given = content provider) =E2=80=93 and in this case the problem may be only from t= he destination or (partially) the transit. =20 > Furthermore, when considering, initially this draft, I was looking to= a long term, when the access will be IPv6-only, that=E2=80=99s why for me = make sense to look into IPv6 reporting only. =20 I need more coffee...Why are we talking about happy eyeballs if the access is Ipv6-only? Or what do you mean by 'access; in this case? [Jordi] IPv6-only access doesn=E2=80=99t mean that you don=E2=80=99t have d= ual-stack at the customer LANs (DS-LITE, lw4o6, MAP-T/E, 464XLAT =E2=80=A6)= . =20 > However, if we still believe it make sense to do the reporting with d= ual-stack, and that syslog is not the best way to report, then we can eithe= r find another solution (any other commonly used reporting way that is comm= on in networks), or if we believe syslog is the way, we can change it to TC= P to allow dual-stack fall back with HE, right? =20 I feel like we need to stop asking. 'how?' before 'should?' ;) [Jordi] Agree, however, I=E2=80=99m clear that we should ;-) because it = is a real problem, and I=E2=80=99m not the only one has reports on it. I wa= s commenting with several folks (that you know), exactly the same issue whe= n I quickly presented it at the last IPv6 WG in the Dubai RIPE meeting =E2= =80=93 they come to me to tell =E2=80=9Cfinally=E2=80=9D we do something ab= out this =E2=80=A6 Of course, we can=E2=80=99t report =E2=80=9Cdirectly=E2=80=9D to the destin= ation if that's the problem, but the ISP that is suffering from frequent HE= fallback in its network, typically is interested in knowing 1) that this i= s happening 2) if happens only to few destinations or if they are related w= hich case, may mean same content provider or transit 3) if happens only fro= m specific customers or many (which may indicate a more local failure, or i= nternal to the customers networks, or CE configurations, etc.). =20 > -----Mensaje original----- > De: Jen Linkova > Responder a: > Fecha: viernes, 17 de noviembre de 2017, 14:36 > Para: Jordi Palet Martinez > CC: "v6ops@ietf.org" > Asunto: Re: [v6ops] draft-palet-v6ops-he-reporting-00 > > On Thu, Nov 16, 2017 at 4:58 PM, JORDI PALET MARTINEZ > wrote: > > And last one =E2=80=A6 I=E2=80=99ve already talked with Carlos,= the co-author, in order to work on the path forward and how to make sure t= hat security/privacy are correctly taken into account in the document. > > Also, I think we got the clear message that the reporting shoul= d be done with both IPv6 and IPv4 (as fallback by means of happy eyeballs). > > If it's syslog, it's UDP. How are you going to implement HE?? > Using IPv6 does not sound very helpful as IPv6 might be broken. U= sing > IPv4 introduces a significant risk of those logs to be sent to an= yone > who advertises that > /24. > > I personally do not see much value in all that logging in general= but > it might be just me. However the solution currently proposed in t= he > draft sounds very scary. > > -- > SY, Jen Linkova aka Furry > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 --=20 SY, Jen Linkova aka Furry =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Sat Nov 18 05:59:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BFC1270AE for ; Sat, 18 Nov 2017 05:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 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, 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 bYeQZGd0F2sU for ; Sat, 18 Nov 2017 05:59:50 -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 632F9120726 for ; Sat, 18 Nov 2017 05:59:50 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id EE7B7AF; Sat, 18 Nov 2017 14:59:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511013587; bh=xZL1+AKOr197WacTl9EyUhc+/jty/kRkoTJUpw3VsGE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=BqhL3YVNOJRA4AZW+9tKFShoa8ZuwOdmZYnIvZ5GG228vIiXUWQ0BJF7du6VSNDhw fgEI5p+x+9dp6D59P5Putmi9ZyrnW0zvMu3MxqlP0TjidUEDTwb/uimxLCOXRNekvE 0iLIy3LsFMAY9jriDaBt3s5p3LziI4cUtju4kHyk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E9F449F; Sat, 18 Nov 2017 14:59:47 +0100 (CET) Date: Sat, 18 Nov 2017 14:59:47 +0100 (CET) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ cc: v6ops@ietf.org In-Reply-To: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> Message-ID: References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> 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-2070612067-1511013587=:32099" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 13:59:53 -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-2070612067-1511013587=:32099 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 16 Nov 2017, JORDI PALET MARTINEZ wrote: > Does anyone have a suggestion about how to “secure” syslog, or an > alternative way for doing the reporting? There are multiple initiatives that try to have end devices talk to a "network information server" of some kind. It would be good if this work regarding HE failures could boot-strap off of their work. CAPPORT has their RA/DHCP options and a format to talk to something that regulates network access. ALTO has a network information server to get information about what networks that might be "better" or "worse" to send traffic to. The provisioning domain work in INTAREA (previsouly in MIF) has a JSON blob that will be downloaded, that could have information about what server HE failures should be reported to. All of these would be good if they were coordinated somehow, and clients would have a way to both get and send information to the ISP. The whole thing about blindly sending UDP packets to a well-known address is a complete no-starter for me. I like the idea of ISPs getting preformance reports from devices, but this is not the way to do it (UDP/SYSLOG). So we need to figure out how to send the reports, and what should go in the reports. Probably we also need different kinds of reports depending on privacy settings. A report that states "in the past day, I have had X HE failures for v4 and fell back to v6" etc would perhaps be ok even for the highly privacy minded, because it says very little about what sites were visited, just a generic failure metric. Also, as an ISP I would like to have a way for the user to report in more detailed information when they're for instance is in contact with customer support, to help diagnosing their problems. Would be beneficial if we had a standard way of doing that as well. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-2070612067-1511013587=:32099-- From nobody Sat Nov 18 08:05:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5310712741D for ; Sat, 18 Nov 2017 08:05:29 -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 3h506ryyr9MC for ; Sat, 18 Nov 2017 08:05: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 91F71120726 for ; Sat, 18 Nov 2017 08:05: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 50AFF80EEE; Sat, 18 Nov 2017 17:05:18 +0100 (CET) To: Jen Linkova , Jordi Palet Martinez Cc: "v6ops@ietf.org" References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> From: Fernando Gont Message-ID: <4d82a025-80d5-cd48-3540-65c38f86e2bf@si6networks.com> Date: Sat, 18 Nov 2017 20:28: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 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 16:05:29 -0000 On 11/17/2017 04:19 PM, Jen Linkova wrote: > On Fri, Nov 17, 2017 at 5:54 PM, JORDI PALET MARTINEZ > wrote: [....] >> Furthermore, when considering, initially this draft, I was looking to a long term, when the access will be IPv6-only, that’s why for me make sense to look into IPv6 reporting only. > > I need more coffee...Why are we talking about happy eyeballs if the > access is Ipv6-only? Or what do you mean by 'access; in this case? I haven't been following this thread closely, but... I'd note that the underlying issue that HE tries to address is not specific of mixed IPv6/IPv4 environments, but also present in IPv4-only, IPv6-only, etc: A server that is available on multiple addresses, some of which are unavailable, poses the same problem -- no matter whether the aforementioned addresses are IPv4-only, IPv6-ly, or mixed IPv6/IPv4. If a list of available addresses is tried in sequence, the potential for long details in "connection establishment" exists. 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:05:49 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690021275C5 for ; Sat, 18 Nov 2017 08:05:46 -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 92no-VuALw0h for ; Sat, 18 Nov 2017 08:05:45 -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 8FFD912741D for ; Sat, 18 Nov 2017 08:05:45 -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 3FCE180A81; Sat, 18 Nov 2017 17:05:36 +0100 (CET) To: Brian E Carpenter , "Templin, Fred L" , "Van De Velde, Gunter (Nokia - BE/Antwerp)" , Fred Baker , "v6ops@ietf.org" References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <43186ad6-dc2f-c9d8-2884-db4a097f142d@gmail.com> From: Fernando Gont Message-ID: Date: Sat, 18 Nov 2017 21:05:16 +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: <43186ad6-dc2f-c9d8-2884-db4a097f142d@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 16:05:46 -0000 On 11/16/2017 04:21 PM, Brian E Carpenter wrote: > On 16/11/2017 18:35, Templin, Fred L wrote: [....] > > I suggest > (a) changing the title. Something like "IPv6 Prefix Delegation Models". > (b) refactoring the contents to clearly separate the router-like > and host-like behaviours. > > Also, perhaps, identify any points that would be better moved > into 6434bis (or 6434ter). > > With those changes I'd be happy to see this as a WG draft. I agree with these. 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 Sat Nov 18 11:47:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB18126C89 for ; Sat, 18 Nov 2017 11:47: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 CU04d8bkiZJ7 for ; Sat, 18 Nov 2017 11:47:56 -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 4893D1200FC for ; Sat, 18 Nov 2017 11:47:56 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id a84so4371465pfl.0 for ; Sat, 18 Nov 2017 11:47: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=LzVlTtYDtTvwRo63Qf8ZT+9unIS75+7R/4FUC6iqIEQ=; b=YzCcKgTsiginqWlGEGxy/7+6RZzRhVx5aurtTRTk6SFQt+4+vtT55wiRHDvi+0BMci uewEXM17D+Ni+WoD7dA1ainE3WEmJauGIwZU6+uK6W4uDTqLPJzlA9UJ3S7iOTbgyLyZ VCnqrsfJY0XEWMbT1PKrFZVyDUbNOgHq6204P/zP7+IW5nFWJ7K1rUHjGu6auF1OUe61 T6jN4TBFUYdqfCb6BlcBj7GZSMLbVNXDD5CHyNFsAPIbxGO2H64Qb3b/Wqvs+4swjE+B 8sydD1irNLoeIsbw5TNs5+cVPvrtrx8q2LHDqtViAn1ApwazHqHkibYCN5o+JZDz1zKx PpIA== 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=LzVlTtYDtTvwRo63Qf8ZT+9unIS75+7R/4FUC6iqIEQ=; b=ZYSPhVAD4F9erN5GJUuyMJNII9hkGAam3VAPgZAyjvIAqGJ1ANF1cmRWKPBnsKtX0/ Eb2sHY4sVQW1oeeihn42+z7irazxAdiPpQueGDNgwKGY9tiFjxHqqzM9y1UUxAgU/L60 dQZQlQoKgg6AFm1yRnZ+/9vwktaW1cZe5OwTdHA8fHS3DJ/16uF8YRdCKG+XpGge7BpJ Z1ToHNkdQynXV11X/rWkiltRmws/EPAzI6X86G27Ch8DG6IDUlstFVsBdukFWeSIcG9O ZAiWVQoN/Lxjx6xGCpn4ctLU5TmkzQrspi+nnOtdK7k/z5uz4OKscmV2tbDWCuMFteWS uKgQ== X-Gm-Message-State: AJaThX7M095fsEpg0MteXrPHsFf4B8sySnxSfI9uJ67X4dzD1dDsYt5W jcWGhQu/R8k4UkO60agVzqNiKA== X-Google-Smtp-Source: AGs4zMYSVAUpmllBoJTdbuwywzO8DlVzznDhoizTchNf0NY7zeOfFvqVK0uTfwRYFeCMum3Pnor3zA== X-Received: by 10.98.69.86 with SMTP id s83mr6244025pfa.32.1511034475477; Sat, 18 Nov 2017 11:47:55 -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 v28sm12309386pfl.118.2017.11.18.11.47.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Nov 2017 11:47:54 -0800 (PST) To: v6ops@ietf.org References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> <4d82a025-80d5-cd48-3540-65c38f86e2bf@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sun, 19 Nov 2017 08:47: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: <4d82a025-80d5-cd48-3540-65c38f86e2bf@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 19:47:58 -0000 On 19/11/2017 01:28, Fernando Gont wrote: > On 11/17/2017 04:19 PM, Jen Linkova wrote: >> On Fri, Nov 17, 2017 at 5:54 PM, JORDI PALET MARTINEZ >> wrote: > [....] >>> Furthermore, when considering, initially this draft, I was looking to= a long term, when the access will be IPv6-only, that=E2=80=99s why for m= e make sense to look into IPv6 reporting only. >> >> I need more coffee...Why are we talking about happy eyeballs if the >> access is Ipv6-only? Or what do you mean by 'access; in this case? >=20 > I haven't been following this thread closely, but... I'd note that the > underlying issue that HE tries to address is not specific of mixed > IPv6/IPv4 environments, but also present in IPv4-only, IPv6-only, etc: >=20 > A server that is available on multiple addresses, some of which are > unavailable, poses the same problem -- no matter whether the > aforementioned addresses are IPv4-only, IPv6-ly, or mixed IPv6/IPv4. >=20 > If a list of available addresses is tried in sequence, the potential fo= r > long details in "connection establishment" exists. Sure. And these issues crop up for MPTCP and SHIM6 too. https://tools.ietf.org/html/draft-naderi-ipv6-probing-01 Brian From nobody Sun Nov 19 02:15:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0BC126CD6 for ; Sun, 19 Nov 2017 02:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.408 X-Spam-Level: X-Spam-Status: No, score=-0.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGiD0uVQSIVE 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 94AB11243F6 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=1511086162; x=1511690962; 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=vNymCcy+Td3Y2X1Ux5jaZnr1U 1S9fvAv/1yoY30cVS0=; b=gWrr9JVuLnU8+MjY3ZOMvKMFGeZ+l6+p1fPKSPFFi 7y60rstA7eFUBrYJ97SGTRMDVfN+KLBnEPoNlOjVsks3euhsURdE8X2aJewW7D4a PmnNZQWQn4OfiXSNNwfHCHIxnHYpaPf4Q4j75z8EWpD7NL4GlTEMUFJBqHKekjMY wA= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=nGpLSP2hZqiHA/HKy4pMq9EJDuUev6oLMghNG+vNuq8NaNfokNyF7yTmdhHG O1p8fslYNdVmBx/+OwOlxFQCormd1vESbfbL/3toJqNcZgb2niD0Ypvjq nRC/ionUqTcQnniGu5J2HBUE9y0TohvODxiRbJ9fpCm8rNoaVzgkKc=; X-MDAV-Processed: mail.consulintel.es, Sun, 19 Nov 2017 11:09:22 +0100 X-Spam-Processed: mail.consulintel.es, Sun, 19 Nov 2017 11:09:19 +0100 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005629747.msg for ; Sun, 19 Nov 2017 11:09: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:171119:md50005629747::31alSQ5z7UR07Eje:00000uMw X-Return-Path: prvs=14962de760=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Sun, 19 Nov 2017 07:03:45 +0000 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-he-reporting-00 References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 10:15:08 -0000 Hi Mikael, Thanks a lot for all this info. I will definitively take a look. My reason to choose, as an initial approximation, syslog, is because this i= s often present in even the smaller service provider network, so it is a si= mple way for all them to deploy it, as simply requires having the correct a= ddress setup in the actual syslog server and you=E2=80=99re done. My fear with any other alternatives is that they aren=E2=80=99t deployed. S= o, we will need to investigate first which one has a global deployment or i= f there is a way to secure syslog/TCP. Someone suggested me to use Netflow, but I=E2=80=99m not really sure it can= be used to detect those failures including the failed destination. I think not reporting the source address is fine, but not reporting the des= tination becomes useless, because then the ISP can=E2=80=99t see where is t= he source of the problem. >From a privacy perspective, I still believe that if the ISP needs to log th= e =E2=80=9Cfailed=E2=80=9D destinations, this should not be a privacy issue= . I believe regulations allow that if this is needed for O&M. Of course, wh= at law doesn=E2=80=99t allow is any further usage of that data or even less= disclosing it to third parties. Regards, Jordi =20 -----Mensaje original----- De: Mikael Abrahamsson Organizaci=C3=B3n: People's Front Against WWW Responder a: Fecha: s=C3=A1bado, 18 de noviembre de 2017, 13:59 Para: JORDI PALET MARTINEZ CC: Asunto: Re: [v6ops] draft-palet-v6ops-he-reporting-00 On Thu, 16 Nov 2017, JORDI PALET MARTINEZ wrote: =20 > Does anyone have a suggestion about how to =E2=80=9Csecure=E2=80=9D s= yslog, or an=20 > alternative way for doing the reporting? =20 There are multiple initiatives that try to have end devices talk to a= =20 "network information server" of some kind. It would be good if this wor= k=20 regarding HE failures could boot-strap off of their work. =20 CAPPORT has their RA/DHCP options and a format to talk to something tha= t=20 regulates network access. =20 ALTO has a network information server to get information about what=20 networks that might be "better" or "worse" to send traffic to. =20 The provisioning domain work in INTAREA (previsouly in MIF) has a JSON= =20 blob that will be downloaded, that could have information about what=20 server HE failures should be reported to. =20 All of these would be good if they were coordinated somehow, and client= s=20 would have a way to both get and send information to the ISP. =20 The whole thing about blindly sending UDP packets to a well-known addre= ss=20 is a complete no-starter for me. I like the idea of ISPs getting=20 preformance reports from devices, but this is not the way to do it=20 (UDP/SYSLOG). So we need to figure out how to send the reports, and wha= t=20 should go in the reports. Probably we also need different kinds of repo= rts=20 depending on privacy settings. A report that states "in the past day, I= =20 have had X HE failures for v4 and fell back to v6" etc would perhaps be= ok=20 even for the highly privacy minded, because it says very little about w= hat=20 sites were visited, just a generic failure metric. =20 Also, as an ISP I would like to have a way for the user to report in mo= re=20 detailed information when they're for instance is in contact with custo= mer=20 support, to help diagnosing their problems. Would be beneficial if we h= ad=20 a standard way of doing that as well. =20 --=20 Mikael Abrahamsson email: swmike@swm.pp.se ********************************************** 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 03:12:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E0B1200CF for ; Sun, 19 Nov 2017 03:12:17 -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 FPZcUWiN3zE1 for ; Sun, 19 Nov 2017 03:12:15 -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 B170E1200C5 for ; Sun, 19 Nov 2017 03:12:15 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2FC17AF; Sun, 19 Nov 2017 12:12:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511089933; bh=eHz/q7V6v0G+immsbrrfQz0T7C36v0+pcxojVIQkBx8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=CFv4BnpxA4tsU7OSYWzT2IEsznSzHCSA7pNUTEV+ElUFXM5O2KenOPMifx8ni6Ues DPTzV4+2H+2drSoktvTRX3zsH4L7Jvqhy9uHadWLtlGmspywaxzZF2ideAUWR5J7Jg DNhAwk3+yPTGKkqEF30PS9qyk7hgtSPNnsgv4CCU= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2BB379F; Sun, 19 Nov 2017 12:12:13 +0100 (CET) Date: Sun, 19 Nov 2017 12:12:13 +0100 (CET) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> 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-1048616530-1511089933=:32099" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 11:12:17 -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-1048616530-1511089933=:32099 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 19 Nov 2017, JORDI PALET MARTINEZ wrote: >> From a privacy perspective, I still believe that if the ISP needs to >> log the “failed” destinations, this should not be a privacy issue. I It is a privacy issue. Huge one. Yes, it can be argued that the ISP can do the same thing by looking at DNS query logs, but it's still a privacy issue. As an ISP I would more like to understand if I have a problem in my own network. So getting hourly or daily statistics about HE failures tied to a certain customer connection would be nice (not reporting destinations, only source). I don't think this should be a privacy issue in practice, even though there might be some theoretical ones. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1048616530-1511089933=:32099-- From nobody Sun Nov 19 03:14:05 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB30D1200CF for ; Sun, 19 Nov 2017 03:14:04 -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 IHGAxGbDAwbP for ; Sun, 19 Nov 2017 03:14:03 -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 79C891200C5 for ; Sun, 19 Nov 2017 03:14:03 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 195D2AF; Sun, 19 Nov 2017 12:14:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511090042; bh=0Uuq7l2DMlpiBd7pMi/ToIkB6w6zotvHkcN1PI2apWk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=sQ7Sn/33E0pq+Oo74juEnNcTNkgdd9pIAaIry4pQclivdX1sURrNw4lW0PcqAmIaM mOqz22vrMC2cab4TOQjW6x2nql0yw8tLfko0xCmhflLpZBedfSji0IYcz+bBSwKdfy xgLbgqV+UajLBMu8LESA1+N4PaiBsgTQwv3UCBXI= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 169519F; Sun, 19 Nov 2017 12:14:02 +0100 (CET) Date: Sun, 19 Nov 2017 12:14:02 +0100 (CET) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> 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-1365085652-1511090042=:32099" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 11:14:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1365085652-1511090042=:32099 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 19 Nov 2017, JORDI PALET MARTINEZ wrote: > I think not reporting the source address is fine, but not reporting the > destination becomes useless, because then the ISP can’t see where is the > source of the problem. Btw, it would probably be better if there was an HTTP standard to report HE statistics to the web server in question. Then I imagine there are no privacy issues (because you're already speaking to this web server). So a new header type, perhaps? I am no HTTP expect... -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1365085652-1511090042=:32099-- From nobody Sun Nov 19 04:40:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7E1127077 for ; Sun, 19 Nov 2017 04:40:43 -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 wg9y9bvWVnHa for ; Sun, 19 Nov 2017 04:40: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 E0D0F126E01 for ; Sun, 19 Nov 2017 04:40:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 760364A; Sun, 19 Nov 2017 13:40:38 +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= 1511095235; bh=f+3z0Gbjr1fB+v6ZzNhp55o8dB4RFOSgf/jSeRoi9ms=; b=r CIsaaNcGp5RjZ1dX1t2I2nAwnxhJk9+EaYZ7YtahTne6ykVIs684NS9CCBqfasfH D9NtyL0iiAPDTubUdS9wZ+nnAGGeDBXX5Q/A8vdR9os0tir4jKH6kd3LgE59BBDy dnwZtFjatC/NYQhMm8Y1YU7OdwWwfz9dTPaRCGva0A= 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 OO-Vsrk2QPD4; Sun, 19 Nov 2017 13:40:35 +0100 (CET) Received: from [IPv6:2a02:a213:a301:1000:dced:10c7:4ae8:d621] (unknown [IPv6:2a02:a213:a301:1000:dced:10c7:4ae8:d621]) (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 062F849; Sun, 19 Nov 2017 13:40:34 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: Date: Sun, 19 Nov 2017 13:40:33 +0100 Cc: JORDI PALET MARTINEZ , v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 12:40:44 -0000 Hi, > Op 19 nov. 2017, om 12:14 heeft Mikael Abrahamsson = het volgende geschreven: >=20 > Btw, it would probably be better if there was an HTTP standard to = report HE statistics to the web server in question. Then I imagine there = are no privacy issues (because you're already speaking to this web = server). >=20 > So a new header type, perhaps? I am no HTTP expect... That sounds useful. Content hosters/owners have an interest in looking = into issues/delays/etc that their users might have. It's a different = target group than in Jordi's draft though, so the ideas are not mutually = exclusive. I think reporting HE information to the webserver would be useful and = I'd happily help with writing a draft if more people are interested. Cheers, Sander From nobody Sun Nov 19 05:07:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F240127077 for ; Sun, 19 Nov 2017 05:07: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] 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 hukMRqwb4bRo for ; Sun, 19 Nov 2017 05:07: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 B9018127873 for ; Sun, 19 Nov 2017 05:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511096039; x=1511700839; 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=QY0H/zfZcrYoiwG4pLyWIpqfV VODHHQiHh9gH4KILZ0=; b=GtXXsRQuGEg4WwlWJNz/E2b207C80FSE24fefSLBi nsmFjbfwGHwegT5RFT61/NSVVZulkbnTnGIVFw3U1Huub9+Bj2ynCfJqxk8vDQck TIhDjJsWl+7Q4RZS5ubvftgU8q6oYNINjNh/r4WN38r0SqgtG1jYIG/JIUEUjyef YU= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=sMkfGVbmdZnegG4MLVs0nHV+Oxp7vCEc7sfTq+cAMMWWSodl+4w7qrTItqeJ Yr5drCu5aHBqb9TA7FC7RUVb/hv7l9wzT4cShIZEcYTYVgjWQZASTPwwt 8uYa6Oot8IhL1FC6dNJDoGzlvV9y6egiVfQGPp5nWCFFl8+K9t6v2w=; X-MDAV-Processed: mail.consulintel.es, Sun, 19 Nov 2017 13:53:59 +0100 X-Spam-Processed: mail.consulintel.es, Sun, 19 Nov 2017 13:53:58 +0100 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005629900.msg for ; Sun, 19 Nov 2017 13:53:57 +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:md50005629900::d31VBrLbivGs5jmx:0000AqG0 X-Return-Path: prvs=14962de760=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Sun, 19 Nov 2017 13:53:53 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-he-reporting-00 References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Reply-To: jordi.palet@consulintel.es Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 13:07:33 -0000 Hi Sander, I will be happy to help if this is the =E2=80=9Cway to go=E2=80=9D, however= , my concern =E2=80=A6 do you think content providers will make use of this= ? What happens if the HE fallback is not a webserver (http/s) but some other = service? Basically, those questions were the ones, in addition to make it simple to = deploy, that I initially considered when started with this document. Regards, Jordi =20 -----Mensaje original----- De: Sander Steffann Responder a: Fecha: domingo, 19 de noviembre de 2017, 13:40 Para: Mikael Abrahamsson CC: JORDI PALET MARTINEZ , Asunto: Re: [v6ops] draft-palet-v6ops-he-reporting-00 Hi, =20 > Op 19 nov. 2017, om 12:14 heeft Mikael Abrahamsson = het volgende geschreven: >=20 > Btw, it would probably be better if there was an HTTP standard to rep= ort HE statistics to the web server in question. Then I imagine there are n= o privacy issues (because you're already speaking to this web server). >=20 > So a new header type, perhaps? I am no HTTP expect... =20 That sounds useful. Content hosters/owners have an interest in looking = into issues/delays/etc that their users might have. It's a different target= group than in Jordi's draft though, so the ideas are not mutually exclusiv= e. =20 I think reporting HE information to the webserver would be useful and I= 'd happily help with writing a draft if more people are interested. =20 Cheers, Sander =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 Sun Nov 19 05:43:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D1F127F0E for ; Sun, 19 Nov 2017 05:43:15 -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 e9rfYLLzNfXH for ; Sun, 19 Nov 2017 05:43:14 -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 E0376127B5A for ; Sun, 19 Nov 2017 05:43:13 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 50889AF; Sun, 19 Nov 2017 14:43:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511098991; bh=E+F+jJ2TwH0a6Qoypnwo10QI7fdB/KujGoJPY+C/EEA=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=TeIoQhSY0wCtNDpjpmQtRDRUYxoO1iyQYp4UkVsOVdN7N/rgT/kgIddUcOI01hrlQ HRl484mRGndaWopHDrw+H9c0ZgWTRTa+gLib+ZJ4EIl3RX7L9kM8TW2Q6KVC/Y2Wni tX5mytAoBEJvmB61CdeeJLS/34Bv99+Z3rALfzwE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4CFE29F; Sun, 19 Nov 2017 14:43:11 +0100 (CET) Date: Sun, 19 Nov 2017 14:43:11 +0100 (CET) From: Mikael Abrahamsson To: JORDI PALET MARTINEZ cc: v6ops@ietf.org In-Reply-To: Message-ID: References: <1099A65E-2CE3-4E67-A57F-5D1EAFA11722@consulintel.es> 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-1198451963-1511098991=:32099" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-he-reporting-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 13:43:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---137064504-1198451963-1511098991=:32099 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 19 Nov 2017, JORDI PALET MARTINEZ wrote: > I will be happy to help if this is the “way to go”, however, my concern … do you think content providers will make use of this? > > What happens if the HE fallback is not a webserver (http/s) but some other service? > > Basically, those questions were the ones, in addition to make it simple to deploy, that I initially considered when started with this document. I think both ISPs and the people hosting the information are interested in this information. I fully support it being reported to both, I just don't think sending syslog blindly using UDP is the way to do it. So the idea is great behind this draft is great, I just think the current suggested way of sending the reports isn't going to get enough support. I am also not a stranger to having aggregate information being sent to some kind of neutral third party, regularily. Right now I think some device vendors collect this kind of statistics, but I don't know exactly what is being collected and how it's used. -- Mikael Abrahamsson email: swmike@swm.pp.se ---137064504-1198451963-1511098991=:32099-- From nobody Sun Nov 19 17:27:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8490E1201F8 for ; Sun, 19 Nov 2017 17:27:55 -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 JXuYQJdZS2Gr for ; Sun, 19 Nov 2017 17:27:53 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 E12571241FC for ; Sun, 19 Nov 2017 17:27:52 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id s4so6404182ote.4 for ; Sun, 19 Nov 2017 17:27:52 -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=NxSeyke2d740RcpMhQkywuCt2mRaMx0uEEkmKYwUzqQ=; b=rqZ/ClSBOSTRULJxVgw74u7TGD5cgr6Nu8JCmWHcwrMfrSqY9B8tVh7ph8Z++Oroid tHc8oKY/oD3KFmvbY0PIrhHfoaQIunrWSTP57oATemtRRR27TG50VskEbDX3zYCezrb1 fHzPLHs525KsCrXel9vAaPgfBWrNv578JK982iHgICLm/VaEtgW/4kb1E5sn0yc3WZTb kTc9WWgoreYeH+pN/IKSk6qYJGZHVBOSEW8zXIEiagTz3v4OGLFWlINjlrWDe7tmp9mN gk9nmlCiIeMkstGSA8TMFeLxJu5/GxHlL6Aq8EMz2O+Zkg4wB1+l4It+uSlrOkn5heEu xG3w== 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=NxSeyke2d740RcpMhQkywuCt2mRaMx0uEEkmKYwUzqQ=; b=IBTCEvCJ09maI5ozgaIdadhmDE1ppxp6SeBw04Z2VJyiQy03jSRfHi/AS7ErvqIP3T ibvL8xYT+QFUwJ7+zZ1oRgjd8EiMfUEVUWPcvzxxyjRQM3+j/OJTMlYClCarg4mdwekP egjaIAgG1rVvnqRNrG8ekRCwUHId8aFW8GYqKcYss6Fo6YZo9E03aXTsQVWcU3pGZEg0 odmHhHNlYmLsPTfD88n1O+34TT550Q2yfBCuEQtAhKHaGppeHVxzwQWIwjVaEUyDFJ/3 v89uE3mhS5665IfFUXlcF21wKFIp7IZJXordg0Aqh4UtAGL76P5T0I14V2/dFLHWyt5r 0R1w== X-Gm-Message-State: AJaThX7jUUv4hL13/UXOfwFPqFwHYJPWBT6z3rg2ClQjdls3uhg8t3KD sX+UqvcPV1+HLJbqHWFiUI8= X-Google-Smtp-Source: AGs4zMajoghW30j/nah/qLPIJnIBlhcZ2qtJEyyHSDqGuEV+OMRr8Oz0VUssjxj4t3uh41mVfA+PJQ== X-Received: by 10.157.21.49 with SMTP id u46mr7132429otf.361.1511141272372; Sun, 19 Nov 2017 17:27:52 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::1005? ([2600:8802:5600:f7a::1005]) by smtp.gmail.com with ESMTPSA id z96sm4354075ota.30.2017.11.19.17.27.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Nov 2017 17:27:51 -0800 (PST) From: Fred Baker Message-Id: <9FDA6FE7-C03C-4AA9-BED4-F0D7ED63FBBF@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5E1DBB8E-7A64-4B78-86A8-A8243B4F481B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 19 Nov 2017 17:27:49 -0800 In-Reply-To: <655879d9e7274da88ee2cd33a0202dd7@XCH15-06-08.nw.nos.boeing.com> Cc: "v6ops@ietf.org" To: Fred Templin References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <43186ad6-dc2f-c9d8-2884-db4a097f142d@gmail.com> <655879d9e7274da88ee2cd33a0202dd7@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [v6ops] Who implements the DHCP service? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 01:27:55 -0000 --Apple-Mail=_5E1DBB8E-7A64-4B78-86A8-A8243B4F481B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One comment on the draft in question. Looking at figure 1 (applies to all of the figures, but let me be = specific for the purposes of a comment) I don't see any reason to = believe that the node marked "Delegating Router" is in fact a router or = is connected directly to the "Upstream Interface". AFAIK, given the = relay capability present in RFC 3315, the common practice is to have a = more central server respond to IA_NA and IA_PD requests, and simply have = a router connected on the ISP link. That might get complex to draw in a = figure, but I'd worry about any implicit assumption in the WG version of = the document that only routers implemented the PD service. --Apple-Mail=_5E1DBB8E-7A64-4B78-86A8-A8243B4F481B 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+AFAloSL5UACgkQEhdRnd2G P+BL/g//Wmfigd8zOumXAW2CxEBmAGeI8QE9PYYgPTfkkKxZnhrM853D41vJ6oGO mGY+9R4jcYjjktbQOt1ccn+cfy7fqR6dWv55diXroitb9qUITaDesGvw82Qfj69Y S+F5DwnLbMeYLuHf4Azd63V0ptsQIe6dzAiyvmJnwRZiL8r4HS73X/Q5pMoCJ6Xl +fkbptFTmG58hYuaTUO89ZaaiZjwE4GlVwDOBKpHfx5xEzi1aSmSBnocQzFyvOQo G9L2mNEOO0JX0i1Tj8llwS8lZYWT4bhl9zLieyioELoz0bF1gSJTjgMsA/1CI1KP ahi1e+vsqT+RS5eyYzpPUgvIOHoeW4hFLblrATaABfY3J3cr6Z8P6QyQS8oAt77N USQuD+OezAC7EbT/5tlflGonunYm4sRg/HEkvKKrupPxSyac9ZZ3Ik0GQHSN1qp2 IqSuqls9PQ1H925Luh+eYyqa1jWvohFAAal41322/SJchq6/aUuvAk2McRM6SVpL uOZCsPwnSH9FEvua9gT0aVuQ6CHuKDIGDGlhBjr2uCv5Q2Whooo16VffSbM1motK Vxl2rvQVbAdrmPh85rgxgTBF8NShSsYvtE2B1H4z1OZ1UX4lPiFzHkadmP6ij84E VrARF2qdPyQTrVGPIxtSshu/o/5t3RRs7KMRL/sm3oRbIcgNMhA= =Xeme -----END PGP SIGNATURE----- --Apple-Mail=_5E1DBB8E-7A64-4B78-86A8-A8243B4F481B-- From nobody Sun Nov 19 17:36:54 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA52126B6D for ; Sun, 19 Nov 2017 17:36:53 -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 qnVZ7j0CgKo1 for ; Sun, 19 Nov 2017 17:36:51 -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 A83C51250B8 for ; Sun, 19 Nov 2017 17:36:51 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id n134so10063442itg.3 for ; Sun, 19 Nov 2017 17:36: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=QjlWWDi81Y6CT81w/fySqbMvVfs2K1XU0ijliaPh7js=; b=JiR7FV+umhT55geDMuFYpkI2oxChxnuCp8FwF8MjYXdtmKWBUZGjBg4PkjtNLYrfSA Hwve3AXG2e+ikacYfVrpV8S17dLYvB0sUUMDTjxJib6ocAVBiEjHwWPs+GcfeiN7FoJo EB2wgNoKM+STx7s3Z+iUaNAjk66iM9d7x6O4Cky5sVJBTou3EyQRqDSx0WuMDST8T1U6 IoJZH0MQ2oXXaWy8yWScHWB4gKt5Zrcwl4dKzQtFm53AZ1PO4PYVhsNGsApmi2ojBhn8 1yJiosmPqmSVXCtfgB/awSBdNt8jg1IMCJs7+5AWgsxW4VPOoC3mAKM0m6jDqHbkG2PX nOZQ== 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=QjlWWDi81Y6CT81w/fySqbMvVfs2K1XU0ijliaPh7js=; b=MLNHh2anAMmsgxX+jNcEv5HAgjUZwcd/HjQC4e0ilD7JGVlrSYP/b0G/pJwZXTL0mo BQraLfTeYqfOSQJ1IzjagjSr/NiIkGPv0+NtPJLLD2ck1WI3NGrQmKFHFrYzQHPNpdpF RySKdIc++DUlxFZiYyEWCxHRoUcrMuMPkln/7FrXVnW3Rt9BrX8w7CKtK8civ0+ZQ60P s5TsIk8aI1TpOM2GashNSVz4UC3CGF6D3IDTWpQ0jzEMW+S0R0TbAWMTRFoZ+Esxgqml 32SLcdmzheF8FjVZINhjAur8Q42F+cpXV92DhYhL5ahkYarMjm+b/fOckO9RsznTKHmQ t/+A== X-Gm-Message-State: AJaThX7cKWyUPFBJq+RFk6FFKPc4KVupMUA9r0QXYKhsAIZ4JtZ5kn8I eqDVbiUBK4jukqlNHzVo4LD/lOUwLDPJexsAUb4DrA== X-Google-Smtp-Source: AGs4zMbSnwAy7mmOlTK3jiyuaDn37v9jGXwW8IcQdfG82/JD4FvLjoIVFNFqamJadeTBMicMaBpXruvilidbtWAs06c= X-Received: by 10.36.81.21 with SMTP id s21mr16785639ita.144.1511141810504; Sun, 19 Nov 2017 17:36:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.16.155 with HTTP; Sun, 19 Nov 2017 17:36:29 -0800 (PST) In-Reply-To: <9FDA6FE7-C03C-4AA9-BED4-F0D7ED63FBBF@gmail.com> References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <43186ad6-dc2f-c9d8-2884-db4a097f142d@gmail.com> <655879d9e7274da88ee2cd33a0202dd7@XCH15-06-08.nw.nos.boeing.com> <9FDA6FE7-C03C-4AA9-BED4-F0D7ED63FBBF@gmail.com> From: Lorenzo Colitti Date: Mon, 20 Nov 2017 10:36:29 +0900 Message-ID: To: Fred Baker Cc: Fred Templin , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a113a7146d2b95c055e601e98" Archived-At: Subject: Re: [v6ops] Who implements the DHCP service? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 01:36:53 -0000 --001a113a7146d2b95c055e601e98 Content-Type: text/plain; charset="UTF-8" +1, in most scenarios the delegating node does not have an interface connected to the requesting node. On Mon, Nov 20, 2017 at 10:27 AM, Fred Baker wrote: > One comment on the draft in question. > > Looking at figure 1 (applies to all of the figures, but let me be specific > for the purposes of a comment) I don't see any reason to believe that the > node marked "Delegating Router" is in fact a router or is connected > directly to the "Upstream Interface". AFAIK, given the relay capability > present in RFC 3315, the common practice is to have a more central server > respond to IA_NA and IA_PD requests, and simply have a router connected on > the ISP link. That might get complex to draw in a figure, but I'd worry > about any implicit assumption in the WG version of the document that only > routers implemented the PD service. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --001a113a7146d2b95c055e601e98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1, in most scenarios the delegating node does not have an= interface connected to the requesting node.

On Mon, Nov 20, 2017 at 10:27 AM, Fred Bak= er <fredbaker.ietf@gmail.com> wrote:
One comment on the draft in question.

Looking at figure 1 (applies to all of the figures, but let me be specific = for the purposes of a comment) I don't see any reason to believe that t= he node marked "Delegating Router" is in fact a router or is conn= ected directly to the "Upstream Interface". AFAIK, given the rela= y capability present in RFC 3315, the common practice is to have a more cen= tral server respond to IA_NA and IA_PD requests, and simply have a router c= onnected on the ISP link. That might get complex to draw in a figure, but I= 'd worry about any implicit assumption in the WG version of the documen= t that only routers implemented the PD service.

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


--001a113a7146d2b95c055e601e98-- From nobody Sun Nov 19 17:42:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF727126B72 for ; Sun, 19 Nov 2017 17:42:42 -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 hJKONENtM5J2 for ; Sun, 19 Nov 2017 17:42:41 -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 8BABF1201F8 for ; Sun, 19 Nov 2017 17:42:41 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id i38so14170318iod.2 for ; Sun, 19 Nov 2017 17:42:41 -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=KuUYX2DvPlvQl/G5oYiGD3j/ToxGHpR3wQbyZpqIh4Q=; b=jp8Bx80blGcyfLrLgZI9UvIObnCwvu8aR0bZT4mIfrS6Re/pKc28D79fW+guWAPq3G RT5MUvUQhde4jc3csnSqfdtNo22WIYsypiliOmdbX6NzLStpdZtZ03GjiwI1dGaz3djV 7xBLmtdcSGKc6tKvWMOHpMpSLtOkyywJyIssmmOorpJy9ri4MoQVoFjZur+M8rIRPTcA s4ScKXGOaKH3fgMclasaGDVIytLJCqWNl0G254K4NHne+a1NblrtbPzEkIlr7TbtN5GO 0iZYXS0GXDDliAY8OY/h8OVuKpch86Wp0Mf+FXU9nRXbYbpg55h+JGhQ3VSq/6j5xhX3 c1bA== 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=KuUYX2DvPlvQl/G5oYiGD3j/ToxGHpR3wQbyZpqIh4Q=; b=RQ8yxfzY9AoDEr/t/CGhDeSgVjYmPSpDF8jq8TTKdWMGl+S50xGoGrspkNKQuTrBQq fLkTYS4L7EXiZxLFTpBDc5+Uo2NMCzYGx9yJsi5Snv25O+kTTxhuhmoqwZb+cZYz68Pv slf38QBtaM4ZjOohdyDRDqmRIFcd2M2IHKZuqfvPHHBWRBwMx7OpommEs3ZWvgQGj6fT 6tgflu2h+u4JyFbaeW7dL25hUTF3XU/mkQv1YjLSQdja+pF7SgJHsiRJrv13g7t/6tqe KI/9G/zkGrbYR/fjcPGWUk65FhJ+4dacczEgDoe825CI5pg9eCaZ0Vk7sCJpNnYxVgz+ mOdw== X-Gm-Message-State: AJaThX7nXhPc0q7qH0u85hd6oMmzc36mAuDE90mhK6ukfko76aBWvD+S Na+Uqk4FMyR+tEL1Vv/w9hVK2d9TEFphf/PRQph/8A== X-Google-Smtp-Source: AGs4zMZBAaIT/5VsR+xzaGMcvo74MV2gNh8vXyAt20Revx4gYcULR2z7fKTaktANR/3SDiOvoaspD98M616uTX1uoCY= X-Received: by 10.107.16.206 with SMTP id 75mr12064750ioq.83.1511142160537; Sun, 19 Nov 2017 17:42:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.16.155 with HTTP; Sun, 19 Nov 2017 17:42:19 -0800 (PST) In-Reply-To: <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Mon, 20 Nov 2017 10:42:19 +0900 Message-ID: To: "Templin, Fred L" Cc: Fred Baker , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a113eda96afb1a7055e6033a3" Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 01:42:43 -0000 --001a113eda96afb1a7055e6033a3 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 16, 2017 at 2:55 PM, Templin, Fred L wrote: > The way I understood the comment was that the draft needs more supporting > text on the rationale for doing what the document describes (e.g., the > benefit > for not having to place the upstream interface in promiscuous mode, > efficiencies > for not doing link-scoped multicasting over the upstream interface, > avoiding > disturbance of other nodes on the upstream link, etc. > > I did not think the comment was asking to expand the document to cover all > methods of conveying a /64 to the host (e.g., unique-ipv6-prefix-per-host, > 3GPP, etc.). This document only concerns methods that meet the description > of prefix delegation as described for examples such as DHCPv6 PD. > FWIW my comment at the mike was asking for the latter as well. There are many ways that a host can get a dedicated prefix, and we should provide guidance on what a host should do in this situation. Also if we look at current deployments, way more hosts get dedicated prefixes via RAs then via PD: all 3GPP networks provide a dedicated prefix, and very few hosts implement DHCPv6 prefix delegation. So focusing on DHCPv6 PD is focusing on a niche use case. --001a113eda96afb1a7055e6033a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 16, 2017 at 2:55 PM, Templin, Fred L <Fred.L.Templin@boei= ng.com> wrote:
The way I un= derstood the comment was that the draft needs more supporting
text on the rationale for doing what the document describes (e.g., the bene= fit
for not having to place the upstream interface in promiscuous mode, efficie= ncies
for not doing link-scoped multicasting over the upstream interface, avoidin= g
disturbance of other nodes on the upstream link, etc.

I did not think the comment was asking to expand the document to cover all<= br> methods of conveying a /64 to the host (e.g., unique-ipv6-prefix-per-host,<= br> 3GPP, etc.). This document only concerns methods that meet the description<= br> of prefix delegation as described for examples such as DHCPv6 PD.

FWIW my comment at the mike was asking for the l= atter as well. There are many ways that a host can get a dedicated prefix, = and we should provide guidance on what a host should do in this situation. = Also if we look at current deployments, way more hosts get dedicated prefix= es via RAs then via PD: all 3GPP networks provide a dedicated prefix, and v= ery few hosts implement DHCPv6 prefix delegation. So focusing on DHCPv6 PD = is focusing on a niche use case.
--001a113eda96afb1a7055e6033a3-- From nobody Mon Nov 20 00:43:04 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEB61294BD for ; Mon, 20 Nov 2017 00:43: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 F6sM3PwGF5PU for ; Mon, 20 Nov 2017 00:43:01 -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 77F1A12941C for ; Mon, 20 Nov 2017 00:43:01 -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 374E92D5125; Mon, 20 Nov 2017 08:43:01 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 9DEB1200C8F0A1; Mon, 20 Nov 2017 09:42:59 +0100 (CET) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6B10F4DD-CB3D-4F21-BDBD-562DF57B0425"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 20 Nov 2017 09:42:58 +0100 In-Reply-To: Cc: "Templin, Fred L" , "v6ops@ietf.org" To: Lorenzo Colitti References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 08:43:02 -0000 --Apple-Mail=_6B10F4DD-CB3D-4F21-BDBD-562DF57B0425 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Lorenzo, > The way I understood the comment was that the draft needs more = supporting > text on the rationale for doing what the document describes (e.g., the = benefit > for not having to place the upstream interface in promiscuous mode, = efficiencies > for not doing link-scoped multicasting over the upstream interface, = avoiding > disturbance of other nodes on the upstream link, etc. >=20 > I did not think the comment was asking to expand the document to cover = all > methods of conveying a /64 to the host (e.g., = unique-ipv6-prefix-per-host, > 3GPP, etc.). This document only concerns methods that meet the = description > of prefix delegation as described for examples such as DHCPv6 PD. >=20 > FWIW my comment at the mike was asking for the latter as well. There = are many ways that a host can get a dedicated prefix, and we should = provide guidance on what a host should do in this situation. Also if we = look at current deployments, way more hosts get dedicated prefixes via = RAs then via PD: all 3GPP networks provide a dedicated prefix, and very = few hosts implement DHCPv6 prefix delegation. So focusing on DHCPv6 PD = is focusing on a niche use case. The "dedicated" prefix over 3GPP networks is not something that you can = generalise right? It is a property implied by that particular link-layer. Cheers, Ole --Apple-Mail=_6B10F4DD-CB3D-4F21-BDBD-562DF57B0425 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+/bDNdvtpYqJhC33YFAloSlZIACgkQvtpYqJhC 33brgg/+LoJfuwo1NWATdfQ9UbIa/WwdpphA+9zCOXMOKzAxD6cA7h4D/NOJ+/Av d8h7TbCu/R6V2FIHCQyowKxtRb0xss/bk+VUbOfvNfbGck59/9NDGMS5NBm6JDK1 Z42vIwdJviO0vaMbXFXOBcpBtQDIM7y7YRfSVMzAGpeQ0tjpyFBZ2MN5YeKa9HMd 3kg9WHy4cHQC3G8wrSMgOoLIZJPPpahMtpsLCuxAug8obCvscO1q4ym89g2SOY5z +tvxCK3E8KfAOi9vlYDQjMhz0tuXRwBmm0UDQtdvWgIyGC3lYJ2Li512nrOuBpHY 9bPlmOD9Shy7zckwROZWbEmttS9NvChW5XJ0nYR31SOuwUT0RQYq2hTtVTghDrVf 1QuTMBuoXSrUlF733hkhRXCzORZjWlCxZA9DMVPmgJa2nylT0uWKQYdBDIfrESoQ OCpk6gfEi+/ECOG76jGFaG/64CasicwezWO4kf+1v01g8RGWkpcu5qFYsfEI1jCJ yN9CK9py9mRRLTpDKA1e020mDb5TtGKpI9Rk126jbRJqUmLjYV/BJN4Je+qC1RZl UjP49FyJ5i7ftW0RDYM8nbtyMDL6bBLPLSFGTEvrg+QRtTpvEeJCTV4kWia3Tf7Q Ds+MeoIrC2ciIaIxNpsA/x2GAprHhMAeWP3B/InX6570SFZeHSk= =rz+u -----END PGP SIGNATURE----- --Apple-Mail=_6B10F4DD-CB3D-4F21-BDBD-562DF57B0425-- From nobody Mon Nov 20 00:50:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF281294BD for ; Mon, 20 Nov 2017 00:50:45 -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 oXBW9mwQ8p5x for ; Mon, 20 Nov 2017 00:50:44 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDD41294E8 for ; Mon, 20 Nov 2017 00:50:32 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id 71so14956483ior.7 for ; Mon, 20 Nov 2017 00:50: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=99CfiQ1g0hBbGvaValLaYvThP0MaEinhMM/+c1WnU70=; b=H2MZUYedJo+SQRZB6TpDwC0TuOflaPmfJ5GKZLVSNnBA8YdyxeZlVN0KDuyAZEKUT7 JBriluCAIZwzrrb/YV795ZSVLkQjxKpfTC/XdJS2CPpOvJEz/pmG+dnn6gDYx0iTRX/l qW7uGYj4escA40onQsf1hXzJocXIPkXReEzbNL2CzJJCeu3tv3i2ysOB5UW8GP6+P+GA NICSxR2mmtJt4yFZKsin7x7uCv4CnTaR/Odv9btKsgF5Kt4GcOsgnxthYqOyXBIeQ1vm +oKbeyfLkFirVNeM/yAy06zzLZAPMvUjm5rHYQZqcjLmC2BpPfqWa46WfgeclgC42vNE NwMA== 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=99CfiQ1g0hBbGvaValLaYvThP0MaEinhMM/+c1WnU70=; b=NVNBVtT+9ADcTCg/K47Y/6QO5LDgtPVY9POeMsNMo+eZrK4IZgBV5eAOnTIvIQDZfA giZroWzzV6UnSR8tDoXgNnYxTBDadicJoYAUyeOf1tlbhsk2Yf3mniYTzEdOwofKCAsc q9UiBOUT3xOc+FYE9NxGyrLYVRsya/8+uAZQ11EOc3ORtoNpBzMLNhc+IrAwZT9WXW1t YNOxzL/GdJodA2hVhA+mQ8wfrqrlr3SuEMdXQvgbUfBijip4mL7x5W2TwPvo9mG+LIAy QPWd9+fpbqTlSneqUhmqTvCWfpMTxcH/sKCgnMjmRrpyItE8tUT+TXgMGDbmKj042QvY qLcg== X-Gm-Message-State: AJaThX5yM1/53h9f34yVnbDk5kw1msd+3JhvzxFYdmpAoPKn32Y6rBpZ U8Wsb9sQgJe0ay/01GEnJw2sSSA1K2O/GfrMA1C30g== X-Google-Smtp-Source: AGs4zMZZYGGMF/pUMA1zRqXhwU03m808Fr3FDbhdm73BnKluSMFPRB21ABqU9PV2QKP36Ig0L9X4ITXFXrctMikVKrk= X-Received: by 10.107.16.206 with SMTP id 75mr13011183ioq.83.1511167830380; Mon, 20 Nov 2017 00:50:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.16.155 with HTTP; Mon, 20 Nov 2017 00:50:09 -0800 (PST) In-Reply-To: References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Mon, 20 Nov 2017 17:50:09 +0900 Message-ID: To: Ole Troan Cc: "Templin, Fred L" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a113eda96ba87f3055e662d6d" Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 08:50:46 -0000 --001a113eda96ba87f3055e662d6d Content-Type: text/plain; charset="UTF-8" On Mon, Nov 20, 2017 at 5:42 PM, Ole Troan wrote: > > FWIW my comment at the mike was asking for the latter as well. There are > many ways that a host can get a dedicated prefix, and we should provide > guidance on what a host should do in this situation. Also if we look at > current deployments, way more hosts get dedicated prefixes via RAs then via > PD: all 3GPP networks provide a dedicated prefix, and very few hosts > implement DHCPv6 prefix delegation. So focusing on DHCPv6 PD is focusing on > a niche use case. > > The "dedicated" prefix over 3GPP networks is not something that you can > generalise right? > It is a property implied by that particular link-layer. > I think there are properties we can generalize such as "hosts don't need to send DAD packets to the network for any address formed from that prefix", "hosts can likely form as many IPv6 addresses from that prefix without causing ND cache scaling issues in the network", "hosts can use RFC 7278 tethering safely", etc. --001a113eda96ba87f3055e662d6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Nov 20, 2017 at 5:42 PM, Ole Troan <otroan@employees.org> wrote:
> FWIW my= comment at the mike was asking for the latter as well. There are many ways= that a host can get a dedicated prefix, and we should provide guidance on = what a host should do in this situation. Also if we look at current deploym= ents, way more hosts get dedicated prefixes via RAs then via PD: all 3GPP n= etworks provide a dedicated prefix, and very few hosts implement DHCPv6 pre= fix delegation. So focusing on DHCPv6 PD is focusing on a niche use case.
The "dedicated" prefix over 3GPP networks is not something= that you can generalise right?
It is a property implied by that particular link-layer.

I think there are properties we can generalize such as &qu= ot;hosts don't need to send DAD packets to the network for any address = formed from that prefix", "hosts can likely form as many IPv6 add= resses from that prefix without causing ND cache scaling issues in the netw= ork", "hosts can use RFC 7278 tethering safely", etc.
<= /div>
--001a113eda96ba87f3055e662d6d-- From nobody Mon Nov 20 02:07:14 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A4F126D0C for ; Mon, 20 Nov 2017 02:07: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, 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 b_FiudUK_Gnl for ; Mon, 20 Nov 2017 02:07:06 -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 8AA2512426E for ; Mon, 20 Nov 2017 02:07:06 -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 D83562D5038; Mon, 20 Nov 2017 10:07:05 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id D0938200C95446; Mon, 20 Nov 2017 11:07:03 +0100 (CET) From: Ole Troan Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C1E1A199-1213-4E83-A8FB-07F12ED56EB8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 20 Nov 2017 11:07:02 +0100 In-Reply-To: Cc: "Templin, Fred L" , "v6ops@ietf.org" To: Lorenzo Colitti References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 10:07:12 -0000 --Apple-Mail=_C1E1A199-1213-4E83-A8FB-07F12ED56EB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 20 Nov 2017, at 09:50, Lorenzo Colitti wrote: >=20 > On Mon, Nov 20, 2017 at 5:42 PM, Ole Troan = wrote: > > FWIW my comment at the mike was asking for the latter as well. There = are many ways that a host can get a dedicated prefix, and we should = provide guidance on what a host should do in this situation. Also if we = look at current deployments, way more hosts get dedicated prefixes via = RAs then via PD: all 3GPP networks provide a dedicated prefix, and very = few hosts implement DHCPv6 prefix delegation. So focusing on DHCPv6 PD = is focusing on a niche use case. >=20 > The "dedicated" prefix over 3GPP networks is not something that you = can generalise right? > It is a property implied by that particular link-layer. >=20 > I think there are properties we can generalize such as "hosts don't = need to send DAD packets to the network for any address formed from that = prefix", "hosts can likely form as many IPv6 addresses from that prefix = without causing ND cache scaling issues in the network", "hosts can use = RFC 7278 tethering safely", etc. I really don't want to see the hack of 7278 spread further. My point was that there is no way for the host to know this prefix is = dedicated to it, apart from making a guess based on data-link layer = type. Ole --Apple-Mail=_C1E1A199-1213-4E83-A8FB-07F12ED56EB8 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+/bDNdvtpYqJhC33YFAloSqUYACgkQvtpYqJhC 33b/ag//YZKPA8ibZ4feTe/UR/MSyTTD62nkn2sPZcZMOy2OuiiSdlZhUywj1+7m +t5jt+lZ/vyh3WtY2U5Lg9tVBq3IVzoukgp8fKalOm3zFcMD8qgbQA8jzEun9Fyg GDPpm4BRttPHn6hYfFMNLcDytpGivaXEK4HCj98oe8arf2Yj+03eaxSTDkRLJYBE SUWOVw88wbegBnnHq1TiFFa7IhUJ5KMcoZiAMg0bjDtNTU4/TZhJFcjVa5HY7z1a yXuzrtBc/n1DujnhrUPyJnyJWZY8yfZHGiArosCC+xYdsmWpyx+Va0mqfMUaUXV1 BDEBTkhepXLM/TdVztCDvZIw+ZayPdx+SCLac8Csah1iCUE2BMi005S70wOQfc9L Ifh7RzkpP4JCYsPd/AiE3so5Rq2oazCsQEbuaMbRRnl7NYjL0zmQkYZf2+HDh9nB ek9jirQnmFsOkgeVKKx9fgpQLu6iCtMRiKUAuAf/uj28YViCpGx/1mSCBNOarUE9 5Jm12VW8ba9IT4GXezEgJsskEr4ZPq3SCMuKhjN4qj/S7gggVyiJu2i80ovGGWQJ C5nXpzFv22LV7RdkeYDaMx/pX+5yHU4vcruxQmIQbzkxwvWLkwLvfGCjDLrU/LT1 0myBBmDKMs2hHEX9kD4D+qKbZjoY9fwGtYFvbatvEKorxrTldGk= =CxtT -----END PGP SIGNATURE----- --Apple-Mail=_C1E1A199-1213-4E83-A8FB-07F12ED56EB8-- From nobody Mon Nov 20 02:21:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A85129527 for ; Mon, 20 Nov 2017 02:21: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=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 ifu5CADf2sPg for ; Mon, 20 Nov 2017 02:21:36 -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 0244A120046 for ; Mon, 20 Nov 2017 02:21:35 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id m191so11213735itg.2 for ; Mon, 20 Nov 2017 02:21: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=eVhiLkIEGHXN7hHg0pIl23V7p37zeeDyprJByZlHCiY=; b=MzI7q0YViC6MPGNwVcs0Rn0/Sh7CzmteRbWSwleDkcqbsYUcHu8F7xQnakzI/CLi92 Zx51qDddH93Osm2nkkquZ0wuvXVwzoMetq+4SOY+702mJMToWx/Om7t12tLksOY2C6/n t2PLXNRVinTxNu+Bl4PpV4iqZt8cUn9i7Gd8iOnyvyoO6CWD50FeMDZSeldxM0RQz9Dc Tp5G/xrhCsuGX5MJvFEyPnwf5iD+uImS5VfUyAVZh0+CI/hjhpr4a3joDKw3vDTDh+/x FxbdEn1PNFjqnx73bOvxU/2X0W1AIu/00BG1KivVWB/o8vzwuncJL0PnYUcfiIrmidPv gnBQ== 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=eVhiLkIEGHXN7hHg0pIl23V7p37zeeDyprJByZlHCiY=; b=ZH54SAdMY1qGH/wHyembME8lpudYiGylbVU74auysRf2WSCNe+6jtJdHVx+QEIa9Kv fUCYgMj9sXJTbgHUTxWF7odzEyAzZaL9AlhPRfFyQBOaZaNZxywLsHwcoB2WMOhXb1pB i2HLKVoW97oc0i3OlqCfUjMAZ/YjuQpZEL8l1jkkT2AGDJnQ0ObCt6M3vOMnaKkT2s6J 30zvAO8RrdY16xL30pSJW34BilYg446uFf41lZnCo+i9iLt5M6tyKzMvtwkYfi5HVOLj lubyUQJXPr7CqARWnLag+rQ7zJa1iFD2tWoAmaIFF7hR3+esLLIsKMSQxYxV4VwAjebY gbXA== X-Gm-Message-State: AJaThX52ysK+6vA1hLZSLncAYvZPXKmTPF0j+MTInVSgUxH+7rI3OL3O f6V65U0FRbPBqqc1FGOohwuNNbPAudhLXC2L7NcMBg== X-Google-Smtp-Source: AGs4zMbPCK8823fPVEIW3/QAM6ieEvEFJVdmHh8YkqvNr4tRsodhO0L/iosqo+b8TFmADbpx5cQqYIlc3Hvg/3iLxI0= X-Received: by 10.36.14.207 with SMTP id 198mr19269025ite.66.1511173295017; Mon, 20 Nov 2017 02:21:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.16.155 with HTTP; Mon, 20 Nov 2017 02:21:14 -0800 (PST) In-Reply-To: References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> From: Lorenzo Colitti Date: Mon, 20 Nov 2017 19:21:14 +0900 Message-ID: To: Ole Troan Cc: "Templin, Fred L" , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a1143f5347217c9055e67734b" Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 10:21:37 -0000 --001a1143f5347217c9055e67734b Content-Type: text/plain; charset="UTF-8" On Mon, Nov 20, 2017 at 7:07 PM, Ole Troan wrote: > > I think there are properties we can generalize such as "hosts don't need > to send DAD packets to the network for any address formed from that > prefix", "hosts can likely form as many IPv6 addresses from that prefix > without causing ND cache scaling issues in the network", "hosts can use RFC > 7278 tethering safely", etc. > > I really don't want to see the hack of 7278 spread further. > My point was that there is no way for the host to know this prefix is > dedicated to it, apart from making a guess based on data-link layer type. > Sure, in general there is no way for the host to know (at least currently). But there are lots of things that we can say the host can/should do if it does know that the prefix is dedicated to it. Two ways it can know are a) it's a 3GPP link and b) it received a prefix delegation. --001a1143f5347217c9055e67734b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Nov 20, 2017 at 7:07 PM, Ole Troan <otroan@employees.org> wrote:
> I think there are= properties we can generalize such as "hosts don't need to send DA= D packets to the network for any address formed from that prefix", &qu= ot;hosts can likely form as many IPv6 addresses from that prefix without ca= using ND cache scaling issues in the network", "hosts can use RFC= 7278 tethering safely", etc.

I really don't want to see the hack of 7278 spread further.=
My point was that there is no way for the host to know this prefix is dedic= ated to it, apart from making a guess based on data-link layer type.

Sure, in general there is no way for the host= to know (at least currently). But there are lots of things that we can say= the host can/should do if it does know that the prefix is dedicated to it.= Two ways it can know are a) it's a 3GPP link and b) it received a pref= ix delegation.
--001a1143f5347217c9055e67734b-- From nobody Mon Nov 20 02:39:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E86712953F for ; Mon, 20 Nov 2017 02:39: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, 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 16jJUahjJQnq for ; Mon, 20 Nov 2017 02:39:28 -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 3C25E129536 for ; Mon, 20 Nov 2017 02:39:28 -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 EA4EB2D4F99; Mon, 20 Nov 2017 10:39:27 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 6BC9E200C97D75; Mon, 20 Nov 2017 11:39:26 +0100 (CET) From: Ole Troan Message-Id: <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org> Content-Type: multipart/signed; boundary="Apple-Mail=_23E1B899-7402-4052-ABF4-EDB8D2271A4E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 20 Nov 2017 11:39:25 +0100 In-Reply-To: Cc: "Templin, Fred L" , "v6ops@ietf.org" To: Lorenzo Colitti References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 10:39:29 -0000 --Apple-Mail=_23E1B899-7402-4052-ABF4-EDB8D2271A4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Lorenzo, > On Mon, Nov 20, 2017 at 7:07 PM, Ole Troan = wrote: > > I think there are properties we can generalize such as "hosts don't = need to send DAD packets to the network for any address formed from that = prefix", "hosts can likely form as many IPv6 addresses from that prefix = without causing ND cache scaling issues in the network", "hosts can use = RFC 7278 tethering safely", etc. >=20 > I really don't want to see the hack of 7278 spread further. > My point was that there is no way for the host to know this prefix is = dedicated to it, apart from making a guess based on data-link layer = type. >=20 > Sure, in general there is no way for the host to know (at least = currently). But there are lots of things that we can say the host = can/should do if it does know that the prefix is dedicated to it. Two = ways it can know are a) it's a 3GPP link and b) it received a prefix = delegation. Right. Which goes back to your point that there are currently many ways = for a host to get a dedicated prefix. No, there isn't. There is really = only one that is generic. Two if you count 6rd. Three if you include = manual configuration. Cheers, Ole --Apple-Mail=_23E1B899-7402-4052-ABF4-EDB8D2271A4E 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+/bDNdvtpYqJhC33YFAloSsN0ACgkQvtpYqJhC 33ZQEw/+LvEL1GV+ox3PpOk7zIAfVvQUS3f1re6O33FmcpkiqGJJI2Hz54BHkZ3k HD4QcredNvnp84MUH7G5hydWIQJIr9K00mCeFse7XEDOJ0i+xgGuEY91KwSiZOEs ihNhx7Y2g86Bp5knh11JTaaYJRXKHEjFPC9yYUkl7hPwhPQfKAc9akEGROPIovfq WtBLVkv/pMtdvRWxj7hz7/jZatyVY8uyJKj7w61kG9/a2vPceMOTc6SakvWliNmh sshcZS37ZUtsR1uGrHD9Z9l/+laLqA82tWWuQACRYmch1WOfJBSnmBLgebdvnI40 FErTEzuyjzSnOByqaTx5vZVlcIaTlhD7rpAbA50lJBoqpcZWM437/ag+kTsGZQMs dkYluGifxKn+Rq8XPgjVArI2Q6A67M2AzML1Scmn/BaLIT4lP6pSRjEtMOsrrEi3 KSraYuDHSwj7kwKvTxj/E4/V+lFZNKdrZ2AT1V02ssWklT7htrGEhHeeX4s1ApxJ x1m3sagafYcw9+bHDXj16YtJ+G9LnMWhMEqvK3L3ifYkE1NRmVyV0nA4kkXKFBFz 2t52LIbWiL037Q6oEzyhkRMNUz0UoU1vzeUvBm8SpNvm2xWEVYjJMSIq/VIkxkjn qSKQ5zAYK9dyewR3ekqzQY4u4WCkOj1tGETEdC8V8xTGOGzLt+Q= =/UPZ -----END PGP SIGNATURE----- --Apple-Mail=_23E1B899-7402-4052-ABF4-EDB8D2271A4E-- From nobody Mon Nov 20 03:30:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0E7127010 for ; Mon, 20 Nov 2017 03:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoOQYr0ANAiD for ; Mon, 20 Nov 2017 03:30:51 -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 ECB971200FC for ; Mon, 20 Nov 2017 03:30:50 -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 vAKBUmF7062651; Mon, 20 Nov 2017 12:30:48 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id DED2E205E4E; Mon, 20 Nov 2017 12:30:48 +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 CFC0C205D0A; Mon, 20 Nov 2017 12:30:48 +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 vAKBUmoT008527; Mon, 20 Nov 2017 12:30:48 +0100 To: v6ops@ietf.org References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <43186ad6-dc2f-c9d8-2884-db4a097f142d@gmail.com> <655879d9e7274da88ee2cd33a0202dd7@XCH15-06-08.nw.nos.boeing.com> <9FDA6FE7-C03C-4AA9-BED4-F0D7ED63FBBF@gmail.com> From: Alexandre Petrescu Message-ID: <97a1f13f-e9dd-8120-0301-3eac6cef80fd@gmail.com> Date: Mon, 20 Nov 2017 12:30:48 +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: <9FDA6FE7-C03C-4AA9-BED4-F0D7ED63FBBF@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Who implements the DHCP service? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 11:30:53 -0000 Hi Fred, If you refer to the danir draft, we could add a small cloud, or a few dots, to say there are many intermediary routers in between. About the question in the Topic line "who implements the DHCP service". There is at least one trial in cellular network that has DHCP Service on the PGW (I copy the relevant person). Some earlier modem in Huawei E392 USB key (User Equipment) may host a 'proxy' DHCP Server that replies to Requests issued by the linux computer. We are checking that now to be sure. The modem Qualcomm QDSP6 MDM9207 (a modem present in many smartphones) does not 'support' DHCPv6; the ticket response person recommends the use of RS/RA instead of DHCP. By 'not support' one should read that it does not implement a DHCPv6 proxy (like the Huawei does), and it blocks DHCPv6 Solicit that is multicast and is port 547 (does not block DHCPv6 Solicit unicast 547, nor multicast 24683). On the ARM part of the Sierra module WP76xx (a recent IoT device), and on Android Huawei Mate 8, we do support DHCPv6 clients with Prefix Delegation feature. For home, small boxes like openwrt do have odhclient with prefix delegation feature. There are at least three independent publicly available open-source DHCPv6 clients with PD feature. Alex Le 20/11/2017 à 02:27, Fred Baker a écrit : > One comment on the draft in question. > > Looking at figure 1 (applies to all of the figures, but let me be > specific for the purposes of a comment) I don't see any reason to > believe that the node marked "Delegating Router" is in fact a router > or is connected directly to the "Upstream Interface". AFAIK, given > the relay capability present in RFC 3315, the common practice is to > have a more central server respond to IA_NA and IA_PD requests, and > simply have a router connected on the ISP link. That might get > complex to draw in a figure, but I'd worry about any implicit > assumption in the WG version of the document that only routers > implemented the PD service. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Mon Nov 20 04:18:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2ACE126BFD for ; Mon, 20 Nov 2017 04:18:40 -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 1o41jFyX2t0d for ; Mon, 20 Nov 2017 04:18:38 -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 C39071200FC for ; Mon, 20 Nov 2017 04:18:38 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 1D3B940BA0 for ; Mon, 20 Nov 2017 13:18:36 +0100 (CET) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 0D38B40B9C; Mon, 20 Nov 2017 13:18:36 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id F318934B4; Mon, 20 Nov 2017 13:18:35 +0100 (CET) Date: Mon, 20 Nov 2017 13:18:35 +0100 From: Gert Doering To: Ole Troan Cc: Lorenzo Colitti , "v6ops@ietf.org" Message-ID: <20171120121835.GO45648@Space.Net> References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H1ehZ+7pb2ZlFFlk" Content-Disposition: inline In-Reply-To: <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 12:18:41 -0000 --H1ehZ+7pb2ZlFFlk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Nov 20, 2017 at 11:39:25AM +0100, Ole Troan wrote: > Right. Which goes back to your point that there are currently > many ways for a host to get a dedicated prefix. No, there isn't. > There is really only one that is generic. Two if you count 6rd. > Three if you include manual configuration. Four, as soon as we've added appropriate functionality to OpenVPN (the need to be able to "number more things than just the VPN-pointing interface" is clearly there, as in all other "/64 to the host" examples, but the mechanics are not there, and not very well understood either) So it's reasonable to spend a bit of thinking on "what would a host do with a /64 if it knew it's all reserved for itself" Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --H1ehZ+7pb2ZlFFlk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAloSyBgACgkQ31bAZeTO f8VVFA//Rxx11YSvUTHD7VxaDSrCwwHFTY8AD+Uq937OoRWEKpqUHPfpO3HiaSUf xst5JlN0/MmmStwSlGdp1vQ2Th3QFWAgxwEn47oeHNkCz25ijC/sB5i+MycVFRRa RwOWrjRrnoW0b/W9S6Ympy+7AMPDdIvGwug8r+njuH2uLmJRWp0oLKlmA7l7b0a+ DMaB4tTPBIrozdAjlaM9v9hdage82DjuBRpcXY9mpQOn5ekjVnmcCd4Eg97gj6p5 QAxMFzaG8vftCbKPkJlhqBJK9Y6U6p/2vjzFYplLpR0KQ0YP1vLaVb8x11EQILXg 4qSDtUa0N8tyu5A0AUdRuhqHqqoE7hYv3CaeSdK0SRwHpzaTR1VhoY8VYO9zCAD4 A7kyxh4RqxxtfwSnvJENl/pzVNuHTYsVaFdkZ2gVHDSBBd92VHJlIIcKHXMmUhbo Q8j9TItmylrP1qgRrWOg26AgUW6i7gQNgkfRxZxrH/noHo07+bG+0TEjm46kjDsk 1wsbyqHP4DAa/sspL+NiqWpYQXeq2OpY2wLi0FhDr15V1vJ8yD8XH2RANewJEOaj ykNDNQt2T8YfOsAAo872vnhMUlz+RGzNsyf7k4qU6HhzwnWQV83GdJ8gOrCrL0EA T80qlLiPv8yWc3d7S9ZuUVqmWu+iDafx+WFAHYNY9RgaWjVUKGk= =VILy -----END PGP SIGNATURE----- --H1ehZ+7pb2ZlFFlk-- From nobody Mon Nov 20 06:09:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67DF126C0F for ; Mon, 20 Nov 2017 06:09: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 doEQXjRKIry2 for ; Mon, 20 Nov 2017 06:09:31 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0CB3129A9C for ; Mon, 20 Nov 2017 06:09:28 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id n134so11905788itg.3 for ; Mon, 20 Nov 2017 06:09: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=csKilJki3lwcxWUajRc6A7L8r3X2a1/JryZAog9TTzw=; b=Dw1XDyQvOyBY/Ytr77MqsOt6Dldz5UyKHwtoGx9LjkXvPu7ykFV8ell+/P4elA9a6p foEZCODA4OcpTZ3MUDzhsJGNTxJzjQuEa5xlh3uvMKNRWdALVmi+/CKIjtOFKl+ZE+Xi pAJnItNfGnC73JOHHqRmJuMaE6+9YWniH9vAo4j4Xg85NX8H1bjNRyUOvHpNSuO9bScM MIC1nH8hGfHWytkP7KD5ww31pvtd6s7RLU2vCikl8goSKVnALtaUwXEuGNzuMA2iaEPU wGABDJ5ML2m4ugMxaro6dl1OAhG2ToxdQeWuhKzFKWFhzj2hRJ64yKaIVzto4P+zDmbr ysLg== 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=csKilJki3lwcxWUajRc6A7L8r3X2a1/JryZAog9TTzw=; b=o3/3JYq+jpiqSAATU3Fp0cCG/Q8jh0suqwxZyNKjnQG4JhWr/oMBdTLEo8Smvl0gX3 fTiga8/4M+Sq9+ChyK0N8RVIBSnoK7sC8FV2ZuctKOg/eyHAd6cbihfSkgQr37UT71O+ 66sDm2knZHrWswG9iw0yoX1vJel7io6aj8RWYtBIn+Jvb7jfmMYuxdjj56T5SNbtzgfr UB0gyrKFMiofZynHEYSBgNwRNBWiKFYzoARqh8sbipJELNmJDnrY62sFNsS05HdOVA11 OU6vOgbZYxX0F46A5J40dqlGZOot7kcuxNXeL5b2rJnGizCGru73XdyRZExFMjgAy//n dShg== X-Gm-Message-State: AJaThX71g6Py8A/M/zKquPP8iFQcJCg1jDvlBDDwnhtaENH3GaOOvzSA 9NtaCXlE/PZKUQezX/lK6CrsN2vofr3dxzRYpVtF0Q== X-Google-Smtp-Source: AGs4zMY+pIeFaZPjQIltBlBiVnYnL6FhDN2ITo1yVQ/JF4CmS5l9a7wnhQ5QF0bZJbRf9oBvENlablJR7liQB3LJUtE= X-Received: by 10.36.14.207 with SMTP id 198mr20183103ite.66.1511186967450; Mon, 20 Nov 2017 06:09:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.16.155 with HTTP; Mon, 20 Nov 2017 06:09:06 -0800 (PST) In-Reply-To: <20171120121835.GO45648@Space.Net> References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org> <20171120121835.GO45648@Space.Net> From: Lorenzo Colitti Date: Mon, 20 Nov 2017 23:09:06 +0900 Message-ID: To: Gert Doering Cc: Ole Troan , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="001a1143f53463066a055e6aa29d" Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 14:09:33 -0000 --001a1143f53463066a055e6aa29d Content-Type: text/plain; charset="UTF-8" On Mon, Nov 20, 2017 at 9:18 PM, Gert Doering wrote: > Four, as soon as we've added appropriate functionality to OpenVPN > (the need to be able to "number more things than just the VPN-pointing > interface" is clearly there, as in all other "/64 to the host" examples, > but the mechanics are not there, and not very well understood either) > Great to hear you're working on this. A while ago I asked around to see if there were any VPN providers that handed out more than a single /128 and I couldn't find any. Once this is supported in OpenVPN it might be easier for providers to offer it. > So it's reasonable to spend a bit of thinking on "what would a host do > with a /64 if it knew it's all reserved for itself" > One thing we're thinking of is to give apps an API to create new IPv6 addresses for their own use. This is only really useful if the prefix is dedicated to the host, as doing this on a shared prefix may not work and may end up causing scaling issues to the network. --001a1143f53463066a055e6aa29d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Nov 20, 2017 at 9:18 PM, Gert Doering <gert@space.net> wrot= e:
Four, as soon as we've added appro= priate functionality to OpenVPN
(the need to be able to "number more things than just the VPN-pointing=
interface" is clearly there, as in all other "/64 to the host&quo= t; examples,
but the mechanics are not there, and not very well understood either)

Great to hear you're working on this. A = while ago I asked around to see if there were any VPN providers that handed= out more than a single /128 and I couldn't find any. Once this is supp= orted in OpenVPN it might be easier for providers to offer it.
= =C2=A0
So it's reasonable to spend = a bit of thinking on "what would a host do
with a /64 if it knew it's all reserved for itself"

One thing we're thinking of is to give apps an AP= I to create new IPv6 addresses for their own use. This is only really usefu= l if the prefix is dedicated to the host, as doing this on a shared prefix = may not work and may end up causing scaling issues to the network.
--001a1143f53463066a055e6aa29d-- From nobody Mon Nov 20 09:38:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045C2129C6D for ; Mon, 20 Nov 2017 09:38:20 -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 QTo2zh-y73ix for ; Mon, 20 Nov 2017 09:38:18 -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 ECCD9129C73 for ; Mon, 20 Nov 2017 09:38:17 -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 vAKHcH9i016995; Mon, 20 Nov 2017 10:38:17 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vAKHcDmn016962 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 10:38:13 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 09:38:13 -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 09:38:12 -0800 From: "Templin, Fred L" To: Fred Baker CC: "v6ops@ietf.org" Thread-Topic: Who implements the DHCP service? Thread-Index: AQHTYiZWc/3zBrWZik6BjeURAPhioA== Date: Mon, 20 Nov 2017 17:38:12 +0000 Message-ID: References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <43186ad6-dc2f-c9d8-2884-db4a097f142d@gmail.com> <655879d9e7274da88ee2cd33a0202dd7@XCH15-06-08.nw.nos.boeing.com> <9FDA6FE7-C03C-4AA9-BED4-F0D7ED63FBBF@gmail.com> In-Reply-To: <9FDA6FE7-C03C-4AA9-BED4-F0D7ED63FBBF@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] Who implements the DHCP service? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 17:38:20 -0000 Hi Fred, The figures are derived directly from RFC3633, Section 5.1. Please see that document for the answers to your questions. Thanks - Fred > -----Original Message----- > From: Fred Baker [mailto:fredbaker.ietf@gmail.com] > Sent: Sunday, November 19, 2017 5:28 PM > To: Templin, Fred L > Cc: v6ops@ietf.org > Subject: Who implements the DHCP service? >=20 > One comment on the draft in question. >=20 > Looking at figure 1 (applies to all of the figures, but let me be specifi= c for the purposes of a comment) I don't see any reason to believe > that the node marked "Delegating Router" is in fact a router or is connec= ted directly to the "Upstream Interface". AFAIK, given the > relay capability present in RFC 3315, the common practice is to have a mo= re central server respond to IA_NA and IA_PD requests, and > simply have a router connected on the ISP link. That might get complex to= draw in a figure, but I'd worry about any implicit assumption > in the WG version of the document that only routers implemented the PD se= rvice. From nobody Mon Nov 20 09:49:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D300C129A92 for ; Mon, 20 Nov 2017 09:49:57 -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 IUElOGDd4_ri for ; Mon, 20 Nov 2017 09:49: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 67711129A89 for ; Mon, 20 Nov 2017 09:49: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 vAKHns2i021385; Mon, 20 Nov 2017 10:49:54 -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 vAKHnqMP021375 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 10:49:52 -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; Mon, 20 Nov 2017 09:49:51 -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 09:49:51 -0800 From: "Templin, Fred L" To: Gert Doering , Ole Troan CC: "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AQHTXoFjbBaTujqFZECShuBca1gGBKMWf4dggAaLLICAAHWIAIAAAgKAgAAVewCAAAP3AIAABRWAgAAbtYD//9Ua4A== Date: Mon, 20 Nov 2017 17:49:51 +0000 Message-ID: References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org> <20171120121835.GO45648@Space.Net> In-Reply-To: <20171120121835.GO45648@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: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 17:49:58 -0000 We have DHCPv6 PD working with OpenVPN on Android today - have been using it for the better part of two years. We are currently using the kea DHCPv6 server and it works great, but I am sure the many other publicly-available DHCPv6 servers could work as well. The DHCPv6 client piece in OpenVPN is a few hundred lines of code and was not hard to implement. And, if the client needs to do something to request, manage and maintain a delegated prefix it might as well be DHCPv6. Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering > Sent: Monday, November 20, 2017 4:19 AM > To: Ole Troan > Cc: v6ops@ietf.org > Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >=20 > Hi, >=20 > On Mon, Nov 20, 2017 at 11:39:25AM +0100, Ole Troan wrote: > > Right. Which goes back to your point that there are currently > > many ways for a host to get a dedicated prefix. No, there isn't. > > There is really only one that is generic. Two if you count 6rd. > > Three if you include manual configuration. >=20 > Four, as soon as we've added appropriate functionality to OpenVPN > (the need to be able to "number more things than just the VPN-pointing > interface" is clearly there, as in all other "/64 to the host" examples, > but the mechanics are not there, and not very well understood either) >=20 > So it's reasonable to spend a bit of thinking on "what would a host do > with a /64 if it knew it's all reserved for itself" >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Nov 20 10:15:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549281296D2 for ; Mon, 20 Nov 2017 10:15: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=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8FXXWqJzOYc for ; Mon, 20 Nov 2017 10:15:49 -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 47AF31296CD for ; Mon, 20 Nov 2017 10:15:48 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4846340B9B for ; Mon, 20 Nov 2017 19:15:46 +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 375FC406DF; Mon, 20 Nov 2017 19:15:46 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 24EAB8B55; Mon, 20 Nov 2017 19:15:46 +0100 (CET) Date: Mon, 20 Nov 2017 19:15:46 +0100 From: Gert Doering To: "Templin, Fred L" Cc: Gert Doering , Ole Troan , "v6ops@ietf.org" Message-ID: <20171120181546.GS45648@Space.Net> References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org> <20171120121835.GO45648@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T1iPLtA/uXXp7jA0" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 18:15:51 -0000 --T1iPLtA/uXXp7jA0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Nov 20, 2017 at 05:49:51PM +0000, Templin, Fred L wrote: > We have DHCPv6 PD working with OpenVPN on Android today - have > been using it for the better part of two years. We are currently using > the kea DHCPv6 server and it works great, but I am sure the many > other publicly-available DHCPv6 servers could work as well. >=20 > The DHCPv6 client piece in OpenVPN is a few hundred lines of code > and was not hard to implement. And, if the client needs to do > something to request, manage and maintain a delegated prefix it > might as well be DHCPv6. So what does your patch *do* with the received prefix (since it's=20 an out of tree patch I haven't seen yet)? "Just configure it on the tun interface" (you do not need DHCPv6-PD for that)? Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --T1iPLtA/uXXp7jA0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAloTG88ACgkQ31bAZeTO f8Wjig//ZcKb2EuVr0V3vfMpinMDuuwJfwGTe1HO/EKitUbhBjVCXIGtpFRdqyoD N9qTEHAmTGgcHnpLIcfNKIWKEtpdb2XTXLZxk02IQx/OtnyNgP2zWrQ06gdpl7AZ QEb+9i1UC5Ma7TH+Y5LyVh8ec5t3ejHA1lWUfvik06VWz/9JyNFZcohA46ZBa6H9 +SIEOE3i9LpiediVNCjC5V6Mh8bJL/X2svbMzfiZ/7Yij72OCnEeyFtmQabFjaos ceUZZEOe/UPwZnuFZ+bLOx1lV/lnGwyGyEtKbxyZVJ8hfwXfyeXT9Mttcp8WL1AT 2BNGr86jtw6e1/RSDZqoeiJgex9I+TFea1+e4f9AiBAlL+EVzMiqenaTxPuD01yd IrVzbR2UnmNGG819hs/ze0mn4HpO2X3aql90KoQ2jSSDtjnu5My3Q3EMv5vSj2lJ uNsFTdWMdwY4zJVGSfYECfob/LwADF//PQFc/HXt5u20LsQzaYVuPDNZAK0t8zai r/h137eroYyfk7d3HJqfAWATmyYb0fUqnl6RCrGDC4QOOVTEbUDiREGzB7kxqPk9 5+rBkPpc3Ke3OjY6Nml1Wg+ESy+UBIOtrBWT2bhY7yx77B0/d4QiFlvGRHcflwLb V0KIjZMIBB78b/3PN1LzqmMEATj/PGLxyXsRqPH0z5ILI67EEzQ= =f35G -----END PGP SIGNATURE----- --T1iPLtA/uXXp7jA0-- From nobody Mon Nov 20 10:19:55 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1113612E05C for ; Mon, 20 Nov 2017 10:19:54 -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 PjblbGMtFsp2 for ; Mon, 20 Nov 2017 10:19:52 -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 2BDD8126B7F for ; Mon, 20 Nov 2017 10:19:52 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9BD08B1; Mon, 20 Nov 2017 19:19:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1511201989; bh=ljalkG7OoqfS7tCXgdsopETP8Nmxmmf19MiVYFas8/0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Y/ADLcYRKJ/JCkoeYqA+mzlTv3jLOulioKcoATc43KYKVHo5duou4gUSQYVibZcTa Nty3MMyH2LrjgS9B3fGtiu0NcByWdjVO0rxg1EbwqT3DcwA6SWr1vaOrwa8Qy6tggw mEbiKgGNuJHKTPdaLMH4Yns++4vJML+Zi5VB/j8U= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 83748B0; Mon, 20 Nov 2017 19:19:49 +0100 (CET) Date: Mon, 20 Nov 2017 19:19:49 +0100 (CET) From: Mikael Abrahamsson To: Gert Doering cc: Ole Troan , "v6ops@ietf.org" In-Reply-To: <20171120121835.GO45648@Space.Net> Message-ID: References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org> <20171120121835.GO45648@Space.Net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 18:19:54 -0000 On Mon, 20 Nov 2017, Gert Doering wrote: > So it's reasonable to spend a bit of thinking on "what would a host do > with a /64 if it knew it's all reserved for itself" We did some of this thinking in the PIO-X draft in 6man. It's not complete, but there is some thinking about it... -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Nov 20 10:33:09 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB1B129C26 for ; Mon, 20 Nov 2017 10:33:07 -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 Z-OSeW2r9Zfx for ; Mon, 20 Nov 2017 10:33:05 -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 B0E5E126DCA for ; Mon, 20 Nov 2017 10:33:05 -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 vAKIX4aF043296; Mon, 20 Nov 2017 11:33:04 -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 vAKIWsaM043128 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 11:32: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 10:32: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 10:32:53 -0800 From: "Templin, Fred L" To: Gert Doering CC: Ole Troan , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AQHTXoFjbBaTujqFZECShuBca1gGBKMWf4dggAaLLICAAHWIAIAAAgKAgAAVewCAAAP3AIAABRWAgAAbtYD//9Ua4IAAjrIA//97mGA= Date: Mon, 20 Nov 2017 18:32:53 +0000 Message-ID: <8d9f4425644a4c08ba08e16c2dce2f15@XCH15-06-08.nw.nos.boeing.com> References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org> <20171120121835.GO45648@Space.Net> <20171120181546.GS45648@Space.Net> In-Reply-To: <20171120181546.GS45648@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: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 18:33:07 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, November 20, 2017 10:16 AM > To: Templin, Fred L > Cc: Gert Doering ; Ole Troan ; v6op= s@ietf.org > Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >=20 > Hi, >=20 > On Mon, Nov 20, 2017 at 05:49:51PM +0000, Templin, Fred L wrote: > > We have DHCPv6 PD working with OpenVPN on Android today - have > > been using it for the better part of two years. We are currently using > > the kea DHCPv6 server and it works great, but I am sure the many > > other publicly-available DHCPv6 servers could work as well. > > > > The DHCPv6 client piece in OpenVPN is a few hundred lines of code > > and was not hard to implement. And, if the client needs to do > > something to request, manage and maintain a delegated prefix it > > might as well be DHCPv6. >=20 > So what does your patch *do* with the received prefix (since it's > an out of tree patch I haven't seen yet)? "Just configure it on the > tun interface" (you do not need DHCPv6-PD for that)? It configures addresses derived from the prefix and assigns them to the tun interface. It does not join the solicited-node multicast address nor perform DAD over the tun interface. Right now, it is only assigning a single address but it can in fact assign as many addresses as it wants as shown in Figure 3 of 'pdhost' without having to invoke MLD or DAD. Do you want to see our code? Thanks - Fred=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Nov 20 10:38:00 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF1512704B for ; Mon, 20 Nov 2017 10:37:58 -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 EUfQxWaw1xfl for ; Mon, 20 Nov 2017 10:37:57 -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 ED6B112706D for ; Mon, 20 Nov 2017 10:37:56 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 390D140B9B for ; Mon, 20 Nov 2017 19:37:55 +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 2B294406DF; Mon, 20 Nov 2017 19:37:55 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 27F3A8BD3; Mon, 20 Nov 2017 19:37:55 +0100 (CET) Date: Mon, 20 Nov 2017 19:37:55 +0100 From: Gert Doering To: "Templin, Fred L" Cc: Gert Doering , Ole Troan , "v6ops@ietf.org" Message-ID: <20171120183755.GU45648@Space.Net> References: <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org> <20171120121835.GO45648@Space.Net> <20171120181546.GS45648@Space.Net> <8d9f4425644a4c08ba08e16c2dce2f15@XCH15-06-08.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kLTOpTk3sdvcZAB1" Content-Disposition: inline In-Reply-To: <8d9f4425644a4c08ba08e16c2dce2f15@XCH15-06-08.nw.nos.boeing.com> X-NCC-RegID: de.space User-Agent: Mutt/1.8.2 (2017-04-18) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 18:37:58 -0000 --kLTOpTk3sdvcZAB1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Mon, Nov 20, 2017 at 06:32:53PM +0000, Templin, Fred L wrote: > > > The DHCPv6 client piece in OpenVPN is a few hundred lines of code > > > and was not hard to implement. And, if the client needs to do > > > something to request, manage and maintain a delegated prefix it > > > might as well be DHCPv6. > >=20 > > So what does your patch *do* with the received prefix (since it's > > an out of tree patch I haven't seen yet)? "Just configure it on the > > tun interface" (you do not need DHCPv6-PD for that)? >=20 > It configures addresses derived from the prefix and assigns them > to the tun interface. It does not join the solicited-node multicast > address nor perform DAD over the tun interface. So where's the benefit of doing DHCPv6-PD here? *This* is a function OpenVPN can do out of the box just fine... *scratch head* Single address, or "many"? > Right now, it is only assigning a single address but it can in fact assign > as many addresses as it wants as shown in Figure 3 of 'pdhost' > without having to invoke MLD or DAD. >=20 > Do you want to see our code? It would be nice to have a look, but the "do DHCPv6-PD handshake" is not the really challenging bit - "do something interesting with the prefix" is... Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 --kLTOpTk3sdvcZAB1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEruB5jRHVM+CjiYD131bAZeTOf8UFAloTIP8ACgkQ31bAZeTO f8XhKA//XbkK/eoWpHQAFsmm3TJpE4l3FSTy7+EBic3WIhr8IGnKhQ7jAGh+lNT0 WEcNC+8bVlRhuoS5xo0aO8Ra/8IWECqgbvu71T6zl9ij9nA8J0+lobXA64mAJOka ze+LQWzV+9dev+9dUd7hQef4jXUkFufWhStC8Tns/MdUh3BOzg4bYqA69AksgvOM b6lTa1KOIw6WBHCRYj+2XgJW6KKXx/fNK/XlKx0GCo7/0+vxpfiSEgaPSQFsM/uC 4D+x7jD+uscIbwEffPBrIdC0drPtH4gUsHEbTpZzjA1450vRB+h/bRnDl1mx5uYQ WuLH3VDvu3g0ZPt5KXQn9ZUOtlplhRmYrVk4KkO+winOJEObjbc2fNlVuuoYCpdm 8fzbgu1H6S8TtT4+RNmZutF+q2mJWXutXgsxg5TCg4KTQPIdbB+vATRgZdCAkcZ+ VCJWCWjm+eGXvPOc53wkcGhO0cW3xBfZ2Urx0zy1F+RAN0vvjS7JIMxRhYEA1D3p h9HmMRnjsFtLvUeR/IdwUmgNFH3sDykVPsl3Yu3gkBZFQF3/dmmoi/wFRAzFMp0v XZla7w6pwG/VdxmSar4A6xejb71jg2NTEQf7yKhqxcTQj6o2zKYJsKUm5YEwfEzs UbD1bWqc5YKuLJCtxKFzrnhm+cp4yxulUAbKdV0uO/4Rr7alAzE= =CjRK -----END PGP SIGNATURE----- --kLTOpTk3sdvcZAB1-- From nobody Mon Nov 20 10:56:42 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A5712E855 for ; Mon, 20 Nov 2017 10:56:41 -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 yIblG9rFLhbe for ; Mon, 20 Nov 2017 10:56:40 -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 E8A89126DD9 for ; Mon, 20 Nov 2017 10:56:39 -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 vAKIucep018406; Mon, 20 Nov 2017 11:56: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-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id vAKIuXAE018234 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 20 Nov 2017 11:56:33 -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; Mon, 20 Nov 2017 10:56: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; Mon, 20 Nov 2017 10:56:29 -0800 From: "Templin, Fred L" To: Gert Doering CC: Ole Troan , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AQHTXoFjbBaTujqFZECShuBca1gGBKMWf4dggAaLLICAAHWIAIAAAgKAgAAVewCAAAP3AIAABRWAgAAbtYD//9Ua4IAAjrIA//97mGCAAIqYgP//fTyw Date: Mon, 20 Nov 2017 18:56:29 +0000 Message-ID: References: <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org> <20171120121835.GO45648@Space.Net> <20171120181546.GS45648@Space.Net> <8d9f4425644a4c08ba08e16c2dce2f15@XCH15-06-08.nw.nos.boeing.com> <20171120183755.GU45648@Space.Net> In-Reply-To: <20171120183755.GU45648@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: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 18:56:41 -0000 Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, November 20, 2017 10:38 AM > To: Templin, Fred L > Cc: Gert Doering ; Ole Troan ; v6op= s@ietf.org > Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >=20 > Hi, >=20 > On Mon, Nov 20, 2017 at 06:32:53PM +0000, Templin, Fred L wrote: > > > > The DHCPv6 client piece in OpenVPN is a few hundred lines of code > > > > and was not hard to implement. And, if the client needs to do > > > > something to request, manage and maintain a delegated prefix it > > > > might as well be DHCPv6. > > > > > > So what does your patch *do* with the received prefix (since it's > > > an out of tree patch I haven't seen yet)? "Just configure it on the > > > tun interface" (you do not need DHCPv6-PD for that)? > > > > It configures addresses derived from the prefix and assigns them > > to the tun interface. It does not join the solicited-node multicast > > address nor perform DAD over the tun interface. >=20 > So where's the benefit of doing DHCPv6-PD here? *This* is a function > OpenVPN can do out of the box just fine... *scratch head* >=20 > Single address, or "many"? >=20 > > Right now, it is only assigning a single address but it can in fact ass= ign > > as many addresses as it wants as shown in Figure 3 of 'pdhost' > > without having to invoke MLD or DAD. > > > > Do you want to see our code? >=20 > It would be nice to have a look, but the "do DHCPv6-PD handshake" is not > the really challenging bit - "do something interesting with the prefix" > is... There is nothing particularly challenging about assigning multiple addresse= s from the prefix to the tun interface (tens, hundreds, thousands or more if you'd like) - although that in itself would be very interesting. Again, see Figure 3 of 'pdhost' along with the supporting text. Thanks - Fred > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culema= nn > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Mon Nov 20 13:41:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 15:34:58 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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 21:31:19 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: To: "Templin, Fred L" Cc: 6MAN <6man@ietf.org>, v6ops list , "dhcwg@ietf.org" Content-Type: multipart/alternative; boundary="089e08266864f67310055e77814c" Archived-At: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 22:26:16 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:17 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C80127735 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 HeaHkv7Ng3Kp for ; Mon, 20 Nov 2017 22:48:10 -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 755E7127517 for ; Mon, 20 Nov 2017 22:48:08 -0800 (PST) Received: by mail-yb0-x232.google.com with SMTP id e83so4053113yba.4 for ; 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=DDUBAvDNG0txhmfgJ0qkg0TFzXZ8G4P4v4RKPxqXKHb8agnswofTbU7SrtO/S8YDH9 3uwTjpjryXnwNQp3uw4LjMWHz7ZNK8tH2xCSLSaFtu2sBMFccqAf80Eq72PSVJkUqT7q e/lbSaGCx5NwWs49NOsETK3nFe/MjKdqNsxDNICkSesS4//jRg+VR5GKLku+yrCxudnR whW6NHkJM9VjXxbqNtyODXoUj7w6O5nmF/jQ4jrGveTRnxnK5YS3nfmWaeZUszho2ys8 ZtPHURhftB6gH+13XotNasPSfRA71R9v6gar+HDPc5A9dcQtxIGVUMdYaZ2YzakFJEU4 ErIw== X-Gm-Message-State: AJaThX4RxHeb/DVXSRQ2TBmQNhDv4543V9Q17RiFe9jgK45rTi+UPzwi tkSgeaK6DFG6UwgwIP5CVUuLkyEzlhnonZcNsyQWaA== 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: 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 Tue Nov 21 07:38:21 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629531294E1 for ; Tue, 21 Nov 2017 07:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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, 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=shytyi.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTad0bY4TjIU for ; Tue, 21 Nov 2017 07:38:17 -0800 (PST) Received: from sender-of-o52.zoho.eu (sender-of-o52.zoho.eu [31.186.226.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BAC1294D2 for ; Tue, 21 Nov 2017 07:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1511278692; s=hs; d=shytyi.net; i=ietf.dmytro@shytyi.net; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=14044; bh=+O8P3YK835xfDcSadLsv5T7kMjROFDytXiCBxLdmKus=; b=GdXd9ghbZViWGQWR2q+E3DdOAoNjvrzzgIBCArOKua9fSybbfcXZcd1DfBurGKyu xcHSQAd6gSLBGyzYLHaNBo/DW6FIpcTHceBdtpqTz2rlzuuE22HdoJ3hEDYG9SqY1rN 8WxNWULLfRmkzWBDpcCXsnWNhd8dekf33HHgu210= Received: from mail.zoho.eu (172.26.17.39 [172.26.17.39]) by mx.zoho.eu with SMTPS id 1511278692311698.2027402121275; Tue, 21 Nov 2017 16:38:12 +0100 (CET) Date: Tue, 21 Nov 2017 16:38:12 +0100 From: Dmytro Shytyi To: "Templin, Fred L" Cc: "Gert Doering" , "v6ops@ietf.org" Message-ID: <15fdf3ac775.10ae1bffd22319.2672208877291679718@shytyi.net> In-Reply-To: <8d9f4425644a4c08ba08e16c2dce2f15@XCH15-06-08.nw.nos.boeing.com> References: <7FC2CA6E-8BF7-47BC-9164-1877FAF83FD0@gmail.com> <962041fbaee844b5a4cdd82012440dbe@XCH15-06-08.nw.nos.boeing.com> <31EC6585-3C75-4DDF-9059-3411C20770DF@employees.org> <20171120121835.GO45648@Space.Net> <20171120181546.GS45648@Space.Net> <8d9f4425644a4c08ba08e16c2dce2f15@XCH15-06-08.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_53936_313155125.1511278692223" X-Priority: Medium X-ZohoMail-Sender: 78.122.18.3 User-Agent: Zoho Mail X-Mailer: Zoho Mail X-ZohoMailClient: External Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2017 15:38:19 -0000 ------=_Part_53936_313155125.1511278692223 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hello Fred, You could find interesting, that the danir draft describes, how the prefixes are obtained via DHCPv6 and are advertised on the links. Precisely, multiple IPv6 Global Unique Network Prefixes (GUNPs) are derived from the GUNPs pool and are advertised on the multiple links. > configures addresses derived from the prefix and assigns them > to the tun interface. It does not join the solicited-node multicast > address nor perform DAD over the tun interface. At this moment, the implementation, described by the danir draft (the code), is able to advertise multiple GUNPs, derived from the GUNPs pool, on the multiple links. > Right now, it is only assigning a single address but it can in fact assign > as many addresses as it wants as shown in Figure 3 of 'pdhost' > without having to invoke MLD or DAD. Also I suppose, you could find useful, that danir draft describes the DHCPv6 implementation without VPNclient usage on the UE side: >>The DHCPv6 client piece in OpenVPN is a few hundred lines of code >>and was not hard to implement. And, if the client needs to do >>something to request, manage and maintain a delegated prefix it >>might as well be DHCPv6. >> Fred. >>There is at least one trial in cellular network that has DHCP Service on >>the PGW (I copy the relevant person). >>On the ARM part of the Sierra module WP76xx (a recent IoT device), and >>on Android Huawei Mate 8, we do support DHCPv6 clients with Prefix >>Delegation feature. >>Alex. ---- On Mon, 20 Nov 2017 19:32:53 +0100 Templin, Fred L <Fred.L.Templin@boeing.com> wrote ---- Hi Gert, > -----Original Message----- > From: Gert Doering [mailto:gert@space.net] > Sent: Monday, November 20, 2017 10:16 AM > To: Templin, Fred L <Fred.L.Templin@boeing.com> > Cc: Gert Doering <gert@space.net>; Ole Troan <otroan@employees.org>; v6ops@ietf.org > Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? > > Hi, > > On Mon, Nov 20, 2017 at 05:49:51PM +0000, Templin, Fred L wrote: > > We have DHCPv6 PD working with OpenVPN on Android today - have > > been using it for the better part of two years. We are currently using > > the kea DHCPv6 server and it works great, but I am sure the many > > other publicly-available DHCPv6 servers could work as well. > > > > The DHCPv6 client piece in OpenVPN is a few hundred lines of code > > and was not hard to implement. And, if the client needs to do > > something to request, manage and maintain a delegated prefix it > > might as well be DHCPv6. > > So what does your patch *do* with the received prefix (since it's > an out of tree patch I haven't seen yet)? "Just configure it on the > tun interface" (you do not need DHCPv6-PD for that)? It configures addresses derived from the prefix and assigns them to the tun interface. It does not join the solicited-node multicast address nor perform DAD over the tun interface. Right now, it is only assigning a single address but it can in fact assign as many addresses as it wants as shown in Figure 3 of 'pdhost' without having to invoke MLD or DAD. Do you want to see our code? Thanks - Fred > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_53936_313155125.1511278692223 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hello Fred,<= br>

Y= ou could find interesting, that the danir draft describes, how the prefixes= are obtained via DHCPv6 and are advertised on the links. Precisely, <= span class=3D"highlight">multiple IPv6 Global Unique Network Prefixes= (GUNPs) are derived from the GUNPs pool and are advertised on the multiple links.

> configures addresses derived from the pref= ix and assigns them 
> to the tun inter= face. It does not join the solicited-node multicast 
> address nor perform DAD over the tun interface. 

At this moment, the implementation, described b= y the danir draft (the code), is able to advertise multiple GUNPs, derived = from the GUNPs pool, on the multiple links.

> Right now, it is only assigning = a single address but it can in fact assign 
> as many addresses as it wants as shown in Figure 3 of 'pdhost' 
> without having to invoke MLD or DAD. 

Also I suppose, you could find useful, that danir draft descr= ibes the DHCPv6 implementation without VPNclient usage on the UE side:

>>The DHCPv6 client piece in Ope= nVPN is a few hundred lines of code&n= bsp;
>>and was not hard to = implement. And, if the client needs to do 
>>something to r= equest, manage and maintain a delegated prefix it 
>>might = as well be DHCPv6. 
>> Fred.

>>Ther= e is at least one trial in cellular network that has DHCP Service on=  
>>the PGW (I copy = the relevant person). 
>>On the ARM = part of the Sierra module WP76xx (a recent IoT device), and 
>>on Android Huawei Mate 8, we do support DHCPv6 c= lients with Prefix 
>>Delegation fe= ature. 
>>Alex.


---- On Mon, 20= Nov 2017 19:32:53 +0100 Templin, Fred L <Fred.L.Templin@boeing.= com> wrote ----

Hi Gert,

> -----Original Message----- <= br>
> From: Gert Doering [mailto:gert@space.net]
> Sent: Monday, November 20, 201= 7 10:16 AM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>
&= gt; Cc: Gert Doering <gert@space.net>; Ole Troan <otroan@employ= ees.org>; v6ops@ietf.org
<= /div>
> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working gr= oup draft?
>
> Hi,
> =
> On Mon, Nov 20, 2017 at 05:49:51PM +0000, Templin, Fred= L wrote:
> > We have DHCPv6 PD working with OpenVPN o= n Android today - have
> > been using it for the bette= r part of two years. We are currently using
> > the ke= a DHCPv6 server and it works great, but I am sure the many
&= gt; > other publicly-available DHCPv6 servers could work as well.
> >
> > The DHCPv6 client piece in Open= VPN is a few hundred lines of code
> > and was not har= d to implement. And, if the client needs to do
> > som= ething to request, manage and maintain a delegated prefix it
> > might as well be DHCPv6.
>
>= So what does your patch *do* with the received prefix (since it's
> an out of tree patch I haven't seen yet)? "Just configure it o= n the
> tun interface" (you do not need DHCPv6-PD for tha= t)?

It configures addresses derived from the = prefix and assigns them
to the tun interface. It does not jo= in the solicited-node multicast
address nor perform DAD over= the tun interface.

Right now, it is only ass= igning a single address but it can in fact assign
as many ad= dresses as it wants as shown in Figure 3 of 'pdhost'
without= having to invoke MLD or DAD.

Do you want to = see our code?

Thanks - Fred
> Gert Doering
> -- NetMaster
> --
> have you enabled IPv6 on something = today...?
>
> SpaceNet AG = Vorstand: Sebastian v. Bomhard
> Joseph-Dolling= er-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
=

_______________________________________________ <= br>
v6ops mailing list

------=_Part_53936_313155125.1511278692223-- From nobody Tue Nov 21 07:52:36 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 07:59:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 23:19:25 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1033012EB2D for ; Tue, 21 Nov 2017 23:33:31 -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 ZVb0icQc5Pzw for ; Tue, 21 Nov 2017 23:33:30 -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 D852712EB48 for ; Tue, 21 Nov 2017 23:33:28 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id p19so5533975ybd.2 for ; 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=m0a61KfKkOfrvkVCySzm7VV2Tb1nS6wmDfWhvkRUUjT68CmleB+5gVjxSIw0Lgy9jU gzRkx/Lu8FiB4/2yXSy/6sMm6dnX+4fvxDW7/AX82HqfG8SDcjr8+emcvp06wXTpRETP AwSshHve0YSi6FXInGldtICIEw2m3Y8DGLWRPLFZBEhjDewsKirQJbxDJu4QBEBxExC+ h8YeB92cocGdLlz1MHepYMGI3PfEULbywDx6nZYEaarIMj1o4fnRs+XwlIbhd7wm3o/q lxKwWoclMi3nqTr2IeNf/VkWW4SdVS8BuT8CgA92jodQGw8XHqLUO67DZ92qGDDi8ZZg P26g== X-Gm-Message-State: AJaThX5TTlm+ux4yKKs9xQz6R3DaLMEUOqNi3zX6GilrTEvjJqOSGiqC K8JsAtoZIDhZ1Znn0uQQjS5nfgPFrYV3AtkX5GdGDw== 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: 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: Subject: Re: [v6ops] [dhcwg] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 07:33:31 -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 07:25:46 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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:54:02 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 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:12 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 00:19:01 -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 Thu Nov 23 10:05:34 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 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:42:03 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C185B1293E3 for ; Fri, 24 Nov 2017 12:42:01 -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 LceApBDXwzBl for ; Fri, 24 Nov 2017 12:42:00 -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 08F881289C3 for ; Fri, 24 Nov 2017 12:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1511556118; x=1512160918; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding: Reply-To; bh=Vbt0Npx9pqfaJkBu3ULuVeIwXjJjCqEVuLeoGs9M2BQ=; b=nJM 3iTwhwRH5S1z7GZCnyeULBRB3xR8c2F2wNFiVGVCZAJeFfp8s1IrCGdt/3Wlb0UV b899gOJ7W7BAgHK0WHeCCYzRwU/VyqtQ6KqvciqrIfLRksXwLPRoKi1KG8SrhSLO YABLwRagP+Ztg7FBfnyKTLcfK0qPj1vsc81f8A4s= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=S4vyROkAOe7ZDdfO0h8//mgq2lw7pX8L121s+7gEX0cOnDLgi1LBSvtF9WkV OB+bsZjuQTIvYSSa60VgBlJJbnqP4+lVN1oFLSOpsfIhgUkUt0k9xeKPF NEEK2W86K6egJzcel4wOJJLp46bkSUU2vo31V/OFaDgn70+p8i+Dqg=; X-MDAV-Processed: mail.consulintel.es, Fri, 24 Nov 2017 21:41:58 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 24 Nov 2017 21:41:58 +0100 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005637848.msg for ; Fri, 24 Nov 2017 21:41:56 +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:md50005637848::KEwHfLYQot3NeZF4:0000103c X-Return-Path: prvs=1501b83790=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Fri, 24 Nov 2017 21:41:56 +0100 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt 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: Subject: [v6ops] FW: New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 20:42:02 -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:50:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECDA1293E1 for ; Fri, 24 Nov 2017 12:50: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, 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 CPE9QO9OPrfs for ; Fri, 24 Nov 2017 12:50:50 -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 BFD46127005 for ; Fri, 24 Nov 2017 12:50:49 -0800 (PST) X-MDAV-Processed: mail.consulintel.com, Fri, 24 Nov 2017 21:47:45 +0100 Received: from mail.consulintel.es by mail.consulintel.com (Cipher TLSv1:-SHA:128) (MDaemon PRO v11.0.3) with ESMTP id md50000956359.msg for ; Fri, 24 Nov 2017 21:47:43 +0100 X-Spam-Processed: mail.consulintel.com, Fri, 24 Nov 2017 21:47:43 +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=1501f01733=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org 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=dNp5GBKyGppNsSZ0vRFl605P6vYMvTKKGHPkXGBn5 KgYQ7O2NZ6KqssJD/4VOGGFagTBaAKBwS+pnAisp8VAYoJeQAQSbYN0XkbciHuMI kXUqSLtgWFyPxtHCr9mvn22ljkZ1yXUgUd9SHT7ybmAUYe9RoIKAYU+eYa9CPSLV Sg= 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:40 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 24 Nov 2017 21:47:40 +0100 Received: from [10.10.10.133] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005637852.msg for ; Fri, 24 Nov 2017 21:47:38 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:171124:md50005637852::udkMFlMMKzWw5UJz:00000cPB User-Agent: Microsoft-MacOutlook/f.27.0.171010 Date: Fri, 24 Nov 2017 21:47:33 +0100 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: Subject: Re: [v6ops] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 20:50:51 -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 Sat Nov 25 11:00:53 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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\)) 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: Subject: Re: [v6ops] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 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:45:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE5712895E for ; Sat, 25 Nov 2017 15:45:57 -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] autolearn=ham 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 mlv7qDujTi0D for ; Sat, 25 Nov 2017 15:45:56 -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 751A9127B60 for ; Sat, 25 Nov 2017 15:45:56 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id h205so32000401iof.5 for ; 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=KKlgZgmFS2Qmzg0mizYzFXSE9bAU/Q0BA27H+WAfPdLmm1ho3ZC68GS6kSWHobNLOF oSC+FBE/2L1xvIgIlE5tFUa4yTupfC41sJPBJOZsaLw2I9nnm05qD5w2WLPH1JdzgOhc jtDdFs5OZjQTXfrO5HEka1QPuGlmo0DZGT6JONIlgm4u6a3ysMPpKbYoa3IPc5BdqtCe WTD6eA/rZgDWJvOn33sMAHm0G2XCdZRGuoioVzB9V2LFevRN9ddXSqBRFvEtlUg+ZF3B sI+UBCW3XQY5dAqm3xHzdDBxQoAc1IlA1L+WHG0SEh3fVo9qWDRoe5HVZ/JgjLtZMPaH kERA== X-Gm-Message-State: AJaThX6Yz8yc9mZj7kJ/8OEDt3BfsrGafYJ1hqZNw2eAmng7ezuaXMyk MW6nqfCEf10B7MYLGaKJwr2lcQ== 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) 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: Subject: Re: [v6ops] [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Nov 2017 23:45:57 -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 Mon Nov 27 01:50:45 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 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: Subject: Re: [v6ops] [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 13:20:30 -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:30 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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:59:06 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CDD1292AE 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 F-nBdNFyiyKD 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 54C701292CE for ; Mon, 27 Nov 2017 09:58:49 -0800 (PST) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 337A942A0E for ; 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 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: Subject: Re: [v6ops] [DNSOP] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 17:58:52 -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 11:12:52 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F991128E19 for ; Mon, 27 Nov 2017 11:12: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 pmHhz4sFW3Xn for ; Mon, 27 Nov 2017 11:12:49 -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 DD334126C83 for ; Mon, 27 Nov 2017 11:12:48 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id k24so8041705pfb.1 for ; Mon, 27 Nov 2017 11:12: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=NqPn3J5D1gUlApqImfmVqeAGYdmErJFN1LcoDQRift8=; b=fkNGR+T3XCyvFij+sT4xobC0M2yFE/1JWK4ivpStKl75H2a2z7/4HZcixl9iarDLaR iwDYIcdBNS2X6Tjh8HX4W+FscXYJr6dRrSWlelqOJqVbEk/XpzIWpAZDPpmwurrA7T5m wGJHjCfKt2SJBwBDeBCAcJ+FI5eYR2rqEJdd09v6mlBSi/M+FVT0ie+3ZPX7FR1hnFgx xGOlSqY9KLUuu2uTKBtjJ7RF9gDmyH5F00RN1oKrnjMmijLqStKEL+gSfQg9g+BnCPul nIFB3Ey4DBbLAyExAEWELD/zFzdeFVMKZdbAhU0r7TuIeiRpPTtxG1XlVyfsMu7eAU1g OMIA== 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=NqPn3J5D1gUlApqImfmVqeAGYdmErJFN1LcoDQRift8=; b=mhG/iC4xUDnav/j9B3KarLCX8Hmy5NsuAw7pM0V1Mgr/QpAl8H+5q4DEtZhMz+MLSH 87I5B8lHCpOh/7mT9OyQjYJiSKko9pa060lvjbbdwrlwpLU5gONz3xQM50yunNGhzq8N olV1A8GpwjdBvG1qDNB+LDv1ZiNjTWor5wS/T/0/AnGIcohk/tfO5BgZRA10CAkiyNki vINZ7909X7bk8NdfQa/xYn1rPKzhwx3uHitxC8JVFEk2W7W4l8jmBflZ17wl45QBpvTB jWRFnd3h8URttBM1pEfRZq8uhUIbmzowOhMqnHDW+DCQF1dJK7l0Pl1Q9q6gWNhIKK6E BUKg== X-Gm-Message-State: AJaThX6DJJZqnOdf9hJusAH86ZTJRCllm5CVtD7TS/GLN514DWCVysWW 4qgN8kB3T256oy6LIYsVCmpbRA== X-Google-Smtp-Source: AGs4zMaKYPILxAqaceVnKekujdmV6KKG/Yk0h7OyTZzOUYaVfQYex/sB/MjqODTMNuScuSh7ZIPqRw== X-Received: by 10.98.185.8 with SMTP id z8mr28696279pfe.166.1511809968100; Mon, 27 Nov 2017 11:12:48 -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 u68sm49291013pfu.154.2017.11.27.11.12.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 11:12:47 -0800 (PST) To: v6ops@ietf.org References: <9debb1672e3d4f0d89d672d64e0fe579@XCH15-06-08.nw.nos.boeing.com> <4e01cd6cc5234daca2f7be55b8cc28b0@XCH15-06-08.nw.nos.boeing.com> <27327.1511369630@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <6c2ea16b-a452-4e32-d5af-c92d39c474bd@gmail.com> Date: Tue, 28 Nov 2017 08:12: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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 19:12:50 -0000 On 28/11/2017 06:30, Templin, Fred L wrote: > 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 >> >> >> >>> 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. >> >> 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. > > 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. Prefix management is a bit different from prefix delegation. They both need to be stateful to some extent, but neither of them actually *requires* DHCP; what they do require is for A to tell B "you now own prefix P" and for both sides to record that fact. draft-ietf-anima-prefix-management looks rather different to DHCP, and so does RFC7695 and RFC7788. Brian From nobody Mon Nov 27 15:07:27 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 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:18 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 23:59:16 -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 21:22:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BB1126DD9 for ; Mon, 27 Nov 2017 21:22: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 2z5mzzdUrnO1 for ; Mon, 27 Nov 2017 21:22:21 -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 7D700124C27 for ; Mon, 27 Nov 2017 21:22:20 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id q37so12806422ywa.12 for ; 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=oVtpdTtJa5SIeHgT3WiH4200H/2nZ6If6acbiufc1w5OFd/YF8Ox0Yc/CxCf1K8yVT s2JiZdctwrGuX6offdcqewE3IVBcEgpj1jUo94CVEWTl3G7aHYBa0AF+UWh7eyAogET/ CrPOqT1VliIGxDPlS5V7FqSXvWOzxXD72jMhLIcluwqHMaJuu4Z4Gv0hvEQNq0S6LQLq Hl1LBqQVDt1hwDCKjEQCDci6jeivpeuy4FCdbV9UGAkMuBIXOB44oJyAAUo2U6Peo9ae RMTdRQ3TaZXZLqInsBpDIkzuytqHo5U9SkqqFDhCSrbmGuRPbbq2/MLLFnxpzSDc3ov1 PEug== X-Gm-Message-State: AJaThX4kce+toGZSbbet1VLNQGv33eSp5GrahfhRnjvxFL0RoTph8iSI 5kfFr4G//btbfvTkR/PfzDA82DFO8zbUHS6q1KWp8g== 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: 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: Subject: Re: [v6ops] [dhcwg] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 05:22:23 -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:23 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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> 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: Subject: Re: [v6ops] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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" 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: Subject: Re: [v6ops] [dhcwg] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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:40 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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) 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: Subject: Re: [v6ops] [dhcwg] Combining IPv6 ND and DHCPv6 into a single, unified function X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 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 12:37:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02C7127078 for ; Tue, 28 Nov 2017 12:37:34 -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 nYLpTmbFNG32 for ; Tue, 28 Nov 2017 12:37:32 -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 6804D124239 for ; Tue, 28 Nov 2017 12:37:32 -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 vASKbUbC038308; Tue, 28 Nov 2017 13:37:30 -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 vASKbNRK038243 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Tue, 28 Nov 2017 13:37:23 -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, 28 Nov 2017 12:37:22 -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 12:37:22 -0800 From: "Templin, Fred L" To: "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdNoiEQoZAX3ZeaJTjOHwVsWAIjDPw== Date: Tue, 28 Nov 2017 20:37:22 +0000 Message-ID: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 20:37:34 -0000 See below for an updated version of this draft. This version addresses comm= ents received on the list regarding more clearly identifying classes of devices = that can be considered as ordinary routers. Can we have this version as a wg item? Thanks - Fred -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Tuesday, November 28, 2017 12:27 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-pdhost-16.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 Prefix Delegation Models Author : Fred L. Templin Filename : draft-templin-v6ops-pdhost-16.txt Pages : 12 Date : 2017-11-28 Abstract: IPv6 prefixes are typically delegated to requesting routers which then use them to number their downstream-attached links and networks. This document considers prefix delegation models according to whether the requesting router acts as a router on behalf of any downstream networks, as host on behalf of its local applications or as both. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-v6ops-pdhost-16 https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-16 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Nov 28 13:41:47 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60844124D68 for ; Tue, 28 Nov 2017 13:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 DGbcmmbb-6D2 for ; Tue, 28 Nov 2017 13:41:06 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D228120721 for ; Tue, 28 Nov 2017 13:41:06 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id h1so1470724wre.12 for ; Tue, 28 Nov 2017 13:41:06 -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=d1wqNwbIPE9O9Eck+6/c6ry1vKDGC8wjIpeASRVjPn8=; b=dj4r30JX3YMByRowIUm4GEhbyBG/XLcSVqoLMObRjIhNefK5R/0fPguulyXrsYscCR VfUL2WaqVD8u3Pdp7fl3XJEJuxFIHZccJ4eWoBqC6lpW9kbqBEw+Y6nKkdSuM8QOLHBc susged2MPezHWKt5iWro7yKGmUiBXWrk36de3dGk56AC8lMXiePfKEqNh9Dl2WY8wW9k Wcq4skhwc0xAhlANw93jsxpFZMUAQNNBxDc4Q/JOFuMx9CIgESGTd7Li7YtwLPC7dxRY BtoZ8oaYE+3ZlBMkmYV89QDSOqlyWDJhPBTtmlW926wUBmAj4EouCRmyLmNMrtXqyTGO GIbw== 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=d1wqNwbIPE9O9Eck+6/c6ry1vKDGC8wjIpeASRVjPn8=; b=kjgegYA6dvSM54er5TC0Kfy/Sd2Tygd+gcIcWn4uCx1o/AeZDF1CGNBGT18JZ9X7EK e6Ksy/w3Ud14E+5Ksr93A/azFLeq1k0w9DgrG/2ce2XIZgXtqXmHyZDT8IdZsVc1Y5lD 44qQAIW2L+MHtU5P7RgeDRc0XNLHX4FA9nDBiK5Sga7y0RljzTNLpIY65TfvHD0wXhDL m8o/XhKyqNksvCxASpCVrfqbJtlJT0CIzsvyulSKMwpsUYnuuibWrIfyqhXBD4O02rYI ODs4VXUB0PCWKrVfwzMkPswRnvvHjur8Lixt+GaNAzQWC41fwp2D2GgbgygF+Wb4DknO uhsw== X-Gm-Message-State: AJaThX5VcS89HgPeOKbx/968wBSKZsi8oo/Znkw60fP7LH83Qx5jIDvf Txl80RviFcJ1Wi0o1+fe7QPhGtfe X-Google-Smtp-Source: AGs4zMbishprBm2ook8ZYym01igB8BzPRlmjWblTc6RJxn2BtmgRTpxSJK4fbnyjwSXuzXdmm3XapA== X-Received: by 10.223.156.146 with SMTP id d18mr456822wre.161.1511905264271; Tue, 28 Nov 2017 13:41:04 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::1024? ([2600:8802:5600:f7a::1024]) by smtp.gmail.com with ESMTPSA id k19sm232145wrk.88.2017.11.28.13.41.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 13:41:03 -0800 (PST) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_23712887-4631-4A8A-8597-98097EBA6D6E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 28 Nov 2017 13:40:59 -0800 References: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> To: "v6ops@ietf.org" In-Reply-To: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> Message-Id: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 21:41:10 -0000 --Apple-Mail=_23712887-4631-4A8A-8597-98097EBA6D6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 28, 2017, at 12:37 PM, Templin, Fred L = wrote: >=20 > See below for an updated version of this draft. This version addresses = comments > received on the list regarding more clearly identifying classes of = devices that can > be considered as ordinary routers. I have not gone through the entire list of comments to see if they have = been addressed, but I see one quickly that has not. In figure 1, and = each comparable figure, an assumption is made that the delegation is = made by a specific router, referred to as the "delegating router", as = opposed to "a system in the upstream network". The latter is the common = case, implemented using DHCP's relay mechanism. =46rom my perspective, = if we are describing an architecture for a commonly-implemented service, = it should at least describe current common implementations of the = service. I would encourage comment on the draft. Lorenzo specifically wanted = material added to it to fully describe that architecture, and I'm not = sure what else others had in mind. Let's get those comments on the = table, and then we can decide when and whether to ask for adoption. > Can we have this version as a wg item? >=20 > Thanks - Fred >=20 > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Tuesday, November 28, 2017 12:27 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-templin-v6ops-pdhost-16.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : IPv6 Prefix Delegation Models > Author : Fred L. Templin > Filename : draft-templin-v6ops-pdhost-16.txt > Pages : 12 > Date : 2017-11-28 >=20 > Abstract: > IPv6 prefixes are typically delegated to requesting routers which > then use them to number their downstream-attached links and = networks. > This document considers prefix delegation models according to = whether > the requesting router acts as a router on behalf of any downstream > networks, as host on behalf of its local applications or as both. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-templin-v6ops-pdhost-16 > https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-16 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-16 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_23712887-4631-4A8A-8597-98097EBA6D6E 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+AFAlod1+sACgkQEhdRnd2G P+AeWQ//YhhARJCat6vqVW2+tRrnc7ZvxD/zbHZtJqANBCXd9LEnzJbtFJFDpv+n 4N5chcmRuegLTqwaD04Fw9UpukmZNlbwTSD1XtR/hGaLdJlPCBaA2eueDnkPugv8 ClAlb/wHUQllJG5vmnJOhBkMwt3M/KLMeq3FzcyNn5/sHw01nue/pBXBLMyv2dMR BVofWesVI2n4n9SYMrjxXwvYmasrx6Zs6iwpcUCuuIeIrxQdBAxFHW47cvWZP0vf HdteZXTRNLTCzG1jxfJUk3yZKgf1BLfD/7vcvm75Uzelgnn+2dBzG+mQ70WGqtud xrZJw7vvnWyk/YSxvFRUOc8DK/D6iWRn3VJHkp2/nEQgwSY/56W0vHnvcYjKRzX7 kkXK9XREqnRyfWeReIexf81AApfOVe1rHSS6aZgJEL9E8c0ETTirbIJ5k89JL8s2 dUSwECc5eAQw5Uia+06ja0ThsxLLJ4UZsOCx9VU+IPPKZbry75rHA2q9kV1eeRs5 k3aluSH1hufEbTMs5J/kh7G8sZyq6AjYA2RSzWVwQJjkdm3zq2lpbg7sBF+cyVVq +vr/USxq4dYKwGiJbM575MMXiKwmKbQQGeBpTarMvt8qIaprO7UtyiL0/k7lrzeP S+NCsAFY1lVSHWzoRYETG9iBS/hcU/Ji8fq1vWUhttA2zlFLsTg= =7JUd -----END PGP SIGNATURE----- --Apple-Mail=_23712887-4631-4A8A-8597-98097EBA6D6E-- From nobody Tue Nov 28 14:02:38 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2135A1252BA for ; Tue, 28 Nov 2017 14:02:36 -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 Ag7HaU93o6zp for ; Tue, 28 Nov 2017 14:02:33 -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 079A91201F8 for ; Tue, 28 Nov 2017 14:02:33 -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 vASM2VIx017474; Tue, 28 Nov 2017 15:02:31 -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 vASM2OLP017365 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 28 Nov 2017 15:02:24 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 28 Nov 2017 14:02:23 -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 14:02:23 -0800 From: "Templin, Fred L" To: Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdNoiEQoZAX3ZeaJTjOHwVsWAIjDPwATF4yAABBiPEA= Date: Tue, 28 Nov 2017 22:02:23 +0000 Message-ID: References: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 22:02:36 -0000 Hi Fred, > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker > Sent: Tuesday, November 28, 2017 1:41 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >=20 >=20 >=20 > > On Nov 28, 2017, at 12:37 PM, Templin, Fred L wrote: > > > > See below for an updated version of this draft. This version addresses = comments > > received on the list regarding more clearly identifying classes of devi= ces that can > > be considered as ordinary routers. >=20 > I have not gone through the entire list of comments to see if they have b= een addressed, but I see one quickly that has not. In figure 1, > and each comparable figure, an assumption is made that the delegation is = made by a specific router, referred to as the "delegating > router", as opposed to "a system in the upstream network". The latter is = the common case, implemented using DHCP's relay > mechanism. From my perspective, if we are describing an architecture for = a commonly-implemented service, it should at least > describe current common implementations of the service. I didn't add anything about this, because I thought I had already addressed= your question (you didn't respond). What you are asking is already covered in RF= C3633, and the figures in this document are derived from Section 5.1 of RFC3633. T= he relay function is also addressed in RFC3633, Section 14. Proposed resolution is to add the following sentence in the introduction: "Delegating/Requesting router relationships and the role of relay agents = are discussed in [RFC6333] and apply also to this document." Thanks - Fred > I would encourage comment on the draft. Lorenzo specifically wanted mater= ial added to it to fully describe that architecture, and I'm > not sure what else others had in mind. Let's get those comments on the ta= ble, and then we can decide when and whether to ask for > adoption. >=20 > > Can we have this version as a wg item? > > > > Thanks - Fred > > > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > > Sent: Tuesday, November 28, 2017 12:27 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-templin-v6ops-pdhost-16.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > > > > > Title : IPv6 Prefix Delegation Models > > Author : Fred L. Templin > > Filename : draft-templin-v6ops-pdhost-16.txt > > Pages : 12 > > Date : 2017-11-28 > > > > Abstract: > > IPv6 prefixes are typically delegated to requesting routers which > > then use them to number their downstream-attached links and networks. > > This document considers prefix delegation models according to whether > > the requesting router acts as a router on behalf of any downstream > > networks, as host on behalf of its local applications or as both. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-templin-v6ops-pdhost-16 > > https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-16 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-16 > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Nov 28 17:32:20 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA34E126DFE for ; Tue, 28 Nov 2017 17:32:18 -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 V3Vtm7Wwuebw for ; Tue, 28 Nov 2017 17:32:17 -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 5B701126E7A for ; Tue, 28 Nov 2017 17:32:17 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id y82so34103122wmg.1 for ; Tue, 28 Nov 2017 17:32:17 -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=Wv6XkjFgNGvhg1Rra+VAhY/pgjSSuqpJZ7XfJSJPuW0=; b=eC09otNO/EHwEU4SM6MOiNq9LVD2iI0BosH7ABXkHZ7xcIYdthgCl+HTfEMEmnfpYn yfa/9br/EWXADAeX47ZncrIJP3enUBgQT/iMxCs+/RbnsK5+vR7yO9Bfc6aIzzMXxYkn T4wOCYTGoV4N2Je8CZwjCtFSC49MA2SULGeJyDndOl4dnKyOpbWUEdhKtJ5ZeXrKDTgV slz8/7wcpmBuNtvVT2EzQs2XaR4NopDnafYVtnqmYSRb6iaXM9cwh/b4VGbi0bUDQDjv gjN1oDBpfqM1dZZK6dPEJzJP3dV6H45TA2/zZO6pNF6x0nniLIjT8F4DvY+IXGp3VX32 G5cg== 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=Wv6XkjFgNGvhg1Rra+VAhY/pgjSSuqpJZ7XfJSJPuW0=; b=THp9nlE+PfPA9ovszFNpQaHhRO7DGAu9L0kt8MqQRNdA2MGKYCBNmjdueS2kshdrxh 0HX7TD59fvb0pLu3v041bPBjRIdb8UVIshUl2fA7nOPt2m3hdminMrVfno8By4sqOw8/ I7fPz4RlBHKVTy5ySnAwyTuMj8kZd+YJE9f+9PADBq54agQG33aaczLFotnuA6BlA2+5 HOd6s0iv/uqlyQTUWkv16roK7BRTWH7WUJUPhHrr96hmmE8HpbzfsWvNJR5TFt22iyQY /754UmExV0p7h/CU1dPnMI07ojHmNXdNfjy1RH/0L21NdJK+E4tuYTElRQTprtGeufBS vUyA== X-Gm-Message-State: AJaThX6GmqQucEpwqblYV4S+GvpzFx9z9mLiEXmzFsiJKgIC/ChXhyS8 1zZ/p/FTfTa+1M15JGEydpZtFVm84tzS4FGGFPL2VA== X-Google-Smtp-Source: AGs4zMb3Px9q0NXFFDaCsucwXsVtjfv52w9mWJOqiMC6E2Nh3GasqISMliCyT07uo5ZSEq5ciUApqQbQbNag88FiIu0= X-Received: by 10.28.238.221 with SMTP id j90mr1195511wmi.44.1511919135546; Tue, 28 Nov 2017 17:32:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.161.4 with HTTP; Tue, 28 Nov 2017 17:31:54 -0800 (PST) In-Reply-To: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> References: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> From: Paul Marks Date: Tue, 28 Nov 2017 17:31:54 -0800 Message-ID: To: "Templin, Fred L" Cc: "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 01:32:19 -0000 On Tue, Nov 28, 2017 at 12:37 PM, Templin, Fred L wrote: > See below for an updated version of this draft. This version addresses comments > received on the list regarding more clearly identifying classes of devices that can > be considered as ordinary routers. Have you considered clarifying whether addresses at the top and bottom of the delegated prefix (RFC 2373, RFC 2526) should be reserved under this model? When delegating to a host, I often wonder whether it's technically incorrect to use prefix::0 as a normal address. Does anyone know for sure? From nobody Wed Nov 29 07:49:22 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2996128799 for ; Wed, 29 Nov 2017 07:49:20 -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 cq_C6A4_MCiE for ; Wed, 29 Nov 2017 07:49:11 -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 157A81275C5 for ; Wed, 29 Nov 2017 07:49:11 -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 vATFn9TJ023387; Wed, 29 Nov 2017 08:49:10 -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 vATFn0PJ023279 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 29 Nov 2017 08:49:00 -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, 29 Nov 2017 07:48:59 -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, 29 Nov 2017 07:48:59 -0800 From: "Templin, Fred L" To: Paul Marks CC: "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdNoiEQoZAX3ZeaJTjOHwVsWAIjDPwAbKBoAAAyErnA= Date: Wed, 29 Nov 2017 15:48:59 +0000 Message-ID: References: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 15:49:21 -0000 SGkgUGF1bCwNCg0KVGhhbmtzIGZvciB0aGUgcmVtaW5kZXIgYWJvdXQgdGhpcyBpbnRlcmVzdGlu ZyBxdWVzdGlvbi4gU2VlIGJlbG93Og0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IFBhdWwgTWFya3MgW21haWx0bzpwbWFya3NAZ29vZ2xlLmNvbV0NCj4gU2VudDogVHVl c2RheSwgTm92ZW1iZXIgMjgsIDIwMTcgNTozMiBQTQ0KPiBUbzogVGVtcGxpbiwgRnJlZCBMIDxG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFt2Nm9wc10gZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QgYSB3b3JraW5nIGdyb3Vw IGRyYWZ0Pw0KPiANCj4gT24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTI6MzcgUE0sIFRlbXBsaW4s IEZyZWQgTA0KPiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4gU2VlIGJl bG93IGZvciBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhpcyBkcmFmdC4gVGhpcyB2ZXJzaW9uIGFk ZHJlc3NlcyBjb21tZW50cw0KPiA+IHJlY2VpdmVkIG9uIHRoZSBsaXN0IHJlZ2FyZGluZyBtb3Jl IGNsZWFybHkgaWRlbnRpZnlpbmcgY2xhc3NlcyBvZiBkZXZpY2VzIHRoYXQgY2FuDQo+ID4gYmUg Y29uc2lkZXJlZCBhcyBvcmRpbmFyeSByb3V0ZXJzLg0KPiANCj4gSGF2ZSB5b3UgY29uc2lkZXJl ZCBjbGFyaWZ5aW5nIHdoZXRoZXIgYWRkcmVzc2VzIGF0IHRoZSB0b3AgYW5kIGJvdHRvbQ0KPiBv ZiB0aGUgZGVsZWdhdGVkIHByZWZpeCAoUkZDIDIzNzMsIFJGQyAyNTI2KSBzaG91bGQgYmUgcmVz ZXJ2ZWQgdW5kZXINCj4gdGhpcyBtb2RlbD8NCg0KSSB0aGluayBpbiB0aGUgcm91dGVyIG1vZGVs LCBzdWJuZXR0aW5nIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IHdvdWxkIGJlDQpleGFjdGx5IHRoZSBz YW1lIGFzIGZvciBhbnkgcm91dGVyLiBTbywgc3VibmV0IHJvdXRlciBhbnljYXN0IGZvcg0KZXhh bXBsZSB3b3VsZCBoYXZlIHRoZSBzYW1lIHNpZ25pZmljYW5jZSBhcyBpbiBhbnkgcm91dGluZyBo aWVyYXJjaHkuDQoNCj4gV2hlbiBkZWxlZ2F0aW5nIHRvIGEgaG9zdCwgSSBvZnRlbiB3b25kZXIg d2hldGhlciBpdCdzIHRlY2huaWNhbGx5DQo+IGluY29ycmVjdCB0byB1c2UgcHJlZml4OjowIGFz IGEgbm9ybWFsIGFkZHJlc3MuICBEb2VzIGFueW9uZSBrbm93IGZvcg0KPiBzdXJlPw0KDQpJbiB0 aGUgaG9zdCBtb2RlbCwgSSB3b3VsZCBsaWtlIHRvIHNheSB0aGF0IGFkZHJlc3MgYXV0b2NvbmZp Z3VyYXRpb24gaXMgcGVyDQpzdGFuZGFyZCBJUHY2IHByb2NlZHVyZXMgYW5kIGxlYXZlIHRoYXQg YXMgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGRvY3VtZW50Lg0KQnV0LCBwZXJoYXBzIEkgY291bGQg YWxzbyBhZGQgYSByZWZlcmVuY2UgdG8gUkZDNDI5MShiaXMpIGFuZCBzYXkgdGhhdCBhZGRyZXNz DQphdXRvY29uZmlndXJhdGlvbiBtdXN0IGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgSVB2NiBhZGRy ZXNzaW5nIGFyY2hpdGVjdHVyZS4NCg0KQWJvdXQgcHJlZml4OjowLCBJIHRoaW5rIHdlIHdvdWxk IGhhdmUgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgbG9jYWwNCmFwcGxpY2F0aW9ucywgbWlkZGxlYm94 ZXMgYW5kL29yIGNvcnJlc3BvbmRlbnRzIHdvdWxkIHZpZXcgdGhhdCBhcyBhDQpzcGVjaWFsIGFk ZHJlc3MgYW5kIGRvIHNvbWV0aGluZyBkaWZmZXJlbnQgd2l0aCBpdCB0aGFuIGZvciBhbiBvcmRp bmFyeQ0KR1VBLiBCdXQsIEkgdGhpbmsgdGhhdCBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9j dW1lbnQuDQogDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KVGhhbmtzIC0gRnJlZA0K From nobody Wed Nov 29 10:44:44 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE482126C22 for ; Wed, 29 Nov 2017 10:44: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, 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 9_GxKqMTbvBv for ; Wed, 29 Nov 2017 10:44: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 26A57127337 for ; Wed, 29 Nov 2017 10:44:41 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id o2so1873750pgc.8 for ; Wed, 29 Nov 2017 10:44: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=syBsChW5zLXnWBA+Wesw/7CubBpMd75yWpqYuMxV2dA=; b=I6agFbv54RQebm68VCiRZaA/pp0r/9sgQfZ1cNQQ+VhxFEnrxe7L2ko82xuLMwox05 /LF2my75FA5R23Elg07SFkZGwchL6tVWRLmwSg4tgGr3JXRbEf3/FWk9BF/tTaSAJlL8 sv+2nOhQwFLtx+1dKJ8v6Y/eXKj4kYUuwrXOcP0OQOEvRTZV865B+uA6vKp8I1pXsuqz TDMMxCXmsxnCrtVdqV25aUsg5fKSf326SqGjOR3Rg1JDchjYCi/Y980Ttz1kykkaVWvl bmNebFBNonWWHbZLIcoCerr8XwMcMa52ru3KHkNaiWy/EpzkVUNgYcWKaECwChiUmiIb 8ttg== 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=syBsChW5zLXnWBA+Wesw/7CubBpMd75yWpqYuMxV2dA=; b=g2qanyfg71yeol7d3gW+jaA6LFGyAMJuOyzr6ngTThjtaRE8qr4bu9/J14DRUNcNv/ kDVhR9FqoD+6GTSSuciX+FOUXoz/5uBLPhSt8iKBvwOaFAt12lMtI2haCZu4bNaa5/5T tJXG89Xycm/MKEVib7s2/dlaSMqSX1hbfSNmUiwMpk1UDuCm7VgTgeTaWoFCUpY+TrJd JIKRFeiSkiLGrfQmXrY8yx2rlwp0W8Hpf2hkQwE88MPe/Jn0ZxkXgsbpFEIm+5/Bm+ja n5ftek57w4yWSDhBAT/lCXA8zmPdhWHJ6nmwgoyyd0gJ4xhQY8Y/aX4ooeCip778oM7d I6Ww== X-Gm-Message-State: AJaThX6+vJSo6uVc57Y0zT14ySuwz8OAAB6F0KskvjXVTMuMQ0T4qVZ2 FdlwyUAxLsICr/3jUrfX+nXEtQ== X-Google-Smtp-Source: AGs4zMZfKPYHkdv7eKE6UfL2MUkXcEvh7slahPOJR2WTh42UBvrDOuKJwDMzmub1VFpCcQLxQrOXYg== X-Received: by 10.99.43.5 with SMTP id r5mr3763373pgr.348.1511981080405; Wed, 29 Nov 2017 10:44:40 -0800 (PST) Received: from ?IPv6:2620::10e7:10:adcb:890a:a521:8f42? ([2620:0:10e7:10:adcb:890a:a521:8f42]) by smtp.gmail.com with ESMTPSA id k63sm4615120pfk.172.2017.11.29.10.44.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 10:44:39 -0800 (PST) From: james woodyatt Message-Id: <42B4C703-00FF-4C44-984D-71D5A7736BE9@google.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7DBC2379-EEF7-42B0-8ADB-BC9834B5C26E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 29 Nov 2017 10:44:49 -0800 In-Reply-To: Cc: "v6ops@ietf.org" To: Paul Marks References: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 18:44:43 -0000 --Apple-Mail=_7DBC2379-EEF7-42B0-8ADB-BC9834B5C26E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 28, 2017, at 17:31, Paul Marks wrote: >=20 > When delegating to a host, I often wonder whether it's technically > incorrect to use prefix::0 as a normal address. Does anyone know for > sure? RFC4291 pretty clearly specifies that [$prefix::] is one of the Subnet = Router anycast addresses in the set of all subnets where n >=3D = len($prefix), where the IID on the link type is (n - 128), and where the = subnet prefix is [$prefix::/n]. --james woodyatt > --Apple-Mail=_7DBC2379-EEF7-42B0-8ADB-BC9834B5C26E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Nov 28, 2017, at 17:31, Paul Marks <pmarks@google.com> = wrote:

When delegating to = a host, I often wonder whether it's technically
incorrect to use prefix::0 as a normal address. =  Does anyone know for
sure?

RFC4291 pretty = clearly specifies that [$prefix::] is one of the Subnet Router anycast = addresses in the set of all subnets where n >=3D len($prefix), where = the IID on the link type is (n - 128), and where the subnet prefix is = [$prefix::/n].


--james woodyatt <jhw@google.com>



= --Apple-Mail=_7DBC2379-EEF7-42B0-8ADB-BC9834B5C26E-- From nobody Wed Nov 29 15:02:15 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833561271FD for ; Wed, 29 Nov 2017 15:02:14 -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 3p8pY793x-gi for ; Wed, 29 Nov 2017 15:02:13 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17F412711A for ; Wed, 29 Nov 2017 15:02:12 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id l22so4914569wrc.11 for ; Wed, 29 Nov 2017 15:02:12 -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=b6L54FbQBQmawYbgYhBUhTUSAf9gDhtoR/RlWDzLwJM=; b=o45zDj0eoOyzxfh7UjX2BYNt7CbSQPpBYYTrSR43UvH11NKsrQK3xo/oVOPCFTgK23 ZnanXyrgpnlgBDJBQ9bIYXzIe05SlV1a/INW9BpJf7AD/7gG3xhmQ4wZxzrk5f0oLGYw 4bWgDlkJMKNRzUAh1w0b3mHnvlm8Iszkn/5EuD0UPLSVe0kHRLpULTLwOoYBgqa4d0IN 0pfrxjF8RIVhG0A01XS1v9lRlOOS4VwA1UazenKI4HMa66j8Zx5Mt1OP/nKKafAqF9Io 6RebzFOYwHmPNLbgmzpI82QPZW0r58DlmGViffCVJWsbfIurzz1FQz7PIF3uu55UuQFd ZoVQ== 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=b6L54FbQBQmawYbgYhBUhTUSAf9gDhtoR/RlWDzLwJM=; b=CN2Kwq5H4KRl1Bp/Yd4oxg0c2KMM+nAc/6p4WeXfwrTYysnIpHAU/l9upjmfsvV7zz CGVzHB/Oa3BbiofqtyDPJPmJ62HLMnNuRSdW8AOsv9qrwV8W8qTSv/pVWB6dghPfTrHn JMUZ6dAyvsX4L6dIDN8pJ9BuiSBcfBe0sZBlY03qP7x/+eDvmXv73tsZpHF0xhOsA+eB rBKFkEkoKZEspHlEyaSJKDXitot212q5JH95L3U3x4t3grBfG/mNAvq5wCYVv7MMgRt4 M66BL4jgFkjztt6wFOmvaMmtPvRHOdhJRlODvcoo8N9uALA4rD8s83DgLOc63kvd5Kfj n7ZA== X-Gm-Message-State: AJaThX51tkHjNaM9eL8eg1c10FGicSkaky/YSvFMuRynhUvKYyM/r4An VnnJJMd3G1Qu09I/TXU7aMsgzLzOVRZSZEkjHIazlwe2X+I= X-Google-Smtp-Source: AGs4zMYz32w0rKjk7EU5AiJnlAliioPPXRFHO0xWlyiujON/dmkKH+whfQwEE3akbhJno1L+4IOZvIbEyO42BiKXS+0= X-Received: by 10.223.144.36 with SMTP id h33mr321659wrh.180.1511996530970; Wed, 29 Nov 2017 15:02:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.161.4 with HTTP; Wed, 29 Nov 2017 15:01:49 -0800 (PST) In-Reply-To: <42B4C703-00FF-4C44-984D-71D5A7736BE9@google.com> References: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> <42B4C703-00FF-4C44-984D-71D5A7736BE9@google.com> From: Paul Marks Date: Wed, 29 Nov 2017 15:01:49 -0800 Message-ID: To: james woodyatt Cc: "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c06990621d570055f2720d3" Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 23:02:14 -0000 --94eb2c06990621d570055f2720d3 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 29, 2017 at 10:44 AM, james woodyatt wrote: > On Nov 28, 2017, at 17:31, Paul Marks wrote: > > > When delegating to a host, I often wonder whether it's technically > incorrect to use prefix::0 as a normal address. Does anyone know for > sure? > > > RFC4291 pretty clearly specifies that [$prefix::] is one of the Subnet > Router anycast addresses in the set of all subnets where n >= len($prefix), > where the IID on the link type is (n - 128), and where the subnet prefix is > [$prefix::/n]. > > RFC4291 says "a subnet prefix is associated with one link", but a pdhost prefix is assigned to a host, which doesn't really behave like a link (there's no neighbor discovery, for example.) So, is a pdhost prefix actually a "subnet prefix" (with reserved addresses), or something distinct? I would advocate for permitting the host to do whatever it wants with the (128-n) bits. That could include "treat it like a regular subnet prefix" or "build a service where every hash(content) gets an IP address." --94eb2c06990621d570055f2720d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 29, 2017 at 10:44 AM, james woodyatt <jhw@google.com> = wrote:
On Nov 28, 2017, at 17:31, Paul= Marks <pmarks@go= ogle.com> wrote:

When delegating to a host, I often wonder whether it's techn= ically
incorrect to use prefix::0 a= s a normal address.=C2=A0 Does anyone know for
sure?

RFC4291= pretty clearly specifies that [$prefix::] is one of the Subnet Router anyc= ast addresses in the set of all subnets where n >=3D len($prefix), where= the IID on the link type is (n - 128), and where the subnet prefix is [$pr= efix::/n].


RFC42= 91 says "a subnet prefix is=C2=A0associated with one link", but a= pdhost prefix is assigned to a host, which doesn't really behave like = a link (there's no neighbor discovery, for example.)

So, is a pdhost prefix actually a "subnet prefix" (with re= served addresses), or something distinct?

I would = advocate for permitting the host to do whatever it wants with the (128-n) b= its.=C2=A0 That could include "treat it like a regular subnet prefix&q= uot; or "build a service where every hash(content) gets an IP address.= "
--94eb2c06990621d570055f2720d3-- From nobody Wed Nov 29 15:32:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C148F12700F for ; Wed, 29 Nov 2017 15:32: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 01Jsin_86PCL for ; Wed, 29 Nov 2017 15:32:28 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 4283B126E3A for ; Wed, 29 Nov 2017 15:32:28 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id e74so4615426ote.7 for ; Wed, 29 Nov 2017 15:32:28 -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=CofN6bXZIXKYpx9YdYX7nQyTmkDhfQQl/Lu2HVEXvrk=; b=s6IxfvglDOPp6uE1gG4CjvftbIdx/zEfhbBv7XCMSvsfQHk88DMSz1PuW/diXzLN1V Xlpqnng5glvOwvE/+uQxDDT/rh9jg4Li+P39DPuPVX20KQ9+POg5mSWvwGeHYtTHTd3N ZQAgG1jQfudmy2U1DDs/RQ9UUVQM30tHit58VPI7T09UUadTvJ5Fo1ZfKWYLuDsXenld ebUZVWfLtX5W5iF8soPAJYXl5PsmswDBFZ/MIJ1sx/jJW3PsgwZTGEr7znQ/wIc4Fds8 juG4caMyyZUHSX/VuR5tR9lcFvlyDQrfx25LNZq/FE7ezuM2pZCsb9fmmqYSG6RrPdTi lI+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=CofN6bXZIXKYpx9YdYX7nQyTmkDhfQQl/Lu2HVEXvrk=; b=LvSIq/5OX2Q+XU90gkgvvKluuS874KXn+DPUjOhjKCSCiMGIRypH/uT6X/8e3VPlmo njDHybZef39yt5go2mCyf0RCk8iB9jDVi/XxgRMUESg3CCG5yyMtLODdrRtVP2SgKwIx Q0lJnvlAJzuJ4WWl6lU+PmAqS/+34PyY+/ynqaiuMgv/NHlctjAFY5oHqDihvyCScQyi wytQULw5D/DtPmgYxKIE5/oTOZi8ghQsKriFFzheQ93X/i4SM3xEapqVpxE4aarMreUd fcAvgmrnQ08qkKnw8ScaijjQ4gHxdO/A6EWi7ZtltNEHwB2ksw9UB08VLFr2nC8Fv2G3 fStQ== X-Gm-Message-State: AJaThX5JWjSu8/XO91U5pFzCsqODSORJ/g+JrOrtDUTJcKiL6sTyq09x biCyTOu4cLzKVIhiswHYaUQ= X-Google-Smtp-Source: AGs4zMboNW0mmxdxjEyK2K+g3cxEhyv/skrKOthi85UqPdZPLV6ft+7SoDtpPktrU4XKwsKXoUgUOg== X-Received: by 10.157.51.143 with SMTP id u15mr3475609otc.98.1511998347680; Wed, 29 Nov 2017 15:32:27 -0800 (PST) Received: from ?IPv6:2600:8802:5600:f7a::1028? ([2600:8802:5600:f7a::1028]) by smtp.gmail.com with ESMTPSA id x127sm1172762oix.8.2017.11.29.15.32.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 15:32:26 -0800 (PST) From: Fred Baker Message-Id: <9A3E4D1C-A244-4562-9AEC-63F0CB67FDAA@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_735345C6-D78B-4D60-9DA3-1BB2D23167AE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 29 Nov 2017 15:32:24 -0800 In-Reply-To: Cc: james woodyatt , "v6ops@ietf.org" To: Paul Marks References: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> <42B4C703-00FF-4C44-984D-71D5A7736BE9@google.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 23:32:30 -0000 --Apple-Mail=_735345C6-D78B-4D60-9DA3-1BB2D23167AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 29, 2017, at 3:01 PM, Paul Marks wrote: >=20 > RFC4291 says "a subnet prefix is associated with one link", but a = pdhost prefix is assigned to a host, which doesn't really behave like a = link (there's no neighbor discovery, for example.) >=20 > So, is a pdhost prefix actually a "subnet prefix" (with reserved = addresses), or something distinct? I would argue that it is a prefix, in the sense that a prefix advertised = in BGP is a prefix. > I would advocate for permitting the host to do whatever it wants with = the (128-n) bits. That could include "treat it like a regular subnet = prefix" or "build a service where every hash(content) gets an IP = address." I'm not going to argue against that. That said, "every hash gets an = address" works for a 64 bit IID if the hash can be expressed in 64 bits. = It might argue in a direction you didn't intend. And you really don't = want to make 128-n work badly for SLAAC, if fielded systems use SLACC = (I'm told a number of them do). I tend to think of the IA_PD prefix as a bundle of /64 prefixes. --Apple-Mail=_735345C6-D78B-4D60-9DA3-1BB2D23167AE 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+AFAlofQ4gACgkQEhdRnd2G P+D2Mg/+OfCRSzpe26yRBhLg4DJgRzD28Xz+NN1nuaN7OfsjrFGMF+od3E+FWQvU 0YS0TM49M1gsiGnztKPIANaBEgKShQwjjmn/c92tbhFVvNT2VrJUUbwHT3E3AMma 15h3btiQnOeOVdOV5GqjH06y8z6iQnwNMrGVXFnXh9MquatocVP+qlYMqLATkglr 1bRiRlAWPXiPZE5r+L9RgUUQutVlqr2/bUju3uyx3ga2ZHbLdCOcGajxp040qXuC 9IwyhXa/aj31josJDmc/ykTKBMLW/jdcTeNig01BbnBvWygmGfLN1ui+o86S5IjR wPxE7v4c7+PXDo5Uh4lXgrbyyWCk0WX3Ry6S4LQxjMWIP/4axN88xhoccRTeeaeF DZAeOhlTwhcM9/AinuivmC/rAMHdJ9j6plchASr6kWXRxucPk3cPLLLnKoNc0IG0 clJnPBJhJw1wxp55MOCy/GgrU/1+Z5gE45A8fpWCrwrm587SadZkOoIWRuFM2LKR NlcxvsszIVJBfbQ+jBz/B7IxWb9e3DYQZZ3DOtZq9NsuTiGUfrmTx1XDzLrrEIGo PAzGS331RdUsPE7p0mC32VnOYIuxnI2R85PM9SRtDZGOByYXoR5GVicoU5RPtNzP F62DsMqo8OuUfuglkBmp7J51p5OfRQOCw/sP+Glzf7NiWmPq8f0= =qSCr -----END PGP SIGNATURE----- --Apple-Mail=_735345C6-D78B-4D60-9DA3-1BB2D23167AE-- From nobody Wed Nov 29 16:16:59 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D642D124D6C for ; Wed, 29 Nov 2017 16:16:54 -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 8WGkVWmF1MRQ for ; Wed, 29 Nov 2017 16:16:53 -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 8A3A912773A for ; Wed, 29 Nov 2017 16:16:53 -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 vAU0GrHC009924; Wed, 29 Nov 2017 17:16:53 -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 vAU0GoEm009519 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 29 Nov 2017 17:16:50 -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, 29 Nov 2017 16:16: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; Wed, 29 Nov 2017 16:16:49 -0800 From: "Templin, Fred L" To: Fred Baker , Paul Marks CC: james woodyatt , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdNoiEQoZAX3ZeaJTjOHwVsWAIjDPwA3drClABHPmwAAD36YYA== Date: Thu, 30 Nov 2017 00:16:49 +0000 Message-ID: <9440cb6c90ed4239b6c3cfcce208c5f3@XCH15-06-08.nw.nos.boeing.com> References: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> <42B4C703-00FF-4C44-984D-71D5A7736BE9@google.com> <9A3E4D1C-A244-4562-9AEC-63F0CB67FDAA@gmail.com> In-Reply-To: <9A3E4D1C-A244-4562-9AEC-63F0CB67FDAA@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 00:16:55 -0000 I agree with Fred. The delegated prefix shows up in the routing system the same as for any prefix, and the host needs to be the steward of the prefix in the same sense as an ordinary router would. From the outside world, the behavior of a host with a delegated prefix should be indiscernible from that of an ordinary router, i.e., even though it acts as a host internally. This brings up an interesting question, however - should the host respond to packets addressed to the subnet router anycast address? Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker > Sent: Wednesday, November 29, 2017 3:32 PM > To: Paul Marks > Cc: james woodyatt ; v6ops@ietf.org > Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? >=20 >=20 >=20 > > On Nov 29, 2017, at 3:01 PM, Paul Marks wrote: > > > > RFC4291 says "a subnet prefix is associated with one link", but a pdhos= t prefix is assigned to a host, which doesn't really behave like a > link (there's no neighbor discovery, for example.) > > > > So, is a pdhost prefix actually a "subnet prefix" (with reserved addres= ses), or something distinct? >=20 > I would argue that it is a prefix, in the sense that a prefix advertised = in BGP is a prefix. >=20 > > I would advocate for permitting the host to do whatever it wants with t= he (128-n) bits. That could include "treat it like a regular > subnet prefix" or "build a service where every hash(content) gets an IP a= ddress." >=20 > I'm not going to argue against that. That said, "every hash gets an addre= ss" works for a 64 bit IID if the hash can be expressed in 64 bits. > It might argue in a direction you didn't intend. And you really don't wan= t to make 128-n work badly for SLAAC, if fielded systems use > SLACC (I'm told a number of them do). >=20 > I tend to think of the IA_PD prefix as a bundle of /64 prefixes. From nobody Wed Nov 29 16:19:57 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BC41287A7 for ; Wed, 29 Nov 2017 16:19:55 -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 PPt0aIVQE13E for ; Wed, 29 Nov 2017 16:19:54 -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 99C951286B1 for ; Wed, 29 Nov 2017 16:19:52 -0800 (PST) Received: by mail-pl0-x22b.google.com with SMTP id bd8so3118206plb.9 for ; Wed, 29 Nov 2017 16:19:52 -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=m3w3rh5OX5fUnYG5w1RyxbU32Hu0RvTto8DOr9fhzl0=; b=ZI8DdFQz7D4F63h+OKyGzwZfUsm1QqbT8OGOoymK8ALMuP1t6UOSXNR/2vPjPnCIGj 6/S0k/Id/PDVCeUUKSSG7wYfZu1C86YMELD+7EXwM5iwfp2j90MUnN8JQRVqRP7aqIw4 PU8ueIdUfDG8T9IPXnteo+hO2VlK1Smh2EsHGWakRfLVGoBAaQz/4+EKIhzFxyO/oE14 CsxdvvjOMOCGM5w7ZRcmfwYl99M9WhoJ19IBwPavajWTP6CSSszxIGp1gPH50up1gw0F 8EHjHfzYIpdmwZVb6zk73RHs/KP+9N1VwwK0dLdmL6GzSMFA0ndQQRAdoGtpjy1KKcE7 MvIw== 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=m3w3rh5OX5fUnYG5w1RyxbU32Hu0RvTto8DOr9fhzl0=; b=Bxg23l9j+zSiYeCggll9d7DjmsbiPL2q1REi9Ksgg25DpqoKrVRJoV4ReHyHlOTNJS lsH/n0aK493z69/v+/OoxCsc+92GOSqBH8z4Saz8orXgvxWQMXY0jr0EbSBHn1r7Kj5X uda6mWOXKKxr2sApo2VqRzQeiM8fnnRF6/rGg+6mmSFjNUKBbXWy9iXeiQckdppDhUT8 p8nncIN90zgl+QNI2B3aAjskC/2GwPkkZF85iaQ+F7esZq0ioQhz08RG7AnnALfFX+Xn VYG78EYk0lULOCpg03TkB/Aemo9rEzN40DupZ6kPuOLNnMU3DomGjC6kTZoINQ6AdZW/ adHw== X-Gm-Message-State: AJaThX48EspI8wlGFybUD9+zI+b5DIEx661klj6ljsKBgxY0kCJTU1z6 BGmc1g8SzCYLT/tBHm7ZH8Qg5Q== X-Google-Smtp-Source: AGs4zMb+Ea9DtrSrg5Z0cgzOp7iV0s5JsChLv+PQ+qd5w1iM8zF8yFg2LkGIXU2NmGSTx45PHjxr2w== X-Received: by 10.84.232.200 with SMTP id x8mr639693plm.101.1512001192068; Wed, 29 Nov 2017 16:19:52 -0800 (PST) Received: from ?IPv6:2620::10e7:10:3d62:1d60:85d9:a6b5? ([2620:0:10e7:10:3d62:1d60:85d9:a6b5]) by smtp.gmail.com with ESMTPSA id r86sm5222551pfk.114.2017.11.29.16.19.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Nov 2017 16:19:51 -0800 (PST) From: james woodyatt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E7EA8604-E28E-4E31-987C-CF8660B0B668" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 29 Nov 2017 16:19:50 -0800 In-Reply-To: Cc: "v6ops@ietf.org" To: Paul Marks References: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> <42B4C703-00FF-4C44-984D-71D5A7736BE9@google.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 00:19:55 -0000 --Apple-Mail=_E7EA8604-E28E-4E31-987C-CF8660B0B668 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 29, 2017, at 15:01, Paul Marks wrote: >=20 > So, is a pdhost prefix actually a "subnet prefix" (with reserved = addresses), or something distinct? No, it is merely a routing prefix. Its length is not restricted to that = defined for subnets of the link type. --james woodyatt > --Apple-Mail=_E7EA8604-E28E-4E31-987C-CF8660B0B668 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Nov 29, 2017, at 15:01, Paul Marks <pmarks@google.com> = wrote:

So, is a pdhost prefix actually = a "subnet prefix" (with reserved addresses), or something = distinct?

No, it is merely a routing prefix. Its = length is not restricted to that defined for subnets of the link = type.

--james woodyatt <jhw@google.com>



= --Apple-Mail=_E7EA8604-E28E-4E31-987C-CF8660B0B668-- From nobody Wed Nov 29 16:22:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C901287A3 for ; Wed, 29 Nov 2017 16:22:23 -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 v88XUwZ0ymKi for ; Wed, 29 Nov 2017 16:22:22 -0800 (PST) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160541241FC for ; Wed, 29 Nov 2017 16:22:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id vAU0MLgL003051; Wed, 29 Nov 2017 17:22:21 -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 vAU0MHgI002668 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 29 Nov 2017 17:22:17 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 29 Nov 2017 16:22:16 -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, 29 Nov 2017 16:22:17 -0800 From: "Templin, Fred L" To: james woodyatt , Paul Marks CC: "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost a working group draft? Thread-Index: AdNoiEQoZAX3ZeaJTjOHwVsWAIjDPwA6Lnl2AAAMi0A= Date: Thu, 30 Nov 2017 00:22:16 +0000 Message-ID: References: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> <42B4C703-00FF-4C44-984D-71D5A7736BE9@google.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_a8d36b0e5c69480c8661e990c14d8fa9XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 00:22:23 -0000 --_000_a8d36b0e5c69480c8661e990c14d8fa9XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree. From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Wednesday, November 29, 2017 4:20 PM To: Paul Marks Cc: v6ops@ietf.org Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? On Nov 29, 2017, at 15:01, Paul Marks > wrote: So, is a pdhost prefix actually a "subnet prefix" (with reserved addresses)= , or something distinct? No, it is merely a routing prefix. Its length is not restricted to that def= ined for subnets of the link type. --james woodyatt > --_000_a8d36b0e5c69480c8661e990c14d8fa9XCH150608nwnosboeingcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree.

 

From: v6ops [mailto:v6ops-bounces@ie= tf.org] On Behalf Of james woodyatt
Sent: Wednesday, November 29, 2017 4:20 PM
To: Paul Marks <pmarks@google.com>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draf= t?

 

On Nov 29, 2017, at 15:01, Paul Marks <pmarks@google.com> wrote:

 

So, is a pdhost prefix actually a "subnet pre= fix" (with reserved addresses), or something distinct?

 

No, it is merely a routing prefix. Its length is not= restricted to that defined for subnets of the link type.

 

--james woodyatt <jhw@google.com>

 

 

 

--_000_a8d36b0e5c69480c8661e990c14d8fa9XCH150608nwnosboeingcom_-- From nobody Wed Nov 29 16:45:31 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDC41287A0 for ; Wed, 29 Nov 2017 16:45:29 -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 dYK3GDUoQbB0 for ; Wed, 29 Nov 2017 16:45:27 -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 53C88126D73 for ; Wed, 29 Nov 2017 16:45:27 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vAU0jPOV025078 for ; Thu, 30 Nov 2017 01:45:25 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5D6A5207A63 for ; Thu, 30 Nov 2017 01:45:25 +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 540622079B1 for ; Thu, 30 Nov 2017 01:45:25 +0100 (CET) Received: from [132.166.84.5] ([132.166.84.5]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vAU0jOCk028175 for ; Thu, 30 Nov 2017 01:45:25 +0100 To: v6ops@ietf.org References: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: Date: Thu, 30 Nov 2017 01:45:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <34cf035352254aadb3146dffb3baebb0@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 00:45:29 -0000 Le 28/11/2017 à 21:37, Templin, Fred L a écrit : > See below for an updated version of this draft. This version addresses comments > received on the list regarding more clearly identifying classes of devices that can > be considered as ordinary routers. > > Can we have this version as a wg item? I support adoption. Alex > > Thanks - Fred > > -----Original Message----- > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Tuesday, November 28, 2017 12:27 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-templin-v6ops-pdhost-16.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 Prefix Delegation Models > Author : Fred L. Templin > Filename : draft-templin-v6ops-pdhost-16.txt > Pages : 12 > Date : 2017-11-28 > > Abstract: > IPv6 prefixes are typically delegated to requesting routers which > then use them to number their downstream-attached links and networks. > This document considers prefix delegation models according to whether > the requesting router acts as a router on behalf of any downstream > networks, as host on behalf of its local applications or as both. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-templin-v6ops-pdhost-16 > https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-16 > > > 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 > From nobody Thu Nov 30 08:18:35 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3534E129410 for ; Thu, 30 Nov 2017 08:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQuguJbBjvVM for ; Thu, 30 Nov 2017 08:18:31 -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 962481200FC for ; Thu, 30 Nov 2017 08:18:31 -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 vAUGITJK019482 for ; Thu, 30 Nov 2017 17:18:29 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 9FA312052FA for ; Thu, 30 Nov 2017 17:18:29 +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 871332040DE for ; Thu, 30 Nov 2017 17:18:29 +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 vAUGITav013755 for ; Thu, 30 Nov 2017 17:18:29 +0100 To: v6ops@ietf.org References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> From: Alexandre Petrescu Message-ID: <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> Date: Thu, 30 Nov 2017 17:18:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 16:18:34 -0000 v6opsers, We succeeded in making DHCPv6 PD work natively on a cellular link. I would claim it to be a first[*]. Packet dump available upon request. The UE device is a Huawei E392u-12 USB dongle produced in 2011. It hosts a baseband processor Qualcomm model MDM9600 (or model MDM9200, or an Intel - not sure). It lets all standard DHCPv6 messaging through. The DHCPv6 client 'odhcpv6' is running on linux laptop. The mobile operator's PGW assigns a /56 and sets proper forwarding for it. The PGW runs on a big Cisco platform. After the successful DHCP exchange the laptop is able to ping google with a src address which is manually derived out of the /56 delegated prefix. That said, DHCPv6-PD on cellular links is relevant for a few RFCs and Internet Drafts. They should be improved because at places these documents are a little bit wrong. DHCPv6-PD is blocked on other baseband processors, including Qualcomm and Balong versions; they are hosted by many smartphones, USB cellular dongles, mobile personal WiFi hotspots and IoT devices. A sample list is available upon request. Last but not least, [*] earlier DHCPv6 PD on cellular links was shown on tunnel virtual interfaces, like VPN. Alex From nobody Thu Nov 30 08:43:10 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DEF1200FC; Thu, 30 Nov 2017 08:43:02 -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 wDvSN1pO4bgx; Thu, 30 Nov 2017 08:43:01 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6778127876; Thu, 30 Nov 2017 08:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5729; q=dns/txt; s=iport; t=1512060180; x=1513269780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=16wtuIoMF7/QQLYa8IocJVofK5fkSEzYjBSxHgDg+j4=; b=HmInbHeWL+/ocZs3M1MfgdNI+SLpvPQr4iV94Gln41sKnOapMk+KwwGn +ZqdTs8cSeORfMq3VBh3g2W5QazHDkAUbCPM1PSeecIdNc/mlYxhRlPTP laRRxJOGIHvXtNsqaItPJhPL0Gxyt5grJSFZmAfYwIA4LIgjZiDrEnRgz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AgAdNCBa/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8Zm4ng3+ZEopoiECFS4IRChgBCoUYAhqFB0AXAQEBAQEBAQE?= =?us-ascii?q?BayiFIAIEAQEhSwsQAgEIBDsDAgICHwYLFBECBA4FiT5MAxUQpheCJ4c0DYMkA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWDQYIJg2iDAoJrhUoxgjIFoh49ApAVhHq?= =?us-ascii?q?TU403iGECERkBgTkBIQE2M4EebxU6KgGBfoJSBReBZ3iKAwEBAQ?= X-IronPort-AV: E=Sophos; i="5.45,341,1508803200"; d="scan'208,217"; a="38643033" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2017 16:43:00 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vAUGgxI0012832 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Nov 2017 16:42:59 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 30 Nov 2017 10:42:59 -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; Thu, 30 Nov 2017 10:42:59 -0600 From: "Bernie Volz (volz)" To: Alexandre Petrescu CC: "v6ops@ietf.org" , "dhcwg@ietf.org" Thread-Topic: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok Thread-Index: AQHTafbnOF1NwEy2cE6/8AeiHgsEYaMtIKEz Date: Thu, 30 Nov 2017 16:42:59 +0000 Message-ID: <87D21F39-7C1D-4F08-A3EE-39882C8832E6@cisco.com> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com>, <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> In-Reply-To: <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> 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_87D21F397C1D4F08A3EE39882C8832E6ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 16:43:02 -0000 --_000_87D21F397C1D4F08A3EE39882C8832E6ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBuZXchIQ0KDQotIEJlcm5pZSAoZnJvbSBpUGhvbmUpDQoNCk9uIE5vdiAzMCwgMjAxNywg YXQgMTE6MTggQU0sIEFsZXhhbmRyZSBQZXRyZXNjdSA8YWxleGFuZHJlLnBldHJlc2N1QGdtYWls LmNvbTxtYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQp2Nm9w c2VycywNCg0KV2Ugc3VjY2VlZGVkIGluIG1ha2luZyBESENQdjYgUEQgd29yayBuYXRpdmVseSBv biBhIGNlbGx1bGFyIGxpbmsuDQpJIHdvdWxkIGNsYWltIGl0IHRvIGJlIGEgZmlyc3RbKl0uDQpQ YWNrZXQgZHVtcCBhdmFpbGFibGUgdXBvbiByZXF1ZXN0Lg0KDQpUaGUgVUUgZGV2aWNlIGlzIGEg SHVhd2VpIEUzOTJ1LTEyIFVTQiBkb25nbGUgcHJvZHVjZWQgaW4gMjAxMS4gIEl0IGhvc3RzIGEg YmFzZWJhbmQgcHJvY2Vzc29yIFF1YWxjb21tIG1vZGVsIE1ETTk2MDAgKG9yIG1vZGVsIE1ETTky MDAsIG9yIGFuIEludGVsIC0gbm90IHN1cmUpLiAgSXQgbGV0cyBhbGwgc3RhbmRhcmQgREhDUHY2 IG1lc3NhZ2luZyB0aHJvdWdoLiBUaGUgREhDUHY2IGNsaWVudCAnb2RoY3B2NicgaXMgcnVubmlu ZyBvbiBsaW51eCBsYXB0b3AuDQoNClRoZSBtb2JpbGUgb3BlcmF0b3IncyBQR1cgYXNzaWducyBh IC81NiBhbmQgc2V0cyBwcm9wZXIgZm9yd2FyZGluZyBmb3IgaXQuICBUaGUgUEdXIHJ1bnMgb24g YSBiaWcgQ2lzY28gcGxhdGZvcm0uDQoNCkFmdGVyIHRoZSBzdWNjZXNzZnVsIERIQ1AgZXhjaGFu Z2UgdGhlIGxhcHRvcCBpcyBhYmxlIHRvIHBpbmcgZ29vZ2xlIHdpdGggYSBzcmMgYWRkcmVzcyB3 aGljaCBpcyBtYW51YWxseSBkZXJpdmVkIG91dCBvZiB0aGUgLzU2IGRlbGVnYXRlZCBwcmVmaXgu DQoNClRoYXQgc2FpZCwNCg0KREhDUHY2LVBEIG9uIGNlbGx1bGFyIGxpbmtzIGlzIHJlbGV2YW50 IGZvciBhIGZldyBSRkNzIGFuZCBJbnRlcm5ldCBEcmFmdHMuICBUaGV5IHNob3VsZCBiZSBpbXBy b3ZlZCBiZWNhdXNlIGF0IHBsYWNlcyB0aGVzZSBkb2N1bWVudHMgYXJlIGEgbGl0dGxlIGJpdCB3 cm9uZy4NCg0KREhDUHY2LVBEIGlzIGJsb2NrZWQgb24gb3RoZXIgYmFzZWJhbmQgcHJvY2Vzc29y cywgaW5jbHVkaW5nIFF1YWxjb21tIGFuZCBCYWxvbmcgdmVyc2lvbnM7IHRoZXkgYXJlIGhvc3Rl ZCBieSBtYW55IHNtYXJ0cGhvbmVzLCBVU0IgY2VsbHVsYXIgZG9uZ2xlcywgbW9iaWxlIHBlcnNv bmFsIFdpRmkgaG90c3BvdHMgYW5kIElvVCBkZXZpY2VzLiAgQSBzYW1wbGUgbGlzdCBpcyBhdmFp bGFibGUgdXBvbiByZXF1ZXN0Lg0KDQpMYXN0IGJ1dCBub3QgbGVhc3QsDQoNClsqXSBlYXJsaWVy IERIQ1B2NiBQRCBvbiBjZWxsdWxhciBsaW5rcyB3YXMgc2hvd24gb24gdHVubmVsIHZpcnR1YWwg aW50ZXJmYWNlcywgbGlrZSBWUE4uDQoNCkFsZXgNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5v cmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wcw0K --_000_87D21F397C1D4F08A3EE39882C8832E6ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpH b29kIG5ldyEhPGJyPg0KPGJyPg0KPGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj4tIEJlcm5p ZSAoZnJvbSBpUGhvbmUpPC9kaXY+DQo8ZGl2Pjxicj4NCk9uIE5vdiAzMCwgMjAxNywgYXQgMTE6 MTggQU0sIEFsZXhhbmRyZSBQZXRyZXNjdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRyZS5w ZXRyZXNjdUBnbWFpbC5jb20iPmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQo8YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48 c3Bhbj52Nm9wc2Vycyw8L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPldlIHN1 Y2NlZWRlZCBpbiBtYWtpbmcgREhDUHY2IFBEIHdvcmsgbmF0aXZlbHkgb24gYSBjZWxsdWxhciBs aW5rLjwvc3Bhbj48YnI+DQo8c3Bhbj5JIHdvdWxkIGNsYWltIGl0IHRvIGJlIGEgZmlyc3RbKl0u PC9zcGFuPjxicj4NCjxzcGFuPlBhY2tldCBkdW1wIGF2YWlsYWJsZSB1cG9uIHJlcXVlc3QuPC9z cGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5UaGUgVUUgZGV2aWNlIGlzIGEgSHVh d2VpIEUzOTJ1LTEyIFVTQiBkb25nbGUgcHJvZHVjZWQgaW4gMjAxMS4gJm5ic3A7SXQgaG9zdHMg YSBiYXNlYmFuZCBwcm9jZXNzb3IgUXVhbGNvbW0gbW9kZWwgTURNOTYwMCAob3IgbW9kZWwgTURN OTIwMCwgb3IgYW4gSW50ZWwgLSBub3Qgc3VyZSkuICZuYnNwO0l0IGxldHMgYWxsIHN0YW5kYXJk IERIQ1B2NiBtZXNzYWdpbmcgdGhyb3VnaC4gVGhlIERIQ1B2NiBjbGllbnQgJ29kaGNwdjYnIGlz IHJ1bm5pbmcgb24NCiBsaW51eCBsYXB0b3AuPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+ DQo8c3Bhbj5UaGUgbW9iaWxlIG9wZXJhdG9yJ3MgUEdXIGFzc2lnbnMgYSAvNTYgYW5kIHNldHMg cHJvcGVyIGZvcndhcmRpbmcgZm9yIGl0LiAmbmJzcDtUaGUgUEdXIHJ1bnMgb24gYSBiaWcgQ2lz Y28gcGxhdGZvcm0uPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5BZnRlciB0 aGUgc3VjY2Vzc2Z1bCBESENQIGV4Y2hhbmdlIHRoZSBsYXB0b3AgaXMgYWJsZSB0byBwaW5nIGdv b2dsZSB3aXRoIGEgc3JjIGFkZHJlc3Mgd2hpY2ggaXMgbWFudWFsbHkgZGVyaXZlZCBvdXQgb2Yg dGhlIC81NiBkZWxlZ2F0ZWQgcHJlZml4Ljwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0K PHNwYW4+VGhhdCBzYWlkLDwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+REhD UHY2LVBEIG9uIGNlbGx1bGFyIGxpbmtzIGlzIHJlbGV2YW50IGZvciBhIGZldyBSRkNzIGFuZCBJ bnRlcm5ldCBEcmFmdHMuICZuYnNwO1RoZXkgc2hvdWxkIGJlIGltcHJvdmVkIGJlY2F1c2UgYXQg cGxhY2VzIHRoZXNlIGRvY3VtZW50cyBhcmUgYSBsaXR0bGUgYml0IHdyb25nLjwvc3Bhbj48YnI+ DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+REhDUHY2LVBEIGlzIGJsb2NrZWQgb24gb3RoZXIg YmFzZWJhbmQgcHJvY2Vzc29ycywgaW5jbHVkaW5nIFF1YWxjb21tIGFuZCBCYWxvbmcgdmVyc2lv bnM7IHRoZXkgYXJlIGhvc3RlZCBieSBtYW55IHNtYXJ0cGhvbmVzLCBVU0IgY2VsbHVsYXIgZG9u Z2xlcywgbW9iaWxlIHBlcnNvbmFsIFdpRmkgaG90c3BvdHMgYW5kIElvVCBkZXZpY2VzLiAmbmJz cDtBIHNhbXBsZSBsaXN0IGlzIGF2YWlsYWJsZSB1cG9uIHJlcXVlc3QuPC9zcGFuPjxicj4NCjxz cGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5MYXN0IGJ1dCBub3QgbGVhc3QsPC9zcGFuPjxicj4NCjxz cGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5bKl0gZWFybGllciBESENQdjYgUEQgb24gY2VsbHVsYXIg bGlua3Mgd2FzIHNob3duIG9uIHR1bm5lbCB2aXJ0dWFsIGludGVyZmFjZXMsIGxpa2UgVlBOLjwv c3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+QWxleDwvc3Bhbj48YnI+DQo8c3Bh bj48L3NwYW4+PGJyPg0KPHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+djZvcHMgbWFpbGluZyBsaXN0PC9zcGFuPjxi cj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8 L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v djZvcHM8L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_87D21F397C1D4F08A3EE39882C8832E6ciscocom_-- From nobody Thu Nov 30 11:03:37 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82118129447; Thu, 30 Nov 2017 11:03: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mork.no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNCalpbIz0jq; Thu, 30 Nov 2017 11:03:23 -0800 (PST) Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201A3128959; Thu, 30 Nov 2017 11:03:22 -0800 (PST) Received: from miraculix.mork.no (miraculix.mork.no [IPv6:2001:4641:0:2:7627:374e:db74:e353]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id vAUJ3DOl023216 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Nov 2017 20:03:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1512068595; bh=XQ/UoHivB5Fz5Z8xyNaQUDe+FRsDdIvMSPtT2Y75pps=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=FeH1a0S+7bWA2M3vavfqJMcvudJcf6bnIIMXHYHwi39UiA49aZsaWaCj0xP6OlJt/ 67Wl2A20+oQ9gVscnL6U4R6cZu2FFFbphzKc0z3OZMH4w+ggq5yzqcrFkXD+pzUzP9 KcAmLcQl9yAkLBOMHgn7XlKz/rQ1s65NTlHRuHDw= Received: from bjorn by miraculix.mork.no with local (Exim 4.89) (envelope-from ) id 1eKU77-000055-Km; Thu, 30 Nov 2017 20:03:13 +0100 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: "Bernie Volz \(volz\)" Cc: Alexandre Petrescu , "dhcwg\@ietf.org" , "v6ops\@ietf.org" Organization: m References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> <87D21F39-7C1D-4F08-A3EE-39882C8832E6@cisco.com> Date: Thu, 30 Nov 2017 20:03:13 +0100 In-Reply-To: <87D21F39-7C1D-4F08-A3EE-39882C8832E6@cisco.com> (Bernie Volz's message of "Thu, 30 Nov 2017 16:42:59 +0000") Message-ID: <87a7z37fny.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.99.2 at canardo X-Virus-Status: Clean Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 19:03:25 -0000 > On Nov 30, 2017, at 11:18 AM, Alexandre Petrescu > wrote: > > v6opsers, > > We succeeded in making DHCPv6 PD work natively on a cellular link. > I would claim it to be a first[*]. > Packet dump available upon request. > > The UE device is a Huawei E392u-12 USB dongle produced in 2011. It > hosts a baseband processor Qualcomm model MDM9600 (or model MDM9200, > or an Intel - not sure). MDM9200. Not that it matters much... > It lets all standard DHCPv6 messaging through. The DHCPv6 client > 'odhcpv6' is running on linux laptop. Can't help being a bit curious about the Linux driver used for this test? PPP? qmi_wwan? Something else? (crossing fingers for qmi_wwan :-) > DHCPv6-PD is blocked on other baseband processors, including Qualcomm > and Balong versions; they are hosted by many smartphones, USB cellular > dongles, mobile personal WiFi hotspots and IoT devices. A sample list > is available upon request. Yes, the "smarter" these things get, the harder it is to make them work properly. Bj=C3=B8rn From nobody Thu Nov 30 15:30:29 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D41612704B for ; Thu, 30 Nov 2017 15:30:28 -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 TAebQISC-pKh for ; Thu, 30 Nov 2017 15:30:26 -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 11287120046 for ; Thu, 30 Nov 2017 15:30:26 -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 vAUNUPir006575; Thu, 30 Nov 2017 16:30:25 -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 vAUNUGD7006528 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 30 Nov 2017 16:30:16 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 30 Nov 2017 15:30:16 -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, 30 Nov 2017 15:30:16 -0800 From: "Templin, Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok Thread-Index: AQHTafbk8NbQK2MtQEiVBLaWU5iYrKMtkktA Date: Thu, 30 Nov 2017 23:30:16 +0000 Message-ID: <43f7ee15c68f4c089c4ed1bfbb72777d@XCH15-06-08.nw.nos.boeing.com> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> In-Reply-To: <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 23:30:28 -0000 That is great news, Alex - thanks. Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petres= cu > Sent: Thursday, November 30, 2017 8:18 AM > To: v6ops@ietf.org > Subject: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links -= works ok >=20 > v6opsers, >=20 > We succeeded in making DHCPv6 PD work natively on a cellular link. > I would claim it to be a first[*]. > Packet dump available upon request. >=20 > The UE device is a Huawei E392u-12 USB dongle produced in 2011. It > hosts a baseband processor Qualcomm model MDM9600 (or model MDM9200, or > an Intel - not sure). It lets all standard DHCPv6 messaging through. > The DHCPv6 client 'odhcpv6' is running on linux laptop. >=20 > The mobile operator's PGW assigns a /56 and sets proper forwarding for > it. The PGW runs on a big Cisco platform. >=20 > After the successful DHCP exchange the laptop is able to ping google > with a src address which is manually derived out of the /56 delegated > prefix. >=20 > That said, >=20 > DHCPv6-PD on cellular links is relevant for a few RFCs and Internet > Drafts. They should be improved because at places these documents are a > little bit wrong. >=20 > DHCPv6-PD is blocked on other baseband processors, including Qualcomm > and Balong versions; they are hosted by many smartphones, USB cellular > dongles, mobile personal WiFi hotspots and IoT devices. A sample list > is available upon request. >=20 > Last but not least, >=20 > [*] earlier DHCPv6 PD on cellular links was shown on tunnel virtual > interfaces, like VPN. >=20 > Alex >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Nov 30 15:48:56 2017 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA491252BA for ; Thu, 30 Nov 2017 15:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_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=shytyi.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Erus_YSwiyLt for ; Thu, 30 Nov 2017 15:48:52 -0800 (PST) Received: from sender-of-o51.zoho.eu (sender-of-o51.zoho.eu [87.252.213.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63B18120046 for ; Thu, 30 Nov 2017 15:48:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1512085727; s=hs; d=shytyi.net; i=ietf.dmytro@shytyi.net; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type; l=5664; bh=+Cj+BjIZ7cWOb5RYaGi1T87nCMbg9cQbXHEt6yd0JoU=; b=ff7pQJjKjuLOzY5Dx8GcnenxlOD+wMxZWrfz+cYKxTiI2/3pw/nBuUNzoZeupGvI tUOoSWqa7D4ujYQP7cvoOLAtkiHcJnMaPVjYXQ6EinDNa0LSA4AlvHnalciPc1X5cwm mD93JiLYhfUCA/CBqv88XlmGCgn1Q7J0gQVT8C1k= Received: from mail.zoho.eu (172.27.16.81 [172.27.16.81]) by mx.zoho.eu with SMTPS id 1512085727418394.818226575105; Fri, 1 Dec 2017 00:48:47 +0100 (CET) Date: Fri, 01 Dec 2017 00:48:47 +0100 From: Dmytro Shytyi To: "Alexandre Petrescu" Cc: Message-ID: <1600f552856.edeb728d17491.789678005895704045@shytyi.net> In-Reply-To: <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> References: <7537deef-8f87-5187-1e44-595ac63a16ca@gmail.com> <6077c7a4-01c8-8b80-588f-0ef4af153487@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_33625_1428592375.1512085727322" X-Priority: Medium X-ZohoMail-Sender: 78.122.18.3 User-Agent: Zoho Mail X-Mailer: Zoho Mail X-ZohoMailClient: External Archived-At: Subject: Re: [v6ops] DHCPv6 Prefix Delegation (DHCPv6 PD) on cellular links - works ok X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 23:48:54 -0000 ------=_Part_33625_1428592375.1512085727322 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hello, Congrats! It is really a great news. It would be much more pleasure to perform the DHCPv6_PD procedure without blockage, made by Qualcomm and Hisilicon. v6opsers, what could be a nice motivation for such vendors as Qualcomm to change their policy regarding the DHCPv6_PD support[*]. [*] without VPN usage. Dmytro SHYTYI ---- On Thu, 30 Nov 2017 17:18:29 +0100 Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote ---- v6opsers, We succeeded in making DHCPv6 PD work natively on a cellular link. I would claim it to be a first[*]. Packet dump available upon request. The UE device is a Huawei E392u-12 USB dongle produced in 2011. It hosts a baseband processor Qualcomm model MDM9600 (or model MDM9200, or an Intel - not sure). It lets all standard DHCPv6 messaging through. The DHCPv6 client 'odhcpv6' is running on linux laptop. The mobile operator's PGW assigns a /56 and sets proper forwarding for it. The PGW runs on a big Cisco platform. After the successful DHCP exchange the laptop is able to ping google with a src address which is manually derived out of the /56 delegated prefix. That said, DHCPv6-PD on cellular links is relevant for a few RFCs and Internet Drafts. They should be improved because at places these documents are a little bit wrong. DHCPv6-PD is blocked on other baseband processors, including Qualcomm and Balong versions; they are hosted by many smartphones, USB cellular dongles, mobile personal WiFi hotspots and IoT devices. A sample list is available upon request. Last but not least, [*] earlier DHCPv6 PD on cellular links was shown on tunnel virtual interfaces, like VPN. Alex _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------=_Part_33625_1428592375.1512085727322 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hello,

Congrats! It is real= ly a great news.
It would be much more pleasure to perform the DHCPv6_P= D procedure without blockage, made by Qualcomm and Hisilicon.
 
v6opsers, what could be a nice motivation for such vendors as Qu= alcomm to change their policy regarding the DHCPv6_PD support[*].
[*] without VPN usage.
         =                 
Dmytro SHYTYI


---- On Thu, 30 Nov= 2017 17:18:29 +0100 Alexandre Petrescu <alexandre.petrescu@gmai= l.com> wrote ----

=
v6opsers,

We succeeded in making DHCPv6= PD work natively on a cellular link.
I would claim it to be= a first[*].
Packet dump available upon request.
<= div>
The UE device is a Huawei E392u-12 USB dongle produced = in 2011. It
hosts a baseband processor Qualcomm model MDM96= 00 (or model MDM9200, or
an Intel - not sure). It lets all = standard DHCPv6 messaging through.
The DHCPv6 client 'odhcpv= 6' is running on linux laptop.

The mobile op= erator's PGW assigns a /56 and sets proper forwarding for
it= . The PGW runs on a big Cisco platform.

Aft= er the successful DHCP exchange the laptop is able to ping google
with a src address which is manually derived out of the /56 delegated=
prefix.

That said,

DHCPv6-PD on cellular links is relevant for a few RFC= s and Internet
Drafts. They should be improved because at p= laces these documents are a
little bit wrong.

DHCPv6-PD is blocked on other baseband processors, includi= ng Qualcomm
and Balong versions; they are hosted by many sma= rtphones, USB cellular
dongles, mobile personal WiFi hotspot= s and IoT devices. A sample list
is available upon request.=

Last but not least,

[*] earlier DHCPv6 PD on cellular links was shown on tunnel virtual=
interfaces, like VPN.

Alex <= br>

_____________________________________________= __
v6ops mailing list

------=_Part_33625_1428592375.1512085727322--